roafacturare/docs/cercetare/verif_baza_vie_cont_venit.md

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

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:

& '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.