סנכרון הזמנות 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
\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 \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. נעשה שימוש בעיבוד אסינכרוני כדי למזער הפסדים.

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