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.