roafacturare/docs/cercetare/pack_auto_actualizeaza_deviz.md

# Cercetare: `pack_auto.actualizeaza_deviz` si riscul asupra devizului ROAAUTO la #13

Scop: `plan_13_unificare_formular_facturare.md` vrea sa permita adaugarea unei linii noi pe o
factura deja emisa, inclusiv pe facturile ROAAUTO (`tip = -12`). Intrebarea: ce se intampla cu
**devizul** din ROAAUTO cand factura primeste o linie pe care devizul nu o stie. Punctul de
plecare a fost `pack_auto.actualizeaza_deviz`, apelat din
`D:\ROA\ROAAUTO\Programe\oproceduri_devize.prg:1310`, al carei corp nu fusese citit inainte de
aceasta cercetare.

Continua `roaauto_facturi.md` si `roaauto_articole_lista_preturi.md` (deja citite, nu reiau
constatarile lor: acelasi `PACK_FACTURARE`, `VANZARI_DETALII_TEMP` -> `VANZARI_DETALII`,
`tip=-12`, liniile sintetice `-100000..-100008` plus liniile reale "Alte servicii", editorul
`frm_modific2024` read-only, `oviz_devize.vc2:4536` blocheaza modificarea dupa `nrfact`).

## 1. Unde e definit `PACK_AUTO`

`D:\ROA\DATABASE\SCRIPTURI_CLAR\<an>\<luna>\ff_..._AUTO_PACK_AUTO.sql` — 14 versiuni istorice
gasite (2013-2026). Sursa de adevar folosita (cea mai recenta, dupa conventia deja aplicata in
`roaauto_facturi.md` pentru `PACK_FACTURARE`):

**`D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\03\ff_2026_03_31_02_AUTO_PACK_AUTO.sql`** (1804 linii,
antet "17.03.2026 / robert / creare procedura setOptiuneInchidere").

Semnatura in spec: `:74-76`. Corp: `:692-733`.

## 2. Ce face `actualizeaza_deviz`, pas cu pas

Corpul complet (`ff_2026_03_31_02_AUTO_PACK_AUTO.sql:692-733`):

```sql
procedure actualizeaza_deviz(tnProcTvav  IN NUMBER,
                             tcSirIdOrdl IN VARCHAR2,
                             tnIdSet     IN NUMBER) is
  lcSeparator VARCHAR2(1) := ',';
  lnIdFact    DOCUMENTE.ID_DOC%TYPE;
begin
  -- nu iau pack_contafin.get_idfact pentru ca s-ar putea sa am id_fact de la incasare, nu de la factura
  SELECT MAX(ID_FACT)
    INTO lnIdFact
    FROM ACT
   WHERE COD = pack_contafin.get_cod()
     AND SCD NOT LIKE '5%';

  UPDATE DEV_ORDL
     SET PROC_TVAV = tnProcTvav
   WHERE ID_ORDL IN (SELECT X FROM table(charn2collection(tcSirIdOrdl, lcSeparator)));

  UPDATE /*+ INDEX(RUL IDX_RUL_001) */ RUL
     SET ID_FACT = lnIdFact
   WHERE ID_SET <> 229
     AND ID_LUCRARE IN (SELECT ID_LUCRARE FROM DEV_ORDL
                          WHERE ID_ORDL IN (SELECT X FROM table(charn2collection(tcSirIdOrdl, lcSeparator))));

  IF tnIdSet IN (31003, 31004, 31005, 31006, 31007, 31011) THEN
    UPDATE NOM_LUCRARI
       SET ID_FACT = lnIdFact
     WHERE ID_LUCRARE IN (SELECT ID_LUCRARE FROM DEV_ORDL
                            WHERE ID_ORDL IN (SELECT X FROM table(charn2collection(tcSirIdOrdl, lcSeparator))));
  END IF;
end actualizeaza_deviz;
```

Trei pasi, toti indexati pe `ID_ORDL`/`ID_LUCRARE` (comanda/lucrarea din ROAAUTO), **niciunul pe
`VANZARI`/`VANZARI_DETALII`**:

1. Citeste `lnIdFact` = cel mai mare `ID_FACT` din `ACT` pentru "codul" curent de sesiune
   (`pack_contafin.get_cod()`), excluzand notele de incasare (`SCD NOT LIKE '5%'`) — comentariul
   din cod explica de ce: la momentul apelului pot exista in `ACT` atat o nota de incasare cat si
   nota/factura propriu-zisa, si vrea explicit factura.
2. `UPDATE DEV_ORDL SET PROC_TVAV = tnProcTvav` — scrie cota de TVA pe comenzile din
   `tcSirIdOrdl` (lista CSV de `ID_ORDL`, despartita cu `charn2collection`).
3. `UPDATE RUL SET ID_FACT = lnIdFact WHERE ID_SET <> 229 AND ID_LUCRARE IN (...)` — leaga
   inapoi randurile din `RUL` (jurnalul de manopera/materiale al lucrarii, folosit si la
   `frm_inchidere_productie.do_executa` pentru totalul pe sectii, vezi §4) de documentul creat.
4. Doar daca `tnIdSet` e unul din `{31003,31004,31005,31006,31007,31011}`, acelasi `ID_FACT` se
   scrie si pe `NOM_LUCRARI` (nomenclatorul de lucrari).

**Nu exista niciun `SELECT`/`UPDATE` pe `VANZARI` sau `VANZARI_DETALII` in `actualizeaza_deviz`**
si, verificat suplimentar, **in tot pachetul `PACK_AUTO`** (grep pe `VANZARI` in cele 1804 linii
ale fisierului: 0 potriviri). Deci raspunsul direct la intrebarea din brief: procedura **nu
recalculeaza niciun total al devizului din liniile facturii** — nu citeste liniile facturii deloc.
Ce face e sa "stampileze" `ID_FACT` (documentul de vanzare/nota abia creat) pe randurile din `RUL`
si `NOM_LUCRARI` legate de comenzile din `tcSirIdOrdl`, plus sa actualizeze cota TVA pe
`DEV_ORDL`. E o legatura *deviz -> document*, nu un recalcul *document -> total deviz*.

## 3. Ce se intampla cu o linie de factura pe care devizul nu o are

Raspunsul e neted, pentru ca premisa intrebarii (un `SUM` peste `VANZARI_DETALII`) nu exista in
cod: **procedura nu vede deloc liniile facturii**, nici cele cunoscute (sintetice
`-100000..-100008`), nici cele reale (nomenclator, cazul "Alte servicii" din raportul anterior),
nici una noua adaugata din afara. Ea opereaza exclusiv pe `ID_ORDL`/`ID_LUCRARE` (identitatea
comenzii ROAAUTO), primite ca parametru `tcSirIdOrdl` — nu deriva niciodata acest identificator
din continutul `VANZARI_DETALII`.

Precedentul "Alte servicii" (articole reale, `id_articol` pozitiv, cf.
`roaauto_articole_lista_preturi.md` §2) confirma exact acest comportament pe date deja live: acele
linii coexista cu liniile sintetice in `VANZARI_DETALII` de multa vreme, fara ca
`actualizeaza_deviz` sa faca vreo distinctie — pentru ca nu se uita la `VANZARI_DETALII` deloc.

**Consecinta pentru #13**: adaugarea unei linii noi pe `VANZARI_DETALII` pentru o vanzare
`tip=-12` nu poate "dezechilibra" ce scrie `actualizeaza_deviz`, pentru simplul motiv ca aceasta
procedura nu depinde de continutul `VANZARI_DETALII`. Nu exista *eroare*, nu exista *ignorare
explicita* — e o absenta totala de citire.

Important insa (nuanta pe care intrebarea din brief o presupune implicit gresit): asta **nu**
inseamna ca "devizul" (asa cum e prezentat operatorului in ROAAUTO) ar reflecta automat noua
linie. Totalul devizului afisat in `oviz_devize.vc2` e calculat client-side din `RUL` (vezi
`crsTotaluri`, construit cu un `SELECT SUM(...) FROM RUL ... GROUP BY ID_SECTIE` in
`oviz_devize.vc2:7816-7823`, in `frm_inchidere_productie.do_executa`) si din cursoarele
`crsdeviz`/`crsalteserv` calculate in `oproceduri_devize.prg` la momentul facturarii — niciodata
din `VANZARI_DETALII`. Deci o linie adaugata ulterior pe factura **nu va aparea niciodata** in
totalul devizului asa cum il calculeaza ROAAUTO, indiferent daca `actualizeaza_deviz` mai ruleaza
sau nu — pur si simplu acel total nu are o sursa care sa citeasca `VANZARI_DETALII`.

## 4. Cand e apelata

Cautare in ROAAUTO (`Grep` pe `actualizeaza_deviz`, cele trei aparitii de cod, plus istoric
`.??2`) si in tot `D:\ROA\DATABASE\SCRIPTURI_CLAR` (niciun alt pachet Oracle nu o apeleaza — grep
pe `actualizeaza_deviz` in tot arborele SCRIPTURI_CLAR gaseste doar fisierele care *definesc*
`PACK_AUTO`/vechiul `PACK_DEVIZE`, nu vreun apel extern):

Trei puncte de apel, toate in VFP, niciunul intr-un trigger/job Oracle:

1. **La emiterea facturii** — `oproceduri_devize.prg:1310`, in acelasi bloc `lcSql` cu
   `pack_facturare.scrie_in_vanzari` (linia 1302), cu `tnIdSet` dinamic (`lnIdSet`, calculat mai
   sus in `factureaza_deviz`). Comentariu la linia 1311: *"am scos apelul catre
   `pack_devize.dev_completeaza_rul`; e inclus in `actualizeaza_deviz`"* — confirma ca functia a
   inlocuit o procedura mai veche cu acelasi scop (legare RUL -> document).
2. **`frm_inchidere_productie.do_executa`** (`oviz_devize.vc2:7896`, clasa la `:7143`) — cu
   `tnIdSet` **fix, 31007** — apelata dupa ce formularul de **inchidere productie** scrie o
   *nota contabila* (`oscrie_in_fisiere()` peste cursorul `actactan`, `:7889`), **nu** o factura;
   nu apeleaza `pack_facturare.scrie_in_vanzari`, deci nu atinge `VANZARI` deloc pe acest drum.
3. **`frm_inchidere_regie.do_executa`** (`oviz_devize.vc2:8907`, clasa la `:8093`) — identic,
   `tnIdSet` fix **31006**, pentru inchiderea de **regie** (overhead), tot printr-o nota
   contabila, nu o factura.

Deci `actualizeaza_deviz` nu e specifica facturarii — e o operatie generica *"leaga
comenzile/lucrarile astea de ultimul document contabil creat pentru codul curent"*, refolosita si
la doua fluxuri de inchidere interna care nu produc facturi de vanzare. In niciunul din cele trei
cazuri nu e re-declansata mai tarziu (nu exista un al patrulea apel, nici din UI, nici din
schedule/trigger Oracle) — deci editarea ulterioara a unei facturi deja emise (obiectivul #13) nu
ar re-invoca automat aceasta procedura, pentru ca nimic din codul citit o cheama in afara celor 3
puncte de mai sus.

## 5. Alte proceduri din `PACK_AUTO` care citesc `VANZARI`/`VANZARI_DETALII` pentru un deviz

**Niciuna.** Grep pe `VANZARI` in intregul fisier `ff_2026_03_31_02_AUTO_PACK_AUTO.sql` (1804 de
linii, tot pachetul, nu doar `actualizeaza_deviz`) — 0 potriviri. `PACK_AUTO` nu are nicio
dependenta de tabelele de vanzari/facturare; toata legatura cu partea financiara trece prin `ACT`
(note contabile) si `DEV_ORDL`/`RUL`/`NOM_LUCRARI` (structura proprie ROAAUTO).

Singurul loc care **citeste** liniile facturii pentru re-listarea unui deviz e in afara
`PACK_AUTO`, pe partea VFP: `relisteaza_factura_deviz`
(`D:\ROA\ROAAUTO\Programe\oproceduri_devize.prg:1516-1576`, mentionata in raportul anterior).
Verificat acum sursa: interogheaza direct view-urile COMUN `fact_vfacturi`
(`:1531`, filtrat `WHERE cod = ...`) si **`fact_vfacturi_detalii`** (`:1564`,
`select * from fact_vfacturi_detalii where id_vanzare = <poDate.nid_vanzare>` — fara alt filtru).
View-ul e definit in
`D:\ROA\DATABASE\SCRIPTURI_CLAR\2024\06\ff_2024_06_04_01_COMUN_FACTURARE.sql:8-94`:
`create or replace view fact_vfacturi_detalii as select ... from vanzari_detalii a left join
nom_articole b ... ` — un simplu wrapper peste `VANZARI_DETALII` cu join-uri de denumire, **fara
nicio clauza `WHERE`** care sa restranga la id-uri de articol cunoscute sau la liniile
"originale" ale devizului.

**Consecinta**: o linie noua inserata in `VANZARI_DETALII` pentru acel `id_vanzare` **va aparea
automat** la o re-listare/re-tiparire ulterioara prin `relisteaza_factura_deviz` — comportament
asteptat de la un view neconditionat, nu o stricare. Nu exista risc de eroare sau de excludere pe
acest drum; riscul (daca exista) e doar de **asteptare a utilizatorului**: factura retiparita va
arata linia noua, dar ecranul de deviz din ROAAUTO (total calculat din `RUL`, §3) nu o va arata
niciodata, pentru ca nu deriva din `VANZARI_DETALII`.

## 6. Concluzie operationala pentru #13

**Da, se poate adauga o linie pe o vanzare `tip=-12` fara sa "strice" `pack_auto.actualizeaza_deviz`
sau vreo alta procedura din `PACK_AUTO`** — pentru ca niciuna din ele nu citeste `VANZARI`/
`VANZARI_DETALII`; nu exista mecanism Oracle-side care sa recalculeze/verifice totalul devizului
din liniile facturii, deci nu exista nimic de dezechilibrat la acel nivel. Nu e nevoie de niciun
apel Oracle suplimentar din partea ROAFACTURARE ca sa "anunte" ROAAUTO despre linia noua —
`actualizeaza_deviz` n-ar face nimic util cu acea informatie oricum (opereaza pe `ID_ORDL`, nu pe
linii de factura).

Ce **nu** rezolva aceasta concluzie, si ramane responsabilitatea planului #13, nu a acestei
proceduri:

- **Desincronizare de afisare, nu de date**: totalul devizului aratat in ROAAUTO
  (`oviz_devize.vc2`, calculat din `RUL`/cursoarele de facturare) nu va reflecta niciodata o
  linie adaugata ulterior direct pe `VANZARI_DETALII` — nici azi (cu liniile "Alte servicii"),
  nici cu o linie noua din editorul unificat. Daca produsul vrea ca devizul sa "stie" de linia
  noua vizual, ar trebui cod nou in ROAAUTO (nu exista azi), nu un apel catre `actualizeaza_deviz`.
- **Reprintarea** (`relisteaza_factura_deviz`) va include automat linia noua (§5) — de verificat
  daca asta e comportamentul dorit de produs sau o suprindere pentru operatorul ROAAUTO.
- Confirmat si direct in cod ROAFACTURARE: `Grep` pe `pack_auto` in
  `D:\ROA\ROAFACTURARE` (inclusiv `COMUN`) nu gaseste nicio referinta in cod, doar in `docs\`
  (planul #13 si aceste rapoarte) — azi ROAFACTURARE nu apeleaza deloc `PACK_AUTO`, confirmand ca
  nu exista deja o presupunere ascunsa de sincronizare intre cele doua.

## Neverificat

- Ce reprezinta exact tabelele `ACT`/`RUL`/`NOM_LUCRARI`/`DEV_ORDL` la nivel de schema completa
  (DDL/comentarii) — inteles doar din felul in care sunt folosite in cod, nu dintr-un dictionar de
  date citit explicit.
- Daca vreun raport fiscal/SAF-T (mentionat generic in `ff_2022_03_24_01_COMUN_SAFT.sql`, nedeschis)
  agrega `VANZARI_DETALII` intr-un mod care ar fi afectat de o linie noua pe `tip=-12` — in afara
  ariei `PACK_AUTO` cerute, nu a fost investigat.
- Daca `frm_incasare_finala.do_recalculeaza_total`/`calculeaza_total` (`oviz_devize.vc2:6494,6700`)
  ar putea fi reconciliate manual de un operator ca sa "vada" o linie adaugata ulterior — nu am
  citit corpul acestor metode, doar semnalul ca exista.
- Istoricul complet al celorlalte 13 versiuni `AUTO_PACK_AUTO.sql` nu a fost comparat linie cu
  linie cu cea din 2026-03 — presupun (conform conventiei deja aplicate pentru `PACK_FACTURARE`)
  ca cea mai recenta e sursa de adevar pentru comportamentul curent din productie.