# Nota contabila pentru articol fara politica de pret (proiect #13)

Cercetare pe cod, fara modificari. Continua raportul anterior
`cont_venit_corespondente.md` (SCC vine prin lantul
`CRM_POLITICI_PRET_ART -> CRM_POLITICI_PRETURI.ID_NOTA -> CRM_NOTE_VANZARI.ID_SET -> NOTE_CONTABILE`,
citit de `cursor_articol` din `pack_facturare.contabilizeaza_articol`).

Sursa: `D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\08\ff_2026_08_06_10_COMUN_PACK_FACTURARE.sql`
(pachet `pack_facturare`, 17020 linii) si `D:\ROA\ROAAUTO\Programe\oproceduri_devize.prg` +
`D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\03\ff_2026_03_31_02_AUTO_PACK_AUTO.sql` (pachet `pack_auto`).

---

## 1. Ce face `contabilizeaza_articol` cand `id_pol` e NULL/0

Raspuns: **ridica exceptia FACT-024 si intreruce functia, inainte sa ajunga la cursorul care
citeste SCC**. Nu exista o ramura de default si nu se scrie nota cu SCC NULL pentru acest caz.

Corpul complet e la `ff_...:7182-7556`. Primul lucru pe care il face (inainte de `cursor_articol`,
inainte de orice `scrie_nota`) e:

```
ff_...:7286-7311
BEGIN
  SELECT COMPUS, ID_POL_ART
    INTO V_COMPUS, V_ID_POL_ART
    FROM VCRM_POLITICI_PRET_ART
   WHERE ID_ARTICOL = detalii_articol.id_articol
     AND ID_POL = detalii_articol.id_pol;
EXCEPTION
  WHEN NO_DATA_FOUND THEN
    SELECT DENUMIRE INTO lcArticol FROM NOM_ARTICOLE WHERE id_articol = detalii_articol.id_articol;
    SELECT NUME_LISTA_PRETURI INTO lcPolitica FROM CRM_POLITICI_PRETURI WHERE id_pol = detalii_articol.id_pol;
    RAISE_APPLICATION_ERROR(-20000,
      'Articolul ' || detalii_articol.id_articol || '|' || lcArticol ||
      ' nu este definit in politica de preturi ' ||
      detalii_articol.id_pol || '|' || lcPolitica || '! (FACT-024)');
END;
```

`ID_POL = detalii_articol.id_pol` cu `id_pol` NULL nu poate potrivi niciun rand in SQL standard
(`X = NULL` e necunoscut, nu adevarat) — deci pentru `id_pol` NULL sau 0 (presupunand ca nu exista
o politica cu `ID_POL = 0`), `SELECT INTO` intra mereu pe `NO_DATA_FOUND`.

**Observatie suplimentara, neceruta explicit dar relevanta**: in ramura de exceptie, al doilea
`SELECT ... INTO lcPolitica FROM CRM_POLITICI_PRETURI WHERE id_pol = detalii_articol.id_pol` sufera
de aceeasi problema — cu `id_pol` NULL, si acest `SELECT INTO` da tot `NO_DATA_FOUND`, care **nu e
tratat** in acest bloc (nu exista un al doilea handler). Deci mesajul FACT-024 "curat" (cu numele
politicii) nu s-ar afisa niciodata pentru cazul `id_pol IS NULL` — s-ar propaga o exceptie
`NO_DATA_FOUND` neprinsa din interiorul handler-ului, cu alt mesaj Oracle generic, nu FACT-024 cu
text. Codul articolului (`lcArticol`) apuca sa fie rezolvat inaintea acestui eșec, deci
identificarea articolului nu s-ar pierde in log/eroare, dar textul final ar fi ORA-01403, nu
mesajul FACT-024 formatat. Pentru `id_pol = 0` (nu NULL), daca exista vreo politica cu id 0, acel
`SELECT` ar reusi si mesajul FACT-024 ar iesi corect.

Cursorul `cursor_articol` (care citeste SCD/ASCD/SCC/ASCC din `NOTE_CONTABILE` prin lant) **nu se
mai deschide** — funcția a ridicat deja exceptia mai sus. Deci intrebarea "cursorul intoarce zero
randuri, ce face codul mai departe" nu se pune in acest caz: nu ajunge acolo.

Concluzie Q1: **orice linie de vanzare cu `id_pol` NULL/0 trimisa la `contabilizeaza_articol` in
starea actuala a codului arunca o eroare si opreste tranzactia** (nu scrie nota cu cont NULL, nu
pune default). Cerinta proiectului #13 ("articol din nomenclator fara politica de pret, pret
tastat manual, pe orice tip de document") ar lovi FACT-024 (sau exceptia neprinsa descrisa mai sus)
daca linia respectiva e trecuta prin acest cod neschimbat.

---

## 2. Validare la `scrie_nota` pentru cont NULL

Raspuns: **nu exista**. Corpul complet e la `ff_...:12338-12570`.

- Singura verificare care ar fi atins asta e comentata:
  ```
  ff_...:12441-12453
  /*    IF V_SUMA IS NULL THEN
        RAISE_APPLICATION_ERROR(...) ...
        END IF;*/
  ```
  Si oricum verifica `V_SUMA` (suma calculata), nu `V_SCD`/`V_SCC`.
- `INSERT INTO ACT_TEMP (... SCD, ASCD, SCC, ASCC ...)` (`ff_...:12458-12544`) insereaza direct
  `V_SCD`/`V_ASCD`/`V_SCC`/`V_ASCC` primite ca parametri, fara niciun `NVL`/`CASE`/verificare de
  NULL pe ele.
- Nu exista `NOT NULL` verificat in cod pentru aceste coloane in acest fisier (constrangerea ar fi
  la nivel de DDL al tabelei `ACT`/`ACT_TEMP`, care nu face parte din pachetul PL/SQL cercetat —
  vezi sectiunea Neverificat).

Deci daca cineva ar ocoli blocul de la punctul 1 (de ex. printr-un `id_pol` care *exista* in
`CRM_POLITICI_PRET_ART` dar al carui lant `CRM_POLITICI_PRETURI -> CRM_NOTE_VANZARI -> NOTE_CONTABILE`
e incomplet, asa incat `D.SCC` iese NULL din LEFT JOIN), `scrie_nota` ar scrie nota cu `SCC = NULL`
fara sa protesteze. Asta e insa un scenariu diferit de "fara politica de pret" (aici politica exista,
dar lantul de sub ea e incomplet) — nu e cazul cerut de proiectul #13 asa cum a fost formulat.

---

## 3. Toti apelantii lui `contabilizeaza_articol` in fisier

Cautare exhaustiva `Grep 'contabilizeaza_articol'` pe tot fisierul: 3 apeluri (in afara de propria
definitie si un comentariu):

| Linie | Procedura apelanta | Domeniu / flux |
|---|---|---|
| `ff_...:6150` | `scrie_factura2` (corp `ff_...:6029-6272`) | **Fluxul principal de scriere** — pentru orice document ale carui randuri nu cad in ramurile speciale ale `CASE`-ului de la `ff_...:6081-6151`: transfer intre subunitati (`ntip IN (23,25,30,41)`), factura/aviz custodie (`ntip IN (42,47)`), rata cu `id_rata<>0` (`ntip IN (2,6,52)`). Toate celelalte tipuri — **factura normala** (`ntip<=20`), hotel, restaurant, nota de plata, vanzare retail, tipurile 48/49/51/52, aviz simplu, aviz catre clienti debitori, si **aviz retur (tip 24)** cand e scris prin `scrie_factura2` — ajung la `contabilizeaza_articol` aici. Aceasta e apelarea "de baza" pe care se sprijina interpretarea corpului functiei facuta la punctul 1 (ramurile `CASE` din interiorul `contabilizeaza_articol`, `ff_...:7407-7432`, mapeaza direct pe tipurile de document tratate de acest apelant). |
| `ff_...:6867` | `scrie_factura_avize_retur` (corp `ff_...:6273-6666`) | Flux **factura scrisa pe baza de avize + retur simultan**. Apelul e in interiorul buclei pe `articole_aviz` (`ff_...:6841-6960` zona), pentru randurile cu `custodie = 1` (marfa in custodie ce se descarca din avize). |
| `ff_...:7149` | `scrie_aviz_retur` (corp `ff_...:7094-7180`) | Procedura dedicata **aviz retur** (`V_ID_DELEGAT, V_ID_MASINA, ...`). Apelul e in ramura `ELSE` a testului `pack_facturare.nfactavizcust = 1` (`ff_...:7124-7150`) — deci pentru randurile care **nu** sunt in custodie. |

Concluzie Q3: **da**, `contabilizeaza_articol` e apelata pe fluxul principal de facturare
(`scrie_factura2`, care acopera factura normala si majoritatea celorlalte tipuri de document), nu
doar din `scrie_aviz_retur`. Raportul anterior lasase asta neverificat; e confirmat aici cu cele 3
puncte de apel gasite si citate mai sus — nu exista un al 4-lea apel in fisier.

---

## 4. Precedentul ROAAUTO "Alte servicii" — **nu e de fapt un precedent pentru cazul cerut**

Asta contrazice premisa din cerere. Firul (`crsalteserv -> crsvanztemp -> adauga_articol_factura_deviz`)
duce spre un flux care **ocoleste complet `contabilizeaza_articol`**, deci nu demonstreaza ce se
intampla in `pack_facturare` pentru un articol fara politica — demonstreaza doar ca exista un *alt*
mecanism de contabilizare, in afara pachetului `pack_facturare`.

Pasii, cu citate:

1. **`crsalteserv -> crsvanztemp`** (`D:\ROA\ROAAUTO\Programe\oproceduri_devize.prg:1040-1041`):
   ```
   Insert Into (lcCursorDeviz)(id_articol,denumire,explicatie,cantitate,um,id_jtva_coloana,proc_Tvav,taxcode,pret,discount_unitar) ;
     Select id_articol,denumire,"",cantitate,um,CAST(lnIdJTvaColoana as N(6) null) as id_jtva_coloana,CAST(lnProcTvav as N(7,2) null) as proc_tvav,CAST(lnTaxCode as N(6) null) as taxcode,pretftva,0 From crsalteserv Where !Deleted()
   ```
   Nu exista coloana `id_pol` in `crsalteserv`, in `lcCursorDeviz`, sau in cursorul `crsvanztemp`
   creat la `oproceduri_devize.prg:1190-1192` (schema explicita a cursorului nu include `id_pol`).

2. **`crsvanztemp -> adauga_articol_factura_deviz`** (`oproceduri_devize.prg:1240-1257`): apelul RPC
   trimite `id_articol, explicatie, serie, pret_achizitie, pretd, id_valuta_d, pret, id_valuta,
   curs, multiplicator, proc_tvav, id_jtva_coloana, cantitate, discount_unitar, id_gestiune, cont,
   pret_cu_tva, NULL, NULL, taxcode` — **fara `id_pol`**, pentru ca procedura insasi nu are un
   parametru `id_pol`.

3. **Semnatura `adauga_articol_factura_deviz`** (spec `ff_...:468-488`, corp `ff_...:4675-4745`):
   nu exista `V_ID_POL IN NUMBER` printre parametri. `INSERT INTO VANZARI_DETALII_TEMP` la
   `ff_...:4697-4744` **nu include coloana `ID_POL`** in lista de coloane inserate — deci
   `ID_POL` ramane pe valoarea implicita a coloanei (probabil NULL; DDL-ul tabelei nu face parte
   din pachetul cercetat, vezi Neverificat). **Asta confirma partea (a) a intrebarii: da, liniile
   "alte servicii" ajung cu `id_pol` gol** in `VANZARI_DETALII_TEMP`.

4. **Dar acele randuri nu trec niciodata prin `contabilizeaza_articol`.** Apelantul din
   `oproceduri_devize.prg` nu cheama `scrie_factura2` / `scrie_factura_avize` / `scrie_aviz_retur`
   (singurele proceduri care cheama `contabilizeaza_articol`, vezi punctul 3). In schimb cheama, in
   ordine (`oproceduri_devize.prg:1211-1310`):
   - `pack_facturare.initializeaza_date_factura(...)`
   - bucla `pack_facturare.adauga_articol_factura_deviz(...)` (doar insert in `VANZARI_DETALII_TEMP`)
   - opțional `pack_facturare.scrie_incasari(...)` (incasare, nu venit din vanzare)
   - `pack_facturare.scrie_in_vanzari(0, ...)` (`ff_...:13497-13962`)
   - `pack_auto.actualizeaza_deviz(...)` (`D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\03\ff_2026_03_31_02_AUTO_PACK_AUTO.sql:692-733`)

   **`scrie_in_vanzari` nu scrie nici o nota contabila de venit.** Corpul complet
   (`ff_...:13497-13962`) face: `INSERT INTO VANZARI` (antetul documentului), `scrie_cursuri`,
   `scrie_seturi`, apoi
   ```
   ff_...:13714-13766
   INSERT /*+ APPEND */ INTO VANZARI_DETALII (..., ID_POL, ...)
     SELECT ..., ID_POL, ... FROM VANZARI_DETALII_TEMP;
   ```
   (copiaza `ID_POL` — care e NULL pentru aceste randuri — direct in `VANZARI_DETALII`, fara nicio
   validare), si la final actualizeaza totalurile cache pe `VANZARI`. **Nu apare niciun apel catre
   `contabilizeaza_articol`, `scrie_nota`, `cumuleaza_note_act` sau `finalizeaza_factura` in acest
   corp** (verificat citind procedura cap-coada).

   `pack_auto.actualizeaza_deviz` (`ff_2026_03_31_02_AUTO_PACK_AUTO.sql:692-733`) face doar:
   ```
   SELECT MAX(ID_FACT) INTO lnIdFact FROM ACT WHERE COD = pack_contafin.get_cod() AND SCD NOT LIKE '5%';
   UPDATE DEV_ORDL SET PROC_TVAV = ... WHERE ID_ORDL IN (...);
   UPDATE RUL SET ID_FACT = lnIdFact WHERE ...;
   UPDATE NOM_LUCRARI SET ID_FACT = lnIdFact WHERE ... (doar pt anumite id_set);
   ```
   Adica **presupune ca exista deja un rand in `ACT`** (nu `ACT_TEMP`) cu `SCD NOT LIKE '5%'` pentru
   codul documentului curent, si doar propaga `ID_FACT` gasit acolo spre `DEV_ORDL`/`RUL`/`NOM_LUCRARI`.
   Nu insereaza el insusi in `ACT` sau `NOTE_CONTABILE`, si nu contine nicio referinta la `SCC`,
   `NOTE_CONTABILE` sau `CRM_POLITICI*` (cautat explicit, zero rezultate in acest fisier).

**Concluzie Q4, corectand premisa din cerere**: liniile "Alte servicii" chiar ajung cu `id_pol` gol
(confirmat), dar **nu demonstreaza ca `contabilizeaza_articol` tolereaza `id_pol` gol** — pentru ca
nu trec niciodata prin el. Ele demonstreaza doar ca exista deja, pentru fluxul deviz ROAAUTO, o cale
de facturare paralela (`scrie_in_vanzari` + `pack_auto.actualizeaza_deviz`) care **nu genereaza deloc
nota contabila de venit prin `pack_facturare`**. Daca acele randuri capata totusi un cont de venit in
`ACT`/`NOTE_CONTABILE` in productie, mecanismul nu e vizibil in codul cercetat (posibil un
trigger pe tabel, un job batch, sau o scriere manuala/alt modul neexaminat — vezi Neverificat).
**Nu se poate folosi acest precedent ca raspuns de fapt la intrebarea 1.**

---

## 5. Vreun mecanism care sa foloseasca `NOM_ARTICOLE.CONT` drept cont de venit

Raspuns: **NU**, in `pack_facturare`.

Cautat explicit `Grep -i 'NOM_ARTICOLE\.CONT'` pe intregul fisier
`ff_2026_08_06_10_COMUN_PACK_FACTURARE.sql` (17020 linii) — **zero potriviri**. Singurele utilizari
ale `NOM_ARTICOLE` gasite in `contabilizeaza_articol` insusi sunt pentru `DENUMIRE` (mesajul de
eroare FACT-024, `ff_...:7295-7298`), nu pentru `CONT`.

`crs_rand_articol.scc` (folosit ca `V_SCC` la `ff_...:7434`) vine exclusiv din
`D.SCC` din join-ul `CRM_POLITICI_PRET_ART -> CRM_POLITICI_PRETURI -> CRM_NOTE_VANZARI -> NOTE_CONTABILE`
(`ff_...:7261, 7275-7276`) — nu exista ramura alternativa care sa substituie `NOM_ARTICOLE.CONT`
cand politica lipseste. (Raportul anterior confirmase deja separat ca `NOM_ARTICOLE.CONT` e folosit
doar ca **cont de gestiune**, transmis catre `descarca_gestiune`, `ff_...:7499`.)

---

## Neverificat

- **Continutul efectiv al `NOTE_CONTABILE`/`CRM_POLITICI_PRET_ART`** (daca exista politici cu
  `ID_POL = 0`, ce SCC au liniile din productie pentru documente "alte servicii" existente) —
  necesita interogare pe baza de date, nu doar cod.
- **Constrangerile DDL** ale `VANZARI_DETALII_TEMP.ID_POL` si `ACT_TEMP.SCC`/`ACT.SCC` (NOT NULL?
  default?) — scripturile DDL ale acestor tabele nu au fost cautate/citite in aceasta cercetare
  (am cautat doar in pachetele PL/SQL `ff_...COMUN_PACK_FACTURARE.sql` si `..._AUTO_PACK_AUTO.sql`).
- **Cine scrie efectiv contul de venit (`ACT`/`NOTE_CONTABILE`) pentru documentele "alte servicii"
  din ROAAUTO**, daca se scrie deloc. `pack_auto.actualizeaza_deviz` presupune ca exista deja un
  rand `ACT` cu `SCD NOT LIKE '5%'` pentru codul documentului curent — sursa acelui rand nu a fost
  gasita in `oproceduri_devize.prg` sau in corpul `scrie_in_vanzari`/`actualizeaza_deviz` cercetate.
  Ar trebui cautat: alte proceduri `pack_auto` (fisierul `ff_2026_03_31_02_AUTO_PACK_AUTO.sql` are
  si alte proceduri necercetate aici), triggere pe `VANZARI`/`VANZARI_DETALII`/`ACT`, sau apeluri
  din alte forme VFP (`.scx`/`.vcx`) din ROAAUTO care preced acest apel RPC. Nu am cautat exhaustiv
  triggere in afara folderului `SCRIPTURI_CLAR\2026` (cautare limitata, zero rezultate acolo).
- **Ce se intampla exact daca `id_pol = 0` si exista o politica reala cu `ID_POL = 0`** (caz
  teoretic, neexclus explicit din schema) — ar schimba concluzia de la "eroare neprinsa" la
  "FACT-024 cu mesaj complet", dar tot ramane o eroare, nu un default silentios.