Умный Закуп

🎯 Проблема

Компания продаёт тысячи разных товаров. Чтобы понять, что пора заказать, менеджер вручную собирает несколько Excel-файлов: продажи, остатки, товар в пути, сезонность, категории и минимальные партии поставщика.

Такой расчёт занимает много времени. Поэтому его сложно делать часто и одинаково внимательно по каждому товару.

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

Менеджеру приходится принимать решение сразу между двумя рисками:

Почему обычного среднего недостаточно

• В одном месяце мог пройти единичный крупный заказ. Если считать его регулярным спросом, компания закупит лишнее.
• Когда товара не было на складе, продажи равны нулю. Но это не означает, что спроса не было.
• Зимой и летом один товар может продаваться по-разному.
• Часть товара уже едет от поставщика и должна уменьшать новый заказ.
• Поставщик отгружает товар только определёнными партиями.
• Пока новый заказ едет 45 дней, спрос продолжает меняться.

Главная проблема не в Excel как таковом. Проблема в том, что бизнес слишком поздно узнаёт о будущем дефиците и слишком поздно замечает деньги, замороженные в лишнем запасе.

💸 Сколько денег можно потерять

Мы проверили сервис на реальных файлах заказчика. В актуальном расчёте (базовый сценарий, данные на 22.09.2026) система нашла:

[!IMPORTANT] Цена заполнена только примерно у 14,6% позиций к заказу. Поэтому 14,9 млн ₸ — не полная возможная потеря и не прогноз упущенной прибыли, а минимальная видимая сумма критической потребности. Полный денежный риск выше. Для точного расчёта потерянной прибыли нужны цены по всем товарам и их маржинальность.

Компания теряет деньги сразу в двух местах:

Нет товара → нет продажи → нет выручки и прибыли

Слишком много товара → деньги заморожены → их нельзя вложить в нужные позиции

💡 Что мы создали

«Умный Закуп» собирает разрозненные данные в одно решение и заранее предупреждает менеджера о рисках.

Вместо вопроса:

«Что у нас закончилось?»

сервис помогает ответить:

«Что закончится через несколько недель и что нужно заказать уже сегодня?»

Первый экран отвечает на один вопрос: что менеджеру нужно сделать сегодня:

• 4 показателя, которые не пересекаются: нет на складе · срок заказа наступил · заказать на этой неделе · стоимость заказа (с долей позиций, у которых известна цена);
• карточка каждого поставщика — сколько позиций заказать сегодня и кнопки «Выбрать товары», WhatsApp, Telegram;
• графики: статусы позиций, заказы по неделям, поставщики, группы товаров;
• 10 главных действий: просроченные и «дефицит сейчас» → ранняя дата окончания запаса → категория A → больший дефицит до прихода поставки. Отсутствие цены приоритет не снижает.

Сверху выбираются поставщик, склад и категория (группа товаров) — весь дашборд пересчитывается.

Как проходит работа

flowchart LR
    A[Продажи, остатки и товар в пути] --> B[Прогноз будущего спроса]
    B --> C[Дата возможного дефицита]
    C --> D[Последний безопасный день заказа]
    D --> E[Готовый заказ с объяснением]

    style A fill:#eff6ff,stroke:#2563eb
    style B fill:#eff6ff,stroke:#2563eb
    style C fill:#fff7ed,stroke:#f97316
    style D fill:#fef2f2,stroke:#dc2626
    style E fill:#f0fdf4,stroke:#16a34a

Система:

1. загружает историю продаж и остатки;
2. убирает влияние единичных крупных заказов;
3. восстанавливает спрос за периоды, когда товара не было;
4. учитывает сезонность и устойчивое изменение спроса;
5. проверяет товар, который уже находится в пути;
6. прогнозирует, когда закончится текущий запас;
7. рассчитывает последний безопасный день заказа;
8. предлагает количество с учётом страхового запаса и минимальной партии;
9. объясняет рекомендацию обычными словами;
10. формирует заказ поставщику: менеджер выбирает товары и отправляет заказ в WhatsApp, Telegram, на почту, в Excel или CSV для 1С.

🚀 Как запустить

Вариант 1 — онлайн, без установки (рекомендуем для проверки): откройте https://umny-zakup.vercel.app. Работает круглосуточно на компьютере и телефоне; после первого открытия — и без интернета.

Вариант 2 — локально, без установки: скачайте репозиторий и откройте файл web/index.html в браузере. Данные уже рассчитаны, сервер не нужен.

Вариант 3 — пересчитать на выгрузках 1С и запустить тесты (нужны Python 3.10+ и, для сверки с браузером, Node.js 18+):

git clone https://github.com/BAITC-Hacks/hack-bd80e77f-light.git
cd hack-bd80e77f-light

python3 -m venv .venv
source .venv/bin/activate          # Windows: .venv\Scripts\activate
pip install -r requirements.txt

python -m engine.build             # чтение Excel → расчёт → web/data.js и output/*.xlsx (~30 сек)
PYTHONPATH=. pytest -q             # автотесты требований ТЗ → 32 passed
python3 -m http.server 8000 --directory web   # открыть http://localhost:8000

Новые выгрузки 1С кладутся в папки IEK/ и Systeme electric/ с теми же именами файлов; после python -m engine.build сервис показывает свежие данные. Онлайн-версия обновляется командой bash scripts/deploy.sh.

🛠 Технологии и архитектура

flowchart LR
    A["Выгрузки 1С"] --> B["Расчёт<br/>Python"] --> C["Сайт"] --> D["Заказ: Excel · 1С · WhatsApp"]

✅ Как проверить решение

За 2 минуты в браузере — откройте https://umny-zakup.vercel.app:

Автоматически (вариант 3 из «Как запустить»):

PYTHONPATH=. pytest -q      # ожидается: 32 passed
node scripts/check_site.js  # проверка онлайн-версии: ✅ Сайт работает

Тесты по требованиям ТЗ: tests/test_requirements.py (пять требований Must have), tests/test_calendar.py (безопасный день, stockout, товар в пути, сценарии, граница месяца), tests/test_parity.py (Python и браузер считают одинаково, цены, бюджет, экспорт), tests/test_coverage.py (охват данных).

⏰ Главное отличие: сервис говорит не только «сколько», но и «когда»

Количество само по себе не спасает от дефицита. Если заказать на неделю позже, товар всё равно придёт с опозданием.

Поэтому для каждой позиции сервис строит календарь будущего остатка:

Сегодня
   ↓
товар ежедневно продаётся
   ↓
учитываются запланированные приходы
   ↓
определяется возможная дата окончания запаса
   ↓
из этой даты вычитается срок поставки и дни на согласование
   ↓
получается последний безопасный день заказа

Последний безопасный день = дата окончания запаса − срок поставки (45 дн) − согласование (3 дн)

Пример из данных — автомат ВА47-29 10А IEK: запаса хватит до 19 октября, а заказ, размещённый сегодня, придёт только 9 ноября.

gantt
    title Календарь остатка: автомат ВА47-29 10А IEK
    dateFormat YYYY-MM-DD
    axisFormat %d.%m
    section Склад
    Запас на складе              :done, s1, 2026-09-22, 2026-10-19
    Дефицит — товара нет         :crit, s2, 2026-10-19, 2026-11-09
    section Заказ сегодня
    Согласование 3 дн            :a1, 2026-09-22, 3d
    Поставка 45 дн               :a2, after a1, 45d

Последний безопасный день для этого товара был 1 сентября — сервис показывает статус «Просрочено» и дефицит ≈ 2 225 шт до прихода заказа.

Товар в пути учитывается только с датой прихода и только начиная с этой даты. Товар без даты (в файле Systeme Electric) не считается прибывшим вовремя: сервис показывает его отдельно и просит уточнить дату. Спрос месяца распределяется по дням, поэтому месячный сезонный объём сохраняется и на границах месяцев.

Менеджер видит понятный статус:

Статус действий отдельный от срочности и ABC-категории: он отвечает на вопрос «когда действовать», а срочность — «насколько велик риск».

🔎 Почему менеджер может доверять рекомендации

Сервис не показывает необъяснимое число. Для каждой позиции он раскрывает расчёт.

Например:

При спросе 3 185 шт./мес. и остатке 1 406 шт. (+1 800 в пути) товар закончится примерно 19 октября. Поставка 45 дн. + 3 дн. на согласование: последний безопасный день был 1 сентября (21 дн. назад) — заказывать нужно немедленно. Рекомендуется 6 072 шт.: прогноз 7 962 + страховой 1 315 − остаток 1 406 − в пути 1 800 = 6 072, округлено до кратности 12.

— реальное объяснение сервиса для автомата ВА47-29 (1ф) 10А IEK

В карточке товара можно увидеть:

• реальные продажи по месяцам;
• очищенный спрос без случайных всплесков;
• периоды, когда товара не было;
• сезонное изменение спроса;
• текущий остаток;
• товар в пути и ожидаемую дату прихода;
• страховой запас;
• минимальную партию поставщика;
• прогноз остатка с новым заказом и без него;
• вклад каждого фактора в штуках: сезонность, тренд, восстановленный спрос, исключённые разовые продажи, остаток, товар в пути, страховой запас, округление до MOQ;
• качество данных по позиции: есть ли цена, кратность, достаточно ли истории.

📨 Отправка заказа в WhatsApp и Telegram

Сервис умеет отправлять заказ поставщику в WhatsApp, Telegram и на почту, а также выгружать его в Excel. Какие товары покупать, менеджер выбирает сам — отправка идёт в два понятных шага.

sequenceDiagram
    actor M as Менеджер
    participant S as Умный Закуп
    participant W as WhatsApp / Telegram
    M->>S: «Выбрать товары» у поставщика
    S-->>M: Шаг 1 — рекомендованные товары отмечены
    M->>S: снимает лишнее, добавляет через поиск, правит количество
    M->>S: «Далее: проверить и отправить»
    S-->>M: Шаг 2 — список выбранного и текст сообщения
    M->>S: нажимает «WhatsApp» (это согласование)
    S->>W: открывает чат с готовым текстом заказа
    M->>W: выбирает поставщика и отправляет
    Note over S,W: Сервис ничего не отправляет сам

Где начать: кнопка «Отправить заказ» в шапке сайта или кнопки «☑ Выбрать товары», WhatsApp, Telegram на карточке поставщика — все ведут в шаг 1.

Шаг 1 из 2 — выбрать товары

• Сервис заранее отмечает товары, которые нужно заказать сегодня (можно переключить на «+ эта неделя» или «Весь заказ»).
• Галочки у каждой позиции, кнопки «Отметить все» и «Снять все» — чтобы выбрать с нуля.
• Поиск по названию, коду 1С или артикулу; любой товар поставщика можно добавить кнопкой «+ Добавить», даже если сервис его не рекомендовал.
• Количество правится прямо в списке. Внизу всегда видно: «Выбрано: N позиций · штук · сумма» и кнопка «Далее: проверить и отправить».

Шаг 2 из 2 — проверить и отправить

• Список только выбранных товаров и предпросмотр сообщения — ровно тот текст, который уйдёт: поставщик, позиции и штуки, сумма и список «код — товар — количество» (до 50 позиций целиком, иначе первые 30 и ссылка на Excel).
• Кнопки WhatsApp, Telegram, Почта открывают мессенджер или почту с этим текстом; получателя выбирает менеджер. Excel скачивается только отдельной кнопкой, на телефоне «Поделиться файлом» отправляет его сразу.
• «← Изменить выбор» возвращает к шагу 1.

Сервис ничего не отправляет сам — как требует ТЗ: нажатие кнопки отправки и есть подтверждение ответственного сотрудника (заказ отмечается согласованным на этом устройстве). Коммерческие данные лучше отправлять с рабочего номера.

🧪 Проверить расчёт на своих числах

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

• Взять реальный товар по коду 1С — результат совпадает с основным расчётом (сервис это показывает: «✓ Совпадает»), дальше можно менять цифры.

• Проверить требования ТЗ одной кнопкой: «+ разовый заказ ×30» (заказ не меняется), «3 месяца без товара» (спрос восстанавливается), «сделать сезонным», «товар в пути с датой / без даты» — с показом «было → стало».

• Все параметры (срок поставки, согласование, пересмотр, прирост) можно задать точным числом, а не только ползунком.

• Добавить новый товар в заказ. Введите название, код и поставщика — кнопка «+ Добавить в заказ поставщику» добавит товар в дашборд, таблицу заказа и отправку в WhatsApp / Telegram с пометкой «добавлен вручную». Удаляется одной кнопкой.

Данные ручной проверки и добавленные товары хранятся только в браузере пользователя.

🎚 Три сценария и бюджет

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

Это демонстрационные допущения, а не вероятности; они лежат в одном месте (engine/forecast.py → SCENARIOS). Разница между сценариями — не «экономия»: для этого нужны проверенные маржа и стоимость хранения.

Приоритизация заказа при ограниченном бюджете. Если задать доступный бюджет, сервис включает позиции по приоритету: «Дефицит сейчас» и «Просрочено» → ранняя дата окончания → категория A → больший дефицит. В бюджет попадают только позиции с известной ценой. Позиции без цены не считаются бесплатными: они показаны отдельно, а критичные из них остаются в предупреждениях. В таблице видны метки «в бюджете», «не поместилось», «нет цены».

🔬 Проверка прогноза на прошлом

Мы «вернулись» в 1 марта 2026 года: алгоритм видел только данные до этой даты (продажи, остатки, накладные, сезонность по полным годам) и спрогнозировал спрос на март–май. Затем прогноз сравнили с фактическими продажами.

Простое среднее завышает спрос на 16% — это прямой путь к замороженным деньгам. Для редких товаров (категория C) ошибка выше: при штучных продажах это ожидаемо. Проверка измеряет точность прогноза спроса и не доказывает предотвращённые дефициты — для этого нужна точная история ежедневных остатков и поступлений.

🧹 Как система защищает деньги от лишней закупки

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

Мы сравнили два расчёта:

• обычный расчёт, который принимает все продажи за регулярный спрос;
• расчёт «Умного Закупа», который отделяет единичные крупные продажи от постоянного спроса.

Результат моделирования на предоставленных данных:

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

📊 Что получает менеджер

Менеджер может изменить предложенное количество перед выгрузкой. Система помогает принять решение, но не принимает его вместо человека.

💰 Какой экономический результат мы нашли

На предоставленных данных система уже выявила два отдельных финансовых резерва:

1. Защита от лишней закупки

Фильтрация единичных крупных продаж уменьшила модельную закупку на 49 497 единиц. По товарам, где цена известна, это примерно 8,35 млн ₸ модельно меньшей закупки (по себестоимости, без учёта маржи).

2. Деньги в избыточном запасе

Сервис нашёл около 28,9 млн ₸, находящихся в запасах сверх расчётной потребности на шесть месяцев — и это только по позициям с известной ценой.

Эти две суммы нельзя автоматически складывать: они отражают разные виды риска и могут частично пересекаться.

Честный вывод: система уже нашла, где компания может не потратить лишние 8,35 млн ₸ и где около 28,9 млн ₸ капитала требует проверки и возможного высвобождения. Но это пока найденный финансовый резерв, а не деньги на банковском счёте.

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

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

После пилота экономический эффект считается просто:

Реально сохранённые деньги =
предотвращённые лишние закупки
+ высвобождённый запас
+ сохранённая маржа от предотвращённого дефицита
− стоимость внедрения и хранения

Так мы сможем честно сказать не только «система рассчитала заказ», а:

«Компания сохранила X тенге и получила Y тенге дополнительной маржи благодаря тому, что нужный товар был в наличии вовремя».

🧾 Какие данные используются

Товары связываются между файлами по коду 1С. Персональные данные клиентов не используются.

✅ Что выполнено по заданию

Сверка с каждым пунктом технического задания ТОО «Электрокомплект».

Всё это проверяют 32 автоматических теста (PYTHONPATH=. pytest -q): пять требований ТЗ, календарь остатка (безопасный день, дефицит сейчас, нулевой спрос, приход до и после дефицита, товар без даты, MOQ, граница месяца), порядок сценариев, отсутствие утечки будущего в проверке прогноза, а также сверка: расчёт в браузере совпадает с эталоном на Python на 54 комбинациях. Отдельно проверяется, что отсутствующая цена не превращается в ноль, покрытие ценами считается верно, бюджетный режим не теряет критичные позиции без цены, а в Excel коды 1С сохраняются как текст и нет NaN/undefined.

🧭 Охват данных и допущения

На вкладке «Методика и данные» видно, какая часть каталога дошла до расчёта и что взято из файлов заказчика, а что задано командой:

Исключено 617: у 28 нет ни продаж, ни остатков, ни товара в пути; 589 не продавались последние 6 месяцев и не лежат на складе — заказывать нечего.

Реестр допущений перечисляет 21 параметр с источником: «файл заказчика», «вычислено из истории» или «допущение команды Light». Например, срок поставки 45 дней — допущение команды (оценено по датам в файле «Путь ИЭК»), сезонность — файл заказчика плюс профиль товара.

В Excel-выгрузке есть лист «Параметры»: дата данных, сценарий, сроки поставки, факторы расчёта, покрытие ценами и отметка «поставщику ничего не отправлено».

Как перейти от демо к пилоту (вход по ролям, данные через API, журнал согласований, интеграция с 1С) — в docs/PILOT_ARCHITECTURE.md.

🔐 Безопасность

• Система ничего не отправляет поставщику автоматически.
• Менеджер проверяет и может изменить количество.
• «Отметить согласованным» сохраняет отметку только на этом устройстве — это не журнал согласований; Excel подготовлен для проверки и последующего импорта в учётную систему.
• Номера накладных в опубликованных данных не хранятся. В выгрузке партнёра нет поля клиента, поэтому проверка «крупные продажи одному клиенту» невозможна — разовые заказы ищутся по накладной.
• Финальный заказ появляется только после решения человека.
• Персональные данные клиентов не используются.
• Если данных недостаточно, сервис сообщает об этом, а не придумывает результат.
• Отсутствующая цена показывается как «Нет данных», а не 0 ₸; стоимость заказа всегда подписана как неполная, если цены известны не везде.
• В выгрузке каждая строка помечена «Черновик, не отправлен» или «Утверждён, не отправлен поставщику».

🚀 Как развивать решение дальше

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

1. цены и маржинальность по всему ассортименту;
2. клиентские резервы и подтверждённые заказы;
3. плановые и фактические даты поставок;
4. стоимость хранения;
5. история ручных решений менеджера;
6. товары-заменители;
7. планы отдела продаж по крупным проектам.

После этого сервис сможет показывать:

• точную потерянную прибыль из-за дефицита;
• надёжность каждого поставщика (интерфейс уже готов и ждёт плановые и фактические даты приходов);
• бюджетный режим по всему ассортименту, а не только по позициям с ценой;
• варианты замены отсутствующего товара;
• фактическую экономию после внедрения;
• уведомления в Telegram о наступлении безопасной даты заказа.

🧮 Методология расчёта

flowchart LR
    A["Очистка<br/>выбросов"] --> B["Спрос без<br/>дефицита"] --> C["Сезон<br/>и тренд"] --> D["Заказ<br/>+ страх. запас"] --> E["Дата<br/>заказа"]
    style D fill:#f0fdf4,stroke:#16a34a
    style E fill:#fef2f2,stroke:#dc2626

Расчёт идёт по каждому артикулу. Все параметры собраны в начале engine/forecast.py.

1. Очистка от разовых заказов и всплесков — см. алгоритм ниже.
2. Восстановление упущенного спроса (stockout). Остаток известен на начало каждого месяца, конец месяца = начало следующего. Доля месяца в наличии: оба нуля → ≈ 10 % (или 40 %, если продажи всё же были), один ноль → 60 %, иначе 100 %. Спрос в таком месяце = max(факт, min(ожидаемый, факт + (1 − доля) × ожидаемый)), где ожидаемый считается только по месяцам с товаром.
3. Сезонность. Коэффициенты поставщика из файла «Сезонность» + собственный профиль товара по полным годам (вес до 60 %).
4. Уровень и тренд. Уровень — средний спрос за 6 последних месяцев без сезонности. Тренд — последние 6 месяцев к тем же месяцам год назад, ограничен −30…+50 %. Прогноз прироста рынка — ручная поправка менеджера.
5. Страховой запас = z × σ × √(срок поставки + период пересмотра); z по категории ABC (частота заказов за 12 мес.): A — 95 %, B — 90 %, C — 80 % уровня сервиса.
6. Заказ = прогноз на (срок поставки + пересмотр) + страховой запас − остаток − товар в пути с датой прихода, округление вверх до кратности (MOQ).
7. Календарь остатка и срочность. Остаток по дням на 180 дней (месячный прогноз распределён по дням, приходы товара в пути — по датам). Последний безопасный день = дата окончания запаса − срок поставки − согласование. Статусы: Дефицит сейчас · Просрочено · Сегодня · На этой неделе · Позже · Недостаточно данных (меньше 3 мес. истории).

🧹 Алгоритм исключения выбросов

Цель — чтобы разовая крупная продажа не превратилась в регулярную закупку. Два слоя:

flowchart LR
    N["Крупная накладная"] --> Q{"Повтор 4+ мес.?"} -- да --> K["Оставить"]
    Q -- нет --> X["Исключить"]

1. Разовые заказы по накладным. Для каждого артикула по всем расходным накладным считаются устойчивые к выбросам статистики — медиана и MAD (медианное абсолютное отклонение) размера отгрузки. Накладная признаётся разовым крупным заказом, если одновременно:

• объём > медиана + 6 × MAD и > Q3 + 3 × IQR;
• объём ≥ 5 медиан;
• накладная даёт ≥ 25 % продаж артикула за месяц;
• по артикулу не меньше 8 накладных (иначе «обычный» заказ не определить).

Такие накладные вычитаются из регулярного спроса и показываются в карточке товара. Защита от ложных срабатываний: если крупные заказы повторяются (в 4+ месяцах или в > 20 % месяцев продаж), это постоянный оптовый покупатель — такой спрос регулярный и не исключается.

2. Фильтр Хампеля по месячному ряду (для периода без накладных и всплесков без документа). Окно ±3 месяца; значение выше медиана + 3 × 1,4826 × MAD и выше 2 медиан срезается до границы, а не удаляется. Месяцы без товара в «норму» окна не входят — иначе обычные продажи после дефицита ошибочно считались бы всплеском.

Клиент. В ТЗ — «включая крупные продажи одному клиенту». В выгрузке партнёра поля клиента нет (дата, документ, товар, склад, количество), поэтому разовый заказ определяется по накладной. При появлении обезличенного ID клиента правило расширяется на серию накладных одного клиента.

Проверка: тест добавляет заказ в 30 раз больше месячного спроса — рекомендация меняется меньше чем на 10 %, а без фильтра выросла бы более чем в 2 раза. Тест на постоянного оптовика подтверждает, что регулярные крупные покупки не удаляются.

Рекомендуемый заказ = прогноз спроса на (срок поставки + период пересмотра)
                    + страховой запас (z по ABC и сценарию × σ × √горизонт)
                    − текущий остаток
                    − подтверждённый товар в пути (с датой прихода)
                    → округление вверх до кратности поставщика

Последний безопасный день = дата окончания запаса − срок поставки − согласование

hack-bd80e77f-light/
├── engine/
│   ├── loaders.py          # чтение и нормализация выгрузок 1С
│   ├── forecast.py         # алгоритм: выбросы, stockout, сезонность, тренд, заказ, календарь
│   ├── backtest.py         # проверка прогноза на прошлом
│   ├── coverage.py         # охват каталога и причины исключения
│   └── build.py            # сборка web/data.js и Excel
├── web/                    # сайт: index.html, app.js, engine.js, styles.css, data.js, sw.js
├── tests/                  # 32 автотеста (pytest + сверка с браузером через Node.js)
├── scripts/                # deploy.sh — публикация, check_site.js — проверка сайта
├── docs/                   # скриншоты, PILOT_ARCHITECTURE.md — план пилота
├── IEK/, Systeme electric/ # данные партнёра
├── output/                 # Excel с рекомендациями
├── assets/readme/          # оформление README
├── requirements.txt, vercel.json
└── README.md