Інтеграція з 1С:Підприємство: обмін товарами, замовленнями, остатками
Утро понеділка. Менеджер відкриває сайт і бачить, що позиція, яку розпродали в п'ятницю, досі «в наявності». Три клієнти вже оплатили замовлення на товар, якого немає. Це класична біль відсутності синхронізації між 1С та інтернет-магазином.
1С — облікова система більшості російських компаній. Сайт — вітрина. Вони повинні говорити однією мовою та робити це регулярно, надійно та без втрати даних.
Протоколи та підходи
CommerceML 2.x — стандартний протокол обміну, який підтримують 1С:Управління торгівлею, 1С:Комплексна автоматизація та низка інших конфігурацій. WooCommerce та деякі інші CMS мають вбудовану підтримку (1С-Bitrix плагін для своїх продуктів, окремі плагіни для WordPress). Потік: 1С ініціює обмін → відправляє ZIP-архів з XML на endpoint сайту → сайт розбирає, оновлює каталог.
CommerceML формат — XML зі своєю схемою: KommercheskayaInformacija, Klassifikator, Katalog, PaketPredlozhenij. Категорії, товари, характеристики, зображення, ціни, остатки. Головна складність — ієрархія характеристик у 1С та атрибути товарів на сайті не завжди співпадають один до одного. Вимагає маппінгу.
REST API напрямку. Для нестандартних конфігурацій 1С або коли CommerceML не підходить — пишемо HTTP-сервіс у 1С (вбудована можливість починаючи з версії 8.3) та взаємодіємо через REST JSON. Це дає повний контроль над структурою даних та частотою синхронізації, але вимагає розробки зі сторони 1С-програміста.
Message Broker. Для enterprise-задач з кількома обліковими системами — Message Broker (RabbitMQ, Apache Kafka) як посередник. 1С публікує события в очередь, сайт підписується та обробляє. Гарантована доставка, буферизація при недоступності однієї зі сторін.
Що синхронізуємо та як
Каталог (товари, категорії, характеристики). Найбільш об'ємна частина. Повна виявлення при першому запуску, дельта-оновлення далі. При імпорті CommerceML: парсимо XML через PHP SimpleXML або XMLReader (для великих файлів — тільки XMLReader, інакше memory limit). Сопоставляємо товари по ID з 1С, який зберігаємо в окремому полі БД. Якщо товар видалений у 1С — ховаємо на сайті, не видаляємо (історія замовлень може посилатися).
Остатки та ціни. Це окремий PaketPredlozhenij у CommerceML, оновлюється чатіше каталогу. Критично робити атомарно: не оновлювати остаток по одному, а транзакцією. Інакше у момент оновлення користувач може бачити неконсистентне стан. Частота: раз на годину для спокійного режиму, раз в 5–15 хвилин для активної торгівлі.
Замовлення. Двосторонній обмін. Сайт → 1С: нове замовлення передається з номенклатурою, кількістю, цінами, контактними даними покупця. 1С → сайт: статус замовлення (оплачено, зібрано, відправлено, доставлено). Для передачі замовлень — або той же CommerceML (блок Dokumenty), або прямий REST-виклик при створенні замовлення на сайті.
Типові проблеми, які вирішуємо
Дублювання товарів. 1С-оператор створив позицію з опечаткою в артикулі, потім виправив. На сайті — два товари. Рішення: сопоставлення по GUID з 1С (не по артикулу), GUID незмінний.
Кирилиця у XML та кодування. 1С історично працює з Windows-1251. CommerceML файл може прийти в CP1251, PHP очікує UTF-8. mb_convert_encoding() або iconv() у перших рядках парсера — обов'язково.
Таймаути при великій виявленні. Каталог із 100,000 позицій — це 50–200MB XML. PHP default execution time 30s не хватить. Рішення: CLI-команда (Laravel Artisan або Symfony Console), запускається через cron, без HTTP timeout. Або chunked processing через XMLReader з частковими коммітами в БД.
Зображення. 1С може передавати зображення Base64 всередині XML (розпухає файл у 1.3 раза) або посиланнями на файли. Другий варіант краще. Завантажуємо асинхронно, конвертуємо в WebP, кладемо в медіабібліотеку.
Кейс: інтернет-магазин запчастин, 85,000 SKU. Синхронізація через CommerceML кожні 30 хвилин. Проблема: повна виявлення займала 18 хвилин, у результаті нова виявлення починалася, поки стара ще йшла. Рішення: lock через Redis (SET nx ex), дельта-виявлення (тільки змінені позиції за останні 2 години через фільтр у 1С), обробка через очередь з 20 паралельними workers. Час синхронізації: 18 хвилин → 2.5 хвилини, конфліктів нема.
Процес та строки
Аудит конфігурації 1С (версія, тип конфігурації, можливості виявлення) → проектування маппінгу даних → розробка приймача на сайті та відправника у 1С → тестування на реальних даних → налаштування розпису → моніторинг перших обмінів.
Участь 1С-програміста зі сторони клієнта — обов'язково або ми залучаємо перевіреного спеціаліста.
| Сценарій | Строк |
|---|---|
| CommerceML, каталог + остатки, WooCommerce | 2–4 тижні |
| Двосторонній обмін замовленнями | +2–3 тижні |
| Кастомна конфігурація 1С, REST API | 4–8 тижнів |
| Enterprise: кілька баз 1С, шина даних | 2–4 місяці |
Вартість розраховується індивідуально.