Фаза 2 з 9
Design — архітектура й конфігурація
Перетворити BRD на конкретну конфігурацію Odoo: рахунки, податки, аналітика, склади, права, виробничі лінії.
Передумови
- Підписаний BRD і scope statement з фази Discovery
- Доступ до тестового сервера Odoo (community або enterprise)
- Облікова політика підприємства (наказ керівника)
Покрокові завдання 22
- Проектування chart of accounts на основі НПСБО
Спочатку повний перелік П(С)БО, потім додати кастомні субрахунки під аналітику.
- Деталізація рахунків 201, 22, 23, 26 під виробничий цикл
- Налаштування рахунку 641 — субрахунки 641/2, 641/К, 641-СЕА
СЕА-ПДВ субрахунок — окремий і недоторканний для бухгалтерських коригувань.
- Налаштування податків: 20%, 7%, 0%, звільнено, без ПДВ
- Налаштування fiscal positions: внутрішні, експорт, звільнення, оборонні
- Аналітичні рахунки: підрозділ / продукт / проєкт
Три виміри — мінімум. Підрозділ обов'язково для розподілу ЗВВ.
- Налаштування складів: сировина, НЗВ, готова продукція, експорт, defense
- Маршрути (routes): закупівля → склад, склад → виробництво → готова, реалізація
- Виробничі лінії (work centers), календарі змін
Якщо є нічна зміна — окремий календар з коефіцієнтом.
- BoMs draft на топ-20 SKU (з фактичними нормами і коефіцієнтами браку)
- Налаштування прав доступу (groups) за ролями
Принцип мінімальних привілеїв. Бухгалтер не має бачити собівартість, продавець — закупівельні ціни.
- Sequence/numbering policy для документів (М-4, М-11, видаткових, ПН)
- Approval workflow: закупівля >50k грн → керівник, >500k → директор
- Approval workflow: списання ТМЦ, акт браку, ручні коригування 641
- Friendly templates для друку (QWeb): М-4, М-11, видаткова, акт виробництва
- Налаштування fiscal year, періоди, дата закриття
- Multi-currency якщо є експорт (USD, EUR, валютний журнал)
- Defense: окрема fiscal position для контрактів з МО
- Defense: аналітика для оборонних замовлень (контракт-номер, ЦО, А-номер ВЧ)
- Налаштування звітних шаблонів: trial balance, P&L, balance sheet за П(С)БО
- Драфт design specification з усім вище
- Walkthrough design specification з бухгалтером і керівником, signoff
Без підпису — не починаємо міграцію. Зміни після signoff = change request.
Контекст: чому ця фаза критична
Design — це фаза, де ви перекладаєте бізнес-вимоги на мову системи. Помилка в chart of accounts на цьому етапі коштує в 100 разів дорожче, ніж та сама помилка через місяць після Go-live. Бо після Go-live будь-яка зміна структури рахунків означає перепроведення сотень тисяч транзакцій.
Тиждень 1: рахунки і податки
Бухгалтер веде. Консультант пише. Без живого головного бухгалтера на цій фазі — не починайте. Він має знати свою облікову політику напам’ять, інакше отримаєте загальну конфігурацію, що проходить повз вашу специфіку.
Тиждень 2: процеси і потоки
Склади, маршрути, виробничі лінії. Тут консультант моделює, а виробничник перевіряє. Особлива увага BoMs — нормативи мають бути реальні, з документів, а не «приблизно».
Тиждень 3: безпека, друк, інтеграційні точки
Права, шаблони, sequences, approval. Кожну друковану форму має перевірити бухгалтер: чи відповідає вона нормативним вимогам Мінфіну.
Тиждень 4: документ і узгодження
Design specification на 80-120 сторінок. Walkthrough з бізнесом. Signoff.
Пастка: не копіюйте chart of accounts з 1С один-в-один. У 1С часто є «спадщина» — субрахунки, які давно не використовуються, але ніхто не наважується видалити. Це шанс почистити.
Пастка: approval workflow треба проектувати за реальною ієрархією, а не за бажаною. Якщо директор фактично затверджує все — не намагайтеся силою децентралізувати.
Результати фази (deliverables)
- Design specification (~80-120 сторінок)
- Chart of Accounts mapped на П(С)БО з аналітикою
- Tax configuration map (20%, 7%, 0%, звільнено)
- RBAC matrix — права за ролями
- Approval workflow design (закупівля, оплата, відвантаження)
- Warehouse і виробничі лінії — схема