Системы и потоки данных: обмен с 1С, ERP и CRM

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

Назначение и границы

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

Участники обмена

1С (УТ, УНФ, ERP) — учётная система, из которой уходят товары, цены, остатки и куда стекаются заказы. Возможности обмена зависят от конфигурации: УНФ и УТ дают стандартный протокол обмена с сайтом, ERP — расширенную модель данных; см. протокол обмена с сайтом.
«МойСклад» — облачный учёт с JSON API по товарам, заказам, контрагентам и документам; типичен для небольших проектов без серверной 1С: JSON API.
CRM — клиентская база и сделки. В РФ-практике это Битрикс24, amoCRM или самописные решения; обмен с витриной почти всегда кастомный, потому что CRM API различаются составом сущностей.

Может быть комбинация: 1С владеет ценами и остатками, CRM — клиентами и сделками, витрина — заказами и профилями аутентификации. Компромисс — дублирование сущностей в двух системах; он допустим, если закрыт матчем при приёме (см. ниже).

Способы обмена

Три канала работают в связке, а не вместо друг друга:

Канал	Что передаёт	Когда уместен	Ограничения
Прямое API	Заказы, статусы, цены, остатки — по запросу или по событию	Оба конца подписаны, задержки измеряются секундами	Нужна авторизация, лимиты, обработка недоступности peer-системы
Файлы (CommerceML/CML, CSV)	Полные выгрузки каталога, цен, остатков; обмен с сайтом по протоколу 1С	Регламентные выгрузки, большой объём, отсутствие API	Задержки от минут до часов; нужна защита от частичной записи
События / webhooks	Точечные изменения: оплата, статус, остаток после списания	События, где важна задержка в секунды	Потеря события требует реконсиляции — webhook не доставка, а уведомление

CommerceML/CML — историческая пара формата обмена 1С с сайтом; CSV остаётся для собственных выгрузок и партнёрских интеграций, где контракт проще файла, чем API.

Привязка к версии 1С

Возможности обмена привязывать к конфигурации и версии («1С:УНФ 3.1», «УТ 11.5», «ERP 2.5»), а не к «есть 1С вообще». По одной и той же версии одного и того же протокола разные конфигурации отдают разный состав полей: в одной есть shipping-адрес и налоговые группы, в другой — нет; в одной поддерживаются характеристики (варианты), в другой — только артикулы.

Практическое правило: состав полей обмена фиксируется в спецификации на уровне «конфигурация + версия + ревизия обмена» и проверяется пилотной выгрузкой до начала разработки витрины. Обещание «единый обмен с любой 1С» в реалистичных проектах не реализуется; расширение состава полей почти всегда требует изменения конфигурации на стороне учётной системы.

Техника надёжного обмена

За рамками простого «настроить обмен» остаётся техника, без которой интеграция деградирует в первые месяцы:

Очереди. Обмен через очередь, а не синхронный вызов в момент оформления заказа: пользователь не должен ждать ответа учётной системы. Очередь сглаживает пики и делает недоступность 1С незаметной для покупателя.
Идемпотентность. Каждое сообщение несёт клиентский ID (ID заказа на витрине, версия товара, hash изменений); повторная доставка не создаёт дубль, а обновляет существующую запись. Без клиентских ID любой ретрай переотправленного заказа — источник дубликатов в учёте.
Лимиты и повторы. Для API-обмена фиксируются лимиты запросов и политика повторов с экспоненциальной задержкой и ограничением количества попыток; после исчерпания попыток сообщение уходит в ручную очередь.
Журнал обмена. Каждое сообщение логируется с направлением, сущностью, client-ID, статусом и меткой времени. Журнал отвечает на три вопроса: что ушло, когда и с каким результатом.
Ручная очередь ошибок. Ошибки, не решённые автоматикой (битые данные, конфликт версий), попадают в очередь с ответственным, который разбирает их по журналу; автоматический ретрай бесконечно не считается «разбором».

Направления и состав потоков

Поток	Откуда → куда	Состав	Триггер	Гарантии
Товары, цены, остатки	Учёт → витрина	Карточка учёта, прайс-листы, доступность к продаже	Регламент + событие изменения	Идемпотентность по артикулу/версии, сверка выборки
Заказы	Витрина → учёт	Состав, контакт, доставка, способ оплаты, промокод	Событие завершения заказа	Клиентский ID, ретраи с экспонентой, ручная очередь
Клиенты	Двусторонне	Профиль, контакты, реквизиты юрлица, сегменты	Событие регистрации/заказа	Матчинг по e-mail/телефону, приоритет источника
Статусы	Учёт/OMS → витрина	Отгружен, отозван, отправлен, вручён, отменён	Событие перехода статуса	Уведомления + периодическая сверка

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

Модель недоступности peer-систем

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

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

Практическое правило: формулировка «обмен лежит — магазин не продаёт» в SLA означает, что интеграция не спроектирована, и это возвращает проект к очереди и буферам из предыдущего раздела.

Сверка после обмена

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

заказы за период на витрине против учёта (счётчик и сумма);
доступность к продаже — витрина против учёта по ключевым SKU;
платежи — вебхуки и статусы заказов против реестров провайдера;
возвраты и отгрузки — по номерам документов.

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

Различия B2C и B2B

В B2C обмен в основном «учёт → витрина» плюс заказы обратно; клиентская база маленькая и однородная. В B2B добавляются персональные прайс-листы, реквизиты юрлица и договоры, лимит дебиторки, согласование заказа — каждый контрагентный атрибут должен доехать из учёта на витрину или в CRM и обратно без ручной синхронизации. B2B-модель в целом описана в B2B-портале и опте, а юридические документы, которые ездят по ЭДО, — в платежах и документах; статусы документов у операторов типа Диадок выписываются отдельно: статусы Диадока.

Исключения и ограничения

Проект без учёта: витрина остаётся master для заказов до момента заведения учёта; миграция — отдельный проект.
Физический остаток без учётной системы (чистый WMS): остатки синхронизируются со складом, но цены и документы всё равно требуют учёта.
Мультиканальность (несколько витрин на один учёт): каждый канал — своя очередь и свой client-ID, общими остаются справочники и учёт.

Критерии выбора

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

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

Связанные страницы

Обзор контура «Данные и интеграции» — кто владеет каждой сущностью и какая задержка допускается.
Товарные данные: модель, атрибуты и качество — что именно доезжает из PIM и учёта до каналов.
Заказы и остатки: состояния, резерв и склад — бизнес-события, которые летят по потокам обмена.
Надёжность и безопасность — эксплуатационные требования к интеграционной инфраструктуре.
Жизненный цикл платежа — события от платёжного провайдера, попасть в потоки обмена.

Материалы и источники

Протокол обмена с сайтом, 1С — подтверждает стандартный канал обмена 1С с сайтом и его состав.
МойСклад JSON API — подтверждает API-модель облачного учёта: сущности заказов, контрагентов, товаров.
Статусы Диадока — подтверждает, что юридически значимые документы ходят со своими статусами оператора.
Saby (СБИС) API — подтверждает альтернативного оператора ЭДО с API-интеграцией.