799 lines
62 KiB
Markdown
799 lines
62 KiB
Markdown
# Handoff — #13 formular unificat de facturare + editare prin regenerare
|
||
|
||
Sesiune: 11.08.2026, **runda 17** (istoricul de mai jos e cumulativ; blocul rundei 14 e pastrat ca
|
||
atare). Runda 13 predase dupa cinci proiectari si deciziile 44-50.
|
||
|
||
> ## RUNDA 17 — „Urmatorul bloc de lucru" S-A GOLIT. Proiectarea lui #13 e INCHEIATA.
|
||
>
|
||
> Runda 17 a executat **exact cele doua sarcini** care mai ramasesera (punctele 4 si 5 din lista de
|
||
> jos) si **nu a deschis niciuna noua**.
|
||
>
|
||
> > ### DECIZIA 66 (runda 17) RASTOARNA DECIZIA 64 — citeste asta inainte de orice paragraf despre asezare
|
||
> > **Motivul discountului sta LANGA DISCOUNT, in banda de totaluri, nu ca a treia sectiune jos.**
|
||
> > Formularea lui Marius: *„motiv discount vreau sa fie langa discount, nu a treia coloana"*.
|
||
> > **Randul de jos revine la DOUA sectiuni** (incasare, alte date), fiecare pe jumatate de latime —
|
||
> > adica exact decizia 57, punctul 2, neatinsa. **Argumentul „~440 px fiecare, strans" cade odata cu
|
||
> > decizia 64.** Mai jos, in istoricul cumulativ al rundei 16, decizia 64 apare inca in vigoare in
|
||
> > cateva paragrafe: **sunt istorie, nu stare curenta.** Locurile decisive sunt corectate; daca
|
||
> > gasesti unul necorectat, **decizia 66 castiga**. Enuntul complet, cu regula de activare adaugata de
|
||
> > proiectare (campul e activ **doar cand discountul nu e zero**): **in plan**, la „Decizia 66".
|
||
>
|
||
> **O singura decizie noua, 66**, deci numerotarea se opreste la **66**.
|
||
|
||
> ### AUDIT DE INCHIDERE (18.08.2026) — planul e curatat de marcajele „deschis" ramase in urma
|
||
> Verificare ceruta de Marius inainte de a inchide sesiunea: **e planul finalizat?** Raspuns: **da ca
|
||
> proiectare**, dar avea **noua intrebari fantoma** — blocuri „De decis de Marius" si „ramane deschis"
|
||
> care supravietuisera deciziilor care le inchisesera. Un agent proaspat le-ar fi citit ca sarcini si
|
||
> ar fi redeschis lucruri transate. **Toate au fost stinse**, fiecare cu decizia care o inchide, in
|
||
> **8 linii** din plan (verificat prin diff fata de o copie de siguranta: zero modificari colaterale):
|
||
> - trei blocuri **„De decis de Marius"** (S5c, S8b, S11) → inchise de deciziile **51**, **52**, **53**
|
||
> si **56**; textul ramane ca **inventar al recomandarilor acceptate**, nu ca intrebari;
|
||
> - doua afirmatii „ramane deschisa asezarea campului de motiv" → inchise de **decizia 66**;
|
||
> - „din intrebarea 7 ramane deschisa partea de tipuri 48/49" → inchisa de **decizia 60**.
|
||
>
|
||
> **Ce a ramas deschis, si e corect asa — trei puncte, toate de implementare, niciunul blocant:**
|
||
> 1. **Relistarea unei facturi vechi deja trimise** (decizia 62, rest semnalat): dupa decizia 59 ar
|
||
> produce N randuri de discount in loc de unul, deci hartie diferita de originalul din eFactura.
|
||
> Relistarea nu e modificare, deci `EsteInEFactura` n-o acopera. **Nedecis, semnalat lui Marius.**
|
||
> 2. **`PROC_TVAV` ca parametru** (consecinta 3 a deciziei 54): doar daca se cere reproducere exacta
|
||
> peste o modificare legala de cota. **De decis separat.**
|
||
> 3. **De unde se reconstituie `IN_STOC`** (cerinta rundei 17): preconditie de proiectare a lui S8,
|
||
> trei variante scrise, niciuna aleasa.
|
||
> **Cod: neatins** — nici un `.vc2` / `.sc2` / `.prg` deschis macar. **Zero Oracle** in aceasta runda,
|
||
> nici macar `SELECT`. **Niciun commit dat de aceasta sesiune.**
|
||
>
|
||
> **Punctul 4 — golul `IN_STOC` din S8 — INCHIS**, prins acolo unde cerea handoff-ul precedent (in nota
|
||
> de executie a lui S8, nu la S12). Trei editari in plan, toate verificate pe disc dupa ce sesiunea de
|
||
> la #6 a rescris `docs\` in paralel:
|
||
> - `plan_13:3520-3546` — caseta „CERINTA DE EXECUTIE ADAUGATA IN RUNDA 17";
|
||
> - `plan_13:3567-3569` — criteriul intra in „gata cand" al lui S8;
|
||
> - `plan_13` la S10, consecinta 1 — marcata **PRELUAT**, ca sa nu se redescopere.
|
||
>
|
||
> **Punctul dur, si e mai greu decat suna cerinta:** valoarea istorica a lui `IN_STOC` **nu e stocata
|
||
> nicaieri** — nu e coloana pe `VANZARI_DETALII` (verificat pe DB inca de la S10), traieste doar in
|
||
> temp. Deci „S8 incarca `IN_STOC` din document" **nu e implementabil ca atare azi**. De unde se
|
||
> reconstituie e o **preconditie de proiectare a lui S8** — trei variante scrise in plan (din urma
|
||
> lasata in rulaje/gestiune; nomenclatorul curent ca aproximatie **declarata**; coloana noua, deci
|
||
> migrare DB inainte de EXE). **Nu s-a ales niciuna** si nu se presupune niciuna.
|
||
>
|
||
> **Punctul 5 — mockup v9 — LIVRAT.** `docs\mockup_13_formular_unificat.html`, 71 336 octeti (era
|
||
> 67 075 la v8). Asezarea e acum **varianta D** cu **randul de jos in doua** si motivul discountului in
|
||
> banda de totaluri (deciziile 57 + 66):
|
||
> antet strans pe doua randuri fara titluri de grup; panoul „Discount pe document" **disparut**; banda
|
||
> de totaluri **in interiorul panoului Articole, dupa `.gridbar`**, deci lipita de grid, cu procentul
|
||
> de discount editabil pe loc, **motivul discountului imediat dupa suma pe care o explica** (decizia
|
||
> 66) si totalul mare singur la dreapta; sub ea, **doua** sectiuni colapsabile egale
|
||
> (incasare · alte date), cu **rezumatul continutului pe randul inchis**.
|
||
> Legenda are acum 5 callout-uri (2 si 4 repurpozate, 5 nou). In text au intrat deciziile
|
||
> **52, 53, 54, 59, 60, 61, 62, 63+65**. Raport: `docs\cercetare\mockup_v9_modificari.md`.
|
||
> **Verificat de sesiunea principala, nu preluat din raport:** 0 taguri nechise, 0 inchideri
|
||
> neasteptate, `<style>` unic si inchis.
|
||
>
|
||
> **Mockup-ul E REPUBLICAT** (Marius a cerut-o in aceeasi runda), **pe URL-ul existent, nu pe unul nou**:
|
||
> **https://claude.ai/code/artifact/e9d73e86-7518-4f50-a998-43c49e083142**. Cu asta decizia 33 e
|
||
> consumata — URL-ul nu mai e in urma, e la v9. **URL-ul e notat acum si in plan**, la S1; pana in runda
|
||
> 17 nu exista nicaieri in `docs\` si a trebuit scos cu `Artifact action: "list"`.
|
||
> Inainte de publicare s-a facut **WebFetch pe URL** (obligatoriu, altfel publicarea e refuzata) si s-a
|
||
> confirmat ca versiunea online era **v8**, deci v9 e superset si nu s-a suprascris nimic.
|
||
>
|
||
> **Ce ramane dupa runda 17:** *nimic de proiectat*. Raman **testele (S6, S12)** si **inchiderea
|
||
> (S13)**, si amandoua cer cod, care nu poate incepe inainte de #6 (decizia 30). Prima sarcina la
|
||
> pornire: **spargerea planului pe stories** + nota de executie a primeia (decizia 55).
|
||
Stare: **ETAPA I E PROIECTATA INTEGRAL. ETAPA II E PROIECTATA INTEGRAL — S8 a fost ultima poveste, si
|
||
e gata. Raman testele (S6, S12), diff/review (S13), si O SINGURA VERIFICARE PE COD, in curs. Cod:
|
||
neatins.** Runda 14 a livrat **doua rapoarte** (S8 in detaliu, garda pe aviz), a luat **deciziile
|
||
51-54**, si a **rasturnat doua premise**: una despre garda existenta (era inteleasa pe dos), alta
|
||
despre S10 (Marius a respins intrebarea, nu a ales dintre variante).
|
||
|
||
**Din partea rundei 14, nimic nu e intr-o stare periculoasa.** Niciun `.vc2` / `.sc2` editat, **niciun
|
||
write-back**, niciun `git_sync.ps1` / `txt2vcx.ps1` rulat, nicio tranzactie deschisa, niciun commit.
|
||
Pe Oracle **numai `SELECT`-uri** (`all_source`, `all_tab_columns`, distributia `VANZARI_CORESP.TIP`),
|
||
pe `MARIUSM_AUTO`. Singurele fisiere scrise sunt in `docs\` — planul, acest handoff, doua rapoarte noi.
|
||
|
||
**Verificarea S10 s-a terminat** (`docs\cercetare\s10_rederivare_pe_calea_reemiterii.md`, 245 randuri,
|
||
toate cele 6 intrebari) si e integrata in plan.
|
||
|
||
**Runda 15 (11.08.2026) a inchis asezarea zonei de jos: varianta D, decizia 57, aprobata de Marius.**
|
||
Cu ea, **punctul 17 din lista de deschise cade**. Deciziile 57 si 58 sunt in plan, la „Deciziile lui
|
||
Marius, runda 15"; S1 e actualizat. **Cod: tot neatins.** Singurele scrieri ale rundei: acest handoff,
|
||
plan-ul, si artifactul de asezare. **`docs\mockup_13_variante_asezare_jos.html` a fost scos din
|
||
`docs\`** la cererea lui Marius („doar online, ca sa nu mai intretii 2 variante") — daca il cauti si
|
||
nu-l gasesti, nu s-a pierdut, e la URL-ul din punctul 3.
|
||
|
||
**Runda 16 (11.08.2026) a inchis punctul 1 din „Urmatorul bloc de lucru", integral.** Cele doua
|
||
rapoarte de discount au fost **citite**, cele trei afirmatii portante ale lor **verificate la sursa**
|
||
(toate rezista), rapoartele **imbinate** intr-unul singur, rezultatul **integrat in plan** (sectiune
|
||
noua **K-bis**, plus S1, decizia 56 si decizia 57), si raspunsul **dat lui Marius**. **Marius a
|
||
raspuns in aceeasi runda: decizia 59 — repartizare proportionala pe cote.** Cu asta **punctul 18
|
||
iese si din cercetare, si din decizie** pe partea principala; cele doua fire mici (campul de motiv,
|
||
retroactivitatea la relistare) **s-au inchis si ele, tot in runda 16 — decizia 61 (camp: da) si
|
||
decizia 62 (restrictia e strict `EsteInEFactura`, fara legatura cu data)**. Runda 16 a mai luat si
|
||
decizia 60 (tipurile 48/49 editabile) si decizia 63 (cerinta noua de audit). **Cod: tot neatins.**
|
||
|
||
**Tot runda 16 a mai inchis TREI cercetari, toate cu rezultatul integrat in plan si verificat la
|
||
sursa de sesiunea principala** (nu preluat din rapoarte):
|
||
1. **Custodia (48/49)** — `custodie_48_49_stergere_reemitere.md`. Blocantul de la decizia 60 **cade**:
|
||
nu e nimic de reversat, fiindca emiterea lor nu atinge stocul. **Premisa era gresita** —
|
||
`scrie_fact_aviz_custodie` serveste `ntip = 4`, nu custodia. Ramane **cerinta** ca S4/S4g/S5 sa
|
||
pastreze restrictia `IN_STOC = 0`.
|
||
2. **Auditul** — `audit_vanzari_creare_modificare_stergere.md`, proiectat ca **S14**. Patru din sase
|
||
informatii exista deja; lipseste perechea de modificare; regenerarea ar suprascrie tacit crearea.
|
||
3. **Stocul la stergere** — `stoc_la_stergere_si_reemitere.md`. **Nu e blocant**, dar din alt motiv
|
||
decat parea: `sterge_factura` nu reverseaza rulajele, o face `PACK_CONTAFIN.STERGE_DIN_RUL` prin
|
||
`oscrie_in_fisiere`. Deci **tripleta din S9 nu se simplifica** — vezi S9 si sectiunea „Teste".
|
||
|
||
**Cu asta „ce ramane de proiectat" e din nou gol**, in afara de S14 care tocmai a fost scris. Raman
|
||
testele (S6, S12), diff/review (S13). **Cele trei intrebari mici lasate lui Marius — asezarea
|
||
campului de motiv (decizia 61) si cele doua de la S14 (audit numai pe antet sau si pe linii; se
|
||
afiseaza in interfata sau e doar pentru interogare) — au primit toate raspuns, tot in runda 16:
|
||
decizia 64 (randul se imparte in trei) si decizia 65 (audit in gridul din `frm_facturi`, deci pe
|
||
antet). Nu mai ramane nicio intrebare deschisa pentru Marius.**
|
||
|
||
> ### REZOLVAT IN RUNDA 16 — rapoartele de discount sunt citite, verificate, imbinate si integrate
|
||
> Caseta ramane ca inventar al rezultatului, **nu mai e o sarcina**. Nu relua nimic din ea.
|
||
>
|
||
> | fisier | stare |
|
||
> |---|---|
|
||
> | `docs\cercetare\discount_document_cota_tva.md` | **raportul unic**, 44 KB — rezultatul imbinarii; aici se citeste |
|
||
> | `docs\cercetare\discount_document_cota_tva_b.md` | **ramane pe disc ca sursa** a partii adaugate (3.1-3.3, 2.3, 4.1); nu se sterge, nu se mai citeste separat |
|
||
>
|
||
> **Imbinarea E FACUTA.** Structura noua: sectiunile **3.1** (masuratoarea `IIF`/NULL), **3.2**
|
||
> (grupul orfan pe factura scutita), **3.3** (validarea offline cu control negativ), plus completari
|
||
> in 2.3, 4.1 si 5. Cele trei casete de avertizare vechi („sectiunea 3 nu e inchisa", blockquote-ul
|
||
> din capul sectiunii 4, mentiunea din „Raspunsul scurt") au fost **inlocuite cu rezultatul**, nu
|
||
> lasate alaturi de el.
|
||
>
|
||
> **Cele trei afirmatii portante au fost verificate la sursa de sesiunea principala. Toate rezista:**
|
||
> - **masuratoarea `IIF`/NULL** — sonda `probe_null.prg` citita si confruntata cu
|
||
> `xmlefactura.prg:226-248`: reproduce fidel acelasi `LEFT JOIN` si aceeasi cheie de grupare;
|
||
> iesirea reala arata **1 grup** (contopire), `IIF()` da ramura falsa, nu `.NULL.`;
|
||
> - **controlul negativ din validare exista si chiar iese cu erori** — `control_stricat.txt` are exact
|
||
> `[BR-CO-13]` + `[BR-CO-15]`, in timp ce restul au `ok`. Deci validatorul discrimineaza;
|
||
> - **identitatea SHA256** — confirmata cu `Get-FileHash`:
|
||
> `3303AFE34BC9E3E84DA9B3527C435DD9B8CB0BC7881D7D2F660A250237E23C64`, XML-ul de pe disc = cel din
|
||
> `TRIMISE`. Iar continutul din `ERORI` e un mesaj de 446 octeti pentru o incarcare **anterioara**,
|
||
> cu alt index, pe `BR-CO-15` + `BR-CL-04`.
|
||
>
|
||
> **In plus, o observatie noua a sesiunii principale, care nu exista in niciun raport** (acum in
|
||
> raport, §4.1): fisierul `...2885...` e o factura **integral scutita** cu alocare de document, si are
|
||
> **un singur `TaxSubtotal`, net** (`4410.00 − 539.82 = 3870.18`), fara grup orfan. Cum `expltva` face
|
||
> parte din cheia de grupare, contopirea **dovedeste** ca pseudo-linia purta un `id_jtva_coloana` real
|
||
> — deci era discount **pe linie**. E un **al treilea indiciu independent** ca cele 4 XML-uri de
|
||
> productie sunt discounturi pe linie, si arata **pozitiv forma corecta** pe o factura scutita — exact
|
||
> forma pe care o recomanda reparatia. Rezerva: fisierul e din 02.2024, inferenta presupune traseul de
|
||
> cod neschimbat.
|
||
>
|
||
> **Ce raporta al doilea agent, acum verificat si integrat:**
|
||
> - **Ipoteza bazei negative e GRESITA pe factura obisnuita** — masurat headless, nu dedus: `IIF()` din
|
||
> VFP intoarce **ramura falsa, nu `.NULL.`**, cand conditia e nula. Deci pseudo-linia de discount se
|
||
> contopeste corect in grupul cotei maxime, si **sectiunile 3-4 ale raportului principal raman
|
||
> valabile**.
|
||
> - **Se confirma insa pe facturile scutite / taxare inversa / intracomunitare**, unde liniile reale au
|
||
> `scutit = 1` si `expltva` completat iar pseudo-linia are `0` si gol: apare un **`TaxSubtotal` in
|
||
> plus, cu baza negativa si categoria `Z`**, si `agettipcota(1)` devine ambiguu.
|
||
> - **Nu blocheaza factura:** validat cu **DUKIntegrator offline**, 6 scenarii, **inclusiv un control
|
||
> negativ care chiar iese cu erori** (BR-CO-13/BR-CO-15) — fara el cele cinci „ok" n-ar fi dovedit
|
||
> nimic. Trece inclusiv un caz cu `TaxableAmount = -400.00`. Regulile pe categorii (BR-S/E/Z-08) se
|
||
> satisfac trivial, deci **aritmetica inchide si niciun schematron nu prinde greseala de modelare**.
|
||
> Avertisment propriu: jar-ul local e din 2022, validatorul online curent poate fi mai strict.
|
||
> - **`currencyID="RON"` hardcodat e neconformitate reala si activa**, dovedita pe fisier: XML-ul EUR
|
||
> de la VENDING_MASTER e identic pe SHA256 cu cel din `TRIMISE` (deci exact ce a plecat la ANAF) si
|
||
> **a fost acceptat**. Respingerea din `ERORI` e a unei incarcari anterioare, pentru alte reguli.
|
||
> Deci: neconform, dar **fara dovada ca ar cauza respingere**.
|
||
> - **Nu s-a putut proba pe date reale, si o spune explicit:** in baza accesibila sunt **3** facturi cu
|
||
> discount de document (toate cu o singura cota, anterioare eFacturii) si **34** cu cote mixte fara
|
||
> discount — **intersectia e goala**. Cele 4 XML-uri de productie cu alocare de document par a fi
|
||
> discounturi **pe linie** (unul are alocarea pe cota minima, altul are doua alocari — niciuna
|
||
> obtenabila din `Max()` pe o singura pseudo-linie). **Absenta din date nu e dovada.**
|
||
> - **Completare pentru #13, importanta la implementare:** daca se merge pe repartizare proportionala,
|
||
> bucatile de discount trebuie sa primeasca **`id_jtva_coloana` al grupului pe care il reduc**, nu
|
||
> doar cota — cheia de grupare are cinci campuri si `expltva` se completeaza tot prin
|
||
> `id_jtva_coloana`. O implementare care seteaza doar `proc_tva` **lasa grupul orfan exact unde e azi**.
|
||
>
|
||
> **Igiena confirmata de agent pe disc, nu din memorie:** `svn status` gol pe `xmlefactura.prg`,
|
||
> `ofacturare_comun.prg`, `oproceduri_facturare.prg` — doar citite; **zero write-back, deci niciun
|
||
> fisier text editat fara conversie in binar**; niciun proces `vfp9.exe` / `sqlplus.exe` / `java.exe`
|
||
> viu; nicio tranzactie deschisa (numai `SELECT` cu `exit`); **datele de test neconsumate** (scenariile
|
||
> au fost XML-uri sintetice in scratchpad); **niciun apel catre ANAF** — validare offline.
|
||
>
|
||
> **SINGURUL PUNCT RAMAS NEDOVEDIT PRIN RULARE, si dupa runda 16:** reproducerea **end-to-end prin
|
||
> program** a scenariului *factura scutita / taxare inversa + discount de document*. Tot ce sustine
|
||
> concluzia de acolo e analiza statica plus XML-uri sintetice plus masuratoarea `IIF`/NULL. Nu e
|
||
> blocant pentru nimic acum — **se dovedeste la implementare**, cand exista cod de testat. Artefactele
|
||
> sunt inca pe disc si sunt refolosibile: sondele si XML-urile de scenariu in scratchpad-ul sesiunii
|
||
> `d2dbc0e9-...`, cu apelul exact al validatorului in raport, §3.3 si §4.3.
|
||
>
|
||
> **Nu relansa cei doi agenti** — si-au terminat treaba, iar rapoartele lor sunt deja imbinate. Daca
|
||
> apare o intrebare noua pe discount, porneste un agent proaspat **pe raportul unic**, nu pe `_b.md`.
|
||
>
|
||
> **Cauza coliziunii, ca sa nu se repete:** `discount-tva-efactura` raportase `idleReason: interrupted`
|
||
> avand pe disc doar scheletul (624 octeti), a fost presupus mort si relansat — **era viu**. Vezi
|
||
> „Capcane de mediu".
|
||
|
||
> ### ATENTIE — copia de lucru are modificari necomise care NU sunt ale rundei 14
|
||
> **Actualizat in runda 17, masurat, nu copiat.** Ce e necomis **din partea lui #13**: exact trei
|
||
> fisiere, toate in `docs\` — `handoff_13_formular_unificat.md`, `mockup_13_formular_unificat.html`
|
||
> (v9) si `cercetare\mockup_v9_modificari.md` (netracked). Nimic altceva. Editarile rundei 17 in
|
||
> `plan_13` si `plan_index` **apar deja comise**, prinse in commit-ul de curatenie al sesiunii de la
|
||
> #6 — vezi „Capcane de mediu", prima intrare.
|
||
>
|
||
> Restul de mai jos e al lui **#6** si/sau zgomot de compilare VFP, si e **inca acolo** (verificat cu
|
||
> `svn status` in runda 17: `changelog_roafacturare.txt`, `roafacturare.PJX` / `.PJT`, `versiune_db.txt`,
|
||
> plus in `COMUN\`: `anaf_efactura`, `comun`, `ofacturare_comun`, `omodificari`, doua ferestre de import
|
||
> si `ofacturare_editare.prg`). Lista originala, pastrata ca atare:
|
||
> ```
|
||
> M changelog_roafacturare.txt · M roafacturare.PJX / .PJT · M versiune_db.txt
|
||
> M COMUN\clase\ofacturare_comun.vcx / .vct · M COMUN\clase\omodificari.vcx / .VCT
|
||
> M COMUN\clase\anaf_efactura · M COMUN\clase\comun · M COMUN\docs\...
|
||
> ? COMUN\clase\ofacturare_comun.pre_s4butoane.bak.vcx / .vct · ? bash.exe.stackdump
|
||
> ```
|
||
> Astea sunt **ale sesiunii de la #6** (editarea facturii emise) si/sau zgomot de compilare VFP.
|
||
> **Nu le comite, nu le reverta, nu le da `svn revert` in bloc si nu rula `git stash` in `COMUN\`**
|
||
> (`COMUN` e dublu-versionat SVN+git — un `stash` acolo pierde modificari necomise din SVN).
|
||
> `bash.exe.stackdump` din radacina, din `docs\` si din `docs\cercetare\` se pot sterge.
|
||
> **`{06D747B8-0824-488C-8832-DEB9AE661974}.png` din radacina NU e gunoi** — e captura Saga pusa de
|
||
> Marius ca referinta vizuala pentru asezarea formularului (runda 14), citata in plan la S1. Nu o sterge.
|
||
|
||
## Ce a livrat runda 14
|
||
|
||
| Livrabil | Ce a stabilit |
|
||
|---|---|
|
||
| `garda_aviz_facturat.md` | **premisa era pe dos** — garda blocheaza deja avizul facturat; golul e pe **proforma** |
|
||
| `s8_incarcare_document.md` | **S8 proiectat integral** — si ambele piese din schita planului sunt gresite |
|
||
| deciziile **51-54** in plan | `TIP = 4`, `do_modifica`, atasamentele, si **rasturnarea lui S10** |
|
||
| S7 rescris in plan | garda nu se reimplementeaza — se **muta momentul** (pre-flight read-only) |
|
||
| S10 rescris in plan | nu garda, ci **eliminarea** re-derivarii; cele 3 intrebari vechi cad |
|
||
| S9 / S11 corectate | pasul de atasamente devine **stergere**, nu `UPDATE` |
|
||
|
||
## Cele patru rezultate care conteaza (nu se reiau, nu se reargumenteaza)
|
||
|
||
### 1. Garda pe aviz EXISTA deja — premisa care circula in plan era gresita
|
||
Se credea ca `sterge_factura` blocheaza documentul doar cand are **retururi** peste el. **Nu:** a doua
|
||
garda testeaza `TIP IN (1, 2)`, iar **`TIP = 1` e corespondenta aviz → factura normala, nu retur**
|
||
(`EXPORT:5464-5476`; semantica citita ramura cu ramura din `CASE`-ul lui `finalizeaza_factura`,
|
||
`EXPORT:14818-14839`). Formularea gresita venea din citirea **comentariului**
|
||
`-- verific daca exista facturi sau avize de retur`, in care „de retur" se distribuia si peste
|
||
„facturi". Codul zice altceva. **Deci decizia 50 nu cere nicio garda noua pe aviz.**
|
||
|
||
**Sunt trei garzi, nu doua, si a treia schimba enuntul deciziei 50:**
|
||
|
||
| garda | `EXPORT` | ce blocheaza |
|
||
|---|---|---|
|
||
| 1 | 5452-5462 | **factura** cu facturi de retur peste ea (`TIP = 3`) |
|
||
| 2 | 5466-5476 | **aviz** cu 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 |
|
||
|
||
**„Factura din aviz ESTE editabila" nu e neconditionat** — e editabila doar cat timp niciunul dintre
|
||
avizele ei n-a primit aviz de retur.
|
||
|
||
**Ce lipseste nu e regula, e MOMENTUL:** garda traieste in `sterge_factura`, deci se manifesta ca
|
||
`ORA-20000` **in mijlocul** stergerii din regenerare, dupa completarea formularului si dupa deschiderea
|
||
tranzactiei. S7 are nevoie de **pre-flight read-only** pe exact aceeasi conditie, **fara** reimplementarea
|
||
regulii. Se interogheaza `VANZARI_CORESP`, **nu `VANZARI.FACTURAT`** — `FACTURAT` e derivat, scris si
|
||
resetat, dar **necitit de nicio garda**.
|
||
|
||
**GOLUL REAL E PE PROFORMA, si a devenit relevant chiar acum, prin decizia 51.**
|
||
`sterge_proforma` (`EXPORT:5610-5635`) **nu are nicio garda** — corpul ei e doua `UPDATE ... SET
|
||
STERS = 1`. E procedura **complet separata**, nu cheama `sterge_factura`, deci garda existenta **nu se
|
||
extinde automat** la `TIP = 4`. O proforma din care s-a emis factura se poate sterge azi fara niciun
|
||
avertisment (calea VFP iese devreme: `ofacturare_comun.vc2:4707-4719`). **Asta e continutul concret al
|
||
punctului 4 din S5c** — nu mai e intrebare de principiu, e garda de scris intr-o procedura fara niciuna.
|
||
|
||
**Comanda si contractul nu trec prin `VANZARI_CORESP`.** Comanda: `VANZARI.ID_COMANDA` +
|
||
`inchide_comanda`, garda e **in VFP si pe comanda** (`COMUN\clase\ocomenzi.vc2:1806-1807` la modificare,
|
||
`:2065-2066` la stergere). Contract: `VANZARI.ID_CTR` + `CTR_RATE_FACTURI`, nicio garda „are urmasi".
|
||
|
||
### 2. S8: ambele piese din schita planului sunt gresite, si nu marunt
|
||
1. **`completeaza_setari_document(toFactura, .T.)` copiaza 16 proprietati din ~120**
|
||
(`COMUN\programe\ofacturare_comun.prg:361-411`) si **niciuna de identitate**. Lipsesc serie, numar,
|
||
data, scadenta, `text_aditional`, `id_facturare`, `id_ruta`, `tip_saft`, `efactura`,
|
||
`listare_detaliata`, `dataora_exp`, discountul de document, `discount_evidentiat`, `eproforma`,
|
||
valuta, cursul.
|
||
2. **`cursor_retur_document(V_COPIERE = 1)` nu umple documentul, ci selectorul-sursa.** Rezultatul intra
|
||
in `crsarticole` (gridul din stanga); `crsfactura` se creeaza **gol si ramane gol** — comentariul din
|
||
cod e explicit (`COMUN\programe\ofacturare.prg:338`, `:455-457`). Transferul se face doar prin
|
||
`do_adauga_tot` → `do_adauga_articol`, care pentru articole gestionabile trece **prin dialogul de
|
||
alegere din stoc**.
|
||
3. **Nu intoarce `ID_VANZARE_DET` si nici `TAXCODE`** (`PACK_FACTURARE:3949-4054`). Fara
|
||
`ID_VANZARE_DET`, cheia de linie presupusa de S8b **nu exista**, iar `modifica_explicatie_articol`
|
||
**devine neapelabila** — primul ei parametru *este* `V_ID_VANZARE_DET` (`PACK_FACTURARE:14511-14519`).
|
||
|
||
**Recomandarea centrala:** S8 se construieste pe precedentul care face deja exact asta —
|
||
`relisteaza_ofacturare_stoc` (`COMUN\programe\ofacturare_stoc.prg:456-742`), care reconstituie `poDate` +
|
||
cursorul de linii dintr-un document salvat, prin `FACT_VFACTURI` + `FACT_VFACTURI_DETALII` (ambele au
|
||
`ID_VANZARE_DET` si `TAXCODE`).
|
||
|
||
**Cerinta din S8b e mai blanda decat se credea:** lookup-ul „ultimul delegat / ultima masina" **are deja
|
||
garda** — `Empty(id_delegat) And Empty(id_masina)` (`ferestre_cere_date.vc2:3111`). Riscul e real
|
||
**numai** pe documentele fara delegat si fara masina. Raportul da inventarul complet al celorlalte
|
||
initializari „pentru document nou" de sarit (§2.2), si **sapte corectii** la materialele existente
|
||
(§8.3) — printre care: nu exista coloana `ZI_CURS` pe `VANZARI`; etichetele lui `Ct_clb_altele` sunt
|
||
**sase**, nu cinci (lipsea „Nr. aviz / avize", tip 4 — exact cazul relevant pentru S9).
|
||
|
||
### 3. S10 nu se decide, se rastoarna — Marius a respins intrebarea
|
||
Cele trei intrebari deschise (blocare vs. avertizare; ramura de aviz; masurarea frecventei) **sunt
|
||
inchise prin respingerea premisei lor**. Formularea lui: *„nu inteleg de ce se schimba valorile fata de
|
||
ce se incarca din factura sursa care se modifica? asta este comportamentul pe care il doresc — modific
|
||
sursa"*. **La reemitere se scriu valorile din formular.** Nu se cere utilizatorului sa confirme o
|
||
schimbare pe care n-a cerut-o.
|
||
|
||
**VERIFICAT integral** — `s10_rederivare_pe_calea_reemiterii.md`, confirmat pe fisier **si** pe DB.
|
||
Rezultatul e in plan, la S10, cu tabelul complet. Ce conteaza:
|
||
|
||
- **Ramurile care re-deriva sunt TREI, nu una — raportul rundei 9 gresea.** Contract, **aviz** si
|
||
comenzi, toate in acelasi `CASE` din `adauga_articol_factura` (`PF:5052-5220`), **inainte** de
|
||
insertul in temp. Copierea temp → `VANZARI_DETALII` e 1:1, deci nu protejeaza nimic — dauna e amonte.
|
||
- **Ramura AVIZ e cea mai agresiva din tot `CASE`-ul:** `PRET` inlocuit **neconditionat**, fara `DECODE`,
|
||
fara filtru pe pretul din formular, **fara bloc `EXCEPTION`**, si **fara `A.STERS = 0`** desi coloana
|
||
exista. Ramura comenzi, in schimb, **cade cu `ORA-01403`** — vizibila, nu tacita.
|
||
- **Comportamentul cerut de decizia 54 exista deja in cod**, pe ramura de exceptie a contractului
|
||
(`PF:5167-5185`), care pune toate cele cinci pe valorile din formular. Nu e nimic de inventat.
|
||
- **Curat VFP nu se poate, si acum e dovada pozitiva, nu absenta:** semnatura n-are comutator
|
||
(`PF:4989-5015`), globalele n-au (`PF:126-212`), poarta se decide pe `ntip` (ajunge in `VANZARI.TIP`)
|
||
si pe `CONTRACTE.OPT_FACTURARE`. `V_ID_POL = NULL` **are exact acelasi defect ca `V_ID_CTR = NULL`**,
|
||
deja respinsa — notat in plan **tocmai ca sa nu fie redescoperit ca „solutie"**.
|
||
- **Modificarea de pachet e mica:** un `WHEN` nou, primul in `CASE`, cu **acelasi corp ca `ELSE`-ul de
|
||
azi**, comandat de o variabila noua de pachet („regenerare in curs", implicit `0`). **Acopera toate
|
||
trei ramurile dintr-o data.** Punctul de resetare exista deja (`initializeaza_date_factura`,
|
||
`PF:1808-1917`). Inert prin constructie. **DB inainte de EXE.**
|
||
|
||
**Trei consecinte de acceptat explicit, nu de descoperit la S12** (detaliate in plan): `IN_STOC` ar veni
|
||
din formular — si **S8 nu-l incarca azi** (`ofacturare_editare.prg:302-303` il ia din nomenclator), deci
|
||
flag-ul singur nu ajunge; se **pierde o validare** pe ramura comenzi; `PROC_TVAV` **ramane derivat** pe
|
||
toate ramurile (nu e parametru), deci o modificare legala de cota schimba TVA-ul la reemitere chiar si
|
||
pe `ELSE`.
|
||
|
||
**Capcana NULL, dedusa nu rulata:** `CTR_ARTICOLE.PRET_UNITAR` NULL (nu `0`) → `DECODE` da **NULL**,
|
||
pretul din formular se pierde complet. In dev nu apare (27 randuri, 0 NULL) — ceea ce nu spune nimic.
|
||
|
||
**Obstacol pentru S9, gasit in treacat:** **`VVANZARI_ARTICOLE` nu expune `ID_POL` si nici `ID_CTR`** —
|
||
exact cei doi ceruti de `adauga_articol_factura`. Reemiterea **nu poate folosi view-ul ca atare**. E un
|
||
argument in plus pentru varianta (B) de la intrebarea 1 din S8.
|
||
|
||
### 4. Doi agenti ucisi de limita de sesiune — si amandoi livrasera
|
||
`s8-incarcare` (52 KB, toate cele 8 puncte, cu propria concluzie de final) si `s10-rederivare` (**zero
|
||
octeti — nu apucase sa scrie nimic**). `garda-aviz` a trecut in `idle` fara mesaj final, desi livrase
|
||
integral 13 KB. **A cincea, a sasea si a saptea oara** cand se intampla. **Livrabilul se verifica pe
|
||
disc**, nu se reia munca reflex. Instructiunea „scrie devreme si incremental" e ce a salvat 52 KB.
|
||
|
||
## Ce asteapta raspunsul lui Marius
|
||
|
||
> ### CITESTE ASTA INAINTE DE LISTA DE MAI JOS
|
||
> **Marius a raspuns „DA LA TOATE" (decizia 56) — lista lunga care urmeaza NU mai e deschisa.**
|
||
> A acceptat in bloc toate recomandarile, cu doua exceptii pe care le-a scos el explicit. Lista e
|
||
> pastrata mai jos **doar ca inventar al recomandarilor acceptate**, ca sa se stie ce s-a decis si de
|
||
> ce; fiecare punct e scris si la locul lui, in povestea careia ii apartine. **Nu se reintreaba
|
||
> niciunul.** Textul deciziei 56, cu toate punctele: in plan, la deciziile rundei 14.
|
||
>
|
||
> **Runda 16 a raspuns la tot ce mai astepta pe Marius — inclusiv ultima alegere ramasa (48/49),
|
||
> cele doua puncte mici de la decizia 59, asezarea campului de motiv (decizia 64) si cele doua
|
||
> intrebari de la S14 (decizia 65). NU MAI RAMANE NICIO INTREBARE DESCHISA PENTRU MARIUS:**
|
||
> 1. **Tipurile 48/49** (facturi de marfa in custodie) — **INCHIS, decizia 60 (runda 16): DA, sunt
|
||
> editabile prin #13.** Formularea lui: *„vreau sa fie posibila editarea si a facturilor in
|
||
> custodie"*. **Verificarea care conditiona executia s-a facut, si blocantul CADE** — regenerarea
|
||
> e sigura pe 48/49, dar din alt motiv decat se banuia: **nu e nimic de reversat**, fiindca
|
||
> emiterea lor nu atinge deloc stocul (articole `IN_STOC = 0` prin constructie). Premisa despre
|
||
> `scrie_fact_aviz_custodie` **era gresita** — vezi „Capcane de mediu". Ramane o **cerinta** pentru
|
||
> S4/S4g/S5: restrictia `IN_STOC = 0` pe 48/49 se pastreaza, altfel invariantul se rupe.
|
||
> Raport: `docs\cercetare\custodie_48_49_stergere_reemitere.md`; enunt complet in plan, decizia 60.
|
||
> *Precizare pastrata din runda 14:* partea despre `frm_facturare_articole2` era o eroare de
|
||
> raport — nu e o varianta paralela de exclus, e **prototipul pe care se construieste formularul
|
||
> unificat** (S1).
|
||
> 2. **Cota si explicatia de TVA a discountului de document** — **INCHIS INTEGRAL.** Repartizarea:
|
||
> decizia 59, runda 16 (proportional pe cote). Campul text optional de motiv: **decizia 61, runda
|
||
> 16 — DA, se adauga.** Retroactivitatea la relistare/retrimitere: **decizia 62, runda 16 —
|
||
> restrictia de modificare e strict `EsteInEFactura`, fara legatura cu nicio data.** Ramane deschis
|
||
> doar cum se aseaza campul de motiv pe rand (vezi punctul 3) si un rest separat semnalat la
|
||
> decizia 62 (relistarea unei facturi vechi deja trimise). Vezi deciziile 61-62 in plan.
|
||
> 3. **Alegerea variantei de asezare** A / B / C — **INCHISA in runda 15**, varianta D, decizia 57.
|
||
> **Redeschisa partial de decizia 61, INCHISA la loc de decizia 64 (runda 16): randul de jos se
|
||
> imparte in trei** (incasare, alte date, motivul discountului), ~440 px fiecare la 1366 px, strans.
|
||
> D ramane intr-un etaj.
|
||
> 4. **Cerinta noua de audit** (decizia 63, runda 16) — **PROIECTATA, S14**. Cercetarea s-a terminat
|
||
> (`docs\cercetare\audit_vanzari_creare_modificare_stergere.md`); cele doua puncte ramase (antet
|
||
> vs. si linii; afisare in UI vs. doar interogare) **INCHISE de decizia 65 (runda 16)**: afisarea e
|
||
> in **gridul din `frm_facturi`**, deci pe **antet** — S14 nu mai cere controale noi in formularul
|
||
> unificat, cere coloane in acel grid, si incepe cu inventarul lui (posibil sa existe deja).
|
||
|
||
**Blocanta: NICIUNA.**
|
||
|
||
**Din S8 (opt puncte, toate cu recomandare — `s8_incarcare_document.md` §8.2):**
|
||
1. **Canalul de citire a liniilor:** (A) extinderea lui `cursor_retur_document`, (B) procedura noua
|
||
`cursor_editare_document`, (C) `FACT_VFACTURI_DETALII`. *Recomandare:* **(B)** — (A) schimba
|
||
comportamentul copierii (`taxcode` ar incepe sa se propage), (C) pierde `ID_POL`, `PRETD` si
|
||
tratamentul valutar.
|
||
2. **`GESTIONABIL` la editare: din nomenclatorul de azi sau din document?** *Recomandare:* **din
|
||
document** — un document editat trebuie sa arate cum a fost emis.
|
||
3. **`text_aditional`: se normalizeaza la incarcare (`Chr(170)` → `CR+LF`)?** *Recomandare:* **da**,
|
||
altfel orice document cu text pe mai multe randuri apare modificat la deschidere. Nota: cele doua
|
||
rute de scriere salveaza **forme diferite** ale campului — defect preexistent, de semnalat separat.
|
||
4. **`zi_curs` la editare: ascuns sau afisat gol?** *Recomandare:* **ascuns** (precedent: tipurile 8/9).
|
||
Mica abatere de la decizia 5, semnalata ca atare.
|
||
5. **`poDate.lEditare`: proprietate pe `oDateFactura` sau parametru?** *Recomandare:* **proprietate** —
|
||
sunt cel putin patru locuri care au nevoie de semnal, si `lCopiere` e deja acolo cu acelasi rol.
|
||
6. **`id_ruta` — proprietate noua pe `oDateFactura`?** *Recomandare:* **da**; fara ea S8c nu poate
|
||
implementa unul din cei 14 parametri.
|
||
7. **Tipurile 48/49 si `frm_facturare_articole2` intra in etapa II?** *Recomandare:* **nu acum**, dar se
|
||
declara explicit ca neacoperite.
|
||
8. **Defectul de prefixare `text_aditional` la `Init` pentru contracte** — se repara in #13 sau separat?
|
||
*Recomandare:* **se ocoleste** prin `lEditare` si **se semnaleaza separat**.
|
||
|
||
**Din S5c (patru puncte ramase — punctul 1, `TIP = 4`, e INCHIS prin decizia 51):**
|
||
9. **Apel pe starea de sesiune a pachetului vs. procedura noua cu parametri expliciti.** *Recomandare:*
|
||
varianta simpla (zero cod Oracle nou), **cu conditia** verificata la implementare ca niciun apel
|
||
Oracle intercalat nu reseteaza starea.
|
||
10. **Aceeasi proforma poate fi copiata de N ori.** *Recomandare:* daca deranjeaza — avertisment, **nu**
|
||
blocare.
|
||
11. **Garda simetrica la stergerea proformei** — **nu mai e intrebare de principiu**: `sterge_proforma`
|
||
n-are nicio garda, deci e **cod nou**. Vezi rezultatul 1.
|
||
12. **Afisarea „provine din proforma X"** — gratis din legatura scrisa, la nivel de document.
|
||
|
||
**Din S4g (patru puncte):**
|
||
13. **Numarul codului de eroare nou** (`FACT-0xx`), distinct de `FACT-024`.
|
||
14. **`CU_TVA = 1` hardcodat** — are efect **masurat** prin `nproc_tva_max`. **De confirmat.**
|
||
15. **Decizia 36** — numele cheii de optiune de firma pentru `SCD` (`FACT_SCD_ARTFPRET` propus).
|
||
16. **Trasabilitatea `CONT_VENIT` pe `VANZARI_DETALII`** — optionala pentru functionare.
|
||
|
||
**Deschise la sfarsitul rundei 14:**
|
||
17. ~~**Asezarea zonei de jos**~~ — **INCHIS. Marius a ales varianta D (decizia 57), runda 15.**
|
||
Enuntul complet, cele patru consecinte de executie si singurul punct lasat deschis sunt **in plan**,
|
||
la „Deciziile lui Marius, runda 15", si rezumate la S1. Pe scurt: banda de totaluri din C;
|
||
**incasarea si alte date sunt sectiuni colapsabile in formular, una langa alta pe acelasi rand**,
|
||
nu dialoguri; **nu exista bara de comenzi jos** — `but_renunt` / `but_termin` raman in banda de
|
||
titlu. **Nu se reintreaba, nu se reargumenteaza, A / B / C au cazut.**
|
||
Doua lucruri de dus mai departe la implementare, ambele deja scrise in plan: **validarea incasarii
|
||
se muta in `Termina`** (de prins in S9), si **„renunt doar la incasare" dispare** — acceptat
|
||
explicit de Marius dupa ce i s-a spus.
|
||
18. **Cota si explicatia de TVA a discountului de DOCUMENT** — **cercetarea E TERMINATA (runda 16)**,
|
||
raportul unic e `docs\cercetare\discount_document_cota_tva.md`, rezultatul e in plan la
|
||
**K-bis**. **INCHIS INTEGRAL, tot in runda 16:** repartizarea — **decizia 59**, proportional pe
|
||
cote, fara sa se ceara cota de la utilizator; campul text optional de motiv — **decizia 61**, da,
|
||
se adauga (`AllowanceChargeReason`, `ReasonCode` ramane `95`, stocare noua pe `VANZARI`, control
|
||
nou in formular); retroactivitatea la relistare/retrimitere — **decizia 62**, restrictia de
|
||
modificare e strict `EsteInEFactura`, fara legatura cu nicio data (ramane insa deschis, separat,
|
||
cazul relistarii unei facturi vechi deja trimise — vezi decizia 62 in plan). **Singurul rest
|
||
deschis: asezarea campului de motiv pe rand** (decizia 61 redeschide punctul de la decizia 57).
|
||
Ce s-a stabilit prin cercetare, integral valabil:
|
||
- **Cota discountului de document = cota MAXIMA de pe factura**, si e o regula implicita pe care
|
||
n-o alege nimeni. `Calculate Max(proc_tvav)` (`oproceduri_facturare.prg:1387`); discountul intra
|
||
ca **pseudo-linie** printr-un rand-sentinela `Replicate('Z',20)`
|
||
(`ofacturare_comun.prg:1891-1896`). In XML, `AllowanceChargeReason="Discount"` si
|
||
`ReasonCode=95` sunt **hardcodate** (`xmlefactura.prg:774-776`), la fel `currencyID="RON"`
|
||
(`:778`).
|
||
- **Regula e implementata de DOUA ori**: si in VFP (mai sus), si in PL/SQL —
|
||
`recalculeaza_totaluri_vanzari`, `MAX(ROUND(discount*(a1.proc_tvav-1),...)) as DISC_TVA_RON`
|
||
(`ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql:16081-16092`), scris in `VANZARI.DISCOUNT_TVA`
|
||
(`:16214-16227`). **Pentru #13 inseamna doua locuri de schimbat, nu unul.**
|
||
- **Ipoteza „TaxSubtotal cu baza negativa" — TRANSATA, cu verdict impartit.** Se temea ca
|
||
pseudo-linia, avand `id_jtva_coloana = 0`, iese din LEFT JOIN cu `coloana_jv` NULL si isi
|
||
formeaza grup propriu. **Infirmata pe factura obisnuita** — masurat, nu dedus: `IIF()` din VFP
|
||
intoarce **ramura falsa, nu `.NULL.`**, deci pseudo-linia se contopeste corect si sectiunile
|
||
3-4 ale raportului raman valabile. **Confirmata pe facturile scutite / taxare inversa /
|
||
intracomunitare**, unde liniile reale au `scutit = 1` si `expltva` completat iar pseudo-linia
|
||
are `0` si gol: iese un `TaxSubtotal` orfan cu baza negativa si categoria `Z`, iar
|
||
`agettipcota(1)` devine ambiguu intre `E` si `Z`.
|
||
- **Corectie la o presupunere care circula in handoff-ul precedent: ANAF NU respinge forma asta.**
|
||
Validat offline, 6 scenarii, cu control negativ care chiar iese cu erori. Aritmetica inchide
|
||
(`BR-S/E/Z-08` se satisfac trivial), deci **niciun schematron nu prinde greseala de modelare**.
|
||
Ramane eroare **tacuta**, ca si defectul de atribuire fiscala. Rezerva: validatorul local e din
|
||
2022, cel online al ANAF **nu a fost apelat**.
|
||
- **`currencyID="RON"` hardcodat e neconformitate reala si activa**, dar dovedit pe fisier ca
|
||
**a fost acceptat** de ANAF (identitate SHA256 cu XML-ul din `TRIMISE`). Neconform, fara dovada
|
||
ca ar cauza respingere.
|
||
- **Nu s-a putut proba pe date reale:** 3 facturi cu discount de document (toate cu o singura
|
||
cota) si 34 cu cote mixte fara discount — **intersectia e goala**. Absenta din date nu e dovada.
|
||
- **Completare importanta la implementare:** bucatile de discount trebuie sa primeasca
|
||
**`id_jtva_coloana` al grupului pe care il reduc**, nu doar cota — o implementare care seteaza
|
||
doar `proc_tva` **lasa grupul orfan exact unde e azi**. **eFactura nu cere nicio modificare** —
|
||
`xmlefactura.prg:758-792` grupeaza deja pe cota.
|
||
19. Cele **trei consecinte** ale deciziei 54 (`IN_STOC`, validarea pierduta pe comenzi, `PROC_TVAV`
|
||
derivat) — ultima poate cere decizie separata.
|
||
|
||
**Si defectul `lnTip` din `do_copiaza`** (runda 13) — de decis daca se repara in #6 (fisierul e al lui)
|
||
sau separat, dupa.
|
||
|
||
## Ce ramane de proiectat
|
||
|
||
**Nu mai e „nimic" — runda 16 a adaugat doua povesti noi, ambele cu cercetare in curs, nu inchise:**
|
||
**Actualizare runda 17: punctele 1 si 4 de mai jos sunt FACUTE. Lista e goala pe partea de proiectare
|
||
— raman doar 3 (testele si inchiderea), care cer cod.**
|
||
|
||
1. ~~**Golul `IN_STOC` din S8**~~ — **FACUT in runda 17**, in nota de executie a lui S8. A lasat in
|
||
urma o **alegere de proiectare** (de unde se reconstituie valoarea istorica), nu o sarcina.
|
||
2. **Canalul care scrie `serie_act` / `numar_act` / `data_act` / `data_scad` / `id_ruta` / `tip_saft` /
|
||
`efactura`** pe documentul reemis — **nu apar in `scrie_factura2`**. Se inchide in S9, la implementare.
|
||
3. `S6` / `S12` (teste pe flux real) si `S13` (diff, review, changelog) raman la final.
|
||
4. ~~**Mockup-ul e la v8**~~ — **FACUT in runda 17: e la v9.1**, cu varianta D, randul de jos in doua
|
||
si motivul discountului in banda de totaluri (deciziile 57 + 66), plus deciziile
|
||
52/53/54/59/60/61/62/63+65 in text. **Republicat** pe URL-ul existent (vezi punctul 5 din
|
||
„Urmatorul bloc de lucru") — decizia 33 e consumata, URL-ul e la zi.
|
||
5. **Verificarea custodiei (decizia 60, runda 16) — TERMINATA.** Verdict:
|
||
`scrie_fact_aviz_custodie` nu are legatura cu 48/49 (serveste `ntip = 4`); emiterea 48/49 nu
|
||
atinge stocul (`cursor_articole_k`, `IN_STOC = 0`); `sterge_factura` n-are ce reversa. **Blocantul
|
||
CADE — regenerarea e sigura pe 48/49.** Ramane o rezerva neverificata exhaustiv (invariantul
|
||
`IN_STOC = 0` pe 48/49) si o cerinta noua pentru S4/S4g/S5 sa nu-l rupa. Detaliu si citari: plan,
|
||
decizia 60; raport `docs\cercetare\custodie_48_49_stergere_reemitere.md`.
|
||
6. **Cerinta noua de audit (decizia 63, runda 16) — PROIECTATA, S14.** Cercetarea s-a terminat
|
||
(`docs\cercetare\audit_vanzari_creare_modificare_stergere.md`): patru din sase informatii exista
|
||
deja pe `VANZARI` (`ID_UTIL`/`DATAORA` creare, `ID_UTILS`/`DATAORAS` stergere, scrise consecvent);
|
||
lipseste complet perechea de modificare; regenerarea din S9 ar suprascrie tacit perechea de creare
|
||
daca nu se transporta explicit, la fel ca `ID_FACT`. S14 are verdictul complet, recomandarea
|
||
(pereche noua `ID_UTILM`/`DATAORAM`, transport la S9, migrare DB inainte de EXE). **Decizia 65
|
||
(runda 16) a inchis cele doua puncte ramase** (antet vs. si linii; afisare in UI sau doar
|
||
interogare): afisarea e in **gridul din `frm_facturi`**, deci pe **antet** — S14 incepe cu
|
||
inventarul acelui grid (posibil sa existe deja coloane de audit), inainte de a adauga ce lipseste.
|
||
|
||
**Nu mai intreba** — inchise in rundele 6-15: tot ce listeaza handoff-ul rundei 13, plus deciziile 51-54,
|
||
cele patru intrebari ale rundei 14 puse lui Marius direct, **si asezarea zonei de jos (decizia 57)**.
|
||
|
||
### Deciziile 51-54 (Marius, runda 14) — luate, nu de reluat
|
||
51. **`TIP = 4` in `VANZARI_CORESP` = „factura scrisa dintr-o proforma".** Confirmat explicit dupa ce i
|
||
s-a explicat ce inseamna `1/2/3`: `TIP` e **natura legaturii parinte-copil**, nu tipul documentului
|
||
(`1` = aviz → factura, `2` = aviz → aviz de retur, `3` = factura → factura de retur). `4` e in
|
||
aceeasi familie cu `1`. **Alocarea e ireversibila** odata cu primele date de productie — acceptat.
|
||
52. **`do_modifica` ramane activ pentru multi-selectie.** Formularul unificat preia cazul cu un singur
|
||
document. Consecinta: **S2 nu poate desfiinta nici aceasta ruta**, nu doar alegerea de la decizia 49.
|
||
53. **Atasamentul PDF se sterge la reemitere** — nici remigrare, nici marcaj „versiune inlocuita".
|
||
Pasul din S9 devine **stergere** (`STERS = 1`), nu `UPDATE`. **Consecinta i-a fost spusa explicit si
|
||
a acceptat-o:** urma PDF-ului efectiv trimis clientului dispare din sistem.
|
||
54. **La reemitere se scriu valorile din formular, nu se reciteste sursa.** Rastoarna S10 — vezi
|
||
rezultatul 3. Avertizarea + confirmarea sunt **respinse**.
|
||
55. **Metoda de executie e obligatorie, si e scrisa in plan** (sectiunea **„Metoda de executie"**,
|
||
imediat inainte de Etapa I). Trei cerinte: (a) la implementare planul **se sparge pe stories**,
|
||
fiecare story fiind o livrare de sine statatoare, cu nota de executie proprie scrisa **inainte** de
|
||
prima linie de cod; (b) **se testeaza la fiecare pas**, nu doar la S6 / S12 — headless pentru
|
||
logica, UI vizibil unde sunt griduri, cu rezultatul asteptat declarat **inainte** de rulare, si
|
||
testele se pastreaza pentru suita finala; (c) **fiecare story trece prin code review dupa
|
||
implementare si dupa teste, inainte de commit**, facut de **un agent care nu a scris codul**.
|
||
Ordinea fixa: implementare → teste → diff in `docs\` → review → aprobarea lui Marius → commit.
|
||
**S13 nu mai e momentul review-ului**, ci al inchiderii (review de ansamblu, suita completa,
|
||
changelog, documentatie).
|
||
|
||
### Deciziile 57-58 (Marius, runda 15) — luate, nu de reluat
|
||
57. **Asezarea zonei de jos = varianta D.** Banda de totaluri din C; **incasare si alte date ca
|
||
sectiuni colapsabile in formular, una langa alta pe acelasi rand**, nu dialoguri; **fara bara de
|
||
comenzi jos** — `but_renunt` / `but_termin` raman in banda de titlu. A / B / C cad. Enuntul
|
||
complet, cele patru consecinte si punctul lasat deschis: **in plan**, la deciziile rundei 15.
|
||
58. **Mockup-ul asezarii ramane doar online**, fara copie in `docs\`. Vezi „Urmatorul bloc de lucru",
|
||
punctul 3, pentru procedura de modificare.
|
||
|
||
### Decizia 59 (Marius, runda 16) — luata, nu de reluat
|
||
59. **Discountul de DOCUMENT se repartizeaza proportional pe cote**, nu pe cota maxima. Doua locuri
|
||
de schimbat impreuna (`ofacturare_comun.prg` si `recalculeaza_totaluri_vanzari`), plus
|
||
`id_jtva_coloana` pe fiecare bucata si diferenta de rotunjire pe ultima cota. Raman deschise
|
||
campul de motiv si retroactivitatea. Enuntul complet: **in plan**, la „Decizia 59".
|
||
|
||
### Deciziile 60-65 (Marius, runda 16) — luate, nu de reluat
|
||
60. **Tipurile 48/49 (custodie) SUNT editabile prin #13.** Inchide punctul (a) ramas deschis din
|
||
decizia 56. **Verificarea s-a facut: blocantul cade**, regenerarea e sigura pe 48/49 fiindca
|
||
emiterea lor nu atinge stocul (`cursor_articole_k` filtreaza `IN_STOC = 0`), deci n-are ce reversa.
|
||
Ramane **cerinta** ca S4/S4g/S5 sa pastreze acea restrictie. Enuntul complet, cu ramificatia pentru
|
||
`ct_clb_altele` in S8: **in plan**, la „Decizia 60".
|
||
61. **Discountul de document primeste un camp text optional de motiv** (`AllowanceChargeReason`,
|
||
`ReasonCode` ramane `95`) — cere stocare noua pe `VANZARI` si un control nou in formular.
|
||
**Redeschide intrebarea de asezare de la decizia 57**: randul se imparte in trei sau campul
|
||
coboara pe rand propriu — **inchisa la loc de decizia 64**. Enuntul complet: **in plan**, la
|
||
„Decizia 61".
|
||
62. **Restrictia de modificare e strict „nu a fost trimisa in eFactura"** (garda `EsteInEFactura`,
|
||
deja in S7) — **retroactivitatea nu mai e o intrebare**, nu se leaga de nicio data. Ramane
|
||
semnalat, nedecis, un rest separat: relistarea (nu editarea) unei facturi vechi deja trimise ar
|
||
produce N randuri de discount dupa decizia 59, deci hartie diferita de originalul trimis. Enuntul
|
||
complet: **in plan**, la „Decizia 62".
|
||
63. **Cerinta noua de audit**: data + utilizator pentru creare, modificare si stergere pe documente.
|
||
**Cercetare TERMINATA, proiectata ca S14.** Patru din sase informatii exista deja pe `VANZARI`
|
||
(creare, stergere); lipseste perechea de modificare; regenerarea (S9) ar rescrie tacut perechea
|
||
de creare fara un transport explicit, la fel cum era riscul pentru `ID_FACT` inainte de decizia
|
||
care l-a pastrat. Locul de afisare, ramas deschis aici, se inchide la decizia 65. Enuntul
|
||
complet: **in plan**, la „Decizia 63" si la S14.
|
||
64. ~~**Asezarea campului de motiv: randul se imparte in trei.**~~ **RASTURNATA DE DECIZIA 66
|
||
(runda 17). Nu mai e in vigoare** — se pastreaza doar ca istorie, ca sa se stie ca varianta „a
|
||
treia sectiune jos" a fost incercata si respinsa dupa ce Marius a vazut-o in mockup. Ce e in
|
||
vigoare: **motivul sta in banda de totaluri, langa discount; randul de jos are doua sectiuni.**
|
||
65. **Auditul (decizia 63) se afiseaza in gridul din `frm_facturi`, nu in formularul facturii.**
|
||
Confirma continutul de la decizia 63 (trei perechi data + utilizator: adaugat, modificat,
|
||
sters). Inchide ambele puncte ramase de la S14: e pe **antet** (gridul listeaza documente) si
|
||
**se afiseaza**, in acel grid — nu cere controale noi in formularul unificat. **Prim pas al
|
||
implementarii S14: inventarul gridului din `frm_facturi`**, posibil sa existe deja coloane de
|
||
audit. Enuntul complet: **in plan**, la „Decizia 65" si la S14.
|
||
|
||
### Decizia 66 (Marius, runda 17) — luata, nu de reluat. RASTOARNA DECIZIA 64.
|
||
|
||
66. **Motivul discountului sta LANGA DISCOUNT, in banda de totaluri** — *„motiv discount vreau sa fie
|
||
langa discount, nu a treia coloana"*. **Rastoarna decizia 64**: randul de jos ramane cu **doua**
|
||
sectiuni (incasare, alte date), fiecare pe jumatate de latime, adica exact decizia 57 punctul 2.
|
||
Proiectarea a adaugat o regula care nu i-a fost ceruta explicit si care se poate schimba dintr-o
|
||
linie: **campul e activ doar cand discountul de document nu e zero**. Consecinta de asezare,
|
||
acceptata: banda de totaluri devine plina si la latimi mici se rupe pe doua randuri. Enuntul
|
||
complet: **in plan**, la „Decizia 66".
|
||
|
||
## Interzis
|
||
|
||
- **Nu se atinge `COMUN\clase\ofacturare_comun.vc2` si nici `COMUN\programe\ofacturare_editare.prg`** —
|
||
perimetrul lui #6 cat timp #6 e in lucru. **Include si defectul `lnTip`.**
|
||
**`COMUN\programe\ofacturare.prg` NU e in acest perimetru.**
|
||
- **Nu se ruleaza `git_sync.ps1`** cat timp sesiunea de la #6 lucreaza.
|
||
- **Nu se propune „avertizare + confirmare" la S10** — respinsa de decizia 54.
|
||
- **Nu se foloseste `oscrie_in_fisiere` ca ruta de contare in #13** (decizia 35). Exceptie: piciorul de
|
||
**stergere** din S9.
|
||
- **Nu se proiecteaza retragerea fluxului lui #6** (decizia 38).
|
||
- **Reteta in 4 pasi din J-quater e ABANDONATA** (decizia 34).
|
||
- **Nu se proiecteaza pe numere masurate in Dev** (decizia 31).
|
||
- **Nu se reargumenteaza deciziile 22, 29, 39, 43, 49, 50, 57** — perimetrul lor e inchis.
|
||
- **Nu se mai propune dialog modal pentru incasare / alte date** si **nu se readuce bara de comenzi
|
||
jos** — respinse de decizia 57. Nici A / B / C nu se mai propun.
|
||
- **Nu se mai propune motivul discountului ca sectiune separata jos** — incercat in v9 si **respins de
|
||
decizia 66**. Sta in banda de totaluri, langa discount.
|
||
- Fara commit din proprie initiativa: diff-ul se livreaza intai ca fisier in `docs\`.
|
||
- **Nu se incepe implementarea pe cod** — #13 porneste dupa terminarea lui #6 (decizia 30).
|
||
|
||
## Capcane de mediu
|
||
|
||
- **NOU (runda 17), si e cea care conteaza pentru oricine lucreaza acum: SESIUNEA DE LA #6 COMITE IN
|
||
ACEEASI COPIE DE LUCRU, IN PARALEL, INCLUSIV IN `docs\`.** In timpul rundei 17 a dat commit-ul
|
||
`b5a7108` („cercetarile comune trec in COMUN, reziduul #6 dispare") — o curatenie care a **rescris 39
|
||
de fisiere din `docs\`**, a mutat 14 cercetari in `COMUN\docs\cercetare\` si a **sters 20 de rapoarte**.
|
||
Doua consecinte de stiut:
|
||
1. **A sters si doua fisiere ale lui #13**, incadrate gresit drept reziduu de #6:
|
||
`mockup_v7_modificari.md` si `mockup_v8_modificari.md`. **Nu sunt pierdute** —
|
||
`git show d9f5ca4:docs/cercetare/mockup_v8_modificari.md` le scoate. Nu s-au restaurat: erau
|
||
nereferite si stergerea a fost o curatenie aprobata a altei sesiuni; **daca le vrei inapoi, e o
|
||
comanda, dar se cere lui Marius intai**.
|
||
2. **Editarile rundei 17 in plan au fost prinse in acel commit**, nu de mine — `git status` arata
|
||
`plan_13` si `plan_index` **curate**, desi le-am scris eu. Nu e o dovada ca n-am scris nimic.
|
||
**Verifica pe continut (`grep`), nu pe `git status`.** Toate trei editarile au supravietuit,
|
||
confirmat.
|
||
**Regula practica:** cat timp #6 lucreaza, orice fisier din `docs\` poate fi rescris sau sters sub
|
||
tine intre doua apeluri. Editarile se **reverifica pe continut dupa** ce le-ai facut, iar fisierele
|
||
proprii nu se presupun stabile.
|
||
- **Ruda punctului de mai sus, platita tot in runda 17: un `grep` care nu gaseste nu dovedeste ca
|
||
lipseste.** Am „constatat" ca decizia 62 lipseste din mockup si eram gata s-o adaug — era acolo,
|
||
rupta pe doua randuri (`decizia\n62`), iar eu cautasem si forma feminina („trimisa"), nu pe cea din
|
||
text („trimis"). **Inainte sa declari ceva lipsa dintr-un fisier, cauta termenul cel mai scurt si
|
||
neflexionat**, si abia apoi forma completa.
|
||
- **NOU (runda 16): `PACK_CONTAFIN` are DOUA copii pe schema** — `owner = ACN` si
|
||
`owner = MARIUSM_AUTO`. O interogare pe `all_source` **fara filtru pe `owner`** intoarce cele doua
|
||
corpuri intercalate, adica **text corupt** care pare cod real. Filtreaza mereu pe owner, sau
|
||
citeste din exportul de pe disc (`D:\ROA\DATABASE\SCRIPTURI_CLAR\...`).
|
||
- **NOU (runda 16): `git_sync.ps1` a fost rulat din greseala de un subagent**, desi e interzis cat
|
||
timp sesiunea de la #6 lucreaza. **Paguba: zero** — verificat pe mtime, singurul fisier atins e
|
||
`COMUN\clase\ofacturare_comun.pre_s4butoane.bak.vc2`, text generat pentru un **binar de backup
|
||
netracked**; niciun `.vc2` / `.sc2` de lucru n-a fost rescris, niciun write-back, niciun commit.
|
||
**Lectia pentru briefing:** interdictiile trebuie puse **la inceputul** promptului, nu la mijloc —
|
||
agentul a inceput sa lucreze inainte sa le citeasca pe toate.
|
||
- **NOU, si e cea mai scumpa a rundei: o garda intreaga a fost inteleasa pe dos pentru ca s-a citit
|
||
COMENTARIUL, nu codul.** `-- verific daca exista facturi sau avize de retur` a fost citit ca „facturi
|
||
de retur sau avize de retur"; codul testa `TIP IN (1,2)`, adica si facturarea normala. Premisa a
|
||
circulat prin plan mai multe runde. **Comentariul nu e sursa de adevar; `IF`-ul e.**
|
||
- **Ruda buna a punctului de mai sus: numele unei proceduri nu e sursa de adevar.**
|
||
`scrie_fact_aviz_custodie` suna ca si cum ar servi facturile de custodie (48/49) — de fapt are un
|
||
singur apel in tot pachetul, pe ramura `ntip <> 4` (`PACK:7472`, `:7521`), deci serveste `ntip = 4`
|
||
(factura din avize). Premisa gresita a circulat pana in decizia 60. Se verifica **apelantul si
|
||
garda**, nu numele.
|
||
- **NOU: numerotarea difera intre exportul `PACK_FACTURARE` si corpul din `all_source`.**
|
||
`sterge_factura` incepe la `EXPORT:5432` si la `DB PACK_FACTURARE:4192`. **Nu exista offset
|
||
constant** — nici intre export si rapoarte, nici intre export si DB. Textul insa e identic.
|
||
- **Cifrele si multimile de valori se citesc din `Do Case`-ul real, nu din raportul precedent.** A doua
|
||
oara consecutiv cand asta salveaza ceva.
|
||
- **Un agent poate trece in `idle` fara mesaj final, desi a livrat integral** — si poate fi **ucis de
|
||
limita de sesiune** dupa ce a livrat. S-a intamplat de **opt** ori pana acum, ultima oara chiar la
|
||
`s10-rederivare-2`, care a raportat `idle` la o ora dupa ce terminase raportul. **Livrabilul se
|
||
verifica pe disc** (dimensiune, sectiuni, ultimele randuri, marcaje `(in lucru)` ramase), nu se reia
|
||
munca reflex.
|
||
- **NOU, si a costat o coliziune: `idleReason: interrupted` NU dovedeste ca agentul a murit.**
|
||
`discount-tva-efactura` a raportat `interrupted` (de doua ori) avand pe disc doar scheletul de 624
|
||
octeti. A fost presupus mort si relansat — **era viu**, si a ajuns la 13,5 KB. Al doilea agent era la
|
||
un pas de un `Write` peste raportul viu; a scapat doar pentru ca harness-ul a prins ca fisierul se
|
||
schimbase de la citire. **Inainte de relansare se compara mtime-ul livrabilului cu ora curenta**, nu
|
||
doar dimensiunea — un fisier atins acum cateva minute inseamna scriitor viu. **Daca s-a produs deja
|
||
coliziunea:** al doilea agent scrie in fisier separat (`<nume>_b.md`) si se imbina manual — nu `Edit`
|
||
tintit pe sectiunile ramase (primul le scrie oricum), si nu predare, care arunca firul deja inceput.
|
||
- **Cere din promptul initial: raport scris pe disc devreme si incremental.** In runda 14 asta a salvat
|
||
52 KB de la un agent ucis; celalalt, care n-apucase sa scrie, a pierdut tot.
|
||
- **Limita de sesiune poate ucide agentii instant, la pornire.** **Sonda ieftina**: relanseaza intai
|
||
agentul cel mai mic.
|
||
- **`vfp_symbols.ps1` se cheama din unealta PowerShell, nu din Bash** — caile cu `\` sunt mancate de
|
||
Bash. Indexeaza si `.bak`-urile; liniile se confirma pe fisierul real.
|
||
- **Pentru sqlplus foloseste unealta PowerShell**, nu Bash:
|
||
`& 'D:\ROA\instantclient_19_18\sqlplus.exe' -L -S 'MARIUSM_AUTO/ROMFASTSOFT@ROA_CENTRAL' '@C:\cale\x.sql'`
|
||
SQL-ul **in fisier ASCII**, cu `set linesize 32767` / `set pagesize 0` / `set feedback off` si `exit`.
|
||
- **`cd` intr-un apel de shell persista intre apeluri.** Verifica fisierele pe **cale absoluta**.
|
||
- **Grep de la radacina nu vede `COMUN\`** (gitignore); se da `path` explicit.
|
||
- **`grep -o -E '.{N}X.{N}'` rateaza tacut potrivirile de la capete de rand.** Intai termenul simplu.
|
||
- **`ID_UTILS` / `DATAORAS` pe `VANZARI_DETALII` nu inseamna „sters de/la".** Editarea de linie a lui
|
||
#6 le scrie si pe randuri **nesterse** — `ofacturare_editare.prg:501-505` (pe rand viu, `sters = 0`)
|
||
si `:522-525` (pe rand proaspat inserat). Un raport de audit trebuie sa puna si `STERS` in conditie,
|
||
altfel liniile doar atinse la editare apar gresit drept sterse.
|
||
- **Cautarea unui literal SQL trebuie sa tina cont de spatii** (`-10000` nu gaseste `rownum - 10000`).
|
||
- **Un singur scriitor pe fisier.** Integrarea in plan a facut-o sesiunea principala, secvential.
|
||
- **Verifica afirmatiile portante ale rapoartelor, nu le lua pe incredere.** Runda 14 a infirmat doua
|
||
premise portante din plan (garda pe aviz; ambele piese ale schitei S8) si a corectat sapte afirmatii
|
||
din materialele existente.
|
||
- **Export pachet:** `D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\08\ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql`
|
||
(17217 linii). Marcajul `versiune_db.txt` = `2026_08_09_02`, deci exportul e aplicat pe DB.
|
||
|
||
## Teste
|
||
|
||
**Caz adaugat de runda 16, si e cel mai important dintre toate:** **reemiterea unei facturi cu
|
||
articole gestionabile lasa stocul NESCHIMBAT.** E proba directa ca piciorul de stergere din S9 a
|
||
trecut chiar prin `oscrie_in_fisiere` — daca cineva „simplifica" tripleta la un apel direct de
|
||
`sterge_factura`, rulajele raman in picioare si gestiunea se descarca **de doua ori**, fara niciun
|
||
mesaj. Testul se face pe stocul agregat inainte / dupa, nu pe inspectia codului.
|
||
|
||
**Caz adaugat de runda 17, pereche cu cel de mai sus:** un document emis cu un articol caruia i s-a
|
||
schimbat intre timp `IN_STOC` in nomenclator, deschis in formular, **poarta valoarea de la emitere**,
|
||
nu pe cea de azi; iar reemiterea lui lasa **stocul agregat neschimbat**. Masurat inainte / dupa, nu
|
||
prin inspectia codului. E criteriul care demonstreaza ca golul `IN_STOC` din S8 chiar s-a inchis.
|
||
|
||
**Nu s-a rulat nimic.** Nu exista inca cod de testat (decizia 30). Testele minime raman in
|
||
`canal_cont_venit_fara_politica.md` §6, plus cazurile rundei 11 (aviz cu articol fara politica → `SCD`
|
||
ramane `461` / `418`; `ntip = 46` → `scrie_nota` nu se cheama), probele de paritate ale rundei 12
|
||
(acelasi rezultat de inchidere cu si fara linii libere; factura emisa dupa du-te-vino prin proforma
|
||
descarca stocul) si cele ale rundei 13 (factura din proforma descarca gestiunea si are rand `TIP = 4`,
|
||
iar proforma **nu** e marcata `FACTURAT`; linie cu `id_pol` si `cont_venit` simultan → eroare).
|
||
**Runda 14 adauga:** reemiterea unui document de contract **dupa** ce pretul din contract s-a schimbat
|
||
reproduce **pretul din formular**, nu pe cel din contract (decizia 54); si stergerea unei proforme din
|
||
care s-a emis factura **e refuzata** (garda noua, punctul 11).
|
||
**Runda 16 adauga (decizia 60, verificare terminata):** pe un document de tip 48/49 (custodie) **nu
|
||
se poate adauga un articol gestionabil** (`IN_STOC <> 0`), nici prin cautarea pe server in linie
|
||
(S4), nici prin „Alege din nomenclator…" (S4g) — criteriu de test, nu presupunere; raport
|
||
`docs\cercetare\custodie_48_49_stergere_reemitere.md`.
|
||
`s8_incarcare_document.md` §7 da criteriul „gata cand" al lui S8 in forma testabila, pe fiecare tip de
|
||
sursa.
|
||
|
||
## Urmatorul bloc de lucru
|
||
|
||
1. ~~Citeste cele doua rapoarte de discount si imbina-le~~ — **FACUT INTEGRAL in runda 16**, toti cei
|
||
cinci pasi (a)-(e): citite, cele trei afirmatii portante verificate la sursa, imbinate in raportul
|
||
unic, integrate in plan (**K-bis** + S1 + deciziile 56 si 57), si raspunsul dat lui Marius. **Nu se
|
||
reia nimic din el.** Ce a ramas in urma lui e o **decizie a lui Marius**, nu o sarcina de executie:
|
||
se implementeaza sau nu repartizarea proportionala pe cote, si vrea sau nu un camp de motiv.
|
||
*Cand vine vorba de asta, atentie la formulare:* concluzia s-a intors de doua ori pe drum — cota
|
||
maxima e regula reala, dar defectul e **tacut**, nu blocheaza factura, si nu s-a putut proba pe
|
||
date reale.
|
||
2. **NU mai cere raspunsuri pe lista de 19 puncte** — sunt inchise prin decizia 56 („da la toate").
|
||
Tipurile 48/49 s-au raspuns si ele — **decizia 60, runda 16: da, editabile**. Nimic de reintrebat
|
||
din lista veche.
|
||
3. ~~Confirmarea variantei D~~ — **DATA (decizia 57).** Cercetarea a confirmat ca discountul **NU
|
||
cere cota de la utilizator**, deci **a treia sectiune „grea" (cota + explicatie proprii) nu mai e
|
||
in discutie**. **Varianta minimala s-a materializat — decizia 61, runda 16: Marius vrea campul
|
||
text optional de motiv.** Intrebarea de asezare e deci **activa, nu mai e ipotetica**: campul fie
|
||
imparte randul in trei (~440 px fiecare la 1366 px, strans), fie coboara pe rand propriu si D
|
||
redevine doua etaje. **De decis de Marius**, nu la implementare. Pagina:
|
||
https://claude.ai/code/artifact/dfc70d38-856f-48fd-b6af-3da78e9da4f7
|
||
> **ATENTIE — mockup-ul asezarii NU MAI ARE COPIE PE DISC.** Cerinta lui Marius, runda 15: „doar
|
||
> online, ca sa nu mai intretii 2 variante". `docs\mockup_13_variante_asezare_jos.html` **a fost
|
||
> mutat afara din `docs\`**; **artifactul e singura sursa de adevar**. Ca sa-l modifici:
|
||
> **intai `WebFetch` pe URL** ca sa recuperezi HTML-ul, scrie-l intr-un fisier de lucru **in
|
||
> scratchpad, nu in `docs\`**, editeaza, apoi `Artifact` cu **`url` = link-ul de mai sus** (fara
|
||
> `url` se creeaza link nou). `WebFetch` cere si el o citire prealabila daca artifactul a fost
|
||
> publicat din alta conversatie — asa a fost si in runda 15, si a mers.
|
||
> **`docs\mockup_13_formular_unificat.html` (v8) nu e atins de regula asta** — Marius a cerut-o
|
||
> numai pentru mockup-ul asezarii.
|
||
4. ~~**Golul de la `IN_STOC` in S8**~~ — **FACUT in runda 17.** E in plan, in nota de executie a lui S8
|
||
(caseta „CERINTA DE EXECUTIE ADAUGATA IN RUNDA 17"), cu criteriul de test in „gata cand" si cu
|
||
consecinta 1 de la S10 marcata **PRELUAT**. **Nu se reia.** Ce a ramas in urma lui **nu e o sarcina
|
||
de executie, e o alegere de facut la proiectarea lui S8**: valoarea istorica a lui `IN_STOC` nu e
|
||
stocata nicaieri, deci trebuie ales **de unde se reconstituie** (una din cele trei variante scrise
|
||
in plan). Nu se presupune niciuna.
|
||
5. ~~**Mockup v9**~~ — **FACUT in runda 17.** `docs\mockup_13_formular_unificat.html` e la **v9.1**, cu
|
||
varianta D, randul de jos in **doua** sectiuni si motivul discountului in banda de totaluri
|
||
(decizia 66, care rastoarna decizia 64); raport de modificari:
|
||
`docs\cercetare\mockup_v9_modificari.md`. **Republicat**, la cererea lui Marius, pe URL-ul existent:
|
||
**https://claude.ai/code/artifact/e9d73e86-7518-4f50-a998-43c49e083142** (notat de acum si in plan,
|
||
la S1). Ca sa-l modifici: `WebFetch` pe URL intai — fara asta publicarea e refuzata — apoi `Artifact`
|
||
cu `url` = link-ul de mai sus.
|
||
6. Dupa aceea **nu mai e proiectare de facut**: #13 asteapta terminarea lui #6 (decizia 30). Prima
|
||
sarcina la pornirea implementarii e **spargerea planului pe stories** si scrierea notei de executie
|
||
pentru prima dintre ele (decizia 55).
|
||
|
||
**FACUT in runda 14, nu se reia:** integrarea in plan a rezultatelor 1-3 (decizia 50 rescrisa cu cele
|
||
trei garzi; S7 rescris cu pre-flight; S8 cu blocul de avertizare peste schita gresita; S10 rescris
|
||
integral; S9 si S11 corectate pentru atasamente; deciziile 51-55 adaugate), **plus sectiunea „Metoda de
|
||
executie"** (spargerea pe stories, testele la fiecare pas, code review per story inainte de commit) si
|
||
rescrierea lui S13 ca inchidere, nu ca moment al review-ului. **Plus, tot in runda 14:** corectia S8
|
||
(`frm_facturare_articole2` e **prototipul**, nu o varianta de exclus — S1); inchiderea punctului
|
||
`REST_NOTE_PLATA` / `IPS_VOYAGES_VANZARI` prin raspunsul lui Marius, cu cerinta ca **S7 sa le refuze
|
||
explicit**; si cele trei variante de asezare a zonei de jos.
|
||
|
||
**Nu se incepe implementarea pe cod** (decizia 30).
|