Una

User accounts, sessions, roles and password resets.

Multi-tenant directory with tenants and organizations.

Shared configuration storage and helpers for module settings.

User-defined entities, custom fields, and dynamic records storage.

Hybrid query layer with full-text and vector search capabilities.

Auto-generated documentation for all HTTP endpoints.

Tracks user actions and data accesses with undo support scaffolding.

In-app notifications with module-extensible types and actions.

Configurable admin dashboard with module-provided widgets.

File attachments and media management.

Event bus and subscriber dispatch

Kanoniczni odbiorcy gazu (Klient). Likwidują placeholder-UUID w hubach (energy_master_data), umowach (contracts) i fakturach (billing) gazowego MVP UNA — luźny FK po UUID, bez relacji ORM między modułami.

Kanoniczna hierarchia Klient → Hub → PointOfDelivery (PPG) → Licznik. Bitemporalne przypisania PPG ↔ klient/OSD/grupa taryfowa oraz licznik ↔ PPG. Fundament danych podstawowych gazowego MVP UNA (ADR-D10).

Transport SFTP/platforma OSD gazowego (PSGaz): ingest odczytów pomiarowych + dwukierunkowa wymiana komunikatów switchingu. Domyka audyt F1 §4 — wspólny konektor dla metering (DAT-002) i switching (DAT-003). DG1: tylko OSD gazowy SFTP, nie CSIRE/AS4.

Import danych pomiarowych OSD, VEE (walidacja/estymacja), konwersja m³→kWh (Wk per obszar OSD), niemutowalna migawka MeteringDataSnapshot, okresy rozliczeniowe, Correction Case. Rdzeń gazowego MVP UNA (REQ-001–REQ-012, DG2).

Indeksy cen rynkowych gazu (TGE/TTF/NBP) i governance publikacji fixingów. Dane wejściowe dla formuł indeksowanych w module pricing (REQ-005, REQ-013). Standalone OM, ADR-D12.

Taryfy gazowe (Sprzedawca + OSD pass-through), formuły cenowe (fixed/indexed TGE/TTF), RatingService deterministyczny, snapshoty wyceny i kalkulacja marży. Blok 2/6 Data Master UNA (ADR-D12).

CLM umów sprzedaży gazu (Blok 3 Data Master). Contract + ContractVersion + bitemporalne assignments (PPG, produkt, cena, security), PoA + Signatory, kalendarz operacyjny, aneksy/wypowiedzenia/przedłużenia, take-or-pay. Trigger switchingu przez contracts.ppg.added (audyt F1 P-04).

Moduł billing — Invoice/KSeF/akcyza/VAT/korekty + FI-CA balance (P-01). Blok 6 Data Master: meter-to-cash, BillingRun/BillingBatch/BillingDataPackage, KsefSubmission (FA(3) MVP mock), TaxBreakdown, CorrectiveInvoice, BillingAccount + Receivable + CustomerBalance (właściciel salda). Saga meterToCash = Temporal Tier 1 (om-temporal-saga — odrębny agent).

Moduł payments — MT940 import, auto/manual matching, N:M allocation (partial/overpay), virtual accounts (PAT-001), online payments (payment_gateways FK), overdue detection. Blok 7 Data Master: order-to-cash domknięcie po stronie pieniądza. P-01: Receivable + CustomerBalance = właściciel billing; payments emituje payments.payment.matched → billing aktualizuje saldo (P-07). P-05: wszystkie event IDs 3-członowe.

Zmiana sprzedawcy gazu przez OSD gazowy (NIE CSIRE — ADR DG1/0005). Blok 4 Data Master (4H–4P). SwitchingCase (per PPG) + SwitchingPackage (4J, częściowa akceptacja) + SwitchingRequest do OSD przez connector_osd_gaz, odczyt graniczny z metering (P-03, 4K), SLA monitoring (4L), rezygnacja/ponowienie (4M/4N), sprzedaż rezerwowa (4P). Trigger: contracts.ppg.added (P-04). PoA fail-closed (REQ-007, AC-002). Saga switchingWorkflow → om-temporal-saga agent (lib/saga/** intentionally NOT here).

Transport MT940 z banku przez SFTP/H2H: pobieranie wyciągów, parsowanie do kanonicznego BankStatement DTO, emisja eventu connector_bank.statement.imported. Zastępuje mock importu MT940 w module payments (SVC-001). Gaz MVP — tylko inbound MT940, bez payouts/settlement.

MOCKUP seam — eksport zaksięgowanych faktur z billing do zewnętrznego programu księgowego (ERP). Transport STUB: adapter zapisuje postingi do AccountingPostingLog ze statusem MOCKED, bez realnego połączenia. TODO: podłącz AccountingAdapter.send() do właściwego API programu księgowego.

Windykacja należności — DunningCase/Policy/Level/Step/Letter. Konsumuje payments.receivable.overdue → otwiera sprawę windykacyjną. Eskalacja przez Tier 2 USER_TASK (ReactFlow/OM workflows). Emituje dunning.case.opened / dunning.case.escalated / dunning.case.closed. PII w pismach przez TenantDataEncryptionService.