---
title: Данные и интеграции
description: Где хранится истина по товарам, клиентам, ценам, остаткам и заказам и как системы обмениваются этими данными.
---

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

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

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

Вне этого контура остаются сами движения денег и физическое исполнение: жизненный цикл платежей и кассовые события — в [платежах и документах](https://wpcraft.ru/kb/practices/ecommerce/payments.md), доставка, вручение и возврат товара — в [логистике и постпродаже](https://wpcraft.ru/kb/practices/ecommerce/logistics.md). Здесь описываются только данные, которыми эти контуры обмениваются.

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

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

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

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

Учётная система владеет ценами, прайс-листами, остатками, взаиморасчётами и документами. Она же почти всегда остаётся системой, куда стекаются заказы с витрины и откуда возвращаются статусы исполнения. Обмен с сайтом у 1С стандартизирован протоколом обмена, но состав того, что реально ходит по протоколу, зависит от конфигурации и версии — об этом подробнее в [потоках данных](https://wpcraft.ru/kb/practices/ecommerce/integrations/systems-and-data-flows.md).

### CRM

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

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

Распределяет заказы по складам и способам исполнения, ведёт их состояние. В небольших проектах роль OMS исполняет сама платформа или учётная система; выделенный OMS появляется при нескольких складах, dropshipping или разбиении заказов. Подробнее — в [заказах и остатках](https://wpcraft.ru/kb/practices/ecommerce/integrations/orders-and-inventory.md).

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

Владеет физическим размещением, отбором, сборкой и отгрузкой. WMS не решает, сколько «продавать» на витрине: доступность к продаже считает учётная или распределительная система по данным склада. У 1С есть собственное складское решение, учитывающее адресное хранение и отбор: [1С:WMS](https://solutions.1c.ru/catalog/wms4/features).

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

Переносит документы (счета, УПД, акты, накладные) между контрагентами через оператора. ЭДО не владеет коммерческими данными — только юридически значимыми документами и их статусами. Жизненный цикл финансовых документов описан в [платежах и документах](https://wpcraft.ru/kb/practices/ecommerce/payments.md); здесь важен лишь факт, что статусы документов — самостоятельный поток обмена.

## Матрица 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-портал и опт](https://wpcraft.ru/kb/practices/ecommerce/models/b2b-portal-wholesale.md). Это означает, что поток «цена» перестаёт быть одним прайс-листом: появляется матрица «контрагент × прайс-лист», и её master — учётная система, а не витрина. Поток «клиент» обрастает реквизитами юрлица и договорами, которые живут в учёте и CRM, но не в платформе.

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

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

Отдельный класс — события, которые приезжают извне вашего периметра: вебхуки платёжного провайдера о факте оплаты, статусы перевозчика о вручении. Они тоже входят в контур, но как входящие уведомления с обязательной периодической сверкой, потому что событие может не дойти. Полную технику — очереди, идемпотентность, журнал — см. в [системах и потоках данных](https://wpcraft.ru/kb/practices/ecommerce/integrations/systems-and-data-flows.md); состояния заказа и резервы — в [заказах и остатках](https://wpcraft.ru/kb/practices/ecommerce/integrations/orders-and-inventory.md).

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

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

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

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

- Цифровые товары и услуги без физического остатка: поток «остаток» вырождается, master по доступности — платформа.
- Маркетплейс-агрегатор: часть сущностей (остатки поставщика) владеется вне вашего периметра — см. [маркетплейс-агрегатор](https://wpcraft.ru/kb/practices/ecommerce/models/marketplace-aggregator.md).
- Новый магазин без учёта: сначала платформа владеет всем, потом данные переезжают в учёт; миграция — отдельный проект, а не настройка обмена.

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

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

- Для каждой сущности из матрицы названа ровно одна master-система — или конфликт задокументирован.
- Задержки обмена согласованы с бизнесом (сколько минут магазин может продавать «прошлые» остатки).
- Для каждого канала сбыта известно, что именно он потребляет из карточки (см. [товарные данные](https://wpcraft.ru/kb/practices/ecommerce/integrations/product-data.md)).
- У каждой интеграции есть журнал обмена и процедура ручного разбора ошибок.
- Учётная система и её версия названы по конфигурации, а не «есть 1С» — от этого зависят возможности обмена (см. [потоки данных](https://wpcraft.ru/kb/practices/ecommerce/integrations/systems-and-data-flows.md)).

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

- [Товарные данные: модель, атрибуты и качество](https://wpcraft.ru/kb/practices/ecommerce/integrations/product-data.md) — как устроена карточка и что из неё потребляет каждый канал.
- [Системы и потоки данных: обмен с 1С, ERP и CRM](https://wpcraft.ru/kb/practices/ecommerce/integrations/systems-and-data-flows.md) — участники, каналы и техника надёжного обмена.
- [Заказы и остатки: состояния, резерв и склад](https://wpcraft.ru/kb/practices/ecommerce/integrations/orders-and-inventory.md) — жизненный цикл заказа и модель доступности к продаже.
- [Платформа и витрина](https://wpcraft.ru/kb/practices/ecommerce/storefront.md) — на чём строится магазин и как покупатель оформляет покупку.

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

- [Структура каталога Akeneo](https://api.akeneo.com/concepts/catalog-structure.html) — подтверждает товарную модель и канальные представления PIM.
- [Протокол обмена с сайтом, 1С](https://v8.1c.ru/tekhnologii/obmen-dannymi-i-integratsiya/standarty-i-formaty/protokol-obmena-s-saytom/) — подтверждает стандартный канал обмена между учётной системой и сайтом.
- [1С:WMS](https://solutions.1c.ru/catalog/wms4/features) — подтверждает границы ответственности складской системы.