romfast/roafacturare
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
5b52cb39991987f98cc0e34dbb5d0768d122836d
roafacturare/docs/propunere_fact008_precizie_pret.md
Marius Mutu ca3c5d7eea docs: runda 6 - cercetari, propuneri si conventia mediului Oracle 
Cercetarile si propunerile rundelor 4-6 pe editarea facturii emise. Starea
rundei 6 si ce s-a stabilit intra in progres.md.

Nou: docs/conventii_mediu_oracle.md - pe dev/test se lucreaza numai cu
ROA_CENTRAL si schemele CONTAFIN_ORACLE si MARIUSM_AUTO; schema ACN nu se
foloseste. Scripturile de pachet sunt necalificate, deci schema tinta o
decide sirul de conectare, nu fisierul.

roafacturare.pj2 regenerat de git_sync.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013gYCNE26G1G7UoGu2ju7aS
2026-08-20 16:35:03 +03:00

4.8 KiB
Raw Blame History

Propunere: precizia pretului de achizitie la trimiterea liniilor de factura (FACT-008)

Diagnostic: docs/cercetare/rec_fact008_pret_achizitie_zecimale.md. Diff: docs/diff_fact008_precizie_pret.patch — aplicat pe 18.08.2026, necomis.

In productia vending optiunea PPRET a fost pusa pe 4 si eroarea a disparut, confirmand diagnosticul. Modificarea de cod acopera acelasi lucru independent de configurare.

Modificarea propusa

Un singur tipar, in 8 locuri: serializarea in SQL foloseste precizia declarata a cursorului, nu gnPPret / gnPPretV / gnPPretVal singure.

- Alltrim(Str(poArt.pret_achizitie,18,gnPPret))
+ Alltrim(Str(poArt.pret_achizitie,18,Max(gnPPret,4)))

Cursoarele sunt deja definite pret_achizitie N(20, Max(gnPPret,4)), pretd N(20, Max(gnPPretVal,4)), pretv_orig N(20, Max(gnPPretV,4)) — modificarea doar aliniaza emiterea cu declaratia. Coloanele tinta din Oracle suporta precizia (STOC.PRET/PRETV/PRETD au scale 4, VANZARI_DETALII_TEMP.PRET_ACHIZITIE scale 6).

fisier linii camp
COMUN\clase\ofacturare.vc2 (frm_facturare_articole.do_scrie_articole) 14073, 14074, 14087 pret_achizitie, pretd, pretv_orig
COMUN\clase\ofacturare.vc2 (frm_facturare_articole2.do_scrie_articole) 18108, 18109, 18122 pret_achizitie, pretd, pretv_orig
COMUN\programe\ofacturare_stoc.prg (adauga_articol_factura_stoc) 360, 361 pret_achizitie, pretd

pret_achizitie rezolva eroarea raportata. pretd si pretv_orig sunt aceeasi eroare, latenta: descarca_gestiune le compara si pe ele prin egalitate exacta (A.PRETD = V_PRETD, A.PRETV = V_PRETV_ALES), iar coloanele din STOC au tot scale 4. La vending nu se manifesta (pretv = 0, pretd = 0 peste tot), dar pe o gestiune tinuta la pret de vanzare ar da acelasi FACT-008. Daca se prefera modificarea strict minima, se pot pastra doar cele 3 linii cu pret_achizitie — spun explicit ca as include si celelalte 5.

Ce NU propun

  • Rotunjire la importul eFactura (ROACONT\COMUN\clase\anaf_efactura.vc2, liniile 12727, 12744, 12786). Ar strica valoarea receptiei: 8.559 x 500 = 4279.50 fata de 4279.28 cat e valoarea reala a facturii. Zecimalele sunt corecte, transportul din facturare e cel gresit. (Ramane discutabila inconsecventa dintre 4 la 12744/12786 si 6 la 12727 — dar e cosmetica, nu cauza.)
  • Relaxarea predicatului din pack_facturare.descarca_gestiune (round(A.PRET, ...)). Pe un articol cu mai multe loturi in aceeasi gestiune ar putea potrivi lotul gresit si ar descarca alt cost.

Deblocare imediata in productie, separat de cod

OPTIUNI.PPRET de la 3 la 4 la vending — facut de Marius pe 18.08.2026, eroarea a disparut. Are efect fara recompilare si a deblocat toate cele 14 articole din stoc care dadeau FACT-008. Cu PPRET = 4, Max(gnPPret,4) din diff devine oricum echivalent, deci cele doua masuri nu se bat cap in cap. Optiunea ramane pe 4 pana cand versiunea noua e in productie.

Aplicare (dupa aprobare)

  1. .prg — editare directa, atentie la CRLF.
  2. .vc2 — editare byte-safe (fisierul e cp1250 cu diacritice; liniile atinse sunt ASCII) apoi write-back cu txt2vcx.ps1 -AllowComun, si verificare pe binar prin reconversie in cache temporar + diff, nu pe mtime.
  3. COMUN\ e partajat de toate produsele ROA si versionat separat (comun.git) — modificarea atinge si ROAGEST/ROAACNPRO/ROAIMOB. Commit-ul se face din COMUN\.
  4. Changelog: intrarea intra la 2.11.15, tag :eroare: — versiunea nu se bumpeaza, 2.11.15 nu e inca in productie.
  5. Fara test headless util aici: eroarea apare doar cu un rand real din STOC cu pret pe 4 zecimale. Verificarea practica e o factura pe articolul 5155 dupa recompilare.

Scriptul PPRET = 4 pentru toate firmele: abandonat

Scriptul a fost scris si apoi sters (SCRIPTURI_CLAR\2026\08\ff_2026_08_19_01_COMUN_OPTIUNI_PPRET.sql). Decizia lui Marius, 19.08.2026: nu e nevoie de el.

Dupa ce intra versiunile cu Max(gnPPret,4), scriptul nu mai repara nimic, iar PPRET nu e doar precizie de transport — conduce si rotunjirea pretului unitar la NIR-ul introdus manual (ointroduceri.vc2: Round(valoare/cantitate, gnPPret)) si mastile de afisare. Pus pe 4 la toate firmele ar fi schimbat rotunjirea receptiilor manuale la toti clientii, ca sa repare ceva ce codul repara deja. versiune_db.txt a ramas nebumpat.

Ramane de acoperit prin cod, nu prin configurare: ROAGEST\Programe\ofactureaza.prg (liniile 267, 268, 280) inca trunchiaza, iar copiile COMUN din celelalte produse sunt in urma si primesc reparatia la urmatorul svn update plus recompilare.

La vending PPRET ramane pe 4 pana cand versiunea noua e in productie — acum e singurul lucru care tine facturarea in picioare acolo. Dupa punerea in productie se poate reveni la 3, daca nu se doresc preturi de achizitie pe 4 zecimale la receptiile manuale.