גרסה 400 — השורה שתוקנה ממסך החוסרים נשארת ירוקה במקומה

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

• השורה נשארת במקומה, ירוקה. מוצר שכמותו תוקנה במסך הזה ואין בו עוד חוסר או עודף מוצג באותה קבוצה ובאותו מקום (לפי סדר הנייר), בירוק: "הגיע הכול · 80 יח׳" (או "כמו בתעודה · 12 יח׳" לעודף שהתיישר, "לא הגיע · הוסר מהספירה" לעודף של מוצר שאינו בתעודה שנמחק), עם אותם שלושה מספרים (חויב בתעודה 80 · נסרק בפועל 80 · חסר 0), עם המשפט "תוקן כאן. טעית? שנה את הכמות והחוסר יחזור." ועם העורך. מורידים את המספר — השורה חוזרת להיות אדומה באותו מקום, והחוסר חוזר. בכותרת הקבוצה: תג ירוק "תוקן 1" (או "תוקנו 3") ליד מניין הפתוחים; כשלא נשאר שום דבר פתוח הקבוצה כולה ירוקה והכותרת היא "מה שתיקנת כאן:".
• הזיכרון נשמר עם ההשוואה. מה תוקן כאן נשמר בטיוטה יחד עם מצב ההשוואה (ועובר בהעברת טיוטה בין טלפונים): "חזור לסריקה" וחזרה, סגירת האפליקציה ופתיחה — השורה הירוקה חוזרת. הוא נמחק כשהתעודה נשמרת או מתבטלת, וכשההשוואה נפתחת מחדש מאפס.
• ההשוואה לא קופצת ל"מאוזן" מעצמה. כשמסך הסריקה פתוח ויש בו שורה ירוקה, סגירת החוסר האחרון (גם כשהסכום הוקלד ידנית והתעודה מתאזנת) משאירה את המסך עם השורה הירוקה; "הכול תואם — המשך" הוא שמוביל הלאה, כמו קודם.
• מה לא השתנה. מוצר שעדיין יש עליו חוסר או עודף מוצג כממצא רגיל, לא כירוק; כרטיס המנתח, הזיכויים, המחירים והנייר שנקרא — כמו בגרסאות 397–399.

בדיקה: node --test tools/finding-received-edit.test.mjs (12; מהן חדשות: השורה הירוקה והחזרה ממנה, שמירת המקום בין שתי שורות, שחזור אחרי "חזור לסריקה" ואחרי פתיחה מחדש, והמסך שנשאר כשהתעודה מתאזנת); כל הבדיקות עוברות (node --test tools/*.test.mjs tests/*.test.mjs).

גרסה 399 — תעודה שלא מתאזנת: מה חסר, איפה ההפרש ואילו שורות לבדוק

מהשטח (קליטה פתוחה מ-22.10.2026 בבוקר, שירות 153): תעודת משלוח 9073907315, 3 עמודים, 28 שורות, ₪1,816.37 ו-348 יחידות מודפסים, נקראה שלוש פעמים ואף קריאה לא התאזנה. הקריאה שנבחרה (המודל החזק) החליקה בעמוד 1 את המספרים בשורה: דילגה על הלאבנה (12 × ₪9.10 = ₪109.20) וספרה ₪52.80 פעמיים, ולכן חסרו ₪56.40. קריאה זולה אחת החליקה באותו מקום, ולכן ההצבעה "אישרה" את המספרים השגויים. הקריאה הזולה השנייה קראה את עמוד 1 נכון. העובד קיבל "תעודה 1: סכום שורות הנטו אינו תואם בדיוק לסיכום המודפס", כפתור "בדוק צילומים / הוסף עמוד חסר" אף שלא חסר עמוד, ו-36 כרטיסים "הפענוח חלקי או חסר עמוד", גם לתעודה השנייה שנקראה מושלם. ובנוסף באג, שהתגלה בהרצה של הטיוטה הזאת לפני שהעובד תיקן שורה: תיקון שלוש השורות לפי הנייר מאזן את התעודה, אבל הקליטה נשארת חסומה עם "השלם צילום או הזן ידנית את נתוני התעודה לפני הסיום".

• תיקון שמאזן את התעודה משחרר את הקליטה. אחרי כל תיקון לפי הנייר, וגם בלחיצה על "סיום", התעודות נבדקות שוב בדיוק כמו בסוף הפענוח. כשכולן מתאזנות, הסכומים והיחידות המודפסים נקלטים והקליטה ממשיכה. קליטה שתוקנה בגרסה קודמת ונשארה חסומה מראה "כל התעודות מתאזנות עכשיו מול הסיכום המודפס" וכפתור "המשך".
• הודעה אחת שאומרת מה קרה. כשהבעיה בנייר היא רק הכסף או היחידות (מספר העמודים ומונה השורות תואמים), ההודעה בראש הקליטה אומרת למשל "תעודה 9073907315: חסרים ₪56.40 מול הסיכום המודפס. כל השורות והיחידות נקראו, אז לא חסר עמוד. כנראה מספר באחת השורות נקרא לא נכון. ההפרש בעמוד 1." במקום "הוסף עמוד חסר" יש "או צלם את התעודה מחדש" ו"או הקלד סכום ויחידות", כמו קודם.
• איפה ההפרש. האפליקציה מחפשת עמוד שבו קריאה אחרת, שקראה את כל שורות העמוד באותו מספר שורות, מביאה את הכסף ואת היחידות של התעודה בדיוק לסיכום המודפס. בבדיקת המחירים מופיע כרטיס אחד לתעודה: מה מודפס, מה נקרא, "ההפרש בעמוד 1: קריאה אחרת של העמוד מסתכמת ל-₪527.76 במקום ₪471.36", ולכל שורה לבדיקה מה נקרא, מה הקריאה האחרת ראתה ומחיר היחידה במאגר. בלי עמוד כזה מוצגות עד 8 שורות שבהן הקריאות ראו מספרים שונים. כשכמה קריאות מאזנות את העמוד בשורות אחרות (בשטח: אחת בשורה 4, השנייה בשורות 5–7), הכרטיס אומר שרק הנייר מכריע ביניהן.
• "בנייר כתוב 12 × ₪9.10 = ₪109.20". הכפתור פותח את חלון התיקון הקיים כשהוא ממולא במה שהקריאה האחרת ראתה, עם השורה "המספרים מולאו לפי קריאה אחרת של השורה. השווה אותם לנייר לפני האישור." האישור, הבדיקות והשמירה זהים לתיקון ידני, ו"בנייר כתוב משהו אחר" פותח אותו ריק מהצעה. שורה שתוקנה לא מוצעת שוב. אחרי כל תיקון ההודעה מתעדכנת, למשל "חסרים ₪16.56 וחסרות 12 יחידות" אחרי השורה הראשונה מתוך שלוש.
• רק מה שיש לעשות. כשתעודה לא מתאזנת, השורות שרק מחכות שהתעודה תתאזן לא מקבלות כרטיס. במקומן שורה אחת: "עוד 31 שורות ייבדקו אחרי שהתעודה תתאזן. אין בהן מה לעשות עכשיו." שורות עם משימה משלהן, כמו בחירת מוצר, נשארות כרטיסים, והכותרת סופרת אותן.

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

על הקליטה מהבוקר: שלוש ההצעות לשורות 5–7 מאזנות את התעודה בדיוק על ₪1,816.37 ו-348 יחידות, והקליטה ממשיכה. נשארות 5 שורות רגילות לטיפול: 3 לבחירת מוצר ו-2 לבדיקה מול הנייר.

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

בדיקות: node --test tools/paper-gap.test.mjs (6 חדשות: הכרטיס במקרה מהשטח, שלושת התיקונים ושחרור הקליטה, קליטה שתוקנה ונשארה חסומה, הצעה בשורה הלא נכונה, בעיית נייר אחרת וחלון התיקון בלי הצעה). חמש הראשונות נכשלות על גרסה 398. כל הבדיקות עוברות (node --test tools/*.test.mjs tests/*.test.mjs).

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

מהשטח (גיבוי החנות, 22.10.2026, אפליקציה v397): בעל העסק פתח את קובץ הגיבוי ושאל אם בכלל נקלטה תעודה. בפועל כל 18 הקליטות שנסרקו מאז 8.9 נקראו במלואן (סכום השורות וסך היחידות תאמו לנייר בכל 28 התעודות), כל 22 השורות שדרשו הכרעה נפתרו בזמן הקליטה, וכל 10 החוסרים נסגרו — בקיזוז, בהשלמת סחורה או בזיכוי. אבל הקובץ והמסכים הראו רק דגלים טכניים: needs_review על 10 מתוך 28 תעודות (שורה אחת שבה הברקוד לא הצביע על מוצר יחיד והעובד בחר), hasDiscrepancy: true ו-status: "open" על 10 קליטות שהמסך כבר הציג מאוזנות, וכרטיס „צריך להשלים את הבדיקה” עם ארבע קריאות ומודל חזק. שום דבר לא אמר במשפט אחד מה המצב ומה לעשות.

• משפט אחד לכל קליטה שמורה. בכרטיס המקופל, מתחת לתאריך: „נקלטה ומאוזנת ✓ · קיזוז”, „חסר 6 × פסטה רביולי גבינה ילדים · ₪67.75 · ממתין לזיכוי מהספק”, „עודף 12 × … (₪…) · לא בתעודה — לקזז מול חוסר או לתקן”, „נקלטה לפי ספירה בלי תעודה · ממתינה לנייר”, „ממתין לזיכוי ספק של ₪… על מחיר או מבצע”, „פער של 8 יחידות חסרות שטרם שויך למוצר”. המשפט נבנה מאותם חישובים של המסך (receiptDiscrepancyInfo) ואינו משנה שום סכום. כשיש מה לעשות, הכרטיס הפתוח נפתח בקופסה „מה לעשות עכשיו” עם המשפט וכפתור אחד (התקבל זיכוי מהספק / תקן הפרשים / הגיע זיכוי). שאר הכרטיס, פס המצב והכפתורים כמו קודם.
• בקליטה, הכותרת אומרת מה לעשות. „נשארה שורה אחת לבחירת מוצר”, „נשארו 2 שורות לבדיקה מול הנייר”, „שורה אחת עם פער מחיר”, וכשיש כמה סוגים — „נשארו 3 שורות לטיפול: 1 לבחירת מוצר · 1 לבדיקה מול הנייר · 1 להשלמת מחיר במאגר” (גם בכפתור הקטן במסך הסריקה). כרטיס שורה שהקריאות לא הסכימו עליה נפתח ב„בדוק את הכמות מול הנייר” / „בדוק את המחיר והסכום מול הנייר” / „בדוק את הכמות והמחיר מול הנייר” במקום „צריך להשלים את הבדיקה”. ההסבר הטכני — מה כל קריאה ראתה, המודל החזק, הקריאה הרביעית, למה החשבון לא מכריע — נשאר במלואו, מקופל תחת „פרטים טכניים — מה כל קריאה ראתה”, אחרי הכפתור. גם באימות סיכום התעודה: קודם „בדוק מול הנייר: ₪… לפני מע״מ · … יחידות · … שורות שנקראו” והכפתור, ואחריהם ההסבר מקופל. שום כלל של אישור, תיקון או חשבון לא השתנה.
• הסטטוס השמור מתעדכן כשהתעודה נסגרת. עד כאן status ו-aiAudit.hasDiscrepancy נכתבו רק בשמירה ובסגירת דרישת זיכוי; קיזוז (ידני, לפי שווי, אוטומטי, שחזור ישן), השלמת סחורה וזיכוי על חוסר השאירו open לנצח. עכשיו כל כתיבה כזאת כותבת גם את הסטטוס לפי המצב האמיתי (וביטול קיזוז פותח מחדש), לפי אותו כלל כמו סגירת זיכוי: ממצא מחיר או מבצע אמיתי משאיר פתוח; דגל ישן בלי ממצאים לא נועל תעודה מאוזנת. aiAudit נכתב רק כשהדגל באמת משתנה, והממצאים עצמם נשארים להיסטוריה. המסך לא השתנה — הוא תמיד חישב מחדש. רשומות שנסגרו לפני 398 נשארות עם השדה הישן עד הכתיבה הבאה אליהן; המשפט במילים הוא הקובע.
• קובץ הגיבוי נפתח בסיכום במילים (summary, לפני collections): ספירה (כמה מאוזנות, כמה פתוחות), שורה לכל קליטה — תאריך, מספרי תעודות, מצב ופעולה באותן מילים כמו במסך — ומילון קצר לדגלים הטכניים (status, aiAudit.hasDiscrepancy, needs_review, priceAudit.rows[].result). הייבוא קורא רק את collections ומתעלם מהסיכום. תווית הגרסה ביומן הפעולות ובגיבוי (appVersion) נגזרת עכשיו מ-APP_VERSION (עד כאן נשארה המחרוזת v396_second_strong_read).

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

יש לסגור ולפתוח את האפליקציה ולבדוק 398 בתחתית.

בדיקות: node --test tools/plain-receipt-status.test.mjs (7 חדשות: המשפט לכל מצב, הכרטיס והקופסה, הסטטוס השמור בכל סוגי הסגירה והפתיחה מחדש, סיכום הגיבוי, כותרות הקליטה); הניסוח החדש עודכן ב-tools/quantity-arithmetic.test.mjs, tools/quantity-arithmetic-contract.test.mjs, tools/second-strong-read.test.mjs, tools/values-confirm-arithmetic.test.mjs ו-tools/early-price-audit.test.mjs; כל הבדיקות עוברות (node --test tools/*.test.mjs tests/*.test.mjs).

גרסה 397 — תיקון הכמות שהתקבלה ישירות ממסך החוסרים והעודפים

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

• "קיבלתי בפועל" מתחת לכל חוסר ועודף. בכל שורה במסך החוסרים והעודפים (שורות המנוע, וגם כרטיס המנתח כשהוא מוביל ומציג את שלושת המספרים) יש שדה כמות עם − / +, וכפתור מהיר: בחוסר "הגיע הכול (80)", בעודף של מוצר שמופיע בתעודה "כמו בתעודה (12)", ובעודף של מוצר שאינו בתעודה "לא הגיע (0)". מקלידים 64 ויוצאים מהשדה (או Enter) — השורה אומרת "חסר 16"; מקלידים 80 — החוסר נעלם, ואם זה היה ההפרש היחיד התעודה נסגרת מול הנייר. הודעה קצרה אומרת מה נרשם ומה נשאר: "עודכן: התקבלו 64 יח׳ · עדיין חסר 16 יח׳".
• זו אותה ספירה, לא עותק. הכמות נכתבת גם לשורת ההשוואה וגם לרשימת הסריקה, ובסיס ההשוואה מתקדם איתן — "חזור לסריקה" מראה את הכמות המתוקנת, וחזרה משם למסך ההשוואה שומרת אותה; הטיוטה נשמרת, וגם אחרי סגירת האפליקציה הספירה והממצאים חוזרים מתוקנים. כמות 0 מורידה את המוצר מרשימת הסריקה.
• בלי קריאה בתשלום. הממצאים מחושבים מחדש מקומית מהפענוח השמור של הנייר, בלי צילום ובלי סריקה. המנתח אינו רץ מעצמו אחרי תיקון (אפשר להריץ אותו מהכפתור, כמו קודם); תשובה ישנה שלו שתגיע אחרי התיקון נפסלת, כי ההערכה שהוא נשלח עליה כבר אינה ההערכה הנוכחית.
• מה לא השתנה. הנייר שנקרא, המחירים, הזיכויים ובדיקת המחירים. העורך לא מופיע בשורת פיקדון, בכרטיס מנתח שכמותו אינה ההפרש בין הנייר לסריקה (חלק מהחלפה), בכרטיס מנתח ישן שנשאר אחרי חישוב מחדש, ולא כשהטיוטה נעולה (נשמרת, או עברה לטלפון אחר). קלט שאינו מספר שלם ("-1", "abc") נדחה בלי לשנות את הספירה.

בדיקה: node --test tools/finding-received-edit.test.mjs (10 חדשות: הקלדה, "הגיע הכול", − / +, עודף של מוצר שלא בתעודה, חזרה לסריקה וחזרה, שחזור טיוטה, קלט פסול ותשובת מנתח ישנה, כרטיס המנתח, מצבים בלי עורך); כל הבדיקות עוברות (node --test tools/*.test.mjs tests/*.test.mjs).

גרסה 396 — קריאה רביעית במודל החזק (שירות הפענוח 153)

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

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

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

באפליקציה:

• שדה שנסגר כך לא מוצג לעובד בכלל: אין כרטיס ואין הודעה חדשה. הערכים תמיד מהקריאה שנבחרה. רק בנתוני האבחון (המקופלים) נוספה שורה „קריאה 4 (המודל החזק, פעם שנייה)”: מה קרה בה, כמה שדות נסגרו, ומספר הטוקנים שלה. כשהיא לא הייתה זהה (not_identical) השורה מוסיפה גם כמה הבדלים היו ואיפה הראשון.
• כשהקריאה הרביעית לא הייתה זהה, הכרטיס „צריך להשלים את הבדיקה” מציג את ארבע הקריאות, למשל „קריאה 1 – 16.13 · קריאה 2 – 16.30 · קריאה 3 (המודל החזק) – 16.03 · קריאה 4 (המודל החזק, פעם שנייה) – 16.03”, ואחריהן „גם הקריאה השלישית והקריאה הרביעית (המודל החזק, פעמיים) קראו את הנייר, אבל הקריאה הרביעית לא הייתה זהה לשלישית בכל התעודה, ולכן היא לא אישרה אף שדה”. כך העובד יודע למה שדה שהמודל החזק קרא פעמיים באותו ערך עדיין מחכה לו. הקריאה הרביעית מוצגת רק לאותה שורה מודפסת באותה תעודה; אם קראה את השורה פעמיים, דילגה עליה או החזירה תעודה אחרת במקומה, היא לא מוצגת. האישור והתיקון לפי הנייר נשארו כמו קודם.
• כשהקריאה הרביעית הייתה זהה, השדות שנשאלו נסגרו. אם בשורה נשאר שדה שלא נשאל (למשל הכמות, כשאחת הקריאות הזולות לא קראה אותה), הכרטיס אומר „... והיו זהות, אבל הקריאה הרביעית לא נשאלה על הכמות”. בשורה „החשבון לא מכריע” הוא אומר, למשל, „סכום השורה והסכום לפני הנחה אושרו רק בקריאה הרביעית (המודל החזק, פעם שנייה), שלא נשאלה על הכמות”, ולא „לא מוסכם בין הקריאות”.
• הקריאה הרביעית לא מוכיחה כמות בחשבון. השירות לא מוסיף אותה לרשימת הקריאות התומכות של השדה (fieldSupport): שדה שנסגר בה רק יוצא מרשימת הבעיות ונרשם ב-secondStrongRead.closed. לכן החשבון של האפליקציה (כמות × מחיר = סכום השורה, על תעודה מאוזנת) לא נשען עליה, בדיוק כמו בגרסה 395 ובלי שום כלל מיוחד, וגם השירות לא בודק חשבון אחרי הקריאה הרביעית. כמות שהשירות השאיר פתוחה בשורה שבה הקריאה הרביעית סגרה כסף לא נשאלה בכוונה. אם הכסף היה נספר, החשבון היה מאשר בלי כרטיס את הכמות של קריאת ההכרעה, גם כשהיא החליפה שתי שורות באותו מחיר.
• הקריאה הרביעית לעולם לא קובעת איזה מוצר מופיע בשורה. ההתאמה לפי מחיר מאומת והזהות המוסכמת נשענות רק על שלוש הקריאות הראשונות.

מה שלא השתנה:

• עם שירות 152, עם שירות 153 שהקריאה הרביעית בו כבויה (SECOND_STRONG_READ=off), וכשהקריאה הרביעית נכשלה או לא הספיקה לרוץ, הכרטיסים בדיוק כמו בגרסה 395. גם גרסה 395 עם שירות 153 משאירה לעובד כל שדה שהשירות לא סגר, כי הקריאה הרביעית לא נכנסת לרשימת הקריאות התומכות. ההבדל הוא רק בניסוח הכרטיס. לכן אפשר לעדכן את האפליקציה לפני השירות או אחריו.
• זמן ההמתנה לסריקה (420 שניות) לא השתנה. שירות 153 מריץ את הקריאה הרביעית רק אם היא תסתיים לכל המאוחר 360 שניות מהרגע שהבקשה הגיעה אליו, כולל זמן העלאת הצילומים. זה לא מאוחר יותר ממה ששלוש הקריאות הראשונות לבדן כבר יכולות להימשך אחרי ההעלאה (180 + 180 שניות, כמו בשירות 152). לכן הקריאה הרביעית אף פעם לא מאריכה סריקה מעבר למה שהיה אפשרי קודם, והמרווח להעלאה ולתשובה נשאר כמו שהיה. כשלא נשאר לה זמן היא לא רצה, והשדה נשאר לעובד כמו היום.

יש לסגור ולפתוח את האפליקציה ולבדוק 396 בתחתית.

בדיקות: node --test tools/second-strong-read.test.mjs tools/quantity-arithmetic.test.mjs tools/quantity-arithmetic-contract.test.mjs tools/values-confirm-arithmetic.test.mjs.

גרסה 395 — אישור בהקשה אחת רק כשהחשבון של השורה תואם

בכרטיס „צריך להשלים את הבדיקה” הכפתור „כן, הכמות והמחיר נכונים לפי הנייר” הופיע גם כשהמספרים שנקראו בשורה סותרים זה את זה. למשל כמות 6, מחיר יחידה 16.13 וברוטו 96.18: לפי מחיר × כמות יוצא 96.78, כלומר אחד התאים נקרא לא נכון, ובהקשה אחת הוא היה מאושר כמו שנקרא.

עכשיו האישור בהקשה אחת מוצע רק כשמחיר × כמות תואם לברוטו של השורה. כשהברוטו לא נקרא, הבדיקה היא מחיר × כמות פחות ההנחה מול סכום השורה, כשההנחה וסכום השורה נקראו. הסטייה המותרת היא אותה סטייה של בדיקת השורה הרגילה: חצי אגורה לכל יחידה כשמחיר היחידה מודפס באגורות, ואגורה אחת כשהוא מודפס עם יותר ספרות. כשהחשבון לא תואם, הכרטיס מציג שורה אחת עם הסיבה („מחיר × כמות אינו תואם לסכום הברוטו בשורה — תקן לפי הנייר”) ואת הכפתור „הפענוח שגוי — תקן לפי הנייר”. גם לחיצה מכרטיס ישן נדחית.

מה שלא השתנה:

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

יש לסגור ולפתוח את האפליקציה ולבדוק 395 בתחתית.

בדיקות: node --test tools/values-confirm-arithmetic.test.mjs tools/quantity-arithmetic.test.mjs tools/quantity-arithmetic-contract.test.mjs tools/receipt-review-fixes.test.mjs.

גרסה 394 — זיכוי שצולם כתעודה נעצר עם הסבר

תעודת זיכוי מהנהג שצולמה בכפתורי התעודה הרגילים („+ תעודה נוספת מהנהג / הספק”) נקראה עד היום כחשבונית. העובד ראה הודעות מטעות („הסכום ללא מע״מ לא נקרא…”, „ודא שצולם גם העמוד האחרון…”), ובקריאה שאיבדה את סימני המינוס הזיכוי אף נקלט כתעודת משלוח נוספת — הסחורה שבו נספרה כמחויבת ונוצרה תביעת חוסר מדומה.

עכשיו תעודה כזאת מזוהה ונעצרת, ושום דבר לא זז לבד. במקום ההודעות הישנות מופיעה הודעה אחת: „תעודה 2 נראית כמו תעודת זיכוי — הסר אותה מהתעודות (בדוק צילומים) וצלם אותה בכפתור הירוק «הנהג הביא זיכוי על חוסר? צלם כאן».” עד אז הסיום חסום, כמו בכל תעודה שלא נקראה. יש שתי דרכי יציאה: „בדוק צילומים / הוסף עמוד חסר” — מסירים שם את הזיכוי, והתעודות האחרות כבר שמורות ולא נקראות שוב בתשלום; או „או הקלד סכום ויחידות” — אם זו בכל זאת תעודת משלוח (אז ההשוואה האוטומטית מול הנייר לא חלה על הקליטה הזאת, והכמויות שבנייר מוזנות ידנית). בספק עוצרים: גם תעודת משלוח שאחת הקריאות ראתה בה מינוס, או שבכותרת שלה מופיעה המילה „זיכוי”, תיעצר — כי בלי זה זיכוי שאיבד את המינוס היה נקלט כסחורה. גם סכום או יחידות עם מינוס שמוקלדים ידנית נדחים עם הסבר, ולא נוספים עוד כסכום חיובי. בצירוף נייר לקליטה שנשמרה (שם אין כפתור ירוק) ההודעה מפנה ל„התקבל זיכוי מהספק” בקליטה השמורה.

הזיהוי עובד גם עם שירות הפענוח 150: לפי סכום שלילי באחת הקריאות. שירות 151 מוסיף זיהוי לפי הכותרת המודפסת („ביטול מכירה”, „זיכוי” / „זכוי”, „ביטול חשבונית”, „תעודת החזרה”), וכך נתפס גם זיכוי שסימני המינוס שלו אבדו בקריאה. עם שירות 150 זיכוי כזה עדיין נקלט כמו היום.

יש לסגור ולפתוח את האפליקציה ולבדוק 394 בתחתית.

בדיקות: node --test tools/credit-document-guard.test.mjs tools/scan-transport.test.mjs tools/credit-on-gate.test.mjs.

גרסה 393 — זיכוי שסוגר הכל מוצג כסגור

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

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

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

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

בדיקות: node --test tools/reconcile-credit-baseline.test.mjs tools/reconcile-draft.test.mjs tools/credit-auto-attach.test.mjs tools/credit-on-gate.test.mjs tools/receipt-history-credit.test.mjs.

גרסה 392 — שדה הדבקת הזמנה פתוח תמיד

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

יש לרענן את האפליקציה ולבדוק 392 בתחתית.

גרסה 391 — מסך פשוט להזמנה באפליקציה

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

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

גרסה 390 — הערה על שורה אינה מסמך חלקי

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

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

בדיקות: node --test tools/price-document-warning.test.mjs tools/early-price-audit.test.mjs tools/actionable-price-review.test.mjs tools/document-summary-review.test.mjs.

גרסה 389 — תזכורת חוסרים מפורטת בהחזרות בלבד

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

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

יש לסגור ולפתוח את האפליקציה ולבדוק 389 בתחתית.

בדיקות: node --test tools/supplier-gap-reminder.test.mjs tools/receipt-history-credit.test.mjs tools/returns-events.test.mjs tools/returns-history-unified.test.mjs.

גרסה 388 — הקליטה נשמרת בטלפון עד הסיום

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

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

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

בדיקות: node --test tools/receiving-handoff.test.mjs tools/reconcile-draft.test.mjs tools/receipt-scan-persistence.test.mjs tools/receipt-scan-regression.test.mjs וכן בדיקות המודול tests/local-receiving-adversarial.test.mjs.

גרסה 387 — תיקון חוסרי שווא בבדיקת קליטה

בסיס הספירה של רשימת ההשוואה מתקדם רק כשהשינויים הוחלו עליה. שמירה אוטומטית אחרי סריקות נוספות אינה מסמנת אותן בטעות ככבר מטופלות. בפתיחת הבדיקה מושלמים גם מוצרים שנשמטו מטיוטות גרסאות 384–386, תוך שמירת תיקוני כמות, מחיר ושורות נייר ידניות. פענוח התעודה השמור משמש לחישוב מחדש בלי בקשת OCR נוספת; חוסר אמיתי או הבדל ברקוד ממשיכים להופיע.

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

בדיקות: node --test tools/reconcile-draft.test.mjs tools/receipt-scan-persistence.test.mjs tools/receipt-scan-regression.test.mjs tools/receiving-handoff.test.mjs.

גרסה 386 — החזרות משותפות בלי מחיקת סריקות

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

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

פירוט ההגירה, ההגנות והבדיקות.

גרסה 385 — קליטה בטלפון והמשך בטלפון אחר

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

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

פירוט החיבור והבדיקות.

גרסה 384 — תיקוני ההשוואה נשמרים

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