# Garda "aviz deja facturat" — verificare pe cod

Verificare pe cod, fara nicio modificare de fisier. Sursele citate:

- export pachet: `D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\08\ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql`
  (mai jos: `EXPORT:<linie>`);
- corpul **desfasurat pe DB** (`MARIUSM_AUTO@ROA_CENTRAL`, `all_source`), citit ca sa se confirme ca
  ce e in export e si ce ruleaza (mai jos: `DB PACK_FACTURARE:<linie>`). **Numerotarea difera**:
  `sterge_factura` incepe la `EXPORT:5432`, dar la `DB PACK_FACTURARE:4192`. Nu exista offset
  constant; textul insa e identic cuvant cu cuvant pe zona gardelor.

---

## 1. Blocheaza garda de azi si un AVIZ care are deja factura generata din el?

**DA.** Nu e nevoie de nicio garda noua pentru cazul asta — este exact ce testeaza a doua garda din
`sterge_factura`, prin `TIP IN (1, 2)`.

`EXPORT:5464-5476` = `DB PACK_FACTURARE:4224-4236`:

```
    -- ptr. un aviz normal:
    --  verific daca exista facturi sau avize de retur pe avizul resp.
    SELECT COUNT(*)
      INTO V_NR_AVIZE_FACT
      FROM VANZARI_CORESP
     WHERE STERS = 0
       AND ID_VANZARE_AVIZ = V_ID_VANZARE
       AND TIP IN (1, 2);

    IF V_NR_AVIZE_FACT > 0 THEN
      RAISE_APPLICATION_ERROR(-20000,
                              'Pe acest aviz s-au emis facturi / aviz de retur. Trebuie sa stergeti mai intai facturile / avizul de retur!');
    END IF;
```

Cheia e semantica lui `TIP`, citita din **singurul scriitor** al tabelei, ramura cu ramura
(`finalizeaza_factura`, `EXPORT:14818-14839`):

| `VANZARI_CORESP.TIP` | scris cand | `ID_VANZARE_FACT` | `ID_VANZARE_AVIZ` | e retur? |
|---|---|---|---|---|
| **1** | `ntip = 4` — facturare din aviz (`EXPORT:14823-14826`) | factura | avizul-sursa | **NU** |
| 2 | `ntip = 24` — aviz de retur (`EXPORT:14828-14830`) | avizul de retur | avizul original | DA |
| 3 | `ntip in (8, 9)` — factura de retur (`EXPORT:14834-14836`) | factura de retur | factura originala | DA |

Deci `TIP = 1` este **corespondenta aviz -> factura normala**, nu retur. Garda de la `EXPORT:5473`
prinde ambele cazuri; textul mesajului chiar o spune ("s-au emis **facturi** / aviz de retur").
Formularea din brief ("garda de azi blocheaza documentul care are facturi/avize **de retur**") vine
dintr-o citire a comentariului `-- verific daca exista facturi sau avize de retur` in care "de retur"
se distribuie si peste "facturi"; codul zice altceva.

Deci: la ora asta, **exact regula ceruta de decizia 50 este deja implementata pentru avize**
(document cu urmasi = blocat; capatul lantului = liber).

### Ce NU citeste garda

- **`VANZARI.FACTURAT` nu e citit de nicio garda.** Pe calea de stergere e doar **scris**
  (`EXPORT:5504-5510` pentru `V_TIP = 24`, `EXPORT:5527-5533` pentru `V_TIP = 4` — resetare la 0
  cand dispare factura/avizul de retur), iar la facturare e **pus** de `marcheaza_facturat`
  (`EXPORT:15381-15418`). Niciun `IF` / `RAISE` nu il interogheaza. Semnalul autoritar este
  `VANZARI_CORESP`, `FACTURAT` e derivat redundant.
- **`ID_VANZARE_SURSA` / `ID_VANZARE_DEST` nu exista.** `VANZARI_CORESP` are exact 5 coloane
  (interogare pe `all_tab_columns`): `ID_VANZARE_CORESP`, `ID_VANZARE_FACT`, `ID_VANZARE_AVIZ`,
  `STERS`, `TIP`. Nici `VANZARI` nu are coloane `*_SURSA` / `*_DEST` (aceeasi interogare).

---

## 2. Exista alte garzi pe calea de stergere / modificare?

### 2a. Oracle — nu exista alta, dar garda e **atinsa pe ambele ramuri** de stergere

Interogare pe `all_source` (owner curent): singurele obiecte care contin `VANZARI_CORESP` sunt
**`PACK_FACTURARE` (package body)** si **`TRG_VANZARI_CORESP_BEFOINS`**. Deci nu exista o a doua
garda ascunsa in alt pachet.

**Triggerele nu contin garzi** (sursa citita integral din `all_source`):

| trigger | tabela | eveniment | ce face |
|---|---|---|---|
| `TRG_VANZARI_BEFOUPD` | `VANZARI` | UPDATE | 4 apeluri `pack_audit.verifica_val` (NR_ACT, SERIE_ACT, DATA_ACT, DATA_SCAD) — audit, nu blocare |
| `TRG_VANZARE_BEFOINS` | `VANZARI` | INSERT | — |
| `TRG_VANZARI_DET_BEFOINS` | `VANZARI_DETALII` | INSERT | — |
| `TRG_VANZARI_CORESP_BEFOINS` | `VANZARI_CORESP` | INSERT | doar `SEQ_VANZARI_CORESP.nextval` |

**Punct important de verificat, pentru ca la prima citire pare o portita:** in
`frm_facturi.do_sterge` apelul direct `pack_facturare.sterge_factura` e **comentat** pe ramura
documentelor cu note contabile — `ofacturare_comun.vc2:4807-4809` (`*!* modificare v 2.2.5`), iar
ramura activa (`:4810-4811`) cheama numai `pack_contafin.finalizeaza_stergere_nota`. **Nu e o
portita**: lantul se inchide in Oracle.

```
PACK_CONTAFIN:8322-8326   SELECT COUNT(*) INTO lnEInVanzari FROM vanzari WHERE cod = tnCod;
                          IF lnEInVanzari > 0 THEN
                            pack_facturare.sterge_din_vanzari(tnCod, tnAn, tnLuna, tnIdUtil);
PACK_FACTURARE:14996-14998  SELECT ID_VANZARE INTO V_ID_VANZARE FROM VANZARI WHERE COD = V_COD;
                            pack_facturare.sterge_factura(V_ID_VANZARE, V_LUNA, V_AN, V_ID_UTIL);
```

Apelantii lui `sterge_factura` in baza (cautare pe `all_source`) sunt exact doi:
`PACK_FACTURARE.sterge_din_vanzari` (`DB PACK_FACTURARE:14998`) si procedura standalone
`STERGE_DOCUMENT` (`DB STERGE_DOCUMENT:416`). Ambele cai trec prin garda.

### 2b. VFP — pe calea de stergere: nicio garda pe urmasi

`frm_facturi.do_sterge` (`COMUN\clase\ofacturare_comun.vc2:4661-4877`) verifica, inainte de apel:
luna inchisa (`:4676`), `sters = 1` (`:4689`), confirmare (`:4694`), luna curenta (`:4701`) si
referinte de incasari/plati (`ReferinteDocumenteNota`, `:4723-4727`). **Nimic despre `FACTURAT`,
`VANZARI_CORESP` sau urmasi** — verificarea lantului e delegata integral Oracle-ului.

### 2c. VFP + Oracle — pe calea de **modificare**: nicio garda, nici pe urmasi, nici pe lant

`frm_facturi.do_modifica` (`ofacturare_comun.vc2:4541-4640`) blocheaza doar doua lucruri
(`:4590`, `:4635`):

```
			If poRec.sters = 0 AND NVL(m.pnEFactura,0) = 0
			...
				amessagebox("Nu puteti face modificari pe inregistrarile sterse sau facturile trimise in eFactura!", 48, "Atentie")
```

`pack_facturare.modifica_date_factura` (`EXPORT:14439-14509`) e un lant de `UPDATE`-uri fara niciun
`IF` de validare si fara niciun `RAISE_APPLICATION_ERROR`. Ceea ce e coerent cu ce modifica azi
(ruta, delegat, agent, masina, dataora exp., text aditional, tip SAFT, eFactura, serie/numar/data act,
data scadenta) — campuri de antet care nu ating lantul aviz -> factura.

---

## 3. Concluzia operationala pentru decizia 50 / S7

**Regula ceruta de decizia 50 exista deja, si nu are gol pe aviz.** `sterge_factura` implementeaza
azi, in trei garzi consecutive, exact "documentul cu urmasi e blocat, capatul lantului e liber":

| garda | `EXPORT` | ce blocheaza |
|---|---|---|
| 1 | 5452-5462 | **factura** care are facturi de retur peste ea (`TIP = 3`) |
| 2 | 5466-5476 | **aviz** care are factura (`TIP = 1`) sau aviz de retur (`TIP = 2`) peste el |
| 3 | 5480-5494 | **factura din aviz** ale carei avize-sursa au primit intre timp aviz de retur |

A treia garda merita subliniata pentru decizia 50: factura din aviz e editabila **doar** cat timp
niciunul dintre avizele ei nu are aviz de retur; nu e "capat de lant" neconditionat.

**Deci S7 nu are nevoie de o garda noua ca regula — dar are nevoie de o citire noua a aceleiasi
conditii, ca moment.** Garda de azi e in interiorul lui `sterge_factura`, adica se manifesta ca
`ORA-20000` **in mijlocul** pasului de stergere din regenerare, dupa ce utilizatorul a completat
formularul si dupa ce s-a deschis tranzactia. Pentru un flux de editare asta e o esuare tarzie.
Ce lipseste e un **pre-flight read-only**, inainte de intrarea in formular, pe exact aceeasi
conditie (fara reimplementarea regulii):

```sql
select count(*) from vanzari_coresp
 where sters = 0 and id_vanzare_aviz = :id_vanzare and tip in (1, 2, 3)
```

plus, pentru cazul "factura din aviz", subinterogarea din garda 3 (`EXPORT:5480-5488`). Garda din
`sterge_factura` ramane pe loc ca plasa de siguranta — nu se muta, nu se slabeste.

Interogarea se face pe `VANZARI_CORESP`, **nu** pe `VANZARI.FACTURAT`: `FACTURAT` e un marcaj
redundant, derivat, scris/resetat de `marcheaza_facturat` / `sterge_factura`, si necitit de nicio
garda; `VANZARI_CORESP` e semnalul autoritar.

---

## 4. Inventar: ce tipuri de documente-parinte produc urmasi prin `VANZARI_CORESP`?

**Doar trei, toate scrise din acelasi `CASE` din `finalizeaza_factura` (`EXPORT:14818-14839`), prin
singurul scriitor `scrie_corespondente_vanzari` (`EXPORT:15481-15516`, singurul `INSERT INTO
VANZARI_CORESP` din tot pachetul — si din toata baza, cf. `all_source`).**

| parinte | urmas | `TIP` | de unde vine lista parintilor |
|---|---|---|---|
| **aviz** (`VANZARI.TIP in 21, 22, 26, 42`) | factura din aviz (`ntip = 4`) | 1 | `clistaid_avize`, setat la `EXPORT:7037` in `scrie_factura_avize`; lista o construieste VFP prin `caut_avize`, filtrata `a.tip in (21,22,26,42) and a.facturat = 0` — `COMUN\programe\oproceduri_facturare.prg:2036-2038` |
| **aviz** | aviz de retur (`ntip = 24`) | 2 | `clistaid` |
| **factura** | factura de retur (`ntip in 8, 9`) | 3 | `clistaid` |

**Ce NU produce urmasi prin `VANZARI_CORESP`** (deci decizia 50 nu are acoperire acolo prin garda
existenta):

- **proforma -> factura.** Proforma sta in `VANZARI` cu `EPROFORMA = 1`; `finalizeaza_factura` nu are
  ramura care sa scrie corespondenta pentru ea. `TIP = 4` este o **propunere** de la S5c, nu cod
  existent. Mai mult, `pack_facturare.sterge_proforma` (`EXPORT:5610-5635`) **nu are nicio garda** —
  corpul ei e doar doua `UPDATE ... SET STERS = 1` pe `VANZARI` si `VANZARI_DETALII`. O proforma din
  care s-a emis factura se poate sterge azi fara niciun avertisment. (Calea VFP:
  `ofacturare_comun.vc2:4707-4719`, care iese din `do_sterge` inainte de restul verificarilor.)
- **comanda -> factura.** Legatura e `VANZARI.ID_COMANDA` + `pack_facturare.inchide_comanda`
  (`EXPORT:5769`), nu `VANZARI_CORESP`. `COMENZI` **nu are coloana `FACTURAT`** (verificat pe
  `all_tab_columns`) — flagul `facturat` din grid vine din view-ul de incarcare. Garda exista, dar e
  **in VFP si pe comanda**, nu pe factura: `COMUN\clase\ocomenzi.vc2:1806-1807` la modificare
  ("Aceasta comanda a fost facturata si nu mai poate fi modificata!") si `:2065-2066` la stergere.
- **contract -> factura.** Legatura e `VANZARI.ID_CTR` + `CTR_RATE_FACTURI`
  (atinsa de `sterge_factura` la `EXPORT:5566-5580` pentru `V_TIP IN (2, 6, 52)`); nicio linie in
  `VANZARI_CORESP`, nicio garda de tip "are urmasi".

---

## 5. Ce am verificat direct vs. ce am dedus

**Verificat direct pe cod / pe metadate:**

- textul celor trei garzi din `sterge_factura`, in export **si** desfasurat din `all_source` (identice);
- `CASE`-ul din `finalizeaza_factura` care da semantica lui `TIP`, ramura cu ramura;
- corpul lui `scrie_corespondente_vanzari` si `marcheaza_facturat`;
- ca `INSERT INTO VANZARI_CORESP` exista intr-un singur loc (grep pe export + `all_source` pe toata baza);
- sursa integrala a celor 4 triggere de pe `VANZARI` / `VANZARI_DETALII` / `VANZARI_CORESP`;
- lista completa a apelantilor lui `sterge_factura` (`all_source`), inclusiv lantul
  `finalizeaza_stergere_nota -> sterge_din_vanzari -> sterge_factura`;
- coloanele reale ale `VANZARI_CORESP`, `PROFORME`, si absenta lui `FACTURAT` din `COMENZI`
  (`all_tab_columns`);
- `frm_facturi.do_sterge` si `frm_facturi.do_modifica` integral, plus `modifica_date_factura`;
- filtrul `caut_avize` din `oproceduri_facturare.prg`.

**Dedus / cu limite declarate:**

- Ca `TIP = 1` inseamna "factura normala din aviz" e o deductie din singurul punct de scriere
  (`ntip = 4` -> `scrie_corespondente_vanzari(1)`) — solida, dar e deductie, nu o eticheta declarata
  intr-un nomenclator.
- Ca setul tipurilor-parinte pentru `TIP = 1` e `{21, 22, 26, 42}` vine din filtrul VFP `caut_avize`,
  nu dintr-o restrictie in Oracle. Pachetul insereaza **orice** `ID_VANZARE` primit in
  `clistaid_avize`, fara filtru pe tip (`EXPORT:15494-15504`). Alt apelant (alt produs ROA, un import)
  ar putea introduce alte tipuri.
- Nu am verificat daca vreun **alt produs ROA** (ROACONT / ROAGEST / ...) are o cale proprie de
  stergere care ocoleste `sterge_factura`. Am verificat doar ca in Oracle nu exista alt apelant si
  ca in ROAFACTURARE ambele ramuri din `do_sterge` ajung acolo.

**Din date, deci nedovaditor:** interogarea pe `VANZARI_CORESP` din baza de dev arata `TIP=1` cu
parinti de tip 21 si 22, `TIP=2` cu parinte 22, `TIP=3` cu parinte 1 — consistent cu tabelul de mai
sus, dar volumul e de ordinul unitatilor (8 randuri in total). **Nu e dovada**; concluziile de mai
sus vin din cod.

## 6. Ce nu s-a putut stabili

Nimic din cele 4 intrebari nu a ramas nedeterminat. Singurul punct pe care l-as lasa explicit
deschis pentru S7 este cel de la §4: **golul real nu e pe aviz, e pe proforma** —
`sterge_proforma` nu are absolut nicio garda, iar daca S5c chiar introduce `TIP = 4`
(proforma -> factura), garda din `sterge_factura` **nu se aplica automat**, pentru ca `sterge_proforma`
e o procedura complet separata care nu o apeleaza.