roafacturare/docs/propunere_runda6_grid_articole_ux.md

Propunere runda 6 - grid Articole: nomenclatoare, zecimale, aspect, meniu, buton frm_facturi

Stare: diagnostic incheiat, nimic aplicat. Cele sase semnalari din proba pe ecran din 20.08.2026 sunt diagnosticate cu dovada pe cod. Fiecare punct de mai jos are cauza, interventia propusa si ce anume trebuie sa decizi.

Cercetari de sprijin: docs\cercetare\rec_r6_nomenclatoare_grid.md, docs\cercetare\rec_r6_zecimale_si_aspect_grid.md, docs\cercetare\rec_r6_meniu_editare_factura.md, docs\cercetare\rec_r6_buton_modificare_frm_facturi.md.

---

Cum functioneaza de fapt gridul de Articole azi

Miezul, verificat direct pe cod - fara asta punctele 1, 2 si 4 par contradictorii:

Cinci coloane au nomenclator (GotFocus + InteractiveChange), enumerate din COMUN\clase\omodificari.vc2:

Coloana	ControlSource	GotFocus	InteractiveChange
cDenumireArt (articol)	tvd.denumire	:16705	:16710
cGestiuneArt	tvd.gestiune	:16734	:16739
cTaxcodeArt	tvd.taxcode	:16810	:16815
cValutaArt	tvd.valuta	:16821	:16826
cExplicatieTvaArt	expresie (vezi mai jos)	:16722	:16728

Toate cinci au Text1.ReadOnly = .T.. Asta nu e o greseala: mecanismul se sprijina fix pe ea. Intr-un grid VFP, cand celula curenta e read-only si coloana e legata de un camp real, tastarea declanseaza cautarea incrementala a gridului, care schimba Value, ceea ce declanseaza InteractiveChange, care deschide nomenclatorul. Asa merge taxcode la tastare.

cExplicatieTvaArt e singura exceptie, si de aici vine punctul 1:

omodificari.vc2:12467
Column16.ControlSource = "Iif(Seek(Nvl(tvd.id_jtva_coloana,0),'crsJtvaTemp','id_jtva'),crsJtvaTemp.denumire,'')"

Coloana afiseaza denumirea din crsJtvaTemp, deci e legata de o expresie, nu de un camp. Nu exista camp pe care sa se faca seek, deci Value nu se schimba niciodata la tastare, deci InteractiveChange nu porneste. Nu e o garda gresita si nu lipseste nicio ramura din dispecer - e o consecinta structurala a felului in care coloana isi ia textul.

Butonul lateral Modificare ocoleste complet problema fiindca nu citeste ControlSource, ci Thisform.pccontrol, pe care GotFocus il pune explicit:

omodificari.vc2:16722-16726
PROCEDURE ... cExplicatieTvaArt.Text1.GotFocus
    *!* coloana afiseaza denumirea din crsJtvaTemp, deci ControlSource e expresie - campul editat se da explicit
    Thisform.pccontrol = 'tvd.id_jtva_coloana'
    Thisform.pncolumnorder = This.Parent.ColumnOrder

De aici rezulta fixul care rezolva punctele 1 si 2 dintr-o singura miscare: DblClick se sprijina si el pe pccontrol, deci merge uniform pe toate cele cinci coloane, inclusiv pe explicatie TVA, unde tastarea nu are cum sa mearga niciodata.

---

Punctul 1+2 - dublu-click pe toate nomenclatoarele

Cauza: DblClick nu exista deloc pe grdArticoleFactura azi. Explicatie TVA n-are nici calea de tastare, din motivul de mai sus.

Interventia propusa: cinci metode noi DblClick, cate una per coloana cu nomenclator, pe controlul din coloana (<coloana>.Text1.DblClick, nu pe coloana), cu corp identic - acelasi corp de trei linii ca InteractiveChange-urile existente:

PROCEDURE pgfArticole.PAGE3.grdArticoleFactura.<coloana>.Text1.DblClick
    Local loEditor
    loEditor = Createobject('ArticoleNotaEditor', Thisform)
    loEditor.ModificaNomenclator(Thisform.pccontrol)
ENDPROC

Nimic de schimbat in dispecer. pccontrol e deja corect la momentul dublu-click-ului: primul clic da focusul si declanseaza GotFocus, al doilea completeaza DblClick.

Efect: explicatie TVA capata in sfarsit o cale din grid (dublu-click), iar celelalte patru capata a doua cale, pe langa tastare.

De decis: nimic - e curat si aditiv. Confirma doar ca vrei si pe cDenumireArt (articol), nu doar pe cele patru mici.

---

Punctul 3 - trei zecimale la Pret

Aici formularea ta era aproape exacta, dar cu variabila inversata, si asta e chiar defectul.

Coloana este deja controlata de o variabila globala:

omodificari.vc2:12391   Column6.InputMask = (get_mask(12,gnPPRET))    && cPretArt = tvd.pret
omodificari.vc2:12400   Column7.InputMask = (get_mask(12,gnPPRET))    && cPretAchizitieArt

Ambele coloane primesc gnPPret. Dar gnPPret e precizia pretului de achizitie (=3 in mediul investigat, OPTIUNI.PPRET), iar tvd.pret e pretul de vanzare al liniei, a carui precizie e gnPPretV (oinit_optiuni.prg:515: Store 0 To gnPPretV && nr. de zecimale pret vanzare).

Regula e consecventa in restul suitei, si se vede pe doua coloane vecine in acelasi fisier:

ofacturare.vc2:3490   Column5.InputMask = (get_mask(14,gnPPret))     && "pret"  = achizitie
ofacturare.vc2:3497   Column6.InputMask = (get_mask(14,gnPPretV))    && "pretv" = vanzare

Chiar scrierea in Oracle a coloanei VANZARI_DETALII.PRET - aceeasi din care se umple tvd.pret - foloseste gnPPretV:

ofacturare_stoc.prg:367
Alltrim(Str(poArticol.Pret,18,Iif(poDate.in_valuta = 1,gnPVal,gnPPretV)))

Cauza: la scrierea sectiunii de grid s-a copiat masca de la coloana de achizitie pe coloana de vanzare de langa ea.

Interventia propusa: omodificari.vc2:12391, get_mask(12,gnPPRET) -> get_mask(12,gnPPretV). O singura linie.

Doua lucruri conexe, de decis separat:

• cPretCuTvaArt (omodificari.vc2:12404-12409) n-are deloc Format/InputMask, deci afiseaza precizia bruta a cursorului (4 zecimale), necontrolata de nimic. Il aliniem la gnPPretV in aceeasi runda, sau il lasam?
• Linia din ofacturare_stoc.prg:367 arata ca pe documentele in valuta precizia corecta e gnPVal, nu gnPPretV. InputMask de pe coloana se evalueaza o singura data, la instantierea clasei, cand moneda documentului inca nu e cunoscuta in acel context - deci o masca fidela pe ambele cazuri ar cere setare la runtime, in Init, dupa ce se stie in_valuta. Recomand sa NU intram acum: e o rafinare separata, iar simptomul pe care l-ai vazut se rezolva complet cu schimbarea de o linie. Semnalez doar ca ramane o inexactitate cunoscuta pe facturile in valuta.

---

Punctul 4 - fundalul gri

Aici concluzia e in doua parti, si a doua e mai serioasa decat pare din enunt.

Conventia de culoare exista deja in aplicatie, si chiar in acelasi formular, pe pagina Rulaje:

Aspect	Semnificatie	Exemplu
alb 255,255,255 + ReadOnly=.F.	se scrie direct, prin tastare	grdRulaje.cPret.Text1, :9990
verde 160,255,205 + ReadOnly=.F.	se editeaza, dar prin dialog/nomenclator	grdRulaje.cGest.Text1, :9689; cDenumire.Text1, :9595
gri 225,225,225 + ReadOnly=.T.	nu se editeaza	-

4a. Cele cinci coloane cu nomenclator sunt colorate gresit

cDenumireArt, cGestiuneArt, cTaxcodeArt, cValutaArt, cExplicatieTvaArt au toate BackColor = 225,225,225 (gri) desi au editor. Omologul direct al lui cGestiuneArt de pe pagina Rulaje (cGest, acelasi tipar GotFocus/InteractiveChange/ArticoleNotaEditor) e verde. Deci acelasi mecanism functional e colorat diferit in doua pagini ale aceluiasi formular.

Interventia propusa: cele cinci trec pe verde 160,255,205.

Recomand sa NU atingem Text1.ReadOnly pe ele, desi pe Rulaje verdele vine cu ReadOnly=.F. Motivul: pe Articole, calea de tastare merge tocmai fiindca sunt read-only (cautarea incrementala). Ai probat-o azi pe taxcode si functioneaza. Daca le facem .F., tastarea ar scrie direct in celula in loc sa declanseze cautarea - alt comportament, netestat, cu risc de a scrie gunoi in tvd.taxcode. Verdele singur spune adevarul si nu misca nimic functional.

4b. Serie, lot si explicatie NU sunt editabile azi - griul spune adevarul

Asta e partea care nu se potriveste cu ce ai scris, si cred ca e o bucata neterminata din runda 5.

Aceste trei coloane au Column.ReadOnly = .F. si o garda .When relaxata in runda 5 (cSerieArt :16804, cLotArt :16745, cExplicatieArt :16716 - toate IF lArticoleReadOnly OR id_vanzare_set <> 0 -> RETURN .F.). Dar controlul din coloana a ramas neatins:

omodificari.vc2:12734-12743   cSerieArt.Text1       BackColor = 225,225,225   ReadOnly = .T.
omodificari.vc2:12631-12640   cLotArt.Text1         BackColor = 225,225,225   ReadOnly = .T.
omodificari.vc2:12569-12578   cExplicatieArt.Text1  BackColor = 225,225,225   ReadOnly = .T.

Comparatie de control, pe o coloana pe care sigur o editezi:

omodificari.vc2:12485-12494   cCantitateArt.Text1   BackColor = 255,255,255   ReadOnly = .F.

Nu au nici cale prin buton: but_modificaR se activeaza in AfterRowColChange (:16678-16682) doar cand Thisform.pncolumnorder = nColIndex, iar pncolumnorder se scrie exclusiv in GotFocus - care exista doar pe cele cinci coloane cu nomenclator. Pe serie/lot/explicatie butonul ramane dezactivat.

Deci: garda a fost relaxata in runda 5, dar campurile au ramas read-only. Nu se pot edita pe nicio cale. Griul e onest; intentia din runda 5 e cea neimplinita.

Interventia propusa: cele trei trec pe alb 255,255,255 + Text1.ReadOnly = .F., ca cCantitateArt. Abia atunci devin editabile prin tastare, cum s-a decis in runda 5.

De decis - e o schimbare reala de comportament, nu cosmetica: confirmi ca serie, lot si explicatie trebuie sa devina scriabile direct in celula pe liniile deja salvate? (Garda .When existenta ramane si continua sa blocheze liniile din seturi si facturile intrate in e-Factura.)

---

Punctul 5 - textul din meniu

Eticheta nu e in .mnx - cautarea in toate meniurile proiectului n-a gasit-o. E un literal intr-o metoda, deci se poate schimba prin text + write-back, fara interventie manuala in IDE:

COMUN\clase\ofacturare_comun.vc2:4930
lnOptiune = xmenu('Modificare \<date factura;Editare \<factura (articole, cantitati, preturi)')

Interventia propusa: a doua optiune devine Editare \<factura (note, rulaje, articole), cu acceleratorul \<F pastrat.

ToolTipText = "Modificare (CTRL+M)" de pe butonul generic (cmd_butoane.vc2:194) nu se atinge - e mostenit de peste 100 de formulare din toata suita; un text despre facturi acolo ar minti pe ecranele de parteneri, personal, stocuri.

Doua observatii inainte sa confirmi textul:

• Paginile reale ale formularului nu se numesc "Note / Rulaje / Articole":

  omodificari.vc2:8725   PAGE1.Caption = "Rulaje materii prime, materiale, marfuri, obiecte inventar (303)"
  omodificari.vc2:8728   PAGE2.Caption = "Rulaje obiecte inventar in folosinta (8039)"
  omodificari.vc2:8731   PAGE3.Caption = "Articole factura"
  

  Nu exista pagina "Note" - liniile notei sunt corpul principal al formularului, nepaginat. Formularea ta descrie corect cele trei zone functionale, dar nu citeaza etichetele de pe ecran. E in regula asa, sau vrei alt text?
• Pagina Articole e conditionata (omodificari.vc2:14927-14936): apare doar cand nota se mapeaza pe exact o vanzare (Reccount('tvanz') = 1); altfel PageCount = 2. Un text care promite mereu "articole" va fi inexact pe notele fara vanzare atasata. Nu e grav - dar sa stii.

---

Punctul 6 - explicatie TVA in butonul de modificare din frm_facturi

Premisa ta e corecta si am verificat-o direct pe baza, nu din raport. Procedura care salveaza:

PROCEDURE modifica_explicatie_articol(V_ID_VANZARE_DET IN NUMBER,
                                      V_EXPLICATIE IN VARCHAR2,
                                      V_ID_UTIL    IN NUMBER,
                                      V_TAXCODE    IN NUMBER DEFAULT NULL) is
BEGIN
  UPDATE VANZARI_DETALII
     SET EXPLICATIE = V_EXPLICATIE, TAXCODE = V_TAXCODE
   WHERE ID_VANZARE_DET = V_ID_VANZARE_DET;
END modifica_explicatie_articol;

Doua coloane, fara recalcul, fara atingerea cantitatii/pretului/cotei. Butonul e intr-adevar "campurile care nu modifica valorile". (Detaliu lateral: V_ID_UTIL e primit si nefolosit.)

Traseul azi: But_modifica2 (ofacturare_comun.vc2:1436) -> do_modifica_explicatie() (:4642) -> dialogul frm_modifica_articol_factura (:5129), cu explicatie (editbox) si taxcode (combo pe lista plata de coduri SAF-T, fara legatura cu explicatia TVA).

Aici e capcana. Sablonul din frm_modific2024 nu se poate copia 1:1: acolo alegerea explicatiei TVA scrie id_jtva_coloana si proc_tvav (cota noua) si recheama calculeaza_valori_articol() (ofacturare_editare.prg:1100-1147, omodificari.vc2:15049). Adica exact ce butonul asta nu face si nu trebuie sa faca.

Interventia propusa, ca sa ramana neutru valoric:

1. In dialog, combo nou pe explicatie TVA, filtrat pe cota curenta a liniei - ca sa nu se poata alege o explicatie cu alta cota. Asta e ce pastreaza promisiunea "nu modifica valorile".
2. La alegere, se deriva taxcode prin GetTaxCodeIdPart (oproceduri_comune.prg, functie globala, apelabila din orice formular) si se scrie in combo-ul existent. proc_tvav nu se atinge.
3. Piesele sunt refolosibile ca atare: caut_explicatie_tva (ocautare.prg) si GetTaxCodeIdPart sunt globale. Cod VFP nou estimat: ~30-40 de linii.

Blocajul, si de asta punctul 6 nu poate intra in aceeasi livrare cu 1-5: id_jtva_coloana n-are unde sa se salveze. Procedura Oracle primeste doar explicatie si taxcode. Daca scriem doar taxcode, explicatia TVA a liniei ramane desincronizata de codul fiscal - adica exact defectul pe care vrem sa-l evitam. Deci e nevoie de un parametru nou in pack_facturare.modifica_explicatie_articol, schimbare PL/SQL in afara acestui repo, de coordonat separat.

De decis:

• Confirmi filtrarea pe cota curenta (varianta neutra)? Alternativa - lista completa de explicatii, cu recalcul - ar transforma butonul in altceva decat e azi si l-ar suprapune peste editarea din frm_modific2024. Recomand filtrarea.
• Vrei sa pornim modificarea PL/SQL, sau punctul 6 asteapta?

Bonus, deja rezolvat: gridul din frm_facturi afiseaza deja "Explicatie TVA" / "Explicatie TVA 2" ca si coloane read-only (ofacturare_comun.vc2:1679-1687) - nu e nimic de adaugat in grid, doar in dialog.

---

Ce propun sa intre in livrarea imediata

Punctele 1, 2, 3, 4, 5 - toate in COMUN\clase\omodificari.vc2 si COMUN\clase\ofacturare_comun.vc2, ambele write-back-abile. Fara atingerea bazei de date.

#	Fisier	Interventie	Volum
1+2	omodificari.vc2	5 metode DblClick noi	~25 linii
3	omodificari.vc2:12391	gnPPRET -> gnPPretV	1 linie
4a	omodificari.vc2	5 BackColor -> verde 160,255,205	5 linii
4b	omodificari.vc2	3 BackColor -> alb + ReadOnly=.F.	6 linii
5	ofacturare_comun.vc2:4930	textul optiunii 2 din xmenu	1 linie

Punctul 6 ramane separat - depinde de o schimbare PL/SQL.

Ce astept de la tine inainte sa deleg aplicarea

1. Punctul 4b - confirmi ca serie/lot/explicatie devin scriabile in celula? (singura schimbare reala de comportament din lot)
2. Punctul 3 - aliniem si cPretCuTvaArt la gnPPretV, sau il lasam?
3. Punctul 5 - textul exact: Editare \<factura (note, rulaje, articole)?
4. Punctul 1+2 - DblClick si pe coloana de articol (cDenumireArt), sau doar pe celelalte patru?
5. Punctul 6 - pornim schimbarea PL/SQL acum, sau asteapta?

Nimic nu e aplicat. Niciun fisier de cod n-a fost atins in aceasta runda, nu s-a facut write-back, nu s-a rulat git_sync.ps1, nu s-a scris nimic in Oracle (doar un SELECT din all_source pentru sursa procedurii), nu s-a comis nimic.

---

DECIZIILE LUI MARIUS - 20.08.2026, luate, se aplica

Punct	Decizie
1+2 DblClick	toate cinci coloanele cu nomenclator, inclusiv cDenumireArt
3 Pret	gnPPRET -> gnPPretV la omodificari.vc2:12391
3 conex cPretCuTvaArt	se aliniaza la get_mask(12,gnPPretV)
4a cele 5 cu nomenclator	verde 160,255,205; Text1.ReadOnly ramane .T.
4b serie / lot / explicatie	devin scriabile: alb 255,255,255 + Text1.ReadOnly = .F.
5 meniu	Editare \<factura (note, rulaje, articole); Caption-urile paginilor nu se ating
6 explicatie TVA in frm_facturi	lista completa, CU recalcul; PL/SQL porneste acum

Consecinta punctului 6, semnalata si acceptata

Cu lista completa si recalcul, butonul But_modifica2 nu mai e "campuri fara impact pe valori". Devine o a doua cale de editare care schimba cota si totalurile documentului. Concret, fata de estimarea initiala din propunere, modificarea PL/SQL creste: procedura nu mai primeste doar id_jtva_coloana, ci si proc_tvav, si trebuie sa antreneze recalcularea valorilor liniei si a totalurilor documentului. Marius a ales aceasta varianta dupa ce consecinta a fost semnalata.

Cum se imparte aplicarea

Un singur scriitor per fisier - regula de baza, ca sa nu se piarda modificari tacut.

Agent	Fisier	Puncte
apply-grid	COMUN\clase\omodificari.vc2 + write-back	1+2, 3, 4a, 4b
apply-meniu	COMUN\clase\ofacturare_comun.vc2 + write-back	5
design-plsql	script in D:\ROA\DATABASE\SCRIPTURI_CLAR\ (doar scris, nerulat)	6 - partea DB + proiectarea partii VFP

Partea VFP a punctului 6 (combo-ul din frm_modifica_articol_factura) atinge tot ofacturare_comun.vc2, deci nu porneste in paralel cu apply-meniu si nici inainte ca semnatura procedurii sa fie fixata. Intra intr-un al doilea val, dupa ce design-plsql livreaza contractul si apply-meniu termina.

Commit-ul (git sau svn) nu se da - nici in acest val, nici in urmatorul.

---

Constatare pe baza, 20.08.2026 - corectie la handoff-ul rundei 5

Handoff-ul rundei 5 spune despre ff_2026_08_20_01_COMUN_PACK_FACTURARE.sql (garda FACT-025 pe totaluri) ca e "nerulat pe schema MARIUSM_AUTO (ROA_CENTRAL)". Nu mai e adevarat. Verificat direct in ALL_SOURCE, schema MARIUSM_AUTO, corpul lui PACK_FACTURARE:

lnLiniiActive in DB = 3 aparitii
FACT-025      in DB = 2 aparitii

Deci scriptul 01 a fost aplicat pe schema MARIUSM_AUTO (ROA_CENTRAL) intre timp. Consecinte, toate favorabile:

• ff_2026_08_20_02 a fost construit din sursa vie a pachetului, deci contine deja modificarile scriptului 01. Nu exista riscul ca aplicarea lui 02 sa dea inapoi runda 5.
• Formularea din raportul lui design-plsql — "trebuie aplicat DUPA/impreuna cu 01" — e depasita: 01 e deja in baza, 02 il include.

Capcana ramasa, de retinut: daca cineva re-aplica ff_2026_08_20_01 dupa ce s-a aplicat 02, sterge modificarile punctului 6. Scriptul 01 e consumat; nu se mai ruleaza.

Sursa de derivare a cotei, confirmata pe dictionar: MARIUSM_AUTO.JTVA_COLOANE.COTA_TVA exista.

---

REVIZUIRE punctul 6 - 20.08.2026, decizie schimbata de Marius

Textual: "nu vreau sa schimb cota de tva, maxim explicatia de tva si taxcode, aferente cotei de tva, ca sa nu se modifice totaluri".

Se revine la varianta filtrata pe cota curenta - cea recomandata initial in propunere. Varianta "lista completa, CU recalcul", aleasa in prima runda de intrebari, e ABANDONATA.

Ce ramane

Butonul But_modifica2 din frm_facturi redevine neutru valoric, cum era si cum il descrisese Marius de la inceput. Se scriu trei coloane: EXPLICATIE, TAXCODE, ID_JTVA_COLOANA. PROC_TVAV nu se atinge, totalurile documentului nu se recalculeaza.

Parametrul nou din PL/SQL, V_ID_JTVA_COLOANA IN NUMBER DEFAULT NULL, ramane necesar: fara el, explicatia aleasa n-ar avea unde sa se salveze si ar ramane desincronizata de taxcode.

Ce cade din discutia de gardi

Toata sectiunea A5 din docs\propunere_runda6_punct6_plsql.md era consecinta recalculului. Fara el:

• Garda pe seturi (FACT-027) cade. Motivul ei era agregarea MAX(proc_tvav) peste componentele setului; odata ce proc_tvav nu mai e atins, componentele isi pot schimba linistit explicatia si taxcode-ul.
• Garda e-Factura cade. Butonul redevine neutru valoric, iar azi nu are nicio astfel de verificare - a o adauga acum ar bloca ceva ce functioneaza, fara ca decizia s-o ceara.
• Garda pe valuta oricum nu fusese propusa.

Garda care ramane, si de ce e in PL/SQL

Neutralitatea valorica e chiar cerinta lui Marius, deci se impune in baza, nu se lasa doar pe seama filtrarii combo-ului in interfata: daca filtrul din VFP e gresit sau ocolit, baza trebuie sa refuze.

Daca V_ID_JTVA_COLOANA e dat si JTVA_COLOANE.COTA_TVA a explicatiei alese difera de PROC_TVAV-ul liniei, procedura nu scrie nimic si arunca RAISE_APPLICATION_ERROR - stilul FACT-025 din runda 5: esec vizibil cu rollback, niciodata scriere tacuta.

Raman si gardele ieftine: linie inexistenta sau stearsa, explicatie TVA inexistenta sau fara cota valida.

Starea livrabilelor

ff_2026_08_20_02_COMUN_PACK_FACTURARE.sql, in forma scrisa la 14:22, implementeaza varianta respinsa (recalcul + FACT-027). Se rescrie peste el, pornind de la sursa vie din MARIUSM_AUTO - nu se lasa doua fisiere cu acelasi scop pe disc, exact capcana din runda 5 cand o varianta respinsa a stat alaturi de cea buna. Scriptul nu a fost rulat pe schema MARIUSM_AUTO (ROA_CENTRAL) in nicio forma.

Partea VFP: combo-ul din frm_modifica_articol_factura trebuie filtrat pe cota liniei.