251 lines
15 KiB
Markdown
251 lines
15 KiB
Markdown
# 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`.
|