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