Cele trei fisiere erau pe disc, netrackuite, iar ce se stia despre ele traia
intr-un handoff intre sesiuni. Handoff-ul a fost desfiintat: ce era durabil a
intrat in antetul harnessului - plaja de serii care chiar prinde (FACTURA cere
gnIdUtil=8 cu gnIdSucursala=167, AVIZ merge si cu -3), faptul ca alocarea
consuma numere ireversibil chiar cand documentul nu se scrie, ordinea gresita
de incarcare a lui mock_amessagebox care e suspectul principal pentru agatari,
si riscul de curs EUR ramas neconfirmat pe cursor_contract.
Harnessul nu a scris inca niciun document cu succes - antetul spune asta
explicit, ca sa nu fie luat drept unealta functionala.
test_init_env_auto_roafacturare.prg e generic si folosit deja de alte suite:
seteaza gcNumeProgram=[ROAFACTURARE], fara de care garzile proprii fluxului de
facturare nu se declanseaza.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
Enumerarea diferentelor dintre rulaje si articole capata interfata: buton pe
pagina de articole, dialog cu grid si comutator de directie, plus verificarea la
salvare. Dialogul propune, nu decide - aplicarea ramane o apasare explicita.
- omodificari.vc2: cmdSincronizeazaArticole pe PAGE3, dezactivat odata cu restul
paginii cand documentul e blocat in eFactura; frm_sincronizare_articole,
derivata din frm_termin_renunt. Gridul e legat de propunere_afisata, cursor
stabil creat in Load si doar golit si reumplut - propunere_sincronizare se
recreeaza la fiecare apel, deci o legare directa s-ar rupe la prima comutare
de directie.
- id_articol trece de la I la N(20), in toate cele 6 locuri scrise pentru acest
punct. Restul codebase-ului foloseste dintotdeauna N(20): valorile reale trec
de 2^31 pe 89.8% din NOM_ARTICOLE, iar un camp I le trunchia tacit, asa incat
potrivirea pe id_articol cadea si iesea perechea Adaugare+Semnalare in locul
unei Modificari. Nu e o schimbare de design, e revenire la conventia casei.
- doua accesari This. in loc de Thisform. in Click-ul butonului de adaugare
articol: proprietatile sunt ale formularului, iar scurtcircuitul OR le
evalua exact cand documentul avea articole - orice click real dadea eroare.
- teste: test_s4b_dialog (35/0) acopera instantierea, comutarea directiei si
aplicarea la salvare; test_s4b_sincronizare (42/0) capata cazul id_articol
3598545102, care ar fi picat inainte de schimbarea de tip.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
Rulajele contabile si articolele facturii sunt doua reprezentari independente ale
aceluiasi document, editabile separat. Helperele noi construiesc enumerarea
diferentelor dintre ele si o pot aplica, la cererea utilizatorului.
- ConstruiestePropunereSincronizare: potrivire pe id_articol, singura cheie
comuna - nu exista corespondent la nivel de linie intre rulaj si articol.
Agregarea RUL foloseste pretul mediu ponderat cand un articol are mai multe
randuri. Articolele nestocate, documentele in valuta si articolele cu mai
multe randuri RUL active raman N-A, cu motiv afisat: propunerea ar fi o
presupunere, nu un calcul.
- AplicaSincronizareArticole: scrie doar in tvd/trul, in memorie. Nu adauga
randuri de rulaj (conturile nu se deduc din articol) si nu sterge linii in
nicio directie - divergenta se semnaleaza, stergerea ramane manuala.
Scrierea reala in Oracle ramane calea existenta, la salvare.
- test_s4b_sincronizare: headless, fara Oracle, pe cursoare construite in test.
Butonul, dialogul si verificarea la salvare vin separat.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
Cand documentul e deja trimis in eFactura, pagina de articole ramane vizibila,
dar needitabila: cantitate, pret, pret achizitie, flagul pret cu TVA, discountul
de antet, plus adaugarea si stergerea de linii. Alegerea e "vizibil, dar blocat",
nu "pagina ascunsa" - contabilul trebuie sa vada ce contine factura trimisa.
- omodificari.vc2: flag lArticoleReadOnly calculat in frm_modific2024.Show, impins
peste .When-urile de celula, peste Enabled si peste garda din Click-ul butoanelor,
si peste txtDiscountArt.ReadOnly. Eticheta lblArticoleReadOnly explica motivul.
- ofacturare_editare.prg: id_fact adus pe tvanz, in IncarcaVanzareNota si in
CreeazaCursorTvanzGol. EsteInEFactura interogheaza anaf_efactura dupa id_fact,
nu dupa id_vanzare - fara asta garda nu s-ar fi declansat niciodata pe date reale.
- teste: test_efactura_readonly (headless, garda in ambele sensuri),
test_ui_efactura_readonly (formular vizibil - coloanele gridului nu se
materializeaza sub -A -T), test_s7_rotunjire, si test_s8_matrice_surse pentru
matricea S8 pe tipuri de sursa.
S8 rulat pe cate un document din fiecare tip de sursa (lista de preturi, contract,
aviz, factura din aviz), fiecare editat din ambele puncte de intrare: notele vechi
raman STERS=1, id_fact nu se schimba, totalurile si liniile raman coerente.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
La salvarea unei facturi deja emise, modificarile facute liniilor de articole
se scriu acum real in VANZARI_DETALII, in aceeasi tranzactie cu restul salvarii,
si totalurile documentului se recalculeaza din liniile efectiv salvate.
- ofacturare_editare.prg: helper nou ScrieArticoleFacturaEditate. Idiomul e
"marcheaza tot sters, invie ce ramane", nu delta, pentru ca
actualizeaza_vanzari face UPDATE ... SET STERS = 0 pe tot documentul, fara
garda; o scriere delta ar lasa liniile sterse sa reinvie la fiecare salvare.
Cursor gol = no-op, ca o eroare la incarcare sa nu goleasca factura.
- comun.vc2, ofacturare_comun.vc2: agatarea apelului dupa
finalizeaza_modificare_nota si inainte de inchiderea tranzactiei, in ambele
puncte de intrare.
- omodificari.vc2: coloana Pret achizitie in grid, editabila doar pe liniile
noi; liniile de set devin needitabile, cu marcaj; cinci validari la salvare.
- teste: cinci suite noi (validari, grid UI, scriere reala, discount/valuta,
rollback, al doilea punct de intrare) si asteptari actualizate in
test_page3_articole.
- docs: oracle_export.md - exportul all_source cere linesize 32767, altfel
rupe liniile lungi prin mijlocul identificatorilor; scripturi-migrare-db.md -
UpdateVersiune adauga singur extensia .sql.
Cere scripturile ff_2026_08_09_01 (PACK_FACTURARE) si ff_2026_08_09_02
(VVANZARI_ARTICOLE).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
frm_modific2024, pgfArticole.PAGE3 - editare in memorie, fara scriere in Oracle
(aceea ramane S5).
- sub-blocul A: cantitate/pret/pret_cu_tva editabile inline, marcaj lmodificat
pe linie, coloana valoare pe linie
- sub-blocul B: stergere logica de linii (sters/DynamicForeColor gri) si adaugare
de linii prin frm_articol_factura, cu alegerea articolului prin caut_articol()
- sub-blocul C: bara de totaluri sub grid (total linii convertit RON la cursul
documentului, discount de antet editabil, total net), ascunsa pe
transfer/custodie; verdict de corelatie ACT/RUL informativ, cu 3 stari
- suma ACT: sold net debit-credit, cont pe tip de document (4111 / 418 / 461,
iar pe rate/contract 4111, 411 sau 461)
- suma RUL: doar ID_TIP_RULAJ = 0, adica miscarile reale; perechile
ID_TIP_RULAJ = 3 sunt virtuale (tin locul procesului verbal de schimbare de
pret) si nu intra in suma. Corectie cu liniile nestocate, marcata "ajustat"
- adaugarea de linii pe document in valuta: dialogul primeste tip_valuta si
cursul documentului de pe tvanz, deci pretul se introduce direct in valuta;
ofacturare.vc2 ramane neatins
- cei 5 apelanti frm_modific2024 (afisjurcom, anaf_efactura, cele doua .sc2 de
import) pregatesc cursorul de articole inainte de Createobject, gardat pe
SET PROCEDURE - registrul jurnal din ROACONT/ROAGEST ramane neschimbat
Teste headless pe MARIUSM_AUTO, suite care isi descopera singure documentele:
test_page3_articole 14/2 (cele 2 = artefact de grid nematerializat headless,
acoperit pe ecran), test_incarca_vanzare_din_nota 5/0,
test_adauga_linie_articol 20/0, test_adauga_linie_valuta 16/0,
test_ui_sterge_linie 8/0, test_verdict_act_rul 26/0.
docs/todos.txt: punctele 13 si 20, scrise de Marius.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
ofacturare_editare.prg (nou): helpere comune - garda eFactura, cursoarele
notei si ale rulajelor, randul de vanzare corespunzator notei si liniile de
articole citite din view-ul VVANZARI_ARTICOLE.
omodificari.vc2 (frm_modific2024): pagina noua de articole ale facturii,
deocamdata doar afisare. Apare numai cand ofacturare_editare.prg e
inregistrat si documentul are rand in VANZARI; in ROACONT si ROAGEST, unde
fisierul nu e incarcat, pagina lipseste si registrul jurnal ramane neatins.
Randul de vanzare al notei se cauta pe toate tripletele distincte (nract,
serie_act, dataact) din nota, pentru ca primul rand poate fi o incasare.
ofacturare_comun.vc2 (frm_facturi): do_editare_factura si butonul aferent,
dupa modelul lui do_sterge, cu garzile de luna inchisa, luna curenta,
document sters, referinte si eFactura.
docs: comentariile se scriu strict necesar, si in cod si in scripturile de
migrare - fara referinte la planuri, stories, decizii sau erori, istoricul
doar in antetul fisierului. Plus regula zero (predarea contextului),
capcanele de la testarea headless si completari pe fluxul text -> binar.
utile/Teste: suita de regresie pentru editarea facturii si harness-ul
watchdog (nu sunt in SVN, unde utile/Teste e ignorat). .gitignore ignora si
capturile PNG si watchdog_out/, ramase din rulari.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
