# S5 — testul cu scriere reala in Oracle. Rezultat

Aprobat de Marius (09.08.2026, consemnat in `docs\handoff_s5.md`). Suita:
`COMUN\utile\Teste\editare_factura\test_s5_scriere_reala.prg`. Log:
`COMUN\utile\Teste\editare_factura\test_s5_scriere_reala_log.txt` (rulare 09.08.2026 23:41:32-23:41:35).
Diff: `docs\diff_s5_test_scriere_reala.patch`.

## Rezultat

**25 PASS / 0 FAIL**, numarate din log (12 la trecerea 1, 13 la trecerea 2). Ultima linie a logului
este `done`, deci rularea a ajuns la capat. Ambele treceri s-au inchis cu **COMMIT real**, iar starea
finala a fost verificata **independent prin `sqlplus`**, nu din logul testului.

**Baseline inainte de pornire**: `test_incarca_vanzare_din_nota` rerulata la 23:27:52 — **5 PASS /
0 FAIL**, identic cu asteptarea. Golul de baseline din briefing e inchis.

## Ce dovedeste, si nu putea fi dovedit headless

Proba centrala nu vine dintr-o asertie pe starea finala, ci din **citirea starii necomise in
interiorul tranzactiei**, pe aceeasi conexiune, intre pasi. In ambele treceri:

| Moment | `VANZARI_DETALII.STERS` pe linia stearsa (`det=1582`) |
|---|---|
| inainte de tranzactie | `1` (trecerea 2) / `0` (trecerea 1, inca nestearsa) |
| **dupa `finalizeaza_modificare_nota`, inainte de scrierea liniilor** | **`0`** — resetul a rulat si a **inviat** linia |
| dupa `ScrieArticoleFacturaEditate` | **`1`** — idiomul a corectat resetul |
| dupa COMMIT | `1` |

Log: liniile 19-28 (trecerea 1) si 57-67 (trecerea 2). Asta stabileste direct cele doua afirmatii ale
deciziei 38: `pack_facturare.actualizeaza_vanzari` face `UPDATE VANZARI_DETALII SET STERS = 0` pe tot
documentul **inainte** ca liniile sa fie scrise, si idiomul „marcheaza tot sters, invie ce ramane",
apelat **dupa** `finalizeaza_modificare_nota` in aceeasi tranzactie, il repara.

Trecerea 2 e cea care conteaza pentru consecinta 2: documentul a fost **reeditat fara nicio
modificare**, resetul a inviat din nou `det=1582`, si linia a ramas totusi stearsa dupa commit.
Fara aceasta trecere, testul nu ar fi atins scopul.

## Ordinea testata

Copiata literal din `ofacturare_comun.vc2:3799-3837`, inclusiv blocul nou de la `:3828-3830`:

```
MyDeschideTranzactie()                       -- _frm_base.vc2:252-265, reprodus inline
  OSCRIE_IN_FISIERE(2, .T., .T.)  => 1
  OSCRIE_IN_FISIERE(0, .T., .T.)  => 1
  pack_contafin.finalizeaza_modificare_nota  => 1
  ScrieArticoleFacturaEditate(tvanz.id_vanzare) => 1
MyInchideTranzactie(1)                       -- COMMIT
```

`OSCRIE_IN_FISIERE`, `finalizeaza_modificare_nota` si `ScrieArticoleFacturaEditate` au rulat **reale**,
pe conexiune Oracle reala. Garda blocului nou (`"OFACTURARE_EDITARE" $ Upper(Set("Procedure"))`,
`Used('tvanz')`, `Reccount('tvanz') = 1`) a fost satisfacuta in ambele treceri — logul ar fi scris
`ATENTIE: blocul ScrieArticoleFacturaEditate NU s-a executat` altfel.

## Documentul de test si ce s-a facut cu el

`id_vanzare = 1049`, factura tip 1 din 07.08.2026, `id_fact = 8009659`, `discount = 0`, fara linii de
set (`id_vanzare_set` NULL pe toate), 3 linii active. **Nu** `id_vanzare = 1050`, care e documentul pe
care `descopera_caz_test.prg` il alege pentru cazul `FACTURA_ARTICOLE` (`order by id_vanzare desc`).
Garzile `ReferinteDocumenteNota` si `EsteInEFactura` intorc 0 pe el, verificat inainte de rulare.

**Trecerea 1** — o linie stearsa, o cantitate schimbata, o linie noua:

| Linie | Actiune in `tvd` | Stare in Oracle dupa commit |
|---|---|---|
| `det=1581` | cantitate `1 -> 2`, `lmodificat = .T.` | `sters=0`, `cant=2`, `pret_achizitie=10` (neatins) |
| `det=1582` | marcata stearsa (`tvd.sters = 1`) | `sters=1` |
| `det=1583` | neatinsa | `sters=0`, `cant=1` |
| linie noua | `id_vanzare_det = 0`, `cantitate=3`, `pret=50`, `pret_achizitie=77.77` | `det=1588` alocat de `TRG_VANZARI_DET_BEFOINS`, `sters=0`, `pret_achizitie=77.77` |

**Trecerea 2** — reeditare fara nicio modificare: nicio linie noua, `det=1582` inca `sters=1`,
`det=1588` inca activa cu `pret_achizitie = 77.77`, totaluri neschimbate.

`PRET_ACHIZITIE` e verificat pe valori **nenule si distincte** (10 pe linia existenta careia i s-a
schimbat cantitatea, 77.77 pe linia noua) — nu pe zerouri, care n-ar fi dovedit nimic. La trecerea 2
linia `1588` e deja **linie existenta**, deci trece prin `UPDATE`-ul care omite `pret_achizitie` din
`SET`: faptul ca a ramas 77.77 e proba directa a omisiunii.

## Verificarea independenta prin sqlplus (dupa ambele treceri)

`MARIUSM_AUTO/…@ROA_CENTRAL`, dupa terminarea procesului VFP:

```sql
select cod, sters, id_fact, discount, total_fara_tva, total_tva, total_cu_tva
  from vanzari where id_vanzare = 1049;
```
```
cod=1140897 sters=0 id_fact=8009659 discount=0 ftva=747.96 tva=157.06 ctva=905.02
```

```sql
select id_vanzare_det, id_articol, cantitate, pret, pret_cu_tva, proc_tvav, id_gestiune,
       sters, pret_achizitie, id_utils, validat, custodie, descarcat, diferenta
  from vanzari_detalii where id_vanzare = 1049 order by id_vanzare_det;
```
```
det=1581 art=315554536  cant=2 pret=302.51 pret_cu_tva=1 proc_tvav=1.21 id_gest=1     sters=0 pret_ach=10    id_utils=-3 validat=0 custodie=0 descarcat=0 diferenta=0
det=1582 art=4294507492 cant=1 pret=121.3  pret_cu_tva=1 proc_tvav=1.21 id_gest=0     sters=1 pret_ach=0     id_utils=-3 validat=0 custodie=0 descarcat=0 diferenta=0
det=1583 art=315554536  cant=1 pret=150    pret_cu_tva=1 proc_tvav=1.21 id_gest=2     sters=0 pret_ach=10    id_utils=-3 validat=0 custodie=0 descarcat=0 diferenta=0
det=1588 art=315554536  cant=3 pret=50     pret_cu_tva=1 proc_tvav=1.21 id_gest=-1000 sters=0 pret_ach=77.77 id_utils=-3 validat=0 custodie=0 descarcat=0 diferenta=0
```

```sql
select sum(cantitate*pret) from vanzari_detalii where id_vanzare = 1049 and sters = 0;
```
```
905.02        -- identic cu VANZARI.total_cu_tva dupa recalculeaza_totaluri_vanzari
```

```sql
select cod, count(*), sum(sters) from vact_tot
 where an=2026 and luna=8 and cod in (1140887,1140896,1140897) group by cod;
```
```
cod=1140887 randuri=10 sterse=10      -- nota de la prima editare, integral stearsa
cod=1140896 randuri=10 sterse=10      -- nota intermediara, integral stearsa
cod=1140897 randuri=10 sterse=0       -- nota curenta, activa
```

```sql
select s.sid from v$transaction t join v$session s on s.saddr = t.ses_addr
 where s.username = 'MARIUSM_AUTO';
```
```
(0 randuri)   -- nicio tranzactie deschisa
```

Totalurile: `747.96 + 157.06 = 905.02` (identitate verificata), iar `905.02` e chiar suma
`cantitate * pret` pe liniile active — relatie care se verifica si pe starea de dinaintea editarii
(`302.51 + 121.30 + 150.00 = 573.81`), pentru ca toate liniile documentului au `pret_cu_tva = 1`.

## Date de test consumate ireversibil

- **`cod`-uri realocate: `1140887` -> `1140896` -> `1140897`.** `1140897` e valoarea curenta; cine
  reia testul pe `id_vanzare = 1049` trebuie sa citeasca `cod`-ul din `VANZARI`, nu sa-l presupuna.
- **`det=1582` ramane `sters=1` definitiv** — documentul are acum 3 linii active in loc de 3 initiale,
  dar alta compozitie (`1581`, `1583`, `1588`).
- **`det=1588`** e o linie noua, creata de test, cu `id_gestiune = -1000` si `pret_achizitie = 77.77`.
- Totalurile documentului: `573.81` -> `905.02`.
- `1049` **nu** e documentul ales de `descopera_caz_test.prg` pentru `FACTURA_ARTICOLE` (acela e
  `1050`), si nu apare in listele de excludere ale suitelor existente (`1140888`/`1140885` pentru
  `test_incarca_cursoare`, `1139934` pentru `test_ui_sterge_linie`).

Rerularea suitei pe acelasi document e idempotenta ca structura: trecerea 1 ar sterge iar a doua
linie activa si ar adauga inca una.

## Ce NU acopera testul

- **`inainte_de_do_termin`** — `buton = 1` e fortat direct, deci cele cinci validari noi din
  `omodificari.vc2` (cantitate <= 0, `id_articol` nul, `pret` nul, zero linii active, avertismentul de
  `pret_achizitie = 0`) **nu** au fost executate pe aceasta cale.
- **`frm_modific2024`** nu a fost instantiat: gridul de pe PAGE3, coloana noua de pret de achizitie,
  editabilitatea per rand si marcajul liniilor de set raman neverificate aici (cad in verificarea pe
  ecran).
- **Liniile din seturi** — documentul ales nu are `id_vanzare_set` nenul pe nicio linie, deci
  comportamentul agregarii pe seturi (totalurile luate din capul de set, nu din componente) **nu e
  atins**. Cifrele de totaluri de mai sus nu spun nimic despre acel caz.
- **Al doilea punct de intrare** (`comun.vc2:2491`) nu a fost rulat; agatarea acolo e identica
  textual, dar testul a trecut doar prin ramura din `ofacturare_comun.vc2`.
- **Documentele in valuta** si cele cu `discount` nenul — `1049` are `discount = 0` si
  `in_valuta = 0`, deci parametrul de discount al lui `recalculeaza_totaluri_vanzari` a fost testat
  doar cu valoarea `0`, niciodata cu `NULL` si niciodata cu o valoare nenula.
- **Esecul partial** — nicio cale de eroare nu a fost provocata, deci ROLLBACK-ul lantului
  (`lnSucces < 0`) ramane netestat pe date reale.

## Observatii pe cod, fara defecte de raportat

- `INSERT`-ul din `ScrieArticoleFacturaEditate` **omite** cinci coloane `NOT NULL` din
  `VANZARI_DETALII` (`VALIDAT`, `STERS`, `DIFERENTA`, `CUSTODIE`, `DESCARCAT`). Verificat pe dictionar
  inainte de rulare: toate cinci au `DEFAULT 0`, deci `INSERT`-ul e valid, iar linia noua intra activa
  (`STERS = 0`) — confirmat pe `det=1588`. Nu e defect, dar dependenta de `DEFAULT` nu se vede din cod.
- `id_gestiune = -1000` (valoarea folosita de `CreeazaPoArticolNouTvd`) **nu** are corespondent in
  `NOM_GESTIUNI` si nu exista constrangere de cheie straina pe coloana — `INSERT`-ul trece. Inaintea
  acestui test nu exista nicio linie in `VANZARI_DETALII` cu aceasta valoare; acum exista una.
- Nu am gasit niciun defect in codul de productie in urma acestui test.

## Igiena la iesire

Zero tranzactii deschise (interogare pe `v$transaction`, 0 randuri), zero procese `vfp9.exe` ramase
(`tasklist`), zero commituri git sau SVN. Singurul fisier adaugat de aceasta lucrare in arborele de
lucru este suita de test; `COMUN\clase\ofacturare.vc2`, `omodificari.vc2`, `actualizeaza_vanzari` si
`PACK_CONTAFIN` nu au fost atinse.