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 handoff intermediar (sters) (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 intermediar (sters). 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. diff aplicat (sters) — 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 handoff intermediar (sters) 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.