חיבור חנות אונליין ל-ERP: Shopify ו-WooCommerce מול פריוריטי, SAP B1 וחשבשבת

התבנית תמיד זהה. החנות רצה על Shopify או WooCommerce. העסק רץ על פריוריטי, SAP Business One או חשבשבת. ביניהם יושב אדם עם שתי לשוניות בדפדפן, שמעתיק פרטי הזמנה מאחת לשנייה. ב-20 הזמנות ביום זה מעצבן. ב-200 זו משרה מלאה שמייצרת שגיאות הקלדה בכתובות ולקוחות וחשבוניות עם מע"מ שגוי.

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

אלה ארבע אינטגרציות, לא אחת

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

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

קודם כל - מי המאסטר

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

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

הסטאק הישראלי בפועל

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

SAP Business One חושף את ה-Service Layer (OData). יכולתי ומובנה היטב, אבל כבד יותר: סשנים, מודלי אובייקטים נוקשים יותר, וטיפול בשגיאות פחות סלחני. צפו ליותר זמן בצד ה-ERP מאשר בצד החנות.

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

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

החלקים שמדלגים עליהם

אידמפוטנטיות

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

תור השגיאות

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

התראות

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

כשלים חלקיים

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

כמה זה עולה

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

תתחילו מהזמנות בלבד

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

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

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