comun/docs/flux-modificare-stergere-nota-jurnal.md

Flux: modificare/stergere nota in Registrul Jurnal

Comportament CORECT (nu bug): la modificarea unei note din Registrul Jurnal, documentul original nu se suprascrie. Se marcheaza sters = 1 pe randurile vechi (ACT/RUL/RUL_OBINV), apoi se scrie un document NOU cu alt cod, pastrand acelasi id_fact/id_factd. Ambele operatii ruleaza intr-o tranzactie manuala unica (commit sau rollback pe amandoua).

Unde

• afisjurcom.do_modifica - COMUN\clase\comun.vc2:2222-2562. Deschide tranzactia manuala (Thisform.do_deschide_tranzactie(), linia 2448), apoi oscrie_in_fisiere(2,...) = STERGE (linia 2451), apoi oscrie_in_fisiere(0,...) = SCRIE (linia 2479), apoi pack_contafin.finalizeaza_modificare_nota(...) (2484-2486), apoi Thisform.do_inchide_tranzactie(...) (linia 2535) - commit daca tot ce a rulat inainte a reusit, rollback altfel.
• do_deschide_tranzactie/do_inchide_tranzactie (_frmbase, COMUN\clase\_frm_base.vc2:252,279; varianta identica ca procedura globala in COMUN\programe\oproceduri_rulaje.prg:287,303): SQLSetProp(gnHandle,'Transactions',2) la deschidere, SQLCOMMIT/SQLROLLBACK + SQLSetProp(...,'Transactions',1) la inchidere.
• oscrie_in_fisiere.prg (COMUN\programe\oscrie_in_fisiere.prg): tnScrie_Sterge 0=scriere, 2=stergere. Apeleaza server-side pack_contafin.init_scriere_act_rul_local + final_scriere_act_rul_local -> finalizeaza_scriere_act_rul, care ruleaza SCRIE_IN_ACT (scriere) sau STERGE_DIN_ACT (stergere) din PACK_CONTAFIN.pck.
• PACK_CONTAFIN.STERGE_DIN_ACT (COMUN\docs\PACK_CONTAFIN.pck:1815-1859): UPDATE ACT SET STERS = 1 ... WHERE COD = tnCod - marcheaza vechiul document, pe cod-ul vechi.
• PACK_CONTAFIN.SCRIE_IN_ACT (PACK_CONTAFIN.pck:630-901): LN_COD := pack_contafin.GET_COD() (linia 648) aloca un cod nou; UPDATE ACT_TEMP SET COD = LN_COD, ... (linia 897) il scrie pe noul document - ID_FACT nu e atins, ramane cel din documentul original.
• PACK_CONTAFIN.finalizeaza_modificare_nota (PACK_CONTAFIN.pck:8601-8651): aloca din nou lnCodNou := pack_contafin.get_cod() si actualizeaza pe codul nou vanzari (pack_facturare.actualizeaza_vanzari) si atasamente_vanzari. nom_lucrari se actualizeaza DOAR pentru id_set IN (31003,31004,31005,31011) (repune id_fact), nu general. gest_inventar NU se leaga de cod-ul nou - se identifica dupa dataora_validat + an + luna (cazul id_set = 90101, note de inventariere).

Atentie: nu e valabil la fel pentru stergerea simpla

afisjurcom.do_sterge (comun.vc2:2565-2724) ofera doua optiuni (xmenu, linia 2625):

• Stergere document (lnOptiune = 1): DOAR OSCRIE_IN_FISIERE(2,...) + finalizeaza_stergere_nota
  • marcheaza sters = 1, NU se creeaza document nou.
• Anulare document (lnOptiune = 2): STERGE (linia 2698) + SCRIE (linia 2709, cu sumele puse pe 0) - creeaza si document nou, la fel ca la modificare - dar aici cele doua apeluri NU sunt invelite intr-o tranzactie manuala comuna (nu apare do_deschide_tranzactie/ do_inchide_tranzactie in do_sterge); fiecare OSCRIE_IN_FISIERE isi gestioneaza singur commit-ul (vezi tlModificare/llManualTransactions in oscrie_in_fisiere.prg:111-165).

Ramura noua: editare factura de vanzare (VANZARI/VANZARI_DETALII)

Cand documentul modificat prin frm_modific2024 are un rand corespunzator in VANZARI, clasa adauga o pagina noua in pageframe-ul de rulaje, PAGE3 "Articole factura" (COMUN\clase\omodificari.vc2:8707), cu un grid legat pe cursorul tvd (structura view-ului VVANZARI_ARTICOLE). Pe orice alt document (nota fara factura) formularul ramane neschimbat - pageframe-ul are PageCount = 2, ca azi.

Ramura e activa doar cand COMUN\programe\ofacturare_editare.prg e incarcat in SET PROCEDURE (verificat prin "OFACTURARE_EDITARE" $ Upper(Set("Procedure"))) - inregistrat la pornire de toate trei aplicatiile care folosesc frm_modific2024: ROAFACTURARE\Programe\roafacturare.prg:214, ROACONT\Programe\roacont.prg:212, ROAGEST\Programe\roagest.prg:260.

Doua puncte de intrare

• frm_facturi.do_editare_factura (COMUN\clase\ofacturare_comun.vc2:3715-3872), actiune noua pe formularul de facturi din ROAFACTURARE. Refuza editarea daca documentul e sters, e proforma, nu e din luna curenta (:3742-3755), are referinte de incasari/plati (ReferinteDocumenteNota, :3758) sau a fost trimis in eFactura (EsteInEFactura, in ofacturare_editare.prg, :3764). Inainte de Createobject([frm_modific2024]) incarca crsArticoleFactura cu IncarcaArticoleFactura (:3793), ca gridul din PAGE3 sa se lege o singura data pe cursorul deja plin.
• afisjurcom.do_modifica (COMUN\clase\comun.vc2:2222-2567) - acelasi punct folosit pentru orice nota din Registrul Jurnal, neschimbat pentru documentele care nu sunt facturi de vanzare. Inainte de Createobject, PregatesteArticoleFacturaEditare('tact') (:2436, in ofacturare_editare.prg) cauta randul din VANZARI corespunzator notei (pe combinatiile cod/nract/serie_act/dataact din tact) si, daca il gaseste, pre-incarca articolele. Pe acest punct de intrare nu se verifica garda eFactura si nici cea de referinte de incasari/plati - doar restrictia de luna curenta, deja existenta pentru orice nota (:2265-2268). Diferenta e intentionata: garda de referinte protejeaza incasarile legate prin id_fact la operatia care sterge efectiv factura; pe editarea de sume din ROAFACTURARE se aplica pentru ca stergerea si rescrierea notei sunt parte din acelasi pas, dar pe editarea generica de note din Registrul Jurnal (care poate sa nu priveasca deloc o factura) nu se aplica.

Daca apelantul nu a putut pregati articolele dinainte, frm_modific2024.Show reface legatura prin IncarcaVanzareDinNota ca fallback si decide acolo daca arata PAGE3 (omodificari.vc2:14769-14794).

Scrierea, in aceeasi tranzactie manuala

La buton = 1 (Terminat), pasul nou se adauga la coada secventei existente de stergere+scriere+realiniere, in aceeasi tranzactie manuala unica, identic pe ambele puncte de intrare (ofacturare_comun.vc2:3828-3830, comun.vc2:2491-2493):

do_deschide_tranzactie()
  oscrie_in_fisiere(2,...)                        -- sterge nota veche (ACT/RUL)
  oscrie_in_fisiere(0,...)                        -- scrie nota noua, cod nou
  pack_contafin.finalizeaza_modificare_nota(...)  -- realiniaza VANZARI.COD (actualizeaza_vanzari)
  ScrieArticoleFacturaEditate(tvanz.id_vanzare)   -- NOU
do_inchide_tranzactie(...)

Agatarea ruleaza doar cand tvanz e deschis cu exact un rand (documentul are factura asociata). VANZARI.ID_FACT nu e atins de niciun pas al secventei - ramane cel alocat la emiterea initiala a facturii, la fel ca la orice alta nota (vezi "Implicatii practice"); doar VANZARI.COD se realiniaza pe codul nou al notei. Tot ce se leaga prin id_fact (ANAF_EFACTURA, DOCUMENTE, ACT.id_factd/id_factc) sau prin ID_VANZARE supravietuieste neschimbat unei reeditari; doar ce ar tine minte cod-ul vechi il pierde.

pack_facturare.actualizeaza_vanzari, apelata din finalizeaza_modificare_nota, face UPDATE VANZARI_DETALII SET STERS = 0 pe tot documentul, fara nicio garda pe linie - reseteaza si liniile sterse la o editare anterioara. De aceea ScrieArticoleFacturaEditate ruleaza DUPA finalizeaza_modificare_nota, nu inauntrul ei: scrierea liniilor trebuie sa vina dupa acest reset, ca sa-l corecteze, nu inaintea lui.

ScrieArticoleFacturaEditate (COMUN\programe\ofacturare_editare.prg:468-555):

1. marcheaza sters = 1 pe tot documentul din VANZARI_DETALII (:489-491);
2. invie si actualizeaza liniile pastrate din tvd (cantitate, pret, pret_cu_tva - pret_achizitie se omite, ramane valoarea persistata) (:497-506);
3. insereaza liniile noi (id_vanzare_det = 0), fara id_vanzare_det explicit - il genereaza trigger-ul TRG_VANZARI_DET_BEFOINS (:518-535);
4. apeleaza pack_facturare.recalculeaza_totaluri_vanzari(id_vanzare, discount) (:544-548), cu discountul luat din tvanz.discount; NULL pastreaza valoarea curenta din VANZARI in loc s-o zeroeze.

O linie stearsa de utilizator la o editare ramane stearsa si dupa reeditari ulterioare - fiecare salvare reface pasii 1-2 pe starea curenta din tvd, deci resetul din actualizeaza_vanzari e mereu corectat inainte sa ajunga vizibil.

pack_facturare.recalculeaza_totaluri_vanzari (script de migrare ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql) recalculeaza din VANZARI_DETALII - liniile proprii si, separat, liniile din seturi agregate din VANZARI_SETURI - coloanele discount, discount_tva, valoare_achizitie, total_fara_tva, total_tva, total_cu_tva, valval, tvaval, totval, id_valuta, curs, multiplicator, cu acelasi calcul per-linie ca la emitere (calculeaza_total_fara_tva_fact/calculeaza_total_tva_fact). Coloanele de incasare (serie_incasat/nr_incasat/suma_incasat/tip_incasat) nu sunt atinse.

View-ul VVANZARI_ARTICOLE (script de migrare ff_2026_08_09_02_COMUN_VVANZARI_ARTICOLE.sql) expune direct VANZARI_DETALII, cu id_vanzare_set si pret_achizitie printre coloanele proprii ale tabelei, plus denumire/codmat/nume_gestiune/nume_val din join-uri - sursa cursorului tvd.

Editarea in grid

Gridul pgfArticole.PAGE3.grdArticoleFactura (omodificari.vc2:12320-...) e legat pe tvd. Linia provenita dintr-un set (id_vanzare_set <> 0) e needitabila (cantitate, pret, pret_cu_tva) si apare intr-o culoare distincta in grid (DynamicForeColor); coloana pret_achizitie e editabila doar pe liniile noi (id_vanzare_set = 0 AND id_vanzare_det = 0), doar-afisare pe restul (:16526-16552). Stergerea unei linii e logica - cmdStergeArticol.Click comuta sters pe randul curent din tvd, ramane vizibila grizata pana la salvare (:16508-16517). Adaugarea reutilizeaza dialogul frm_articol_factura de la compunerea facturii (:16497-16505).

Inainte de salvare (inainte_de_do_termin, :14329-14386, activa doar cand ofacturare_editare.prg e incarcat si tvd exista), pentru fiecare linie activa din tvd: opreste salvarea daca are cantitate <= 0, pret nul sau nu are articol asociat; cere confirmare daca o linie noua are pretul de achizitie 0, respectiv daca toate liniile facturii au fost sterse.

Implicatii practice

• Codul (cod) unui document din Registrul Jurnal NU e stabil dupa modificare/anulare - se schimba la fiecare editare. Cod hardcodat sau retinut dintr-o executare anterioara devine invalid.
• Regasirea documentului editat se face dupa id_fact (sau alt marcaj stabil), niciodata dupa cod.
• Randurile sters = 1 ramase in ACT/RUL/RUL_OBINV dupa o modificare sunt normale (istoric), nu date corupte sau duplicate de curatat.
• Editarea unei facturi de vanzare (document cu rand in VANZARI) reface si liniile si totalurile denormalizate din VANZARI/VANZARI_DETALII, in aceeasi tranzactie cu nota - vezi ramura de mai sus.
• Documentele care nu sunt facturi de vanzare nu sunt atinse de aceasta ramura - pagina de articole nu apare si scrierea in VANZARI_DETALII nu se declanseaza (garda: Reccount('tvanz') = 1).