Files
roafacturare/docs/cercetare/handoff_s4_runda1.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

14 KiB

Handoff — S4 runda 1 (PAGE3 doar afisare), predare pe prag de context

Sesiune intrerupta la prag de context (monitorizare-context.md). Stare stabila si consistenta (text = binar), dar cu schele de diagnostic inca in cod — de scos inainte de livrare.

1. Ce am modificat, unde, si write-back-ul

Toate in COMUN (cross-proiect).

  • COMUN\programe\ofacturare_editare.prg — write-back N/A (e .prg, nu .vcx, se ruleaza direct). Antet actualizat (linia cu *!* helpere...) + doua functii noi, adaugate la coada fisierului:

    • IncarcaVanzareNota(tnCod, tnNract, tcSerieAct, tdDataAct) — gaseste randul din VANZARI corespunzator notei curente, in cursorul tvanz.
    • IncarcaArticoleFactura(tnIdVanzare) — incarca liniile active din VANZARI_DETALII (+ denumire articol/gestiune/valuta) in cursorul tvd. Fisier ASCII (fara diacritice), editat direct cu Edit tool — fara riscul de corupere cp1252.
  • COMUN\clase\omodificari.vc2 (clasa frm_modific2024) — text si binar SINCRONIZATE, ambele includ inca cod de diagnostic care trebuie scos:

    • PAGE3 nou pe pgfArticole (PageCount=3, PAGE3.Caption="Articole factura") — linia cu PageCount = 3, ; in blocul ADD OBJECT 'pgfArticole'.
    • Grid nou pgfArticole.PAGE3.grdArticoleFactura (13 coloane, RecordSource="tvd", ReadOnly=.T. la nivel de grid si pe fiecare Text1), plus intrarile OBJECTDATA corespunzatoare (cautabile dupa grdArticoleFactura).
    • Proprietati noi pe clasa: lAreArticoleVanzari, nIdVanzare, nTipVanzare (in blocul *<PropValue>, cautabile dupa lareaarticolevanzari/nidvanzare/ntipvanzare).
    • Load(): placeholder CREATE CURSOR tvd (...) daca nu e deja deschis — necesar, altfel grid-ul incearca USE tvd la constructie si pica pe dialog nativ "Open" (vezi sectiunea 4).
    • Show(): bloc nou (cautabil dupa This.lAreArticoleVanzari) care apeleaza IncarcaVanzareNota/IncarcaArticoleFactura si comuta pgfArticole.PageCount intre 2 si 3.
    • DE SCOS inainte de livrare: 5 linii STRTOFILE(...'diag_class.txt'...) inserate ca checkpoint-uri de depanare in Init() (3 linii: inceput, dupa DoDefault(), sfarsit) si Load() (2 linii: inceput, sfarsit) — cautabile dupa diag_class. Nu au efect functional (doar scriu intr-un fisier de log), dar nu trebuie sa ramana in cod livrat.
    • Fidelity check txt2vcx: OK la ultimul write-back (cel CU liniile de diagnostic inca in el). .vcx/.vct au mtime 12:10, exact dupa acel write-back — deci binarul reflecta exact .vc2-ul curent, inclusiv diagnosticul.

Backup-uri pe disc (COMUN\clase\)

Fisier Continut
omodificari.vc2.pre_s4runda1.bak Originalul, dinaintea oricarei modificari S4
omodificari.vc2.pre_diag.bak Versiunea mea curata (fara cele 5 linii de diagnostic) — asta e sursa de folosit pentru versiunea finala
omodificari.vc2.mine_s4_full.bak Identic cu pre_diag.bak (copie facuta in timpul unui test de izolare)
omodificari.vcx.mine_s4.bak / omodificari.vct.mine_s4.bak Binarul corespunzator lui pre_diag.bak, copiat direct (fara compilare) — restaurare instantanee

Pasul urmator recomandat: Copy-Item omodificari.vc2.pre_diag.bak -> omodificari.vc2, Copy-Item omodificari.vcx.mine_s4.bak -> omodificari.vcx (+ .vct) — restaurare instantanee (fara txt2vcx) la versiunea curata cu PAGE3 functional, fara schela de diagnostic. Verifica dupa aceea cu un diff ca omodificari.vc2 chiar nu mai contine diag_class.

2. Ce mai ramane din runda 1

Din sectiunea E / runda 1 a planului (A.2 PageCount + A.3 detectie + B.1 incarcare + B.2 marcaje):

  • A.2 (PageCount) — FACUT, testat static (fidelity OK), netestat live pe formular (vezi sectiunea 3 — blocaj de mediu, nu s-a ajuns sa vad PageCount pe formularul instantiat real).
  • A.3 (detectie) — FACUT, testat direct (fara UI) cu rezultate PASS pe date reale (sectiunea 3). Deviaza de la recomandarea planului (cauta si de ce, sectiunea 4).
  • B.1 (incarcare cursoare) — FACUT, testat direct, PASS.
  • B.2 (marcaje stare linii) — NU e in scope runda 1 (grid-ul e strict readonly, fara editare — marcajele _modificat/sters/id_vanzare_det=0 sunt pentru runda 2). Nu e inceput.

Ce lipseste efectiv: verificarea end-to-end ca, pe formularul REAL (Createobject('frm_modific2024')

  • .Show()), PageCount chiar ajunge 3 pe o factura si 2 pe o nota fara VANZARI — blocata de problema de mediu din sectiunea 3. Codul e scris si compilat curat; ramane doar confirmarea live.

3. Ce am testat, cu ce rezultat

Suita: COMUN\utile\Teste\editare_factura\test_page3_articole.prg (headless, vfp9.exe -A -T, conexiune reala MARIUSM_AUTO). Log: test_page3_articole_log.txt in acelasi folder.

PASS, pe date reale, testat direct (apel functie, fara formular):

  • cod=1140888 → IncarcaVanzareNota gaseste id_vanzare=1050, tip=1; IncarcaArticoleFactura incarca 4 linii — coincide exact cu baza de regresie din progres.md (TOTAL_CU_TVA=1924.59).
  • cod=1140885 → gaseste id_vanzare=1047, tip=-12 (nu e factura, e alt tip de document) — confirma ca detectia functioneaza pe orice tip din VANZARI, nu doar facturi (decizia 19).
  • cod=1125486 (an=2008, luna=2, notă contabila fara nicio legatura cu VANZARI) → 0 randuri gasite — cazul negativ cerut de criteriul de "gata" al rundei.
  • Coliziune pe cod=1139934 (patru randuri active in VANZARI, acelasi cod): filtrul compus (cod+nract+serie_act+data_act) gaseste EXACT randul cerut (nract=375/SSS → id_vanzare=882) si NU gaseste nimic pentru un nract fara corespondent (nract=13) — vezi sectiunea 4, e important.

NETESTAT live (formular real): verifica_pagecount_form (in acelasi fisier de test) instantiaza frm_modific2024 exact ca do_editare_factura (Createobject+Show) si verifica PageCount — se blocheaza intr-un dialog nativ VFP "View Parameter" in timpul Createobject, inainte sa apuce sa ruleze vreo linie din Show(). Vezi sectiunea 4 pentru diagnosticul facut si o pista noua, neexplorata inca, primita de la team-lead.

test_baseline_isolation.prg (in acelasi folder) — fisier temporar de diagnostic, se poate sterge dupa ce cineva confirma diagnosticul de mai jos independent; nu face parte din suita finala (antetul lui o spune explicit). L-am folosit ca sa demonstrez ca binarul ORIGINAL (dinainte de S4) NU are acest blocaj in acelasi mediu de test (PageCount=2, done, fara dialog) — deci problema e din diff-ul meu, nu un gol preexistent de mediu.

4. Descoperiri care nu trebuie pierdute

VANZARI.COD NU e unic — dovedit pe date, nu presupus

Contrar recomandarii A.3 din plan ("SELECT ... FROM vanzari WHERE cod = tact.cod"), am verificat direct pe MARIUSM_AUTO:

  • Indexul IDX_VANZARI_04 e pe (STERS, COD) si e NONUNIQUE — schema insasi nu garanteaza unicitate.
  • cod=1139934 are 4 randuri active (STERS=0) in VANZARI, cu TIP/NUMAR_ACT diferite (375/SSS, 24/PF, 25/PF, 26/PF). cod=1139555 are 2 randuri cu TIP diferit (43 si 1).
  • Filtrarea suplimentara pe NUMAR_ACT+SERIE_ACT+DATA_ACT (toate disponibile pe cursorul tact ca nract/serie_act/dataact, din vact_tot) rezolva ambiguitatea: (COD, NUMAR_ACT, SERIE_ACT, DATA_ACT) verificat fara nicio dublura pe toata tabela VANZARI.
  • ID_FACT (alternativa mentionata in progres.md — "toate legaturile trec prin ID_FACT sau ID_VANZARE, niciodata prin cod") nu e utilizabil ca filtru unic aici: e NULL pe o fractie mare de randuri chiar si pentru facturi normale (tip=1: 58 din 183 NULL; tip=51: 58 din 74 NULL), deci n-ar gasi avizele/tipurile fara facturare clasica — ar incalca decizia 19.

Concluzie aplicata in cod: IncarcaVanzareNota filtreaza pe cele 4 coloane compuse, nu doar pe cod. Aceasta e o corectie de fond fata de A.3 din plan, nu o improvizatie — sectiunea C.1 din plan_06_s4_proiectare.md ar trebui sa mentioneze asta daca cineva o rescrie.

Blocaj "View Parameter" la Createobject('frm_modific2024') — cauza NECONFIRMATA

Simptom: procesul vfp9.exe ramane blocat (CPU~0, Responding=True) intr-un dialog nativ "View Parameter" exact in timpul liniei Createobject([frm_modific2024], lnIdSet), inainte sa ajunga la orice linie din Show() — confirmat cu checkpoint-uri STRTOFILE in Init()/Load() (niciunul nu s-a scris, deci blocajul e chiar mai devreme decat Load(), sau checkpoint-urile nu s-au atins din alt motiv neexplicat).

Exclus cu dovezi (nu pierde timp re-verificand):

  • Nu e cursorul tvd lipsa — am incercat atat placeholder in Load(), cat si pre-creare in scriptul de test inainte de Createobject; blocajul a persistat identic.
  • Nu e un gol de mediu preexistent — binarul ORIGINAL (omodificari.vcx.mine_s4.bak restaurat temporar) ruleaza curat in ACELASI mediu de test (test_baseline_isolation.prg, PageCount=2, fara dialog). Deci e ceva din diff-ul meu.
  • Un blocaj anterior, diferit (File 'crsjtvatemp.dbf' does not exist, dialog "Open") era intr-adevar preexistent — cerut de Column63 din grdRulaje (PAGE1, cod netusat de mine), rezolvat in scriptul de test cu update_jtva_coloane("", "crsJtvaTemp", 0) inainte de Createobject (nu in clasa — e o lipsa de mediu de test, nu de productie: in productie, crsJtvaTemp e populat pe alte cai inainte sa ajunga un utilizator la acest formular).
  • Am citit _pageframe.Init() (_baza.vc2:514-523, itereaza For i = 1 To PageCount si cheama tradu(.Caption)) ca prim suspect — tradu() (oproceduri_comune.prg:1746) e confirmat inofensiv (doar STRTRAN pe diacritice, fara Oracle/View). Nu e cauza, dar ramane singurul cod DEPENDENT de PageCount gasit prin cautare in _baza.vc2/_frm_base.vc2/_grd_base.vc2.
  • Am cautat "CREATE SQL VIEW" / USE ... VIA in toata ierarhia de clase (omodificari, _baza, _frm_base, _grd_base, gridextras) — zero rezultate. Niciun view local gasit static.

Pista noua, neexplorata (primita de la team-lead, nu verificata de mine inca): dialogul "View Parameter" apare tipic cand o variabila referita prin ?variabila (SQL passthrough) sau intr-un view parametrizat e declarata LOCAL in loc de PRIVATE intr-un harness de test — LOCAL nu e vizibil in rutinele apelate. Exemplu citat: do_editare_factura declara Private pnAn, pnLuna, lnCod, lnIdFact, lnIdVanzare (ofacturare_comun.vc2:3742). Nu am apucat sa verific daca test_page3_articole.prg foloseste LOCAL unde codul original ar cere PRIVATE undeva in lantul IncarcaCursoareModificareNota/Createobject — e primul lucru de incercat inainte de a relua sapatul cu EnumWindows/PrintWindow (costisitor, ~15 cicluri de test in aceasta sesiune doar pentru asta).

5. Capcane de mediu platite in aceasta sesiune

  • Sterge intotdeauna .fxp-ul vechi inainte de fiecare rulare de test — m-a pacalit o data: am editat .prg-ul dar am uitat sa sterg .fxp, iar VFP a rulat tacut codul VECHI compilat, dand rezultate inconsistente intre rulari identice in aparenta. Simptom: log-ul arata alt comportament decat sursa curenta ar trebui sa produca.
  • FoxBin2Prg NU pastreaza ordinea textuala la scriere-citire (roundtrip) pentru ADD OBJECT multiple si proprietati custom — le REGENEREAZA in ordine proprie (alfabetica pentru coloane/obiecte fii, alta regula neclara pentru proprietati custom simple — nidvanzare a iesit INAINTEA lui nid_set, desi _ < v in ASCII). Fidelity-check-ul compara text-sursa cu text-regenerat, deci orice ordine "naturala" (alfabetica presupusa de mine) poate pica fidelity. Solutie aplicata: dupa primul fidelity FAIL, am adoptat ca sursa noua textul regenerat din <staging>\verify\*.vc2 (e deja in forma canonica), nu am incercat sa ghicesc ordinea corecta. Confirma exact indicatia din flux-editare-vfp-text.md.
  • InputMask cu literal (nu get_mask(...)) trebuie ghilimeluit ("9.99"), nu bar (9.99) — altfel VFP il interpreteaza numeric, nu ca string de format. Prins abia la inspectia manuala a textului regenerat, fidelity-check-ul NU l-a semnalat separat (a picat impreuna cu reordonarea).
  • Grid nou cu RecordSource pe un cursor care nu exista inca la constructia formularului → VFP incearca USE <recordsource> ca fisier fizic si arata dialogul nativ "Open" daca nu-l gaseste pe disc — exact acelasi tipar deja documentat in clasa pentru saft_taxtable/ saft_mecanisme_plati (Load(), verificat If !Used(...) inainte de orice altceva). Solutia e aceeasi: placeholder gol creat in Load(), INAINTE ca framework-ul sa construiasca grid-urile.
  • Query-uri Oracle multiple rulate manual (sqlplus) au fost esentiale pentru validarea empirica a filtrului compus pe VANZARI — nu s-ar fi descoperit coliziunea pe cod doar din cod static.

6. Ce recomand pentru urmatorul agent

  1. Restaureaza versiunea curata (sectiunea 1, pasul recomandat) — 2 copieri de fisier, fara compilare, verifica cu grep diag_class ca a disparut.
  2. Incearca pista LOCAL/PRIVATE din sectiunea 4 pe test_page3_articole.prg inainte de orice alta depanare GUI.
  3. Daca se rezolva: reruleaza test_page3_articole.prg complet, confirma PASS pe toate cazurile (inclusiv verifica_pagecount_form), sterge test_baseline_isolation.prg + .fxp + log-ul lui, scrie diff-ul (diff aplicat (sters), git diff --no-index <bak> <editat>) si raportul (docs\cercetare\rec_s4_runda1.md) cerute initial de team-lead.
  4. Daca team-lead sau alt agent scrie capcana "View Parameter / LOCAL vs PRIVATE" in testare-ui-vfp.md, nu o duplica — team-lead a intrebat explicit cine o scrie.