לקוח מדווח שלא קיבל חשבונית. איך בודקים את שרשרת המסירה חוליה אחר חוליה, מה מוכיחה תשובת השרת המקבל, ולמה הוצאת מסמך שני היא הפעולה האחרונה ברשימה.
עיקרי הדברים
- המסמך וההודעה הם שני אובייקטים. מסמך קיים שלא נשלח ומסמך שנשלח ולא הגיע דורשים פעולות הפוכות לחלוטין.
- לפי RFC 5321, שרת שהחזיר תשובת הצלחה בסיום נתוני ההודעה נטל על עצמו אחריות למסור אותה או לדווח על כישלון. הוא אינו רשאי להעלים אותה בשקט.
- הודעת דחייה בקוד שמתחיל ב-4 היא זמנית והשליחה עשויה להצליח מאוחר יותר; קוד שמתחיל ב-5 הוא קבוע ולא ישתנה בניסיון נוסף באותה צורה.
- הכשל הנפוץ ביותר אינו מייצר דחייה כלל: ההודעה מתקבלת, נכשלת באימות שולח, ומסוננת לתיקיית זבל בלי שאיש יידע.
- שליחה חוזרת של אותו קובץ אינה אותה פעולה כמו הפקת מסמך חדש, והמערכת חייבת להבחין ביניהן ברמת הקוד.
"לא קיבלתי חשבונית" הוא דיווח על ההודעה, לא על המסמך. שני אלה הם אובייקטים נפרדים עם מזהים נפרדים ומחזור חיים נפרד, והבדיקה הראשונה היא איזה מהם באמת חסר. הוצאת מסמך שני לפני שיודעים את זה יוצרת בעיה חשבונאית אמיתית במקום בעיית מסירה זמנית.
שני אובייקטים, לא אחד
מסמך שהופק במערכת החשבוניות שלכם קיים מרגע ההפקה, נושא מספר מסמך משלו, ובישראל עשוי לשאת גם מספר הקצאה שהתקבל מרשות המסים. ההודעה שנשאה אותו היא אובייקט אחר לגמרי: יש לה כותרת Message-ID משלה, מזהה נפרד אצל ספק הדואר היוצא, ותוצאת מסירה משלה. הפרדה בין השניים היא מה שמאפשר לענות על השאלה הנכונה.
| השאלה | איפה בודקים | מה נובע מהתשובה |
|---|---|---|
| האם המסמך הופק בכלל | מערכת החשבוניות | אם לא, אין מה לשלוח מחדש. יש להפיק |
| האם נוצרה הודעה יוצאת | לוג השליחה של המערכת שלכם | אם לא, התקלה אצלכם ולא אצל הלקוח |
| האם ההודעה נמסרה לשרת של הלקוח | לוג ספק הדואר, לפי Message-ID | אם כן, שליחה חוזרת לא תשנה כלום |
| האם ההודעה הגיעה לתיבה הנצפית | רק הלקוח יכול לענות | זו הנקודה שבה המדידה שלכם נגמרת |
| האם המסמך שולם | מערכת הגבייה | תשלום מוכיח קבלה טוב מכל לוג |
השורה האחרונה שווה יותר מכל השאר יחד. אם המסמך שולם, הוא התקבל, וכל הבירור מתייתר.
מה בעצם מוכיחה תשובת השרת המקבל?
היא מוכיחה העברת אחריות. RFC 5321 מנסח זאת מפורשות: ברגע שהשרת החזיר תשובת הצלחה בסיום נתוני ההודעה, מתרחשת העברה פורמלית של האחריות, והפרוטוקול מחייב את השרת לקבל על עצמו למסור את ההודעה או לדווח כראוי על הכישלון. מכאן שקבלה מוצלחת אינה "אולי הגיע" אלא נקודה מוגדרת בשרשרת.
מה שהיא אינה מוכיחה: שההודעה נחתה בתיבת הדואר הנכונה, שהיא נראתה, או שהקובץ המצורף שרד את שער האבטחה של הארגון המקבל. מעבר לנקודת הקבלה, המדידה שלכם מסתיימת.
כשההודעה כן נדחית, קודי המצב המורחבים של RFC 3463 מספרים בדיוק מה קרה:
| הקוד | המשמעות המתועדת | מה עושים |
|---|---|---|
X.1.1 | תיבת הדואר שצוינה בכתובת אינה קיימת | תקנו את הכתובת. שליחה חוזרת לאותה כתובת חסרת טעם |
X.1.2 | מערכת היעד אינה קיימת או אינה מסוגלת לקבל דואר | בדקו את הדומיין. לרוב שגיאת הקלדה |
X.2.2 | התיבה מלאה, בחריגה ממכסה או מקיבולת | מצב זמני. בקשו מהלקוח לפנות מקום |
X.7.1 | השולח אינו מורשה לשלוח ליעד, וההודעה סורבה | סינון לפי שולח או לפי נמען. כאן מטפלים באימות השולח |
מחלקת הקוד קובעת את הפעולה: לפי RFC 3463, קוד שמתחיל ב-4 מציין מצב זמני ושליחה עתידית עשויה להצליח, וקוד שמתחיל ב-5 מציין כישלון קבוע שלא צפוי להיפתר בשליחה חוזרת של ההודעה בצורתה הנוכחית.
הכשל השקט: התקבל, ואז סונן
זהו התרחיש שאוכל את רוב הזמן, מפני שהוא אינו מייצר שום אירוע שאפשר לחפש. ההודעה מתקבלת בהצלחה, נכשלת באימות שולח, והמדיניות שהדומיין שלכם מפרסם מנחה את השרת המקבל להעביר אותה להסגר. הלקוח לא ראה כלום, אתם לא קיבלתם דחייה, והלוג שלכם מראה מסירה תקינה.
- כתובת השולח בפועל שונה מהדומיין שעליו הגדרתם את הרשומות. מערכת חשבוניות ששולחת בשם הלקוח היא מקור נפוץ לפער הזה.
- הודעה שנשלחת מכתובת אישית ומכילה קובץ מצורף עם מספר מסמך נראית לשער סינון כמו הודעת התחזות קלאסית.
- תיבת החשבוניות של הלקוח היא לעיתים קרובות כתובת קבוצתית שמנותבת למערכת כרטיסים, ושם החשבונית נסגרת כפנייה שטופלה בלי שאיש פתח את הקובץ.
- קובץ מצורף גדול מדי או סוג קובץ חסום נחתכים בשער הארגוני, וההודעה מגיעה בלי הצרופה שהיא כל תכליתה.
הצד התשתיתי של זה, כולל מה בודקים ברשומות האימות ובאיזה סדר, מתואר בתפעול SPF, DKIM ו-DMARC נגד סינון דואר.
למה לא פשוט להפיק את החשבונית שוב?
מפני שהפקה חוזרת יוצרת מסמך שני עם מספר מסמך שני, ובישראל גם עם מספר הקצאה נוסף כשהמסמך מחייב זאת, עבור עסקה אחת. הלקוח מחזיק שני מסמכים, הנהלת החשבונות רואה שתי רשומות, וההתאמה מול התשלום שתגיע בהמשך נשברת. זהו תיאור טכני של ההשלכה התפעולית ואינו ייעוץ מסי או חשבונאי; מסלול התיקון של מסמך שכבר הופק נקבע מול רואה החשבון שלכם ולפי כללי רשות המסים.
ההבחנה שהמערכת חייבת לדעת לעשות היא בין שלוש פעולות שונות לגמרי:
- שליחה חוזרת של אותו קובץ לאותה כתובת. אין כאן מסמך חדש, רק ניסיון מסירה נוסף.
- שליחה חוזרת של אותו קובץ לכתובת אחרת. עדיין אותו מסמך, עם רישום של הכתובת החדשה.
- הפקת מסמך חדש. פעולה חשבונאית, לא פעולת מסירה.
מערכת שבה כפתור אחד עושה את שלושתם היא הסיבה שהבעיה הזו חוזרת. הקשר בין הצעת מחיר, הזמנה וחשבונית ואיך שומרים מזהה אחד לאורך כל השרשרת מפורט בזרימת הצעה, הזמנה וחשבונית עם מזהה יחיד, והדרישות סביב מספרי הקצאה מפורטות במספר הקצאה לחשבונית - מבט למפתחים.
מה לתעד כדי שהבירור הבא ייקח שתי דקות
- מספר המסמך, ולידו מספר ההקצאה אם המסמך נושא כזה.
- כתובת הנמען בדיוק כפי שנשלחה, כולל רווחים מיותרים שנשמרו בטעות.
- כותרת
Message-IDשל ההודעה, שהיא מפתח החיפוש היחיד שעובד גם בלוג של ספק הדואר וגם אצל הלקוח. - שורת התשובה המלאה של השרת המקבל, ולא רק "נשלח" או "נכשל".
- שם הקובץ המצורף וגודלו, כדי לזהות חיתוך בשער ארגוני.
- מספר השליחות של אותו מסמך והסיבה שנרשמה לכל אחת מהן.
- מי ביצע את השליחה החוזרת ומתי, כדי שאפשר יהיה לשחזר את סדר האירועים.
ארבעת הפריטים הראשונים הם ההבדל בין בירור של שתי דקות לבין ויכוח של שבוע. הם עולים שדות בודדים בטבלה, והם משמשים בכל פעם שלקוח טוען שלא קיבל משהו.
מקורות
שאלות נפוצות
הלוג שלנו מראה מסירה מוצלחת והלקוח מתעקש שלא קיבל. מי צודק?
שניכם. מסירה מוצלחת אומרת שהשרת המקבל נטל אחריות על ההודעה, ולא שהיא הגיעה לתיבה שהלקוח מסתכל עליה. סינון להסגר, ניתוב לתיבה קבוצתית או חסימת הצרופה מייצרים בדיוק את הפער הזה, וכולם קורים אחרי נקודת המדידה שלכם.
מה עדיף, לשלוח שוב את אותו קובץ או להנפיק מסמך חדש?
לשלוח שוב את אותו קובץ, כמעט תמיד. המסמך כבר קיים ותקף, והבעיה היא במסירה. הנפקת מסמך חדש מוסיפה רשומה חשבונאית שנייה לעסקה אחת, ואת התיקון שלה צריך לבצע מול רואה החשבון במקום לפתור בעיה טכנית.
איך יודעים שהקובץ המצורף לא נחתך בדרך?
שומרים את שם הקובץ ואת גודלו ברשומת השליחה, ומשווים מול מה שהלקוח מדווח שהוא רואה. אם ההודעה הגיעה בלי הצרופה, מדובר כמעט תמיד בשער אבטחה בצד המקבל. קישור מאובטח למסמך במקום צרופה עוקף את המחלקה הזו של תקלות.
כדאי להוסיף אישור קריאה כדי לדעת שהחשבונית נפתחה?
אישור קריאה תלוי בהסכמת הנמען ובהגדרות שלו, ולכן היעדרו אינו מוכיח דבר. מדד אמין הרבה יותר הוא סטטוס התשלום: מסמך ששולם התקבל בוודאות. מעקב אחר מצב התשלום מול המסמך מתואר ב[אוטומציית התאמת תשלומים לחשבוניות](/blog/payment-to-invoice-automation-israel).
להמשך קריאה
שירות רלוונטי
אוטומציה לעסקים
אני בונה אוטומציות מותאמות שמורידות עבודה חוזרת מקצה לקצה.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.