אינטגרציות
סנכרון אוטומטי בין CRM לחשבונית ירוקה: בלי להקליד פעמיים
כשמחברים CRM למערכת החשבוניות, ארבעה דברים עוברים בין המערכות: לקוח, הצעת מחיר, חשבונית ותשלום. מה שלא עובר, וגם לא אמור, הוא שיקול דעת: מתי לתת הנחה, למי לפתוח אשראי ומה לעשות עם לקוח שלא משלם. העמוד הזה מפרט מה עובר לאיזה כיוון, שלוש נקודות הכשל שמפילות חיבורים כאלה, ומתי עדיף לא לחבר בכלל.
מה בדיוק עובר בין המערכות, ולאיזה כיוון?
חיבור עובד אינו סנכרון של הכול לכל הכיוונים. הוא ארבעה מסלולים מוגדרים, ולכל אחד יש כיוון אחד בלבד. כיוון אחד לכל שדה הוא מה שמונע התנגשות שאי אפשר להכריע אוטומטית.
- לקוח. נפתח פעם אחת, במערכת שהוגדרה כבעלים של פרטי הלקוח, ומשוכפל לשנייה באותו שם ובאותו מספר מזהה. השם באותיות עברית, מספר העוסק וכתובת החיוב הם השדות שחייבים להיות זהים, כי הם אלה שיופיעו על המסמך.
- הצעת מחיר. נבנית ב-CRM, שם היא חלק מתהליך המכירה. כשהיא מאושרת, היא הופכת למסמך במערכת החשבוניות בלי שמישהו יקליד את השורות מחדש.
- חשבונית. מופקת רק במערכת החשבוניות, לעולם לא בשני מקומות. מספר המסמך והקישור אליו חוזרים אל כרטיס הלקוח ב-CRM, כדי שאיש המכירות יראה אותם בלי להיכנס למערכת אחרת.
- תשלום. נקלט במערכת החשבוניות ומעדכן את הסטטוס ב-CRM. זה השדה שבגללו רוב החיבורים האלה נבנים: הוא מה שמפסיק את השאלה "הוא כבר שילם?" שנשאלת בעל פה כמה פעמים ביום.
שלוש נקודות הכשל שמפילות את החיבור
חיבורים כאלה כמעט אף פעם לא נופלים על התשתית. הם נופלים על שלושה מקומות שנראים שוליים בהקמה ויקרים אחר כך, וכל השלושה נבדקים לפני שבונים ולא אחרי.
- לקוח כפול. אותו לקוח קיים כבר בשתי המערכות בשתי כתיבות שונות: עם ובלי ח"פ, עם בע"מ ובלעדיו, בעברית ובאנגלית. חיבור שמזהה לפי שם יפתח לו כרטיס שלישי. הזיהוי חייב להיות לפי מספר עוסק או ח"פ, ומה שלא נמצא בוודאות עולה לרשימה שאדם מכריע פעם אחת, לפני ההפעלה.
- מספור מסמכים. סדרות מספור הן דרישה חשבונאית, לא העדפה. חיבור שמפיק מסמך מחוץ לסדרה, או שיוצר רווח בין מספרים, יוצר בעיה שמתגלה בביקורת ולא ביום שהיא נוצרה. מי שמפיק את המסמך הוא תמיד מערכת החשבוניות, וההגדרה נעשית מול מנהל החשבונות.
- זיכויים והחזרות. זה החלק שהכי הרבה חיבורים פשוט מדלגים עליו. זיכוי אינו חשבונית שלילית: הוא מסמך נפרד שחייב להצביע על המסמך המקורי, והוא משנה גם את היתרה וגם את הדוח. חיבור שלא טיפל בזיכויים ייראה תקין עד הזיכוי הראשון, ואז יפריד בין המערכות בשקט.
כמה זמן ההקמה לוקחת, ומה נדרש מכם?
משך ההקמה נגזר כמעט כולו ממצב הנתונים ולא מכמות המסמכים. חיבור על שתי מערכות נקיות ומוסכמות הוא עבודה קצרה. אותו חיבור על מאגר לקוחות שנצבר שבע שנים בלי כללי כתיבה הוא בעיקר ניקוי, והחיבור עצמו הוא החלק הקטן.
מה שנדרש מכם: הרשאות קריאה וכתיבה לשתי המערכות בהיקף שהתהליך צריך ולא רחב מזה, החלטה מי הבעלים של פרטי הלקוח, ואישור של מנהל החשבונות על סדרת המספור. שלב המדידה מסתיים בתשובה מספרית על התהליך שלכם: כמה מסמכים בחודש, כמה מהם נוגעים ידיים היום, וכמה מזה נשאר גם אחרי החיבור.
אילו חיבורים דומים אנחנו עושים?
אותו עיקרון חוזר בכל צמד מערכות, ומה שמשתנה הוא מה שכל צד מאפשר. הסביבה הישראלית הטיפוסית מורכבת ממערכת פיננסית כמו חשבשבת, ממערכת ליבה כמו פריוריטי, מהפקת חשבוניות בחשבונית ירוקה, מניהול עבודה במאנדיי, ומקבצים ב-Microsoft 365.
בדיקת החיבור מול המערכת עצמה, בגרסה ובהרשאות שיש לכם ולא לפי מה שכתוב שהיא מאפשרת, היא חלק משלב המדידה. הבטחת אינטגרציה בשיחת מכירה, בלי לפתוח את המערכת, היא הדרך המהירה ביותר לפרויקט שנתקע באמצע. הרחבה על העבודה מול מערכות קיימות נמצאת בעמוד שירותי אוטומציה לעסקים, ועל הצד הפיננסי בעמוד אוטומציה פיננסית.
מתי אנחנו אומרים לא
חיבור בין מערכות אינו תמיד התשובה, ויש מקרים שבהם הוא רק מקבע בעיה קיימת. אלה המקרים שבהם נגיד לכם לא, גם כשאתם מבקשים כן:
- כשאף אחד לא הכריע מי הבעלים של פרטי הלקוח. זו אינה בעיה טכנית אלא חוסר הסכמה על מי מחזיק את המספר הנכון. חיבור רק יהפוך את חוסר ההסכמה למהיר יותר.
- כשהמאגר לא נקי. אם אותו לקוח קיים בשלוש כתיבות, החיבור ישכפל את הבלגן לשתי מערכות במקום אחת. קודם מנקים, אחר כך מחברים.
- כשהנפח קטן. עסק שמפיק מספר מסמכים בודד בחודש לא יחזיר את עלות ההקמה והתחזוקה. הקלדה של דקה, כמה פעמים בחודש, אינה בעיה שצריך לפתור בתוכנה.
- כשאתם באמצע החלפת אחת המערכות. בניית חיבור למערכת שיוצאת היא בזבוז. מחכים.
חלק מהמדידות מסתיימות במסקנה שהחיסכון אינו מצדיק את ההשקעה, וזו תשובה לגיטימית. ספק שמסכים לכל בקשה כבר החליט מה הוא מוכר לכם, לפני שראה מה יש לכם.
אנחנו כבר מייצאים קובץ פעם בחודש. למה צריך חיבור?
ייצוא חודשי עובד כשהמידע נכון ברגע הייצוא ואף אחד לא צריך אותו לפני כן. הוא נשבר בשני מקומות: בחודש שבו מישהו שכח לייצא, ובכל יום שבו איש מכירות רוצה לדעת אם הלקוח שילם ואין לו איפה לראות. אם שני אלה לא קורים אצלכם, הייצוא הידני הוא פתרון סביר ואין סיבה להחליף אותו.
מי מנצח כששני הצדדים מחזיקים גרסה שונה של אותו לקוח?
זו ההחלטה הראשונה שצריך לקבל, והיא עסקית ולא טכנית. בוחרים מערכת אחת שהיא הבעלים של פרטי הלקוח, ובדרך כלל זו מערכת החשבוניות, כי היא זו שמחויבת כלפי רשות המסים. הצד השני מקבל עדכון ולא כותב חזרה. חיבור שמאפשר לשני הצדדים לכתוב אותו שדה מייצר התנגשויות שאי אפשר להכריע אוטומטית, ולכן לא בונים אותו כך.
מה קורה לחשבוניות שהופקו לפני החיבור?
ברירת המחדל היא לא לגעת בהן. היסטוריה שמיובאת אחורה יוצרת כפילויות מול מסמכים שכבר קיימים, ושעת עבודה שנחסכת בייבוא עולה ימים בניקוי. אם יש סיבה עסקית לייבא, למשל דוח יתרות פתוחות, מייבאים חלון מוגדר וקצר ומשווים אותו ידנית פעם אחת לפני שממשיכים.
החיבור נפל באמצע. מה קורה למסמך שהיה בדרך?
תהליך תקין לא מנסה שוב בעיוורון, כי ניסיון חוזר על הפקת מסמך הוא בדיוק איך שנוצרת חשבונית כפולה. כל בקשה נושאת מזהה משלה, והתהליך בודק קודם אם המסמך כבר קיים באותו מזהה. מה שלא הצליח נעצר, נרשם, ומגיע לאדם עם הסיבה לצידו. מסמך חשבונאי הוא לא הודעה, ואי אפשר לשלוח אותו פעמיים ולקוות.
צריך את מנהל החשבונות בשביל זה?
כן, בשני מקומות. בהחלטה מי הבעלים של פרטי הלקוח, ובהחלטה איך נראית סדרת מספור נכונה אצלכם. אלה החלטות שמי שאחראי על הספרים צריך לאשר, כי הן משפיעות על מה שיוצג בביקורת. ההפעלה השוטפת אחר כך לא דורשת אותו.
זה עובד גם מול פריוריטי או חשבשבת?
אותו עיקרון ולא אותה עבודה. מה שעובר בין המערכות זהה, אבל מה שכל מערכת מאפשרת שונה, וזה נבדק מול המערכת שלכם בגרסה ובהרשאות שיש לכם לפני שנאמר משהו. יש מערכות עם ממשק מסודר שעובדים מולו ישירות, יש כאלה שמאפשרות רק ייצוא וייבוא של קבצים או דוחות מתוזמנים, ויש פעולות שהיצרן לא פתח לגישה חיצונית.
התוכן בעמוד זה הוא מידע כללי על דרך העבודה, ואינו הצעה, התחייבות או הבטחה לתוצאה. ההסדרים המחייבים (לרבות היקף השירות והטיפול במידע) נקבעים בהסכם בכתב. ראו תנאי שימוש.