Обмен 1С и 1С-Битрикс часто называют типовой настройкой, но типовым бывает только транспорт и часть формата. Реальные правила бизнеса — виды цен, склады, характеристики, резервы, статусы заказов, удаление товаров — отличаются. Если их не зафиксировать до запуска, технически успешная выгрузка может оставить на сайте неверную цену, создать дубли или повторно отправить заказ.
У меня пока нет отдельного опубликованного кейса именно о чистом обмене 1С с 1С-Битрикс. Поэтому здесь нет попытки выдать интеграцию с CRM или службой доставки за кейс 1С. Статья опирается на устройство CommerceML, практику диагностики обменов и общие требования к надёжным интеграциям. Конкретную реализацию всегда нужно сверять с конфигурацией 1С, редакцией Битрикс и бизнес-процессом компании.
Что такое CommerceML и чего он не решает
CommerceML — XML-формат, который используется для передачи коммерческих данных между учётной системой и сайтом. В типичном сценарии 1С формирует файлы с классификатором, каталогом, предложениями, ценами и остатками, а Битрикс принимает и разбирает их. В обратную сторону сайт может передавать заказы.
Формат описывает структуру сообщений, но не принимает бизнес-решения. Он не знает:
- какой вид цены показывать розничному и оптовому покупателю;
- как трактовать доступный остаток с учётом резерва;
- что делать с товаром, исчезнувшим из выгрузки;
- какой статус заказа считать разрешением на отгрузку;
- должна ли 1С или сайт быть владельцем названия, описания и изображений;
- как сопоставить старые товары, если изменились идентификаторы.
Эти правила необходимо оформить отдельно. Иначе одна сторона будет считать поле главным, а другая — перезаписывать его при каждом обмене.
Выберите подход: типовой, кастомный или гибридный
Типовой обмен подходит, когда конфигурация 1С близка к поддерживаемой, каталог сайта ещё не оброс независимой логикой, а цены, остатки и заказы укладываются в стандартный сценарий. Его преимущество — меньше собственного кода и понятнее обновление. Но слово «типовой» не отменяет настройки соответствий и тестирования.
Кастомный обмен нужен, когда данные или процесс принципиально не помещаются в стандартный механизм: собственные справочники, особые расчёты, нестандартный жизненный цикл заказа, другая транспортная схема. Он даёт контроль, но создаёт код, который придётся сопровождать, документировать и проверять после изменений обеих систем.
Гибридный подход сохраняет стандартный протокол там, где он подходит, и добавляет ограниченные преобразования или отдельные каналы для исключений. Часто это практичнее полной замены: базовая номенклатура и заказы идут штатно, а специфические реквизиты обрабатываются расширением. Граница кастомизации должна быть явно описана — иначе после обновления никто не поймёт, где заканчивается стандарт и начинается собственная логика.
Решение следует принимать после обследования, а не по предпочтению разработчика. На странице интеграции 1С и сайта перечислены задачи, которые стоит обсудить до оценки работ.
Чек-лист данных в 1С
1. Конфигурация и расширения
Запишите точное название и версию конфигурации, платформы, модуля обмена и всех расширений, влияющих на номенклатуру, цены, склады и заказы. Уточните, можно ли обновлять конфигурацию типовым способом. Фраза «обычная Управление торговлей» недостаточна, если внутри изменены реквизиты или алгоритмы.
2. Устойчивые идентификаторы
У товара, предложения, группы, свойства, вида цены и склада должен быть идентификатор, который не меняется от выгрузки к выгрузке. На стороне Битрикс обычно ключевую роль играет XML_ID. Артикул и название не подходят как единственный ключ: они могут быть неуникальны или измениться.
До первого боевого импорта проверьте:
- нет ли одинаковых идентификаторов у разных сущностей;
- сохраняются ли они при переносе базы или объединении справочников;
- как будут сопоставлены уже существующие товары сайта;
- что произойдёт при смене владельца данных.
Создание дублей часто связано не с «ошибкой Битрикс вообще», а с тем, что входящую позицию невозможно однозначно связать с существующей.
3. Номенклатура и характеристики
Определите, что является товаром, а что торговым предложением. Цвет, размер или фасовка могут храниться как характеристики 1С и превращаться в SKU на сайте, но это нужно согласовать со структурой каталога. Уточните единицы измерения, коэффициенты упаковки, наборы, серии и варианты.
Не выгружайте все реквизиты просто потому, что они есть. Составьте таблицу соответствий: источник, поле CommerceML, назначение в Битрикс, направление обмена, правило преобразования и поведение при пустом значении.
4. Цены, валюта и НДС
Зафиксируйте виды цен и аудитории, которым они доступны. Определите, передаётся готовая цена или сайт рассчитывает её по правилам. Проверьте валюту, округление, включение НДС, скидки и периоды действия.
Особенно опасен частично обновившийся набор цен: одна цена уже новая, другая осталась старой. Приёмочные тесты должны проверять не только наличие значения, но и согласованность всех типов цен.
5. Склады, остатки и резервы
Количество в учётной системе не всегда равно доступности для покупки. Нужно решить, учитываются ли резервы, товары в пути, отрицательные остатки, несколько складов и сроки поставки. Для нулевого остатка отдельно задайте поведение: скрывать товар, запрещать заказ, принимать предзаказ или показывать срок.
Чек-лист сайта
Проверьте редакцию и модули 1С-Битрикс, структуру инфоблоков, торговые предложения, типы цен и склады. Для простого магазина может подойти продуктовая редакция уровня «Малый бизнес», а многосклад и сложная многоценовость требуют проверки возможностей редакции «Бизнес». Наличие функции в лицензии ещё не означает готовность конкретного сайта: шаблон и доработки могут менять стандартный сценарий.
Ответьте на вопросы:
- какие поля редактируются только в 1С, только на сайте или в обеих системах;
- сохранятся ли SEO-тексты и изображения после повторного импорта;
- как обрабатываются деактивированные и удалённые позиции;
- нужна ли полная выгрузка или достаточно изменений;
- где хранится соответствие идентификаторов;
- что видит пользователь, пока большой импорт ещё не завершён.
Полный импорт полезен для первичной синхронизации и восстановления, но не должен быть единственным рабочим режимом для большого каталога без проверки нагрузки.
Заказы: отдельный договор данных
Обратный обмен заказами часто сложнее импорта каталога. Нужно согласовать момент отправки заказа, контрагента, состав, скидки, доставку, оплату, комментарии, реквизиты юридического лица и статусы.
Критичный вопрос — идемпотентность. Повторная отправка того же сообщения не должна создавать второй заказ. Для этого нужен устойчивый внешний идентификатор и правило обновления существующего документа. Также задайте направление статусов: какие меняет сайт, какие 1С, что происходит при отмене и допускается ли обратный переход.
Проверьте заказы с обычным товаром, SKU, скидкой, доставкой, онлайн-оплатой, юридическим лицом и отсутствующим реквизитом. «Один тестовый заказ прошёл» — недостаточная приёмка.
Логи, без которых обмен нельзя сопровождать
У надёжного обмена есть журнал на обеих сторонах. Минимально полезная запись содержит время, направление, идентификатор запуска, тип сообщения, имя или контрольную сумму файла, количество обработанных сущностей, предупреждения и ошибку с контекстом.
Логи не должны содержать пароли, токены, платёжные данные и лишние персональные сведения. Доступ к ним ограничивают, а срок хранения согласуют. При этом сообщения уровня «ошибка импорта» недостаточно: должно быть понятно, на каком файле и сущности остановилась обработка.
Кроме текстовых журналов нужны контрольные показатели: время последнего успешного запуска, длительность, число обновлённых товаров и заказов, объём очереди. Резкое падение числа обновлений может быть таким же сигналом, как явная ошибка.
Частые режимы отказа
- Дубли товаров. Изменился или потерялся внешний идентификатор, либо импорт сопоставляет сущность по нестабильному полю.
- Расхождение цен. Неверно сопоставлены виды цен, не согласован НДС или одна часть пакета не обработалась.
- Остатки не обновляются. Неизвестный склад, неправильное правило доступности, зависшая очередь или кеш сайта.
- Импорт обрывается. Таймаут, нехватка памяти или диска, слишком большой пакет, повреждённый XML.
- Заказы создаются дважды. Нет идемпотентного ключа или повторный ответ трактуется как новый документ.
- Обмен «успешен», но данных нет. Транспорт завершился без ошибки, однако сообщения содержат предупреждения или сущности были пропущены.
- После обновления всё меняется. Собственная правка внесена в типовой модуль без документации и проверки совместимости.
Сбой не следует автоматически объяснять изменением конфигурации 1С. Причина может быть на сайте, в сети, правах файлов, сертификате, расписании, данных или ресурсах сервера. Диагностика начинается с временной линии и журналов обеих систем.
Как проводить запуск
Сначала сделайте резервные копии файлов, базы сайта и базы 1С по правилам вашей инфраструктуры. Подготовьте тестовый контур с обезличенными данными, если это необходимо. На нём выполните первичный импорт и повторный импорт того же набора: второй запуск не должен создавать дубли или разрушать ручные данные, которые сайт обязан сохранять.
Затем протестируйте изменение названия, цены, остатка и характеристики; деактивацию; новый товар; удаление; заказ и повторную отправку. Отдельно проверьте восстановление после обрыва в середине пакета. Зафиксируйте критерии приёмки и ответственных с обеих сторон.
Боевой запуск лучше проводить в согласованное окно с планом отката. После него сравните контрольную выборку товаров и заказов между системами, проверьте журнал и наблюдайте несколько циклов. Если проект передаётся другой команде, включите регламент обмена, расписание, доступ к логам и процедуру восстановления в чек-лист передачи проекта.
Итог
Хороший обмен — не тот, который один раз перенёс каталог, а тот, который предсказуемо переживает повторный запуск, частичный сбой и изменение данных. CommerceML даёт основу, но владельцев полей, идентификаторы, цены, остатки, статусы, журналы и восстановление нужно проектировать явно. Если эти решения приняты до разработки, типовой, кастомный или гибридный вариант можно выбирать по реальной сложности, а не по обещанию «всё заведётся автоматически».