roafacturare/docs/plan_11_integrare_politici_preturi.md

Plan #11 — integrarea editarii politicilor/listelor de preturi in ROAFACTURARE

Sursa: COMUN\docs\todos.txt punctul 11. Ordine de executie: al cincilea, dupa #12. Proiect mare, executat separat, cu commit si verificari proprii. Stare: propunere, neinceput.

Situatia reala

Editarea listelor/politicilor de preturi traieste azi intr-un produs separat, mic si dedicat: D:\ROA\ROAPRETURI (.pjx propriu, roapreturi.exe), cu Clase\opreturi.vcx, Clase\onom_preturi.vcx, Clase\ofundal_preturi.vcx, Programe\onom_preturi.prg, Programe\update_preturi.prg, Programe\update_nomenclator.prg.

ROAFACTURARE doar citeste aceste date, nu le editeaza:

• facturare pe lista de preturi: facturare_lista_de_preturi = Do politica.mpr (COMUN\programe\oproceduri_facturare.prg:113-116), buton Page2.Cw1.do_actiune (Clase\ofundal_facturare.vc2:882-884);
• filtrarea politicilor dupa dreptul utilizatorului: select nume_lista_preturi, id_pol from crm_vpolpretcurutil (COMUN\clase\baza.vc2:10504, plus :10087, :10157, :10502-10512);
• rapoarte grupate pe nume_lista_preturi din vvanzari_detalii: frm_raport_marfa (COMUN\clase\configurare.vc2:3915-3972).

Datele sunt Oracle, in ceea ce pare a fi un modul transversal "CRM" (vcrm_politici_preturi, crm_vpolpretcurutil, cheia id_pol). Deci structura de date nu se muta — e deja partajata si citita corect. Se muta doar interfata de editare.

Nu s-a gasit o tabela separata de "note contabile asociate politicii de pret": contul de vanzare pare sa vina din nomenclatorul de articole (catalog_articole.cont). De confirmat in S1, pentru ca schimba ce anume trebuie adus in interfata.

Sablonul de urmat: COMENZI

COMENZI nu e un exe separat lansat din ROAFACTURARE, ci cod montat direct din COMUN\. Reteta, verificata pe cod:

1. Clasa container ct_comenzi din COMUN\clase\ocomenzi.vcx.
2. Montata ca obiect copil lb_comenzi in formularul de fundal (Clase\ofundal_facturare.vc2:824-831).
3. Butoane de actiune legate la business logic: Page2.Cw3.do_actiune -> DO facturare_comenzi IN oproceduri_facturare.prg (Clase\ofundal_facturare.vc2:899-902).
4. Inregistrare in entry point Programe\roafacturare.prg: SET CLASSLIB TO ocomenzi ADDITIVE (:180-181), SET PROCEDURE TO orap_comenzi.prg / onom_comenzi.prg / update_comenzi.prg ADDITIVE (:239-242), variabile de modul (:246-247) — toate sub blocul *** COMENZI.
5. Fisierele stau fizic in COMUN\clase\ / COMUN\programe\, dar sunt membri ai roafacturare.pjx.

Drepturi

Mecanismul: COMUN\programe\acces_meniu.prg. Sursa e view-ul Oracle contafin_oracle.vdef_util_obiecte (:29-31), citit o data per firma in cursorul crsdrepturi (citeste_drepturi, :17-37), punct de intrare verifica_drepturi('gofundal','_pgfrmbase1') (Ferestre\fundal.sc2:699). Cheia unui buton = caracterele de nivel ale paginii + codul de 2 cifre din proprietatea nid_cw: lcCheie = lcKey + Padl(Alltrim(Str(.Objects(l).nid_cw)), 2, '0') (acces_meniu.prg:138). Administrarea: COMUN\clase\drept_grupuri.vc2, pachet Oracle PACK_DREPTURI.grupdreptmodproc (:39).

Constrangere: Page2 are deja Cw1..Cw9 ocupate (Clase\ofundal_facturare.vc2:882-926), deci butoanele noi au nevoie de nid_cw libere. Catalogul server-side din spatele vdef_util_obiecte nu e vizibil in sursa VFP — trebuie inspectat direct in Oracle inainte de a aloca coduri.

Exista in plus un al doilea strat de drepturi, specific pe politici de pret (crm_vpolpretcurutil, baza.vc2:10502-10512), distinct de acces_meniu.prg. Cerinta "drepturi pe liste de preturi" se refera la acesta — de tratat separat de drepturile pe obiecte.

Precoditie blocanta

ROAPRETURI nu are cache text generat (.vc2/.sc2), deci clasele lui nu se pot nici citi in detaliu, nici edita pe text. Fara acest pas, tot ce urmeaza se poate face doar manual in IDE-ul VFP. Procedura: COMUN\docs\inrolare-proiect-git-text.md.

Stories

S1 — Inrolarea ROAPRETURI in fluxul text + inventarul interfetei

Genereaza cache text pentru D:\ROA\ROAPRETURI conform inrolare-proiect-git-text.md, apoi inventariaza: ce formulare exista, ce tabele/view-uri Oracle scriu, ce validari au, de unde vine contul contabil de vanzare. Confirma sau infirma ipoteza "contul vine din catalog_articole.cont". Gata cand: exista o lista de formulare + tabele scrise, in docs\progres.md. Blocheaza: tot restul.

S2 — Decizia de perimetru

Pe baza S1, stabileste ce se muta si ce ramane: ROAPRETURI scrie si in nomenclatorul comun (update_nomenclator.prg), care e folosit si de alte produse. Daca interfata muta si acea parte, lucrarea devine cross-project. Gata cand: perimetrul e scris explicit si aprobat de Marius. Depinde de: S1.

S3 — Clasa container ct_preturi in COMUN

Adapteaza clasele din ROAPRETURI intr-un container montabil, dupa modelul ct_comenzi. Fisierele merg in COMUN\clase\, deci schimbarea e cross-project (repo propriu gitea.romfast.ro:romfast/comun.git). Gata cand: clasa se instantiaza fara erori intr-un test headless. Depinde de: S2.

S4 — Incarcare lazy

Cerinta explicita a lui Marius: datele nu se incarca decat la accesarea paginii, iar cautarea se face pe server. Sablonul exista deja si se copiaza ca atare din ct_comenzi:

1. PageX.Activate cheama do_activeaza_container() (Clase\ofundal_facturare.vc2:1006-1008).
2. do_activeaza_container e mostenit din COMUN\clase\_ct_base.vc2:278-281 si cheama This.actualizeaza_cursoare().
3. actualizeaza_cursoare din _ct_base e un stub gol (:231-232) — containerul concret trebuie sa il suprascrie explicit; nu vine gratis din mostenire.
4. Implementarea de urmat: ocomenzi.vc2:1088-1104 — guard (!Used('crscomenzi') Or gcS != This.cSchema Or <schimbare sectie>), apoi creeaza_cursoare() (:1191-1245) cu un WHERE imposibil, id_comanda = -9999999 (:1216): se creeaza structura, nu se aduc date.
5. Datele reale vin abia la do_cauta() (:1484-1510), care trimite filtrul prin actualizeaza_grid1(lcFiltru) -> ca_baza1.cfiltru -> ca_baza1.afisare() (:1109-1123), adica WHERE executat in Oracle, nu filtrare locala pe cursor deja incarcat.

Gata cand: deschiderea formularului de fundal nu incarca date de preturi; activarea paginii creeaza doar structura; filtrarea trimite WHERE in Oracle. Depinde de: S3.

S5 — Montarea in fundal + inregistrarea in entry point

Obiect nou langa lb_comenzi in Clase\ofundal_facturare.vc2; bloc *** PRETURI in Programe\roafacturare.prg cu SET CLASSLIB / SET PROCEDURE; adaugare in roafacturare.pjx. Respecta COMUN\docs\conventie_ux_formulare.md. Gata cand: pagina apare si e functionala in exe-ul reconstruit. Depinde de: S3.

S6 — Drepturi pe obiecte

Aloca nid_cw libere pentru butoanele noi (verificate mai intai in tabelul server-side din spatele vdef_util_obiecte), si inregistreaza obiectele in catalogul Oracle. Verifica dezactivarea corecta pentru un utilizator fara drept. Gata cand: un utilizator fara drept nu vede/nu poate actiona butoanele noi. Depinde de: S5.

S7 — Drepturile pe liste de preturi

Adu si administrarea stratului al doilea (crm_vpolpretcurutil), daca S2 a inclus-o in perimetru. Depinde de: S6.

S8 — Rapoarte

Adu rapoartele de preturi din ROAPRETURI. .frx se editeaza doar in IDE-ul VFP — nu exista write-back din text. Depinde de: S5.

S9 — Testare, diff, changelog

Test UI conform COMUN\docs\testare-ui-vfp.md; verificare ca ROAPRETURI stand-alone continua sa functioneze (nu se dezinstaleaza in aceasta lucrare). Diff ca fisier in docs\, commit dupa aprobare, in doua repo-uri (ROAFACTURARE si COMUN). Changelog :nou:.

Riscuri

• Cross-project pe COMUN: orice clasa pusa in COMUN\clase\ ajunge la toate produsele.
• Coexistenta: ROAPRETURI ramane instalat la clienti; doua interfete care scriu aceleasi tabele Oracle trebuie sa aiba aceleasi validari, altfel una permite ce cealalta interzice.
• Drepturile server-side sunt partea cel mai putin vizibila din cod; subestimarea lor e riscul principal de intarziere.
• Modulul "CRM" al politicilor pare folosit si de alte produse (ipoteza din cercetare, de confirmat in S1) — daca e asa, "se folosesc numai in ROAFACTURARE" din enuntul initial nu se verifica, iar perimetrul trebuie restrans.