A1 · Fixed fee — de la fixed_amount la factură

O singură dată · la vânzarea serviciului

În fluxul A1 istoric, se alegeau assetul (clientul se deriva din el, nu se alegea separat), departamentul (grupul se deriva din el) și billing type-ul Fixed fee (A1). Singurul parametru de preț era suma lunară fixă. Numele serviciului nu se scria — se compunea.

Tracer bullet-ul istoric folosea ruta contextuală /t/{tenantId}/digital-assets/{digitalAssetId}/services/fixed-fee/new: un formular minim A1, fără supplier, care persista prin FixedFeeServiceCreator. După redirect, Digital Asset afișa un panou minim Services cu departamentul, tipul, suma fixă și planning-ul. Rândurile erau ordonate după statusul efectiv: întâi active, apoi pe pauză, apoi închise; departamentul și data creării rămâneau departajarea în interiorul fiecărui grup. Fiecare rând ducea la pagina read-only /t/{tenantId}/services/{serviceId}, unde se verificau identitatea serviciului, pricing-ul A1, orele planificate și faptul că serviciul labor apărea ca No supplier. Aceeași pagină păstra pricing-ul de setup ca default și îl putea edita separat prin Edit defaults (fixed_amount și planning_hours). Excepțiile lunare stăteau pe rândul perioadei: o lună ready, dar nefacturată, putea fi ajustată dintr-un drawer de period cu sumă manuală și motiv obligatoriu. Programarea finalului folosește Schedule end / Change end date și formularul Last active day, care poate seta, schimba sau șterge end_date ca ultima zi activă, inclusiv; nu există status persistat closed. O dată viitoare afișează Scheduled to end, serviciul rămâne activ până la sfârșitul acelei zile și devine Closed în ziua următoare. Ultima lună nefacturată se recalculează după zilele eligibile, perioadele ulterioare se elimină, iar orice conflict cu date facturate sau cu input uman blochează salvarea. După închiderea efectivă, setup-ul, pricing-ul și perioadele rămân istoric read-only. Pauza temporară folosește Pause service / Resume service și salvează în service_pause date calendaristice exacte: paused_from și paused_until, ambele inclusive. Formularele folosesc Paused from, Last paused day și prima zi activă Resume on. Pauza oprește simultan livrarea și billing-ul. O lună complet suspendată primește service_billing_pause și nicio perioadă; o pauză parțială păstrează perioada cu baza auditabilă billable_days / calendar_days. „Resume on 20 August” înseamnă că ultima zi suspendată salvată este 19 August. Reluarea în chiar prima zi programată anulează pauza prin traseul auditat de corecție. O pauză planificată cu final, dar fără actor de reluare, poate fi încă schimbată; o pauză anulată sau deja reluată rămâne audit imuabil. Toate Dashboard-ul păstrează un tabel de audit cu intervalele scheduled/current/completed/cancelled, Resume on, actorii și motivele. Perioadele arată intervalul calendaristic, baza billable_days / calendar_days și ecuația din snapshot_pricing_fixed_amount. Suma fixă folosită este persistată pe perioadă, deci schimbarea default-ului nu rescrie auditul; rândurile legacy facturate fără baza sau inputul original afișează Historical calculation. Toate scrierile derivate din calendar folosesc același coordinator: setup, editarea pricing-ului cu recalcularea lunilor deschise, pause/resume/cancel, service end, generator/reconciler și recompute/reopen/close/override de perioadă. Operația exterioară deschide o singură tranzacție proprie și refuză să adopte o tranzacție DBAL externă deja activă. Blochează pesimist rândul Digital Asset comun și reîncarcă o singură dată Service-ul și rândul financiar direct înainte de citirea stării mutabile. Operațiile imbricate pe același coordinator refolosesc lock-ul și refresh-ul și lasă flush/commit limitei exterioare. Astfel, un writer cu o perioadă stale nu poate suprascrie o reconciliere de calendar deja comisă, iar batch-urile își păstrează un singur flush. Query-urile canonice reîncarcă rândurile existente fără să piardă rândurile încă programate în UnitOfWork. Metodele engine-ului care primesc coverage și metodele mutante ale reconcilerului sunt inner-only și verifică runtime că Digital Asset-ul Service-ului este blocat în scope. Sub MariaDB REPEATABLE READ, batch-ul capturează candidații înaintea tranzacției, deduplică și sortează Digital Asset-urile după UUID, apoi le blochează pe toate înainte de callback, refresh sau orice consistent read; altfel primul SELECT ar fixa un snapshot care poate ascunde un pause/pricing commit ulterior. Fiecare limită exterioară îngheață setul declarat de Digital Asset-uri imediat după lock-uri și înainte de primul refresh, read sau callback. Operațiile imbricate pot refolosi numai asset-uri din setul înghețat; un asset omis este respins înainte de orice lock, refresh sau work suplimentar care ar putea inversa ordinea lock-urilor. Batch-ul este outermost și îngheață setul complet sortat și deduplicat înainte de work. Un batch gol îngheață un set gol și respinge asset work imbricat; setul se elimină la ieșirea din limita exterioară, inclusiv după excepții. Comenzile per-Service precolectează perechea de ID Service/Digital Asset, deschid tranzacția, obțin o referință Digital Asset fără SELECT, o blochează și abia apoi încarcă Service-ul fresh. Emiterea facturii și fluxurile financiare F1 vor adopta același protocol când vor fi implementate. Schimbările de calendar reconciliază doar lunile nefacturate și nu șterg niciodată în tăcere pontaje, inputuri, linii sau override-uri. Reconcilierea post-migrare verifică înainte de orice mutație UnitOfWork: coverage zero nu poate șterge un override manual sau o linie deliverable user-owned, iar coverage zero/parțial nu poate exclude pontaje datate. La save, FixedFeeServiceCreator pornea generatorul pentru lunile eligibile, așa că un A1 cu invoice_start_date în luna curentă se năștea deja cu perioada ready. Din aceeași pagină se putea reporni manual generatorul idempotent doar după ce luna curentă ajungea la invoice_start_date; înainte de acea lună acțiunea nu apărea, iar POST-ul direct era respins fără rând lunar sau skip. Se vedeau rândurile lunare cu state, suma clientului, labour și net profit snapshot. Drawerul complet cu toate tipurile rămânea pasul următor.

1 august · automat

Un generator lunar calculează mai întâi acoperirea calendaristică exactă. Creează service_billing_period dacă rămâne cel puțin o zi facturabilă; numai când o pauză elimină toate zilele eligibile creează service_billing_pause. Intervalele de pauză anulate sunt ignorate. Entry point-ul operațional este app:billing:generate-periods, cu --tenant=<uuid> pentru rulare pe un tenant și --month=YYYY-MM pentru generare până la luna respectivă. Comanda este idempotentă: rerun-ul nu dublează perioadele și nu emite facturi. Acțiunea manuală de pe Service detail urmează aceeași regulă de eligibilitate și apare numai din luna invoice_start_date. După migrarea calendarului exact, app:billing:reconcile-calendar completează doar lunile A1 deja reprezentate; nu generează istoric nou și nu recalculează perioade invoiced. Migrarea rulează prima, reconcilierea a doua, apoi generatorul normal. Pentru A1 nu există nimic de introdus și suma nu depinde de ore, dar componenta fixă se proratează cu billable_days / calendar_days într-o lună parțială, așa că rândul se naște direct ready: strategia rulează la creare și sumele facturabile îngheață pe loc. (A1 e singurul cu privilegiul ăsta — la A2/B factura depinde de orele lunii, deci perioada lor se naște cost_entry.)

Pe parcursul lui august

Factura A1 e fixă, dar profitul nu e — depinde de cât timp consumă echipa. Orele se loghează pe task-urile serviciului; costul intern e per angajat, din payroll (cost/h efectiv la data pontajului). După fiecare pontaj, engine-ul actualizează snapshot_labour_cost, iar DB-ul recalculează singur netul.

1 septembrie · batch lunar

Fluxul ghidat de facturare (clienți → assets → servicii → generate) adună toate perioadele ready din august ale clientului și produce o factură per client, cu câte o linie per serviciu. Linia noastră vine direct din snapshot — nimic nu se recalculează.

Oricând după aceea

Profitabilitatea pe serviciu / client / agenție e un SUM peste rândurile de perioadă — cifrele au fost înghețate la momentul potrivit, deci raportul e stabil istoric și nu re-rulează nicio strategie.