Каталог и остатки: правила «одного источника правды» между 1С, CRM и маркетплейсами

Однажды наш клиент — владелец сети магазинов бытовой техники — позвонил в воскресенье вечером. Голос у него был такой, будто он только что узнал о конце света. «У нас на Ozon продали 47 кондиционеров, которых нет на складе. Wildberries заблокировал карточку за пересортицу. А в 1С остатки вообще другие. Что происходит?»

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

История со счастливым концом: за три недели мы выстроили нормальную архитектуру синхронизации. Но сначала пришлось разобраться с фундаментальным вопросом, который мучает любой бизнес, продающий через несколько каналов: кто главный? Кто решает, какая информация о товаре правильная? Откуда брать актуальные остатки? Как не сойти с ума с вариантами, наборами и комплектами?

В этой статье я расскажу про принцип «единого источника правды» (Single Source of Truth, SSOT) применительно к товарному каталогу. Без воды и абстрактных рассуждений — конкретные правила, которые работают на практике.

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

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

1С — там живёт бухгалтерия, склад, закупки. Номенклатура ведётся по правилам бухучёта: артикулы, единицы измерения, себестоимость. Всё строго, всё по ГОСТу. Но маркетинговые описания, фотографии, SEO-тексты — это не про 1С.

CRM — здесь менеджеры работают с клиентами. Им нужны быстрые ответы: «Есть в наличии?», «Когда будет?», «Сколько стоит со скидкой?». CRM показывает карточки товаров, но откуда она берёт данные? Часто — из собственной базы, которую кто-то когда-то загрузил из Excel и с тех пор обновляет вручную.

Маркетплейсы — Ozon, Wildberries, Яндекс Маркет. У каждого свои требования к карточкам, свои форматы, свои категории. Продавцы заводят товары прямо в личном кабинете маркетплейса, потому что «так быстрее». В итоге на площадке живёт своя версия каталога, которая с 1С связана условно.

Сайт — ещё одна система со своим каталогом. CMS, админка, загрузка через CSV. Фотографии одни, описания другие, цены третьи.

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

Single Source of Truth: кто должен быть главным

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

Звучит очевидно. На практике — вызывает споры. Потому что у каждого отдела свои аргументы, почему именно их система должна быть главной.

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

Базовая информация о товаре (Master Data)

Артикул (SKU), название, категория, единица измерения, штрихкод, производитель, базовые характеристики — это фундамент. Откуда эти данные берутся изначально? От поставщика или из внутренней номенклатуры компании. Где они должны храниться? В системе, которая управляет закупками и складом. В большинстве случаев это 1С.

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

Маркетинговый контент

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

Здесь источником правды обычно становится PIM-система (Product Information Management) или, если её нет, CMS сайта. Главное — чтобы это было одно место, откуда контент распространяется на все каналы: сайт, маркетплейсы, CRM (для скриптов продаж).

Остатки и доступность

Это самая болезненная тема. Остатки меняются постоянно: продали, вернули, списали, переместили между складами, зарезервировали под заказ. Кто знает актуальный остаток? Только WMS (система управления складом) или складской модуль 1С.

Никакая CRM, никакой маркетплейс не должны хранить остатки как источник правды. Они могут кэшировать, показывать, но не владеть. Если менеджер в CRM вручную меняет остаток — это путь к катастрофе.

Цены

С ценами сложнее. Базовая цена (себестоимость + наценка) формируется в 1С. Но розничная цена, скидки, промо-акции — это уже маркетинг и продажи. Здесь часто работает гибридная модель:

• Базовая цена — источник в 1С
• Канальные цены и скидки — источник в CRM или отдельном модуле ценообразования
• Цены для маркетплейсов — рассчитываются с учётом комиссий площадки (можно в отдельном сервисе)

Главное правило: в каждый момент времени должно быть понятно, откуда взялась цена и кто имеет право её менять.

SKU, варианты, наборы, комплекты: как не запутаться

Отдельная головная боль — это структура каталога. Когда у вас простые товары типа «Молоток слесарный», всё просто: один артикул, один товар. Но реальный бизнес сложнее.

Варианты товара (цвет, размер, объём)

Футболка бывает S, M, L, XL. Смартфон — на 128 или 256 ГБ. Краска — в банках 1, 5, 10 литров. Как это хранить?

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

На маркетплейсах и сайте варианты объединяются в одну карточку. Покупатель видит «Футболка белая», выбирает размер из выпадающего списка. Это удобно для UX, но создаёт проблему маппинга: как связать SKU из 1С с вариантами в карточке Ozon?

Решение: ввести иерархию. Есть «родительский» товар (Product) — это сущность для маркетинга. И есть «дочерние» SKU (Variant) — это учётные единицы. В CRM и на сайте работаете с продуктами, но при проверке остатков и создании заказа обращаетесь к конкретным SKU.

Наборы и комплекты

Здесь ещё веселее. Есть два типа сущностей, которые часто путают:

Набор (Bundle) — это маркетинговая упаковка. «Всё для пикника: корзина + плед + термос». Физически на складе лежат три отдельных товара. При продаже набора со склада списываются три позиции. Набор не имеет своего остатка — его остаток равен минимуму из остатков компонентов.

Комплект (Kit) — это физически собранный товар. «Компьютер в сборе: системный блок + монитор + клавиатура». Комплект собирается на складе, получает свой артикул и учитывается как единица. При сборке компоненты списываются, комплект приходуется.

Почему это важно? Потому что логика учёта остатков разная:

• Набор: остаток = min(остаток_компонента_1, остаток_компонента_2, ...)
• Комплект: остаток — это остаток самого комплекта как отдельной позиции

В 1С наборы и комплекты реализуются по-разному. Если ваша интеграция этого не учитывает — готовьтесь к расхождениям.

Архитектура интеграции: как это должно работать

Теория — это хорошо, но давайте посмотрим, как выглядит работающая архитектура на практике.

Вариант 1: 1С как мастер-система

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

Плюсы:

• Один источник правды — меньше рассинхрона
• Бухгалтерия и склад всегда видят актуальные данные
• Привычно для команды, которая работает в 1С

Минусы:

• 1С не заточена под маркетинговый контент
• Медленно: изменения в 1С → выгрузка → обновление на сайте (может занять часы)
• Маркетологам приходится работать в 1С или через неудобные интерфейсы

Подробнее про интеграцию с 1С мы писали в статье Интеграция CrmAI с 1С: товары, цены, остатки, заказы.

Вариант 2: PIM-система как мастер каталога

PIM (Product Information Management) — специализированная система для управления товарной информацией. Akeneo, Pimcore, или даже Excel на стероидах — неважно, суть одна.

В этой схеме 1С остаётся мастером для учётных данных (остатки, цены закупки, бухгалтерия), но маркетинговый контент живёт в PIM. Оттуда он распространяется на сайт, маркетплейсы, CRM.

Плюсы:

• Маркетологи работают в удобном интерфейсе
• Легко управлять контентом для разных каналов
• Версионирование, workflow согласования, локализация

Минусы:

• Ещё одна система в ландшафте — ещё одна интеграция
• Нужно поддерживать связь между PIM и 1С
• Дополнительные затраты на лицензии и поддержку

Вариант 3: Интеграционная шина (ESB/iPaaS)

Для крупного бизнеса с множеством систем имеет смысл вынести интеграционную логику в отдельный слой. Это может быть классическая ESB (Enterprise Service Bus) или облачное решение типа MuleSoft, Boomi, или отечественный аналог.

В этой схеме каждая система публикует события («товар создан», «остаток изменился», «цена обновлена»), а шина маршрутизирует их в нужные системы-подписчики.

Плюсы:

• Гибкость: легко добавлять новые системы и каналы
• Централизованный мониторинг и логирование
• Можно трансформировать данные «на лету»

Минусы:

• Сложность и стоимость внедрения
• Нужна команда для поддержки
• Избыточно для малого и среднего бизнеса

Подробнее про событийную архитектуру — в статье Событийная архитектура (Event-Driven) для бизнеса.

Синхронизация остатков: правила, которые спасают от штрафов

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

Правило 1: Остаток всегда берётся из WMS/1С

Никогда не храните остатки в CRM или на сайте как источник правды. CRM может кэшировать остаток для быстрого показа менеджеру, но при создании заказа — всегда проверка в реальном времени.

Правило 2: Резервирование при создании заказа

Когда клиент оформляет заказ (на сайте, в CRM, на маркетплейсе), товар должен сразу резервироваться. Не «когда менеджер подтвердит», не «когда заказ попадёт в 1С», а сразу. Иначе один и тот же товар успеют продать дважды.

Как это работает технически: заказ создаётся → вызов API 1С/WMS → товар переходит из «свободного» в «зарезервированный» → свободный остаток уменьшается.

Правило 3: Страховой запас для маркетплейсов

На маркетплейсах лучше показывать не реальный остаток, а остаток минус страховой запас. Почему? Потому что между обновлением остатка на площадке и реальной продажей проходит время. Если у вас осталась одна штука, а вы показываете «1 в наличии» на Ozon и на сайте — есть шанс продать её дважды.

Типичная формула: Остаток_для_маркетплейса = Свободный_остаток - Страховой_запас. Страховой запас зависит от скорости продаж и частоты синхронизации. Для быстро продающихся позиций — больше, для slow movers — можно меньше.

Правило 4: Частота обновления зависит от канала

Не все каналы требуют обновления каждую секунду:

• CRM: реальное время или близко к нему (при запросе менеджера)
• Сайт: каждые 5-15 минут для большинства товаров
• Маркетплейсы: API позволяет обновлять часто, но есть лимиты. Обычно 15-60 минут
• Фиды для рекламы: раз в несколько часов достаточно

Правило 5: Обнуление остатка — триггер для карточки

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

Особенности работы с маркетплейсами: Ozon, Wildberries, Яндекс Маркет

Каждый маркетплейс — отдельный мир со своими правилами, API, ограничениями. Вот что нужно учитывать.

Ozon

Ozon — один из самых продвинутых с точки зрения API. Есть возможность управлять остатками в реальном времени, создавать карточки программно, получать уведомления о заказах через вебхуки.

Нюансы:

• У Ozon своя система категорий — нужен маппинг с вашей номенклатурой
• Обязательные атрибуты зависят от категории — без них карточка не опубликуется
• Есть лимиты на количество запросов в минуту

Wildberries

Wildberries исторически был менее открытым, но сейчас API развивается. Особенность — модель FBS (продажа со своего склада) и FBW (товар на складе Wildberries) требуют разной логики управления остатками.

Нюансы:

• Карточки создаются через загрузку файлов или API (API предпочтительнее)
• Жёсткие требования к контенту — модерация может отклонить карточку
• Штрафы за отмену заказов — нельзя продавать то, чего нет

Яндекс Маркет

Яндекс активно развивает маркетплейс, API хорошо документирован. Особенность — интеграция с другими сервисами Яндекса (Доставка, Метрика).

Нюансы:

• Можно использовать YML-фиды для загрузки каталога
• Поддержка модели DBS (Delivery by Seller) — доставка своими силами
• Интеграция с Яндекс.Доставкой для логистики

Подробнее про интеграцию с маркетплейсами — в статье CRM и маркетплейсы: как управлять продажами на Ozon, Wildberries, Яндекс Маркет.

Типичные ошибки и как их избежать

За годы работы мы видели одни и те же грабли. Вот топ ошибок, которые дорого обходятся.

Ошибка 1: «У нас всё в Excel»

Выгрузка из 1С в Excel, редактирование, загрузка на маркетплейс. Звучит просто, работает — пока у вас 50 товаров. При 500+ позициях и ежедневных изменениях Excel превращается в ад. Ошибки копирования, забытые обновления, конфликты версий.

Решение: автоматизировать. Даже простая интеграция через API лучше, чем ручные файлы.

Ошибка 2: Редактирование в нескольких местах

Маркетолог поправил описание на сайте. Менеджер по маркетплейсам — в личном кабинете Ozon. Закупщик обновил характеристики в 1С. Через неделю три версии разошлись, и никто не помнит, какая правильная.

Решение: железное правило — редактирование только в мастер-системе. Всё остальное — только чтение.

Ошибка 3: Синхронизация раз в сутки

Для статичных данных (описания, фото) — нормально. Для остатков — катастрофа. Если ваш товар активно продаётся, за сутки ситуация может измениться кардинально.

Решение: остатки обновлять минимум каждые 15-30 минут. Для популярных позиций — чаще.

Ошибка 4: Игнорирование ошибок интеграции

API маркетплейса вернул ошибку. Скрипт записал её в лог и пошёл дальше. Никто лог не смотрит. Товар не обновился, остаток неверный, клиент недоволен.

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

Ошибка 5: Нет маппинга для новых товаров

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

Решение: процесс добавления нового товара должен включать шаг «настроить выгрузку на все каналы». Чек-лист, автоматическая проверка, или хотя бы напоминание в CRM.

Практические рекомендации: с чего начать

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

Шаг 1: Аудит текущего состояния

Нарисуйте схему: какие системы у вас есть, какие данные в каждой хранятся, как они связаны. Честно. Включая «этот Excel на рабочем столе у Марины». Без понимания текущего состояния невозможно планировать изменения.

Шаг 2: Определите мастер-систему для каждого типа данных

Заполните табличку:

Шаг 3: Настройте мониторинг расхождений

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

• Остатки в 1С vs остатки на маркетплейсах
• Цены в прайс-листе vs цены на сайте
• Количество активных SKU в каждой системе

Расхождения — это симптом. Увидели расхождение — разбирайтесь, почему оно возникло.

Шаг 4: Автоматизируйте критичные потоки

Начните с того, что больнее всего. Обычно это остатки. Настройте автоматическую выгрузку остатков из 1С на маркетплейсы. Это можно сделать через готовые модули (для 1С их много), через iPaaS-платформу, или кастомной разработкой.

Шаг 5: Документируйте и обучайте

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

Итог: порядок — это инвестиция, которая окупается

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

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

Начните с малого. Определите мастер-систему для остатков. Настройте автоматическую синхронизацию хотя бы раз в час. Включите мониторинг расхождений. Эти три шага уже снимут 80% боли.

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