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