roafacturare/docs/cercetare/rute_scriere_antet.md

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