Звітність та регістри¶

Як читати результати обліку: журнали (хронологія), леджери (залишки), звіти (P&L, Cash Flow, Balance).

1. Регістри (Journals & Ledgers)¶

DOP розрізняє журнали (хронологічний перелік операцій) та леджери (накопичувальні залишки).

Journals (хронологія)¶

Журнал	Джерело даних	Приклад запитів
`CashJournal`	Cash/Bank payments	"Рухи готівки за день"
`InventoryJournal`	GoodsReceipt/Shipment/Writeoff	"Оборот товару X за місяць"
`IncomeExpenseJournal`	Invoices + Payments + Operations	"Доходи/витрати за ExpenseItem"
`PlannedPaymentJournal`	PlannedPayment	"Календар платежів"

Ledgers (залишки)¶

Леджер	Призначення
`CashLedger`	Залишки кас і р/р по датах
`InventoryLedger`	Залишки товарів (warehouse × item × batch)
`PartyLedger`	Уніфікований регістр розрахунків з контрагентами — `direction ∈ {receivable, payable}` (детальніше)

Леджери — денормалізовані для швидких запитів. Оновлюються при проведенні документа через Django signals.

Історично у документації були заявлені окремі ClientLedger (дебіторка) та SupplierLedger (кредиторка). Фактична реалізація (2026-04-22) — єдиний PartyLedger з полем direction, оскільки структура полів ідентична, а клієнт може бути і покупцем, і постачальником одночасно.

2. Universal RegisterRecordsPage¶

UI-компонент, який працює з будь-яким журналом/леджером у 3 режимах:

Режим	URL-pattern	Що показує
`document`	`/:section/:group/:item/:recordId/postings`	Проводки конкретного документа
`list`	`/:section/:group/:item/postings?id=X`	Проводки рядка зі списку
`all`	`/:section/:group/:item/postings`	Всі записи регістра з фільтрами

Джерело даних — POSTING_CONFIG[itemCode] з transactionForm.config.ts (для документів) або item.componentProps.apiPath (для JOURNAL/LEDGER).

3. Основні звіти¶

Усі ендпоінти реалізовано у essentials/views/reports.py під префіксом /api/v1/essentials/reports/.

A. Trial Balance (ОСВ — оборотно-сальдова)¶

Endpoint: GET /reports/trial-balance/?date_from=...&date_to=... Реалізовано: ✅ 2026-04-22.

Класичний бух. звіт: по кожному рахунку PCG — початкове сальдо → обороти Дт/Кт → кінцеве сальдо. Джерело даних — IncomeExpenseJournal, згрупований за account. Використовується як первинний діагностичний звіт перед закриттям періоду.

B. Звіт про фінансові результати (P&L)¶

Endpoint: GET /reports/profit-loss/?date_from=...&date_to=... Реалізовано: ✅ (базовий).

Доходи: 701, 702, 703 → 791
Собівартість: 901, 902, 903 → 791
Операційні витрати: 92, 93, 94
Результат: 791 → 441 (нерозподілений прибуток)

B-bis. P&L Drill-Down¶

Endpoint: GET /reports/profit-loss/drill-down/?date_from=...&date_to=...&prefix=70&dimension=account Реалізовано: ✅ 2026-04-22.

Розгортка P&L по вимірах аналітики. Параметр dimension ∈ {account, expense_item, business_direction, department} — обидва prefix та dimension обов'язкові. Дозволяє бачити не просто «витрати 50 000 грн», а розподіл за статтями / напрямами / підрозділами.

C. Cash Flow (рух грошових коштів)¶

Endpoint: GET /reports/cash-flow/?date_from=...&date_to=... Реалізовано: ✅ (Direct Method).

Operating (поточна діяльність): виручка − виплати постачальникам − зарплата − податки
Investing (інвест): покупка ОЗ, продаж активів
Financing (фінансова): кредити, дивіденди, внески учасників

D. Balance Sheet (баланс, PCG)¶

Endpoint: GET /reports/balance-sheet/?as_of=... Реалізовано: ✅ (9 секцій).

Активи = Зобов'язання + Капітал - Необоротні активи (10, 11, 12) - Оборотні активи (20, 22, 28, 30, 31, 36) - Власний капітал (40, 44) - Поточні зобов'язання (63, 64, 68)

D-bis. ПСБО Форма 1 — management layout (не офіційний звіт)¶

Endpoint: GET /reports/psbo-form1/?as_of=... Реалізовано: ✅ 2026-04-22 як management layout.

⚠️ Обмеження scope: DOP використовує європейський (французький) план рахунків (класи 1-7: 4100 — Customers, 4000/4010 — Suppliers, 5300/5310 — Cash, 7000 — Sales). Офіційна українська ПСБО Форма 1 історично заповнюється з українського національного плану рахунків (361, 631, 301, 701 і т.д.).

Цей endpoint виводить той самий набір даних у візуальному layout-і ПСБО Форми 1 (номери рядків 1000, 1010, 1100, 1125, 1400, 1420, 1615 …) — для внутрішнього управлінського використання (CFO/бухгалтер звик читати саме у такому вигляді). Це НЕ офіційний документ для подачі в ДПС чи M.E.Doc. Для офіційного подання потрібен окремий mapping через український CoA — див. 🔮 deferred-ініціативу «Dual chart of accounts: accounting-eu + accounting-ua», яка охоплює повну доведення ПСБО Форми 1 до офіційної форми.

Mapping PCG → рядки ПСБО: 4100 debit → 1125 (торг. дебіторка), 4000/4010 credit → 1615 (торг. кредиторка), 5100/5110/5120/5300/5310 debit → 1165 (гроші), 7000 revenue → рядок 27 звіту P&L.

E. Payment Calendar¶

Endpoint: GET /reports/payment-calendar/?date_from=...&date_to=... Реалізовано: ✅.

Календар платежів: заплановані (з PlannedPaymentJournal) vs фактичні (з CashJournal).

F. Заборгованість контрагентів¶

Реалізовано через уніфікований PartyLedger — окремий регістр з ендпоінтами /registers/ledgers/party/report/ (залишки на дату) і /registers/ledgers/party/by-document/ (drill-down).

Aging report: 0-30, 31-60, 61-90, 90+ днів — 🔮 backlog.
Prognosis: очікувані надходження/платежі з Invoice.due_date — 🔮 backlog.

G. Specialized реports¶

VAT Return — звіт ПДВ (за періодом, Декларація) → експорт у M.E.Doc — 🔮 planned.
UKTZED-based export report — звіт за кодами УКТЗЕД — 🔮 planned.
Financial analytics — P&L за напрямами, регіонами (BusinessDirection × BusinessRegion) — частково (через P&L Drill-Down).

4. Побудова звітів¶

ReportViewer (Frontend)¶

components/Reports/ReportViewer.tsx — універсальний дашборд з: - Фільтри (період, організація, аналітики) - Mantine Charts (lines, bars, pies) - Excel export (xlsx) - Друк (print-friendly layout)

Backend¶

Raw aggregation queries (Django ORM + django.db.models.Sum/Count)
Plus — custom materialized views для великих обсягів
API endpoint: /api/v1/essentials/reports/<report_name>/

5. Фінансовий аналітик (AI)¶

Feature: Finance Analyst — AI-агент, що: - Приймає питання природною мовою ("як зросли витрати на паливо?") - Сам будує SQL-запити до регістрів - Генерує графіки + пояснення - Base — ESWF-Chat (OpenRouter)

🔮 Deferred / Ideas¶

Real-time dashboard (WebSocket)¶

Мотивація: CFO хоче live-статус каси, заборгованостей, очікуваних надходжень Чому відкладено: потрібен stream aggregation Trigger: запит CFO великого клієнта

Multi-entity consolidated reports¶

Мотивація: холдинг має 5 Organization → консолідований P&L Чому відкладено: потрібен модуль Consolidator Trigger: група компаній

Budget vs Actual variance reports¶

Мотивація: порівняння планових платежів / виручки з фактом Чому відкладено: треба модуль Budgeting Trigger: клієнт з річним плануванням

Drill-down from report to source document¶

Мотивація: клік на цифру у звіті → перехід до первинки Чому відкладено: link-back потребує розширення звітного API Trigger: постійні support-запити бухгалтерів

Scheduled report delivery (email)¶

Мотивація: керівники хочуть щоденні/щотижневі звіти на пошту Чому відкладено: потрібен email template engine + scheduler Trigger: корпоративний клієнт