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