# 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](plan_07_pret_cu_tva_pe_linie.md) | 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 explicit in #6 | | 1 | [#6 — editare factura emisa](plan_06_editare_factura.md) | mediu | `omodificari.vc2` (COMUN) + `PACK_FACTURARE` | **IN LUCRU, aproape gata** — S1-S7 si S9 comise (S4b incheiat 11.08.2026). Ramane **S8**: 2 esecuri reale pe „factura din aviz" (rulajele nu se refac pe nota noua) + 3 tipuri de sursa neacoperite. Stare: antetul planului | | 2 | [#13 — formular unificat + editare prin regenerare](plan_13_unificare_formular_facturare.md) | **mare** | `ofacturare.vc2` + `ofacturare.prg` + `PACK_FACTURARE` (COMUN) | **PROIECTAT INTEGRAL, cod neatins** (17 runde de proiectare, 11.08.2026). Etapele I si II sunt proiectate story cu story (S1-S14); raman testele (S6, S12) si inchiderea (S13). **65 de decizii luate**, niciuna deschisa. Perimetrul cu #6 e transat: **#13 incepe dupa terminarea lui #6** (decizia 30). Mockup: [`mockup_13_formular_unificat.html`](mockup_13_formular_unificat.html). Stare curenta: `handoff_13_formular_unificat.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. Se reiau dupa terminarea lui #8, #7 si #6, cu analiza reluata 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).