Інтеграція 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). Налаштування сканера зазвичай змінюються скануванням конфігураційного штрихкоду з мануалу виробника. Для Бітрікс рекомендуємо: суфікс = 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С — знайдемо вузькі місця та запропонуємо оптимальне рішення.