comun/docs/cercetare/rec_tva_vanzari.md

Cercetare: TVA calculat vs salvat (#7) + denormalizare VANZARI (#8)

Sursele principale sunt fisierele "curate" din arhiva de migrare Oracle D:\ROA\DATABASE\SCRIPTURI_CLAR\... (nu in working copy VFP git — DDL/PL-SQL nu e versionat in ROAFACTURARE), plus D:\ROA\ROAFACTURARE\COMUN\clase\ofacturare.vc2 (working copy VFP, text .vc2 deja la zi).

Cea mai recenta definitie completa a pachetului PACK_FACTURARE (COMUN, folosit de toate produsele ROA care factureaza) e in D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\03\ff_2026_03_23_04_COMUN_PACK_FACTURARE.sql (16948 linii). Toate liniile citate mai jos fara alta mentiune sunt din acest fisier.

---

SUBIECT A — TVA calculat, nu salvat (#7)

1. Structura VANZARI / VANZARI_DETALII (coloane pret/TVA)

Nu exista CREATE TABLE VANZARI_DETALII in arhiva cautata (tabela e mai veche decat SCRIPTURI_CLAR, care incepe efectiv din 2009; originea e probabil in D:\ROA\DATABASE\SCRIPTURI\2006-2008, nu am parcurs exhaustiv acel arhiv de migrari vechi). Coloanele efective au fost confirmate prin utilizarea lor in cod (view-uri + SQL dinamic VFP):

VANZARI_DETALII (per linie articol):

• PRET — pret unitar (fara/cu TVA, in functie de flag)
• DIFERENTA — ajustare pret (folosita in calculeaza_total_*_fact)
• DISCOUNT_UNITAR
• CANTITATE
• PRET_CU_TVA — flag NUMBER(1): 1 = pretul de mai sus e cu TVA inclus, 0 = fara TVA (ff_2026_07_27_01_FACTURARE.sql:25,43 — b.pret_cu_tva)
• PROC_TVAV — procent TVA ca multiplicator (ex. 1.19), nu procent brut (ff_2026_07_27_01_FACTURARE.sql:26 — b.proc_tvav)
• PRET_ACHIZITIE (ff_2026_07_27_01_FACTURARE.sql:105,130)
• ID_ARTICOL, ID_VALUTA, ID_POL (politica de pret), SERIE, STERS, ID_VANZARE, ID_VANZARE_DET (ff_2026_07_27_01_FACTURARE.sql:11-76)
• TAXCODE — adaugata 2022\03\ff_2022_03_24_01_COMUN_SAFT.sql:6 (cod taxa SAFT)
• ID_JTVA_COLOANA_EX — adaugata 2019\08\ff_2019_08_20_04_COMUN.sql:7
• LOT — adaugata 2024\06\ff_2024_06_04_01_COMUN_FACTURARE.sql:3

NU exista o coloana de TVA calculata/salvata per linie (nici valoare_tva, nici pret_fara_tva rezultat) — doar inputurile (pret, pret_cu_tva flag, proc_tvav), confirmand exact ce zice todo #7: TVA e derivat, nu stocat.

VANZARI (antet factura) — coloane denormalizate relevante TVA, toate adaugate prin 2017\03\ff_2017_03_28_01_FACTURARE.sql:9-38:

• DISCOUNT_TVA — "TVA DISCOUNT (DISCOUNT * MAX(PROC_TVA) ARTICOLE)"
• TOTAL_FARA_TVA, TOTAL_TVA, TOTAL_CU_TVA — totaluri pe document (denormalizate)
• VALOARE_ACHIZITIE
• vezi si Subiect B pt. SERIE_INCASAT/NR_INCASAT/SUMA_INCASAT/TIP_INCASAT/AVIZE

2. Unde se calculeaza TVA-ul pe linie — toate locurile

Calculul e centralizat in doua straturi Oracle, apelate de fiecare punct de consum (VFP nu face calcul TVA local — doar construieste SQL dinamic care cheama functiile Oracle):

• PACK_SESIUNE.calculeaza_pret_fara_tva/tva/cu_tva — motorul de rotunjire per-unitate de pret (nu e in PACK_FACTURARE; pachetul PACK_SESIUNE nu a fost gasit definit separat in arhiva cautata — cautare punctuala pe cateva luni din 2025/2026, fara succes; probabil e intr-un script COMUN_PACK_SESIUNE mai vechi, netestat exhaustiv).

• PACK_FACTURARE.calculeaza_pret (linia 14557) — wrapper subtire peste cele 3 functii PACK_SESIUNE de mai sus.

• PACK_FACTURARE.calculeaza_sume (linia 14631, spec 980) — calculeaza suma_fara_tva / suma_tva / suma_cu_tva pe linie (cantitate * pret), delegand catre:

  • calculeaza_total_fara_tva (linia 15745/15769) — delega la pack_sesiune.calculeaza_total_fara_tva
  • calculeaza_total_tva (linia 15850/15874) — delega la pack_sesiune.calculeaza_total_tva
  • calculeaza_total_cu_tva (linia 15638/15662) — delega la pack_sesiune.calculeaza_total_cu_tva
  • variantele _fact (calculeaza_total_fara_tva_fact 15794, calculeaza_total_tva_fact 15899, calculeaza_total_cu_tva_fact 15687) au formula proprie inline (nu delega la pack_sesiune), documentata explicit in cod ca fiind "folosita in view-ul fact_vrap_centralizator_fact" (comentarii 15686, 15744, 15793, 15848, 15897).

  Formula _fact (exemplu calculeaza_total_tva_fact, 15899-15949) e explicit ROUND-based, cu ramuri separate pentru discount_evidentiat — aici e punctul central de rotunjire per linie.

• Puncte de CONSUM ale acestor functii (unde efectiv se calculeaza TVA afisat/raportat):

  • Views fact_vrap_fact_articole si fact_vrap_articole_vandute (ff_2026_07_27_01_FACTURARE.sql:18-44, 131-196 — apeleaza calculeaza_total_fara_tva/calculeaza_total_tva direct in SELECT)
  • Raport VFP dinamic: COMUN\programe\oproceduri_rapoarte_fact.prg:581-590 — SQL construit in VFP apeleaza direct pack_sesiune.calculeaza_pret_cu_tva(...) si pack_sesiune.calculeaza_total_cu_tva(...) pentru listare/relistare rapoarte articole vandute.
  • PACK_FACTURARE.scrie_in_vanzari (13468) si finalizeaza_avize_lucrare (14807) — calculeaza si scriu VANZARI.TOTAL_FARA_TVA/TOTAL_CU_TVA folosind calculeaza_total_fara_tva_fact in subquery-uri (13716-13786, 14965-15008).
  • verifica_total_document (16009) — vezi punctul 5, verifica totalul calculat vs. cel din notele contabile si genereaza o corectie.

  Nu am gasit un apel VFP direct catre calculeaza_pret( sau calculeaza_sume( in working copy ROAFACTURARE/COMUN (grep pe nume exact, fara rezultate) — deci formularul de introducere factura in VFP nu recalculeaza local pretul/TVA-ul linie cu linie prin apel explicit de procedura; cel mai probabil articolele + preturile lor (deja cu pret, pret_cu_tva, proc_tvav) vin dintr-un cursor Oracle (PACK_FACTURARE.cursor_preturi, spec 335, body 2121) populat cand se adauga articolul, iar TVA vizibila in grid e calculata la afisare din acele coloane brute — nu am gasit expresia VFP exacta (cursor_preturi e ~500 linii, nu am parcurs linie cu linie in bugetul acestei cercetari).

3. Ce inseamna "preturi_cu_tva" / pret_cu_tva

• Pe linie: VANZARI_DETALII.PRET_CU_TVA — NUMBER(1), 0/1, transmis ca parametru V_PRET_CU_TVA / V_PRET_ARE_TVA la toate functiile de calcul de mai sus (controleaza care ramura de formula se aplica — pornind de la pret cu TVA sau fara TVA).
• In grid-ul VFP exista o coloana checkbox cPret_cu_tva in D:\ROA\ROAFACTURARE\Clase\ofundal_facturare.vc2:696-699 (_grdrow2.cPret_cu_tva...) — probabil afiseaza/permite editarea flagului per linie in formular.
• Nu am gasit coloana PRET_CU_TVA (sau similara) direct pe CRM_POLITICI_PRETURI in scripturile de migrare cautate (am cautat ALTER TABLE CRM_POLITICI_PRETURI ADD, fara hit pe acest nume) — deci originea exacta a valorii implicite per politica de pret ("politica are bifat 'preturi fara TVA'", cum descrie todo #7) nu e confirmata cu fisier:linie; e probabil citita/propagata in PACK_FACTURARE.cursor_preturi (2121) sau citeste_setari_pol_pret (spec 324, body 2025) cand se adauga articolul pe factura — nu am parcurs acele corpuri in detaliu (buget de cercetare).

4. Locuri de atins daca s-ar salva pret_cu_tva/valoare_tva per linie real (nu calculat)

Enumerare pe baza punctelor de consum gasite mai sus:

1. DDL: ALTER TABLE VANZARI_DETALII ADD (valoare_tva, pret_fara_tva_calculat, ...) — coloane noi + migrare date istorice.
2. PACK_FACTURARE (Oracle, ff_2026_03_23_04_COMUN_PACK_FACTURARE.sql):
   • adauga_articol_factura (spec 529, body 4972) — punctul unde se insereaza linia in VANZARI_DETALII_TEMP; ar trebui sa scrie valoarea (eventual editata de user) in loc s-o lase doar pe pret/pret_cu_tva/proc_tvav.
   • calculeaza_sume (14631) — daca valoarea e editabila, aceasta procedura ar trebui sa citeasca valoarea salvata in loc s-o recalculeze, sau sa fie ocolita.
   • scrie_in_vanzari (13468) si finalizeaza_avize_lucrare (14807) — subquery-urile care insumeaza calculeaza_total_fara_tva_fact/calculeaza_total_tva_fact pe toate liniile (13716-13786, 14965-15008) ar trebui sa insumeze coloana noua in loc s-o recalculeze.
   • verifica_total_document (16009) — logica de reconciliere total-vs-note-contabile ar trebui ajustata (vezi punct 5) daca totalul nu se mai deriva strict din formula.
3. Views Oracle: fact_vrap_fact_articole, fact_vrap_articole_vandute (ff_2026_07_27_01_FACTURARE.sql:10-257), fact_vfacturi/fact_vfacturi2 (vezi Subiect B #11) — toate ar trebui sa citeasca noua coloana in loc de calculeaza_total_*.
4. VFP: COMUN\programe\oproceduri_rapoarte_fact.prg:581-590 — SQL-ul de raport care apeleaza direct pack_sesiune.calculeaza_pret_cu_tva/calculeaza_total_cu_tva.
5. VFP grid formular: D:\ROA\ROAFACTURARE\Clase\ofundal_facturare.vc2 (coloana cPret_cu_tva + coloanele de pret/valoare din grid — nu identificate exhaustiv, cautare punctuala doar pe flag).
6. Rapoarte .frx care afiseaza TVA pe linie de factura (ex. usr_factura*.fr2 — 25 de fisiere gasite cu referinta la PACK_FACTURARE, listate la cautarea initiala; nu au fost deschise individual).

Estimare: minim 6 zone distincte (DDL, pachet Oracle ~4 proceduri, 3-4 views, 1 program raport VFP, grid formular, rapoarte .frx) — consistent cu observatia ca e o schimbare "de volum", nu locala.

5. Mecanism existent de ajustare/rotunjire

Da, exista, dar la nivel contabil, nu la nivel de linie facturata / vizibil userului.

PACK_FACTURARE.verifica_total_document (linia 16009-16188+) compara totalul FTVA/TVA asteptat (pack_facturare.ntotftva, populat din VFP la pnTotalFtva/Thisform.nbazaron) cu suma reala din notele contabile generate (ACT_TEMP, grupate pe conturi 4111/4427/418/4428). Daca difera (16082-16083: NVL(pack_facturare.ntotftva,0) <> V_TOTFTVA_VER), calculeaza diferenta pack_facturare.ndifftva := pack_facturare.ntotftva - V_TOTFTVA_VER (16085) si insereaza automat o linie de corectie in ACT_TEMP (16086-16188, INSERT cu suma => pack_facturare.ndifftva) — adica ajustarea de rotunjire se absoarbe silentios in nota contabila, nu apare ca linie editabila pe factura si nu se reflecta in VANZARI_DETALII. Aceasta e probabil exact mecanismul care face ca utilizatorul sa nu poata corecta manual TVA-ul afisat: rotunjirea se "repara" doar in contabilitate, dupa fapt.

---

SUBIECT B — Denormalizare VANZARI, bug facturi din avize + numerar (#8)

6. Locatia PACK_FACTURARE

Nu exista fisier .pck/.sql cu acest pachet in working copy ROAFACTURARE (nici in COMUN/ local) — e in afara working copy-ului VFP, in arhiva DDL/PL-SQL Oracle D:\ROA\DATABASE\SCRIPTURI_CLAR\. Cea mai recenta versiune completa (16948 linii):

D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\03\ff_2026_03_23_04_COMUN_PACK_FACTURARE.sql

(exista si un diff mai nou, doar pe view-uri, 2026\07\ff_2026_07_27_01_FACTURARE.sql — vezi #11). Istoricul complet de modificari e in SCRIPTURI_CLAR\<an>\<luna>\ff_..._COMUN_PACK_FACTURARE.sql respectiv ..._FACTURARE.sql (zeci de fisiere, 2006-2026).

7. Procedura care scrie in VANZARI valorile denormalizate

PACK_FACTURARE.scrie_in_vanzari (spec linia 894, body linia 13468-13908) — apelata din finalizeaza_factura (linia 14740). Face UPDATE VANZARI SET ... cu (13886-13898):

total_fara_tva    = lnTotalFaraTVA,
...
total_cu_tva      = lnTotalCuTVA,
...
serie_incasat     = lnSerieIncasat,
nr_incasat        = lnNrIncasat,
suma_incasat      = lnSumaIncasat,
tip_incasat       = lnTipIncasat

unde lnSerieIncasat/lnNrIncasat/lnSumaIncasat/lnTipIncasat sunt populate (13727-13730) din variabilele de pachet pack_facturare.cserie_act_incasare, .nnumar_act_incasare, .nsuma_incasare, .ntip_doc_incasare (declarate 179-182).

O a doua ramura echivalenta exista in finalizeaza_avize_lucrare (spec 1011, body 14807-15176), care face acelasi UPDATE (15124-15130) — pentru ramura "avize pe lucrare".

Variabilele de pachet cserie_act_incasare/nnumar_act_incasare/ntip_doc_incasare/ nsuma_incasare sunt setate doar de PACK_FACTURARE.scrie_incasari (spec 864, body 13070-13139), apelata condiționat (IF V_LISTA_INCASARE IS NOT NULL) din:

• scrie_factura2 — linia 6178 (ramura factura normala / comanda / contract)
• scrie_factura_avize — linia 7008 (ramura factura din aviz)

Sunt resetate la NULL in initializeaza_date_factura (comentariu 1384-1386, cod la 1876-1880) — fix explicit din 03.07.2020: "ramaneau completate pe facturile urmatoare de la o factura anterioara".

VANZARI.AVIZE (seria/numarul avizelor facturate) e scris de scrie_corespondente_vanzari (spec 1057, body 15421-15457, comentariu la linia 15445: "Completez VANZARI.AVIZE redundant, pentru a nu face mai rapid fact_vfacturi") — nu am confirmat in acest buget de cercetare din ce apeleaza finalizeaza_factura daca scrie_corespondente_vanzari ruleaza necondiționat pe toate tipurile sau doar pe unele (V_TIP e parametru) — merita verificat punctual daca se investigheaza bug-ul mai departe.

8. Coloanele denormalizate din VANZARI si ramura care le populeaza

Toate adaugate prin 2017\03\ff_2017_03_28_01_FACTURARE.sql:9-38 (comentariu fisier, linia 1-4: "adaugare coloane in vanzari pentru denormalizarea join-urilor din fact_vfacturi"):

Coloana	Comentariu DB (linia 44-54 din script)	Populata de
DISCOUNT_TVA	TVA DISCOUNT (DISCOUNT * MAX(PROC_TVA) ARTICOLE)	scrie_in_vanzari
VALOARE_ACHIZITIE	Valoare la pret achizitie articole	scrie_in_vanzari
TOTAL_FARA_TVA	Total fara TVA lei	scrie_in_vanzari (13886), finalizeaza_avize_lucrare (15124)
TOTAL_TVA	Total TVA lei	idem
TOTAL_CU_TVA	Total cu TVA lei	scrie_in_vanzari (13888), finalizeaza_avize_lucrare (15126)
SERIE_INCASAT	Seria chitanta/bon fiscal	scrie_in_vanzari (13895), din pack_facturare.cserie_act_incasare (setat de scrie_incasari)
NR_INCASAT	Nr chitanta/bon fiscal	idem (13896)
SUMA_INCASAT	Suma chitanta/bon fiscal	idem (13897)
TIP_INCASAT	11=CHITANTA, 2=BON FISCAL	idem (13898); vezi si nTipIncasareCardBancar=3, nTipIncasareTichete=5
AVIZE	Serie/numar avize facturate (max 1000 caractere, comentariu la linia 1490)	scrie_corespondente_vanzari (15421)

9. Tipurile de factura/aviz si ramificarea codului

Din VANZARI.TIP (CASE explicit in view fact_vfacturi2, ff_2017_03_28_01_FACTURARE.sql:89-171) — cateva valori cheie: 1=POLITICA PRETURI, 2=CONTRACT, 3=COMANDA, 4=FACT. DIN AVIZ, 21=AVIZ PE BAZA DE COMANDA, 24=AVIZ DE RETUR, 43=BON FISCAL MAGAZIN, etc. (lista completa la liniile citate).

Ramificare in VFP, D:\ROA\ROAFACTURARE\COMUN\clase\ofacturare.vc2, metoda do_scrie_factura — exista doua copii aproape identice ale acestei logici, in doua clase diferite (confirmat via vfp_symbols.ps1 -Where):

• frm_facturare_articole.do_scrie_factura — liniile 13981-14339
• frm_facturare_articole2.do_scrie_factura — liniile 18004-18331

Structura DO CASE (identica in ambele, ex. clasa 1 la liniile 14067-14174):

• poDate.eProforma = 1 → {call pack_facturare.scrie_proforma(...)} (14071)
• poDate.Tip = 4 → {call pack_facturare.scrie_factura_avize(...)} (14103) — "facturare din aviz" (comentariu 14086-14087)
• poDate.Tip IN (3,21,25,28,42,47) → {call pack_facturare.scrie_factura2(...)} (14130) — "facturare pe baza de comanda / avize pe baza de comanda"
• Otherwise → {call pack_facturare.scrie_factura2(...)} (14158) — politica de preturi/contract

Inainte de asta, lista de incasare lcListaIncasare se construieste (14012-14038) din poDate.ntip_incasare (11=chitanta, 2=bon fiscal, 3=POS/card), comun tuturor ramurilor.

10. Ramura "factura din aviz" + "achitata numerar" — ce ar trebui sa scrie si ipoteza de cauza

Ce se intampla, pas cu pas (Tip = 4, ntip_incasare in (11,2,3)):

1. VFP (ofacturare.vc2:14012-14038) construieste lcListaIncasare de forma '11|<suma>|<id_casa>;' (chitanta) sau '2|...'/'3|...' (bon fiscal/card) — daca ntip_incasare nu e in (11,2,3), lcListaIncasare = [NULL] (literal SQL NULL).
2. VFP construieste lcSql = {call pack_facturare.scrie_factura_avize(pnDiscount, serie_chit, nr_incasare, lcListaIncasare, id_delegat, id_masina, id_facturare, listare_detaliata, dataora_exp, id_agent, text_aditional, discount_evidentiat, param_aditional, ?@nid_vanzare)} (14103-14115) — semnatura corespunde exact cu procedura Oracle activa scrie_factura_avize (linia 6675-7041, care NU are V_TOTFTVA/V_TOTTVA ca prime argumente, spre deosebire de scrie_factura2 — asta e corect, nu e discrepanta de parametri).
3. In Oracle, scrie_factura_avize (7007-7012): IF V_LISTA_INCASARE IS NOT NULL THEN pack_facturare.scrie_incasari(...) — deci doar daca lcListaIncasare nu e literalul NULL se seteaza variabilele de pachet cserie_act_incasare/etc.
4. scrie_factura_avize seteaza pack_facturare.clistaid_avize := ...V_LISTAID (7020) — lista de ID-uri de avize facturate, folosita ulterior de scrie_corespondente_vanzari pentru VANZARI.AVIZE.
5. scrie_factura_avize cheama finalizeaza_factura (7026-7034), care cheama scrie_in_vanzari (14740) → scrie serie_incasat/nr_incasat/suma_incasat/tip_incasat din variabilele de pachet setate la pasul 3.

La nivel de cod citit, lantul pare corect cablat — parametrii trec prin, semnaturile se potrivesc, iar cele doua clase VFP (frm_facturare_articole si frm_facturare_articole2) au logica identica pentru aceasta ramura.

IPOTEZA (cauza posibila a bug-ului, nedemonstrata prin citire de cod — necesita investigatie suplimentara/testare):

• Daca ordinea reala de operatii difera de ordine_operatii_facturare.txt (ex. daca intre pasul 3 si pasul 5 se mai apeleaza initializeaza_date_factura pentru alt document/lucru din aceeasi sesiune, inainte ca finalizeaza_factura sa apuce sa citeasca variabilele de pachet), fix-ul din 03.07.2020 (linia 1876-1880, reset la NULL) ar putea sterge datele de incasare inainte ca scrie_in_vanzari sa le foloseasca — dar nu am gasit in codul citit un asemenea apel intercalat.
• Alternativ: daca pe ramura aviz scrie_corespondente_vanzari (care scrie VANZARI.AVIZE) nu e apelata necondiționat din finalizeaza_factura pentru TIP=4 (nu am verificat corpul complet al finalizeaza_factura, liniile 14723-14807, dincolo de apelul la scrie_in_vanzari) — merita verificat explicit daca acel apel exista si e neconditionat de tip.
• Nu am verificat daca exista vreo diferenta intre scrie_factura_avize si scrie_factura_avize_retur (spec 667, alta ramura pentru tip retur din aviz) in privinta apelului scrie_incasari/scrie_in_vanzari — posibil ca bug-ul sa fie specific ramurii de retur, nu celei simple.

Recomandare pentru pasul urmator (daca se investigheaza mai departe): instrumentare/breakpoint pe scrie_in_vanzari (13468) intr-un mediu de test, pentru o factura Tip=4 platita numerar, verificand valorile efective ale pack_facturare.cserie_act_incasare/nnumar_act_incasare/nsuma_incasare/ ntip_doc_incasare chiar inainte de UPDATE (13886-13898).

11. Cele doua view-uri de facturi

• fact_vfacturi — view-ul "original" (pe model relational, cu join-uri catre VANZARI_DETALII / ACT / etc., fara denormalizare). Redefinit de multe ori de-a lungul timpului; cea mai recenta gasita: D:\ROA\DATABASE\SCRIPTURI_CLAR\2023\11\ff_2023_11_17_01_COMUN.sql (si 2023\02\ff_2023_02_08_01_COMUN.sql) — nu am deschis continutul exact in acest buget.
• fact_vfacturi2 — view-ul cu totaluri denormalizate din VANZARI (total_fara_tva, total_tva, total_cu_tva, serie_incasat, nr_incasat, suma_incasat, tip_incasat, avize citite direct din coloanele VANZARI, nu recalculate din VANZARI_DETALII/ACT). Definit initial in D:\ROA\DATABASE\SCRIPTURI_CLAR\2017\03\ff_2017_03_28_01_FACTURARE.sql:59-236, cu comentariul explicit (linia 3): "View fact_vfacturi2 - temporar, urmand a inlocui view-ul fact_vfacturi, dupa completarea coloanelor din vanzari pentru datele existente deja".

Separat, exista si o a doua pereche de view-uri, mai recenta si mai granulara (pe linie de articol, nu pe factura): fact_vrap_fact_articole / fact_vrap_articole_vandute, definite in D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\07\ff_2026_07_27_01_FACTURARE.sql:10-257 — acestea NU citesc din coloane denormalizate, ci calculeaza TVA live prin pack_facturare.calculeaza_total_* (vezi Subiect A #2). Nu sunt aceleasi cu perechea mentionata in cerinta (care pare sa se refere la fact_vfacturi/fact_vfacturi2), dar sunt relevante daca se cauta "view-ul cu totaluri din vanzari" generic.

---

Note metodologice

• PACK_SESIUNE (motorul de rotunjire per-pret, apelat de PACK_FACTURARE) nu a fost gasit definit ca fisier separat in cautarile punctuale facute (cateva luni din 2025-2026); daca se continua investigatia pe rotunjire, merita o cautare dedicata create or replace package pack_sesiune in D:\ROA\DATABASE\SCRIPTURI_CLAR.
• Arhiva D:\ROA\DATABASE\SCRIPTURI_CLAR e foarte mare (mii de fisiere, 2009-2026); cautarile de mai sus au fost tintite (nume de coloane/proceduri cunoscute), nu exhaustive — un grep complet pe intreg arhivul repetat timeout la 20s in unele incercari initiale.
• Nu am gasit apeluri catre PACK_FACTURARE din D:\ROA\ROAFACTURARE propriu-zis (in afara COMUN\clase\ofacturare.vc2) — pachetul e consumat exclusiv prin acea clasa si prin COMUN\programe\oproceduri_rapoarte_fact.prg.