# Cercetare: calea VFP->Oracle la emitere si calea propusa pentru editare (#6, punctul E.4)

Sursa: interogari SELECT proaspete pe `MARIUSM_AUTO@ROA_CENTRAL` (08.08.2026), acelasi mediu si
aceeasi versiune de baza ca in `rec_s5_oracle_vanzari.md` (nu s-a schimbat nimic intre cele doua
cercetari din aceeasi zi). Numerele de linie PL/SQL de mai jos sunt dintr-un export propriu, facut
in aceasta sesiune, din `all_source` pentru `PACK_FACTURARE` (schema/pachet identic cu cel din
raportul anterior). Partea VFP e din cache-ul text `.vc2` din proiect (nu binarul).

Aceasta cercetare inchide golul lasat de `rec_s5_oracle_vanzari.md`, sectiunea E.4: cum ajung
liniile facturii in Oracle la emitere si care e calea corecta pentru editare.

## 1. Calea de azi, capat la capat

### 1.1 VFP: cine populeaza `VANZARI_DETALII_TEMP`

Raspuns: **Oracle**, prin apeluri per-linie facute din VFP, nu VFP direct prin INSERT.

- `frm_facturare_articole.do_scrie_articole` (`COMUN\clase\ofacturare.vc2:13967-14195`):
  - `:13981-13999` cheama `pack_facturare.initializeaza_date_factura(...)` (antetul documentului,
    tine minte parametrii in stare de sesiune pe pachet: `pack_facturare.ntip`, `nid_sucursala`,
    `nid_util` etc. — folosite mai jos de `adauga_articol_factura`).
  - `:14036-14115`: `SELECT crsfactura` -> `SCAN`, cate un `Scatter Name poArt MEMO` per linie, apoi
    pentru fiecare linie fara rata de contract (`ELSE` la `:14051`) construieste text PL/SQL literal
    (nu `{call}` cu parametri legati) si apeleaza
    `pack_facturare.adauga_articol_factura(id_temp, id_articol, serie, explicatie, id_pol,
    id_gestiune, pret_achizitie, pretd, id_valutad, pret, id_valuta, cu_tva, gestionabil,
    cantitate, discount, cont, curs, multiplicator, id_jtva_coloana, id_part_rez, id_lucrare_rez,
    pretv_orig, id_set_fact, id_ctr, gnIdUtil, taxcode, lot)` (`:14069-14091`), executat imediat
    prin `goExecutor.oExecute(lcSql)` (`:14105`) — **un apel Oracle per linie de factura**, in
    bucla, nu un singur apel cu tot cursorul.
  - Pentru liniile din seturi: `pack_facturare.initializeaza_seturi_temp` + un apel
    `pack_facturare.adauga_articol_set(...)` per linie de set (`:14117-14154`), scrie in
    `VANZARI_SETURI_TEMP`.
- `frm_facturare_articole.do_scrie_factura` (`:14197-14554`): dupa ce toate liniile au fost urcate
  in TEMP prin apelurile de mai sus, apeleaza finalizarea documentului —
  `pack_facturare.scrie_factura2(...)` (facturi, `:14345`/`:14373`) sau
  `pack_facturare.scrie_proforma(...)` (`:14286`) sau `scrie_factura_avize(...)`/
  `scrie_factura_avize_retur(...)` dupa tipul documentului — **un singur apel**, fara sa mai
  transmita liniile (ele sunt deja in `VANZARI_DETALII_TEMP`, populata de bucla anterioara, in
  ACEEASI sesiune/tranzactie Oracle).

### 1.2 Oracle: `adauga_articol_factura` — nu doar INSERT, RECALCULEAZA din sursa originala

Verificat sursa completa a procedurii publice `pack_facturare.adauga_articol_factura` (semnatura cu
`V_ID_TEMP` ca prim parametru, cea apelata de VFP la `:14069`) — **nu** e un simplu INSERT cu
valorile primite de la VFP. Ramifica pe `pack_facturare.ntip` (starea de sesiune setata la
`initializeaza_date_factura`) si **re-deriva** `V_PRET`, `V_PROC_TVAV`, `V_ID_VALUTA`,
`V_PRETURI_CU_TVA`, `V_IN_STOC` direct din documentul-sursa:
- `ntip IN (3,21,28,42,47)` (facturare din comenzi): `SELECT ... FROM COMENZI_ELEMENTE ...`
- `ntip = 4` (facturare din avize): `SELECT ... FROM VANZARI_DETALII ...` (avizul deja scris)
- `ntip = 45` (restaurant): calcul din `JTVA_COLOANE` + `CRM_POLITICI_PRET_ART`
- `V_OPT_FACTURARE = 3` (contract): `SELECT ... FROM CTR_ARTICOLE ...`
- fallback (`ELSE`): doar cota TVA din `JTVA_COLOANE`, restul (`V_PRET`, `V_ID_VALUTA`,
  `V_PRETURI_CU_TVA`, `V_IN_STOC`) preluate ca atare din parametrii transmisi de VFP.

Abia dupa acest bloc `CASE` urmeaza INSERT-ul propriu-zis:

```sql
INSERT INTO VANZARI_DETALII_TEMP
  (ID_TEMP, ID_ARTICOL, SERIE, LOT, EXPLICATIA, ID_POL, PRET_ACHIZITIE, PRETD, ID_VALUTAD,
   PRET, PRET_CU_TVA, PROC_TVAV, CANTITATE, DISCOUNT_UNITAR, ID_GESTIUNE, CONT, ID_VALUTA,
   CURS, MULTIPLICATOR, ID_JTVA_COLOANA, IN_STOC, ID_VANZARE_SET, ID_PART_REZ, ID_LUCRARE_REZ,
   PRETV_ORIG, CUSTODIE, ID_CTR, ID_UTIL, TAXCODE)
VALUES (...)
```

(am confirmat integral corpul, INSERT-ul e ultimul bloc din procedura, imediat dupa `END CASE`).

**Consecinta directa pentru #6**: `adauga_articol_factura` NU poate fi reutilizata ca atare pentru
editare — depinde de starea de sesiune `pack_facturare.ntip`/`clistaid`/`id_ctr` care descrie
DOCUMENTUL SURSA de la emitere (comanda/aviz/contract), stare care nu exista si nu are sens la o
editare ulterioara a facturii deja emise. Orice procedura noua pentru editare trebuie sa scrie
direct in `VANZARI_DETALII` (tabela reala), nu prin acest drum.

Exista si `sterge_articol_factura(V_ID_TEMP, V_ID_UTIL)` — `DELETE FROM VANZARI_DETALII_TEMP WHERE
ID_TEMP = V_ID_TEMP` — folosita doar cat timp factura e in curs de compunere (inainte de emitere),
nu dupa.

### 1.3 Oracle: `scrie_factura2` -> `finalizeaza_factura` -> `scrie_in_vanzari` — trecerea TEMP -> real

`scrie_factura2` (PACK_FACTURARE, corpul activ, nu varianta comentata din cod):
- `:70` `pack_contafin.sterge_temp_actrul()`, seteaza `pack_facturare.ntotftva/ntottva` din
  parametri (valori calculate in VFP).
- `:84` `SELECT * BULK COLLECT INTO tab_detalii FROM VANZARI_DETALII_TEMP` — citeste TOATA tabela
  temp intr-un array PL/SQL, fara filtru pe sesiune (GTT-ul e oricum izolat per sesiune/tranzactie).
- Bucla pe `tab_detalii`, ramificata tot pe `ntip` (transfer intre subunitati, restaurant etc.) —
  pentru cazul standard de factura apeleaza mai departe spre `pack_facturare.finalizeaza_factura`.

`finalizeaza_factura` (nu comentata):
```sql
pack_facturare.initializeaza_scriere_actrul(V_DATAORA);
pack_facturare.scrie_in_vanzari(V_DISCOUNT_FACTURA, V_ID_DELEGAT, V_ID_MASINA, V_ID_FACTURARE,
  V_LISTARE_DETALIATA, V_DATAORA_EXP, V_ID_AGENT, V_TEXT_ADITIONAL, pack_facturare.nid_vanzare);
pack_facturare.finalizeaza_scriere_actrul();
-- update vanzari set id_fact = ... (completare id_fact dupa scrierea in contabilitate)
```

`scrie_in_vanzari` — gasit exact mecanismul care lipsea din raportul anterior:
- `INSERT INTO VANZARI (...) VALUES (...) RETURNING ID_VANZARE INTO pack_facturare.nid_vanzare`
  (randul parinte, un rand per document din bucla pe `tab_vanz`, tabela interna cu documentele de
  scris — cazul normal e un singur document).
- `pack_facturare.scrie_cursuri(pack_facturare.nid_vanzare)`.
- **Trecerea efectiva TEMP -> real**:
  ```sql
  INSERT /*+ APPEND */ INTO VANZARI_DETALII
    (ID_VANZARE, ID_ARTICOL, SERIE, ID_POL, CANTITATE, PRET_ACHIZITIE, PRETD, ID_VALUTAD,
     PRET, PROC_TVAV, DISCOUNT_UNITAR, ID_GESTIUNE, ID_VALUTA, CONT, PRET_CU_TVA, ID_JTVA_COLOANA)
  SELECT pack_facturare.nid_vanzare, ID_ARTICOL, SERIE, ID_POL, CANTITATE, PRET_ACHIZITIE, PRETD,
         ID_VALUTAD, PRET, PROC_TVAV, DISCOUNT_UNITAR, ID_GESTIUNE, ID_VALUTA, CONT, PRET_CU_TVA,
         ID_JTVA_COLOANA
    FROM VANZARI_DETALII_TEMP
   WHERE ID_COMANDA = tab_vanz(i).id_comanda AND NUMAR_ACT = tab_vanz(i).numar_act
   ORDER BY ID_TEMP;
  ```
  Cheia de potrivire intre randul nou din `VANZARI` si liniile lui din TEMP e
  `(ID_COMANDA, NUMAR_ACT)` — nu `ID_TEMP` direct — pentru ca un singur apel poate scrie mai multe
  documente `VANZARI` deodata (facturare pe mai multe comenzi/numere de act simultan); fiecare
  document isi ia doar liniile care se potrivesc.
- Coloanele COPIATE in `VANZARI_DETALII` sunt un subset din `VANZARI_DETALII_TEMP` (16 coloane) —
  `ID_TEMP`, `ID_CTR`, `ID_UTIL`, `TAXCODE`, `LOT`, `ID_VANZARE_SET`, `ID_PART_REZ`,
  `ID_LUCRARE_REZ`, `PRETV_ORIG`, `CUSTODIE`, `NUMAR_ACT`, `ID_COMANDA`, `ID_GESTIUNE_DEST`
  raman DOAR in TEMP, nu se copiaza in tabela reala (`VANZARI_DETALII` nu are coloanele `ID_TEMP`,
  `NUMAR_ACT`, `ID_COMANDA` etc. — confirmat din `all_tab_columns`, vezi 2.2).
- Urmeaza blocul de agregare (`SELECT INTO` din `VANZARI_DETALII_TEMP`, deja documentat in
  `rec_s5_oracle_vanzari.md` A.3-A.4) si `UPDATE VANZARI SET total_fara_tva=..., ...` cu totalurile
  denormalizate.

**PK-ul `VANZARI_DETALII.ID_VANZARE_DET`** se genereaza automat: trigger `TRG_VANZARI_DET_BEFOINS`
(`BEFORE INSERT ... FOR EACH ROW`, verificat prin `dbms_metadata.get_ddl`) face exclusiv
`SELECT SEQ_VANZARI_DETALII.NEXTVAL INTO :NEW.ID_VANZARE_DET FROM DUAL` — nu seteaza alte coloane.
Deci **orice INSERT nou in `VANZARI_DETALII`** (inclusiv unul scris pentru #6, la adaugare de linie
noua la editare) primeste automat PK-ul corect fara sa fie nevoie de secventa apelata manual din
codul de editare.

## 2. Natura tabelei temp si structura

### 2.1 `VANZARI_DETALII_TEMP` — Global Temporary Table, `ON COMMIT DELETE ROWS`

Confirmat din `all_tables`:

| TABLE_NAME | TEMPORARY | DURATION |
|---|---|---|
| VANZARI | N | — |
| VANZARI_DETALII | N | — |
| VANZARI_DETALII_TEMP | **Y** | **SYS$TRANSACTION** |
| VANZARI_SETURI_TEMP | **Y** | **SYS$TRANSACTION** |

`DURATION = SYS$TRANSACTION` inseamna GTT cu `ON COMMIT DELETE ROWS` — randurile dispar la commit
(sau rollback), nu doar la sfarsit de sesiune. **Consecinta directa**: orice solutie care ar
reutiliza `VANZARI_DETALII_TEMP` pentru editare (#6) trebuie sa umple tabela SI sa consume
rezultatul in ACEEASI tranzactie — nu poate fi umpluta intr-un pas si citita in altul, ca in fluxul
de emitere unde umplere (bucla `adauga_articol_factura`) si consum (`scrie_factura2`) se intampla
deja in aceeasi conexiune/tranzactie, inainte de commit.

### 2.2 Coloane: `VANZARI_DETALII` vs `VANZARI_DETALII_TEMP`

`VANZARI_DETALII` (35 coloane, din `all_tab_columns`) — cheie primara `ID_VANZARE_DET` (NOT NULL,
generata din secventa prin trigger), FK logic `ID_VANZARE` (NOT NULL). Coloane relevante pentru
editare: `PRET` (NOT NULL), `CANTITATE`, `PRET_CU_TVA`, `DISCOUNT_UNITAR`, `PROC_TVAV`, `STERS`
(NOT NULL), `VALIDAT`/`DATAORA_VALID`/`ID_UTIL_VALID`, `ID_UTILS`/`DATAORAS` (audit),
`DIFERENTA` (NOT NULL), `CUSTODIE`/`DESCARCAT` (NOT NULL) — ultimele patru nu au valoare implicita
vizibila in trigger, deci probabil `DEFAULT` la nivel de coloana (nu s-a verificat separat, nu era
in scope).

`VANZARI_DETALII_TEMP` (28 coloane) — **fara PK real** (`ID_TEMP` e generat in VFP, folosit doar ca
identificator temporar de linie in cadrul sesiunii curente de compunere a facturii), **fara**
`ID_VANZARE`/`ID_VANZARE_DET`/`STERS`/`VALIDAT` (nu se aplica inainte de a exista documentul
parinte). Are in schimb coloane specifice etapei de compunere, care NU exista in tabela reala:
`ID_TEMP`, `NUMAR_ACT`, `ID_COMANDA`, `ID_GESTIUNE_DEST`, `ID_UTIL` (vs `ID_UTILS` in cea reala).

Coloanele comune folosite de editare (S4): `ID_ARTICOL`, `PRET`, `CANTITATE`, `PRET_CU_TVA`,
`DISCOUNT_UNITAR`, `PROC_TVAV`, `ID_GESTIUNE`, `CONT`, `ID_VALUTA`, `CURS` (doar in TEMP; in
`VANZARI_DETALII` nu exista `CURS` per linie — cursul e doar pe document, in `VANZARI_CURSURI`/
`VANZARI.CURS`), `ID_JTVA_COLOANA`, `SERIE`, `EXPLICATIE`/`EXPLICATIA` (nume diferit!), `TAXCODE`,
`LOT`.

## 3. Stergerea si adaugarea de linii

### 3.1 Stergere — mecanism EXISTENT azi doar la nivel de document intreg, NU per linie

Cautat explicit orice `UPDATE VANZARI_DETALII SET STERS` in `PACK_FACTURARE` — gasite doar doua
locuri, ambele sterg TOATE liniile unui document, niciodata o singura linie:

- `sterge_factura(V_ID_VANZARE, ...)`:
  `UPDATE VANZARI_DETALII SET STERS = V_STERS, ID_UTILS = V_ID_UTIL, DATAORAS = V_DATAORA WHERE
  ID_VANZARE = V_ID_VANZARE AND STERS = V_NESTERS` (V_STERS variaza 0/1 dupa tipul documentului,
  cazul normal fiind 1).
- `sterge_proforma(V_ID_VANZARE, ...)`: acelasi tipar, exclusiv pe proforme.

**Nu exista azi un mecanism Oracle sau VFP de stergere per-linie in `VANZARI_DETALII`** — orice
"stergere de linie la editare" ceruta de S4/S4b e functionalitate NOUA, de adaugat la #6, nu o
reutilizare a ceva existent.

Exista insa un precedent apropiat de UPDATE punctual per linie, util ca sablon:
`modifica_explicatie_articol(V_ID_VANZARE_DET, V_EXPLICATIE, V_ID_UTIL, V_TAXCODE)` —
`UPDATE VANZARI_DETALII SET EXPLICATIE = V_EXPLICATIE, TAXCODE = V_TAXCODE WHERE ID_VANZARE_DET =
V_ID_VANZARE_DET` — exact modelul de "UPDATE tintit prin `goExecutor`" mentionat ca varianta in
planul S5/S6, deja folosit azi din `frm_modifica_articol_factura` (mostenire de la #7, vezi
`plan_06_editare_factura.md`).

### 3.2 Adaugare de linie noua — nu cere nimic special in plus fata de un INSERT direct

`ID_VANZARE_DET` vine automat din `SEQ_VANZARI_DETALII` prin trigger la orice `INSERT INTO
VANZARI_DETALII`, indiferent de cine face insert-ul (nu doar fluxul de emitere) — vezi 1.3. Deci
adaugarea unei linii noi la editare **nu** cere obtinerea manuala a unui ID din secventa; e suficient
un `INSERT INTO VANZARI_DETALII (ID_VANZARE, ID_ARTICOL, PRET, CANTITATE, PRET_CU_TVA, ...) VALUES
(...)` (fara `ID_VANZARE_DET` in lista de coloane) intr-o procedura noua, apelata din
`finalizeaza_modificare_nota` alaturi de recalculul de totaluri propus in `rec_s5_oracle_vanzari.md`
punctul B.

## 4. Propunerea pentru S4/S5/S6 — cum trimite editarea liniile modificate in Oracle

### Optiuni comparate

**A. Refolosirea `VANZARI_DETALII_TEMP` + o "mini scrie_in_vanzari" pentru editare** — ar insemna ca
formularul de editare (S4) sa populeze TEMP la fel ca la emitere (apeluri per linie), apoi o
procedura noua sa faca INSERT-urile/UPDATE-urile in `VANZARI_DETALII` din TEMP, in aceeasi
tranzactie (impusa de `ON COMMIT DELETE ROWS`, vezi 2.1). Risc: reproduce complexitatea lui
`adauga_articol_factura` (ramificare pe `ntip`/sursa document) fara sa aiba sens la editare — acolo
nu exista comanda/aviz/contract "curent" din care sa se re-deriva pretul; ar trebui un mod nou,
simplificat, de populare a TEMP doar pentru editare, ceea ce complica inutil un cod deja incarcat.
Risc mediu-mare de regresie pe calea de emitere daca vreo modificare atinge accidental
`adauga_articol_factura`/`scrie_in_vanzari` partajate.

**B. UPDATE/INSERT/soft-DELETE punctual direct in `VANZARI_DETALII`, prin `goExecutor`, dintr-o
procedura noua dedicata editarii** — fara sa treaca deloc prin `VANZARI_DETALII_TEMP`. Model deja
existent si folosit: `modifica_explicatie_articol` (UPDATE tintit pe `ID_VANZARE_DET`). Pentru cele
trei operatii cerute de S4/S4b:
  - **Editare cantitate/pret/`pret_cu_tva`** pe o linie existenta: `UPDATE VANZARI_DETALII SET
    CANTITATE=..., PRET=..., PRET_CU_TVA=..., DISCOUNT_UNITAR=... WHERE ID_VANZARE_DET = :id`.
  - **Stergere linie**: `UPDATE VANZARI_DETALII SET STERS=1, ID_UTILS=:util, DATAORAS=SYSDATE WHERE
    ID_VANZARE_DET = :id` — acelasi tipar ca `sterge_factura`, dar tintit pe o singura linie (nou,
    nu exista azi, vezi 3.1).
  - **Adaugare linie noua**: `INSERT INTO VANZARI_DETALII (ID_VANZARE, ID_ARTICOL, PRET, CANTITATE,
    PRET_CU_TVA, DISCOUNT_UNITAR, PROC_TVAV, ID_GESTIUNE, CONT, ID_VALUTA, ID_JTVA_COLOANA, SERIE,
    EXPLICATIE, TAXCODE, LOT) VALUES (...)` — PK automat din trigger (vezi 3.2).
  Apoi, in ACEEASI tranzactie (deschisa deja de `do_deschide_tranzactie` in fluxul de editare a
  notei, cf. `rec_s5_oracle_vanzari.md` B "Idempotenta si tranzactionalitate"), se cheama procedura
  de recalcul a totalurilor propusa in `rec_s5_oracle_vanzari.md` (`recalculeaza_totaluri_vanzari`),
  care citeste direct din `VANZARI_DETALII WHERE ID_VANZARE=:id AND STERS=0` — **fara nicio
  dependenta de `VANZARI_DETALII_TEMP`**.

### Recomandare: **Varianta B**

Argumentul principal e riscul de regresie asupra emiterii: Varianta A ar obliga fie la extinderea
lui `adauga_articol_factura` cu o ramura noua "editare" (cod partajat cu emiterea, risc direct pe
calea critica), fie la duplicarea partiala a logicii lui in altă procedura (risc de divergenta,
exact problema pe care #8 a corectat-o deja pentru calculul de totaluri). Varianta B nu atinge deloc
`adauga_articol_factura`/`scrie_in_vanzari`/`VANZARI_DETALII_TEMP` — cod nou, izolat, apelat doar
din calea de editare (`finalizeaza_modificare_nota`), cu acelasi profil de risc "mic" motivat deja
pentru `recalculeaza_totaluri_vanzari` in `rec_s5_oracle_vanzari.md`. In plus, B se potriveste
natural cu S4b (verificare/sincronizare explicita, nu silentioasa): fiecare rand modificat/sters/
adaugat poate fi tratat ca o comanda separata, usor de enumerat utilizatorului inainte de aplicare
("linia X: cantitate 5 -> 8, pret 10 -> 12"), pe cand Varianta A ar produce un singur bloc opac de
recalcul din care nu se pot extrage usor liniile individuale schimbate.

**Observatie tehnica pentru implementare**: la editarea preturilor, NU se recalculeaza `V_PROC_TVAV`
din `JTVA_COLOANE`/comanda/contract ca la emitere (asta ar reintroduce dependenta de sursa
documentului, respinsa mai sus) — cota de TVA ramane cea deja persistata pe linie
(`VANZARI_DETALII.PROC_TVAV`), coerent cu felul in care `pret_cu_tva`/`proc_tvav` sunt deja tratate
ca date proprii ale liniei si nu recalculate la fiecare atingere (cf. #7).

## 5. Ce ramane neconfirmat / in afara scopului acestei cercetari

- Coloanele `STERS`, `VALIDAT`, `DIFERENTA`, `CUSTODIE`, `DESCARCAT` din `VANZARI_DETALII` sunt
  `NOT NULL` fara sa aiba valoare din trigger — probabil au `DEFAULT` la nivel de coloana
  (`all_tab_columns.data_default` nu a fost interogat, nu era necesar pentru concluziile de mai
  sus); de verificat explicit inainte de a scrie INSERT-ul de linie noua din Varianta B, ca sa nu
  fie nevoie sa le populeze manual.
- Valorile implicite exacte pentru `DEFAULT` (daca exista) pe coloanele NOT NULL de mai sus.
- Comportamentul `VANZARI_SETURI_TEMP`/liniile din seturi la editare (#6 nu pare sa acopere editarea
  seturilor, doar articolele individuale — de clarificat cu Marius daca seturile sunt in scope).