Commit Graph

6 Commits

Author SHA1 Message Date
f9af574877 Dovezile masurate pentru propunerile de directie (09.2026)
Backtest read-only pe productie: recunoasterea articolului la importul de
eFactura, contarea pe istoric de furnizor, identificarea partenerului la
importul de extrase, plafonul potrivirii facturii din textul bancii.
Include harta codului de import extrase, testul care confirma eroarea de
parsare BT si scripturile SQL reproductibile.

Propunerile care se sprijina pe ele:
COMUN/docs/cercetare/rec_directie_roacont_2026_09.md

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T8jmGHs29e9eyLgoMiLBHW
2026-09-03 14:19:16 +03:00
869403cd3e Registre 2025: cotele 24/20 la soldul neexigibil; exigibilizare TVA reparata
frm_regcump2025 / frm_regvanz2025 au fost derivate din clasele 2010 INLOCUIND
cotele 24/20 cu 11/21, in loc sa le adauge. Consecinta: filtrul "Diferenta sold"
si lista TVA-ului exigibilizat din plati pierdeau facturile cu TVA neexigibil la
24% sau 20% - adica exact facturile vechi cu TVA la incasare, cele carate din
perioade anterioare, care sunt rostul filtrului. Corectate 6 filtre, formula de
sold din frm_regvanz2025 (care omitea complet RO20/RO24, spre deosebire de
geamana ei de la cumparari) si lista de coloane selectate.

Clasele frm_regcump2010 / frm_regvanz2010 raman neatinse: enumera 24/20/19/9/5 si
e corect asa - se folosesc doar pe perioade dinainte de cotele 21/11, iar cursorul
lor actcv nici nu are coloanele ro11*/ro21*.

inchidere_tva_sold:
- soldn21/soldn11 si ro21nt/ro11nt se citesc doar daca exista in cursor.
  Registrele de dinainte de 2025 nu le emit, de unde eroarea VFP la apasarea
  butonului de exigibilizare pe orice perioada anterioara.
- cota 21 nu era luata in calcul: `Iif(m.lnCota = 21, ...)` intr-o bucla
  For 1 To 7, deci lnSuma21 era cod mort, iar la cota 6 se lua soldul de 11% cu
  1.21. Linia imediat urmatoare folosea deja corect `= 6`.
- 8 variabile adaugate in Local; deveneau PRIVATE si se scurgeau in stiva de apel.

Scoase 37 `SET STEP ON` ramase in cod (35 in ovanzcump.vc2, 2 in
oproceduri_inchidere.prg); deschideau depanatorul la fiecare rulare din IDE.

Changelog 2.11.66. Sterse handoff-urile, planurile si patch-urile de review ale
lucrarii ANAF/TVA/eFactura; .gitignore acopera acum docs/diff_*.patch, nu doar
docs/diff_runda*.patch.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhJwsrFFe1ZNAAtS8Twuti
2026-07-28 15:12:51 +03:00
8b5a670ff1 Transa 2: changelog 2.11.68, versiune_db, plan cu semnatura oExecute si decizia pe N
Plan completat: tlReconnect e al 8-lea parametru din oExecute si e implicit .T., deci transa 3
trebuie sa-l paseze .F. explicit. N din dialogul transei 3 numara facturi distincte (decizie
marius.mutu, 28.07.2026).

SVN r17914; script DB in DATABASE r17912.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhJwsrFFe1ZNAAtS8Twuti
2026-07-28 08:23:40 +03:00
7cd7d57708 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
2026-07-28 00:50:26 +03:00
5bc2cb82f1 Verificare ANAF la alegerea partenerului: 404, disponibilitate serviciu (docs)
Design doc REVIZIA 5: contractul 404 (verdict "inexistent" doar cand raspunsul
contine chiar codul cerut), starile serviciului pe sesiune si banda cand ANAF nu
raspunde, cache doar pe verdicte pozitive, codul nenumeric.

Changelog: intrarea 2.11.65 descrie comportamentul asa cum ajunge la utilizator -
functionalitatea nu a fost inca livrata, deci corectiile din interiorul ei nu se
pomenesc separat.

TODOS: contractul 404 pe drumul batch (P4) si verificarea dupa tara partenerului
(P5), amanate explicit.

Codul: COMUN 95cf54e.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhJwsrFFe1ZNAAtS8Twuti
2026-07-27 16:25:18 +03:00
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