roafacturare/docs/cercetare/roaauto_facturi.md

Cercetare: facturile emise din ROAAUTO si relatia lor cu VANZARI_DETALII

Scop: pentru plan_13_unificare_formular_facturare.md — poate formularul unificat sa acopere si facturile emise din ROAAUTO (piese + manopera pe deviz), stiind ca ele "se pot modifica ulterior"?

Metoda si ce am putut verifica

ROAAUTO (D:\ROA\ROAAUTO) e un working copy migrat (are deja .vc2/.sc2 in-tree, ca ROAFACTURARE), deci am cautat direct in text, fara sa rulez git_sync.ps1 (interzis explicit). Nu pot garanta ca acel text e sincron 100% cu binarul curent (nu l-am regenerat) — daca vreo linie citata pare sa nu corespunda comportamentului live, motivul cel mai probabil e text neactualizat, nu o citire gresita.

D:\ROA\_vfp_textcache\roaauto\_symbols.tsv exista dar indexeaza doar .prg (1924 intrari, toate .prg; niciun .vc2/.sc2) — probabil generat inainte de migrarea in-tree. Nu m-am bazat pe el; am cautat direct cu Grep in .vc2/.prg din arbore.

Pentru partea Oracle am gasit sursa curenta a pachetului PACK_FACTURARE (COMUN, shared) in D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\08\ff_2026_08_06_10_COMUN_PACK_FACTURARE.sql (17020 linii, cel mai recent script din istoricul de migrari) — folosita ca sursa de adevar pentru semnaturile procedurilor.

1. Formularul/programul care emite facturi in ROAAUTO

Nu e un formular separat de facturare, ci un modul apelat din formularul de devize/comenzi (frm_... in oviz_devize.vc2, clasa cu cmd_factavans/cmd_factfinal). Logica de facturare propriu-zisa e in Programe/oproceduri_devize.prg:

• Procedure factureaza_deviz — D:\ROA\ROAAUTO\Programe\oproceduri_devize.prg:846 (semnatura la linia 847: Lparameters tnIdComanda,tcNrOrd,tcNrInmat,tcDenop,tnMultiple,...).
• Apelata din formular in D:\ROA\ROAAUTO\Clase\oviz_devize.vc2 (liniile 1834, 2201, 3146, 4056, 4456) prin butoanele de facturare avans/final.
• Exista si Procedure relisteaza_factura_deviz — D:\ROA\ROAAUTO\Programe\oproceduri_devize.prg:1516 — pentru re-listarea (re-tiparirea) unei facturi deja emise, nu pentru editarea ei.

2. Cum scrie in Oracle: aceleasi proceduri, cale comuna cu ROAFACTURARE

Da — acelasi pachet Oracle PACK_FACTURARE (COMUN, shared cu ROAFACTURARE), apelat prin goExecutor.oExecute, cu doi apeluri specifice pe langa cele generice:

• pack_facturare.initializeaza_date_factura(...) — D:\ROA\ROAAUTO\Programe\oproceduri_devize.prg:1211
• pack_facturare.adauga_articol_factura_deviz(...) (varianta _deviz a adauga_articol_factura, cu parametri expliciti de pret/gestiune/valuta in loc sa caute articolul din nomenclator) — D:\ROA\ROAAUTO\Programe\oproceduri_devize.prg:1240, in bucla Scan/Endscan peste cursorul crsvanztemp.
• oscrie_in_fisiere(0,.F.,.T.) — D:\ROA\ROAAUTO\Programe\oproceduri_devize.prg:1269.
• pack_facturare.scrie_incasari(...) — linia 1294 (doar daca exista incasare la emitere).
• pack_facturare.scrie_in_vanzari(0, id_delegat, id_masina, id_facturare, ..., @poDate.nid_vanzare) — linia 1302, urmata in acelasi lcSql de pack_auto.actualizeaza_deviz(...) (linia 1310) — un apel specific ROAAUTO, care actualizeaza starea devizului/comenzii dupa facturare (marcheaza RUL, seteaza nrfact etc., nu am citit corpul lui pack_auto — pachet separat, nu l-am cautat).
• Corpul adauga_articol_factura_deviz (spec+body in ff_2026_08_06_10_COMUN_PACK_FACTURARE.sql:468 si :4675-4745) face un simplu INSERT INTO VANZARI_DETALII_TEMP (...) — exact tabela de staging pe care o foloseste si facturarea normala din ROAFACTURARE (adauga_articol_factura, linia 549 din spec, insereaza in acelasi VANZARI_DETALII_TEMP).
• Premisa lui Marius e confirmata, cu o nuanta: ROAAUTO nu scrie direct in VANZARI_DETALII; ca si fluxul normal, trece prin VANZARI_DETALII_TEMP, iar transferul definitiv catre VANZARI/VANZARI_DETALII se face in pack_facturare.scrie_in_vanzari (ff_2026_08_06_10_COMUN_PACK_FACTURARE.sql:915-923 spec, body la :13497-13962) — acelasi punct final pe care il foloseste orice alta facturare ROA (avize, comenzi, contracte). Nu exista cale Oracle proprie ROAAUTO pentru scrierea liniilor de factura.

3. Tipul de document: tip = -12

factureaza_deviz construieste obiectul de date cu poDate = Createobject("oDateFactura",lnIdSet,-12) — D:\ROA\ROAAUTO\Programe\oproceduri_devize.prg:922 — al doilea parametru e tip. Clasa oDateFactura nu am gasit-o definita ca text (nu apare DEFINE CLASS oDateFactura in nicio sursa text din ROAAUTO sau din COMUN al oricarui proiect cautat) — probabil traieste intr-un .vcx inca neconvertit sau e generata dinamic; neverificat unde anume e clasa, dar e clar shared (folosita si in D:\ROA\ROAFACTURARE\COMUN\clase\ofacturare_comun.vc2, ex. liniile 3894/4075/7090, cu acelasi tipar Createobject("oDateFactura", tip1, tip2)).

tip = -12 e deja cunoscut in ROAFACTURARE — nu ca un cod nou, ci ca ceva deja intalnit si documentat in cercetarea recenta de regresie a editarii facturii (proiectul S4, docs\progres.md:339, :1142; docs\cercetare\rec_datoria6_baza_regresie.md:93; docs\cercetare\rec_s4_runda1.md:38; docs\cercetare\rec_view_articole_vanzare.md:108), pe un rand real din baza de test MARIUSM_AUTO: cod=1140885 -> id_vanzare=1047, tip=-12. Acolo e descris explicit: "nu e factura, e alt tip de document" (handoff_s4_runda1.md:77) si decizia produsului (decizia 19) e ca detectia liniilor de articole "merge pe orice tip, nu doar facturi" — adica IncarcaArticoleFactura/IncarcaVanzareNota din COMUN\programe\ofacturare_editare.prg (mentionate in rec_datoria6_baza_regresie.md:83-84) nu filtreaza dupa tip=1, deci vad si randurile tip=-12 deja, fara cod suplimentar.

4. Ce e specific fata de o factura obisnuita

• Camp de legatura cu masina: V_ID_MASINA e transmis catre pack_facturare.scrie_in_vanzari (oproceduri_devize.prg:1304). Nu e un camp exclusiv ROAAUTO — ID_MASINA e coloana standard pe VANZARI, cunoscuta si de fluxurile generice din pachet: modifica_date_factura are parametrul V_ID_MASINA IN NUMBER (ff_2026_08_06_10_COMUN_PACK_FACTURARE.sql:946), la fel scrie_factura2, scrie_factura_avize, scrie_factura_avize_retur (liniile 618-747 din acelasi fisier). Deci nu e o bariera de schema — ROAFACTURARE stie deja de ID_MASINA.
• Liniile facturii nu sunt articole individuale din nomenclator, ci sume cumulate cu pseudo-articole (id negative): factureaza_deviz agrega toate sumele din contul analitic al devizului (actactan) pe categorii si insereaza cate o linie sintetica per categorie — -100000 MANOPERA (oproceduri_devize.prg:965-967), -100001 DISCOUNT MANOPERA (:972), -100003 MATERIALE (:947-949), -100005 AVANS (:936-937), -100006 STORNARE AVANS (:1026-1027), -100007/-100008 INSPECTIE TEHNICA / SPALARE AUTO (:979-982). Optional, daca gnAUTOIdArticolReparatii e setat, toate liniile de mai sus se cumuleaza intr-o singura linie cu un articol real din nomenclator ("REPARATII AUTO", :989-1004). Confirmat pe date reale in docs\cercetare\rec_view_articole_vanzare.md:108-109: id_vanzare=1047 (tip=-12) are doar 2 randuri in VANZARI_DETALII, cu id_gestiune/nume_gestiune NULL (linii nestocate, netinute in gestiune). Deci pe factura nu apar piesele individual — apar totaluri MATERIALE/MANOPERA (cu exceptia cazului cumulat, unde apare un singur articol generic).
• pack_auto.actualizeaza_deviz(...) e chemat imediat dupa scrie_in_vanzari, in acelasi bloc SQL (oproceduri_devize.prg:1310) — leaga vanzarea nou creata inapoi de deviz/comanda (tabelele DEV_*/comenzi din ROAAUTO). Corpul lui pack_auto nu a fost citit (pachet separat, in afara ariei PACK_FACTURARE cautate) — neverificat ce tabele ROAAUTO scrie exact.
• DEV_TIP_DEVIZ (garantie/postgarantie/regie, oproceduri_devize.prg:1797) e o clasificare diferita, a devizului insusi, nu are legatura cu VANZARI.tip=-12.

5. Cum se modifica azi o astfel de factura

• Din ROAAUTO: nu exista editare a liniilor dupa facturare. Formularul de devize/comanda (oviz_devize.vc2) dezactiveaza explicit butonul de modificare dupa ce comanda are numar de factura: Thisform.cmd_modifica1.Enabled=Iif(Empty(nrfact),.T.,.F.) — D:\ROA\ROAAUTO\Clase\oviz_devize.vc2:4536. Singura actiune disponibila post-facturare gasita in cod e re-listarea (relisteaza_factura_deviz, oproceduri_devize.prg:1516), care doar reciteste antetul/liniile din fact_vfacturi/fact_vfacturi_detalii pentru reprintare, fara sa scrie nimic. N-am gasit niciun apel din ROAAUTO catre pack_facturare.modifica_date_factura (grep fara rezultate in tot arborele ROAAUTO) — nici macar antetul (delegat/masina/text aditional) nu pare editabil din ROAAUTO dupa emitere. Neverificat: n-am acoperit tot oviz_devize.vc2 (fisier de

  8800 linii) linie cu linie, doar zonele gasite prin grep pe termenii relevanti — nu exclud un alt punct de editare cu alt nume de metoda.

• Din ROAFACTURARE: exista deja, in lucru (proiectul S4), un editor de factura care citeste liniile oricarui tip (inclusiv -12) din VANZARI_DETALII — funcțiile IncarcaVanzareNota/IncarcaArticoleFactura in COMUN\programe\ofacturare_editare.prg (adaugate conform docs\cercetare\handoff_s4_runda1.md:79-81, verificate pe cod=1140885 -> id_vanzare=1047, tip=-12, docs\cercetare\rec_datoria6_baza_regresie.md:93) si formularul frm_modific2024 (COMUN\clase\omodificari.vc2), cu un grid nou grdArticoleFactura pe pagina 3 "Articole factura". Insa acest grid e in prezent READ-ONLY: "grid nou grdArticoleFactura (...), ReadOnly la nivel de grid si pe fiecare Text1" (docs\cercetare\handoff_s4_runda1.md:80-82) — deci azi se poate vizualiza, nu edita, de aici (nici adaugare, nici stergere de linii).

6. Se poate adauga azi o linie libera / din lista de preturi pe o astfel de factura?

Pe cod, nu, din nicaieri, azi:

• Din ROAAUTO: butonul de modificare a devizului e dezactivat dupa facturare (oviz_devize.vc2:4536), iar singura cale de scriere gasita (factureaza_deviz) ruleaza o singura data la emitere; nu exista un adauga_articol_... apelabil ulterior pe o vanzare deja scrisa. Structura insasi a liniilor (sume cumulate pe pseudo-articole negative, sectiunea 4) e diferita de o linie normala de factura cu articol real din lista de preturi — un eventual "adauga articol" ar trebui sa lucreze langa niste linii care nu reprezinta articole reale.
• Din ROAFACTURARE: editorul nou (frm_modific2024) vede liniile (orice tip, deci si cele venite din ROAAUTO), dar gridul e read-only — nu exista azi cod de adaugare/scriere pe acest grid. Nu am gasit alt formular ROAFACTURARE (frm_facturi clasic) care sa editeze articolele unei vanzari cu tip=-12 — cautarea ROAAUTO in D:\ROA\ROAFACTURARE (in afara de COMUN) nu da potriviri de cod, doar mentiuni in docs\ (progres.md, cercetare); Grep pe ROAAUTO in D:\ROA\COMUNROA a expirat (arbore prea mare) si nu a fost reincercat — neverificat daca COMUNROA (copia partajata separata de COMUN din ROAAUTO/ROAFACTURARE) are vreo referinta directa la ROAAUTO.

Concluzie pentru planul de unificare

Premisa lui Marius se confirma pe cod: facturile ROAAUTO ajung, prin acelasi PACK_FACTURARE shared si acelasi VANZARI_DETALII_TEMP -> VANZARI_DETALII, in aceeasi tabela pe care o citeste ROAFACTURARE — deci un formular unificat le poate vedea fara cod special de recunoastere a sursei (dovada: editorul S4 le vede deja, testat pe date reale). Ce lipseste nu e recunoasterea, ci capacitatea de scriere: azi nimic, in niciun produs, nu poate adauga o linie pe o vanzare tip=-12 — gridul nou din ROAFACTURARE e deliberat read-only, iar ROAAUTO isi blocheaza propriul formular dupa facturare. Particularitatea reala de gestionat e ca liniile existente nu sunt articole individuale, ci sume cumulate MATERIALE/MANOPERA pe pseudo-articole cu id_articol negativ — orice UI care adauga articole din lista de preturi "langa" ele trebuie sa decida cum coexista cu randuri care nu au id_gestiune/nu corespund unui articol real.