Интеграция 1С:ERP с интернет-магазином на 1С-Битрикс: обмен и сложные сценарии

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

Ниже — практический разбор обмена 1С:ERP с сайтом на Битриксе: от протокола CommerceML 2 и настройки узлов до многоскладских остатков, резервов, B2B-цен и обработки ошибок. Это выжимка из наших внедрений по интеграции сайтов с 1С — без общих слов, с конкретикой по тому, что реально ломается и как это чинить.

1С:ERP против УТ и УНФ: в чём разница для обмена

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

Управление торговлей (УТ) и Управление нашей фирмой (УНФ) — это торговые конфигурации с относительно простой моделью: как правило, одна-две организации, понятный набор складов, типовая выгрузка на сайт «из коробки». Обмен настраивается мастером за полчаса, и на выходе получается рабочая связка каталог-остатки-заказы.

1С:ERP Управление предприятием — это система уровня всего предприятия. В ней одновременно живут производство, закупки, склад, финансы, продажи. Из этого вытекают особенности обмена, к которым нужно быть готовым:

• Несколько организаций. В одной базе может быть несколько юрлиц. Нужно явно решить, от имени какой организации продаёт сайт и остатки какой организации показывать.
• Много складов и структура хранения. Склады делятся на ордерные и неордерные, есть помещения и территории. На сайт обычно выгружают не все склады, а только те, откуда идёт отгрузка в розницу или B2B.
• Сложное ценообразование. Виды цен, ценовые группы, скидки, соглашения с клиентами. На витрину попадает только часть — выбранные виды цен.
• Оперативные и неоперативные остатки. ERP различает «свободный остаток», «в резерве», «ожидается» — и от того, какой показатель вы выгрузите, зависит корректность наличия на сайте.
• Регламентный характер выгрузки. В ERP обмен с сайтом — это отдельная подсистема со своими регламентными заданиями, а не «галочка в карточке номенклатуры».

Практический вывод: при интеграции ERP основная работа и основные риски — не на сайте, а в грамотной настройке того, что именно ERP отдаёт наружу. Если это спроектировано правильно, сторона Битрикса собирается почти так же, как для обычной УТ. Базовый сценарий обмена «сайт — 1С» мы подробно разобрали в отдельном материале про интеграцию магазина с 1С; здесь же сосредоточимся на том, что добавляет именно ERP.

Протокол CommerceML 2: что передаётся по проводам

В основе обмена лежит стандарт CommerceML 2 (Commerce Markup Language) — это набор XML-файлов, которыми обмениваются 1С и сайт. Стандарт открытый, и именно его понимает штатный модуль Битрикса «Обмен с 1С». Понимать структуру полезно даже если вы не пишете обмен руками: она подсказывает, где искать проблему, когда что-то не долетает до сайта.

Обмен CommerceML логически делится на несколько потоков файлов:

• Каталог (import.xml). Классификатор (группы и свойства), сама номенклатура, описания, картинки, единицы измерения. Это «что за товары».
• Предложения (offers.xml). Цены по видам цен и остатки по складам для каждого товара или торгового предложения. Это «почём и сколько есть».
• Заказы (orders.xml). Двусторонний поток: сайт отдаёт новые заказы, 1С возвращает их со статусами, оплатами и отгрузками.

Технически обмен идёт по протоколу HTTP в несколько шагов: авторизация, инициализация (сайт сообщает лимит размера файла и включён ли zip), затем передача файлов частями (file), команда импорта (import) и, для заказов, встречная выгрузка (query/success). Каждый шаг — отдельный HTTP-запрос к специальной точке обмена на сайте. Если обмен «застревает», почти всегда виноват один из этих шагов: не прошла авторизация, файл больше разрешённого лимита, таймаут на шаге import.

Узлы и планы обмена: как связать ERP и сайт

В 1С:ERP обмен с сайтом описывается через узел обмена (иногда говорят «настройка обмена с сайтом» или «план обмена»). Узел — это, по сути, паспорт соединения: с каким сайтом дружим, по какому адресу, под каким логином, что и как выгружаем. Правильно заведённый узел — половина успеха.

В настройке узла на стороне ERP задаются ключевые параметры:

• Адрес и авторизация. URL точки обмена на сайте (обычно вида /bitrix/admin/1c_exchange.php), логин и пароль пользователя Битрикса с правом на обмен.
• Организация. Юрлицо, от имени которого идут выгрузка и приём заказов.
• Виды цен. Список типов цен, которые уходят на сайт (розничная, оптовая, дилерская и т.д.).
• Склады. Перечень складов, остатки которых передаются, и режим — суммарно или по каждому складу.
• Состав номенклатуры. Отбор товаров: вся номенклатура, определённые группы, товары с признаком «выгружать на сайт».
• Расписание. Регламентные задания, которые запускают полную и частичную выгрузку и приём заказов.

На стороне Битрикса связка описывается в модуле «Торговый каталог» — там создаётся профиль обмена, привязанный к инфоблоку каталога. Критично, чтобы реквизиты совпадали с двух сторон: адрес узла, логин и пароль, идентификатор инфоблока/каталога. Самая частая причина «обмен не идёт» на старте — рассинхрон именно здесь: сменили пароль на сайте, а в узле ERP оставили старый.

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

Выгрузка каталога, характеристик и упаковок

Каталог — это основа витрины, и от того, как он выгружен, зависит вся дальнейшая работа фильтра, карточек и поиска. В CommerceML каталог передаётся классификатором (структура групп и справочник свойств) и самой номенклатурой.

Группы и свойства. Дерево групп из ERP становится структурой разделов инфоблока, а свойства номенклатуры — свойствами инфоблока. Здесь важно, чтобы свойства, по которым потом строится фильтр, приходили как значения из справочника (списки), а не произвольным текстом. Если в ERP характеристики ведутся хаотично, на сайте это выльется в раздутый фасетный индекс и медленный фильтр.

Характеристики и торговые предложения. В ERP у номенклатуры бывают характеристики (цвет, размер) — они на сайте превращаются в торговые предложения (SKU) дочернего инфоблока. Обмен связывает родительский товар и его предложения по внешнему коду. Ключевой момент: решите заранее, что именно является предложением, а что — отдельным товаром, и держите эту логику единой с двух сторон.

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

• Картинки. Приходят как файлы в архиве обмена. На большом каталоге это самая «тяжёлая» часть — картинки заметно увеличивают размер и время обмена, поэтому их часто выгружают отдельным, более редким шагом.
• Описания и SEO-поля. Договоритесь, где «источник правды» для описаний и метатегов — в ERP или на сайте. Если правите описания на сайте, а обмен их перезатирает из ERP, вы будете терять контент при каждой выгрузке.
• Признак выгрузки. Полезно завести в ERP реквизит «Публиковать на сайте», чтобы не гнать на витрину служебную и снятую с продажи номенклатуру.

Цены по типам и остатки по нескольким складам

Здесь начинается то, ради чего ERP и внедряют. Цены и остатки передаются в файле предложений, и в ERP их структура заметно сложнее, чем в УТ.

Цены по типам. В ERP каждый вид цены (розничная, оптовая, дилерская, РРЦ) — это отдельный источник. В настройке обмена выбирается, какие виды цен выгружать, и каждый из них на сайте превращается в свой тип цены торгового каталога. Дальше типы цен привязываются к группам пользователей: незалогиненный посетитель и розничный покупатель видят розничную цену, а авторизованный дилер — дилерскую. Так одна выгрузка обслуживает и B2C, и B2B витрину одновременно.

Остатки по складам. Если в узле обмена включён режим выгрузки по складам, в предложениях каждый товар приходит с разбивкой количества по складам. На сайте эти склады должны быть заранее заведены в модуле «Торговый каталог» и сопоставлены складам ERP по коду. Тогда витрина может:

• показывать суммарный остаток по всем складам («в наличии: 42 шт»);
• показывать наличие по каждой точке («Москва — есть, Казань — под заказ»);
• ограничивать продажу товаром только тех складов, что доступны конкретному покупателю или региону.

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

Загрузка заказов и возврат статусов в ERP

Обмен заказами — двусторонний, и это самая чувствительная часть интеграции: тут крутятся деньги, и ошибка сразу видна и клиенту, и менеджеру. Поток устроен так: сайт формирует заказ, при очередном обмене выгружает его в ERP, ERP принимает заказ (создаёт документ реализации/заказа клиента), а затем возвращает на сайт его состояние.

Что уходит с сайта в ERP при выгрузке заказа:

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

Что возвращается из ERP на сайт:

• Статус заказа — принят, собран, отгружен, выполнен, отменён. Статусы ERP сопоставляются со статусами заказа Битрикса.
• Факт оплаты — оплачен/не оплачен, что важно, если оплата проходит в 1С (например, по счёту для юрлица).
• Факт и параметры отгрузки — что и когда отгружено, номер накладной.
• Номер заказа в 1С — чтобы менеджер и клиент говорили об одном и том же документе.

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

Резервирование и оперативные остатки

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

Есть два принципиальных подхода к резерву:

• Резерв на стороне 1С. Сайт показывает свободный остаток, а фактический резерв делает ERP в момент приёма заказа. Плюс — единый источник правды, минус — между оформлением на сайте и приёмом в ERP есть окно, когда товар ещё не зарезервирован и его может «увести» другой заказ.
• Резерв на стороне сайта. Битрикс уменьшает доступный остаток сразу при оформлении, а ERP синхронизирует резерв при обмене. Плюс — мгновенная защита от перепродажи, минус — усложняется логика и возможны расхождения, если обмен запаздывает.

Для витрины важно выгружать именно свободный (доступный к продаже) остаток, а не физический. Иначе покупатель увидит «в наличии 5», хотя все 5 уже в резерве под чужие заказы, и оформит то, чего фактически нет. Это классический источник конфликтов «продали, а отгрузить нечем».

Отдельно стоит вопрос частоты. Оперативные остатки в ERP меняются постоянно — при каждой продаже, отгрузке, поступлении. Гонять полный обмен ради остатков нельзя, поэтому остатки выносят в частый частичный обмен (каждые 10–30 минут), передавая только изменившиеся позиции. Чем «горячее» товарные категории и выше оборот, тем чаще нужен обмен остатками — вплоть до почти реального времени через дополнительный REST-канал поверх штатного CommerceML.

Частичный и полный обмен, расписание, производительность

На большом каталоге вопрос производительности обмена становится вопросом работоспособности сайта в принципе. Секрет — в правильном разделении полного и частичного обмена.

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

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

Что настраивают для производительности больших выгрузок:

• Размер файла и пакета. Лимит размера одного файла обмена и число товаров в пакете подбирают так, чтобы не упираться в память PHP и таймауты веб-сервера. Слишком большой пакет — падение по памяти, слишком мелкий — лишние накладные расходы.
• Разнесение шагов. Каталог, картинки, цены, остатки и заказы можно выгружать по разным расписаниям: каталог — раз в сутки, цены — раз в час, остатки — каждые 15 минут, заказы — каждые несколько минут.
• Zip-сжатие. Включение архивации уменьшает трафик и время передачи, особенно на выгрузке картинок.
• Отложенная постобработка. Тяжёлые операции сайта после приёма данных — пересчёт цен со скидками, переиндексация фасетного индекса фильтра, отправка уведомлений — выносят в очередь и агенты, чтобы они не блокировали сам шаг обмена.

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

Сопоставление номенклатуры: GUID против названий

Всё, что связывает объект в 1С с объектом на сайте, держится на одном принципе — сопоставлении по стабильному внешнему коду. В 1С таким кодом служит GUID (уникальный идентификатор объекта в базе). Именно он передаётся в CommerceML как внешний код товара, группы, свойства, предложения.

Почему это критично: GUID не меняется, когда меняется название или артикул. Если сопоставлять по имени или артикулу, то стоит поменять в ERP название «Смартфон XYZ» на «Смартфон XYZ (2024)» — и обмен создаст на сайте новый товар вместо обновления старого. Каталог обрастает дублями, ссылки бьются, SEO рушится. С GUID такого не случается: как бы ни менялись реквизиты, сайт узнаёт товар и обновляет существующую запись.

Практические правила сопоставления:

• Товары и предложения — по GUID. Внешний код хранится в свойстве инфоблока (обычно CML2_LINK и внешний код элемента) и никогда не редактируется руками.
• Группы — по GUID. Иначе перемещение раздела в ERP пересоздаст его на сайте и «оторвёт» товары.
• Свойства и значения списков — по внешнему коду. Особенно важно для фильтруемых свойств: иначе значения задваиваются.
• Склады и типы цен — по коду. Сопоставление заводится один раз при настройке и дальше держит связку остатков и цен.
• Упаковки — по коду упаковки. Чтобы кратность заказа не «слетала» при обмене.

Отдельная боль — первичная стыковка, когда каталог на сайте уже есть, а обмен только настраивают. Тут нужно аккуратно проставить GUID существующим товарам (по артикулу, а лучше вручную выверенным сопоставлением), иначе первый же полный обмен продублирует весь каталог. Эту операцию всегда делают на копии базы и с бэкапом.

Ошибки обмена, идемпотентность и очереди

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

Что делает обмен идемпотентным:

• Сопоставление по стабильному ключу. Товар — по GUID, заказ — по идентификатору заказа. Повторная выгрузка обновляет, а не создаёт.
• Транзакционность шага. Приём пакета либо завершается целиком, либо откатывается. Полупринятый пакет не должен оставлять систему в «половинчатом» состоянии.
• Подтверждение и повтор. 1С помечает данные как переданные только после явного подтверждения от сайта. Если подтверждение не пришло, тот же пакет уйдёт повторно — и благодаря идемпотентности это безопасно.

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

Обработка ошибок должна быть явной, а не «упало и молчим»:

• Классификация ошибок. Отличайте временные (сеть, таймаут — повторить) от постоянных (невалидные данные — в карантин и уведомить оператора).
• Повторы с задержкой. Временные ошибки повторяют с нарастающей паузой, а не бесконечным циклом раз в секунду.
• Карантин «битых» объектов. Заказ или товар, который не проходит валидацию, откладывают в отдельную «полку», не блокируя остальной поток.
• Алерты. Если обмен встал или карантин растёт, ответственный должен узнать об этом сразу, а не из жалобы клиента.

B2B-сценарии: цены под контрагента

B2B-витрина — частая причина, по которой вообще заходят на ERP. Оптовику мало «розничной цены»: у него своё соглашение, своя скидка, свои условия. Здесь штатный CommerceML достигает предела: он передаёт цены по типам, а не по каждому клиенту, и этого хватает для «дилерской» или «оптовой» цены, но не для персональной.

Уровни персонализации цен и как их закрывать:

• Цена по группе (тип цены). Дилеры видят дилерскую цену, оптовики — оптовую. Полностью решается штатным обменом: тип цены из ERP → тип цены сайта → группа пользователей. Самый распространённый и надёжный сценарий.
• Персональная цена контрагента. У конкретного клиента своя цена по соглашению. CommerceML это напрямую не передаёт, поэтому персональные цены обычно подтягивают в личном кабинете через REST-запрос к 1С в момент показа корзины.
• Скидки и условия соглашения. Кратность, минимальная сумма заказа, отсрочка платежа — это бизнес-логика соглашения, которую тоже удобно запрашивать из ERP по API для авторизованного контрагента.

Типовая архитектура B2B-магазина на ERP: базовые цены и остатки идут штатным CommerceML (быстро, надёжно, кэшируется), а «поверх» для авторизованного контрагента личный кабинет запрашивает у ERP персональные цены, доступные склады, дебиторку и историю заказов через REST. Так витрина остаётся быстрой для всех, а B2B-клиент видит именно свои условия. Про построение таких кабинетов и порталов — раздел B2B-порталы.

Мониторинг и логирование обмена

Обмен, за которым никто не следит, однажды молча встаёт — и вы узнаёте об этом, когда клиенты жалуются на неверные остатки или пропавшие заказы. Поэтому мониторинг закладывают сразу, а не «когда сломается».

Что нужно видеть по обмену:

• Время последнего успешного обмена по каждому потоку (каталог, цены, остатки, заказы). Если остатки не обновлялись час — это сигнал.
• Статус текущего шага — идёт, завершён, упал, и с какой ошибкой.
• Объёмы — сколько товаров, цен, заказов прошло за сеанс. Резкое падение объёма — тоже симптом.
• Очередь и карантин — сколько объектов ждёт обработки и сколько отложено с ошибкой.
• Ошибки с контекстом — не просто «ошибка обмена», а какой объект, какой шаг, какой текст ошибки.

Штатный лог обмена Битрикса (exchange.log и журнал в админке) фиксирует ход выгрузки и приёма. Со стороны ERP есть журнал регистрации, куда падают ошибки регламентных заданий обмена. Для промышленной эксплуатации этого мало: логи разнесены по двум системам, их неудобно сопоставлять. Поэтому поверх ставят единую панель — сводку по потокам обмена с алертами в мессенджер, когда обмен встал или карантин растёт. Это превращает обмен из «чёрного ящика» в управляемый процесс.

Реализация в 1С-Битрикс: модуль и настройки

На стороне сайта весь обмен обслуживает модуль «1С-Битрикс: Обмен с 1С» в связке с модулем «Торговый каталог». Точка входа обмена — файл /bitrix/admin/1c_exchange.php, к которому обращается ERP. Настройки профиля обмена живут в разделе «Магазин → Настройки → Настройки обмена с 1С» (в зависимости от редакции — «Контент → Инфоблоки → Обмен с 1С»).

Ключевые вещи, которые задают на стороне Битрикса:

• Инфоблоки каталога и предложений. Куда складывать товары и торговые предложения (SKU).
• Типы цен. Создаются в торговом каталоге и сопоставляются видам цен ERP; привязываются к группам пользователей.
• Склады. Заводятся в торговом каталоге и сопоставляются складам ERP по коду для многоскладских остатков.
• Права пользователя обмена. Отдельный пользователь с правом на обмен, без лишних привилегий.
• Статусы заказов. Сопоставление статусов Битрикса со статусами документов ERP.
• Агенты и очереди. Постобработку (переиндексация фасета, пересчёт скидок, уведомления) выносят в агенты, чтобы не грузить шаг обмена.

Схематично экран настройки профиля обмена выглядит так:

Отдельный практический момент — окружение. Обмен большого каталога упирается в лимиты PHP (память, время выполнения) и настройки веб-сервера. На боевом внедрении заранее поднимают memory_limit и max_execution_time для точки обмена, включают zip, а тяжёлую постобработку уводят в фоновые агенты. Без этого первый же полный обмен большого каталога упрётся в таймаут на середине.

Частые ошибки

• Сопоставляют товары и заказы по названию или артикулу вместо GUID — повторный обмен плодит дубли каталога и заказов.
• Выгружают физический остаток вместо свободного — витрина показывает наличие товара, который уже в резерве, и магазин продаёт то, чего нет.
• Гоняют полный обмен ради обновления остатков — сервер захлёбывается, а актуальность всё равно отстаёт. Остатки нужно слать частичным обменом.
• Не сопоставили склады и типы цен на стороне сайта — остатки по складам и B2B-цены «не приезжают», хотя в ERP всё настроено.
• Настроили обмен заказами односторонне — заказы уходят в ERP, но статусы обратно не возвращаются, и клиент в кабинете видит вечное «принят».
• Меняют статус заказа с обеих сторон — при каждом обмене статус «прыгает», потому что не определён единственный владелец статуса.
• Перетирают обменом описания и метатеги, отредактированные на сайте, — контент теряется при каждой выгрузке, потому что не назначен «владелец поля».
• Забывают перестроить фасетный индекс фильтра после большого обмена — счётчики и выдача расходятся с реальными остатками.
• Не мониторят обмен — он молча встаёт, и о проблеме узнают из жалоб клиентов, а не из алерта.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность обмена ERP с сайтом перед запуском:

1. Модель зафиксирована. Определены организация продаж, список выгружаемых складов и набор видов цен для витрины и B2B.
2. Узел и профиль настроены. Реквизиты соединения совпадают с двух сторон: адрес, логин, пароль, инфоблок.
3. Сопоставления по GUID. Товары, группы, свойства, склады и типы цен связаны по стабильным кодам, дублей нет.
4. Каталог и предложения выгружены. Характеристики стали SKU, упаковки и единицы измерения переданы, картинки идут отдельным шагом.
5. Цены и остатки корректны. Типы цен привязаны к группам, на витрину идёт свободный остаток по складам, а не физический.
6. Заказы ходят в обе стороны. Выгрузка в ERP работает, статусы возвращаются, определён единственный владелец статуса.
7. Обмен разнесён по расписанию. Полный — ночью, цены и остатки — часто и малыми пакетами, заказы — почти в реальном времени.
8. Надёжность заложена. Обмен идемпотентен, есть очередь, повторы и карантин для битых объектов.
9. Постобработка вынесена. Переиндексация фасета и пересчёт скидок работают в агентах, а не в шаге обмена.
10. Мониторинг включён. Есть сводка по потокам обмена и алерты, когда обмен встал или растёт карантин.

Вывод

Интеграция 1С:ERP с интернет-магазином на 1С-Битрикс — это не «настроить галочку обмена», а спроектировать, что именно предприятие показывает витрине: от какой организации торгуем, остатки каких складов и какие типы цен отдаём, как возвращаем статусы заказов. Протокол CommerceML 2 и штатный модуль обмена дают надёжную основу, а сложность ERP закрывается правильной моделью данных, сопоставлением по GUID, разделением полного и частичного обмена и вынесением тяжёлых операций в очереди и агенты. Сделайте эти вещи аккуратно — и обмен перестанет быть источником дублей, рассинхрона и продаж того, чего нет на складе, даже на большом B2B-каталоге.