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`; `COMUN\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 intermediar (sters)) 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
  `COMUN\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.