Metz · ВЭД и закупки · Архитектура v1 · 27.04.2026

Систематизация закупок Metz

Переопределение единицы учёта и сборка реляционной структуры вокруг неё. Документ для Кристины, Сержа, Маши.

Содержание

Главный тезис

Текущая система — это набор листов, в которых единица учёта плавает. «Заказ N 4 белая» существует в трёх экземплярах с одинаковой датой и тремя разными статусами. Нумерация рассыпается, как только заказ дробится между белым и серым контуром, между ИП Лактионов и ИП Ившина, между Metz/Unlim/Бишкек.

Мы не «улучшаем таблицу заказов». Мы переопределяем единицу учёта и собираем вокруг неё нормальную реляционную структуру. Дальше любой отчёт, дашборд, decision rule или контроль платежей становится производным от этого ядра.

Цена бездействия растёт линейно: каждая новая фабрика, каждое новое юрлицо, каждый новый канал кладутся на текущую структуру с трением выше, чем предыдущий слой. Точка разрыва — найм нового ВЭД-менеджера: при текущей системе он не сможет принять процесс, потому что процесса нет, есть устная традиция Антона и Кристины.

1. Диагноз

1.1 Что говорит ваш аудит

Проблематика — 8 пунктов

  1. Нет единой архитектуры процесса
  2. Единица управления заказом не стандартизирована
  3. Процесс изначально заточен под серую схему, а компания растёт в белую
  4. Правила игры меняются по ходу исполнения
  5. Сильная ручная зависимость от людей и таблиц
  6. Белый ввоз усложняется не документами, а самой бизнес-моделью
  7. Нет одного источника правды по decision rules
  8. Кассовый/платёжный контур ломает закупку и логистику
есть
  • Декомпозиции по категориям
  • Шаблон заказов для байеров
  • Информация по сертам
  • Статусы по заказам и поставщикам
сломано
  • Master-файл слабый как система управления
  • Белый контур формально есть, фактически не ведётся как контур
  • Нет единого правила выбора логистики
  • Платежи живут отдельно от заказов
строить
  • Order line / invoice line / партия на корыто
  • Реестр документов по белому ввозу
  • Реестр маршрутизации белая/серая
  • Реестр фабрик и условий
  • Единый dashboard руководителя
  • Бюджет оплат Китай / Бишкек

1.2 Что подтверждается данными

НаходкаЧто вижу в данныхСледствие
Единица учёта плавает В «сроках» N 4 фигурирует трижды с одной датой и тремя разными статусами. «N 1 белая», «N 6 белая», «N 7 белая» — decision rule в названии записи. Невозможно ответить «где сейчас N 4». Подтверждает п. 2 проблематики.
Декомпозиция в wide-формате «Сводный общий» = 4 юрлица × 14 категорий × 3 месяца блоками вправо. Внутри: Потреб шт / Факт / Разница / Потреб ₽ / Факт ₽. Из этой структуры формулой нельзя получить ничего. Любой агрегат — копипастой. Подтверждает п. 7.
Контур зашит в название Вместо колонки route — суффикс «белая» в номере. В платёжной таблице платежи мешаются вне зависимости от контура. Decision rules маршрутизации негде хранить, кроме как в голове Кристины и Антона.
Платежи вшиты в строку заказа В «Заказ Настя» — Оплата 1/2/3/Остаток в столбцах. Бюджет оплат — отдельный xlsx без связи с заказами. Один заказ может иметь 5+ платежей. Структура ломается. Кэш и заказы — два разных мира.
Много валют, нет курса Инвойс ¥, фрахт $, ВТП €, итоги ₽. Колонки курсов есть, но заполнены не везде. NSM (себестоимость единицы до WB) посчитать нельзя. Ретроспективы расходятся в разные дни.

1.3 Структурный корень

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

2. Целевая архитектура

2.1 Принцип

Order line = одна позиция заказа = (артикул × количество × фабрика × дата × контур × юрлицо × партия). Каждый order line — одна строка в master-таблице orders. Все остальные таблицы ссылаются через order_id. Текущие листы байеров становятся взглядами на master через фильтр.

ORDER LINE (артикул × кол-во × фабрика) — основная единица
    ↓ группируется в
PARTY (партия = одно «корыто» = контейнер/тираж)
    ↓ финансируется через
PAYMENT (один или много платежей: аванс, остаток, по готовности)
    ↓ соотносится с
DECOMPOSITION (план потребности на месяц по категории и юрлицу)

Плюс справочники: factories, articles. Плюс правила: routing_rules.

2.2 Master-таблицы

Таблица 1 · orders — Order Lines

КолонкаПримерНазначение
order_id2026-04-NSTY-001уникальный ID
order_groupN 4человекочитаемый № (как сейчас в «сроках»)
order_date04.03.2026дата размещения
factory_id / buyer / purchaserNSTY / Настя / Антонцепочка фабрика → байер → закупщик
article_id / categoryдж-дракончик-голуб / Джинсычто заказано
qty / size_split200 / S 50/M 80/L 70количество и раскладка
price_yuan / total_yuan52 / =qty*priceцена и сумма
routeбелый / серыйконтур ввоза — ключ
legal_entityMetz / Unlim / Бишкекпод какое юрлицо/канал
recipient_ipИП Ившина / ИП Лактионовконкретный получатель
party_idFK на partiesпартия
statusотшивается / готов / в пути / приехалостатус заказа
4× даты + deltaпланы и факты по готовности и приходуконтроль сроков

Таблица 2 · parties — Партии

Одна строка = одно физическое перемещение через границу. Заменяет «Таблицу платежей». Считает cost_per_unit_rub формулой = NSM блока.

Группа колонокЧто внутри
Идентификацияparty_id, sender, recipient_ip, route
Логистикаtransport_type, weight_kg, qty_total
Деньги (валютный пул)invoice ¥/₽, freight $/₽, vtp €/₽, nds ₽, dt ₽, total ₽
NSM-метрикаcost_per_unit_rub = total_rub / qty_total
Сроки и курсыдаты отправления/прихода, transit_days, курсы ¥/$/€ на дату

Таблица 3 · payments — Платежи

Заменяет «Бюджет план Закупки.xlsx». Каждый платёж привязан к order_id или party_id. Бюджет на неделю/месяц = pivot этой таблицы.

КолонкаПример
payment_id / payment_date2026-04-PAY-021 / 15.04.2026
payment_typeаванс / по готовности / остаток / белая оплата / карго
link_to + link_idorder_id 2026-04-NSTY-001 или party_id 2026-04-PARTY-007
amount / currency / amount_rub10000 ¥ → формулой ₽
from_account → to_accountИП Лактионов р/с → Юра карго
legal_entity / route / statusMetz / белый / план|оплачено|просрочено

Таблица 4 · decomposition — План в long-format

Один лист на ~670 строк в год (4 юрлица × 14 категорий × 12 месяцев). Текущий wide становится pivot.

year · month · legal_entity · category · need_qty · need_rub · fact_qty · fact_rub · diff_qty · diff_rub · coverage_pct · comments

Таблица 5 · routing_rules — Decision Rules

~20-40 строк правил маршрутизации. Decision rules выходят из головы Кристины в таблицу.

Справочники

factories — фабрики, байеры, карго-агенты с условиями (lead time, payment terms, надёжность).
articles — твой существующий «впр», доведённый: артикул, категория, состав, цена ¥, WB SKU.

3. Decision Rules — драфты

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

3.1 Маршрутизация контура (белый / серый)

#УсловиеКонтурПолучательТранспорт
R-001Платья, Блузки + qty ≥ 200белыйИП Ившинаавто ТИР
R-002Купальники, Топы + qty ≥ 500белыйИП Лактионовавто ТИР
R-003Шлёпки, Аксессуарысерый—карго (Юра/Саша)
R-004Срочный (lead time < 14 дней)серый—авиа
R-005Юрлицо Metz + qty ≥ 1000белыйИП Метцавто ТИР
R-006Юрлицо БишкекKGS-режимсклад Бишкекчерез КР

3.2 Маршрутизация платежа

#УсловиеПлатёж
P-001Аванс по серомучерез карго-агента в ¥
P-002Остаток по серомучерез карго после готовности
P-003Белый аванспрямой банковский в ¥ от ИП
P-004ВТП + НДС + ДТот ИП-получателя в ₽ при таможне
P-005Карго по беломуот ИП-получателя в ₽

4. Дашборд руководителя — три экрана

Цель: Кристина за 5 минут понимает, где компания.

Экран 1

Деньги

  • План vs факт по месяцам / юрлицам
  • Кэш-out на закупку (из payments)
  • Остаток обязательств
  • Себес единицы до склада WB (NSM)
  • Курсовая разница vs прошлый месяц
Экран 2

Поток

  • Воронка статусов (5 стадий)
  • Просрочки по готовности
  • Старение (> 60 дней без движения)
  • Партии в пути
Экран 3

Артикулы

  • Топ дефицитов (план не покрыт)
  • Топ переборов (купили лишнее)
  • Сток на пути по категориям
  • Скорость закрытия плана

5. Теория игр — кто проиграет от наведения порядка

Любая система управления — это перераспределение информации и власти. Если не понять кто проиграет, систему похоронят саботажем за 2-4 недели.

5.1 Стейкхолдеры и стимулы

СтейкхолдерТекущий стимулЧто выиграетЧто потеряет
Кристина (собственник блока)Хаос = её незаменимостьВидит компанию, может масштабироватьТеоретически — эксклюзивность экспертизы
Антон (закупщик)Носитель «как это работает»Снимет рутину, поднимет статус методологаУязвимость к замене новым ВЭД
Байеры в КитаеСерая прибавка/откаты, размытый контроль маржиПрозрачные условия, можно растиСерая подушка между себестоимостью и ценой Metz
Карго-агенты (Юра/Саша/Адим)Серый поток = доходСтабильный потокКомиссия за непрозрачность
БухгалтерияЛовит ошибки рукамиМеньше работы, фокус на отчётность—

5.2 Где саботаж наиболее вероятен

  1. Антон — если почувствует, что система делает его заменимым, начнёт «забывать» вносить данные. Митигация: сделать его методологом системы — он не пропадает, он растёт.
  2. Карго-агенты — будут продавливать «серое быстрее». Митигация: считать TCO белый vs серый по топ-20 артикулам с учётом штрафов и блокировок WB.
  3. Байеры — могут «забыть» прислать инвойс. Митигация: заказ не считается размещённым, пока не заполнены price_yuan и factory.

5.3 Принципы устойчивости системы

  1. Награждать за заполнение, не наказывать за дыры (первый месяц)
  2. Антон становится владельцем methodology, а не «оператором ввода»
  3. Decision rules — open book для Кристины и Сержа, не для байеров
  4. Серый контур не убираем — делаем учитываемым (route='серый' колонка)
  5. Бюджет утверждается по payments, не по «договорённостям»

6. План миграции

ПериодЧто делаемЧек-точка
Неделя 1
28.04–04.05		Каркас: пустые master-таблицы по схемам, заполнить справочники factories и articles из «впр» и шапок заказов. Согласовать decision rules с Кристиной (~30-40 правил).Все справочники заполнены. Кристина и Антон видят систему.
Неделя 2
05.05–11.05		Миграция только активных заказов (отшивается / готов / в пути / на таможне). Закрытые — в архиве. План оплат на 4 недели в payments.Любой активный заказ находится за минуту. Антон работает в новой системе.
Неделя 3
12.05–18.05		Дашборд из трёх экранов. Ретроспективное сравнение план/факт за апрель.Еженедельный обзор Кристины с Сержем — 30 минут вместо 2 часов.
Недели 4-6Все новые заказы — только в новую систему. Каждую пятницу — корректировка decision rules.Полный переход. Старая структура заморожена.
Месяц 2-3 (опционально)Переход в Airtable / Notion если Sheets начнёт тормозить или потребуется role-based доступ.Тот же набор сущностей, другой движок.

7. Открытые вопросы — нужны решения

Кристине

  1. Validate decision rules (раздел 3.1) — переписать своими формулировками. Блокер старта.
  2. Подтвердить роль Антона как «методолога системы» с KPI на качество ведения
  3. Кто делает первичную миграцию — Антон, Кристина+Антон, или Маша?
  4. Топ-20 артикулов / категорий для пилота белый vs серый TCO

Сержу

  1. Дедлайн — стратсессия с Кристиной или фоновая работа?
  2. Объём пилота — все 4 юрлица сразу, или начать с Metz?
  3. Сразу делать рабочий шаблон Sheets с примерами на 30-50 строках?
  4. Кто финальный владелец системы после миграции?

Что в папке architecture-v1/

До старта: 4 решения от Кристины + 4 от Сержа (раздел 7). После — 5 рабочих дней до MVP.