דוח יומי מאתר בנייה דרך WhatsApp: מבנה ראיה שלא מסתמך על הודעות חופשיות

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

חמשת העוגנים שהודעה חופשית לא נושאת

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

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

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

איזו חותמת זמן קובעת בדיווח מהשטח?

זו שמגיעה מ-WhatsApp בתוך ה-webhook. באירוע הודעה נכנסת השדה timestamp מוחזר כמחרוזת של שניות Unix, לצד from ומזהה הודעה שמתחיל ב-wamid.. שלושת השדות האלה הם מה שיש לכם שלא נוצר אצלכם. למדריך מעשי ראו איך בונים בוט וואטסאפ.

קיימים שלושה זמנים שונים סביב אותה תמונה, וכדאי לשמור את שלושתם בשדות נפרדים:

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

חלון חמש הדקות שקובע אם נשארה לכם תמונה

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

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

מגבלות הגודל של Meta קובעות גם מה בכלל אפשר לצפות שיגיע מהשטח:

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

הרשומה עצמה: מה נשמר לכל דיווח

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

• report_id - מזהה פנימי, לא מספר רץ של הודעה.
• site_id ו-zone_id - אתר ואזור, שניהם מרשימה סגורה.
• work_item_id - סעיף עבודה מכתב הכמויות.
• reported_by - מזהה עובד, לא מספר טלפון. מספר הטלפון נשמר בנפרד כערוץ.
• wa_message_id - ה-wamid המקורי, כדי שתמיד אפשר להצביע להודעה.
• sent_at - חותמת ה-webhook.
• raw_text - הטקסט כפי שנשלח, ללא ניקוי.
• media[] - לכל קובץ: מזהה מדיה, נתיב מקומי לעותק שהורד, סוג MIME וגודל.
• exceptions[] - עיכוב, ליקוי בטיחות או חוסר, כל אחד עם חומרה ובעלים.

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

מה קורה כשמנהל העבודה מתקן דיווח למחרת?

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

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

שלושה מצבים שכדאי להגדיר מראש:

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

מה נשבר בפועל

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

מה צריך להיות מוכן לפני שמתחילים

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

מקורות

• WhatsApp Cloud API - Media reference
• WhatsApp Cloud API - Send messages
• RFC 3339 - Date and Time on the Internet