Files

Marius Mutu b5a7108f34 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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3

2026-08-11 22:31:42 +03:00

5.4 KiB

Raw Blame History

S9 — documentatia fluxului de editare a facturii, adaugata in flux-modificare-stergere-nota-jurnal.md

Fisier editat: D:\ROA\ROAGEST\COMUN\docs\flux-modificare-stergere-nota-jurnal.md. Diff salvat: diff aplicat (sters). Nimic comis (nici git, nici SVN) - COMUN e dublu-versionat SVN+git, git stash acolo e interzis; nu s-a folosit.

Ce s-a adaugat si unde

Doua sectiuni noi, dupa ## Atentie: nu e valabil la fel pentru stergerea simpla si inainte de ## Implicatii practice:

## Ramura noua: editare factura de vanzare (VANZARI/VANZARI_DETALII) - conditia de activare, cele doua puncte de intrare cu garzile lor, secventa de scriere in tranzactia manuala, contractul lui ScrieArticoleFacturaEditate, procedura Oracle de recalcul, view-ul sursa, si comportamentul gridului de articole (editabilitate per linie, stergere logica, validari la inchidere).
Doua bullet-uri noi in ## Implicatii practice, in continuarea listei existente.

Din ce fisiere vine fiecare afirmatie

Cele doua puncte de intrare si garzile lor: COMUN\clase\ofacturare_comun.vc2:3715-3872 (do_editare_factura - garzi la :3742-3768, incarcare articole la :3793, agatare la :3828-3830) si COMUN\clase\comun.vc2:2222-2567 (do_modifica - luna curenta :2265-2268, pregatire articole :2435-2437, agatare :2491-2493). Verificat explicit ca EsteInEFactura si ReferinteDocumenteNota nu apar in comun.vc2 (grep pe fisier, zero rezultate) - de-aia afirmatia ca garda eFactura/referinte exista doar pe punctul din ROAFACTURARE.
Inregistrarea ofacturare_editare.prg in toate trei aplicatiile: grep confirmat separat in ROAFACTURARE\Programe\roafacturare.prg:214, ROACONT\Programe\roacont.prg:212, ROAGEST\Programe\roagest.prg:260 - toate cu SET PROCEDURE TO ofacturare_editare.prg ADDITIVE.
Helperele: COMUN\programe\ofacturare_editare.prg citit integral. EsteInEFactura (:16-25), PregatesteArticoleFacturaEditare (:332-348), IncarcaVanzareDinNota/IncarcaArticoleFactura (:161-324), ScrieArticoleFacturaEditate (:468-555, cei 4 pasi citati din corpul functiei).
Formularul: COMUN\clase\omodificari.vc2 - Load (:14645-14682), Show (:14731-14814, in special :14769-14794 pentru decizia PageCount), validarile din inainte_de_do_termin (:14282-14387), gridul grdArticoleFactura (definitia coloanelor :12320-..., caption PAGE3 :8707), handlerele When/Valid pe cCantitateArt/cPretArt/ cPretAchizitieArt/cPretCuTvaArt (:16519-16566) si cmdStergeArticol.Click (:16508-16517).
Oracle: D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\08\ff_2026_08_09_01_COMUN_PACK_FACTURARE.sql (recalculeaza_totaluri_vanzari, :16023-16228, citit integral - coloanele scrise, agregarea pe linii proprii si pe seturi, coloanele de incasare neatinse) si ...\ff_2026_08_09_02_COMUN_VVANZARI_ARTICOLE.sql (view-ul, citit integral).

Ce am lasat deliberat afara

Totalurile de control / verdictul ACT-RUL (ActualizeazaBaraTotaluri, ActualizeazaVerdictActRul, omodificari.vc2:12966-13105) - exista in cod si e parte din S4b, dar e o functionalitate de afisare/avertizare, nu parte a fluxului de stergere-scriere-realiniere pe care il documenteaza fisierul tinta. L-am scos ca sa nu ingreunez sectiunea cu un subiect distinct (planul cere explicit doar "ramura de facturi" pe fluxul de modificare/stergere).
Actiunea de sincronizare cu enumerarea liniilor vechi->noi - nu exista inca in cod (S4b partial, per handoff intermediar (sters)), n-am documentat ceva nelivrat.
Eticheta text "linie din set" - handoff-ul S5 o mentioneaza, dar in cod (grep pe omodificari.vc2) nu exista un literal cu acest text; marcajul e doar vizual, prin DynamicForeColor (culoare distincta). Am scris "culoare distincta", nu "eticheta", ca sa nu inventez un text care nu exista.
Drepturile (tokenul "3", lactiv3) - documentul tinta nu discuta permisiuni pentru niciun flux existent (nici stergerea, nici modificarea simpla), asa ca am pastrat consistenta si n-am adaugat-o nici pentru factura.
nom_lucrari/gest_inventar/atasamente_vanzari din finalizeaza_modificare_nota - deja documentate mai sus in fisier (sectiunea "Unde"), n-am repetat.

Intrebari deschise

Asimetria de garzi intre cele doua puncte de intrare e by design sau gap de acoperit? do_editare_factura (ROAFACTURARE) verifica eFactura si referinte de incasari/plati; do_modifica (Registrul Jurnal, comun tuturor notelor) nu le verifica deloc - doar restrictia generica de luna curenta. Codul confirma asta explicit (am citit ambele metode integral), dar nu pot spune din documentatie daca e o omisiune ramasa din S1 sau o decizie asumata (planul spune doar ca "garzile trebuie sa fie in formular sau in codul comun", fara sa specifice care cale trebuia sa le primeasca). Am documentat faptul, nu l-am calificat drept bug.
Eticheta "linie din set" mentionata in handoff intermediar (sters) (decizia 39) nu exista ca text in cod la verificare - posibil ramasa doar la nivel de intentie sau inlocuita de marcajul de culoare in implementarea finala. N-am putut confirma din git log/istoric fara sa ies din scop; las-o ca discrepanta cunoscuta intre document de decizie si livrare.

Nu am atins niciun fisier de cod (.prg/.vc2/.sc2/.sql) si niciun alt fisier de documentatie in afara celui cerut.

5.4 KiB Raw Blame History