romfast/roacont
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
96577f00056a4f3ab124897b060e02db930112ad
roacont/TODOS.md
Marius Mutu 5b0a3321db Verificare ANAF la alegerea partenerului: opt-in pe introducerea de documente 
Cablarea din ROACONT pentru verificarea ANAF implementata in COMUN (ocautare.prg):

- ointroduceri_cont.vc2: 6 apeluri de cautare partener trec lVerificaANAF=1
  (frm_introd_compact, frm_introd_compact2007, frm_note, frm_note2007), plus
  frm_plati_impozite prin caut_parteneri. Raman fara verificare cautarile de
  responsabili, achizitor, casa si creditor.
- cont2000.mn2: punct de meniu Initializari > Optiuni utilizator >
  "Verificare ANAF la alegerea partenerului" (DO ANAF_ComutaVerificare IN ocautare.prg).
- roacont.prg: incarcarea procedurilor necesare verificarii.
- oproceduri_import.prg: la importul cu cod fiscal discordant se cere confirmare
  in loc sa se aleaga tacit.
- changelog 2.11.65 si documentul de design al functionalitatii.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019H3r66sVojGhgaKq5niu1u
2026-07-27 01:29:20 +03:00

5.8 KiB
Raw Blame History

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.