Розничная сеть сталкивается с тремя потоками заказов одновременно: интернет-магазин Битрикс, POS-терминалы в магазинах и телефонные звонки. Без синхронизации остатки резервируются несколько раз параллельно — до 15% заказов отменяются из-за недостатка товара. Мы, инженеры с 10+ лет опыта, обеспечиваем двусторонний обмен заказами и остатками между Битрикс и 1С в реальном времени. Это означает: оплата онлайн мгновенно резервирует товар на складе, POS-продажа сразу уменьшает остатки в интернете, конфликты отсутствуют. Под ключ — от выбора архитектуры схемы до обучения персонала.
Почему три изолированных потока заказов убивают складской учёт?
Типичный сценарий: клиент оплачивает онлайн товар, который уже продан через POS 10 минут назад. Битрикс списывает остаток только после формирования заказа, а POS-продажа уже уменьшила физический остаток. В результате онлайн-заказ принимается, но отгрузить нечего. Внедрение синхронизации сокращает потери от двойных продаж на 15-20%.
Как выбрать мастера синхронизации?
| Критерий | 1С как мастер | Битрикс как мастер | Гибрид (не рекомендуется) |
|---|---|---|---|
| Источник правды | 1С | Битрикс | Нет единого |
| Заказы онлайн | Передаются в 1С | Обрабатываются в Битрикс | Дублируются |
| Оффлайн-продажи | Фиксируются в 1С | Создаются в Битрикс через API | Потеря заказов |
| Остатки | Синхронизируются в Битрикс | Синхронизируются в 1С | Перезаписываются |
| Конфликты при параллельных продажах | Разрешаются в 1С | Разрешаются в Битрикс | Возникают в обеих системах |
80% конфликтов уходят, если выбрать мастера до начала разработки. Проконсультируйтесь с нашими специалистами на этапе аудита.
Архитектура синхронизации: протоколы и схема
1С как мастер
1С является источником истины по заказам и остаткам. Битрикс передаёт онлайн-заказы в 1С, оффлайн-продажи фиксируются там же, остатки синхронизируются обратно.
Битрикс как мастер
Все заказы (онлайн и оффлайн через POS) собираются в Битрикс, 1С получает данные для бухгалтерии.
Синхронизация через CommerceML
Стандартный обмен 1С-Битрикс (/bitrix/admin/1c_exchange.php) покрывает базовый сценарий. Настройка в модуле sale. Как указано в документации 1С-Битрикс, стандартный обмен через CommerceML подходит для пакетного обмена заказами и остатками. Ограничение: пакетный раз в N минут. Для реального времени нужны вебхуки или очереди.
REST API и очередь сообщений
| Протокол | Скорость | Сложность реализации | Подходит для |
|---|---|---|---|
| CommerceML | Пакетный (раз в N минут) | Средняя | Базовый обмен с 1С |
| REST API | Реальное время | Высокая | Нестандартные POS, вебхуки |
| Очередь сообщений (RabbitMQ) | Миллисекунды | Очень высокая | Крупные сети, highload |
Для крупных сетей и highload подходит очередь на RabbitMQ с задержкой не более 2 секунд.
Реализация: резервирование и конфликты
Оффлайн-заказы из POS
Когда кассир оформляет продажу через POS, нужно создать заказ в Битрикс из 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(); Резервирование остатков при онлайн-заказе
Критическая точка — момент резервирования. Битрикс управляет резервами через b_catalog_store_product и b_sale_product_reserve. Для 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 — остатка нет, отклоняем заказ В Битрикс реализуется через CCatalogProductProvider.
Как мы это делаем: кейс сети с 10 000 SKU
Наш клиент — сеть из 12 точек: 3 онлайн-потока и оффлайн-продажи через 1С:Розница. Стандартный CommerceML давал задержку 15 минут. Решение: очередь на RabbitMQ + кастомный агент с задержкой не более 2 секунд. Конфликты разрешаются по принципу «кто первый зафиксировал транзакцию». Результат — 99.9% актуальность остатков. Окупился за 2 месяца.
Что входит в работу и процесс
- Аудит текущей архитектуры
- Выбор мастер-системы и протокола
- Настройка обмена заказами, статусами, остатками
- Разработка кастомных агентов
- Тестирование под нагрузкой
- Документация и обучение
- Поддержка 1 месяц
Процесс: аналитика (1-2 дня) → проектирование (1-2) → реализация (3-5) → тестирование (2-3) → деплой (1). Сроки — от 5 до 10 рабочих дней.
Гарантия: работы выполняются с использованием официальной документации Битрикс и 1С. Применяем асинхронную обработку для минимизации потерь.
Свяжитесь с нами для бесплатного аудита вашей схемы. Получите план синхронизации для вашего бизнеса. Закажите интеграцию и забудьте о проблемах с остатками.