Интеграция 1С-Битрикс с 1С:Предприятие
CommerceML: почему стандартный обмен — это и спасение, и ловушка
Модуль обмена на базе CommerceML 2.0 — первое, что подключают. И правильно: с типовой Управлением торговлей или Комплексной автоматизацией он заводится за день-два. Товары, цены, остатки, заказы — всё через XML-файлы по расписанию. Для магазина на 3 000 позиций с парой обновлений в сутки этого хватает с запасом.
Проблемы начинаются, когда каталог перерастает 30 000 SKU.
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.
Когда CommerceML уже не тянет
Сильно доработанная 1С — это не исключение, это норма. «У нас типовая конфигурация» — говорит каждый второй клиент, а потом мы открываем базу и видим 200 кастомных обработок, переименованные реквизиты и самописные документы реализации.
CommerceML работает с фиксированной структурой XML. Если в 1С изменили состав реквизитов номенклатуры или добавили нестандартный документ — обмен молча пропускает эти данные. Или падает с непонятной ошибкой в журнале регистрации 1С, а в Битрикс вообще ничего не пишется.
В таких случаях делаем кастомную выгрузку. На стороне 1С пишем обработку, которая формирует JSON (не XML — парсить быстрее, отлаживать проще) и отправляет через REST API Битрикса. Полный контроль: какие поля берём, как трансформируем, что делаем при конфликте. Для совсем тяжёлых случаев — D7 API с прямой работой через \Bitrix\Catalog\ProductTable и \Bitrix\Sale\Order.
Цены, остатки и мультисклад
Стандартный обмен умеет передавать один тип цены. В реальности их может быть 15: розничная, оптовая, дилерская, акционная, региональная, валютная. Плюс у каждой — своя группа покупателей и приоритет. Маппинг между ценовыми группами 1С и группами пользователей Битрикса — отдельная инженерная задача. Особенно весело, когда скидки пересекаются и нужно определить, какая цена побеждает.
Мультисклад добавляет ещё один слой: товар есть на складе в Москве, нет в Питере, и «под заказ» в Новосибирске. На сайте нужно показать наличие по каждой точке, подключить выбор пункта самовывоза и рассчитать доставку от ближайшего склада, где товар физически есть. Стандартный модуль складского учёта Битрикс (catalog.store) справляется с отображением, но логику «откуда отгружать» пишем отдельно.
Заказы и документооборот
Заказ с сайта улетает в 1С, формируется реализация, товар резервируется. Статусы возвращаются обратно. На бумаге — просто. На практике — нюансы.
Главный: частичная отгрузка. Клиент заказал 5 позиций, 3 есть на складе, 2 придут через неделю. 1С формирует два документа реализации. Битрикс из коробки не умеет разбивать один заказ на несколько отгрузок — дорабатываем обработчик OnSaleOrderSaved, который создаёт дочерние заказы и синхронизирует статусы по каждому.
Документы в личном кабинете — счета, акты, накладные из 1С — отдаём через REST, PDF генерируется на стороне 1С и кэшируется на CDN. Покупатель скачивает не из 1С напрямую (это убило бы сервер), а из кэша.
Мониторинг: не «настроил и забыл»
Обмен может сломаться тихо. Скрипт отработал, ошибок в логе нет, но 200 товаров не обновились из-за невалидного UTF-8 в названии. Или 1С поменяла формат даты в очередном обновлении, и все цены пришли нулевыми.
Минимальный набор, который ставим на каждом проекте:
- Алерт в Telegram, если время обмена выросло в 3+ раза от среднего
- Проверка расхождения остатков: скрипт сравнивает
b_catalog_product.QUANTITYс тем, что отдаёт 1С, и кричит при дельте больше 5% - Дашборд: последняя синхронизация, количество обработанных позиций, очередь, ошибки
Для проектов с высокой нагрузкой добавляем асинхронные очереди на Redis или RabbitMQ. Обмен не блокирует веб-сервер, данные не теряются при кратковременном падении 1С.
Связка с Битрикс24
Если кроме сайта есть корпоративный портал на Битрикс24 — связываем и его. Контрагенты из CRM летят в 1С, счета из 1С появляются в карточке сделки. Менеджер видит дебиторку и взаиморасчёты, не переключаясь между окнами. Закрыли сделку — документы сформировались сами.
Оплата поступила в 1С → логист получает задачу на отгрузку в Битрикс24. Товар отгружен → менеджер видит уведомление. Автоматические задачи по событиям из 1С — через вебхуки Битрикс24 REST API.
Стоимость
Типовой обмен каталогом и заказами через CommerceML — от 50 000 ₽, запускается за 1-2 недели. Расширенный обмен с мультискладом, типами цен и контрагентами — от 120 000 ₽. Полная кастомная интеграция 1С + сайт + Битрикс24 — от 250 000 ₽, срок 1-2 месяца. Окупается за 2-6 месяцев: магазин с 5 000 товаров экономит 40-80 часов ручной работы оператора в месяц, а автоматическая синхронизация остатков убирает ситуации «заказал — а товара нет».