סנכרון מלאי לא תקין בין Shopify למחסן כמעט אף פעם לא נפתר רק באמצעות לחיצה נוספת על כפתור ״סנכרון״. השאלה החשובה היא איזו מערכת אחראית על כל כמות, איזה סוג מלאי אנחנו משווים ומה קורה כשהעדכון מגיע פעמיים, באיחור או לא מגיע בכלל.
כשחנות Shopify עובדת מול מחסן חיצוני, מערכת WMS, ERP או אוטומציה, תקלה יכולה להתבטא במכירת יתר, במוצרים שחסרים באתר למרות שיש אותם במחסן, בניתוב הזמנות למיקום לא נכון או בפערים בין דוחות.
המדריך הזה מיועד למנהלי חנויות ולמפתחים שרוצים להבין את הבעיה לפני שמתקינים עוד אפליקציה.
קודם כול: משווים את הכמות הנכונה
ב־Shopify יש מצבי מלאי שונים לכל מיקום:
-
On hand: כלל היחידות הרשומות במיקום.
-
Available: יחידות הזמינות למכירה.
-
Committed: יחידות שהוקצו להזמנות ולא זמינות למכירה חוזרת.
-
Unavailable: יחידות שנשמרו או הוצאו זמנית ממכירה.
-
Incoming: מלאי בדרך שעדיין לא התקבל.
אם המחסן מדווח על הכמות הפיזית שעל המדף והאינטגרציה כותבת אותה לשדה Available, עלול להיווצר פער גם כששתי המערכות מציגות מספרים נכונים לפי ההגדרות שלהן.
לכן מתחילים מהשוואת אותו מוצר, אותו מיקום, אותה נקודת זמן ואותו מצב מלאי. אפשר להיעזר בהסבר הרשמי של Shopify על מצבי מלאי.
שש סיבות נפוצות לפערי מלאי
1. העדכון מגיע למיקום הלא נכון
לחנות יכולים להיות מחסן חיצוני, משרד, חנות פיזית ומרכז לוגיסטי, וכל אחד מהם מוגדר כמיקום נפרד ב־Shopify. העדכון יכול להצליח טכנית, אך לעדכן מיקום שממנו כלל לא נמכר המוצר באתר.
מה בודקים: מזהה פריט מלאי, מזהי המיקומים, הגדרות Fulfillment וההתאמה למיקומים של המחסן. לא מניחים שסך המלאי בכל המיקומים הוא הכמות הזמינה בקופה.
2. התאמת המוצרים לפי SKU שגויה
SKU הוא כלי חשוב, אבל לא תמיד הוא קיים או ייחודי. לפעמים מארז, וריאנט או מוצר מיובא מקבלים אותו SKU.
מה בודקים: מיפוי מדויק ויציב בין מוצר המחסן לבין Inventory Item ומיקום ב־Shopify. מזהים במפורש מוצרים לא תואמים וכפילויות, ולא מנחשים מהו ה־SKU הקרוב ביותר.
3. ההזמנה משנה את מצב המלאי עוד לפני השילוח
הזמנה יכולה להעביר יחידות ל־Committed בזמן שהמחסן עדיין מציג ״ממתין לליקוט״. סטטוסים כמו ״הודפס״, ״באריזה״ ו״נשלח״ אינם זהים לסגירת תהליך מלאי.
מה בודקים: מסלול של מספר הזמנות מייצגות, מהקבלה ועד לשילוח. מבררים איזו מערכת משנה מלאי ובאיזה שלב.
4. ניסיון חוזר מבצע את אותה פעולת מלאי פעמיים
Webhooks יכולים להגיע שוב, ואוטומציה יכולה לבצע Retry אחרי Timeout. אם הפעולה היא הורדה של שתי יחידות, הרצה כפולה עלולה להוריד ארבע.
מה בודקים: מזהה אירוע קבוע, שמירת תוצאות עיבוד, טיפול בכפילויות ו־Idempotency. בגרסאות GraphQL API החדשות של Shopify קיימות דרישות Idempotency לפעולות מלאי; לפני פיתוח יש לבדוק את תיעוד הגרסה הרלוונטית.
5. שתי מערכות חושבות שהן מקור האמת
מערכת המחסן שולחת כמות ל־Shopify, ואפליקציה אחרת מעדכנת את המחסן לפי Shopify. בלי כללי בעלות, העדכון האחרון יכול לדרוס מידע תקין.
מה בודקים: מגדירים מי אחראי על ספירה פיזית, מי על הזמנות, מי על החזרות ומי על שמירת מלאי — לכל מיקום ולכל סוג פעולה.
6. התהליך נכשל בשקט
גם מערכת שמשתמשת ב־Webhooks יכולה להיתקל בתקלה אצל ספק חיצוני, בהרשאות API שהשתנו או בעדכון שלא יושם בפועל. Run שמסומן כ״הצליח״ לא בהכרח מוכיח שכל המערכות התעדכנו.
מה בודקים: יומני שגיאות, פעולות שנתקעו, הודעות שלא עובדו, התראות על פערים והשוואה תקופתית של פריטי מלאי. לכל חריגה צריך להיות בעל אחריות ונתיב תיקון.
צ׳קליסט אבחון של 30 דקות
| שאלה | מה לאסוף | למה זה חשוב |
|---|---|---|
| איזה מוצר? | SKU, Variant ID, Inventory Item ID | זיהוי מדויק |
| איזה מיקום? | Shopify Location ומיקום המחסן | מניעת השוואה שגויה |
| איזה מצב מלאי? | Available, Committed, On hand | השוואת אותה כמות |
| מתי נוצר הפער? | נקודת הזמן האחרונה שבה הייתה התאמה | צמצום טווח הבדיקה |
| מה השתנה? | הזמנות, החזרות, קבלות, העברות | איתור שינוי לגיטימי |
| האם הפעולה הושלמה? | Webhook, Run, תגובת API ואישור המחסן | הבחנה בין קבלה ליישום |
| אפשר להריץ שוב? | מזהה פעולה ו־Idempotency | מניעת פער חדש |
אפשר להתחיל מחמישה פריטים: מוצר שנמכר הרבה, מוצר עם מלאי נמוך, מוצר במספר מיקומים, מוצר עם וריאנטים או מארז ומוצר שהייתה בו החזרה לאחרונה. לא מבצעים תיקון גורף לפני שמבינים את דפוס התקלה.
אפליקציה מוכנה, Make או פיתוח מותאם?
מעדיפים פונקציונליות מובנית של Shopify כשהיא פותרת את הבעיה. אפליקציית אינטגרציה קיימת מתאימה כאשר יש תמיכה אמינה במערכת החיצונית וכלי בקרה טובים. Make יכול להתאים לתהליכים ממוקדים שאפשר לנטר ולשחזר. פיתוח מותאם מוצדק כשיש מיפוי מורכב, ניתוב הזמנות, התאמות מלאי או דרישות אמינות מיוחדות.
בבחירה צריך לחשב לא רק את עלות המנוי, אלא גם זמן טיפול בתקלות, מגבלות API, ניטור ותחזוקה.
איך נראית אינטגרציה שאפשר לסמוך עליה?
פתרון טוב כולל מקור אמת מוגדר, מיפוי פריטים ומיקומים, מנגנון למניעת כפילויות, תיעוד פעולות, תור שגיאות, בדיקות התאמה ודרך ברורה לטיפול אנושי בחריגות.
אם כבר קיימים פערי מלאי, אפשר להתחיל בסקירה מקצועית ממוקדת של החנות כדי לזהות מה חשוב לבדוק קודם. לפתרונות מורכבים יותר, ראו את שירותי Shopify B2B ואינטגרציות. נבחן את המערכת הקיימת ואת האילוצים שלה לפני שנציע כלי נוסף או בנייה מחדש.
מקורות טכניים: מצבי מלאי ב־Shopify, מלאי לפי מיקום ומוטציות מלאי ב־GraphQL. יש לוודא גרסת API והרשאות לפני שינוי מלאי בחנות פעילה.
