חשבונית ישראל ומספרי הקצאה: מה זה אומר למערכות שלכם

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

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

השינוי המבני

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

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

כל מה שקשה בזה נובע מהמשפט האחד הזה.

איפה זה יושב בזרם

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

הצורה הטובה יותר מפרידה בין האירוע המסחרי להפקת המסמך:

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

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

מצבי כשל שצריך לתכנן עבורם

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

תעודות ואישורי גישה

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

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

כדאי לבנות את זה בעצמכם?

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

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

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

מה לשאול את רואה החשבון

לפני כל ההנדסה, קבלו תשובות בכתב לאלה. הן קובעות את כל התכנון:

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

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

הגרסה הקצרה

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

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