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