sync SVN r18143
This commit is contained in:
@@ -1,798 +0,0 @@
|
||||
# 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).
|
||||
@@ -1,73 +0,0 @@
|
||||
# Handoff — stergerea lui progres.md (ultimul pas al curateniei)
|
||||
|
||||
Scris 20.08.2026, dupa r18027. Sesiunea principala a trecut de pragul de context (254k).
|
||||
**Numai stare, fara analize noi.**
|
||||
|
||||
## Nimic nu e intr-o stare periculoasa
|
||||
|
||||
- **Totul e comis si pushed.** SVN `r18026` (lucrarea) si `r18027` (curatenia). Git: proiect
|
||||
`3ddcbc0`, COMUN `58d4c4a`, ambele la zi cu origin. `git status` curat in ambele repo-uri.
|
||||
- Niciun fisier editat fara write-back. `vfp9.exe` nu ruleaza. Nicio tranzactie deschisa.
|
||||
- `roafacturare.PJT`/`.PJX`/`.exe` raman modificate din sesiunea de VFP a lui Marius: **nu se comit**.
|
||||
|
||||
## Ce a cerut Marius, si unde s-a oprit
|
||||
|
||||
> "cred ca poti sa stergi si progres.md daca nu mai indica catre modificari active"
|
||||
|
||||
**Premisa e corecta**, verificat: `progres.md` nu mai descrie lucrari active. #6, #7 si #8 sunt
|
||||
inchise; starea lui #13 sta in `handoff_13_formular_unificat.md`, care **nu** il refera
|
||||
(0 trimiteri; la fel `plan_13` si `plan_10`).
|
||||
|
||||
**Ce lipseste ca sa se poata sterge** — sase trimiteri vii de rescris:
|
||||
|
||||
| fisier | trimiteri | ce spune |
|
||||
|---|---|---|
|
||||
| `docs\plan_index.md` | **3** | "Planul a fost sters la curatenie; istoricul e in `progres.md`" — randurile #8, #6, #7 |
|
||||
| `docs\plan_11_integrare_politici_preturi.md` | 1 | |
|
||||
| `docs\plan_12_nomenclator_ca_lista_preturi.md` | 1 | |
|
||||
| **`COMUN\docs\reguli_lucru.md`** | 1 | **cross-proiect** — fisier partajat de toata suita ROA |
|
||||
|
||||
Ultima e motivul pentru care lucrarea nu e banala: `COMUN` e dublu-versionat (SVN + git propriu,
|
||||
`gitea.romfast.ro:romfast/comun.git`) si orice modificare acolo atinge toate produsele ROA.
|
||||
|
||||
## Ce are de facut sesiunea urmatoare
|
||||
|
||||
1. Decide cu Marius **unde se muta rolul de arhiva**: fie se renunta la promisiune (istoricul
|
||||
ramane doar in git, `3ddcbc0` si mai vechi), fie trimiterile arata catre revizia SVN/commit-ul
|
||||
git in loc de fisier.
|
||||
2. Rescrie cele 6 trimiteri de mai sus in acord cu decizia.
|
||||
3. Sterge `docs\progres.md` (e sub SVN — `svn delete`, nu doar `rm`).
|
||||
4. Commit in **doua repo-uri**: SVN pe `docs\` + `COMUN\docs\reguli_lucru.md`, apoi `roa_sync.bat`.
|
||||
Verifica separat repo-ul git al lui `COMUN`.
|
||||
5. Sterge si acest handoff, odata ce pasul e incheiat.
|
||||
|
||||
## Starea curenta a documentatiei
|
||||
|
||||
`docs\` are **10 fisiere** + `docs\cercetare\` cu **63**:
|
||||
|
||||
- planurile deschise/amanate: `plan_13` (**urmatorul la rand**, locul 1 in index), `plan_12`,
|
||||
`plan_11`, `plan_10`, `plan_index.md`;
|
||||
- materialul lui #13: `handoff_13_formular_unificat.md`, `mockup_13_formular_unificat.html`,
|
||||
`S1_inventar_campuri_formular_unificat.md`;
|
||||
- `conventii_mediu_oracle.md` (netrackat in SVN, doar git);
|
||||
- `progres.md` — subiectul acestui handoff.
|
||||
|
||||
**Capcana de nume, deja platita**: `cercetare\s8_incarcare_document.md`, `s8b_rutarea_scrierii.md`
|
||||
si `audit_vanzari_creare_modificare_stergere.md` NU tin de planul #8 — sunt story-uri ale lui
|
||||
**#13**. Criteriul de stergere in `cercetare\` a fost referinta, nu numele: **#13 se sprijina pe
|
||||
folder cu 86 de trimiteri**, deci nu se poate sterge in bloc.
|
||||
|
||||
## Reziduu acceptat, nu defect
|
||||
|
||||
`progres.md` pastreaza 39 de trimiteri catre fisiere sterse, plus 5 mentiuni in proza in
|
||||
`plan_13`, `cercetare\handoff_s4_runda1.md`, `cercetare\rec_s4_runda1.md` si
|
||||
`cercetare\rec_cale_vanzari_detalii.md`. Sunt istorice, se rezolva din git — aceeasi situatie ca la
|
||||
curatenia planului #8. Daca `progres.md` dispare, dispar si cele 39.
|
||||
|
||||
## Defect deschis, raportat si nereparat (decizia lui Marius)
|
||||
|
||||
Sincronizarea articole-rulaje nu recalculeaza `valoarev`/`valtvav` pe randul `trul`; ele ajung
|
||||
invechite in Oracle (`RUL`). `VALOAREVCTVA` nu e coloana in `RUL` — ramane invechit doar pe ecran,
|
||||
pana la reincarcarea notei. Back-fill-ul de la reincarcare are garda `WHERE EMPTY(NVL(...,0))`,
|
||||
deci prinde doar zerourile. Lantul complet, cu `fisier:linie`, era in `docs\raport_r7_sincronizare.md`,
|
||||
sters la curatenie — se recupereaza din git (`5b52cb3`), iar rezumatul a ramas in `progres.md`.
|
||||
@@ -1,94 +0,0 @@
|
||||
# Handoff: skill-uri de agent ROA + backstop de rutare
|
||||
|
||||
Data: 2026-09-16. Sesiune oprita la limita de context. Acesta e fisier de stare, nu documentatie.
|
||||
|
||||
## Ce s-a livrat (in COMUN, versionat git + SVN)
|
||||
|
||||
- 9 skill-uri, cate un `SKILL.md` per folder (`COMUN\skills\<nume>\`), frontmatter doar
|
||||
`name`+`description`, corp auto-suficient (skill = proprietarul procedurii):
|
||||
`roa-vfp-text-edit`, `roa-vfp-headless-test`, `roa-git-svn-commit`, `roa-oracle-migration`,
|
||||
`roa-oracle-diagnostic`, `roa-oracle-production-access`, `roa-vfp-null-guards`,
|
||||
`roa-vfp-go-recno`, `roa-oracle-sqlexec-no-data`.
|
||||
- `COMUN\utile\leaga_skills.ps1` - creeaza symlink-uri in `%USERPROFILE%\.claude\skills\` catre
|
||||
`COMUN\skills\<nume>` (fara copiere; citit de Claude Code SI de opencode). Idempotent, `-DryRun`.
|
||||
- `COMUN\utile\backstop_skills.txt` (sursa canonica a rutarii) +
|
||||
`COMUN\utile\scrie_backstop_skills.ps1` (`-Root`, `-Proiecte`, `-DryRun`; scrie `AGENTS.md` +
|
||||
bloc marcat in `CLAUDE.md`; garda anti-duplicare: sare fisierele care contin deja `roa-` fara markers).
|
||||
- `COMUN\docs\reguli_lucru.md` pct. 7 + `COMUN\docs\README.md` - ruteaza fiecare zona la skill-ul
|
||||
care o detine (nu la doc).
|
||||
- `COMUN\docs\cercetare\rec_skills.md` - decizia, inventarul, cum se adauga un skill nou.
|
||||
- `AGENTS.md` (radoacina ROAFACTURARE, backstop pentru opencode) + `CLAUDE.md` (2 rute + ancora).
|
||||
- Backstop aplicat pe 10 proiecte: ROAACNPRO, ROAAUTO, ROACONT, ROACONTRACTE, ROADEF,
|
||||
ROAFACTURARE, ROAGEST, ROAIMOB, ROAPRETURI, ROAREGISTRATURA (verificat idempotent).
|
||||
|
||||
## Ce NU e terminat (de continuat)
|
||||
|
||||
1. **2 fisiere de onboarding modificate, NEcomise in SVN** (singura stare nefinalizata de cod):
|
||||
- `COMUN\docs\onboarding\inrolare-calculator-nou.md` - secțiune noua "Pasul 8 - skill-uri de
|
||||
agent ROA" (+22 linii; pastreaza diacriticele).
|
||||
- `COMUN\docs\onboarding\inrolare-proiect-git-text.md` - secțiune noua "### 8. Skill-uri de
|
||||
agent (backstop de rutare)" (+7 linii; ASCII).
|
||||
- Ambele: LF, fara BOM. NU au fost testate mai departe (sunt doar text).
|
||||
2. **8 proiecte au commit SVN dar mirror-ul git nu a rulat `roa_sync`** (ROAACNPRO, ROAAUTO,
|
||||
ROACONT, ROACONTRACTE, ROADEF, ROAGEST, ROAIMOB, ROAPRETURI, ROAREGISTRATURA). Fisierele sunt
|
||||
active pe disc; git-ul lor se aliniaza la urmatorul `roa_sync.bat` local.
|
||||
3. **Optional nefacut**: skill `roa-onboarding` (Nivel D din plan). Nu s-a creat intentionat:
|
||||
`vfp-ui-test` NU se creeaza (e acoperit de `roa-vfp-headless-test`).
|
||||
|
||||
## Stare depozite
|
||||
|
||||
- SVN: COMUN r18116; ROAFACTURARE r18118; proiecte r18114/18115/18117/18119/18120/18121/18122/
|
||||
18123/18124.
|
||||
- git: COMUN `4756dc0`, ROAFACTURARE `50274b8`, ambele `ahead=0` (push facut, `main`).
|
||||
- `svn status COMUN` = 2 x M (cele doua onboarding-uri de mai sus).
|
||||
- `svn status ROAFACTURARE` (in afara COMUN) = reziduri PRE-EXISTENTE, neale noastre:
|
||||
`.claude` (?), `Clase\ofundal_facturare.vc2.pre_runda1.bak` (?),
|
||||
`Utile\Teste\test_catalog_articole_s1.FXP` (?), `docs\diff_runda3_vanzare_ui.patch` (?).
|
||||
- Branch `claude/skills-agenti`: sters in ambele repo-uri.
|
||||
|
||||
## Comenzi de rulare (exacte)
|
||||
|
||||
- Backstop, pe proiecte: `powershell -ExecutionPolicy Bypass -File D:\ROA\<PROJ>\COMUN\utile\scrie_backstop_skills.ps1 -Root D:\ROA -Proiecte ROAACNPRO,ROAAUTO,ROACONT,ROACONTRACTE,ROADEF,ROAFACTURARE,ROAGEST,ROAIMOB,ROAPRETURI,ROAREGISTRATURA`
|
||||
(intai `-DryRun`). Fara `-Proiecte` = toate proiectele detectate (53 - NU rula asa fara acord).
|
||||
- Legare pe masina: `powershell -ExecutionPolicy Bypass -File <PROJ>\COMUN\utile\leaga_skills.ps1 [-DryRun]`.
|
||||
- Sync: `D:\ROA\ROAFACTURARE\roa_sync.bat` (svn update -> git_sync -> commit "sync SVN rN" ->
|
||||
reconciliere; push DOAR daca tot ahead-ul e commit-uri de sync).
|
||||
- Verificare ASCII: `([IO.File]::ReadAllBytes($p) | Where-Object {$_ -gt 127}).Count` -> 0.
|
||||
|
||||
## Decizii luate (nu re-investiga)
|
||||
|
||||
- Skill = proprietarul procedurii; docurile din `COMUN\docs` = referinta CONDITIONATA (cel mult 1
|
||||
pointer per skill). Motiv: sa nu se incarce contextul de doua ori.
|
||||
- Un singur loc de rutare per host: `AGENTS.md` (opencode) + `reguli_lucru.md` pct. 7 (Claude,
|
||||
citit mereu) + ancora in `CLAUDE.md`.
|
||||
- Skill-urile traiesc in `COMUN\skills`, expuse prin symlink in `~/.claude/skills` (fara copie).
|
||||
opencode citeste nativ `.claude/skills` (confirmat in sursa: `SkillV2.load` -> `glob(...,{symlink:true})`).
|
||||
- Sursa canonica a rutarii = `COMUN\utile\backstop_skills.txt` (regenerata in proiecte de script).
|
||||
- NU se foloseste plugin marketplace: opencode nu citeste cache-ul de pluginuri.
|
||||
- Declansare: automata din `description` in ambele host-uri; backstop-ul always-on prinde
|
||||
cazurile in care descrierea nu se potriveste. `paths` NU se foloseste (doar restrange, nu forteaza).
|
||||
|
||||
## Interzis
|
||||
|
||||
- Nu copia manual fisiere de skill in `~/.claude/skills` (se pierde legatura cu sursa; doar `leaga_skills.ps1`).
|
||||
- Nu `git commit`/`push`/`merge` pe `main` in COMUN in afara fluxului; commit-urile de lucru pe branch
|
||||
`claude/<subiect>`, apoi `svn commit` + `roa_sync`.
|
||||
- Nu rula `roa_sync` pe un branch cu fisiere noi inainte de `svn commit` (pe branch face
|
||||
`checkout main` si scoate fisierele de pe disc).
|
||||
- Nu rescrie `COMUN\docs\` din proprie initiativa (regula 11/12) - propune.
|
||||
- Nu rula `scrie_backstop_skills.ps1` fara `-Proiecte` (atinge 53 de proiecte).
|
||||
|
||||
## Capcane platite
|
||||
|
||||
- PowerShell 5.1 `New-Item -ItemType SymbolicLink` cere privilegii; `mklink /D` merge cu Developer
|
||||
Mode activ (scriptul are fallback).
|
||||
- `COMUN\docs` sunt LF, nu CRLF; fisierele noi create (AGENTS.md, skill-uri) sunt CRLF.
|
||||
- `reguli_lucru.md` si `CLAUDE.md` au em-dash (non-ASCII) PRE-EXISTENTE - nu se "repara" din oficiu.
|
||||
- `inrolare-proiect-git-text.md` are 5 en-dash pre-existente (15 octeti non-ASCII); adaugarea
|
||||
noastra e ASCII pur.
|
||||
|
||||
## Urmatorul pas recomandat
|
||||
|
||||
1. `svn commit` pentru cele doua onboarding-uri + `roa_sync.bat` + `push`.
|
||||
2. `roa_sync.bat` in cele 8 proiecte ramase (apoi push, la alegere).
|
||||
3. (Optional) skill `roa-onboarding`.
|
||||
@@ -1,146 +0,0 @@
|
||||
*!* 03.09.2026
|
||||
*!* agent documentatie (orchestrat de team-lead, sesiune plan13-s2)
|
||||
*!* Coloana "Stare" era stale din 27.08.2026 (marca NEINCEPUT povesti de mult inchise si probate).
|
||||
*!* Adusa la zi pe baza `docs\handoff_plan13_executie_continua.md` (fisierul de stare viu — ramane
|
||||
*!* sursa de adevar, se citeste ACOLO intai). Rezolvata si capcana de numerotare de mai jos, prin
|
||||
*!* sectiunea separata "Firul geometrie (designer editabil)".
|
||||
|
||||
# Plan #13 - executie pe stories
|
||||
|
||||
Tabel de urmarire pentru executia planului `docs\plan_13_unificare_formular_facturare.md`,
|
||||
conform metodei de executie (liniile 1954-2015 din plan, decizia 55). Nu e reproiectare - fiecare
|
||||
story are proiectarea proprie in plan si/sau in `docs\cercetare\`. Actualizat dupa fiecare story
|
||||
inchisa. **Sursa de adevar pentru stare e `docs\handoff_plan13_executie_continua.md`** - acest
|
||||
tabel e o rasfrangere a lui, tinuta pentru titluri scurte, fisiere atinse si dependente.
|
||||
|
||||
**Capcana de numerotare — REZOLVATA (03.09.2026).** Numele `S6`/`S7`/`S8`/`S8b`/`S8c` din acest
|
||||
tabel se refera strict la povestile din acest plan ("Test pe flux real", "Actiunea si garzile",
|
||||
"Incarcarea documentului in formular" etc.). Un lant separat, comis tot pe `plan13-s2`, a folosit
|
||||
ACELEASI nume pentru firul "designer editabil" (cererea separata a lui Marius,
|
||||
`docs\sinteza_designer_editabil.md`). Cele doua nu au nicio legatura. Firul de geometrie are acum
|
||||
randuri proprii, cu prefixul `S8-geometrie-*`, in sectiunea **„Firul geometrie (designer
|
||||
editabil)"** de sub tabelul principal — nu se mai confunda cu povestile de aici.
|
||||
|
||||
## Vocabular de stare
|
||||
|
||||
- **INCHISA SI PROBATA** — cod comis + proba automata verde.
|
||||
- **INCHISA FARA COD** — inchisa prin decizia lui Marius, fara implementare (cu decizia citata).
|
||||
- **LIVRATA, PROBA MANUALA DATORIE** — codul e comis si probat automat, dar criteriul oficial
|
||||
„gata" e o proba manuala UI pe care Marius n-o poate face acum (mandatul din §1 al handoff-ului).
|
||||
- **PARTIALA** — ce s-a livrat si ce a ramas, explicit.
|
||||
- **NEINCEPUT** — chiar neinceput.
|
||||
|
||||
## Tabel stories
|
||||
|
||||
| Story | Nume scurt | Fisiere atinse (din plan) | Depinde de | Stare | Nota de executie |
|
||||
|---|---|---|---|---|---|
|
||||
| S1 | Inventar campuri + alegerea bazei | (inventar, fara cod) | - | **INCHISA FARA COD** — aprobata de Marius, 09.08.2026 | `docs\S1_inventar_campuri_formular_unificat.md` |
|
||||
| S2 | O singura procedura `factureaza` | `COMUN\programe\ofacturare.prg`, `Clase\ofundal_facturare.vc2` (decizia 67 + completare + corectie review) | S1 | **LIVRATA, PROBA MANUALA DATORIE** — comisa pe `plan13-s2`, 21.08.2026; netestata manual la momentul comiterii (decizia lui Marius). De atunci exercitata cu succes indirect, prin documente reale emise care trec prin `factureaza`, la S6 (`docs\raport_s6_flux_real.md`) si S9 (`docs\raport_s9_7_oracle.md`, `docs\raport_s9_7_vfp_proba.md`) — proba manuala UI dedicata ramane datorie deschisa | `docs\nota_executie_s2.md`, `docs\raport_s2_implementare.md`, `docs\cercetare\s2_factureaza_unificare.md`, `docs\review_s2.md`, `docs\handoff_13_s2.md` |
|
||||
| S3 | Portare logica antet in formularul unificat (spart in S3-1..S3-4, decizia 68) | `ofacturare.vc2`, `ofacturare_antet.prg` (nou, S3-2), `ofacturare.prg` (S3-4) | S2 | **LIVRATA, PROBA MANUALA DATORIE** — S3-1..S3-4d COMISE pe `plan13-s2` (COMUN `89dd30a`, `27bdf58`, `c269fdf`, `4f6af10`, `359f478`, `02df236`, `e538590`, `409ce90`, `e96fd3e`); Q8 (numarul ars) COMISA, doar pe calea unificata. Implementarea e completa; proba manuala pe tip 1 a fost refuzata de Marius (22.08.2026), iar `factureaza` nu e apelabila headless | `docs\nota_executie_s3.md`, rapoartele si review-urile S3-1/S3-2/S3-3, `docs\raport_b1_rerulare_s3_3.md`, `docs\raport_q8_numar_ars.md`, `docs\review_q8_numar_ars.md`, `docs\raport_adaptare_paritate_q8.md`, `docs\handoff_13_s3.md` |
|
||||
| S3b | Sectiune pliata: alte date + analitice | `caut_ora.vc2`, `ferestre_cere_date.vc2`, `ofacturare.vc2`, `omodificari.vc2` | S3 | **PARTIALA** — implementata aproape integral, comisa pe `plan13-s2`. Criteriul „gata" din 5 puncte (`docs\cercetare\s3b_alte_date_analitice.md` §10): **(1) paritate emitere pe 4 tipuri de incasare — TRECUT**, `test_s3b_emitere_paritate_2.prg` PASS 20/0 (`docs\raport_s3b_criteriu1_pasat.md`); **(2) non-alocare la toggle de pliere — TRECUT**, `test_s3b_incasare_nealocare.prg` PASS 14/0 (`docs\handoff_13_s3b_asezare.md`); **(3) blocarea grupului de incasare pe document emis — CADUC pentru S3b, amanat la S8c** (decizia 25); **(4) analitice read-only — CADUC, rasturnat de decizia 72** (raman editabile); **(5) paritate delegat/transport/adresa/text — FACUT**, cu o inconsecventa vizuala minora ramasa (`Ct_clb_delegat`/`Ct_clb_masina` editabile pe proforma, unde calea veche le scotea) [^1] | `docs\handoff_13_s3b_varianta_b.md`, `docs\raport_s3b_varianta_b.md`, `docs\handoff_13_s3b_reasezare_grila.md`, `docs\handoff_13_s3b_asezare.md`, `docs\cercetare\s3b_alte_date_analitice.md` §10, `docs\cercetare\s3b_bloc5_ce_ramane.md` |
|
||||
| S3c | Sursa ca parametru, nu ca global | `ferestre_contracte.vc2`, `ocomenzi.vc2`, `ofacturare.prg`, `ofacturare_comun.prg`, `ofundal_facturare.vc2`, `oproceduri_facturare.prg` | S2. Atinge cod comun intregii suite - nu se face impreuna cu alta modificare | **INCHISA SI PROBATA (S3c-1/2/3/4-tinta1)** + **INCHISA FARA COD (S3c-4-tinta2 si S3c-5)**, 31.08.2026 — S3c-1/S3c-2/S3c-3: `toSursa` la coada in `Init`/`factureaza`/`facturare_contracte`/`facturare_comenzi`, test 55/0, comis 27.08.2026. S3c-4 tinta 1 (`ocomenzi.vc2:do_factura`): LIVRATA, test 18/0. S3c-4 tinta 2 (ROACONTRACTE) si S3c-5 (sincronizare cross-produs, 6 produse): mutate intr-o **poveste separata prin decizia lui Marius**, nu se mai ating la planul #13 (detaliu in §9 al handoff-ului) | `docs\nota_executie_s3c.md`, `docs\raport_s3c_1_implementare.md`, `docs\handoff_13_s4_s3c.md`, `docs\propunere_s3c_4_apelanti_reali.md`, `docs\propunere_s3c_5_sincronizare.md` |
|
||||
| S4 | Cautarea articolelor pe server, in linie | `ofacturare.prg`, `ofacturare.vc2` | S3 | **PARTIALA** — S4-1 (Oracle articole server) INCHISA SI PROBATA, 23.08.2026 (identic byte-cu-byte pe filtru NULL fata de baseline); S4-2 (functii Oracle remainder/plafon) INCHISA SI PROBATA, 24.08.2026 (114 randuri numai adaugate in `PACK_FACTURARE`, zero stergeri); S4-3 (cautare in linie, `ofacturare_cautare.prg` nou) INCHISA SI PROBATA, 27.08.2026, teste 41/0, 50/0, 39/0; S4-4 (decuplare Rol A, decizia 6 varianta C) LIVRATA, PROBA MANUALA DATORIE, test paritate 18/0; **S4-5 (Rol B) PARTIALA** — garda `If Used(lcCursor)` in `do_sterge` LIVRATA (repara bug LIVE preexistent, test 10/10), dar plafonul Rol B pe tipul `23` a fost implementat, testat si **REVENIT** in aceeasi sesiune (garda structural moarta); ramane deschis prin deciziile 7 si 8 din handoff §2 (nedecise) [^2] | `docs\raport_s4_1_aplicare.md`, `docs\scripturi_oracle_13.md`, `docs\cercetare\s4_cautare_articole_server.md`, `docs\raport_s4_3_implementare.md`, `docs\raport_s4_4_vfp_implementare.md`, `docs\raport_s4_4_oracle_varianta_c.md`, `docs\propunere_s4_5_rol_b.md`, `docs\raport_s4_5_implementare.md` |
|
||||
| S4b | Bara de butoane si meniul de adaugare | `ofacturare.vc2` | S4 | **INCHISA FARA COD** — decizia 9 varianta 3 (31.08.2026): mecanismul v2 (`but_incarca_articole` -> `do_incarca_articole`) e pastrat neatins; alegerea selectiva devine poveste separata (datoria 19) | `docs\propunere_s4b_bara_butoane.md` |
|
||||
| S4c | Discount pe linie, mutat din dialog in grid | `ofacturare.vc2`, `ofacturare_comun.prg`, `oproceduri_facturare.prg`, `xmlefactura.prg` | S4 | **LIVRATA, PROBA MANUALA DATORIE** — handlere `LostFocus` pe cele doua campuri de discount + `recalc_discount_linie` nou, camp `procdisc` nou; repara si un defect preexistent (`cProcentDiscount` editabila dar legata la camp inexistent); test 26/0/0, write-back verificat independent | `docs\propunere_s4c_discount_grid.md` |
|
||||
| S4d | Data cursului valutar, numai cand are sens | `ofacturare.prg`, `ofacturare.vc2`, `ofacturare_comun.prg` | S4 | **LIVRATA, PROBA MANUALA DATORIE** — metoda noua `do_actualizeaza_vizibilitate_curs`, apelata din 3 puncte (sink comun `do_calculeaza_totaluri`, `Init`, `do_incarca_articole`); test 32/0/0, inclusiv traseul complet al erorii Oracle `-20005`, write-back verificat independent | - |
|
||||
| S4e | Lista de preturi si pe factura din comanda | `ofacturare.prg`, `ofacturare.vc2` | S4-1, S4-3 | **INCHISA SI PROBATA** — S4e-1 acoperit de S4-3 (prin `do_adauga_articol_cautat`, acceptat de Marius ca solutie finala, nu se redeschide); S4e-2 GATA (decizia 44); S4e-0 GATA 31.08.2026 (deblocarea `do_adauga_articol`); S4e-3 GATA 31.08.2026 (validare cantitate/stoc, tipurile `3,4,21,25,28,42,47`, test 62/0/0); S4e-4 GATA (proba de neregresie a registrului, fara cod nou, test 15/0/0); S4e-5 GATA (probe repetate pe tip 4/21 + captura dialog, test 37/0/0) | `docs\nota_executie_s4e.md`, `docs\recon_s4e_stare_reala.md`, `docs\raport_s4e_2_implementare.md`, `docs\raport_s4e_0_implementare.md`, `docs\raport_s4e_3_implementare.md`, `docs\raport_s4e_4_implementare.md` |
|
||||
| S4f | Returul in formularul unificat | `ofacturare.vc2` | S2, S4e | **INCHISA** (08.09.2026) — stare veche din acest tabel depasita, vezi `docs\handoff_plan13_executie_continua.md` §4.0; `do_adauga_articol_cautat` deleaga returul (tip 8/9/41) la `do_adauga_articol` | `docs\raport_s4f_retur.md` |
|
||||
| S4g | Adaugare articole la modificarea documentului | `ofacturare.vc2`, `ofacturare_comun.prg` | S4e + deciziile de mai sus. Nu blocheaza etapa I | **INCHISA** (08.09.2026) — stare veche din acest tabel depasita, vezi `docs\handoff_plan13_executie_continua.md` §4.0; decizia 34/optiunea B aplicata (Oracle `FACT-032` + VFP `deriva_cont_venit_fara_pol`) | `docs\raport_s4g_oracle.md`, `docs\raport_s4g_vfp.md` |
|
||||
| S5 | Acoperirea tuturor tipurilor de document | `ofacturare.prg` | S4 | **INCHISA SI PROBATA**, 01.09.2026 — cod COMUN `1f89c18` (v2), teste conform §6 al handoff-ului | `docs\propunere_s5_acoperire_tipuri.md`, `docs\matrice_goluri_s5_form2.md`, `docs\verificare_s5_tabel_sursa.md` |
|
||||
| S5b | Proforma si copierea pe formularul unificat | `ofacturare.prg`, `ofacturare.vc2`, `ofacturare_comun.vc2`, `oproceduri_facturare.prg` | S5 | **INCHISA SI PROBATA**, 01.09.2026 — COMUN `76e7398` (emiterea proformei pe formularul unificat, v2) + `d6cae36` (v1, calea de copiere); teste `080321f` (UI, 20/0/2) + testul de rutare (22/0/0). Ramane o singura datorie neblocanta: clauza de gestiune probata prin paritate, nu prin `id_gestiune > 0` (M3) | `docs\propunere_s5b_proforma_copiere.md`, `docs\raport_s5b_implementare.md`, `docs\raport_verificare_s5b_disc.md` |
|
||||
| S5c | Factura din proforma (decizia 43) | `cmd_butoane.vc2`, `ocomenzi.vc2`, `ofacturare.prg`, `ofacturare.vc2`, `ofacturare_comun.prg`, `ofacturare_comun.vc2`, `ofacturare_editare.prg`, `oinit_optiuni.prg`, `xmlefactura.prg` | S5b | **INCHISA SI PROBATA**, 01.09.2026 — proba capat-la-capat prin UI RULATA, 20/0/2; vezi si golul de produs semnalat separat (nu al lui S5c) in handoff §4.0a | `docs\raport_s5c_test_ui.md` |
|
||||
| S6 | Test pe flux real - formularul unificat | (test, nu cod nou) | S5 | **PARTIALA** — INCHIS 02.09.2026 cu proba partiala: **4 din 7** surse au acum comparatie v1/v2 pe document real emis (0/7 la pornire), **7 defecte de productie gasite, 6 reparate si comise** (3 cu proba doar partiala) | `docs\raport_s6_flux_real.md`, `docs\propunere_s6_test_flux_real.md`, `docs\raport_s6_1_lista_preturi.md`, `docs\raport_s6_3_aviz_retur.md`, `docs\raport_s6_4_transfer.md`, `docs\raport_s6_5_valuta.md`, `docs\raport_s6_6_listare_intrare.md` |
|
||||
| S7 | Actiunea si garzile | `ofacturare_comun.vc2`, `ofacturare_editare.prg` | S6, si inchiderea perimetrului cu #6 | **INCHISA SI PROBATA**, 02.09.2026 — cod revizuit integral si comis, COMUN `70eddfa`; cele 5 cerinte de review inchise (cens octeti 13=13, metoda cu toate cele 3 inregistrari). Metoda ramane schela, fara apelant, pana cand S8 cableaza a treia optiune de meniu | `docs\propunere_s7_actiune_garzi.md`, `docs\raport_s7_actiune_garzi.md`, `docs\verif_s7_doua_fapte.md` |
|
||||
| S8 | Incarcarea documentului in formular | `ferestre_cere_date.vc2`, `ofacturare.prg`, `ofacturare.vc2`, `ofacturare_comun.prg`, `ofacturare_editare.prg`, `ofacturare_stoc.prg` | S7 | **INCHISA SI PROBATA**, 02.09.2026 — pasii 1-8 GATA, proba finala `test_s8_editare_incarcare.prg` 307/0, CINCI rulari consecutive identice verificate pe md5/diff. Decizia 1 (`IN_STOC`) INCHISA de Marius (handoff §2). Defect nou, neblocant, in afara perimetrului: **G10 incalcat pentru avize** | `docs\propunere_s8_incarcare.md`, `docs\raport_s8_pas7b_proba.md`, `docs\raport_s8_defect5_incasat.md`, `docs\nota_s8q_aplicare_etapa6.md` |
|
||||
| S8b | Rutarea scrierii dupa schimbarea tipului | `ferestre_cere_date.vc2`, `ofacturare.vc2` | S8 | **INCHISA SI PROBATA**, 03.09.2026 — rutarea scrierii la editare, COMUN `0a41327`, ROAF `e5530fe`; proba 54/0, trei rulari consecutive identice, toate cele patru rute exercitate pe traseul real | `docs\raport_s8b_implementare.md` |
|
||||
| S8c | Buton comutator antet + salvare separata | `lb_tx.vc2`, `rulaje.vc2` | S8 | **NEINCEPUT** — mentionata in handoff doar ca alternativa paralela posibila cu S9 (mai mica, poate rula in paralel), fara cod scris pana acum | - |
|
||||
| S9 | Stergere + reemitere intr-o tranzactie, `ID_FACT` pastrat | `oscrie_in_fisiere.prg` | S8b | **PARTIALA — IN LUCRU (03.09.2026)** — S9-1..S9-7 INCHISE SI PROBATE (S9-6 `PACK_CONTAFIN.nIdFactFortat` aplicat/probat pe `MARIUSM_AUTO`; S9-7 cablaj VFP aplicat si probat, sweep P1-P6/CN1-CN4 verde, COMUN `658acc6`/`cc79734`, ROAF `5886b3f`/`119474e`). **S9-8** (testul de flux: reemitere identica + cu modificari, pe aviz/comanda/contract/ELSE) **IN LUCRU** in aceasta sesiune. Datorii neinchise: proba vizuala UI dupa scoaterea garzii, neregresia pe ROACONTRACTE pentru scriptul #9 | `docs\propunere_s9_stergere_reemitere.md`, `docs\propunere_s9_6_pack_contafin.md`, `docs\propunere_s9_7_cablare_idfact.md`, `docs\raport_s9_7_oracle.md`, `docs\raport_s9_7_vfp_aplicare.md`, `docs\raport_s9_7_vfp_proba.md` |
|
||||
| S10 | Pretul care nu trebuie re-derivat | `ofacturare.prg`, `ofacturare.vc2`, `ofacturare_editare.prg` | S9 | **NEINCEPUT** — decizia 3 (`PROC_TVAV` ca parametru) care il blocheaza e INCHISA (handoff §2), deci pornirea nu mai e conditionata de o decizie in asteptare | - |
|
||||
| S11 | Legaturile ramase pe `ID_VANZARE` | (verificare + cod punctual, vezi plan) | S9 | **NEINCEPUT** | - |
|
||||
| S12 | Test pe flux real - regenerarea | (test, nu cod nou) | S10, S11 | **INCHISA** - criteriul (toate cele patru familii trec scenariul B) atins prin sweep 4/4 pe `test_s9_8_flux.prg`, 04.09.2026 | `docs\raport_s12_inchidere.md` |
|
||||
| S14 | Audit: creare, modificare, stergere document | `ofacturare_editare.prg` | S9 | **INCHISA**, 04.09.2026 — criteriul din plan bifat pe date reale (documentele reemise 1195/1196); vezi datoriile deschise in raport | `docs\raport_s14_oracle.md`, `docs\raport_s14_vfp_transport.md`, `docs\raport_s14_vfp_grid.md`, `docs\raport_s14_inchidere.md` |
|
||||
| S13 | Diff, review, changelog, documentatie | toate cele de mai sus (inchidere de etapa) | toate stories anterioare - livrare finala | **NEINCEPUT** | - |
|
||||
|
||||
[^1]: In plus, nedus in niciun raport separat pana acum: `lb_total_mod` e cod viu dar inert
|
||||
(`docs\raport_s3b_lb_total_mod.md`, recomandat pentru alta poveste); euristica „205/210 dezalinieri
|
||||
de coloana" din `verifica_grila.ps1` ramane neinvestigata.
|
||||
|
||||
[^2]: Tipul `41` (S4-5) ramane definitiv in afara perimetrului curent — fix-ul necesar e proiectat
|
||||
in `docs\propunere_s4_5_rol_b.md` §7, dar nefacut, ca sa nu arate tacit stoc din gestiuni gresite.
|
||||
|
||||
## Firul geometrie (designer editabil)
|
||||
|
||||
Firul separat, comis tot pe `plan13-s2`, prin care Marius poate aranja controalele formularului cu
|
||||
mana in designerul VFP (`docs\sinteza_designer_editabil.md`). A folosit intern aceleasi litere
|
||||
`S6`/`S7`/`S8b`/`S8c` in documentele lui proprii (`docs\handoff_s6_designer_editabil.md`,
|
||||
`docs\handoff_s7_containere.md`, `docs\handoff_s8b_transa_a_si_ghid.md`,
|
||||
`docs\handoff_s8c_transa_c.md`) si, intr-o etapa ulterioara, etichetele `S8h`-`S8p`/Etapa 6 — **fara
|
||||
nicio legatura** cu povestile din tabelul de mai sus. Randurile de aici sunt rasfrangerea acelei
|
||||
etape ulterioare (sursa: `docs\handoff_plan13_executie_continua.md` §3); tot firul e **INCHIS SI
|
||||
COMIS**.
|
||||
|
||||
| Bloc | Ce | Stare | Commit |
|
||||
|---|---|---|---|
|
||||
| S8-geometrie-h..m | Ancorare nativa vs. geometrie din cod; bitul `Bottom(4)` scos de pe controalele asezate din cod | **INCHISA** | COMUN `e2eca46` |
|
||||
| S8-geometrie-n | Test de geometrie mutat din scratchpad in arborele de teste | **INCHISA SI PROBATA**, 8/8 pasi | COMUN `4063277`, ROAF `20eb547` |
|
||||
| S8-geometrie-p | Dependenta rupta reparata: `Clase\ofacturare_util.vc2` intrat in versionare + `SET CLASSLIB` in `roafacturare.prg` | **INCHISA** — fara ea, `plan13-s2` era rupt la checkout curat | ROAF `fe3eef8` |
|
||||
| S8-geometrie-o | Proba de rezolutie 1366x768 + diagnosticul benzii de totaluri | **INCHISA SI PROBATA** — la 1366x768 maximizat, deficit 98px, preexistent, nu regresie | COMUN `261f547`, ROAF `6257df6`, `3b312a0` |
|
||||
| Etapa 6 | 5 fisiere de test reparate (`ObjExists` facut recursiv in 3; substitutia `opt_incasat.Value` -> `seteaza_mod_incasare` aplicata doar pe siturile formei NOI) | **INCHISA SI PROBATA** — `test_s3b_emitere_paritate_2` 20/0, `test_s3b_emitere_reala` 1/0, `test_s3_controale` 20/0, zero aparitii ale erorii 1734 | COMUN `34a1f30` |
|
||||
|
||||
## Ordinea de executie rezultata din dependente
|
||||
|
||||
```
|
||||
S1 (GATA)
|
||||
-> S2 (GATA implementare, in asteptare review/aprobare)
|
||||
-> S3c (paralel cu S3, atinge alt fisier comun - nu impreuna cu alta modificare)
|
||||
-> S4e (STALE: aici in arbore ca "porneste dupa S2"; depinde de fapt de S4-1 si S4-3 -
|
||||
vezi randul S4e din tabel si `docs\nota_executie_s4e.md` §6)
|
||||
-> S4f (dupa S4e)
|
||||
-> S3
|
||||
-> S3b
|
||||
-> S4 (proiecteaza intai punctul 2, neproiectat)
|
||||
-> S4b
|
||||
-> S4c
|
||||
-> S4d
|
||||
-> S4g (dupa S4e + deciziile anterioare; nu blocheaza etapa I)
|
||||
-> S5
|
||||
-> S5b
|
||||
-> S5c
|
||||
-> S6 (test pe flux real)
|
||||
-> S7 (dupa inchiderea perimetrului cu #6)
|
||||
-> S8 (varianta IN_STOC fixata in nota de executie S8, runda 17)
|
||||
-> S8b
|
||||
-> S9
|
||||
-> S10
|
||||
-> S11
|
||||
-> S14
|
||||
-> S12 (dupa S10 si S11)
|
||||
-> S8c
|
||||
-> S13 (inchidere finala, dupa toate)
|
||||
```
|
||||
|
||||
Observatii pe ordine:
|
||||
- S3c si S4e nu depind de S3/S4 - pot fi luate in paralel cu ramura S3, dar **un singur scriitor pe
|
||||
fisier**: S3c atinge `ofacturare.prg`/`oproceduri_facturare.prg`, S2 le-a atins deja si le-a
|
||||
eliberat (S2 e inchisa la nivel de implementare), deci nu se suprapun.
|
||||
- S4g explicit "nu blocheaza etapa I" - poate aluneca dupa S6/S7 fara sa opreasca lantul principal.
|
||||
- S8c e paralela cu S9 (ambele depind doar de S8), dar scrie in fisiere diferite (`lb_tx.vc2`,
|
||||
`rulaje.vc2` vs `oscrie_in_fisiere.prg`) - fara conflict de scriitor.
|
||||
- **Starea reala la 03.09.2026** (handoff §6): lantul e dus pana la S9 (S9-1..S9-7 inchise,
|
||||
S9-8 in lucru); ordinea ramasa e **S10 -> S11 -> S12 -> S14 -> S13**, cu **S8c** paralela.
|
||||
Actualizare 04.09.2026: **S12 inchisa** (`docs\raport_s12_inchidere.md`) - vezi §4.0 al
|
||||
handoff-ului pentru starea curenta. **S14 inchisa** (`docs\raport_s14_inchidere.md`) - ramane
|
||||
doar **S13** (inchiderea de etapa), cu **S8c** in continuare paralela.
|
||||
|
||||
## Cele 3 puncte de implementare ramase deschise — TOATE INCHISE (handoff §2, 31.08.2026)
|
||||
|
||||
Sursa initiala: `docs\handoff_13_formular_unificat.md`. Cele trei decizii ale lui Marius care le
|
||||
inchid sunt in `docs\handoff_plan13_executie_continua.md` §2.
|
||||
|
||||
1. **Relistarea unei facturi vechi deja trimise** (decizia 62) — **INCHISA**: toate facturile se
|
||||
tiparesc dupa regula noua, fara versionare dupa data. Facturile trimise la ANAF nu se mai pot
|
||||
retrimite.
|
||||
2. **`PROC_TVAV` ca parametru** (consecinta 3 a deciziei 54) — **INCHISA, DA devine parametru**:
|
||||
caile de copiere si modificare pastreaza cota documentului original; blocheaza S10.
|
||||
3. **De unde se reconstituie `IN_STOC`** — **INCHISA, varianta (2)**: valoarea curenta din
|
||||
nomenclator, fara migrare DB si fara reconstituire din rulaje; blocase S8, acum livrat si probat.
|
||||
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user