Самая частая ошибка в подключении дистрибьютора к аналитике — запрос «давайте выгрузим всё».
Результат предсказуемый: файлы огромные, структура плавает, качество спорное, сроки срываются. А главное — даже после героических усилий вы всё равно не можете ответить на простой вопрос: что делать завтра с отгрузкой, запасом и полкой.
Ниже — минимальный набор данных (MVP), который даёт управляемость. Не «идеальная архитектура», а практичный минимум, с которого стоит начинать.
1) Сначала решения, потом данные: какие 3 решения вы хотите принимать
Решение А. Планировать отгрузку в канал
Чтобы не «заливать» канал и не создавать избыточные запасы.
Решение B. Управлять запасом в канале
Чтобы видеть дефицит и избыточные запасы заранее.
Решение C. Контролировать исполнение в точках (в связке с полем)
Чтобы понимать, где проблема — в поставке, в полке, в дисциплине.
Если вы можете закрыть хотя бы А и B — это уже рычаг управления, даже без кассы (off-take).
2) Минимальный состав данных: 3 блока
Блок 1. Справочники (без них цифры никогда не будут «сходиться»)
1) Справочник торговых точек (ТТ)
Минимум полей: ID ТТ у дистрибьютора, название, адрес (структурированный), город/район, канал (традиция/современная), признак "активная/закрыта".
2) Справочник товаров (SKU)
ID SKU у дистрибьютора, наименование, бренд/категория (если есть), единица измерения, коэффициент пересчёта (штука/короб).
3) Справочник складов/филиалов
ID склада, город/регион, тип (центральный/филиал).
Почему это критично: без справочников продажи и остатки будут "жить" в разных вселенных — один и тот же магазин/товар будет размножаться в отчётах.
Блок 2. Факты (то, что даёт управление)
4) Продажи в торговые точки (sell-out / вторичные продажи)
Минимум: дата, ТТ, SKU, количество, сумма.
Это главный слой, который показывает реальное движение “в рынок”.
5) Остатки на складах дистрибьютора
Минимум: дата (на конец дня/недели), склад, SKU, количество.
Без остатков вы не отличите рост спроса от “переноса запасов”.
6) Возвраты (отдельно от продаж!)
Минимум: дата, ТТ или склад, SKU, количество, причина (если есть).
Если возвраты не отделены — “продажи” будут красивыми, а бизнес-эффект — нет.
Блок 3. Технические поля, без которых интеграция будет вечной
7) Признак закрытия периода
Что считается "закрытой неделей/месяцем", бывают ли корректировки, как они приезжают.
Одна и та же "неделя" у разных сторон не должна считаться по-разному.
8) Тип операции / документ
Чтобы отличать продажу, возврат, перемещение, списание. Даже если документ-детализация не нужна — тип операции нужен обязательно.
3) В каком разрезе и как часто: минимум, который реально работает
Частота
- для управления отгрузкой и запасом достаточно еженедельных данных;
- для оперативных сигналов (дефицит/падение продаж) — лучше ежедневно.
Гранулярность
- продажи: SKU × ТТ × дата (это база);
- остатки: SKU × склад × дата.
4) Что НЕ нужно просить на старте (чтобы не сорвать подключение)
- "все документы по каждой накладной" (оставьте на этап 2–3);
- "все поля из учётной системы" (это мусор без правил);
- "всю историю за 3 года" (начните с 8–12 недель, стабилизируйте поток, потом расширяйтесь).
5) Быстрый тест: если у вас есть только 2 файла — какие?
Если прямо сейчас дистрибьютор готов отдать минимум, просите сначала:
- sell-out (вторичные продажи) в ТТ
- остатки по складам
Эта пара уже позволяет управлять: где спрос, где дефицит, где избыточные запасы, где “влили” канал.
Вопрос вам: что из этого у вас уже есть стабильно — продажи в точки, остатки, возвраты, справочники? И как часто присылают (день/неделя/месяц)?
Если нужна расширенная версия (с примерами полей, типовыми ошибками и “как формулировать запрос дистрибьютору, чтобы он не прислал кашу”) — полная методика будет в лонгриде "Sell-in, Sell-out и Off-take в FMCG: как навести порядок в дистрибуции и научиться управлять каналом по данным".
А базовая страница про контур управления дистрибуцией (куда эти данные “приземляются” в управлении) — здесь.