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):

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.