hack-fbc5b7ee-the-click

Hackathon team repository for The Click

Автоматический расчёт заказов поставщикам

Мы разработали сервис для ТОО «Электрокомплект», который помогает автоматически определить, какие товары и в каком количестве нужно заказать у поставщиков для пополнения склада.

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

Поэтому наша задача — сделать расчёт более автоматическим и понятным для менеджера по закупкам.

Как работает решение

Сервис использует несколько источников данных:

• историю продаж за 2024–2026 годы;
• текущие остатки товаров;
• товары, которые уже находятся в пути;
• минимальную партию заказа (MOQ);
• данные об отдельных отгрузках;
• информацию о сезонности и изменении спроса.

Мы протестировали решение на реальных данных по двум поставщикам:

• Systeme Electric — 554 SKU;
• IEK — 2453 SKU.

Всего система формирует рекомендации по тысячам товарных позиций.

1. Убираем разовые крупные заказы

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

Например, обычно за месяц продаётся 10 штук товара, но один раз клиент купил 100 штук. Если просто посчитать среднее, система может решить, что теперь нужно постоянно заказывать намного больше.

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

Заказ считается выбросом, если он одновременно значительно больше обычного объёма, имеет высокий логарифмический z-score и составляет не менее 5 штук.

Такие продажи не удаляются из исходных данных. Они просто не используются при расчёте регулярной потребности.

При этом есть ограничение: данные об отдельных отгрузках доступны только за 2025–2026 годы. Для более раннего периода у нас есть только месячные суммы продаж, поэтому определить конкретный крупный заказ за этот период невозможно.

2. Учитываем периоды, когда товара не было на складе

Есть ещё одна проблема: если товара не было на складе, его низкие продажи не обязательно означают низкий спрос.

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

Поэтому мы определяем месяцы с возможным дефицитом и корректируем продажи за такие периоды.

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

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

3. Учитываем сезонность и изменение спроса

После очистки данных система рассчитывает прогноз на следующий месяц.

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

Также мы смотрим на изменение спроса. Для этого сравниваются последние три месяца с предыдущими тремя месяцами.

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

Итоговый прогноз получается на основе:

обычного спроса + сезонности + текущего тренда.

4. Рассчитываем необходимое количество товара

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

Мы используем следующий принцип:

потребность = прогноз + страховой запас

Затем из этой потребности вычитаются:

• текущий остаток;
• товар, который уже находится в пути.

Если после этого товара всё ещё недостаточно, система формирует рекомендацию на заказ.

Количество округляется с учётом MOQ - минимальной партии или кратности заказа у поставщика.

Например, если системе необходимо заказать 37 штук, а поставщик принимает заказы только кратно 10, рекомендация будет составлять 40 штук.

5. Почему результат удобен менеджеру

Мы не просто выдаём число.

Для каждой рекомендации система показывает:

• артикул;
• поставщика;
• рекомендуемое количество;
• срочность;
• краткое объяснение, почему получилось именно такое количество.

Например, менеджер может увидеть, что рекомендация выросла из-за увеличения спроса, сезонности или того, что на складе был дефицит.

Все рекомендации можно посмотреть в index.html, где их удобно фильтровать и анализировать.

При этом решение не отправляет заказ поставщику автоматически. Последнее решение остаётся за ответственным сотрудником.

Чтобы пересобрать встроенные данные dashboard после обновления recommended_orders.json, запустите из корня репозитория:

python build_dashboard.py

Dashboard публикуется автоматически через GitHub Pages после push в main. После первого запуска workflow включите в настройках репозитория Settings → Pages → Source → GitHub Actions. Страница будет доступна по адресу:

https://baitc-hacks.github.io/hack-fbc5b7ee-the-click/

Полный пересчёт из исходных Excel-файлов выполняется одной командой:

pip install -r requirements.txt
python main.py

Команда загружает данные обоих поставщиков, исключает разовые выбросы, компенсирует stockout, строит прогноз с сезонностью и трендом, учитывает остатки, товары в пути и MOQ, а затем обновляет recommended_orders.csv, recommended_orders.json и index.html.

Результат

В результате мы получили автоматизированный pipeline, который проходит весь путь от исходных Excel-файлов до готового списка заказов.

Структура проекта разделена на несколько частей:

загрузка и подготовка данных; поиск крупных разовых заказов; обработка периодов дефицита; прогнозирование спроса; расчёт необходимого количества; формирование итоговых рекомендаций.

На выходе создаются:

recommended_orders.csv recommended_orders.json

а также интерактивный index.html.

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

Что можно улучшить дальше

В текущей версии мы специально оставили несколько возможностей для дальнейшего развития.

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

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

Также в будущем можно протестировать более сложные модели прогнозирования временных рядов, если будет достаточно истории по каждому SKU.

Ещё один возможный этап- интеграция с 1С. Однако автоматическая отправка заказа без подтверждения сотрудника в текущей версии не используется.