01 מי מריץ את הצמד הזה
WooCommerce היא חנות המכירה בפועל: מוצרים, עגלה, תשלום, לקוח שגולש ומזמין. Priority היא ה-ERP שמאחורי הקלעים: מלאי אמיתי, מחירונים, הזמנת רכש, ייצור, חשבוניות. אצל יבואנים וקמעונאים בישראל שמריצים גם חנות אונליין וגם ערוץ מכירה סיטונאי או פיזי, זה הצמד שקובע אם המלאי שמוצג באתר תואם את מה שבאמת יש במחסן.
הבעיה הקלאסית: הזמנה נכנסת באתר, ומישהו פותח את Priority בבוקר ומקליד אותה ידנית כדי שהמחסן יידע לארוז. בינתיים מוצר שאזל במחסן עדיין מוצג כ'במלאי' באתר, כי אף אחד לא סנכרן את המספר בזמן.
02 חמש זרימות שכדאי לסנכרן
ההיקף כאן טבעי לחלק לפי כיוון: מה שיוצא מהחנות פנימה, ומה שחוזר מה-ERP החוצה.
- הזמנה שהושלמה ב-WooCommerce נפתחת כהזמנת לקוח ב-Priority: פרטי לקוח, פריטים, כמויות וסכום עוברים אוטומטית ברגע שהתשלום אושר, כדי שהמחסן יתחיל להכין משלוח בלי המתנה להקלדה ידנית
- מלאי מ-Priority מתעדכן בחנות במחזורים תכופים: כשכמות פריט במחסן יורדת מתחת לסף, החנות מציגה 'עומד להיגמר' או יורדת אוטומטית מ'זמין', כדי שלא נמכר מה שאין
- מחיר ומבצעים מ-Priority דוחפים למחיר המוצג ב-WooCommerce: מחירון מתעדכן ב-ERP והחנות עוקבת, לא ההפך, כך שאין פער בין מה שהלקוח רואה למה שבאמת ייגבה
- חשבונית או קבלה (חשבונית ירוקה) מופקת אוטומטית עם השלמת ההזמנה: דרך iCount או ספק חשבונית ירוקה מקביל שמחובר גם ל-WooCommerce וגם, במקרים רבים, מוזן חזרה כמסמך תואם ב-Priority, כדי שהנהלת החשבונות לא מפיקה מסמכים כפולים
- סטטוס משלוח חוזר מה-ERP או מחברת השילוח לחנות ומוצג ללקוח: מספר מעקב ועדכון סטטוס מופיעים בהזמנה ב-WooCommerce, כדי שהלקוח לא כותב 'איפה החבילה שלי' לשירות הלקוחות
03 איך זה נבנה בפועל
WooCommerce חושפת REST API רשמי עם Consumer Key/Secret לאימות, וגם webhooks על אירועי הזמנה (order.created, order.updated) שמאפשרים לתפוס הזמנה חדשה כמעט ברגע שהיא נסגרת, בלי לבדוק כל כמה דקות אם משהו חדש נכנס. Priority, בצד השני, נגישה דרך API מבוסס OData עם Basic Auth וכותרות רישוי, מאורגנת לפי טפסים כמו ORDERS ליצירת הזמנת לקוח.
כיוון הבעלות: מלאי אמיתי ומחיר רשמי, Priority בעלים, WooCommerce קורא ומציג בלבד. פרטי הזמנה ולקוח שנוצרו בקנייה, WooCommerce הוא המקור, ו-Priority קולט. ברגע שהזמנה קיימת בשתי המערכות, שינויים בסטטוס משלוח יכולים לזרום משני הכיוונים, אבל רק דרך כלל מוגדר מראש.
תזמון: קליטת הזמנה חדשה חייבת להיות event-driven דרך webhook, כל עיכוב פה מעכב את המחסן. עדכון מלאי יכול לרוץ כל כמה דקות עד כמה פעמים ביום, תלוי בנפח המכירות ובכמה קריטי למנוע 'oversell'. עדכון מחיר וקטלוג בדרך כלל מספיק פעם ביום או בלילה.
ספציפית לישראל: שדה מע״מ צריך להיות מפורש בכל שורת הזמנה (המחיר באתר כולל מע״מ, ובחשבונית צריך לפרק נכון), וחיבור לחשבונית ירוקה או iCount הוא בדרך כלל רכיב נפרד בזרימה, לא חלק מ-Priority עצמה. צריך להחליט אם ה-ERP מפיק את המסמך הפיסקאלי או שהחשבונית מופקת בצד ה-e-commerce ומוזנת בחזרה. אישור אנושי חובה על כל שינוי מחיר גורף וכל ביטול הזמנה שכבר יצא לו מסמך חשבונאי, זה לא רץ לבד.
04 מה בדרך כלל משתבש
התקלות הכי נפוצות בצמד הזה, כולל שתיים שספציפיות לישראל:
- SKU כפול או לא תואם בין המערכות: אם מק״ט המוצר ב-WooCommerce לא זהה בול למק״ט ב-Priority (רווח מיותר, אותיות גדולות/קטנות, גרסה ישנה), הסנכרון פשוט לא מוצא את הפריט המתאים ומדלג עליו בשקט
- קטלוג מיושן בשני הכיוונים: אם עדכון המלאי רץ פעם ביום בלבד וקצב המכירות גבוה, החנות מוכרת פריטים שכבר אזלו במחסן שעות לפני שהמספר מתעדכן, 'oversell' שדורש ביטול הזמנה ידני מול לקוח מתוסכל
- שדה מע״מ לא עקבי: מחיר באתר כולל מע״מ, אבל אם ההזמנה עוברת ל-Priority בלי סימון מפורש שהמחיר כולל מע״מ, המסמך החשבונאי שיוצא שגוי. צריך כלל מיפוי מפורש, לא ברירת מחדל
- חשבונית כפולה: אם גם תוסף החשבונית הירוקה בחנות וגם Priority מנסים להפיק מסמך פיסקאלי לאותה הזמנה בלי תיאום מי הבעלים של הפעולה, הלקוח מקבל שתי חשבוניות על אותה עסקה
- כשל שקט ב-webhook: אם WooCommerce שולח webhook והשרת בצד הקולט לא זמין לרגע, ההזמנה פשוט לא מגיעה ל-Priority ואף אחד לא שם לב עד שהלקוח מתקשר לשאול איפה החבילה. לכן צריך תור עם ניסיון חוזר (retry) והתראה על כשל, לא רק קריאה חד-פעמית
05 מה בדרך כלל משתבש (וכדאי לדעת מראש)
- התיאור מתאר דפוסי אינטגרציה כלליים; שמות טפסים מדויקים ב-Priority ומבנה ה-webhooks תלויים בגרסה ובתצורת ה-tenant, ונבדקים בשלב האפיון.
- חשבונית ירוקה/iCount מתואר כרכיב נפרד בזרימה ולא כחלק מ-Priority עצמה. צריך לאמת מול התוסף/ספק הספציפי איזה צד מפיק את המסמך הפיסקאלי כדי למנוע כפילות.
- סנכרון מלאי בזמן אמת (למניעת oversell) דורש תדירות גבוהה יותר ומורכבות rate-limit גבוהה יותר מסנכרון קטלוג ומחיר. אלה שני היקפי עבודה שונים ולא כדאי להניח שהם אותו דבר.
לפני שבונים, בודקים איפה בדיוק ה-SKU נשבר בין המערכות
שיחת היכרות של 20 דקות. סורק התפעול (₪4,900, שבועיים) מסתיים באוטומציה עובדת אחת, והעלות שלו יורדת במלואה מהספרינט אם ממשיכים תוך 60 יום.
לתיאום סריקת תפעול