אינטגרציה בין ERP לאתר מסחר היא אחד הפרויקטים שנראים פשוטים על הנייר ומסתבכים מהר בפועל. “לחבר את המלאי לאתר” נשמע כמו משימה טכנית קטנה, אבל מאחוריו מסתתרות החלטות על בעלות על נתונים, תזמון, טיפול בשגיאות ומה קורה כשמשהו נשבר באמצע הלילה. במדריך הזה נעבור על מה שחשוב להחליט לפני שכותבים את שורת הקוד הראשונה.
אילו נתונים עוברים בין מערכת ה-ERP לאתר המסחר?
ברוב העסקים עוברים בין שתי המערכות שישה סוגי נתונים: מוצרים, מלאי, מחירים, הזמנות, לקוחות וחשבוניות. כל אחד מהם מתנהג אחרת, ולכן צריך לתכנן כל אחד בנפרד ולא “לסנכרן הכול”.
- מוצרים – מק“ט, שם, מאפיינים, וריאציות וקטגוריות. בדרך כלל הנתונים הלוגיסטיים מנוהלים ב-ERP, והתוכן השיווקי והתמונות באתר.
- מלאי – הכמות הזמינה למכירה, לפעמים בפילוח לפי מחסן או סניף.
- מחירים – מחירון בסיס, מחירונים ייעודיים ללקוחות או לקבוצות, מבצעים והנחות.
- הזמנות – נוצרות באתר, ונדרשות ב-ERP לליקוט, למשלוח ולהנהלת החשבונות.
- לקוחות – פרטים וכתובות, ובלקוחות עסקיים גם תנאי תשלום ומסגרות אשראי.
- חשבוניות ומסמכים – מופקים ב-ERP, ולעיתים צריכים להופיע ללקוח באזור האישי באתר.
מי מקור האמת לכל ישות?
לכל ישות צריך להיות מקור אמת אחד: המערכת שבה הנתון נוצר ושבה מותר לערוך אותו. כשההגדרה הזו חסרה, שתי המערכות דורסות זו את זו, ואף אחד כבר לא יודע איזה ערך נכון.
הטבלה הבאה מציגה חלוקה נפוצה. היא נקודת פתיחה לדיון, לא כלל מחייב:
| ישות | מקור אמת נפוץ | כיוון הסנכרון | תזמון מתאים |
|---|---|---|---|
| נתוני מוצר בסיסיים (מק“ט, שם, משקל) | ERP | מה-ERP לאתר | בעת שינוי או בסנכרון מתוזמן |
| תוכן שיווקי ותמונות | אתר המסחר | לא מסונכרן | – |
| מלאי | ERP | מה-ERP לאתר | קרוב ככל האפשר לזמן אמת |
| מחירים ומחירונים | ERP | מה-ERP לאתר | בעת שינוי, עם בדיקת התאמה תקופתית |
| הזמנות | אתר המסחר | מהאתר ל-ERP | מיידי, על בסיס אירוע |
| סטטוס הזמנה ומשלוח | ERP | מה-ERP לאתר | בעת שינוי |
| לקוחות | תלוי במודל העסקי | לרוב חד-כיווני | בעת יצירה או עדכון |
| חשבוניות | ERP | מה-ERP לאתר | לאחר ההפקה |
הישות הרגישה ביותר היא בדרך כלל הלקוח. באתר שמוכר לצרכנים פרטיים הלקוח נולד באתר, ואילו במכירה לעסקים הוא מוקם לרוב ב-ERP יחד עם תנאי האשראי שלו. אם בכל זאת נדרש סנכרון דו-כיווני, הגדירו בעלות ברמת השדה: הכתובת נערכת באתר, תנאי התשלום רק ב-ERP.
סנכרון בזמן אמת או סנכרון מתוזמן?
לא כל נתון צריך לעבור בזמן אמת. השאלה הנכונה היא כמה עולה עיכוב: במלאי ובהזמנות עיכוב עלול לעלות בכסף ובלקוחות, ובתיאור מוצר הוא כמעט לא מורגש.
Webhooks ואירועים
ב-webhook המערכת המקורית שולחת הודעה ברגע שמשהו קורה: הזמנה חדשה, שינוי מלאי, עדכון סטטוס. היתרון הוא מהירות ועומס נמוך, כי לא צריך לשאול שוב ושוב אם יש משהו חדש. החיסרון הוא שהודעות עלולות ללכת לאיבוד, להגיע פעמיים או להגיע בסדר שגוי, ולא כל מערכת ERP יודעת לשלוח אירועים החוצה.
סנכרון מתוזמן (Batch)
בסנכרון מתוזמן תהליך רץ במרווחי זמן קבועים ומושך את כל מה שהשתנה מאז הריצה הקודמת. הוא פשוט, צפוי וקל להתאוששות: אם ריצה נכשלה, הריצה הבאה משלימה את הפער. המחיר הוא עיכוב מובנה.
השילוב שעובד בפועל
הגישה העמידה ביותר משלבת בין השניים: אירועים לנתונים דחופים כמו הזמנות ומלאי, וריצת התאמה (reconciliation) תקופתית שמשווה בין המערכות ומתקנת פערים. ריצת ההתאמה היא רשת הביטחון שתופסת את מה שהאירועים פספסו.
טיפול בשגיאות: תורים, ניסיונות חוזרים ו-idempotency
אינטגרציה טובה מניחה מראש שדברים ייכשלו, ובנויה להתאושש מזה בלי התערבות ידנית ובלי לייצר כפילויות. ה-API לא יענה, הרשת תתנתק, נתון יגיע חסר. השאלה היא רק מה קורה אז.
- תור הודעות (Queue) – כל הזמנה או עדכון נכנסים לתור במקום להישלח ישירות. אם ה-ERP לא זמין, ההודעה ממתינה ולא הולכת לאיבוד.
- ניסיונות חוזרים עם השהיה הולכת וגדלה – לא לנסות שוב מיד בלולאה, אלא לרווח את הניסיונות כדי לא להעמיס על מערכת שכבר מתקשה.
- Idempotency – שליחה חוזרת של אותה פעולה לא יוצרת תוצאה כפולה. בפועל, כל הזמנה נושאת מזהה ייחודי מהאתר, ולפני יצירת מסמך חדש בודקים אם ההזמנה כבר נקלטה.
- תור לכישלונות (Dead letter queue) – הודעה שנכשלה שוב ושוב עוברת לתור נפרד לטיפול ידני, במקום לחסום את כל מה שמאחוריה.
- הבחנה בין שגיאה זמנית לשגיאה קבועה – פסק זמן (timeout) מצדיק ניסיון חוזר. מק“ט שלא קיים ב-ERP לא ייפתר מעצמו, ודורש טיפול של אדם.
ניטור והתראות: איך יודעים שמשהו נשבר?
אם הדרך היחידה לגלות שהאינטגרציה נפלה היא לקוח שמתקשר לברר איפה ההזמנה שלו, אין לכם ניטור. צריך יומן (log) מסודר של כל פעולה, והתראות אוטומטיות על חריגות.
כדאי לעקוב לפחות אחרי:
- הזמנות שנוצרו באתר ולא נקלטו ב-ERP בתוך פרק הזמן שהגדרתם.
- גודל התור. תור שגדל ולא מתרוקן הוא סימן מוקדם לתקלה.
- כמות השגיאות, בחלוקה לפי סוג.
- מועד הסיום המוצלח האחרון של כל סנכרון מתוזמן.
- פערי מלאי ומחירים שעלו בריצת ההתאמה.
התראה טובה מגיעה לאדם מוגדר, עם מספיק הקשר כדי לפעול: איזו הזמנה, באיזה שלב, ומה הודעת השגיאה. “שגיאה 500” לבדה לא עוזרת לאף אחד.
הטעויות הנפוצות באינטגרציה בין ERP לאתר מסחר
רוב התקלות באינטגרציות כאלה חוזרות על עצמן, וכמעט כולן ניתנות למניעה כבר בשלב התכנון.
מכירת יתר (Overselling)
המלאי באתר מתעדכן באיחור, ושני לקוחות קונים את אותו פריט אחרון. הפתרון משלב עדכון מלאי מהיר לפריטים רגישים, מלאי ביטחון (הצגת כמות נמוכה מהכמות בפועל) ושריון מלאי ברגע שההזמנה נקלטת.
הזמנות כפולות
כמעט תמיד הן תוצאה של ניסיון חוזר בלי idempotency. אותו webhook שנשלח פעמיים הופך לשתי הזמנות ב-ERP, ולפעמים גם לשני משלוחים.
פערי מחירים
המחיר באתר שונה מהמחיר ב-ERP כי מבצע הוגדר רק במערכת אחת, כי העיגול שונה, או כי מערכת אחת עובדת עם מחירים כולל מע“מ והשנייה בלי. החליטו מראש איפה מנוהלים מבצעים ואיך מטופל המע”מ בכל צד.
מיפוי מק“טים
מוצר אחד באתר יכול להתאים לכמה פריטים ב-ERP, למשל בערכות ובמארזים. וריאציות של מידה וצבע מנוהלות לא פעם אחרת בכל מערכת, ולפעמים אותו מק“ט פשוט נכתב אחרת, עם רווח, מקף או אותיות גדולות. טבלת מיפוי מלאה לפני הפיתוח חוסכת הרבה תקלות אחרי העלייה לאוויר.
צ’קליסט לפני שמתחילים
לפני שמתחילים לפתח, כדאי לענות בכתב על השאלות הבאות. מסמך כזה מונע ויכוחים בהמשך ומשמש בסיס לבדיקות, ואצלנו ב-SYNCA כל פרויקט אינטגרציה מתחיל ממנו.
- האם למערכת ה-ERP יש API מתועד, ומה המגבלות שלו: קצב בקשות, הרשאות, סביבת בדיקות?
- מי מקור האמת לכל ישות, ולכל שדה שנערך בשתי המערכות?
- מה התדירות הנדרשת לכל סוג נתון, ומה המחיר העסקי של עיכוב?
- איך מזוהה כל מוצר בשתי המערכות, והאם המק“טים כבר תואמים?
- איך מטופלים מע“מ, עיגולים, מטבעות ומחירונים ללקוחות שונים?
- מה קורה כשהזמנה נכשלת: מי מקבל התראה, ומה התהליך הידני?
- האם יש סביבת בדיקות שבה אפשר ליצור הזמנות בלי לגעת בהנהלת החשבונות האמיתית?
- מי אחראי על האינטגרציה אחרי העלייה לאוויר?
בשורה התחתונה
אינטגרציה בין ERP לאתר מסחר היא לא “חיבור” אלא מערכת בפני עצמה. הגדירו מקור אמת לכל ישות, התאימו את תדירות הסנכרון למחיר העיכוב, בנו מנגנון שמתאושש משגיאות בלי ליצור כפילויות, ודאגו לדעת על תקלה לפני שהלקוח יודע עליה. רוב העבודה החשובה קורית עוד לפני שכותבים קוד.