roafacturare/docs/handoff_r6_r7_sincronizare.md

Handoff — runda 6 (punctul 6) + runda 7 (sincronizare articole-rulaje)

Scris 20.08.2026, seara. Sesiunea principala a trecut de pragul de context. Numai stare, fara analize noi.

Stare periculoasa — citeste asta prima

• Nimic nu e comis. Nici SVN, nici git, nici in COMUN. Marius a decis explicit: un singur commit, dupa ce sunt gata toate trei lucrarile (punctul 6 + cele doua cereri de runda 7). Punctul 6 e gata si probat, dar asteapta.
• COMUN\clase\omodificari.vc2 si COMUN\programe\ofacturare_editare.prg erau, la scrierea acestui fisier, in lucru la subagentul r7-sincronizare. Verifica pe disc mtime + git status in COMUN inainte sa presupui ceva; nu porni un al doilea scriitor pe ele.
• roafacturare.PJT / .PJX / .exe apar modificate in svn status. Nu sunt ale noastre — vin din sesiunea de VFP a lui Marius. Decizia lui: se lasa asa, nu se comit, nu se reverteaza.

1. Punctul 6 — TERMINAT, verificat, necomis

Explicatia TVA in dialogul de modificare a articolului deschis din frm_facturi.

Cod, pe numerotarea finala (COMUN\clase\ofacturare_comun.vc2):

ce	unde
data_act + id_part puse pe poRec din antetul crsfacturi	frm_facturi.do_modifica_explicatie, :4650-4651
layout: Height 370->431, randul cbo_saft coborat, obiecte noi _shape4 / lbExplTva / cbo_expl_tva / lbExplTvaInfo	frm_modifica_articol_factura, :5140-5300
proprietatea nidjtvaales (+ intrarea *p:, obligatorie)	:5147, :5158
popularea combo-ului, filtrata	Init, :5328-5360
filtrul SQL	:5340-5342
derivarea taxcode	cbo_expl_tva.InteractiveChange
al 5-lea parametru pozitional, literal null cand combo-ul n-a fost atins	inainte_de_do_termin
Destroy inchide crsExplTvaCbo + crsExplTvaArt	in aceeasi clasa

Write-back FACUT si dovedit (nu prin mtime): reconversie binar -> text intr-un cache temporar, diff 0 linii, md5 identic. Binar la 19:59. Encoding: 13 octeti >0x7F, zero EF BF BD, CRLF pe toate liniile; octetul diacritic din lbExplTva.Caption e 0xFE (cp1250), verificat citind din binar.

Probat pe ecran de Marius, de doua ori (a doua oara dupa corectia de filtru). E OK.

Ce s-a stabilit — nu se redeschide

• Filtrul listei: id_jtva_coloana > 0 AND afisat > 0 AND jv = 1 AND cota_tva = <cota liniei>. Verificat pe date in vjtva_coloane (MARIUSM_AUTO, 197 randuri cu id > 0): afisat = 0 sunt liniile de TVA, afisat = 1 bazele cu cota, afisat = 2 neimpozabilele. jv = 1 tine afara explicatiile de achizitie, care altfel treceau de garda FACT-029 (au aceeasi cota). Acelasi filtru pe care il foloseste emiterea (ofacturare.prg:170).
• NU se preia si restrictia pe cote_tva de an/luna curenta din update_jtva_coloane: ar goli lista la editarea unei facturi vechi cu cota iesita din uz (24%).
• neexigibil = .F. (parametru omis), la fel n50/n100. Nu e presupunere: emiterea foloseste GetTaxCode(gnAn, gnLuna, ldDataAct, lnIdJtva, .F.) cu ultimii trei impliciti (ofacturare.vc2:2529 si :3101), iar pe jurnal de vanzari GetTaxCodeIdPart degenereaza exact in acel apel.
• crsDetalii nu are data_act/id_part; vin din randul curent din crsfacturi, care e chiar antetul liniei editate (ofacturare_comun.vc2:3621-3623).
• Combo-ul nu are ControlSource — valoarea se preia in InteractiveChange, ca sa se poata distinge "userul a atins combo-ul" de "nu l-a atins" (al doilea caz trimite null si lasa procedura PL/SQL pe ramura veche).
• Ordinea de tab: Ed_tx_simplu1=1, cbo_expl_tva=2, cbo_saft=3, BUT_TERMIN1=4, But_renunt1=5, Lb_titlu_alb_b121=6, lbSaft=7, lbExplTva=8.

Oracle — nimic de facut

ff_2026_08_20_02_COMUN_PACK_FACTURARE.sql era deja aplicat pe schema MARIUSM_AUTO de pe ROA_CENTRAL, contrar notei "NERULAT" din rapoartele vechi. Dovezi: rand 20.08.2026 / seq 2 / COMUN_PACK_FACTURARE in VERSIUNE; PACKAGE + PACKAGE BODY VALID, last_ddl_time 13:56:38; sursa vie din ALL_SOURCE identica cu fisierul de pe disc, 0 linii diferenta pe 16 407. Nu se re-aplica ff_2026_08_20_01 — ar sterge punctul 6.

2bis. ACTUALIZARE 20.08.2026 20:40 - starea reala pe disc, dupa oprirea subagentului

Sesiunea subagentului r7-sincronizare a fost inchisa din greseala, inainte sa scrie raport. docs\raport_r7_sincronizare.md nu exista. Starea de mai jos e citita direct de pe disc, nu dintr-un raport.

STARE PERICULOASA: text editat FARA write-back

fisier	text	binar	concluzie
COMUN\clase\omodificari.vc2	20:35	.vcx/.vct la 14:08	modificarea NU exista in binar, deci nu exista in aplicatie
COMUN\programe\ofacturare_editare.prg	20:33	-	.prg, nu are nevoie de write-back
COMUN\clase\ofacturare_comun.vc2	19:59	19:59, diff 0 linii	punctul 6, sincronizat si verificat

vfp9.exe nu ruleaza - lock-ul e liber, write-back-ul se poate face oricand.

M1 - facut pe text, corect

Blocul "al doilea punct de declansare" a disparut din frm_modific2024.inainte_de_do_termin (0 potriviri pe comentariu). AfiseazaDialogSincronizareArticole() mai are un singur apelant, omodificari.vc2:16665, adica butonul. Corect. Ramane de facut write-back-ul.

M2 - facut pe text, dar DEPASESTE perimetrul aprobat

AplicaModificareTrul (ofacturare_editare.prg) calculeaza si scrie acum: pretv, pretvtva, tvav (cerute) plus valoarev, valtvav, valoarevcTVA - pe care Marius le-a respins explicit: sincronizarea e intre cantitate si preturi, nu valori. Subagentul a apucat sa aplice varianta initiala a brief-ului; corectia de perimetru nu a mai ajuns la el.

De facut in sesiunea urmatoare, in aceasta ordine:

1. Scoate din AplicaModificareTrul cele trei campuri de valoare din REPLACE si cele trei linii care le calculeaza (lnValoarecTVA, lnValoareTVA, lnValoareFtva), plus lnCantitate daca ramane nefolosit. Raman pretv, pretvtva, tvav. Verifica si LOCAL-urile declarate, si comentariul-antet al lui AplicaSincronizareArticole.
2. Write-back pe omodificari.vc2 (txt2vcx.ps1 -TextFile ... -AllowComun), apoi dovada prin reconversie cu vcx2txt.ps1 intr-un cache temporar si diff - trebuie 0 linii.
3. Ruleaza cele doua suite (vezi mai jos), o suita per apel, cu .fxp sters inainte.
4. Raspunde la intrebarea de fapt ramasa deschisa (cine recalculeaza valoarev/valtvav/valoarevcTVA dupa sincronizare) - doar raspuns, fara reparatie.
5. Adauga cele doua puncte in changelog, regenereaza docs\diff_r6_punct6.md si cere aprobarea de commit.

Nimic nu a fost testat: cele doua suite nu au fost rulate.

2. Runda 7 — IN LUCRU la subagentul r7-sincronizare

Brief executabil, cu liniile si formula: docs\brief_r7_sincronizare.md. Raportul lui va fi la docs\raport_r7_sincronizare.md.

M1 — sincronizarea articole-rulaje porneste doar din buton. Se sterge blocul "al doilea punct de declansare" din frm_modific2024.inainte_de_do_termin, omodificari.vc2:14484-14494. Butonul pgfArticole.PAGE3.cmdSincronizeazaArticole.Click (:16671) ramane singura cale. Dupa stergere raman fara consumator metoda SemnaturaDivergenteSincronizare (:14840), proprietatea cSemnaturaSincronizare si atribuirea de la :14956 — se semnaleaza, nu se sterg.

M2 — AplicaModificareTrul (ofacturare_editare.prg:924) scrie azi doar cant/cante si pretvtva; trebuie sa scrie si pretv, si tvav.

• Perimetru corectat de Marius: DOAR pretv si tvav. Versiunea initiala a brief-ului cerea si valoarev/valtvav/valoarevcTVA — respinsa: sincronizarea e intre cantitate si preturi, nu valori. Nu o reintroduce.
• Intrebare de fapt inca deschisa, ceruta subagentului, fara modificare de cod: cine recalculeaza valoarev/valtvav/valoarevcTVA pe randul trul dupa sincronizare, inainte de scrierea in Oracle? Trei concluzii posibile — le recalculeaza cineva / le recalculeaza salvarea / nu le recalculeaza nimeni si ajung vechi in Oracle. In ultimul caz se raporteaza ca defect, nu se repara; decide Marius.
• Formula canonica, de reutilizat, nu de reinventat: omodificari.vc2, calculeaza_valori_rul, ramura pretvtva, :13566-13587. Doua precizii diferite: gnPPretV pentru preturi, gnPC pentru valori.
• calculeaza_valori_rul nu se poate apela direct din sincronizare: isi alege cursorul din This.pgfArticole.ActivePage (:13532-13533) si nimereste trul doar cand pagina activa e 1; sincronizarea porneste de pe pagina 3, deci ar scrie in trul_obinv.

Teste obligatorii pentru runda 7

COMUN\utile\Teste\editare_factura\test_s4b_sincronizare.prg (42 cazuri, sectiunea C e chiar directia ARTICOLE_SURSA) si test_s4b_dialog.prg (35 cazuri). Reguli: sterge .fxp-ul inainte de fiecare rulare; o singura suita per apel de comanda; cifra se ia numarand PASS/FAIL din log, iar dovada ca rularea a ajuns la capat e linia de REZULTAT (care contine ea insasi cuvintele PASS si FAIL — un Select-String naiv raporteaza cu unu mai mult din fiecare).

3. Changelog

changelog_roafacturare.txt — intrarea rundei 6 e scrisa, in blocul existent 2.11.15, data mutata la 20/08/2026. Versiunea nu se bifurca cat timp #6 nu e in productie (decizia lui Marius, commit 09f9d47).

Ramas de adaugat, dupa ce runda 7 e gata: sincronizarea porneste doar din buton, si copierea pretv/tvav in rulaj.

4. Ce se comite, cand vine aprobarea

SVN (sursa de adevar), tintit — pe binare, niciodata pe .vc2/.sc2:

• COMUN\clase\ofacturare_comun.vcx + .vct
• COMUN\clase\omodificari.vcx + .vct (dupa runda 7)
• COMUN\programe\ofacturare_editare.prg (dupa runda 7)
• changelog_roafacturare.txt
• docs\progres.md

Nu: roafacturare.PJT / .PJX / .exe. Imediat dupa svn commit -> roa_sync.bat, si se raporteaza revizia SVN si ce a intrat pe main. Fisierele noi din docs\ sunt doar in git.

Diff-ul pentru aprobare, deja generat pentru punctul 6: docs\diff_r6_punct6.md (contine si rationamentul filtrului, cu cifrele pe date). Trebuie regenerat dupa ce intra runda 7.

5. Capcane de mediu platite in aceasta sesiune

• python <<EOF si python -c "..." nu executa nimic prin tool-ul Bash de pe masina asta — exit 0, zero efect, fara eroare. Scrie scriptul intr-un fisier si ruleaza-l pe cale absoluta. Pentru .vc2 foloseste mod binar ('rb'/'wb'): e CRLF peste tot si cp1250 pe diacritice.
• txt2vcx.ps1 are parametrul -TextFile, nu -Source (vcx2txt.ps1 are -Source). Ambele au nevoie de -ProjectRoot si -CacheRoot date explicit pentru acest proiect.
• Write-back-ul esueaza cat timp ruleaza vfp9.exe — tine .vcx/.vct exclusiv. Se verifica cu Get-Process vfp9 inainte. Procesul e al lui Marius: nu se omoara, se cere inchiderea.
• Un subagent poate raporta idle si apoi sa scrie in fisier. S-a intamplat; era sa produca doi scriitori pe aceeasi metoda. Verifica mtime/md5 pe disc inainte sa preiei un fisier, si spune-le explicit sa nu raporteze idle cu lucru in curs.
• svn status cere --depth sau atentie la externals: COMUN apare ca X (external), iar starea lui se vede separat.

---

ACTUALIZARE FINALA 20.08.2026 22:40 — toate cele trei lucrari sunt gata

Pasii 1-5 din lista de mai sus sunt executati. Handoff-ul de mai sus ramane ca istoric; starea curenta e cea de aici.

1. Perimetrul M2 corectat — valoarev/valtvav/valoarevcTVA scoase din AplicaModificareTrul, impreuna cu lnValoarecTVA/lnValoareTVA/lnValoareFtva/lnCantitate si cu LOCAL-urile si comentariile-antet ale ambelor functii. Raman pretv, pretvtva, tvav.
2. Write-back pe omodificari.vc2 FACUT si dovedit — nu mai exista fisier editat fara binar. Prima incercare a picat la fidelity check: subagentul lasase linia 14485 goala in loc de \t\t. Restaurata. Dovada pe binarul din proiect: md5 d23691466b7017380fe36099943b3208, diff 0 linii.
3. Ambele suite rulate: test_s4b_sincronizare 44/0, test_s4b_dialog 35/0. A fost nevoie de o corectie de fixture (gnPPretV, coloanele pretv/tvav in cursorul trul) plus un caz nou cu TVA 19% — detalii in docs\raport_r7_sincronizare.md.
4. Intrebarea de fapt: raspunsa — nu le recalculeaza nimeni; VALOAREV/VALTVAV ajung invechite in Oracle, VALOAREVCTVA nu e coloana in RUL. Raportat ca defect, nereparat.
5. Changelog completat (2 randuri in :modificare:, blocul 2.11.15) si diff regenerat ca docs\diff_r6_r7_pentru_commit.md (inventarul intregului commit; docs\diff_r6_punct6.md ramane ca rationament detaliat al punctului 6).

Nimic nu e intr-o stare periculoasa

• Niciun fisier editat fara write-back. Nicio tranzactie deschisa. vfp9.exe nu ruleaza.
• Nimic nu e comis — nici SVN, nici git, nici in COMUN. Se asteapta aprobarea pe docs\diff_r6_r7_pentru_commit.md, apoi svn commit tintit + roa_sync.bat.
• roafacturare.PJT/.PJX/.exe raman modificate din sesiunea de VFP a lui Marius: nu se comit.