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

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.