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

Обмен сайта с 1С Управление торговлей — это регулярная передача данных между учётной системой и интернет-магазином: каталог, цены, остатки и характеристики идут на сайт, а заказы и данные покупателей — в 1С. Задача решается связкой «редакция УТ + модуль обмена на стороне сайта + узел обмена в 1С», и результат проверяется по журналам и сверкой конкретных позиций, а не по факту «обмен запустился».

Что решает обмен сайта с 1С Управление торговлей и где его границы

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

Границы задачи стоит зафиксировать до настройки, иначе ожидания расходятся:

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

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

Общая логика связки сайта и учётной системы разобрана в материале обмен сайта на Битрикс с 1С; здесь речь именно о специфике УТ.

Версии: редакция УТ и модуль обмена с сайтом

Первое, что проверяют перед настройкой, — сочетание редакции УТ и версии модуля обмена. В документации они связаны: для УТ редакции 11.5 описан модуль обмена 8.1.х, а для редакций 11.1–11.3 — модуль 7.0.х. Это не взаимозаменяемые варианты: набор доступных настроек и порядок работы различаются.

Что важно знать про совместимость

В документации по модулю обмена 7.х указано, что он совместим с версией модуля «Интернет-магазин» не ниже 17.0.1, а работа с соответствием служб доставки требует версии не ниже 17.0.21. Это ориентир для проверки, а не гарантия для любой конфигурации: фактическую совместимость подтверждают на своём стенде.

Как узнать свои версии

• Редакцию УТ смотрят в самой учётной системе — в сведениях о программе.
• Версию модуля обмена на стороне сайта можно посмотреть из 1С: в меню синхронизации узла есть пункт с информацией о номере версии используемого модуля обмена.
• Редакцию продукта на стороне сайта смотрят в разделе обновления платформы.

Критерий готовности к настройке простой: версия модуля обмена на сайте соответствует требованиям документации для вашей редакции УТ, а версия модуля «Интернет-магазин» не ниже минимально требуемой. Если это не так, часть настроек может быть недоступна, и настройку начинают с обновления, а не с подбора параметров.

Узел обмена в 1С: где живут настройки

Настройки обмена с сайтами в УТ собраны в плане обмена «Узлы обмена с сайтами». Это список, в котором каждый сайт представлен отдельным узлом.

Список узлов и что в нём видно

В списке отображаются узлы и информация о критичных ошибках: если во время обмена с сайтом возникла ошибка, при которой обмен прекращается, она попадает в соответствующую колонку. Это первое место, куда смотрят при жалобе «данные не пришли».

Новый узел создают кнопкой «Создать»; элемент можно найти или скопировать через контекстное меню. Кнопка синхронизации данных открывает меню с действиями: выполнить обмен данными для выбранного узла, показать зарегистрированные изменения, посмотреть информацию о версии модуля обмена, открыть лог за нужную дату. Отдельная кнопка позволяет импортировать и экспортировать настройки обмена в файл — это удобно, чтобы перенести проверенную конфигурацию на другой контур, не собирая её заново вручную.

Форма создания узла

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

• выгрузка информации о номенклатуре;
• выгрузка пользовательских справочников;
• обмен документами;
• выгрузка контрагентов.

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

Подключение к сайту

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

Если выбран вариант с каталогом на диске, задаются каталог выгрузки и файл загрузки заказов. Такой режим полезен для отладки и для случаев, когда прямой обмен по каким-то причинам не подходит.

Что именно уходит на сайт и что возвращается

Состав обмена — это не «всё сразу», а набор блоков, которые включаются по отдельности. Разберём их предметно.

Номенклатура, цены и остатки

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

Документы: заказы и статусы

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

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

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

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

Идентификаторы объектов

Чтобы обмен не создавал дубли, объекты двух систем должны быть сопоставлены. В документации это описано как идентификаторы объектов. Практический вывод: любые ручные переименования и «пересоздание» товаров на одной из сторон ломают сопоставление, и это нужно запретить регламентом.

Полная выгрузка или только изменения

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

Полная выгрузка

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

Только изменения

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

Деактивация товаров и разделов

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

Версионность

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

Расписание, логи и повторы

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

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

Логи

В параметрах обмена задаётся каталог лога. Логи хранятся в разрезе дня в подчинённой папке reports (или аналогичной, в зависимости от версии платформы). Дополнительно можно определить, выгружать ли логи на сайт и хранить ли файлы обмена на сайте. Практический критерий: если логи не сохраняются, разбирать сбой будет нечем, поэтому хранение логов — обязательная часть настройки, а не опция «на будущее».

Повторы и тайм-ауты

Для неудачно отправленных пакетов задаются число повторов и тайм-аут между повторами. Это защита от разовых сетевых сбоев: короткий тайм-аут и малое число повторов дают быстрый отказ, длинный тайм-аут и большое число повторов — растянутый по времени обмен. Значения подбирают под реальную нагрузку и проверяют на тестовом контуре.

Журналы

В документации упоминаются журнал обменов и журнал ошибок. Это два разных инструмента: журнал обменов показывает, что и когда происходило, журнал ошибок — что именно сломалось. При приёмке работы нужно убедиться, что оба доступны и заполняются.

Матрица обмена УТ: что фиксировать до старта

Матрица обмена — рабочий документ, который снимает большинство споров на приёмке. Она заполняется до настройки и подписывается владельцем процесса.

Если по какой-то строке источник истины не определён, это не техническая, а управленческая проблема: обмен будет работать, но данные будут расходиться.

Учебный пример: обмен для оптового магазина

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

Входные условия

Условная компания «Ромашка-Опт» ведёт учёт в 1С:Управление торговлей редакции 11.5, на сайте установлен модуль обмена 8.1.х. Ассортимент — несколько тысяч позиций, два склада, две ценовые группы: розничная и оптовая. Заказы оформляются на сайте, менеджеры работают с ними в 1С. Обмен требуется ежедневно, в ночное окно.

Порядок действий

1. Фиксируют матрицу обмена: какие сущности и в каком направлении передаются, кто источник истины. 2. Проверяют версии: редакция УТ, версия модуля обмена, версия модуля «Интернет-магазин». 3. Готовят пользователя сайта с правом на обмен и проверяют соединение из узла. 4. Создают узел обмена, включают нужные блоки: номенклатуру, документы, контрагентов. 5. Выбирают режим «только изменения» для регулярной работы. 6. Настраивают расписание на ночное окно и каталог логов. 7. Выполняют первый обмен на тестовом контуре и сверяют результат по контрольным позициям. 8. Только после успешной проверки повторяют настройку на рабочем контуре.

Что проверяют после первого обмена

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

Ограничения примера

Порядок действий переносим, а конкретные значения — нет. Число повторов, тайм-ауты, расписание и состав блоков зависят от объёма каталога, нагрузки на сайт и режима работы складов. Настройки, снятые с одного контура, нельзя считать проверенными на другом: для файловой и клиент-серверной базы расписание настраивается по-разному.

Как проверить результат и принять работу

Приёмка обмена — это не «посмотрели, что работает», а последовательность проверок с фиксацией результата.

• Матрица обмена заполнена и подписана владельцем процесса
• Версии модуля обмена и модуля «Интернет-магазин» соответствуют требованиям документации для вашей редакции УТ
• Пользователь сайта имеет право на выполнение обмена, проверка соединения проходит
• Включены только те блоки обмена, которые описаны в матрице
• Режим контроля изменений выбран осознанно, полная выгрузка не стоит в расписании по умолчанию
• Флаг деактивации товаров и разделов проверен на копии и включён только при полном отборе
• Расписание обмена согласовано и не попадает в часы пиковой нагрузки
• Каталог логов задан, логи сохраняются, журнал обменов и журнал ошибок доступны
• Число повторов и тайм-аут между повторами заданы и проверены на тестовом контуре
• Контрольные позиции сверены по названию, коду, цене и остаткам
• Тестовый заказ прошёл в 1С, статус вернулся на сайт
• Настройки обмена экспортированы в файл и сохранены как резервная копия конфигурации
• Определены ответственные со стороны 1С и со стороны сайта, порядок эскалации при сбое

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

Типичные ошибки и ограничения

Большинство сбоев объясняется не «плохим модулем», а решениями, принятыми до настройки.

• Несовпадение версий. Модуль обмена и редакция УТ подбираются по документации; при несоответствии часть настроек недоступна, и это выглядит как «функция пропала».
• Пользователь без права обмена. Соединение проверяется, но обмен не проходит: пользователь сайта должен относиться к нужной группе.
• Полная выгрузка в расписании. При большом каталоге обмен идёт долго и может не успевать к следующему запуску.
• Случайная деактивация. Сузили отбор, оставили флаг деактивации — часть ассортимента отключилась на сайте.
• Дубли из-за ручных правок. Пересоздание товаров на одной стороне ломает сопоставление объектов.
• Обмен в часы нагрузки. Синхронизация каталога и оформление заказов конкурируют за ресурсы.
• Отсутствие логов. Без сохранённых логов разбор сбоя превращается в догадки.

Часть этих ситуаций разобрана подробнее в материале Обмен с 1С сломался: типичные проблемы интеграции и как их решить.

Ограничения, которые стоит принять заранее: обмен не мгновенный, он идёт по расписанию или по запуску; состав передаваемых данных ограничен включёнными блоками; а вопросы обработки сведений о покупателях выходят за рамки технической настройки и требуют отдельного согласования.

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ, а не гадать, нужен минимальный набор сведений.

• Редакция УТ и версия установленного модуля обмена.
• Версия модуля «Интернет-магазин» на стороне сайта.
• Сколько сайтов обслуживается: один узел обмена или несколько.
• Объём каталога, число складов и ценовых групп.
• Перечень сущностей, которые должны обмениваться, и направление по каждой.
• Требуемая частота обмена и допустимое окно.
• Кто отвечает за настройку со стороны 1С и со стороны сайта.
• Есть ли тестовый контур, на котором можно проверить настройки до рабочего запуска.
• Как сейчас передаются заказы и кто обрабатывает расхождения.

Общий порядок настройки связки, если вы только выбираете подход, описан в материале Интеграция Битрикс с 1С: как настроить обмен товарами и заказами.