roafacturare/docs/cercetare/rec_s5_goluri_test.md

S5 — inchiderea golurilor de acoperire (rollback, al doilea punct de intrare, linii de set)

Continua docs\livrare_s5.md, sectiunea 5 „Ce NU e acoperit". Trei goluri, in ordinea cerută: calea de ROLLBACK la esec partial, al doilea punct de intrare (comun.vc2:2491), liniile din seturi de articole. Suite noi: COMUN\utile\Teste\editare_factura\test_s5_rollback_real.prg, COMUN\utile\Teste\editare_factura\test_s5_al_doilea_intrare.prg. Niciun cod de productie atins.

A. Calea de ROLLBACK la esec partial — INCHIS, cu o descoperire importanta

Suita: test_s5_rollback_real.prg. Log: test_s5_rollback_real_log.txt (rulare 10.08.2026, 01:20:31-01:20:32). 13 PASS / 0 FAIL.

PARTEA M (mock, fara Oracle) — completeaza test_s5_validari_articole.prg/B3 (care opreste esecul la a DOUA comanda, in mijlocul buclei de UPDATE): aici esecul e la PRIMA comanda a helperului (pasul 1, „marcheaza tot sters"). Dovedit: functia intoarce .F. imediat, o singura comanda incercata (nApeluri=1) — nicio comanda de UPDATE/INSERT/recalcul nu se mai declanseaza.

PARTEA R (real, Oracle) — pe id_vanzare=1049, prin SQLEXEC brut (nu prin ScrieArticoleFacturaEditate/goExecutor.oExecuta — vezi descoperirea de mai jos), reproduce EXACT secventa SQL pe care helperul o genereaza pentru un caz cu esec la INSERT (linie noua cu id_articol=999999999, verificat inainte ca articolul chiar nu exista in NOM_ARTICOLE):

Pas	Comanda	Rezultat
1	UPDATE ... SET STERS=1 (marcheaza tot)	reuseste
2	3x UPDATE (invie+actualizeaza liniile pastrate 1581/1583/1588)	reuseste
3a	INSERT linie noua VALIDA	reuseste
3b	INSERT linie noua cu id_articol inexistent	ORA-02291 (FK_VANZARE_DET002)

Dovedit, cu citiri necomise pe aceeasi conexiune, INTRE pasi (proba de executie PARTIALA reala, nu doar teoretica): dupa pasii 1-2, cele 3 linii pastrate erau deja active si actualizate (necomis); dupa insertul valid, documentul avea deja 5 linii (necomis). Insertul invalid a oprit secventa exact acolo (simetric cu EXIT din SCAN-ul helperului) — recalculeaza_totaluri_vanzari nu s-a mai apelat. Tranzactia s-a inchis cu ROLLBACK (tiparul apelantilor: lnSucces=Iif(...,1,-1) → MyInchideTranzactie(Iif(lnSucces<0,2,1))).

Verificat independent prin sqlplus, dupa terminarea procesului VFP: VANZARI.COD neschimbat (1140898), toate cele 4 randuri din VANZARI_DETALII identice octet-cu-octet cu starea de dinainte (id_vanzare_det:sters:cantitate:pret:pret_achizitie), zero randuri cu id_articol=999999999, zero tranzactii deschise.

Descoperire, NEREPARATA (cod de productie interzis pentru acest agent) — de raportat separat

goExecutor.oExecuta(<sql>) — calea Oracle pe care ScrieArticoleFacturaEditate o foloseste pentru toate comenzile ei — agata procesul VFP headless la o eroare Oracle REALA, sub tranzactie manuala (SQLSetprop(...,"Transactions",2)), chiar daca Oracle a raspuns deja cu eroarea. Constatat de doua ori, izolat, cu un script minimal (~15 linii, sters dupa investigatie):

• sesiunea Oracle arata INACTIVE/SQL*Net message from client (Oracle a raspuns, asteapta urmatoarea comanda de la client) — nu e o incuietoare (v$lock/v$transaction: nimic blocant);
• EnumWindows pe procesul VFP arata doar fereastra principala — nu e un dialog Windows care asteapta input;
• SQLEXEC brut (fara goExecutor) pe exact aceeasi comanda intoarce eroarea instant (lnRes=-1, AERROR populat corect, alen=7, [1]=1526) — deci nu e o problema a driverului Oracle/OLEDB in sine.

CAUZA GASITA de orchestrator, 10.08.2026 — e artefact headless, NU un defect de productie

Suspiciunea pe goLog.Log() de mai sus e gresita. Cauza reala, citita in cod:

ORA-02291 ajunge in oproceduri_comune.prg ca eroare ODBC, deci lnEroare1 = 1526 si lnEroare2 = 2291. 2291 nu e in lista de reconectare (:385), deci executia intra pe ramura Otherwise (:421-424):

If llShowError
    lnRaspuns = amessagebox('Eroare necunoscuta' + Chr(13) + lcTextEroare, 0, 'Eroare')
Endif

Acolo se agata: un AMESSAGEBOX modal, intr-un proces headless in care nimeni nu apasa OK. goLog.Log() (:427) vine dupa el si nici nu apuca sa ruleze. Explica si de ce SQLEXEC brut intoarce eroarea instant — el nu trece prin ramura asta.

llShowError vine din This.lShowError cand apelantul nu-l paseaza (:234 vs :243), iar ScrieArticoleFacturaEditate cheama goExecutor.oExecuta(m.lcSql) fara al doilea argument pe toate cele patru cai (ofacturare_editare.prg:491, 502, 531, 547) — deci mesajul chiar se afiseaza.

Consecinta reala pentru livrare, inversa fata de ce scria mai sus: in productie, cu utilizator in fata ecranului, comportamentul e corect — se afiseaza mesajul, Exit iese din bucla, helperul intoarce .F., apelantul inchide tranzactia cu ROLLBACK. Aplicatia nu ramane agatata. Agatarea e capcana headless deja documentata in docs\progres.md („Dialogurile native VFP blocheaza testul headless la infinit"), lovita aici de un script minimal care nu avea mock pe amessagebox.

Ce ramane, ca wart preexistent al infrastructurii comune (nu al S5, si neatins): textul afisat e Eroare necunoscuta + SQL-ul brut + GETCALLSTACK() — corect functional, urat pentru utilizator. Priveste tot ROA, nu doar acest lant.

B. Al doilea punct de intrare (comun.vc2:2491, afisjurcom.do_modifica) — INCHIS

Suita: test_s5_al_doilea_intrare.prg. Log: test_s5_al_doilea_intrare_log.txt (rulare 10.08.2026, 01:29:51-01:29:52, a doua trecere — vezi „Corectie" mai jos). 17 PASS / 0 FAIL.

Reproduce integral secventa comun.vc2:2222-2569 (garzile, cursoarele notei, salvarea), mai putin partea de UI (gridul actjur, Createobject([frm_modific2024], lnIdSet) — sarit deliberat, risc de blocaj headless; verificarea vizuala ramane la Marius, per briefing). Pe aceeasi nota folosita de test_s5_scriere_reala.prg/test_s5_discount_valuta.prg (id_vanzare=1049) — singurul document de test cunoscut care are simultan rand real in VANZARI si nota in luna curenta (cerinta specifica a lui afisjurcom.do_modifica, comun.vc2:2265-2268, pe care do_editare_factura nu o are in aceeasi forma).

Diferenta functionala fata de primul punct de intrare, singura care conteaza pentru acest test: afisjurcom.do_modifica nu apeleaza IncarcaVanzareDinNota direct — apeleaza PregatesteArticoleFacturaEditare('tact') (comun.vc2:2436), care populeaza tvanz si crsArticoleFactura pe alta cale de cod. Dovedit REAL (nu static):

• PregatesteArticoleFacturaEditare gaseste documentul (.T.);
• garda noua (Used('tvanz') And Reccount('tvanz')=1) se satisface REAL prin aceasta cale;
• tvanz.id_vanzare corect (1049), crsArticoleFactura precarcat;
• blocul nou (comun.vc2:2491-2493) s-a executat (flag verificat direct in cod, nu prin scanare de log);
• lantul complet a reusit (lnSucces=1), tranzactia s-a inchis cu COMMIT (Thisform.do_inchide_tranzactie(Iif(lnSucces<0,2,1)), comun.vc2:2541) — spre deosebire de suita A, aici nu s-a provocat niciun esec, deci lantul chiar reuseste si comite, ca in fluxul real.

Fara nicio modificare de articole (ca blocul C din test_s5_discount_valuta.prg): COD s-a realocat (1140899 → 1140900, efect normal al finalizeaza_modificare_nota la orice salvare, chiar fara modificari), dar discount/totaluri/numar de linii active raman identice, verificat independent prin sqlplus dupa terminarea procesului.

Corectie facuta IN TIMPUL scrierii acestui test (nu a ajuns in fisierul final, dar a scris real in baza)

O prima varianta a testului apela ScrieArticoleFacturaEditate fara sa incarce intai tvd (in fluxul real, Load()-ul lui frm_modific2024 e cel care il populeaza din crsArticoleFactura — sarit aici deliberat). Garda EXTERNA (Used('tvanz') And Reccount('tvanz')=1) s-a satisfacut, dar garda INTERNA de no-op a helperului (!Used('tvd')) a transformat apelul intr-un no-op tacut (intoarce tot .T.) — fara sa corecteze reset-ul STERS=0 pe care pack_facturare.actualizeaza_vanzari il face pe TOT documentul (acelasi mecanism documentat in rec_s5_scriere_reala.md). Tranzactia a comis reset-ul necorectat: linia det=1582, definitiv stearsa in test_s5_scriere_reala.prg (09.08.2026), a fost reinviata real in Oracle (STERS: 1 → 0).

Reparat imediat, inainte de orice alta actiune: UPDATE vanzari_detalii SET sters=1 WHERE id_vanzare_det=1582; COMMIT;, verificat prin sqlplus ca restul coloanelor (cantitate, pret, pret_achizitie) au ramas neatinse. Varianta finala a testului incarca tvd cu IncarcaArticoleFactura(tnIdVanzare,'tvd') chiar dupa PregatesteArticoleFacturaEditare (ca Load()-ul formularului), deci helperul chiar corecteaza reset-ul — noua rulare confirma explicit, prin asertia 17, ca det=1582 ramane sters=1 dupa salvare. Consemnat in antetul suitei finale, ca precautie pentru cine reia/adapteaza testul.

Aceasta e o capcana de test (guard-ul !Used('tvd') functioneaza exact cum trebuie, prevenind un no-op periculos sa arunce eroare — problema a fost ca testul nu a reprodus fidel ce face UI-ul real inainte de acest punct), nu un defect de productie.

C. Liniile din seturi de articole (id_vanzare_set nenul)

Partea Oracle (agregarea pe seturi din recalculeaza_totaluri_vanzari) — NEACOPERIBILA pe datele curente, confirmat prin interogare, nu presupus:

select count(*) from vanzari v join vanzari_detalii vd on vd.id_vanzare=v.id_vanzare and vd.sters=0
 where vd.id_vanzare_set is not null
   and extract(year from v.data_act)=2026 and extract(month from v.data_act)=8;
-- 0 randuri

Cele mai recente documente cu linii de set active sunt din 2026-03 (id_vanzare=1027) si mai vechi — niciunul din luna curenta (august 2026), cerinta obligatorie a gardei de editare ((pnAn*12)+pnLuna = (gnAn*12)+gnLuna, verificata direct in suitele A si B de mai sus). Fara fabricare de date (interzisa explicit in briefing): golul ramane deschis, ca risc cunoscut, pana apare un document real editabil cu linii de set.

Partea helper VFP (ScrieArticoleFacturaEditate trateaza corect o linie cu id_vanzare_set nenul) — DEJA ACOPERITA, verificat prin recitirea suitei existente, fara munca noua necesara: test_s5_validari_articole.prg, sectiunea B1, randul 6 („componenta de set, pastrata" id_vanzare_set=999, det=558) — asertia „clasificare: exact 3 UPDATE (liniile pastrate 555/556/ 558, inclusiv nemodificata si componenta de set)" dovedeste ca helperul trateaza o linie cu id_vanzare_set nenul identic cu orice alta linie pastrata (UPDATE normal, fara ramura speciala in codul VFP — id_vanzare_set nu apare in nicio conditie din ScrieArticoleFacturaEditate, confirmat si prin citirea sursei). Nu era nevoie de mock nou.

Cifre PASS/FAIL, numarate din log

Suita	Cifra	Verdict
test_s5_rollback_real.prg (nou)	13 PASS / 0 FAIL	Rollback la esec partial: contract (mock) + stare DB (real, SQLEXEC)
test_s5_al_doilea_intrare.prg (nou)	17 PASS / 0 FAIL	Al doilea punct de intrare, executie reala prin comun.vc2:2491-2493
test_s5_validari_articole.prg (existent, doar recitit)	35 PASS / 0 FAIL (neschimbat)	Confirma acoperirea existenta pentru linia de set (B1/rand 6)

Date de test consumate

Pe id_vanzare=1049 (acelasi document folosit de toate suitele S5 anterioare):

• cod realocat: 1140898 → 1140899 → 1140900 (ambele din suita B — prima trecere, cu corectia de mai sus, apoi a doua trecere finala). Cine reia testele citeste cod-ul curent din VANZARI, nu-l presupune.
• Continutul liniilor si totalurile documentului raman identice cu starea de dinaintea acestei lucrari (verificat exhaustiv, prin sqlplus, dupa fiecare pas): det=1581/1583/1588 active cu aceleasi valori, det=1582 ramane sters=1.
• Suita A (rollback) nu a consumat nimic — ambele parti (mock si real) se inchid fara COMMIT.
• Zero linii noi ramase, zero tranzactii deschise, zero procese vfp9.exe ramase — verificat prin sqlplus/tasklist la finalul lucrarii.

Fisiere atinse

• COMUN\utile\Teste\editare_factura\test_s5_rollback_real.prg (nou)
• COMUN\utile\Teste\editare_factura\test_s5_al_doilea_intrare.prg (nou)
• Niciun fisier de productie (.vc2/.prg de aplicatie) atins. omodificari.vc2, ofacturare_comun.vc2, comun.vc2, ofacturare_editare.prg, COMUN\clase\ofacturare.vc2 — neatinse, conform interdictiei din briefing.

Diff (fisiere noi): diff aplicat (sters).