סנכרון הזמנות Bitrix 1C: קונפליקטים במלאי והחלפה בזמן אמת

רשת קמעונאית מתמודדת עם שלושה ערוצי הזמנות בו-זמנית: חנות המקוונת Bitrix, מסופי POS בחנויות הפיזיות והזמנות טלפוניות. ללא סנכרון, המלאי נשמר במקביל מספר פעמים — מה שמוביל לביטול של עד 15% מההזמנות עקב מחסור בסחורה. אנחנו, מהנדסים עם ניסיון של 10+ שנים בייצור, מבטיחים החלפה דו-כיוונית של הזמנות ומלאי בין Bitrix ל-1C בזמן אמת. משמעות הדבר: תשלום מקוון שומר סחורה במחסן באופן מיידי, מכירות POS מפחיתות מיד את המלאי המקוון, וקונפליקטים מסולקים. מפתח-לסיום — מבחירת ארכיטקטורה ועד להדרכת צוות.

מדוע שלושה ערוצי הזמנות מבודדים הורסים את ניהול המלאי?

תרחיש טיפוסי: לקוח משלם באינטרנט עבור מוצר שנמכר כבר דרך POS לפני 10 דקות. Bitrix מנכה מלאי רק לאחר יצירת ההזמנה, בעוד שמכירת ה-POS כבר הפחיתה את המלאי הפיזי. ההזמנה המקוונת מתקבלת אך לא ניתן למלא אותה. יישום סנכרון מפחית את ההפסדים ממכירות כפולות ב-15–20%.

כיצד לבחור את מערכת השליטה בסנכרון?

80% מהקונפליקטים נעלמים אם מערכת השליטה נבחרת לפני תחילת הפיתוח. התייעצו עם המומחים שלנו בשלב הביקורת.

ארכיטקטורת סנכרון: פרוטוקולים ותוכניות

1C כמערכת שליטה

1C הוא מקור האמת להזמנות ומלאי. Bitrix מעביר הזמנות מקוונות ל-1C, מכירות לא מקוונות נרשמות שם, והמלאי מסונכרן בחזרה.

Bitrix כמערכת שליטה

כל ההזמנות (מקוונות ולא מקוונות דרך POS) נאספות ב-Bitrix; 1C מקבל נתונים לחשבונאות.

סנכרון דרך CommerceML

ההחלפה הסטנדרטית של 1C-Bitrix (/bitrix/admin/1c_exchange.php) מכסה את התרחיש הבסיסי. ההגדרה נמצאת במודול sale. כפי שמצוין בתיעוד של 1C-Bitrix, החלפה סטנדרטית דרך CommerceML מתאימה להחלפה בקבוצות של הזמנות ומלאי. מגבלה: החלפה בקבוצות כל N דקות. לזמן אמת, נדרשים webhooks או תורי הודעות.

REST API ותור הודעות

לרשתות גדולות ועומס גבוה, מומלץ תור RabbitMQ עם זמן השהיה של פחות משתי שניות.

יישום: שמירת מלאי וקונפליקטים

הזמנות לא מקוונות מ-POS

כאשר קופאי משלים מכירה דרך POS, האם עלינו ליצור הזמנה ב-Bitrix דרך API או רק לנכות מלאי?

דוגמה ליצירת הזמנה לא מקוונת דרך REST API:

// Создание оффлайн-заказа в Битрикс \Bitrix\Main\Loader::includeModule('sale'); \Bitrix\Main\Loader::includeModule('catalog'); $order = \Bitrix\Sale\Order::create(SITE_ID, $userId); $order->setField('CURRENCY', 'RUB'); $order->setField('USER_DESCRIPTION', 'Продажа в магазине: ' . $storeName); $basket = \Bitrix\Sale\Basket::create(SITE_ID); foreach ($items as $item) { $basketItem = $basket->createItem('catalog', $item['PRODUCT_ID']); $basketItem->setFields([ 'QUANTITY' => $item['QUANTITY'], 'CURRENCY' => 'RUB', 'LID' => SITE_ID, 'PRODUCT_PROVIDER_CLASS' => '\CCatalogProductProvider', ]); } $order->setBasket($basket); // Помечаем источник заказа $order->setField('STATUS_ID', 'F'); // Выполнен — оффлайн-продажа завершена $order->setField('ADDITIONAL_INFO', json_encode([ 'source' => 'offline', 'store' => $storeId, 'pos_transaction_id' => $transactionId, ])); $result = $order->save(); 

שמירת מלאי על הזמנה מקוונת

נקודה קריטית היא תזמון השמירה. Bitrix מנהל שמירות דרך // Создание оффлайн-заказа в Битрикс \Bitrix\Main\Loader::includeModule('sale'); \Bitrix\Main\Loader::includeModule('catalog'); $order = \Bitrix\Sale\Order::create(SITE_ID, $userId); $order->setField('CURRENCY', 'RUB'); $order->setField('USER_DESCRIPTION', 'Продажа в магазине: ' . $storeName); $basket = \Bitrix\Sale\Basket::create(SITE_ID); foreach ($items as $item) { $basketItem = $basket->createItem('catalog', $item['PRODUCT_ID']); $basketItem->setFields([ 'QUANTITY' => $item['QUANTITY'], 'CURRENCY' => 'RUB', 'LID' => SITE_ID, 'PRODUCT_PROVIDER_CLASS' => '\CCatalogProductProvider', ]); } $order->setBasket($basket); // Помечаем источник заказа $order->setField('STATUS_ID', 'F'); // Выполнен — оффлайн-продажа завершена $order->setField('ADDITIONAL_INFO', json_encode([ 'source' => 'offline', 'store' => $storeId, 'pos_transaction_id' => $transactionId, ])); $result = $order->save(); ו-b_catalog_store_product. עבור Click & Collect, שמרו במחסן ספציפי.

סנכרון מלאי בזמן אמת

שינויים במלאי בכל צד חייבים לבוא לידי ביטוי מיידי. השתמשו בתור אירועים:

// При изменении остатков — добавляем в очередь \Bitrix\Main\EventManager::getInstance()->addEventHandler( 'catalog', 'OnProductUpdate', function (\Bitrix\Main\Event $event) { $productId = $event->getParameter('ID'); $fields = $event->getParameter('FIELDS'); if (isset($fields['QUANTITY'])) { // Ставим в очередь синхронизации с 1С \Local\Queue\InventorySync::push([ 'product_id' => $productId, 'quantity' => $fields['QUANTITY'], 'timestamp' => time(), ]); } } ); 

קונפליקטים של מכירות מקבילות

פתרון — ניכוי מלאי אטומי ברמת מסד הנתונים:

-- Атомарное списание с проверкой UPDATE b_catalog_store_product SET QUANTITY = QUANTITY - 1 WHERE PRODUCT_ID = ? AND STORE_ID = ? AND QUANTITY >= 1; -- Если affected_rows = 0 — остатка нет, отклоняем заказ 

מיושם ב-Bitrix דרך b_sale_product_reserve.

איך אנחנו עושים את זה: מקרה של רשת עם 10,000 פריטים

הלקוח שלנו — רשת של 12 חנויות עם 3 ערוצים מקוונים ומכירות לא מקוונות דרך 1C:Retail. CommerceML סטנדרטי גרם לעיכוב של 15 דקות. פתרון: תור RabbitMQ + סוכן מותאם אישית עם זמן השהיה של פחות משתי שניות. קונפליקטים נפתרו על ידי עקרון "הראשון שמבצע". תוצאה — דיוק מלאי של 99.9%. החזר השקעה תוך חודשיים.

מה כלול בעבודה ובתהליך

• ביקורת על הארכיטקטורה הנוכחית
• בחירת מערכת שליטה ופרוטוקול
• הגדרת החלפת הזמנות, סטטוסים ומלאי
• פיתוח סוכן מותאם אישית
• בדיקות עומס
• תיעוד והדרכה
• תמיכה לחודש אחד

תהליך: ניתוח (1–2 ימים) → עיצוב (1–2) → יישום (3–5) → בדיקות (2–3) → פריסה (1). לוח זמנים: 5 עד 10 ימי עבודה.

אחריות: העבודה מתבצעת באמצעות תיעוד רשמי של Bitrix ו-1C. נעשה שימוש בעיבוד אסינכרוני כדי למזער הפסדים.

צרו קשר לביקורת חינם על המערכת שלכם. קבלו תוכנית סנכרון לעסק שלכם. הזמינו אינטגרציה ושכחו מבעיות מלאי.