# 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.

```foxpro
- 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.