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
118 lines
6.1 KiB
Markdown
118 lines
6.1 KiB
Markdown
# Plan #10 — integrarea paginii de contracte in ROAFACTURARE
|
|
|
|
Sursa: `COMUN\docs\todos.txt` punctul 10.
|
|
Ordine de executie: **ultimul**. Marius si-a exprimat indoiala asupra utilitatii; planul incepe cu o
|
|
decizie go/no-go, nu cu implementarea.
|
|
Stare: propunere, neinceput.
|
|
|
|
## Constatarea care pune sub semnul intrebarii lucrarea
|
|
|
|
**Motorul de facturare pe baza de contract exista deja si e complet functional in ROAFACTURARE.**
|
|
Nu e o functionalitate lipsa, ci una care merge azi fara pagina de contracte:
|
|
|
|
- `facturare_contracte(tcTip)` (`COMUN\programe\oproceduri_facturare.prg:119-136`) — primeste
|
|
"FACTURA LEI" / "INVOICE" / "FACTURA VALUTA" si apeleaza `factureaza(2)` / `(6)` / `(52)`.
|
|
- Buton deja pe pagina de fundal: `Page2.Cw2.do_actiune` (`Clase\ofundal_facturare.vc2:886-897`),
|
|
meniu cu cele 3 optiuni.
|
|
- Cautarea contractului facturabil: `caut_contract_facturare(tnIdPart, tcSirTipFacturare)`
|
|
(`COMUN\programe\oproceduri_facturare.prg:1986-2021`), din view-ul Oracle `fact_vcontracte`
|
|
(`:2001`).
|
|
- Alegerea contractului pe factura: `frm_date_factura.do_cauta_contract`
|
|
(`COMUN\clase\ofacturare.vc2:9067-9115`) si `frm_date_aviz.do_cauta_contract` (`:7049-7051`).
|
|
- Tab/grid dedicat pe editorul de articole: `grd_contracte`, `cb_contracte`, cursor `crscontracte`
|
|
(`COMUN\clase\ofacturare.vc2:15069-15107`).
|
|
- Exista si aviz "catre clienti din contract", tip 26 (`oproceduri_facturare.prg:207`, `:2045`).
|
|
- Ratele de contract se scriu la emitere: `finalizeaza_factura` cheama `scrie_rate_factura` pentru
|
|
`ntip in (2,6,52)` (`ff_2026_03_23_04_COMUN_PACK_FACTURARE.sql:14785-14786`).
|
|
|
|
Ce lipseste efectiv, fata de cerinta:
|
|
1. pagina de **editare CRUD** a contractelor in ROAFACTURARE (azi doar in exe-ul separat
|
|
`D:\ROA\ROACONTRACTE`, cu `Clase\ferestre_contracte.vcx`);
|
|
2. **rapoarte** de contracte (glob `*contract*` in `ROAFACTURARE\Rapoarte\` nu intoarce niciun
|
|
`.frx` — doar meniu si iconite);
|
|
3. **comasarea drepturilor** pe obiectele din ROACONTRACTE cu cele noi din ROAFACTURARE.
|
|
|
|
Observatie: `ROAFACTURARE\Meniuri\contracte.mnx` exista deja, dar e un popup de facturare
|
|
(lei / invoice / valuta), nu un meniu de administrare — deci numele e ocupat, continutul nu.
|
|
|
|
## Intrebarea de decis inainte de orice cod
|
|
|
|
Cine editeaza azi contractele si cat de des? Daca persoana care factureaza nu e si cea care
|
|
intocmeste contractele, integrarea CRUD in ROAFACTURARE nu scade nimic din efortul zilnic — motorul
|
|
de facturare merge deja. In cazul asta lucrarea se reduce eventual la punctul 2 (rapoarte), care e
|
|
mult mai ieftin.
|
|
|
|
## Stories
|
|
|
|
### S0 — Decizie go/no-go — **DATE CULESE, 05.08.2026**
|
|
Rulat read-only pe schema de productie `VENDING`:
|
|
|
|
| Masura | Valoare |
|
|
|---|---|
|
|
| contracte existente | **4** |
|
|
| contracte create in ultimele 12 luni | **0** |
|
|
| facturi emise vreodata pe baza de contract (tip 2, 6, 52) | **0** |
|
|
| facturi din contract in ultimele 12 luni | **0** |
|
|
|
|
Pentru context, din 140 656 de facturi: 116 071 pe lista de preturi, 5 608 din comanda, 11 din aviz.
|
|
|
|
**La acest client contractele sunt practic nefolosite**, iar mecanismul de facturare pe contract —
|
|
care exista si e complet — nu a fost folosit niciodata. O pagina CRUD de contracte in ROAFACTURARE
|
|
nu ar scadea niciun efort real aici.
|
|
|
|
**Limitare importanta**: e un singur client. Inainte de un no-go definitiv, aceleasi patru cifre
|
|
trebuie luate de la 2-3 clienti care chiar lucreaza pe contracte. Daca si acolo ies zerouri, punctul
|
|
#10 se inchide; daca nu, se reia de la S1 cu clientul respectiv ca referinta.
|
|
*Gata cand:* cifrele exista de la inca 2-3 clienti si decizia e scrisa.
|
|
|
|
### S1 — Inrolarea ROACONTRACTE in fluxul text
|
|
`ROACONTRACTE` nu are cache text generat, deci `ferestre_contracte.vcx` nu se poate citi in detaliu
|
|
si nu se poate edita pe text. Procedura: `COMUN\docs\inrolare-proiect-git-text.md`.
|
|
*Depinde de:* S0 = go.
|
|
|
|
### S2 — Clasa container `ct_contracte` in COMUN
|
|
Dupa sablonul `ct_comenzi` (`COMUN\clase\ocomenzi.vcx`): container CRUD montabil, fisiere in
|
|
`COMUN\clase\`, deci schimbare **cross-project**.
|
|
*Depinde de:* S1.
|
|
|
|
### S3 — Incarcare lazy
|
|
Aceeasi cerinta ca la #11: datele se incarca la prima activare a paginii, cautarea trimite `WHERE` in
|
|
Oracle. Sablonul e detaliat in `plan_11_integrare_politici_preturi.md` (S4) — se copiaza din
|
|
`ocomenzi.vc2:1088-1104` / `:1484-1510`, nu se inventeaza un al doilea.
|
|
|
|
**Atentie — capcana confirmata**: `ct_contracte` din ROACONTRACTE
|
|
(`Clase\ferestre_contracte.vc2:9`) mosteneste acelasi `_ct_base` ca `ct_comenzi`, dar **nu**
|
|
suprascrie `actualizeaza_cursoare`/`creeaza_cursoare` (zero aparitii in fisier), deci foloseste
|
|
stub-ul gol si **nu e lazy azi** — cursorul principal `cContracte` apare deja populat la `Init`
|
|
(`:1518-1527`). Daca clasa se aduce ca atare, se aduce si incarcarea eager. Sablonul de copiat e
|
|
strict cel din `ocomenzi.vc2`.
|
|
*Depinde de:* S2.
|
|
|
|
### S4 — Montare in fundal + entry point + drepturi
|
|
Obiect nou in `Clase\ofundal_facturare.vc2` langa `lb_comenzi`; bloc `*** CONTRACTE` in
|
|
`Programe\roafacturare.prg` (`SET CLASSLIB` / `SET PROCEDURE`, dupa modelul `:180-181` si
|
|
`:239-242`); adaugare in `roafacturare.pjx`.
|
|
Drepturi: `nid_cw` libere — `Page2` are deja `Cw1..Cw9` ocupate
|
|
(`Clase\ofundal_facturare.vc2:882-926`); catalogul server-side din spatele
|
|
`contafin_oracle.vdef_util_obiecte` trebuie inspectat direct in Oracle inainte de alocare.
|
|
Comasarea cu drepturile existente din ROACONTRACTE se face aici.
|
|
*Depinde de:* S2.
|
|
|
|
### S5 — Rapoarte de contracte
|
|
Poate fi livrat **independent de restul**, daca S0 arata ca doar rapoartele sunt cerute. `.frx` se
|
|
editeaza doar in IDE-ul VFP.
|
|
*Depinde de:* S0.
|
|
|
|
### S6 — Testare, diff, changelog
|
|
Test UI (`COMUN\docs\testare-ui-vfp.md`); verificare ca ROACONTRACTE stand-alone continua sa mearga.
|
|
Diff ca fisier in `docs\`, commit dupa aprobare, in doua repo-uri (ROAFACTURARE si COMUN).
|
|
|
|
## Riscuri
|
|
|
|
- Cel mai mare risc e sa se construiasca ceva ce nu reduce niciun efort real — de aceea S0 e blocant.
|
|
- Comasarea drepturilor atinge un catalog Oracle nevizibil in sursa VFP; e partea cea mai putin
|
|
estimabila.
|
|
- `COMUN\clase\` inseamna impact pe toate produsele.
|
|
- Duplicarea CRUD-ului de contracte in doua exe-uri care scriu aceleasi tabele cere validari
|
|
identice in ambele.
|