Files

Marius Mutu b5a7108f34 docs: cercetarile comune trec in COMUN, reziduul #6 dispare, progres.md la zi

Curatenie ceruta dupa inchiderea lui #6. Folderul cercetare\ NU se putea sterge
in bloc: plan_13 se sprijina pe el cu 85 de trimiteri, deci e baza de dovezi a
planului aflat in lucru. Impartirea:

- 14 cercetari trans-proiect trec in COMUN\docs\cercetare\ - valuta si curs,
  TVA/VANZARI, consumatorii VANZARI din toata suita, integrarile #10/#11/#12,
  watchdog VFP, proiectarea Oracle a lui S5, view-ul VVANZARI_ARTICOLE. Nu sunt
  ale ROAFACTURARE, iar #10/#11/#12 se reiau chiar din ele.
- 20 de rapoarte de executie ale lui #6, nereferite de nimic viu, sterse.
- 91 raman, neatinse.

Trimiterile catre handoff-urile si diff-urile intermediare deja desfiintate au
fost curatate peste tot (39 de fisiere): 50 catre handoff-uri, 37 catre diff-uri
aplicate, plus caile celor mutate in COMUN. Zero trimiteri rupte ramase.

progres.md preia rolul de predare: ce ramane din #6 (cele sase documente
parazite, cele doua esecuri reale din S8 pe factura din aviz), cifrele de test
citite din log, si cele doua capcane de mediu platite - .FXP vechi executat in
locul .prg-ului, si GETFONT() care atarna un formular instantiat fara goApp.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3

2026-08-11 22:31:42 +03:00

4.6 KiB

Raw Blame History

Livrare - decizia 35: intrare directa in valuta la adaugarea de linii

Implementare pe baza cercetarii de contract deja facute (handoff intermediar (sters)): premisa initiala (atingerea ofacturare.vc2) a fost infirmata acolo - dialogul frm_articol_factura nu citeste poDate.in_valuta, ramura de valuta e condusa de poArticol.tip_valuta/Curs/ multiplicator/nume_val. Toata lucrarea de mai jos e in apelant, ofacturare.vc2 nu a fost atins.

Ce s-a schimbat

COMUN\programe\ofacturare_editare.prg - CreeazaPoArticolNouTvd extinsa cu 5 parametri optionali (tlInValutaDoc, tnCursDoc, tnMultDoc, tcNumeValDoc, tnIdValutaDoc); cand tlInValutaDoc e adevarat, suprascrie tip_valuta=1/Curs/multiplicator/nume_val/id_valuta cu valorile documentului. Fara parametri (cei 2 apelanti de test si semnatura veche), comportamentul ramane identic (parametrii nepasati sunt .F., IF m.tlInValutaDoc nu se activeaza).

COMUN\clase\omodificari.vc2:

cmdAdaugaArticol.Click - inainte de Createobject, citeste tvanz.in_valuta/curs/ multiplicator/nume_val/id_valuta (deja incarcate de IncarcaVanzareNota, nicio interogare Oracle noua) si le paseaza la CreeazaPoArticolNouTvd. Cand documentul nu e in valuta, garda Used('tvanz') cade pe valorile implicite (0/1/1/''), comportament identic cu azi.
AdaugaLinieTvdDinArticol - rescrisa sa ramifice pe toArticol.tip_valuta: =1 citeste direct pretftva_val/pretctva_val/discount_unitar_val/discount_unitar_ctva_val (deja in valuta documentului, fara reconversie); =0 pastreaza neatinsa conversia RON->valuta existenta (* multiplicator / curs).

Testare

Toate rulate DUPA ultima editare de cod (verificat pe mtime: binar 18:53, .prg 18:52, test 18:57; rulari 18:58+), watchdog_vfp.ps1 -AutoDismiss, cifre numarate din log (REZULTAT/done):

Test	Rezultat	Baseline	Regresie?
`test_adauga_linie_valuta` (extins, sub-blocurile A+B)	16 PASS / 0 FAIL	6/0	nu - extins cu scenariul B
`test_page3_articole`	14 PASS / 2 FAIL	14/2	nu (cele 2 = artefact headless cunoscut, coloane grid)
`test_incarca_vanzare_din_nota`	5 PASS / 0 FAIL	5/0	nu
`test_adauga_linie_articol`	20 PASS / 0 FAIL	20/0	nu
`test_ui_sterge_linie`	8 PASS / 0 FAIL	8/0	nu
`test_verdict_act_rul`	26 PASS / 0 FAIL	26/0	nu

Confirmare absenta dublei conversii (verificarea centrala ceruta): scenariul B din test_adauga_linie_valuta.prg construieste poArticol cu tip_valuta=1, Curs=5.2688, multiplicator=1 (prin CreeazaPoArticolNouTvd extinsa) si pretftva_val=200 (pretul introdus direct in valuta, ca de la un dialog real cu tip_valuta=1). Dupa AdaugaLinieTvdDinArticol, tvd.pret ramane 200.00 - nu 1053.76 (200*curs, conversie in plus) si nu 37.96 (200/curs, conversie in sens gresit). Bara de totaluri (ActualizeazaBaraTotaluri) recalculeaza corect echivalentul RON (1053.76 = 200 * 5.2688).

Scenariul A (existent, tip_valuta=0, dialogul lucreaza in RON) a fost lasat neschimbat ca test si continua sa treaca - confirma ca ramura RON a AdaugaLinieTvdDinArticol n-a fost atinsa.

Ce ramane netestat headless (pentru verificarea pe ecran a lui Marius)

frm_articol_factura.Show(1) cu poArticol.tip_valuta=1 populat de noul apelant: ca userul chiar vede/editeaza caseta de valuta (nu RON) cand adauga o linie pe o factura deja emisa in valuta - comportamentul intern e verificat (do_calculeaza_*/tip_valuta deja folosite in productie de frm_facturare_articole, cf. cercetarii), dar interactiunea vizuala reala nu.
Cazul de la punctul 2 din "Ce ramane de decis de Marius" (cercetarea de contract): un articol cu politica de pret proprie in valuta (tip_valuta=1 din alta sursa), pe un document in alta valuta - implementarea curenta suprascrie necondiționat cu valorile documentului; nu exista date de test pentru acest caz, ramane teoretic.

Write-back

txt2vcx.ps1 -AllowComun pe omodificari.vc2 rulat si confirmat cu succes (fidelity-check OK, omodificari.vcx/.vct actualizate, mtime nou). ofacturare_editare.prg e sursa directa, fara write-back necesar.

Fisiere atinse

COMUN\programe\ofacturare_editare.prg (+ .pre_s4_valuta.bak)
COMUN\clase\omodificari.vc2 (+ .pre_s4_valuta.bak), scris in omodificari.vcx/.vct
COMUN\utile\Teste\editare_factura\test_adauga_linie_valuta.prg (+ .pre_s4_valuta.bak)
Patch-uri: diff aplicat (sters), diff aplicat (sters), diff aplicat (sters)

Fara commit (git/SVN). Zero scrieri in Oracle - toate testele lucreaza pe cursoare in memorie.

4.6 KiB Raw Blame History