Кто источник истины: клиент, товар, цена, остаток, заказ

Опубликовано: 27.08.2026 Обновлено: 27.08.2026 Время чтения: 15 мин

Автор и издатель: редакция «Пятого фактора».

Практическая матрица данных для CRM, сайта, склада, банка и бухгалтерии

У среднего интернет-магазина или B2B-компании данные о клиенте, товаре, цене, остатке и заказе одновременно живут в CRM, на сайте, на складе, в банке-эквайере и в бухгалтерской системе. Как только эти системы начинают обмениваться данными без чёткого правила «кто здесь главный», возникает рассинхрон: менеджер видит одну сумму задолженности, склад — другую, бухгалтерия — третью. Ниже — рабочая матрица, которая закрепляет за каждой сущностью одну систему-источник (source of truth), а за остальными — роль потребителя копии данных, с учётом требований 152-ФЗ и 54-ФЗ для российского бизнеса.

Зачем вообще договариваться, кто «главный»

Типичная ситуация в растущей компании: менеджер по продажам говорит, что клиент заказал на миллион рублей, бухгалтерия видит оплату на 800 тысяч, а склад отчитался об отгрузке на 950 тысяч. Все правы, и одновременно никто не прав — потому что каждая система смотрит на свой срез процесса в свой момент времени. Именно для решения такой ситуации и вводится концепция единой точки правды: вся информация о клиенте, его заказах и платежах должна храниться и сверяться в одном согласованном месте, а не разъезжаться по системам [5].

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

Простыми словами: что такое источник истины

Источник истины (source of truth) — это система, значение поля в которой считается официальным и обязательным для всех остальных. Все прочие системы либо получают из неё копию данных для собственных нужд, либо присылают в неё событие, из которого система-источник формирует итоговое значение.

Это частный случай более общей дисциплины — управления мастер-данными (Master Data Management, MDM). MDM работает с мастер-данными для создания «золотой записи» — целостного эталонного представления о мастер-сущности, которое используется всем предприятием как эталон при обмене информацией, а специализированные MDM-системы автоматизируют этот процесс и становятся «авторитетным» источником данных масштаба предприятия [2]. Практически это означает, что MDM централизует и стандартизирует ключевую информацию внутри компании, создавая единый источник истины, благодаря которому все отделы работают с согласованными, точными и актуальными записями [3].

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

Как это работает на практике: пять сущностей — пять систем-источников

Возьмём пять типовых сущностей интернет-магазина или B2B-компании и разберём, кто должен быть их источником истины.

Клиент

Клиент — сущность с двумя разными наборами данных: контактно-коммерческие (имя, телефон, история обращений, договорённости) и персональные данные в юридическом смысле (ФИО, паспорт, адрес доставки). Как правило, источником истины по коммуникациям и статусу сделки выступает CRM: открыв карточку клиента, менеджер должен видеть полную картину — что покупал, когда платил, о чём договаривались и какие были проблемы [5]. При этом сайт обычно выступает лишь точкой сбора первичной заявки, а не хранилищем окончательной версии данных о клиенте: как только пользователь отправляет форму, CRM может самостоятельно создавать сделку и заполнять её ключевыми полями — направлением, ответственным менеджером, стадией воронки продаж [6].

Отдельный нюанс — задолженность клиента, которую менеджер видит прямо в карточке сделки: CRM-модули, интегрированные с учётной системой, дают доступ к актуальным остаткам товаров и данным о взаиморасчётах с клиентом, но сама сумма долга рассчитывается и остаётся источником истины в учётной или бухгалтерской системе, а в CRM лишь отображается [1].

Здесь же встаёт юридический слой: как только у компании появляется электронная форма или CRM с контактами человека, компания автоматически становится оператором персональных данных — даже если клиент просто оставил телефон через форму обратной связи на сайте, и независимо от формы собственности и объёма данных [16]. Это означает отдельную ответственность: любая организация, которая собирает, хранит, использует или передаёт такие данные, — оператор, а нарушения закона влекут не только корпоративную, но и личную ответственность руководителя или ИТ-директора [17]. Это отдельная причина не размножать бесконтрольные копии карточки клиента по всем системам «на всякий случай» — чем меньше систем реально хранят персональные данные, тем проще соблюдать закон.

Товар (карточка, характеристики, контент)

Для карточки товара — названия, описания, характеристик, фото — источником истины логично делать либо учётную систему (1С, ERP), либо специализированную PIM-систему, если товаров и каналов продаж много. Идея единого источника правды о продукте в том, что информация об SKU собирается один раз и автоматически расходится по всем каналам продаж — сайту, маркетплейсам, рознице, B2B-порталу, — благодаря чему физически не может возникнуть расхождение данных между разными площадками [18]. Сайт, маркетплейсы и мобильное приложение в этой модели — витрины, которые получают контент, но не редактируют его напрямую.

Цена

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

Остаток

Остаток — самая динамичная сущность: она меняется при каждой продаже, поступлении, резервировании и инвентаризации. Здесь источник истины физически распадается на два уровня. Учётная система (1С, ERP) хранит обобщённые остатки по компании в целом и правила резервирования под заказ. Складская система (WMS), если она есть, детализирует, где именно физически лежит товар, — но именно учётная система остаётся «точкой правды» по остаткам, объёмам и срокам поставок, а WMS выступает для неё источником данных, как и любой другой канал продаж вроде B2B-портала [9]. Разделение ролей закреплено и на уровне интеграции: ERP фиксирует финансовый учёт, планирование закупок и оборотные остатки, а WMS отвечает за фактическое движение товара внутри склада, при этом обмен между ними должен быть двусторонним — WMS получает задания из ERP и передаёт статус их выполнения обратно [8]. Продавцу-менеджеру важно видеть именно свободный остаток за вычетом резервов, а не «физическое» количество на складе, и одновременно сообщать клиенту актуальную цену с учётом всех скидок и акций [7].

Заказ (и статус оплаты)

Заказ — составная сущность: сам факт заказа фиксируется в CRM или учётной системе, а вот статус его оплаты — прерогатива платёжного шлюза и банка-эквайера. Здесь стоит отличать промежуточные статусы платежа от финального результата: провайдер токенизирует данные карты и инициирует авторизацию через банк-эмитент, после подтверждения доступности средств статус меняется на «authorized», а после списания — на «captured», которое может происходить сразу или позже, например после отгрузки товара [11]. Финальным и обязательным источником истины по статусу платежа выступает не факт визуального отображения «оплачено» на странице оформления заказа, а вебхук от платёжной системы — именно он считается основным источником правды о финальном статусе [10].

Практическая сложность в том, что вебхуки могут дублироваться или приходить не по порядку, поэтому магазину нужна собственная логика идемпотентности поверх банковской: проверка подписи сообщения и проверка идемпотентности решают разные задачи, и валидно подписанное сообщение всё равно может оказаться повторной доставкой, поэтому для критичных операций стоит определять более сильное бизнес-правило — например, что бонус за один и тот же идентификатор платежа может быть начислен не более одного раза, а не просто исключать дубли по идентификатору события [12]. При этом карточные данные в идеале вообще не должны попадать на сервер магазина: современная интеграция платёжных систем строится так, чтобы вебхуки, гарантированная идемпотентность и минимальные требования PCI DSS делали приём платежей надёжным, а соблюдение этого стандарта обязательно для любой организации, принимающей платежи с банковских карт [13].

Российская специфика: 54-ФЗ и фискальный контур

Помимо коммерческого статуса оплаты в CRM или учётной системе, у продажи в России есть отдельный обязательный слой — фискальный. Источником истины по факту расчёта с точки зрения закона выступает не банк и не CRM, а связка ККТ (онлайн-касса) и оператор фискальных данных (ОФД): касса формирует чеки и другие документы и передаёт их ОФД через интернет, а оператор формирует подтверждение для каждого документа, обрабатывает, хранит и передаёт данные в налоговую службу [14]. Именно ККТ формирует юридически значимый документ о расчёте — фискальные документы, включая кассовые чеки в бумажном и электронном виде, с последующей передачей данных о продажах ОФД в онлайн-режиме [15].

Это значит, что для полностью корректной архитектуры интернет-магазина нужно различать минимум три статуса одной и той же операции: коммерческий статус заказа в CRM/1С («оплачен», «в обработке»), технический статус платежа у эквайера («authorized», «captured», «declined») и фискальный статус чека у ОФД. Смешивать их в одно поле — частая причина расхождений между продажами, деньгами на счёте и налоговой отчётностью.

Практическая матрица: кто владеет чем

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

Сущность / поле Источник истины Кто получает копию Что важно синхронизировать Карточка клиента (контакты, история) CRM Сайт (личный кабинет), бухгалтерия (контрагент) Обновление контактов, статус согласия на обработку персональных данных Персональные данные клиента (юридический слой, 152-ФЗ) CRM/учётная система, где заведена карточка Все системы, куда данные передаются по договору поручения Согласия, сроки хранения, право на удаление Карточка товара, контент Учётная система или PIM Сайт, маркетплейсы, каталоги партнёров Название, характеристики, фото, категория Цена Учётная система (прайс-лист, правила скидок) Сайт, CRM, маркетплейсы Базовая цена, спецусловия для сегментов клиентов, акции Остаток (обобщённый, по компании) Учётная система (ERP) Сайт, CRM, маркетплейсы Свободный остаток за вычетом резерва Остаток (физическое размещение на складе) WMS Учётная система Ячейка, партия, статус (в резерве, в пути, брак) Заказ (факт и состав) CRM или учётная система Склад, сайт (личный кабинет клиента) Состав, адрес доставки, ответственный менеджер Статус оплаты (коммерческий/технический) Платёжный шлюз / банк-эквайер (вебхук) CRM, учётная система Идемпотентность обработки, сверка расхождений по идентификатору платежа Фискальный чек ККТ + ОФД Бухгалтерия, клиент (копия чека) Соответствие суммы чека фактическому платежу Итоговые финансовые проводки Бухгалтерская система Руководство (отчёты), CRM (задолженность) Соответствие данных о поступлении денег и отгрузке товара Общий принцип матрицы: система-источник хранит поле и правило его изменения, все остальные системы работают с read-only копией, которую можно перезаписать только через тот же самый источник, а не напрямую.

Практические этапы синхронизации

Инвентаризация текущих данных. Нужно честно ответить на вопрос, где сейчас лежат прайсы, описания товаров, фото и контакты клиентов — часто выясняется, что часть данных существует только в Excel у конкретного сотрудника или в устаревшей CRM, и без этой карты внедрять единый источник данных всё равно что строить дом без фундамента [4].
Закрепление системы-источника за каждой сущностью. Формализуется в виде матрицы, аналогичной приведённой выше, и утверждается как внутренний регламент, а не остаётся устной договорённостью.
Настройка одностороннего потока данных. Для большинства пар «источник — потребитель» синхронизация должна идти в одну сторону: добавление и обновление товарных карточек, цен и остатков происходит автоматически при изменениях в учётной системе, и это одна из приоритетных задач при интеграции сайта с 1С [19].
Двусторонний обмен только там, где это необходимо. Исключение — статусы выполнения складских операций (WMS передаёт факт отгрузки обратно в ERP) и вебхуки платёжных систем (эквайер присылает статус, который меняет состояние заказа).
Обработка ошибок и повторов. Для вебхуков и складских интеграций закладывается идемпотентность на уровне бизнес-правила, а не только на уровне технического идентификатора события.
Регламент по персональным данным. Определяется, какие системы реально обрабатывают персональные данные, заключаются договоры поручения с подрядчиками, у которых есть доступ к этим данным.
Тестирование на контрольных сценариях. Проверяется поведение при повторной доставке вебхука, при расхождении остатка между складом и сайтом, при частичной оплате заказа.

Ограничения, типичные ошибки и риски

Двусторонняя синхронизация «на всякий случай». Если и сайт, и учётная система могут менять цену, рано или поздно они разойдутся, и починка потребует ручной сверки каждой позиции.
Смешение статусов платежа и статуса заказа. Если CRM помечает заказ «оплачен» по факту клика на кнопку оплаты, а не по вебхуку от эквайера, компания рискует отгрузить товар по неоплаченному заказу.
Игнорирование идемпотентности. Формальное описание вида «получить событие, установить статус “оплачено”, начислить бонус, отправить письмо» недостаточно для реальной интеграции: без отдельно определённого уровня идемпотентности на уровне бизнес-логики повторно доставленный вебхук может привести к двойному списанию остатка или повторному начислению бонуса [12].
Отсутствие разделения физического и учётного остатка. Если склад физически видит один остаток, а ERP хранит другой (без выделенной WMS-логики), инвентаризация и обещания клиентам расходятся с реальностью.
Нарушение 152-ФЗ из-за бесконтрольного размножения копий клиентских данных. После поправок 2025 года штрафы по статье 13.11 КоАП РФ заметно выросли и стали дифференцированными: от 100 000–300 000 рублей для юрлица за обработку данных без должного уведомления Роскомнадзора до оборотных штрафов в 1–3% годовой выручки (но не менее 20 млн и не более 500 млн рублей) при повторной утечке — поэтому чем больше систем хранит персональные данные без документального основания, тем выше совокупный риск [17], [20].
Смешение фискального и коммерческого учёта. Ошибочно считать, что бухгалтерская проводка и фискальный чек — это одно и то же событие; для сверки нужно явно связывать их между собой по идентификатору операции.

Как может помочь «Пятый фактор»

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

Вывод

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

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

Источники

[1] erp.is1c.ru — 1С:CRM — управление продажами и клиентами от 1С:ERP — https://erp.is1c.ru/1c-crm

[2] habr.com — Что такое «система управления мастер-данными» и зачем она нужна — https://habr.com/ru/articles/324148/

[3] omni.korusconsulting.ru — MDM-системы: как эффективно и безошибочно управлять данными бизнеса — https://omni.korusconsulting.ru/blog/mdm-sistemy-kak-effektivno-i-bezoshibochno-upravlyat-dannymi-biznesa/

[4] marketprovider.ru — Single Source of Truth (SSOT) в PIM и зачем это нужно вашему бизнесу — https://marketprovider.ru/blog/article/ssot

[5] crmai.kz — Управление клиентами, заказами и биллингом: CRM как единая точка правды — https://crmai.kz/blog/upravlenie-klientami-zakazami-billingom-crm-edinaya-tochka

[6] cleverence.ru — CRM: интеграция с сайтом и 1С — как объединить бизнес в единую цифровую систему — https://www.cleverence.ru/articles/auto-busines/-integratsiya-crm-kak-obedinit-sistemu-s-saytom-i-1s/

[7] 1ccrm.com — 1С:CRM модуль для 1C:ERP и 1C:KA — https://1ccrm.com/1c-modul-crm/

[8] cleverence.ru — Интеграция WMS с ERP: как связать склад с учётом и продажами — https://www.cleverence.ru/articles/sklad-i-logistika/-integratsiya-wms-s-erp/

[9] intervolga.ru — Лучшие практики интеграции: объединяем 1С, WMS и B2B-платформу — https://www.intervolga.ru/blog/1C/luchshie-praktiki-integratsii-obedinyaem-1s-wms-i-b2b-platformu-chtoby-vyrastit-prodazhi-v-7-raz/

[10] ekvairing-dlya-saita.ru — API интернет-эквайринга: платёжные методы, вебхуки, безопасность — https://ekvairing-dlya-saita.ru/api-i-dokumentaciya/

[11] ekvairing-dlya-saita.ru — Интернет-эквайринг для сайта: как работает и из чего состоит — https://ekvairing-dlya-saita.ru/internet-ekvairing/

[12] habr.com — Как корректно описать приём и обработку webhook — https://habr.com/ru/companies/otus/articles/1064436/

[13] esk-solutions.com — Интеграция платёжных систем: вебхуки, идемпотентность и PCI DSS — https://esk-solutions.com/ru/information/1905-platezhnye-sistemy-integracija-webhooks-idempotentnost-pci.html

[14] kontur.ru — Основные требования 54-ФЗ: что нужно знать бизнесмену — https://kontur.ru/market/spravka/295-kto_i_kogda_perehodit_na_online_kassy

[15] atol.online — Закон 54-ФЗ: что нужно знать — https://atol.online/blog/articles/zakon-54-fz-chto-nuzhno-znat/

[16] reg.ru — 152-ФЗ: коротко для бизнеса — https://www.reg.ru/blog/zakon-152-fz-personalnye-dannye/

[17] infars.ru — 152-ФЗ о персональных данных: требования, документы и меры защиты для бизнеса — https://infars.ru/blog/152_fz-o-personalnykh-dannykh_-chto-dolzhen-znat-kazhdyy-vladelets-biznesa/

[18] bpadevelop.ru — PIM-система: как работает, зачем бизнесу и как внедрить — https://bpadevelop.ru/blog/pim-sistema/

[19] studia-crm.ru — Интеграция 1С с сайтом — автоматизация обмена данными для интернет-магазина — https://studia-crm.ru/integracziya-1s-s-sajtom/

[20] klerk.ru — Штрафы Роскомнадзора за персональные данные в 2026 году — https://www.klerk.ru/blogs/fedresurs/702077/