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

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

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

מה טופס חיוב עסקי באמת אוסף?

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

השדות משתנים ממדינה למדינה, אך הם מתקבצים לקבוצות מוכרות:

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

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

מהם ארבעת הענפים שכל טופס חיוב צריך להיבדק דרכם?

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

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

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

מדוע אותו שדה מתנהג אחרת במדינות שונות?

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

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

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

מה משתבש מעבר לטופס עצמו?

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

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

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

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

למפתחים: מטריצת המקרים ומערכי הנתונים

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

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

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

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

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

צעדים הבאים

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