# Handoff: cercetare "cost materiale / rulaj + manoperă" (read-only)

Sarcina (subagent `lane-cost`): găsește și documentează cum se determină azi (a) costul de
achiziție al unei piese ieșite pe o comandă/factură și (b) valoarea + orele de manoperă,
pentru cererea clientului de a afișa aceste valori în listele de comenzi/facturi. Cercetare
READ-ONLY — **niciun fișier din proiect nu a fost modificat.**

## Stare: COMPLET

Toate constatările au fost transmise integral către `team-lead` prin două mesaje SendMessage
(cu citate exacte de cod și file:line). Acest fișier e doar predarea pe disc, conform REGULA
ZERO — pentru cazul în care mesajele s-ar pierde. Nu există lucru neterminat, fișiere editate,
tranzacții deschise sau date de test consumate.

**Important**: în timp ce scriam handoff-ul am găsit că exista deja pe disc
[`docs/propuneri_coloane_manopera_piese_viz.md`](propuneri_coloane_manopera_piese_viz.md) —
un document mult mai complet (scris cu acces direct la Oracle: `EXPLAIN PLAN`, `autotrace`,
măsurători reale pe schema `MARIUSM_AUTO`/`ROA_CENTRAL`), care **acoperă și depășește** tot ce
am găsit eu static din cod. Acela e documentul de referință pentru implementare, nu acesta.
Constatările mele (fără acces DB, doar citire de cod) coincid cu ale lui la toate punctele
verificabile static.

## Inventar constatări (file:line)

### 1. Tabelul RUL (rulaj) — coloane relevante
Schema cursorului `viz_rulaje`: `COMUN/programe/oproceduri_rulaje.prg:15-25`.
`PRET n(16,4)` = preț achiziție/cost per rând de mișcare, `PRETV n(16,4)` = preț vânzare,
`CANT`/`CANTE` = cantitate, `COD` = document sursă, `ID_LUCRARE`, `ID_GESTIUNE`, `STERS`.

### 2. Cost achiziție — DEJA STOCAT pe linia de vânzare/factură (nu recalculat la citire)
- Schema cursor linii deviz: `Programe/oproceduri_devize.prg:882` — `pret_achizitie N(20,4)`.
- Populat din lotul de stoc consumat: `COMUN/clase/ofacturare.vc2:4233,13131,13511` —
  `poArticol.pret_achizitie = Pret`.
- Scris efectiv prin `pack_facturare.adauga_articol_factura_deviz`
  (`Programe/oproceduri_devize.prg:1218-1244`).
- Persistă și la editare facturi: `COMUN/programe/ofacturare_editare.prg:225,547,652,775,807-817`;
  schema tabel `vanzari_det`: `COMUN/programe/oproceduri_facturare.prg:378-491,1114-1133`.
- Rapoarte care citesc costul direct de pe linie, fără recalcul:
  `COMUN/programe/oproceduri_rapoarte_fact.prg:579-590` (view `fact_vfacturi_detalii`).

### 3. Algoritm de determinare a costului la ieșire — FIFO pe LOT, din tabela STOC
Sursă (în afara repo-ului git ROAAUTO, în `D:\ROA\DATABASE\SCRIPTURI_CLAR\` — istoric SVN al
schemei Oracle COMUN, actualizat curent, ultimul fișier relevant la 2026-09-16):
`PACK_FACTURARE.cursor_gestiuni_articol`
(`D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\09\ff_2026_09_16_04_COMUN_PACK_FACTURARE.sql:4513-4597`).
Selectează loturi din **`STOC`** (nu din `RUL`), filtrate pe `LUNA`/`AN`/`ID_ARTICOL`/
`ID_GESTIUNE`, cantitate rămasă = `CANTS + CANT - CANTE > 0`, ordonate **`ORDER BY DATAIN`**
(FIFO pe data intrării lotului). `PRET` = costul lotului ales, scris o singură dată pe linia
de vânzare (punctul 2). Rapoartele nu re-rulează FIFO, doar re-însumează ce s-a scris deja.

### 4. Manoperă — ore și valoare
DDL `DEV_OPER`: `Scripturi_instalare/tabele.sql:674-693` — `TIMPN NUMBER(8,3)` (ore),
`PRET NUMBER(17,4)` (tarif orar), `ID_ORDL` (FK spre `DEV_ORDL`, fără index explicit pe
`DEV_OPER.ID_ORDL` în DDL). `DEV_ORDL` are index pe `ID_LUCRARE` (`IDX_ORDL_00001`,
`Scripturi_instalare/tabele.sql:636`).
Valoare manoperă = `TIMPN * PRET`, agregată în raport:
`Programe/oproceduri_listari.prg:1608-1621` (`facturi_emise_pe_sectii`).

### 5. Raportul cerut de client EXISTĂ DEJA — view Oracle `AUTO_ISTORIC_COMENZI`
Versiune curentă (ultima modificare găsită, 2025-06-30, nimic mai nou):
`D:\ROA\DATABASE\SCRIPTURI_CLAR\2025\06\ff_2025_06_30_01_AUTO.sql:37-95`.
```sql
(select sum(round(pret * cante, 2)) from rul where sters = 0 and id_lucrare = a.id_lucrare) as val_materiale_ach,
(select sum(round(pretv * cante, 2)) from rul where sters = 0 and id_lucrare = a.id_lucrare) as val_materiale_vz,
(select sum(b1.timpn) from dev_ordl a1 left join dev_oper b1 on a1.id_ordl=b1.id_ordl where a1.id_lucrare=a.id_lucrare and a1.sters=0 and b1.sters=0) as ore_manopera,
(select sum(round(b1.timpn*b1.pret,2)) from dev_ordl a1 left join dev_oper b1 on a1.id_ordl=b1.id_ordl where a1.id_lucrare=a.id_lucrare and a1.sters=0 and b1.sters=0) as val_manopera,
```
Subselecte **corelate pe `id_lucrare`** (nu scan fără filtru), susținute de indexul
`IDX_RUL_001 on RUL(ID_LUCRARE, STERS)` (creat `D:\ROA\DATABASE\SCRIPTURI\2009\1\ff_2009_01_21_01_GESTIUNI.sql:63`,
încă folosit activ cu hint în producție — ultima apariție
`D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\03\ff_2026_03_31_02_AUTO_PACK_AUTO.sql:711`).
Folosit deja în VFP: `Programe/oproceduri_vizualizare.prg:441-457` (`vizualizare_ist_comenzi`),
afișat în grid `Clase/oviz_devize.vc2:9585-9607` (`ControlSource`: `val_materiale_ach`,
`val_materiale_vz`, `val_materiale_factura`, `val_manopera_factura`, `ore_manopera`).

### 6. Raportul care CHIAR scanează tot RUL fără scopare pe lucrare (risc real, dar altă bucată de cod)
`Programe/oproceduri_listari.prg:1607-1625` (`facturi_emise_pe_sectii`):
```sql
left join (select sum(round(pret*cante,2)) as valoarea, sum(round(pretv*cante,2)) as valoarev,
  id_lucrare, id_sectie from rul where sters=0 group by id_lucrare, id_sectie) e
  on a.id_lucrare = e.id_lucrare and a.id_sectie = e.id_sectie
```
`GROUP BY` peste tot `RUL` (fără filtru pe `id_lucrare` în where), join-ul pe perioadă se face
abia după — spre deosebire de `AUTO_ISTORIC_COMENZI` (punctul 5), care e corelat per lucrare.
Acesta e adevăratul candidat de "selecție pe toată baza de date", dacă vreodată devine relevant
de optimizat.

## Ce s-a stabilit deja (să nu se reia)
- Costul de achiziție e stocat pe linia de vânzare/factură (`pret_achizitie`), nu recalculat FIFO
  la fiecare citire — FIFO rulează o singură dată, la facturare, pe tabela `STOC`.
- View-ul `AUTO_ISTORIC_COMENZI` deja livrează exact coloanele cerute de client și e deja folosit
  în ecranul „Istoric comenzi"; documentul de propuneri recomandă copierea acelorași subinterogări
  în `AUTO_NORMARE_COMENZI`/`AUTO_FACTURI_EMISE` pentru ecranele „Vizualizare comenzi"/"Facturi".
- Sursa de adevăr pentru DDL/PL-SQL Oracle (istoric complet de migrări, inclusiv versiuni curente
  ale pachetelor și view-urilor) NU e în `Scripturi_instalare\` din ROAAUTO, ci în
  `D:\ROA\DATABASE\SCRIPTURI\` (brut, cronologic) și `D:\ROA\DATABASE\SCRIPTURI_CLAR\` (reformatat) —
  repo SVN separat, partajat între toate aplicațiile ROA.

## Interzis / nu s-a făcut
Nicio modificare de cod, niciun script Oracle rulat, niciun write-back `.vc2`/`.sc2`. Cercetare
pur read-only, conform mandatului primit.

## Runda 2 — întrebări punctuale de la team-lead (trimise, nu doar aici)
Sursă: `PACK_FACTURARE.descarca_gestiune`, în
`D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\09\ff_2026_09_16_04_COMUN_PACK_FACTURARE.sql` (versiune
curentă, 2026-09-16).

1. **`RUL.PRET` la ieșire — SIGUR**: nu se recalculează în `descarca_gestiune`. Procedura primește
   `V_PRET_ACHIZITIE IN NUMBER` ca parametru, selectează din `STOC` exact lotul cu acel preț
   (`AND A.PRET = V_PRET_ACHIZITIE`, linia 8766 și analog 8659/8899/10642), apoi
   `V_PRET := tab_stoc(i).PRET` (linia 8975) și `V_PRET as PRET` în `INSERT INTO RUL_TEMP`
   (linia 9456). FIFO-ul (alegerea lotului) se face separat, mai devreme, în
   `cursor_gestiuni_articol` (`ORDER BY DATAIN`, raportat runda 1).
   **Incert**: n-am găsit niciun `INSERT INTO RUL` literal (fără `_TEMP`) în acest fișier — nu am
   urmărit cum `RUL_TEMP` ajunge fizic în `RUL`. Nu schimbă răspunsul (valoarea `PRET` e fixată la
   `V_PRET` oricum), dar rămâne un gol de investigat dacă cineva vrea firul complet.
2. **RUL pe `id_lucrare` = doar piese, niciodată manoperă — SIGUR**: gardă la intrarea în
   `descarca_gestiune` (liniile 8264-8270):
   ```sql
   SELECT MAX(IN_STOC) INTO lnInStoc FROM NOM_ARTICOLE WHERE ID_ARTICOL = V_ID_ARTICOL;
   if lnInStoc = 0 then GOTO SFARSIT; end if;
   ```
   Articolele cu `IN_STOC=0` (servicii/manoperă) nu ajung niciodată să scrie în `RUL_TEMP`/`RUL`.
   Replicat pe VFP prin `gestionabil = Iif(Nvl(in_stoc,0)<>0,1,0)`
   (`COMUN/programe/ofacturare_editare.prg:242`).
3. **`CANTE` vs `CANT` — SIGUR**: `CANTE`=ieșire, `CANT`=intrare, din formula soldului
   `CANTS+CANT-CANTE` (folosită consecvent, ex. `cursor_gestiuni_articol`). La retur (ramura
   `WHEN pack_facturare.ntip IN (8,9)` din `descarca_gestiune`, ~linia 8355) nu se folosesc
   cantități negative — ieșirea originală (`a.cante`) devine `cant` (intrare) pe rândul nou:
   `SELECT 1 as tip, ..., a.cante as cant, 0 as cante, ... FROM RUL A ... WHERE A.CANTE<>0`.
4. **`DEV_OPER.TIMPN` = ore — SIGUR pe bază de uz**, nicio conversie de unitate întâlnită:
   `Programe/oproceduri_listari.prg:1620` (`sum(...timpn) as ore`), `:2005` (`sum(timpn) as ore`),
   caption `Clase/odevize.vc2:6310` (`"Total ore"`). Niciun `COMMENT ON COLUMN` găsit în DDL —
   eticheta vine din convenția de cod, nu dintr-un comentariu de schemă.
5. **`VANZARI_DETALII.PRET_ACHIZITIE` — mecanism SIGUR, procentul de 95% zero INCERT**: scris de
   același flux (`descarca_gestiune`/finalizare factură), doar pentru linii gestionabile
   (`IN_STOC<>0`), cu `V_PRET` din `STOC` (condiție de MERGE, linia 12741:
   `AND A.PRET_ACHIZITIE = V_PRET ...`). Pentru linii de manoperă (`IN_STOC=0`) rămâne 0 **prin
   design** (codul nici nu rulează pentru ele — punctul 2). Nu am verificat empiric (fără acces
   Oracle) dacă cele ~95% zero din schema de test chiar corespund liniilor de manoperă sau ascund
   și piese needescărcate din alt motiv — am recomandat team-lead-ului un count pe
   `IN_STOC × (PRET_ACHIZITIE=0)` pentru confirmare.

**Concluzie rundă 2**: `pret_achizitie` de pe `VANZARI_DETALII` e de încredere ca sursă a costului
pe factură pentru liniile de piese; un 0 pe linie de manoperă e corect, nu semnal de problemă.

**CORECTARE ulterioară (din `docs/propuneri_coloane_manopera_piese_viz.md`, actualizat de altcineva
cu acces Oracle, după ce am trimis răspunsul de mai sus)**: pe schema de test, `PRET_ACHIZITIE = 0`
nu doar pe liniile de manoperă (`IN_STOC=0`: 2475/2526 = 98%), ci **și pe 96% din liniile de piese
gestionabile** (`IN_STOC=1`: 8561/8889 = 96%). Deci concluzia mea "e de încredere pentru piese" nu
se confirmă empiric — mecanismul de scriere există (descris mai sus), dar pe date reale coloana e
goală aproape peste tot, inclusiv acolo unde ar trebui completată. Motivul exact nu e stabilit
(posibil: câmpul se completează doar pe un anumit flux de facturare, sau pe majoritatea documentelor
din baza de test descărcarea de gestiune nu s-a mai executat din alt motiv). **Nu folosiți
`VANZARI_DETALII.PRET_ACHIZITIE` ca sursă de cost fără verificare suplimentară — `RUL.PRET` (via
`AUTO_ISTORIC_COMENZI`) rămâne sursa confirmată empiric.**