romfast/roafacturare
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b5a7108f34fce3ca78a00ece36dca2f65bda9641
roafacturare/docs/cercetare/rute_scriere_antet.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

250 lines
17 KiB
Markdown
Raw Blame History

# Rute de scriere pe antetul unui document DEJA EMIS (VANZARI/ACT/RUL) — Grupele A/B/C
Cercetare read-only, fara nicio modificare de cod. Sfera: `pack_facturare.modifica_date_factura`
(14 campuri, deja documentat in `modifica_date_factura_parametri.md`) e confirmata ca **singura**
cale directa pentru serie/numar/data act/data scadenta + ruta/delegat/masina/agent/dataora_exp/
id_facturare/listare_detaliata/text_aditional/tip_saft/efactura. Intrebarea de aici: exista alte
cai, pentru campurile din grupele A/B/C, in afara drumului de emitere initiala.
**Rezumat**
| Camp | Verdict | Nota |
|---|---|---|
| A. ID_VENCHELT | NU (cu o rezerva) | vezi pct. 1.4 — posibil editabil direct in grid, neverificat pana la capat |
| A. ID_SECTIE | **DA** (nou, activ) | prin editare directa a notei contabile, pct. 1.3-1.4 |
| A. ID_RESPONSABIL | **DA** (nou, activ) | idem |
| A. ID_LUCRARE | **DA** (nou, activ) | idem |
| B. ID_FDOC (tip document) | NU | cautat, negasit — pct. 2 |
| B. ID_VALUTA | NU | cautat, negasit |
| B. Zi curs | NU | cautat, negasit |
| B. ID_CLIENT | NU | cautat, negasit |
| B. sursa/"altele" | NU | cautat, negasit |
| B. gestiune sursa | NU | cautat, negasit |
| B. politica de preturi | NU | cautat, negasit |
| C. opt_incasat/casa/serie chit/nr chit/incasat/POS | NU direct, PARTIAL indirect | scrise doar la emitere (pct. 3.1); posibila cale indirecta prin editarea notei contabile daca incasarea e pe acelasi `cod` (pct. 3.2, neconfirmat pana la capat) |
---
## 1. Grupul A — analiticele de antet (ID_VENCHELT, ID_SECTIE, ID_RESPONSABIL, ID_LUCRARE)
### 1.1 Unde traiesc si cum se scriu la emitere
Coloanele sunt pe `ACT` (`ACT.ID_VENCHELT%TYPE`, `ACT.ID_SECTIE%TYPE`, `ACT.ID_RESPONSABIL%TYPE`,
declarate asa in pachetul Oracle), nu pe `VANZARI`. La emitere, `frm_date_factura`/`frm_date_aviz`
(`COMUN\clase\ofacturare.vc2:9041-9706` / `:6900-7516`, controale `Ct_clb_venchelt`/`Ct_clb_sectie`/
`Ct_clb_responsabil`/`Ct_clb_lucrare`) populeaza variabilele de sesiune Oracle
`pack_facturare.nid_venchelt` / `nid_sectie_stoc` / `nid_responsabil` / `nid_lucrare`
(`ff_2026_08_06_10_COMUN_PACK_FACTURARE.sql:1884-1887`), care se scriu o singura data, uniform pe
tot documentul, in `INSERT INTO ACT_TEMP` la contabilizare (comentariul explicit de la linia 1286
din `PACK_CONTAFIN.pck`: *"Am completat ID_RESPONSABIL la instructiunile INSERT INTO ACT_TEMP"*).
Nicaieri in cele doua fisiere Oracle centrale nu exista `UPDATE ACT SET ID_VENCHELT|ID_SECTIE|
ID_RESPONSABIL|ID_LUCRARE = ...` (grep combinat `UPDATE ACT ... SET` + fiecare coloana, zero
potriviri, atat in pachetul curent `ff_2026_08_06_10_COMUN_PACK_FACTURARE.sql` cat si in
`PACK_CONTAFIN.pck`, `PACK_UPDATE.pck`, `PACK_MIGRARE.pck` din `COMUN\docs`).
`frm_date_factura`/`frm_date_aviz` sunt instantiate **doar** din interiorul `ofacturare.vc2`
insusi (nu am gasit niciun `Createobject` catre ele in afara clasei) — sunt exclusiv wizard-ul de
la emitere, nu apar pe niciun flux de editare ulterioara.
**Concluzie partiala**: `modifica_date_factura` (calea documentata deja) NU atinge aceste 4
campuri, si nu exista niciun `UPDATE` Oracle separat pe ele. **Pana aici, verdictul era NU.**
### 1.2 Descoperire care schimba raspunsul: `frm_facturi.do_editare_factura` (functionalitate noua)
Commit-ul cel mai recent din branch (`97d1613`, *"#6 editare factura emisa: omodificari.vcx intra
in proiect"*) a adaugat exact ce lipsea. Exista deja o cercetare anterioara in acest depozit
(`docs\cercetare\rec_modific2024.md`, scrisa inainte de acest commit) care documenteaza clasa
`frm_modific2024` (`COMUN\clase\omodificari.vc2:6375+`, editor generic de nota contabila,
partajat cu ROAGEST) si concluziona explicit: *"clasa exista deja, dar codul apelant din
ROAFACTURARE NU exista inca — trebuie scris"*. **Acel gol a fost umplut** — am gasit apelantul,
cablat si activ:
`COMUN\clase\ofacturare_comun.vc2`, metoda `frm_facturi.do_editare_factura` (~linia 3690-3869):
- Garda: blocheaza daca factura a fost trimisa in eFactura (`EsteInEFactura`, `:3764-3767`).
- `IncarcaCursoareModificareNota(lnCod, pnAn, pnLuna, .F.)` (helper din `ofacturare_editare.prg`,
citit dar nemodificat) incarca nota contabila completa (`vact_tot`/`vrul_tot`/`vrul_obinv_tot`
filtrate pe `cod`) in cursoarele READWRITE `actactan`/`tact`/`rul_temp`/`trul`/
`rul_temp_obinv`/`trul_obinv` (`:3769`).
- `Omodif = Createobject([frm_modific2024], lnIdSet)` + `Omodif.Show()` (`:3796-3797`) — deschide
editorul modal pe cursorul `tact` deja incarcat cu nota facturii curente.
- Daca userul apasa Terminat (`buton = 1`, `:3799-3833`): deschide tranzactie manuala, sterge nota
veche (`OSCRIE_IN_FISIERE(2,.T.,.T.)`), rescrie din cursoarele editate (`tact`->`actactan`,
`trul`->`RUL_TEMP`, `trul_obinv`->`RUL_TEMP_OBINV`, cu `id_util`/`sters=0` noi),
`OSCRIE_IN_FISIERE(0,.T.,.T.)` (scriere noua), apoi
`pack_contafin.finalizeaza_modificare_nota(...)`, commit/rollback.
Acest `finalizeaza_modificare_nota` (`PACK_CONTAFIN.pck:8601-8651`, citat deja in
`rec_modific2024.md`) **resincronizeaza `vanzari`** dupa editare: `SELECT COUNT(*) FROM vanzari
WHERE cod = tnCod; IF > 0 THEN pack_facturare.actualizeaza_vanzari(tnCod, lnCodNou); END IF;`.
### 1.3 Ce e efectiv editabil in `tact`/`trul` — verificat prin `do_modifica`
`frm_modific2024.do_modifica` (`omodificari.vc2:13836-13957`) e mecanismul generic prin care un
camp din grid deschide un dialog de cautare (`cauta_alfa`) si apoi face `REPLACE` pe cursorul
corespunzator. Pentru `trul`/`trul_obinv` (nivel LINIE de nota, nu antet unic), `CASE` explicit
gestioneaza:
```
CASE m.lcControl = 'nrord' -> replace nrord with loCauta.nrord, id_lucrare with loCauta.id_lucrare
CASE m.lcControl = 'sectie' -> replace sectie with loCauta.sectie, id_valuta with loCauta.id_sectie (!)
CASE m.lcControl = 'nresp' -> replace nresp with loCauta.nume, id_responsabil with loCauta.id_responsabil
```//omodificari.vc2:13934-13943
Deci **ID_LUCRARE si ID_RESPONSABIL sunt editabile explicit**, pe cursorul `trul` (nivel de linie
RUL), prin acest mecanism, azi, din UI, prin `do_editare_factura`. Linia `sectie` are ce pare a fi
un bug preexistent (`replace ... id_valuta with loCauta.id_sectie` in loc de `id_sectie` — cod
existent, nu l-am atins, doar il semnalez ca observatie relevanta pentru evaluarea "functioneaza
sau nu in practica"): daca bug-ul e real, campul afisat `sectie` (text) se schimba, dar coloana
`id_sectie` propriu-zisa risca sa NU se actualizeze corect (se suprascrie `id_valuta` in loc).
Nu am testat comportamentul, doar am citit codul.
**ID_VENCHELT**: NU exista un caz `CASE m.lcControl = 'venchelt'` (sau `dst_chlt`) in
`do_modifica` pentru `trul`/`trul_obinv` — cautat explicit in tot procedeul (13836-13957), zero
potriviri. Insa Grid1 al clasei (proprietatile de coloana, in afara metodelor) are o coloana cu
`ControlSource = "dst_chlt"` (`omodificari.vc2:753, 2862, 7393` — a treia aparitie e in intervalul
propriu al clasei `frm_modific2024`), deci explicatia venit/cheltuiala **e afisata** in grid. Daca
acea coloana permite editare directa de text (nu prin popup de cautare) sau daca exista un alt
handler (buton dedicat, dublu-click) care leaga `id_venchelt`, nu am verificat pana la capat — vezi
"Necunoscute ramase". **Raspuns pentru ID_VENCHELT: NU confirmat ca ruta activa, dar cu o rezerva
neinchisa** (grid-ul afiseaza coloana, mecanismul de editare exact al ei nu a fost trasat complet).
### 1.4 Nivel LINIE vs. nivel ANTET
O nuanta importanta: campurile din grupul A, la nivel Oracle, traiesc pe `ACT` (fiecare linie de
nota isi are propriile `ID_VENCHELT`/`ID_SECTIE`/`ID_RESPONSABIL`/`ID_LUCRARE`), desi la EMITERE
se scriu uniform (aceeasi valoare pe toate liniile unui document, din variabilele de sesiune).
Editarea prin `frm_modific2024` e la nivel de LINIE (fiecare rand din `trul` se editeaza separat),
nu o singura bifa de antet — deci userul poate, teoretic, sa lase valori diferite pe linii diferite
ale aceleiasi facturi dupa editare, lucru care nu se putea intampla la emiterea initiala (uniforma).
Asta conteaza pentru orice raportare care presupune "un singur ID_SECTIE per factura".
**Verdict grup A**: **DA** pentru `ID_SECTIE`/`ID_RESPONSABIL`/`ID_LUCRARE` (cale noua, activa,
`frm_facturi.do_editare_factura` -> `frm_modific2024` -> `OSCRIE_IN_FISIERE` ->
`pack_contafin.finalizeaza_modificare_nota` -> Oracle `ACT`/`RUL`, cu resincronizare in `VANZARI`).
**NU confirmat** pentru `ID_VENCHELT` prin acelasi mecanism generic (`do_modifica` nu are caz
pentru el), dar cu rezerva de la 1.3 neinchisa complet.
---
## 2. Grupul B — identitate/sursa (fdoc, valuta, zi curs, client, altele, gestiune sursa,
politica preturi)
Controalele (`Ct_clb_fdoc`, `Ct_clb_valuta`, `Clb_zi_curs`, `Ct_clb_nume_client`, `Ct_clb_altele`,
`Ct_clb_gestiune_init`, `Ct_clb_politici_preturi`) au fost gasite **exclusiv** in metodele proprii
ale `frm_date_aviz`/`frm_date_factura`/`frm_date_aviz_lucrare` din `ofacturare.vc2` — acelasi
wizard de emitere de la grupul A (cautare `vfp_symbols.ps1 -Grep` pe toate cele 7 nume de
control, in tot proiectul indexat: 316 fisiere, zero potriviri in afara `ofacturare.vc2`).
Cautat in Oracle (pachetul curent + `PACK_CONTAFIN.pck` + `PACK_UPDATE.pck` + `PACK_MIGRARE.pck`):
`UPDATE VANZARI ... SET (ID_FDOC|ID_VALUTA|ID_CLIENT|ID_PART|ID_GESTIN|ID_POL) = ...` si
`UPDATE ACT ... SET` idem — zero potriviri (grep multiline, fereastra 400 caractere dupa
`UPDATE`). Toate cele 13 aparitii ale `UPDATE VANZARI` din pachetul curent au fost inspectate
individual (`sterge_factura`, `sterge_proforma`, `marcheaza_facturat`,
`scrie_corespondente_vanzari`, plus `modifica_date_factura`) — niciuna nu atinge aceste coloane
(ating `STERS`/`FACTURAT`/`ID_UTILFACT`/`DATA_FACTURAT`/`AVIZE`/`COD`/serie-numar-data-scadenta).
`frm_modific2024`/`do_editare_factura` (descoperirea de la grupul A) nu ajuta aici: cursoarele pe
care le editeaza (`tact`/`trul`/`trul_obinv`) sunt nota contabila (conturi, sume, gestiuni de
STOC, TVA) — nu contin fdoc/valuta document/client/politica de preturi ale facturii; acestea sunt
proprietati ale `VANZARI`, populate o singura data la `scrie_factura2`/`scrie_in_vanzari`, in afara
oricarui flux gasit de editare ulterioara.
**Verdict grup B: NU**, pentru toate cele 7 campuri — cautat si negasit, in ambele straturi
(Oracle: pachetul de facturare curent + cele 3 pachete conexe; VFP: toate clasele indexate de
`vfp_symbols.ps1`, 1128 clase / 9281 metode / 2461 proceduri).
---
## 3. Grupul C — incasarea
### 3.1 Unde se scrie la emitere
Controalele din `frm_alte_date` (`COMUN\clase\ferestre_cere_date.vc2:2219+`) — `opt_incasat`,
`Cb_casa`, `Clb_serie_chit`, `Clb_nrchit`, `Clb_incasat`, `chkPOS` — au `ControlSource` pe
proprietati ale obiectului `poDate` (`poDate.nIncasatPos`, si prin cod pe `poDate.incasat`,
`poDate.nr_incasare`, `poDate.ntip_incasare`, `poDate.id_casa`, `poDate.serie_chit`), NU pe un
cursor legat direct de tabel. `frm_alte_date` e instantiat exclusiv din
`frm_facturare_articole(2).inainte_de_do_termin` si din doua fluxuri de listare
(`ofacturare.prg:listare_protocol`, `ofacturare_stoc.prg:oscrie_vanzare_din_stoc`,
`oproceduri_listari.prg:listare_protocol`) — toate parti ale fluxului de EMITERE, niciuna de
editare ulterioara.
La `do_scrie_factura` (`ofacturare.vc2:14260-14389`, ambele forme `frm_facturare_articole` si
`frm_facturare_articole2`), valorile din `poDate` sunt asamblate intr-un string
`lcListaIncasare` (format `tip|suma|id_casa;...`) si trimise ca parametru la
`pack_facturare.scrie_factura2` / `scrie_factura_avize` / `scrie_proforma` (apel RPC unic, la
emitere). In Oracle, `scrie_factura2` cheama intern `pack_facturare.scrie_incasari` (linii 6204,
7034 din pachetul curent), care parseaza lista si cheama `scrie_incasare2` per linie
(`:13096-13168` -> `:13170+`) — aceasta insereaza o **nota contabila noua in `ACT_TEMP`**
(coloane vazute: `ACT.SUMA`, `ACT.ID_PARTD` pentru casa/banca, `ACT.ASCC`/`SCD`/`ASCD`,
`ACT_TEMP.PAYMENTCODE`), adica incasarea devine ea insasi o linie de jurnal (cont 5311/5121 etc.
vs. 4111), scrisa prin acelasi flux `ACT_TEMP -> ACT` ca restul documentului, nu un camp separat
pe `VANZARI`. `scrie_incasare2` nu are niciun apelant in afara lui `scrie_incasari` (cautat cu
grep in tot pachetul de facturare — un singur call-site).
### 3.2 Cale de schimbare DUPA emitere
Nu exista nicio procedura Oracle de tip "modifica_incasare"/"corecteaza_incasare" (cautat
`PROCEDURE ... (modifica|corecteaza|actualizeaza)...incasa...` in pachetul curent si
`PACK_CONTAFIN.pck` — zero potriviri). `scrie_incasari`/`scrie_incasare2` nu au niciun apelant VFP
direct (cautat in tot proiectul indexat — zero potriviri) — sunt folosite doar intern, o singura
data, la emitere.
**PARTIAL, neconfirmat pana la capat**: incasarea scrisa la emitere e o linie de nota contabila
(`ACT`/`RUL`) ca oricare alta. Daca acea linie foloseste acelasi `cod` (acelasi document contabil)
ca restul facturii, atunci mecanismul nou de la Grupul A (`frm_facturi.do_editare_factura` ->
`frm_modific2024`) ar incarca-o si pe ea in grid — si, editand campurile generice de nota
(cont/gestiune/suma, prin acelasi `do_modifica` sau direct in grid), un utilizator ar putea
schimba indirect suma/contul incasarii, deci si `casa`/`suma incasata` efectiva. **Nu am confirmat
daca incasarea primeste acelasi `cod` sau un `cod` separat** — ar necesita fie testare live
(interzisa aici, doar cercetare pe cod), fie citirea completa a insertiei din `scrie_incasare2`
(am citit doar semnatura si primele ~35 linii, nu INSERT-ul propriu-zis in `ACT_TEMP`). Marchez
explicit ca necunoscuta ramasa, nu ca "DA" confirmat.
`opt_incasat`/`chkPOS`/serie-numar chitanta/bon **ca atare** (proprietati `poDate` folosite doar
pentru alocarea de numere de serie si generarea listei `lcListaIncasare`) nu au niciun camp
persistent separat pe care sa-l poata atinge editarea ulterioara a notei — nu exista coloane
`VANZARI.OPT_INCASAT`/`VANZARI.SERIE_CHIT` in tot ce am cautat.
**Verdict grup C**: NU pentru o cale directa/documentata de schimbare dupa emitere; PARTIAL,
neconfirmat, prin editarea generica a notei contabile (acelasi mecanism nou de la Grupul A),
DACA incasarea partajeaza `cod`-ul cu restul documentului.
---
## Ce am cautat (pentru un "NU" verificabil)
- **Oracle**: `D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\08\ff_2026_08_06_10_COMUN_PACK_FACTURARE.sql`
(17020 linii, pachetul curent) — grep pe `UPDATE VANZARI`, `UPDATE ACT`, `UPDATE DOCUMENTE` (toate
aparitiile citite in context), plus grep combinat `UPDATE <tabel> ... SET <coloana> =` (fereastra
multiline 300-400 caractere) pentru fiecare coloana din grupele A/B/C. Idem pe
`D:\ROA\ROAFACTURARE\COMUN\docs\PACK_CONTAFIN.pck` (9041 linii), `PACK_UPDATE.pck` (2420 linii),
`PACK_MIGRARE.pck` (407 linii).
- **VFP**: `vfp_symbols.ps1 -Grep -CodeOnly` (index complet: 316 fisiere, 1128 clase, 9281 metode,
2461 proceduri) pentru fiecare nume de coloana Oracle si fiecare nume de control VFP din enunt
(`Ct_clb_venchelt/sectie/responsabil/lucrare/fdoc/valuta/altele/gestiune_init/politici_preturi`,
`Clb_zi_curs`, `opt_incasat`, `Cb_casa`, `Clb_serie_chit`, `Clb_nrchit`, `Clb_incasat`, `chkPOS`).
Pentru fiecare formular gasit (`frm_date_factura`, `frm_date_aviz`, `frm_alte_date`), am cautat
toti apelantii (`Createobject("...")`) in tot proiectul indexat, ca sa confirm ca sunt doar pe
fluxul de emitere.
- **Citire, fara scriere**: `ofacturare_comun.vc2` (metoda `do_editare_factura`, ~3690-3869) si
`ofacturare_editare.prg` (integral, 457 linii) — apartin altui fir de lucru, doar citite.
- `omodificari.vc2` (16464 linii) — clasa `frm_modific2024`: citite integral `do_modifica`
(13836-13957) si `do_salvare` (13985-14042); NU am citit toate cele ~180 de metode ale clasei
(Grid1.Column*, pgfArticole.*) — posibil sa existe alte cai de editare directa in grid,
nedescoperite prin `do_modifica`.
## Necunoscute ramase
1. **ID_VENCHELT** (grup A): daca e editabil in grid-ul `frm_modific2024` prin alt mecanism decat
`do_modifica` (coloana `dst_chlt` exista in grid) — neverificat pana la capat.
2. **Incasarea pe acelasi `cod`** (grup C): daca linia de incasare scrisa de `scrie_incasare2`
foloseste acelasi `cod` ca restul facturii (ceea ce ar face-o editabila prin
`do_editare_factura`) — necesita citirea INSERT-ului efectiv in `ACT_TEMP` din
`scrie_incasare2` (nu doar semnatura, citita aici doar partial) sau verificare pe date reale.
3. **Bug-ul de la `sectie`** (`omodificari.vc2:13941`, `id_valuta with loCauta.id_sectie` in loc de
`id_sectie`) — semnalat ca observatie, nu investigat mai departe (nu face parte din intrebare,
dar afecteaza increderea in verdictul "DA" pentru `ID_SECTIE": campul e teoretic editabil, dar
codul care il scrie pare sa aiba un bug care ar putea sa nu-l actualizeze corect in practica).
Reference in New Issue View Git Blame Copy Permalink