Marius Mutu
ca3c5d7eea
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
85 lines
4.8 KiB
Markdown
85 lines
4.8 KiB
Markdown
# 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.
|