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

חשבונית יכולה להתאים להזמנת הרכש ועדיין לא להתאים לכמות שהתקבלה. בדוגמת הרכש CASE-104 מופיעות 120 תחנות עגינה בחשבונית ובהזמנה, אך תעודת המשלוח מציינת 112. הפער של 8 יחידות דורש בירור לפני שממשיכים בתהליך. התאמה של תנאי התשלום אינה פותרת את הסתירה בכמות.

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

ארבעת מקורות הקלט

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

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

הרשומה המצופה שומרת גם את הסתירה

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

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

{
  "case_id": "CASE-104",
  "status": "human_review_required",
  "fields": {
    "item": {
      "value": "docking_station",
      "source_refs": [
        "invoice",
        "order",
        "delivery",
        "contract"
      ]
    },
    "invoiced_quantity": {
      "value": 120,
      "source_refs": [
        "invoice"
      ]
    },
    "ordered_quantity": {
      "value": 120,
      "source_refs": [
        "order"
      ]
    },
    "delivered_quantity": {
      "value": 112,
      "source_refs": [
        "delivery"
      ]
    },
    "payment_terms_days": {
      "value": 30,
      "source_refs": [
        "invoice",
        "contract"
      ]
    }
  },
  "checks": [
    {
      "id": "quantity_reconciliation",
      "expected_quantity": 120,
      "observed_quantity": 112,
      "difference_units": 8,
      "status": "human_review_required",
      "source_refs": [
        "invoice",
        "order",
        "delivery"
      ]
    },
    {
      "id": "payment_terms",
      "value_days": 30,
      "status": "matched",
      "source_refs": [
        "invoice",
        "contract"
      ]
    }
  ]
}

הורדת דוגמת CASE-104 כקובץ JSON. הקובץ כולל illustrative: true, מצב בדיקה, מקורות, כללי בקרה ורשימת בדיקה. אין בו פרטים אישיים או סכומים כספיים.

שלושה מצבים שמעבירים לבדיקה

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

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

רשימת בדיקה לגורם המבקר

1. לוודא שכל המקורות שייכים ל-CASE-104 ומתייחסים לתחנות עגינה.
2. לבדוק את הכמויות ואת יחידות המידה בחשבונית בעמוד 1, בהזמנה בשורה 8 ובתעודת המשלוח בעמוד 1.
3. להשוות את תנאי התשלום בחשבונית מול סעיפים 2 עד 3 בהסכם.
4. לברר את הפער של 8 יחידות עם הגורם שאחראי לרכש או לקבלת הסחורה, ולצרף ראיה שתומכת בפתרון.
5. לתעד את החלטת הבדיקה, את הביסוס שלה ואת האחריות להמשך בתהליך הארגוני.
6. להשאיר את התיק בבדיקה עד שהפער נפתר. שדה אחד שנמצא מתאים אינו אישור לתיק כולו.

מה כדאי לקחת לאפיון תהליך אמיתי?

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

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