roafacturare/docs/cercetare/rec_modific2024.md

# Cercetare frm_modific2024 — editare directa act/rul in ROAFACTURARE

## 1. Localizare frm_modific2024

Clasa `frm_modific2024` e definita in `D:\ROA\ROAFACTURARE\COMUN\clase\omodificari.vc2`
(clasa incepe la `omodificari.vc2:6375`; metodele proprii ale lui `frm_modific2024` sunt la
liniile `12200`-`15319`). Text `.vc2` (492 942 octeti, 02.08.2026 12:28) e mai nou decat
binarul `.vcx` (64 144 octeti, 02.08.2026 12:24) — cu ~4 minute, deci sincronizat, nimic
neconvertit ramas in urma.

Important: `omodificari.vc2` NU e specific unui singur produs — exista un fisier aproape
identic si in `D:\ROA\ROAGEST\COMUN\clase\omodificari.vc2` (aceleasi metode, linii aproape
identice, cf. `_symbols.tsv` per-produs). `COMUN/` e propriul working copy git per produs
(cf. CLAUDE.md), deci **frm_modific2024 exista deja, azi, in checkout-ul COMUN al
ROAFACTURARE** — nu trebuie adus/portat de nicaieri, doar instantiat.

E o **clasa .vcx instantiabila** (`Createobject([frm_modific2024], lnIdSet, ...)`), nu un
`.scx` monolitic. Ascendenta: `frm_modific2024 -> _frmbase (_frm_base.vc2:7) -> _form
(_baza.vc2:157) -> form`.

## 2. Ce face efectiv

Editeaza **cursoare locale in memorie** `tact` / `trul` / `trul_obinv` (READWRITE), NU
tabelele Oracle `ACT`/`RUL` direct:

- `Init` (`omodificari.vc2:13510-13616`) primeste `tnIdSet, tlNotaNoua, toBackupXML, toSet,
  tlVizualizare` — nu incarca date, doar configureaza UI (readonly pe coloane cand
  `id_set` e "specializat", vizibilitate butoane).
- `do_modifica` (`12906-13027`), `do_sterge` (`13111-13185`), `do_adauga` (`12615-12663`)
  editeaza direct pe `SELECT tact` / `SELECT trul` — grid-uri legate de aceste cursoare.
- `inainte_de_do_termin` (`13316-13508`) ruleaza validari (`verificare_note_contabile`,
  echilibru conturi 4426-4428, `VerificaAvertizareExigibilizareTVA`) inainte de a permite
  inchiderea formularului cu `gnButon=1`.
- `do_termin` in sine e mostenit din `_frmbase` (`_frm_base.vc2:363-376`): doar seteaza
  `gnButon=pnButon=Buton=pnIesire=1` si inchide formularul — **nu scrie nimic in baza de
  date**. Scrierea e responsabilitatea apelantului, dupa `.Show()`.

**Salvarea reala** (in codul apelant, vezi pct. 5) trece prin `ACT_TEMP`/`RUL_TEMP` +
`oscrie_in_fisiere.prg` + pachetul Oracle `PACK_CONTAFIN`, intr-o tranzactie manuala
(`SQLSetProp(gnhandle,'Transactions',2)` ... `COMMIT`/`ROLLBACK`).

Protectii: `glLunaInchisa` (luna inchisa → return), verificare sucursala curenta pe stergere
(`do_sterge:13129-13136`), verificare referinte incasari/plati inainte de stergere
(`ReferinteDocument`, `do_sterge:13152`), validare structura nota (`verificare_note_contabile`
in `inainte_de_do_termin`).

## 3. Reutilizabilitate din ROAFACTURARE

**Direct reutilizabila, fara portare** — clasa e deja in `ROAFACTURARE\COMUN\clase\omodificari.vc2`,
iar `COMUN\clase` e deja inregistrat in `SET CLASSLIB`/`SET PROCEDURE` din
`Programe\roafacturare.prg` (verificat ca `omodificari.vc2` foloseste variabile globale
standard ROA: `gnAn`, `gnLuna`, `goExecutor`, `gcs`, `gnIdUtil`, `glLunaInchisa` — toate deja
setate de bootstrap-ul ROAFACTURARE). Nu am gasit dependinte de clase/proceduri absente din
ROAFACTURARE — `verificare_note_contabile`, `update_saft_taxtable`, `backupxml` etc sunt tot
in `COMUN`, deci deja disponibile.

Ce lipseste NU e clasa in sine, ci **codul apelant** (echivalentul `afisjurcom.do_modifica`)
care: (a) incarca `vact_tot`/`vrul_tot`/`vrul_obinv_tot` filtrate pe `cod` in `tact`/`trul`/
`trul_obinv`, (b) deschide tranzactia, (c) apeleaza `oscrie_in_fisiere` de doua ori (sterge +
scrie), (d) apeleaza `pack_contafin.finalizeaza_modificare_nota`, (e) inchide tranzactia. Acest
cod nu exista inca in ROAFACTURARE si trebuie scris nou, dupa modelul de la pct. 5-6 (dar e
~40 linii, nu o clasa noua).

## 4. Punctul de agatare in ROAFACTURARE: frm_facturi

`frm_facturi` e in `COMUN\clase\ofacturare_comun.vc2:1168`, ascendenta `frm_facturi ->
_frmbase -> _form -> form` (aceeasi baza ca `frm_modific2024`).

- `do_modifica` (`ofacturare_comun.vc2:4382-4482`): deschide un formular **diferit**,
  `frm_modifica_factura` (editeaza doar metadate: ruta/delegat/agent/masina/text
  aditional/data act/serie act — NU sume), apoi cheama `pack_facturare.modifica_date_factura(...)`.
  La linia 4432 exista deja garda exacta ceruta de utilizator:
  `If poRec.sters = 0 AND NVL(m.pnEFactura,0) = 0` — verifica `anaf_efactura` (linia 4428) si
  blocheaza cu mesajul *"Nu puteti face modificari pe inregistrarile sterse sau facturile
  trimise in eFactura!"* daca factura a plecat deja. **Acesta e modelul de garda de reutilizat**
  pentru o actiune noua "editare directa".
- `do_sterge` (`4503-4719`) e modelul arhitectural cel mai apropiat de ce se cere: incarca
  `vact_tot`/`vrul_tot`/`vrul_obinv_tot` filtrate pe `cod` in `actactan`/`rul_temp`/
  `rul_temp_obinv` (4573-4615), arata un formular de verificare (`Createobject('verificare')`,
  4620), deschide tranzactie manuala (4625), apeleaza `OSCRIE_IN_FISIERE(2,.F.,llRul)` (4632),
  apoi `pack_contafin.finalizeaza_stergere_nota(...)` (4652-4653), commit/rollback (4662-4673).
  Cazul special "eProforma" foloseste in schimb un singur apel PL/SQL,
  `pack_facturare.sterge_proforma` (4549-4560); cazul fara randuri in `act` foloseste
  `pack_facturare.sterge_factura` direct (4689).
- **Corectie fata de ipoteza initiala**: nu exista `nid_cw` in `ofacturare_comun.vc2`.
  Vizibilitatea/activarea butoanelor `do_modifica`/`do_sterge` e controlata prin flag-urile
  `This.lactiv3`/`This.lactiv4` (definite in `_frm_base.vc2`, default `.F.`) si prin variabila
  globala `gcAcces` (sir de tokeni gen `"4;"` pentru dreptul de stergere — vezi
  `ofacturare_comun.vc2:4773-4776`, unde `glLunaInchisa` scoate tokenul `4;` din `gcAcces` si
  ascunde `Thisform.but_sterge1`). `nid_cw` exista doar in `ofundal.vc2` si
  `drept_grupuri.vc2` (proprietate pe clasa de fundal/toolbar, nefolosita in
  `ofacturare_comun.vc2`) — deci reteta de "adaugare actiune noua" e: (1) adauga metoda
  `do_<actiune>` pe `frm_facturi` dupa modelul `do_sterge`, (2) adauga un buton nou pe
  toolbar-ul formularului (langa `but_sterge1`) cu `Click` care cheama `Thisform.do_<actiune>()`,
  (3) controleaza vizibilitatea prin acelasi mecanism `gcAcces`/`lactivN` daca se doreste
  control pe drepturi, altfel doar prin garda `sters=0 AND eFactura=0` din pct. eFactura de mai
  sus.

## 5. Fezabilitate scriere (cel mai important)

**NU exista niciun `UPDATE`/`DELETE` direct pe `ACT`/`RUL` in cod VFP** (cautat
`update act `, `update rul `, `delete from act`, `delete from rul` in tot
`ROAFACTURARE` si `ROAGEST\COMUN` — zero rezultate). Singura cale de scriere e prin
tabelele staging Oracle `ACT_TEMP`/`RUL_TEMP`:

1. VFP populeaza cursoare `actactan`/`rul_temp`/`rul_temp_obinv` (READWRITE, incarcate din
   view-urile `vact_tot`/`vrul_tot`/`vrul_obinv_tot`).
2. `COMUN\programe\oscrie_in_fisiere.prg` (10 461 octeti, 25.03.2026): parametrul
   `tnScrie_Sterge` (0=scriere, 2=stergere) — apeleaza `pack_contafin.init_scriere_act_rul_local`
   (linia 121), apoi `sql_temp_insert('actactan','ACT_TEMP')` / `sql_temp_insert('rul_temp',
   'RUL_TEMP')` care fac `INSERT INTO ACT_TEMP`/`RUL_TEMP` rand cu rand (liniile 127-136, 272-274
   — singurele DML explicite din acest fisier, si sunt pe tabelele `_TEMP`, nu pe `ACT`/`RUL`),
   apoi `pack_contafin.final_scriere_act_rul_local` (linia 141-143) care, in Oracle, ruleaza
   `SCRIE_IN_ACT`/`STERGE_DIN_ACT` din `PACK_CONTAFIN.pck` — **acolo** se face efectiv
   `UPDATE ACT SET STERS=1 ...` (stergere) sau `INSERT`/`UPDATE ACT_TEMP -> ACT` (scriere) prin
   PL/SQL, in Oracle, nu in VFP.
3. Editarea NU suprascrie randul vechi: la modificare, randurile vechi din `ACT`/`RUL`/`RUL_OBINV`
   raman cu `STERS=1`, iar un document nou (`cod` nou, acelasi `id_fact`/`id_factd`) e scris in
   locul lor — comportament confirmat explicit ca "nu e bug" in
   `D:\ROA\ROAGEST\COMUN\docs\flux-modificare-stergere-nota-jurnal.md`.
4. `pack_contafin.finalizeaza_modificare_nota` (`PACK_CONTAFIN.pck:8601-8651`) — apelata dupa
   `oscrie_in_fisiere` — **deja contine sincronizarea cu `vanzari`**:
   ```
   SELECT COUNT(*) INTO lnEInVanzari FROM vanzari WHERE cod = tnCod;
   IF lnEInVanzari > 0 THEN pack_facturare.actualizeaza_vanzari(tnCod, lnCodNou); END IF;
   UPDATE atasamente_vanzari SET cod = lnCodNou WHERE cod = tnCod;
   ```
   si simetric, `finalizeaza_stergere_nota` (`8653-8709`) apeleaza
   `pack_facturare.sterge_din_vanzari(tnCod, tnAn, tnLuna, tnIdUtil)`.
   **Acesta e precedentul concret ca "editarea act/rul actualizeaza automat vanzari"** — dar
   sursa pachetului `PACK_FACTURARE` (unde traiesc `actualizeaza_vanzari`/`sterge_din_vanzari`/
   `modifica_date_factura`/`sterge_factura`/`sterge_proforma`) **nu e exportata** in
   `COMUN\docs\*.pck` din acest working copy (doar `PACK_CONTAFIN`, `PACK_DIAG_SPATIU`,
   `PACK_MIGRARE`, `PACK_UPDATE`) — deci **nu se poate stabili din working copy** daca
   `actualizeaza_vanzari` recalculeaza si sumele/liniile din `vanzari_detalii` sau doar
   realiniaza `vanzari.cod` la `cod`-ul nou generat de `pack_contafin.get_cod()`. Asta e
   intrebarea-cheie de lamurit inainte de a proiecta planul (posibil necesar acces la codul
   Oracle sau la un DBA/export suplimentar al `PACK_FACTURARE`).

Concluzie arhitecturala: planul de "editare directa" trebuie sa respecte acelasi flux
(cursoare temp -> `ACT_TEMP`/`RUL_TEMP` -> `PACK_CONTAFIN`), nu un `UPDATE`/`DELETE` VFP
direct pe `ACT`/`RUL` — asta nu exista nicaieri ca precedent si ar ocoli toata logica de
alocare `cod` nou, marcare `sters`, si sincronizare `vanzari`/`atasamente_vanzari` care traieste
in Oracle.

## 6. Precedent de editare de nota contabila (afara de frm_modific2024)

**Nu exista un formular separat** pentru "MODIFICARE REGISTRU JURNAL" — e acelasi
`frm_modific2024`, folosit din `afisjurcom.do_modifica`
(`D:\ROA\ROAFACTURARE\COMUN\clase\comun.vc2:2222-2563`, identic si in
`ROAGEST\COMUN\clase\comun.vc2`). `afisjurcom` = clasa formularului "Registru jurnal" (afisare
jurnal contabil). Acesta e **precedentul complet, deja documentat**:
`D:\ROA\ROAGEST\COMUN\docs\flux-modificare-stergere-nota-jurnal.md` descrie exact acest flux
(scris de un agent/dezvoltator anterior, cross-verificat de mine cu codul — coincide integral
cu ce am gasit independent la pct. 2 si 5). N-am gasit un literal "MODIFICARE REGISTRU JURNAL"
in `ROAGEST\todo.txt` (cautat, zero potriviri) — probabil e o formulare verbala a
utilizatorului, nu un text din cod; funcțional se refera la exact acest `afisjurcom.do_modifica`.

`afisjurcom.do_modifica` (rezumat, pentru referinta directa la implementare):
- 2253-2264: citeste `an`/`luna`/`cod`/`id_set`/`id_fact`/`id_factd` din randul curent din grid.
- 2265-2268: blocheaza daca nu e luna curenta.
- 2313-2331: elibereaza cursoarele vechi (`actactan`, `tact`, `rul_temp`, `trul`, ...).
- 2352-2427: incarca `vact_tot`/`vrul_tot`/`vrul_obinv_tot` filtrate pe `cod` in
  `actactan`→`tact`, `rul_temp`→`trul`, `rul_temp_obinv`→`trul_obinv` (READWRITE).
- 2436: `Omodif = Createobject([frm_modific2024],lnIdSet)` ; 2442: `Omodif.Show()` (modal).
- 2444-2541: daca userul a apasat Terminat (`buton=1`), deschide tranzactie
  (`Thisform.do_deschide_tranzactie()`), `oscrie_in_fisiere(2,.T.,llRul)` (sterge vechi),
  reincarca `tact`→`actactan`/`trul`→`RUL_TEMP`/`trul_obinv`→`RUL_TEMP_OBINV` cu
  `id_util`/`sters=0`, `oscrie_in_fisiere(0,.T.,llRul)` (scrie nou),
  `pack_contafin.finalizeaza_modificare_nota(...)`, apoi
  `Thisform.do_inchide_tranzactie(...)` (commit/rollback) si `Thisform.do_cauta` (refresh grid).
- Cod mort comentat la 2496-2503 arata ca la un moment dat exista aici EXPLICIT un apel
  `pack_facturare.actualizeaza_vanzari(lnCod, pack_contafin.get_cod())` **direct din VFP** pentru
  "nota din ROAFACTURARE" — mutat ulterior in Oracle, in
  `pack_contafin.finalizeaza_modificare_nota` (pct. 5). Confirma ca legatura
  notă-contabila-din-jurnal <-> `vanzari` a fost tratata explicit de dezvoltatori anterior,
  exact pentru cazul ROAFACTURARE.