Transa 1 ANAF TVA: changelog 2.11.67, plan corectat pe date, handoff-uri de verificare
Plan corectat in patru puncte confirmate pe Oracle: - lista de coloane de taxare inversa are 13 termeni, nu 10 (TI19T/TI09T nu exista pe jc2007; expresia din oproceduri_decont.prg:8670 e scrisa peste view-ul VJC2025, cu aliasuri calculate) - tva_incasare nu exista pe jc2007/jv2007; interogarea transei 3 merge pe VJC2025/VJV2025 - kill-switch-ul nu se face in Optiuni_FIRMA/PROGRAM.dbf, ci pe modelul RC_ANAF_VERIF_SELECTIE (INI + optiuni Oracle + intrare de meniu) - oExecute deschide dialog de reconectare cu QUIT pe conexiune cazuta; apelul din transa 3 trebuie sa dezactiveze explicit reconectarea SVN r17910/r17911. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DhJwsrFFe1ZNAAtS8Twuti
This commit is contained in:
87
docs/handoff_transa1.md
Normal file
87
docs/handoff_transa1.md
Normal file
@@ -0,0 +1,87 @@
|
||||
# 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 `<60>` 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.
|
||||
Reference in New Issue
Block a user