roafacturare/docs/cercetare/rec_s5_scriere_reala.md

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:

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

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

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

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

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.