Перейти до змісту

Аудит ESWF / DOP — документація vs реалізація

✅ ЗАКРИТО 2026-04-22. Усі планові фази (0, 1, 3, 4, 5-частково) виконано в двох сесіях; Фаза 2 (CI/CD) свідомо відкладена до колективної розробки. Продовження аудиту — у audit-2026-04-22.md.

Підсумок (повний підсумок виконання — у §11ter, §11quart і §12 нижче): - Phase A (Documentation sync): ✅ — applications.ts статуси, DOCS.md маркери, CLAUDE.md розмежування Client Portal ↔ E-Commerce Manager, useActivePlugins regression-тест, +5 розширений EssentialsSettingsSerializer. - Phase B (Frontend reports): ✅ — TrialBalanceReport, PnlDrillDownReport, PsboForm1Report для готових Phase-3 endpoints. - Phase C (CI/CD): ⏸️ ВІДКЛАДЕНО до команди / prod-deploy. Trigger: перший зовнішній PR. - Phase D (CRM Pipeline + analytics): ✅ — auto-history через perform_update, ActivityLedger через perform_create, 4 analytics endpoints, 2 dashboard-сторінки. - Phase E (JournalEntry + FixedAsset): ✅ — повноцінні MVP backend + frontend. - Phase F-1..F-4 (4 нові MVP-модулі): ✅ HRM, Production, BAF Sync, Budgeting — кожен з власним backend app, тестами, frontend, документацією. - God-components refactor: ⏸️ ВІДКЛАДЕНО (активна розробка створює ризик конфліктів).

Метрики (143 backend tests, 21 backend apps) — див. §12.

Дата: 2026-04-21 (закрито 2026-04-22) Автор: Claude Code Область: backend (15 Django apps), frontend ERP (config + components), mobile (Driver + Sales), integrations, documentation in docs/ Методологія: порівняння кожного розділу DOCS.md з фактичним кодом (backend/, frontend/, mobile/, mobile-sales/) станом на 2026-04-21.

0. TL;DR (стисло — що робити далі)

Загальна оцінка: у проєкті є надмірна документація (плани модулів, яких ще немає), але нульові/мінімальні тести бекенду, монолітні компоненти і кілька розбіжностей між конфігами frontend / backend / docs (див. §8).

Топ-5 кроків (що закрити першим):

  1. Привести sidebar frontend до реальності. У applications.ts статуси appCRM, appFleetTrack, appPurchaseInvoice, appQuality фактично installed. appAccounting — частково реалізовано (ChartOfAccounts + PostingGroup/PostingEntry + фінансові звіти в essentials/ — потрібен статус installed з приміткою "core, розширення у розробці"). appCommerce треба переосмислити як "E-Commerce Manager" — процес-аддон всередині Essentials (StoreManager в ERP + shop backend) → installed. appPortal — це окремий Next.js фронтенд frontend/shop/ (shop.eswf.dev) → installed (частково). Деталі — §1.3 та §2.5. (appLogistic залишається як демонстрація механізму платного плагіна — logistic/ навмисно винесено з community-поставки backend, щоб відлагодити exclusion-flow.)
  2. Закрити backend-тести. Front має 80 тестів (Vitest), у backend лише 7 пустих tests.py по 3 рядки. Потрібен pytest + покриття UniversalViewSet, TenantFilterMixin, serializers, permissions.
  3. CI/CD-пайплайн. .github/, Dockerfile, docker-compose.yml відсутні. Потрібен як мінімум GitHub Actions (lint + typecheck + test + build) на PR.
  4. ✅ Reset migrations (2026-04-22). Було 183 → стало 19 initial-міграцій (один розробник, prod-бази немає — зроблено повний reset, не squash). Деталі — §9.4.
  5. Рефакторинг god-компонентів. AdminToolsPage.tsx (1331 ряд.), ChatPage.tsx (1443), ChatDrawer.tsx (1290), SalesFieldManager.tsx, ETTNPage.tsx (1077) — розбити на секції / контейнери / presentational.

Деталі — §§ 1-10.

1. Відповідність заявлених модулів фактичному коду

1.1 Backend Django apps

Документація (DOP-модуль) Backend app Статус реалізації Примітка
Core (ESWF) core/ ✅ реалізовано User, Tenant, AuditLog, Registry, UniversalViewSet
Essentials (horizontal) essentials/ ✅ реалізовано 42+ моделей — відповідає документації
Fleet (vertical) fleet/ ✅ реалізовано 33+ моделі, waybill, eTTN, GPS, аггрегати
Logistic / Multimodal Freight & Forwarding (vertical) logistic/ 🧩 платний плагін — навмисно поза community (еталонний exclusion-кейс) Frontend config + документи dop/modules/vertical/logistic/{README,operations,architecture}.md лишаються; _PLUGIN_URLS["logistic"] обумовлено apps.is_installed("logistic"); при відсутності — секція logisticSection ховається через useActivePlugins. Документація з multimodal/ консолідована в цю теку (2026-04-21)
ContainerHub (vertical) containerhub/ ✅ реалізовано 15+ моделей, drone, stacking, EDI
CRM & Sales (horizontal) crm/ ⚠️ частково (9 моделей: Lead, Contact, Deal, Activity, Quotation + SalesOrder) Немає Account (як okремої сутності — використовується Client), немає PipelineHistory (журнал переміщень по етапах)
Accounting & Tax (horizontal) essentials/ (ядро) ⚠️ частково реалізовано — ядро в Essentials План рахунків (ChartOfAccounts), проводки (PostingGroup+PostingEntry), звіти P&L / Balance / CashFlow / PaymentCalendar, BusinessOperation. Відсутні: Trial Balance, ПСБО Форма 1, податкові декларації, окремий FixedAsset/Depreciation, ручні JournalEntry
HRM & Payroll (horizontal) — ❌ не реалізовано Частково присутнє в Fleet (DriverSalaryAccrual, DriverSalaryRate) як підмодуль водіїв
Production & BOM (horizontal) — ❌ не реалізовано planned, backlog
Budgeting (horizontal) — ❌ не реалізовано (заглушка документації) in_progress
E-Commerce Manager (horizontal addon) backend/shop/ + ERP StoreManager/ ✅ реалізовано як процес-аддон Essentials — каталог продуктів DOP, activation codes, SMTP/email, замовлення. Це конкретний випадок "DOP продає сам себе"; загальний headless e-commerce engine для клієнтів DOP (з LiqPay/Nova Poshta) — planned
Consolidator (horizontal) — ❌ не реалізовано заглушка документації
Client Portal (horizontal) frontend/shop/ (Next.js 15 SSR) ✅ реалізовано як окремий Next.js фронтенд (shop.eswf.dev): каталог з довідників Essentials, замовлення, трекінг, customer account, transport requests. Відсутні: statement of account (акт звірки), reconciliation, returns, platформа B2B з individual pricing
Essentials — Quality Control essentials_quality/ ✅ реалізовано (підключається як plugin) 5 моделей: DefectReason, StorageLocation, QualityInspection, ReceiptFlow, BlockedStockLedger
Transport (railway catalogs) transport/ ✅ реалізовано RailwayRoad, RailwayStation, Wagon — довідники
Chat (AI + messenger) eswf_chat/ ✅ реалізовано ChatSession, Message, ChatRoom, RoomMembership, RoomMessage
Shop (продаж DOP-модулів) shop/ ✅ реалізовано 8+ моделей, activation codes
News news/ ✅ реалізовано Article, Category, Tag
Mobile API (Driver) mobile_api/ ✅ реалізовано WatermelonDB sync pull/push
Sales Mobile API sales_mobile_api/ ✅ реалізовано 9 моделей, photo/sig/GPS
Sales Field supervisor sales_field/ ✅ реалізовано 10 endpoints, без власних моделей
Medoc exchange medoc_exchange/ ✅ реалізовано (UKTZED довідник) Для податкової звітності
Registers (журнали/леджери) registers/ ✅ реалізовано 12 моделей регістрів

Розбіжності зі списком у CLAUDE.md («15 apps»):

  • Фактично: 17 apps (додалися essentials_quality, transport, sales_field).
  • CLAUDE.md згадує logistic/ як існуючий app з 3 моделями (LogisticOrder, RouteSheet, ContainerType) — насправді це зовнішній/платний плагін, фізично відсутній у community-збірці; перепис у CLAUDE.md потрібно зробити саме як «опціональний плагін, не входить у community».
  • eswf_chat/ у CLAUDE.md описано як окремий (з моделями чату) — воно справді є, але не в списку «15 apps».

1.2 Frontend ERP — config секції

Файл-індекс: frontend/erp/src/config/index.ts експортує 6 секцій:

sections: [essentials, fleet, crm, logistic, containerhub, applications]
Секція Файл Кількість code: Backend-пара
Essentials essentials.ts 110 essentials/
Fleet fleet.ts 71 fleet/
CRM crm.ts 22 crm/
Logistic logistic.ts 38 🧩 logistic/ — платний плагін; у community backend відсутній за дизайном
ContainerHub containerhub.ts 55 containerhub/
Applications applications.ts 25 (app-store UI)

Питання дизайну (не баг): logisticSection експортується завжди, але без backend-плагіна CRUD дає 404. Цільова поведінка — frontend має приховати секцію, якщо backend повідомив, що плагіна немає (механізм useActivePlugins). Треба перевірити, що logisticSection пов'язана з appCode коректно і фактично ховається при відсутності плагіна. Це ключова точка валідації механізму exclusion для всіх майбутніх платних модулів.

1.3 Applications (app store) — статуси vs реальність

У applications.ts заявлено 17 додатків. Звіряємо status з фактом:

Додаток (code) Declared status Фактично Рекомендація
appEssentials installed ✅
appFleet installed ✅
appLogistic installed 🧩 платний плагін, у community відсутній змінити на available (платний) — статус має відображати «купується окремо», а не «встановлено»
appContainerHub installed ✅
appCRM available ✅ backend є (crm/), frontend crmSection є змінити на installed
appAccounting available ⚠️ ядро реалізовано в essentials/: ChartOfAccounts, PostingGroup+PostingEntry, BusinessOperation, 4 фінансові звіти installed (з уточненим описом: "core у Essentials; розширення — Trial Balance, ОСВ, Форма 1, податкові декларації — у розробці")
appBudgeting development ❌ заглушка залишити
appManager (HR) development ❌ немає залишити
appCommerce (→ переіменувати в E-Commerce Manager) available ✅ реалізовано як процес-аддон всередині Essentials: StoreManager/ (ProductsPage, LicensesPage, ActivationCodesPage, ECommercePage, EmailClientPage, SmtpSettingsPage) + backend/shop/ installed + community (частина ядра); уточнити опис: керування каталогом для Client Portal + генерація activation codes + SMTP
appPortal (Client Portal) available ✅ окремий Next.js-фронтенд frontend/shop/ (shop.eswf.dev): каталог, замовлення, transport requests installed; уточнити опис: окремий Next.js 15 SSR фронтенд, використовує довідники Essentials, керується з appCommerce
appConsolidator development ❌ заглушка залишити
appFleetTrack available ✅ GPS реалізовано (WebSocket, Wialon) installed
appDriverApp installed ✅ (mobile/)
appSalesField installed ✅
appChat installed ✅
appBankExchange available ⚠️ є UI BankExchangeProcess.tsx, API? перевірити
appPurchaseInvoice available ✅ реалізовано installed
appQuality available ✅ essentials_quality installed (якщо plugin активний)
appeTTN installed ✅
appMED available ⚠️ medoc_exchange є, але тільки UKTZED довідник, без повного flow залишити available
appBAFSync development ❌ заглушка документації залишити

Висновок: близько 8 статусів потребують коригування. Це — найдешевша правка (редагування одного файлу applications.ts), але критично впливає на довіру користувача до UI app-store.

1.4 Розмежування Client Portal ↔ E-Commerce Manager

Два додатки appPortal і appCommerce раніше перекривалися за сенсом. Чітка логіка (відповідає поточній реалізації):

Аспект Client Portal (appPortal) E-Commerce Manager (appCommerce)
Хто користувач Зовнішній клієнт (покупець) Внутрішній менеджер магазину (з ERP)
Де живе UI Окремий Next.js 15 SSR фронтенд (frontend/shop/, домен shop.eswf.dev) Процес-аддон всередині ERP (frontend/erp/src/components/StoreManager/)
Framework Next.js (SSR) — окремий deployment React + Mantine у складі DOP App
Backend backend/shop/ (/api/v1/shop/) + /api/v1/cart, /api/v1/orders, /api/v1/transport-requests той самий backend/shop/ — адмін-ендпоінти для продуктів / ліцензій / SMTP / codes
Джерело даних Довідники Item, Client, Invoice з Essentials Той самий каталог + Product + ActivationCode + License + EmailSmtpSettings + EmailLog
Функції Перегляд каталогу, кошик, замовлення, оплата, трекінг доставки, transport request, customer account Публікація товарів у Client Portal, генерація/розсилка activation codes, SMTP налаштування, email-логи, Kanban замовлень, управління ліцензіями
Статус зараз ✅ Реалізовано (Core) ✅ Реалізовано (Core)
Класифікація appType: "module" — окремий фронтенд appType: "addon" — процес всередині Essentials

Конкретний кейс реалізації, який пояснює дизайн: компанія розробила ERP-систему DOP і водночас через саму DOP продає свої модулі (addons / perpetual licenses / subscriptions). Тобто Client Portal у нашому демо — це shop, де продаються самі DOP-модулі, а E-Commerce Manager — це ERP-аддон, через який ми цими продажами керуємо. Для клієнтів DOP той самий pattern: вони можуть включити ці два додатки, щоб створити свій власний інтернет-магазин на базі своєї DOP-системи.

Плановий розширений сценарій (залишається у backlog): headless e-commerce engine (backend/ecommerce/) для продажу товарів клієнта DOP (з LiqPay / Нова Пошта / рекламаціями / B2B individual pricing) — див. dop/modules/horizontal/commerce/README.md. Це інша історія: не «DOP продає себе», а «клієнт DOP продає свої товари через DOP».

2. Аудит Essentials — detailed

2.1 Master Data (очікувано vs реалізовано)

Документація обіцяє (essentials README):

Item, ItemComponent, Unit, ExpenseItem, PriceType, Client, ClientResponsiblePerson, Organization, Person, Department, BusinessDirection, BusinessRegion, Contract, ContractSpecification, Cashbox, Bank, SettlementAccount, TaxRate, Currency, ExchangeRate, ExchangeRateSource, ChartOfAccounts, BusinessOperation, Warehouse, Batch, BatchStatus, ValuationMethod, ItemWarehouseStock

Реалізовано (backend/essentials/models/): усе присутнє ✅.

Додатково у коді, не згадано в README: - DistanceScaleLine (тариф-по-км у специфікації договору) — є в prices/tariffs доках Fleet; - TelephonySettings — для IP-телефонії (тільки згадано в ip-telephony integration); - EssentialsModuleSettings — налаштування модуля.

2.2 Transactions

Документація: PurchaseOrder, GoodsReceipt, PurchaseInvoice, AdditionalExpense, Invoice, GoodsShipment, IncomingPayment, OutgoingPayment, PlannedPayment, GoodsWriteoff, DocumentOperation

Реалізовано: усе ✅ (плюс AdditionalExpenseAllocation + AdditionalExpenseLine + AdditionalExpenseTarget — повна модель аллокації).

2.3 Registers

Документація: CashJournal, InventoryJournal, IncomeExpenseJournal, PlannedPaymentJournal, CashLedger, InventoryLedger, ClientLedger, SupplierLedger, Posting, StockTransaction

Реалізовано у essentials/: CashJournal, InventoryJournal, IncomeExpenseJournal, PlannedPaymentJournal, PostingGroup + PostingEntry, StockTransaction.

Реалізовано у registers/ (окремий app): CashJournal, CashLedger, InventoryJournal, FuelJournal, FuelLedger, PieceworkSalaryJournal, AggregateAmortizationJournal, PipelineHistoryJournal, PerformanceIndicatorTurnover, ActivityLedger, DriverSalaryLedger, CustomerOrderLedger.

Проблема: CashJournal і InventoryJournal дубльовані в essentials/ і registers/. ClientLedger, SupplierLedger — відсутні взагалі (документація згадує). Треба визначити єдине джерело істини.

2.4 Розділи документації vs наявність коду (деталізовані md-файли)

doc-файл Статус бекенду Статус frontend
nomenclature.md ✅ ✅ (components)
partners.md ✅ ✅
contracts.md ✅ ✅
prices.md ✅ (ItemPrice) ✅ PriceManagement.tsx
finance-accounts.md ✅ ✅
currency.md ✅ ✅ ExchangeRatesPage.tsx, NbuFetchPage.tsx
batches.md ✅ ✅ BatchPickerModal.tsx, InventoryValuationPage.tsx
vat.md ✅ (vatUtils.ts + TaxRate) ✅
goods-receipt.md ✅ ✅ (через TransactionForm)
purchase-invoice.md ✅ 3-way matching ✅
sales-invoice.md ✅ ✅ (+ InvoiceKanbanBoard)
payments.md ✅ (+ PlannedPayment) ✅
writeoffs.md ✅ ✅
quality-control.md ✅ (essentials_quality) ⚠️ немає окремих frontend-компонентів (Quality UI в roadmap)
accounting-setup.md ✅ ChartOfAccounts + BusinessOperation ✅
document-operations.md ✅ DocumentOperation ✅
inventory-finance.md ✅ batches + ledgers ✅
cashflow-reports.md ✅ реалізовано — 4 endpoints у essentials/views/reports.py: ProfitLossReportView (P&L з PCG-структурою), BalanceSheetView (Balance Sheet з 9 секціями), CashFlowReportView (Direct Method), PaymentCalendarView (planned vs actual) ✅ ReportViewer.tsx рендерить виклики цих endpoints

Висновок Essentials: фундамент дуже міцний — наявні всі ключові журнали + повноцінні фінансові звіти (P&L, Balance Sheet, Cash Flow, Payment Calendar) з PCG-mapping та валюто-агрегацією через IncomeExpenseJournal / CashJournal. Залишається допрацювати ClientLedger / SupplierLedger (декларовано — немає) і дашборди-обгортки для звітів (drill-down, фільтри).

2.5 Accounting — що фактично вже входить у Essentials

Окремий backend-app accounting/ не створено, але ядро бухгалтерії реалізовано як частина Essentials:

Що реалізовано Де
План рахунків (ChartOfAccounts) essentials/models/chart_of_accounts.py + master-data UI
Бізнес-операції (шаблон проведень) essentials/models/business_operation.py + DocumentOperation
Проводки (Posting) essentials/models/posting.py — PostingGroup + PostingEntry
Перегляд проводок з документа Frontend DocumentPostingsModal.tsx + route /:sectionCode/:groupCode/:itemCode/:id/postings
Журнали і леджери registers/ + essentials/ (CashJournal, InventoryJournal, IncomeExpenseJournal, CashLedger, InventoryLedger)
Фінансові звіти essentials/views/reports.py — P&L, Balance Sheet, Cash Flow, Payment Calendar
UI для регістрів RegisterRecordsPage (3 режими: document / list / all), замінив legacy JournalViewer + LedgerViewer

Чого не вистачає для повного "Accounting & Tax" modules: - Trial Balance (ОСВ) як окремий endpoint - ПСБО Форма 1 / Form 2 (окремий mapping поряд з PCG) - Tax returns (ПДВ декларація, Прибуток) - Ручна проводка (JournalEntry) — зараз всі проводки автоматичні від документів - FixedAsset + Depreciation - ClientLedger + SupplierLedger (декларовано — не реалізовано)

Тобто статус appAccounting має бути installed (ядро) + явне формулювання "full tax forms — in development".

3. Аудит Fleet

Документи: README, waybill.md, driver-salary.md, tariffs.md, fuel-calculation.md, driver-app.md.

Backend моделі (fleet/models/): 33+ моделей. Усе заявлене у документації наявне: - Vehicle + VehicleAggregate + VehicleConfiguration + VehicleStatusPeriod + OdometerReading ✅ - Waybill + WaybillTask + WaybillWorkResult + WaybillFuelRecord + WaybillDriverAccrual ✅ - Driver + DriverAccrualType + DriverSalaryRate + DriverSalaryAccrual ✅ - Route + RouteWaypoint + LocationPoint + Country ✅ - FuelType + FuelConsumptionNorm + FuelModifier + WorkCondition + SeasonOrder ✅ - MaintenanceRecord + MaintenanceType + TransportComponent + RepairUnit ✅ - ETTNDocument + ETTNParty + ETTNTestKey ✅ - GpsSnapshot + GpsAddonSettings ✅ - Order (замовлення клієнта на перевезення) + TransportInvoice + VehicleRefueling + FuelDrain + InitialBalances ✅

Frontend: components/Fleet/ — 20+ компонентів, config fleet.ts 636 рядків, 71 code-items. ✅

Проблема: документ fleet/driver-app.md описує мобільний застосунок водія як «окремий addon», але в реальності — це окремий проєкт mobile/ (React Native + WatermelonDB). У CLAUDE.md це описано, але в моді-специфічній документації Fleet посилання на структуру mobile/src/ відсутні.

4. Аудит ContainerHub

Документи: README, user-guide.md.

Backend (containerhub/models/): 15+ моделей. - Container, ContainerInspection, ContainerSeal ✅ (реалізовано в container.py) - GateTransaction, GatePhoto ✅ - ContainerMovement, ContainerBooking ✅ - YardZone, Terminal, ShippingLine, ContainerTariff ✅ - TrainArrival, TrainManifest, RailwayWaybill + RailwayWaybillWagon ✅ - DroneFlightResult, DroneDetection ✅ - ContainerLedger, StorageChargeLedger, DemurrageCalculation ✅ - IntegrationConfig, EDIMessage ✅

Frontend: components/ContainerHub/ (YardMap, DemurrageTracker, StackingOptimizer, InventoryDashboard, IntegrationHub) + config containerhub.ts 1005 рядків. ✅

Статус: модуль найдетальніший, повністю синхронізований із документацією.

5. Аудит CRM

Документ: crm-sales/README.md — деталізований план.

Backend (crm/models/): LeadSource, SalesStage, Lead, Contact, Activity, Deal, Quotation + QuotationLine, SalesOrder. ✅

Прогалини проти doc: - Документ очікує окрему сутність Accounts (компанії) — у коді використовується існуючий Client з essentials. Це архітектурне рішення (і воно логічне), але README не пояснює цього — треба доопрацювати документ. - PipelineHistoryJournal — журнал переміщень угоди по етапах — модель є в registers/, але чи оновлюється вона автоматично при зміні Deal.stage? Треба перевірити. У README заявлено. Перевірити crm/views.py / signals.py. - ActivityLedger — є в registers/ як модель, але фактичний розрахунок метрик менеджерів (кількість дзвінків × тривалість) — не реалізовано (tool-set для аналітики менеджерів).

Frontend: crmSection (config/crm.ts, 22 code-items, 316 рядків) — повний CRUD UI на базі MasterDataPage / TransactionPage. Немає окремого SalesFunnel.tsx, Win/Loss analysis dashboard — тільки плаский список угод із фільтром по стадії.

6. Аудит Mobile

6.1 Driver App (mobile/)

Відповідає документу dop/modules/vertical/fleet/driver-app.md:

  • Expo SDK 51 + React Native + WatermelonDB 0.28 ✅
  • Screens: Login, Dashboard, Profile, Waybills, Orders (+ details) ✅
  • Offline sync через /api/v1/mobile/sync/ ✅
  • delivery-action (5-step delivery) ✅

Прогалини: - Тестів: 0 - Немає моніторингу (Sentry для RN) - Немає push-повідомлень (задекларовано для sales mobile, не для driver)

6.2 Sales App (mobile-sales/)

Відповідає CLAUDE.md (документ DOP-модуля для Sales Rep). Є 23+ WatermelonDB моделей, 7 bottom-tabs, background GPS, фото, підпис, чат, push. ✅

Прогалини: - Тестів: 0 - Не описано у eswf/frontends/mobile.md — там згадано тільки загально. Треба окремий doc-файл під sales-mobile detailed.

7. Аудит Integrations

Інтеграція Документ Backend app / модуль Статус
eTTN (Ed25519) integrations/ettn.md fleet/models/ettn.py, frontend ETTNPage.tsx ✅
M.E.Doc integrations/medoc.md medoc_exchange/ (тільки UKTZED довідник + load_uktzed команда) ⚠️ частково — немає експорту документів у M.E.Doc форматі (XML), немає ЄРПН reconciliation
GPS Wialon integrations/gps-wialon.md fleet/models/gps_*, management команди start_gps_poller ✅
IP-Telephony integrations/ip-telephony.md essentials/models/telephony_settings.py + frontend SipCallOverlay.tsx ⚠️ UI-компонент є, backend моделі налаштувань — є. Фактичний SIP-клієнт → браузер WebRTC. Перевірити live-сценарій (чи робочий?)
BAF Sync integrations/baf-sync.md — детальний план (gitsync + BSL HTTP-сервіс + Pydantic + Python client) — консолідовано з колишнього 1c-sync.md (2026-04-21), бо BAF — український аналог 1С:БП — ❌ не реалізовано — лише план
Bank Exchange integrations/bank-exchange.md backend/essentials/views/bank_exchange.py (parse/import endpoints) + frontend/erp/src/components/Essentials/BankExchangeProcess.tsx ⚠️ частково — UI + parse/import є; не всі формати банків

8. Планові модулі без коду + платні плагіни

Повністю реалізовані модулі, які раніше вважалися "planned": - Client Portal — ✅ реалізовано як frontend/shop/ (Next.js 15 SSR). Документ client-portal/README.md описує розширену B2B-візію (statement of account, individual pricing, reconciliation, returns) — це залишається backlog-ом поверх поточної реалізації. - E-Commerce Manager — ✅ реалізовано як процес-аддон в Essentials (StoreManager/ + backend/shop/). Документ commerce/README.md описує загальний headless e-commerce engine (backend/ecommerce/ з LiqPay/Nova Poshta/B2B-specific pricing) — це інша амбіція, яка залишається planned. Поточна реалізація — це конкретний випадок "DOP продає сам себе". - Accounting & Tax (core) — ⚠️ ядро реалізовано в Essentials (ChartOfAccounts + PostingGroup/PostingEntry + 4 звіти + BusinessOperation). Документ accounting-tax/README.md — розширення (Trial Balance, ОСВ, Форма 1, податкові декларації, FixedAsset, ручний JournalEntry) — залишається planned.

Залишаються doc-файли без відповідного backend-коду (5 горизонтальних + 1 вертикальний):

  1. dop/modules/horizontal/accounting-tax/README.md — розширення Accounting (full tax forms). Ядро — в Essentials.
  2. dop/modules/horizontal/hrm-payroll/README.md — заявлено Employees / Positions / KPI / Timesheets / Payroll — 0 коду.
  3. dop/modules/horizontal/production-bom/README.md — BOM / WIP / Work Center — 0 коду.
  4. dop/modules/horizontal/budgeting/README.md — заглушка.
  5. dop/modules/horizontal/consolidator/README.md — заглушка.
  6. dop/modules/horizontal/commerce/README.md — розширений headless e-commerce engine (ecommerce/ app). Базовий Store Manager — вже реалізовано.
  7. dop/modules/horizontal/client-portal/README.md — розширення B2B (statement of account, individual pricing). Базовий portal — вже реалізовано.

Vertical — платні плагіни (навмисно поза community-збіркою):

  • dop/modules/vertical/logistic/{README,operations,architecture}.md + frontend/erp/src/config/logistic.ts — Logistic (Multimodal Freight & Forwarding) — платний плагін, консолідований з колишнього multimodal/ (2026-04-21). Backend-app навмисно винесено з community, щоб відлагодити exclusion-flow (через _PLUGIN_URLS + apps.is_installed("logistic") + frontend useActivePlugins). Перевірка flow — окрема задача (див. §10 Фаза 1, крок 8).

Рекомендація: для всіх «заглушок» додати явну позначку у DOCS.md:

Status: 📋 planned — код відсутній, тільки архітектурний начерк

А для платних плагінів окремий маркер:

Status: 💎 paid plugin — не входить у community, доступний як commercial addon

Це унеможливить плутанину між доступними, обіцяними та платними модулями.

9. Аудит технічного стану

Тут дублюються висновки з eswf/architecture/audit.md + нові спостереження.

9.1 Тести

  • Frontend ERP: 80 тестів, ~9 файлів, Vitest + Testing Library. ✅
  • Backend: 0 тестів (7 пустих tests.py по 3 рядки). ❌ критично.
  • Mobile (driver + sales): 0 тестів.
  • Інших frontend (portal, news, shop): 0 тестів.

9.2 CI/CD

  • Немає .github/workflows/*, Dockerfile, docker-compose. ❌
  • Немає pre-commit hooks (husky, lint-staged).
  • Немає автоматичного lint / typecheck / build перевірок.

9.3 Observability

  • Sentry підключено (frontend + backend) ✅ за документом audit.md.
  • Health-check endpoint — немає.
  • Prometheus / структуроване логування — немає.

9.4 Міграції

  • ✅ Скинуто 2026-04-22. Було 183 міграції на 13 застосунків (essentials 61, fleet 43, containerhub 14, shop/registers 13, core 8, crm 7, ~20 з них data-міграції RunPython: add_uuid, populate_state_field, cleanup tenant, seed продуктів). Замінено на 19 initial-міграцій (essentials/fleet/containerhub/crm розбиті на 2-3 через циклічні FK).
  • Процедура: бекап db.sqlite3 → видалення всіх */migrations/*.py крім __init__.py (включно з plugins/eswf-logistic/logistic/migrations/) → rm db.sqlite3 → makemigrations → migrate → init_instance + init_accounting_data --tenant 1. Дозволене, бо prod-бази немає і розробник один.
  • Профілактика на майбутнє: data-логіку тримати в management commands (seed, init_accounting_data, load_uktzed, seed_shop), а не RunPython усередині міграцій; давати осмислені імена через makemigrations --name; перед першим prod-deploy — фінальний reset, після нього вже тільки squashmigrations з мостами.
  • Нюанс з venv: find <root> -path "*/migrations/*.py" без виключення venv/ знесе також Django stdlib міграції в site-packages. Або виключати -not -path "*/venv/*", або переставляти Django/DRF/simplejwt через pip install --force-reinstall --no-deps.

9.5 Код — god-components

За результатами сканування: - AdminToolsPage.tsx — 1331 рядок - ChatPage.tsx — 1443 - ChatDrawer.tsx — 1290 - SalesFieldManager.tsx — (за audit.md) ~1265 - ETTNPage.tsx — 1077 - DevToolsPage.tsx — 1134

Шаблон антипатерну: один TSX = state + API + бізнес-логіка + UI + i18n. Важко тестувати, рефакторити, ділити.

9.6 Документація самих себе

  • DOCS.md — оглавлення, актуалізовано 2026-04-20. ✅
  • CLAUDE.md — потрібна правка: logistic/ згадано як вбудований Django-app з 3 моделями, насправді це платний плагін (відсутній у community). Треба переписати як 🧩 optional paid plugin.
  • todo.md — 1376 рядків, в частині розділів — застаріле (назва модулів «integrations/», «budgeting/» — не існуючих django-apps).
  • docs/BACKLOG.md — автогенерований. Потрібно регулярно регенерувати (npm run backlog).

10. Покроковий план робіт (for you)

Пріоритет від найпростішого / найдешевшого до складного. P0 = зробити цього тижня, P1 = цей місяць, P2 = квартал, P3 = backlog.

Фаза 0 — Документація (1-2 дні, P0)

Мета: привести doc-sync до реальності, щоб нічого не обіцяло зайвого.

  1. ✍️ Оновити CLAUDE.md:
  2. Переписати logistic/ як 🧩 paid plugin (не входить у community) замість «built-in app з 3 моделями».
  3. Додати essentials_quality/ app (є, але не описаний).
  4. Додати transport/ app (є, але не описаний у розділі «Django Apps»).

  5. Оновити список «15 apps» → 17 apps (без logistic, який є плагіном).

  6. ✍️ Оновити frontend/erp/src/config/applications.ts:

  7. appLogistic.status → available (платний; не «installed»).
  8. appCRM.status → installed (backend + frontend є).
  9. appFleetTrack.status → installed.
  10. appPurchaseInvoice.status → installed.
  11. appQuality.status → installed (за умови активного плагіна).
  12. appAccounting.status → installed (ядро реалізовано в Essentials; розширення — у розробці; уточнити опис).
  13. appCommerce → перейменувати у "E-Commerce Manager", уточнити опис (процес-аддон всередині Essentials — каталог + activation codes + SMTP), status: installed, price: community.

  14. appPortal → уточнити опис "Client Portal" як окремий Next.js-фронтенд (frontend/shop/), status: installed, залежність від appCommerce.

  15. ✍️ Позначити статуси у DOCS.md:

  16. 📋 planned — hrm-payroll, production-bom, budgeting, consolidator, baf-sync.
  17. ⚠️ частково — accounting-tax (ядро є в Essentials), commerce (Store Manager є, headless engine — ні), client-portal (shop frontend є, B2B-розширення — ні).

  18. 💎 paid plugin — logistic.

  19. ✍️ Скорегувати todo.md:

  20. Прибрати застарілі розділи «integrations/», «budgeting/» з backend-блоку.

  21. Додати короткий розділ «Sync with reality» із посиланням на цей аудит.

  22. ✍️ Додати файл eswf/frontends/mobile-sales.md або розширити eswf/frontends/mobile.md деталями mobile-sales/ (23 таблиці, 7 tabs, GPS, signature, photo, push).

Фаза 1 — Backend тести + перевірка plugin-exclusion flow (1-2 тижні, P0)

  1. 🧪 Встановити pytest на бекенді: 

    pip install pytest pytest-django pytest-cov
    Створити backend/pytest.ini + conftest.py з DJANGO_SETTINGS_MODULE=eswf.settings.development.

  2. 🧪 Перші 50 тестів (покрити найкритичніше):

  3. core/tests/test_universal_viewset.py — whitelist sort/filter, pagination ліміти, tenant isolation, 401/403.
  4. core/tests/test_permissions.py — RolePermission, ownership checks.
  5. essentials/tests/test_serializers.py — auto_list_serializer_factory, TenantFilterMixin.
  6. essentials/tests/test_posting.py — проведення Invoice, GoodsReceipt — перевірити регістри.
  7. essentials/tests/test_reports.py — P&L, Balance Sheet, Cash Flow, Payment Calendar (вже реалізовано, треба покрити тестами).

  8. fleet/tests/test_ettn.py — Ed25519 sign/verify.

  9. 🔧 Перевірити plugin-exclusion flow на logistic/ (eталонний кейс для всіх майбутніх платних плагінів):

  10. Backend: переконатися, що _PLUGIN_URLS["logistic"] обумовлено apps.is_installed("logistic") і не реєструється у urls.py.
  11. Backend: API /api/v1/core/active-plugins/ (або аналог) має повідомляти про відсутність logistic.
  12. Frontend: useActivePlugins хук має приховати logisticSection з sidebar (а не показувати «мертві» пункти, що дають 404).
  13. Документувати pattern як «як додати платний плагін» у eswf/infrastructure/plugin-instruction.md.

Фаза 2 — CI/CD + код-гігієна (⏸️ ВІДКЛАДЕНО до переходу на колективну розробку, 2026-04-22)

Рішення: для одного розробника без prod-бази CI/CD дає мінімальну користь — самоперевірка через tsc --noEmit / py_compile / локальний pytest достатня. GitHub Actions + Dockerfile + pre-commit стають критичними коли: - з'являється другий розробник (PR-flow з обов'язковими автоматичними чеками), - або з'являється prod-deploy (потреба в standardized container + auto-rollout). Trigger reactivation: перший зовнішній PR / перший prod-deploy.

  1. ⏸️ GitHub Actions (.github/workflows/ci.yml) — pytest backend, vitest + vite build для ERP, build для portal/news/shop, tsc --noEmit для mobile.
  2. ⏸️ Production Dockerfile + docker-compose.yml — окремо від уже існуючого Dockerfile.demo (single-container demo з SQLite). Production варіант: backend + postgres + redis + nginx.
  3. ⏸️ Pre-commit hooks — ruff (Python) + eslint (TS) на staged-файлах через pre-commit framework.
  4. ✅ Reset міграцій виконано (2026-04-22) — замість squash зроблено повний reset (183 → 19 initial-міграцій). Див. §9.4. Squash не потрібен.

Фаза 3 — Зрілість продукту (1-2 місяці, P1-P2)

  1. ⏸️ Рефакторинг god-components — відкладено (активна розробка, ризик конфліктів):

    • ChatPage.tsx (1443) → контейнер + hooks + ChatBody / ChatSidebar / ChatInput.
    • AdminToolsPage.tsx (1331) → таби з окремими файлами (PluginManager.tsx, AppManager.tsx, ...).
    • ChatDrawer.tsx (1290) → винести WebSocket hook, окремий RoomList.
    • ETTNPage.tsx (1077) → розділити Ed25519-логіку у utils/ettnCrypto.ts, UI у ETTNList.tsx + ETTNForm.tsx.

  2. ✅ Розширення звітів Essentials (2026-04-22) — реалізовано:

    • ✅ Trial Balance (ОСВ) — endpoint /api/v1/essentials/reports/trial-balance/ через агрегат IncomeExpenseJournal + нормалізація по PCG.
    • ✅ P&L drill-down — endpoint /api/v1/essentials/reports/profit-loss/drill-down/ з параметрами prefix + dimension (account / expense_item / business_direction / department).
    • ✅ UA ПСБО Форма 1 — endpoint /api/v1/essentials/reports/psbo-form1/ з mapping PCG → рядки балансу.
    • ⏳ Frontend-обгортки для нових endpoints — buck-log (core logic вже доступна через існуючий ReportViewer).

  3. ✅ Unified PartyLedger (2026-04-22) — реалізовано замість окремих ClientLedger / SupplierLedger:

    • ✅ Модель registers.PartyLedger з полем direction='receivable'|'payable' (одна таблиця замість двох).
    • ✅ essentials/services/posting.py: post_invoice_party_ledger / post_incoming_payment_party_ledger / post_purchase_invoice_party_ledger / post_outgoing_payment_party_ledger + unpost_* + recompute_running_balance (хронологічний running balance).
    • ✅ Автопостинг через Django signals при збереженні транзакційних документів.
    • ✅ API endpoints: /api/v1/registers/ledgers/party/report/ (залишки as_of + фільтр direction), /api/v1/registers/ledgers/party/by-document/ (drill-down по документах клієнта).
    • ✅ Frontend: PartyLedgerReport.tsx — toggle receivable/payable, drill-down panel → переходи до джерельних документів.

  4. ✅ M.E.Doc — повний flow (2026-04-22) — реалізовано:

    • ✅ medoc_exchange.TaxInvoice модель (direction, tax_type, denormalized TINs/totals, erpn_status lifecycle, xml_content).
    • ✅ TaxInvoiceExporter — XML J1201006 (windows-1251, DECLARHEAD + DECLARBODY + line items з fallback на aggregate totals).
    • ✅ build_tax_invoice_from_source() — конструктор TaxInvoice з Invoice / PurchaseInvoice / IncomingPayment, правильно swap TINs для direction='in'.
    • ✅ parse_medoc_xml() + import_as_tax_invoice() — імпорт вхідних ПН, round-trip export → import verified.
    • ✅ reconcile(tenant, erpn_rows) — buckets: matched / amount_mismatch / missing_in_erpn / extra_in_erpn.
    • ✅ parse_erpn_extract(csv_text) — толерантний CSV-парсер (DD.MM.YYYY / YYYY-MM-DD / DDMMYYYY; 1 234,56 / 1234.56).
    • ✅ API: TaxInvoiceViewSet (CRUD + from_invoice / from_purchase_invoice / xml / mark_registered), MedocImportXMLView, MedocReconcileView.

  5. ✅ Backend-тести (2026-04-22) — 26 нових тестів, усі проходять:

    • essentials/tests/test_party_ledger.py — 10 тестів (invoice/payment posting, running balance, report endpoints).
    • essentials/tests/test_reports.py — +10 тестів (Trial Balance, P&L drill-down, PSBO Form 1, leak-prevention).
    • medoc_exchange/tests/test_tax_invoice.py — 6 тестів (builder, XML round-trip, reconciliation, CSV parser).
    • Загалом у проєкті: 84 passing tests (58 існуючих + 26 нових).

Фаза 4 — Нові модулі (квартал+, P2)

  1. 📦 CRM Pipeline History Journal — signal на зміну Deal.stage → запис у журнал. Дашборд «час у стадії».
  2. 💼 Accounting & Tax MVP:
    • FixedAsset + Depreciation.
    • JournalEntry (ручна проводка).
    • TaxInvoice (податкова накладна).
  3. 👥 HRM & Payroll MVP (спочатку — Employee master data + Payroll замість fleet-only driver salary).
  4. 🏭 Production & BOM MVP (якщо є конкретний клієнт з виробництвом).
  5. 📊 Budgeting MVP (після Consolidator або паралельно).
  6. 🔁 BAF Sync MVP — реалізувати per-план у baf-sync.md (етапи 1–5: HTTP-сервіс у BAF + Python-клієнт + маппер + порядок sync).

Фаза 5 — Backlog (P3)

  • 🔮 Logistic / Multimodal Freight & Forwarding (logistic/ app як платний плагін — Vessel, B/L, Shipment Leg).
  • 🔮 Consolidator (intercompany elimination).
  • 🔮 Client Portal — B2B-розширення (statement of account, reconciliation, returns, individual pricing).
  • 🔮 E-commerce engine (окремий headless ecommerce/ app для клієнтів DOP — LiqPay, Nova Poshta).
  • 🔮 BAF Sync.
  • 🔮 VRP (route optimization) для Logistic.

Деталі — див. BACKLOG.md та розділ ## 🔮 Deferred / Ideas у кожному модулі.

11. Чекліст «зробити сьогодні»

  • [x] Переписати у CLAUDE.md logistic/ як 🧩 paid plugin (а не вбудований app).
  • [x] Додати essentials_quality/ і transport/ до списку apps у CLAUDE.md.
  • [x] Оновити status у applications.ts: appLogistic → available, appCRM/appFleetTrack/appPurchaseInvoice/appQuality → installed, appAccounting → installed (core), appCommerce → installed як E-Commerce Manager, appPortal → installed як Client Portal.
  • [x] Позначити статуси у DOCS.md: planned / частково / paid-plugin (див. §10 крок 3).
  • [x] CLAUDE.md — додати чітке розмежування Client Portal (frontend/shop/) ↔ E-Commerce Manager (frontend/erp/src/components/StoreManager/).
  • [x] commerce/README.md + client-portal/README.md — додати блок "Status quo vs Planned extension" на початку.
  • [x] Перевірити useActivePlugins-flow: useFilteredSections фільтрує секції за appCode через installedAppCodes, items — за plugin через activePlugins. Backend _PLUGIN_URLS обумовлено apps.is_installed(). Регресія покрита backend/core/tests/test_plugin_exclusion.py.
  • [x] Створити backend/pytest.ini та встановити pytest-django.

11bis. Прогрес Фази 3 (2026-04-22) + ревізія scope 2026-04-22

Реалізовано за одну сесію (додатково поверх checklist з §11):

Задача Статус Деталі
§10 / 13 — god-components refactor ⏸️ відкладено Ризик конфліктів з активною розробкою; повернемось після Фази 2
§10 / 14 — Звіти Essentials ✅ 2 production + 1 management Trial Balance ✅, P&L drill-down ✅, ПСБО Форма 1 — management layout ⚠️ (не офіційний звіт, див. нижче)
§10 / 15 — Unified PartyLedger ✅ backend + frontend Модель + signals + endpoints + UI PartyLedgerReport.tsx
§10 / 15-bis — PartyLedger ↔ plan-of-accounts sync ✅ додано 2026-04-22 EssentialsModuleSettings.default_*_operation (4 FK) + patch signal-функцій + consistency test TestPartyLedgerMatchesChartOfAccounts
§10 / 16 — M.E.Doc: експорт видаткових ✅ production J1203001/F1203001 — стабільне ядро інтеграції (MVP)
§10 / 16-bis — M.E.Doc: tax invoice lifecycle 🧪 experimental (переглянуто 2026-04-22) TaxInvoice + J1201006 + імпорт + ЄРПН reconciliation реалізовані в коді, але винесені в okремий future-track. Scope MVP інтеграції: DOP експортує видаткові, ПН створюються у M.E.Doc. Див. medoc integration — повернення теми потребує виділеної команди податкового супроводу.
§10 / 17 — Backend-тести ✅ 28 нових 86 passing всього (26 Phase-3 + 2 нових consistency-тести для PartyLedger sync)

Ревізія scope (2026-04-22, після user-review):

Три архітектурних питання, які виникли після Фази 3:

  1. PartyLedger ↔ план рахунків: початково PartyLedger і PostingEntry на рахунку 4100/4000 могли розсинхронізуватись (ledger завжди пишеться, посту на рахунок — тільки при наявності явного BO). Баланси у Balance Sheet/Trial Balance/ПСБО Формі 1 могли не сходитись з баг-листом дебіторки. Виправлено: додано 4 default BusinessOperation-и в settings + fallback-логіка в signal-функціях; consistency покрито тестом. Див. party-ledger.md §3-bis.

  2. ПСБО Форма 1 на європейському PCG: DOP використовує французький PCG (4100/4000/5300/7000), а офіційна ПСБО Форма 1 традиційно базується на українському плані рахунків (361/631/301/701). Вирішено: позначити поточний endpoint /reports/psbo-form1/ як management layout — внутрішній звіт у візуалі ПСБО над європейським PCG. НЕ офіційний документ для ДПС. Офіційне подання — майбутній окремий модуль UA-локалізації (accounting-ua, 🔮 deferred).

  3. Tax invoice lifecycle в DOP: реалізація TaxInvoice + J1201006 + імпорт + ЄРПН reconciliation — вихід за початковий scope інтеграції. Початковий план: DOP експортує лише видаткові накладні, бухгалтер робить податкові в M.E.Doc (податкове законодавство змінюється швидше, ніж DOP-реліз-цикл). Вирішено: experimental-track залишається в коді як «колись-можливо», але не для production без окремої команди податкового супроводу. Див. попередження у medoc.md.

Після цього патчу §12-метрики слід оновлювати так: backend tests: 86 (не 84), ClientLedger/SupplierLedger-прогалину закрито unified PartyLedger-підходом з гарантованим sync до плану рахунків, appMED — production-MVP (видаткові) + experimental-track (податкові, відкладено).

Наступні кроки: - Frontend-обгортки для нових reports endpoints (Trial Balance UI, P&L drill-down dashboard, PSBO Form 1 management view). - Admin UI для EssentialsModuleSettings.default_*_operation (щоб tenant-admin міг одноразово налаштувати дефолтні BO). - Повернення до §10 / 13 (god-components) після стабілізації активних фіч. - 🔮 Окремий future-track: розділення бухгалтерії на accounting-eu + accounting-ua з одночасним використанням обох планів рахунків + доведення ПСБО Форма 1 до офіційної форми. Див. accounting-tax/README.md — Dual chart of accounts. - 🔮 Окремий future-track: tax-accounting в DOP (TaxInvoice UI + виділена команда податкового супроводу).

11ter. Закриття Фази A (2026-04-22)

Перед закриттям фази проведено реверифікацію — виявилось, що більшість пунктів §11 чекліста були тихо закриті у попередніх ітераціях (DOCS.md маркери, Status-quo блоки в commerce/client-portal README, plugin-instruction.md з регресійним тестом test_plugin_exclusion.py 6117 байт). Залишились дрібні правки + один напівзакритий механізм:

Зроблено в одній сесії:

Що Файл Деталі
appMED description уточнено applications.ts:508-511 Production: expense export J1203001/F1203001; experimental (off by default): tax invoices J1201006 + ЄРПН reconciliation. Status залишено available.
appBAFSync.requires виправлено applications.ts:542 Було ["appLogistic"] (логічна помилка) → ["appEssentials"]. BAF-обмін довідниками/документами Essentials, не залежить від Logistic.
Sync-with-reality секція в todo.md todo.md:90 Вже існує — посилання на цей аудит.
EssentialsSettingsSerializer — закриття PartyLedger sync flow essentials/views/essentials_settings.py, AccountingSettings.tsx Модель EssentialsModuleSettings має 4 FK-поля default_sales_operation / default_incoming_payment_operation / default_purchase_operation / default_outgoing_payment_operation (додані 2026-04-22 разом з PartyLedger sync), але сериалізатор їх не експонував — tenant-admin міг налаштувати лише через Django Admin. Виправлено: додано в API + Admin UI.

Чому пункт 4 (default BO в settings UI) важливий: PartyLedger пишеться signal-функціями завжди при проведенні документа, а проводки на 4100 у плані рахунків — лише якщо документ має явний business_operation. Без default-BO у settings tenant-admin отримував би розбіжність між PartyLedger (борги клієнтів) і Trial Balance (нульове сальдо 4100) — і не мав способу це виправити через UI. Після фази A така налаштовність доступна звичайним tenant-admin (без Django Admin).

Все ще лишається для Фази B: - Frontend-обгортки TrialBalanceReport.tsx, ProfitLossDrillDown.tsx, PsboForm1View.tsx для production endpoints, які зробили у §10/14.

11quart. Закриття Фаз D, E, F-1..F-4 (2026-04-22, друга сесія)

Реалізовано в одній сесії після закриття Фаз A та B:

Фаза Що Backend файли Frontend файли Tests
D — CRM Pipeline + analytics PipelineHistoryJournal автозапис при зміні Deal.stage; ActivityLedger автозапис при створенні Activity; 4 analytics endpoints (funnel, stage-duration, win-loss, manager-activity) crm/services/{pipeline_history,activity_ledger}.py, crm/views_analytics.py, перевизначення perform_create/perform_update/perform_destroy у crm/views.py SalesFunnelDashboard.tsx, ManagerActivityDashboard.tsx +11
E — JournalEntry + FixedAsset MVP JournalEntry+JournalEntryLine — ручні проводки з валідацією Σ Дт=Σ Кт + post/unpost; FixedAsset+DepreciationEntry — 3 методи амортизації (linear/accelerated/none), idempotent monthly run; settings extension з 4 default-BO essentials/models/{journal_entry,fixed_asset}.py, essentials/services/{journal_entry,depreciation}.py, essentials/views/accounting_extra.py JournalEntryPage.tsx, DepreciationRunner.tsx +19
F-1 — HRM & Payroll MVP Новий backend app hrm/ — Position/Employee/PayrollPeriod/PayrollSlip; service compute_slip + post_slip (4 PostingEntry: gross + tax withholding) backend/hrm/{models,services,views,serializers,urls,apps}.py generic MasterDataPage/TransactionPage через config hrm.ts; appManager → installed +9
F-2 — Production & BOM MVP Новий backend app production/ — BOM+BOMLine+WorkOrder; service complete_work_order (consumption: Дт COGS / Кт inventory + production: Дт inventory / Кт output_account) backend/production/{models,services,views,serializers,urls,apps}.py generic CRUD через config production.ts; новий appProduction → installed +7
F-3 — BAF Sync MVP Новий backend app baf_sync/ — BAFSyncSettings/BAFEntityMapping/BAFSyncLog; pluggable BAFTransport + FakeTransport для тестів; dry-run за замовчуванням; push для clients і invoices backend/baf_sync/{models,services,views,serializers,urls,apps}.py BAFSyncPage.tsx (settings + manual triggers + history); appBAFSync → installed +7
F-4 — Budgeting MVP Новий backend app budgeting/ — Budget+BudgetLine (per (year, version, organization)); compute_variance агрегує IncomeExpenseJournal по тому ж account+month → Plan vs Actual JSON backend/budgeting/{models,services,views,serializers,urls,apps}.py BudgetVarianceReport.tsx; generic CRUD для Budget+BudgetLine через budgeting.ts; appBudgeting → installed +4

Архітектурний приниципи дотримано: - Pattern explicit posting functions (без django.dispatch), узгоджено з рештою кодової бази (essentials/services/posting.py). - Кожен сервіс idempotent (re-call replaces previous PostingGroup). - Кожен MVP — мінімальні моделі + повноцінні тести + frontend (де generic не вистачає — спеціальні pages). - BAF Sync через pluggable transport — реальний HTTP-клієнт додається без змін у service-логіці.

12. Метрики (стан на 2026-04-22, друга сесія)

Метрика Значення
Backend apps (реальні) 21 (+4: hrm, production, baf_sync, budgeting)
Backend tests (проєктні) 143 passing (з 0 → 143 за 2 сесії: 86 base + 11 CRM + 19 JE/FA + 9 HRM + 7 Production + 7 BAF Sync + 4 Budgeting)
Frontend ERP tests 80
Frontend ERP lines ~70,000 (+5K Phase D-F components)
Mobile apps 2 (driver + sales), 0 tests
Міграції БД 23 (initial-mass, без data-міграцій)
Документи в docs/ ~60 md-файлів
Повністю planned (немає коду) 1 (consolidator — intercompany elimination)
Частково реалізовано — ядро є, розширення planned 3 (accounting-tax core; commerce як E-Commerce Manager; client-portal як frontend/shop/) + (НОВЕ) 4 нові MVP-модулі: HRM (без Timesheet/KPI), Production (без WIP costing), BAF Sync (mock-transport, реальний httpx — окрема ітерація), Budgeting (без consolidation)
Платні плагіни (поза community) 1 — logistic
Звіти Essentials (P&L, BS, CF, PaymentCal, TrialBalance, P&L Drill-Down, ПСБО Form 1) ✅ 7 reports (фронти готові: ProfitLossReport, BalanceSheetReport, CashFlowReport, PaymentCalendarPage, TrialBalanceReport, PnlDrillDownReport, PsboForm1Report) + PartyLedgerReport
CRM analytics ✅ SalesFunnelDashboard + ManagerActivityDashboard
God-components (≥1000 рядків) 6 (без змін, refactor відкладено)

Пов'язане

  • DOCS.md — оглавлення документації
  • eswf/architecture/audit.md — попередній архітектурний аудит (2026-03-26)
  • todo.md — загальний backlog
  • BACKLOG.md — агрегат ## 🔮 Deferred-секцій
  • CLAUDE.md — контекст для Claude Code

Наступний аудит рекомендовано провести після закриття Фази 0 (приведення документації до реальності) — приблизно через 2 тижні.