Данные и интеграции

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

Назначение контура

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

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

Ландшафт систем

PIM (управление товарным контентом)

Хранит товарную модель: атрибуты, варианты, медиа, связи, канальные представления. PIM — единственный источник контента карточки, но не цены и не остатка: их источники лежат в учётной системе. Без выделенного PIM роль контент-мастера часто выполняет каталог платформы; это допустимо до появления второго канала сбыта. Структура каталога на примере Akeneo: concepts/catalog-structure.

ERP и 1С (УТ, УНФ, ERP)

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

CRM

Владеет клиентом как субъектом продаж: историей общения, сделками, сегментами, ответственным менеджером. CRM не владеет профилем аутентификации и адресом доставки — их источник в платформе. Из-за этого клиентская сущность синхронизируется двусторонне, и главный риск — дубли одного клиента в обеих системах.

OMS (управление заказами)

Распределяет заказы по складам и способам исполнения, ведёт их состояние. В небольших проектах роль OMS исполняет сама платформа или учётная система; выделенный OMS появляется при нескольких складах, dropshipping или разбиении заказов. Подробнее — в заказах и остатках.

WMS (управление складом)

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

ЭДО (юридически значимый документооборот)

Переносит документы (счета, УПД, акты, накладные) между контрагентами через оператора. ЭДО не владеет коммерческими данными — только юридически значимыми документами и их статусами. Жизненный цикл финансовых документов описан в платежах и документах; здесь важен лишь факт, что статусы документов — самостоятельный поток обмена.

Матрица source of truth

Ключевое решение контура — для каждой сущности ровно одна master-система. Данные рождаются у владельца и расходятся по направлениям; ни одна система не редактирует чужую сущность напрямую.

Сущность	Master-система	Владелец данных	Направление обмена	Канал	Допустимая задержка	Типовой конфликт	Способ сверки
Товар (карточка, атрибуты, медиа)	PIM или каталог платформы	Каталожная команда	Master → витрина, фиды, маркетплейсы	API / файлы	Часы	Полнота атрибутов на витрине и в фиде расходится	Периодический отчёт полноты карточек по каналам
Клиент	CRM	Отдел продаж	Двусторонне: заказы из витрины → CRM, статусы и сегменты → обратно	API / события	Минуты	Дубль клиента: одно лицо, два ID	Матчинг по e-mail/телефону при приёме
Цена	Учётная система (1С/ERP)	Коммерческий блок	Учёт → витрина	API / файлы	5–15 минут	Не снятая акционная цена, не тот прайс-лист	Выборочная сверка цен витрина против учёта
Остаток	Учётная/складская система	Склад и закупки	Учёт → витрина	API / события	Секунды–минуты	Витрина продала то, чего нет (задержка)	Ежедневная сверка доступности к продаже
Заказ	Платформа (витрина)	Служба эксплуатации	Витрина → учёт / OMS, статусы обратно	API / события	Минуты	Дубль заказа при повторной отправке	Клиентские ID сообщений и журнал обмена
Оплата	Платёжный провайдер	Бухгалтерия	Провайдер → учёт; факт оплаты → заказ	API / webhook	Минуты	Оплата есть, заказ не обновлён (потерянный webhook)	Сверка реестров провайдера с заказами
Отгрузка	WMS / учётная система	Склад	WMS/учёт → витрина	API	Минуты	Отгружено физически, витрина не закрыта	Сверка отгрузок по накладным
Документ (счёт, УПД, акт)	Учётная система / ЭДО	Бухгалтерия	Учёт → ЭДО → контрагент	ЭДО-оператор	Часы	Контрагент не получил документ	Статусы документов у оператора
Возврат	Учётная система	Склад + бухгалтерия	Витрина → учёт (заявка), учёт → витрина (факт)	API / файлы	Часы	Возврат оприходован, витрина не знает	Сверка возвратов по документам

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

Типовые дефекты контура

Признаки того, что контур спроектирован плохо, замечаемые по симптомам, а не по коду:

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

Каждый дефект ссылается на конкретное решение контура: владение, канал, задержку, журнал или сверку.

Различия B2C и B2B

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

Процессы и статусы обмена

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

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

Порядок проектирования контура

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

Назвать системы-участники и для каждой — роль, инвентаризируя, чем она владеет на самом деле, а не на бумаге.
Заполнить матрицу source of truth по всем сущностям таблицы выше, включая согласованную задержку.
Зафиксировать каналы обмена под задержку: событие для секунд, API для минут, файлы для часов.
Для каждого нового канала сбыта выписать его потребности из карточки и провести их через PIM/платформу.
Спроектировать журнал обмена и ручную очередь ошибок до первого боевого обмена, а не после первого инцидента.
Назначить сверки и их владельцев; сверка без имени исполнителя не выполняется.

Исключения и частные случаи

Цифровые товары и услуги без физического остатка: поток «остаток» вырождается, master по доступности — платформа.
Маркетплейс-агрегатор: часть сущностей (остатки поставщика) владеется вне вашего периметра — см. маркетплейс-агрегатор.
Новый магазин без учёта: сначала платформа владеет всем, потом данные переезжают в учёт; миграция — отдельный проект, а не настройка обмена.

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

Проверяйте проект по этим вопросам до начала разработки:

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

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

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

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

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