Marius Mutu
b5a7108f34
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
79 lines
5.4 KiB
Markdown
79 lines
5.4 KiB
Markdown
# 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`:
|
|
|
|
1. **`## 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).
|
|
2. 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
|
|
|
|
1. **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.
|
|
2. **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.
|