roafacturare/docs/plan_index.md

# Planuri ROAFACTURARE — index si ordine de executie

Sursa: punctele ROAFACTURARE din `COMUN\docs\todos.txt` (6, 7, 8, 10, 11, 12).
Ordinea e pe risc crescator, cu proiectele mari la final. Se executa **pe rand**, fiecare cu commit
si verificari proprii, ca sa nu se amestece.

| # | Plan | Volum | Ce atinge | Stare |
|---|---|---|---|---|
| — | #8 — denormalizare VANZARI | **mediu** (scop extins 06.08) | `PACK_FACTURARE` + ambele view-uri (COMUN) + reparare date | **TERMINAT si COMIS** 07.08.2026 (r17990-r17993). Planul a fost sters la curatenie; istoricul e in `progres.md` |
| — | #7 — pret cu TVA pe linie | mic-mediu | doar VFP, gridul de articole din `frm_facturare_articole` | **TERMINAT** 08.08.2026 (changelog 2.11.14). Editarea flagului pe o factura **deja salvata** a fost mutata in #6. Planul a fost sters la curatenie; istoricul e in `progres.md` |
| — | #6 — editare factura emisa | mediu | `omodificari.vc2` (COMUN) + `PACK_FACTURARE` | **INCHIS** 20.08.2026 (r18026, changelog 2.11.15). Planul a fost sters la curatenie; istoricul — inclusiv cele 2 esecuri ramase pe „factura din aviz" din S8 — e in `progres.md` |
| 1 | [#13 — formular unificat + editare prin regenerare](plan_13_unificare_formular_facturare.md) | **mare** | `ofacturare.vc2` + `ofacturare.prg` + `PACK_FACTURARE` (COMUN) | **INCHIS ca plan (08.09.2026)**, pe branch `plan13-s2` (ROAFACTURARE + COMUN), nemerge-uit si netestat manual; ce ramane sunt datorii. Stare curenta: `handoff_reluare_13_b13.md`, `handoff_plan13_executie_continua.md` |
| — | [#12 — nomenclator ca sursa de pret](plan_12_nomenclator_ca_lista_preturi.md) | mediu | depinde de varianta | valabil, **amanat** |
| — | [#11 — integrare politici de preturi](plan_11_integrare_politici_preturi.md) | mare | COMUN + ROAPRETURI | valabil, **amanat** |
| — | [#10 — integrare contracte](plan_10_integrare_contracte.md) | mare | COMUN + ROACONTRACTE | valabil, **amanat** |

### De ce sunt amanate #12, #11 si #10

Decizia lui Marius, 06.08.2026. **Nu sunt abandonate si nu sunt invalidate** — planurile si faptele
stabilite in ele raman valabile ca punct de plecare. Sunt amanate pentru ca sunt **proiecte complexe,
care mai au nevoie de analiza** inainte de a fi pornite:

- **#12** — varianta nu e inca aleasa (C singura, sau C urmata de A restransa). Alegerea schimba
  perimetrul, de la un atribut optional de articol pana la coloane de pret in nomenclator.
- **#11** — atinge COMUN si ROAPRETURI, iar `ROAPRETURI` nu e inca inrolat in fluxul text, deci
  clasele lui nu se pot edita decat manual in IDE.
- **#10** — go/no-go-ul nu e inchis. Datele de la un client inclina spre no-go, dar e un singur
  client; mai trebuie aceleasi cifre de la 2-3 clienti care chiar lucreaza pe contracte.

#8, #7 si #6 sunt terminate, deci conditia de reluare e indeplinita; analiza se reia de unde s-a
oprit (rapoartele din `docs\cercetare\`).

## Dependente reale intre planuri

- **#7 -> #6**: editarea flagului `pret_cu_tva` pe o factura emisa (story S4 din #6) are sens doar
  dupa ce #7 stabileste comportamentul la introducere.
- **#8 -> #6**: story S5 din #6 refoloseste calculul totalurilor din `scrie_in_vanzari`, atins in #8.
  Daca ordinea se inverseaza, calculul se dubleaza si cele doua cai diverg.
- **#11 -> #10**: sablonul de incarcare lazy se stabileste o singura data, in #11 (S4), si se
  refoloseste in #10 (S3).
- **#12** e independent de restul.

## Deciziile deschise — stare la 05.08.2026, de reluat cand se reiau #12 si #10

Ambele au fost investigate read-only pe schema de productie `VENDING`. Concluziile raman valabile;
ce lipseste e decizia, nu investigatia.

1. **#12, varianta** — investigatia a reformulat problema. Pretul nu e cauza duplicarii: **nota
   contabila e**. 14 politici poarta 12 note distincte (`VANZARE AUTO EUR`, `VANZARE AUTO LEI`,
   `SERVICII`, `TRANSPORT`...), iar articolele sunt introduse in medie de 3 ori (3 354 articole ->
   10 130 randuri de pret). Varianta B e **exclusa**; recomandarea e **varianta C** (nota contabila
   ca atribut optional de articol), eventual urmata de o varianta A restransa doar la pret, pentru
   cele 807 articole fara niciun pret. **Ramane de aprobat.**
2. **#10, go/no-go** — la clientul verificat: 4 contracte, 0 create in ultimul an, **0 facturi emise
   vreodata pe baza de contract**. Mecanismul exista si nu a fost folosit niciodata. Inclina clar
   spre **no-go**, dar e un singur client — mai trebuie aceleasi cifre de la 2-3 clienti care chiar
   lucreaza pe contracte.

## Precoditii de mediu

- **Orice DDL**: sursa de referinta e `MARIUSM_AUTO` pe `ROA_CENTRAL`, nu productia, si numai dupa ce
  s-a verificat ca are toate scripturile aplicate — `COMUN\docs\scripturi-migrare-db.md`, sectiunea
  "Sursa de referinta pentru DDL". Verificat la 06.08.2026: toate cele 2 567 de scripturi `ff_` sunt
  aplicate.
- **#8** se dezvolta si se testeaza integral pe `MARIUSM_AUTO` — bug-ul se reproduce si acolo (846
  randuri, o singura valoare distincta de `AVIZE`). Accesul la `VENDING` ramane optional, ca al
  doilea set de date, strict in citire, prin tunel SSH.
- **#11** si **#10** au nevoie ca `ROAPRETURI`, respectiv `ROACONTRACTE`, sa fie inrolate in fluxul
  text (`COMUN\docs\inrolare-proiect-git-text.md`) — altfel clasele lor nu se pot edita decat manual
  in IDE-ul VFP.

## Note transversale

- `PACK_FACTURARE` si clasele din `COMUN\` sunt **partajate de toata suita ROA**. Planurile #8, #6,
  #11 si #10 ies din perimetrul ROAFACTURARE si cer commit in doua repo-uri.
- Scripturile Oracle se scriu la nivel **10.2** (un client, ROMCONSTRUCT, e inca acolo), CRLF,
  idempotente — `COMUN\docs\scripturi-migrare-db.md`.
- Sursa completa `PACK_FACTURARE` nu e in working copy VFP. Referinta se exporta din `MARIUSM_AUTO`
  (`COMUN\docs\oracle_export.md`); copia pe disc, cu alta numerotare de linii, e
  `D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\03\ff_2026_03_23_04_COMUN_PACK_FACTURARE.sql` (16948 linii).