# Verificari pe baza de date vie — reteta contului de venit (#13, J-quater)

Rulat: **10.08.2026**, schema `MARIUSM_AUTO` pe `ROA_CENTRAL` (`10.0.20.121:1521`, `SERVICE_NAME=ROA`),
client `D:\ROA\instantclient_19_18\sqlplus.exe`. **Doar `SELECT`** — nicio scriere, nicio modificare de
structura. Raspunde la punctul 2 din „Ce ramane deschis" al `docs\handoff_13_formular_unificat.md`.

## Verdict, in trei randuri

**Pasul 1 al retetei (derivarea `SCC`) e sigur: zero ambiguitate, zero cazuri de cont de venit gol pe
articole reale.** **Pasul 2 (gasirea unei politici cu acel `SCC`) reuseste pentru 3 din 7 conturi
candidate si eșueaza pentru 4** — dar nu asa cum prevedea planul: **`704` are 19 politici valabile azi,
nu zero**, iar cele care lipsesc sunt `702`, `703`, `711`, `7018`. **Riscul serios nu e ambiguitatea, ci
`PTVA`-ul notei** — singura nota cu `SCC=707` are `PTVA=5`, deci alegerea politicii dupa `SCC` importa si
o cota de TVA care poate fi greșita.

## Doua corectii la planul si handoff-ul rundei 8

| Ce spune planul (J-quater, „Costurile") | Ce arata baza vie |
|---|---|
| „pentru **704** nu s-a gasit nicio nota configurata, deci trebuie creata o data din ecranul de configurare note contabile" | **FALS.** `704` e cel mai bine acoperit cont: **4 note de vanzari** (`NOTA 1`, `COMISION INTERMEDIERE`, `SERVICII VALUTA`, `SERVICII TRANSPORT`) si **25 de politici** (19 valabile azi). `NOTA 1` — nota implicita a majoritatii politicilor — are exact `SCC=704`. **Pasul de creare a notei pentru 704 se scoate din plan.** |
| „`CONT_VENIT` are date reale (**20 de conturi**, migrare 2023)" | **Imprecis.** Tabelul are **41 de randuri active**; exact **20** au `CONT_VENIT` populat. Restul 21 sunt conturile de ajustari (`391`…`398`, toate cu `CONT_CHELT=681`) — vezi mai jos de ce nu conteaza. |

Ce **se confirma** din plan: `CONT_VENIT` **n-are consumatori** (nu am verificat aici — a fost stabilit pe
cod in runda 8); lantul invers e realizabil; ambiguitatea „mai multe politici cu acelasi `SCC`" e reala.

## 1. DDL-ul lui `CORESP_CONT_VENCHELT` (cerut explicit in handoff)

| # | Coloana | Tip | Null |
|---|---|---|---|
| 1 | `ID_CCV` | `NUMBER(10,0)` | N |
| 2 | `CONT` | `VARCHAR2(4)` | Y |
| 3 | `CONT_CHELT` | `VARCHAR2(4)` | Y |
| 4 | `CONT_VENIT` | `VARCHAR2(4)` | Y |
| 5 | `STERS` | `NUMBER(1,0)` | N |
| 6 | `DATAORAS` | `DATE` | Y |
| 7 | `CONT_APROVIZIONARE` | `VARCHAR2(4)` | Y |
| 8 | `CONT_DIFERENTE` | `VARCHAR2(4)` | Y |

Constrangeri: **doar** `PK_CORESP_CONT_VENCHELT` pe `ID_CCV`, plus `NOT NULL` pe `ID_CCV` si `STERS`.
**Nu exista unique pe `CONT`** — deci nimic in schema nu impiedica doua randuri pe acelasi cont de
gestiune. In date insa **nu exista niciun `CONT` duplicat**, deci pasul 1 al retetei e determinist azi.
Fragilitatea e de tip „merge pana nu merge": daca cineva adauga un al doilea rand pe `301`, derivarea
devine ambigua fara ca nimic sa semnaleze.

## 2. Continutul relevant al tabelului — cele 20 de randuri cu cont de venit

| `CONT` (gestiune) | `CONT_CHELT` | **`CONT_VENIT`** |
|---|---|---|
| `231` | `212` | `707` |
| `301`, `302`, `3021`–`3028`, `303` | `601`, `602`, `6021`–`6028`, `603` | **`707`** (13 randuri) |
| `331`, `332` | `711` | `711` |
| `341` | `711` | `702` |
| `345`, `348` | `711` | `7015` |
| `346` | `711` | `703` |
| `361` | `711` | `7018` |
| `371` | `607` | `707` |
| `381` | `608` | `707` |

Cele 21 de randuri fara `CONT_VENIT` sunt `391`, `392`, `3921`, `3922`, `393`, `394`, `3941`, `3945`,
`3946`, `395`, `3951`–`3958`, `396`, `397`, `398` — toate cu `CONT_CHELT=681`, adica **ajustari pentru
depreciere**, nu conturi de gestiune pe care sta marfa.

**Si contează**: `articole_pe_cont_cu_venit_gol = 0`. Niciun articol activ din `NOM_ARTICOLE` nu are
`CONT`-ul pe un rand cu `CONT_VENIT` gol. **Deci ramura „cont de venit derivat gol" nu are cazuri reale**
— trebuie tratata defensiv, dar nu e un scenariu de acoperit in UX.

## 3. Interogarea inversa — rezultatul pe fiecare `SCC` candidat

```sql
with cand as (select column_value scc from table(sys.odcivarchar2list('707','711','702','703','7015','7018','704')))
select c.scc, count(distinct p.id_pol) pol,
       count(distinct case when nvl(p.datai,date '1900-01-01')<=trunc(sysdate)
                            and nvl(p.datas,date '2999-12-31')>=trunc(sysdate)
                       then p.id_pol end) pol_valabile_azi,
       count(distinct nc.id_set) seturi, count(nc.id_note) nc_randuri
  from cand c
  left join note_contabile nc on nc.scc = c.scc
  left join crm_note_vanzari nv on nv.id_set = nc.id_set and nvl(nv.sters,0)=0
  left join crm_politici_preturi p on p.id_nota = nv.id_nota and p.sters=0
 group by c.scc;
```

| `SCC` | Politici | **Valabile azi** | Seturi cu acest `SCC` | Randuri `NOTE_CONTABILE` | Verdict pentru pasul 2 |
|---|---|---|---|---|---|
| **`704`** | 25 | **19** | 7 | 28 | **reuseste**, cu ambiguitate mare |
| **`707`** | 4 | **4** | 5 | 8 | **reuseste**, ambiguitate mica |
| **`7015`** | 1 | **1** | 1 | 1 | **reuseste, caz ideal** |
| `711` | 0 | 0 | 4 | 4 | **eșuează** — note exista, dar **nicio politica** nu le foloseste |
| `702` | 0 | 0 | 3 | 3 | **eșuează** — idem |
| `703` | 0 | 0 | 3 | 3 | **eșuează** — idem |
| `7018` | 0 | 0 | **0** | **0** | **eșuează total** — nu exista nici macar nota |

Citit pe conturile de gestiune: reteta merge pentru marfa (`301`–`303`, `371`, `381`, `231` → `707`) si
pentru produsele din `345`/`348` (→ `7015`), plus pentru orice cade pe fallback-ul `704`. **Nu merge**
pentru `331`/`332` (→ `711`), `341` (→ `702`), `346` (→ `703`), `361` (→ `7018`) — adica **producția
neterminată, semifabricatele, produsele reziduale si ambalajele**.

Distinctia care conteaza la `711`/`702`/`703`: **nota exista, doar politica lipseste.** Costul de
configurare e „ataseaza nota existenta unei politici", nu „creeaza nota de la zero". Doar `7018` cere
si nota noua.

## 4. Riscul pe care planul nu l-a vazut: `PTVA` si `IN_VALUTA` de pe nota

Cele 7 note de vanzari active, cu nota contabila atasata:

| `ID_NOTA` | Denumire | `ID_SET` | `SCD` | **`SCC`** | **`PTVA`** | `CU_TVA` | **`IN_VALUTA`** |
|---|---|---|---|---|---|---|---|
| 1 | `NOTA 1` | 251023 | `4111` | **704** | **21** | 1 | 0 |
| 2 | `DISCOUNT` | 251024 | `667` | 4111 | 21 | 1 | 0 |
| 3 | `COMISION INTERMEDIERE` | 251025 | `4111` | **704** | **0** | 1 | **1** |
| 4 | `SERVICII VALUTA` | 251026 | `4111` | **704** | **0** | 1 | **1** |
| 5 | `VANZARE MARFA` | 251027 | `4111` | **707** | **5** | 1 | 0 |
| 6 | `PRODUCTIE` | 251028 | `4111` | **7015** | 21 | 1 | 0 |
| 7 | `SERVICII TRANSPORT` | 251029 | `4111` | **704** | 21 | 1 | 0 |

> **RETRAS — verificat pe cod si infirmat.** Ingrijorarea de mai jos, formulata la prima citire a acestor
> date („`PTVA=5` pe singura nota cu `SCC=707` produce TVA greșit"), **nu se susține**.
> `docs\cercetare\s10_pret_rederivat.md`, „Completare: nota contabila a politicii" p. 2: `cursor_articol`
> (`PACK_FACTURARE:7218-7271`) **nu selecteaza `D.PTVA`**; cota folosita e
> `detalii_articol.proc_tvav * 100 - 100` (`:7464`), din articol / document. Coloana e moarta pentru
> `contabilizeaza_articol`. Iar `IN_VALUTA=1` pe un document in lei nu da eroare si nu strica suma —
> doar populeaza redundant `ACT_TEMP.SUMA_VAL` la curs 1. **Deci criteriul de selectie NU trebuie extins
> cu `PTVA` / `IN_VALUTA`.** Se pastreaza textul de mai jos doar ca urma a raționamentului; nu se citeaza
> ca risc.

Ce **rămâne** ca risc real din aceste date, si e mai grav: `cursor_articol` face `LEFT JOIN
NOTE_CONTABILE ON C.ID_SET = D.ID_SET` fara `ROWNUM` si fara agregare, iar bucla care il consuma executa
`scrie_nota` **si** `descarca_gestiune` o data **pentru fiecare rand al setului**, cu pretul si cantitatea
intregi de fiecare data. Deci un set cu N randuri = **venit inregistrat de N ori si gestiune descarcata de
N ori**. Cele 7 note de vanzari active au exact un rand fiecare — dar **30 din cele 40 de seturi din baza
au mai multe, cu maxim 30**. Vezi punctul 6.1 mai jos.

Ce planul enunta drept **avantaj** al retetei — „politica reala aduce si `CU_TVA`, `IN_VALUTA`,
`EXPLICATIE`, `ASCD`, `ASCC`" — se confirma ca argument, cu nuanta ca `ASCD`/`ASCC` au oricum fallback
automat din grupul de utilizatori, deci nu ele justifica alegerea.

Textul original al ingrijorarii, pastrat pentru trasabilitate:

- **`707` are o singura nota, si aceea cu `PTVA=5`.** Pentru marfa (majoritatea articolelor de gestiune)
  singurul rezultat posibil al pasului 2 e nota cu TVA 5%.
- **Doua din cele patru note cu `SCC=704` au `IN_VALUTA=1`** (`SERVICII VALUTA`, `COMISION INTERMEDIERE`),
  deci o potrivire pe `SCC` poate ateriza pe ele pe un document in lei.

Colateral util pentru **S4c**: exista deja o nota de discount configurata — `id_nota=2`, `SCD=667` /
`SCC=4111`. Nu e o eroare de configurare (explica randul `SCC=4111` din agregat), e nota folosita pentru
discount. De verificat la S4c daca discountul pe linie trece prin ea.

## 5. Efectul colateral al pasului 3 — politica **este** o lista de preturi

Pasul 3 al retetei insereaza articolul in politica alesa, prin `pack_preturi.adauga_politica_pret_art`.
Politicile candidate, cu numarul de articole pe care le contin azi:

| `SCC` | `ID_POL` | Nume | Articole |
|---|---|---|---|
| `7015` | 41 | `STOC PRODUSE` | **6310** |
| `707` | 39 | `LISTA PRETURI LEI` | **909** |
| `707` | 40 | `LISTA PRETURI CU TVA EURO` | 2 |
| `707` | 47 / 62 | `DEPOZIT ELI` / `DEPOZIT ELI_31/07/2025 11:07:25` | 3 / 3 |
| `704` | 2 | `LISTA 2` | 19 |
| `704` | 34 | `LISTA 2 - EURO` | 12 |
| `704` | 36 | `SERVICE AUTO` | 9 |
| `704` | 35 | `LISTA STANDARD EURO` | 8 |
| `704` | 9 | `CHIOSC` | 5 |
| `704` | 6, 12, 13, 14, 15, 16 | `LISTA DE PROBA`, `S5 ZILNIC`, `S6 WEEKEND SEZON`, `S7 CRACIUN`, `S3 PASTE`, `S3 1MAI` | 4 fiecare |
| `704` | 65, 66 | `TRANSPORT`, `SERVICII INFORMATICE` | 1 fiecare |
| `704` | 26, 27, 28, 29, 30, 31 | `S6 ZILE IARNA`, `S8 REVELION`, `S1 IARNA2`, `S1 IARNA2 WEEKEND`, `S2 PRIMAVARA`, `S7 CRACIUN` | **0** |

**Astea sunt liste de preturi reale, cu nume de client si de sezon.** Daca reteta alege `LISTA PRETURI
LEI` sau `STOC PRODUSE` pentru un articol adaugat ad-hoc pe factura, articolul **apare de acum in lista
de preturi a acelui context**, cu pretul cu care a fost facturat o data. Asta e efectul pe care planul il
descrie drept „politica tehnica populata automat" — dar **numai daca politica e chiar tehnica**.
Alegerea unei politici comerciale existente **poluează o lista de preturi de producție**.

Consecinta de proiectare, de dus in J-quater: pasul 2 nu trebuie sa caute *orice* politica cu `SCC`-ul
potrivit, ci **o politica tehnica dedicata, una per `SCC`**, creata anume — modelul
`gnId_pol_pret_stoc` extins de la o politica la sapte. Cele sase politici cu **0 articole** arata ca o
politica goala e o stare acceptata de produs.

Detaliu care ajuta: **majoritatea politicilor cu `SCC=704` trimit la aceeasi `id_nota=1`**. Deci
ambiguitatea celor 19 politici e ambiguitate de **lista de preturi**, nu de rezultat contabil — toate dau
acelasi `704` / `PTVA=21` / lei. Cu atat mai mult, criteriul de alegere trebuie sa fie „care lista de
preturi vreau sa murdaresc", si raspunsul corect e „niciuna dintre cele existente".

## 6. Fragilitati masurate, de trecut in Riscuri

1. **`ID_SET` cu mai multe randuri dubleaza venitul si descarcarea de gestiune.** Pe cele 7 seturi
   folosite de politici, fiecare are exact **1** rand `NOTE_CONTABILE`. Dar in tabel sunt **40 de seturi,
   din care 30 au mai multe randuri**, cu maxim **30 de randuri pe set**. Confirmat pe cod
   (`s10_pret_rederivat.md`, Completare p. 1): `cursor_articol` face `LEFT JOIN ... ON C.ID_SET =
   D.ID_SET` **fara `ROWNUM`, fara agregare, fara filtru**, iar bucla `:7393-7542` executa `scrie_nota`
   **si** `descarca_gestiune` o data per rand, **cu aceeasi cantitate si acelasi pret intreg**, fara
   distributie (`ORDINE` nu apare in tot pachetul). Deci pasul 2 al retetei trebuie sa garanteze **un
   singur rand pe setul ales**, nu doar un rand cu `SCC`-ul potrivit. Conditia care face reteta sigura
   azi e o coincidenta a datelor, nu o garanție a codului sau a schemei.
2. **Doua politici active fara `ID_NOTA`**: `32 HOTEL TAXE` si `33 HOTEL CAZARE` (ambele valabile
   01.01.2010–31.12.2099, `id_valuta=3`). Un articol pe una din ele are `id_pol` valid dar **fara nota** —
   comportament neverificat, intrebare trimisa agentului pe `PACK_FACTURARE`. E o gaura care **exista
   deja azi**, independenta de #13.
3. **Fara unique pe `CORESP_CONT_VENCHELT.CONT`** — vezi punctul 1.

## 7. Distributia articolelor — cat de mult conteaza fiecare ramura a deciziei 27

`NOM_ARTICOLE`, 6430 articole active:

| Prima cifra din `CONT` | Articole | Conturi distincte | Ramura deciziei 27 |
|---|---|---|---|
| `3xx` | **6125** | 9 | gestionabil → `CORESP_CONT_VENCHELT` |
| `8xx` (toate `8035`) | 26 | 1 | nu e 6xx/7xx, nu e in `CORESP` → **`704`** |
| `6xx` | 22 | 5 | `NOM_ARTICOLE.CONT` ca atare |
| `7xx` | 20 | 6 | `NOM_ARTICOLE.CONT` ca atare |
| `1xx` | 4 | 2 | → `704` |
| `4xx` | 3 | 2 | → `704` |
| `0xx` | 1 | 1 | → `704` |
| `2xx` | 1 | 1 | → `704` |
| **fara `CONT`** | **228** | — | → `704` |

Conturi de pe articole care **nu** sunt 6xx/7xx si **nu** apar in `CORESP_CONT_VENCHELT.CONT`, deci cad pe
`704`: `8035` (26 articole), `123` (3), `446` (2), `111`, `409`, `0`, `212`, `37` (1 fiecare).

**Ramura dominanta e de departe cea gestionabila** — 6125 din 6430. Iar ea trimite in majoritate spre
`707`, adica spre cazul cu `PTVA=5`. Cele 228 de articole fara cont si cele 26 pe `8035` fac fallback-ul
`704` un caz real, nu teoretic — si acolo reteta functioneaza.

Nota: `212` apare pe un articol, dar in `CORESP_CONT_VENCHELT` figureaza ca `CONT_CHELT` (pe randul
`231`), nu ca `CONT`. Deci cade corect pe `704` prin regula deciziei 27.

## Ce nu s-a putut stabili aici, si de ce

- **Ce face `contabilizeaza_articol` cu `PTVA` / `CU_TVA` / `IN_VALUTA` ale notei** — e intrebare de cod,
  nu de date. Trimisa agentului deja incarcat in `PACK_FACTURARE`; raspunsul intra in
  `docs\cercetare\s10_pret_rederivat.md`, sectiunea „Completare: nota contabila a politicii". **Pana
  atunci pasul 2 al retetei nu se considera validat.**
- **Daca `CONT_VENIT` chiar n-are consumatori** — stabilit pe cod in runda 8, nu reverificat pe date.
- **Comportamentul politicii fara nota** — idem, intrebare de cod, trimisa.
- Verificarile sunt pe **schema de dezvoltare** `MARIUSM_AUTO`. Datele sunt reprezentative (liste de
  preturi cu nume reale, 6430 articole), dar **o baza de client poate avea alta configurare de note** —
  in special poate avea deja politici pe `711` / `702` / `703`. Concluziile pe **structura** (lantul,
  absenta unique-ului, `ID_SET` multi-rand) sunt insa independente de date.

## Reproducere

Cele trei scripturi rulate, in ordine: descoperire DDL/coloane · interogarea inversa pe `SCC` ·
efecte colaterale si distributii. Interogarea-cheie e citata integral la punctul 3. Rulare:

```powershell
& 'D:\ROA\instantclient_19_18\sqlplus.exe' -L -S 'MARIUSM_AUTO/ROMFASTSOFT@ROA_CENTRAL' '@fisier.sql'
```

SQL-ul se scrie in fisier **ASCII**, nu prin pipe din PowerShell (BOM-ul UTF-16 sparge parserul), si cu
`linesize 32767` — vezi `COMUN\docs\oracle_export.md`.