roacont/docs/handoff_transa1.md

Handoff Transa 1 (L1 + L2) — ocautare.prg + validare.prg

Data: 27.07.2026. Patch: docs/diff_runda1_transa1.patch. Backup-uri: *.pre_runda1.bak in COMUN/programe/. Fara comit (git/svn), fara git add.

L1 — perioada TVA

• validare.prg header (dupa ultima intrare 27.07.2026): intrare noua cumulativa.
• validare.prg:1663 ANAF_VerdictDinCursor: 4 proprietati noi pe loResult (dInceputScpTVA, dSfarsitScpTVA, dAnulareScpTVA, cMesajScpTVA), citite din cursor INAINTE de Use In — linii neschimbate fata de plan (1657→1663 dupa insertia headerului, offset normal).
• validare.prg ParseJsonANAFv8 (~2074-2086): log explicit (nu in CATCH) pentru fiecare din cele 3 campuri de data, cand sirul sursa e nevid dar CTOD a intors gol.
• ocautare.prg header: intrare noua cumulativa (L1; L2 nu are comentariu, e corectie).
• ocautare.prg:145-153 ANAF_StarePartener: propaga cele 4 proprietati in loOut, citire garda cu Pemstatus(loRezANAF, '<prop>', 5); daca lipsesc (validare.prg vechi la alte produse ROA), loOut primeste oricum proprietatea cu valoare goala — asa TextAnaf/Detalii n-au nevoie de Pemstatus la randul lor.
• TextStare (nou parametru tcPerioada) + SufixPerioadaTVA (functie noua) + TextAnaf (foloseste cele doua) — implementeaza tabelul de conditii si formele exacte din plan (precedenta pe dAnulareScpTVA, apoi range daca ambele date, apoi din data; sufixul ' la data documentului' dispare cand perioada apare).
• TextPerioadaTVA (functie noua) + Detalii: bloc cu perioada completa (etichete distincte)
  • mesajul ANAF integral, inserat dupa AntetDialog(...) in AMBELE ramuri unde oStare nu e null (cazul concordant si cel discordant/lista de candidati) — deci apare si in cazul concordant, cum cere planul.

L2 — CNP la 13 cifre

• EvalueazaRand:600(vechi): This.cClasaEsec = '' → 'COD_INVALID' (fara comentariu).
• ANAF_StarePartener: parametru nou tnTipPersoana (adaugat la finalul listei, ca sa nu mut pozitiile parametrilor @); conditia de la :82 devine Len(m.lcCui) = 13 And !(Vartype(m.tnTipPersoana) = 'N' And m.tnTipPersoana = 1), seteaza tcClasaEsec = 'CNP' inainte de Return .Null.. Singurul apel din tot codul e in EvalueazaRand (verificat cu grep in D:\ROA\ROACONT) — actualizat sa paseze m.lnTipPersoana (deja calculat la linia anterioara, nimic nou de calculat). Corectie runda 2 (semnalata de team-lead la review): forma initiala m.tnTipPersoana <> 1 compara direct cu 1, ceea ce arunca eroare VFP 107 ("Operator/operand type mismatch") daca ANAF_StarePartener e chemata cu vechea semnatura de 6 parametri (tnTipPersoana nepasat = .F. logic, .F. <> 1 = mismatch tip) — risc real, pentru ca fisierul e cod partajat COMUN si alte produse ROA il pot chema fara noul parametru. Forma cu Vartype(...) = 'N' And ... = 1 e sigura indiferent daca parametrul e pasat sau nu si pastreaza compatibilitatea inapoi (apelant vechi -> se comporta ca azi, sare ANAF pe 13 cifre).
• EvalueazaRand: ramura noua Case Isnull(m.loStare) And m.lcClasaEsec == 'CNP' inaintea lui Case Isnull(m.loStare), banda neutra 'Persoana fizica - CNP corect'.
• Detalii, Iif imbricat: doua ramuri noi, CNP si COD_INVALID, exact textul din plan.
• Ramurile marcate INACCESIBILE in plan (CNP invalid sub clasa noua, CUI valid/invalid sub FARA_RASPUNS) NU au fost implementate, cum cere planul.

Verificari facute

• cp1252: toate editarile au fost facute INTAI, verificare byte-level DUPA. ocautare.prg a avut 3 linii corupte (0xBA → EF BF BD) dupa editari (caracterul ș din "mașina"/"și"/"tranșa", niciuna dintre ele atinsa intentionat) — reparate cu s/\xEF\xBF\xBD/\xBA/g (sigur, pentru ca toate cele 3 corupte erau confirmat 0xBA in backup si in svn cat, verificat byte-cu-byte cu xxd+md5sum, nu doar vizual — atentie, terminalul afiseaza 0xBA si EF BF BD identic vizual, verificarea trebuie facuta pe octeti, nu pe ce se vede). Dupa reparare: 0 aparitii EF BF BD in ambele fisiere, numar de linii cu octeti >=0x80 identic intre fisierul curent si svn cat (3 in ocautare.prg, 0 in validare.prg), continut confirmat identic prin md5sum pe liniile respective.
• Comentarii: doar in antet, cate o intrare cumulativa per fisier (L1); L2 fara comentariu.
• Patch (docs/diff_runda1_transa1.patch) recitit — contine doar modificarile de mai sus, fara cele 3 linii cu diacritice (au disparut din diff dupa reparare, semn ca sunt byte-identice cu baseline-ul).

Ce n-am putut verifica

• Nu am rulat headless VFP (vfp9.exe -A -T) pe aceste functii — modificarile ating clase UI (anaf_verif_cautare, mesaje Amessagebox) greu de testat fara IDE/formular; recomand testare manuala in VFP conform planului de test insotitor.
• N-am gasit alti apelanti ai ANAF_StarePartener in afara de ocautare.prg insusi (grep pe tot D:\ROA\ROACONT), deci parametrul nou tnTipPersoana nu are alti calleri de actualizat — dar n-am verificat si in D:\ROA\COMUNROA sau alte produse ROA in afara acestui working copy.

Capcane intalnite

• Editarea cu Edit tool a corupt caractere cp1252 in TOT fisierul ocautare.prg la fiecare scriere, exact cum avertizeaza conventie_encoding_cp1252.md — dar comparatia vizuala in terminal ("liniile arata la fel") a fost INSELATOARE: 0xBA si EF BF BD (3 octeti) se afiseaza identic ca <EFBFBD> in terminal. Un prim test cu perl -ne 'print "$." if /[\x80-\xFF]/' a raportat "acelasi numar de linii, acelasi continut vizual" si a fost gresit interpretat ca "nicio corupere" — abia comparatia cu xxd+md5sum a scos la iveala diferenta reala. Concluzie pentru viitor: verificarea corecta e strict pe secventa de octeti EF BF BD (perl -ne 'print "$." if /\xEF\xBF\xBD/'), nu pe prezenta oricarui octet >=0x80.