roacont/TODOS.md

TODOS — ROACONT

Generat de /autoplan (review PRD eFactura OAuth2) pe 2026-07-07.

P2 — Token broker pe romfast.ro (decizie de business)

• Ce: Serverul păstrează refresh token-urile per client și servește access token-uri la cerere; zero gestiune de token în aplicație, sincronizare multi-stație automată.
• De ce: Cabinetele de contabilitate au multe stații; azi tokenul se gestionează per instalare. Broker-ul elimină complet subiectul „token" din aplicație.
• Pro: UX 10x (nicio generare per stație); suport aproape zero pe subiect.
• Contra: Vendorul devine custode al accesului la datele fiscale ale clienților — răspundere, GDPR, consimțământ contractual. Decizie comercială, nu tehnică.
• Context: Arhitectura aleasă în PRD (server deja intermediar la schimbul code→token, stocare temporară cu state) lasă ușa deschisă. De pornit de la PRD_efactura_oauth2_autoflow.md, secțiunea „Variante respinse".
• Efort: L (uman) → M (cu CC). Depinde de: decizie comercială + analiză GDPR.

P3 — Avertizare proactivă expirare certificat calificat

• Ce: ROA avertizează cu N zile înainte de expirarea certificatului din SPV (diferit de expirarea tokenului, deja acoperită de RefreshTokenAuto).
• De ce: Certificatul expirat = eFactura moartă + drum la furnizorul de semnătură; utilizatorii află abia când eșuează.
• Pro: elimină o categorie de urgențe. Contra: data expirării certificatului nu e azi persistată în ROA — necesită captură la generarea tokenului (JWT-ul ANAF conține serialul certificatului) sau introducere manuală.
• Efort: M → S. Depinde de: decodare JWT în ROA sau câmp nou în opțiuni.

P3 — Extinderea infrastructurii state+pickup la celelalte produse ROA

• Ce: Aceeași pereche index.php/pick.php + funcțiile VFP mutate în COMUNROA pentru ROAGEST, ROACASA etc.
• De ce: Toate produsele suitei au aceeași problemă de token eFactura.
• Pro: o singură implementare întreținută. Contra: blast radius COMUNROA (schimbările ripple în toate produsele — vezi CLAUDE.md „Shared code").
• Efort: M → S. Depinde de: stabilizarea fluxului în ROACONT (un ciclu de release).

Lansare automată a fluxului de token nou la eșec definitiv de refresh — PRELUAT

Decis la poarta /autoplan (D3, 2026-07-07): utilizatorul o implementează direct în VFP (legarea mesajului de expirare refresh de apelul newToken). Nu mai e item deschis aici.

Amanari review /autoplan — verificare ANAF la alegerea partenerului (26.07.2026)

Sursa: docs/design-alegere-partener-anaf.md, REVIZIA 4 (implementata doar nivelul 1).

P2 — Guard de duplicat pe CUI normalizat la crearea partenerului

• Ce: La crearea unui partener nou, verificare ca nu mai exista alt partener activ cu acelasi CUI normalizat (NormalizeazaCUI); avertizare/blocare inainte de salvare.
• De ce: stratul cel mai ieftin de prevenire a duplicatelor — netratat in 4 revizii ale verificarii ANAF la alegere, care acopera doar alegerea unui partener deja existent, nu crearea unuia nou. Cel mai bun raport cost/beneficiu dintre amanarile de mai jos.
• Pro: cost mic, taie problema la sursa. Contra: cazuri legitime de acoperit (sedii/puncte de lucru cu acelasi CUI).
• Efort: S. Depinde de: decizie UX blocare vs. avertizare.

P3 — Raport pasiv de discordante CUI + curatare duplicate de parteneri

• Ce: Raport cu partenerii care au discordante fata de ANAF (nume/stare TVA) si perechile de CUI duplicat, pentru curatare manuala periodica.
• De ce: REVIZIA 4 logheaza discordantele in goLog la alegere, dar fara raport datele brute nu arata tiparul.
• Efort: M. Depinde de: volum de date acumulat din logarea introdusa la REVIZIA 4.

P3 — Coloana "Ultim document" in cautarea de partener

• Ce: Coloana in gridul de cautare partener cu data ultimului document inregistrat pe acel partener.
• De ce: discriminatorul "are documente in perioada" din Detalii (REVIZIA 4) ajuta doar la alegere; o coloana in grid ar ajuta si la navigare fara deschiderea Detalii pe fiecare candidat.
• Efort: S-M. Depinde de: sursa ireg_parteneri, deja identificata in REVIZIA 4.

P3 — Prevenirea duplicatelor la import

• Ce: La import (facturi, extrase, eFactura), verificare CUI normalizat inainte de crearea automata a unui partener nou.
• De ce: importurile creeaza parteneri fara sa treaca prin formularul de creare manuala, deci guard-ul de mai sus (P2) nu acopera acest flux.
• Efort: M. Depinde de: guard-ul de duplicat pe CUI normalizat (P2 de mai sus).

P3 — Tooltip per rand in gridul de cautare

• Ce: Tooltip la hover pe randul din gridul de cautare partener, cu detaliile ANAF/discordanta randului respectiv.
• De ce: alternativa la click/F4 pe Detalii (REVIZIA 4), utila pe fluxurile cu mouse.
• Efort: S.

P3 — Marcaj colorat pe toate randurile din grid (nivelul 2 al RC_ANAF_VERIF_SELECTIE)

• Ce: Extinderea verificarii ANAF de la randul curent (nivelul 1, implementat) la marcaj colorat pe toate randurile din grid.
• De ce: amanat explicit la poarta /autoplan din 26.07.2026 (decizia D1/UC1) — risc de nedeterminism (timer unic, cursor de grid) si de rate-limit ANAF pe volum mare.
• Conditii de intrare (in aceasta ordine, nicio implementare inainte):
  1. Masuratori: latenta reala a unui apel ANAF la ore diferite; comportamentul la rafale (30 loturi x 20 CUI la interval scurt — de la al catelea vine 429).
  2. Date din loguri: cate discordante apar efectiv la pilot si in ce flux.
• Cerinte tehnice deja verificate (de nepierdut la implementare) — sectiunea 8 din docs/design-alegere-partener-anaf.md: UC1, D-F2, C4, H1, H4, H5, H8, H9, M1, M7.
• Efort: L. Depinde de: masuratorile de mai sus.
• Masurat partial (27.07.2026), vezi docs/plan-reparatie-anaf-404-breaker.md: latenta unui apel la ANAF sanatos 0,08 s; gazda care inghite pachetele 21,05 s fara timeout-uri, 4,00 s cu SetTimeouts(2000,2000,3000,3000); WinHTTP asincron Send() 0,009 s, WaitForResponse(0) 0 s. Ramane nemasurat comportamentul la rafale (de la al catelea 429).

P4 — Contract 404 pe drumul batch ANAF (D406 si sincronizari) — PRELUAT

Preluat 31.07.2026, povestea S5 din transa docs/contract-cache-anaf.md (docs/diff-S5-contract-404-batch.md).

• Ce: validare.prg:1827 citeste corpul raspunsului doar pe Status = 200, la fel cum facea si wrapper-ul single-CUI. Pe loturi, un CUI inexistent si o cadere de serviciu ajung la utilizator ca acelasi lucru ("nu s-a putut verifica").
• De ce: masurat 27.07.2026 — ANAF intoarce HTTP 404 cu corp complet {"found":[],"notFound":[<cui>]}, deci informatia exista, doar e aruncata. Regula corecta, stabilita si implementata pe calea single-CUI: verdict "inexistent" doar cand notFound contine chiar codul cerut (notFound apare si in raspunsurile de succes, ca tablou gol).
• Ce s-a facut deja in transa din 27.07: doar timeout-urile pe calea batch (~105 s de fereastra inghetata devin ~20 s pe 500 de coduri). Logica de verdict nu s-a atins.
• De ce nu acum: atinge interpretarea raspunsului in D406 si in sincronizari, deci cere runda proprie de teste pe declaratie, nu doar pe formularul de cautare.
• Efort: M. Depinde de: transa plan-reparatie-anaf-404-breaker.md (regula notFound).

P5 — Verificare ANAF dupa tara partenerului (punctul D)

• Ce: tara partenerului adusa in cursorul de cautare, ca cod_tara caracter (gol sau RO = se verifica), in locul euristicii pe primele doua litere din codul fiscal.
• De ce: dupa reparatia din 27.07, un partener extern cu cod pur numeric ajunge la ANAF si poate primi verdict rosu "Cod fiscal inexistent la ANAF". In MARIUSM_AUTO: 2825 parteneri, dintre care 21 cu alta tara — suprafata mica, dar reala si acum vizibila.
• Decizii deja luate (nu se redeschid): se verifica dupa tara, nu dupa literele codului; tara necompletata = Romania; respinse explicit de Marius — functie noua cu query per partener si selectia din VNOM_PARTENERI ("prea multe join-uri in adresa"). VALIDARE_CIF nu se atinge in nicio varianta (folosita in toata suita).
• Ramas de facut: lantul scurt NOM_PARTENERI → ADRESE_PARTENERI (principala=1) → SYN_NOM_LOCALITATI → SYN_NOM_JUDETE → SYN_NOM_TARI.PRESCURTARE, masurat fata de cautarea de azi (28 ms pe filtrul cont='401' and denumire like 'FA%'); al doilea drum, CautPartenerContabilitate (ocautare.prg ~890-960), selecteaza direct din tabela si cere join separat.
• Conditie de intrare: reclamatii pe parteneri externi marcati rosu, vizibile in logul de discordante (anaf_verif_cautare).
• Efort: M. Depinde de: masuratoarea lantului scurt.

Amanari review /autoplan — cache ANAF pe ISTORIC_CODURI_FISCALE (29.07.2026)

Sursa: docs/design-cache-anaf-istoric-coduri-fiscale.md, sectiunea GSTACK REVIEW REPORT.

P2 — Cascada de ferestre modale la verificarea in masa cu ANAF cazut

• Ce: AMESSAGEBOX este apelat in interiorul buclei pe grupuri din ANAF_SincronWebService_PlatitorTva (COMUN\programe\validare.prg:1968, :1970, :1976, :1993, :1996). La 3000 de parteneri = 30 de grupuri, deci pana la 30 de ferestre modale de inchis manual la o singura rulare de D406.
• De ce: cu ANAF cazut, plasa de siguranta introdusa de proiectarea din 29.07 lucreaza in spatele acestui zid de modale — castigul e invizibil pentru utilizator. Probabil mai valoros decat cache-ul insusi.
• Fix: un singur mesaj la sfarsitul rularii (numar de grupuri esuate), nu unul per grup.
• De ce nu acum: atinge interpretarea raspunsului pe traseul in masa (acelasi cod ca P4 de mai sus), deci cere runda proprie de teste pe declaratie.
• Efort: S-M. Depinde de: mock-ul pe calea batch (T1 din review).

P3 — Bucla O(n^2) la imperecherea rezultatului ANAF cu lista de parteneri

• Ce: COMUN\clase\overificari.vc2:2722 face LOCATE FOR ... liniar in interiorul unui SCAN peste cursorul de raspuns ANAF. Costul creste cu patratul numarului de parteneri.
• De ce: tranșa de cache adauga peste bucla un apel de procedura Oracle per cod, deci ambele cresc pe acelasi traseu.
• Conditie de intrare: masuratoarea ceruta oricum la E4, pe un lot de ~500 de coduri. Daca timpul e acceptabil, nu se atinge.
• Efort: M. Depinde de: masuratoarea de la E4.

P3 — Parsarea sarita cand primul rezultat nu are dcod_judet

• Ce: COMUN\programe\validare.prg:1986-1994 — daca found_vfpsafe_[1].adresa_domiciliu_fiscal.dcod_judet lipseste (cazul unui lot in care toate codurile sunt notFound, deci found e gol), se afiseaza fereastra de eroare "Serviciul web ANAF intors mesaj de eroare" si nu se parseaza nimic, desi raspunsul e valid.
• De ce: face ca un lot legitim de coduri inexistente sa arate ca o defectiune de serviciu.
• Efort: S. Depinde de: acelasi contract 404 pe calea batch (P4 de mai sus).

P3 — DATATVAMFIN ramane text

• Ce: VARCHAR2(30) din 2012, afisat direct la COMUN\programe\oproceduri_comune.prg:4783. Noile coloane de interval il fac redundant.
• De ce nu acum: decizia explicita a proiectarii din 29.07 (Intrebarea deschisa 2).
• Efort: S. Depinde de: livrarea coloanelor de interval.

Amanari transa cache ANAF — completare (01.08.2026)

Sursa: docs/diff-TRANSA-cache-anaf.md, docs/handoff_cache_anaf.md.

P1 — Rulare reala prin PACK_UPDATE pe TEST, inainte de prima livrare (decizie de EXECUTIE)

• Ce s-a facut deja: cele trei scripturi ale transei (co_2026_07_30_02_RTVAI_PACK_ROARTVAI.sql, co_2026_07_31_01_COMUN_ISTORIC_CF.sql, ff_2026_07_31_01_COMUN_ISTORIC_CF.sql) figurau "aplicate" in tabela versiune din rulari manuale sqlplus, desi coada reala UPD_DATABASE nu avea niciun rand pentru ele. Randurile s-au curatat (CONTAFIN_ORACLE -9, MARIUSM_AUTO -7, ACN -1, zero randuri ramase pentru cele trei scripturi) si toate trei s-au dovedit re-rulabile (DDL gardat, inserturi where not exists, pachete CREATE OR REPLACE) — nu mai e nicio decizie tehnica de luat.
• Ce ramane: doar executia propriu-zisa prin PACK_UPDATE, netrasa inca. SCRIPTURI_CLAR mai contine scripturi straine de transa, neaplicate — daca motorul ia tot ce gaseste pe disc, ar rula si munca in lucru a altcuiva pe un server de test partajat. Banda Oracle stabileste pe sursa daca fluxul se poate limita la cele trei fisiere ale transei.
• Efort: S. Depinde de: decizia lui Marius de a executa PACK_UPDATE pe TEST (nimeni n-a apasat butonul inca); detaliu complet docs\audit-oracle-final.md.

P3 — Export Excel din verificarea in masa (D406/D394) nu duce mai departe provenienta cache

• Ce: Programe\orapoarte.prg (Copy To ... Type Xl5) nu adauga sursa/data_sursa in fisierul exportat — un fisier trimis mai departe nu arata ca o parte din verdicte vin din cache, nu dintr-un raspuns proaspat ANAF.
• De ce nu acum: cursoarele exportate (cFacturiTVA si perechea de la a doua raportare) ar cere o coloana noua, iar ALTER TABLE ADD COLUMN pica pe cursor liber cu nume de camp peste 10 caractere (platitortva are 11) — ar cere rematerializarea cursorului in doua situri de raportare, cu schimbarea formatului unui fisier care ajunge la client. Amanat explicit de Marius, 01.08.2026.
• Efort: M. Depinde de: decizie separata daca merita rematerializarea cursoarelor.

P2 — Clarificare cu ANAF: marginea perioadelor scpTVA/splittva/inactiv

• Ce: cache-ul ANAF (ISTORIC_CODURI_FISCALE) foloseste conventie inclusiva la sfarsitul intervalelor SCPTVA/SPLITTVA/INACTIV (spre deosebire de TVAINCASARE, aliniat 01.08.2026 la conventia exclusiva a RTVAI). Nu exista ground truth local (registru echivalent rtvai_istoric) pentru aceste trei campuri.
• De ce: risc de verdicte gresite cu o zi pe declaratii D394/D406 la marginea perioadelor, acelasi tipar de defect confirmat pe tvaincasare (vezi docs\handoff_cache_anaf.md, sectiunea A-ter).
• Efort: S (o intrebare catre ANAF) -> M (aplicarea raspunsului in cod, daca schimba conventia). Depinde de: raspunsul ANAF.

P3 — Test UI pe gridul de verificare parteneri (coloana de provenienta cache)

• Ce: confirmare vizuala (paint real, nu doar EVALUATE pe ControlSource) ca noua coloana de provenienta (sursa/data_sursa, S8) se afiseaza corect in gridul de verificare.
• De ce nu acum: cere write-back .vc2 pe overificari.vc2, deci dupa aprobarea lui Marius pe diff.
• Efort: S. Depinde de: aprobarea write-back-ului .vc2 al transei cache ANAF.

Curatenie mediu — randuri orfane in tabela versiune (MARIUSM_AUTO)

• Ce: doua randuri co_2026_07_30_01_COMUN_ISTORIC_CF.sql in MARIUSM_AUTO.versiune, din testarea manuala a lui S1 dinainte de redenumirea in ff_.
• De ce nu acum: fara efect (motorul PACK_UPDATE dispecerizeaza dupa numele fisierului de pe disc, nu dupa stringul din versiune) — curatenie de mediu de test, nu de productie.
• Efort: S. Depinde de: nimic, se poate face oricand.