האם למורנינג (חשבונית ירוקה) יש API?

כן. מורנינג מספקת REST API מודרני עם אימות מבוסס טוקנים שמכסה יצירת מסמכים, לקוחות וסטטוס מסמכים. זו אחת המערכות הפיננסיות הישראליות הפשוטות יותר לאינטגרציה, בעיקר כי היא תוכננה כמוצר ענן מלכתחילה. עבדו תמיד מול התיעוד הרשמי העדכני לנקודות קצה ושמות שדות מדויקים, כי אלה משתנים עם הזמן.

איזה סוג מסמך האוטומציה צריכה להפיק?

זו החלטה חשבונאית ולא טכנית, וצריך לקבל אותה עם רואה החשבון לפני שנכתב קוד. החשבוניות בישראל מבחינות בין הצעות מחיר, הזמנות, תעודות משלוח, חשבוניות מס, קבלות וחשבונית-קבלה, ולכל אחת משמעות משפטית, מספור ונוהל ביטול שונים. מפו כל טריגר עסקי לסוג מסמך במפורש וקודדו את המיפוי כקבוע עם שם ולא כערך קבור בבקשה.

מה קורה אם אותה חשבונית מופקת פעמיים?

יש לכם בעיה חשבונאית אמיתית, לא משימת ניקוי נתונים - מסמך מס כפול צריך להתבטל בתהליך זיכוי תקין, ואם הוא הגיע ללקוח יש גם בעיית שירות. לכן כל מסלול הפקה חייב להיות אידמפוטנטי: מפתחו את הפעולה על מזהה ההזמנה שלכם, בדקו אם כבר הופק מסמך לפני קריאה ל-API, ושמרו את מזהה המסמך שחזר. עם הבדיקה הזו, webhook שנשלח שוב הופך ללא-פעולה במקום לחשבונית שנייה.

כמה זמן לוקח לבנות את האינטגרציה הזו?

זרם יחיד - הפקת מסמך כשהזמנה משולמת, עם תור משימות תקין וטיפול בשגיאות - הוא בדרך כלל שבוע עד שבועיים. הוספת חשבוניות חוזרות וסנכרון לקוחות מביאה לשלושה-ארבעה שבועות. משיכת סטטוס תשלום בחזרה ל-CRM או דשבורד מוסיפה עוד כשבועיים. זו אחת האינטגרציות השימושיות הזולות שיש, ולכן היא פרויקט ראשון טוב.

צריך שאדם עדיין יאשר חשבוניות אחרי האוטומציה?

בשבועות הראשונים, כן. שהאוטומציה תיצור מסמכים בטיוטה ותדרוש אישור לפני הפקה. כך מוצאים את בעיות הנתונים שמופיעות רק בנפח - רשומות לקוח עם מספרי עוסק לא תקינים, דמי משלוח שצריך למזג לשורה, עיגול שלא תואם למה שרואה החשבון מצפה. ברגע ששלב האישור מפסיק לתפוס משהו לאורך זמן, הסירו אותו.

אוטומציה של חשבוניות עם ה-API של מורנינג (חשבונית ירוקה)

מורנינג היא מערכת החשבוניות הישראלית הקלה ביותר לאוטומציה, ולכן האינטגרציה הראשונה הטובה ביותר לרוב העסקים הקטנים. הארכיטקטורה שעובדת, מלכודת סוגי המסמכים שתופסת את כולם, ולמה אידמפוטנטיות חשובה כאן יותר מבכל מקום אחר.

מכל המערכות הפיננסיות הישראליות שעסק קטן עשוי לרצות לעשות להן אוטומציה, מורנינג (לשעבר חשבונית ירוקה) היא הידידותית ביותר. היא ענן-נייטיב, יש לה REST API מודרני עם אימות מבוסס טוקנים, והיא נבנתה בתקופה שבה אינטגרציה הייתה ציפייה ולא תוספת. השילוב הזה הופך אותה לפרויקט האוטומציה הראשון הטבעי להרבה עסקים.

המדריך הזה מכסה מה כדאי לאטמט, איזו ארכיטקטורה שורדת מגע עם פרודקשן, ואילו טעויות ספציפיות הופכות פרויקט של שבועיים לניקוי חשבונאי.

מה שווה לאטמט

בסדר ערך גס:

הפקת מסמך כשהזמנה משולמת. קופה בחנות, קישור תשלום או אישור פגישה מפעילים את המסמך. זה מסיר את הכי הרבה עבודה ידנית יומית.
חשבוניות חודשיות חוזרות. ריטיינרים ומנויים שמופקים לפי לוח זמנים מרשימה, במקום ידנית באחד לחודש.
מהצעת מחיר לחשבונית. כשהצעה מתקבלת, המירו אותה במקום להקליד מחדש את השורות.
התאמת תשלומים. משכו סטטוס מסמך ותשלום בחזרה למערכת שלכם כדי לדעת מה פתוח בלי להתחבר.
סנכרון לקוחות. שמרו על רשימת הלקוחות מיושרת מול ה-CRM כדי שאף אחד לא ייווצר פעמיים עם פרטים מעט שונים.

לרוב העסקים מספיק הראשון כדי להצדיק את כל הפרויקט.

מלכודת סוג המסמך

כאן כמעט כל אינטגרציה ראשונה נכשלת. החשבוניות בישראל מבחינות בין כמה סוגי מסמכים - הצעות מחיר, הזמנות, תעודות משלוח, חשבוניות מס, קבלות, וחשבונית-קבלה משולבת - והם לא ניתנים להחלפה. יש להם משמעויות משפטיות וחשבונאיות שונות, רצפי מספור שונים, ונהלי ביטול שונים.

לפני כתיבת קוד, שבו עם מי שמנהל לכם את הספרים וכתבו במפורש: לכל אירוע עסקי שיפעיל אוטומציה, איזה סוג מסמך צריך להיווצר. שימו את המיפוי הזה בקוד כקבוע עם שם, לא כמספר קסם קבור בגוף הבקשה.

טעות כאן היא לא באג שמטליאים. מסמך מס שהופק בטעות צריך להתבטל בתהליך זיכוי תקין, ואם הוא כבר נשלח ללקוח, יש גם שיחה לא נעימה.

ארכיטקטורה שעובדת

לעולם לא לקרוא ל-API ישירות מתוך מטפל ה-webhook

הדפוס שנכשל: webhook תשלום מגיע, המטפל קורא מיד ל-API החשבוניות, המטפל חוזר. כשה-API איטי או לא זמין לרגע, ה-webhook נכשל בפסק זמן, ספק הסליקה מנסה שוב, ואתם מפיקים שתי חשבוניות.

הדפוס שעובד: webhook מגיע, אתם כותבים משימת "הפק מסמך" למסד הנתונים שלכם עם מזהה ההזמנה, ומאשרים מיד. worker נפרד מרים את המשימה, קורא ל-API, רושם את מזהה המסמך שהתקבל, ומסמן את המשימה כהושלמה. ניסיונות חוזרים בטוחים כי המשימה ממופתחת על מזהה ההזמנה.

אידמפוטנטיות, ברצינות

לפני הפקה, בדקו במסד הנתונים שלכם אם כבר הופק מסמך כנגד מזהה ההזמנה הזה. אם קיים, החזירו אותו. הבדיקה הבודדת הזו היא מה שעומד בין תקלת רשת למסמך מס כפול.

שמרו את מזהה ומספר המסמך שהוחזרו מול ההזמנה. הרשומה הזו היא גם מה שתהליך התמיכה שלכם צריך כשלקוח מבקש את החשבונית שוב.

טיפול בטוקנים

ה-API של מורנינג משתמש בטוקנים קצרי-חיים שמתקבלים מאישורי גישה ארוכי-חיים. אל תמשכו טוקן חדש בכל בקשה ואל תשמרו אחד לנצח. שמרו במטמון עם תוקף, רעננו יזומה לפני שהוא פג, וטפלו ב-401 על ידי רענון אחד וניסיון חוזר. אישורי הגישה שייכים למאגר סודות, אף פעם לא לריפוזיטורי.

תור שגיאות עם טיוטת המסמך מצורפת

כשלים כאן הם בדרך כלל בעיות נתונים: לקוח עם מספר עוסק לא תקין, שורה בלי מחיר, סכום שלא מתאזן. המשימה שנכשלה צריכה להיות גלויה עם ה-payload המדויק וטקסט השגיאה מה-API, כדי שאפשר יהיה לתקן ולנסות שוב במקום ליצור מחדש ידנית.

הריצו קודם במצב טיוטה

בשבועיים עד ארבעה שבועות הראשונים, שהאוטומציה תיצור מסמכים בטיוטה ותדרוש אישור אנושי להפקה. זו לא פחדנות - זו הדרך לגלות ש-3% מרשומות הלקוחות שלכם מכילות מספר עוסק עם רווח בסוף, או שהחנות שולחת את עלות המשלוח כשורה נפרדת שרואה החשבון רוצה ממוזגת.

ברגע ששלב האישור מפסיק לתפוס משהו, הסירו אותו.

לוח זמנים ועלות

היקף	בנייה טיפוסית
הפקת מסמך בתשלום הזמנה, טריגר אחד, תור שגיאות	1-2 שבועות
בתוספת חשבוניות חוזרות וסנכרון לקוחות	3-4 שבועות
בתוספת התאמת תשלומים בחזרה ל-CRM או דשבורד	5-7 שבועות

זו אחת האינטגרציות הזולות שיש, ובדיוק לכן זה מקום טוב להתחיל בו: היא מוכיחה את התבנית, מייצרת ערך יומי גלוי, והצוות לומד בשביל מה תור שגיאות לפני שהסיכון עולה.

הסתייגות אחת

חשבוניות יושבות בשטח מס ורגולציה, והכללים שחלים על העסק שלכם הם שאלה לרואה החשבון, לא למפתח. קבעו את מיפוי המסמכים ואת מדיניות ההפקה יחד איתו, השאירו אדם בלולאת האישור עד שיש ביטחון, ובדקו את תיעוד ה-API העדכני במקום להסתמך על מדריך כלשהו - כולל זה - לפרטי שדות ונקודות קצה מדויקים.

לאפיון אוטומציית חשבוניות למערך שלכם, קבעו שיחה ללא עלות. קשור: איך לעשות אוטומציה לחשבוניות, הסטאק הישראלי ומה מתחבר למה, ואוטומציה של חשבוניות ותזכורות תשלום.