roafacturare/docs/cercetare/rec_s5_discount_valuta.md

S5 — parametrul de discount si documentele in valuta. Rezultat

Inchide cele doua goluri declarate de docs\cercetare\rec_s5_scriere_reala.md, sectiunea „Ce NU acopera testul". Suita: COMUN\utile\Teste\editare_factura\test_s5_discount_valuta.prg. Log: COMUN\utile\Teste\editare_factura\test_s5_discount_valuta_log.txt (rulare 10.08.2026, 00:05:16-00:05:21). Diff: docs\diff_s5_discount_valuta.patch.

Rezultat

46 PASS / 0 FAIL, numarate din log. Zero linii EROARE, ultima linie e done, deci rularea a ajuns la capat. Starea finala e verificata independent prin sqlplus, nu din logul testului.

VERDICTUL pe NULL: PASTREAZA. Nu zeroeaza.

Dovedit pe date, in doua contexte diferite, prin patru apeluri succesive in aceeasi tranzactie, cu citirea starii necomise intre ele (log, blocul A):

Apel	VANZARI.DISCOUNT	DISCOUNT_TVA	TOTAL_FARA_TVA	TOTAL_TVA	TOTAL_CU_TVA
stare initiala	0	0	747.96	157.06	905.02
recalculeaza_totaluri_vanzari(1049, NULL)	0	0	747.96	157.06	905.02
recalculeaza_totaluri_vanzari(1049, 12.5)	12.50	2.63	735.46	154.43	889.89
recalculeaza_totaluri_vanzari(1049, NULL)	12.50	2.63	735.46	154.43	889.89
recalculeaza_totaluri_vanzari(1049, 0)	0	0	747.96	157.06	905.02

Randul al patrulea e verdictul: NULL peste un discount de 12.50 il lasa 12.50, si lasa toate totalurile neschimbate pana la a patra zecimala (asertia A3 compara exact, cu toleranta 0.0001, nu aproximativ). Randul al cincilea arata contrastul: 0 explicit chiar zeroeaza — deci cele doua valori nu se confunda in implementare.

Acelasi verdict, repetat pe calea de valuta (blocul B, id_vanzare = 1037): discount 10 -> NULL -> discount ramane 10, ftva/tva/valval/tvaval neschimbate.

Codul si datele concorda

ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql:16043-16046:

SELECT NVL(V_DISCOUNT, discount), in_valuta, NVL(discount_evidentiat, 0)
  INTO lnDiscountFactura, lnInValuta, lnDiscountEvidentiat
  FROM vanzari
 WHERE id_vanzare = V_ID_VANZARE;

NVL(V_DISCOUNT, discount) — parametrul nul cade pe valoarea din tabela, iar UPDATE-ul final (:16215) scrie inapoi discount = lnDiscountFactura. Citirea corpului si comportamentul pe date spun acelasi lucru. Nu am gasit nicio divergenta si niciun defect in procedura.

Cum se comporta o valoare nenula

Document in RON (in_valuta = 0): discountul se scade ca atare din baza fara TVA, iar TVA-ul lui se scade din TVA. Cu PPRETV = 2 si cota maxima 1.21 pe liniile active:

total_fara_tva = 747.96 - 12.50            = 735.46
discount_tva   = ROUND(12.50 * 0.21, 2)    =   2.63
total_tva      = 157.06 -  2.63            = 154.43
total_cu_tva   = 735.46 + 154.43           = 889.89

VALOARE_ACHIZITIE ramane 263.31 — nu depinde de discount, verificat explicit (A2).

Document in valuta (in_valuta = 1): discountul e exprimat in valuta. In RON se scade convertit prin cursul documentului, in valuta se scade brut — ramura decode(in_valuta, 1, ROUND(curs * discount / multiplicator, PPRETV), discount) (:16073-16092). Pe id_vanzare = 1037 (id_valuta = 2, curs = 5.2688, multiplicator = 1), cu discount 10:

discount in RON = ROUND(5.2688 * 10 / 1, 2) = 52.69
total_fara_tva  = 1053.76 - 52.69           = 1001.07
total_tva       =  221.29 - ROUND(52.69 * 0.21, 2) = 221.29 - 11.06 = 210.23
valval          =  200 - 10                 =  190.00
discount_tva    = ROUND(10 * 0.21, 2)       =    2.10   (TVA-ul discountului, in VALUTA)
tvaval          =   42 -  2.10              =   39.90
totval          =  190 + 39.90              =  229.90

Toate cele sapte valori au fost calculate in test din starea de plecare si comparate cu ce a scris procedura. ID_VALUTA, CURS si MULTIPLICATOR raman 2 / 5.2688 / 1 dupa recalcul.

De consemnat, pentru cine citeste coloanele: DISCOUNT_TVA retine DISC_TVA_VAL, adica TVA-ul discountului in valuta (2.10), nu in RON (11.06) — pe documentele in RON cele doua coincid, pe cele in valuta nu. Nu e defect, scrie_in_vanzari face la fel; e doar neevident din nume.

Documentele in valuta EXISTA. Premisa contrara era gresita.

Nota anterioara („nu exista in schema un document descoperibil simultan cu articole si in valuta reala") nu se confirma. In MARIUSM_AUTO:

• 28 de randuri VANZARI cu IN_VALUTA = 1;
• 25 dintre ele au cel putin o linie activa in VANZARI_DETALII;
• 8 au si ID_VALUTA / CURS / MULTIPLICATOR completate si rand in VANZARI_CURSURI: id_vanzare 329, 627, 678, 859, 864, 947, 952, 1037.

Celelalte 17 sunt degenerate (ID_VALUTA si CURS nule pe cap), deci nu sunt cazuri de test bune.

Ales: id_vanzare = 1037, cod = 1140730, din 07.05.2026, o linie activa (det = 1565, cantitate 1, pret 200 in valuta, pret_cu_tva = 0, proc_tvav = 1.21, pret_achizitie = 100), totaluri persistate 1053.76 / 221.29 / 1275.05 in RON si 200 / 42 / 242 in valuta.

Recalculul reproduce exact starea persistata a acestui document, si in RON si in valuta (asertiile B1). Asta e proba directa ca agregarea din procedura — inclusiv conversia prin VANZARI_CURSURI — e corecta pe un document in valuta emis pe cale normala, nu doar pe unul simulat in VFP. Golul lasat de test_adauga_linie_valuta.prg (care suprascria tvanz manual) e inchis pe partea de Oracle.

Ce NU se poate acoperi pe documentele in valuta

Niciunul dintre cele 8 nu e din luna curenta (cel mai recent e din 05.2026, restul din 2009-2022), iar garda din do_editare_factura cere data_act in luna de lucru. Deci lantul complet de editare nu poate fi rulat pe un document in valuta — pe date exista doar recalculul Oracle, care e insa exact partea despre care nu se stia nimic. Documentul fiind arhiva, blocul B se inchide cu ROLLBACK: 1037 e verificat prin sqlplus dupa test si e neatins.

Lantul real de salvare cu discount nenul (blocul C)

Singurul bloc care comite. Documentul 1049 a primit discount 12.5 prin chiar procedura testata (commit), apoi a trecut prin lantul complet de editare fara nicio modificare de linii:

recalculeaza_totaluri_vanzari(1049, 12.5)   -- COMMIT, pregatire
  IncarcaVanzareDinNota -> tvanz.discount = 12.5000       <- proba C2
MyDeschideTranzactie()
  OSCRIE_IN_FISIERE(2, .T., .T.)  => 1
  OSCRIE_IN_FISIERE(0, .T., .T.)  => 1
  pack_contafin.finalizeaza_modificare_nota => 1
    [in tranzactie] cod 1140897 -> 1140898, discount INCA 12.50   <- proba C3
  ScrieArticoleFacturaEditate(1049) => 1
MyInchideTranzactie(1)                       -- COMMIT
  [dupa commit] discount 12.50, ftva 735.46, tva 154.43, ctva 889.89   <- proba C5
recalculeaza_totaluri_vanzari(1049, 0)      -- COMMIT, restaurare

Trei lucruri pe care doar acest bloc le stabileste:

1. tvanz.discount chiar aduce discountul din VANZARI. IncarcaVanzareNota (ofacturare_editare.prg:177) selecteaza v.discount direct din VANZARI, iar helperul citeste de acolo (:485-486). Daca cursorul l-ar fi adus 0, salvarea ar fi sters discountul documentului — exact riscul din briefing. Nu se intampla.
2. finalizeaza_modificare_nota nu atinge DISCOUNT. Citit in tranzactie, dupa realinierea COD-ului: 1140897 -> 1140898, discount inca 12.50. Concorda cu corpul lui actualizeaza_vanzari (:16012-16022), care scrie doar VANZARI_DETALII.STERS, VANZARI.COD si VANZARI.STERS.
3. Discountul supravietuieste unei salvari complete, cu totalurile recalculate coerent (735.46 + 154.43 = 889.89).

NULL nu ajunge azi in procedura pe calea VFP decat daca VANZARI.DISCOUNT e NULL in baza — helperul trimite NULL doar la Isnull(discount) (:546), altfel trimite valoarea. Pe 1049 discountul e 0, nu NULL, deci calea reala trimite mereu o valoare. Ramura NULL a helperului nu e atinsa de acest test; contractul procedurii pe NULL este insa dovedit direct (blocurile A si B).

Verificarea independenta prin sqlplus (dupa test, cu procesul VFP terminat)

MARIUSM_AUTO/…@ROA_CENTRAL:

1049: cod=1140898 sters=0 in_valuta=0 discount=0 discount_tva=0 val_ach=263.31
      ftva=747.96 tva=157.06 ctva=905.02 valval=747.96 tvaval=157.06 totval=905.02
linii 1049: det=1581 sters=0 cant=2 pret=302.51 pret_ach=10
            det=1582 sters=1 cant=1 pret=121.30 pret_ach=0
            det=1583 sters=0 cant=1 pret=150.00 pret_ach=10
            det=1588 sters=0 cant=3 pret=50.00  pret_ach=77.77
1037: cod=1140730 sters=0 in_valuta=1 discount=0 discount_tva=0 val_ach=100
      ftva=1053.76 tva=221.29 ctva=1275.05 valval=200 tvaval=42 totval=242
      id_valuta=2 curs=5.2688 multiplicator=1        -- NEATINS
1050: cod=1140895 discount=0 total_cu_tva=1924.59    -- NEATINS
vact_tot 08.2026: cod=1140897 randuri=10 sterse=10 | cod=1140898 randuri=10 sterse=0
v$transaction pe MARIUSM_AUTO: 0 randuri

1049 e exact in starea de dinaintea acestui test pe toate coloanele de valoare — singura schimbare e COD. Structura liniilor e neschimbata (aceleasi 3 active, 1582 ramane stearsa din testul precedent).

Date de test consumate

• Un singur cod realocat: 1140897 -> 1140898 pe id_vanzare = 1049. Cine reia testul citeste cod-ul curent din VANZARI, nu-l presupune.
• Nimic altceva. Zero linii adaugate sau sterse, zero valori de totaluri lasate schimbate, DISCOUNT restaurat la 0. Blocurile A si B nu consuma nimic (ROLLBACK).
• id_vanzare = 1050 si id_vanzare = 1037 sunt neatinse, verificat prin sqlplus.

Ce NU acopera nici acest test

• Liniile din seturi (id_vanzare_set nenul) — niciunul dintre documentele folosite nu are asa ceva, deci ramura union all din agregare (:16178-16209), care ia totalurile din capul de set, ramane neatinsa. Neschimbat fata de raportul precedent.
• Lantul complet de editare pe un document in valuta — imposibil azi: niciun document in valuta nu e din luna curenta (vezi mai sus). Doar recalculul Oracle e acoperit.
• Ramura NULL a helperului (ofacturare_editare.prg:546) — cere VANZARI.DISCOUNT NULL in baza, ceea ce nu s-a fabricat.
• discount_evidentiat = 1 — toate documentele folosite au 0; ramura care distribuie discountul pe linii nu e atinsa.
• Cele cinci validari din inainte_de_do_termin, frm_modific2024, al doilea punct de intrare (comun.vc2:2491) si calea de ROLLBACK la esec partial raman neacoperite, ca inainte.

Igiena la iesire

Zero tranzactii deschise (v$transaction, 0 randuri), zero procese vfp9.exe (tasklist), zero commituri git sau SVN. Niciun fisier de productie atins: singurul fisier nou este suita de test. PACK_FACTURARE, omodificari.vc2, ofacturare_comun.vc2, comun.vc2, ofacturare_editare.prg si COMUN\clase\ofacturare.vc2 sunt neatinse.