roacont/docs/plan-anaf-tva-efactura-4-lucrari.md

Plan: 4 lucrari ROACONT (ANAF perioada TVA, validare CNP, avertizare exigibilizare, borderou eFactura)

Data: 27.07.2026. Autor livrare: marius.mutu. Versiune consolidata dupa runda 2 de review si poarta de decizie. Aceasta e versiunea de executat — incorporeaza toate deciziile. Istoricul review-ului e in Anexa, la final, si nu contine nimic de implementat.

Plan de test insotitor: ~/.gstack/projects/ROACONT/mmari-main-eng-review-test-plan-20260727-194744.md

Livrare in TREI TRANSE separate

Cele 4 lucrari nu au nicio dependenta functionala intre ele, dar au clase de risc si povesti de retragere incompatibile. Impachetate impreuna, o retragere pentru L3 ar lua cu ea si view-ul deja aplicat in schema clientului.

Transa	Continut	Blast radius	Retragere	Blocata de
1	L1 + L2	2 fisiere .prg in COMUN	un pas	nimic — se poate incepe
2	L4	script DB + o expresie in client	doi pasi coordonati	2 conditii de intrare
3	L3	drumul de salvare al notelor, toata suita ROA	un pas, dar afecteaza tot	1 conditie de intrare

Fiecare transa se inchide in SVN inainte de a incepe urmatoarea.

---

TRANSA 1 — L1 + L2

Ambele in COMUN\programe\ocautare.prg + COMUN\programe\validare.prg. Lane secvential: L1 apoi L2. Fara DB, fara drum de salvare. Reversibil prin revenire la binarul anterior.

L1 — de cand este platitor / neplatitor de TVA

Problema

Verificarea ANAF de la alegerea partenerului spune doar starea la data documentului ("ANAF: platitor TVA la 27.07.2026"). Pentru un cod fiscal care si-a schimbat atributul, utilizatorul nu vede DE CAND s-a schimbat.

Ce exista deja (verificat, nu se construieste)

• ParseJsonANAFv8 (validare.prg:2001-2114) pune DEJA in cursor toate campurile necesare: data_inceput_ScpTVA, data_sfarsit_ScpTVA, data_anul_imp_ScpTVA, mesaj_ScpTVA (citite din inregistrare_scop_tva.perioade_tva[1], liniile 2060-2072).
• Cele trei coloane de data sunt DEJA de tip D in CREATE CURSOR (validare.prg:2012). Nu e nevoie de normalizare, doar de garda pe gol.
• Informatia se pierde in ANAF_VerdictDinCursor (validare.prg:1657-1689), care ia din cursor doar cui, scpTVA, statusInactivi, denumire, mesaj (:1670-1675).
• Cache-ul de sesiune goCacheANAF_Sesiune pastreaza obiectul intreg (ocautare.prg:127 .Add(m.loRezANAF, ...), :130 .Item(...)). Proprietatile noi supravietuiesc. Nu se modifica.
• lDiscordanta exista deja: ocautare.prg:143, (loRezANAF.scpTVA <> loOut.lAreRO) Or loRezANAF.statusInactivi. Banda se ramifica deja pe ea la :651. Nu se scrie detectie noua.

Lucrarea e strict propagare + afisare. Nu se schimba apelul HTTP, nu se face al doilea apel.

Modificari

1. validare.prg, ANAF_VerdictDinCursor (~1657-1689)

Pe obiectul rezultat se adauga patru proprietati, toate citite din cursorul deja parsat:

• dInceputScpTVA, dSfarsitScpTVA, dAnulareScpTVA — din coloanele de tip D, cu Nvl si garda pe gol.

• cMesajScpTVA — din coloana mesaj_ScpTVA (C(244)), NU din mesaj.

  Motiv: validare.prg:2012 declara mesaj_ScpTVA C(244) dar mesaj V(100), iar :2109 face loDate.mesaj = loDate.mesaj_ScpTVA urmat de Insert Into la :2112 — VFP taie tacut la 100 din 244 de caractere. Proprietatea mesaj deja expusa contine mesajul ANAF trunchiat la 41%.

Toate patru se citesc aici: cursorul se inchide la :1683 si nu mai exista alta ocazie.

2. ocautare.prg, ANAF_StarePartener, blocul de verdict (136-145)

Propaga cele patru proprietati in loOut.

Citirea se face cu Pemstatus(loRezANAF, 'dInceputScpTVA', 5) aici, la :140-145 — nu in TextAnaf. ocautare.prg e incarcat si de produse ROA care pot avea un validare.prg mai vechi (garda existenta la :63-66); citirea neprotejata ar arunca eroare in acest bloc, inainte sa se ajunga vreodata la TextAnaf.

3. ocautare.prg, TextAnaf (683-695) — cand si unde apare data

Data de perioada apare in banda doar pe trei conditii. In rest banda ramane identica cu azi, iar perioada completa se vede in F4.

Conditie	Data in banda
lDiscordanta = .T. (ROA difera de ANAF, sau partener inactiv)	DA
dAnulareScpTVA nevid (anulare din oficiu)	DA
dSfarsitScpTVA < Date() (perioada s-a incheiat deja)	DA
rest (cazul normal, concordant)	NU

Regula de pozitionare, obligatorie: data se lipeste imediat dupa starea de TVA, inaintea oricarui segment , Inactiv.

TextStare (ocautare.prg:680) produce Platitor TVA, Inactiv. Forma gresita ANAF: Platitor TVA, Inactiv din 01.03.2019 afirma ca partenerul e inactiv din 2019, cand de fapt aceea e data de inceput a perioadei de TVA. Cum lDiscordanta include statusInactivi, cazul inactiv e chiar unul dintre cele aduse in banda — deci regula nu e optionala.

Forme corecte:

ANAF: Platitor TVA din 01.03.2019, Inactiv (DENUMIRE... RO12345678)  (F4 = detalii)
ANAF: Platitor TVA din 01.03.2019 (DENUMIRE... RO12345678)  (F4 = detalii)
ANAF: Platitor TVA 01.03.2019 - 31.03.2026 (DENUMIRE... RO12345678)  (F4 = detalii)
ANAF: Neplatitor TVA din 12.03.2026 (DENUMIRE... 12345678)  (F4 = detalii)
ANAF: Neplatitor TVA, anulat din 12.03.2026 (DENUMIRE... 12345678)  (F4 = detalii)

Precedenta cand ambele date sunt nevide: pe dAnulareScpTVA — anularea din oficiu e informatia mai grava, iar anulat e cuvantul pe care contabilul il cauta. Cele doua date NU se contopesc: data_sfarsit_ScpTVA (incetarea inregistrarii) si data_anul_imp_ScpTVA (anulare din oficiu) au consecinte diferite asupra dreptului de deducere.

Cand perioada apare in banda, data documentului redundanta (' la ' + Dtoc(toStare.dData)) se scoate din text, ca sa nu rezulte doua date cu doua prepozitii alaturate.

Banda are voie 2-3 randuri: lb_anaf are WordWrap = .T., Height = 46, Width = toForm.Width - 20 (ocautare.prg:472-476). Riscul real nu e latimea, ci ca un sufix de lungime variabila muta punctul de wrap si (F4 = detalii) sare intre randuri la derularea cu sagetile. Regula de mai sus il reduce mult: ~95% din randuri pastreaza banda de azi.

4. ocautare.prg, Detalii (787-873)

Bloc nou in dialog, dupa starea curenta: perioada de inregistrare in scopuri de TVA (inceput / sfarsit / anulare, cele nevide, cu etichete distincte) si, daca cMesajScpTVA e nevid, mesajul textual primit de la ANAF, integral.

Perioada apare in F4 intotdeauna cand ANAF a trimis-o, inclusiv in cazul concordant in care banda nu o arata.

5. validare.prg (2064-2072) — logul pe parsare esuata

Se logheaza cazul in care perioade_tva[1] exista, sirul sursa e nevid, dar data parsata e goala.

Conditia se scrie explicit, NU in CATCH: CTOD nu arunca exceptie pe format necunoscut, ci intoarce data goala. CATCH-ul de la :2070 prinde doar erori de acces la perioade_tva[1], deci un log pus acolo nu s-ar declansa niciodata pe cazul pentru care a fost cerut.

(Parsarea e corecta cat timp ANAF trimite YYYY-MM-DD, sub Set Date To YMD de la :2023, restaurat in Finally la :2131.)

Limita de acceptat

ANAF v9 intoarce O SINGURA perioada — cea care acopera data interogata. Textul afisat descrie perioada relevanta pentru data documentului, nu tot istoricul.

---

L2 — validare CNP la codurile de 13 cifre

Problema (bug raportat)

ARGHIR MARIA (CUI: 2540324131210, ID: 149) ANAF nu a raspuns - verificarea a fost sarita.

Mesajul e fals. ANAF_StarePartener (ocautare.prg:82-84) intoarce .Null. pentru codurile de 13 cifre FARA a seta tcClasaEsec. CNP-ul din exemplu este VALID.

Localizarea exacta a defectului:

• BANDA nu acuza ANAF: .Null. cu clasa goala cade pe Case Isnull(m.loStare) (:648-650) -> promptul neutru. Nu e gresit, dar nu spune nimic.
• DIALOGUL F4 e singurul care minte: Detalii, :799-804, ultima ramura a Iif-ului imbricat (:803) -> 'ANAF nu a raspuns - verificarea a fost sarita.'
• VerificaAlegere (:875+) intoarce .T. tacut pe oStare nul — acolo nu e nimic de reparat.

Defectul e mai larg decat cazul raportat: EvalueazaRand sterge explicit clasa de esec cand codul e invalid (:600, This.cClasaEsec = ''). Deci pentru ORICE cod fiscal invalid, banda spune corect "CNP invalid" / "CIF invalid", dar F4 afiseaza tot 'ANAF nu a raspuns'. Cazul raportat e una din doua instante ale aceluiasi defect.

Ce exista deja (verificat)

• Validarea locala RULEAZA DEJA: EvalueazaRand apeleaza ANAF_ValidareCod la :594 si iese devreme pe orice rezultat nevid (595-604), INAINTE de apelul ANAF. Deci "CNP invalid (...)" si "CIF invalid (...)" se afiseaza deja azi. Nu se scrie validare noua.
• Consecinta: un cod care pica validarea nu ajunge niciodata pe drumul ANAF. Ramurile "CNP invalid" sub clasa noua si "CUI valid/invalid" sub FARA_RASPUNS sunt INACCESIBILE prin constructie si NU se implementeaza.
• ANAF_ValidareCod (:208-227) decide CNP vs CIF cu prioritate pe tip_persoana, altfel lungime 13.
• VALIDARE_CNP (validare.prg:1296-1312), VALIDARE_CIF (validare.prg:1225-1294).
• Clasa noua COD_INVALID urmeaza tiparul existent COD_NENUMERIC de la ocautare.prg:643-646.

Modificari

1. ocautare.prg, EvalueazaRand (:600): This.cClasaEsec = 'COD_INVALID' in loc de ''.

2. ocautare.prg, ANAF_StarePartener (82-84): seteaza tcClasaEsec = 'CNP' inainte de Return .Null.

3. ocautare.prg, ANAF_StarePartener: primeste in plus tnTipPersoana, iar conditia de la :82 devine Len(m.lcCui) = 13 And m.lnTipPersoana <> 1.

   Motiv: :82 decide "persoana fizica" doar pe lungime, ignorand tip_persoana, in timp ce ANAF_ValidareCod (:222) decide invers, cu prioritate pe tip_persoana. Divergenta e mascata azi pentru ca banda cade pe promptul neutru si nu afirma nimic. L2 pune acolo "Persoana fizica - CNP corect", deci pentru un partener extern cu cod numeric de 13 cifre aplicatia ar afirma pe ecran ceva fals, unde azi tace. Cauza e preexistenta, consecinta vizibila ar fi introdusa de L2.

4. ocautare.prg, EvalueazaRand (636-657): ramura noua inaintea lui Case Isnull(m.loStare), pe clasa 'CNP' — banda arata Persoana fizica - CNP corect, culoare NEUTRA (SeteazaLabel(..., .F., .T.)), nu verde.

   De ce nu verde: verdele si formularea scurta stau in acelasi loc si in aceeasi culoare cu confirmarea reala de la ANAF. O cifra de control nu este o verificare la ANAF.

5. ocautare.prg, Detalii (799-804): doua ramuri noi in Iif-ul imbricat:

   • 'CNP' -> Persoana fizica - CNP corect.
   • 'COD_INVALID' -> Cod fiscal invalid - nu s-a interogat ANAF. Corectati codul in fisa partenerului.

Informativ, fara blocare si fara dialog de confirmare — cascada RC_ANAF_VERIF_SELECTIE ramane neatinsa.

---

TRANSA 2 — L4: borderou eFactura, taxare inversa

Nu se incepe inainte ca transa 1 sa fie in SVN.

Problema

In borderoul eFactura, facturile primite cu taxare inversa apar gri (diferenta fata de registrul de cumparari). In XML-ul eFactura taxarea inversa are TVA 0 (ClassifiedTaxCategory/ID = 'AE'), dar in contabilitate se inregistreaza 4426 = 4427, deci jc2007.totctva contine si acest TVA. Diferenta rezultata e exact TVA-ul de taxare inversa si nu e o eroare reala.

Importul face deja corectia inversa la generarea notelor (anaf_efactura.vc2:12096-12106), dar numai IF thisform.lPrimite.

Decizie

Corectia se face din datele contabile REALE, prin view-ul Oracle — nu prin recalcul cu cota standard (care ar da gresit pe facturi mai vechi la 19%). Scope: DOAR facturi primite.

Coloana vizibila in grid NU se face. Se livreaza doar corectia interna a expresiei diferenta.

Conditii de intrare (ambele obligatorii inainte de a scrie scriptul)

1. Trasare cap-coada a unei facturi reale: linie XML cu ClassifiedTaxCategory/ID = 'AE' -> id_jtva_coloana -> coloana din jc2007. Se confirma pe date ca acolo sta suma.

2. Definitia curenta a lui anaf_vefactura_trimis se ia din USER_VIEWS.TEXT din schema tinta, nu din arhiva CLAR.

   Motiv: scriptul-model 2025\06\ff_2025_06_16_02_COMUN_EFACTURA.sql redefineste NUMAI anaf_vefactura_primit (:3-53). Corpul lui anaf_vefactura_trimis e in alt fisier, mai vechi (2024\08\ff_2024_08_22_01_COMUN_EFACTURA.sql:63-112); cele doua au divergat cu ~10 luni si exista 10 scripturi in arhiva care il redefinesc. Cine il rescrie "dupa model" luand fisierul gresit revine tacut la o versiune veche a view-ului.

Modificari

1. Script de migrare nou, in D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\07\

create or replace view pentru AMBELE view-uri, cu o coloana noua jtva_ti:

• anaf_vefactura_primit: jtva_ti = suma coloanelor de TVA de taxare inversa din jc2007, cu EXACT aceeasi potrivire ca cea folosita azi pentru jtotctva (an/luna/dataact/regexp pe numar act si cod fiscal emitent).

• anaf_vefactura_trimis: jtva_ti = constanta 0. La facturi emise nu se inregistreaza nota contabila de TVA pentru taxare inversa, deci diferenta de acolo ramane identica cu azi.

  Coloana e obligatorie in AMBELE: import_efactura.prg:40 foloseste FROM <<m.lcTabel>>, un singur SELECT pentru ambele view-uri (lcTabel setat la :27). Fara ea, borderoul de facturi TRIMISE crapa cu ORA-00904.

Lista de coloane — CORECTATA 28.07.2026, verificata pe USER_TAB_COLUMNS.

Expresia din Programe\oproceduri_decont.prg:8670 NU se poate copia: e scrisa peste view-ul VJC2025 (FROM VJC2025 J, :8677), nu peste tabela. In acel view ti19t si ti09t sunt ALIASURI calculate (SUM(ti19bct+ti19bvt+ti19bft) as ti19t, SUM(ti09bvt+ti09bft) as ti09t). Pe jc2007 coloanele TI19T si TI09T nu exista. Un create or replace view care le foloseste direct pica cu ORA-00904 — si, cum acelasi script redefineste si anaf_vefactura_trimis, ar rupe borderoul pe AMBELE sensuri.

Lista corecta pe jc2007 are 13 termeni, nu 10 (TI09 nu are varianta BC, asimetric fata de TI19):

NVL(j.TI21T,0)+NVL(j.TI11T,0)+NVL(j.TI24T,0)+NVL(j.TI20T,0)
+ NVL(j.TI19BCT,0)+NVL(j.TI19BVT,0)+NVL(j.TI19BFT,0)
+ NVL(j.TI09BVT,0)+NVL(j.TI09BFT,0)
+ NVL(j.XX21TIT,0)+NVL(j.XX11TIT,0)+NVL(j.XX19TIT,0)+NVL(j.XX9TIT,0)

Familia NU este XX*TI* singura. Importul eFactura trece prin ProcentTva2IdJtva (definita in COMUN\programe\oproceduri_comune.prg:5836, doar apelata din anaf_efactura.vc2:12093), care pentru cumparari cu taxare inversa da id-urile 216/218/141/145; in jtva_coloane, 216 = 'TX. INV. 21%' -> TI21B (pereche 217 = TI21T), 218 = 'TX. INV. 11%' -> TI11B (219 = TI11T). Coloanele XX*TIT sunt achizitii NON-CE, pe care importul eFactura nu le scrie. Toate confirmate ca existente in jc2007: TI21T=217, TI11T=219 (2026\03\ff_2026_03_09_02_COMUN_PACK_CONTAFIN_10G_ROMCONSTRUCT.pck:4991-4993), XX19TIB=192, XX19TIT=193 (2026\01\PACK_CONTAFIN_ROMCONSTRUCT...pck:4891-4892).

Performanta: jtotctva e deja un subselect corelat peste jc2007 cu REGEXP_SUBSTR + REGEXP_REPLACE in WHERE — neindexabil, scanare per rand. Un al doilea subselect identic pentru jtva_ti ar dubla exact acest cost. Se scrie un singur subselect care intoarce ambele sume.

Se pastreaza EXEC pack_migrare.UpdateVersiune(...) + COMMIT. Fisierul se scrie cu CRLF. Se bumpeaza versiune_db.txt. Scriptul se incheie cu o verificare de obiecte invalide: view-urile anaf_vefactura_primit_detaliu si anaf_vefactura_trimis_detaliu (2024\08\ff_2024_08_28_02_COMUN_EFACTURA.sql:84, :122) sunt construite peste cele doua si se recompileaza automat, dar invaliditatea trebuie sa nu treaca neobservata.

2. COMUN\programe\import_efactura.prg — o singura expresie

Linia :36:

NVL(total_cu_tva,0.00) - (NVL(jtotctva,0.00) - NVL(jtva_ti,0.00)) as diferenta

lcSchema (:31-33) NU se modifica. jtva_ti apare doar ca termen intr-o expresie, nu ca coloana de iesire, deci numarul de coloane al cursorului ramane acelasi. lcSchema e o schema pozitionala imperecheata cu lcSelect in gencursor (:50); orice coloana noua de iesire ar cere modificarea ambelor, iar modificarea uneia singure ar strica intreg borderoul.

3. Degradare gratioasa la lipsa coloanei

Inainte de a construi lcSelect, se testeaza o data existenta coloanei (SELECT jtva_ti FROM ... WHERE 1=2 intr-un TRY, sau interogare pe user_tab_columns) si se construieste lcSelect cu sau fara termenul jtva_ti.

Motiv: exe-ul ajunge la client prin update automat, iar migrarea CLAR ruleaza pe alta cadenta. Fara sonda, prima combinatie gresita da ORA-00904 si borderoul nu se deschide deloc, nici primite nici trimise. Cu sonda, ordinea de livrare devine optimizare, nu conditie de functionare.

Ordinea recomandata ramane: scriptul se aplica INAINTE de build — de scris in nota de release.

4. Ce NU se atinge

Colorarea ramane pe diferenta <> 0 (anaf_efactura.vc2:6020-6041 Page2 si 12790-12817 frm_import_efactura) — se corecteaza doar sursa numarului. NU se inventeaza o a treia culoare: randurile cu taxare inversa nu sunt de investigat, sunt corecte prin constructie, iar falsurile pozitive omoara marcajul de exceptie. NU se ating Page1 / Page3 si filtrul chkDiferente (anaf_efactura.vc2:5347-5349) — sunt facturi emise. Nu se editeaza niciun binar .vcx.

Limita cunoscuta, de consemnat

O taxare inversa inregistrata la cota GRESITA face ca diferenta sa se anuleze reciproc si randul sa devina alb. Fara coloana in grid nu mai exista nicio parghie vizuala pentru acest caz. E pretul deciziei de a nu adauga coloana si trebuie sa fie scris, nu descoperit.

---

TRANSA 3 — L3: avertizare de exigibilizare TVA la salvarea notelor

Ultima, singura. Nu se incepe inainte ca transele 1 si 2 sa fie in SVN.

Scopul lucrarii — ca sa nu se citeasca gresit

Singura modificare de cod e in COMUN\clase\omodificari.vc2, in inainte_de_do_termin al celor doua clase de formular de note: frm_modific2007 (:5001) si frm_modific2024 (:13131).

NU se modifica oproceduri_inchidere.prg. NU se modifica do_adauga_tva_exigibil. NU se genereaza nimic automat in afara butonului din dialog.

oproceduri_inchidere.prg apare mai jos doar ca drum de test: exigibilizarea din meniu deschide chiar frm_modific2007 (:902, Createobject([frm_modific2007], ...), cu titlul 'Exigibilizare TVA Incasare'), deci avertizarea se declanseaza si acolo fara ca cineva sa fi atins acel fisier.

Conditie de intrare

Cotele 21% si 11% in pack_contab.defalca_tva_incasare si pack_contab.cauta_facturaTVAEx. Partial inchisa: exista suport 21%/11% in 2025\08\ff_2025_08_08_02_COMUN__PACK_CONTAB.sql (comentariu "creeaza_note_tva_incasare TVA 21%, 11%"). De confirmat pe date.

Ce exista deja (verificat)

• Command5 -> Thisform.do_adauga_tva_exigibil() (omodificari.vc2:13776-13778). Captionul DIFERA intre clase: :2643 = "Adauga nota TVA devenit exigibil" (frm_modific2007), :6923 = "Adauga TVA exigibilizat" (frm_modific2024).
• do_adauga_tva_exigibil (:12483+) lucreaza pe conditia ales and (scc = '4428' or scd = '4428' or id_factd > 0 or id_factc > 0) (:12509). Nu contine nicio lista de cote — lucreaza pe liniile notei si pe proc_tva, si deleaga defalcarea Oracle-ului. Deci e agnostic la cota si functioneaza la 21%.
• cmdSelect.Click = "Selecteaza tot" (:13640-13658) — face doar Replace All ales With .T.
• Precedent identic ca forma in acelasi hook: avertizarea 4426-4428 (:13165-13176), cu amessagebox(..., 4+32, ...) si Return .F.
• tact poarta tipnota, id_fact, id_factd, id_factc, ales, id_act. Cursorul e construit de fiecare apelant, nu de omodificari.vc2. Codul insusi nu are incredere ca tipnota exista: :4752 si :12847 folosesc If TYPE('tact.tipnota') = 'N' AND ...
• Return .F. din inainte_de_do_termin opreste salvarea: apelantul din _frm_base.vc2 (PROCEDURE do_termin) nu face Release/Hide si nu seteaza buton/gnButon, iar toti apelantii testeaza If buton = 1 inainte de a scrie. Nicio subclasa a celor doua clase nu exista in arbore, deci niciun override nu poate sari peste hook.

Modificari — algoritm

Pasul 0 — pozitionare in hook. Verificarea se aseaza sub acelasi IF m.llRet ca avertizarea existenta (:13165) si dupa SELECT tact / SET FILTER TO de la inceputul procedurii (:5001-5005, :13131-13135). Altfel apare peste dialogul de eroare de la verificare_note_contabile, sau filtrul gridului ii ascunde randuri.

Ordinea dialogurilor la o singura apasare de Salvare: verificare_note_contabile -> avertizarea 4426-4428 -> avertizarea noua. Prima semnaleaza o greseala facuta, a doua o omisiune.

Pasul 0.5 — kill-switch. Optiune implicit pornita. Daca e oprita: nicio avertizare, nicio interogare, in tot produsul. L1/L2 stau deja in spatele RC_ANAF_VERIF_SELECTIE; L3 intra pe drumul de salvare al intregii suite si nu are voie sa fie fara oprire.

Mecanismul — CORECTAT 28.07.2026. NU se folosesc Optiuni_FIRMA/Optiuni_PROGRAM.dbf din DATE\: acele tabele exista pe disc, dar nu sunt calea folosita si nu apar deloc in cod. Modelul de urmat este chiar RC_ANAF_VERIF_SELECTIE, care are trei straturi (ocautare.prg:255-285, :341-381):

1. kill-switch INI: getini(gcGeneralIniFile, 'anaf', 'verificare_selectie'), doar '0' opreste;
2. optiuni Oracle (optiuni / optiuni_util), citite cu citeste_optiune / citeste_optiune_utilizator din oinit_optiuni.prg, cu cache intr-o Collection;
3. UI = intrare de meniu (Meniuri\CONT2000.MPR:210, ON SELECTION BAR ... DO ANAF_ComutaVerificare), nu ecran cu campuri DBF.

Pasul 0.6 — flag de lot. Apelantii care instantiaza formularul in bucla seteaza un flag public "rulez in lot", iar verificarea se sare. anaf_efactura.vc2:12733 instantiaza frm_modific2024 per factura importata: un import de 150 de facturi ar insemna 150 de AMESSAGEBOX succesive plus 150 de interogari Oracle sincrone. Acelasi lucru la :12940 si comun.vc2:2436.

Pasul 1 — colectare. Din tact, id-urile id_factd / id_factc > 0. Daca nu exista niciunul: nimic, cost zero, fara interogare Oracle.

Pasul 2 — suprimarea platilor deja acoperite.

Regula: exista in tact o linie cu tipnota = 1 SI id_fact = <id>.

Citirea lui tipnota se face prin TYPE('tact.tipnota') = 'N', ca la :4752 si :12847 — tact e construit de apelant, posibil din alt produs ROA.

Santinela -5 NU intra in regula. do_adauga_tva_exigibil scrie -5 numai cand id-ul facturii nu se poate rezolva (:12531, :12542, :12551, :12559), iar comentariul din cod spune ce inseamna: "pun -5 ... ca sa-i completez id_fact la scrie_in_act" — adica "de completat la scriere", nu "rezolvat". Pentru liniile colectate la pasul 1 (id_factd/id_factc > 0) codul scrie intotdeauna id-ul real, deci -5 e imposibil prin constructie pe multimea urmarita. In schimb, o disjunctie SAU id_fact = -5 nu ar fi conditionata de id: o singura linie cu -5 oriunde in tact ar stinge avertizarea pentru TOATE platile din lot, tacut.

Calificarea pe tipnota = 1 se pastreaza: fara ea, excluderea ar prinde si notele MANUALE 4426=4428 — exact cele despre care avertizarea existenta de la :13165 spune ca sunt probabil gresite.

Nota de reconciliere: o decizie intermediara a review-ului (D23) ceruse mutarea cheii de pe tipnota pe perechea de conturi, pe motiv ca notele generate de inchidere_tva_sold au tipnota = 0 (oproceduri_inchidere.prg:884). Motivul a cazut: acel drum nu ajunge niciodata la regula, pentru ca INSERT INTO actactan (:848-854) nu completeaza id_factd/id_factc, deci pasul 1 nu colecteaza nimic. Cheia ramane pe tipnota, fara -5.

Pasul 3 — interogarea, fara lista IN.

O singura interogare goExecutor, care intoarce id_fact-urile cu tva_incasare = 1 si sold neexigibil <> 0. Intersectia cu tact se face local, in VFP.

Sursa — CORECTATA 28.07.2026. Interogarea NU se poate scrie peste jc2007 + jv2007: coloana tva_incasare nu exista pe cele doua tabele (verificat pe USER_TAB_COLUMNS). Ea sta pe DOCUMENTE (id_doc = id_fact) si pe view-urile VJC2025 / VJV2025. Se interogheaza view-urile: au deja tot ce trebuie (cotele, tva_incasare, an/luna, id_fact) si sunt exact ce foloseste deja pack_contab.cauta_facturaTVAEx. Cele 14 coloane de cota de mai jos exista, in schimb, si pe jc2007/jv2007 — verificat.

Nu se construieste lista IN (...). Pragul Oracle de 1000 (ORA-01795) se atinge la utilizare normala, nu la 10x: acelasi formular deserveste, dupa propriul caption, "Import extrase bancare, deconturi curieri, procesatori plati" (anaf_efactura.vc2:12941), iar imperecherea se face linie cu linie (oproceduri_import.prg:729, 755, 782, 808). Un extras obisnuit are 300-2000 linii/luna; un decont de procesator, mult mai mult. Un singur SQL de lungime fixa elimina o clasa intreaga de esec de pe drumul de salvare al intregii suite.

Formula de sold neexigibil — NU se copiaza din registru. Filtrul existent la Clase\ovanzcump.vc2:38011 foloseste ro24nb+ro24nt+ro20nb+ro20nt+ro19nb+ro19nt+ro9nb+ro9nt+ro5nb+ro5nt, care OMITE cotele 21% si 11%, in vigoare din august 2025 (RO21NB/RO21NT/RO11NB/RO11NT, id-uri 214/215, 2025\07\ff_2025_07_21_01_COMUN_TVA21.sql:134-140). Cu formula copiata, avertizarea nu s-ar declansa NICIODATA pe o factura din 2025 incoace — exact pe facturile pentru care a fost ceruta.

Lista corecta:

ro24nb+ro24nt+ro20nb+ro20nt+ro21nb+ro21nt+ro11nb+ro11nt+ro19nb+ro19nt+ro9nb+ro9nt+ro5nb+ro5nt

Robustete. Verificarea ruleaza doar dupa ce verificare_note_contabile a trecut si doar cu conexiune valida. Orice esec (tabela inexistenta in alt produs ROA, conexiune cazuta, timeout) -> se sare, cu linie in goLog. Niciodata tacut: o verificare care moare invizibil e mai rea decat una absenta, pentru ca nimeni nu afla ca nu mai merge. Esecul nu blocheaza salvarea.

Cum se obtine asta — PRECIZAT 28.07.2026, dupa citirea clasei. oexecutor e in COMUN\programe\oproceduri_comune.prg:69-547. Comportamentul real:

• oExecute() NU arunca eroare VFP pe SQL esuat: intoarce CT_INSUCCES (-1). Deci nu urca la ON ERROR global. goLog.Log se apeleaza pe toate drumurile de esec. Pana aici, cerinta e indeplinita din oficiu.
• DAR pe eroare ODBC de conexiune cazuta (cod 1526 cu subcod 12152/3113/3114/12560/4068/28/12 — exact cazul numit mai sus) se deschide un amessagebox "Doriti reconectare?" (oproceduri_comune.prg:390) NECONDITIONAT de tlShowError, iar raspunsul "Nu" duce la QUIT — inchide aplicatia, in mijlocul salvarii. Exact opusul cerintei.
• Deci apelul TREBUIE facut cu reconectarea dezactivata explicit. Nu exista precedent: din 150+ apeluri oExecute/oExecuta din codebase, niciunul nu trece de 2 parametri. Tiparul se scrie aici prima oara — de verificat pozitia exacta a parametrului in semnatura inainte de a-l folosi.
• Se foloseste oExecute, NU oExecuta (aceasta din urma afiseaza mesaj propriu, neconditionat, pe orice esec). Nu se adauga niciun amessagebox propriu.
• Nu exista niciun timeout Oracle configurat (SQLSETPROP QueryTimeout/ConnectTimeout) nicaieri: un query agatat blocheaza la nesfarsit, nu doar da eroare. De avut in vedere la testare.

Pasul 4 — dialogul.

Trei butoane:

Exista <N> plati/incasari pe facturi cu TVA la incasare pentru care nu s-a adaugat
nota de TVA exigibilizat.

[Adauga acum]  [Continua]  [Anuleaza]

• Adauga acum — ruleaza do_adauga_tva_exigibil pe liniile deja identificate de interogare, apoi continua salvarea.
• Continua — salveaza fara exigibilizare.
• Anuleaza — Return .F., ramane in formular fara sa salveze.

De ce buton si nu instructiune: sistemul stie deja care plati au nevoie de exigibilizare — asta e chiar interogarea de la pasul 3. O modala care spune "du-te si apasa un buton" ar fi fost inexecutabila in doua feluri: captionul difera intre cele doua clase (:2643 vs :6923), iar Command5.Enabled se calculeaza dupa randul curent (:5661-5667, :13850) si cmdSelect.Click nu il recalculeaza — deci butonul poate fi gri exact dupa "Selecteaza tot".

<N> — de fixat inainte de implementare daca numara facturi distincte sau linii din tact.

Pasul 5 — flag anti-bucla.

Proprietate de formular lAvertizatExigibilizare, setata dupa prima avertizare; a doua oara in aceeasi sesiune de formular nu se mai avertizeaza.

Motiv: cand chkTVAEX e bifat si linia e plata/incasare, do_adauga_tva_exigibil cheama creeaza_note_tva_incasare (:12598-12600), unde id_fact vine din cursorul intors de pack_contab.defalca_tva_incasare (:12412, a.id_fact As id_fact). Daca procedura nu intoarce randuri, nu se insereaza nimic potrivit -> suprimarea nu prinde niciodata -> avertizare -> buton -> avertizare -> buton (dubland notele generate) -> avertizare, fara iesire in afara de "Continua". Ca "zero randuri" e un caz real: oproceduri_inchidere.prg:843-848 il trateaza explicit.

Acoperire — drumuri de instantiere

frm_modific2007 / frm_modific2024 sunt instantiate din: ocont2003.prg:416, 1230, 1679, 2141; oproceduri_incasari.prg:299; frm_import_extrase_banca.sc2:1652; anaf_efactura.vc2:12733, 12940; frm_initializare_facturi_balanta.sc2:1803; comun.vc2:2436; oproceduri_inchidere.prg:719, 902, 1007, 1438; frm_import_note_a4200.sc2:1651; frm_import_note_facturi_clienti.sc2:895; ooperatii_comune.prg:1137.

Premisa "prinde si casa, si banca, si notele manuale" TINE.

Nota de metoda: COMUN/ e in .gitignore, deci Grep/ripgrep il sare implicit. Cautarile de tip "cine apeleaza" se fac cu rg --no-ignore sau cu cale explicita, altfel intorc zero fals.

---

NU intra in scop (amanat, cu motiv)

Defectele din drumul de exigibilizare din meniu (inchidere_tva_sold). De adaugat in TODOS.md cu descrierea de mai jos, care inlocuieste formularea anterioara — aceea descria un defect inexistent si ar fi trimis pe cine preia lucrarea catre o harta gresita.

Ce este de fapt:

1. oproceduri_inchidere.prg:833 testeaza Iif(m.lnCota = 21, m.lnSuma21, m.lnSuma11) intr-o bucla For lnCota = 1 To 7 (:829). lnCota nu ajunge niciodata 21, deci lnSuma21 e cod mort, iar la lnCota = 6 se ia soldul de 11% cu cota 1.21 (:834). Linia vecina :837 o face corect (Iif(m.lnCota = 6, m.lnSuma21T, ...)). Este o greseala de tipar 6 -> 21.
2. :802-803 citesc soldn21 / soldn11 neconditionat din crsTVAIncasareTemp. Aliasurile sunt emise doar de formele 2025 (ovanzcump.vc2:44220-44225, :55069-55073). Pe formele 2010 (:39660, :51403) nu exista -> eroare VFP 12, modala, la apasarea butonului. Exigibilizarea din registru e rupta pe perioadele anterioare lui 2025.
3. lnSuma21, lnSuma11, lnSuma20, lnSuma19 lipsesc din lista Local (:770-773) — devin PRIVATE si se scurg in stiva de apel.

Ce NU este: ovanzcump.vc2:39660 nu "pierde 24/20"; e forma 2010, folosita pe perioade < 2025, al carei cursor sursa vjc2010/vjc2013 nu are deloc coloanele ro21*/ro11* (oproceduri_decont.prg:18795-18801), deci acolo omisiunea e corecta.

Nu afecteaza L3: butonul catre care trimite avertizarea L3 este do_adauga_tva_exigibil, care nu foloseste nicio lista de cote. Sunt doua butoane diferite, pe doua drumuri diferite.

De scris in nota de release: pe o factura cu TVA la incasare 21%, L3 avertizeaza corect, dar utilizatorul care merge pe drumul din meniu (registru -> exigibilizare) gaseste lista goala. Butonul din formular functioneaza.

Alte lucruri amanate:

• Istoricul complet al atributului de TVA (mai multe perioade). ANAF v9 intoarce o singura perioada.
• Al doilea apel ANAF la data curenta ("era platitor la data documentului, dar nu mai este azi").
• Persistarea totalului cu TVA de taxare inversa pe randul din anaf_efactura la import: nu ar acoperi facturile deja importate; view-ul repara si istoricul.
• Derivarea listelor de cote din jtva_coloane in loc de enumerare in mai multe locuri. E cauza radacina a defectelor gasite la L3 si L4.

---

Ce exista deja (si se reutilizeaza)

Sub-problema	Cod existent	Se reutilizeaza?
Perioada TVA de la ANAF	ParseJsonANAFv8, validare.prg:2001-2114	Da, integral. Se propaga, nu se parseaza din nou
Detectia discordantei ROA vs ANAF	lDiscordanta, ocautare.prg:143	Da. Nu se scrie detectie noua
Cache de sesiune	goCacheANAF_Sesiune, ocautare.prg:127, :130	Da, nemodificat
Validare CNP / CIF	VALIDARE_CNP / VALIDARE_CIF, apelate prin ANAF_ValidareCod la :594	Da, integral
Generarea notelor de exigibilizare	do_adauga_tva_exigibil, omodificari.vc2:12483+	Da (rulat din butonul dialogului)
Tiparul de avertizare in inainte_de_do_termin	omodificari.vc2:13165-13176	Da, se copiaza forma
Lista canonica de coloane TVA taxare inversa	oproceduri_decont.prg:8670	Da, se preia ca atare

---

Reguli de livrare

• Fiecare transa livreaza docs\diff_runda<N>_<subiect>.patch; write-back in binar (txt2vcx.ps1) si commit DOAR dupa aprobare. Patch-urile nu se comit.
• Comentarii: o singura intrare cumulativa in antetul fisierului, *!* DD.MM.YYYY / *!* marius.mutu / 1-2 fraze. Fara comentarii in corpul codului. La L2 (corectie de eroare) nu se adauga comentariu.
• ocautare.prg, validare.prg si omodificari.vc2 contin octeti cp1252 (0xBA). Orice scriere cu Edit/Write ii corupe in EF BF BD. Se editeaza TOT ce e de editat, si abia DUPA ultima scriere se verifica byte-level si se repara o singura data, luand octetul corect din svn cat.
• Scripturile .sql din SCRIPTURI_CLAR se scriu cu CRLF.
• changelog_roacont.txt: cate o intrare scurta per transa. L1/L3/L4 = :nou: sau :modificare:; L2 = :eroare: (mesajul fals a ajuns la utilizatori).

---

Ce ramane neverificat

Stare la 28.07.2026, dupa verificarea pe date (schema dev MARIUSM_AUTO). Detalii in docs\handoff_transa2_conditii.md, handoff_transa3_conditii.md, handoff_transa3_deschise.md.

• Comportamentul goExecutor la timeout / conexiune cazuta — INCHIS, vezi "Robustete" mai sus.
• Daca pack_contab.defalca_tva_incasare poate intoarce id_fact null/0 — INCHIS. id_fact in cursor e mereu parametrul trimis, deci nu poate fi null. Zero randuri ESTE posibil (filtrul final poate exclude tot), si e chiar garantat pe drumul omodificari.vc2:12547-12561, unde santinela -5 ajunge ca parametru la defalca_tva_incasare(-5, ...). Flagul anti-bucla de la Pasul 5 e confirmat necesar, nu preventiv.
• Cotele 21/11 in pack_contab — INCHIS. defalca_tva_incasare deleaga la creeaza_note_tva_incasare, care are DECODE explicit pe id_jtva_coloana 211/215 (JC) si 38/42 (JV) pentru RO21*/RO11*; cauta_facturaTVAEx filtreaza si el pe RO21NT/RO11NT. Conditia de intrare a transei 3 e indeplinita.
• Numarul real de linii pe un decont de curier/procesator — RAMANE DESCHIS pe cifra. Schema dev nu are date reprezentative (DECONT: 2 randuri in toata baza; EXTRAS CON: p95 ~10 linii/lot, cu un ordin de marime sub estimarea din plan, dar pe loturi de test, nu activitate reala). Nu schimba decizia: o interogare unica de lungime fixa elimina ORA-01795 indiferent de volum, deci nu exista prag sub care lista IN(...) ar fi de preferat.
• Trasarea cap-coada a unei facturi cu linie AE (transa 2) — RAMANE DESCHISA pe date reale. In schema dev NU exista nicio factura venita din import eFactura cu taxare inversa (anaf_efactura: 487 randuri primite, 8 cu id_fact, zero suprapunere cu randuri TI* nenule). Mecanismul a fost demonstrat numeric doar pe un caz construit din jc2007 (id_fact=8007136, ti19bft=19, totctva=119: diferenta falsa de -19 se anuleaza exact cu jtva_ti). De consemnat in nota de release: verificarea finala ramane de facut pe prima factura reala de taxare inversa importata dupa aplicarea scriptului.

---

---

ANEXA — istoricul review-ului

Nimic de implementat aici. Se pastreaza pentru trasabilitate.

Metoda

Doua runde: /autoplan (CEO -> Design -> Eng) pe 27.07, apoi runda 2 cu trei voci independente (subagenti fara context de review) confruntate cu verificare proprie pe cod. Codex indisponibil pe masina, deci consensul e "voce independenta + verificare proprie", nu Claude/Codex. Faza DX sarita: produsul nu e pentru dezvoltatori.

Afirmatii verificate pe cod

CONFIRMATE: ParseJsonANAFv8 pune datele in cursor (validare.prg:2012); ANAF_VerdictDinCursor expune doar 5 campuri (:1670-1675); cache-ul pastreaza obiectul intreg (ocautare.prg:127, :130); tact poarta campurile necesare (omodificari.vc2:4496, :5661, :13166); precedentul de avertizare (:13165-13172); un singur SELECT pentru ambele view-uri (import_efactura.prg:40); coloanele TI21T=217, TI11T=219, XX19TIB=192, XX19TIT=193; lb_anaf multi-rand (ocautare.prg:472-476); localizarea defectului L2 in Detalii (:648-650, :803); Return .F. opreste salvarea (_frm_base.vc2, do_termin).

INFIRMATE: tipul coloanelor de perioada era declarat incert — sunt deja D; mesaj NU e echivalent cu mesaj_ScpTVA (V(100) vs C(244)); santinela -5 inseamna "de completat la scriere", nu "rezolvat"; capcana inchidere_tva_sold e evitata prin id_factd/id_factc necompletate, nu prin tipnota; defectul de cote amanat era descris gresit.

Decizii

D1-D21 (runda 1, /autoplan): mod SELECTIVE EXPANSION; lista de coloane TI*+XX*TI*; coloana in ambele view-uri; conditie de intrare prin trasare cap-coada; lista de cote cu 21/11; defect preexistent semnalat nu reparat; texte distincte pentru sfarsit vs anulare; log pe parsare esuata; eliminarea ramurilor inaccesibile din L2; corectarea localizarii defectului L2; data lipita de stare; banda multi-rand; interval pentru perioada inchisa; Pemstatus; defectul L2 mai larg (:600); banda neutra pentru CNP; regula de suprimare pe tipnota; jtva_ti coloana vizibila; fara a treia culoare; ordinea DB-inainte-de-exe.

D22-D33 (runda 2): N1 mesaj_ScpTVA in loc de mesaj (rastoarna D7); N2/N3/N4/N5/N6/N7; 4+32+256; conditie de intrare pe pack_contab; rescrierea textului amanarii.

D34-D37 (poarta, marius.mutu): trei livrari separate, fixurile N7 raman amanate cu text rescris; L3 cu buton de actiune in dialog; L4 fara coloana vizibila; L1 cu data si la lDiscordanta.

Contradictie rezolvata la consolidare: D23 (cheia de suprimare pe perechea de conturi) cade in favoarea E.2 (tipnota = 1 AND id_fact, fara -5) — motivul lui D23 a disparut odata cu E.3.

Deciziile D36 si D37 au dizolvat trei constatari: N5, K-1 si N6 nu mai au obiect fara coloana vizibila; N3 si N4 nu mai au obiect cu butonul in dialog.

Teme transversale

Tema 1 — "corect pe hartie, inexecutabil de utilizator". Trei constatari independente (caption diferit, buton conditionat de randul curent, coloana invizibila din cauza preferintelor de grid) au avut aceeasi forma. Toate trei au fost eliminate prin deciziile de la poarta.

Tema 2 — planul verifica listele de cote in VFP si nu deschide niciun pachet Oracle. De aici conditia de intrare pe pack_contab pentru transa 3.