PRD: Iris MVP — versiunea manuală

10 Iulie 2026 · Draft v1 · BONO × SOLO · Confidențial Owner: BGN · Input: PRD Iris v2 (12 mai), PRD Larry + Adam final (Cristi, 8 iun), decizii BGN (11 iun + 10 iul)

---

1. Rezumat

Nevoie: documentele justificative ale clienților finali (facturi, bonuri, extrase) trebuie transformate în note contabile gata de postat, într-un sistem centralizat multi-tenant. Azi asta se face dispersat și manual în sistemele fiecărui tenant.

Decizie de secvențiere (BGN, 11 iun): construim întâi Iris operat integral de om — operatorul face conspectarea, gruparea, interpretarea și deciziile contabile de mână, pe aceeași suprafață care în Faza 2 va fi pre-completată de Castor/Larry/Adam. Faza manuală definește modelul de date, nota contabilă și granițele dintre motoare, și produce dataset-ul de evaluare pentru automatizare.

Ce este Iris în Faza 1: un serviciu multi-tenant care primește documente + context prin API de la tenanți, le pune într-o coadă de lucru pentru operatori umani, și returnează note contabile prin API către tenant.

Ce NU este: nu are OCR, nu are AI, nu are scoruri de încredere, nu are Zero-Touch. Singurele automatisme permise sunt cele pur deterministe și ieftine: deduplicare hash, interogări ANAF/BNR, aritmetica valorilor contabile (calc spreadsheet, nu decizie).

---

2. Decizii de bază (confirmate BGN, 10 iul)

---

3. Actori și joburi

---

4. Fluxul documentului (end-to-end)

1. Tenantul trimite POST /documents: fișier + tip + context client + idempotency key
2. Iris verifică: idempotență, dedup hash (per tenant), validare payload
   → duplicat identic = respins imediat, tenantul notificat
3. Documentul intră în coada tenantului cu status "primit"
4. Operatorul îl deschide → status "în conspectare"
   4a. CONSPECTARE: verifică/completează câmpurile documentului pe formularul
       specific tipului (datele vin goale în Faza 1 — operatorul le introduce
       citind documentul afișat alături)
   4b. Iris rulează automat: interogare ANAF (partener), curs BNR (dacă valută),
       dedup semantică (nr doc + dată + CUI + sumă → flag "posibil duplicat")
5. GRUPARE: operatorul grupează/splituiește liniile în tranzacții
   (default: toate liniile cu tratament identic = o tranzacție)
6. INTERPRETARE per tranzacție: operatorul alege categoria (taxonomie globală)
   + folosința în firmă (DA/NU)
7. DECIZII CONTABILE per tranzacție: operatorul confirmă scenariul TVA și
   deductibilitatea; sistemul precompletează determinist din reguli (§8) și
   calculează aritmetica (baze, valori ded/neded, conturi din TAC)
8. NOTĂ CONTABILĂ: preview per tranzacție → operatorul finalizează documentul
9. Iris trimite nota/notele prin webhook către tenant + le expune pe GET
10. Documentul devine "finalizat"; audit trail complet păstrat

---

5. State machine

Document

Statusuri expuse tenantului prin API: primit · în procesare (= în lucru/așteptare) · finalizat · respins (cu motiv). Detaliul intern nu se expune.

Tranzacție

Reguli: un document nu poate fi finalizat cu tranzacții în draft. O tranzacție se poate redeschide cât timp documentul nu e finalizat. Corecțiile după export = out of scope MVP (marcat TBD — vezi §13).

ID-uri

• Document: {TENANT}-{AN}-{NNNNN} (ex: BN-2026-00042) — secvență per tenant
• Tranzacție: {ID-document}-T{n} (ex: BN-2026-00042-T2)
• Nota contabilă moștenește ID-ul tranzacției

---

6. Contracte API

6.1 Ingestie — POST /documents (tenant → Iris)

request_id, idempotency_key
tenant_id (din autentificare — cheie API per tenant)
source_document_id        // ID-ul documentului în sistemul tenantului
document_type             // efactura_xml | factura_pdf | bon | factura_externa
                          // | factura_emisa_json | extras_cont
file                      // binar sau URI semnat
client_context            // snapshot complet (vezi 6.3)
callback_url              // opțional, override per document

Răspuns: iris_document_id, status inițial. Erori: duplicat (cu referința documentului existent), payload invalid, tip nesuportat.

6.2 Output — webhook document.finalizat + GET /documents/{id}/notes

iris_document_id, source_document_id, status
transactions[]: {
  transaction_id, source_line_ids[],
  // CONSPECTARE (introduse de operator)
  descriere, cantitate, valori (netă / TVA / totală / valută+curs),
  // CONTEXT folosit
  context_snapshot_id, partener (date ANAF),
  // INTERPRETARE (decise de operator)
  categorie {cod, nume, grupa}, folosinta_firma,
  // DECIZII CONTABILE
  scenariu_tva, ded_ch_pct, baza_tva, baza_ch, val_ded_ch, val_neded_ch,
  tac {cheltuiala, tva}, conturi {debit, credit, tva_debit, tva_credit},
  flags[], comentarii_operator,
  // AUDIT
  operator_id, timestamps, ruleset_version
}

Structura e identică cu cea din Faza 2 — singura diferență va fi apariția câmpurilor de confidence și model_versions. Tenantul integrează o singură dată.

6.3 Contextul clientului — câmpuri și surse

\* dacă lipsesc, regulile R3/R4 nu pot precompleta — operatorul decide și marchează lipsa; lipsa apare în audit. Câmp lipsă ≠ blocare (principiu din PRD v2).

Contextul se salvează ca snapshot imutabil per document (context_snapshot_id) — decizia contabilă e auditabilă față de contextul de la momentul procesării, nu față de profilul curent.

6.4 Interogare status — GET /documents/{id} (tenant → Iris)

Status simplu + istoricul tranzițiilor.

---

7. Modelul de date

Tenant        — id, nume, chei API, callback_url, operatori
Client        — firma clientului final (per tenant), profil = ultimul context primit
Document      — id, tenant, client, tip, fișier (storage per tenant), hash,
                source_document_id, status, operator curent, timestamps
ContextSnapshot — imutabil, per document
DocumentLine  — linia brută introdusă de operator la conspectare
Transaction   — grup de linii; interpretare + decizii contabile; status
NotaContabila — output final per tranzacție (structura 6.2)
AuditEntry    — cine, ce câmp, valoare veche → nouă, când (write-once)
RulesetVersion — versiunea taxonomiei + regulilor active la procesare

Stocare: documentele și datele de procesare, izolate per tenant, retenție 12 luni de la finalizare (parametru global). După retenție: ștergere, cu notă în audit. Stocarea permanentă = responsabilitatea tenantului (arhitectura permite mutarea ownership-ului la un viitor modul de documente — „Findocs" în propunerea Prodi — fără schimbarea contractelor).

---

8. Reguli contabile în varianta manuală (asistare deterministă)

Sursa: PRD Adam final (8 iun, Cristi). În Faza 1 regulile NU rulează ca motor autonom — ele precompletează câmpurile, operatorul confirmă sau modifică (orice modificare cere motiv, logat în audit).

Taxonomia (globală, ~50 categorii în 8 grupe): AUTO (A1–A13) · SEDIU (B1–B7) · PERSONAL (C1–C9) · BIROU & ADMINISTRATIV (D1–D10) · IT & SOFTWARE (E1–E5) · SERVICII EXTERNE (F1–F8) · FINANCIAR (G1–G4) · ASOCIAT (H1). Fiecare categorie cară: cod, nume, descriere, grupă, TAC, deductibilitate default.

Reguli de deductibilitate (precompletare):

• R1: Folosinta_Firma = NU → Ded_Ch% = 0% (prioritate maximă)
• R2: categorii de transfer/patrimoniu (A1, A2, A3, C3, D3, E1, E2, F8…) → Ded_Ch% = N/A (amortizare la Engine Contabil, la tenant)
• R3: grupa AUTO → după Regim_Auto (Fara=0% / Mixt=50% / 100%=100%)
• R4: B2–B6 → după Activitate_La_Sediu (DA=100% / NU=0%); B1 chirie mereu 100%
• 0% fix: A12, D8, D9, D10, H1 · restul: 100%

Scenariile TVA (precompletare din date): NO-TVA (~80%) · TVA-SERV (~10%, taxare inversă servicii, D 635 → C 4423) · TVA-AIC_BUNURI (~5%) · TVA-IMP_BUNURI (<1%, mereu manual — DVI introdus de operator). Validări globale G1–G3 (VIES invalid → manual; achiziție externă >2.000 EUR → alertă; bun extern din categorii speciale → manual) rulează ca atenționări pentru operator.

Prag mijloc fix 5.000 RON: reclasificare automată sugerată (R1-Adam: categorie MF sub prag → D2 cu comentariu; R2-Adam: D2 peste prag → flag verificare).

Aritmetica (automată, needitabilă decât prin schimbarea inputurilor): Baza_ch, Baza_TVA, Val_ded_ch, Val_neded_ch conform formulelor per scenariu.

Taxonomia + regulile au versiune globală (ruleset_version), stampilată pe fiecare notă.

---

9. Ecrane

E1 — Coada de documente

• Actor: Operator (tenantul lui) / Admin
• Job: „ia următorul document de procesat și vezi starea cozii"
• Informații: ID, client final, tip document, dată primire, status, operator, flag duplicat semantic; filtre pe status/tip/client; contoare per status
• CTA: deschide documentul (claim automat)
• Stări: normal · empty („nicio procesare în așteptare") · documente în așteptare evidențiate

E2 — Conspectare (formular per tip de document)

• Actor: Operator
• Job: „transcrie fidel documentul în date structurate"
• Layout: split-screen — stânga preview document (PDF/imagine/XML randat), dreapta formularul tipului
• Formulare (6): eFactură (câmpuri pre-populate din XML — parsare = randare, nu motor) · Factură PDF/imagine · Bon fiscal · Factură externă (+ valută, curs BNR precompletat, mențiuni taxare inversă) · Factură emisă (pre-populată din JSON) · Extras de cont (model diferit: listă de operațiuni eterogene, fiecare operațiune = potențială tranzacție — formular de detaliat la prototip, §13)
• Informații comune: metadate document + linii (descriere, cantitate, UM, preț, valori, cotă TVA, mențiuni per linie) + panou context client (cu evidențierea câmpurilor lipsă) + rezultatul ANAF pe partener
• CTA: „Continuă la tranzacții"
• Stări: verificare identitate cumpărător (CUI factură ≠ CUI firmă → atenționare „posibil pe persoană fizică") · duplicat semantic → banner cu link la documentul similar

E3 — Grupare în tranzacții (pas în E2 sau ecran propriu)

• Actor: Operator
• Job: „împarte liniile în grupuri cu tratament contabil identic"
• Comportament: default toate liniile într-o tranzacție; split/merge cu drag sau selecție; recalcul automat al valorilor per grup; discount/transport alocate proporțional pe liniile selectate
• CTA: „Confirmă tranzacțiile (N)"

E4 — Interpretare + decizii contabile (per tranzacție)

• Actor: Operator
• Job: „decide ce e cheltuiala asta și cum se tratează fiscal"
• Informații: liniile tranzacției · selector categorie (căutare în taxonomie, cu descrieri) · folosință DA/NU · scenariu TVA precompletat + motivul precompletării · deductibilitate precompletată + regula aplicată (ex: „50% — R3, Regim_Auto = Mixt") · valorile calculate live · flags (G1–G3, prag MF)
• CTA: „Generează nota"
• Stări: categorie negăsită → „Altă categorie" + comentariu obligatoriu → documentul rămâne procesabil dar marcat pentru analiza taxonomiei

E5 — Notă contabilă (preview + finalizare)

• Actor: Operator
• Job: „verifică nota finală înainte să plece la tenant"
• Informații: nota completă (structura 6.2) per tranzacție; sumar document: „N tranzacții → N note"
• CTA: „Finalizează documentul" → export automat

E6 — Lista tranzacții

• Actor: Operator / Admin Tenant
• Job: „găsește o tranzacție anume și vezi istoricul ei"
• Informații: ID corelat, document-mamă, client, categorie, valoare, status, operator; pagina tranzacției = tot istoricul + audit
• Stări: filtre pe status/categorie/client/perioadă

E7 — Administrare

• Actor: Admin Iris (tot) / Admin Tenant (subset read-only + operatorii lui)
• Job: „administrează tenanții, utilizatorii și regulile"
• Informații: tenants + chei API + callback · utilizatori/roluri · taxonomia și regulile (read-only, cu versiune) · parametri globali (retenție, prag MF)

---

10. Parametri configurabili

---

11. SRL vs PFA

• Conspectarea: identică (decizie BGN).
• Interpretarea: aceeași taxonomie și aceleași decizii (categorie, folosință, scenariu TVA); diferă outputul notei: SRL → conturi în partidă dublă (TAC → debit/credit); PFA → categorii generale de cheltuială/venit + deductibilitate, fără conturi.
• ⚠️ TBD (Cristi): tabelul de mapare categorie → tratament PFA (echivalentul anexei Adam pentru PFA) — materialul existent e SRL-only. Blocant pentru finalizarea formularului E4 pe clienți PFA, nu pentru restul PRD-ului.

---

12. Non-goals (explicit NU în Faza 1)

Pregătit în arhitectură pentru Faza 2: câmpurile de confidence în modelul de date (nullable) · ruleset_version de la început · contractele API neschimbate · fiecare decizie de operator = pereche (input, decizie) exportabilă ca training/eval data.

---

13. Întrebări deschise (TBD)

1. Formularul de extras de cont — model de date diferit (operațiuni eterogene: comisioane, plăți, încasări, fără TVA). De definit la prototip. *(Owner: BGN + Cristi)*
2. Maparea PFA la interpretare/notă (§11). *(Cristi)*
3. Corecții post-export — dacă tenantul găsește o eroare după primirea notei, care e fluxul? Propunere: v1.x, eveniment note.corrected. *(BGN + Prodi)*
4. Autentificare API — chei statice per tenant sau OAuth client credentials? Propunere: chei per tenant în MVP. *(Prodi)*
5. Alerta G2 (achiziții externe >2.000 EUR) — email zilnic din Iris sau responsabilitatea tenantului? *(Prodi + Cristi)*
6. Alocarea discount/transport — proporțional pe valoare netă? Confirmare formulă exactă. *(Cristi)*

---

14. Metrici de succes

---

15. Integrări

Fără migrare de date — sistem nou.