romfast/roafacturare
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
fc9c3780df205498a96ac83fbb38b9ffdafbf1ce
roafacturare/docs/cercetare/rec_s4_valuta_dialog.md
Marius Mutu d9f5ca4226 docs: planurile, proiectarile si rapoartele de lucru intra in versionare 
Folderul docs\ era pana acum in afara oricarui control de versiuni - nici git,
nici SVN - desi contine planurile pe puncte, proiectarile si rapoartele de
cercetare pe care se sprijina modificarile din cod. O stergere acolo era
definitiva.

Fisierele intermediare (handoff-uri intre sesiuni, diff-uri deja aplicate) au
fost sterse inainte, nu versionate: ce era durabil in ele a intrat in antetele
fisierelor de test la care se refereau.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
2026-08-11 22:17:17 +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 (docs\handoff_decizia35_valuta_dialog.md): 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: docs\diff_s4_valuta_dialog.patch, docs\diff_s4_valuta_dialog_prg.patch, docs\diff_s4_valuta_dialog_test.patch

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