PRD · versiunea din 16 septembrie 2026 · în lucru
Sistemul din mijlocul platformei de contabilitate BONO. PRD-ul ăsta spune ce e, ce s-a hotărât, ce e deschis și cine răspunde — pentru cineva care n-a fost în nicio ședință.
PRD-ul se citește și din el se hotărăște. Harta sistemelor, scenariile pas cu pas, circuitul apei și spec-urile celorlalte echipe se explorează în aplicație.
Cum se parcurge
Citește în ordinea asta și oprește-te la 4. Sunt vreo 29 de minute. După ele știi sistemul, ce s-a hotărât și de ce.
Aici se termină cititul. Mai departe e de lucru, în două locuri. Secțiunea 5, „Ce publicăm”, ține fiecare câmp din Dublin și din Vertigo, cu sursa și frecvența lui; acolo le confirmă BGN, rând cu rând. Secțiunea 6, „Ce e deschis”, ține întrebările vii: caută-ți numele mai jos. Anexele și istoricul întrebărilor sunt de consultat, nu de parcurs.
1
Ce e. BONO ține contabilitatea firmelor mici. Clientul vede totul în Dublin, echipa lucrează în Vertigo, iar între ele stă Nucleu: primește documentele, le păstrează, le trimite la interpretare și la contabilitate, citește înapoi rezultatele și le arată. Nucleu nu calculează cifre contabile — le calculează SAGA. Ce calculăm noi e potrivirea plăților cu documentele, socoteala taxelor pe luni și netul dividendelor. Interpretează documentele Iris. Nucleu e baza lui Dublin și a lui Vertigo și ține adevărul: ce a intrat, ce a ieșit, în ce stare e fiecare lucru — tot, într-un singur tabel, la Ce ține Nucleu.
Unde suntem. Există deja: prototipul Dublin, PRD-ul și prototipul Vertigo, PRD-ul Iris, Remix, Facturare, SalarEasy, și roboții SAGA din proiectul Saga, dintre care importul XML e gata. Nu există încă Nucleul însuși — baza, stocarea, orchestratorul — nici generatorul fișierelor pentru SAGA, nici citirea înapoi din el.
Cele patru reguli care decid restul. Toate deciziile, cu dată și cu autor, sunt în Deciziile.
Ce e deschis. Din 56 de întrebări, 28 sunt lămurite, 4 amânate pentru V2 și 5 sunt teste pe SAGA. Deschise au rămas 19 întrebări, fiecare cu omul care răspunde. În Ce publicăm, 10 din cele 83 de câmpuri n-au încă sursă limpede, și alea sunt ce-i cerem lui BGN.
2
Tot ce apare în document, într-un singur tabel. „Stare” spune ce există azi, nu ce ne dorim. Spec-urile sunt copiate și în aplicație.
| Sistem | Ce face | Unde | Cine | Stare | Spec |
|---|---|---|---|---|---|
| Dublin | Ecranele clientului: facturi, cheltuieli, extrase, taxe de plată, angajați, documente. Nu calculează nimic; arată ce ține Nucleu. | în Nucleu | Prodi · BGN | prototip | dublin.bgn.ro/prd |
| Vertigo | Ecranele echipei: profilul firmei, documentele în lucru, ce a rămas nepotrivit, checklist-ul contabil. Agregatorul spre SalarEasy și SAGA. Datele lui stau în Nucleu, inclusiv analiticele partenerilor. | în Nucleu | Vlad | prototip + PRD | PRD Vertigo |
| Facturare | Emite facturile clientului, cu serie și număr, și le trimite ca e-Factura la ANAF. Scrie factura în Nucleu la emitere; răspunsul e-Factura vine tot acolo. | în Nucleu | Prodi | există | — |
| Findocs | Orchestratorul documentelor: primește fișierul, îl pune în Vault, îl trimite la Remix și la Iris, scrie rezultatul în Atom. Deduplicarea se face aici. | în Nucleu | Prodi | de construit | — |
| Remix | La încărcare, în ~5 secunde: citește documentul (OCR), scoate furnizorul și suma pentru preview și spune dacă e document contabil sau nu. Nu interpretează contabil. | în Nucleu | Prodi | există | — |
| Atom | Baza de date a Nucleului — deci a lui Dublin și a lui Vertigo. Ce ține, cine scrie și cine citește fiecare lucru e în tabelul de mai jos. | în Nucleu | Prodi | de construit | — |
| Vault | Stocarea fișierelor: originalul documentului, ce trimitem la SAGA, ce se întoarce (balanță, declarații, recipise). | în Nucleu | Prodi | de construit | — |
| Iris | Transformă un document în note contabile, linie cu linie: categorie, conturi, procent de deductibilitate, TVA. Fără analitice — pe alea le pune Nucleu. | în afară | BGN | PRD + prototip manual | iris.bgn.ro |
| SAGA | Contabilitatea propriu-zisă: primește fișierele, calculează taxele, închide luna, scoate balanța și declarațiile. O bază de date pe firmă, pe Desktop; SAGA Web pentru importul XML și validări. | în afară | Alex (roboți) · Raluca (spec) | există · roboți în lucru | saga-prd |
| SalarEasy | Salarizarea: pe firmă, pe lună, pe angajat — net, taxe, fluturași, statul de plată, declarația D112. | în afară | Alex | există | — |
| 4 Secunde | Semnează declarațiile și le depune la ANAF. Un om le încarcă. | în afară | Cristi | există | — |
| SPV / ANAF | Spațiul privat virtual: de aici vin facturile primite (e-Factura) și recipisele declarațiilor; acolo pleacă facturile emise. | statul | — | există | — |
| Lista de firme | De unde vin firmele noi la onboarding. | în afară | BGN | există | — |
| Rex | Semnarea electronică a documentelor. | în afară | — | există | — |
| Băncile | Azi: nimic — extrasul îl încarcă clientul. Open Banking, mai târziu. | în afară | — | mai târziu | — |
Nucleu e baza lui Dublin și a lui Vertigo (Chris). Un rând pe fiecare lucru pe care îl ține, cu cine îl scrie și cine îl citește. Cum ajung sistemele la el — direct în bază sau printr-un API — e întrebarea 1.2.
| Ce ține | Cine scrie | Cine citește |
|---|---|---|
| Documentele urcate: fișierul, tipul, statusul — neprocesat, primit, în lucru, finalizat | Findocs, la încărcare; statusul îl actualizează și Iris | Dublin, Vertigo |
| Fișierele: originalul, ce pleacă la SAGA, ce se întoarce — balanța, declarațiile, recipisele | Findocs; generatorul de fișiere (B1); contabilul, pentru ce descarcă din SAGA | Dublin, Vertigo · stau în Vault |
| Cheltuielile interpretate: linii, conturi, deductibilitate, TVA | Iris, prin Findocs; analiticul partenerului îl pune Nucleu | Dublin, Vertigo, fișierele pentru SAGA |
| Facturile emise | Facturare, la emitere | Dublin, Vertigo, fișierele pentru SAGA |
| Răspunsul e-Factura la facturile emise | Facturare, lângă factură | Dublin |
| Facturile primite prin e-Factura | citirea din SPV, de construit (8.1) | Dublin, Vertigo |
| Liniile extrasului și potrivirea lor cu documentele | Findocs desface extrasul; potrivirea o face Nucleu; ce nu se potrivește rezolvă omul din Vertigo (4.7) | Dublin, Vertigo |
| Starea facturilor: încasată, plătită, parțial | Nucleu, din potrivire; clientul, când bifează o factură plătită din banii lui | Dublin, Vertigo |
| Plățile fără document, pe omul care a plătit | Nucleu, la potrivire; rândul se închide când vine documentul | Dublin — Cheltuieli și „Bani de luat” —, Vertigo |
| Socoteala taxelor pe luni | Nucleu, după ordinea din lege — tabelă sau calcul la afișare (5.3) | Dublin — De plată |
| Balanța lunară, cu luna notată la import | contabilul, în Vertigo | Dublin, Vertigo |
| Declarațiile depuse, cu indexul ANAF și recipisa | contabilul, la „Depune”, în Vertigo | Dublin, Vertigo |
| Starea distribuirilor de dividende | Nucleu (C5) | Dublin — Banii tăi |
| Contractele de împrumut: număr, dată, sumă, semnat sau nu, dobânda | Nucleu (BGN) | Dublin — Banii tăi |
| Firma: datele de bază și conturile bancare | fluxul de înființare; IBAN-urile noi, echipa, la cererea clientului | Dublin, Vertigo |
| Profilul firmei: statut fiscal, sediu, mașini, bunurile cu impozit local, persoane — cu istoric pe fiecare atribut | echipa, în Vertigo (10.1) | Iris, Dublin, Vertigo |
| Analiticele partenerilor | Vertigo (B5) | fișierele pentru SAGA |
| Istoricul fiecărui lucru de mai sus | Nucleu | Dublin, Vertigo |
Codurile și cuvintele care apar în document, o linie fiecare.
3
Opt circuite, în ordinea în care se întâmplă lucrurile într-o firmă. Fiecare are doar pașii pe care îi știm, ca să se citească dintr-o suflare. La capătul fiecăruia scrie ce nu e încă hotărât acolo, cu trimitere la întrebarea din Ce e deschis, la omul care răspunde.
Orice fișier trimis de client — poză, PDF, XML, extras — și drumul lui până devine ceva înregistrat. Aici e intrarea; ce devine documentul după e în circuitele 2, 3 și 4.
Cum funcționează
Document ≠ cheltuială. Documentul e fișierul: un bon fotografiat, un PDF, un XML, un extras. Are un tip și un status și stă în Vault; poate să nu însemne nimic contabil. Cheltuiala e ce înseamnă un document de cumpărare după ce l-a citit Iris: furnizor, linii, deductibilitate, notă contabilă. Un document dă zero, una sau mai multe cheltuieli; un extras nu dă cheltuieli, dă plăți; o factură emisă e venit, nu cheltuială.
Nu e hotărât încă: 1.2 · 1.3 · 1.4 · 1.5 · 8.1 · 8.2 — sunt în Ce e deschis, la omul care răspunde.
Rezultatul interpretării unei facturi primite sau a unui bon: furnizor, linii, deductibilitate, notă contabilă. Aceeași formă ca o factură, plus deductibilitatea — care e partea grea.
Cum funcționează
Nu e hotărât încă: 2.3 — e în Ce e deschis, la omul care răspunde.
Singurul circuit care merge cap-coadă. Clientul emite în Dublin; SAGA primește o copie; „încasată” vine mai târziu, din extras.
Cum funcționează
Nu e hotărât încă: 3.1 — e în Ce e deschis, la omul care răspunde.
Până aici sistemul doar mută date. Aici trebuie să și hotărască: ce plată închide ce factură. Potrivirea o facem noi, nu SAGA, și numai pentru ce arătăm clientului și pentru plățile fără document.
Cum funcționează
Nu e hotărât încă: 4.3 · 4.7 — sunt în Ce e deschis, la omul care răspunde.
SAGA calculează; noi citim o dată pe lună. Între două închideri, Dublin arată ultima cifră știută, cu data ei, fiindcă nu estimează nimic. Aici sunt și documentele de contabilitate — balanța, declarațiile — și drumul lor înapoi la noi.
Cum funcționează
Nu e hotărât încă: 5.3 · 7.1 — sunt în Ce e deschis, la omul care răspunde.
SalarEasy calculează, Vertigo agregă, SAGA primește note. Taxele se plătesc la grămadă — deci se urmăresc pe firmă, nu pe angajat.
Cum funcționează
Cum intră o firmă nouă în sistem și cine îi ține datele la zi. Tot ce știe Iris despre firmă vine de aici.
Cum funcționează
Nu e hotărât încă: 9.1 · 10.1 — sunt în Ce e deschis, la omul care răspunde.
Amânat pentru V2, cu PRD separat. Rămâne aici ca să se vadă ce urmează: ce îi spunem clientului să facă, și ce îi arătăm că se întâmplă cu firma lui între o factură și alta.
Cum funcționează
4
Ce s-a hotărât, când, de cine, și ce schimbă, în ordinea în care s-a hotărât. Dacă o decizie nu e aici, nu e luată. „De confirmat” înseamnă că a fost spusă, dar cel care decide n-a semnat-o încă; „redeschisă” înseamnă că a fost luată și cineva a pus-o din nou în discuție.
| Data | Decizia | Cine | Ce schimbă |
|---|---|---|---|
| 4 aug | Nucleu e sistemul de înregistrare și hub-ul: păstrează, rutează, ține istoricul. Nu calculează nimic contabil — SAGA e motorul de calcul, ca procesor al Nucleului. | BGN, Prodi | Dublin și Vertigo citesc totul prin Nucleu; nimic nu se calculează în ecrane. |
| 31 aug | Arhiva facturilor emise stă în Nucleu; Facturare scrie factura acolo la emitere. | BGN | Răsturnat pe 9 septembrie, repus pe 10: lista din Dublin se citește din Nucleu. SAGA primește copia, pentru contabilitate. |
| 3 sept | Fișierele de import SAGA, versiunea 3.0: XML pentru facturi (F_), plăți (P_) și încasări (I_); CSV doar pentru notele de salarii. Partenerii se creează automat din antetul facturii. Fișierele CSV vechi sunt arhivate. | Raluca | Închide întrebarea formatului (B1). Rămâne de construit generatorul. |
| 4 sept | Granița Nucleului: înăuntru Atom, Vault, Findocs, Remix, Dublin, Vertigo; în afară Iris, SAGA, SalarEasy, 4 Secunde, Rex, Forex, lista de firme. | Chris | Ce e „al nostru” de construit și ce e integrare. |
| 4 sept | Deduplicarea se face la intrarea în Nucleu; Iris primește orice document (triaj universal); „incomplet nu se întoarce” — Iris dă o notă completă sau nimic. | Prodi, Chris | Regulile de bază ale circuitului documentului. |
| 7 sept | Importul XML se face pe SAGA Web, printr-un robot; bifarea plăților o face un robot pe Desktop, după criteriile din 4.1. Roboții de declarații se grupează. | Proiectul Saga: Teo, Raluca, Alex | Importul există din 3 sept; bifa e în lucru (termen 10 sept). |
| 8 sept | SAGA calculează tot — taxe, plafoane, închideri. Noi citim o dată pe lună, din balanță, care nu e stocată în SAGA. Nu există taxe în timp real. | Cristi, Raluca, Prodi, Alex | Cifrele de taxe și profit din Dublin sunt lunare, afișate cu data ultimei actualizări. |
| 8 sept | Nota contabilă și bifa „plătit” sunt lucruri diferite. Nota e corectă și fără bifă; bifa contează doar pentru statusul din Dublin. Iris dă contul doar pentru liniile de extras fără factură. | Prodi, Raluca, Cristi | Bifa iese din sarcina noastră. Potrivirea rămâne, ca regulă, nu ca modul. |
| 8 sept | Analiticul partenerului îl dăm noi, din Vertigo; persoanele fizice pe un singur analitic, fără CNP. | Prodi, Raluca | redeschisă 9 sept XML v3.0 n-are câmp de analitic — B5. |
| 8 sept | Taxele pe salarii se urmăresc pe firmă, nu pe angajat: se plătesc la grămadă: impozitul pe salarii, CAS și CASS în contul unic, CAM-ul separat. Doar salariul net se potrivește pe om, după IBAN. | Otilia, Cristi | Ecranul de salarizare din Vertigo se schimbă. |
| 8 sept | Pentru lei, e-Factura XML e singurul document justificativ; luăm toate facturile din SPV, ultimele 60 de zile. Facturile emise din alt program: în MVP doar alertă. | Raluca, Cristi, Prodi | de confirmat BGN, pe produs (8.1, 8.2). |
| 8 sept | Extrasul de cont se încarcă luna următoare; din el se potrivesc plățile și se închide luna. Open Banking după MVP. | BGN (PRD Dublin §5) | Ritmul reconcilierii e lunar. |
| 8 sept | Dividendele: totalul „poți scoate” = dividende nete decise + partea netă din profitul nedistribuit + deconturi + împrumuturi; impozitul intră la „De plată”; actele le pregătește echipa. | BGN (PRD Dublin §7) | Partea contabilă (conturi, formula) rămâne la Cristi. |
| 9 sept | Lotus, modulul de reconciliere propus pe 4 septembrie, e retras. Potrivirea rămâne la noi, dar ca regulă, nu ca modul. Ce ține Nucleu pentru ea — plățile fără document, starea facturilor, socoteala taxelor pe luni — e în tabelul de la Sistemele. | Chris, Prodi | Nu mai apare pe hartă. Ecranul de reconciliere din Vertigo rămâne. |
| 9 sept | Remix e pre-procesarea de la încărcare: OCR în ~5 secunde, furnizor, sumă, preview, verdict document / nu. | Chris | Lămurește pasul de după upload. |
| 9 sept | Extrasul de cont îl încarcă clientul; băncile nu ne dau tranzacții. | Chris | Harta: fluxul de la bănci e „mai târziu”. |
| 9 sept | Nu cronometrăm SAGA; întâi înțelegem circuitul (scenariul A8, amânat). | Chris | — |
| 9 sept | Tot ce se poate lua din SAGA se ia din SAGA. Motivul: două surse ale adevărului riscă să arate clientului o cifră care nu bate cu ce a calculat contabilitatea. Unde nu se poate, luăm de altundeva. | BGN | Fiecare câmp are de-acum o sursă declarată. Excepțiile — lista facturilor emise și P&L-ul din Vertigo — sunt scrise în decizia din 10 septembrie și în „Ce publicăm”. |
| 9 sept | Dublin nu calculează și nu estimează nimic. Arată informația pe care o are, cu data ultimei actualizări. Frecvența e un atribut al fiecărei informații, nu o constantă: azi lunar, cu Open Banking mai des. | BGN | Dispar cifrele estimative din Acasă, Contabilitate și Analize. Fiecare cifră capătă o etichetă cu data. |
| 9 sept | În SAGA nu se face matching. Facturile în lei plătite în lei nu se închid: nota e corectă fără bifă. Facturile în valută plătite din cont de lei trebuie închise, fiindcă apare diferența de curs, iar nota pentru ea o produce Iris. | BGN, Cristi | redeschisă 15 sept BGN ar face potrivirea facturilor în SAGA — B2. Până atunci, robotul de bifat rămâne fără scop pentru lei. Potrivirea o facem la noi, pentru raportare și pentru plățile fără document. |
| 9 sept | Documentele care nu sunt facturi, bonuri sau extrase intră tot prin Iris: el face triajul, iar ce nu e evident merge într-o zonă separată, unde citește un om sau un model mai bun. | BGN | Închide jumătate din întrebarea 1.4. Formatul notei pentru ele rămâne de lucrat până la 1 octombrie. |
| 9 sept | În MVP nu punem la îndoială acuratețea calculelor SAGA. Ne bazăm pe ele. | BGN | Nu construim verificări paralele. O eroare de-a SAGA se corectează contabil, nu se previne prin recalculare la noi. |
| 9 sept | Produsul livrează lista completă a câmpurilor din Dublin și Vertigo, fiecare cu sursa și frecvența lui. La BGN merg doar cele neclare, nu toate. | Chris, Teo | Lista e „Ce publicăm”; BGN confirmă sursele rând cu rând, acolo. |
| 9 sept | Un singur document, la nucleu.bonofintech.ro, din git; task-urile de clarificare se pun în Batman, oamenii răspund acolo, răspunsul intră în document. | Chris | Cum lucrăm de aici înainte. |
| 10 sept | Regula de sursă, scrisă: tot ce înseamnă calcul sau cifră contabilă se ia din SAGA. Veniturile, cheltuielile și deductibilitatea afișate se citesc din contabilitate, nu din Iris. Sistemele noastre rămân locul unde se întâmplă lucrul; sursa pentru ce se afișează e SAGA. | Chris, pe linia lui BGN | Rezolvă dezacordul dintre ședință și analiza pe surse. Cifrele de pe Acasă devin lunare, cu data lor. |
| 10 sept | Analiticele se fac numai cu cifre. Unul scris cu litere trăiește în SAGA, dar nu apare în balanță — impozitul pe dividende stătea pe 446.div și tocmai de-aia lipsea din balanța de august; în specificația din 14 septembrie e deja renumerotat, 446.01. | Raluca | Ne privește direct, fiindcă analiticul partenerului îl alocăm noi. Un analitic cu litere înseamnă o sumă care dispare din singura sursă pe care o citim. |
| 10 sept | O firmă poate avea în același an și 4418, impozit pe venit, și 4411, impozit pe profit: firma din balanța de august a trecut de la unul la altul în trimestrul 3. Contul se alege după regimul din perioada citită, nu o dată pentru totdeauna. | Raluca | Ecranul „De plată” nu poate avea un cont fix pentru impozit. |
| 10 sept | Balanța descărcată din SAGA Web nu spune pentru ce lună e — nici în XML, nici în XLSX, nici în metadatele fișierului. Perioada o notăm noi, în clipa în care o cerem, și o purtăm cu fișierul — convenția din specificația Ralucăi: în numele fișierului, CUI_2026-08.xml. Ea a cerut celor de la SAGA să o scrie înăuntru; dacă acceptă, convenția devine de prisos. | Raluca | „Ultima cifră, cu data ei” depinde de asta: fără perioadă, nu putem eticheta nicio cifră venită din balanță. Verificarea că lunile vin la rând se face comparând coloana prec a fișierului nou cu total a celui vechi. |
| 10 sept | Facturile emise se citesc din Nucleu, unde le scrie modulul de facturare la emitere. E una din cele două excepții de la regula de sursă — cealaltă e P&L-ul din Vertigo, calculat în Iris: nu e o cifră calculată de contabilitate, ci chiar documentul pe care l-a făcut clientul. | Chris | Lista din Dublin e din nou în timp real. SAGA primește copia prin importul lunar și rămâne sursa pentru veniturile din balanță. |
| 14 sept | Un test pe SAGA are două jumătăți, și testul spune care e a cui: contabilul pregătește firma și rulează operațiunea în SAGA, dezvoltatorul face copia bazei, diff-ul și citirea. Testul poartă amândouă și numele omului de la conta. | Alex, Teo | Fără asta, testul începe cu „pe o firmă cu venituri, TVA și impozit” — adică exact ce un dezvoltator nu poate face singur, și se blochează fără să spună. |
| 14 sept | Evidența poartă distincțiile; ecranul le alege. Ce arătăm în Dublin — pe stări sau pe perioade, separat sau la un loc — e decizie de front-end și se poate schimba. Ce nu se poate schimba ieftin e ce ținem: profitul nedistribuit separat de dividendele distribuite dar neplătite, dividendele pe fiecare perioadă, banii puși de asociat separat de banii scoși din firmă, împrumuturile cu contractul și dobânda lor. | BGN | Întrebările despre afișare nu se pun la contabilitate. Modelul de date trebuie să fie mai fin decât ecranul, nu invers. |
| 14 sept | Impozitele locale se țin cu analitic pe fiecare bun, nu pe tip: nu „impozit auto”, ci impozitul mașinii cu numărul ei. La fel la clădiri. | BGN | Cere analitice noi în SAGA pentru fiecare bun, și o listă a bunurilor în profilul firmei. Leagă impozitele locale de aceleași date pe care le cere Iris pentru deductibilitate. |
| 15 sept | O factură fără plată în extras rămâne neplătită până bifează clientul că a plătit-o din banii lui. La bon, o plată care nu apare în extras e din banii omului. | BGN, Raluca | Închide jumătate din 2.3. Rămân dovada plății și banii scoși de la bancomat. |
| 15 sept | Deconturile se arată în două cifre, fiecare cu cardul ei, sus pe ecran: bani de dat — ce a pus omul din buzunar pentru firmă — și bani de luat — ce a scos din firmă și n-a justificat încă, inclusiv plățile din extras fără document. | BGN, Raluca | Un rând nou în „Ce publicăm”: 542 · fin_d. Nimic nu se compensează pe ecran. |
| 15 sept | SAGA nu pune bifa singur. Lângă o plată din Jurnal de bancă arată facturile partenerului; bifa o pune un om sau robotul, cu suma parțială dacă e cazul. Prin import nu i se poate spune ce factură a stins o plată. | Raluca | Testul #7668 are răspuns. Rămâne B2: facem potrivirea facturilor și în SAGA, sau nu. |
| 16 sept | Nucleu e baza lui Dublin și a lui Vertigo. Facturare pune facturile în el, iar răspunsul e-Factura vine tot acolo. Textul de arhitectură din PRD-ul Dublin nu se preia. | Chris | Ce ține Nucleu stă într-un singur tabel, la Sistemele. Cum ajung sistemele la date rămâne 1.2, la Prodi. |
| 16 sept | Sarcinile ies din PRD și rămân în Batman. În document rămâne, la fiecare întrebare, doar cine răspunde. | Chris | „Ce e deschis” devine o listă scurtă, fără termene. |
Aici se termină partea de citit. Știi acum ce e Nucleu, cine sunt sistemele, cum curge o lună și ce s-a hotărât. Ce urmează nu se citește cap-coadă: „Ce publicăm” e lista câmpurilor, cu sursa fiecăruia, iar „Ce e deschis” e lista întrebărilor vii. Anexele sunt de consultat. Înapoi la drum
5
Fiecare câmp din Dublin și din Vertigo, cu sursa lui și cu frecvența la care se actualizează. Lista a cerut-o BGN, ca sursele să se confirme rând cu rând, direct aici. Regula de sursă: tot ce se poate lua din SAGA se ia din SAGA, ca să nu arătăm clientului o cifră care nu bate cu contabilitatea. „De unde vine” spune unde se calculează cifra, nu unde o ținem noi: dacă o primim din SAGA și doar o stocăm și o arătăm, sursa e SAGA. Nucleu apare ca sursă numai unde cifra chiar se naște la noi — lucrurile din tabelul „Ce ține Nucleu”, de la Sistemele. Conturile, formulele și frecvențele stau o singură dată, aici: Acasă trimite la „De plată” și la „Banii tăi”. Frecvența nu e un detaliu: Dublin nu calculează și nu estimează nimic, deci arată ultima valoare venită, cu data ei. Rândurile care vin din balanță poartă contul și câmpul exact din XML, din specificația Ralucăi. Tabelul îmbină și analiza pe surse a lui Cristi,. Unde cele două nu se potriveau — veniturile, cheltuielile — a decis regula: cifra afișată vine din contabilitate. Excepția e lista facturilor emise, care se citește din Nucleu: nu e o cifră calculată, e documentul făcut de client.
Pentru Bogdan
Fiecare rând are în dreapta da și nu. Apasă nu unde sursa propusă e greșită și scrie în coloana de comentarii de unde vine de fapt. Frecvența și comentariul se scriu direct în tabel: dai clic pe ele și scrii. La final apeși Confirmă restul, copiezi răspunsurile și ni le trimiți într-un singur mesaj. Tot ce bifezi și scrii se salvează pe loc, la noi, deci poți lăsa tabelul și te poți întoarce la el de pe orice calculator.
? sursa nu e limpede nici pentru noi — întrebarea e scrisă la finalul anexei ! propunem altceva decât scrie PRD-ul sau prototipul Dublin + lipsea din tabelul nostru, adăugat din PRD-ul sau prototipul lui
Dublin · ecranele clientului
| Ce publicăm | De unde vine | Frecvența | Comentariu | Sursa e bună? |
|---|---|---|---|---|
| Pe toate paginile | ||||
| Firma și CUI-ul, sus pe ecran | Nucleu · datele firmei, importate din fluxul de înființare | rar | ||
| „Live · data”, sus pe ecran Fiecare cifră se arată cu data ei. | Nucleu · data ultimei citiri reușite | la fiecare citire | ||
| Lista „De făcut” 11.2 | Nucleu · task-uri | la eveniment | V2 | |
| Feed-ul „din motorul Bono” 11.1 | Nucleu · jurnalul de evenimente | la eveniment | V2 | |
| +Stiva de mesaje: alerte și observații, cu amânare Din PRD-ul Dublin §1. Nu era în tabelul nostru. | Nucleu, plus observațiile lui Iris | la eveniment | V2 | |
| „Ce urmează” | Vertigo · calendarul declarațiilor | lunar | ||
| Badge-urile din meniu: documente în procesare, facturi neplătite | Atom · documentele nefinalizate și facturile nepotrivite încă cu extrasul | la eveniment | ||
| Acasă | ||||
| „Totul e ok azi” 11.2 | Nucleu · task-uri și erori | la eveniment | V2 | |
| Venituri facturate, cu încasate și neîncasate Perioada închisă vine din balanță; suma facturată în luna încă neînchisă vine din Facturare și se afișează separat (specificația Ralucăi). | SAGA · balanța, pentru lunile închise; Facturare, pentru luna curentă venituri 70x · rulajt_c · încasate 4111 · rulajt_c · neîncasate 4111 · fin_d plus 4118 · fin_d | lunar, la închidere | ||
| Cheltuieli, cu deductibile și nedeductibile Defalcarea nu vine din balanță, ci din deductibilitatea pusă de Iris pe fiecare document (specificația Ralucăi). Totalul rămâne contabil. | SAGA · balanța pentru total; defalcarea deductibil / nedeductibil, din Nucleu total: toate conturile 6xx fără 691 și 698 · rulajt_d | lunar, la închidere | ||
| KPI-urile sunt altele pe Micro decât pe Profit Pe Profit: cheltuieli, deductibile, nedeductibile. Pe Micro: cheltuieli, documente procesate, fără documente. Regimul se citește din vectorul fiscal. | aceleași surse, altă alegere de cifre | lunar | ||
| De distribuit · dividende A7 | SAGA · soldul contului de profit nerepartizat, plus cel curent la interimare; netul și impozitul le calculăm noi aceeași bază ca pe „Banii tăi”: (1171 · fin_c − 1171 · fin_d) + (121 · fin_c − 121 · fin_d) − 463 · fin_d | lunar, la închidere | ||
| Deconturi · bani de dat și bani de luat A7 Două cifre, nu una compensată (BGN). 542 ține și avansurile date omului, și banii pe care i-a pus el din buzunar pentru firmă (Raluca). 462 e altceva — împrumuturi de la creditori care nu sunt asociați. | SAGA · soldul contului de avansuri de trezorerie, pe fiecare persoană ca pe „Banii tăi”: 542 · fin_c pentru bani de dat, 542 · fin_d pentru bani de luat | lunar, la închidere | ||
| Împrumuturile tale A7 | SAGA · soldul contului asociatului ca pe „Banii tăi”: 4551 acționari/asociați — conturi curente, cu analitic pe om. 455 e doar grupa, iar 462 sunt creditorii care nu-s asociați | lunar, la închidere | ||
| Taxe și impozite de plată 5.2 Cifra e a contabilității. Nucleu doar le ține laolaltă, ca să știm ce s-a stins și ce nu — partea noastră e evidența, nu suma. | SAGA · balanța lunară, suma obligațiilor aceleași conturi ca pe „De plată”: 4423, 4315, 4316, 436, 444, 4381, 4411, 4418, 446, 447 · fin_c | lunar | ||
| Documente în curs de procesare | Atom · statusul pus de Findocs și Iris | la eveniment | ||
| Ultimele facturi emise și ultimele cheltuieli | Atom · ultimele documente intrate, de la Facturare și de la Iris | la eveniment | ||
| Facturi | ||||
| Seria, emisă, client, descriere, sumă, valută SAGA primește copia prin importul lunar, dar lista de pe ecran vine de la noi, ca să apară pe loc. | Atom · baza facturilor emise, scrisă de Facturare la emitere | la eveniment | ||
| +Facturile emise din alt program, urcate ca document Din PRD-ul Dublin §3. Nu era în tabelul nostru. | Iris · le recunoaște ca venit din documentul urcat | la eveniment | ||
| Status: încasată / neîncasată, plus cifrele de sus B2 În SAGA nu se bifează nimic pentru facturile în lei; dacă se bifează totuși e întrebarea B2. „Încasată” se folosește la facturile emise; la cele primite spunem „plătită”. | Nucleu · potrivirea noastră 4111 clienți, per factură | după fiecare extras | ||
| e-Factura, pe fiecare rând Doar trimisă / se trimite. Indexul ANAF nu ne vine, deci ecranul nu îl promite. | Nucleu · răspunsul e-Factura, care vine lângă factură (Chris) | la eveniment | ||
| Cheltuieli | ||||
| +Documente neprocesate: nume, tip, încărcat, status Din PRD-ul Dublin §4. Nu era în tabelul nostru. | Atom · statusul pus de Findocs și Iris | la eveniment | ||
| Cheltuieli procesate: furnizor, dată, sumă, valută | Atom · rezultatul lui Iris | la eveniment | ||
| ?Rândurile venite ca e-Factura 8.1 | SPV | zilnic | ||
| Plata: plătită / neplătită 2.3 Factura fără plată în extras rămâne neplătită până bifează clientul că a plătit-o din banii lui (BGN). | Nucleu · potrivirea noastră, plus bifa clientului 401 furnizori, per factură | după fiecare extras | ||
| Deductibilă: 100 / 50 / parțial / nu, cu motivul Verdictul de pe rând e al lui Iris, plafonul de categorie îl aplică SAGA — nu se bat, se completează. „Parțial” înseamnă tocmai un plafon: protocol, asigurări. Cifra totală de pe Acasă vine din balanță. | Iris, pe fiecare linie SAGA ține doar nedeductibilul, pe 6xx.N sau 6588 | la eveniment | ||
| ?Cardul de observație: „Poți deduce mai mult la…” 10.1 | Iris, din profilul firmei | la eveniment | ||
| Plăți fără documente: furnizor, dată, sumă, valută 4.8 În contabilitate plata stă pe 542, cu analitic pe omul care a plătit (Raluca) — furnizorul nu există acolo, deci tabela noastră e singurul loc unde se știe de la cine e. Pe „Banii tăi” intră la „Bani de luat”. | Nucleu · tabela plăților fără document 542, analitic pe om; nu 473 pe furnizor | după fiecare extras | ||
| +Cine a procesat documentul și în cât timp Din PRD-ul Dublin §4. Nu era în tabelul nostru. | Nucleu · jurnalul procesării | la eveniment | ||
| Extrase | ||||
| Conturile bancare: bancă, valută, IBAN | Nucleu · aceleași conturi ca pe „Firma ta”, sursa unică a IBAN-urilor | rar | ||
| Celula lunii: încărcat, se procesează, lipsește | Atom · statusul pus de Findocs | la eveniment | ||
| De plată | ||||
| Cifrele de sus: plătite pe perioadă, de plată acum, următoarea scadență Numărul de plăți și scadența nu vin din balanță. Specificația Ralucăi. | SAGA · balanța, pentru primele două; scadența, din calendarul fiscal plătite: 4423, 4315, 4316, 436, 444, 4381, 4411, 4418, 446, 447 · rulajt_d; de plată acum: aceleași · fin_c | lunar, la închidere | ||
| Impozit pe venit sau pe profit 5.2 | SAGA · balanța lunară, încărcată în Vertigo — fișierul nu spune ce lună acoperă, deci perioada o notăm noi la import 4411 la impozitul pe profit, 4418 la cel pe venit — micro. Pot exista amândouă în același an: firma din balanța de august a trecut de la venit la profit în trimestrul 3, deci contul se alege după regimul din perioada citită | trimestrial | ||
| TVA 5.2 | SAGA · balanța lunară, încărcată în Vertigo — fișierul nu spune ce lună acoperă, deci perioada o notăm noi la import 4423 de plată, 4424 de recuperat; în balanță stau și 4426 deductibilă, 4427 colectată | lunar | ||
| Taxe salarii: impozit 10%, CAS 25%, CASS 10%, CAM 2,25% Un singur card, dar două plăți: impozitul pe salarii, CAS și CASS merg în contul unic, CAM-ul în contul lui — nomenclatorul ANAF al contului unic nu îl conține. Compoziția se vede în detaliu; pe angajat nu se pot urmări. | SAGA · balanța lunară, încărcată în Vertigo — fișierul nu spune ce lună acoperă, deci perioada o notăm noi la import 444 + 4315 + 4316 + 436 — toate patru există separat în balanță | lunar | ||
| Impozit pe dividende A7 | SAGA · balanța lunară, încărcată în Vertigo — fișierul nu spune ce lună acoperă, deci perioada o notăm noi la import 446.01 · fin_c. Impozitul se înregistrează la PLATA dividendelor, nu la hotărâre. Brutul nu se citește: se calculează invers, impozit ÷ cotă | la eveniment | ||
| Impozite locale Suma nu vine din contabilitate până nu urcă clientul decizia de impunere de la primărie; până atunci ecranul arată „necunoscută · așteptăm decizia”. BGN: analitic pe fiecare BUN, nu pe tip — impozitul mașinii cu numărul ei, nu „impozit auto”. Cere analitice noi în SAGA și lista bunurilor în profilul firmei. | SAGA · balanța lunară, încărcată în Vertigo — fișierul nu spune ce lună acoperă, deci perioada o notăm noi la import 446.02 · fin_c | lunar | ||
| ?Starea fiecărei obligații: de plată, plătit, așteptăm decizia 5.3 Specificația Ralucăi dă mecanismul: o obligație e „de plată” cât timp contul ei are rulaj creditor în luna curentă, și trece pe „plătit” în luna următoare, când apare rulajul debitor care o stinge. Cine leagă plata de luna potrivită suntem noi, după ordinea din lege: întâi pe bugete, proporțional, apoi ce e reținut la sursă, abia apoi scadența cea mai veche (5.3). A treia stare, „așteptăm decizia”, e reală: la impozitele locale suma nu există până nu urcă clientul decizia de impunere. | Nucleu · socoteala pe luni, după ordinea din lege | după fiecare balanță | ||
| Cât s-a plătit în luna asta, pe fiecare taxă Balanța dă și obligația, și cât s-a plătit. Ce nu dă e ce lună s-a stins — aia rămâne la noi. | SAGA · balanța lunară, încărcată în Vertigo — fișierul nu spune ce lună acoperă, deci perioada o notăm noi la import înregistrările 44x = 5121, per taxă și dată | lunar | ||
| +Istoricul plăților, potrivite cu extrasul Din PRD-ul Dublin §6. Nu era în tabelul nostru. | Nucleu · potrivirea noastră | după fiecare extras | ||
| Următoarea scadență Nu vine din SAGA: scadențele le știm din calendar, pe tip de declarație, și alunecă peste weekend. | Calendarul declarațiilor din Vertigo | lunar | ||
| !Beneficiarul și IBAN-urile de trezorerie Nu e un singur IBAN: contul unic pentru impozite și contribuții, un cont pentru CAM și unul pentru TVA, la trezoreria de care ține firma. PRD-ul Dublin îl ia din SAGA; noi credem că nu vine de nicăieri și îl ținem noi — de confirmat. | Configurarea Bono · pe trezoreria de care ține firma | rar | ||
| Banii tăi | ||||
| „Poți scoate · net” — totalul Pagina întreagă lipsea din tabelul nostru; e §7 din PRD-ul Dublin. | îl calculăm noi, din cele trei componente de mai jos | lunar, la închidere | ||
| Dividende — decizii și distribuiri A7 Cota e 16% de la 1 ianuarie 2026 (Legea 141/2025), dar se aplică după data hotărârii AGA, nu a plății: ce s-a distribuit până la 31 decembrie 2025 rămâne la 10%. Deci lista poate avea rânduri cu cote diferite. | SAGA · soldurile; descompunerea net + impozit o facem noi brut = (1171 · fin_c − 1171 · fin_d) + (121 · fin_c − 121 · fin_d) − 463 · fin_d; cota, după data distribuirii | lunar, la închidere | ||
| Bani de dat · ce a plătit omul din buzunar pentru firmă 2.3 Separat de „Bani de luat”, nu compensat, fiecare cu cardul lui, sus pe ecran (BGN). Ca să ajungă suma pe contul bun, trebuie știut din ce bani s-a plătit — întrebarea 2.3. | Atom pentru documente, SAGA pentru sold 542 · fin_c | la eveniment; soldul, lunar | ||
| Bani de luat · ce a scos din firmă și n-a justificat încă Aici intră plățile din extras care n-au încă document și banii scoși din firmă pentru cheltuieli nejustificate încă (Raluca și BGN). Lipsea din tabelul nostru. | Atom pentru plățile fără document, SAGA pentru sold 542 · fin_d | după fiecare extras; soldul, lunar | ||
| Împrumuturi — date firmei, cu starea contractului Balanța dă soldul și cât s-a rambursat în lună. Contractul îl ținem noi: număr, dată, sumă, semnat sau nu, și dobânda — implicit zero, dar unii clienți o vor (BGN). | SAGA pentru sold și rambursări; contractele, la noi sold 4551 · fin_c · rambursările lunii 4551 · rulaj_d | la eveniment; soldul, lunar | ||
| ?Tabelul distribuirilor: ce, data, brut, impozit, net, stare C5 Starea nu există nicăieri azi. BGN: evidența trebuie să distingă profitul nedistribuit de dividendele distribuite dar neplătite, și să le țină pe fiecare perioadă. Cum se afișează e altă discuție. | SAGA pentru sume; starea — nedistribuit, decis, ridicat, impozit plătit — o ținem noi | la eveniment | ||
| Angajați | ||||
| Luna: salariu net, taxe, salariul total În balanță aceleași sume stau pe 421, 444, 4315, 4316 și 436 — bune ca verificare, nu ca sursă. | SalarEasy, prin Vertigo | lunar | ||
| Fișa: contract, normă, Revisal | SalarEasy | la angajare | ||
| Data plății salariului, pe lună | Nucleu · potrivirea pe IBAN 421 = 5121, din extras | după fiecare extras | ||
| Data plății taxelor 6.2 | Nucleu · pe firmă, nu pe angajat | după fiecare extras | ||
| Fluturaș | SalarEasy | lunar | ||
| Contabilitate | ||||
| Bara de stare: la zi, ultima lună închisă, cine a verificat și când A2 Confirmat: marcajul e în bază, nu mai depinde de bifa unui om. | SAGA · data „închis până la” din antetul firmei; contabilul și data verificării, din Vertigo | după fiecare închidere | ||
| !Situațiile lunare: balanța de verificare, registrul jurnal, fișele de cont, cartea mare, registrul de casă, jurnalele de vânzări și de cumpărări 7.1 Toate șapte apar în prototip, cu instanțele lor pe luni. PRD-ul Dublin §9 spune însă că fișele de cont și documentele intermediare rămân pentru după MVP — de lămurit care variantă ține. | SAGA · Situații → Listări; căile exacte, pe fiecare document, sunt în analiza lui Cristi | lunar | ||
| Situațiile anuale: bilanțul, registrul inventar, registrul de evidență fiscală 7.1 | SAGA · Situații → Bilanț și Listări | anual | ||
| Declarațiile, după vectorul fiscal al firmei: D300, D100, D112 și restul 5.1 Ce declarații apar ține de firmă: prototipul arată D300, D100 și D112, fiindcă firma lui e plătitoare de TVA trimestrial și micro cu angajat. Lista completă pe care o acoperim e în PRD-ul Dublin §9. | SAGA pentru fișier, SalarEasy pentru D112 | după calendar | ||
| !Fișa mijlocului fix și procesul verbal de recepție În prototip apar amândouă, pe fiecare echipament. §9 pune fișa mijlocului fix după MVP — aceeași contradicție ca mai sus. | SAGA pentru fișă, noi pentru procesul verbal | la eveniment | ||
| ?Pe fiecare document: perioada și data la care a fost generat sau depus 5.1 În Dublin clientul vede doar „Depusă la ANAF” și data. Indexul ANAF și recipisa le cere ecranul echipei, din Vertigo — două nevoi diferite, cu urgențe diferite. | SAGA · data fișierului; marcajul „Depusă la ANAF”, de la cine face depunerea | la eveniment | ||
| Firma ta | ||||
| Datele firmei: denumire, CUI, Nr. Reg. Com., sediu social, administrator, asociați, capital social, înființată, stare Ecranul promite „Stare: activă”, verificată zilnic la ONRC și ANAF — de stabilit dacă o facem. | Nucleu · importate din fluxul de înființare; se schimbă prin echipă, cu act | rar | ||
| Istoricul fiecărui atribut 2.1 | Nucleu · jurnalul modificărilor | la eveniment | ||
| ?Vector fiscal: TVA, impozit, TVA la încasare, angajator, cod VIES Sursa e știută, integrarea nu există. Azi se schimbă de mână în Vertigo, iar ecranul scrie „Sincronizat cu ANAF · azi 06:00”. | ANAF, prin SPV | rar | ||
| Conturi bancare | Nucleu · primul IBAN vine din înființare, restul se adaugă la cererea clientului | rar | ||
| Documentele firmei: ONRC, ANAF, decizii AGA | Vault · cu sursa și data pe fiecare | la eveniment | ||
| Contul tău | ||||
| Profil și securitate: nume, email, telefon, parolă, sesiuni Pagina lipsea din tabelul nostru; e §11 din PRD-ul Dublin. | cont.bono.ro | rar | ||
| Planul, următoarea plată, metoda de plată | modulul de abonamente | lunar | ||
| Facturile de la Bono către client | modulul de abonamente | lunar | ||
Vertigo · ecranele echipei
| Ce publicăm | De unde vine | Frecvența | Comentariu | Sursa e bună? |
|---|---|---|---|---|
| Echipa | ||||
| ?Onboarding ANAF: cele cinci accese, cu statusul fiecăruia 9.1 SPV CUI, e-Factura, F150, REGES, VIES. Firma iese din listă când toate sunt „conectat” sau „nu se aplică”. | Vertigo · bifat de om, cu istoric pe fiecare acces | la eveniment | ||
| +Alerte: expirarea sediului, expirarea buletinelor, micro fără angajat Cele trei tipuri din PRD-ul Vertigo §3.2. Nu erau în tabelul nostru. | Vertigo · calculate din profilul firmei; severitatea, din numărul de zile rămase | zilnic | ||
| ?Alerte: plafoanele de TVA și de micro, activul net 10.2 Astea sunt propunerea noastră: PRD-ul Vertigo nu le are printre alerte. De confirmat că le vrem, fiindcă sunt singurele care depind de contabilitate, nu de profil. | SAGA · balanța, cifra de afaceri și activul net | lunar | ||
| Clienți: lista firmelor și cifrele ei | Vertigo | la eveniment | ||
| Setări contabile: plafoanele și calendarul declarațiilor Calendarul spune pentru fiecare declarație dacă e obligatorie și până când. Din el iese și „următoarea scadență” din Dublin. | Vertigo · le ținem noi; în v1 se citesc, nu se editează | rar | ||
| Declarații: matricea pe trei piloni, cu starea fiecărei celule 5.1 Piloni: contabilitate, TVA–VIES, salarii. Stări: la zi · de depus, cu lista codurilor · întârziat, cu codurile depășite · nu se aplică. | Vertigo · agregat din declarațiile fiecărei firme | la depunere | ||
| Firma, în Vertigo | ||||
| Profilul firmei: identificare, statut fiscal, plafoane, persoane, sediu și flotă auto 2.1 Sediul și flota auto sunt „motoarele de deductibilitate” din PRD-ul Vertigo §9.4 — exact contextul pe care îl cere Iris ca să spună „combustibil, 50%”. | Nucleu · datele de bază vin din înființare, restul le completează echipa din Vertigo | la eveniment | ||
| Documente primite: nr., dată, partener, tip, sumă, plus documentul și nota contabilă | Atom · ce a scris Findocs, cu nota de la Iris | la eveniment | ||
| Adaugă un document de mână: contract, poliță, proces verbal, declarație vamală 1.4 Fiecare tip are câmpurile lui, iar încărcarea fișierului e obligatorie. Ăsta e ecranul din spatele întrebării despre documentele atipice. | Vertigo → Iris | la eveniment | ||
| Evidențe contabile: balanța, registrul inventar, soldurile clienți și furnizori, imobilizările 7.1 PRD-ul Vertigo §7 spune limpede: în v1 totul se face manual, roboții vin în v2. Deci nu e robot, e om — de confirmat că rămâne așa (7.1). | SAGA · listări, descărcate și încărcate de contabil | lunar și anual | ||
| Declarații și raportări: de depus pentru perioada curentă, și cele depuse 5.1 Aici se rezolvă „cum se întorc la noi”: butonul „Depune” din ERP Conta cere index și recipisă, obligatoriu, iar de acolo ajung în tabelul depuselor. | Vertigo · indexul ANAF și recipisa le introduce contabilul la depunere | la depunere | ||
| ?P&L: venituri, cheltuieli deductibile, profit, pe an și pe trimestre Singurul loc unde calculăm noi o cifră contabilă în loc s-o citim din SAGA. Merge împotriva regulii de sursă. | Iris, calculat | lunar | ||
| ERP Conta: cele 68 de activități, cu „încarcă” și „depune” pe declarații B1 PRD-ul Vertigo §11.2: la activitățile de import, Vertigo produce fișierul.csv sau.xml, iar contabilul îl descarcă și îl urcă în SAGA. | Vertigo · bifat de contabil; fișierele de import le generează tot Vertigo | lunar | ||
| Salarizare: D112 depusă, plata taxelor, plata salariului 6.2 | SalarEasy, plus potrivirea noastră pe extras | lunar | ||
| ?Reconciliere: ce nu s-a potrivit 4.7 | Nucleu · potrivirea noastră | după fiecare extras | ||
| Cont și abonament | Vertigo | rar | ||
83 de câmpuri: 79 de bifat și 4 amânate pentru V2, care nu se bifează. La 10 dintre ele sursa nu e limpede nici pentru noi. Întrebările de mai jos sunt 13, fiindcă unele — vectorul fiscal, P&L-ul — nu țin de un singur rând. Cele 24 de acțiuni ale clientului stau separat, mai jos, fiindcă n-au sursă.
Când balanța nu e cea așteptată
Cinci situații, cu ce face importul la fiecare. Din specificația Ralucăi. Regula de fond: mai bine o cifră veche, cu data ei, decât una nouă și greșită.
Ce-i cerem lui Bogdan
Tabelul de mai sus se bifează rând cu rând. Aici sunt cele 13 locuri unde un „da” nu ne ajunge, fiindcă sursa nu e limpede nici pentru noi. Unele acoperă mai multe rânduri din tabel, altele privesc un rând anume. La ele avem nevoie de un răspuns în cuvinte.
Dublin · acțiuni
Astea nu sunt date, deci n-au sursă: fiecare pornește din Dublin și se termină într-un motor. Stau aici ca lista să fie întreagă, dar nu e nimic de confirmat pe ele.
| Acțiunea | Unde se termină |
|---|---|
| Acasă | |
| Emite factura Modalul se deschide în pagină; seria și numărul vin de la serviciul de serii. | Facturare |
| Încarcă un document | Findocs |
| Caută în documente, facturi și cheltuieli | Nucleu |
| Facturi | |
| Emite rapid: client, sumă, valută | Facturare |
| Cazurile care nu merg rapid: persoană fizică, firmă străină, stornare | Facturare, precompletat |
| Descarcă PDF · trimite pe email | Facturare |
| Cheltuieli | |
| Confirmă sau infirmă o e-Factură primită | Nucleu, apoi Iris |
| Dă context sau întreabă pe un document | Iris, care reprocesează |
| Încarcă documentul unei plăți fără document | Nucleu, apoi Iris, care le potrivește |
| Extrase | |
| Încarcă extrasul lunii | Findocs, apoi Iris: parsare și potrivire |
| Adaugă un cont sau un IBAN | Vertigo · cerere la echipă |
| De plată | |
| Copiază detaliile de plată, gata de bancă | nicăieri — se copiază pe loc |
| Încarcă decizia de impunere | Nucleu |
| Banii tăi | |
| Semnează contractul de împrumut Contractul se generează când vedem transferul, nu înainte. | Rex |
| Angajați | |
| Angajează În MVP doar auto-angajarea administratorului. | SalarEasy |
| Aprobă statul de plată | Vertigo |
| Descarcă fluturașul | SalarEasy |
| Contabilitate | |
| Descarcă un document | Vault |
| Trimite un document pe email sau WhatsApp | Dublin |
| Cere un document | Vertigo · task la echipă |
| Firma ta | |
| Copiază o valoare, sau pachetul de date de facturare | nicăieri — se copiază pe loc |
| Cere codul VIES, un document, adaugă IBAN | Vertigo · task la echipă |
| Contul tău | |
| Schimbă cardul | modulul de abonamente |
| Anulează abonamentul | Vertigo · cerere la echipă |
6
19 întrebări fără răspuns întreg. La fiecare: ce lipsește, ce propunem unde avem o propunere, și cine răspunde. Contextul stă pliat sub fiecare. Termene nu sunt: sarcinile stau în Batman. Mai jos, separat, testele pe SAGA, ce e amânat pentru V2 și ce nu scrie încă nicăieri. Ce s-a lămurit e în istoricul întrebărilor.
Ce lipsește. Ce notă contabilă iese pentru documentele atipice și în ce format.
O declarație vamală, un proces verbal de casare, un contract, o poliță trebuie citite, dar nu produc note contabile. Drumul de mai sus se termină cu „se creează o cheltuială”; astea nu creează nimic și nu știm unde ajung, ce status au, cine le vede.
Ce știm. Nehotărât încă: nu s-a stabilit ce devin contabil documentele care nu sunt tranzacții.
Hotărât deja. Clientul poate încărca orice, inclusiv poze fără nicio valoare contabilă. Iris face triajul: ce e evident merge pe drumul obișnuit, ce nu e evident intră într-o zonă separată a Iris, unde citește un om sau un model mai bun (BGN).
Ce lipsește. Dacă cerem dovada plății, și ce facem cu banii scoși de la bancomat și plătiți cash.
Ce propunem. La bifă, clientul atașează dovada plății. Altfel se pot aduna pe furnizor facturi trecute ca plătite care n-au fost plătite (Raluca).
Un bon plătit din buzunarul asociatului înseamnă bani pe care firma i-i datorează; același bon plătit din contul firmei nu înseamnă nimic în plus. Nimic din document nu spune care din două. Dacă ghicim greșit, „De recuperat” de pe Acasă arată o cifră falsă, iar omul nu-și mai vede banii avansați.
Ce știm. Trei variante, niciuna aleasă: îl întrebăm pe client la încărcare; Iris deduce din document; sau ne uităm în extras, fiindcă o plată din contul firmei apare acolo. A treia nu merge singură — un bon plătit cash nu apare în niciun extras. Contabil, diferența decide contul: 542 pentru banii lui, 5121 sau 401 pentru banii firmei — dar întrebarea nu e contabilă, e ce-l întrebăm pe om și când.
Hotărât deja. Factura rămâne „neplătită” până apare plata în extras sau până bifează clientul că a plătit-o din banii lui (BGN). La bon, dacă plata nu apare în extras, e din banii omului (Raluca).
Ce lipsește. Când pleacă factura la SAGA și din ce clipă e blocată: la acceptul ANAF, la 24 de ore de la emitere sau la închiderea lunii.
Ce propunem. Facturile românești pleacă la acceptul ANAF pe e-Factura; cele străine, la 24 de ore de la emitere. Din clipa în care a plecat, factura e blocată — orice corecție e o stornare. Importul în SAGA se face în lot; lotul poate fi zilnic.
Dublin lasă azi „modifică factura”. Din clipa în care SAGA are o copie, orice modificare face două adevăruri. Trebuie o regulă: după cât timp pleacă, și că din clipa aia e blocată.
Ce știm. Trei variante: la 24 de ore de la emitere; la acceptul ANAF pentru cele românești; la închiderea lunii, în lot. Cristi: „în momentul în care pleacă către SAGA, aș bloca-o de la editare”.
Ce lipsește. Robot care le ia din folderele SAGA, sau rămâne upload manual.
Ce propunem. Același robot care duce datele în SAGA aduce și documentele înapoi, după închiderea fiecărei luni, cu luna și categoria pe ele. Fără om la mijloc.
Balanța, declarațiile, fișele de cont trebuie să ajungă la client, în Dublin, și în arhiva noastră. Dacă e un om, e o promisiune ținută de mână, lună de lună, pentru fiecare client.
Ce știm. Contabilul descarcă din SAGA și încarcă în Vertigo, buton cu buton. SAGA le salvează în foldere pe firmă; nu s-a verificat dacă automat. Minuta: roboții de declarații se grupează, nu unul per declarație.
Ce lipsește. Decizia de produs și cine construiește citirea din SPV; ce vede clientul la o factură emisă din alt program.
Dacă le luăm din SPV, o parte din documente nu mai trebuie cerute clientului — și dispar și task-urile care le cereau.
Ce știm. Pentru lei, XML-ul e-Factura e singurul document justificativ, nu PDF-ul (Raluca). Cristi: „luăm 100% din SPV”, ultimele 60 de zile. Facturile emise din alt program (Oblio, Excel) apar și ele în SPV — în MVP doar alertă (Prodi). Seriile sunt text liber în SPV; agregatorii care emit în numele firmei nu se suportă la început. Azi nimic nu citește SPV.
Ce lipsește. Dacă e-Factura trece pe la Iris doar pentru nota contabilă și deductibilitate, sau se ia așa cum vine.
Ce propunem. e-Factura sare peste Remix și peste citire — datele vin din XML — și ajunge la Iris doar pentru verdict: nota contabilă și deductibilitatea.
XML-ul e deja citit — are furnizorul, liniile, sumele. Ce lipsește e verdictul: nota contabilă și deductibilitatea.
Ce știm. Nimic hotărât: nu s-a stabilit dacă e-Factura mai trece pe la Iris sau se ia ca atare.
Ce lipsește. Cine e delegatul la ANAF, de când, cine apasă — și unde se ține asta în Vertigo. Fără el nu citim nimic din SPV.
Fără delegat nu putem lua nimic din SPV (circuitul 1). E primul lucru care se întâmplă cu un client nou.
Ce știm. Niciuna nu are încă răspuns. Vertigo §2 „Acces autorități” urmărește conectarea la cele 5 sisteme ale statului; există proiectele Onboarding (Teo) și Reprezentare autorități (Cristi).
Ce lipsește. Cine bifează o schimbare în profilul firmei, și dacă documentele deja procesate se recalculează în urmă.
Clientul cumpără o mașină pe 15 martie. Cine bifează, și când? Bonurile de combustibil din martie, deja procesate cu datele vechi, se recalculează sau rămân? Fără răspuns, deductibilitatea se schimbă în urmă fără ca nimeni să vadă.
Ce știm. Vertigo §9 are profilul firmei cu istoric pe fiecare atribut (valoare, de la, până la, autor). Câmpurile pe care le cere Iris sunt în PRD-ul Iris §6.3.
Ce lipsește. Dacă facem potrivirea facturilor și în SAGA. BGN ar face-o acolo, iar Raluca are nevoie de ea pentru confirmările de sold trimise clienților și furnizorilor la inventar, care ies din SAGA doar cu bifa pusă. Dacă bifa rămâne, robotul #7622 își păstrează rostul.
Alegerea are un preț de fiecare parte: dacă îi dai nota gata făcută, factura rămâne deschisă; dacă îi dai lista, cineva trebuie să aleagă.
Ce știm. Răspunsul e „amândouă, dar separat”. Contabilitatea intră ca notă și e corectă și fără bifă. Bifa e altceva și o pune robotul „Închidere încasări și plăți”, în Jurnal de bancă, cu potrivire în cascadă și mod simulare (spec Raluca #594, dezvoltare Alex #7622). Rulează pe Desktop, fiindcă facturile în euro nu apar în jurnalul de bancă din Web.
Hotărât deja. Îi dăm nota, și atât. În SAGA nu se face matching: la facturile în lei plătite în lei, nota e corectă și fără bifă, iar bifa n-are implicație contabilă, doar operațională. Excepția e factura în valută plătită din cont de lei, unde apare diferența de curs; nota pentru ea o produce Iris. Potrivirea o facem la noi, pentru ce arătăm clientului și pentru plățile fără document.
Ce lipsește. Direct în bază sau printr-un API — și, dacă e API, ce rute și ce evenimente. PRD-ul Dublin spune explicit a doua variantă; aici nu e hotărât.
Decide cine e stăpânul datelor: dacă Findocs scrie direct, Atom e o bază comună; dacă scrie prin API, Atom e un serviciu cu reguli, aplicate o dată pentru toți cei care vor scrie după el.
Ce știm. E întrebarea lui Prodi: „scriu direct în baza de date, asta e o variantă; cealaltă e prin API”. Findocs are task-ul #7589 (stocare + API documente). Chris: Nucleu e baza lui Dublin și a lui Vertigo; Facturare pune facturile în el și tot acolo vine răspunsul e-Factura. Textul de arhitectură din PRD-ul Dublin nu se preia — acolo scrie explicit „nu bază partajată: nimeni nu intră direct în baza nucleului, totul prin API + evenimente” —, deci cum e trebuie spus aici.
Ce lipsește. Locul (unul sau două), cheia (număr + dată + CUI emitent, sau amprenta fișierului) și mesajul către client.
Același document poate veni de la client, din SPV și din e-mail. Dacă îl înregistrăm de două ori, apare de două ori în contabilitate; dacă îl respingem greșit, clientul rămâne convins că a pierdut un document.
Ce știm. SAGA refuză singur un import cu același număr și aceeași dată, dar doar la import, și numărul trebuie identic literă cu literă. Trei locuri propuse: Vertigo blochează ce a trimis deja, robotul verifică în baza lui, SAGA refuză. Rămâne de spus dacă robotul și Vertigo verifică amândoi.
Ce lipsește. Ce confirmare primim după import: un job cu rezultat — acceptat, respins, parțial — și citirea înapoi după număr și dată. De ea depind blocarea facturii, deduplicarea și eticheta „în contabilitate”.
Ce propunem. Fiecare fișier trimis e un job cu rezultat: acceptat, respins sau parțial, cu erorile SAGA. După job, robotul citește înapoi din Firebird documentele trimise, după număr și dată; doar ce e găsit se marchează „în contabilitate”. Recipisa se păstrează în Vault.
Fără confirmare, Nucleu nu știe dacă o factură trimisă a și intrat — deci nu poate bloca editarea (3.1), nu poate deduplica (1.3) și nu poate arăta „în contabilitate” pe ecranul clientului.
Ce știm. Robotul Import XML-uri citește mesajele SAGA („importul a fost realizat cu succes”, „s-au importat N înregistrări”, raportul de erori la import parțial), dar nimic nu ajunge înapoi la noi. Job-urile din API au rezultat doar pentru onboarding.
Ce lipsește. Dacă statusul se citește din SAGA (ține de B2), cât de des — Prodi: la un interval; Cristi: o dată pe lună, la închidere; Vlad: zilnic, cu Open Banking — și ce afișăm între două citiri.
Statusul „încasată / plătită” din Dublin e o listă de documente deschise ținută la zi. Trebuie știut ce e „deschis” și când se împrospătează.
Ce știm. Un document neînchis = o factură neachitată sau neîncasată, integral sau parțial; SAGA le ține așa, cu data plății. Noi ținem în Atom toate facturile cu statusul lor. Statusul e al nostru, din potrivire, iar la facturile în lei în SAGA nu se mai pune bifa — deci la ele n-ar fi ce citi înapoi. Depinde de B2. Extrasul lunii se încarcă luna următoare (PRD Dublin §5).
Hotărât deja. Definiția e hotărâtă: neachitată sau neîncasată, integral sau parțial; stornarea închide.
Ce lipsește. Cine generează fișierele: PRD-ul Vertigo (§11.2) spune că Vertigo le produce, specificația SAGA le cere de la noi, iar generatorul nu există.
Fără formatul exact, nimic nu intră în SAGA. Aici s-au bătut cap în cap două specificații: CSV-urile din mai și XML-ul din septembrie.
Ce știm. Specificația e hotărâtă și scrisă: PRD Import SAGA v3.0 (Raluca) — XML pentru facturi emise și primite, cu lei și valută la un loc, XML pentru plăți și încasări, CSV pentru notele de salarii. CSV-urile vechi de pe Desktop sunt arhivate. Partenerii se creează automat la importul facturilor, din antet. Robotul Import XML-uri există pe SAGA Web (Alex, #7617) și a mers pe un fișier de test.
Hotărât deja. XML pentru facturi, plăți și încasări; CSV pentru salarii și pentru mijloacele fixe. Robotul de import există.
Ce lipsește. Ce are voie să facă omul nostru la fiecare situație nepotrivită: leagă de mână, împarte o plată pe două documente, desface o potrivire, cere document, ignoră.
Robotul raportează liniile pe care nu le poate închide — salarii, parțiale, „fără facturi”. Cineva trebuie să le rezolve, și trebuie spus ce are voie să facă: să lege de mână, să împartă o plată pe două documente, să desfacă o potrivire.
Ce știm. Spec-ul robotului (#594) descrie raportul, în simulare și în live. Nepotrivirile ajung la om; la salarii, telefon la client. Ecranul e în spec-ul Vertigo; operațiile permise nu sunt scrise.
Ce lipsește. Tabelă sau calcul la afișare; ce trece o taxă pe „plătit” — extrasul sau balanța următoare; ce arătăm până vine balanța.
Ce propunem. Starea pe luni se calculează după ordinea din lege, din balanțele lunare păstrate la noi, și se verifică o dată pe lună cu fișa rol din SPV, care se poate cere automat prin serviciul web al SPV, cu accesul firmei (9.1).
Dublin arată taxele pe luni, plătit / neplătit. SAGA arată cât s-a plătit în lună, nu ce lună s-a stins.
Ce știm. SAGA arată cât s-a plătit în lună, nu ce lună s-a stins: contabilul împarte plata pe conturi de mână, după balanță, iar socoteala pe luni trebuie ținută în afara SAGA (Raluca). Legea nu spune „cea mai veche întâi”: plata din contul unic se împarte întâi pe bugete — stat, pensii, sănătate —, proporțional cu cât datorezi fiecăruia; în fiecare buget merge întâi la ce e reținut la sursă (impozitul pe salarii, CAS, CASS, impozitul pe dividende), apoi la restul, apoi la accesorii; abia apoi se stinge scadența cea mai veche (Codul de procedură fiscală, art. 165, și metodologia ANAF a contului unic). CAM-ul și TVA-ul nu intră în contul unic. BGN: starea pe luni se poate calcula la afișare, din balanță, fără o tabelă ținută de mână. Riscul lui Prodi rămâne: un extras trimis peste două luni amestecă perioadele.
Ce lipsește. Repartizarea și starea unei distribuiri — nedistribuit, decis, ridicat, impozit plătit —, ținute pe fiecare perioadă (BGN). Contul impozitului (446.01) și momentul, la plată, sunt în „Ce publicăm”.
Două cifre de pe ecranul Acasă — dividendul net și impozitul — n-au sursă.
Ce știm. Scenariul „Dividendele” din aplicație e desenat și așteaptă review.
Ce lipsește. Cum se împacă „analiticul îl dăm noi” cu „partenerii se creează automat din antet”.
Analiticul (401.x, 4111.x) e cheia după care se potrivesc plățile cu facturile. Dacă îl alocă SAGA, trebuie citit înapoi; dacă îl alocăm noi, trebuie trimis.
Ce știm. SAGA potrivește partenerul după cod fiscal, apoi nume, apoi cod, iar dacă nu-l găsește îl creează; analiticul se poate da din fișier — testat cu doi clienți pe același analitic. Hotărârea e ca Vertigo să-l genereze, dar specificația v3.0 creează partenerii automat din antetul facturii și n-are câmp de analitic.
Ce lipsește. Cheia care leagă firma din SAGA de firma din Vertigo, și unde o ținem.
Primul lucru care se întâmplă cu un client: firma trebuie să existe în SAGA, configurată la fel ca la noi.
Ce știm. Robotul de onboarding există, a rulat live pe 9 iulie și creează firma din datele trimise de Vertigo: configurarea societății, planul de conturi, IBAN-ul, seriile. Doar pe Desktop — în Web nu se poate crea o firmă. Cât rulează, laptopul e ocupat.
Hotărât deja. Robotul duce firma până la capăt.
Nu sunt decizii, sunt verificări: ce se măsoară, și cine face fiecare jumătate — contabilul pregătește și rulează în SAGA, dezvoltatorul citește și compară baza.
Ce se verifică. Taxele. La testul de până acum închiderile de TVA și de impozit nu au rulat, iar firma nu avea venituri, deci nu a ieșit profit. Unde scrie SAGA o taxă calculată rămâne întrebarea care blochează ecranul „De plată”.
Ce s-a aflat. Amândouă lasă urmă, într-un loc mic și determinist. Data „închis până la” din antetul firmei e cel mai ieftin mod de a afla ce lună e închisă.
Contabilul: pregătește firma de test cu venituri, TVA și impozit, și rulează închiderea — inclusiv „Închidere TVA” și „Impozit profit/venit”, în ordinea corectăDezvoltatorul: copia bazei înainte și după, diff-ul, și citirea celor trei tabele
Ce se verifică. Formatul fiecărei listări, ca să știm ce citim și ce doar arhivăm.
Contabilul: generează din SAGA fiecare document — balanța, D300, D100, D406, S1120 — ca să existe ce căutaDezvoltatorul: unde au aterizat pe disc: folder, nume, format
Ce se verifică. Numele și locul fișierelor; dacă suma se ia din câmp sau doar din text.
Contabilul: generează din SAGA fiecare document — balanța, D300, D100, D406, S1120 — ca să existe ce căutaDezvoltatorul: unde au aterizat pe disc: folder, nume, format
Ce se verifică. Pașii din interfață pe o firmă cu venituri, TVA și impozit — inclusiv cazurile grele: cinci facturi stinse cu o plată, o plată parțială, taxe pe trei luni plătite deodată.
Contabilul: închide o lună pe firma de test și, la nevoie, o redeschide din SAGADezvoltatorul: importul XML-ului cu dată în luna închisă, și diff-ul pe cele trei tabele
Ce se verifică. Încasarea în valută n-a fost testată. Plata parțială se poate bifa în SAGA, cu suma ei (Raluca).
Face: Raluca — încasarea în valută · Alex — citirea înapoi
Lucruri pe care un PRD complet le are și ăsta nu. Nu sunt întrebări puse cuiva încă; omul de lângă fiecare e propus.
Anexa A
Unde se întrerupe drumul unei cifre de la sursă la ecran, și de ce se întrerupe în aceleași patru feluri peste tot. Sursa fiecărui câmp e în anexa D; drumul pas cu pas, ecran cu ecran, se parcurge în aplicație.
Cum se citește
Anexa asta a pornit ca un tabel cu fiecare cifră din Dublin și lanțul ei de pași până la sursă. Tabelul a fost înlocuit de anexa D, care spune același lucru mai scurt: de unde vine fiecare câmp și cât de des se actualizează. Lanțul pas cu pas, cu culori, se vede în aplicație, la Circuitul apei, unde poate fi parcurs ecran cu ecran.
Ce rămâne aici e concluzia, singura parte care nu se vede dintr-un tabel: rupturile nu sunt multe și diferite, sunt patru, și fiecare apare pe mai multe ecrane deodată.
Modelul de fond, hotărât: Nucleu ține și rutează, Iris citește documente, SAGA calculează, iar Dublin și Vertigo afișează.
Cele patru
Drumul unei cifre de la sursă la ecran se rupe în multe locuri, dar rupturile nu sunt toate diferite: sunt patru, și fiecare apare pe mai multe ecrane deodată. De-asta merită numite o dată, aici, în loc să fie repetate la fiecare circuit.
Două lucruri pe care ecranele le arată fără nicio operațiune în spate: vectorul fiscal — nu există sincronizare cu ANAF; și conturile de trezorerie — contul unic, CAM și TVA, la trezoreria de care ține firma, pe care nu le ține încă nimeni.
Și consecința hotărâtă: cifrele de profit, cheltuieli deductibile și impozit se actualizează o dată pe lună, iar Dublin le arată cu data ultimei actualizări, fără să estimeze nimic. Cifrele de pe ecranul Facturi sunt ale lui Dublin, în timp real, și nu vor bate cu SAGA la un moment dat. S-a hotărât că așa rămâne: lista facturilor se citește din Nucleu, fiindcă factura nu e o cifră calculată de contabilitate, ci documentul făcut de client, iar el trebuie să-l vadă pe loc.
Anexa B
Ce intră în SAGA, ce iese, și ordinea operațiunilor: configurarea, luna, trimestrul, anul, ocazional. Din checklist-ul ERP și din specificația fișierelor.
Cum se citește
Fiecare operațiune are un declanșator și un rezultat, iar rezultatul unuia îl pornește pe următorul. Coloana „Intră → Iese” spune ce fișier trece prin pasul acela: săgeata în jos e ceva ce ducem noi în SAGA, săgeata în sus e ceva ce scoatem. Căile de meniu sunt cele din SAGA Desktop, din checklist-ul ERP.
Import și export
Intră prin cinci fișiere, în ordinea de mai jos: facturile înaintea plăților, fiindcă numărul facturii din plată trebuie să existe deja în SAGA. Partenerii se creează singuri, din antetul facturii. Specificația e PRD Import SAGA v3.0: XML peste tot, CSV doar la salarii. Fișierele CSV din specificația de mai, pentru furnizori, clienți și facturi, sunt arhivate.
| # | Fișier | Ce conține | Structura | Pas ERP | Unde se încarcă |
|---|---|---|---|---|---|
| 1 | F_<CIF>_EMISE_<data>.xml | facturile emise ale lunii, lei și valută la un loc; o secvență pe factură, toate liniile sub același antet. CIF-ul firmei în antet = SAGA le duce în Ieșiri | <Facturi><Factura><Antet> … <Detalii><Continut><Linie> | B3 | Diverse → Import date |
| 2 | F_<CIF>_PRIMITE_<data>.xml | facturile și bonurile primite, lei și valută; contul de cheltuială pe fiecare linie; deductibilitatea limitată se marchează pe linie | același antet; pe linie: Descriere · Cantitate · Pret · ProcTVA · Cont · TipDeducere | B5, B8 | Diverse → Import date |
| 3 | Import_note_contabile_salarii_<luna>.csv | notele de salarii, cu conturile și explicațiile fixe; se completează doar data, numărul notei și sumele | DATA,NDP,CONT_D,CONT_C,SUMA,EXPLICATIE | B12 | Operații → Articole contabile → Import |
| 4 | P_<data>.xml | plățile lunii, lei și valută; contul băncii pe o parte, analiticul furnizorului sau un cont de cheltuială pe cealaltă; numărul facturii, opțional | <Plati><Linie> Data · Numar · Suma · Curs · Cont · ContFurnizor · Explicatie · FacturaNumar · CodFiscal · Moneda | B10 | Diverse → Import date |
| 5 | I_<data>.xml | încasările lunii, la fel, cu analiticul clientului | <Incasari><Linie> aceleași elemente, cu ContClient | B10 | Diverse → Import date |
| — | import imobilizări (CSV) | mijloacele fixe; din codul de clasă, SAGA completează durata, tipul de amortizare și conturile | NR_INV,DENUMIRE,DATA,CLASA,VALOARE | B7 | Operații → Imobilizări → Import (robot, #7582) |
Iese pe trei canale. Listările din Situații: balanța, registrul jurnal, cartea mare, fișele de cont, jurnalele de TVA, registrele. Declarațiile, ca fișiere de depus: D100 și D406 ca XML, bilanțul interimar ca XML și arhivă, restul de confirmat. Și baza Firebird a firmei, un fișier pe firmă, la care avem deja conexiune.
De reținut: SAGA n-are un export făcut pentru noi. Ce iese e făcut pentru contabil sau pentru ANAF. Tot ce vrea Dublin — taxa de plată, factura încasată, luna închisă — se citește ori din aceste fișiere, ori direct din bază.
A · o singură dată, la firmă nouă
Până nu sunt bifați A1–A5, restul checklist-ului e blocat. Primii patru pași îi face deja robotul de onboarding din saga-automation-api, cap-coadă, cu datele din profilul firmei.
| Cod | Operațiunea | În SAGA | Intră → Iese | Declanșator · după |
|---|---|---|---|---|
| A1 | Configurare firmă nouă: denumire, CUI fără RO, J, CAEN, capital, sediu, regim micro, regim TVA, luna de început; apoi „Preluare date contabile" → Validez, care aprinde meniul firmei | Administrare → Configurare societăți → Adaug → Salvez | profilul firmei din Vertigofirma există în SAGA, cu cod 000N și propriul cont_baza.fdb | Onboarding: semnare documente · robotul apasă „No" la „Cod fiscal incorect. Continuăm?" și oprește |
| A2 | Plan de conturi: se adaugă 5121.01 (lei), 5124.01 (euro), 5124.02 (dolari) — exact conturile pe care le folosesc fișierele de plăți | Fișiere → Plan de conturi → Adaug → Salvez | analiticele de bancă | Onboarding · deschis: set fix sau doar valutele clientului? |
| A3 | IBAN — Cont 1 în fișa societății, cu banca și filiala | Administrare → Configurare societăți → Sediu social → Cont 1 | IBAN din Conturi bancare | Onboarding — deschidere cont bancar · deschis: banca și filiala din IBAN sau date de noi? |
| A4 | Seriile de facturi: „Factură de ieșire" → An, primul și ultimul număr | Administrare → Numere și Serii → Adăugare | seria din Facturare | Primește dreptul de facturare · deschis: de unde vin numerele; doar factura de ieșire? |
| A5 | Subscrierea capitalului social — notă contabilă | Operații → Articole contabile | capitalul din profil | Configurare plan de conturi |
| A6 | Capitalul nevărsat devine vărsat — notă contabilă, o singură dată; dispare din catalog după | Operații → Articole contabile | dovada depunerii capitalului | Onboarding — depunere capital social |
B · în fiecare lună, pentru fiecare firmă
Ordinea nu e opțională: facturile intră înaintea băncii, fiindcă plățile se închid pe facturi; banca intră înaintea închiderii, fiindcă închiderea recalculează cursul pe soldurile băncii; declarațiile ies abia după balanță. Vertigo blochează pașii B23–B29 până e bifat B21.
| Cod | Operațiunea | În SAGA | Intră → Iese | Declanșator · după |
|---|---|---|---|---|
| B1 | Import furnizori noi | Fișiere → Furnizori → Import terți din fișiere | fișierul 1 (CSV, 9 coloane)SAGA creează analiticul 401.000NN al fiecăruia | Primire fișier de la Vertigo · la externi, două avertizări „cod fiscal incorect" — se apasă Yes la amândouă; duplicatul după cod fiscal nu se reimportă |
| B2 | Import clienți noi | Fișiere → Clienți → același import | fișierul 2 (CSV, 9 coloane)analiticul 4111.000NN | Primire fișier de la Vertigo |
| B3 | Import facturi emise | Operații → Ieșiri → Import | fișierul 5 (CSV, 10 coloane)4111 = 704 per factură | Primire fișier de la Vertigo · clientul trebuie să existe deja (B2) |
| B4 | Validare facturi emise | Operații → Ieșiri | documentele validate contabil | după B3 · Raluca: roboții de validare ar rula pe SAGA Web |
| B5 | Import facturi primite RO + bonuri fiscale | Operații → Intrări → Import | fișierul 3 (CSV, 11 coloane) — contul de cheltuială și cota TVA pe linie6xx = 401 per document | Primire fișier de la Vertigo · furnizorul trebuie să existe (B1) |
| B6 | Validare facturi și bonuri primite RO | Operații → Intrări | documentele validate | după B5 |
| B8 | Import facturi primite externe | Operații → Intrări → Import | fișierul 4 (CSV, 13 coloane) — MONEDA, T la taxare inversă628 = 401 + 4426 = 4427 la taxare inversă | Primire fișier de la Vertigo |
| B9 | Validare facturi primite externe | Operații → Intrări | documentele validate | după B8 |
| Cod | Operațiunea | În SAGA | Intră → Iese | Declanșator · după |
|---|---|---|---|---|
| B10 | Import extrase bancare — încasări și plăți, în lei și în valută. Un fișier per dată și monedă; fiecare linie poartă analiticul partenerului, nu numărul facturii | Diverse → Import date → selecție cale | fișierele 7 și 8 (P_ și I_ XML)operațiunile în jurnalul de bancă, pe 5121.01 / 5124.01 / 5124.02 | Primire fișier de la Vertigo · diferența de curs o scriem noi, ca linie separată pe 6651 |
| B11 | Corelarea plăților și încasărilor cu facturile — SAGA arată facturile neînchise ale partenerului; la sumă egală bifează singur, altfel alege omul | Operații → Jurnal de bancă | facturile închise; soldul 401 / 4111 per partener | după B10 · de verificat: se poate sări peste ecran trimițând nota contabilă gata făcută? |
| Cod | Operațiunea | În SAGA | Intră → Iese | Declanșator · după |
|---|---|---|---|---|
| B7 | Import mijloace fixe — laptopul peste prag intră în lista de imobilizări, cu durata de amortizare | Operații → Imobilizări → Listă → Adăugare | CSV mijloace fixe (fără model testat)fișa mijlocului fix; amortizarea lunară se calculează la B18 | Primire fișier de la Vertigo |
| B12 | Import cheltuieli salariale — statul de plată ca note gata făcute | Operații → Articole contabile | fișierul 6 (CSV, 6 coloane) — din SalarEasy421, 444, 4315, 4316, 436 cu sumele lunii | Primire fișier de la Vertigo |
| B13 | Import înregistrări contabile diverse | Operații → Articole contabile → Import | CSV în același format ca la salarii | Primire fișier de la Vertigo |
| B14 | Dobânzi credit pe termen lung — 666 = 1682 | Operații → Articole contabile | notă contabilă | doar firmele cu credit |
| B15 | Dobânzi credit pe termen scurt — 666 = 5198 | Operații → Articole contabile | notă contabilă | doar firmele cu credit |
| B16 | Înregistrare impozit dividende interimare | Operații → Articole contabile | notă contabilă 457 = 446 | Plata dividendelor interimare · vezi E3–E5 |
| Cod | Operațiunea | În SAGA | Intră → Iese | Declanșator · după |
|---|---|---|---|---|
| B17 | Reevaluare valutară — diferențele de curs la sfârșit de lună, pe soldurile în valută | Operații → Închidere lună → Calcul diferențe curs | 665 / 765 pe fiecare sold în valută — scrise de SAGA, nu de noi | Cut-off: ultima zi a lunii |
| B18 | Calcul amortizare lunară mijloace fixe | Operații → Închidere lună → Amortizare | 6811 = 281x per mijloc fix — scrise de SAGA | după B17 |
| B19 | Repartizarea lunară a cheltuielilor și veniturilor în avans | Operații → Articole contabile | notă contabilă 6xx = 471 | după B18 |
| B20 | Închidere conturi de venituri și cheltuieli — rezultatul lunii ajunge pe 121 | Operații → Închidere lună | 121 = 6xx / 7xx = 121 | după B19 |
| B21 | Închidere lună — blocarea lunii; de aici încolo nu se mai importă nimic în ea | Operații → Închidere lună | luna marcată închisă | după B20 · deblochează B22–B29 în Vertigo |
| Cod | Operațiunea | În SAGA | Intră → Iese | Declanșator · după |
|---|---|---|---|---|
| B22 | Generare balanță de verificare | Situații - Listări → Balanțe | balanța lunii → Vertigo „Încarcă" → Evidențe contabile → Dublin Contabilitate | după B21 · deblochează C1 |
| B23 | Verificare egalitate balanță — debit = credit | Situații - Listări → Balanțe | ok / nu | după B22 |
| B24 | D301 CUI — livrări și achiziții externe | Situații → Jurnal cump./vânz. → Decont 301 | declarația → Vertigo → depusă în SPV | după B22 · la decizia contabilului |
| B25 | D390 VIES — operațiuni intracomunitare | Situații → Jurnal cump./vânz. → D390 | declarația | după B22 · doar cu cod VIES |
| B26 | D100 lunar — impozitul pe dividendele interimare | Operații → Închidere lună → D100 | D100 ca XML — suma impozitului e în fișier | după B22 · doar în luna cu dividende plătite |
| B27 | D301 VIES — operațiuni cu cod VIES | Situații → Jurnal cump./vânz. → Decont 301 | declarația | după B22 |
| B28 | D112 — contribuții și impozit pe salarii. Nu iese din SAGA: se generează în SalarEasy și se depune în SPV | SalarEasy → D112 → depunere SPV | D112 din SalarEasy → Vertigo | după B21 · obligatorie cu salariați |
| B29 | D311 — declarație de inactivitate. Nu iese din SAGA: direct în SPV | Depunere în SPV | — | după B21 · doar la inactiv fiscal / inactiv TVA |
C · la fiecare trimestru
C1 se deblochează după balanța ultimei luni din trimestru și deblochează la rândul lui tot restul. Impozitul pe venit sau pe profit — cifra din ecranul „De plată" al lui Dublin — se calculează la C1 și pleacă la ANAF prin C2.
| Cod | Operațiunea | În SAGA | Intră → Iese | Declanșator · după |
|---|---|---|---|---|
| C1 | Calcul impozit pe venit (micro) sau pe profit, pe trimestru | Operații → Închidere lună → Impozit profit/venit | suma de plată pe 4411, cu scadența 25 a lunii următoare trimestrului | după B22 al ultimei luni · deblochează C2–C7 |
| C2 | D100 — impozit pe profit sau micro | Operații → Închidere lună → D100 | D100 ca XML → Vertigo → SPV | după C1 · obligatorie pentru toate firmele |
| C3 | D406 SAF-T — datele contabile ale trimestrului | Situații - Listări → Declarația 406 | D406 ca XML → Vertigo → SPV | după C1 · obligatorie |
| C4 | Generare registru inventar | Situații - Listări → Registru inventar | registrul → Vertigo Evidențe | la distribuire de dividende interimare |
| C5 | S1120 — bilanțul interimar | Situații - Listări → Bilanț → bifă „Situații financiare interimare" | XML + ZIP → Vertigo → SPV | după C4 · la decizia contabilului; cerut la dividende interimare |
| C6 | D710 — rectificativă pentru impozit | Situații - Listări → Declarații → D710 | declarația | când s-au emis facturi în afara perioadei |
| C7 | Registrul de evidență fiscală — doar la plătitorii de impozit pe profit | Operații → Închidere lună → Impozit pe profit | registrul → Dublin Contabilitate | după C1 |
D · o dată pe an
| Cod | Operațiunea | În SAGA | Intră → Iese | Declanșator · după |
|---|---|---|---|---|
| D1 | Constituirea rezervei legale — 5% din profitul brut, până la 20% din capital: 129 = 1061 | Operații → Articole contabile | notă contabilă | După aprobarea rezultatului în AGA |
| D2 | Repartizare profit pe rezerve legale — 129 = 1061 | Operații → Articole contabile | notă contabilă | după AGA |
| D3 | Transfer rezultat la rezultat reportat — profit: 121 = 1171 | Operații → Articole contabile | notă contabilă | după AGA · de aici vine „de distribuit" din Dublin |
| D4 | Transfer rezultat la rezultat reportat — pierdere: 1171 = 121 | Operații → Articole contabile | notă contabilă | după AGA |
| D5 | Repartizarea profitului pe dividende — 1171 = 457 | Operații → Articole contabile | notă contabilă + hotărârea AGA | după D6 |
| D6 | Hotărârea AGA de distribuire a profitului | act juridic separat, din șablon | documentul semnat — prin Rex | după aprobarea rezultatului |
| D7 | Inventarierea anuală — procese-verbale pe gestiuni, casă, mijloace fixe | Operații → Inventar — parțial | procesele-verbale | la inventarierea anuală |
| D8 | Registrul inventar anual | Situații - Listări → Registru inventar | registrul → Vertigo Evidențe → Dublin | la inventarierea anuală |
| D9 | D101 — impozitul pe profit anual, plătitorii de 16% | Situații - Listări → D101 | declarația → SPV, 25 martie | la închiderea exercițiului · nu apare la micro |
| D10 | D406 SAF-T Active — situația activelor | Situații - Listări → D406 Active | declarația → SPV | la închiderea exercițiului |
| D11 | Situațiile financiare anuale — bilanț, cont de profit și pierdere, note | Situații - Listări → Bilanț (S1003 / S1005) | bilanțul → Vertigo → Dublin | la închiderea exercițiului · deblochează D12 |
| D12 | Depunerea situațiilor financiare la ANAF — 150 de zile de la închidere | Situații - Listări → Bilanț → depunere SPV | recipisa → Vertigo „Depune" | după D11 |
| D13 | D205 — rețineri la sursă, anual | Situații - Listări → D205 | declarația → SPV, 28 februarie | la decizia contabilului |
E · când se întâmplă
Se înregistrează din catalog, cu data evenimentului, și aterizează în luna aleasă. Trei dintre ele pornesc singure din profilul firmei: E11 la schimbarea regimului, E12 la schimbarea sediului, E13 la modificarea CAEN.
| Cod | Operațiunea | În SAGA | Intră → Iese | Declanșator |
|---|---|---|---|---|
| E1 | Modificare capital social | Operații → Articole contabile — parțial | act constitutiv nou | din profil, cu document |
| E2 | Casare sau vânzare mijloc fix | Operații → Imobilizări → Casare/Vânzare | proces-verbaliese din lista de imobilizări; amortizarea se oprește | din profil, cu PV |
| E3 | Distribuire dividende interimare | Operații → Articole contabile — parțial, cere AGA | hotărârea AGA + bilanț interimar (C5) | decizia asociaților |
| E4 | Calcul impozit dividende interimare | Operații → Articole contabile | suma pe 446 → D100 lunar (B26) | după E3 |
| E5 | Înregistrare impozit dividende interimare | Operații → Articole contabile | notă contabilă | după E4 |
| E6 | Înregistrare impozit dividende anuale | Operații → Articole contabile | notă contabilă | după D5 |
| E7 | Regularizare dividende interimare | Operații → Articole contabile | notă contabilă | la închiderea anului |
| E8 | Calcul impozit dividende finale | Operații → Articole contabile | suma pe 446 | după D5 |
| E9 | Dobândă penalizatoare la restituirea dividendelor interimare excedentare | calcul manual | notă contabilă | când interimarele au depășit profitul final |
| E10 | D205 — rețineri la sursă | Situații - Listări → D205 | declarația | la evenimentul fiscal |
| E11 | Schimbare regim TVA sau regim micro | depunere D700 în SPV; apoi actualizarea firmei în SAGA | D700 + recipisă | automat din profil |
| E12 | Schimbare sediu social | ONRC + ANAF; apoi fișa societății în SAGA | 4 documente | automat din profil |
| E13 | Schimbare obiect de activitate, CAEN secundare | ONRC; apoi fișa societății în SAGA | 3 documente | automat din profil |
Drumul înapoi
Azi drumul înapoi e un om: contabilul descarcă din SAGA și apasă „Încarcă" în Vertigo, la activitatea corespunzătoare; de acolo documentul ajunge în Contabilitate › Evidențe sau Declarații, iar Dublin îl citește din Nucleu. Pentru declarații mai e un pas: „Depune", cu indexul ANAF și recipisa. Nimic din drumul ăsta nu e automat.
| Ce vrea Dublin | Unde se naște în SAGA | Cum ajunge la noi azi | Cum ar putea ajunge |
|---|---|---|---|
| Taxa de plată: tip, sumă, scadență | C1 (Închidere lună → Impozit) pe 4411 · B26/C2 D100 · B12 pe 444/4315/4316/436 · E4/E8 pe 446 | nu ajunge — ecranul din Dublin n-are sursă | D100 e XML: se citește suma din fișier la „Încarcă" · sau soldul contului din Firebird |
| Taxa plătită | B10 + B11: plata către trezorerie intră pe 5121 = 44x | nu ajunge | soldul 44x scade după import — de verificat dacă SAGA închide singur — testul Ralucăi, #7668 |
| Factura încasată / cheltuiala plătită | B11: Jurnal de bancă închide 4111 / 401 per document | nu ajunge | starea de închis per document, din Firebird sau din listarea de solduri |
| Balanța, registrul inventar, fișele | B22, C4/D8, Situații - Listări | om: descarcă → Vertigo „Încarcă" | robot pe același drum, după B21 |
| Declarațiile cu recipisă | B24–B27, C2–C6, D9–D13 | om: descarcă → „Încarcă" → depune → „Depune" cu index + recipisă | robot descarcă + depune (4 Secunde) + scrie recipisa |
| „Ultima lună închisă" | B21 | data „închis până la” din antetul firmei, plus registrul închiderilor pentru ce anume s-a închis | confirmat, testul A2 |
| Dividende de distribuit, împrumuturi, deconturi | D3 pe 1171, 121 · 4551 · 542 | nu ajunge | solduri din balanță sau din Firebird |
Anexa C
Trei scenarii: cum se citește baza SAGA, cum se scrie în ea prin fișiere, și drumul unui document cap-coadă. Fiecare cu ce e stabilit și ce rămâne de lămurit.
A · 8 scenarii
Tot ce arată Dublin despre contabilitate vine de aici. Dacă nu putem citi, nu avem ce arăta.
Cum se citește baza SAGA — regulile, din testele lui Alex
B · 8 scenarii
Tot ce facem noi ajunge în SAGA prin import. Formatul îl dictează el; noi trebuie să știm exact ce acceptă.
Nu e hotărât încă: B1 · B2 · B5 — sunt în Ce e deschis, la omul care răspunde.
C · 7 scenarii
Ce se întâmplă în SAGA la evenimentele pe care Dublin trebuie să le arate.
Nu e hotărât încă: C5 · C6 — sunt în Ce e deschis, la omul care răspunde.
De consultat
Cele 28 de întrebări lămurite, câte o linie: răspunsul scurt și de unde vine. Răspunsul întreg a intrat în pașii circuitelor, în „Ce publicăm” sau în decizii. Numerele rămân aici, ca linkurile trimise în Slack și în Batman să ducă undeva.