roafacturare/docs/cercetare/rec_pozitionare_actactan.md

Cercetare: de unde se citesc id_set / id_fact / id_factd in do_editare_factura

Context: decizia 24 din docs\progres.md cere scoaterea completa a garzii pe id_set adaugata in runda 3, cu avertismentul ca pozitionarea din care se citesc id_fact/id_factd nu are voie sa cada pe un rand de discount. Nota de fata verifica premisa pe date si stabileste pozitionarea corecta.

Sursa: MARIUSM_AUTO@ROA_CENTRAL, 08.08.2026, interogari directe pe ACT si VANZARI.

1. Premisa "randurile de discount au ID_FACT = -1" nu se confirma in ACT

Distributia ACT.ID_FACT pe toata tabela:

valoare	randuri	ani
pozitiv	66360	0-2026
negativ	32	2008-2019
NULL	0	—
zero	0	—

Zero randuri cu id_fact <= 0 din 2020 incoace. ACT.ID_FACTD nu e niciodata NULL (65849 de zerouri, 541 pozitive, 2 negative in 2006).

Pe cele 27 de note cu randuri DISCOUNT / TVA DISCOUNT: randurile de discount au acelasi id_fact si acelasi id_set ca restul notei, si id_factd = 0. Coerent cu decizia 24 — cumuleaza_note_act_temp normalizeaza inainte de ACT; -1 din scrie_discount nu ajunge acolo.

Concluzie: randul de discount nu e periculos. Constatarea din rec_garda_idset.md pct. 1 era corecta pe sursa PL/SQL, dar valorile nu supravietuiesc pana in ACT.

2. Randul periculos e INCASAREA, si problema e reala

Note legate de VANZARI cu mai multe id_fact distincte: 78. Tiparul, verificat pe exemple: primul rand dupa id_act este INCASARE / INCASARE NUMERAR, cu id_fact = id_fact-ul facturii minus 1 (chitanta isi are propriul id_fact, alocat inaintea facturii).

   COD      TIP    AN  LUNA  VANZARI.ID_FACT  primul rand ACT  explicatia
1137874     44   2009     8         5040267          5040266  INCASARE
1138549      1   2014     1         8001118          8001117  INCASARE NUMERAR

39 de facturi in schema de dev pe care un Go Top orb pe actactan (ordonat dupa id_act) preia id_fact-ul chitantei, nu al facturii. E comportamentul codului din runda 1/2, nu ceva introdus de runda 3.

Pe 38 din cele 39, VANZARI.ID_FACT exista ca id_fact pe cel putin un rand al notei, deci o pozitionare Locate For id_fact = <id_fact-ul din crsfacturi> il gaseste. Al 39-lea e un rand vechi fara corespondent.

3. Cat conteaza fiecare valoare, la destinatie

PACK_CONTAFIN.finalizeaza_modificare_nota (COMUN\docs\PACK_CONTAFIN.pck:8601-8651):

• tnIdSet — conduce CASE-ul; pentru facturi (25xxx) cade pe ELSE, deci nu face nimic in plus fata de actualizeaza_vanzari;
• tnIdFact — folosit doar pe ramura tnIdSet IN (31003, 31004, 31005, 31011): UPDATE NOM_LUCRARI SET ID_FACT = tnIdFact ... WHERE ID_FACT IS NULL. Ramura e vie si pentru documente din VANZARI: 35 de note cu id_set = 31011, 5 cu 31003, 1 cu 31005. Semantic trebuie sa fie id_fact-ul facturii, adica exact VANZARI.ID_FACT;
• tnIdFactD — apare doar in cod comentat (ramurile 90011/90013). Azi e complet nefolosit.

4. id_set unic pe nota — confirmat

Note legate de VANZARI, dupa numarul de id_set distincte: 558 cu unul singur, 1 cu doua — si aceea e randul-gunoi cod = 0, an = 0, luna = 0 (id_set 46 si 10208), nu o factura. Decizia 24 se confirma pe date; garda din runda 3 poate iesi fara inlocuitor.

5. Pozitionarea corecta

lnIdFact e deja citit corect din crsfacturi (VANZARI.ID_FACT) la inceputul metodei si folosit pentru garda eFactura. Nu trebuie rescris din actactan — poate doar sa se strice. Deci:

• se cauta in actactan randul cu id_fact = lnIdFact; daca se gaseste, de acolo se iau id_set si id_factd;
• daca lnIdFact nu e utilizabil (0/NULL — 283 de randuri VANZARI au ID_FACT NULL, in principal avize si transferuri) sau nu are corespondent in nota, se cade pe Go Top si se ia id_fact de acolo, ca inainte.

Fara garda, fara mesaj de refuz.