# 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 `�` 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.