roafacturare/docs/cercetare/verif_proforma_alegere_stoc.md

# Verificare — alegerea stocului pe proforma (runda de verificare)

Investigatie read-only, 10.08.2026. Raspunde la 4 intrebari punctuale cerute de team-lead, pentru
decizia de proiectare S5b (comutare FACTURA <-> PROFORMA cu linii deja adaugate).

Continua fara sa reia: `s5b_proforma_descarcare_gestiune.md` (mecanismul `gestionabil=0` /
`id_gestiune=-1000`) si `s5b_proiectare_proforma_copiere.md` (proiectarea de runda 12, care a
descoperit deja ca `scrie_proforma` nu cheama `contabilizeaza_articol` deloc).

Nicio modificare de cod, niciun `git_sync.ps1`/`txt2vcx.ps1`, niciun commit, nicio scriere Oracle
(numai `SELECT`/`Read`/`Grep` pe fisiere de pe disc). Sursa Oracle folosita:
`D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\08\ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql` (citat mai jos
`PACK:linie`).

**Status: COMPLET.**

---

## Rezumat executiv

1. **Da, pe calea principala si pe toate celelalte surse (cu exceptia copierii), stocul NU se
   alege la adaugarea unei linii pe proforma azi** — pentru ca `gestionabil` a fost deja fortat pe
   `0` in VFP, in masa, **inainte** ca gridul de linii sa se deschida. Cand ruleaza `Do Case`-ul de
   la `ofacturare.vc2:13803`, `poArticol.gestionabil` e deja `0`, nu valoarea reala din nomenclator.
2. **Marcarea negestionabila are un singur mecanism activ azi, exclusiv in VFP**:
   `UPDATE (m.lcCursor) SET gestionabil = 0` (`ofacturare.prg:333-336`), rulat in interiorul
   functiei `factureaza()`, imediat dupa incarcarea cursorului candidat (`crsarticole`) si
   **inainte** de construirea `crsfactura` (`creeaza_facturacrs`, linia 338) — adica la
   **deschiderea documentului / incarcarea liniilor candidate**, nu la Termina/salvare. **Exista si
   un al doilea mecanism, in Oracle**, in `cursor_retur_document` (`PACK:3993-4000`,
   `CASE WHEN V_PROFORMA=1 THEN 0 ...`), dar acesta e **mort in fluxul curent**: `cursor_retur_document`
   se cheama dintr-un singur loc (`ofacturare.prg:268`, ramura de copiere), cu
   `V_PROFORMA = poDate.eProforma` **al documentului nou**, care e **intotdeauna 0** dupa copiere
   (`nIdTipDoc` nu se propaga de la sursa, `ofacturare_comun.prg:370`) — deci ramura `V_PROFORMA=1`
   nu se activeaza niciodata azi. **Nu e o contradictie intre cele doua rapoarte anterioare — sunt
   doua mecanisme reale in cod, dar doar unul (cel VFP) e activ pe traseul de creare a unei
   proforme; cel Oracle exista doar pentru copiere si acolo nu se declanseaza cu valoarea curenta a
   parametrului.**
3. **`pret_achizitie` depinde de sursa**: pe calea principala (`cursor_preturi`, lista de preturi)
   NU se completeaza deloc din cursor (coloana nici nu exista in `SELECT`-ul lui `cursor_preturi`)
   — ramane `0`, prin acelasi tipar de valoare implicita ca la `id_gestiune` (`do_initializeaza_articol`).
   Pe sursele care incarca dintr-un document existent (`cursor_avize`, `cursor_retur_document` —
   avize si copiere), `PRET_ACHIZITIE` **e** selectat direct din `VANZARI_DETALII`, deci ajunge real.
4. **Daca proforma ar pastra `id_gestiune` real pana la salvare, nimic din contabilizare/stoc nu
   s-ar strica** — pentru ca blocajul real nu e sentinela `-1000`, ci faptul ca `scrie_proforma`
   (calea Oracle aleasa la Termina cand `eProforma=1`) **nu cheama niciodata**
   `contabilizeaza_articol`/`descarca_gestiune` (confirmat deja in raportul-sursa de runda 12).
   `adauga_articol_factura` (care ar primi `V_ID_GESTIUNE` real) **se cheama oricum**, neconditionat
   de `eProforma`, pentru orice linie — deci un `id_gestiune` real ar ajunge fara probleme in
   `VANZARI_DETALII_TEMP`/`VANZARI_DETALII`, fara sa declanseze nimic in plus. **`do_alege_stoc` nu
   rezerva stoc real** — face doar un `SELECT` (cursoare `cursor_gestiuni_articol*`) si scade local,
   in memorie, cantitatile deja puse pe documentul curent (`crsfactura`), ca operatorul sa nu aleaga
   de doua ori acelasi lot; nu scrie nimic in Oracle. Deci lasarea lui `do_alege_stoc` sa ruleze pe
   proforma nu ar bloca stoc pentru nimeni. Singurul risc real gasit e cel deja semnalat in
   `s5b_proiectare_proforma_copiere.md` §5 (drumul invers, proforma -> factura in aceeasi sesiune),
   care ramane valabil indiferent de aceasta decizie.

---

## Intrebarea 1 — se alege stocul la adaugarea unui articol pe proforma azi?

**Raspuns: NU, pe niciuna dintre caile de creare directa a unei proforme** (nu prin copiere).

### Calea principala — `cursor_preturi`

`cursor_preturi` (`PACK:2138-2646`) e apelat pentru `tnTip` in `{45, 1, 22, 5, 29, 7, 10, 23}`
(`ofacturare.prg:275-282` — lista de preturi, inclusiv `restaurant`), adica cea mai comuna sursa
pentru o proforma noua. SELECT-ul lui `cursor_preturi` intoarce `GESTIONABIL` ca
`C.IN_STOC AS GESTIONABIL` (`PACK:2192`, `:2297` — valoarea reala din `NOM_ARTICOLE`, fara nicio
constienta de proforma; `cursor_preturi` **nu are parametru** `V_PROFORMA`, confirmat prin grep pe
tot fisierul: `V_PROFORMA` apare doar la declaratia si corpul lui `cursor_retur_document`,
`PACK:408, 3939, 3944, 3952, 3957, 3994`).

Insa, imediat dupa ce acest cursor e adus in `crsarticole` in VFP, **inainte** ca operatorul sa
apuce sa vada gridul de linii:

```
COMUN\programe\ofacturare.prg:330-336
* Daca este o proforma, consider toate articolele negestionabile, pentru a nu mai alege din stoc
* 12.03.2021
IF poDate.eProforma = 1
    UPDATE (m.lcCursor) SET gestionabil  = 0
    GO TOP IN (m.lcCursor)
ENDIF
```

`m.lcCursor` = `crsarticole` (setat la `:310`). Acest bloc ruleaza **dupa** `Do Case`-ul de
incarcare (`:266-308`) si **inainte** de `creeaza_facturacrs([crsfactura])` (`:338`) — adica la
compunerea listei de articole candidate, nu la salvare. Cand operatorul adauga o linie mai tarziu,
`Do Case`-ul care alege dialogul (`ofacturare.vc2:13803-13809`) citeste `poArticol.gestionabil`,
care e deja `0` pentru **toate** liniile candidate (setat in masa mai sus), deci intra pe ramura
`frm_articol_factura`, **niciodata** pe `Thisform.do_alege_stoc`.

### Celelalte cursoare (fara copiere)

Verificat direct in `PACK_FACTURARE`, niciunul din urmatoarele cursoare, folosite pentru celelalte
surse ale unei proforme noi, nu are parametru `V_PROFORMA` si nici nu calculeaza `GESTIONABIL` in
functie de proforma — toate intorc valoarea reala din nomenclator/contract:

| Cursor | Apelat pentru (`tnTip`) | `GESTIONABIL` in SELECT | Linie |
|---|---|---|---|
| `cursor_preturi` | 45,1,22,5,29,7,10,23 | `C.IN_STOC` | `PACK:2192,2297` |
| `cursor_contract` | 2,26,6,52 | `A.GESTIONABIL` (coloana reala) | `PACK:2411,2487,2572` |
| `cursor_comanda` | 3,21,25,28,42,47 | `E.IN_STOC` | `PACK:2789` |
| `cursor_lucrare` | 27 | `C.IN_STOC` | `PACK:3029` |
| `cursor_articole_k` | 48,49 | `C.IN_STOC` | `PACK:3117` |
| `cursor_avize` | 4 | `C.IN_STOC` | `PACK:3634` |
| `cursor_aviz_nir` | 30 | `0` (hardcodat) | `PACK:3745` |
| `cursor_gestiune` | 41 | `A.GESTIONABIL` | `PACK:4104` |
| `cursor_retur` | 8,9,24 | (nu are coloana `GESTIONABIL` separata — vezi nota) | `PACK:3934-3948` |

Pentru **toate** aceste surse, aceeasi bucla `ofacturare.prg:330-336` e singurul loc care forteaza
`gestionabil=0` cand `poDate.eProforma=1` — mecanismul e identic indiferent de sursa, pentru ca
`UPDATE (m.lcCursor) SET gestionabil = 0` ruleaza pe `crsarticole` dupa orice ramura a `Do Case`-ului
de la `:266-308`, nu doar pe ramura lista-de-preturi.

### Ramura de copiere — singura cu parametru `V_PROFORMA` in Oracle

`Case m.llCopiere` (`ofacturare.prg:267-268`) e **singura** ramura care apeleaza
`cursor_retur_document`, singurul cursor cu parametru `V_PROFORMA`. Insa la copiere, documentul nou
pleaca intotdeauna cu `eProforma=0` (`nIdTipDoc` explicit necopiat, `ofacturare_comun.prg:370` —
deja stabilit in `s5b_proiectare_proforma_copiere.md` §2.3), deci `V_PROFORMA` trimis e `0`, iar
ramura `GESTIONABIL = B.IN_STOC` (valoarea reala) se activeaza, nu `WHEN V_PROFORMA=1 THEN 0`. Asta
e comportamentul **corect si dorit** la copiere (liniile redevin gestionabile) — dar confirma ca
`V_PROFORMA=1` nu apare niciodata cu valoarea `1` in vreun apel real azi (vezi Intrebarea 2).

**Concluzie Intrebarea 1**: pe orice cale de creare directa a unei proforme (nu copiere), la
momentul `Do Case`-ului de adaugare a liniei (`ofacturare.vc2:13803`), `poArticol.gestionabil` e
deja `0` — fortat de VFP la incarcare, nu valoarea reala din nomenclator. `do_alege_stoc` nu ruleaza
niciodata pentru o linie noua adaugata sub `eProforma=1`, indiferent de sursa.

---

## Intrebarea 2 — unde exact se face marcarea negestionabila si CAND?

**Doua locuri in cod, dar un singur loc activ azi:**

### 2.1 VFP — activ, la incarcarea documentului (nu la salvare)

`COMUN\programe\ofacturare.prg:333-336`, in interiorul procedurii `factureaza()`. Secventa completa
in `factureaza()`:

1. `:266-308` — `Do Case` pe `tnTip`/`llCopiere`, alege cursorul Oracle si il aduce in `crsarticole`.
2. `:311` — `goExecutor.oExecute(lcSqlCursor, lcCursor)` — executa efectiv apelul Oracle.
3. `:324-336` — daca sunt randuri, **si daca `poDate.eProforma = 1`**: `UPDATE crsarticole SET gestionabil = 0`.
4. `:338` — abia acum `creeaza_facturacrs([crsfactura])` construieste cursorul gol de linii ale
   documentului; liniile candidate (`crsarticole`, deja marcate) raman disponibile pentru ca
   operatorul sa aleaga din ele.

Acest pas ruleaza **la deschiderea ecranului de adaugare articole**, mult inainte de `Termina`
(`do_scrie_factura`, apelat doar la click pe butonul de finalizare — vezi 2.3 mai jos). Nu exista
niciun `UPDATE`/`REPLACE gestionabil With 0` la salvare in `do_scrie_factura` sau `do_scrie_articole`
— am cautat explicit `gestionabil` in ambele metode (`ofacturare.vc2:14197-14380`,`:13967-14150`) si
singura referinta la `gestionabil` in acea zona e citirea lui la `Do Case`-ul din `:13803` (decizia
de dialog), nu o scriere.

### 2.2 Oracle — exista in cod, dar mort in fluxul curent

`cursor_retur_document` (`PACK:3949-4064`), branch la `PACK:3993-4000`:
```sql
(case
   when V_PROFORMA = 1 then 0
   when V_COPIERE = 1 then B.IN_STOC
   else A.GESTIONABIL
 end) AS GESTIONABIL,
```
cu comentariu explicit in cod: `-- V_PROFORMA: Daca este proforma (1), fac articolele negestionabile
sa pot alege orice cantitate` (`PACK:3957`). Acest cod **exista si e corect scris**, dar
`cursor_retur_document` are un singur punct de apel in tot codul VFP (confirmat prin cautare in
`ofacturare.prg`, singura potrivire e la `:268`; potrivirile suplimentare gasite in
`COMUN\.svn\pristine\*` sunt copii istorice ale **aceleiasi** linii, nu apeluri suplimentare), si
acolo `V_PROFORMA` trimis e `poDate.eProforma` **al documentului nou** din copiere, care e
intotdeauna `0` (Intrebarea 1). **Deci acest branch Oracle nu se activeaza niciodata cu valoarea 1
in fluxul curent** — e cod mort din perspectiva efectului observabil, desi sintactic corect si
prezent.

### 2.3 Clarificare pe "inainte de compunerea documentului" vs. "la salvare"

Formularea raportului de runda 9 ("VFP marcheaza toate liniile proformei negestionabile inainte de
compunerea documentului") e **corecta** — "compunerea documentului" inseamna acolo constructia
listei de articole candidate/`crsfactura` (pasul 4 de mai sus), care se intampla la
**deschiderea** ecranului de facturare, nu la apasarea `Termina`. Nu exista o contradictie reala cu
mentiunea `V_PROFORMA` din `cursor_retur_document` din brief — acel `CASE` Oracle e un mecanism
separat, pentru un cursor diferit (candidati la copiere), care azi nu se declanseaza niciodata cu
`V_PROFORMA=1`. Ambele afirmatii din surse sunt adevarate simultan, pentru ca descriu lucruri
diferite.

**Concluzie Intrebarea 2**: singurul mecanism activ e `UPDATE` de masa in VFP
(`ofacturare.prg:333-336`), care ruleaza in `factureaza()`, la incarcarea/compunerea listei de
articole candidate — **cu mult inainte** de `Termina`/`do_scrie_factura`. Mecanismul Oracle din
`cursor_retur_document` exista in cod dar nu se activeaza cu valoarea curenta a parametrilor.

---

## Intrebarea 3 — se completeaza `pret_achizitie` pe liniile de proforma?

**Depinde strict de sursa cursorului, la fel ca la `gestionabil` — dar cu rezultat opus pentru
calea principala.**

### Ce cursoare selecteaza `PRET_ACHIZITIE`

Cautare directa in `PACK_FACTURARE` (`grep PRET_ACHIZITIE`): coloana **nu apare deloc** in
`cursor_preturi` (`PACK:2138-2646`), `cursor_contract` (`:2646-2952`), `cursor_comanda`
(`:2952-3173`), `cursor_lucrare` (`:3173-3595`), `cursor_articole_k` (`:3595-3703`),
`cursor_gestiune` (`:4158-4349`). Apare doar in:
- `cursor_avize` (in jurul liniilor `PACK:3754-3864` — sursa `VANZARI_DETALII`/`RUL`, articol
  provenit dintr-un aviz existent);
- `cursor_retur_document` (`PACK:4026`, `A.PRET_ACHIZITIE` direct din `VANZARI_DETALII`, folosit la
  copiere).

### Ce se intampla in VFP cand lipseste

`crsfactura` (structura din `creeaza_facturacrs`, `ofacturare_comun.prg:1777`) are un camp
`pret_achizitie` in schema — dar o linie noua nu se construieste prin copiere in masa din
`crsarticole`, ci prin `Scatter`/`Gather` pe obiectul `poArticol`, populat cand utilizatorul alege un
articol din grid. `do_initializeaza_articol` (`ofacturare.vc2:13715-13719`), apelat pentru orice
linie care trece prin `frm_articol_factura` (ramura negestionabila, deci si orice linie de
proforma):
```
If Type('toArticol.pret_achizitie')="U"
    AddProperty(toArticol,'pret_achizitie',0)
Endif
If Isnull(toArticol.pret_achizitie)
    toArticol.pret_achizitie = 0
Endif
```
Deci: **pe calea principala (lista de preturi), `pret_achizitie` ramane `0`** pe liniile de proforma
— campul nici nu exista in `crsarticole` sursa (cursorul Oracle nu-l selecteaza), asa ca proprietatea
lipseste pe `poArticol` si `do_initializeaza_articol` o creeaza cu valoare implicita `0`, exact
acelasi tipar defensiv folosit pentru `id_gestiune=-1000` (aceeasi metoda, linii apropiate,
`:13618-13623` vs `:13715-13719`).

**Pe sursele care carata un document existent** (`cursor_avize`, si `cursor_retur_document` la
copiere), `pret_achizitie` **e** populat real din `VANZARI_DETALII.PRET_ACHIZITIE` a documentului
sursa, deci proprietatea exista pe `poArticol` si `do_initializeaza_articol` nu o suprascrie.

### Unde ajunge

Indiferent de valoare (`0` sau reala), `poArt.pret_achizitie` merge neschimbat catre Oracle ca
parametru pozitional in apelul catre `adauga_articol_factura`:
```
ofacturare.vc2:14073
... + Alltrim(Str(poArt.pret_achizitie,18,gnPPret)) + [,] + ...
```
primit ca `V_PRET_ACHIZITIE_TEMP` (`PACK:4995`), copiat direct `V_PRET_ACHIZITIE := V_PRET_ACHIZITIE_TEMP`
(`PACK:5031`, fara sentinela, spre deosebire de `id_gestiune`) si scris ca atare in
`VANZARI_DETALII_TEMP.PRET_ACHIZITIE` (`PACK:5229/5259`), apoi in `VANZARI_DETALII` la
`scrie_in_vanzari`.

**Concluzie Intrebarea 3**: pe calea principala (lista de preturi), `pret_achizitie` ramane `0` pe
liniile de proforma — nu vine din `do_alege_stoc` (care nu ruleaza) si nici din cursorul Oracle (care
nu-l selecteaza pe aceasta ramura). Pe sursele avize/copiere, valoarea reala din documentul sursa se
pastreaza.

---

## Intrebarea 4 — ce s-ar strica daca proforma ar pastra gestiunea reala pana la salvare?

### 4a. `adauga_articol_factura` se cheama si pentru liniile de proforma?

**Da, neconditionat.** `do_scrie_factura` (`ofacturare.vc2:14197+`) cheama
`Thisform.do_scrie_articole()` la linia **14264**, **inainte** de `Do Case poDate.eProforma = 1`
(care alege intre `scrie_proforma` si `scrie_factura2`, la `:14282`):
```
ofacturare.vc2:14264
llReturn = Thisform.do_scrie_articole() && se deschide tranzactie manuala
...
ofacturare.vc2:14282
Do Case
    Case poDate.eProforma = 1
        * scrie_proforma are aceiasi parametri ca scrie_factura2
        * salveaza doar in vanzari, nu si in contabilitate
        lcSql = [{call pack_facturare.scrie_proforma(...)}]
```
`do_scrie_articole` parcurge liniile din `crsfactura` si cheama `adauga_articol_factura` pentru
fiecare (`ofacturare.vc2:14069-14073`, deja citat in raportul-sursa) — **acelasi cod, indiferent de
`eProforma`**. Daca `poArt.id_gestiune` ar fi real (nu `-1000`), `adauga_articol_factura` l-ar
traduce direct in `V_ID_GESTIUNE2 := V_ID_GESTIUNE` (`PACK:5032-5034`, gate-ul `<> -1000`) si l-ar
scrie ca atare in `VANZARI_DETALII_TEMP.ID_GESTIUNE` (`PACK:5237,5267`), apoi in
`VANZARI_DETALII.ID_GESTIUNE` la `scrie_in_vanzari` (`INSERT INTO VANZARI_DETALII SELECT FROM
VANZARI_DETALII_TEMP`, fara nicio conditie suplimentara pe `id_gestiune`).

### 4b. Are efect ca linia sa ramana cu `ID_GESTIUNE` completat, cata vreme `scrie_proforma` nu cheama `contabilizeaza_articol`?

**Niciunul, pe partea de contabilizare/descarcare.** Confirmat deja (runda 12,
`s5b_proiectare_proforma_copiere.md`, sectiunea "Descoperire centrala"): `scrie_proforma`
(`PACK:5637-5671`) cheama **doar** `scrie_in_vanzari` — insereaza antetul si liniile ca atare, apoi
seteaza `VANZARI.EPROFORMA=1`. **Nu cheama** `contabilizeaza_articol` in niciun caz. Sentinela
`-1000` conteaza doar **in interiorul** lui `contabilizeaza_articol` (`PACK:7472-7476`), care nu
ruleaza deloc pentru `scrie_proforma`. Deci `ID_GESTIUNE` real pe o linie de proforma nu ar declansa
`descarca_gestiune`, nu ar genera `NOTE_CONTABILE`, nu ar atinge `RUL`/`STOC` — pentru ca intreaga
functie care ar face asta nu se executa pe traseul `scrie_proforma`.

### 4c. Rapoarte/view-uri care citesc `ID_GESTIUNE` pe documente `eProforma=1` si ar arata altceva?

Cautare `eproforma` (case-insensitive) in tot `PACK_FACTURARE`: doar 3 potriviri, toate in
`scrie_proforma`/comentarii (`PACK:1408, 5666, 5668`) — nicio alta procedura/vedere din pachet nu
filtreaza sau calculeaza dupa `EPROFORMA`.

Pe partea VFP, `crsDetaliiListare` (folosit la **relistarea** unui document deja emis, inclusiv
proforma — `oproceduri_facturare.prg:1111-1126`, sursa `fact_vfacturi2`) **include** coloana
`id_gestiune` in schema si in `SELECT`, indiferent de `eproforma` (nu exista filtru pe
`eproforma` in acest `SELECT`). Deci daca `ID_GESTIUNE` ar fi real pe o proforma, acest cursor l-ar
citi ca atare la relistare — azi citeste `NULL`. **Nu am putut confirma daca vreun raport `.frx`
tiparit efectiv afiseaza `id_gestiune`/`nume_gestiune` pe documentul proforma insusi**
(rapoartele `PROFORMA`/`PROFORMA_VAL` nu au versiune text `.fr2` generata in `Rapoarte\`, deci nu
s-au putut grep-ui direct) — de regula gestiunea e un camp intern, nu unul tiparit pe un document
comercial, dar afirmatia ramane neconfirmata pe cod, nu doar presupusa corecta. Vezi "Ce nu s-a
putut stabili".

### 4d. `do_alege_stoc` rezerva stoc sau doar alege?

**Doar alege — nu scrie nimic in Oracle.** Corpul complet al `do_alege_stoc`
(`ofacturare.vc2:13200-13400+`) face exclusiv: (1) un `SELECT` prin
`cursor_gestiuni_articol`/`cursor_gestiuni_articol_retur`/`cursor_gestiuni_articol_stoc0` (toate
proceduri read-only, populeaza un cursor local `crsgestarticoltemp`), (2) o scadere **locala, in
memorie**, a cantitatilor deja adaugate pe **acelasi document, in aceeasi sesiune**
(`ofacturare.vc2:13273-13311`: `SELECT ... FROM crsfactura ... INTO CURSOR crsFacturaArticoleTemp`,
apoi `a.cantitate - Nvl(b.cantitate,0)` la afisare), ca sa nu i se ofere operatorului sa aleaga de
doua ori acelasi lot pe acelasi document. **Nu exista niciun `INSERT`/`UPDATE` catre Oracle in
aceasta metoda** — `goExecutor.oExecute` apare o singura data, pentru `SELECT`-ul de la pasul (1).
Blocarea/decrementarea reala a stocului se intampla abia la `descarca_gestiune`
(`PACK:7648-7797`), apelata doar din `contabilizeaza_articol`, care (per 4b) nu ruleaza niciodata
pentru `scrie_proforma`. **Deci chiar daca `do_alege_stoc` ar rula pe liniile unei proforme, nu ar
"tine" stoc blocat pentru nimeni** — nu exista mecanism de rezervare reala in aplicatie pe acest
traseu, doar o verificare locala de neduplicare in sesiunea curenta.

**Concluzie Intrebarea 4**: nimic din contabilizare, descarcare de gestiune sau stoc real nu s-ar
strica daca proforma ar pastra `id_gestiune` real pana la salvare — blocajul functional e la nivelul
routing-ului `scrie_proforma` (care nu cheama `contabilizeaza_articol`), nu la nivelul sentinelei
`-1000`. Singurul loc unde s-ar vedea o diferenta reala e la **relistarea** documentului
(`crsDetaliiListare`/`fact_vfacturi2`), unde `id_gestiune` ar aparea completat in loc de `NULL` —
efect cosmetic/informational, nu unul care sa afecteze stocul sau contabilitatea, cu rezerva ca nu
s-a confirmat daca vreun `.frx` chiar il tipareste. Riscul real ramas e cel deja identificat in
`s5b_proiectare_proforma_copiere.md` §5 (drumul invers, proforma comutata inapoi in factura in
aceeasi sesiune, inainte de Termina) — acela nu se schimba, indiferent de aceasta decizie, pentru ca
depinde de routing-ul de la Termina, nu de momentul in care se alege gestiunea.

---

## Ce nu s-a putut stabili

1. **Daca vreun raport `.frx` tiparit (PROFORMA/PROFORMA_VAL) afiseaza efectiv `id_gestiune` sau
   `nume_gestiune` pe documentul insusi** — rapoartele nu au versiune text `.fr2` generata in
   `Rapoarte\`, asa ca nu s-a putut grep pe continutul lor; ar necesita fie generarea textului cu
   `git_sync.ps1`/`foxbin2prg` (in afara mandatului read-only), fie deschidere in IDE VFP.
2. **Nu s-a rulat nimic pe date vii** — toata analiza e trasare de cod static (VFP text + PL/SQL
   text), conform mandatului read-only.
3. **Cautarea "eproforma" in Oracle** a acoperit doar `PACK_FACTURARE` — nu s-au verificat alte
   pachete/view-uri/rapoarte Oracle care ar putea referi `VANZARI.EPROFORMA` impreuna cu
   `ID_GESTIUNE` (de exemplu rapoarte de gestiune/stoc din alte module ROA). Zero rezultate in
   `PACK_FACTURARE` nu e dovada de completitudine pentru intreaga schema.
4. **`cursor_retur`** (`PACK:3934-3948`, folosit pentru `tnTip` 8,9,24 — retururi) nu a fost citit
   integral pentru coloana `GESTIONABIL` (tabelul de la Intrebarea 1 il listeaza fara valoare
   confirmata) — nu are parametru `V_PROFORMA` (confirmat prin grep), deci concluzia generala
   (marcarea vine doar din VFP) ramane valabila, dar valoarea exacta intoarsa de coloana nu a fost
   verificata linie-cu-linie.

---

## Handoff

Cercetare incheiata intr-o singura sesiune, fara sa fie nevoie de predare de context. Toate cele 4
intrebari din brief au raspuns cu dovada `fisier:linie`, plus rezumatul executiv de mai sus. Niciun
fisier de cod atins, niciun `git_sync.ps1`/`txt2vcx.ps1` rulat, niciun commit, nicio scriere pe
Oracle.