Интеграция интернет-магазина с 1С: как устроен обмен

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

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

Какие данные действительно нужно передавать?

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

Четыре потока и их состав:

Ключевой принцип — карта источников истины: для каждого поля указано, какая система им владеет и в каком направлении оно передаётся. Like Sites ставит эту карту вторым этапом после обследования и прямо говорит, что без неё интеграцию проектировать нельзя: двусторонняя передача одного и того же поля — источник конфликтов, у каждого значения должен быть один владелец (страница «Интеграция интернет-магазина с 1С», проверено 31 октября 2026).

Типовая карта для торговой компании выглядит так:

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

Почему важны конфигурация, версия и доработки?

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

Три вещи, которые определяют объём проекта:

Конфигурация. В «Управлении торговлей 11», «Комплексной автоматизации 2» и «ERP» обмен с сайтом включается функциональной опцией в настройках интеграции, заказы с сайта загружаются как документы «Заказ клиента», а при последующих обменах на сайт передаётся информация об изменении статуса, в частности об отгрузке (1С:ИТС, инструменты дистанционной работы, типовые конфигурации). В «Управлении нашей фирмой» обмен настраивается мастером: тип сайта, способ подключения — по HTTP, через каталог на диске или веб-сервис, — выгрузка товаров и услуг, загрузка заказов, сопоставление состояний заказов и оповещение ответственных об ошибках по электронной почте (1С:ИТС, УНФ 1.6.27). В «Бухгалтерии предприятия» штатного обмена с сайтом как канала продаж нет — она не предназначена для оперативного учёта заказов, и магазин к ней подключают через промежуточную систему или доработку.

Версия. Штатные механизмы развиваются от релиза к релизу: в УНФ двусторонний обмен оплатами и отгрузками появился в одной из версий 1.6 и включается отдельным флажком (1С:ИТС, УНФ 1.6.16); в УТ выгрузка остатков в обмене с сайтом дорабатывалась в версиях 11.5. Устаревший релиз может не иметь нужной функции, а обновление — сломать доработки.

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

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

Где создаются товары и цены?

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

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

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

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

Характеристики и варианты. В УТ и КА вариант товара — характеристика номенклатуры; на сайте — торговое предложение или вариант карточки. Соответствие «одна номенклатура с набором характеристик → одна карточка с вариантами» нужно задать явно, включая случай, когда характеристик нет. Если на сайте варианты устроены иначе, чем в учёте — например, цвет и размер как отдельные измерения, — сопоставление требует правила, а не угадывания.

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

Какие способы обмена доступны для конкретной системы?

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

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

Стандартный интерфейс OData — это REST-интерфейс, который платформа формирует автоматически; его публикуют на веб-сервере, после чего внешние приложения читают, изменяют, создают и удаляют данные HTTP-запросами (1С:ИТС, документация EDT, «Стандартный интерфейс OData»). Удобно для чтения остатков и цен по запросу; для создания заказов его применяют осторожно, потому что запись идёт в объект напрямую, и проверки, зашитые в формы и обработчики, могут не сработать.

Выбор по ситуации. Типовая УТ или УНФ и один сайт — штатный обмен, пока его состава и интервала хватает. Нужны остатки «по запросу» при оформлении заказа — добавляется чтение через OData или HTTP-сервис поверх штатного обмена. Сайт плюс два маркетплейса плюс CRM — промежуточный сервис, в который 1С отдаёт данные один раз, а дальше их получают все каналы. Как такой контур работает для остатков, когда один запас продаётся на сайте и площадках, разобрано на странице интернет-магазин с собственным складом.

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

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

Как передавать заказы, оплаты и возвраты?

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

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

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

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

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

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

Чеки. При онлайн-оплате чек пробивает платёжный сервис или касса, а не 1С; в 1С передаётся факт оплаты. Онлайн-оплата, касса и возвраты — отдельный контур со своими требованиями, и Like Sites выделяет его отдельной страницей, не смешивая с обменом (страница «Интеграция интернет-магазина с 1С», раздел «Когда точнее подойдёт другая страница»).

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

Как сохранять идентификаторы и не создавать дубли?

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

Товары. У каждой номенклатуры и каждой характеристики в 1С есть внутренний уникальный идентификатор, который не меняется при переименовании. Именно он, а не наименование и не артикул, должен быть ключом связи с карточкой сайта. Артикул — второй ключ для людей и для сопоставления на старте, но он может меняться и дублироваться. Like Sites формулирует критерий приёмки так: контрольная выборка товаров и вариантов сопоставлена верно, и переименование позиции связь не рвёт (страница «Интеграция интернет-магазина с 1С»).

Правила для товаров:

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

Заказы. Заказ сайта несёт собственный номер и идентификатор; документ в 1С хранит их в реквизите. Проверка на дубль — по идентификатору сайта, а не по дате и сумме. Повторная отправка того же заказа — из-за сетевого сбоя, повторного запуска обмена, ручного «переотправить» — должна найти существующий документ и обновить его или ничего не делать. Это и есть идемпотентность: одинаковый входящий запрос даёт одинаковый результат независимо от числа повторов. Проверяется она искусственно вызванным повтором на тестовом контуре до запуска и выносится отдельным пунктом приёмки: повторная отправка не создаёт дубль документа.

Контрагенты. Самый дублируемый справочник. Розничный покупатель с телефоном в разных форматах и почтой в разном регистре становится тремя контрагентами. Решение — либо один общий контрагент для розницы с контактами в заказе, либо нормализация телефона и почты перед поиском и единое правило создания. Для B2B-покупателей ключ — ИНН и КПП, и создание контрагента без них интеграция должна блокировать или отправлять на ручное сопоставление.

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

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

Как обрабатывать очередь и повторную отправку?

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

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

Повторы. Повторная попытка выполняется с нарастающим интервалом — через минуту, пять, пятнадцать — и ограниченным числом раз, после чего запись получает статус «требует внимания» и уведомление уходит ответственному. Бесконечные повторы каждые десять секунд создают нагрузку и скрывают проблему.

Схлопывание. Если остаток по позиции изменился пять раз, пока сайт был недоступен, отправить нужно одно актуальное значение, а не пять последовательных. Для остатков и цен действует правило «последнее значение побеждает»; для заказов — каждое событие отдельно, но с проверкой на дубль по идентификатору.

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

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

Таблица типовых отказов и поведения:

Какие права нужны интеграции?

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

Что нужно по потокам:

Принципы:

• Отдельный пользователь 1С с ролью «Обмен с сайтом» или аналогичной, без интерактивного входа, с паролем или ключом, который хранится не в коде сайта, а в защищённой конфигурации.
• Отдельный ключ API на стороне сайта только для интеграции, с ограничением по адресам, с которых разрешены запросы.
• Доступ к продуктивной базе 1С извне — только через согласованный канал: опубликованный сервис за HTTPS, VPN или прокси; прямой доступ к серверу баз данных интеграции не нужен.
• Доступ подрядчика — к тестовой копии для обследования и настройки; на продакшене — согласованный канал. Если политика безопасности не допускает внешнего доступа вовсе, часть работ выполняет ваш специалист по 1С по технической спецификации — такой режим нормален и должен быть предусмотрен в договоре.
• Персональные данные покупателей передаются в 1С в объёме, необходимом для исполнения заказа; где они хранятся и кто имеет доступ — вопрос к вашему регламенту обработки, который проверяет юрист.

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

Как тестировать на копии базы?

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

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

Тестовый сайт. Копия магазина или отдельная площадка на том же коде, с тестовым платёжным режимом и без индексации поисковиками.

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

Порядок тестирования:

1. Выгрузка каталога на пустой тестовый сайт. Проверяется число карточек, вариантов, соответствие идентификаторов, отсутствие дублей.
2. Повторная выгрузка без изменений. Карточки не дублируются, ничего не меняется.
3. Изменения в 1С — переименование, новая характеристика, новая цена, остаток в ноль. Каждое доходит до сайта в согласованный интервал и ложится в нужное поле.
4. Заказы с сайта по сценариям. Документы создаются один раз, с полным составом и реквизитами; отклонённые попадают в очередь с понятной причиной.
5. Статусы из 1С. Изменение в документе отражается на сайте.
6. Искусственные сбои. Остановка сайта во время выгрузки, остановка 1С во время отправки заказа, повтор заказа, частичный файл. Проверяется очередь, журнал и уведомления.
7. Нагрузка. Полная выгрузка каталога реального размера и пакет заказов за пиковый день; измеряется время и нагрузка на базу.

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

Тестовый контур не демонтируется после запуска. Каждое обновление 1С, каждое изменение состава полей, каждый новый тип цены сначала проверяются на нём. Это и есть ответ на вопрос «почему обмен сломался после обновления»: потому что обновление не прошло через тест.

Что включить в ТЗ и приёмку?

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

Разделы ТЗ:

1. Исходные данные: конфигурация, релиз, перечень доработок, платформа сайта, наличие тестовой копии, ответственные с обеих сторон.
2. Карта источников истины по полям с направлением и поведением при конфликте.
3. Перечень передаваемых объектов и полей по четырём потокам, включая типы цен, склады, правило расчёта доступного остатка.
4. Правила сопоставления: идентификаторы товаров, характеристик, контрагентов, складов, статусов; поведение при отсутствии соответствия.
5. Способ обмена и интервалы по каждому потоку; расписание относительно регламентных заданий 1С.
6. Правила создания заказа: документ, контрагент, резерв, цены, поведение при ошибках.
7. Очередь, повторы, схлопывание, поведение сайта при устаревших данных.
8. Журнал: состав записи, срок хранения, кто имеет доступ.
9. Уведомления: события, адресаты, каналы.
10. Права и доступы: пользователь 1С, ключи, каналы, обработка персональных данных.
11. Тестовый контур: состав, сценарии, критерии прохождения.
12. Приёмка: перечень проверок с ожидаемым результатом.
13. Зоны ответственности: что делает исполнитель, что — ваш специалист по 1С, что — вы; сопровождение после запуска и его стоимость.

Чек-лист приёмки, который можно взять за основу — он совпадает с тем, что Like Sites проверяет при сдаче (страница «Интеграция интернет-магазина с 1С»):

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

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

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

Когда достаточно штатного модуля?

Разработка интеграции не нужна там, где штатный обмен конфигурации закрывает задачу. Это честный раздел, и признаки здесь конкретные.

Штатного модуля достаточно, если выполняются все условия:

• Конфигурация типовая или доработки не затрагивают номенклатуру, цены, остатки и заказы. Штатный обмен в УТ, КА, ERP и УНФ работает с типовыми объектами; если они не изменены, он работает.
• Один сайт как канал. Штатный обмен рассчитан на выгрузку в узел обмена с сайтом; маркетплейсы в типовых конфигурациях подключаются отдельными механизмами, и объединять остатки между каналами штатный обмен не умеет.
• Платформа сайта поддерживает протокол обмена с 1С. Это не только «1С-Битрикс»: протокол открытый, и его реализуют многие системы и самописные магазины.
• Состав полей — стандартный: наименование, артикул, характеристики, одна-две цены, остатки, заказы со статусами. Дополнительные реквизиты потребуют доработки обработки выгрузки.
• Интервал в десятки минут приемлем. Пакетный обмен по расписанию не даёт остатков «в момент оформления»; если перепродажи недопустимы, нужен буфер или дополнительный канал чтения.
• Есть кто-то, кто смотрит на ошибки. В УНФ штатно есть оповещение ответственных об ошибках обмена по почте (1С:ИТС, УНФ 1.6.27); в других конфигурациях контроль обмена — отдельная настройка, и без адресата уведомлений любой сбой остаётся незамеченным.

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

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

И последнее: если учёт ведётся не в 1С, а в облачном сервисе, эта статья не про вас — механика обмена с МоимСкладом другая, и ей посвящена отдельная страница интеграция с МоимСкладом. Если же главная задача — работа отдела продаж с заявками, а не учёт, точнее подойдёт интеграция с CRM: передача сделок в CRM — отдельная интеграция со своей логикой.

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