אספקה חלקית היא המקום שבו הכנסה נעלמת בשקט. מזהה עסקה אחד, מכונת מצבים לשורה, טבלת שדות עם ערכים אמיתיים ושלושה דוחות יתומים שמחזירים את הכסף.
עיקרי הדברים
- מנגנון אובדן ההכנסה הוא אספקה חלקית: הזמנה עם ארבע שורות מסופקת בשתי משלוחים, החשבונית נכתבת מול המשלוח הראשון, והשורה שאיחרה יוצאת מהתודעה.
- המזהים אינם צריכים להיות אותו מספר. הם צריכים להצביע זה על זה בשדה שאפשר לחפש - `deal_id` על כל מסמך.
- הקישור חייב להיות ברמת השורה ולא ברמת המסמך. שורת חשבונית ללא `order_line_id` מקורי אינה ניתנת לביקורת.
- מכונת מצבים עם מעברים מוגדרים מבדילה בין "בוטל", "לא סופק" ו"סופק וטרם חויב" - שלושה מצבים שנראים זהים בגיליון.
- הבקרה היא שלושה דוחות יתומים שרצים כל בוקר, לא חיפוש בתיקיות בסוף החודש.
מזהה עסקה אחד הוא שדה שנוצר עם הצעת המחיר ונשמר בהזמנה, בתעודת המשלוח ובחשבונית. בלעדיו אי אפשר לענות על שאלה אחת שעולה כסף: אילו שורות שאושרו ונשלחו מעולם לא חויבו. אובדן ההכנסה אינו בהצעה שנדחתה, אלא בשורה שסופקה ונשכחה.
איך שורה שסופקה מעולם לא הופכת לחשבונית
הנה המקרה במספרים. הצעת מחיר Q-2026-00418 ללקוח עסקי, סכום כולל 38,400 ש"ח לפני מע"מ, שלוש שורות:
| שורה | תיאור | כמות | מחיר יחידה | סכום |
|---|---|---|---|---|
| 1 | התקנה ראשונית | 1 | 18,000 | 18,000 |
| 2 | רישוי שנתי, 12 משתמשים | 12 | 1,200 | 14,400 |
| 3 | הדרכה, 4 מפגשים | 4 | 1,500 | 6,000 |
ההצעה אושרה במייל ב-3 במרץ. ההתקנה בוצעה ב-19 במרץ, הרישוי הופעל ב-1 באפריל, ההדרכה נדחתה לבקשת הלקוח ליוני. חשבונית INV-2026-1123 הופקה ב-31 במרץ על 18,000 ש"ח. ביוני התקיימו שני מפגשים מתוך ארבעה, איש הקשר אצל הלקוח התחלף, והשורה השלישית לא חויבה מעולם. 6,000 ש"ח נעלמו בלי שאף אחד קיבל התראה, כי אף מערכת לא החזיקה את המשפט "שורה 3 בהצעה 00418 אושרה, בוצעה חלקית, וטרם חויבה".
זה המנגנון. הוא לא נובע מחוסר סדר אלא מכך שהחשבונית נבנתה מול אירוע האספקה ולא מול השורה המקורית. עם deal_id ברמת השורה, אותו מקרה מופיע בדוח היתומים למחרת המפגש השני.
למה קישור ברמת המסמך לא מספיק?
קישור ברמת המסמך אינו מספיק מפני שאספקה וחיוב כמעט אף פעם אינם ביחס של אחד לאחד. הצעה אחת מולידה הזמנה אחת, אבל ההזמנה מולידה שתי תעודות משלוח ושלוש חשבוניות, ולפעמים חשבונית אחת מכסה שתי הזמנות.
- הצעה אחת → הזמנה אחת: יחס פשוט, וגם הוא נשבר כשלקוח מאשר חלק מההצעה.
- הזמנה אחת → כמה תעודות משלוח: הנורמה בכל עסק עם מלאי או עם שירות בשלבים.
- כמה הזמנות → חשבונית אחת: נפוץ בחיוב חודשי מרוכז ללקוח קבוע.
- חשבונית אחת → כמה תקבולים: תשלום חלקי, תשלומים, זיכוי חלקי.
ברגע שאחד מהיחסים האלה אינו אחד לאחד, השדה order_id על החשבונית מפסיק לענות על השאלה. מה שנדרש הוא deal_id על המסמך ו-source_line_id על כל שורה.
מכונת המצבים של שורת עסקה
השורה, לא המסמך, היא היחידה שנעה בין מצבים. שישה מצבים ומעברים מוגדרים בלבד:
draft- נכתבה בהצעה, טרם נשלחה. מעבר ל-sent.sent- ההצעה יצאה ללקוח. מעבר ל-approvedאו ל-lost.approved- הלקוח אישר את השורה. מעבר ל-delivered_partial, ל-deliveredאו ל-cancelled.delivered_partial- סופקה כמות קטנה מהמוזמנת. מעבר ל-deliveredאו ל-cancelled_remainder.delivered- סופקה במלואה. מעבר יחיד: ל-invoiced.invoiced- קיימת שורת חשבונית שמצביעה עליה. מצב סופי, למעט זיכוי.
שני כללים הופכים את זה למנגנון ולא לתרשים. הראשון: אין מעבר ישיר מ-approved ל-invoiced - חייב לעבור דרך אספקה, אחרת אי אפשר לדעת מה נשלח. השני: שינוי מחיר או כמות אחרי approved אינו דורס את השורה, אלא פותח גרסה חדשה עם הפניה לקודמת ומחייב אישור. במקרה 00418, שורה 3 הייתה נעצרת ב-delivered_partial עם כמות 2 מתוך 4, וזה בדיוק המצב שדוח היתומים מחפש.
שדות המינימום על כל מסמך
| שדה | דוגמה | מופיע ב |
|---|---|---|
deal_id | D-2026-0418 | הצעה, הזמנה, תעודה, חשבונית |
doc_type | quote / order / delivery / invoice | כל מסמך |
doc_number | INV-2026-1123 | כל מסמך |
source_line_id | Q-2026-00418-L3 | שורת הזמנה, שורת תעודה, שורת חשבונית |
line_state | delivered_partial | שורת עסקה |
qty_ordered / qty_delivered / qty_invoiced | 4 / 2 / 0 | שורת עסקה |
version | 2 | שורה ששונתה אחרי אישור |
changed_by / changed_at | dana / 2026-06-11T09:14+03:00 | כל שינוי אחרי אישור |
שלוש עמודות הכמות הן הלב. כל אי-שוויון ביניהן הוא שאלה עסקית פתוחה, וכל שוויון הוא סגירה. עסק שמחזיק רק qty_ordered לא יכול לייצר את הדוחות בסעיף הבא.
שלושת דוחות היתומים שמחזירים כסף
הבקרה היא שלוש שאילתות שרצות בכל בוקר ומייצרות משימות, לא דוח לקריאה:
- אושר בלי הזמנה - שורות ב-
approvedשאין להן שורת הזמנה מקושרת אחרי 3 ימי עסקים. בדרך כלל מצביע על אישור שהתקבל בטלפון ולא נרשם. - סופק בלי חשבונית - שורות ב-
deliveredאוdelivered_partialשבהןqty_invoicedקטן מ-qty_deliveredמעל למספר ימים שהוגדר. זה הדוח שהיה תופס את 6,000 ש"ח במקרה 00418. - חשבונית בלי מקור - שורות חשבונית ללא
source_line_id. לא בהכרח טעות, אבל כל שורה כזאת היא הכנסה שאי אפשר לשייך להצעה, ולכן גם אי אפשר למדוד לפיה רווחיות.
לכל דוח יש בעלים ותאריך יעד, ולא רק נמען. דוח שנשלח לכולם אינו באחריות אף אחד. הקישור בין השורה הזאת לבין מסמך חתום מתואר בתיעוד חתימה על הצעת מחיר, והצד של יצירת ההצעה משיחה מתואר במהשיחה להצעת מחיר.
מה קורה כשהחשבונית מופקת במערכת אחרת?
כשהחשבונית מופקת במערכת חיצונית, המזהה חייב לנסוע איתה החוצה ולחזור. הדפוס המעשי הוא לשלוח את deal_id ואת source_line_id בשדה חופשי שהמערכת המקבלת מחזירה בתשובה, ולשמור את מספר המסמך שהתקבל בחזרה על השורה המקורית באותה פעולה.
שלוש נקודות שנשברות בפועל: מערכת שמגבילה את אורך השדה החופשי וקוטמת מזהה; חשבונית שנוצרת ידנית בממשק החיצוני ולכן חוזרת בלי מזהה כלל; וזיכוי שנוצר מול החשבונית ולא מול השורה. בישראל נוסף לזה מספר ההקצאה כשדה חובה לחלק מהחשבוניות מעל תקרה שנקבעה, והוא שדה נוסף שצריך לשמור על השורה - הפרטים הטכניים מפורטים במספר הקצאה לחשבונית מס למפתחים.
מקורות
שאלות נפוצות
האם צריך שכל המסמכים יישאו את אותו מספר?
לא, ולרוב זה גם לא אפשרי כי מערכת החשבוניות מייצרת מספור רץ משלה. מה שנדרש הוא שדה קישור שאפשר לחפש לפיו בכל מסמך, ושהוא נשמר גם כשהמסמך נוצר במערכת אחרת. מספור אחיד הוא נוחות, קישור הוא דרישה.
מה עושים עם הזמנות שמגיעות בוואטסאפ?
פותחים להן רשומה עם מזהה לפני שמטפלים בהן, גם אם הפרטים חלקיים. הודעה שנשארת רק בצ'אט אינה חלק מהתהליך ולכן לא תופיע בשום דוח יתומים. הכלל הפשוט: אם אין רשומה, ההזמנה לא קיימת מבחינת הבקרה.
כמה זמן שומרים שורה במצב "סופק וטרם חויב" לפני התראה?
זו החלטה עסקית ולא כלל אחיד, והיא צריכה להיות שונה לפי סוג שורה. אספקה פיזית מצדיקה סף קצר של ימים ספורים, בעוד שירות בשלבים עשוי להצדיק שבועות. העיקר הוא שהסף כתוב ומיושם על ידי שאילתה, ולא נתון לזיכרון של מי שמסתכל.
מה עושים עם שורות שכבר נעלמו בעבר?
מריצים את דוח היתומים אחורה על תקופה סגורה, ומקבלים רשימה סופית של שורות שסופקו ולא חויבו. הטיפול בכל אחת הוא החלטה מסחרית מול הלקוח, אבל הרשימה עצמה היא נתון טכני שאפשר להפיק ברגע שקיים קישור ברמת השורה.
להמשך קריאה
שירות רלוונטי
מערכות בהתאמה אישית
המערכת הפנימית שמחליפה את הגיליון שגדלתם ממנו.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.