roafacturare/docs/brief_s5_test_scriere_reala.md

# Briefing — S5, testul cu scriere reala in Oracle

Misiune pentru un agent proaspat. Se citeste **impreuna cu** `docs\handoff_s5.md` (starea blocului) si
`COMUN\docs\reguli_lucru.md` (regulile de livrare si testare). Nu relua cercetarea — e facuta.

## De ce exista acest test

Cele sase suite headless dovedesc **doar absenta regresiei**. Lucrul care conteaza in S5 nu e atins de
niciuna dintre ele, pentru ca se intampla in Oracle, in interiorul unei tranzactii:

`pack_facturare.actualizeaza_vanzari` (`PACK_FACTURARE.pck:16020-16023`) face
`UPDATE VANZARI_DETALII SET STERS = 0` pe **tot documentul**, fara garda. E apelata din
`finalizeaza_modificare_nota`. Consecinta dubla, care e chiar motivul deciziei 38:

1. o linie marcata stearsa de VFP **inainte** de `finalizeaza_modificare_nota` s-ar pierde tacut;
2. orice linie stearsa la o editare **anterioara** e inviata la fiecare salvare ulterioara — deci
   stergerea de linie n-ar deveni niciodata definitiva.

Idiomul adoptat („marcheaza tot sters, invie ce ramane", scris **dupa** `finalizeaza_modificare_nota`)
trebuie sa corecteze ambele. **Asta e ce are de dovedit testul, nu altceva.**

## Ordinea care se testeaza (decizia 38)

O singura tranzactie manuala:

```
do_deschide_tranzactie()
  OSCRIE_IN_FISIERE(2, ...)                                          -- sterge nota veche
  OSCRIE_IN_FISIERE(0, ...)                                          -- scrie nota noua
  finalizeaza_modificare_nota(...)                                   -- realiniaza COD, RESETEAZA STERS = 0
  ScrieArticoleFacturaEditate(id_vanzare)                            -- NOU
  pack_facturare.recalculeaza_totaluri_vanzari(id_vanzare, discount) -- NOU
do_inchide_tranzactie(Iif(lnSucces < 0, 2, 1))
```

Agatarea reala e in `ofacturare_comun.vc2:3828` si `comun.vc2:2491`, acelasi bloc de 3 randuri.

## Ce trebuie sa dovedeasca, punct cu punct

**Trecerea 1 — o editare cu o linie stearsa si o linie adaugata:**

- linia marcata stearsa in `tvd` ajunge cu `STERS = 1` in `VANZARI_DETALII` **dupa** ce s-a intors
  `finalizeaza_modificare_nota` (deci resetul ei nu o invie);
- linia noua (`id_vanzare_det = 0`) ajunge cu `INSERT`, cu `ID_VANZARE_DET` alocat de trigger
  (`TRG_VANZARI_DET_BEFOINS`), si cu `PRET_ACHIZITIE` exact valoarea tastata;
- liniile pastrate raman active (`STERS = 0`) cu cantitatile/preturile editate;
- `PRET_ACHIZITIE` pe liniile **existente** ramane **neatins** (se omite din `SET`-ul de `UPDATE`) —
  se verifica valoarea dinainte vs. dupa, pe o linie careia i s-a schimbat cantitatea;
- totalurile din `VANZARI` corespund liniilor active dupa recalcul.

**Trecerea 2 — a doua editare a ACELEIASI facturi, fara nicio modificare:**

- linia stearsa la trecerea 1 **ramane stearsa**. Asta e consecinta 2 din decizia 38 si e singurul
  mod de a dovedi ca idiomul repara resetul. **Fara aceasta trecere, testul nu si-a atins scopul.**

## Cum se verifica

**Nu din logul testului.** Dupa fiecare trecere, verificare **independenta prin `sqlplus`** pe
`MARIUSM_AUTO@ROA_CENTRAL`, cu `SELECT`-uri pe `VANZARI` si `VANZARI_DETALII`. Tiparul exista deja si
a fost folosit cu succes: `COMUN\utile\Teste\editare_factura\test_writeback_buton1.prg` plus
`docs\cercetare\rec_test_writeback.md` — **citeste-le intai**, sunt modelul de urmat (au facut COMMIT
real pe `id_vanzare = 1048`, cu 5 verificari confirmate independent).

Cifrele se **numara din loguri**, nu se citesc din impresie. Dovada ca rularea a ajuns la capat e
linia finala a suitei (`REZULTAT` sau `done`, dupa tipar).

## Aprobare si costuri

**Scrierea reala e aprobata de Marius** (09.08.2026), aprobarea e consemnata in `handoff_s5.md`.
**Consuma date de test ireversibil**: `cod`-ul documentului se realoca la fiecare salvare (la testul
precedent, `1140886 -> 1140893 -> 1140894`). Alege un document de test, **nu** unul folosit ca baza de
regresie de alte suite daca poti evita, si **consemneaza in raport `cod`-urile consumate**.

## Reguli care nu se incalca

- **`COMUN\clase\ofacturare.vc2` nu se atinge.**
- `actualizeaza_vanzari` si `PACK_CONTAFIN` **nu se modifica**.
- **Fara commit** — nici git, nici SVN.
- **Un singur scriitor pe fisier.** `omodificari.vc2` e inchis (livrare finala), nu-l atinge.
  Fisierele tale sunt in `COMUN\utile\Teste\editare_factura\`.
- **Nu rula `git_sync.ps1`** decat daca text si binar sunt sincrone.
- **Nu porni VFP daca mai exista un `vfp9.exe` viu** care nu e al tau — verifica intai.
- Daca gasesti un defect real in codul de productie, **nu-l repara singur**: raporteaza-l cu
  `fisier:linie` + citatul minim si asteapta.

## Livrabile — se scriu PE DISC, la aceste cai exacte

1. `COMUN\utile\Teste\editare_factura\test_s5_scriere_reala.prg` — suita.
2. `D:\ROA\ROAFACTURARE\docs\cercetare\rec_s5_scriere_reala.md` — raportul: ce s-a dovedit, ce nu,
   `SELECT`-urile de verificare cu rezultatele lor, `cod`-urile consumate, cifrele din loguri.
3. `D:\ROA\ROAFACTURARE\docs\diff_s5_test_scriere_reala.patch` — diff-ul.

Raspunsul catre orchestrator e **scurt**: „GATA" + cifrele + ce nu s-a dovedit. **Nu trimite raportul
in text** — el sta pe disc.

## Predarea contextului (REGULA ZERO)

Daca ajungi la **~200-250k** context: **opreste-te**, adu tot la o stare consistenta pe disc, scrie
`D:\ROA\ROAFACTURARE\docs\handoff_s5_scriere_reala.md` cu **starea** (ce e facut, ce nu, ce e
periculos: tranzactie deschisa, proces viu, date consumate), si anunta. Nu continua „ca mai e putin" —
si **nu lasa niciodata o tranzactie deschisa** in Oracle.