# 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.