Обмен сайта на 1С-Битрикс с 1С: товары, остатки и заказы

Обмен между интернет-магазином на 1С-Битрикс и 1С нужен, чтобы не переносить каталог, цены, остатки и заказы вручную. Обычно 1С становится источником товарных данных, сайт принимает изменения и передаёт обратно заказы. Но направление обмена, состав полей и момент передачи заказа нужно согласовать до настройки: универсальной схемы для всех компаний нет.

Штатные компоненты 1С-Битрикс поддерживают обмен каталогом в формате CommerceML v2, а настройки магазина позволяют управлять импортом каталога и обменом заказами. Конкретные возможности зависят от конфигурации 1С, версии модуля обмена и редакции сайта. Поэтому работу начинают не с включения расписания, а с карты данных и тестового сценария.

Какие данные передаются между сайтом и 1С

Официальное описание интеграции отдельно перечисляет номенклатуру, разделы, цены, остатки по складам, характеристики и изображения. Для заказов поддерживаются разные модели: обработка на сайте, обработка в 1С или комбинированная схема. Это не означает, что все поля заработают автоматически в конкретной базе — соответствия всё равно нужно проверить.

Как работает типовой обмен

Для каталога используется последовательность запросов между 1С и служебной страницей обмена на сайте. Стороны авторизуются, передают файлы CommerceML, после чего Битрикс разбирает данные и обновляет инфоблок, торговый каталог, цены и остатки. Большие выгрузки могут обрабатываться частями, чтобы один запрос не занимал слишком много времени.

Заказы передаются отдельным сценарием. В профиле задают, заказы какого сайта выгружать, какие статусы учитывать и как обрабатывать изменения. Запуск может выполняться вручную, по расписанию или другим способом, который поддерживает установленный модуль и конфигурация.

Штатный механизм удобен, когда структура данных укладывается в CommerceML и стандартные сущности магазина. Если бизнес использует необычные справочники, несколько учётных систем или собственный порядок резервирования, поверх типового обмена может потребоваться доработка или отдельный API.

Что определить до первой настройки

1. Какая система является источником истины. Например, название и остаток меняются только в 1С, а SEO-описание и фотографии — только на сайте.
2. Какие сущности участвуют. Товары, предложения, склады, типы цен, единицы, контрагенты, заказы, оплаты и отгрузки.
3. Как связаны идентификаторы. Нельзя надёжно сопоставлять товары только по названию: оно меняется и может повторяться.
4. Когда передаётся заказ. Сразу после оформления, после оплаты, после проверки менеджером или при переходе в определённый статус.
5. Кто может менять заказ после передачи. Иначе менеджер исправит состав в 1С, покупатель — на сайте, а следующий обмен перезапишет изменения.
6. Как часто нужны обновления. Расписание зависит от объёма каталога, частоты изменения остатков и допустимой задержки.

Результат этого этапа — небольшая таблица соответствий. Для каждого поля указывают источник, направление, формат, обязательность и правило при конфликте. Такая таблица быстрее выявляет разногласия, чем попытка отладить их уже после полной выгрузки.

Безопасный порядок запуска обмена

1. Проверить версии и совместимость. Фиксируют конфигурацию и релиз 1С, редакцию и версию Битрикс, установленный модуль обмена и доступные обновления.
2. Сделать резервные копии. Нужны актуальная копия базы 1С и сайта, а также понятный порядок восстановления.
3. Настроить тестовую среду. Первую выгрузку не запускают сразу на рабочем каталоге, особенно если на сайте уже есть товары и заказы.
4. Проверить небольшой набор данных. Несколько товаров с характеристиками, разными ценами, остатками, изображениями и единицами измерения показывают большую часть проблем.
5. Согласовать результат. Проверяют карточки, фильтры, наличие, цены и поведение заказа на контрольном сценарии.
6. Выполнить полную выгрузку. После неё сравнивают количество сущностей, журнал ошибок и выборочные позиции.
7. Включить регулярный обмен. Расписание задают только после стабильного повторного запуска на тестовых данных.

Как проверить каталог после выгрузки

Факт появления товаров ещё не означает, что каталог готов. Для приёмки выбирают несколько контрольных позиций: простой товар, товар с характеристиками, позицию с несколькими ценами, остатками на разных складах и изображениями.

• разделы и товары не создаются повторно после следующего обмена;
• торговые предложения связаны с правильным товаром;
• цены попадают в нужные типы и отображаются для правильных групп покупателей;
• остатки соответствуют выбранным складам и правилам доступности;
• единицы измерения и коэффициенты не меняют количество в корзине;
• свойства сохраняют типы и участвуют в фильтре;
• удалённые или скрытые позиции обрабатываются по согласованному правилу;
• ручные SEO-поля сайта не перезаписываются товарной выгрузкой.

Как проверить обмен заказами

Контрольный заказ должен пройти тот же путь, что и реальная покупка. Недостаточно увидеть документ в 1С — важно сравнить состав, суммы и дальнейшие изменения.

• новый заказ передаётся один раз и не создаёт дубль при повторном обмене;
• товары сопоставляются по идентификаторам, а не превращаются в произвольные строки;
• цена, скидка, налог, доставка и итоговая сумма совпадают;
• физическое и юридическое лицо создаются по правильным правилам;
• оплата и доставка соответствуют справочникам учётной системы;
• изменение статуса возвращается на сайт, если это предусмотрено процессом;
• отмена, частичное изменение и повторный заказ не нарушают синхронизацию;
• покупатель видит только те сведения, которые предназначены для личного кабинета.

Почему обмен работает нестабильно

Несовпадают идентификаторы

Товар уже существует на сайте, но был создан вручную или загружен из другого источника. Если внешние коды не сопоставлены, следующая выгрузка создаёт дубль либо обновляет не ту запись.

Не согласованы характеристики и предложения

Цвет, размер и другие варианты могут храниться в 1С и на сайте по-разному. Из-за этого предложения теряют связь с товаром, фильтр показывает лишние значения, а остаток становится общим вместо отдельного.

Сложная система цен и складов

Несколько типов цен, регионов, соглашений и складов требуют явных правил. Нельзя заранее считать, что любой тип цены должен показываться всем посетителям или что остатки нужно просто суммировать.

Выгрузка слишком велика для текущих ограничений

Большие изображения, длинная история изменений, медленные обработчики и ограничения сервера увеличивают время обмена. В этом случае проверяют поэтапную обработку, журнал, ресурсы сервера и код, который запускается при обновлении элементов.

Данные меняют одновременно в двух системах

Если одно поле редактируют и на сайте, и в 1С без правила приоритета, обмен начинает перезаписывать работу сотрудников. Для каждого спорного поля нужен владелец.

Когда нужен API вместо типового CommerceML

Собственная интеграция оправдана, когда нужно работать с нестандартными сущностями, обмениваться данными с несколькими системами, получать события почти без задержки или строго контролировать каждую операцию. Но API не отменяет карту данных, идентификаторы, журналирование и тесты — он только меняет транспорт и логику обработки.

Иногда лучше сохранить типовой обмен для каталога, а отдельный процесс использовать для узкой задачи: резервирования, персональных цен, статусов производства или документов. Такой гибрид проще поддерживать, чем полная замена рабочего механизма.

Что прислать для оценки интеграции

• конфигурацию и версию 1С;
• редакцию и версию 1С-Битрикс;
• пример структуры каталога и число товаров и предложений;
• список типов цен, складов и групп покупателей;
• сценарий обработки заказа от оформления до отгрузки;
• описание текущей ошибки или журнала обмена, если интеграция уже настроена;
• ограничения: несколько сайтов, регионов, юридических лиц или учётных баз.

По этим данным можно отделить типовую настройку от разработки и составить план тестирования. Если проект только планируется, интеграцию стоит учесть ещё при проектировании каталога и оформления заказа.

Короткие ответы

Можно ли обмениваться только остатками и ценами?

Да, состав обмена настраивают под процесс, но нужно проверить, как товары будут сопоставляться и какая система отвечает за остальные поля.

Можно ли запускать обмен в реальном времени?

Возможность зависит от конфигурации 1С, версии модуля и сценария. Для многих проектов достаточно расписания; требование к допустимой задержке лучше определить до выбора режима.

Что делать, если товары уже заведены на сайте?

Сначала сопоставить внешние идентификаторы на тестовой копии. Запуск полной выгрузки без сопоставления повышает риск дублей и перезаписи данных.

Нужно ли останавливать магазин на время запуска?

Не всегда. Решение зависит от объёма изменений и текущих заказов. Для миграции полезно заранее определить окно переключения, контрольный срез остатков и план отката.

Как обсудить интеграцию

Мы настраиваем и дорабатываем интернет-магазины на 1С-Битрикс, включая обмен каталогом и заказами. Для оценки пришлите адрес сайта, конфигурацию 1С и кратко опишите, какие данные должны двигаться в каждую сторону. Можно начать с разработки интернет-магазина на 1С-Битрикс или отдельно описать задачу по интеграции сайта с внешними системами.

Официальные материалы по механизму: компоненты обмена с 1С, настройки интеграции на стороне магазина и возможности публикации товаров и обработки заказов.