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	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	mediu	depinde de varianta	valabil, amanat
—	#11 — integrare politici de preturi	mare	COMUN + ROAPRETURI	valabil, amanat
—	#10 — integrare contracte	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).