Marius Mutu
d9f5ca4226
Folderul docs\ era pana acum in afara oricarui control de versiuni - nici git, nici SVN - desi contine planurile pe puncte, proiectarile si rapoartele de cercetare pe care se sprijina modificarile din cod. O stergere acolo era definitiva. Fisierele intermediare (handoff-uri intre sesiuni, diff-uri deja aplicate) au fost sterse inainte, nu versionate: ce era durabil in ele a intrat in antetele fisierelor de test la care se refereau. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
154 lines
8.3 KiB
Markdown
154 lines
8.3 KiB
Markdown
# 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.
|