Интеграция магазина с 1С ERP: как настроить обмен товарами, ценами и заказами

Интеграция интернет-магазина с 1С ERP — это обмен данными между сайтом и учётной системой: из ERP на сайт уходят товары, характеристики, цены и остатки, обратно — заказы и, при необходимости, контрагенты. Задача решается не включением одной настройки, а проектированием: сначала фиксируют, какие справочники и документы участвуют в обмене, затем настраивают обе стороны, проверяют обмен на тестовых данных и только после этого выводят его в рабочий контур. Ниже — порядок действий, развилки, способ проверки и границы, за которые типовыми настройками лучше не выходить.

Что решает интеграция магазина с 1С ERP и где её границы

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

Границы решения стоит очертить до начала работ. В типовой контур обычно входят:

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

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

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

Какие данные и в какую сторону должны двигаться

Направление обмена — первое, что нужно нарисовать. Удобно свести это в простую схему: что идёт из ERP на сайт, что возвращается обратно и что ходит в обе стороны.

Из ERP на сайт:

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

С сайта в ERP:

• заказы с составом и суммами;
• данные покупателя в объёме, который нужен для оформления документа;
• при необходимости — новые контрагенты.

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

Ещё одна развилка — что именно выгружать из заказов. Можно ограничить выгрузку только оплаченными заказами, только заказами с разрешённой доставкой или заказами начиная с определённого статуса. Это не оптимизация ради оптимизации: каждая лишняя запись — документ, который кто-то должен обработать в ERP.

Схему обмена стоит нарисовать до настройки и согласовать с теми, кто работает и на сайте, и в ERP. Архитектурная схема — обязательный артефакт проекта: на ней видно стороны, направления, расписание и точки, где обмен может остановиться.

Справочники, характеристики и торговые предложения: где чаще всего ломается логика

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

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

Ключевые решения, которые нужно принять до настройки:

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

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

Отдельная тема — справочники. Часть из них выгружается как пользовательские справочники, часть — как свойства товаров в документах. Что именно нужно сайту, зависит от того, как устроены фильтры и карточка товара. Лишние справочники увеличивают объём обмена и время его прохождения, поэтому список стоит ограничить.

Нагрузка обмена: объём, шаги и что снижает время

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

Что влияет на нагрузку:

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

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

Ещё один практичный приём — не тащить на сайт исходные изображения в том виде, в каком они лежат в ERP. Автоматическая генерация картинки анонса и детальной картинки с заданными ограничениями по ширине и высоте позволяет не публиковать тяжёлые файлы.

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

Как устроена интеграция сайта с 1С ERP: сторона сайта и сторона учётной системы

Настройка идёт с двух сторон, и это важно не забыть.

На стороне сайта параметры обмена собраны в отдельной форме настроек интеграции с 1С. Там задаются:

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

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

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

Практический вывод: не переносите настройки по памяти с прошлого проекта. Сверьтесь с документацией именно для вашей конфигурации и редакции, а спорные места проверьте на тестовом контуре.

Если сайт работает на Битрикс, полезна отдельная инструкция про обмен сайта на Битрикс с 1С — там разобраны шаги настройки со стороны платформы.

Таблица решений: что выбрать в типовых развилках

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

Учебный пример: магазин с характеристиками и заказами

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

Входные условия. Интернет-магазин продаёт одежду: около 4 000 моделей, у части моделей по 3–6 размеров. Учёт ведётся в 1С ERP. Заказы оформляются на сайте, оплата — онлайн, часть заказов — с доставкой курьером. Менеджеры работают в ERP и не хотят дублировать ввод заказов на сайте.

Что решили на старте:

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

Порядок работ:

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

Что проверяли на тесте:

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

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

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

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

Приёмка интеграции — это не факт запуска обмена. Проверять нужно по сценариям на заранее подготовленных данных.

Что должно быть в приёмочном наборе:

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

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

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

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

Ответственный за приёмку — владелец процесса со стороны бизнеса. Разработчик показывает, что обмен работает по спецификации; бизнес подтверждает, что данные на сайте и в ERP совпадают с тем, как он ведёт учёт.

Чек-лист перед запуском обмена

• Схема обмена нарисована и согласована: направления, объекты, расписание.
• Определён источник истины по товарам, ценам и остаткам.
• Правила заведения товаров в ERP проверены, включая товары с характеристиками.
• Прайс-листы и соглашение настроены, цены берутся из нужного источника.
• На стороне сайта выбран инфоблок каталога и решено, где хранятся торговые предложения.
• Для обмена заведена отдельная учётная запись с минимально нужными правами.
• Условия выгрузки заказов заданы осознанно, а не по умолчанию.
• Смена статусов заказов по данным из ERP настроена и проверена.
• Поведение с отсутствующими товарами и разделами проверено на тесте.
• Настройки кеша и обновления по изменениям выбраны с учётом нагрузки.
• Изображения не публикуются в исходном тяжёлом виде.
• Приёмочные сценарии пройдены, журналы обменов и ошибок просмотрены.
• Есть копия, резервная копия и план возврата к прежнему состоянию.
• Назначен ответственный за приёмку и за дальнейший контроль обмена.

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

Ошибки, которые встречаются чаще всего:

• Два источника истины. Цену правят и на сайте, и в ERP — обмен затирает правки. Лечится договорённостью, а не настройкой.
• Товары с характеристиками заведены так, что предложения не выгружаются. Проверять нужно до запуска, а не после.
• Полная выгрузка в рабочее время. Каталог обновляется, сайт тормозит, покупатели уходят.
• Удаление вместо деактивации. В модуле обмена удаление отсутствующих товаров недоступно — рассчитывать на него нельзя.
• Обмен под учётной записью администратора. Лишние права и лишний риск.
• Заказы уходят в ERP все подряд, включая те, что бизнес не собирался обрабатывать.
• Статусы не синхронизированы, и менеджер ведёт их в двух местах.
• Журналы не смотрят, пока не поступит жалоба.

Ограничения, которые стоит принять заранее:

• обмен не делает данные идеальными — он переносит то, что заведено в ERP;
• часть настроек зависит от конфигурации и редакции, универсальной инструкции нет;
• персональные данные покупателей — отдельная зона ответственности, её границы согласуют со специалистом;
• обмен требует сопровождения: меняются правила учёта, появляются новые свойства, обновляются конфигурации.

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

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

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

Чем конкретнее список, тем меньше допущений в оценке. Если данных нет, не угадывайте: сначала уточните, потом считайте.

Смежная тема — как настраивается обмен на стороне платформы. Подробный разбор есть в материале Интеграция Битрикс с 1С: как настроить обмен товарами и заказами.

Интеграция сайта с 1С