לחבר ERP ישראלי לכל מערכת אחרת: ההחלטות שלפני הקוד

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

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

שאלה 1: מי הבעלים של כל שדה

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

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

החלוקה שעובדת:

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

שאלה 2: איפה נקודת המסירה

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

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

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

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

שאלה 3: מה באמת דחוף

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

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

שאלה 4: דחיפה או תשאול

ההבדל תלוי במערכת. לפריוריטי יש מנגנון webhooks מובנה דרך כללי BPM - עם הסתייגויות: נדרש רישיון מודול, אין retry מתועד, ויומן השגיאות נשמר 7 ימים. ב-SAP Business One המודל הרווח הוא תשאול.

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

ובכל מקרה: תהליך התאמה יומי

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

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

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

שלושה דברים שחייבים להיות בכל אינטגרציה כזו

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

ההתאמה שהיא כל העבודה: זהויות

זה החלק היקר, והוא לא נראה עד שהוא מתפוצץ.

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

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

מה שמייחד את ההקשר הישראלי

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

סדר עבודה

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

ואם למערכת שלך אין API בכלל - ראה לתוכנה שלי אין API, מה עכשיו.