Product Requirements · Flux contabil end-to-end

PRD — Flux contabil: operațiunile pe care SAGA nu le face automat

Decizii, opțiuni și soluții pentru pașii marcați „de decis” în documentul Flux contabil end-to-end.

Obiectiv: definește CE trebuie să facă sistemele Bono pentru operațiunile contabile pe care SAGA nu le face automat sau pe care nu le-am automatizat încă, ca bază pentru decizia de arhitectură: cine calculează (IRIS, Lotus, un engine contabil lângă Nucleu sau un robot în SAGA) și cine trimite nota contabilă în SAGA.

Sursa: ședința „review Flux contabil end-to-end” din 23 octombrie 2026 (Bogdan, Cristi, Otilia, Raluca) — minuta — și ședința din 20 octombrie 2026 — minuta.

Cum e organizat documentul: fiecare caz are aceeași structură — Pașii din flux, Context, Ce trebuie să facă sistemul, Opțiuni, Soluția propusă, Decizii și De verificat. Secțiunea 8 compară variantele de arhitectură care apar în toate cazurile. Fiecare secțiune are propriul link (#sec-N), ca să poată fi trimisă separat.

Sisteme menționate: IRIS conspectează documentele (facturi, extrase, contracte) și produce note contabile; Lotus leagă plățile din extras de facturi; Nucleu ține datele firmei (facturi, extrase, balanțe); Vertigo este unealta internă de administrare a firmelor; Dublin este aplicația clientului; SAGA este programul de contabilitate în care ajung notele, prin import XML sau prin roboți care apasă butoane.

Changelog document#

1. Diferențe de curs valutar la plata / încasarea facturilor în valută#

Pașii din flux:

• B13.1 Calcul diferențe de curs valutar la plată / încasare
• B13.2 Înregistrare note contabile de diferențe de curs valutar

Frecvență: des (lunar, la orice firmă cu facturi în valută).
Stare: de decis — propus: engine contabil lângă Nucleu, cu notă contabilă importată în SAGA.

Context

O factură în valută se înregistrează în contabilitate în lei, la cursul BNR din data facturii. Când factura se plătește sau se încasează la o altă dată, cursul e altul, iar diferența dintre cele două sume în lei trebuie înregistrată ca venit sau cheltuială din diferențe de curs. La importul XML-urilor de încasări și plăți, SAGA nu calculează automat aceste diferențe și nu le înregistrează pe cheltuială sau venit.

Ce trebuie să facă sistemul

1. Să știe ambele sume în lei: valoarea facturii la cursul din data facturii și valoarea plății la cursul din data plății. Pentru asta are nevoie de legătura plată ↔ factură, pe care o face Lotus.
2. Să calculeze diferența pe fiecare pereche factură – plată sau factură – încasare, inclusiv la plăți și încasări parțiale.
3. Să genereze nota contabilă și să o trimită în SAGA prin import, odată cu notele lunii:
   • 665 = 5121.01 sau 5124.xx — diferență nefavorabilă la încasare sau plată;
   • 5121.01 sau 5124.xx = 765 — diferență favorabilă la încasare sau plată.

Nota contabilă nu are nevoie de robot: SAGA o importă ca pe orice notă normală. Singura întrebare rămasă este ce sistem știe cele două informații și generează nota.

Opțiuni

Soluția propusă

Calculul se face în afara SAGA, pe baza legăturii plată ↔ factură din Lotus, într-un engine contabil lângă Nucleu (opțiunea B); dacă decizia de arhitectură va fi ca IRIS să preia calculele (opțiunea A), fluxul rămâne același, doar locul calculului se schimbă. În ambele variante rezultatul este o notă contabilă standard trimisă în SAGA prin import, în fișierul de note al lunii, cu data plății. Robotul în SAGA (C) rămâne doar ca fallback.

Decizii

• Diferența de curs se trimite în SAGA ca notă contabilă normală, nu prin închiderea facturii în SAGA.
• Alegerea sistemului care calculează se face împreună cu cazurile 2–7, după analiza din secțiunea 8.

De verificat

• Plăți parțiale și plăți care acoperă mai multe facturi: regula de alocare din Lotus.
• Plată dintr-un cont în altă valută decât factura (factură în USD plătită din contul EUR): cursul de referință al fiecărei părți.

2. Bonuri fiscale plătite din bani personali#

Pașii din flux:

• B12 Reconciliere plăți și încasări
• B15 Închiderea bonurilor fiscale plătite din bani personali

Frecvență: des (lunar).
Stare: de decis — propus: Lotus + robot SAGA (robotul trebuie dezvoltat).

Context

Clientul trimite bonuri fiscale (combustibil, consumabile) care se înregistrează pe cheltuială (B5). Un bon se plătește pe loc; dacă după reconcilierea extrasului (B12) un bon nu are plată în extrasul de cont, înseamnă că a fost plătit din banii personali ai asociatului / administratorului. Pentru acel bon trebuie închis furnizorul pe contul de avans spre decontare (542), ca firma să știe că îi datorează omului acei bani; soldul lui 542 intră apoi în compensările lunare (B14).

La facturi nu putem ști dacă au fost plătite din bani personali — clientul poate alege să le plătească mai târziu; trebuie să ne spună el. La bonuri știm sigur că plata s-a făcut pe loc.

Ce trebuie să facă sistemul

1. Să țină o listă cu bonurile și facturile pe care clientul a confirmat că le-a plătit din bani personali.
2. Să marcheze în SAGA fiecare bon și factură din listă ca plătite din contul 542. Aceste note contabile nu se pot importa în SAGA, așa că marcarea o face un robot care intră pe fiecare bon din listă. Robotul trebuie dezvoltat.

Opțiuni

Soluția propusă

Opțiunea A, Lotus + robot. După reconcilierea extrasului, Lotus ține lista bonurilor și facturilor pe care clientul a confirmat că le-a plătit din bani personali. Un robot nou intră în SAGA pe fiecare bon și factură din listă și le marchează ca plătite din contul 542.

Decizii

• Bonurile neînchise după reconciliere se închid pe 542 (avans spre decontare), nu pe 473.
• Pasul este înaintea compensărilor 542/473 (B14), care rămân un flux separat.

De verificat

• Cerem confirmare suplimentară de la client (inclusiv cazul plății cash).
• Momentul exact în flux: după ce Lotus declară reconcilierea lunii închisă.

3. Compensări 542 / 473#

Pașii din flux:

• B14 Compensare 542 și 473

Frecvență: des (lunar).
Stare: în lucru la Otilia.

Context

Contul 542 ține evidența banilor pe care asociatul sau administratorul îi folosește pentru firmă, ca avans.

• Sold debitor: asociatul / administratorul a scos bani din contul firmei (de exemplu de la ATM) ca să plătească cash cheltuieli în numele firmei, dar nu a adus încă bonurile sau facturile.
• Sold creditor: asociatul / administratorul a plătit cheltuieli ale firmei din banii lui personali (bonuri pentru care nu există plată în extrasul firmei), iar firma îi datorează acei bani.

Contul 473 ține evidența plăților pe care nu le putem încă explica. Dacă are sold debitor, înseamnă că din contul firmei s-a făcut o plată (cu cardul sau prin transfer) pentru care clientul nu a adus încă factura sau bonul.

Stare

Fluxul de compensare este în lucru la Otilia. Opțiunile și soluția se completează aici după ce analiza ei este gata.

4. D301 — achiziții din UE și din afara UE#

Pașii din flux:

• B7.1 Înregistrare facturi externe
• B7.2 TVA prin taxare inversă
• B27 D301
• B30 Depunere declarații lunare

Frecvență: des (lunar, la firmele cu furnizori externi).
Stare: de decis — propus: generare D301 lângă Nucleu, cu verificare dublă față de D301 din SAGA.

Context

Clientul neplătitor de TVA, cu cod special de TVA (cod VIES), datorează TVA prin taxare inversă pentru serviciile cumpărate din UE și din afara UE și le declară lunar în D301. Când firma are în aceeași lună și achiziții din UE și din afara UE, trebuie două declarații D301: una pe codul VIES (achizițiile intracomunitare) și una pe CUI-ul firmei (achizițiile din State, China etc.). SAGA generează D301, dar le pune pe toate într-o singură declarație; SAGA a confirmat că nu are funcționalitate pentru împărțire și că se lucrează manual. D301 din SAGA e un PDF inteligent, fără XML.

Ce trebuie să facă sistemul

1. Să ia toate facturile de la furnizori externi din lună (sunt în Nucleu) și să le grupeze pe UE / non-UE și pe bunuri / servicii.
2. Să genereze cele două D301 (sau una, când există un singur tip de achiziție).
3. Să compare rezultatul cu D301 generat de SAGA; dacă diferă, să semnaleze cauza înainte să folosim automatizarea.

Opțiuni

Soluția propusă

Opțiunea A, cu o verificare dublă: generăm declarațiile noastre și le comparăm cu D301 generat de SAGA. Dacă sunt identice (pe total), folosim declarațiile noastre; dacă nu, analizăm cauza. Opțiunea B rămâne de investigat ca sursă de verificare (task Raluca, 30.10.2026).

Decizii

• D301 este candidat pentru generare în afara SAGA.
• Research pe cum rezolvă alte firme de contabilitate împărțirea (Prod).

De verificat

• Dacă putem extrage date structurate din PDF-ul D301 generat de SAGA.

5. Dividende interimare#

Pașii din flux:

• C9 Calcul dividende interimare
• C10 Hotărâre AGA
• C11 Distribuire
• C12 Impozit pe dividende

Frecvență: ocazional (trimestrial, la firmele care distribuie).
Stare: de decis — propus: engine contabil, cu acordul clientului în Dublin.

Context

SAGA nu face calculul dividendelor interimare, nu înregistrează distribuirea de dividende și nu calculează impozitul pe dividende la plată.

Ce trebuie să facă sistemul

1. Să verifice condițiile și să calculeze dividendele interimare brute din balanță.
2. Să genereze hotărârea AGA (template).
3. Să genereze notele contabile de distribuire dividende (463 = 456), compensare cu numerarul retras (456 = 542) și impozitul pe dividende (456 = 446.01).

Opțiuni

Soluția propusă

Opțiunea A. Engine-ul contabil calculează dividendele interimare și trimite calculul în Dublin, unde clientul își dă acordul. După acord, engine-ul generează hotărârea AGA și fișierul CSV de import în SAGA cu nota contabilă de distribuire a dividendelor.

Schema fluxului

6. Contracte de chirie cu persoană fizică și notele contabile recurente#

Pașii din flux:

• E3.1 Chiria lunară
• E3.2 Impozit reținut la sursă
• E3.3 Garanția
• E3.4 Închiderea garanției
• B26 D100
• D15 D205

Frecvență: ocazional.
Stare: de decis — propus: modul de contracte în Vertigo + IRIS → SAGA; manual cu reminder lunar în MVP.

Context

Pentru chiria plătită unei persoane fizice nu există factură: cheltuiala se înregistrează lunar pe baza contractului (6123.02 = 462.02), iar la plata chiriei firma reține la sursă impozitul de 10% (462.02 = 446.04). Clientul trebuie anunțat că plătește mai puțin decât scrie în contract. SAGA nu are „contracte”: nu există o înregistrare inițială (ca la imobilizări), trebuie ca cineva să țină minte lună de lună că există o chirie de înregistrat.

Ce trebuie să facă sistemul

1. Să conspecteze contractul o singură dată (sumă, frecvență, dată de început / sfârșit, valută, tip de contract) și să rețină regulile de alocare (chirie PF → cheltuială + impozit reținut la sursă + sumă netă).
2. Să genereze în fiecare lună, în luna respectivă, nota contabilă de cheltuială cu chiria, la cursul din luna înregistrării pentru contractele în valută, și să o trimită în SAGA.
3. Să calculeze impozitul reținut la sursă.
4. Generarea notei contabile a impozitului reținut la sursă are ca trigger plata chiriei. IRIS generează un CSV de import în SAGA cu nota contabilă (462.01 = 446.02).
5. Să anunțe clientul (Dublin) de suma netă de plată.
6. Să permită oprirea contractului de la o dată, după care nu se mai generează nimic.

SAGA acceptă o notă contabilă cu dată viitoare și o ține fără impact până în luna respectivă — dar pentru sume în valută cursul se știe abia în luna înregistrării, deci notele în avans nu sunt o soluție; notele se generează lună de lună.

Opțiuni

Soluția propusă

Opțiunea A. IRIS conspectează contractul original și extrage informațiile contabile (sumă, valută, frecvență, perioadă, tip → reguli de alocare pe tag „chirie PF”); contractul se înregistrează în Vertigo, în secțiunea de contracte cu efect financiar viitor (chirie, leasing, abonamente recurente, one-time); Vertigo emite lunar către IRIS o notificare / factură fictivă pe contractul activ; IRIS generează notele contabile și le trimite în SAGA; dacă clientul oprește contractul în Vertigo (sau în Dublin), notificarea nu se mai emite. Pentru MVP, cât timp modulul nu există, chiria PF rămâne manuală cu reminder lunar (D).

Decizii

• Nu tratăm contractele de chirie ca imobilizări (decizie tactică, 23.10.2026).
• Chiria se înregistrează când este datorată, nu când este plătită.
• Avem nevoie de un modul mic de contracte care angajează clientul la obligații financiare viitoare, cu posibilitatea de a opri un contract de la o dată.

De verificat

• Formatul notificării lunare Vertigo → IRIS și tag-urile cu reguli de alocare (chirie PF, leasing, colaboratori PF).
• Dacă pentru MVP chiria PF rămâne manuală sau IRIS propune lunar cheltuielile de înregistrat.
• Garanția din contract (E3.3 / E3.4) rămâne operațiune punctuală în interiorul fluxului.

7. Cheltuieli în avans: asigurări, viniete, abonamente plătite anticipat#

Pașii din flux:

• E9.1 Cheltuieli în avans — recunoașterea avansului
• E9.2 Venituri în avans
• E9.3 Scadențarul de repartizare
• E9.4 / E9.5 Repartizarea lunară
• E12 Înregistrare poliță de asigurare

Frecvență: ocazional (asigurări auto / sediu, viniete, abonamente anuale).
Stare: de decis — propus: manual în MVP, apoi robot pentru modulul de cheltuieli în avans din SAGA.

Context

O cheltuială plătită pentru o perioadă viitoare (asigurare pe 12 luni, vinietă, abonament anual) se înregistrează pe cheltuieli în avans (471 = 401) și se repartizează lunar pe cheltuiala lunii (6xx = 471), indiferent dacă e deductibilă sau nu și indiferent dacă plata se face în tranșe. SAGA are modulul „cheltuieli în avans”: primește suma, perioada și data de start și face automat înregistrările lunare — dar nu importă aceste date; scadențarul trebuie introdus manual sau printr-un robot care apasă butoanele. Factura în sine se înregistrează automat prin XML, dacă IRIS recunoaște că e o cheltuială în avans.

Ce trebuie să facă sistemul

1. Să recunoască la factură / poliță că e o cheltuială cu perioadă viitoare (perioada de la – până la) și să o înregistreze pe 471.
2. Să producă scadențarul (număr de luni, sumă lunară, data de start) după regulile stabilite (inclusiv pragul sub care suma intră direct pe cheltuială).
3. Să introducă scadențarul în modulul SAGA de cheltuieli în avans (robot) sau să genereze el notele lunare și să le trimită prin import.

Opțiuni

Soluția propusă

Pentru MVP: asigurările și vinietele se tratează manual (C) — sunt ocazionale, de obicei o dată pe an pe mașină. Pe termen mediu: A (robot pentru modulul SAGA) pentru cazurile simple, cu B ca variantă dacă engine-ul contabil ajunge să genereze oricum note recurente pentru contracte. Asigurările rămân o categorie separată de celelalte cheltuieli în avans (decizie din 20.10.2026), cu reguli proprii.

De verificat

• Pragul sub care o cheltuială cu perioadă viitoare intră direct pe cheltuială (RCA mic vs CASCO mare).
• Dacă IRIS va ști să recunoască facturile de cheltuieli în avans (perioada de pe factură / poliță).

8. Unde se fac calculele: IRIS, Lotus, engine contabil lângă Nucleu sau robot în SAGA#

Stare: de decis — se conturează engine contabil lângă Nucleu; analiză cerută lui Claude ca bază de dezbatere (decizie 23.10.2026).

Context

Cazurile 1, 2, 4, 5, 6 și 7 au o formă comună: o informație pe care o avem deja (plată legată de factură, bon fără plată, facturi externe, balanță, contract, poliță) produce un calcul și o notă contabilă pe care SAGA o poate importa ca pe orice notă. Întrebarea comună este ce sistem face calculul. Rolurile de azi: IRIS inspectează documente și le transformă în note; Lotus corelează facturi și plăți; Nucleu ține datele; SAGA procesează notele și face ce știe (reevaluare, amortizare, cheltuieli în avans dacă i se introduc).

Opțiuni

Soluția propusă

Se conturează opțiunea C: un engine contabil lângă Nucleu, care face ce nu face SAGA și ce nu vrem să facă IRIS sau Lotus. Prima listă de responsabilități: diferențe de curs la decontare (1), închiderea bonurilor pe 542 (2), D301 pe UE / non-UE cu verificare față de SAGA (4), dividende interimare (5), notele recurente din contracte (6, împreună cu modulul de contracte din Vertigo) și notele lunare din scadențare (7, varianta B). Roboții SAGA rămân pentru ce nu se poate importa (modulul de cheltuieli în avans, dacă alegem A la cazul 7). Compensările (3) intră după analiza Otiliei.

Decizii

• Continuăm analiza tuturor operațiunilor înainte să alegem sistemul care generează notele contabile.
• Discuțiile următoare includ și IT, pentru că implementarea ține de sistemele interne.

De verificat

• Contractul de date engine ↔ Nucleu (ce citește) și engine ↔ SAGA (fișierul de note al lunii).
• Cine declanșează calculele: lunar automat, la eveniment (plată corelată) sau la cerere din Vertigo.

Icebox — cazuri rare și subiecte amânate#