לא איזו פלטפורמה טובה יותר, אלא איפה המלאי זז, מי רואה את השינוי, ואיפה התוכן והנתונים באמת יושבים. השוואה לפי מכונת המצבים המתועדת של כל צד.
עיקרי הדברים
- ב-WooCommerce התיעוד קובע שהמלאי יורד כשההזמנה עוברת ל-Processing, וגם במצב On hold, וחוזר למלאי במצבים Failed ו-Cancelled.
- ב-Shopify המלאי אינו "יורד", אלא עובר בין שמונה מצבים מתועדים, וכשהזמנה נקלטת הכמות עוברת למצב committed.
- שינויים במצבים committed, reserved, damaged, safety_stock ו-quality_control אינם מפעילים webhook. זו נקודה עיוורת שצריך לתכנן סביבה.
- מ-WooCommerce 8.2 אחסון ההזמנות בטבלאות ייעודיות הוא ברירת המחדל בהתקנות חדשות, במקום סוגי פוסטים של וורדפרס.
- אף אחת מהשתיים אינה מפיקה מספר הקצאה לחשבונית או תווית שליחות ישראלית. את זה מספקת מערכת אחרת בכל מקרה.
ההחלטה בין WooCommerce ל-Shopify עבור חנות ישראלית נסגרת על שני דברים: מתי בדיוק המלאי זז בכל פלטפורמה, ואיפה התוכן והנתונים שלכם יושבים פיזית בסוף כל יום. שתי הפלטפורמות מוכרות. הן נבדלות במכונת המצבים ובבעלות.
מה המאמר הזה מכריע, ומה כבר הוכרע במקום אחר
ההשוואה הכללית בין השתיים, לפי קלות הקמה, תחזוקה, עמלות ותוספים, כבר קיימת כאן במלואה ב-Shopify מול WooCommerce. המאמר הזה לא חוזר עליה.
מה שהוא כן עושה: לוקח הזמנה אחת ועוקב אחריה בשתי הפלטפורמות, ברמת האירוע המתועד. הסיבה היא שרוב הכאב התפעולי בחנות ישראלית לא נובע מהפלטפורמה עצמה אלא מהתפר בינה לבין המחסן, ההנהלת חשבונות והשליח. התפר הזה מתנהג לפי מכונת המצבים, ולא לפי רשימת התכונות.
איפה בדיוק המלאי זז בכל פלטפורמה?
| האירוע | WooCommerce, לפי התיעוד | Shopify, לפי התיעוד |
|---|---|---|
| הזמנה נוצרה וטרם שולמה | מצב Pending payment. המלאי לא הופחת | הכמות עוברת למצב committed כשההזמנה נקלטת |
| התקבל תשלום | מצב Processing: "Payment has been received (paid), and the stock has been reduced" | הכמות נשארת committed עד לאספקה |
| תשלום שממתין לאישור ידני | מצב On hold: "Stock is reduced, but you need to confirm payment" | לא מוגדר כמצב מלאי נפרד |
| ההזמנה נכשלה | מצב Failed. אם המלאי הופחת קודם, הוא מוחזר | תלוי בפעולה שמבצעת האפליקציה |
| ההזמנה בוטלה | מצב Cancelled. המלאי חוזר אם ניהול מלאי פעיל | תלוי בפעולה שמבצעת האפליקציה |
| סחורה בדרך מהספק | אין מצב ייעודי בתיעוד המצבים | מצב incoming, המצב היחיד שאינו נמצא פיזית במחסן |
| פריט פגום או בבדיקת איכות | אין מצב ייעודי בתיעוד המצבים | מצבים damaged ו-quality_control, שניהם מוצגים למוכר כלא זמינים |
| מלאי ביטחון | אין מצב ייעודי בתיעוד המצבים | מצב safety_stock |
שמונת המצבים ב-Shopify הם incoming, on_hand, available, committed, reserved, damaged, safety_stock ו-quality_control, ולפי התיעוד on_hand הוא סכום כל המצבים שנמצאים פיזית במקום.
מה קורה להזמנה שלא שולמה?
זו השורה שהכי מרבה להפתיע בעלי חנויות, כי שתי הפלטפורמות פותרות אותה אחרת לגמרי.
ב-WooCommerce קיימת הגדרה בשם Hold Stock (minutes), בהגדרות המוצרים. התיעוד מציין שהיא חלה על הזמנות במצב Pending payment בלבד, ולא על הזמנות במצב On hold. כשהמגבלה מגיעה, ההזמנה מבוטלת והמלאי משוחרר חזרה. אם ההגדרה ריקה, המנגנון כבוי.
ב-Shopify המנגנון אינו "החזקה לזמן קצוב" אלא מצב. הכמות נמצאת ב-committed, כלומר היא לא זמינה למכירה אבל היא עדיין פיזית במחסן ונספרת ב-on_hand. התיעוד מציין שגם שריון פריטים בהזמנת טיוטה מעביר אותם ל-committed מיד עם השריון. את הגרסה לפי פלטפורמה - Shopify ו-WooCommerce מול פריוריטי, SAP B1 וחשבשבת - ראו בחיבור חנות אונליין ל-ERP.
ההשלכה המעשית לחנות ישראלית עם משלוחים: הספירה ש"נכונה" תלויה בשאלה איזה מספר אתם מסתכלים עליו. מי שמשווה available מול הספירה במחסן ולא לוקח בחשבון את committed, יחשוב שהמערכת שגויה. ראו בקרת סנכרון מלאי בין חנות לאתר.
מי רואה שינוי מלאי, ומי לא
תיעוד Shopify מפרט את נושאי ה-webhook הקיימים למלאי: inventory_items/create, inventory_items/update, inventory_items/delete, inventory_levels/connect, inventory_levels/disconnect ו-inventory_levels/update. ובאותו עמוד מופיעה ההסתייגות החשובה:
- שינויים במצבים committed, reserved, damaged, safety_stock ו-quality_control אינם מפעילים webhook.
מה זה אומר בפועל:
- מערכת חיצונית שמסתמכת רק על webhooks לא תדע שפריט הועבר לבדיקת איכות.
- מערכת שמסנכרנת מלאי צריכה גם משיכה תקופתית, ולא רק האזנה לאירועים.
- הפער הזה מתועד, ולכן הוא ניתן לתכנון. הבעיה מתחילה כשמניחים שה-webhook מכסה הכול.
ב-WooCommerce המקבילה היא hooks של וורדפרס ו-REST API. הפער שם שונה במהותו: מה שמפעיל אירוע תלוי גם בתוספים שמותקנים, ולכן צריך לבדוק אותו בהתקנה הספציפית ולא רק בתיעוד הליבה.
איפה התוכן והנתונים באמת יושבים
ב-WooCommerce הכול יושב בהתקנת וורדפרס שאתם מארחים. התיעוד מתאר שהזמנות נשמרו היסטורית כסוגי פוסטים ו-post meta, ושמנגנון אחסון ההזמנות בטבלאות ייעודיות הפך לברירת המחדל בהתקנות חדשות החל מגרסה 8.2. בשני המקרים מדובר בבסיס נתונים שאתם יכולים לגבות ולשאול ישירות.
ב-Shopify הנתונים יושבים אצל Shopify והגישה אליהם היא דרך ממשקים. זה לא חסרון אוטומטי: ממשק מתועד ויציב לרוב אמין יותר מגישה ישירה לבסיס נתונים שמישהו שינה. זה כן אומר שהתשובה לשאלה "מה יש לנו ביד אם נעזוב" שונה לחלוטין בין השתיים, וכדאי לענות עליה לפני ההשקה ולא אחריה.
הצד המסחרי מתועד גם הוא: Shopify מתעדת אובייקטים בשם Company, CompanyLocation ו-CompanyContact לפעילות בין עסקים, ומחירונים דרך אובייקט PriceList שדורס מחירי ברירת מחדל במחיר קבוע או בהתאמה באחוזים. קטלוג מוצמד לפי התיעוד לסניף של חברה בלבד.
מה שאף אחת מהשתיים לא עושה בישראל
- מספר הקצאה לחשבונית מול רשות המסים. זה נעשה במערכת החשבוניות.
- ייצוא במבנה אחיד לרואה החשבון.
- תווית שליחות של חברת שליחויות ישראלית. ראו דואר ישראל מול שליח פרטי.
- התאמה בין הסכום שנסלק לסכום שהוזמן, שהיא בדיקה בצד השרת בכל מקרה.
- החלטה מי הבעלים של מחיר הפריט כשהוא קיים גם ב-ERP וגם בחנות.
צורת העלות, בלי מספרים
- מה שגדל עם עסקאות. נפח הזמנות מזיז עלות בשתי הפלטפורמות, אך דרך מנגנונים שונים לגמרי.
- מה שגדל עם תוספים. בוורדפרס כל תוסף הוא גם עלות תחזוקה וגם משטח תאימות בכל עדכון.
- מה שגדל עם התאמות בקופה. התאמות בתהליך התשלום הן תמיד קטגוריית העבודה היקרה ביותר.
- מה שגדל עם התשתית. WooCommerce מחייב מישהו שאחראי על אחסון, גיבוי ועדכוני אבטחה.
- מה שנשאר קבוע. הגדרת בעלות על שדות בין החנות למערכת הפיננסית. עבודה חד פעמית שחוסכת שנים.
מקורות
שאלות נפוצות
איזו פלטפורמה מתאימה יותר לחנות ישראלית?
אין תשובה כללית, כי שתיהן דורשות מערכת נוספת לחשבוניות ולשילוח. ההבדל המכריע הוא מי מתחזק את התשתית: WooCommerce מחייב אחראי אחסון ועדכונים, Shopify לא. אם אין בעסק מי שיחזיק את זה, זו כבר תשובה.
למה המלאי שלי מראה מספר שונה מהמחסן?
לרוב מפני שאתם משווים את המספר הלא נכון. ב-Shopify כמות שהוזמנה ולא סופקה יושבת ב-committed ואינה נספרת ב-available, למרות שהיא פיזית במחסן. ב-WooCommerce הפחתת מלאי כבר קרתה במעבר ל-Processing או ל-On hold.
האם אפשר להעביר חנות מפלטפורמה אחת לשנייה?
אפשר, והחלק הקשה אינו המוצרים אלא ההיסטוריה: הזמנות, זיכויים והמזהים שמערכות אחרות כבר שמרו. תכננו את שמירת המזהה החיצוני בשתי המערכות מהיום הראשון, וההעברה תהיה עבודת נתונים ולא פרויקט מחדש.
מה חשוב יותר, בעלות על הנתונים או יציבות הממשק?
זה תלוי במי שמתחזק. בעלות מלאה שווה הרבה כשיש מי שיודע לתחזק אותה, ומעט מאוד כשאין. ממשק מתועד ויציב עדיף על גישה ישירה לבסיס נתונים שאיש לא מתעד. ענו על השאלה הזו לפי האנשים שיש לכם, לא לפי העיקרון.
להמשך קריאה
שירות רלוונטי
מלאי ורכש
מלאי ברמת SKU, כללי הזמנה חוזרת ותהליך אישור מתועד.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.