למה הקופה תמיד מנצחת את האתר במרוץ על היחידה האחרונה, מה ההבדל בין שריון למלאי זמין להבטחה, כמה השהיית סנכרון מותר לספוג, ואיך בונים התאמה לפי תנועות.
עיקרי הדברים
- הקופה היא הכותב המהיר במערכת: היא סוגרת מכירה בשנייה אחת, בעוד הזמנה באתר עוברת עגלה, סליקה ואישור. לכן היחידה האחרונה כמעט תמיד נמכרת פעמיים לרעת האתר.
- "מלאי זמין" אינו שדה שנשמר, אלא תוצאה של חישוב: מלאי פיזי פחות מחויב, פחות משוריין, פחות דליים לא זמינים כמו פגום או מלאי ביטחון.
- שריון נכון נוצר ברגע שהלקוח מתחיל תשלום, לא ברגע שהתשלום מאושר. ב-WooCommerce ההגדרה שמייצרת את ההתנהגות הזאת נקראת Hold stock (minutes): היא מחזיקה מלאי להזמנה שלא שולמה למשך מספר הדקות שהגדרתם, ואז מבטלת את ההזמנה ומשחררת את המלאי. השאירו ריק כדי לכבות. אין ערך ברירת מחדל מתועד - בדקו מה מוגדר אצלכם.
- חלון הסיכון שווה להשהיית הסנכרון כפול קצב המכירה של אותו פריט. פריט שנמכר פעם בחודש סובל השהיה של חמש דקות; פריט שנמכר עשר פעמים ביום לא.
- התאמה יומית שמשווה כמות סופית בלבד מגלה שיש פער ולא מגלה מה גרם לו. השוואה לפי תנועות מצביעה על הקליטה, ההחזרה או הסנכרון שנשמט.
מכירת יתר קורית מפני שלקופה ולאתר יש כל אחד תמונת מלאי משלו, והקופה כותבת ראשונה. המניעה דורשת שלושה דברים: חישוב אחד של "מלאי זמין להבטחה", שריון שנוצר לפני קבלת התשלום ולא אחריו, ותהליך התאמה שמשווה תנועות מלאי ולא רק כמות סופית.
למה הקופה מנצחת את האתר במרוץ על היחידה האחרונה
הקופה מנצחת מפני שהמכירה בחנות היא פעולה אטומית אחת, בעוד המכירה באתר היא רצף של ארבעה שלבים שכל אחד מהם לוקח זמן. הנה מקרה אמיתי בעיצובו: מק"ט FR-2210-42, יחידה אחת בסניף רמת גן.
- 14:32:07 - המוכר סורק ברקוד בקופה. הרשומה נכתבת מקומית.
- 14:32:09 - לקוח באתר לוחץ "לתשלום" על אותו מק"ט. האתר בדק זמינות לפני 40 שניות.
- 14:32:11 - הסולק מאשר את החיוב. באתר נוצרה הזמנה.
- 14:32:14 - הקופה משדרת את תנועת המכירה ל-ERP.
- 14:32:38 - האתר מושך פיד מלאי ומעדכן את הכמות ל-0, באיחור של 27 שניות.
שתי תעודות, יחידה אחת. שימו לב שאף מערכת לא התקלקלה. כל אחת עשתה בדיוק את מה שתוכננה לעשות, והפער נוצר בין 14:32:07 לבין 14:32:38. כל פתרון שאינו נוגע בחלון הזה - תוסף סנכרון מהיר יותר, מערכת מלאי חדשה, דוח יומי - לא ימנע את המקרה הבא.
מה בעצם אומרת המילה "זמין"
"זמין" הוא תוצאה של חישוב ולא שדה שמישהו כותב. הנוסחה שעובדת:
זמין = מלאי פיזי - מחויב להזמנות שטרם סופקו - משוריין לעגלות פתוחות - דליים לא זמינים - מלאי ביטחון
Shopify מתעדת בממשק ה-GraphQL Admin שמונה מצבי כמות נפרדים: incoming, on_hand, available, committed, reserved, damaged, safety_stock ו-quality_control, כאשר on_hand הוא הסכום של הזמין, המחויב והלא זמין. התיעוד גם קובע שאי אפשר להתאים או להזיז כמות במצב committed דרך ה-API, כי היא נגזרת מהזמנות. ב-WooCommerce המנגנון שונה: הזמנה נכנסת בסטטוס pending, והכמות מופחתת בפועל כשההזמנה עוברת ל-processing או ל-on-hold.
| מה נספר | קופה | אתר | ERP או מערכת מלאי |
|---|---|---|---|
| מלאי פיזי בסניף | מקור אמת בזמן הסריקה | לא יודע | מתעדכן מהתנועות |
| מחויב להזמנות פתוחות | לרוב לא קיים | קיים לפי סטטוס ההזמנה | קיים לפי שורות הזמנה |
| שריון עגלה | לא רלוונטי | קיים כטיימר או כטבלת שריונים | בדרך כלל לא מוכר |
| מלאי ביטחון | לא | ניתן להגדיר כמאגר נפרד | שדה מדיניות |
| החזרות שטרם נבדקו | נכנסות מיד | לא יודע | תלוי בהגדרת מיקום |
השורה האחרונה אחראית לחלק גדול מהפערים: החזרה שנקלטה בקופה חוזרת למלאי מיידית, בעוד באתר היא לא קיימת עד שמישהו אישר אותה.
שריון או מלאי זמין להבטחה - מה מתאים לעסק שלכם?
שריון מתאים כשהיחידה מזוהה, ומלאי זמין להבטחה מתאים כשהיחידות מתחלפות זו בזו. שתי הגישות אינן תחליף זו לזו:
- שריון מחזיק יחידה מסוימת או כמות מסוימת עבור הזמנה מסוימת, עם זמן תפוגה ועם בעלים. מתאים למשקפיים לפי מספר סידורי, לרכב, לרהיט מהתצוגה.
- מלאי זמין להבטחה מחשב כמה אפשר להבטיח כרגע בלי לשמור יחידה ספציפית. מתאים לחולצה במידה M, לברגים, לכל מה שנספר ולא מזוהה.
- הכלל שמכריע: אם החזרת יחידה למלאי דורשת פעולה ידנית של אדם, אתם צריכים שריון עם תפוגה. אם היא מתבצעת ממילא בביטול הזמנה, מספיק חישוב.
בעסק עם מספרים סידוריים הבחירה כבר נקבעה - ראו ניהול מלאי סידורי בחנות אופטיקה.
כמה השהיית סנכרון מותר לספוג?
חלון הסיכון של פריט שווה להשהיית הסנכרון כפול קצב המכירה שלו, ולכן התשובה שונה לכל מק"ט. חישוב פשוט: פריט שנמכר 10 פעמים ביום בשעות פעילות של 10 שעות נמכר בממוצע פעם ב-60 דקות; השהיית סנכרון של 5 דקות מייצרת סיכון של כ-8% למכירה כפולה כשנשארה יחידה אחת. אותה השהיה על פריט שנמכר פעם בשבוע היא רעש.
ההשלכה התכנונית: לא מסנכרנים הכול באותו קצב.
- פריטים עם יחידה אחת או שתיים במלאי עוברים לעדכון בדחיפה מהקופה, ולא לפיד מתוזמן.
- פריטים עם מלאי גבוה נשארים בסנכרון תקופתי, שהוא זול יותר במכסות הקריאה.
- כל מק"ט שירד מתחת לסף שהגדרתם עובר אוטומטית לקבוצה הראשונה.
- כשה-API של החנות מגביל קצב, מדרגים את הפריטים ולא מגדילים את התדירות - הנושא מפורט בטיפול בשגיאת 429 בסנכרון חנות.
מה מציגים כשהסנכרון נופל
כשהסנכרון נופל, ברירת המחדל היא לעצור הבטחה ולא להמשיך למכור מספר ישן. ההחלטה הזאת מתקבלת מראש, בכתב, לכל קבוצת מוצרים:
- להציג "אזל" לפריטים שהמלאי שלהם נמוך מהסף, במקום להציג כמות שגילה לא ידוע.
- לאפשר הזמנה עם זמן אספקה מורחב ובדיקת צוות, במקום הבטחת משלוח מחר.
- לחסום פריטים עם מספר סידורי לחלוטין, כי כפילות שם אינה ניתנת לפיצוי בקלות.
- לרשום את משך הנפילה, כדי שההתאמה של אותו יום תדע איזה חלון לבדוק.
- להתריע לאדם, לא רק ללוג. סנכרון שנפל בשקט הוא מקור הפערים הגדול ביותר.
ב-Shopify ההתנהגות של המשך מכירה במלאי אפס נשלטת בשדה inventoryPolicy ברמת הווריאנט, עם שני ערכים בלבד: DENY ו-CONTINUE. זו החלטה עסקית שנרשמת בקוד, ולא ברירת מחדל שכדאי לרשת.
ההתאמה שמוצאת את הסיבה, לא רק את הפער
התאמה שמשווה כמות סופית מגלה שחסרות שתי יחידות ולא מגלה למה. התאמה שמשווה תנועות מגלה בדיוק איזו תנועה נשמטה. לכן כל תנועת מלאי נשמרת כרשומה, לא כעדכון של שדה כמות:
| שדה | דוגמה |
|---|---|
movement_id | MV-2026-0912-004417 |
sku | FR-2210-42 |
type | sale / return / receipt / transfer / adjustment / reservation |
source | pos-ramat-gan-2 |
qty_delta | -1 |
occurred_at | 2026-09-12T14:32:07+03:00 |
synced_at | 2026-09-12T14:32:38+03:00 |
ref_doc | POS-88213 |
עם המבנה הזה, ההתאמה הלילית מריצה שאילתה אחת: סכום qty_delta לכל מק"ט מול הכמות המדווחת בכל מערכת. פער מוצג יחד עם התנועות שיצרו אותו, וההפרש בין occurred_at ל-synced_at מספר מיד אם מדובר בסנכרון איטי או בתנועה שלא נקלטה כלל. הרחבה על השכבה הזאת מול מערכת ניהול מרכזית נמצאת בחיבור חנות אונליין ל-ERP.
מקורות
שאלות נפוצות
האם תוסף סנכרון מלאי פותר את הבעיה?
תוסף מקצר את ההשהיה אבל לא מבטל אותה, ולכן הוא מקטין את חלון הסיכון בלי לסגור אותו. הפריטים שנמכרים פעמיים הם אלה שנשארה בהם יחידה אחת, וזו בדיוק המצב שבו כל שנייה של פיגור נחשבת. תוסף בלי שריון ובלי התאמה לפי תנועות דוחה את הבעיה.
מה עושים כשהאתר מכר פריט שכבר לא קיים?
מטפלים בזה כתהליך מוגדר ולא כאלתור: מסמנים את שורת ההזמנה כחריגה, יוצרים משימה לאיש קשר עם הלקוח תוך זמן שנקבע מראש, ומציעים החלפה או ביטול. במקביל נרשמת תנועת התאמה עם סיבה, כדי שההתאמה החודשית תדע שהפער הוסבר.
האם מלאי ביטחון פותר מכירת יתר?
מלאי ביטחון מקטין את התדירות אך אינו מנגנון מניעה. הוא פשוט מסתיר חלק מהמלאי מהחישוב, כך שהמרוץ בין הקופה לאתר מתרחש על יחידה שלישית במקום על האחרונה. הוא שימושי כשההשהיה ידועה וקבועה, ומזיק כשמשתמשים בו כדי לא לתקן את הסנכרון.
מה ההבדל בין מלאי מחויב למלאי משוריין?
מחויב הוא מלאי ששייך להזמנה שנוצרה וטרם סופקה. משוריין הוא מלאי שהוצא זמנית מהזמין עבור תהליך שטרם הפך להזמנה, כמו עגלה בתשלום או הצעת מחיר. ההבדל המעשי: שריון פג מעצמו בזמן שנקבע, ומחויב משתחרר רק באספקה או בביטול.
להמשך קריאה
שירות רלוונטי
מלאי ורכש
מלאי ברמת SKU, כללי הזמנה חוזרת ותהליך אישור מתועד.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.