מערכת ותיקה יכולה להמשיך להנפיק מסמכים גם כשנדרש מספר הקצאה. מה חסר בה בפועל, אילו שדות צריך להוסיף, ואיך בונים שכבת ביניים שמדברת עם השירות.
עיקרי הדברים
- הפער הנפוץ הוא שלושה שדות חסרים ברשומת המסמך, לא מנוע חדש: מזהה `INVOICE_ID`, מספר ההקצאה שהתקבל, וסטטוס הפנייה.
- לפי המפרט, מספר האסמכתא הופך לנתון חובה החל משנת 2025, ויש לפנות לשירות כאשר החשבונית כבר נושאת את מספר האסמכתא.
- שכבת ביניים שקוראת מהמערכת הישנה ופונה לשירות מאפשרת להשאיר את קוד ההנפקה הישן ללא שינוי מהותי.
- הזדהות מול השירות היא ב-OAuth2, כך שהמערכת הישנה צריכה גישה יוצאת ל-HTTPS ומקום מאובטח לשמירת סודות.
- הדפסת המסמך היא הצעד האחרון בזרימה, לא הראשון, ושינוי סדר הפעולות הזה הוא רוב העבודה.
מערכת ותיקה שמנפיקה חשבוניות לא חייבת להיזרק כדי לעבוד מול שירות מספר ההקצאה. הפער הוא כמעט תמיד פער נתונים ולא פער ארכיטקטורה: חסרים שדה מזהה חד-ערכי, שדה לשמירת המספר שהתקבל, ונקודה בזרימה שבה עוצרים לפני ההדפסה.
זהו תיאור טכני של ארכיטקטורה ושל שדות נתונים, ולא ייעוץ מס, משפטי או חשבונאי.
מה בדיוק חסר במערכת הוותיקה
מערכות שנבנו לפני עידן החשבונית המקוונת מנפיקות מסמך ומדפיסות אותו באותה פעולה. אין ביניהן נקודת עצירה שממתינה לתשובה חיצונית. זה המבנה שצריך לפרק, וזה גם החלק היחיד שבאמת נוגע בקוד הישן.
ברמת הנתונים, אלה השדות שכמעט תמיד חסרים ברשומת המסמך:
- מזהה חד-ערכי קבוע לפנייה, שנשמר לפני הקריאה הראשונה ולא נוצר בזמן ההדפסה.
- שדה לשמירת מספר ההקצאה שהתקבל, בנפרד ממספר המסמך הפנימי.
- סטטוס פנייה: לא נשלח, נשלח, אושר, לא אושר, נבחרה חלופה.
- חותמת זמן לפנייה האחרונה ומונה ניסיונות.
- שדה מספר עוסק של הלקוח, מלא ותקין, ולא טקסט חופשי בשדה שם.
השדה האחרון הוא זה שמפיל הכי הרבה מסדי נתונים ותיקים, כי בהרבה מערכות מספר העוסק של הלקוח נשמר כטקסט לצד השם או לא נשמר בכלל. אימות מבני של מספרי זיהוי לפני שהם מגיעים לממשק מתואר באימות תעודת זהות וח\"פ בטפסים.
האם אפשר להוסיף הקצאה בלי לגעת במערכת הישנה?
כמעט. הדרך המעשית היא שכבת ביניים נפרדת שיושבת בין המערכת הישנה לבין השירות, אבל היא לא יכולה להיות שקופה לחלוטין: מישהו חייב להחזיק את מספר ההקצאה ואת הסטטוס, ומישהו חייב לעצור את ההדפסה. שני הדברים האלה נוגעים במערכת המקור.
מה שכן אפשר להשאיר ללא שינוי: לוגיקת התמחור, מספור המסמכים הפנימי, הדוחות, וכל מה שסביב. השכבה קוראת את רשומת המסמך, בונה את גוף הבקשה, פונה לשירות, כותבת בחזרה שני שדות, ומחזירה תשובה בינארית למסך ההנפקה.
| רכיב | נשאר במערכת הישנה | עובר לשכבת הביניים |
|---|---|---|
| מספור מסמכים פנימי | כן | לא |
| בניית גוף הבקשה | לא | כן |
| הזדהות וניהול טוקן | לא | כן |
| שמירת מספר ההקצאה | כן, בשדה חדש | לא |
| ניסיונות חוזרים והשהיה | לא | כן |
| החלטת המשתמש בחלופות | מסך ההנפקה | תיעוד ושידור |
| הדפסה | כן, בסוף | לא |
סדר הפעולות שמשתנה
- המסמך נשמר עם מספר האסמכתא שלו לפני הפנייה, כי לפי המפרט הפנייה נעשית כשהחשבונית כבר נושאת את מספר האסמכתא.
- הפנייה יוצאת עם מזהה חד-ערכי ועם שדות המסמך.
- התשובה נבדקת על שדות הפלט ולא על קוד ה-HTTP בלבד.
- מספר ההקצאה נשמר ברשומה, ורק אז המסמך מודפס.
- אם לא התקבל מספר, המסך מציג את החלופות והבחירה מתועדת.
הפרדה נוספת שחוסכת כאב: המתנה, ניסיון חוזר והשהיה אינם עניין של מסך ההנפקה. אם השירות איטי, המסך צריך להראות מצב ולא להיתקע, והמערכת צריכה להיות מסוגלת להמשיך מהנקודה שבה עצרה.
מה קורה למערכות Access ולקבצים ישנים
מסדי נתונים ותיקים מוסיפים שכבת קושי משלהם. תאריכים שנשמרו כטקסט חופשי לא יתורגמו לפורמט YYYY-MM-DD שהמפרט מגדיר לשדות התאריך. שדות מספריים שנשמרו כמחרוזת יעברו את הסכימה או ייפלו עליה בהתאם לתוכן שהוקלד לפני עשור. קידוד עברית ישן יכול להפוך שם לקוח לג'יבריש בגוף JSON.
לכן הצעד הראשון הוא דוח חריגים על הנתונים הקיימים, לא כתיבת קוד: כמה מסמכים חסרי מספר עוסק ללקוח, כמה תאריכים לא ניתנים לפרסור, כמה סכומים שליליים במקומות לא צפויים. אם המערכת ממילא בדרך החוצה, כדאי לקרוא את תוכנית מעבר ממערכת Access למערכת ווב לפני שמשקיעים בשכבה שתיזרק.
איך בודקים את זה בלי לסכן חשבוניות אמיתיות?
המפרט מגדיר שתי סביבות: כתובת ייצור וכתובת בדיקות תחת tsandbox. הבדיקה הראשונה היא מול סביבת הבדיקות, עם נתונים מהמערכת האמיתית אבל בסביבת הרצה נפרדת.
- בדיקה של מסמך תקין לחלוטין, כדי לאמת את ההזדהות ואת מבנה הבקשה.
- בדיקה של מסמך עם מספר עוסק שגוי, כדי לראות שהקוד מזהה שגיאת תוכן.
- בדיקה של תשובה שלילית, כדי לוודא שהמסך לא מדפיס.
- בדיקה של הפסקת תקשורת באמצע, כדי לוודא שהמסמך לא נשאר בסטטוס לא ידוע.
- בדיקה של פנייה חוזרת עם אותו מזהה, כדי לוודא שאין כפילות.
מה מחליטים לפני שכותבים שורת קוד אחת
רוב הפרויקטים האלה נתקעים על החלטות תפעוליות ולא על אינטגרציה. כדאי לסגור אותן מראש, כי כל אחת מהן משנה את המימוש.
- מה קורה כשהשירות לא זמין בכלל: המערכת עוצרת הנפקה, או ממשיכה ומסמנת לטיפול.
- מי בעסק מוסמך לבחור חלופה כשלא התקבל מספר, ומה עושים כשהאדם הזה לא נמצא.
- האם הזרימה החדשה חלה על כל סוגי המסמכים או רק על חלקם.
- כמה זמן מחכים לתשובה לפני שהמסך מציג הודעה, וכמה ניסיונות חוזרים מבצעים.
- מי מקבל התראה כשמצטברים מסמכים בסטטוס לא סופי.
ההחלטה הראשונה היא הכבדה מכולן, והיא לא הנדסית. מערכת שעוצרת הנפקה כשאין תקשורת מגנה על שלמות הנתונים ומשביתה את הדלפק. מערכת שממשיכה שומרת על העבודה השוטפת ומייצרת תור של מסמכים שדורשים טיפול. שתי הגישות לגיטימיות, אבל צריך לבחור אחת ולכתוב אותה איפשהו, כי אחרת היא נקבעת בפועל על ידי מה שקרה להיות בקוד.
מה זה עושה לדיווח המפורט
השדה החדש לא נשאר בתוך המערכת. במפרט מוגדר "מספר הקצאה קצר" - תשעת התווים האחרונים - שנדרש ברשומת התנועה בדיווח המפורט, הן בצד העסקה והן בצד התשומה. כלומר, כל שינוי שעושים בשכבת ההנפקה חייב להגיע גם לקוד שמייצר את קובץ הדיווח, אחרת מקבלים מערכת שמנפיקה נכון ומדווחת חלקית. הרקע המלא על הקובץ נמצא בדיווח מע\"מ אוטומטי בישראל.
מקורות
שאלות נפוצות
חייבים להחליף את המערכת כדי לעבוד מול השירות?
לא בהכרח. הפער העיקרי הוא שדות ברשומת המסמך ונקודת עצירה לפני ההדפסה. מערכת שאפשר להוסיף לה שלושה שדות ולשנות את סדר ההנפקה יכולה לעבוד מול השירות דרך שכבת ביניים, בלי לגעת בתמחור ובדוחות.
איפה שומרים את פרטי ההזדהות?
המפרט קובע הזדהות בפרוטוקול OAuth2, כלומר יש טוקן שצריך להיות בתוקף. הוא לא שייך לקובץ הגדרות של המערכת הישנה ולא לקוד. שכבת הביניים היא המקום הטבעי להחזיק אותו, לרענן אותו, ולהחזיר שגיאה ברורה כשהוא לא בתוקף.
מה עושים עם חשבוניות ישנות שכבר הופקו?
חשבוניות שהופקו לפני החיבור לא משנות את מצבן בדיעבד בגלל שכבה חדשה. מה שכן צריך זה להחליט מאיזה תאריך המערכת עוברת לזרימה החדשה, ולוודא שקוד הדיווח יודע לטפל בשתי התקופות באותו קובץ.
כמה עבודה זה בפועל?
רוב הזמן נשרף על הנתונים ולא על הקוד: ניקוי מספרי עוסק של לקוחות, נרמול תאריכים, והחלטה מה קורה כשאין תשובה. החיבור עצמו הוא בקשת HTTP אחת עם הזדהות. הדוח החריגים על הנתונים הקיימים הוא שקובע את לוח הזמנים.
להמשך קריאה
שירות רלוונטי
הצלת מערכות אקסס ואקסל
לייצב את הקובץ שהעסק רץ עליו, ואז לתקן אותו או להעביר אותו לווב.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.