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.