Интеграция 1С-Битрикс со сканерами штрихкодов
Представьте: на складе менеджер сканирует штрихкод коробки, а система не находит товар — штрихкод в базе есть, но привязан не к тому продукту. Или сканер вводит код, но поле не в фокусе, и данные теряются. Мы сталкивались с этим десятки раз за 10+ лет опыта интеграций. Решение — правильно настроить обработку сканирования на стороне Битрикс, а не сам сканер. Наш опыт показывает: 90% проблем решаются настройкой суффикса и фокуса.
Сканер штрихкода — самое простое периферийное устройство: он эмулирует клавиатуру и вводит считанный код в активное поле ввода. Проблема в другом — что система делает с этим кодом: ищет товар, добавляет в заказ, проверяет позицию при сборке. Настройка интеграции — это прежде всего правильная обработка сканирования на стороне Битрикс, а не настройка самого сканера. Мы гарантируем, что после настройки система будет работать без сбоев.
Типы сканеров и способы подключения
| Тип |
Подключение |
Эмуляция клавиатуры |
Применение |
| USB HID |
USB |
Да |
Касса, приёмка |
| Bluetooth HID |
Bluetooth |
Да |
Мобильная точка |
| COM-port |
RS-232 |
Нет, прямая работа с портом |
Legacy оборудование |
| 2D-имиджер (Honeywell, Symbol) |
USB/BT |
Да |
QR + штрихкод |
| Встроенный в ТСД |
USB/WiFi |
Через API устройства |
Склад |
Для большинства задач в Битрикс: сканер с эмуляцией клавиатуры подключается без драйверов. Специальной настройки на стороне Битрикс не нужно — достаточно правильно обрабатывать ввод в форме. Однако COM-порт требует прямой работы с портом через API — это сложнее, но наш сертифицированный опыт позволяет реализовать это за 2 дня.
Как найти товар по штрихкоду в Битрикс?
Штрихкоды хранятся в Битрикс в таблице b_catalog_product_barcode. Каждый товар может иметь несколько штрихкодов (например, разные упаковки: 1 шт и блок 12 шт с разными EAN).
public static function findByBarcode(string $barcode): ?array
{
$result = \Bitrix\Catalog\EO_ProductBarcode_Collection::wakeUp(
\Bitrix\Catalog\ProductBarcodeTable::getList([
'filter' => ['=BARCODE' => $barcode],
'select' => ['PRODUCT_ID', 'BARCODE'],
])
);
$row = $result->fetch();
if (!$row) return null;
// Загружаем данные товара из каталога
$product = \CIBlockElement::GetByID($row['PRODUCT_ID'])->GetNext();
return [
'product_id' => $row['PRODUCT_ID'],
'name' => $product['NAME'],
'sku' => $product['PROPERTY_ARTICLE_VALUE'],
'price' => \CCatalogProduct::GetOptimalPrice($row['PRODUCT_ID'])['PRICE']['PRICE'] ?? 0,
'stock' => \CCatalogProduct::GetByID($row['PRODUCT_ID'])['QUANTITY'],
];
}
Если штрихкод не найден в b_catalog_product_barcode — ищем в свойстве PROPERTY_BARCODE инфоблока (некоторые проекты хранят штрихкод как свойство). Унифицируем через единый метод поиска. Наш опыт показывает, что 30% проектов хранят штрихкоды только в свойствах — это в два раза медленнее, чем таблица barcode.
Добавление в корзину по штрихкоду
Компонент быстрого добавления товара для кассы или B2B-раздела:
// Обработчик ввода в поле поиска
const barcodeInput = document.getElementById('barcode-input');
barcodeInput.addEventListener('keydown', (e) => {
if (e.key === 'Enter') {
const barcode = e.target.value.trim();
if (!barcode) return;
fetch('/api/catalog/by-barcode/', {
method: 'POST',
headers: {'Content-Type': 'application/json', 'X-Bitrix-Csrf-Token': BX.bitrix_sessid()},
body: JSON.stringify({barcode})
})
.then(r => r.json())
.then(data => {
if (data.error) {
showError('Товар не найден: ' + barcode);
return;
}
addToCart(data.product_id, 1);
barcodeInput.value = '';
barcodeInput.focus();
});
}
});
Ключевой момент: поле ввода штрихкода должно быть всегда в фокусе. Для касс реализуем автофокус с setInterval — сканер вводит код в любой момент. Если этого не сделать, 80% сканирований будут проигнорированы. Пишите — мы реализуем это под ключ за 7–9 дней.
Проверка позиции при сборке заказа
При комплектации заказа на складе: менеджер открывает заказ в административной панели Битрикс, сканирует штрихкод каждой позиции. Система подсвечивает найденную строку в заказе и ставит галочку «собрано».
Кастомная страница в /bitrix/admin/order_assembly.php:
// AJAX-обработчик сканирования
if ($_REQUEST['action'] === 'scan_barcode') {
$barcode = trim($_REQUEST['barcode']);
$orderId = (int)$_REQUEST['order_id'];
$product = BarcodeService::findByBarcode($barcode);
if (!$product) {
echo json_encode(['status' => 'not_found', 'barcode' => $barcode]);
exit;
}
// Ищем товар в позициях заказа
$order = \Bitrix\Sale\Order::load($orderId);
$basket = $order->getBasket();
foreach ($basket as $item) {
if ($item->getProductId() === $product['product_id']) {
// Обновляем счётчик собранных
AssemblyProgressTable::increment($orderId, $product['product_id']);
echo json_encode(['status' => 'ok', 'item_id' => $item->getId()]);
exit;
}
}
echo json_encode(['status' => 'not_in_order', 'product' => $product['name']]);
exit;
}
Инвентаризация через USB-сканер
Для офисной инвентаризации без ТСД: специальная страница с таблицей, куда менеджер сканирует штрихкоды с фиксическим подсчётом. Каждый скан — AJAX-запрос, который увеличивает счётчик позиции. В конце сессии — сравнение с остатками в b_catalog_store_product и экспорт расхождений. Наше решение позволяет проводить инвентаризацию в 3 раза быстрее, чем ручной пересчёт.
Что делать, если сканер вводит лишние символы?
Некоторые сканеры по умолчанию добавляют символы после штрихкода (Tab, Enter + Carriage Return). Настройки сканера обычно меняются сканированием конфигурационного штрихкода из мануала производителя. Для Bitrix рекомендуем: суффикс = Enter, без префикса, без CR. Если символы не убираются, перепрошейте сканер из комплекта поставки.
Что входит в работу
- Разработка API поиска товара по штрихкоду
- Создание компонента быстрого добавления в корзину
- Интерфейс сборки заказа со сканером
- Модуль инвентаризации с отчётами
- Документация по настройке сканеров и обучение сотрудников
- Поддержка 1 месяц после запуска
Сроки
| Этап |
Срок |
| API поиска товара по штрихкоду |
1 день |
| Компонент быстрого добавления в корзину |
1–2 дня |
| Интерфейс сборки заказа со сканером |
2–3 дня |
| Инвентаризационный модуль |
2 дня |
| Тестирование с реальным сканером |
1 день |
| Итого |
7–9 дней |
Закажите интеграцию под ключ — мы оценим ваш проект за 1 день. Свяжитесь с нами, чтобы получить консультацию. Гарантируем качество и сроки.
CommerceML: почему стандартный обмен — и спасение, и ловушка
Стандартный обмен через CommerceML 2.0 на типовой «Управлении торговлей» или «Комплексной автоматизации» заводится за день-два. Товары, цены, остатки, заказы — всё через XML-файлы по расписанию. Для магазина на 3 000 позиций с парой обновлений в сутки этого хватает с запасом. Но как только каталог перерастает 30 000 SKU, начинаются проблемы: интеграция 1С с Битрикс на больших объёмах требует нестандартных решений.
Почему CommerceML тормозит на каталогах свыше 100 000 товаров?
bitrix_1c_exchange.php генерирует XML на стороне Битрикса, 1С забирает и парсит. На больших каталогах парсер активно пишет во временную таблицу b_xml_tree — MySQL может встать колом. Мы видели проект, где стандартный обмен 180 000 товаров занимал 6 часов и полностью блокировал сервер: ни админка, ни фронт не открывались. Решение — инкрементальный обмен. В настройках узла обмена на стороне 1С ставим «Выгружать только изменённые» и разбиваем выгрузку на пакеты по 500–1000 элементов. На стороне Битрикса — кастомный обработчик, который не пересоздаёт b_xml_tree каждый раз, а работает через CIBlockXMLFile::ReadXMLToDatabase() с контролем порций. Каталог в 200 000 SKU обновляется за 8–12 минут.
Ещё один подводный камень — EXTERNAL_ID. При повторном импорте Битрикс сопоставляет элементы инфоблоков по внешнему коду. Если в 1С товар удалён и создан заново с новым GUID, на сайте появляется дубль — со старыми отзывами на одной карточке и нулевыми на другой. Лечится жёсткой привязкой по артикулу через кастомный обработчик события OnBeforeIBlockElementAdd.
Как избежать дублей при повторном импорте?
Привязываем товары не по GUID, а по артикулу. Проверка на уникальность выполняется до записи в инфоблок — дубликаты исключаются даже после пересоздания номенклатуры в 1С. На одном проекте с 50 000 товаров такая схема предотвратила появление 300 дублей в месяц и сэкономила контент-менеджерам около 20 часов ручной чистки.
Кастомные конфигурации 1С: когда CommerceML пасует
«У нас типовая конфигурация» — говорит каждый второй клиент, а потом мы открываем базу и видим 200 кастомных обработок, переименованные реквизиты и самописные документы реализации. CommerceML работает с фиксированной структурой XML. Если в 1С изменили состав реквизитов номенклатуры или добавили нестандартный документ — обмен молча пропускает эти данные. Или падает с непонятной ошибкой в журнале регистрации 1С, а в Битрикс ничего не пишется.
В таких случаях делаем кастомную выгрузку. На стороне 1С пишем обработку, которая формирует JSON (парсить быстрее, отлаживать проще) и отправляет через REST API Битрикса. Полный контроль: какие поля берём, как трансформируем, что делаем при конфликте. Для тяжёлых случаев — D7 API с прямой работой через \Bitrix\Catalog\ProductTable и \Bitrix\Sale\Order.
| Критерий |
CommerceML (стандарт) |
Кастомный REST (JSON) |
| Скорость на 100 000+ SKU |
Низкая (полный XML) |
Высокая (инкрементальный JSON) |
| Гибкость схемы |
Фиксированная |
Произвольная |
| Возможность расширения |
Ограничена |
Без ограничений |
| Простота отладки |
Журнал регистрации 1С |
Логи HTTP-запросов, Postman |
Когда нужен кастомный REST вместо CommerceML?
Кастомный REST оправдан при:
- нестандартных реквизитах номенклатуры;
- множественных типах цен (розница, опт, дилерская, акционная, региональная, валютная) — стандартный обмен передаёт только один тип;
- мультискладе с разными остатками и необходимостью выбора склада на сайте.
Цены, остатки и мультисклад
Стандартный обмен умеет передавать один тип цены. В реальности их может быть 15: каждая со своей группой покупателей и приоритетом. Маппинг между ценовыми группами 1С и группами пользователей Битрикса — отдельная инженерная задача. Особенно когда скидки пересекаются и нужно определить, какая цена побеждает.
Мультисклад добавляет ещё один слой: товар есть на складе в Москве, нет в Питере, и «под заказ» в Новосибирске. На сайте нужно показать наличие по каждой точке, подключить выбор пункта самовывоза и рассчитать доставку от ближайшего склада, где товар физически есть. Стандартный модуль складского учёта Битрикс (catalog.store) справляется с отображением, но логику «откуда отгружать» пишем отдельно. Для одного производственного холдинга мы реализовали кастомный агрегатор остатков, который за 2 секунды рассчитывал баланс по 8 складам — это сократило количество ошибок отгрузки на 80%.
Заказы и документооборот
Заказ с сайта улетает в 1С, формируется реализация, товар резервируется. Статусы возвращаются обратно. Главный нюанс — частичная отгрузка: клиент заказал 5 позиций, 3 есть на складе, 2 придут через неделю. 1С формирует два документа реализации. Битрикс из коробки не умеет разбивать один заказ на несколько отгрузок — дорабатываем обработчик OnSaleOrderSaved, который создаёт дочерние заказы и синхронизирует статусы по каждому.
Документы в личном кабинете — счета, акты, накладные из 1С — отдаём через REST, PDF генерируется на стороне 1С и кэшируется на CDN. Покупатель скачивает не из 1С напрямую (это убило бы сервер), а из кэша.
Рекомендация CommerceML: пакетный импорт с контролем порций снижает нагрузку на MySQL и исключает блокировки (источник: Wikipedia).
Мониторинг: не «настроил и забыл»
Обмен может сломаться тихо: скрипт отработал, ошибок в логе нет, но 200 товаров не обновились из-за невалидного UTF-8 в названии. Или 1С поменяла формат даты в очередном обновлении — все цены пришли нулевыми.
Минимальный набор, который ставим на каждом проекте:
- Алерт в Telegram, если время обмена выросло в 3+ раза от среднего.
- Проверка расхождения остатков: скрипт сравнивает
b_catalog_product.QUANTITY с тем, что отдаёт 1С, и оповещает при дельте больше 5 %.
- Дашборд: последняя синхронизация, количество обработанных позиций, очередь, ошибки.
Для проектов с высокой нагрузкой добавляем асинхронные очереди на Redis или RabbitMQ. Обмен не блокирует веб-сервер, данные не теряются при кратковременном падении 1С. На одном интернет-магазине с оборотами 2 млн заказов в год мы внедрили такую схему — время восстановления после сбоев сократилось с 3 часов до 10 минут.
Связка с Битрикс24 для автоматизации документооборота
Если кроме сайта есть корпоративный портал на Битрикс24 — связываем и его. Контрагенты из CRM летят в 1С, счета из 1С появляются в карточке сделки. Менеджер видит дебиторку и взаиморасчёты, не переключаясь между окнами. Закрыли сделку — документы сформировались сами.
Оплата поступила в 1С → логист получает задачу на отгрузку в Битрикс24. Товар отгружен → менеджер видит уведомление. Автоматические задачи по событиям из 1С — через вебхуки Битрикс24 REST API. Такая связка сокращает ручной ввод на 70% и исключает забытые отгрузки.
Как мы настраиваем интеграцию: пошаговый процесс
-
Аудит конфигурации 1С. Смотрим структуру справочников, документов, реквизитов. Выявляем кастомные доработки. Оцениваем объём данных (количество SKU, заказов, складов).
-
Проектирование схемы обмена. Согласовываем набор данных: товары, цены, остатки, заказы, документы. Определяем интервал синхронизации и механизм — CommerceML или кастомный REST.
-
Настройка стандартного обмена. Настраиваем CommerceML, пакетный режим, привязку по артикулу. Проверяем корректность передачи данных на тестовом каталоге.
-
Расширенная интеграция. Для сложных конфигураций пишем кастомные обработчики на стороне 1С и Битрикса. Подключаем мультисклад, множественные цены, частичную отгрузку.
-
Мониторинг и гарантия. Устанавливаем алерты, дашборд, документацию. Обучаем операторов. После запуска — гарантийная поддержка.
Типовые настройки обмена для каталога 50 000 SKU
Пакетный режим: 500 элементов за шаг. Привязка по артикулу. Период синхронизации: каждые 15 минут. Используем агенты Битрикса с тегированным кэшированием. На стороне 1С — обработка формирования JSON вместо XML для ускорения.
Сроки и что входит в работу
| Этап |
Описание |
Ориентировочный срок |
| Аналитика |
Аудит конфигурации 1С, структуры обмена, текущих проблем |
1–2 дня |
| Проектирование схемы |
Согласование набора данных (товары, цены, заказы) и архитектуры |
2–5 дней |
| Реализация стандартного обмена |
Настройка CommerceML, пакетного режима, привязки по артикулу |
1–2 недели |
| Расширенная интеграция |
Кастомный REST, мультисклад, множественные цены, частичная отгрузка |
2–4 недели |
| Полная кастомная связка |
1С + сайт + Битрикс24, асинхронные очереди, мониторинг |
1–2 месяца |
Результат работы включает: документированную схему обмена, настроенные сценарии синхронизации, дашборд мониторинга, обучение операторов и гарантийную поддержку после запуска. Стоимость рассчитывается индивидуально — она зависит от сложности конфигурации 1С, объёма каталога и необходимой степени автоматизации. Оценим ваш проект за 1 день — пишите, обсудим. Закажите интеграцию — получите стабильный обмен за 1–2 недели.
Мы провели более 50 интеграций 1С для интернет-магазинов и производственных компаний. Средний опыт команды — 7 лет, у нас есть сертифицированные специалисты 1С-Битрикс. Наш опыт гарантирует, что обмен не сломается в первый же месяц и будет стабильно работать годами. Например, на проекте с каталогом 50 000 товаров автоматизация обмена сэкономила клиенту около 200 000 рублей в год на операционных затратах.
Свяжитесь с нами для бесплатного аудита вашей конфигурации 1С — найдём узкие места и предложим оптимальное решение.