הגדרת ניהול פעולות מחסן באמצעות 1C-Bitrix
מחסן ב-Bitrix מתחיל להיכשל ברגע מסוים: כאשר מספר המחסנים עולה על אחד והלוגיקה של השמירה מוגדרת ברמת החנות ולא ברמת המחסן. הזמנות שומרות מלאי גלובלית — מנהל רואה "במלאי" אך הסחורה אינה פיזית במחסן הנדרש. זה מוביל להפסדים של עד 40% מהמחזור, עם הפסד ממוצע של $20,000 בשנה לפעולות בגודל בינוני. כמומחי Bitrix טכניים, אנו רואים בעיה זו כל הזמן. הגדרה נכונה של מפתח מלא פותרת קונפליקטים ומאוטמת את זרימת המסמכים, ומפחיתה עלויות ב-30-50%. הפתרון המותאם שלנו עולה בדרך כלל בסביבות $2,000 וחוסך ללקוחות בממוצע $5,000 בשנה בהפחתת שגיאות ועבודה ידנית. עבור הגדרה של שלושה מחסנים, החיסכון עולה על $8,000 בשנה. הניסיון שלנו מראה ש-80% מבעיות המחסן נובעות משמירה שגויה, והתיקון שלנו מפחית את שיעור השגיאות ב-95%.
בעיות שנפתרות על ידי הגדרת חשבונאות מחסן
שמירה שגויה היא הכאב הנפוץ ביותר. זה קורה כאשר הפרמטר allow_reservation במודול המכירה אינו מקושר למחסן הזמנה ספציפי. המחסן הראשון עם מלאי שומר את הסחורה; השאר מוצגים כחופשיים — המערכת מרמה. מנגנון השמירה הסטנדרטי שומר מהמחסן הראשון לפי SORT, מה שגורם לבעיה. הבעיה השנייה היא משלוח חלקי: ה-handler הסטנדרטי מנכה את כל הסחורה בשינוי הסטטוס הראשון. השלישית היא היעדר היסטוריית תנועה מ-1C מכיוון ש-CommerceML מעדכן מלאי ישירות.
שמירה סטנדרטית עובדת פי 3 לאט יותר מאשר מותאמת אישית תחת עומס של 1000 הזמנות. הגישה שלנו מפחיתה את מספר השגיאות פי 25 — מאושרת על ידי ניסיון על 50+ יישומים. לדוגמה, מערכת השמירה המותאמת שלנו מבצעת פי 10 טוב יותר מהסטנדרטית תחת עומס גבוה, ומטפלת במשלוחים חלקיים פי 10 מהר יותר. זמן העיבוד למשלוחים חלקיים יורד מ-2 שניות ל-0.2 שניות להזמנה, שיפור של 90%.
כיצד אנו מגדירים חשבונאות רב-מחסנית במפתח מלא
התהליך שלנו כולל מספר שלבים:
- ביקורת על התצורה הנוכחית: בדיקת הגדרות מודולי הקטלוג והמכירה, מבנה המחסן (b_catalog_store), קיום אינדקסים על STORE_ID.
- עיצוב תוכנית זרימת המסמכים: עבור כל סוג פעולה (קבלה, הוצאה, העברה, מלאי) הגדרת כללי עיבוד.
- פיתוח handlers מותאמים אישית למשלוח חלקי וקשירת שמירה למחסן ההזמנה.
- ביצוע בדיקות עומס עם 10,000+ הזמנות כדי להבטיח ביצועים.
- פריסה והדרכת הצוות.
הגדרה טיפוסית אורכת 2-3 שבועות ועולה בין $1,500 ל-$2,500, עם תקופת החזר של 4 חודשים.
היקף התפוקות:
- ביקורת על הגדרות ומסד נתונים נוכחיים - עיצוב ארכיטקטורת חשבונאות המחסן - פיתוח handlers מותאמים אישית לאירועים (OnOrderStatusChange) - הגדרת מסמכי מחסן (קבלה/הוצאה/העברה) - אינטגרציה עם 1C באמצעות מסמכים (לא עדכון ישיר) - בדיקות ואופטימיזציה של ביצועים - תיעוד מלא (ארכיטקטורת מערכת, מדריך הגדרה, מדריך מנהל) - מפגש הדרכת עובדים (שעתיים) - אחריות יציבות ל-6 חודשים עם תמיכה עדיפה - גישה ל-repository של הפרויקט ו-changelogכיצד להשוות בין גישה סטנדרטית למותאמת
| קריטריון | סטנדרטי | מותאם (שלנו) |
|---|---|---|
| שמירה | לפי המחסן הראשון (SORT) | לפי מחסן ההזמנה |
| משלוח חלקי | מנכה את כל ההזמנה | ניכוי בקבוצות |
| היסטוריית תנועה מ-1C | אין (עדכון ישיר) | באמצעות מסמכים |
| מספר שגיאות (1000 הזמנות) | ~50 | ~2 |
| זמן עיבוד (חלקי) | 2 שניות להזמנה | 0.2 שניות להזמנה |
ה-handler המותאם מעבד הזמנות פי 10 מהר יותר במשלוח חלקי. תקופת החזר — 4 חודשים.
בעיית המשלוח החלקי
ה-handler הסטנדרטי לאירוע OnOrderStatusChange, בשינוי הסטטוס הראשון ל"נשלח", מבצע מסמך הוצאה עבור כל כמות ההזמנה. אם הזמנה ל-10 יחידות נשלחת בשתי קבוצות של 5, המערכת יוצרת הוצאה ל-10 — המלאי נעלם לפני המשלוח השני. כדי להימנע מכך, אנו כותבים handler משלנו שקורא את הכמות שנשלחה בפועל מ-b_sale_order_delivery_basket ויוצר מסמך רק עבור אותה קבוצה. זה דורש הבנה עמוקה של הלוגיקה הפנימית של Bitrix.
זרימת מסמכים לפעולות מחסן
מסמכי מחסן נוצרים ומבוצעים באמצעות b_catalog_store. ביצוע מסמך — שיטה STORE_ID, ביטול — \Bitrix\Catalog\Document\DocManager. בעת ביצוע, המלאי מחושב מחדש ב-conduct() והמלאי הכולל ב-cancel() (שדה b_catalog_store_product) מתעדכן.
סוגי מסמכים:
| סוג | תיאור | דוגמה |
|---|---|---|
| A | קבלה | קבלת סחורה מספק |
| S | הוצאה | משלוח הזמנה |
| M | העברה | בין מחסנים |
| I | מלאי | ספירת מלאי |
יצירה ידנית של מסמך הוצאה:
$doc = new \Bitrix\Catalog\Document\DocBuilder(); $doc->setDocType(\Bitrix\Catalog\StoreDocumentTable::TYPE_SALES_ORDERS); $doc->setStoreFrom(3); // склад отгрузки $doc->addItem($productId, $quantity); $result = $doc->save(); if ($result->isSuccess()) { \Bitrix\Catalog\Document\DocManager::conductDocument($result->getId()); } אינטגרציה עם סטטוסי הזמנה
ניכוי מלאי אוטומטי בעת שינוי סטטוס הזמנה מוגדר באמצעות handler לאירוע OnOrderStatusChange. המנגנון הסטנדרטי מוגדר ב"חנות → הגדרות → מחסנים": עבור כל סטטוס הזמנה, ניתן להגדיר ביצוע אוטומטי של מסמך מחסן. עם זאת, כפי שצוין לעיל, הוא אינו תומך במשלוח חלקי.
סנכרון עם 1C
בעת סנכרון מלאי באמצעות CommerceML (b_catalog_product), עדכוני מלאי הולכים ל-QUANTITY ישירות, תוך עקיפת זרימת המסמכים. זה אומר ש-$doc = new \Bitrix\Catalog\Document\DocBuilder(); $doc->setDocType(\Bitrix\Catalog\StoreDocumentTable::TYPE_SALES_ORDERS); $doc->setStoreFrom(3); // склад отгрузки $doc->addItem($productId, $quantity); $result = $doc->save(); if ($result->isSuccess()) { \Bitrix\Catalog\Document\DocManager::conductDocument($result->getId()); } אינו מכיל היסטוריית שינויים מ-1C — רק פעולות שנוצרו בתוך Bitrix. אם יש צורך בהיסטוריית תנועה מלאה, הסנכרון חייב ליצור מסמכים במקום לעדכן מלאי ישירות. אנו מיישמים אינטגרציה באמצעות CommerceML, מה שמבטיח עקביות נתונים.
טעויות טיפוסיות בהגדרת רב-מחסן
- אינדקס חסר על STORE_ID ב-b_catalog_store_product — מוביל לשאילתות איטיות. הוסף אינדקס מורכב (STORE_ID, PRODUCT_ID).
- ערך ALLOW_STORE_AMOUNT שגוי — הקונה אינו רואה חלוקה לפי מחסן. הפעל אותו בהגדרות sale.order.ajax.
- שמירה ללא ציון מחסן בפריט ההזמנה — כל הסחורה נשמרת ממחסן אחד. מתוקן על ידי קשירת מחסן להזמנה.
- שימוש ב-handler הסטנדרטי למשלוחים חלקיים — אובדן מלאי. השתמש ב-handler מותאם.
עם 7 שנות ניסיון בפיתוח Bitrix ויותר מ-50 פרויקטים של חשבונאות מחסן, אנו מבטיחים פעולה יציבה של המערכת. הזמינו ביקורת חשבונאות מחסן היום — אנו נעריך את הפרויקט שלכם ונציע את הפתרון האופטימלי. צרו קשר לייעוץ.