From b5a7108f34fce3ca78a00ece36dca2f65bda9641 Mon Sep 17 00:00:00 2001 From: Marius Mutu Date: Tue, 11 Aug 2026 22:31:42 +0300 Subject: [PATCH] docs: cercetarile comune trec in COMUN, reziduul #6 dispare, progres.md la zi Curatenie ceruta dupa inchiderea lui #6. Folderul cercetare\ NU se putea sterge in bloc: plan_13 se sprijina pe el cu 85 de trimiteri, deci e baza de dovezi a planului aflat in lucru. Impartirea: - 14 cercetari trans-proiect trec in COMUN\docs\cercetare\ - valuta si curs, TVA/VANZARI, consumatorii VANZARI din toata suita, integrarile #10/#11/#12, watchdog VFP, proiectarea Oracle a lui S5, view-ul VVANZARI_ARTICOLE. Nu sunt ale ROAFACTURARE, iar #10/#11/#12 se reiau chiar din ele. - 20 de rapoarte de executie ale lui #6, nereferite de nimic viu, sterse. - 91 raman, neatinse. Trimiterile catre handoff-urile si diff-urile intermediare deja desfiintate au fost curatate peste tot (39 de fisiere): 50 catre handoff-uri, 37 catre diff-uri aplicate, plus caile celor mutate in COMUN. Zero trimiteri rupte ramase. progres.md preia rolul de predare: ce ramane din #6 (cele sase documente parazite, cele doua esecuri reale din S8 pe factura din aviz), cifrele de test citite din log, si cele doua capcane de mediu platite - .FXP vechi executat in locul .prg-ului, si GETFONT() care atarna un formular instantiat fara goApp. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3 --- docs/brief_s5_test_scriere_reala.md | 8 +- .../cont_venit_articol_fara_politica.md | 128 --- docs/cercetare/coresp_cont_venchelt.md | 2 +- docs/cercetare/discount_pe_articol.md | 164 ---- docs/cercetare/discount_verificare2.md | 182 ---- docs/cercetare/ff_view_articole_vanzare.sql | 35 - docs/cercetare/handoff_propr_custom.md | 103 --- docs/cercetare/handoff_s4_runda1.md | 2 +- docs/cercetare/handoff_test_writeback.md | 121 --- docs/cercetare/handoff_watchdog_vfp.md | 127 --- docs/cercetare/import_roris_roaacnpro.md | 210 ----- docs/cercetare/legatura_linie_retur.md | 2 +- docs/cercetare/mockup_v7_modificari.md | 53 -- docs/cercetare/mockup_v8_modificari.md | 99 --- docs/cercetare/modifica_antet_bifa.md | 193 ----- .../proforma_copiere_puncte_intrare.md | 199 ----- docs/cercetare/q8.sql | 19 - docs/cercetare/rec_cele_41_facturi.md | 2 +- docs/cercetare/rec_consumatori_vanzari.md | 220 ----- docs/cercetare/rec_d42_efactura.md | 4 +- docs/cercetare/rec_datoria6_baza_regresie.md | 2 +- docs/cercetare/rec_dec42_proiectare.md | 4 +- docs/cercetare/rec_fix_grid_tvd_blank.md | 4 +- docs/cercetare/rec_garda_idset.md | 2 +- docs/cercetare/rec_integrari.md | 358 -------- docs/cercetare/rec_modific2024.md | 177 ---- docs/cercetare/rec_pret_lazy.md | 243 ------ docs/cercetare/rec_review_ancorare_s4.md | 2 +- docs/cercetare/rec_s10_s12.md | 110 --- docs/cercetare/rec_s1_s3_intrare_editare.md | 446 ---------- docs/cercetare/rec_s4_apelanti.md | 2 +- docs/cercetare/rec_s4_fix_culoare_valuta.md | 221 ----- docs/cercetare/rec_s4_runda1.md | 8 +- docs/cercetare/rec_s4_runda2.md | 4 +- docs/cercetare/rec_s4_runda3b.md | 10 +- docs/cercetare/rec_s4_runda3b2.md | 8 +- docs/cercetare/rec_s4_runda3c.md | 6 +- docs/cercetare/rec_s4_runda3c2.md | 6 +- docs/cercetare/rec_s4_runda3c3.md | 4 +- docs/cercetare/rec_s4_valuta_dialog.md | 6 +- docs/cercetare/rec_s4b_dialog_smoke.md | 82 -- docs/cercetare/rec_s4b_document_test.md | 214 ----- docs/cercetare/rec_s4b_etapa1.md | 175 ---- docs/cercetare/rec_s5_agatare.md | 93 --- docs/cercetare/rec_s5_cale_scriere_vfp.md | 2 +- docs/cercetare/rec_s5_discount_valuta.md | 2 +- docs/cercetare/rec_s5_goluri_test.md | 2 +- docs/cercetare/rec_s5_helper_scriere.md | 186 ----- docs/cercetare/rec_s5_proiectare_oracle.md | 780 ------------------ docs/cercetare/rec_s5_scriere_reala.md | 4 +- docs/cercetare/rec_s5_script_oracle.md | 296 ------- docs/cercetare/rec_s5_teste.md | 10 +- docs/cercetare/rec_s7_rotunjire.md | 6 +- docs/cercetare/rec_s8_inventar.md | 131 --- docs/cercetare/rec_s8_matrice.md | 164 ---- docs/cercetare/rec_s9_documentatie.md | 6 +- docs/cercetare/rec_tva_vanzari.md | 341 -------- docs/cercetare/rec_view_articole_vanzare.md | 164 ---- docs/cercetare/rec_watchdog_vfp.md | 207 ----- docs/cercetare/roaauto_facturi.md | 6 +- docs/cercetare/s10_curata_versiune.sql | 55 -- docs/cercetare/s11_legaturi_id_vanzare.md | 2 +- docs/cercetare/s3_portare_antet.md | 4 +- docs/cercetare/s4b_bara_butoane_meniu.md | 2 +- docs/cercetare/s4d_zi_curs_reactiv.md | 2 +- docs/cercetare/valuta_si_curs.md | 296 ------- docs/livrare_s5.md | 24 +- docs/plan_13_unificare_formular_facturare.md | 34 +- docs/plan_index.md | 2 +- docs/progres.md | 180 ++-- docs/propunere_s4b_sincronizare.md | 6 +- docs/rec_s4b_etapa2.md | 6 +- docs/review_s5_grid_articole.md | 4 +- 73 files changed, 227 insertions(+), 6757 deletions(-) delete mode 100644 docs/cercetare/cont_venit_articol_fara_politica.md delete mode 100644 docs/cercetare/discount_pe_articol.md delete mode 100644 docs/cercetare/discount_verificare2.md delete mode 100644 docs/cercetare/ff_view_articole_vanzare.sql delete mode 100644 docs/cercetare/handoff_propr_custom.md delete mode 100644 docs/cercetare/handoff_test_writeback.md delete mode 100644 docs/cercetare/handoff_watchdog_vfp.md delete mode 100644 docs/cercetare/import_roris_roaacnpro.md delete mode 100644 docs/cercetare/mockup_v7_modificari.md delete mode 100644 docs/cercetare/mockup_v8_modificari.md delete mode 100644 docs/cercetare/modifica_antet_bifa.md delete mode 100644 docs/cercetare/proforma_copiere_puncte_intrare.md delete mode 100644 docs/cercetare/q8.sql delete mode 100644 docs/cercetare/rec_consumatori_vanzari.md delete mode 100644 docs/cercetare/rec_integrari.md delete mode 100644 docs/cercetare/rec_modific2024.md delete mode 100644 docs/cercetare/rec_pret_lazy.md delete mode 100644 docs/cercetare/rec_s10_s12.md delete mode 100644 docs/cercetare/rec_s1_s3_intrare_editare.md delete mode 100644 docs/cercetare/rec_s4_fix_culoare_valuta.md delete mode 100644 docs/cercetare/rec_s4b_dialog_smoke.md delete mode 100644 docs/cercetare/rec_s4b_document_test.md delete mode 100644 docs/cercetare/rec_s4b_etapa1.md delete mode 100644 docs/cercetare/rec_s5_agatare.md delete mode 100644 docs/cercetare/rec_s5_helper_scriere.md delete mode 100644 docs/cercetare/rec_s5_proiectare_oracle.md delete mode 100644 docs/cercetare/rec_s5_script_oracle.md delete mode 100644 docs/cercetare/rec_s8_inventar.md delete mode 100644 docs/cercetare/rec_s8_matrice.md delete mode 100644 docs/cercetare/rec_tva_vanzari.md delete mode 100644 docs/cercetare/rec_view_articole_vanzare.md delete mode 100644 docs/cercetare/rec_watchdog_vfp.md delete mode 100644 docs/cercetare/s10_curata_versiune.sql delete mode 100644 docs/cercetare/valuta_si_curs.md diff --git a/docs/brief_s5_test_scriere_reala.md b/docs/brief_s5_test_scriere_reala.md index 13db766..74eb41f 100644 --- a/docs/brief_s5_test_scriere_reala.md +++ b/docs/brief_s5_test_scriere_reala.md @@ -1,6 +1,6 @@ # Briefing — S5, testul cu scriere reala in Oracle -Misiune pentru un agent proaspat. Se citeste **impreuna cu** `docs\handoff_s5.md` (starea blocului) si +Misiune pentru un agent proaspat. Se citeste **impreuna cu** handoff intermediar (sters) (starea blocului) si `COMUN\docs\reguli_lucru.md` (regulile de livrare si testare). Nu relua cercetarea — e facuta. ## De ce exista acest test @@ -66,7 +66,7 @@ linia finala a suitei (`REZULTAT` sau `done`, dupa tipar). ## Aprobare si costuri -**Scrierea reala e aprobata de Marius** (09.08.2026), aprobarea e consemnata in `handoff_s5.md`. +**Scrierea reala e aprobata de Marius** (09.08.2026), aprobarea e consemnata in handoff intermediar (sters). **Consuma date de test ireversibil**: `cod`-ul documentului se realoca la fiecare salvare (la testul precedent, `1140886 -> 1140893 -> 1140894`). Alege un document de test, **nu** unul folosit ca baza de regresie de alte suite daca poti evita, si **consemneaza in raport `cod`-urile consumate**. @@ -88,7 +88,7 @@ regresie de alte suite daca poti evita, si **consemneaza in raport `cod`-urile c 1. `COMUN\utile\Teste\editare_factura\test_s5_scriere_reala.prg` — suita. 2. `D:\ROA\ROAFACTURARE\docs\cercetare\rec_s5_scriere_reala.md` — raportul: ce s-a dovedit, ce nu, `SELECT`-urile de verificare cu rezultatele lor, `cod`-urile consumate, cifrele din loguri. -3. `D:\ROA\ROAFACTURARE\docs\diff_s5_test_scriere_reala.patch` — diff-ul. +3. diff aplicat (sters) — diff-ul. Raspunsul catre orchestrator e **scurt**: „GATA" + cifrele + ce nu s-a dovedit. **Nu trimite raportul in text** — el sta pe disc. @@ -96,6 +96,6 @@ in text** — el sta pe disc. ## Predarea contextului (REGULA ZERO) Daca ajungi la **~200-250k** context: **opreste-te**, adu tot la o stare consistenta pe disc, scrie -`D:\ROA\ROAFACTURARE\docs\handoff_s5_scriere_reala.md` cu **starea** (ce e facut, ce nu, ce e +handoff intermediar (sters) cu **starea** (ce e facut, ce nu, ce e periculos: tranzactie deschisa, proces viu, date consumate), si anunta. Nu continua „ca mai e putin" — si **nu lasa niciodata o tranzactie deschisa** in Oracle. diff --git a/docs/cercetare/cont_venit_articol_fara_politica.md b/docs/cercetare/cont_venit_articol_fara_politica.md deleted file mode 100644 index 3ad23a4..0000000 --- a/docs/cercetare/cont_venit_articol_fara_politica.md +++ /dev/null @@ -1,128 +0,0 @@ -# Contul inregistrat pe o linie de vanzare, cu/fara politica de pret - -**Raspuns scurt**: nu exista, nicaieri in codul cercetat (VFP `ofacturare*` + Oracle -`pack_facturare`), un "cont de venit" (707/704/706/708) legat de linia de factura. Singurul cont -propagat pe linie e coloana `CONT` din `VANZARI_DETALII`/`VANZARI_DETALII_TEMP` (varchar 4 -caractere) — si aceasta e contul de **gestiune/stoc** (371 marfuri, 301-303 materii prime, 357 -custodie etc.), folosit pentru descarcarea de gestiune, nu un cont de venit. El **nu vine din -politica de pret** (`CRM_POLITICI_PRET_ART` nu are coloana `CONT` — verificat, nicio -`CREATE`/`ALTER TABLE CRM_POLITICI_PRET_ART ADD CONT` in `D:\ROA\DATABASE\SCRIPTURI_CLAR`), ci din -nomenclatorul de articole si din lotul de stoc ales. Asta inseamna ca "adaugarea directa din -nomenclator, fara politica de pret" **nu schimba mecanismul de completare a acestui camp** — el -oricum nu depinde de politica azi. Ramane neverificat unde/daca se decide efectiv un cont de venit -707/704/706/708 pentru nota contabila (nu e in `pack_facturare`). - -## 1. Unde e stocat / de unde se ia campul `CONT` - -- **Tabel/coloana tinta**: `VANZARI_DETALII_TEMP.CONT` si `VANZARI_DETALII.CONT`, populate prin - `pack_facturare.adauga_articol_factura` / `_deviz` / `_stoc` - (`ff_2026_08_06_10_COMUN_PACK_FACTURARE.sql:4690,4711,4735` / `:4761,4792,4814` / - `:5013,5247,5277`). -- **Sursa 1 — `NOM_ARTICOLE.CONT`** (prin view `vnom_articole`/`vnom_articole_crm`): coloana `a.cont` - e adusa in grila de cautare a articolelor, `COMUN\programe\ocautare.prg:1671,1683,1687` (`caut_articol`, - folosit de formularul unificat de facturare la alegerea articolului). Confirmata ca fiind pe - `NOM_ARTICOLE` prin `alter table NOM_ARTICOLE add ... A.CONT ...` (`D:\ROA\DATABASE\SCRIPTURI_CLAR\2019\12\ff_2019_12_20_02_COMUN.sql:12`, coloana veche, prezenta din 2009-2010). -- **Sursa 2 — `STOC.CONT`** (contul de pe lotul de stoc): `pack_facturare.cursor_gestiuni_articol` - (`ff_...:4358-4452`) — `SELECT ... A.CONT ... FROM STOC A2 ...` — folosit cand articolul e - **gestionabil** si se alege un lot din stoc (`frm_facturare_articole.do_alege_stoc`, - `COMUN\clase\ofacturare.vc2:13239-13345`, care seteaza `poArticol.Cont = Alltrim(Cont)` la - `:13345` din cursorul intors de Oracle). -- **Sursa 3 — `NOM_GESTIUNI.CONT`**: fallback cand nu exista lot de stoc, vezi punctul 2 - (`cursor_gestiuni_articol_stoc0`). -- **Politica de pret** (`CRM_POLITICI_PRET_ART`): are `PRET`, `PROC_TVAV`, `ID_VALUTA`, - `PRETFTVA` (vazute in `adauga_articol_factura`, declaratiile `V_PRET`, `V_PROC_TVAV` etc. la - `ff_...:5033-5036`) — **nicio coloana de cont**. Cautarea in `SCRIPTURI_CLAR` pentru - `ALTER TABLE CRM_POLITICI_PRET_ART ADD ... CONT` nu a gasit nimic. -- Nu exista `CONT_VENIT`/`ID_CONT_VENIT`/`COD_CONT` nicaieri in - `ff_2026_08_06_10_COMUN_PACK_FACTURARE.sql` (grep pe fisierul intreg, 17020 linii — zero - potriviri) si nici in `NOM_ARTICOLE`/`CRM_POLITICI_PRET_ART` (cautat in `SCRIPTURI_CLAR`). - -## 2. Cum se decide efectiv la scriere — `cursor_gestiuni_articol` / `_stoc0` - -Cand articolul e gestionabil si exista stoc, `cursor_gestiuni_articol` (`ff_...:4358-4452`) ia -contul direct de pe lotul de stoc: -``` -SELECT 0 AS ALES, A.ID_GESTIUNE, A.CANTITATE, A.CONT, ... -FROM (SELECT ... A2.CONT, ... FROM STOC A2 ...) A -LEFT JOIN NOM_GESTIUNI B ON A.ID_GESTIUNE = B.ID_GESTIUNE -``` -— `A.CONT` = `STOC.CONT`, fara nicio alta sursa, fara fallback (daca lotul de stoc are `CONT` -`NULL`, ramane `NULL`). - -Cand articolul e gestionabil dar **nu exista stoc** (optiunea `RF_FACTURARE_FARA_STOC = 1`), -`cursor_gestiuni_articol_stoc0` (`ff_...:4459-4558`) foloseste un lant `NVL2` explicit -(`ff_...:4472-4473`): -```sql -CAST(NVL2(B.CONT, B.CONT, NVL2(A.CONT, A.CONT, '371')) AS VARCHAR2(4)) AS CONT, -``` -unde `B` = `NOM_GESTIUNI` (contul implicit al gestiunii) si `A.CONT` = ultimul cont vazut in -`STOC` pentru articol (an curent/precedent). Ordinea reala: **cont gestiune -> ultimul cont din -stoc -> `'371'` hardcodat**. Acesta e singurul loc din pachet cu un `COALESCE`/`NVL2` in cascada -pe `CONT`, si singurul cu un default hardcodat. - -`adauga_articol_factura` (varianta apelata din `frm_facturare_articole.do_scrie_articole`, params -la `ff_...:4998-5024`) **nu recalculeaza** contul — il primeste ca parametru `V_CONT` si il scrie -ca atare (`V_CONT2 := V_CONT` daca `V_CONT <> 'XXXX'`, altfel ramane `NULL` — `ff_...:5044-5046`, -`V_CONT2` la INSERT `ff_...:5277`). `'XXXX'` e sentinela VFP pentru "fara valoare" — vezi -`COMUN\clase\ofacturare.vc2:6963,7123,7992` (`poDateGestiuneDest.Cont = Nvl(loCauta.Cont,[XXXX])`). -Aceeasi logica de trecere directa, fara recalcul, e in `adauga_articol_factura_deviz` -(`ff_...:4675-4745`, `V_CONT` scris direct in `CONT`, fara sentinela `'XXXX'`, fara `NVL`). - -## 3. Precedent ROAAUTO — "Alte servicii" (articol din nomenclator brut, fara politica de pret) - -Cursorul `lcCursorDeviz` (`ROAAUTO\Programe\oproceduri_devize.prg:880-887`) **nu are coloana -`Cont`**. `crsvanztemp` are `Cont c(4)` (`:1190-1192`) dar `INSERT INTO crsvanztemp(...)` de la -`:1201-1206` **nu o include** in lista de coloane si nici in `SELECT`-ul sursa — ramane la -valoarea implicita de camp caracter needatat, adica blank. La apel: -``` -['] + Alltrim(Nvl(poArticol.Cont,'')) + [',] + ... -- oproceduri_devize.prg:1256 -``` -trimite un literal `''` (gol) catre `adauga_articol_factura_deviz(..., V_CONT IN NUMBER, ...)` -(`ff_...:4690`). Un literal `''` convertit implicit la `NUMBER` devine `NULL` in Oracle; `V_CONT` -ajunge `NULL` si e scris direct in `VANZARI_DETALII_TEMP.CONT` (`ff_...:4735`), fara `NVL`, fara -fallback. **Concluzie**: liniile "Alte servicii" din ROAAUTO (articol real, fara politica de pret, -pret tastat manual — vezi `roaauto_articole_lista_preturi.md`) ajung cu `CONT = NULL` in Oracle. -Nu exista in cod niciun raspuns explicit "cont pentru articol fara politica" — rezultatul e pur si -simplu absenta valorii, nu o valoare calculata. - -## 4. Gestionabile vs. negestionabile - -Difera **calea**, nu neaparat sursa initiala: -- **Gestionabil** (`poArticol.gestionabil <> 0`): `frm_facturare_articole.do_adauga_articol` - (`COMUN\clase\ofacturare.vc2:12871-12896`) cere alegerea unui lot/gestiune prin `do_alege_stoc`, - care suprascrie `poArticol.Cont` cu valoarea din `cursor_gestiuni_articol[_stoc0]` (punctul 2) — - deci `STOC.CONT`/`NOM_GESTIUNI.CONT`, nu `NOM_ARTICOLE.CONT`. -- **Negestionabil** (`poArticol.gestionabil = 0`) sau `gnScadereStoc = 0`: se instantiaza - `frm_articol_factura` direct (`:12871-12880`), fara trecere prin `do_alege_stoc` — `poArticol.Cont` - ramane cel citit initial la cautarea articolului, adica `NOM_ARTICOLE.CONT` (punctul 1, sursa 1), - neschimbat. - -## 5. Ce se intampla daca nu se gaseste niciun cont - -- Nicio exceptie/`RAISE_APPLICATION_ERROR` legata de `CONT` in tot pachetul (spre deosebire de - cota de TVA, unde lipsa produce explicit `FACT-012`/`FACT-013`/`FACT-018`, - `ff_...:5151-5153,5184-5187,5203-5206`). -- **Gestionabil, cu stoc**: `CONT` = `STOC.CONT`; daca acesta e `NULL` in stoc, ramane `NULL` — - fara fallback (punctul 2, `cursor_gestiuni_articol`). -- **Gestionabil, fara stoc** (`RF_FACTURARE_FARA_STOC=1`): fallback pana la `'371'` hardcodat - (punctul 2, `cursor_gestiuni_articol_stoc0`). -- **Negestionabil / articol adaugat fara trecere prin gestiune** (inclusiv "Alte servicii" ROAAUTO): - `CONT` ramane ce a venit din `NOM_ARTICOLE.CONT`; daca e gol, `Nvl(poArt.Cont,'')` -> `''` -> - `NULL` in Oracle (`adauga_articol_factura`, sentinela `'XXXX'` la `ff_...:5044-5046`) — linie - scrisa **fara cont**, fara eroare. - -## Neverificat - -- Unde (daca undeva) se determina un **cont de venit propriu-zis** (707/704/706/708) pentru nota - contabila a vanzarii — nu e in `pack_facturare`; grep pentru `707`/`704`/`706`/`708` in - `ff_2026_08_06_10_COMUN_PACK_FACTURARE.sql` si in `ROAFACTURARE\Programe`/`COMUN\programe\ofacturare_comun.prg` - nu a gasit nimic. Probabil intr-un pachet de contabilitate/note contabile separat, neinclus in - scriptul analizat — ar necesita identificarea acelui pachet (posibil in ROACONT sau un - `pack_contabilitate`/`pack_note_ct`) si urmarirea generarii notei contabile din `VANZARI`/`VANZARI_DETALII`. -- Continutul exact al coloanei `NOM_ARTICOLE.CONT` pentru articole de tip "serviciu" (daca e - populata cu conturi de cheltuiala/productie 6xx/3xx sau lasata goala) — ar necesita o interogare - pe schema Oracle live, in afara bugetului acestei cercetari (doar cod static disponibil). -- Rolul exact al `ID_VENCHELT`/`NOM_VENIT_CHELTUIELI` (parametru la nivel de `ACT`/factura, vazut - la `ff_...:191,1885` si in `initializeaza_date_factura`) — pare o clasificare - venituri/cheltuieli la nivel de document, nu un cont de venit per linie; nu am urmarit - consumatorul lui pana la capat (posibil in raportare, nu in inregistrarea contabila). diff --git a/docs/cercetare/coresp_cont_venchelt.md b/docs/cercetare/coresp_cont_venchelt.md index 52be8b8..4eb7702 100644 --- a/docs/cercetare/coresp_cont_venchelt.md +++ b/docs/cercetare/coresp_cont_venchelt.md @@ -59,7 +59,7 @@ directa `contabilizeaza_articol` in `proceduri_acnpro.prg`: zero rezultate). Not documentului ACN o scrie **`pack_acn.salveaza_regdoc`**, o procedura complet separata, specifica ACN, apelata cu parametri proprii (`?.id_articol, ?.id_locatia, ?.id_valuta, ?.id_client, ?.id_contract, ?.pret, ?.curs, ?.cantitate, ?.valval, ?.tvaval, ?.totval, ...`) — **fara `id_pol`** in lista de -parametri. Confirmat si de raportul deja existent `docs\cercetare\import_roris_roaacnpro.md` +parametri. Confirmat si de raportul deja existent `COMUN\docs\cercetare\import_roris_roaacnpro.md` (sectiunea 3): "**nicio procedura Oracle stocata (`pack_*`) nu e apelata in etapa de import** ... acestea sunt apelate abia la salvarea finala", si articolele/preturile vin din dialoage de calcul tarife proprii ACN (`frm_calcul_tranzit`, `vctr_articole2`), nu din `CRM_POLITICI_PRET_ART`. diff --git a/docs/cercetare/discount_pe_articol.md b/docs/cercetare/discount_pe_articol.md deleted file mode 100644 index e3e7b8c..0000000 --- a/docs/cercetare/discount_pe_articol.md +++ /dev/null @@ -1,164 +0,0 @@ -# Investigatie: discount pe articol (linie de factura) — ROAFACTURARE - -Intrebare: discountul pe articol e azi doar procentual, sau exista si discount in valoare -absoluta pe unitate / pe linie? - -## 1. Model de date — DISCOUNT / DISCOUNT_UNITAR - -**Concluzie**: Exista deja o coloana de discount **in valoare absoluta pe unitate** -(`DISCOUNT_UNITAR`) pe `VANZARI_DETALII` (si pe `VANZARI_DETALII_TEMP`, tabela de lucru din care -se compune factura), pe langa discountul de document `VANZARI.DISCOUNT` (valoare absoluta -rezultata dintr-un procent aplicat la baza, nu procent stocat). Exista si un flag boolean -`VANZARI.DISCOUNT_EVIDENTIAT`. - -**Dovezi**: -- Tip coloana: `alter table VANZARI_DETALII modify discount_unitar NUMBER(22,6);` / - `alter table VANZARI_DETALII_TEMP modify discount_unitar NUMBER(22,6);` / - `alter table CRM_POLITICI_PRET_ART modify discount_unitar NUMBER(22,6);` — - `D:\ROA\DATABASE\SCRIPTURI_CLAR\2024\06\ff_2024_06_13_02_COMUN_FACTURARE.sql:3,9,16`. Precizia - `(22,6)` e cea folosita la coloane de pret/valoare, nu la procente. -- Exista si la nivel de politica de pret (`CRM_POLITICI_PRET_ART.DISCOUNT_UNITAR`), deci - discountul unitar poate proveni din politica de pret a clientului, nu doar tastat pe linie. -- Coloana e folosita direct ca scadere din pret: `A.PRET - NVL(A.DISCOUNT_UNITAR, 0) AS PRET` — - `D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\03\ff_2026_03_23_04_COMUN_PACK_FACTURARE.sql:3315,3500`. -- Document-level: `v.discount as disc_fara_tva` / `v.discount_evidentiat` — - `D:\ROA\DATABASE\SCRIPTURI_CLAR\2011\08\ff_2011_08_30_02_FACTURARE.sql:36-42,251-252,267,291`. - Discountul document e o valoare (lei/valuta), calculata din procent tastat de operator x baza - (vezi punctul 3), nu un procent stocat pe `VANZARI`. - -## 2. VFP — grid-uri de linii factura (`frm_facturare_articole` si `frm_facturare_articole2`) - -**Concluzie**: Ambele forme au coloane de grid pentru discountul unitar **in valoare absoluta**, -cu etichete explicite "Discount unitar cu TVA" / "Discount unitar in valuta fara TVA". In -`frm_facturare_articole` (forma standard) aceste coloane sunt read-only in grid (afisare, nu -editare directa pe linie); in `frm_facturare_articole2` (forma "noua", optionala) sunt editabile -si exista in plus o coloana de **procent pe linie** ("Procent discount", legata de campul -`procdisc`). - -**Dovezi**: -- `frm_facturare_articole`: `Column5.ControlSource = "discountctva"`, `Column5.Name = - "cDiscountCTva"`, `Column5.ReadOnly = .T.` si `Column9.ControlSource = "vdiscountftva"`, - `Column9.Name = "cVdiscountftva"` (fara `ReadOnly`, deci editabil implicit) — - `D:\ROA\ROAFACTURARE\COMUN\clase\ofacturare.vc2:12311-12317, 12340-12345`. Header-e: - `Caption = "Discount unitar cu TVA"` (`:12409`), `Caption = "Discount unitar in valuta fara - TVA"` (`:12546`). -- `frm_facturare_articole2`: `Column5.Name = "cDiscountCTva", Column5.ReadOnly = .F.` - (`:16656-16657`), `Column9.Name = "cVdiscountftva", Column9.ReadOnly = .F.` (`:16687-16688`), - plus `Column14.ControlSource = "procdisc"`, `Column14.Name = "cProcentDiscount"`, - `Column14.Format = "RK"`, `Column14.InputMask = "99 999.99"`, `Column14.ReadOnly = .F.` - (`:16720-16727`), header `Caption = "Procent discount"` (`:16934-16940`). -- Vizibilitate conditionata: nu de `poDate.tip` direct, ci de `poDate.in_valuta` — - `If poDate.in_valuta = 0 ... RemoveObject([cVdiscountftva]) ... Else ... - RemoveObject([cDiscountctva])` — `ofacturare.vc2:15269-15278` (pattern analog si la `:19065` - pentru `frm_facturare_articole2`). -- `frm_facturare_articole2` e optionala, activata prin `gnFacturareNou = 1` cu un dialog Da/Nu - ("Facturare noua (DA) sau standard (NU)?") — `COMUN\programe\ofacturare.prg:87-93`, instantiata - la `:929` (`lcObject = [frm_facturare_articole2]`). - -## 3. Calculul + `discount_evidentiat` - -**Concluzie**: `DISCOUNT_UNITAR` se scade direct din pretul unitar **fara TVA**, in valuta -documentului, inainte de a se aplica TVA-ul, apoi se inmulteste cu cantitatea. Flagul -`DISCOUNT_EVIDENTIAT` schimba doar mecanismul aritmetic (scade discountul din valoarea deja -calculata vs. din pretul unitar rotunjit), nu semantica — discountul ramane o valoare absoluta pe -unitate in ambele ramuri. In VFP, checkbox-ul corespunzator e etichetat "Se pune in evidenta -discount-ul pe articole in notele contabile si pe factura" — adica discountul e afisat separat pe -document/nota contabila vs. absorbit tacit in pret. - -**Dovezi** (`FUNCTION calculeaza_total_fara_tva_fact`, -`D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\03\ff_2026_03_23_04_COMUN_PACK_FACTURARE.sql:15794-15847`): - -``` -IF V_DISCOUNT_EVIDENTIAT = 1 THEN - V_SUMA_FARA_TVA := ROUND((ROUND(curs*PRET,...) - DIFERENTA)*CANTITATE,...) - - ROUND(ROUND(curs*NVL(DISCOUNT_UNITAR,0),...)*CANTITATE,...) -ELSE - V_SUMA_FARA_TVA := ROUND((ROUND(curs*ROUND(PRET,...),...) - - ROUND(curs*ROUND(NVL(DISCOUNT_UNITAR,0),...),...) - DIFERENTA)*CANTITATE,...) -``` - -Aceeasi structura simetrica in `calculeaza_total_tva_fact` (`:15899-15944`). In VFP, sinteza -corespunzatoare: `valdiminuatftva WITH poArticol.pretftva - NVL(poArticol.discount_unitar,0)` — -`ofacturare.vc2:13126`, conversia cu-TVA: `discount_unitar_ctva = -discount_unitar*(proc_tvav-1) + discount_unitar` — `:13635-13636`. Checkbox: -`ADD OBJECT 'ck_discountevidentiat' AS _checkbox WITH ... Caption = "Se pune in evidenta -discount-ul pe articole in notele contabile si pe factura", ControlSource = -"poDate.discount_evidentiat"` — `:11300-11305`. - -## 4. Oracle — parametrii `adauga_articol_factura` - -**Concluzie**: procedura primeste discountul ca parametru numeric absolut -`V_DISCOUNT_UNITAR IN NUMBER` si il scrie direct in `VANZARI_DETALII_TEMP.DISCOUNT_UNITAR`, fara -nicio transformare procent->valoare. Discountul de document (`VANZARI.discount`) e separat, -aplicat/gestionat la alt nivel (agregare pe factura, cf. `do_calculeaza_discount` in VFP). - -**Dovezi**: semnatura completa -`PROCEDURE adauga_articol_factura(V_ID_TEMP IN NUMBER, ... V_CANTITATE IN NUMBER, -V_DISCOUNT_UNITAR IN NUMBER, V_CONT IN VARCHAR2, ...)` — -`D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\03\ff_2026_03_23_04_COMUN_PACK_FACTURARE.sql:4972-4998`, -parametrul `V_DISCOUNT_UNITAR` la linia `4986`; -`INSERT INTO VANZARI_DETALII_TEMP (... DISCOUNT_UNITAR ...) VALUES (... V_DISCOUNT_UNITAR ...)` — -`:5219, 5249`. - -## 5. Discount unitar in valoare absoluta — exista deja in suita - -**Concluzie**: Da, exista deja in toata suita ROA — nu doar "conceptual", ci implementat si -cablat de la Oracle pana la grid. `COMUN\clase\ofacturare.vc2` (fisierul verificat pentru -ROAFACTURARE) e literalmente acelasi fisier partajat cu -`D:\ROA\ROAGEST\COMUN\clase\ofacturare.vc2` si `D:\ROA\ROAACNPRO\COMUN\clase\ofacturare.vc2` -(confirmat prin grep pe ambele arbore), la fel `pack_facturare`. Nu a fost nevoie de o cautare -separata in alt produs — e literalmente acelasi cod, aceeasi coloana. - -**Dovezi**: `discount_unitar`/`discountunitar` apare identic in -`D:\ROA\ROAGEST\COMUN\clase\ofacturare.vc2`, `D:\ROA\ROAGEST\COMUN\clase\ofacturare_comun.vc2`, -`D:\ROA\ROAGEST\COMUN\programe\ofacturare*.prg`, `D:\ROA\ROAACNPRO\COMUN\clase\ofacturare.vc2` si -`D:\ROA\ROAACNPRO\COMUN\clase\ofacturare_comun.vc2`; SQL-uri de discount identice (ex. -`v.discount as disc_fara_tva`) gasite si in -`D:\ROA\DATABASE\SCRIPTURI_CLAR\2021\02\ff_2021_02_03_01_VANZARI.sql:19-20,259-260,409-410, -481-482,612`. - -## 6. Ce ar presupune un discount unitar in valoare absoluta — inventar (nu solutie, doar puncte de atins) - -- **Coloana tabela**: deja exista (`VANZARI_DETALII.DISCOUNT_UNITAR`, `NUMBER(22,6)`, plus pe - `VANZARI_DETALII_TEMP` si `CRM_POLITICI_PRET_ART`) — nimic de adaugat. -- **Parametru Oracle**: deja exista (`adauga_articol_factura(... V_DISCOUNT_UNITAR ...)`, - `ff_2026_03_23_04_COMUN_PACK_FACTURARE.sql:4986`) — nimic de adaugat. -- **Coloana grid**: deja exista in ambele forme (`cDiscountCTva`/`cVdiscountftva`); in - `frm_facturare_articole` (forma standard, majoritara) e read-only — de decis daca se face - editabila pe linie sau ramane doar afisaj derivat din politica de pret / discountul procentual - de pe factura. -- **Intrare pentru operator**: in forma standard nu s-a gasit un punct unde operatorul tasteaza - manual `discount_unitar` per linie la adaugarea articolului — pare alimentat din - `CRM_POLITICI_PRET_ART.DISCOUNT_UNITAR` (politica de pret a clientului) sau din redistribuirea - discountului procentual de pe factura (`do_calculeaza_discount`, `ofacturare.vc2:13405-13424`). - De clarificat fluxul exact inainte de a proiecta un input nou. -- **Recalcul**: formulele Oracle (`calculeaza_total_fara_tva_fact`/`calculeaza_total_tva_fact`) - deja trateaza `DISCOUNT_UNITAR` ca valoare absoluta — nimic de schimbat aritmetic daca se - reutilizeaza calea existenta. -- **Rapoarte `.frx`**: nu s-a verificat daca discountul unitar apare pe rapoartele tiparite de - factura — necunoscut, de verificat separat. -- **eFactura / SAF-T**: nu s-a verificat daca `discount_unitar` e mapat in XML-ul UBL/eFactura sau - in declaratia SAF-T — necunoscut, de verificat separat (fisierele `COMUN_EFACTURA*.sql` / - `COMUN_SAFT*.sql` contin "discount" dar nu au fost citite). - -## Raspuns scurt la intrebare - -Nu doar procentual: **discountul pe articol exista deja si ca valoare absoluta pe unitate** -(`DISCOUNT_UNITAR`, `NUMBER(22,6)`), implementat capat la capat — coloana Oracle pe -`VANZARI_DETALII`/`VANZARI_DETALII_TEMP`, parametru in `pack_facturare.adauga_articol_factura`, -formule de calcul care scad direct din pret, si coloane de grid in VFP cu eticheta explicita -"Discount unitar cu TVA"/"...in valuta fara TVA". Discountul de document (`VANZARI.discount`) -ramane procentual-la-origine (tastat ca procent, stocat ca valoare calculata). Ce nu e clar e daca -operatorul poate tasta liber discountul unitar pe linie in forma standard -(`frm_facturare_articole`, unde coloana e read-only) — in forma "noua" optionala -(`frm_facturare_articole2`, `gnFacturareNou=1`) e editabila si are si un procent-pe-linie separat. - -## Necunoscute ramase - -- Sursa exacta a valorii `discount_unitar` la adaugarea unui articol in forma standard (politica - de pret vs. redistribuire din discountul procentual de pe factura) — nu s-a urmarit tot lantul - `do_adauga`/`crsgestarticol`. -- Daca `discount_unitar` apare pe rapoartele `.frx` tiparite. -- Daca `discount_unitar` e transmis in eFactura (UBL) sau SAF-T. -- Cat de folosita e efectiv `frm_facturare_articole2` in productie (e optionala, per sesiune, cu - prompt). diff --git a/docs/cercetare/discount_verificare2.md b/docs/cercetare/discount_verificare2.md deleted file mode 100644 index eb19a09..0000000 --- a/docs/cercetare/discount_verificare2.md +++ /dev/null @@ -1,182 +0,0 @@ -# Verificare discount pe linie de factura — frm_facturare_articole / VANZARI_DETALII - -Investigatie read-only. Toate liniile citate au fost verificate pe fisierul text real din working -copy (`ofacturare.vc2`, 23087 linii, ultima scriere 07.08 22:18) si pe scripturile DDL din -`D:\ROA\DATABASE\SCRIPTURI_CLAR`. Nu s-a executat nimic pe baza de date. - -## 1. Confirmare/infirmare afirmatii initiale - -**Concluzie**: toate afirmatiile despre `frm_facturare_articole` sunt corecte, cu linii care se -potrivesc exact sau aproape exact. Confirmat via `vfp_symbols.ps1 -Where` ca formularul -`frm_facturare_articole` ocupa exact `ofacturare.vc2:10968-15739`. - -**Dovezi**: -- `Column5.ControlSource = "discountctva"`, `Column5.Name = "cDiscountCTva"`, `Column5.ReadOnly = .T.` - — confirmat la `ofacturare.vc2:12311-12317` (identic cu afirmatia). -- `Column9.ControlSource = "vdiscountftva"`, `Column9.Name = "cVdiscountftva"`, **fara** `ReadOnly` - — confirmat la `ofacturare.vc2:12340-12345` (identic). -- Capete de coloana: `Caption = "Discount unitar cu TVA"` la `:12409`, `Caption = "Discount unitar in - valuta fara TVA"` la `:12546` — ambele confirmate exact. -- Excludere reciproca pe valuta la `ofacturare.vc2:15269-15278`: - ``` - 15269 If poDate.in_valuta = 0 - 15270 Thisform.grd_factura.RemoveObject([cVpretFtva]) - 15271 Thisform.grd_factura.RemoveObject([cVdiscountftva]) - 15272 Thisform.grd_factura.RemoveObject([cVvaldiminuatftva]) - 15273 Else - 15274 Thisform.grd_factura.RemoveObject([cPretFtva]) - 15275 Thisform.grd_factura.RemoveObject([cDiscountctva]) - ``` - confirmat identic (linii exacte, nu doar apropiate). -- `VANZARI_DETALII.DISCOUNT_UNITAR NUMBER(22,6)` — confirmat, dar cu precizare: linia corecta in - `ff_2024_06_13_02_COMUN_FACTURARE.sql` e `:3` (nu si `:9`/`:16` cum lasa sa se inteleaga - formularea initiala — acelea sunt `VANZARI_DETALII_TEMP` si, respectiv, `CRM_POLITICI_PRET_ART`, - vezi punctul 4). - -## 2. Consecinta practica pe ecran - -**Concluzie**: pe factura in lei, coloana vizibila e **"Discount unitar cu TVA"** (`discountctva`) -si e **needitabila** in grid (`ReadOnly = .T.`). Pe factura in valuta, coloana vizibila e -**"Discount unitar in valuta fara TVA"** (`vdiscountftva`) si **este editabila direct in grid** -(nicio proprietate `ReadOnly` setata pe coloana sau pe `Text1`-ul ei → mosteneste default-ul VFP, -`.F.`). - -**Dovezi**: -- Ramane pe ecran: cand `in_valuta = 0` se elimina cele 3 coloane "V..." (inclusiv - `cVdiscountftva`) → ramane `cDiscountCTva`. Cand `in_valuta <> 0` se elimina `cDiscountctva` (si - celelalte 3 coloane fara "V") → ramane `cVdiscountftva`. (`:15269-15278`, citat mai sus). -- Ca sa nu presupun ca lipsa lui `Column9.ReadOnly` inseamna implicit editabil, am verificat lantul - de clase: grid-ul `grd_factura` e `ADD OBJECT 'grd_factura' AS _grdrow` (`:12263`), fara - `ReadOnly` la nivel de grid intre `:12263-12364`; clasa `_grdrow` (`_grd_base.vc2:445`) nu - seteaza `ReadOnly` nicaieri in propriul body, iar parintele ei `_grdbase`/`_grid` de asemenea nu - (singurele 3 aparitii de `ReadOnly` in `_grd_base.vc2` sunt in clasa separata `_grdfooter`, - neinrudita). Deci Column9 chiar e editabila. -- Confirmare suplimentara: in formularul **`frm_facturare_articole2`** (prototip separat, clasa la - `ofacturare.vc2:15741-19355`, NU formularul in productie), aceleasi doua coloane apar cu - `ReadOnly` explicit: `Column5.ReadOnly = .F.` (`:16657`) si `Column9.ReadOnly = .F.` (`:16688`) — - adica in prototip discountul e editabil in ambele monede direct din grid; in formularul real - doar varianta in valuta e editabila din grid. - -## 3. Poate operatorul introduce azi un discount pe linie, si pe ce cale - -**Concluzie**: da, poate — dar nu prin `do_calculeaza_discount` de la -`frm_facturare_articole:13405-13424` (asta calculeaza discountul **global pe toata factura**, -`Thisform.ndiscfactron`/`ndiscfactval`, nicio legatura cu `discountctva`/`vdiscountftva` pe -linie — vezi corectia de la final). Calea reala e formularul **`frm_articol_factura`** -(`ofacturare.vc2:1108-2659`), deschis din `do_adauga_articol` la adaugarea unui articol -(`:12873`, `ofrmadarticol.Show(1)` doar daca `!tlImplicit`). Acolo exista metoda -`frm_articol_factura.do_calculeaza_discount` (`:1874-1976`) legata de 3 controale editabile: -`Clb_procent_discount.Text_simplu1` (procent), `Clb_discount_unitar.tx_suma_nat`/`tx_suma_val` -(suma in lei / valuta), `Clb_discountctva.tx_suma_nat`/`tx_suma_val` (varianta cu TVA) — toate cu -handler `Valid`/`InteractiveChange` care apeleaza `do_calculeaza_discount(valoare, tip)` cu -`tip=1` procent, `tip=2` lei, `tip=3` valuta (`:2602-2624`, `:2646-2649`). - -**Lantul, cu linii**: -1. Operator tasteaza in unul din campurile de mai sus → `Valid`/`InteractiveChange` → - `Thisform.do_calculeaza_discount(valoare, tip)` (`ofacturare.vc2:2602-2649`). -2. `do_calculeaza_discount` (`:1874-1976`) scrie in obiectul `poArticol`: - `poArticol.discount_unitar`, `discount_unitar_val`, `discount_unitar_ctva`, - `discount_unitar_ctva_val` (ex. `:1898-1906`, `:1943-1951`). -3. La revenirea in `do_adauga_articol` (`:12813-13086`), `poArticol` e scris in `crsfactura` prin - `Gather`/`Replace`: - ``` - 12956 Replace id_temp With Recno(), codmat With Nvl(poArticol.codmat, Space(50)), ; - ... - 12957 discountftva With poArticol.discount_unitar, discountctva With poArticol.discount_unitar_ctva, ; - vdiscountftva With Nvl(poArticol.discount_unitar_val, 0), vdiscountctva With Nvl(poArticol.discount_unitar_ctva_val, 0) - ``` - (linii `12956-12957`; varianta pentru selectie multipla de articole la `13003-13005`). -4. `discount_unitar` initial (inainte de tastare) e preluat din `crsarticole` (cursorul de stoc, - populat inainte de deschiderea dialogului) prin `do_initializeaza_articol` (`:13618` si urm.): - `toArticol.discount_unitar = Nvl(toArticol.discount_unitar, 0)` (`:13630`) — deci daca stocul / - politica de pret vine deja cu un discount populat, acela e valoarea implicita afisata in dialog, - pe care operatorul o poate suprascrie. -5. Cale suplimentara, directa: pe factura in valuta, cum `cVdiscountftva` e editabil in grid - (punctul 2), operatorul poate scrie si direct in celula `vdiscountftva` din `grd_factura` — dar - fara niciun `Valid`/`InteractiveChange` propriu definit pentru acea coloana in - `frm_facturare_articole` (cautat explicit `cVdiscountftva`/`cDiscountCTva` in intervalul - `10968-15739`: singurele hit-uri sunt definitiile de coloana si `RemoveObject`, niciun handler - de eveniment) — editarea directa in grid NU declanseaza recalcularea automata a - `vvaldiminuatftva`/totaluri, doar modifica valoarea bruta in `crsfactura`. - -## 4. Structura reala a coloanelor de discount pe VANZARI_DETALII - -**Concluzie**: nu exista un `CREATE TABLE VANZARI_DETALII` in `SCRIPTURI_CLAR` (arhiva incepe din -2009, iar tabela exista deja atunci — coloana `DISCOUNT_UNITAR` era deja in uz in pachete PL/SQL -din 2009, deci a fost creata inainte de arhiva). Singura coloana de discount pe -`VANZARI_DETALII`/`VANZARI_DETALII_TEMP` gasita in `SCRIPTURI_CLAR` e **`DISCOUNT_UNITAR`**, si -singura modificare de tip/precizie inregistrata e cea din 2024. - -**Dovezi (cronologic, tot ce am gasit cu `DISCOUNT` in contextul acestei tabele)**: -- Nu exista niciun `CREATE TABLE VANZARI_DETALII` sau `ALTER TABLE VANZARI_DETALII ADD DISCOUNT...` - in toata arhiva `SCRIPTURI_CLAR` (2009-2026). Cel mai vechi hit pe `DISCOUNT_UNITAR` legat de - aceasta tabela e o declaratie de variabila `V_DISCOUNT_UNITAR VANZARI_DETALII.DISCOUNT_UNITAR%TYPE` - in pachetul `PACK_FACTURARE`, prezenta deja in scripturile din 2009 (ex. - `2009\9\ff_2009_09_03_01_FACTURARE_PACK_FACTURARE.sql`) — coloana exista deja atunci. -- Singura modificare de precizie gasita: `ff_2024_06_13_02_COMUN_FACTURARE.sql:3` — - `alter table VANZARI_DETALII modify discount_unitar NUMBER(22,6);` — si simetric pentru - `VANZARI_DETALII_TEMP` la linia `:9`, si pentru `CRM_POLITICI_PRET_ART` (tabela de **politici de - pret**) la linia `:16`. Deci forma finala confirmata: **`DISCOUNT_UNITAR NUMBER(22,6)`**, o - singura coloana de discount (valoare, nu procent), identica pe toate cele 3 tabele. -- Nu exista alte coloane `DISCOUNT%`/`VDISCOUNT%` la nivel Oracle pe `VANZARI_DETALII` — cele patru - campuri VFP `discountftva`/`discountctva`/`vdiscountftva`/`vdiscountctva` din `crsfactura` NU au - corespondent 1:1 in schema Oracle; la scriere (`Gather`/`Replace` in `do_adauga_articol`, punctul - 3) doar `discount_unitar` (si varianta cu TVA calculata din el) ajunge, prin campurile - intermediare, la coloana unica Oracle. -- Convenția de interogare a bazei de dezvoltare, gasita in `COMUN\docs\scripturi-migrare-db.md:36-40`: - sursa de referinta pentru DDL e schema de dezvoltare **`MARIUSM_AUTO`** (bazata pe - `ROA_CENTRAL`), interogata prin `goExecutor`, niciodata o schema de client. Nu am rulat nimic pe - baza — doar raportez conventia, asa cum a cerut sarcina. - -## 5. Coloana de procent de discount pe VANZARI_DETALII / campul procdisc - -**Concluzie**: **nu** exista o coloana de procent de discount pe `VANZARI_DETALII` (doar -`DISCOUNT_UNITAR`, o valoare absoluta). Campul `procdisc` din `frm_facturare_articole2` e doar un -camp de lucru in grid, **fara nicio scriere in cursorul local si fara corespondent Oracle** — -practic un camp scaffolded si neconectat. - -**Dovezi**: -- Cautare `DISCOUNT`+`PROCENT`/`PROC` in `ff_2024_06_13_02_COMUN_FACTURARE.sql` (scriptul care - fixeaza forma finala a coloanelor de discount): nicio potrivire — confirma ca nu exista un - "procent discount" ca si coloana pe `VANZARI_DETALII`. -- `procdisc` apare **o singura data** in tot `ofacturare.vc2`: `Column14.ControlSource = "procdisc"` - la `:16721`, in interiorul clasei `frm_facturare_articole2` (`15741-19355` — prototip, nu - formularul in productie). -- Nicio instructiune `Gather`/`Replace ... procdisc With ...` in tot fisierul (cautat pe tot - `ofacturare.vc2`) — camp fara sursa de populare in cod. -- Toate celelalte aparitii de "procdisc" din fisier sunt de fapt variabila de memorie - `gnMemProcDisc` ("memorare procent discount" — o optiune de aplicatie care controleaza daca - procentul de discount tastat se retine intre articole, `:2299`, `:2441`, `:12835` etc.), fara - legatura cu campul de cursor `procdisc`. -- Cautare `PROCDISC` in `SCRIPTURI_CLAR`: doar 2 hit-uri, ambele in scripturi din 2015 pentru - tabela de **optiuni firma** (`co_2015_12_09_01_OPTIUNI.sql`, `ff_2015_12_09_01_OPTIUNI.sql`) — - legate de aceeasi optiune `gnMemProcDisc`, nu de `VANZARI_DETALII`. - -## Ce era gresit in afirmatiile de mai sus - -- Formularea "linia 3, 9, 16" pentru coloana Oracle `DISCOUNT_UNITAR` grupa laolalta 3 tabele - diferite (`VANZARI_DETALII` la `:3`, `VANZARI_DETALII_TEMP` la `:9`, `CRM_POLITICI_PRET_ART` la - `:16`) ca si cum ar fi acelasi lucru repetat de 3 ori — corect ca valoare (toate devin - `NUMBER(22,6)`), dar sunt 3 tabele distincte, nu 3 confirmari ale aceleiasi coloane. -- Cea mai importanta corectie: linia indicata pentru "de unde se scrie discountctva/vdiscountftva - — din `do_calculeaza_discount` (`ofacturare.vc2:13405-13424`)" trimite la metoda gresita. - `frm_facturare_articole.do_calculeaza_discount` de la acea linie calculeaza discountul **global - pe factura** (`Thisform.ndiscfactron`/`ndiscfactval`), nu discountul pe linie. Metoda care chiar - calculeaza `discount_unitar`/`discount_unitar_ctva` (sursa reala pentru `discountctva` si - `vdiscountftva`) e **`frm_articol_factura.do_calculeaza_discount`**, o metoda cu acelasi nume dar - in alta clasa, la `ofacturare.vc2:1874-1976`. Cele doua metode au nume identic dar apartin la - doua clase diferite din acelasi fisier — o capcana reala de grep fara indexul de simboluri. - -## Necunoscute ramase - -- Nu am verificat daca `crsarticole` (cursorul de stoc din care pleaca `poArticol.discount_unitar` - la `do_initializeaza_articol:13630`) e populat vreodata cu un discount nenul direct dintr-o - interogare de politica de pret (`CRM_POLITICI_PRET_ART`) inainte de a ajunge in dialogul - `frm_articol_factura` — am gasit doar ca acea tabela are aceeasi coloana `discount_unitar` - (`NUMBER(22,6)`), nu am urmarit interogarea SQL efectiva care umple `crsarticole`/`crsartselectate` - (cod probabil in `Programe/`, in afara `ofacturare.vc2`, netrasat din lipsa de timp alocat). -- Nu am confirmat pe date reale (Oracle) daca exista astazi randuri cu `DISCOUNT_UNITAR` populat pe - `VANZARI_DETALII` provenind din editarea directa in grid pe factura in valuta (punctul 2/3, - ultimul paragraf) — doar am aratat ca acea cale exista in cod, fara handler de recalcul. -- Nu am cautat daca `frm_facturare_articole2` (prototipul) e instantiat undeva in productie sau e - cu adevarat mort/nefolosit — task-ul l-a framat deja ca "prototip" si am pastrat presupunerea. diff --git a/docs/cercetare/ff_view_articole_vanzare.sql b/docs/cercetare/ff_view_articole_vanzare.sql deleted file mode 100644 index abf328c..0000000 --- a/docs/cercetare/ff_view_articole_vanzare.sql +++ /dev/null @@ -1,35 +0,0 @@ --- 08.08.2026 Marius Mutu --- VVANZARI_ARTICOLE: liniile unei vanzari (VANZARI_DETALII) cu denumirea articolului, a gestiunii --- si a valutei, pentru gridul de articole din formularul de modificare a notei. Valori brute, fara --- conversie valutara si fara calcule - editarea scrie inapoi exact ce a citit. Filtrul STERS ramane --- pe seama apelantului, ca la VACT_TOT / VRUL_TOT / VRUL_OBINV_TOT. - -CREATE OR REPLACE VIEW VVANZARI_ARTICOLE AS -select vd.id_vanzare, - vd.id_vanzare_det, - vd.id_articol, - vd.cantitate, - vd.pret, - vd.pret_cu_tva, - vd.proc_tvav, - vd.discount_unitar, - vd.id_gestiune, - vd.cont, - vd.id_valuta, - vd.id_jtva_coloana, - vd.serie, - vd.explicatie, - vd.taxcode, - vd.lot, - vd.sters, - na.denumire, - na.codmat, - ng.nume_gestiune, - nv.nume_val - from vanzari_detalii vd - left join nom_articole na on na.id_articol = vd.id_articol - left join nom_gestiuni ng on ng.id_gestiune = vd.id_gestiune - left join nom_valute nv on nv.id_valuta = vd.id_valuta; - -exec pack_migrare.UpdateVersiune('ff_2026_08_08_01_COMUN_VVANZARI_ARTICOLE'); -commit; diff --git a/docs/cercetare/handoff_propr_custom.md b/docs/cercetare/handoff_propr_custom.md deleted file mode 100644 index c9a50ce..0000000 --- a/docs/cercetare/handoff_propr_custom.md +++ /dev/null @@ -1,103 +0,0 @@ -# Predare — deblocarea proprietatilor custom pe frm_modific2024 - -Bloc de lucru TERMINAT CU SUCCES (nu la prag de context — predare la incheierea blocului, -conform Regula zero). - -## Concluzie - -**Ipoteza principala ("FoxBin2Prg Prg2Bin nu poate crea proprietati noi intr-un .vcx") e -INFIRMATA**, cu dovada directa (test izolat, mai jos). Cauza reala era alta, si s-a reparat. - -## Cauza reala, cu dovada - -Proprietatile noi (`larearticolevanzari`, `nidvanzare`, `ntipvanzare`) fusesera adaugate de -agentul anterior **doar** in blocul `*` (valorile), dar **lipseau din -`*`** (lista `*p:` care inregistreaza o proprietate custom ca membru real -al clasei). Fara intrarea `*p:`, `Prg2Bin` scrie linia de valoare, dar VFP n-o materializeaza ca -proprietate pe obiect — de-asta `PEMSTATUS` intorcea `.F.` desi valoarea aparea in text si -supravietuia fidelity-check-ului (fidelity-ul verifica doar ca textul regenerat == textul editat, -nu ca proprietatea exista pe obiect). - -Regula era deja documentata **pentru metode** in `COMUN\docs\flux-editare-vfp-text.md:76-78` -("Metoda noua de clasa cere `*m: nume` in `*`; fara ea, ... o arunca -tacut") — se aplica identic si proprietatilor (`*p:`), doar ca nu era scrisa explicit acolo. De -adaugat separat in acel fisier (nu am facut-o eu, e in afara sarcinii primite). - -## Testul izolat care a transat ipoteza - -Nu am atins `omodificari` pentru test. Am copiat `COMUN\clase\_pf_base.vcx/.vct/.vc2` (clasa -`_pfbase`, fara nicio importanta) intr-un folder complet izolat in scratchpad, am adaugat text-only -o proprietate noua (`ltestpropnoua`) cu intrare `*p:` corecta, write-back cu `txt2vcx.ps1` (proiect -izolat, nu ProjectRoot real), apoi `CREATEOBJECT` + `PEMSTATUS`: - -``` -PEMSTATUS(ltestpropnoua)=DA valoare=.T. -``` - -Confirma ca fluxul text->bin **poate** crea proprietati noi, cand sunt inregistrate corect. - -**Bonus gasit tot in acest test**: FoxBin2Prg foloseste o colatie unde `_` sorteaza **dupa** -literele obisnuite (nu ordine ASCII simpla pe litere mici) — `nidvanzare` < `nid_set` alfabetic -pentru tool, desi `'_' (0x5F) < 'v' (0x76)` in ASCII brut pe litere mici. Confirmat printr-un al -doilea test izolat: am scris `*p: nid_set` inaintea lui `*p: nidvanzare` (ordine ASCII) — fidelity -check a **picat** cu exact acest motiv; textul canonic din `\verify\` a aratat ordinea -corecta, `nidvanzare` inaintea lui `nid_set`. Coincide cu ordinea deja existenta, corecta, din -`*`-ul real al lui `frm_modific2024`. De adaugat in `flux-editare-vfp-text.md` / -`foxbin2prg\CLAUDE.md` ca nota separata (nu am facut-o, in afara sarcinii primite). - -## Ce am schimbat in `omodificari.vc2`/`.vcx`/`.vct` - -`COMUN\clase\omodificari.vc2`, clasa `frm_modific2024` (`:6375-15856`), blocul -`*` — 3 linii `*p:` noi, in ordine alfabetica (colatia tool-ului): -- `*p: larearticolevanzari` — linia 6804 (inainte de `lavertizatexigibilizare`) -- `*p: nidvanzare` — linia 6811 (inainte de `nid_set`) -- `*p: ntipvanzare` — linia 6818 (dupa `ntaxcode`) - -Blocul `*` **nu a fost atins** — valorile erau deja acolo, deja in ordinea corecta, -de la agentul anterior. - -Write-back real cu `txt2vcx.ps1 -AllowComun` — **fidelity check OK**. Backup pastrat: -`COMUN\clase\omodificari.vc2.pre_proprietati_custom.bak` (starea dinainte de aceasta reparatie, -distinct de `.pre_s4runda1.bak` mai vechi). - -**Capcana pe care am picat-o si am reparat-o singura**: prima incercare a folosit -`$lines.IndexOf(text_exact)` ca sa gasesc pozitia liniilor `*p:` tinta — a gasit o potrivire -falsa mult mai devreme in fisier (alta clasa cu proprietati cu nume asemanator), inserand 3 linii -in locul gresit. Am restaurat din backup **inainte** de a rula orice write-back cu starea gresita, -am refacut editarea cu index-uri de linie verificate explicit (assert pe continutul exact al -liniei), si abia apoi am scris pe disc. Fisierul de pe disc e curat, o singura editare corecta. - -## Verificare finala — PASS complet - -`test_page3_articole.prg` sub `watchdog_vfp.ps1 -AutoDismiss`: exit 0, 0 dialoguri. - -``` -cod=1140888: PageCount = 3 (asteptat 3), lAreArticoleVanzari = .T. (asteptat .T.), nIdVanzare = 1050 -> PASS -cod=1125486: PageCount = 2 (asteptat 2), lAreArticoleVanzari = .F. (asteptat .F.) -> PASS -``` - -Toate celelalte asertii din suita (verifica_vanzare_nota x3, verifica_coliziune_cod) tot PASS, -neschimbate. `PEMSTATUS(loForm,'lAreArticoleVanzari',5)` si `PEMSTATUS(loForm,'nIdVanzare',5)` -acum `.T.` (erau `.F.` la predarea anterioara). - -## Starea la predare - -- **Fara commit git/SVN.** `svn status` pe COMUN arata `M` pe `omodificari.vcx`/`.VCT` (write-back - real); `.vc2` e `I` (ignorat de SVN, urmarit doar de `comun.git`). -- `comun.git status` arata `omodificari.vc2` modificat — diff-ul cumuleaza **toata munca - necomisa de azi pe S4 runda 1** (PAGE3, grid, cele 3 proprietati), nu doar reparatia mea; nimic - neasteptat. -- **Fara tranzactii Oracle deschise** — testul de verificare face doar `SELECT`-uri prin - `goExecutor`, zero scriere. -- **Niciun proces `vfp9.exe` ramas viu** (verificat, `Get-Process vfp9` gol). -- Scratch-ul de test izolat (`_pf_base.vcx` copiat) a ramas doar in - `C:\Users\...\scratchpad\testproj\` — in afara working copy, nu necesita curatare. - -## Ce ramane (in afara sarcinii primite azi) - -Pasii 3-5 din `docs\progres.md` sectiunea „#6, S4 runda 1": scoaterea liniilor `[BISECT]`/`[DIAG]` -din test, stergerea `test_baseline_isolation.prg` (concluzia lui e nula, vezi handoff anterior), -scrierea `docs\diff_s4_runda1_page3.patch` + `docs\cercetare\rec_s4_runda1.md`, actualizarea -`COMUN\docs\testare-ui-vfp.md` cu cele trei capcane noi (`DO...WITH` prin referinta, `SET PATH` -ROACONT, watchdog fara input real) **plus** cele doua descoperite acum (`*p:` obligatoriu si -pentru proprietati, colatia cu `_` dupa litere) — raman pentru runda urmatoare. diff --git a/docs/cercetare/handoff_s4_runda1.md b/docs/cercetare/handoff_s4_runda1.md index 9361b47..3bc124f 100644 --- a/docs/cercetare/handoff_s4_runda1.md +++ b/docs/cercetare/handoff_s4_runda1.md @@ -185,7 +185,7 @@ sesiune doar pentru asta). alta depanare GUI. 3. Daca se rezolva: reruleaza `test_page3_articole.prg` complet, confirma PASS pe toate cazurile (inclusiv `verifica_pagecount_form`), sterge `test_baseline_isolation.prg` + `.fxp` + log-ul lui, - scrie diff-ul (`docs\diff_s4_runda1_page3.patch`, `git diff --no-index `) si + scrie diff-ul (diff aplicat (sters), `git diff --no-index `) si raportul (`docs\cercetare\rec_s4_runda1.md`) cerute initial de team-lead. 4. Daca team-lead sau alt agent scrie capcana "View Parameter / LOCAL vs PRIVATE" in `testare-ui-vfp.md`, nu o duplica — team-lead a intrebat explicit cine o scrie. diff --git a/docs/cercetare/handoff_test_writeback.md b/docs/cercetare/handoff_test_writeback.md deleted file mode 100644 index 3631c29..0000000 --- a/docs/cercetare/handoff_test_writeback.md +++ /dev/null @@ -1,121 +0,0 @@ -# Handoff — test real write-back buton=1 (do_editare_factura) - -Predare la prag de context, conform Regula zero din `CLAUDE.md`. Fara analiza noua aici, doar -starea. - -## CORECTIE IMPORTANTA fata de ce stie team-lead acum - -Team-lead a verificat baza INAINTE de ultima rulare si a raportat "`id_vanzare=1048` e neatins, -nimic de curatat". **Nu mai e adevarat** - intre timp corectia `LOCAL` -> `PRIVATE` a fost aplicata -SI rulata, iar testul **a reusit complet, cu COMMIT real, de doua ori**. Documentul `id_vanzare=1048` -**a fost modificat legitim**, exact cum era scopul aprobat de Marius: - -- `cod` a trecut `1140886` -> `1140893` (TEST 1, salvare fara modificari) -> `1140894` (TEST 2, - cu explicatia unui rand `ACT` modificata: "NOTA 1" -> "NOTA 1 (test writeback)"). -- **Cod-ul curent activ in baza pentru acest document este `1140894`**, nu `1140886`. -- Randurile vechi (`cod=1140886` si `cod=1140893`) raman in `ACT`/`RUL` cu `STERS=1` - asta e - comportamentul normal, prin design (vezi "Fapte stabilite" din `docs\progres.md`). -- `VANZARI.total_cu_tva`/`total_fara_tva`/`total_tva`/`id_fact`/`sters` au ramas neschimbate, - verificat si din log VFP si independent prin `sqlplus` dupa rulare. -- `VANZARI_DETALII` a ramas neatins (verificat, cum era de asteptat pe aceasta cale). - -**Raport complet deja scris**: `docs\cercetare\rec_test_writeback.md` (tabel cu cele 5 verificari -pe ambele teste, PASS pe toate, plus istoricul celor 2 incidente si cum s-au rezolvat). Rezultatul -a fost deja trimis catre team-lead prin mesaj ("PASS complet pe ambele teste, commit real -confirmat independent") - posibil incrucisat cu mesajul lui de STOP. - -## 1. Starea fisierului de test - -`COMUN\utile\Teste\editare_factura\test_writeback_buton1.prg` (ultima modificare azi, 08.08.2026). - -- **Corectia `LOCAL` -> `PRIVATE` (linia ~133, acum ~149-153): DA, APLICATA.** Declararea curenta: - ```foxpro - PRIVATE pnAn, pnLuna, lnCod, lnIdFact - LOCAL lnSters, llEProforma - LOCAL lnIdSet, lnIdFactD, lnSucces, llGasitRand - ``` - (restul variabilelor de test raman `LOCAL`, corect - nu sunt folosite ca bind `?` in SQL). -- `frm_modific2024` e ocolit COMPLET (nu se mai instantiaza deloc) - s-a blocat de doua ori - headless (a se vedea sectiunea 3) si s-a decis cu team-lead sa fie scos din harness. `buton=1` - e fortat direct in cod, `inainte_de_do_termin` NU se executa. - `Thisform.do_deschide_tranzactie`/`do_inchide_tranzactie` sunt reproduse inline in fisier - (`MyDeschideTranzactie`/`MyInchideTranzactie`, copiate dupa `_frm_base.vc2:252-302`). -- `PUBLIC gcMockUltimMesaj, gnMockUltimTip` + logare `goExecutor.cEroare` dupa fiecare pas: DA, - adaugate (procedura `LogMockSiEroare`, apelata dupa fiecare `OSCRIE_IN_FISIERE` si dupa - `finalizeaza_modificare_nota`). -- Logare granulara `[chk]` inainte/dupa fiecare sub-pas din ramura `buton=1`: DA, adaugata. -- **Fisierul e in stare FINALA, functionala - nu mai necesita nicio corectie pentru scopul cerut.** - Orice rulare viitoare pe acest script trebuie sa citeasca `cod`-ul curent din `VANZARI` (nu - presupune `1140886`), pentru ca scriptul insusi face asta (interogheaza `VANZARI` la inceputul - fiecarui apel al procedurii `test_editare_writeback`). - -## 2. Comanda exacta de rulare - -```powershell -$testPrg = 'D:\ROA\ROAFACTURARE\COMUN\utile\Teste\editare_factura\test_writeback_buton1.prg' -Start-Process 'C:\Program Files (x86)\Microsoft Visual FoxPro 9\vfp9.exe' -ArgumentList '-A','-T',"`"$testPrg`"" -PassThru -``` - -Log: `D:\ROA\ROAFACTURARE\COMUN\utile\Teste\editare_factura\test_writeback_buton1_log.txt` -(suprascris de la zero la fiecare rulare - `STRTOFILE(..., lcLog)` fara `,1` pe prima linie). - -Inainte de orice rulare: verifica sa nu existe deja un `vfp9.exe` activ -(`Get-CimInstance Win32_Process -Filter "Name='vfp9.exe'"`) si sterge `.FXP`/`.ERR`/log vechi din -acelasi folder. - -## 3. Ce s-a stabilit deja (nu se reia) - -- Prima varianta a testului instantia `frm_modific2024` (modeless, `WindowType=0`, ca in - `test_page3_articole.prg`) - s-a blocat de doua ori, headless, fara nicio linie de eroare in - log: prima data pe un dialog nativ Windows **"Open"** (`#32770`, confirmat prin - `EnumWindows`/`GetWindowText` pe procesul viu), a doua oara (dupa ce s-a scos `frm_modific2024` - si inainte de corectia `PRIVATE`) pe un dialog **nativ VFP "View Parameter"** ("Enter the value - for pnLuna"), confirmat de captura de ecran trimisa de Marius si de `EnumWindows` local. -- **Ipoteza "backupset" (clasa `BackupXML`, `oproceduri_comune.prg:3685-3987`) respinsa**: foloseste - doar `CREATE CURSOR`/`Cursortoxml`/`Delete File`, niciun `USE` pe tabela lipsa; si oricum prima - rulare (cea cu `-1`) trecuse deja prin acelasi cod fara sa se blocheze. -- **Cauza reala a dialogului "View Parameter"**: `pnAn`/`pnLuna` erau declarate `LOCAL` in harness, - in loc de `PRIVATE` ca in codul real (`ofacturare_comun.vc2:3742`). `PRIVATE` le face vizibile - in josul stivei de apel, unde `goExecutor.oExecuta` rezolva bind-urile `?pnLuna`/`?pnAn` din - apelul catre `pack_contafin.finalizeaza_modificare_nota`. Cu `LOCAL`, VFP nu le gasea si deschidea - dialogul nativ de introducere manuala - niciodata catchabil prin `ON ERROR`/`TRY`/mock de - `amessagebox` (nu e un `AMESSAGEBOX`, e un mecanism VFP intern). -- **Dupa corectie (`PRIVATE`), ambele teste au trecut curat, cu COMMIT real** - vezi "CORECTIE - IMPORTANTA" de mai sus si `docs\cercetare\rec_test_writeback.md` pentru tabelul complet. -- Inainte de corectie, o rulare intermediara aratase `OSCRIE_IN_FISIERE(2,.T.,.T.) => -1` (esec - curat, cu ROLLBACK, fara nicio scriere) - **acel `-1` nu s-a mai reprodus dupa corectia - `PRIVATE`** (ambele `OSCRIE_IN_FISIERE` au intors `1` in rularea finala). Motivul exact al lui - `-1` din acea rulare intermediara **ramane neexplicat definitiv** (posibil efect secundar al - aceleiasi probleme de scope, posibil altceva) - nu mai e relevant, testul final a trecut, dar - daca reapare vreodata pe alt document, `gcMockUltimMesaj`/`goExecutor.cEroare` sunt deja logate - dupa fiecare pas. - -## 4. Ce e interzis (neschimbat) - -- Nu mock-ui `OSCRIE_IN_FISIERE`. -- Nu modifica codul aplicatiei (`ofacturare_comun.vc2`, `oscrie_in_fisiere.prg`, - `omodificari.vc2` etc.) - niciun bug de aplicatie n-a fost gasit, toate problemele au fost in - harness. -- Nu folosi `cod=1140888` / `cod=1140885` (baze de regresie ale `test_incarca_cursoare.prg`). -- Nu rula `git_sync.ps1` si nu atinge `omodificari.vc2`/`.vcx` (alt agent lucreaza in paralel pe - PAGE3, task separat). - -## 5. Starea datelor - vezi CORECTIA de la inceputul fisierului - -Pe scurt: `id_vanzare=1048` a fost editat legitim de doua ori prin testul aprobat. `cod` curent = -`1140894`. Nimic de reparat sau de facut rollback - e rezultatul dorit al testului. Daca se doreste -un test suplimentar pe alt document, se alege un `cod`/`id_vanzare` nou (nu `1140886`/`1140888`/ -`1140885`). - -## 6. Fisiere temporare - -Nimic de sters in working copy. `test_writeback_buton1.FXP` si `test_writeback_buton1_log.txt` -din `COMUN\utile\Teste\editare_factura\` sunt artefacte normale, in acelasi tipar cu -`test_incarca_cursoare.FXP`/`test_page3_articole.FXP` deja existente in acel folder (folder de -teste, neurmarit ca binare in git). Fisierele de diagnostic SQL folosite pentru verificarea -independenta au fost in scratchpad-ul de sesiune (`C:\Users\...\Temp\claude\...\scratchpad\`), in -afara working copy - nu necesita curatare de catre urmatorul agent. - -Un fisier `test_baseline_isolation.prg`/`.FXP`/`_log.txt` exista in acelasi folder, creat inainte -de aceasta sesiune si NU de agentul curent - probabil al agentului paralel de pe alta sarcina; nu -l-am atins. diff --git a/docs/cercetare/handoff_watchdog_vfp.md b/docs/cercetare/handoff_watchdog_vfp.md deleted file mode 100644 index 7dc67f8..0000000 --- a/docs/cercetare/handoff_watchdog_vfp.md +++ /dev/null @@ -1,127 +0,0 @@ -# Handoff — watchdog VFP + bisectie blocaj "View Parameter" gnAn - -Predare la peste 310k context (Regula zero). **Doar stare, fara analize noi.** Raport analitic -complet (dovezi, log-uri, discutie): `docs\cercetare\rec_watchdog_vfp.md`. - -## 1. Inventar livrabile, cu fisier:linie - -**Utilitar**: `D:\ROA\ROAFACTURARE\COMUN\utile\Teste\watchdog_vfp.ps1`. Linia de comanda completa: - -``` -powershell -ExecutionPolicy Bypass -File "D:\ROA\ROAFACTURARE\COMUN\utile\Teste\watchdog_vfp.ps1" -Script "" -TimeoutSec 90 -AutoDismiss -MaxDialogs 10 -``` - -Lanseaza `vfp9.exe -A -T "