Module: Accounting & Tax (Compliance)¶
Статус: ⚠️ Частково реалізовано (прогрес 2026-04-22)
- ✅ Ядро бухгалтерії реалізовано в
essentials/:- План рахунків —
ChartOfAccounts(master-data)- Проводки —
PostingGroup+PostingEntry(автоматичні від документів)- Бізнес-операції (шаблон проведень) —
BusinessOperation+DocumentOperation- Журнали —
CashJournal,InventoryJournal,IncomeExpenseJournal,PlannedPaymentJournal- Леджери —
CashLedger,InventoryLedger, ✅PartyLedger(уніфікований дебіторка/кредиторка — party-ledger.md)- Фінансові звіти — P&L, Balance Sheet, Cash Flow, Payment Calendar (
essentials/views/reports.py)- ✅ Trial Balance (ОСВ) —
GET /reports/trial-balance/(2026-04-22)- ✅ P&L Drill-Down —
GET /reports/profit-loss/drill-down/з вимірами account / expense_item / business_direction / department (2026-04-22)- ✅ ПСБО Форма 1 (management layout) —
GET /reports/psbo-form1/(2026-04-22). ⚠️ Візуальний layout ПСБО над даними європейського PCG — для внутрішнього управлінського читання. НЕ офіційний документ для ДПС. Офіційне подання → потребує майбутньої UA-локалізації (детальніше).- ✅ M.E.Doc — експорт видаткових накладних (J1203001/F1203001) — production flow (MVP)
- 🧪 M.E.Doc — experimental tax invoice lifecycle (
TaxInvoice+ J1201006 + імпорт + ЄРПН reconciliation, 2026-04-22) — див. medoc integration. ⚠️ Окрема майбутня ініціатива, не для production. Рекомендовано: видаткові з DOP, податкові — у M.E.Doc.- UI регістрів —
RegisterRecordsPage(3 режими: document / list / all)- ✅ Manual
JournalEntry+JournalEntryLine(Phase E, 2026-04-22) — вільні бух. довідки з валідацією Σ Дт = Σ Кт + idempotent post/unpost. Документація: journal-entry.md.- ✅
FixedAsset+DepreciationEntry+ monthly amortization (Phase E, 2026-04-22) — облік основних засобів з 3 методами амортизації (linear / accelerated / none). Документація: fixed-assets.md.- 📋 Розширення (planned), описані нижче:
- Податкові декларації (ПДВ декларація, Прибуток) — автоматичний експорт
- ПСБО Форма 2 (Звіт про фінансові результати — офіційна форма)
- 🔮 Deferred — окремі майбутні ініціативи:
- Розділення аддону бухгалтерії на два плани рахунків (
accounting-eu+accounting-ua) з одночасним використанням — див. розділ «Dual chart of accounts» нижче. Покриває також доведення ПСБО Форма 1 до офіційної форми (коректний mapping на UA CoA, повні рядки активів/пасивів, підпис, експорт у M.E.Doc).- Tax accounting у DOP — повний lifecycle податкових накладних (J1201006 + ЄРПН reconciliation). Частково реалізовано як experimental (2026-04-22), але офіційний scope MVP — тільки експорт видаткових, ПН створюються у M.E.Doc. Повернення до теми — за запитом клієнта + виділена команда податкового супроводу. Див. medoc integration — experimental.
Цей модуль забезпечує відповідність діяльності підприємства державним стандартам обліку та податковому законодавству (UA Compliance).
1. Master Data (Мастер-дані)¶
| Сутність | Опис | Ключові поля |
|---|---|---|
| Chart of Accounts | План рахунків (бухгалтерський) | Account_Code, Name, Type (Asset/Liability), Parent_ID |
| Tax Rates | Довідник ставок податків (ПДВ, ЄСВ тощо) | Name, Percentage, Effective_From, Tax_Type |
| Legal Entities | Власні юридичні особи та ФОП | Name, EDRPOU, Tax_System, Legal_Address, Bank_Accounts |
| Accounting Policies | Налаштування методів обліку | Entity_ID, Valuation_Method (FIFO/Average), Depreciation_Method |
| Fixed Assets (FA) | Основні засоби | ID, Name, Purchase_Value, Residual_Value, Lifetime_Months |
2. Transaction Data (Транзакційні дані)¶
- Journal Entry (Бухгалтерська довідка / Проводка):
- Універсальний документ для ручних коригувань або відображення операцій, що не мають стандартних форм.
- Tax Invoice (Податкова накладна / РК):
- Документи для реєстрації ПДВ-зобов'язань та кредиту.
- Depreciation Charge (Нарахування амортизації):
- Регламентний документ, що розраховує знос основних засобів за період.
- Tax Return (Податкова декларація):
- Згенерований звіт для подачі у контролюючі органи.
3. Journals & Ledgers (Журнали та реєстри)¶
A. General Ledger (Головна книга)¶
Центральний реєстр усіх проводок за методом подвійного запису. * Dimensions: Account_Debit, Account_Credit, Entity_ID, Project_ID. * Resources: Amount_LC (місцева валюта), Amount_RC (валюта звітності).
B. Tax Sub-Ledger (Реєстр податкових накладних)¶
Спеціалізований журнал для обліку вхідного та вихідного ПДВ. * Dimensions: Entity_ID, Counterparty, Tax_Date, Status (Registered/Pending). * Resources: Base_Amount, Tax_Amount.
C. Fixed Assets Register (Інвентарна книга)¶
Облік вартості та зносу кожного об'єкта ОЗ. * Dimensions: Asset_ID, Department, Responsible_Person. * Resources: Initial_Cost, Accumulated_Depreciation.
4. Business Processes (Бізнес-процеси)¶
- Mapping Rules: Налаштування автоматичного формування проводок на базі операційних документів (наприклад: Sales Invoice -> Дт 361 Кт 702).
- VAT Reconciliation: Співставлення даних системи з даними ЄРПН (через інтеграцію з M.E.Doc/Vchasno).
- Year-end / Quarter-end Closing: Регламентна процедура закриття фінансового результату та формування сальдо на новий період.
- Audit Logging: Фіксація будь-яких змін у проведених бухгалтерських документах.
5. Analytics & BI (Звітність та комплаєнс)¶
- Trial Balance (ОСВ): Оборотно-сальдова відомість у будь-якому розрізі (рахунок, контрагент, аналітика).
- Balance Sheet (Форма №1): Офіційний фінансовий звіт про стан активів та пасивів.
- Income Statement (P&L Statutory): Звіт про фінансові результати згідно з ПСБО.
- Tax Calendar: План подачі звітів та сплати податків з нагадуваннями.
Multi-CoA / Parallel Ledgers — ✅ implemented (foundation, 2026-04-25)¶
Статус: фундамент реалізовано як Parallel Ledgers (SAP-style). Деталі рішень — docs/planning/multi-coa-implementation.md. Активні стандарти:
pcg_eur(default),ua_nsbo(повний UA-COA + 53 BO templates),ifrs(caption-scaffolding, неактивний за замовчуванням).Раніше планувалось: Dual
accounting-eu+accounting-uaяк окремі плагіни. Реалізовано: уніфікована модельLedgerуessentials/, де кожен tenant вмикає N стандартів одночасно і одна господарська операція породжує по одномуPostingGroupна кожен активний ledger.
Що працює сьогодні¶
| Компонент | Місце | Стан |
|---|---|---|
Модель Ledger (per-tenant активні контури) |
backend/essentials/models/ledger.py | ✅ |
BusinessOperationTemplate (per-standard Dt/Ct) |
backend/essentials/models/business_operation_template.py | ✅ |
PostingGroup.ledger + source_signature |
backend/essentials/models/posting.py | ✅ |
ChartOfAccounts.standard (multi-tree COA) |
backend/essentials/models/chart_of_accounts.py | ✅ |
post_accounting_entry — ledger-loop |
backend/essentials/services/accounting_service.py | ✅ |
pick_standard_for_report + tenant_active_standard_codes |
backend/essentials/services/ledger_service.py | ✅ |
| 6 звітів (P&L / BS / TB / CF / Partner Turnover / P&L Drill-down) — ledger-aware filter | backend/essentials/reports/ | ✅ |
| UA-NSBO P&L (Форма №2) + BS (Форма №1) — каркас структур | profit_loss.py, balance_sheet.py | ✅ |
| seed UA-NSBO COA (~80 рах.) + 53 BO templates за маппінгом | seed_ua_nsbo.py | ✅ |
| seed IFRS scaffolding (26 caption-рах., неактивний Ledger) | seed_ifrs.py | ✅ |
mirror_postings_to_standard — backfill історії |
mirror_postings_to_standard.py | ✅ |
verify_postings --level=1/2/3 — sanity інваріанти |
verify_postings.py | ✅ |
ReconciliationRun модель + endpoint /accounting/reconciliation-status/ |
reconciliation_run.py | ✅ |
| Frontend: Select «Стандарт» у Report.tsx — без додаткових змін | вже було | ✅ |
| Окрема секція «Бухгалтерія» у Sidebar (icon BankOutlined) | config/accounting.ts | ✅ |
| Master Data: ChartOfAccounts (з фільтром standard), BusinessOperations (з subtable «Шаблони проводок») | ChartOfAccountsList.tsx, BusinessOperationTemplatesTable.tsx | ✅ |
| Transaction Data: DocumentOperations (per-line BO, N PostingGroup'ів) + Multi-leg Journal Entry (1 PostingGroup, 3+ ніг) | DocumentOperationPage, JournalEntryPage | ✅ |
Звіти, поділені по стандартах PCG/UA-NSBO/IFRS — групи з requiresStandard ховаються автоматично коли стандарт не активний |
StandardReports.tsx, useActiveStandards.ts | ✅ |
Налаштування адону (Ledgers + Reconciliation) — у глобальному /settings → Бухгалтерія (адон) |
AccountingPluginSettings.tsx, LedgerListPage.tsx, ReconciliationPage.tsx | ✅ |
Endpoint POST /accounting/run-reconciliation/ — тригер verify_postings з UI |
views/reconciliation.py | ✅ |
| Dashboard плашка «Сходимість» (overall_status на головному екрані) | — | ❌ окрема ітерація |
| Офіційний XML-export ПСБО Форми 1/2 у M.E.Doc | — | ❌ окрема ініціатива |
Production-flow (BO «Закупка сировини») для UA: Dt 201 / Ct 631 (з обмеженням маппінгу) |
— | ⚠️ потребує per-context BO або BusinessOperationRule |
Як це працює¶
- У tenant'а активний один або кілька Ledger (
pcg_eur,ua_nsbo,ifrs). Кожен маєactivated_from/activated_toдля перемикання перед періодом. Активація — через/settings → Бухгалтерія (адон). BusinessOperation— шапка господарської операції з людським іменем («Реалізація товару»). Конкретні рахунки на кожен стандарт — у дочірній таблиціBusinessOperationTemplate(business_operation, standard, debit_account, credit_account, vat_debit_account). Редагується через subtable «Шаблони проводок» у формі BO.- При post'у документа
post_accounting_entryробить цикл по активних ledger'ах і створює окремийPostingGroupдля кожного, шукаючиBusinessOperationTemplate(business_operation, ledger.code). Якщо template відсутній — поведінка визначаєтьсяEssentialsModuleSettings.missing_template_policy(skip/error/fallback). ChartOfAccounts.standardділить рахунки на паралельні дерева (PCG_EUR1000-7900, UA-NSBO10-99, IFRSA.1/R.2/тощо). Один tenant — три незалежні COA-tree. У UI план рахунків має фільтр Standard, який за замовчуванням стоїть на PCG_EUR.- Кожен звіт фільтрує
PostingEntry.filter(group__ledger__code=standard)— UA-Балансу не видно EU-проводки і навпаки. Балансова невідповідність на demo-tenant'і = 0 за обома стандартами. - Sidebar-групи звітів мають поле
requiresStandard— група «Звіти — IFRS» не показується, поки IFRS Ledger не активний (хукuseActiveStandardsфільтрує у SectionDashboardPage). - Reconciliation foundation —
source_signature(SHA-256 ключових полів) у кожнійPostingGroup;verify_postings(CLI або POST endpoint) виявляє розходження (unbalanced,amount_mismatch,cross_ledger_amount_mismatch,signature_drift) і фіксуєReconciliationRunдля дашборду.
Розмежування: DocumentOperations vs Multi-leg Journal Entry¶
Два інструменти для різних випадків (паралель з 1С: «Бухдовідка» vs «Операція БО»):
| Документ-операції | Складна проводка (multi-leg) | |
|---|---|---|
| Що генерує на post | N окремих PostingGroup (по 1 на лінію) | 1 multi-leg PostingGroup |
| Лінія | BusinessOperation + Dt + Ct + amount | account + debit + credit (без BO) |
| Інваріант | sum Dt = sum Ct per line | sum Dt = sum Ct на весь документ |
| Use-case | Кілька регламентних операцій одним документом | Корекції з 3+ ніжками: розкид з/п, закриття 79→44, opening balances |
Раніше планувалось (для історії)¶
Статус: 🔮 відкладено в окрему майбутню ініціативу. Тригер: поява клієнта з вимогами офіційної UA-звітності + готовність виділити команду податкового/обліково-методологічного супроводу.
Мотивація¶
Поточний стан (2026-04-22): - В DOP — один глобальний план рахунків (європейський PCG, класи 1–7: 4100=Customers, 4000/4010=Suppliers, 5300/5310=Cash, 7000=Sales). - ПСБО Форма 1 працює як management layout над європейським PCG (див. cashflow-reports.md §D-bis) — не підходить для подачі у ДПС. - Український клієнт очікує «нормальні» рахунки 361, 631, 301, 311, 701, 631 — бо це те, що бачить аудитор, що йде в M.E.Doc, що відповідає ПСБО. - Європейський клієнт (а також DOP-холдинг з управлінським обліком у IFRS-подібній логіці) очікує PCG/IFRS-подібний шаблон.
Проблема: одночасно задовольнити обидва сценарії одним глобальним CoA неможливо — структура рахунків різна (не 1:1), рівні групування різні, звіти різні.
Цільова архітектура¶
Розділити горизонтальний аддон Accounting & Tax на два паралельні плагіни, які можуть бути встановлені одночасно для одного тенанту:
| Плагін | План рахунків | Звіти | Інтеграції |
|---|---|---|---|
accounting-eu |
Європейський PCG (4100, 4000, 5300, 7000 …) — класи 1-7 | Trial Balance, Balance Sheet, P&L (IFRS-style), Cash Flow | Внутрішній management reporting |
accounting-ua |
Український CoA за ПСБО 1 (361, 631, 301, 311, 701, 791, 441 …) | Офіційні ПСБО Форма 1 і Форма 2 (звіт про фінансовий стан + звіт про фінансові результати) | M.E.Doc: експорт ф1/ф2, ПДВ-декларація |
Варіанти використання (use-cases):
- Тільки EU — стартапи / SaaS / internal-tools без UA-юрособи: достатньо для управлінського обліку, KPI, investor reporting.
- Тільки UA — класичне українське підприємство: тільки офіційна звітність, без дублюючого management layer.
- EU + UA одночасно (холдинг з UA-юрособою + експатріатним CFO): та сама господарська операція породжує проводки на обох планах одночасно; кожен звіт читає своє джерело.
Технічні рішення¶
Core-інфраструктура (вже є):
- BusinessOperation — шаблон проводки (Dr/Cr рахунки + розмірності). Вже підтримує різні плани рахунків (FK на ChartOfAccounts).
- ChartOfAccounts — ієрархічний, tenant-aware. Один тенант може мати багато планів рахунків (розрізнених хоч по code_system — новий enum-атрибут).
- PostingGroup + PostingEntry — подвійний запис. Один PostingGroup може мати accounting_framework ∈ {eu, ua} — тоді кожна господарська операція створює два PostingGroup-и (одна для EU-шаблону, друга для UA-шаблону), а звіти фільтрують по framework.
Налаштування в EssentialsModuleSettings:
- enabled_frameworks = {'eu'} / {'ua'} / {'eu', 'ua'} — мультівибір.
- default_framework — який використовується за замовчуванням (для звітів, що не приймають параметр).
- Дефолтні BO (default_sales_operation та ін.) повинні стати списком на кожен framework (default_sales_operation_eu, default_sales_operation_ua) — щоб один продаж породжував Dr 4100 Cr 7000 (EU) та Dr 361 Cr 701 (UA) одночасно.
Плагіни:
- accounting-eu — набір seed-даних (рахунки класів 1-7, типові BO).
- accounting-ua — seed український CoA (361, 631, 301, 311, 701, 791, 441, 92, 93, 94, 311, 631, 641, 651, 661, …), типові BO, офіційні ПСБО Форми 1/2, ПДВ декларація, прибуткова декларація.
Scope включає: доведення ПСБО Форма 1 до офіційної форми¶
Частина ініціативи accounting-ua:
- Повний mapping всіх рядків форми (активи: 1000, 1005, 1010, 1011, 1015, …, 1125, 1135, 1165, 1195; пасиви: 1400, 1410, 1495, 1615, 1620, 1695 …).
- Коректний перенос на початок і кінець звітного періоду (колонки «на початок звітного періоду» / «на кінець звітного періоду»).
- Підтримка малого / мікропідприємництва (спрощена форма 1-м).
- Експорт у офіційний XML-формат для M.E.Doc / СОТА (ф1 → J0100108 / ф2 → J0100208 чи актуальні коди).
- Підпис КЕП через локальний агент.
- Regression-тести на реальних seed-даних (тестові проводки → згенерований звіт → звірка з еталоном).
Поточний management-layout /reports/psbo-form1/ тоді стане alias до майбутнього /reports/psbo-form1/?framework=eu (internal view), а офіційний ПСБО-звіт буде на окремому endpoint-і /api/v1/accounting-ua/reports/psbo-form1/ з уже коректним UA CoA.
Чому відкладено¶
- Потрібна спеціалізована команда з методології UA-обліку (актуальні накази Мінфіну, зміни ПСБО, правила подачі в ДПС) — не задача продуктового команди.
- M.E.Doc-формати звітів змінюються 1–2 рази на рік — потрібен регулярний цикл супроводу (схожий на наш experimental tax invoice flow).
- Для EU-клієнтів (MVP DOP) поточного single-CoA вистачає.
- Ризики помилки подання → штрафи клієнту → репутаційний ризик платформи.
Тригери відновлення роботи¶
- Клієнтський попит: український клієнт із вимогою подачі ПСБО-звітів безпосередньо з DOP (без перенесення в M.E.Doc «руками»).
- Холдинг: клієнт з UA-юрособою + закордонним материнським контуром, якому потрібен одночасний EU + UA облік.
- Виділення команди: поява дедикованого бухгалтера-методолога як частини команди DOP.
До виконання цих умов — одна з найбільших відкладених робіт у accounting-track.