# 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.