מסליקה לחשבונית: לאוטומט את התפר בלי כפילויות

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

ההחלטה שסוגרת את הבעיה

יש שלוש דרכים להפיק מסמך אחרי תשלום, ורק שתיים מהן נכונות:

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

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

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

הטריגר: הודעת שרת, לא הדפדפן

אחרי שהחלטת מי מפיק, השאלה השנייה היא מה מפעיל את זה.

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

וזה חמור יותר מהזמנה שנשארה "ממתינה": חשבונית חסרה היא בעיה חשבונאית, לא רק חוויית משתמש.

ההפקה מופעלת מהודעת השרת-לשרת של הסולק. הדפדפן מציג מסך תודה, ותו לא.

המבנה שעובד

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

המבנה הנכון:

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

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

הגנה מפני כפילות

גם עם צד אחד שמפיק, אפשר לקבל שתי חשבוניות. שני מקורות:

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

שתי ההגנות:

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

מה שחייב לעבור מהתשלום למסמך

נקודה שקל לפספס: הסולק יודע כמה נגבה, אבל לא בהכרח מה נמכר.

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

ושני דברים שדורשים החלטה של רואה החשבון, לא של המפתח:

• איזה סוג מסמך. חשבונית מס, חשבונית מס קבלה, קבלה - הבחירה קובעת מתי מוכרת ההכנסה.
• עסקה בתשלומים. האם המסמך משקף את הסכום המלא או את התשלום? ראה Grow לפירוט.

ההתאמה היומית - מה שהופך את זה לאמין

אוטומציה בלי התאמה היא אופטימיזציה, לא מערכת שאפשר לסמוך עליה.

תהליך שרץ פעם ביום ומשווה: כל תשלום שהתקבל אתמול - האם יש לו מסמך? כל פער מתריע.

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

צ'קליסט

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

קשור: השוואת ה-API של מערכות החשבוניות · מספר הקצאה והמערכת שלך.