GrainFlow · сценарій показу · 2026-07-17

Неперервне постачання маслозаводів — демо для клієнта

Покроковий сценарій показу функціоналу, розробленого під задачу клієнта: два маслозаводи без власних елеваторів (Вінниця і Южне), оренда буферної ємності, конкуренція за соняшник і сою, безперебійна робота виробництва.

Тенант GrainFlow (pk 8)

Логіни GrainFlow/GrainFlow або logist/logist

Тривалість ~35–45 хв

Секція меню Калькулятор зернотрейдера (або Логістика)

Підготовка (за 15 хв до дзвінка)

Запустіть стек: у VS Code Ctrl+Shift+D → Launcher: Demo → ▶️ (або node launcher-demo.js). Backend :8000, ERP :5173.
Увійдіть як GrainFlow/GrainFlow, перемкніть мову на UA.
Санітарна перевірка даних — відкрийте дашборд Постачання заводів: мають бути 3 картки у трьох різних станах (У нормі Час замовляти Критично).
Якщо дані «поїхали» після чужих експериментів — пересійте кейс (ідемпотентно, ~1 хв):
```
cd backend && python3 manage.py seed_crush_continuity --tenant 8
```

Контрольні числа сесії (звірте, порядок величин має збігатися):

Де	Число
GrainFlow по траншах двох заводів (соняшник)	економія ~425 тис. ₴ проти послідовного
Сезонний план, соняшник, 180 днів	виграш проти just-in-time ~7,06 млн ₴; форварди 20 000 т узяті повністю; ~40 000 т зі зберіганням
Дашборд: покриття	соя Вінниця 11.8 діб · соняшник Вінниця 11.3 · Южне 6.0

Сюжет — як подати (2 хв на початку)

У вас два заводи і жодного власного елеватора. Судно з зерном — задача разова: зібрав партію, відвантажив, забув. Завод так не працює: він «їсть» соняшник щодня, і день без сировини — це прямі втрати маржі переробки. Ми побудували два контури: щоденний — система сама стежить за запасом кожного заводу і вчасно формує закупівельні транші, і сезонний — рахує, коли купувати вигідніше: форварди на врожай і зберігання проти докупівлі спотом пізніше. Обидва заводи конкурують за одну сировину — тому всі розрахунки йдуть однією оптимізаційною задачею, а не по заводах окремо.

Демо-ланцюг

Довідник «Переробні заводи» — модель споживача

Меню → Логістика → Довідники → Переробні заводи → відкрити МЕЗ Вінниця

Покажіть картку: юрособа-споживач, буферний елеватор (гео + станція — від них рахується кожне транспортне плече), орендована ємність, тариф зберігання (обидва варіанти клієнта: 0 = фіксована оренда, >0 = ₴/т·місяць) і ліміт приймання. Нижче дві таблиці: Профілі культур (соняшник 1200 т/добу + соя 400 — мультикультурність) і Календар зупинок.

Все, що ви називали у вимогах, — налаштування, не код: темпи, запаси, точки замовлення, зупинки на ремонт. Додати третій завод — це створити картку, не проєкт.

Пропозиції закупівлі: спот і форварди

Довідники → Пропозиції закупівлі зерна

Відфільтруйте за видом: спот (ціна діє у вікні дат) проти форварда (укладений контракт, ціна зафіксована, зерно доступне лише у вікні поставки — восени). Покажіть один форвард: 16 100–16 300 ₴ проти спотових 17 000–18 400.

Форвард — це «бери-або-плати»: система знає, що ці тонни зобов'язальні, і сезонний план ніколи їх не «забуде».

Дашборд «Постачання заводів» — серце щоденного контуру

Процеси → Постачання заводів

Три картки завод×культура: соя Вінниця У нормі (11.8 діб), соняшник Вінниця Час замовляти (11.3), соняшник Южне Критично (6.0). На кожній — крива запасу по днях з червоною лінією недоторканного запасу і датою пробою.

Поясніть криву: запас + заплановані прибуття траншів − темп переробки. Дата пробою видна заздалегідь, а не постфактум. Покажіть кнопку Help (⋯ → Довідка) — вбудована інструкція для їхніх людей.

Звіт переробки — факт, що рухає запас

Документи → Звіти переробки → Створити

Створіть звіт: МЕЗ Вінниця, соняшник, сьогодні, 1200 т → Провести. Поверніться на дашборд — запас Вінниці впав на 1200 т, покриття перерахувалось.

Проведення — не «мінус у табличці»: система створює справжні відвантаження зерна з буферних силосів партія за партією, тому склад, партії і власність зерна завжди сходяться копійка-в-копійку. Скасування проведення повертає все точно.

Після показу скасуйте проведення і видаліть чернетку — щоб контрольні числа не з'їхали для наступного показу.

Критична картка → транш одним кліком

На картці «МЕЗ Южне · соняшник» → Сформувати транш

Якщо на Южному вже висить відкритий транш (PP-номер у таблиці картки) — просто покажіть його і поясніть ідемпотентність: система не плодить дублікати. Якщо ні — натисніть кнопку: з'явиться чернетка плану на 15 000 т з вікном збору до дати пробою.

Це ж робить і автоматика: регламентна задача щоранку перевіряє всі заводи, створює транші за потреби і шле push експедитору. Людина лишається в контурі — транш народжується чернеткою, її ще треба оптимізувати і затвердити.

Оптимізація транспортних потоків — конкуренція заводів

Процеси → Оптимізація транспортних потоків

Оберіть обидва соняшникові транші (PP…) → Розрахувати.

Економія проти послідовного розрахунку — сотні тисяч ₴ (~425 тис. на сідових даних): заводи конкурують за центральний пояс (Черкащина–Кіровоградщина), і спільний розрахунок ділить його оптимально. У таблиці «Наповненість джерел» — колонка Резерв (тонни, утримані вже затвердженими планами: подвійний продаж однієї партії неможливий) і бейдж форвард на контрактних джерелах.

Покажіть карту потоків і right-click-редагування, якщо є час — це та сама механіка, що в судновому демо.

Сезонний план закупівель — «коли купувати»

Процеси → Сезонний план закупівель → Соняшник, 180 днів → Розрахувати

Три числа зверху: обсяг ~212 тис. т, вартість, і головне — «Виграш проти just-in-time» ≈ 7,06 млн ₴. У графіку: форвардні рядки з бейджем, колонка «Зберігання» (купили у жнива — тримаємо 1–2 декади), чесні попередження про дефіцитні декади.

Це відповідь на питання, яке не бачить жоден щоденний інструмент: коли купувати. Дешеві жнива плюс право зберігати проти дорожчого спота взимку — різницю система показує одним числом. Сім мільйонів на сезон — це ціна рішення «купувати в останній момент».

Натисніть Створити транші за графіком — по чернетці на пару завод×декада купівлі. Повторне натискання дублікатів не створює.

Замикання кола: виконання

Будь-який транш → кнопки існуючого ланцюга

Коротко покажіть, що транш після оптимізації живе стандартним виконавчим ланцюгом зернотрейдера, який клієнт уже бачив: план розвозу з закріпленням авто/вагонів → ТТН і залізничні накладні → факт приймання на буферний елеватор → запас на дашборді росте → цикл замкнувся.

Ми не будували окремий світ для заводів — це той самий транспортний движок, що збирав судна. Судно і завод тепер просто два типи споживачів однієї системи.

Чистий тенант: які дані заводити і в якому порядку

Якщо показ буде на «голому» тенанті клієнта (не на демо) — порядок заведення даних суворий, бо кожен наступний крок їсть попередній:

#	Що завести	Де	Без чого не працює
1	Ґатунки культур (соняшник, соя)	Модуль зерна → Ґатунки	— (основа всього)
2	Буферний майданчик + силоси	Майданчики / Силоси	гео і станція майданчика = тарифікація плечей
3	Заводи + профілі культур + зупинки	Переробні заводи	юрособа-споживач і буферний майданчик обов'язкові
4	Постачальники + пропозиції (спот і форварди, з координатами і вікнами дат)	Пропозиції закупівлі зерна	без координат — плече не тарифікується порт-aware
5	Початковий сток буфера — прийманнями зерна (не правкою цифр!)	Модуль зерна → Приймання	тільки документи рухають запас
6	Звіти переробки — щоденно	Звіти переробки	без факту споживання проєкція сліпа
7	Транші — кнопкою з дашборда чи сезонного плану	Постачання заводів	потрібні профілі з ґатунком

Питання, які поставить клієнт — і відповіді

«А якщо у нас оренда фіксована, без плати за тонну?»
Ставите тариф зберігання 0 — сезонний план вважає зберігання безкоштовним і природно тяжіє до ранніх закупівель. Обидві моделі оренди підтримані одним полем.

«Що як форвард не влазить у потребу?»
Система все одно спробує його вибрати (умова «бери-або-плати» вшита в розрахунок), а якщо фізично не влазить — покаже чесне попередження «форвард недобраний», а не промовчить.

«Дві людини порахують одночасно — не продадуть одну партію двічі?»
Затверджений план «утримує» свої тонни: інші розрахунки бачать джерело вже зменшеним (колонка «Резерв»). Паралельні чернеткові розрахунки не блокують одна одну свідомо — блокування починається із затвердження.

«Елеватор фізично не прийме стільки за день»
Ліміт приймання — поле картки заводу; сезонний план перевіряє кожну декаду поставки і попереджає про перевищення з порадою розтягнути сусідніми декадами.

«Звідки система знає ціни на місяці вперед?»
Ціна кожної пропозиції діє у своєму вікні дат. Сезонну динаміку ви задаєте кількома пропозиціями з різними вікнами — так, як ринок реально котирує. Форварди — ваші вже зафіксовані ціни.

Межі поточної версії (говорити чесно, якщо запитають)

Ліміт приймання — попередження після розрахунку, не жорстке обмеження всередині оптимізації (заплановано наступним кроком, якщо попередження стануть регулярними на реальних даних).
Автозапуск траншів — готова регламентна команда; розклад запуску налаштовується на сервері при впровадженні.
Звіт переробки працює на рівні культури (буфер — знеособлене зберігання), не окремого ґатунку.
Push-сповіщення приходять експедиторам у мобільний застосунок після реєстрації пристрою.

Технічний слід сесії: план — docs/planning/grainflow-crushing-continuity-2026-07-17.md, специфікація — docs/ai/domains/logistic/crushing-continuity.md, 11 комітів від 53788d23 до 47677686. Вбудовані довідки: ⋯ → Довідка на кожному з нових екранів.