המערכת הישנה לא יודעת להפיק מבנה אחיד. מה בדיוק צריך לבנות - תיקיית OPENFRMT, שני קבצים ופלטי אימות - ואיך בודקים את הקובץ בסימולטור לפני שמוסרים אותו.
עיקרי הדברים
- התיקון להוראות ניהול פנקסי חשבונות פורסם ב-2 באוגוסט 2006, ומועד תחילתו נקבע ל-1 בינואר 2008.
- הפלט הוא תיקייה בשם `OPENFRMT` על הכונן שהמשתמש בוחר, ובתוכה תת-תיקיות לפי מספר העוסק, שנה ומועד ההפקה.
- לפי מסמכי ההדרכה של רשות המסים, האופציה להפקה צריכה להיות במרחק צעד אחד לכל היותר מהתפריט הראשי.
- המודול לא מסתיים בכתיבת הקובץ: נדרשים גם פלטים מודפסים לאימות הנתונים מול המערכת.
- סימולטור בדיקת הקבצים מקבל קובץ בנפח של עד כ-1MB ומחזיר פלט מסכם.
כשמערכת ישנה לא כוללת מודול ייצוא, בונים שכבת הפקה חיצונית שקוראת את הנתונים מבסיס הנתונים המקורי וכותבת את שני הקבצים לפי המפרט. הפתרון אינו לכתוב שורות ביד: זה תהליך חוזר עם מיפוי שדות מתועד, פלטי אימות ובדיקה בסימולטור של רשות המסים לפני מסירה.
מה בדיוק צריך להיווצר בסוף התהליך
בסיום הפקה תקינה נוצרים שני קבצים באותה תיקייה. INI.TXT הוא הקובץ המוביל: הוא נפתח ברשומה בקוד A000 ומרכז את פרטי בית העסק והתוכנה שהפיקה, ואחריה רשומות סיכום - לכל סוג רשומה שקיים בקובץ הנתונים תופיע שורת סיכום עם ספירת התנועות שלו. BKMVDATA.TXT הוא קובץ הנתונים: הוא נפתח ברשומת A100, נסגר ברשומת Z900, וביניהן רשומות הנתונים עצמן.
הרשומה המרכזת ב-INI.TXT היא המקום שבו נופלות הכי הרבה מערכות ביתיות, כי היא דורשת נתונים שאין להם מקור בבסיס הנתונים העסקי - קבוע מערכת בערך &OF1.10&, מספר רישום התוכנה, שם התוכנה ומהדורתה, מספר העוסק של יצרן התוכנה, סוג התוכנה וסוג הנהלת החשבונות. אלה פרטים על הכלי שמפיק, לא על העסק.
איך נראית תיקיית הפלט
הקבצים לא נשמרים לאן שנוח. המבנה קבוע: תיקייה בשם OPENFRMT מתחת לספריית השורש של הכונן שהמשתמש בחר בזמן ההפעלה, ובתוכה תת-תיקייה שמשלבת את מספר העוסק ואת השנה, ומתחתיה תת-תיקייה שמסמנת את מועד ההפקה בפורמט של יום, חודש, שעה ודקה.
המשמעות המעשית: כל הפקה יושבת בתיקייה נפרדת ואף פעם לא דורסת קודמת. זה נשמע כמו פרט טכני שולי, אבל זה בדיוק מה שמאפשר להפיק שוב אחרי תיקון נתון במקור בלי לאבד את הגרסה שכבר נמסרה. את סדר התווים המדויק של תיקיית התאריך יש לקחת מהמהדורה העדכנית של ההוראות - הוא הופיע בשתי צורות במסמכי הדרכה שונים.
האם מותר להמשיך לעבוד עם מערכת שלא מפיקה מבנה אחיד?
זו שאלה לרואה החשבון, לא למפתח. מה שכן ניתן לומר עובדתית: בהודעת מנהל רשות המסים נקבע שמ-1 בינואר 2008, תוכנה לניהול מערכת חשבונות ממוחשבת שאינה רשומה במרשם ואינה מפיקה קבצים במבנה האמור תיראה ככזו שאינה עונה על דרישות ההוראות לניהול פנקסי חשבונות.
זה תיאור טכני ולא ייעוץ מס או חשבונאות. את המשמעות למקרה ספציפי - עסק, סוג המערכת, היקף הפעילות - יש לברר מול רואה החשבון ומול המקור הרשמי.
מה המודול חייב לעשות מעבר לכתיבת הקובץ
מסמכי ההדרכה מגדירים גם פלטים לאימות נתונים, ואלה בדיוק החלק ששוכחים כשבונים סקריפט ייצוא מאולתר:
- פלט חזותי לחתך התאריכים שהופק. במערכת שכוללת מודול הנהלת חשבונות - מאזן בוחן תנועות.
- דוח שיכלול לגבי כל אחד מסוגי המסמכים את כמות המסמכים ואת הסך הכספי שלהם. מסמך שאינו מנוהל על ידי התוכנה - ממלאים בו אפס.
- פלט סיום. מספר העוסק, שם בית העסק, הודעה שהממשק הפתוח הסתיים בהצלחה, הנתיב שבו נשמרו הנתונים וטווח התאריכים שהופק.
הפלט השני הוא כלי הבקרה האמיתי: הזמנה שמוצגת עם 120 מסמכים וסכום, מול תעודת משלוח שמוצגת עם כמות בלבד וסכום אפס, אומרת בבירור מה המערכת מנהלת ומה לא - עוד לפני שמישהו פותח את הקובץ.
איך מוציאים נתונים ממערכת ישנה בלי לשבור אותה
- עובדים על עותק. גיבוי או צילום מצב של בסיס הנתונים, לא על הקובץ החי.
- קוראים בשאילתות בלבד. שכבת ההפקה לא כותבת שום דבר חזרה למערכת המקור.
- כותבים מיפוי מפורש: איזו טבלה ואיזה שדה מזינים כל שדה ברשומה. המיפוי הוא מסמך, לא הערה בקוד.
- מייצרים דוח חריגים לפני הכתיבה - מסמכים בלי שורות, לקוחות בלי מזהה, תאריכים מחוץ לטווח.
- מפיקים מחדש אחרי כל תיקון במקור, במקום לערוך את הפלט.
מערכות Access ותיקות מוסיפות שכבת קושי משלהן: קידוד עברית, שדות תאריך שנשמרו כטקסט חופשי ומספרי מסמך שאינם רציפים. כל אחד מהם מייצר קובץ שנראה תקין ונופל בקליטה. אם המערכת הישנה גם בדרך החוצה, כדאי לקרוא את תוכנית מעבר ממערכת Access למערכת ווב לפני שמשקיעים בשכבת ייצוא שתיזרק.
איך יודעים שהקובץ תקין לפני שמוסרים אותו?
מעבירים אותו בסימולטור בדיקת הקבצים של רשות המסים. הסימולטור מדמה את תהליך קליטת הקבצים ומחזיר משוב על התאמת מבנה הקבצים למפרט, ומפיק בסיום פלט מסכם המתאר את תוצאת הבדיקה. הוא מקבל קובץ בנפח של עד כ-1MB, ולכן בודקים בו חתך תאריכים מייצג ולא את כל ההיסטוריה.
| שלב | מה בודקים | מה עושים בכישלון |
|---|---|---|
| לפני ההפקה | דוח חריגים על נתוני המקור | מתקנים במערכת המקור |
| אחרי ההפקה | הפלטים המודפסים מול המערכת | מאתרים את סוג המסמך החסר |
| לפני מסירה | פלט הסימולטור | מתקנים במיפוי, מפיקים מחדש |
| מסירה | הקובץ + הפלטים | שומרים עותק של התיקייה כפי שנמסרה |
מה בעצם מוסרים, ולמי
הבקשה מגיעה כמעט תמיד מאחד משלושה מקומות, וזהות המבקש קובעת את הפרמטרים. רואה החשבון מבקש חתך תקופה לצורך ביקורת או סגירת שנה. מבקר מטעם רשות המסים מבקש את הקובץ במסגרת ביקורת מערכות מידע. בית תוכנה חדש מבקש אותו כחלק ממעבר מערכות, ואז מה שמעניין הוא דווקא השלמות של רשומות הפריטים והכרטיסים ולא רק המסמכים.
לפני שמריצים הפקה ראשונה, שלושה נתונים צריכים להיות סגורים: מספר העוסק שעבורו מפיקים, טווח התאריכים או שנת המס, והכונן שאליו נשמר הפלט. אלה בדיוק הפרמטרים שהמודול מבקש, והם לא ניחוש - הם מגיעים ממי שביקש את הקובץ. הפקה עם טווח שגוי מייצרת קובץ תקין מבחינה טכנית שאף אחד לא יכול להשתמש בו.
הקשר בין הקובץ לבין רישום התוכנה
אם הכלי שבניתם מיועד גם לשימוש של אחרים ולא רק לעסק שלכם, נכנס לתמונה נושא נוסף לגמרי - מרשם התוכנות. הפרטים על התוכנה שנכתבים ל-INI.TXT, ובראשם מספר הרישום, מגיעים משם. מה זה אומר בפועל מפורט בתוכנה רשומה ברשות המסים, ורקע כללי על תוכן הקובץ עצמו נמצא במבנה אחיד: מהו קובץ BKMVDATA.
מקורות
שאלות נפוצות
אפשר פשוט לייצא לאקסל ולהמיר לפורמט?
לא בצורה שמחזיקה לאורך זמן. ייצוא לאקסל מציג את מה שהמסך מציג, ואילו הקובץ דורש רשומות שלמות כולל קשרי מסמך-שורה ורשומות סיכום. המרה חד-פעמית תעבור אולי פעם אחת, ותישבר בחודש הבא כשמישהו ישנה עמודה.
כמה זמן לוקח לבנות שכבת הפקה למערכת ישנה?
זה תלוי כמעט לגמרי במיפוי, לא בכתיבה. אם מבנה הנתונים מתועד וסוגי המסמכים ברורים, החלק ההנדסי קצר. רוב הזמן נשרף על בירור מה כל שדה במערכת הישנה באמת מכיל ומה הוחלף במשמעות לאורך השנים.
צריך להפיק את כל ההיסטוריה בבת אחת?
ההפקה מתבצעת לפי פרמטרים: מספר עוסק, כונן יעד וטווח תאריכים או שנת מס. אפשר להפיק חתך. לסימולטור ממילא מעלים חתך בגלל מגבלת הנפח, ואת הטווח שנדרש למסירה בפועל קובע מי שביקש את הקובץ.
מה עושים כשהקובץ נדחה ולא ברור למה?
שומרים את פלט הסימולטור, את הפלטים המודפסים ואת התיקייה כפי שנוצרה, ומשווים את ספירת התנועות ברשומות הסיכום מול הספירה בפועל בקובץ הנתונים. פער בספירה הוא הכשל הנפוץ ביותר, והוא מצביע על שלב המיפוי ולא על הקובץ.
להמשך קריאה
שירות רלוונטי
הצלת מערכות אקסס ואקסל
לייצב את הקובץ שהעסק רץ עליו, ואז לתקן אותו או להעביר אותו לווב.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.