# S8 — Inventar pe tipuri de sursa. Rezultat

Cerinta din plan (`docs\plan_06_editare_factura.md:282-291`): test pe fluxul real, cate un caz din
fiecare tip de sursa (lista de preturi, comanda, contract, aviz), fiecare rulat **de doua ori** (o
data din ROAFACTURARE, o data din registrul jurnal ROACONT), plus un al treilea caz obligatoriu — un
document care nu e factura, deschis din jurnal (**deja acoperit**, testul de garda
`ofacturare_editare.prg` scos din `SET PROCEDURE` -> `PageCount = 2`).

Faza de fata e **inventar, READ-ONLY**: doar `SELECT` si un apel de functie PL/SQL
(`pack_documente.ReferinteDocumenteNota`, functie de citire, fara `INSERT`/`UPDATE`/`COMMIT`).
Zero scriere, zero editare de documente, zero modificare de cod.

## Verdict

**Matricea completa NU e realizabila azi.** Doar tipul **lista de preturi** are documente eligibile
in luna curenta (august 2026) — 3 documente, din care **2 sunt deja indisponibile** (consumate/baza
de regresie in lucrari anterioare). Ramane **un singur candidat neatins**: `id_vanzare=1048`.

Celelalte trei tipuri — **comanda, contract, aviz** — au **zero documente in luna curenta**. Nu e o
limitare de cod sau de garda: nu exista niciun document de acel tip datat in august 2026, in toata
`MARIUSM_AUTO`. Cea mai recenta factura pe comanda e din 26.03.2026, pe contract din 30.06.2026, iar
pe aviz (`tip=4`, "FACT. DIN AVIZ") din **30.11.2023**. Nu se fabrica date.

## 1. Cum se determina „tipul de sursa" — dovada pe cod

`VANZARI.TIP` — mapat explicit in `COMUN\clase\ofacturare.vc2`, atat in configurarea UI a
formularului de facturare (`frm_facturare_articole.Init`, `Do Case` pe `poDate.tip`, `:15122-15153`)
cat si in constantele denumite din `do_copiaza` (`:3628-3681`):

| Tip sursa (cerut de S8) | `VANZARI.TIP` | Eticheta din cod | Sursa |
|---|---|---|---|
| lista de preturi | `1, 5, 7, 10` | POLITICA PRETURI (lei / invoice / credit note / factura valuta) | `ofacturare.vc2:15122-15123`, `:3629-3632` |
| contract | `2, 6` | CONTRACT / CONTRACT - VALUTA | `ofacturare.vc2:15129-15130`, `:3638`, `:3658` |
| comanda | `3` | COMANDA | `ofacturare.vc2:15144-15145`, `:3639` |
| aviz | `4` | FACT. DIN AVIZ (factura emisa pe baza unui aviz anterior) | `ofacturare.vc2:15151-15152`, `:3640` |

Se mapeaza curat pe un singur camp (`VANZARI.TIP`), fara ambiguitate. Precizari:

- Tipurile `21/22/23/24/25/26/28/29/41` etc. sunt **avize propriu-zise sau transferuri** (documente
  separate, nu facturi cu sursa aviz) — nu intra in matrice, pentru ca S8 cere editarea unei
  **facturi**, nu a unui aviz.
- `tip=-12` (facturi din ROAAUTO, devize auto) e alt caz, deja documentat separat in
  `docs\cercetare\roaauto_facturi.md` — nu face parte din cele patru tipuri cerute de plan.
- Contractul (`2,6`) are azi acces liber la lista de preturi in dialogul de adaugare articole
  (`docs\cercetare\retur_si_lista_preturi.md`, sectiunea B), dar asta nu schimba clasificarea sursei
  — clasificarea e pe `VANZARI.TIP`, nu pe ce se poate adauga ulterior.

## 2. Cate documente exista, per filtru — cifre pe `MARIUSM_AUTO`

Garda de editare cumulata (varianta strictă, `frm_facturi.do_editare_factura`,
`ofacturare_comun.vc2:3715-3872`): `sters=0`, `eproforma<>1`, luna curenta (`data_act` in august
2026), fara linii din seturi (`id_vanzare_set` nenul pe nicio linie activa), fara referinte
(`pack_documente.ReferinteDocumenteNota`), netrimisa in eFactura (`anaf_efactura.id_fact`).

| Pas / filtru | lista de preturi | contract | comanda | aviz |
|---|---|---|---|---|
| 1. `sters=0`, tip in grup, luna curenta (08.2026) | **3** | 0 | 0 | 0 |
| 2. + `eproforma<>1` | 3 (neschimbat) | 0 | 0 | 0 |
| 3. + fara linii din seturi | 3 (neschimbat) | 0 | 0 | 0 |
| 4. + fara referinte incasari/plati | 3 (neschimbat) | 0 | 0 | 0 |
| 5. + netrimis in eFactura (**eligibil final**) | **3** | 0 | 0 | 0 |

Niciun filtru nu a eliminat vreun document din grupul „lista de preturi" — cele 3 existente treceau
deja toate gardele. Pentru celelalte trei tipuri, blocajul e la pasul 1: **nu exista document in
luna curenta**, deci pasii 2-5 sunt irelevanti (cifra ramane 0, nu se pierde nimic pe drum).

**Istoric, ca sa se vada ca nu e o problema de cautare**: `comanda` are 38 de facturi nesterse in
total (cea mai recenta 26.03.2026), `contract` 23 (cea mai recenta 30.06.2026), `aviz` doar 5 in tot
istoricul (cea mai recenta **30.11.2023**) — tipul `aviz` (facturare directa dintr-un aviz emis, fara
trecere prin lista de preturi/comanda/contract) e practic neutilizat de câţiva ani, nu doar in luna
curenta.

**Al doilea punct de intrare (ROACONT/`afisjurcom.do_modifica`, `comun.vc2:2222-2572`)**: garda e
mai laxa — verifica doar luna curenta si `id_set` in afara intervalului `[30000,30009]` (rezervat
ROAPRODUCTIE); nu verifica `eproforma`, referinte sau eFactura (vezi `handoff_punct6_dupa_s5.md`,
confirmat din nou pe cod la aceasta cercetare). Verificat pe cei 3 candidati lista de preturi:
`id_set=25010` pentru toti trei (an=2026, luna=8) — in afara intervalului interzis, deci **toti trei
trec si garda ROACONT**. Cum niciun filtru specific ROAFACTURARE (eproforma/referinte/eFactura) n-a
eliminat vreun document din cele 3, garda mai laxa a jurnalului **nu aduce candidati suplimentari**
pentru lista de preturi — si, evident, nu poate aduce candidati pentru comanda/contract/aviz, unde
blocajul e lipsa documentului insusi (ambele puncte de intrare cer luna curenta).

## 3. Lista concreta de candidati propusi

| Tip sursa | `id_vanzare` | `cod` | `id_fact` | Stare | De ce |
|---|---|---|---|---|---|
| lista de preturi | **1048** | 1140894 | 8009658 | **neatins, eligibil** | 1 linie activa, fara valuta (`in_valuta=0`), `discount=0`, client RAJA (`id_part=463`) — document simplu, curat, tip=1 |
| lista de preturi | 1049 | 1140906 (curent) | 8009659 | eligibil pe cod, dar **deja consumat** | documentul de test S5/S7 — `cod` realocat de 8 ori, folosit intentionat ca baza de continuitate; nu se reia pentru S8 fara sa se stie ca istoricul lui e deja incarcat |
| lista de preturi | 1050 | 1140895 | 8009660 | eligibil pe cod, dar **interzis explicit** | „baza suitelor de regresie — nu se atinge" (`handoff_punct6_dupa_s5.md`) |
| contract | — | — | — | **zero** | niciun document `tip in (2,6)` in august 2026 (cel mai recent 30.06.2026) |
| comanda | — | — | — | **zero** | niciun document `tip=3` in august 2026 (cel mai recent 26.03.2026) |
| aviz | — | — | — | **zero** | niciun document `tip=4` in august 2026 (cel mai recent **30.11.2023**) |

**Singurul candidat utilizabil pentru matrice, azi: `id_vanzare=1048` (lista de preturi).** Pentru
comanda/contract/aviz nu exista alternativa in luna curenta — orice executie ar cere fie asteptarea
pana quando apare un document nou de acel tip in perioada curenta, fie o decizie explicita de a
relaxa criteriul „luna curenta" (schimbare de scop, nu de agent).

## 4. Ce ar consuma executia matricei (daca se aproba)

- **Un singur `cod` disponibil de consumat**: `id_vanzare=1048`, `cod=1140894`. Fiecare trecere prin
  fluxul de editare realoca `cod` ireversibil (pattern confirmat empiric in S5/S7: 8 realocari pe
  `id_vanzare=1049`). Testarea „de doua ori" (ROAFACTURARE + ROACONT) ar realoca `cod`-ul cel putin
  **de doua ori** pe acest document.
- **Comanda/contract/aviz**: executie **imposibila** azi, indiferent de aprobare — nu exista document
  de consumat. Singura cale de a acoperi aceste trei tipuri e sa apara documente noi in productie in
  luna curenta, sau o decizie separata de relaxare a scopului (nu s-a luat).
- Al treilea caz obligatoriu (document care nu e factura, din jurnal) — deja acoperit, zero consum
  suplimentar.
- Nimic din inventarul de fata nu a consumat date: read-only, zero `INSERT`/`UPDATE`/`COMMIT`.

## Ce NU acopera cercetarea

- `glLunaInchisa` (garda VFP „luna contabila inchisa") nu e verificabila din Oracle — presupusa
  deschisa (mediul de test curent), neverificata direct.
- Nu s-a cautat in alte luni/ani pentru un eventual document comanda/contract/aviz care sa fi ramas
  needitat din alt motiv — cerinta explicita a fost „luna curenta", conform gardei reale de editare.
- Coloana `VANZARI.ID_VANZARE_SET` nu exista direct pe `VANZARI` — verificarea „fara linii din
  seturi" s-a facut pe `VANZARI_DETALII.ID_VANZARE_SET` (linii active), consistent cu decizia 39
  (`handoff_s5.md`).

## Date de test — NIMIC consumat

Interogari `SELECT` + un apel de functie PL/SQL de citire (`pack_documente.ReferinteDocumenteNota`).
Zero `INSERT`/`UPDATE`/`DELETE`/`COMMIT`. `id_vanzare=1049` si `1050` — neatinse, doar citite.
`id_vanzare=1048` — doar citit, nu editat; ramane candidatul propus pentru executia viitoare.

## Fisiere atinse

Niciunul de productie. Scripturi `.sql` de interogare, in scratchpad (nu in `docs\`, nu in
`SCRIPTURI_CLAR`) — pur exploratorii, nu fac parte din livrare.