חיבור בין CRM למערכת חשבוניות נשבר על כפילויות לקוחות וכיוון סנכרון לא מוגדר. מה לחבר, מה להשאיר בנפרד, ואיך מונעים שתי רשומות לאותו לקוח.
עיקרי הדברים
- ראשית מכריעים מי המאסטר ללקוח - ורק אחר כך מחברים.
- כיוון אחד עדיף על שניים. סנכרון דו-כיווני על אותו שדה מתנגש בעצמו.
- המפתח לזיהוי צריך להיות מוסכם: טלפון, דוא"ל, או ח"פ - ולא שם.
- מה שחשוב לסנכרן זה מעט: לקוח, מסמכים, ומצב תשלום.
חיבור בין CRM למערכת חשבוניות נשמע כמו פרויקט טכני והוא בעיקר החלטה: מי מחזיק את רשומת הלקוח. שתי מערכות שמנהלות לקוחות בלי הכרעה כזו מייצרות שתי רשומות לאותו אדם, ואז מישהו שולח חשבונית לכתובת ישנה או מתקשר ללקוח שכבר קנה.
איך מחברים את חשבונית ירוקה (מורנינג), iCount או ריווחית ל-CRM או לאתר של העסק?
דרך ה-API של כל מערכת, ולא בסנכרון של הכול: ה-CRM או האתר יוצרים את הלקוח ומבקשים ממערכת החשבוניות להפיק את המסמך, ומערכת החשבוניות מחזירה את מספר המסמך, הקישור אליו ומצב התשלום. מורנינג ו-iCount יכולות לדחוף אירועים ב-webhook; ל-API המסמכים של רווחית קוראים ובודקים לפי לוח זמנים. אנחנו בונים חיבורים כאלה; תהליך אחד מתומחר ב-כ-900 - 5,400 ₪.
מורנינג, iCount ורווחית: מה כל API נותן ל-CRM
לשלוש מערכות החשבוניות הנפוצות בישראל יש API מתועד, אבל הן שונות בדיוק בנקודות שחיבור ל-CRM תלוי בהן:
| מורנינג (חשבונית ירוקה) | iCount | רווחית | |
|---|---|---|---|
| סגנון ואימות | REST, OAuth עם client credentials, טוקן שתקף לשעה | POST עם JSON ל-/api/v3.php/ ואחריו מודול ופעולה, טוקן Bearer בלי תפוגה | פעולות בשם בסגנון WCF, api_token בגוף הבקשה |
| הפקת מסמך | POST /documents | doc/create | Document.New |
| דחיפה ל-CRM | webhooks שמגדירים בממשק: document/created, payment/received, client/created | webhooks שנרשמים דרך ה-API עם webhook/add | התיעוד מפרט הודעות דחיפה (IPN) לתשלומי iCredit |
| הגנה מכפילות | מפתח משימה משלכם; שגיאה 1010 מסמנת בקשה עם נתונים זהים | sanity_string, עד 30 תווים | request_reference יחד עם prevent_duplicates |
| איפה נשמר המזהה של ה-CRM | שומרים את מזהה הלקוח של מורנינג ב-CRM; חיפוש לקוחות מסנן לפי שם, מייל, איש קשר ותוויות | custom_client_id | acc_ref, עד 9 תווים |
| יתרה פתוחה לכרטיס הלקוח | /clients/{id}/balance | client/get_balance, client/get_open_docs | Customer.Balance, Customer.OpenDocuments |
לכל מערכת לעומק: הפקת מסמכים דרך ה-API של חשבונית ירוקה (מורנינג), ה-API של iCount בגרסה 3 - אימות, doc/create ו-webhooks, וה-API של רווחית - Document.New, מניעת כפילויות ו-iCredit.
אילו תהליכים כדאי לחבר קודם?
- עסקה נסגרה ב-CRM. הלקוח נוצר או מתעדכן במערכת החשבוניות ומופק חשבון עסקה או חשבונית מס (במורנינג, סוג 300 או 305).
- התקבל תשלום. מופקת קבלה על החשבונית - במורנינג,
linkedDocumentIdsסוגר את המקור - וה-CRM מסמן את העסקה כשולמה. - הזמנה באתר שולמה. מופקת חשבונית מס קבלה (סוג 320 במורנינג,
invrecב-iCount) והקישור אליה נשמר על ההזמנה. - המסמך חוזר לכרטיס הלקוח. מספר וקישור, כדי שאף אחד לא יצטרך להיכנס למערכת החשבוניות כדי למצוא אותם.
- יתרה פתוחה בכרטיס הלקוח. נקראת מקריאות היתרה שבטבלה, כדי שאיש המכירות ידע לפני שהוא מתקשר.
מה מחברים ומה משאירים בנפרד?
| הנתון | לסנכרן? | הכיוון המומלץ |
|---|---|---|
| פרטי לקוח | כן | מ-CRM למערכת החשבוניות, אם שם מנהלים לקוחות |
| מסמכים שהופקו | כן | ממערכת החשבוניות ל-CRM, לצפייה |
| מצב תשלום | כן | ממערכת החשבוניות ל-CRM |
| הצעות מחיר | תלוי | לרוב מהמערכת שבה סוגרים מכירה |
| הזדמנויות ולידים | לא | אין להם מה לחפש במערכת חשבוניות |
| תכתובת ופעילות | לא | נשאר ב-CRM |
| פריטים ומחירים | לפעמים | מהמערכת שמנהלת מחירון |
השורה החמישית היא זו שעסקים מנסים לסנכרן בטעות: ליד שעוד לא קנה אינו לקוח, ואין סיבה שיופיע במערכת שמפיקה מסמכים. זה רק מנפח את הרשימה ומקשה על החיפוש.
למה זה נשבר: כפילויות
הבעיה המרכזית בכל חיבור כזה היא שאותו לקוח קיים פעמיים. זה קורה כי:
- השם נכתב אחרת בשתי המערכות - עם או בלי בע"מ, עם ניקוד או בלי.
- אין מפתח זיהוי מוסכם, ולכן ההתאמה נעשית לפי שם.
- לקוח נוצר ידנית באחת המערכות בזמן שהחיבור כבר קיים.
- אותו אדם עם שני מיילים - עסקי ופרטי.
הפתרון הוא להסכים על מפתח אחד ולאכוף אותו: טלפון נייד הוא בדרך כלל הבחירה הטובה בישראל, כי הוא ייחודי, יציב, וקיים כמעט תמיד. הטיפול המלא בכפילויות מפורט באיך מנקים נתונים מבולגנים.
webhook או משיכה: איך ה-CRM יודע שחשבונית שולמה?
| webhook | משיכה (polling) | |
|---|---|---|
| איך זה עובד | מערכת החשבוניות קוראת לכתובת שלכם כשקורה אירוע | המערכת שלכם שואלת לפי לוח זמנים: POST /documents/search במורנינג, doc/search ב-iCount, Document.List ברווחית |
| עיכוב | שניות | מרווח הבדיקה |
| מה זה דורש | כתובת HTTPS ציבורית, אימות חתימה, תשובה מהירה וסינון כפילויות | מתזמן שמכבד מגבלות - רווחית מאפשרת 200 בקשות בדקה, ובחיפוש של מורנינג עמוד מכיל עד 100 תוצאות |
| איך זה נכשל | בשקט: מורנינג מכבה webhook אחרי 15 משלוחים שנכשלו, ו-iCredit שולחת שוב הודעה שלא קיבלה 200 תוך 1.25 שניות | בגלוי: משימה מתוזמנת שלא רצה |
התשובה החסינה היא שניהם. ה-webhook נותן מהירות, ומעבר משיכה לילי משמש להתאמה: הוא משווה את המסמכים והתשלומים של היום למה שיש ב-CRM ומשלים את מה שמשלוח שפוספס השאיר מאחור.
מה שובר חיבור בין CRM למערכת חשבוניות בפועל?
- טוקן שנשמר לתמיד. טוקן הגישה של מורנינג תקף לשעה; משימה שלא מחדשת אותו מקבלת 401 באמצע ריצה.
- webhook שהשתתק. אחרי 15 משלוחים שנכשלו מורנינג מפסיקה לשלוח, ושום דבר ב-CRM לא מראה את זה.
- תשלום שנרשם פעמיים. שרת שעונה לאט גורם ל-iCredit לשלוח את ה-IPN שוב, ומטפל בלי סינון כפילויות רושם את התשלום פעמיים.
- פרטי לקוח שנחתכים. רווחית מגבילה את
last_nameל-30 תווים ואתacc_refל-9. - לקוח שנוצר פעמיים.
doc/createשל iCount יוצרת לקוח חדש כשהחיפוש לפי מזהה, מספר עוסק, מייל ושם לא מוצא כלום. - מסמך בדיקה שנשלח במייל ללקוח אמיתי. ברווחית ברירת המחדל של
send_mailהיא true. - תקרת המסמכים החודשית. מורנינג מחזירה שגיאה 1112 כשהחשבון מגיע למקסימום החודשי.
- מע"מ שנשלח כ-18. מורנינג מצפה לשיעור מע"מ בין 0 ל-1 ודוחה כל ערך אחר בשגיאה 1108.
סדר ההקמה
- להחליט מי המאסטר ללקוח. בדרך כלל ה-CRM, אם המכירות מתחילות שם.
- לבחור מפתח זיהוי ולוודא שהוא קיים ותקין בשתי המערכות.
- לנקות לפני שמחברים - כפילויות, רשומות ריקות, פורמטים שונים של טלפון.
- לחבר כיוון אחד בלבד בהתחלה, ולראות שבוע.
- להוסיף החזרה של מסמכים ומצב תשלום ל-CRM.
- להגדיר מה קורה בקונפליקט - מי גובר כששני הצדדים השתנו.
השלב השלישי הוא זה שמדלגים עליו וממנו מגיעות רוב הבעיות. ייבוא של רשימה מלוכלכת מייצר כפילויות במערכת השנייה, ואז יש שתי רשימות מלוכלכות במקום אחת.
מה מרוויחים מזה בפועל
- אין הקלדה כפולה של פרטי לקוח.
- איש מכירות רואה אם הלקוח שילם בלי לשאול את הנהלת החשבונות.
- הצעה שהפכה לעסקה הופכת למסמך בלי להתחיל מחדש.
- דוח לקוח אחד שכולל גם פעילות מכירתית וגם היסטוריית תשלומים.
הפריט השני הוא זה שמשנה את היום-יום: שיחת מכירה ללקוח שלא שילם היא שיחה לא נעימה, ורוב אנשי המכירות פשוט לא יודעים.
מה לא לצפות שיקרה
- לא כל שדה יעבור. חיבור מסחרי מעביר מה שהוגדר, ולא הכול.
- לא בזמן אמת. רוב החיבורים עובדים במחזוריות, וזה בסדר.
- לא יפתור בלגן קיים. חיבור מעתיק את המצב, כולל הכפילויות.
- לא יחליף החלטה. אם אף אחד לא יודע מי המאסטר, החיבור רק יפיץ את הבלבול מהר יותר.
מה לבדוק בשבוע הראשון אחרי החיבור
חיבור חדש נראה תקין ביום הראשון ומתגלה כשבור בשבוע השני. חמש בדיקות שכדאי לעשות:
- ליצור לקוח חדש במערכת המאסטר ולראות שהוא מופיע בשנייה, עם כל השדות.
- לשנות פרטי לקוח קיים ולוודא שהשינוי עבר - ולא יצר רשומה שנייה.
- להפיק מסמך ולראות שהוא מופיע בכרטיס הלקוח ב-CRM.
- לסמן חשבונית כשולמה ולוודא שמצב התשלום התעדכן.
- לחפש את אותו לקוח בשתי המערכות ולוודא שיש רק אחד.
הבדיקה החמישית היא החשובה מכולן, וכדאי לחזור עליה גם אחרי חודש - כי כפילויות נוצרות בהדרגה ולא בבת אחת.
איך בונים את זה בלי מפתח
ברוב העסקים הקטנים אין צורך בפיתוח: מערכות ישראליות רבות מציעות חיבורים מוכנים או עבודה דרך פלטפורמות אוטומציה מוכרות, ו-iCount למשל מציגה אפליקציה בפלטפורמת אוטומציה לצד ה-API שלה. מה שכן צריך לעשות בעצמכם הוא ההחלטות: מי המאסטר, מה המפתח, ומה עובר לאיזה כיוון. אלה לא שאלות טכניות ואף מפתח לא יענה עליהן במקומכם - וזו בדיוק הסיבה שחיבורים נכשלים אצל עסקים שיש להם מפתח מצוין.
מתי עדיף לא לחבר
יש מצבים שבהם חיבור מוסיף מורכבות ולא ערך: כשמספר הלקוחות קטן ואין הקלדה כפולה משמעותית; כשאותו אדם מפעיל את שתי המערכות ורואה הכול ממילא; וכשאחת המערכות עומדת להתחלף בחצי השנה הקרובה. בשלושת המצבים האלה, עדיף להמתין - חיבור שנבנה ונזרק הוא עבודה כפולה. לטווחי מחירים מפורטים ראו כמה עולה בניית מערכת CRM.
מה מודדים אחרי שהחיבור עובד
שני מספרים אומרים אם החיבור מחזיר את עצמו: כמה זמן חוסכים בחודש על הקלדה כפולה, וכמה פניות שירות נמנעו בזכות זה שאיש מכירות ראה מצב תשלום לפני שהתקשר. הראשון קל למדוד - כמה לקוחות חדשים בחודש כפול הזמן להקליד אחד. השני נמדד בתחושה, אבל הוא בדרך כלל הגדול מהשניים. בעסק עם צוות מכירות, שווה לשאול אותם אחרי חודש אם משהו השתנה - התשובה שלהם היא המדד האמיתי. פרטים נוספים בעמוד בניית מערכת CRM בהתאמה אישית.
מה קורה כשמחליפים אחת מהמערכות
חיבור שנבנה בין שתי מערכות הופך לנטל ברגע שאחת מהן מוחלפת, ולכן שווה לדעת מראש מה יקרה: האם המפתח שבחרתם קיים גם במערכת החדשה; האם החיבור עצמו ניתן להעברה או שצריך לבנות מחדש; ומה קורה לנתונים שנוצרו בזמן שהחיבור פעל. שלוש השאלות האלה שוות שיחה קצרה לפני שמחליפים, כי הן קובעות אם המעבר הוא שבוע או חודש.
מקורות
שאלות נפוצות
איזו מערכת צריכה להיות המאסטר?
לרוב זו שבה הלקוח נוצר ראשון - כלומר ה-CRM, אם המכירות מתחילות שם. בעסק שבו רוב הלקוחות מגיעים מחנות אונליין, ייתכן שהמאסטר הוא דווקא מערכת החשבוניות. מה שחשוב הוא שתהיה החלטה אחת, כתובה, ושכולם ידעו אותה.
אפשר סנכרון דו-כיווני?
טכנית כן, ומעשית זה מקור לבעיות: כששני הצדדים יכולים לשנות את אותו שדה, צריך כלל הכרעה לכל התנגשות. לרוב עדיף כיוון אחד לפרטי הלקוח, וכיוון הפוך למידע שנוצר במערכת השנייה - למשל מסמכים ומצב תשלום.
מה עושים עם הכפילויות שכבר קיימות?
מנקים לפני החיבור, לא אחריו. מיזוג ידני של מאה רשומות הוא יום עבודה; מיזוג של אלף אחרי שהחיבור הכפיל אותן הוא פרויקט. אם הרשימה גדולה, שווה למיין לפי טלפון ולטפל בקבוצות.
צריך מפתח כדי לחבר?
לא בהכרח. חלק מהמערכות הישראליות מציעות חיבורים מוכנים או עבודה דרך פלטפורמות אוטומציה מוכרות, וזה מספיק לרוב העסקים. מפתח נדרש כשהלוגיקה מיוחדת - למשל כללי סנכרון מורכבים או מערכת פנימית.
האם חשבונית ירוקה (מורנינג) שולחת webhooks ל-CRM?
כן. את ה-webhooks מגדירים בממשק של מורנינג תחת כלי מפתחים, והאירועים כוללים document/created, payment/received ו-client/created. אפשר לחתום כל משלוח ב-HMAC-SHA256 בכותרת x-webhook-signature. צריך לענות מהר בסטטוס 2xx, כי אחרי 15 משלוחים שנכשלו מורנינג הופכת את ה-webhook ללא פעיל.
האם CRM צריך webhooks או משיכה כדי לעקוב אחרי תשלומי חשבוניות?
שניהם, לתפקידים שונים. webhook מעדכן את ה-CRM תוך שניות אבל עלול להיכשל בשקט - מורנינג מכבה webhook אחרי 15 משלוחים שנכשלו. מעבר משיכה לילי דרך חיפוש המסמכים של כל מערכת משווה את מסמכי היום ל-CRM ומשלים פערים. ל-API המסמכים של רווחית פונים במשיכה בכל מקרה.
איך CRM נמנע ממסמכים כפולים במורנינג, ב-iCount או ברווחית?
כל בקשת הפקה נשענת על המזהה של העסקה או ההזמנה ב-CRM. iCount דוחה מסמך שני עם אותו sanity_string, ורווחית עושה אותו דבר כששולחים request_reference עם prevent_duplicates שערכו true. במורנינג שומרים רשומת משימה לכל הזמנה במסד הנתונים שלכם ובודקים אותה לפני הקריאה ל-POST /documents.
להמשך קריאה
שירות רלוונטי
בניית מערכת CRM בהתאמה אישית
CRM שנבנה סביב הפייפליין שלכם, מחובר לכלים שאתם כבר עובדים איתם.
יש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.