איחוד הזמנות מרובי מחסנים ב-1C-Bitrix

תארו לעצמכם: חנות מקוונת עם שלושה מחסנים – מוסקבה, סנקט פטרבורג, יקטרינבורג. לקוח מזמין שלושה מוצרים, כל אחד ממחסן אחר. ללא קונסולידציה, המערכת תשלח שלוש חבילות עם עלויות משלוח משולשות. הלקוח לא מרוצה, המרווח יורד. אנחנו פותרים בעיה זו עם לוגיקה מותאמת אישית על Bitrix. במשך יותר מ-10 שנים, יישמנו יותר מ-50 פרויקטים בלוגיסטיקת מחסנים, והפתרון שלנו עובד ביציבות בעומסים של עד 10,000 הזמנות ביום. במקביל, עלויות המשלוח ללקוחות מופחתות בממוצע ב-30%, ולקוח אחד חסך $11k–16k בשנה בזכות חלוקה חכמה.

למה Bitrix לא מאחדת הזמנות כברירת מחדל?

המודול הסטנדרטי "מחסנים" ב-1C-Bitrix מאחסן מלאים ב-b_catalog_store_product והזמנות ב-b_sale_reserve_quantity, אך אינו מספק מנגנון לבחירה אוטומטית של מחסן בעת ביצוע הזמנה. המפתח חייב לכתוב את לוגיקת החלוקה באופן ידני. אנו משתמשים ב-\Bitrix\Catalog\StoreProductTable::getList() עם פילטר לפי PRODUCT_ID והתנאי AMOUNT > 0 כדי לקבל יתרות זמינות. לאחר מכן אנו בוחרים מחסן לפי האסטרטגיה המוגדרת בהגדרות. אנו מתחשבים לא רק בזמינות, אלא גם במרחק ללקוח, בעלות המשלוח ובעומס המחסן.

אסטרטגיות קונסולידציה: השוואה

אסטרטגיה 1: מהירות מקסימלית – כל מוצר נשלח מהמחסן הקרוב ביותר מיד עם זמינותו. הלקוח מקבל מספר חבילות. יישום: בעת יצירת הזמנה, סוכן מפצל אותה מיד לתת-הזמנות לפי מחסן.

אסטרטגיה 2: מספר חבילות מינימלי – המתנה להרכבת כל ההזמנה במחסן "ראשי" אחד, אליו מועברים המוצרים הנדרשים. יישום: העברה בין-מחסנית דרך b_catalog_store_document עם סוג M.

אסטרטגיה 3: היברידית – משלוח מוצרים זמינים מיד, המתנה למוצרים בהזמנה חוזרת. איזון אופטימלי בין מהירות לעלות משלוח. האסטרטגיה ההיברידית מפחיתה את מספר החבילות פי 2–3 בהשוואה למהירות מקסימלית, תוך שמירה על זמן משלוח סביר. לפי הנתונים שלנו, האסטרטגיה ההיברידית חסכונית יותר ב-40% מבחינת לוגיסטיקה.

איך אנחנו מפצלים הזמנה לתת-הזמנות?

אנו יוצרים את הטבלה bl_order_shipments עם שדות order_id, store_id, status, items_json. בעת אישור ההזמנה, הסוכן מנתח את סל הקניות:

foreach ($basket as $item) { $stores = StoreProductTable::getList([ 'filter' => ['PRODUCT_ID' => $item->getProductId(), '>AMOUNT' => 0], 'order' => ['AMOUNT' => 'DESC'], ])->fetchAll(); $bestStore = $stores[0]['STORE_ID'] ?? $defaultStoreId; $shipments[$bestStore][] = [ 'product_id' => $item->getProductId(), 'quantity' => $item->getQuantity(), ]; } 

כל קבוצה נכתבת לתוך foreach ($basket as $item) { $stores = StoreProductTable::getList([ 'filter' => ['PRODUCT_ID' => $item->getProductId(), '>AMOUNT' => 0], 'order' => ['AMOUNT' => 'DESC'], ])->fetchAll(); $bestStore = $stores[0]['STORE_ID'] ?? $defaultStoreId; $shipments[$bestStore][] = [ 'product_id' => $item->getProductId(), 'quantity' => $item->getQuantity(), ]; } . סטטוסי תת-ההזמנות מנוטרים באופן עצמאי. כאשר מסמך מחסן משתנה (לדוגמה, משלוח), הסוכן מעדכן את הסטטוס של תת-ההזמנה המתאימה.

לוגיקת בחירת המחסן מוגדרת דרך bl_order_shipments: עבור כל מוצר ניתן להגדיר עדיפות – קודם מלאים במחסן, אחר כך מוצרים בהזמנה חוזרת. אם במחסן אין מלאי מספיק, אנו בודקים אחרים. אם אין באף אחד – אנו מסמנים כממתין. זה מאפשר לשנות את האסטרטגיה ללא התערבות מתכנת.

תצוגה ללקוח: שקיפות לוגיסטית

בחשבון האישי ובמייל ההזמנה, אנו מציגים את הפירוט: חבילה 1 (מחסן מוסקבה): 2 מוצרים – נשלחו, חבילה 2 (מחסן SPb): מוצר אחד – בהעברה. רכיב החשבון האישי שולף נתונים מ-b_option וממזג אותם עם ההזמנה הראשית דרך bl_order_shipments. זה מגביר אמון ומפחית פניות לתמיכה.

תהליך עבודה: שלבים ולוחות זמנים

מה כלול בעבודה?

• ביקורת תוכנית המחסנים הנוכחית ורמות המלאי שלך
• עיצוב אסטרטגיית קונסולידציה מותאמת לעסק שלך
• פיתוח הטבלה order_id וסוכני חלוקה
• הגדרת אסטרטגיה דרך bl_order_shipments (ניתנת להחלפה ללא מתכנת)
• יישום תצוגת תת-ההזמנות בחשבון האישי ובפאנל הניהול
• אינטגרציה עם 1C דרך CommerceML לסנכרון מלאים ומשלוחים
• תיעוד לשינוי והדרכה למנהלים שלך
• שישה חודשים של אחריות חינם על הקוד

לוחות זמנים ועלות

לוחות זמנים – בין 5 ל-14 ימי עסקים, תלוי במספר המחסנים ובמורכבות האינטגרציה. העלות מחושבת באופן אישי לאחר ביקורת. קבלו פתרון סוהר: ננתח את תהליך העבודה שלכם ונציע את אסטרטגיית הקונסולידציה האופטימלית. צרו קשר עם המומחים שלנו – אנו עובדים עם כל התצורות של Bitrix ומבטיחים תוצאות. הזמינו ביקורת של תוכנית המחסנים הנוכחית שלכם – זה בחינם וללא התחייבות.