ציירו את מצבי המלאי שהחנות שלכם באמת עוברת, ואז בדקו אם למודל הנתונים יש שדה לכל אחד. מה שאין לו שדה נשמר בראש של מישהו, וזה האילוץ האמיתי בפרויקט.
עיקרי הדברים
- שתי תלונות שונות לחלוטין נשמעות זהות: "האתר מגביל אותנו" יכול להיות עיצוב, ויכול להיות שהתהליך לא ניתן לייצוג.
- Wix מתעדת מעקב מלאי ברמת וריאציה ומיקום, כאשר כל פריט מלאי מזוהה בצירוף של variantId ו-locationId.
- לפי התיעוד, השדה availabilityStatus הוא לקריאה בלבד ומחושב אוטומטית לפי שיטת המעקב והגדרות ההזמנה המוקדמת.
- קריאת decrementInventory מוגבלת ל-300 פריטים בקריאה אחת, ומקבלת דגל preorderRequest שמאפשר מלאי שלילי לפריטים בהזמנה מוקדמת.
- לא אותר בתיעוד המלאי שנבדק מצב ייעודי לפריט פגום, לפריט בבדיקה או למלאי ביטחון. זו קביעה על התיעוד, לא על היכולת.
ההחלטה בין Wix לפיתוח מותאם נקבעת לפי מספר המצבים שהמלאי שלכם עובר, ולא לפי איך נראה האתר. ציירו את המצבים, ואז בדקו אם למודל הנתונים של הפלטפורמה יש שדה לכל אחד. מצב שאין לו שדה נשמר בראש של עובד.
שתי תלונות שנשמעות זהות
התלונה הראשונה: "אנחנו רוצים שהעמוד ייראה אחרת ואי אפשר". זו תלונת תבנית. היא מטופלת בעיצוב, בתבנית אחרת או בקוד בצד הלקוח, והיא כמעט אף פעם לא סיבה לבנות מערכת.
התלונה השנייה: "יש לנו פריט שיצא לתיקון, הלקוח כבר שילם, והוא לא סופק, ואין לנו איפה לרשום את זה". זו תלונת תהליך. אין לה קשר לעיצוב, והיא לא נעלמת כשמחליפים תבנית.
הבעיה היא ששתיהן נאמרות באותן מילים: "הפלטפורמה מגבילה אותנו". הדרך היחידה להפריד ביניהן היא לרשום את המצבים ולחפש להם שדה.
כמה מצבים המלאי שלכם באמת עובר?
זו רשימת המצבים שחוזרת בחנויות ישראליות עם מלאי פיזי. סמנו את אלה שקיימים אצלכם:
- זמין למכירה במחסן.
- שמור ללקוח שטרם שילם.
- שולם וטרם נאסף או נשלח.
- יצא למשלוח ועדיין באחריותכם.
- בהזמנה מהספק וטרם הגיע.
- הגיע פגום וממתין להחלטה.
- יצא לתיקון או למעבדה וצפוי לחזור.
- אצל הלקוח בהשאלה או בבדיקה, ועדיין שלכם.
- פריט עם מספר סידורי, שבו כל יחידה היא רשומה נפרדת.
- מלאי ביטחון שלא נמכר גם כשהוא זמין.
עסק עם ארבעה מצבים ראשונים בלבד יסתדר כמעט בכל פלטפורמה. עסק שמסמן שבעה ומעלה מגיע לגבול של מודל נתונים, וזה גבול שלא זזים ממנו עם תוסף. ראו את הדוגמה המפורטת בזרימת מלאי סידורי בחנות אופטיקה.
מה מודל המלאי של Wix מתעד
| היכולת | מה מתועד | הערה מהתיעוד |
|---|---|---|
| מעקב לפי מיקום | מתועד | פריט מלאי מזוהה בצירוף variantId ו-locationId, וכל וריאציה יכולה להחזיק כמות נפרדת בכל מיקום |
| שתי שיטות מעקב | מתועד | מעקב לפי כמות, או מעקב "במלאי" בלי ספירה, לפריטים לפי הזמנה או דיגיטליים |
| סטטוס זמינות | מתועד כשדה לקריאה בלבד | availabilityStatus מחושב אוטומטית ומתעדכן כשהמלאי משתנה |
| הזמנה מוקדמת | מתועד | מוגדר פר פריט מלאי, כלומר פר צירוף וריאציה ומיקום |
| הפחתת מלאי בקריאה אחת | מתועד עם מגבלה | decrementData מוגבל ל-300 פריטים, וכל פריט חייב decrementBy של 1 לפחות |
| מלאי שלילי | מתועד בתנאי | הדגל preorderRequest מאפשר מלאי שלילי כשהפריט זמין בהזמנה מוקדמת |
| יצירת מוצר עם מלאי | מתועד כקריאה נפרדת | Create Product אינו יוצר פריטי מלאי; לשם כך קיימת Create Product With Inventory |
| שדה המלאי על המוצר | מתועד כמוגבל | השדה inventory על המוצר הוא לקריאה בלבד ומשקף את מיקום ברירת המחדל בלבד |
| ניהול מיקומים | מתועד כקריאה בלבד | ממשק המיקומים של החנות הוא לקריאה; יצירה ועדכון נעשים דרך ממשק המיקומים הכללי עם locationTypes שכולל "INVENTORY" |
| פגום, בבדיקה, מלאי ביטחון | לא אותר בתיעוד המלאי שנבדק | אין קביעה שהיכולת חסרה; לא נמצא לה מצב ייעודי בתיעוד |
שתי השורות האחרונות הן אלה שמכריעות פרויקטים, ולא הראשונות.
מה שאין לו שדה, נשמר בראש של מישהו
- פריט שיצא לתיקון ואין לו מצב יופיע כזמין למכירה, או ייעלם מהספירה. שתי התוצאות שגויות.
- מלאי ביטחון שאין לו שדה מנוהל בכך שמישהו "יודע" לא לרדת מתחת לשלוש יחידות.
- מספר סידורי שאין לו רשומה משלו הופך לשדה טקסט בהערות ההזמנה, ואי אפשר לחפש בו.
- כל מצב חסר מייצר גיליון אלקטרוני מקביל, וכל גיליון מקביל מייצר סתירה בין שני מספרים.
- ברגע שיש סתירה, מישהו מפסיק לסמוך על המערכת, וזו נקודת האל חזור של הפרויקט.
האם התבנית היא האילוץ, או התהליך?
יש מבחן קצר שמפריד בין השניים, ואפשר להריץ אותו בשעה:
- שאלת התבנית. אם היינו מקבלים בדיוק את העיצוב שאנחנו רוצים, האם התהליך היה עובד? אם התשובה כן, זו בעיית עיצוב וההשוואה כאן מסתיימת. ההשוואה הכללית בין תבנית לאתר מותאם קיימת באתר מותאם מול Wix.
- שאלת התהליך. אם היינו מקבלים אתר מכוער לחלוטין אבל עם שדה לכל מצב ברשימה, האם היינו מסתדרים? אם התשובה כן, האילוץ הוא מודל הנתונים ולא התבנית.
התשובה הנפוצה בפועל היא ששתי הבעיות קיימות, אבל רק אחת מהן עולה כסף אמיתי. תקנו קודם את זו שמייצרת גיליונות אלקטרוניים.
מה פיתוח מותאם קונה כאן, ומה לא
הוא קונה שליטה על המצבים: אתם מגדירים אילו מצבים קיימים, מה המעבר החוקי בין כל שניים, ומה נחשב זמין למכירה. הוא גם קונה את היכולת לרשום מספר סידורי כרשומה עם היסטוריה משלה.
הוא לא קונה חנות מוכנה. עיצוב, קופה, ניהול תוכן ותשלומים הם עבודה שכבר קיימת בפלטפורמה, וכתיבתה מחדש רק כדי לקבל מצב מלאי אחד היא החלטה גרועה. הצורה שעובדת ברוב המקרים היא שמירה על החנות הקיימת כחזית, והוצאת ניהול המצבים לשכבה נפרדת שמסונכרנת אליה. ראו אוטומציה של ניהול מלאי.
צורת העלות, בלי מספרים
- מה שגדל עם מספר המצבים. כל מצב נוסף מוסיף מעברים, בדיקות ומסכים. זה הגורם היחיד שבאמת מכפיל עבודה.
- מה שגדל עם מספר המיקומים. ניהול רב מיקומי מכפיל את רשומות המלאי ואת בדיקות ההתאמה.
- מה שגדל עם נפח הפריטים. מגבלה כמו 300 פריטים בקריאה קובעת כמה קריאות דרושות לעדכון קטלוג שלם.
- מה שגדל עם ההתאמות בחזית. התאמות עיצוב זולות בהתחלה ויקרות בכל שדרוג פלטפורמה.
- מה שנשאר קבוע. מסמך אחד שמגדיר את המצבים ואת המעברים ביניהם. זה הנכס שמאפשר להחליף ספק בלי להתחיל מאפס.
מקורות
שאלות נפוצות
מה זה אומר ש-availabilityStatus הוא לקריאה בלבד?
שלפי התיעוד השדה מחושב על ידי המערכת לפי שיטת המעקב והגדרות ההזמנה המוקדמת, ואינו נקבע ישירות. מבחינה מעשית אי אפשר "לסמן" פריט כלא זמין דרך השדה הזה; משנים את הכמות או את הגדרות המעקב, והסטטוס נגזר מהן.
האם מגבלת 300 הפריטים בקריאה היא בעיה?
לא ברוב החנויות. היא הופכת לשיקול תכנוני כשמסנכרנים קטלוג גדול בבת אחת, כי היא קובעת לכמה קריאות מפצלים את העדכון. זו בדיוק דוגמה למגבלה מתועדת שעדיף לתכנן לפיה מראש מאשר לגלות אותה בהרצה ראשונה בייצור.
אפשר להוסיף מצבי מלאי חסרים בעזרת תוסף?
לפעמים אפשר לשמור נתון נוסף, אבל לא תמיד אפשר לגרום למנוע הזמינות של הפלטפורמה להתחשב בו. ההבדל קריטי: נתון שנשמר ואינו משפיע על מה שנמכר הוא תיעוד, לא בקרה, והוא לא ימנע מכירה של פריט שיצא לתיקון.
מתי בכל זאת נכון להישאר בפלטפורמה?
כשרשימת המצבים שלכם קצרה, כשמיקום אחד מספיק, וכשאין פריטים סידוריים. במצב הזה ההשקעה הנכונה היא בתוכן, בצילום ובחוויית הקנייה, ולא במודל נתונים. פלטפורמה שמספיקה היא תמיד הבחירה הזולה יותר.
להמשך קריאה
שירות רלוונטי
מלאי ורכש
מלאי ברמת SKU, כללי הזמנה חוזרת ותהליך אישור מתועד.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.