roafacturare/docs/plan_07_pret_cu_tva_pe_linie.md

Plan #7 — pret cu TVA editabil pe linie de articol

Sursa: COMUN\docs\todos.txt punctul 7. Ordine de executie: al doilea, dupa #8. Stare: propunere, neinceput.

Problema raportata

Factura iese 99.99 lei dar utilizatorul are nevoie de exact 100.00 lei cu TVA. Politica de preturi e pe "preturi fara TVA", calculul porneste de la pretul fara TVA, TVA-ul se rotunjeste si nu poate fi ajustat. Varianta aleasa de Marius: utilizatorul modifica pret_cu_tva la nivel de articol, la introducerea facturii si ulterior la editare.

Descoperirea care schimba dimensiunea lucrarii

Cerinta initiala presupunea o coloana noua salvata in VANZARI_DETALII, cu migrare si atingerea tuturor locurilor de calcul. Nu e necesar. Instalatia exista deja, integral:

1. VANZARI_DETALII.PRET_CU_TVA exista deja, ca flag NUMBER(1) per linie (0 = PRET e fara TVA, 1 = PRET e cu TVA inclus). Confirmat prin uz: ff_2026_07_27_01_FACTURARE.sql:25,43.
2. PACK_FACTURARE.adauga_articol_factura primeste deja flagul ca parametru, V_PRETURI_CU_TVA_TEMP (ff_2026_03_23_04_COMUN_PACK_FACTURARE.sql:540) — deci VFP il trimite deja per articol, la adaugarea pe factura.
3. Toate functiile de calcul ramifica deja pe el (V_PRET_CU_TVA / V_PRET_ARE_TVA in calculeaza_total_fara_tva / _tva / _cu_tva si variantele _fact, :15638-15949).
4. Listarea si relistarea in VFP ramifica deja pe el, in COMUN\programe\ofacturare_comun.prg:1816-1880 (prelucreaza_facturacrs) — lantul de IIF( pret_cu_tva = 1, ..., ...) care produce pretctva, discountctva si valorile pe linie.

Ce lipseste e exclusiv partea de UI: pe formularul de introducere articole nu exista coloana pentru flag, deci utilizatorul nu il poate schimba per linie. Cautare pe pret_cu_tva in COMUN\clase\ofacturare.vc2 (formularele frm_facturare_articole si frm_facturare_articole2): zero rezultate. Singurul checkbox cPret_cu_tva gasit e in alt grid, Clase\ofundal_facturare.vc2:696-699.

Concluzie: fara DDL, fara migrare de date, fara modificari in view-uri sau in pachetul Oracle. Lucrarea e VFP-only, pe formularul de articole.

Consecinta pentru rotunjire

Cu flagul pe 1, utilizatorul tasteaza direct pretul cu TVA (ex. 100.00), iar pretul fara TVA se deriva. Totalul facturii devine exact suma preturilor tastate — exact cazul din todo.

De stiut: exista deja un mecanism ascuns de absorbtie a diferentelor de rotunjire, dar doar contabil. PACK_FACTURARE.verifica_total_document (:16009-16188) compara totalul asteptat cu suma din notele contabile si, la diferenta, insereaza automat o linie de corectie in ACT_TEMP (:16086-16188). Nu apare pe factura si nu se vede in VANZARI_DETALII. Nu se atinge in acest plan, dar explica de ce pana acum diferenta "disparea" fara ca utilizatorul sa o poata controla.

Capcana de duplicare

do_scrie_factura exista in doua clase aproape identice in COMUN\clase\ofacturare.vc2: frm_facturare_articole (:13981-14339) si frm_facturare_articole2 (:18004-18331). Orice modificare de comportament trebuie facuta in ambele, altfel un flux ramane in urma. Prima story stabileste care dintre ele e folosita pe ce tipuri de factura.

Stories

S1 — Stabilirea formularului si a fluxului real

Determina care dintre frm_facturare_articole / frm_facturare_articole2 se deschide pentru fiecare tip de sursa (lista de preturi, comanda, contract, aviz) si de unde vine flagul azi in cursorul de articole (PACK_FACTURARE.cursor_preturi, spec :335, body :2121). Confirma valoarea implicita propagata din politica de pret. Gata cand: e notat in docs\progres.md ce formular acopera ce tip, si care e sursa implicita a flagului. Blocheaza: S2.

S2 — Coloana pret_cu_tva in gridul de articole

Adauga in grid o coloana checkbox pentru flag, editabila per linie. Respecta COMUN\docs\conventie_ux_formulare.md (pozitionare, ordine de taburi) si, daca formularul are 2+ griduri, COMUN\docs\capcana_grid_controlsource.md. Editare pe versiunile text .vc2 + write-back, cu regulile de encoding cp1252 din COMUN\docs\conventie_encoding_cp1252.md. Gata cand: coloana apare si se poate bifa/debifa, in ambele clase.

S3 — Recalcularea afisata la schimbarea flagului

La bifare/debifare, valorile de pe linie si totalul facturii se recalculeaza imediat, folosind aceeasi ramificare ca prelucreaza_facturacrs (ofacturare_comun.prg:1816-1880), ca listarea sa dea identic cu ce vede utilizatorul pe ecran. Gata cand: bifarea unei linii schimba totalul afisat coerent, fara reincarcarea formularului. Depinde de: S2.

S4 — Pretul editabil in modul "cu TVA"

Cu flagul pe 1, campul de pret accepta pretul cu TVA tastat de utilizator si il trimite ca atare la adauga_articol_factura prin V_PRETURI_CU_TVA_TEMP = 1. Verifica precizia de rotunjire folosita (gnPPretV, gnPc — vezi ofacturare_comun.prg:1817-1821). Gata cand: o factura cu o singura linie, pret 100.00 cu TVA, cantitate 1, da total exact 100.00. Depinde de: S2.

S5 — Test pe fluxul real

Test headless conform COMUN\docs\depanare_testare_vfp.md, plus verificare UI conform COMUN\docs\testare-ui-vfp.md. Cazuri: cota standard si cota redusa; cu si fara discount unitar (ramura discount_evidentiat din calculeaza_total_tva_fact, :15899-15949); doua linii cu flaguri diferite pe aceeasi factura. Gata cand: toate cazurile dau acelasi rezultat la introducere, la listarea initiala si la relistare. Depinde de: S3, S4.

S6 — Editarea ulterioara a flagului

Modificarea flagului pe o factura deja emisa nu intra aici — depinde de mecanismul de editare din planul #6, pentru ca schimbarea afecteaza sumele si deci notele contabile. Story-ul se rezuma la a nota dependenta si a lasa punctul de extensie curat. Gata cand: dependenta e consemnata in plan_06_editare_factura.md.

S7 — Diff, review, changelog

Diff ca fisier in docs\, commit doar dupa aprobare. Changelog :nou: sau :modificare:, 1-3 fraze non-tehnice, bump pe seria 2.11.x.

Riscuri

• Flagul exista deja pe linii istorice; expunerea lui in UI nu schimba date vechi, dar face vizibile eventuale inconsistente deja prezente. De privit inainte de livrare cate linii au flagul diferit de valoarea implicita a politicii.
• Rotunjirea per unitate se face in PACK_SESIUNE.calculeaza_pret_*, pachet care nu a fost gasit in arhiva de migrari cautata. Daca S4 arata diferente de rotunjire, e nevoie de o cautare dedicata dupa create or replace package pack_sesiune in D:\ROA\DATABASE\SCRIPTURI_CLAR.
• Duplicarea frm_facturare_articole / _articole2 e sursa clasica de "merge pe un flux, nu si pe celalalt".

Varianta respinsa

Denormalizarea completa (salvarea TVA unitar si a valorii TVA pe linie, cu recitire in toate view-urile si rapoartele) — minimum 6 zone distincte: DDL cu migrare de date istorice, ~4 proceduri in PACK_FACTURARE, 3-4 view-uri (fact_vrap_fact_articole, fact_vrap_articole_vandute, fact_vfacturi, fact_vfacturi2), raportul dinamic din COMUN\programe\oproceduri_rapoarte_fact.prg:581-590, gridul si rapoartele .frx. Nu se justifica atat timp cat flagul per linie rezolva cazul real.