
ZakUp: прототип системы, которая отвечает закупщику на три вопроса: что заказать, сколько и когда. Ответ собирается из продаж, остатков на складах и условий поставщиков, а не из памяти человека, который «и так всё знает».
Сразу честно: это прототип, а не готовая промышленная система. Экраны открываются, таблицы и графики работают, но данные в них демонстрационные. Самая проработанная часть здесь модель данных: товары, склады, поставщики, балансы, транзакции, планы и сегменты описаны подробно, и на этом фундаменте можно строить рабочую систему без переделки основы.
Задача
Закупки обычно живут в Excel и в голове опытного сотрудника. Пока ассортимент небольшой, это работает. Когда SKU сотни, а складов несколько, ошибка в одну сторону замораживает деньги в излишках, в другую оставляет полки пустыми. Техническое задание ZakUp описывает систему, которая считает это сама: сегментирует ассортимент, строит прогноз спроса, оценивает его точность и превращает план в заказ поставщику.
Что внутри
- модуль данных и настроек: товары, категории, бренды, склады, поставщики и условия поставки;
- импорт из Excel и CSV с построчной проверкой: каждая строка файла получает статус, ошибки видны до того, как попадут в базу;
- ABC/XYZ-сегментация по выручке или по штукам с рекомендациями для каждой группы;
- прогноз спроса тремя моделями: скользящее среднее, сезонная модель при истории от 12 месяцев и top-down от заданной цели продаж;
- точность прогноза: accuracy, WAPE и BIAS, чтобы видеть не только промах, но и систематическое завышение или занижение;
- страница планирования на 12 месяцев с ручными правками, новинками и перепланированием;
- заказы на закупку: строки по SKU и складам, ожидаемая дата поступления, статус заказа;
- в ТЗ также спроектирована интеграция с Хорошоп: маппинг полей и алгоритмы синхронизации заказов и остатков.
Экраны системы
Главный рабочий экран, страница планирования. На одном экране три блока: прогноз спроса по трём моделям, мини-дашборд плана за 12 месяцев и точность прогноза. Ниже таблица плана по SKU и складам.

Сегментация раскладывает ассортимент по матрице ABC/XYZ. ABC отвечает за значимость: группа A даёт первые 80% выручки, B следующие 15%, C оставшиеся 5%. XYZ отвечает за стабильность: коэффициент вариации до 10% означает X, от 10 до 25% Y, выше 25% Z. Дальше работают правила: AX и BX идут на автозаказ со страховым запасом, AZ и BZ под заказ с жёстким контролем остатков, а CY и CZ стоит проверить на право остаться в ассортименте.

Данные заходят через импорт. Файл не льётся в базу вслепую: строки сначала попадают в кэш импорта, получают статус и тип записи (товар, баланс, поставщик), и только проверенные идут дальше.

Условия поставки хранятся для связки «товар и поставщик»: цена, срок производства, срок доставки, частота заказов, минимальная и максимальная партия. Именно из них потом считается lead time и момент, когда пора заказывать.

Итог цепочки, заказ на закупку. Строки собираются по SKU и складам, рядом стоят факт продаж и прогноз за операционный период.

Справочники вынесены в отдельное меню: продукты, поставщики, склады, остатки, сегменты, бренды и остальные таблицы модели.

Схема данных
Это сильная сторона прототипа. В SFL-схеме 38 таблиц: от товаров и складов до дневных балансов, план-запусков, метрик прогноза и кэшей импорта. Все расчётные сущности ссылаются на товар и склад, а каждая запись привязана к организации, поэтому данные разных компаний не смешиваются.
Контур системы
Как данные проходят путь от файла до заказа поставщику.
Схема интерфейса
Как устроен рабочий экран планирования.
Чем прототип полезен заказчику
Он переводит разговор о закупках из абстракций в конкретику. Вместо «нам нужна умная система» на столе лежат экраны, таблицы и схема данных, по которым видно, какие поля нужны, откуда они берутся и что из них считается. Спорить о формуле страхового запаса гораздо проще, когда перед глазами колонка, в которой он лежит.
И ещё раз для ясности: это прототип. Модель данных продумана подробно, экраны показывают логику работы, но расчёты на реальных продажах, интеграции и права доступа относятся к следующему этапу.
Следующий шаг
Подключить реальные данные заказчика, выгрузку из учётной системы или интернет-магазина, и проверить прогноз на его истории продаж. Дальше рекомендации «что заказать сейчас», риск дефицита и излишки, а затем отправка заказов поставщикам прямо из системы.
Где посмотреть
Похожее решение: Автобусный букинг: система для перевозчика от сайта до панели собственника.