אוטומציה מול חשבשבת: מה לברר לפני שמבטיחים משהו

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

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

למה זה שונה ממערכת ענן

מערכת חשבוניות בענן - Morning, iCount, EZcount, רווחית - היא שירות אחד עם ממשק אחד. יש כתובת, יש תיעוד, וכל הלקוחות מקבלים את אותו דבר.

חשבשבת מגיעה מעולם אחר. המשמעות:

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

המסקנה: "האם לחשבשבת יש API" היא שאלה שאין לה תשובה אחת. השאלה הנכונה היא "מה יש בהתקנה הזו".

שלוש השאלות לשאול - בכתב

לפני כל הערכה, לספק או לאיש חשבשבת של הלקוח:

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

בכתב, כי בעוד שנה מישהו ישאל למה בנינו את זה ככה.

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

אם אין ממשק מתאים - מה כן עובד

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

ייצוא מתוזמן - התשובה ברוב המקרים

המערכת יודעת לייצא. אתה קולט את הקובץ ומעבד אותו.

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

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

קריאה ישירה מהמסד - לדוחות בלבד

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

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

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

תיקייה משותפת

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

אוטומציית ממשק - מוצא אחרון

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

מה שנשאר נכון בכל מקרה

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

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

ההחלטות שאינן טכניות

גם אם יש ממשק מושלם, אלה נשארות - והן העלות האמיתית:

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

סיכום מעשי

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