romfast/roafacturare
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
87063b06a8abc249ee77d2e0a759b10c3a86e98b
roafacturare/docs/cercetare/suprafata_regresie_contabilizeaza_articol.md
Marius Mutu d9f5ca4226 docs: planurile, proiectarile si rapoartele de lucru intra in versionare 
Folderul docs\ era pana acum in afara oricarui control de versiuni - nici git,
nici SVN - desi contine planurile pe puncte, proiectarile si rapoartele de
cercetare pe care se sprijina modificarile din cod. O stergere acolo era
definitiva.

Fisierele intermediare (handoff-uri intre sesiuni, diff-uri deja aplicate) au
fost sterse inainte, nu versionate: ce era durabil in ele a intrat in antetele
fisierelor de test la care se refereau.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
2026-08-11 22:17:17 +03:00

16 KiB
Raw Blame History

Suprafata de regresie — PACK_FACTURARE, functia contabilizeaza_articol

Cercetare pentru modificarea propusa: parametri noi DEFAULT NULL la finalul listei lui contabilizeaza_articol, plus o ramura activata doar cand parametrul e nenul. Ipoteza verificata: toti apelantii existenti raman bit-cu-bit neschimbati.

Sursa PL/SQL folosita: D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\08\ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql (17217 linii). Marcajul D:\ROA\ROAFACTURARE\versiune_db.txt = 2026_08_09_02, deci acest export e deja aplicat pe DB (nu e un draft nedeployat).

0. Constatarea centrala

contabilizeaza_articol este o FUNCTION cu un singur parametru:

ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql:746
  FUNCTION contabilizeaza_articol(detalii_articol VANZARI_DETALII_TEMP%ROWTYPE)

Cautare in tot D:\ROA\DATABASE (in afara de duplicatele istorice ale pachetului insusi in SCRIPTURI/, SCRIPTURI_CLAR/ si .svn/pristine, care sunt versiuni succesive ale aceleiasi definitii, nu apelanti): contabilizeaza_articol( apare apelata doar de 3 ori, toate in interiorul corpului pachetului PACK_FACTURARE insusi:

fisier:linie context
ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql:6141 pack_facturare.contabilizeaza_articol(tab_detalii(i));
ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql:6858 pack_facturare.contabilizeaza_articol(tab_detalii(i));
ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql:7140 pack_facturare.contabilizeaza_articol(tab_detalii(i));

Toate 3 sunt apeluri pozitionale identice, cu exact 1 argument (tab_detalii(i), o inregistrare VANZARI_DETALII_TEMP%ROWTYPE), din interiorul aceluiasi pachet (probabil din scrie_factura2 / scrie_factura_avize / scrie_factura_avize_retur — toate proceduri care itereaza tab_detalii).

Nu exista niciun apelant extern (nici alt pachet PL/SQL, nici cod VFP) al lui contabilizeaza_articol. Cautare directa pack_facturare\.scrie_nota\b si pack_facturare\.descarca_gestiune in tot codul VFP (.prg/.vc2/.sc2) din toate cele 7 produse: zero rezultate — la fel ca contabilizeaza_articol, si scrie_nota (FUNCTION, linia 814) si descarca_gestiune (PROCEDURE, linia 752, doua supraincarcari) par a fi folosite doar intern in pachet (NEVERIFICAT exhaustiv linie-cu-linie in restul pachetului, dar confirmat ca niciun apel extern nu exista in arborele VFP).

Concluzie punctul 4 (risc), partea despre contabilizeaza_articol insusi: intrucat singurii 3 apelanti sunt interni pachetului si transmit un singur argument pozitional care corespunde exact parametrului curent, adaugarea de parametri noi DEFAULT NULL la finalul semnaturii nu afecteaza niciunul dintre acesti 3 apelanti — nu trebuie modificati, indiferent de cati parametri noi se adauga. Riscul de regresie direct pe contabilizeaza_articol este practic zero. Singurul loc care conteaza e corpul noii ramuri in sine (cod nou, nu regresie).

Ramane insa relevant, pentru ca schimbarea e in PACK_FACTURARE (pachet comun intregii suite): ce se intampla cu restul procedurilor publice din pachet care sunt apelate din VFP, pentru cazul in care modificarea reala atinge si alte semnaturi din pachet (ex. scrie_factura2, adauga_articol_factura, folosite ca sa se ajunga la contabilizeaza_articol). Inventarul de mai jos acopera exact aceste cai.

1. Inventarul apelantilor (VFP + PL/SQL)

Cautat in tot D:\ROA: ROAFACTURARE, ROACONT, ROAGEST, ROAIMOB, ROAACNPRO, ROACONTRACTE, ROAAUTO (surse proprii + COMUN\ fiecaruia), plus D:\ROA\COMUNROA si D:\ROA\DATABASE.

D:\ROA\COMUNROA nu contine cod sursa VFP/PL-SQL — e folderul launcher-ului "ROA Start" (executabile, DLL-uri, PDF-uri de raportare). Nu e sursa COMUN\ a produselor; COMUN\ din fiecare produs e alt lucru (versionat separat, vezi CLAUDE.md). Zero rezultate acolo, cum era de asteptat.

1.1 adauga_articol_factura (si variantele _stoc, _deviz — proceduri distincte, nu supraincarcari ale aceleiasi)

produs fisier:linie nr. parametri trimisi mod
ROAFACTURARE (COMUN) COMUN\clase\ofacturare.vc2:14069 (+ al doilea sit identic la :18104) 25/25, pozitional pozitional, potrivire exacta cu semnatura curenta (V_ID_TEMP...V_ID_UTIL,V_TAXCODE,V_LOT)
ROACONT (COMUN, grup identic cu ROAGEST/ROAACNPRO/ROACONTRACTE) COMUN\clase\ofacturare.vc2:13853 (+ :17885) 25/25, pozitional idem
ROAGEST (COMUN) COMUN\clase\ofacturare.vc2 (offset ~13853, vezi 2.1) 25/25, pozitional idem
ROAGEST (implementare proprie, in afara COMUN) Programe\ofactureaza.prg:264 24 din 25 (se opreste la V_ID_UTIL, omite V_TAXCODE si V_LOT — ambii au deja DEFAULT NULL) pozitional, se bazeaza deja pe omiterea parametrilor finali cu default
ROAIMOB (COMUN) COMUN\clase\ofacturare.vc2 (offset ~13847) 25/25, pozitional idem grup
ROAACNPRO (COMUN) COMUN\clase\ofacturare.vc2 (offset ~13853, grup identic) 25/25, pozitional idem
ROACONTRACTE (COMUN) COMUN\clase\ofacturare.vc2 (offset ~13853, grup identic) 25/25, pozitional idem
ROAAUTO (COMUN) COMUN\clase\ofacturare.vc2:13853 (+ :17884) 25/25, pozitional idem
ROAACNPRO (implementare proprie) Programe\proceduri_acnpro.prg:3382 apeleaza adauga_articol_factura_deviz, nu adauga_articol_factura — 17+ parametri pozitionali, verificat pana la V_PRET_CU_TVA (linia 3399), coada netaiata explicit dar tiparul e identic cu ROAAUTO de mai jos pozitional
ROAAUTO (implementare proprie) Programe\oproceduri_devize.prg:1240 apeleaza adauga_articol_factura_deviz, 19 din 20 parametri (se opreste la V_TAXCODE, omite V_LOT final, care are DEFAULT NULL) pozitional
ROAFACTURARE (COMUN) COMUN\programe\ofacturare_stoc.prg:357 apeleaza adauga_articol_factura_stoc (procedura distincta), pozitional, identic in toate cele 7 produse (fisier byte-identic, vezi sectiunea 2) pozitional

Toate apelurile identificate sunt strict pozitionale — text SQL construit prin concatenare de string-uri VFP (lcSql = [pack_facturare.functie(] + Alltrim(Str(...)) + [,] + ...), nu apel VFP cu parametri numiti si nu => (named notation) in PL/SQL. Niciun apelant nu foloseste named notation. Singurul tip de apel care s-ar putea strica la adaugarea de parametri noi la coada ar fi un apel pozitional care specifica deja mai multi parametri decat lista curenta (nu e cazul gasit) sau un apel care se opreste inainte de un parametru fara DEFAULT (nu e cazul: ambele proceduri adauga_articol_factura si adauga_articol_factura_deviz au deja tiparul "coada de parametri opsionali cu DEFAULT NULL" folosit activ de ROAGEST si ROAAUTO astazi — precedent direct ca acest tipar de extensie e deja tolerat de codul existent).

1.2 scrie_factura2 / scrie_factura

Semnatura curenta (linia 640): 17 parametri, fara niciun DEFAULT — V_TOTFTVA... V_PARAMETRU_ADITIONAL (15 IN), V_ID_VANZARE (OUT), V_CURSOR_VERIFICARE (OUT, ultimul).

produs fisier:linie nr. parametri trimisi mod
ROAFACTURARE (COMUN) COMUN\clase\ofacturare.vc2:14345 (+ al doilea sit :18343) 16 din 17 — se opreste la V_ID_VANZARE (?@poDate.nid_vanzare), omite V_CURSOR_VERIFICARE pozitional
ROACONT/ROAGEST/ROAACNPRO/ROACONTRACTE (COMUN, grup identic) COMUN\clase\ofacturare.vc2:14130 (+ :18124) 16 din 17, idem pozitional
ROAIMOB (COMUN) COMUN\clase\ofacturare.vc2:14124 (+ :18118) 16 din 17, idem pozitional
ROAAUTO (COMUN) COMUN\clase\ofacturare.vc2:14129 (+ :18151) 16 din 17, idem pozitional
ROAGEST (implementare proprie) Programe\ofactureaza.prg:307 16 din 17, idem (?poDate.nid_vanzare e ultimul bind) pozitional

Anomalie semnalata, in afara scopului cerut dar relevanta pentru risc general pe pachet: toate sitele active de apel pentru scrie_factura2 — in toate cele 7 produse, in ambele implementari (COMUN si ROAGEST proprie) — transmit 16 din cele 17 parametri declarati, omitand complet ultimul parametru V_CURSOR_VERIFICARE OUT pack_facturare.cursor_facturare, care nu are DEFAULT (parametrii OUT nu pot avea DEFAULT in PL/SQL). Verificat identic in ambele exporturi disponibile (ff_2026_08_06_10 si ff_2026_08_09_01), deci nu e o modificare de ultima ora. NEVERIFICAT cum functioneaza efectiv acest apel in productie (nu am acces la DB live) — posibile explicatii: (a) goExecutor.oExecute(lcSql, lcCursorVerificare) are o logica proprie de completare/legare a cursorului de iesire care nu se vede din text, (b) parametrul are de fapt un comportament tolerat de driver-ul Oracle folosit, sau (c) e un bug preexistent, netestat de multa vreme pe acest cod-cale. Nu are legatura cu schimbarea propusa la contabilizeaza_articol (nu se ating parametrii lui scrie_factura2), dar merita un test manual separat inainte de a presupune ca "toate caile prin pachet functioneaza azi fara eroare".

1.3 scrie_nota / scrie_nota_import — fals pozitiv de cautare

scrie_nota_import gasit in ROACONT (Clase\oactualizari.vc2:920, Programe\ocont2003.prg:785, Programe\oproceduri_actualizari.prg:189, Programe\oproceduri_inchidere.prg:167,335,524) si in ROAGEST (Programe\inchidere_k.prg:192,257,373,381) NU este functia pack_facturare.scrie_nota din pachet — e o procedura VFP locala, definita in ROAFACTURARE\COMUN\programe\ooperatii_comune.prg:1081 (PROCEDURE scrie_nota_import(...)), folosita pentru import de note contabile, fara nicio legatura cu PACK_FACTURARE. Cautarea directa pack_facturare\.scrie_nota\b in tot arborele VFP a dat zero rezultate (sectiunea 0).

1.4 descarca_gestiune

Zero apeluri externe gasite in cod VFP (cautare directa pack_facturare\.descarca_gestiune, 0 rezultate in toate cele 7 produse). Pachetul are doua supraincarcari (liniile 752 si 773), probabil folosite doar intern (apelate din contabilizeaza_articol conform comentariului de la linia 1466: -- facturare_articole2, contabilizeaza_articol > descarca_gestiune) — NEVERIFICAT linie-cu-linie in restul corpului pachetului (17217 linii; nu am parcurs tot corpul, doar semnaturile si comentariile relevante), dar nimic din cautarea externa VFP le atinge.

2. Duplicarea fisierelor COMUN\

Comparatie pe continut (MD5), nu pe nume, pentru cele 3 fisiere unde s-au gasit apeluri, in cele 7 copii COMUN\ (ROAFACTURARE, ROACONT, ROAGEST, ROAIMOB, ROAACNPRO, ROACONTRACTE, ROAAUTO):

fisier rezultat
clase\ofacturare.vc2 4 variante distincte: ROAFACTURARE unic; {ROACONT, ROAGEST, ROAACNPRO, ROACONTRACTE} identice intre ele; ROAIMOB unic; ROAAUTO unic
programe\ofacturare_stoc.prg identic byte-cu-byte in toate cele 7 (un singur MD5)
programe\ooperatii_comune.prg identic in 6 din 7; ROAIMOB are o varianta diferita

Pentru ofacturare.vc2, desi hash-urile difera intre cele 4 grupuri (fisierul are ~19000 de linii si diferente in alte zone), structura si continutul exact al apelurilor catre adauga_articol_factura / scrie_factura2 sunt identice cuvant-cu-cuvant intre toate cele 4 variante — doar offset-ul de linie difera (ex. apelul adauga_articol_factura e la linia 14069 in ROAFACTURARE, 13853 in grupul ROACONT/ROAGEST/ROAACNPRO/ROACONTRACTE, 13847 in ROAIMOB, 13853 in ROAAUTO — text identic, verificat prin grep pe fiecare variant separat). Deci pentru scopul acestei schimbari: e acelasi sit de apel duplicat de 7 ori (nu 7 implementari independente care ar putea diverge in reactia la parametri noi), plus doua implementari suplimentare, independente si reale, in ROAGEST (Programe\ofactureaza.prg) si ROAACNPRO/ROAAUTO (Programe\proceduri_acnpro.prg / Programe\oproceduri_devize.prg, pentru varianta _deviz).

ofacturare_stoc.prg (contine apelul catre adauga_articol_factura_stoc) e literalmente acelasi fisier, deci 1 singur loc de verificat, nu 7.

3. Cine emite efectiv facturi prin acest pachet

Pe baza apelurilor gasite (nu doar a prezentei fisierului COMUN\ — care exista in toate 7, dar nu inseamna ca produsul chiar il foloseste activ pentru facturare):

produs ajunge la pack_facturare pentru facturare? dovada
ROAFACTURARE Da adauga_articol_factura + scrie_factura2 in COMUN\clase\ofacturare.vc2
ROACONT Da acelasi cod COMUN (grup identic)
ROAGEST Da, cu 2 cai codul COMUN identic + implementare proprie in Programe\ofactureaza.prg (posibil cod mai vechi/alternativ, coexista)
ROAIMOB Da varianta proprie de ofacturare.vc2, dar acelasi tipar de apel
ROAACNPRO Da, cu 2 cai codul COMUN (grup identic) + adauga_articol_factura_deviz in Programe\proceduri_acnpro.prg
ROACONTRACTE Da codul COMUN (grup identic) — nu are cale proprie suplimentara gasita
ROAAUTO Da, cu 2 cai varianta proprie de ofacturare.vc2 + adauga_articol_factura_deviz in Programe\oproceduri_devize.prg

Niciun produs din cele 7 nu pare sa aiba COMUN\clase\ofacturare.vc2 ca fisier mort — toate cele 7 au si Programe\ propriu (in afara de COMUN) care instantiaza clasa relevanta (NEVERIFICAT exhaustiv ca fiecare produs chiar instantiaza si ruleaza clasa din ofacturare.vc2 la runtime — verificarea s-a facut pe prezenta apelului in sursa, nu pe flux de executie live). Toate cele 7 produse sunt in aria de regresie pentru orice modificare de pachet care afecteaza adauga_articol_factura* sau scrie_factura2 — nu doar ROAFACTURARE.

4. Verdict de risc

Pentru contabilizeaza_articol insusi (obiectul cerut al schimbarii): risc practic zero. Cei 3 apelanti sunt toti interni pachetului, toti pozitionali cu un singur argument identic cu semnatura actuala (detalii_articol VANZARI_DETALII_TEMP%ROWTYPE). Adaugarea de parametri noi DEFAULT NULL la coada nu schimba niciunul dintre aceste 3 apeluri — nu necesita nicio modificare in cele 3 sit-uri, indiferent de produs. Nu exista niciun apel extern (nici alt pachet PL/SQL, nici VFP din niciun produs) care sa poata fi afectat, pentru ca nu exista niciun apel extern, punct.

Pentru pachetul PACK_FACTURARE in ansamblu, daca schimbarea reala atinge si alte proceduri publice (nu doar contabilizeaza_articol):

  • Tiparul "adauga parametri DEFAULT NULL la coada, apelantii pozitionali raman neschimbati" are deja precedent activ in codul curent: adauga_articol_factura (V_TAXCODE, V_LOT) si adauga_articol_factura_deviz (4 parametri finali cu DEFAULT) sunt deja apelate de unii producatori omitand parametrii finali optionali (ROAGEST, ROAAUTO). Deci genul de schimbare propus e sigur daca regula "toti parametrii noi sunt strict la coada si toti au DEFAULT" se respecta — ceea ce e exact ipoteza declarata pentru contabilizeaza_articol.
  • Singurul risc real identificat in tot pachetul nu vine din schimbarea propusa, ci e o anomalie preexistenta, independenta: apelurile la scrie_factura2 (in toate cele 7 produse) omit deja parametrul final V_CURSOR_VERIFICARE (OUT, fara DEFAULT posibil). Daca cineva "repara" acea nepotrivire ca parte a aceleiasi lucrari de mentenanta pe pachet, acolo ar trebui atinsi toti apelantii din sectiunea 1.2 — dar asta e o schimbare diferita de cea descrisa (parametri noi la contabilizeaza_articol), nesolicitata explicit aici. O semnalez ca sa nu fie confundata cu "toti apelantii raman neschimbati" pentru intregul pachet, daca scopul lucrarii se extinde.
  • Nu s-a gasit niciun apel cu named notation (=>) nicaieri in cele 7 produse pentru functiile cerute — deci nu exista risc de reordonare-parametri-pe-nume la adaugarea de parametri noi.

Lista de produse pe care trebuie rulata regresia (din sectiunea 3): toate cele 7 — ROAFACTURARE, ROACONT, ROAGEST, ROAIMOB, ROAACNPRO, ROACONTRACTE, ROAAUTO — pentru ca toate emit efectiv facturi prin acest pachet, chiar daca modificarea la contabilizeaza_articol insusi nu impune, teoretic, nicio schimbare de cod la niciunul dintre ele.