Фаза 4 з 9
Customization — українська локалізація і кастомні модулі
Прив'язати Odoo до українських реалій: ПН/РК у ЄРПН, СЕА ПДВ, друковані форми, виробничі акти, defense-розширення.
Передумови
- Підписана design specification (фаза 2)
- Налаштоване середовище розробки з git і CI
- Доступ до тестового API М.Е.Doc / FREDO або власного бриджа до ДПС
Покрокові завдання 22
- Інсталяція l10n_ua з OCA, перевірка налаштувань
- Створення кастомного модуля l10n_ua_pn для ПН/РК
Генерація XML за форматом ДПС, валідація, відстеження статусу реєстрації.
- Інтеграція з М.Е.Doc API для надсилання ПН в ЄРПН
- Альтернатива: інтеграція з FREDO або власний бридж до ДПС
Вибрати один шлях. М.Е.Doc — найпопулярніший, але платний. FREDO — альтернатива.
- Модуль l10n_ua_sea — моніторинг ліміту СЕА ПДВ
Розрахунок поточного ∑Накл і прогноз нестачі. Алерт при <10% ліміту.
- QWeb-шаблон прибуткової М-4 з усіма реквізитами
- QWeb-шаблон лімітно-забірної М-11
- QWeb-шаблон видаткової накладної
- QWeb-шаблон акта виробництва з калькуляцією собівартості
- QWeb-шаблон акта браку з причиною і відповідальним
- QWeb-шаблон інвентаризаційного опису інв-3
- Кастомні поля на mrp.bom: x_scrap_normative_rate, x_quality_control_required
- Кастомні поля на sale.order: x_prozorro_id, x_defense_contract, x_dseku_permit_no
- Кастомне поле на product.template: x_uktzed_code (для експорту і деяких ПН)
- Wizard для розподілу ЗВВ за обраною базою (зарплата, машинний час, обсяг)
- Wizard для нарахування компенсуючих ПЗ за ст. 198.5 ПКУ
Автоматичне виявлення випадків (списання, негосп., звільнене) і пропозиція ПН.
- Friendly defense fiscal position з автоматичним позначенням 'ПН-09'
- Defense: модуль доступу з грифом 'ДСК' (обмеження видимості замовлень)
Тільки користувачі з допуском бачать ID контракту і реквізити ВЧ.
- Unit-тести на кожен кастомний модуль (мінімум 80% coverage)
- Linting (flake8, pylint-odoo) і code review
- Документація API кастомних модулів (Sphinx або markdown)
- Демо кастомізацій бухгалтеру і керівнику, signoff
Контекст: чому ця фаза критична
Odoo «з коробки» не вміє України. Без локалізації ваша система не може законно генерувати ПН, відстежувати ліміт СЕА, друкувати М-4, рахувати компенсуючі ПЗ. Тоді бухгалтер однаково веде паралельну реальність у 1С чи Excel — і сенс впровадження зникає.
Тижні 1-2: ядро локалізації
ПН/РК — основа основ. Доки немає модуля, який генерує XML за форматом ДПС, надсилає його в ЄРПН і відстежує статус реєстрації, рухатися далі немає сенсу. Це найбільший модуль у вашому стеку.
Тижні 3-4: друковані форми і виробничі акти
Українська первинка — це окремий світ. М-4, М-11, видаткова, акт виробництва, акт браку, інв-3. Кожен документ — окремий QWeb-шаблон з усіма реквізитами (підписи, печатки, посади). Бухгалтер має побачити кожен і сказати «це проходить через перевірку».
Тижні 5-6: wizards і defense
Розподіл ЗВВ, компенсуючі ПЗ — це wizards, бо процес багатоступеневий. Defense-модуль — окрема історія: гриф «ДСК», обмеження видимості, інтеграція з Прозоро.МО.
Пастка: не пишіть власний інтеграційний шар до ЄРПН з нуля, якщо клієнт уже платить за М.Е.Doc. М.Е.Doc стабільний, документований, з підтримкою. Власний бридж — це проєкт на півроку.
Пастка: unit-тести на кожен кастомний модуль — не «коли буде час», а обов’язково. Регресія на ПН-генерацію через місяць після Go-live — це не баг, це штраф ДПС.
Пастка для defense: гриф «ДСК» — не декорація. Це означає, що навіть розробник, який не має допуску, не має бачити дані оборонних контрактів у dev-середовищі. Маскуйте.
Результати фази (deliverables)
- Кастомні модулі: l10n_ua_pn, l10n_ua_sea, l10n_ua_prozorro (мінімум 3-5)
- QWeb-шаблони: М-4, М-11, видаткова, акт виробництва, акт браку, інвентаризаційний опис
- Wizards: розподіл ЗВВ, компенсуючі ПЗ, перерахунок собівартості
- Code review report з результатами linting і unit-тестів
- Документація API кастомних модулів