חשבונית מס־קבלה דרך מורנינג: איך כל תשלום במסעדה הופך למסמך חתום

איזה מסמך נולד מאיזה רגע

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

נקודה אחת שמבלבלת רבים: המסמך לא נולד בקופה. הקופה יודעת מה נמכר ובכמה; את המסמך החתום מפיק ספק הפקת המסמכים — אצלנו מורנינג (חשבונית ירוקה) — בשם העסק שלכם, עם המספור הרץ שלכם. הקופה שולחת, הספק חותם, והמספר והקישור נשמרים אצלנו צמודים לתשלום שהוליד אותם.

החיבור: פעם אחת, בלי למסור סיסמאות

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

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

הבעיה הקשה באמת: שתשלום אחד לא יהפוך לשני מסמכים

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

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

ומה כשמורנינג לא עונה

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

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

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

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

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

• טיפ מופיע כשורה נפרדת, לא מובלע במחיר המנות: תשלום לצוות איננו עוד שיפוד בחשבון, והמסמך צריך לומר את זה במפורש. (איך הטיפ מטופל במיסוי אצלכם — שאלה לרואה החשבון; המסמך רק מפריד אותה נכון.)
• עיגול מזומן נרשם כשורה, לא נבלע. ישראל משכה מהמחזור את מטבעות ה־1 וה־5 אגורות, ולכן חשבון של ₪47.23 פשוט לא ניתן לתשלום במזומן. המערכת מעגלת לעשר האגורות הקרובות ורושמת את ההפרש בעמודה משלו — ביניים + טיפ + עיגול = סה״כ הוא שוויון שנשמר תמיד, כך שסוף היום מסתכם בלי ״שאריות״ שאף אחד לא יודע להסביר.

מה לשאול כל מערכת על מסמכים

1. מי מפיק את המסמך — ובשם מי רץ המספור?
2. מה קורה כשספק המסמכים לא זמין באמצע שירות — נעצר תשלום, או נערם תור שמשלים את עצמו?
3. איך מובטח שתשלום אחד לא יוליד שני מסמכים אחרי תקלת רשת?
4. מי מגלה מסמך שנכשל — אתם, בסוף החודש, או הספק שלכם, באותה שעה?
5. איך נראית חשבונית זיכוי — עריכה של המכירה, או מסמך חדש שמצביע עליה? (רק השני חוקי באמת.)

על השאלה השלישית והרביעית עניתם עכשיו בשבילנו. עוד על צד הכסף — במדריך כמה עולה מערכת קופה למסעדה.