romfast/roafacturare
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b5a7108f34fce3ca78a00ece36dca2f65bda9641
roafacturare/docs/cercetare/rec_datoria6_baza_regresie.md
Marius Mutu b5a7108f34 docs: cercetarile comune trec in COMUN, reziduul #6 dispare, progres.md la zi 
Curatenie ceruta dupa inchiderea lui #6. Folderul cercetare\ NU se putea sterge
in bloc: plan_13 se sprijina pe el cu 85 de trimiteri, deci e baza de dovezi a
planului aflat in lucru. Impartirea:

- 14 cercetari trans-proiect trec in COMUN\docs\cercetare\ - valuta si curs,
  TVA/VANZARI, consumatorii VANZARI din toata suita, integrarile #10/#11/#12,
  watchdog VFP, proiectarea Oracle a lui S5, view-ul VVANZARI_ARTICOLE. Nu sunt
  ale ROAFACTURARE, iar #10/#11/#12 se reiau chiar din ele.
- 20 de rapoarte de executie ale lui #6, nereferite de nimic viu, sterse.
- 91 raman, neatinse.

Trimiterile catre handoff-urile si diff-urile intermediare deja desfiintate au
fost curatate peste tot (39 de fisiere): 50 catre handoff-uri, 37 catre diff-uri
aplicate, plus caile celor mutate in COMUN. Zero trimiteri rupte ramase.

progres.md preia rolul de predare: ce ramane din #6 (cele sase documente
parazite, cele doua esecuri reale din S8 pe factura din aviz), cifrele de test
citite din log, si cele doua capcane de mediu platite - .FXP vechi executat in
locul .prg-ului, si GETFONT() care atarna un formular instantiat fara goApp.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
2026-08-11 22:31:42 +03:00

11 KiB
Raw Blame History

Datoria 6 — ce s-a intamplat cu baza de regresie #6/S4 si cum a fost re-ancorata

09.08.2026. Schema MARIUSM_AUTO@ROA_CENTRAL. Strict citiri pe Oracle — nicio scriere, niciun commit.

1. Ce s-a intamplat cu documentul (dovada pe randuri)

Ipoteza de plecare se confirma: documentul nu s-a pierdut, i s-a realocat cod-ul. ID_VANZARE = 1050 exista, e activ si nu si-a schimbat niciun total — doar COD a trecut de la 1140888 la 1140895.

ID_VANZARE   COD      STERS  TIP  NUMAR_ACT SERIE  DATA_ACT     ID_FACT   TOTAL_CU_TVA
      1050   1140895      0    1        547 SSS    07.08.2026   8009660        1924.59
      1047   1140885      0  -12        544 SSS    07.08.2026   8009657         747.79
      1048   1140894      0    1        545 SSS    07.08.2026   8009658         302.51
      1049   1140887      0    1        546 SSS    07.08.2026   8009659         573.81

Pe intervalul 1140880-1140900 exista doar aceste 4 randuri; max(cod) in VANZARI e 1140895, max(id_vanzare) e 1050. Nu exista niciun rand pe cod = 1140888.

Nota contabila arata acelasi lucru — acelasi antet, acelasi total, doar STERS si COD diferite:

       COD    AN LUNA STERS   N  NRACT SERIE  DATAACT      ID_FACT   SUMA_TOT
   1140888  2026    8     1  24    547 SSS    07.08.2026   8009660    4836.67
   1140895  2026    8     0  24    547 SSS    07.08.2026   8009660    4836.67

24 de randuri vechi marcate STERS=1 pe cod vechi, 24 de randuri noi active pe cod nou, cu nract/serie_act/dataact/id_fact identice si aceeasi suma. Este exact semnatura lui finalizeaza_modificare_nota + pack_facturare.actualizeaza_vanzari(cod_vechi, cod_nou). VANZARI_DETALII pe id_vanzare = 1050 are in continuare 4 linii active — neatins, corect (scrierea in VANZARI_DETALII e S5, inca neimplementata).

Cand, pe secunda (ACT.DATAORAS = marcarea ca sters, ACT.DATAORA = crearea randului):

Actiune Moment
cod=1140893 marcat sters, cod=1140894 creat (id_vanzare=1048) 08.08.2026 09:16:29 / 09:16:30
cod=1140888 marcat sters, cod=1140895 creat (id_vanzare=1050) 08.08.2026 14:05:15 / 14:05:16

Deci nu testul de write-back aprobat a mutat documentul de regresie: acela a lucrat pe id_vanzare = 1048 dimineata la 09:16 (1140886 -> 1140893 -> 1140894, consemnat in progres.md). Mutarea lui 1050 e o a doua salvare, la 14:05, pe un alt document — cel folosit ca ancora de regresie. Nu exista in ACT niciun cod intermediar intre 1140888 si 1140895 (1140889-1140892 n-au randuri), deci a fost o singura realocare.

Nimic de recreat. Datele nu s-au pierdut; ancorarea suitelor era gresita. Prin urmare nu se cere nicio decizie de INSERT/UPDATE din partea lui Marius pe partea de date.

Ancorele celorlalte cazuri sunt neatinse: id_vanzare 1047 (cod=1140885), 506 (cod=1137874), 882 (cod=1139934) sunt toate active pe acelasi cod ca inainte — se realoca doar documentele care chiar se salveaza, adica cele din luna curenta, singurele care trec de garzile din do_editare_factura.

2. Cifrele masurate azi, inainte de modificare

Cifra din progres.md (7 PASS / 3 FAIL) era veche: numara doar cele 10 asertii de la runda 2, inainte ca blocul 3A sa adauge alte 5. Masurat azi, pe starea de pe disc:

Suita Inainte Dupa
test_page3_articole.prg 8 PASS / 7 FAIL (15 verificari) 13 PASS / 2 FAIL
test_incarca_vanzare_din_nota.prg 4 PASS / 1 FAIL 5 PASS / 5

Ambele rulari (inainte si dupa): exit code 0, 0 dialoguri native, sub COMUN\utile\Teste\watchdog_vfp.ps1 -AutoDismiss (care sterge .fxp-ul inainte de fiecare lansare). loForm.ClassLibrary e asigurat de blocul existent RELEASE CLASSLIB omodificari + SET CLASSLIB TO D:\ROA\ROAFACTURARE\COMUN\clase\omodificari.vcx, neatins de modificarea de fata.

Motivul concret al esecurilor: IncarcaCursoareModificareNota filtreaza STERS = 0, iar toate cele 24 de randuri ACT de pe cod=1140888 sunt STERS=1 — deci tact venea cu 0 randuri, iar suita nici nu ajungea sa instantieze formularul (PageCount = -1 in log).

3. Ce s-a schimbat in suite si de ce

Principiul aplicat e varianta 1 din brief: suitele isi descopera singure documentul de test, dupa proprietatea ceruta de asertie, nu dupa identitatea lui. Ancorarea pe cod era condamnata prin constructie (se realoca la fiecare salvare); ancorarea pe id_vanzare ar fi rezistat, dar tot cere un numar scris de mana intr-un fisier de test.

Fisier nou: COMUN\utile\Teste\editare_factura\descopera_caz_test.prg

DescoperaCazTest(<nume caz>, <alias>) lasa in alias un rand cu cod, an, luna, id_vanzare, tip, nlin si intoarce .T./.F. Sase cazuri, fiecare o proprietate:

Caz Proprietatea ceruta Rezolvat azi la
FACTURA_ARTICOLE tip=1 activa, cu linii active, a carei nota are primul rand (min(id_act)) pe acelasi (nract, serie_act, dataact) ca vanzarea cod=1140895, id_vanzare=1050, 4 linii
NEFACTURA_ARTICOLE la fel, dar tip <> 1 (decizia 19 — detectia merge pe orice tip) cod=1140885, id_vanzare=1047, tip=-12
FARA_RULAJE linii active + zero randuri in vrul_tot si vrul_obinv_tot cod=1140885, id_vanzare=1047
PRIM_RAND_ORB nota al carei prim rand NU duce la vanzare, dar un triplet ulterior da cod=1140401, id_vanzare=1005
COLIZIUNE_COD idem + cod cu 2+ randuri active in VANZARI + un triplet din nota fara corespondent cod=1139934, id_vanzare=882, nract fara corespondent = 13
NOTA_FARA_VANZARI nota activa fara rand in VANZARI pe niciun triplet cod=1140883, an 2026, luna 7

Doua lucruri contau la proiectare:

  • Independenta fata de codul testat. Interogarile merg pe VACT_TOT / VRUL_TOT / VRUL_OBINV_TOT / VANZARI / VANZARI_DETALII cu join direct, adica pe alt drum decat IncarcaVanzareNota / IncarcaVanzareDinNota / IncarcaArticoleFactura. Valoarea asteptata (id_vanzare, tip, numarul de linii) nu vine de la functia verificata, deci asertia nu devine tautologica.
  • Ordonare determinista (order by v.id_vanzare desc, respectiv an/luna/cod desc), ca doua rulari succesive pe aceleasi date sa aleaga acelasi document. Cazul ales e scris in log la inceputul fiecarei rulari, ca sa se vada pe ce document s-a masurat.
  • Nicio potrivire = FAIL explicit, nu test sarit: caz_negasit scrie in log niciun document din schema nu satisface conditia cazului + FAIL.

Interogarile au fost validate intai direct in sqlplus (fiecare intoarce documentul asteptat), abia apoi puse in cod.

test_page3_articole.prg

Toate cele sase documente hardcodate (1140888, 1140885, 1125486, 1139934, 1137874) au fost inlocuite cu cazul descoperit corespunzator. Structura asertiilor e neschimbata; procedurile de verificare si-au pastrat corpul, doar au primit prin parametru ce inainte era scris in ele:

  • verifica_coliziune_cod primea zero parametri si continea 1139934 / 375 / 'SSS' / 31.12.2021 si nract=13; acum primeste cod, tripletul care trebuie gasit, id_vanzare asteptat si tripletul complet care nu trebuie gasit. Descoperirea intoarce cele trei coloane ale randului negativ de pe acelasi rand (keep (dense_rank first order by nract)), ca sa nu se combine nract-ul unui rand cu serie_act-ul altuia — altfel asertia negativa ar fi trecut din alt motiv decat cel testat.
  • O asertie s-a intarit, niciuna nu s-a slabit. Cazul B (tip <> 1) trecea inainte cu tnLiniiAsteptate = -1, adica verificarea numarului de linii era dezactivata; acum primeste numarul real din VANZARI_DETALII (2) si il verifica.

test_incarca_vanzare_din_nota.prg

Aceleasi patru cazuri, plus cazul EOF, trecute pe descoperire. Nicio schimbare de asertie.

4. Ce a ramas neacoperit

Doua asertii din blocul 3A raman FAIL, si NU din cauza datelor — sunt artefactul de mediu deja consemnat ca datoria 7 in progres.md:

EROARE 1925 [VERIFICA_EDITARE_GRID:353] Unknown member COLUMN5.
  structura grid/cursor (ColumnCount=14, lmodificat L, valoare N) = FAIL
  ReadOnly (cantitate/pret/pret_cu_tva editabile, checkbox pe pret_cu_tva, restul readonly) = FAIL
  stare initiala (lmodificat=.F., valoare calculata corect) = PASS
  dupa editare cantitate (lmodificat=.T., valoare recalculata) = PASS

Sub vfp9.exe -A -T grid-ul nu se materializeaza: ColumnCount raporteaza 0 si ColumnN nu exista ca membru, oricat de complet ar fi definita clasa. Repartitia 2 FAIL (structura, ReadOnly) / 2 PASS (cursor, calcul) e exact cea prezisa in progres.md, datoria 7 — deci suita e acum inapoi la starea ei dinaintea degradarii bazei, nu mai bine si nu mai rau.

Cele doua asertii nu au fost atinse, slabite sau sterse. Ele sunt oricum acoperite corect pe ecran de COMUN\utile\Teste\editare_factura\test_ui_fix_editabil_subtotal.prg sub vfp_ui_harness.ps1 (11/11 PASS, ColumnCount=14, consemnat in progres.md). Daca se doreste curatarea zgomotului, varianta corecta e cea deja propusa la datoria 7 — rescrierea lor ca verificare statica pe memo-ul Properties din .vcx — dar asta e alta lucrare, nu re-ancorare.

Altele:

  • Nu s-a verificat comportamentul suitelor pe alta schema decat MARIUSM_AUTO. Descoperirea e scrisa sa mearga pe orice schema, dar nu a fost probata pe ROMFAST sau VENDING.
  • Cazurile PRIM_RAND_ORB si NOTA_FARA_VANZARI se rezolva azi la alte documente decat inainte (1140401 in loc de 1137874, 1140883 in loc de 1125486) — proprietatea testata e insa aceeasi, iar ambele trec. Vechile documente raman valide, doar ca nu mai sunt primele in ordinea determinista.
  • Nu s-a atins nimic din omodificari.vc2, ofacturare_comun.vc2, ofacturare_editare.prg sau binarele lor. git status in COMUN confirma: singurele fisiere de test schimbate sunt cele doua suite plus fisierul nou.

5. Fisiere

Fisier Stare
COMUN\utile\Teste\editare_factura\descopera_caz_test.prg nou
COMUN\utile\Teste\editare_factura\test_page3_articole.prg modificat
COMUN\utile\Teste\editare_factura\test_incarca_vanzare_din_nota.prg modificat
diff aplicat (sters) diff-ul celor trei

Comenzile de rulare:

powershell -ExecutionPolicy Bypass -File D:\ROA\ROAFACTURARE\COMUN\utile\Teste\watchdog_vfp.ps1 -Script 'D:\ROA\ROAFACTURARE\COMUN\utile\Teste\editare_factura\test_page3_articole.prg' -AutoDismiss -TimeoutSec 300
powershell -ExecutionPolicy Bypass -File D:\ROA\ROAFACTURARE\COMUN\utile\Teste\watchdog_vfp.ps1 -Script 'D:\ROA\ROAFACTURARE\COMUN\utile\Teste\editare_factura\test_incarca_vanzare_din_nota.prg' -AutoDismiss -TimeoutSec 240

Logurile: ..._log.txt langa fiecare suita; rezumatul watchdog-ului in COMUN\utile\Teste\editare_factura\watchdog_out\.