Проектний документ: як працюватиме система

ТОВ «Акфорт» · Впровадження BAS Комплексне управління підприємством · доповнення до дашборда проекту

версія 0.1 · 12.06.2026 чернетка — до Фази 2 «Моделювання»

Один документ — два рівні деталізації. Замовнику достатньо режиму «Замовник»; технічні розділи для розробників позначені фіолетовим.

§0 · Що це за документ

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

Він складається з: §1 — як виглядатиме робочий день вашої команди після впровадження (людською мовою); §2 — реєстр вимог: повний перелік того, що система має робити, і чесна позначка по кожному пункту — штатно / налаштування / доробка / інтеграція; §3 — приклади-перевірки, за якими приймаємо результат; §4 — словник термінів; §5 — журнал версій і погодження.

Документ живий: після Фази 2 «Моделювання» (07.07–20.07) реєстр вимог поповниться знайденими розбіжностями, і версія 1.0 піде на офіційне погодження. Зауваження можна лишати прямо тут — кнопка «Коментар до розділу» під кожним блоком, потім «Експортувати коментарі» праворуч унизу.

§1 · Як працюватиме система: чотири робочі дні

Цільовий стан (TO-BE) очима чотирьох ролей. Червоні блоки — як це відбувається сьогодні

Менеджер продажів · Західна Україна

польова робота, тонкий клієнт BAS через інтернет

9:00

Відкриває BAS з планшета. Бачить реальні залишки київського складу і свіжість кожної партії — знає, що можна впевнено обіцяти клієнту.

9:15

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

9:16

Склад у Києві одразу бачить замовлення у своїй черзі на відбір. Жодних Excel-файлів і пересилань поштою.

17:00

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

Як сьогодні: замовлення набирається в Excel і їде на склад поштою; ціна кожної позиції перераховується вручну для контролю маржі та узгоджується; реальних залишків менеджер не бачить ніколи.

Розробник Об'єкти: «Замовлення клієнта», обмеження доступу на рівні записів (RLS) по менеджеру; види цін «Маржа N%» (формула від «Собівартість з дод. витратами», кратність 0.6); регламентне завдання перерахунку цін о 06:00; звіт «Валовий прибуток» з відбором по менеджеру.

Комірник · склад Київ

термінал збору даних (ТЗД) замість паперу

8:00

Приймання: сканує товар, що приїхав з Польщі, вносить дату виготовлення партії — з цього моменту система сама рахує свіжість.

11:00

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

11:30

Відвантаження підтверджено сканером — залишки оновилися миттєво, менеджери по всій країні бачать актуальну картину.

Як сьогодні: склад збирає по роздрукованому Excel, заносить в облік постфактум; ТЗД фізично є, але стоять без діла; яку партію брати — на пам'ять.

Розробник Мобільне робоче місце комірника на ТЗД (перевірка сумісності — Фаза 4); серії з датою виготовлення/терміном; стратегія відбору FIFO по даті виготовлення; операції: приймання, відбір, переміщення. Адресне зберігання НЕ активуємо (рішення зафіксовано).

Бухгалтер · офіс Дніпро

окрема база BAS Бухгалтерія, обмін з КУП

10:00

Банківська виписка імпортована автоматично, платежі рознесені по контрагентах.

16:00

Одним документом пакетно формує податкові накладні за всі реалізації дня → передає у M.E.Doc → статуси реєстрації у ЄРПН підтягуються назад у систему.

16:30

Імпортне надходження: ГТД, мито, логістика з ЄС, страхування — все лягає у собівартість партії автоматично. Саме від неї рахується ціна «Маржа N%».

Як сьогодні: кожна податкова накладна реєструється окремо вручну; виписки розносяться руками; собівартість з імпортними витратами рахується поза системою.

Розробник Пакетне формування ПН/РК + регламентне завдання перевірки статусів; обробка завантаження виписок (формати — за переліком банків Замовника); «Надходження дод. витрат» з розподілом на партії; вид ціни «Собівартість з дод. витратами» як база ціноутворення. Обмін КУП↔Бух типовими правилами — Фаза 4.

Власник / керівник · Дніпро

управлінська картина бізнесу

9:30

Відкриває P&L, баланс, рух грошей, валовий прибуток — по компанії, по мережах (Партнерах), по групах товару. Дані актуальні, бо операції заносяться в момент здійснення.

9:40

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

Як сьогодні: управлінська звітність в обмеженому вигляді; про партії, що добігають терміну, дізнаються запізно.

Розробник Типові управлінські звіти КУП (склад уточнюється на Моделюванні — клієнт надає скріни своєї робочої моделі); FRESH-індикація: пороги по виду номенклатури + кольорове оформлення поверх штатного звіту «Залишки товарів за строками придатності».

§2 · Реєстр вимог: що штатно, що налаштовуємо, що доробляємо

Головна таблиця проекту. Тут узгоджуємо обсяг робіт — кожен рядок має чесну позначку

Штатно — типова BAS це вже вміє Налаштування — штатний механізм, потрібно налаштувати Інтеграція — підключення зовнішнього сервісу Доробка — пишемо код Умовно — залежить від рішення Фази 0

№	Вимога (людською мовою)	Як закриваємо	Блок
В-01	Реальні залишки видно всім у момент операції детальніше Замовлення, відбір і відвантаження реєструються онлайн — залишок змінюється миттєво, а не постфактум. Dev: штатний контур «Замовлення клієнта → Реалізація», без доробок.	Штатно	Облік
В-02	Кожна партія знає свою дату виготовлення і термін придатності детальніше При прийманні вноситься дата виготовлення — далі система веде партію до відвантаження. Dev: серії номенклатури з датами; політика обліку серій по видах номенклатури.	Налаштування	FRESH
В-03	Свіжість у відсотках по кожній партії + кольорова підсвітка детальніше Зелений = можна у мережі, жовтий = на межі, червоний = терміновий розпродаж. Поріг — свій для кожної групи товару (типово 67%, з договорів з мережами). Dev: відсоток рахує штатний звіт «Залишки товарів за строками придатності» (підтверджено скріном робочої моделі). Дороблюємо: параметр порогу на виді номенклатури + умовне оформлення. Мінімальна доробка.	Доробка	FRESH
В-04	Ціна рахується від потрібної маржі, а не націнки детальніше Комерційний відділ задає цільову маржу по групі — система сама рахує ціну. Округлення кратністю 0.6, щоб ПДВ без копійчаних хвостів. Dev: штатна формула виду ціни: [Собівартість з дод. витратами] / (1 − N/100), кратність 0.6 (підтверджено скріном робочої моделі).	Налаштування	Ціни
В-05	Собівартість враховує імпортні витрати: мито, логістику з ЄС, страхування детальніше База для маржі — не закупівельна ціна, а повна собівартість партії. Dev: штатно: «Надходження дод. витрат» з розподілом по партіях; вид ціни «Собівартість з дод. витратами». Перелік складників — чекаємо від Замовника.	Налаштування	Ціни
В-06	Прайс стабільний протягом дня — перерахунок щоранку детальніше Щоб дві накладні на той самий сир в один день не мали різних цін через рух собівартості. Dev: регламентне завдання перерахунку цін о 06:00.	Налаштування	Ціни
В-07	Ваговий і штучний товар — коректний облік обох (53 шт / 46 кг) детальніше Палет → коробка → штука/кг з коефіцієнтами перерахунку. Dev: штатні «Упаковки одиниці» + види номенклатури за ваговим/штучним характером.	Штатно	Довідники
В-08	Замовлення з мереж приходять у систему самі (EDIN) детальніше Мережа шле замовлення → у BAS воно з'являється автоматично; назад їдуть накладні й повідомлення про відвантаження. Dev: модуль EDIN для BAS: ORDERS, DESADV, RECADV, COMDOC_006, е-ТТН; довідник GLN; мапінг штрих-кодів. Перша мережа — тестовий цикл, далі тиражування.	Інтеграція	EDIN
В-09	Податкові накладні — пакетно, не по одній детальніше Всі ПН за день формуються одним документом і їдуть у M.E.Doc; статуси реєстрації повертаються у систему. Dev: штатне пакетне формування ПН/РК + інтеграція з M.E.Doc + регламентна перевірка статусів. Правила ЄРПН (вікно 08:00–20:00, ліміти) лишаються чинними.	Інтеграція	M.E.Doc
В-10	Банк: виписки заходять самі, платіжки виходять із системи детальніше Dev: обмін з банк-клієнтами (формати — за переліком банків Замовника, чекаємо список).	Інтеграція	Банки
В-11	Комірник працює з ТЗД, а не з папером детальніше Приймання, відбір, переміщення — сканером. Наявний парк ТЗД Замовника. Dev: мобільне РМ комірника; перевірка сумісності наявних ТЗД з BAS-клієнтом — на старті Фази 4; тестування на 1–2 пристроях.	Умовно	ТЗД
В-12	Друковані форми такі, як вимагають мережі детальніше Видаткові, ТТН та специфічні форми окремих мереж. Dev: доробка макетів друкованих форм; шаблони — чекаємо від Замовника.	Доробка	Форми
В-13	Управлінські звіти: P&L, баланс, рух грошей, валовий прибуток детальніше Звіти у BAS гнучкі — кожен користувач налаштовує розрізи під себе; на Моделюванні показуємо типові можливості. Dev: типовий склад звітів КУП; точкові СКД-доналаштування — лише якщо Моделювання покаже розриви.	Штатно	Звіти
В-14	Мережа = одна картинка, навіть якщо юросіб декілька детальніше Звіт можна згорнути до мережі (Партнер) або розгорнути до юрособи (Контрагент). Питання Фази 0: чи є такі мережі у Замовника — якщо ні, працюємо простіше, лише з Контрагентами. Dev: штатний дворівневий механізм Партнер/Контрагент КУП.	Умовно	Довідники
В-15	Бухгалтерія — окрема база BAS Бухгалтерія з обміном детальніше Рішення Замовника (КУП має власну бухгалтерію, але бухгалтер працює у звичній окремій базі). Обмін односторонній КУП → Бухгалтерія: реалізації, надходження, повернення, замовлення (як рахунки на оплату), взаєморозрахунки. Налаштування і тестування — у Фазі 4. Dev: готового плану обміну КУП↔Бух у BAS НЕМАЄ (штатні — лише Бух↔УТ/ЗУП/Малий бізнес). Будуємо через універсальний формат EnterpriseData + правила конвертації (КД), односторонньо; замовлення→рахунки — доробка. Обсяг підтвердити на Фазі 0.	Доробка	Архітектура
В-16	Перехідний період: тимчасовий імпорт замовлень з Excel детальніше На 1–2 місяці переходу, щоб не зупиняти продажі. Після — вимикається. Dev: обробка завантаження замовлень з Excel-шаблону. Тимчасова, з датою «поховання».	Доробка	Перехід

⚠ Реєстр відкритий: за результатами Фази 2 «Моделювання» (07.07–20.07) сюди додаються знайдені розбіжності — кожна з оцінкою і способом закриття. Після цього документ іде на погодження як версія 1.0. Нових «сюрпризних» доробок поза цим реєстром не буває.

§3 · Як перевіримо, що готово: приклади-еталони

Конкретні приклади з вашими цифрами. Система вважається прийнятою, коли поводиться саме так

FRESH-контроль (В-02, В-03)

Дано	Система показує
Гауда 12 кг, виготовлена 100 днів тому, термін 365 днів	73% свіжості · зелений — можна відвантажувати у мережі
Та сама Гауда, лишилось 33 дні до кінця терміну	9% свіжості · червоний — мережа не прийме (поріг 67%), пріоритетний розпродаж
Партія рівно на порозі групи (наприклад 67.0%)	ще проходить — межа включно, правило зафіксоване однаково для всіх груп

Ціноутворення від маржі (В-04, В-05, В-06)

Дано	Система показує
Собівартість з дод. витратами 300.00 грн/кг, цільова маржа 10%	ціна 333.60 грн/кг (формула + кратність 0.6 — звірено з робочою моделлю)
Два замовлення на той самий SKU об 11:00 і о 16:00 одного дня	однакова ціна — прайс зафіксовано вранішнім перерахунком

EDIN та податкові (В-08, В-09)

Дано	Система показує
Мережа надіслала замовлення через EDIN о 9:05	о 9:06 замовлення вже у BAS — без ручного набору позицій
За день проведено 45 реалізацій	одна пакетна операція → 45 ПН сформовані та передані у M.E.Doc

Повний перелік приймальних сценаріїв по кожному блоку формується разом з версією 1.0 (після Моделювання) — і стає чек-листом дослідної експлуатації.

§4 · Словник

Терміни, які зустрічаються у проекті — простими словами

BAS КУП — «Комплексне управління підприємством»: система, де житиме оперативний та управлінський облік.

FRESH / MLOR — практика мереж приймати товар лише зі свіжістю не нижче порогу (зазвичай 67% терміну). MLOR = Minimum Life On Receipt, «мінімальний залишок терміну при прийманні».

EDIN — сервіс електронного обміну документами з мережами (замовлення, накладні, е-ТТН).

GLN — глобальний номер локації: «адреса» магазину/складу мережі в EDIN-обміні.

ПН / РК — податкова накладна / розрахунок коригування (реєструються у ДПС через M.E.Doc).

ГТД — митна декларація; джерело мита й витрат для собівартості імпорту.

ТЗД — термінал збору даних: сканер, з яким працює комірник.

FIFO — «першим прийшов — першим пішов»: старіші партії відвантажуються першими.

Партнер / Контрагент — мережа як ціле / конкретна юрособа мережі з реквізитами.

Обмін КУП → Бухгалтерія — одностороння автоматична передача документів (реалізації, надходження, замовлення як рахунки на оплату) з оперативної бази у бухгалтерську.

СКД — система компонування даних: механізм гнучких звітів BAS.

RLS — обмеження доступу на рівні записів (менеджер бачить лише своїх клієнтів).

§5 · Версії та погодження

Кожна версія документа — зафіксований стан домовленостей

Версія	Дата	Зміст	Статус
0.1	12.06.2026	Початкова чернетка: 4 сценарії TO-BE, реєстр 16 вимог з оцінкою (3 доробки, 4 умовні), приймальні приклади з реальними цифрами робочої моделі	робоча чернетка
1.0	після 20.07	+ розбіжності з Фази 2 «Моделювання», + рішення Партнер/Контрагент, + повні приймальні сценарії	→ на погодження

Як відбувається погодження: Замовник переглядає документ → лишає коментарі (кнопки у кожному розділі) → експортує файл коментарів → Виконавець вносить правки → нова версія → коли зауважень немає, версія фіксується у протоколі зустрічі як погоджена. Погоджена версія = межі робіт; все нове після неї — через журнал рішень у дашборді.