מה למדנו מרישום תוכנה ברשות המסים

מה בעצם רושמים

הרישום נעשה לפי הוראה 36 ונספח ה׳ להוראות מס הכנסה (ניהול פנקסי חשבונות). רושמים תוכנה מסוימת, במהדורה מסוימת, כ״תוכנה לניהול מערכת חשבונות ממוחשבת״. התעודה של BillOS, מספר 269101, הונפקה ב-23 ביולי 2026 למהדורה 1.0, ותוקפה עד 31 ביולי 2028. התעודה עצמה מוצגת כאן.

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

מה מגישים

הבקשה מוגשת במערכת מקוונת של הרשות. מה שצירפנו:

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

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

המבנה האחיד: רשומות ברוחב קבוע

המבנה האחיד הוא הפורמט שבו תוכנה מוסרת את הספרים לרשות המסים בביקורת. שני קובצי טקסט, INI.TXT ו-BKMVDATA.TXT, שבהם כל רשומה היא שורה ברוחב קבוע: סוג הרשומה, ואחריו שדות במיקומים קבועים, בקידוד עברית ISO-8859-8 ובסוף שורה של CRLF. כותרת מסמך היא רשומה אחת, כל שורת פירוט היא רשומה, כל תקבול הוא רשומה.

שלושה דברים שעלו לנו בזמן:

את טבלאות השדות מעתיקים בעיניים

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

בודקים בייטים, לא מחרוזות

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

הקובץ צריך להיות גדול מספיק

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

הסימולטור, והשדה שאי אפשר למלא

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

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

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

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

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

מה הרישום מחייב אחר כך

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

מספרי הקצאה הם תהליך נפרד

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

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

ואם לא רוצים לעבור את כל זה

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