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