#13: formular de facturare unificat - etapa curenta
Squash al branch-ului de lucru plan13-s2. Cod: clasa noua ofacturare_util (geometrie si utilitare de formular), inrolata in roafacturare.prg; meniul "Facturare (nou)" plat, cu reparatia literalului peste limita VFP de 255 de caractere care impiedica compilarea metodei. Livrare: changelog 2.11.19, marcajul de versiune DB pentru scripturile finale din SCRIPTURI_CLAR\2026\09, inventarul livrarii in docs/livrare_13.md si registrul de erori deschise. Documentatia de lucru a etapei (cercetare, rapoarte, handoff-uri, snapshot-uri de scripturi si backup-uri de rollback) a fost scoasa din arbore. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PkyjGyrV2S7932om4kfSiK
This commit is contained in:
@@ -1,502 +0,0 @@
|
||||
# Cercetare + proiectare — S5: acoperirea tuturor tipurilor de document
|
||||
|
||||
Proiectare pe cod, READ-ONLY (fara editari, fara `git_sync.ps1`/`txt2vcx.ps1`, fara commit, fara
|
||||
scriere pe Oracle — numai `SELECT`), pentru povestea **S5** din
|
||||
`docs\plan_13_unificare_formular_facturare.md` (`#### S5`). Nu s-a atins
|
||||
`COMUN\clase\ofacturare_comun.vc2` si `COMUN\programe\ofacturare_editare.prg` (perimetrul altei
|
||||
sarcini in lucru) — doar citite cand au aparut in cautari (n-a fost cazul).
|
||||
|
||||
Sursa VFP: `COMUN\clase\ofacturare.vc2` (`frm_facturare_articole` = formularul de productie,
|
||||
`:10968-15739`; `frm_facturare_articole2` = prototipul, `:15741-19355` — **nu e subclasa** a
|
||||
primului, mostenesc separat din `_frmbase`, au `Init` propriu fiecare). Sursa de rutare:
|
||||
`COMUN\programe\ofacturare.prg` (`factureaza` = standard, `:81-...`; `factureaza2` = prototip,
|
||||
`:660-...`). Referinta de tipuri: `COMUN\docs\tipuri_documente_facturare.md`.
|
||||
|
||||
## Verdict (rezumat, citeste asta primul)
|
||||
|
||||
1. **`Do Case`-ul din `frm_facturare_articole.Init` (`ofacturare.vc2:15109-15248`) acopera 21 de
|
||||
valori de `tip`** (grupate in 14 ramuri): `1,2,3,4,5,6,7,8,9,10,21,22,23,24,25,26,28,29,41,42,47`.
|
||||
2. **Patru tipuri sunt reale, reachable prin `factureaza()`, dar nu apar in niciun `Case`** —
|
||||
pierd titlu, cap de coloana, mesaj de stoc, vizibilitate discount, eliminare `cSerie`: **`45`
|
||||
(factura restaurant), `48`/`49` (custodie cu/fara descarcare K), `52` (contract, factura fiscala
|
||||
valuta)**. Confirmat pe meniuri (`Meniuri\politica.mn2:18,26,29`, `Meniuri\contracte.mn2:18`) si
|
||||
pe rutarea cursorului (`ofacturare.prg:271-282`), care **le recunoaste** — doar Init-ul
|
||||
formularului de articole nu le-a "prins" niciodata. **Nu doar `52`**, cum semnalase raportul S4b —
|
||||
sunt patru, nu unul.
|
||||
3. **Cinci tipuri din referinta (`43,44,46,50,51`) nu sunt niciodata pasate lui `factureaza()`
|
||||
in tot arborele `D:\ROA`** (cautare exhaustiva, zero potriviri) — nu ajung la acest formular deloc
|
||||
azi. `50` e marcat explicit "in lucru" in sursa; `51` (ROAACNPRO) foloseste `id_set=50100`, un
|
||||
interval separat de restul (`25000+`), semn ca provine dintr-un flux Oracle direct al altui produs,
|
||||
nu din `factureaza()` local.
|
||||
4. **Descoperire centrala, dincolo de ce cerea misiunea**: prototipul (`frm_facturare_articole2.Init`,
|
||||
`:18988-19080`) **nu e o versiune partiala a Do Case-ului standard — e aproape gol**. Singurul
|
||||
lucru pe care-l face pe tip e sa aleaga cuvantul `lcTipDoc` ("factura" vs "aviz"), pe o lista
|
||||
**mai scurta** (lipseste `24`). Nu seteaza titlu (nu exista `lb_titlu_alb_b121` in tot fisierul
|
||||
prototipului), nu schimba capul coloanei de cantitate, nu schimba mesajul de stoc, nu ascunde
|
||||
discountul, **nu are deloc conceptul de coloana `cSerie`** (gridul prototipului, `grd_factura`,
|
||||
n-are niciodata `RemoveObject('cSerie')` — cautare pe tot fisierul, zero potriviri in intervalul
|
||||
`15741-19355`). Daca formularul unificat porneste de la prototip (cum indica decizia de baza a
|
||||
planului), **toata diferentierea pe tip trebuie reconstruita de la zero**, nu doar completata.
|
||||
5. **Rutarea cursorului diverge intre standard si prototip pe trei tipuri, nu doua**: `23`
|
||||
(confirmat deja de S4/S4b), plus **`52` si `24`, gasite aici** — pe prototip, `Case Inlist(tnTip,
|
||||
2, 26, 6)` (`ofacturare.prg:762`) **omite `52`** fata de standard (`Inlist(tnTip, 2, 26, 6, 52)`,
|
||||
`:283`), si `Case Inlist(tnTip, 8, 9)` (`:819`) **omite `24`** fata de standard (`Inlist(tnTip, 8,
|
||||
9, 24)`, `:307`). Daca cineva ar factura tip `52` sau `24` prin prototip azi (`gnFacturareNou=1`),
|
||||
`lcSqlCursor` ar ramane nedefinit — eroare, nu doar diferenta de comportament.
|
||||
6. **Tipurile `26` si `52` n-au niciun bookkeeping `crsarticole`** (nici Rol A, nici Rol B) —
|
||||
inchis aici punctul lasat deschis de raportul S4 punctul 2: excluderea lor din toate cele patru
|
||||
`Case`-uri de bookkeeping din `do_adauga_articol`/`do_sterge` e totala (Do Case exhaustiv, fara
|
||||
ramura implicita), nu doar "neconfirmata".
|
||||
7. **`27` si `30` raman pe calea lor** — confirmat pe cod, cu o nuanta importanta pentru `30`: nu
|
||||
e un formular separat, ci **acelasi `frm_facturare_articole`, instantiat si trecut prin acelasi
|
||||
`Init`/`Do Case`, dar niciodata aratat** (`ofacturare.prg:444-453`: calculeaza totalurile, apasa
|
||||
programatic `but_termin1.Click()`, apoi `Release()`, fara `Show()`). Tip `30` **e afectat de
|
||||
golurile din `Do Case`** exact ca oricare alt tip needitat — doar ca defectele (titlu, cap de
|
||||
coloana) nu se vad niciodata pe ecran.
|
||||
|
||||
---
|
||||
|
||||
## 0. Metoda de verificare — lista de referinta
|
||||
|
||||
Lista completa de tipuri vine din `COMUN\docs\tipuri_documente_facturare.md` (sursa unica, deja
|
||||
verificata pe cod de acea cercetare). Tipuri incluse in tabelul de mai jos: toate cele din sectiunile
|
||||
"Facturi" si "Avize de expeditie" (documentele care intra prin `frm_facturare_articole`/`2`).
|
||||
Sectiunea "Tipuri negative" (`-1..-13`) **nu intra in acest formular** — sunt scrise de alte produse
|
||||
(ROAGEST, ROAAUTO) prin propriile lor fluxuri, niciodata prin `factureaza()` din ROAFACTURARE
|
||||
(cautare exhaustiva `factureaza(-` in tot `D:\ROA`, zero potriviri) — declarate aici explicit **ramase
|
||||
pe calea altui produs**, nu "neacoperite".
|
||||
|
||||
---
|
||||
|
||||
## 1. Tabelul complet, tip cu tip
|
||||
|
||||
Coloane: `tip` = `VANZARI.TIP` · **Case propriu** = are ramura proprie in `frm_facturare_articole.Init`
|
||||
(`ofacturare.vc2:15109-15248`)? · **titlu** = ce seteaza pe `lb_titlu_alb_b121.Caption` · **cap
|
||||
cantitate** = ce seteaza pe `grd_articole.cCantitate.header1.Caption` (implicit ramane cel din
|
||||
design, `[Cantitate in stoc]`, daca nu e suprascris) · **mesaj stoc** = `This.cmesaj_cantitate` ·
|
||||
**discount** = `clb_discount.Visible` · **`cSerie`** = coloana ramane (`Da`) sau se scoate (`Nu`) ·
|
||||
**butoane** = ce se face vizibil (`but_urmator_tot1`/`but_retur`, ambele `.F.` la design) · **cursor
|
||||
standard** = ramura din `factureaza` (`ofacturare.prg:266-308`) · **cursor prototip** = ramura din
|
||||
`factureaza2` (`:748-822`, gol daca lipseste) · **Rol crsarticole** = A (cantitate ramasa de
|
||||
facturat) / B (plafon de sesiune) / — (fara bookkeeping), din `docs\cercetare\s4_punct2_registru_cantitate_ramasa.md`
|
||||
· **stare S5** = acoperit azi / gol de completat / ramas pe calea veche / neatins.
|
||||
|
||||
### Facturi
|
||||
|
||||
| tip | denumire | Case propriu | titlu | cap cantitate | mesaj stoc | discount | `cSerie` | butoane vizibile | cursor standard | cursor prototip | Rol | stare S5 |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| 1 | lista de preturi (lei) | **Da** `:15122` (grup 1,5,7,10) | — (implicit) | "Cantitate in stoc" | "nu e pe stoc!" | vizibil (implicit) | **Nu** (scoasa) | `but_retur` | `cursor_preturi` (grup 1,22,5,29,7,10,23), `:279-282` | `cursor_preturi` (grup 1,22,5,29,7,10), `:758-761` | B (gestionabil, `1,22,29`) | acoperit azi, de portat |
|
||||
| 2 | contract (lei) | **Da** `:15129` (grup 2,6) | "FACTURA PE CTR. …" | "Cantitate in stoc" | "nu e pe stoc!" | vizibil | **Nu** | — | `cursor_contract` (grup 2,26,6,52), `:283-291` | `cursor_contract` (grup 2,26,6 — **fara 52**), `:762-769` | B doar pt. `opt_facturare=0`; — pe rest | acoperit azi, de portat |
|
||||
| 3 | comanda | **Da** `:15144` | "FACTURA LA COMANDA …" | "Cantitate comandata" | "cantitate comandata facturata" | vizibil | **Nu** | `but_urmator_tot1` | `cursor_comanda` (grup 3,21,25,28,42,47), `:292-293` | `cursor_comanda` (acelasi grup), `:771-773` | **A** | acoperit azi, de portat |
|
||||
| 4 | din avize | **Da** `:15151` | "FACTURA DIN AVIZE" | — (implicit) | "cantitate de pe aviz facturata" | **ascuns** (`.F.`, `:15154`) | Da (nu se scoate) | `but_urmator_tot1` | `cursor_avize`, `:294-295` | `cursor_avize`, `:774-775` | **A** | acoperit azi, de portat |
|
||||
| 5 | lista de preturi valuta | **Da** `:15122` (grup 1,5,7,10) | — | "Cantitate in stoc" | "nu e pe stoc!" | vizibil | **Nu** | `but_retur` | `cursor_preturi` | `cursor_preturi` | — | acoperit azi, de portat |
|
||||
| 6 | contract valuta | **Da** `:15129` (grup 2,6) | "FACTURA PE CTR. …" | "Cantitate in stoc" | "nu e pe stoc!" | vizibil | **Nu** | — | `cursor_contract` | `cursor_contract` | B partial (ca 2) | acoperit azi, de portat |
|
||||
| 7 | credit note | **Da** `:15122` (grup 1,5,7,10) | — | "Cantitate in stoc" | "nu e pe stoc!" | vizibil | **Nu** | `but_retur` | `cursor_preturi` | `cursor_preturi` | — | acoperit azi, de portat |
|
||||
| 8 | retur factura lei | **Da** `:15236` (grup 8,9) | — | "Cant. max. de returnat" | "nu se mai poate returna" | vizibil | Da (nu se scoate) | `but_urmator_tot1` | `cursor_retur`, `:306-307` | `cursor_retur` (grup 8,9), `:819-820` | B (invers) | acoperit azi, de portat |
|
||||
| 9 | retur factura valuta | **Da** `:15236` (grup 8,9) | — | "Cant. max. de returnat" | "nu se mai poate returna" | vizibil | Da | `but_urmator_tot1` | `cursor_retur` | `cursor_retur` | B (invers) | acoperit azi, de portat |
|
||||
| 10 | factura fiscala valuta | **Da** `:15122` (grup 1,5,7,10) | — | "Cantitate in stoc" | "nu e pe stoc!" | vizibil | **Nu** | `but_retur` | `cursor_preturi` | `cursor_preturi` | — | acoperit azi, de portat |
|
||||
| **43** | bon fiscal magazine (ROARETAIL) | Nu | — | — | — | — | — | — | *nicio ramura* | *nicio ramura* | n/a | **neatins** — niciodata pasat lui `factureaza()` (cautat in tot `D:\ROA`); colectat de la magazine prin alt flux |
|
||||
| **44** | factura hotel | Nu | — | — | — | — | — | — | *nicio ramura* | *nicio ramura* | n/a | **neatins** — la fel, zero apeluri `factureaza(44` |
|
||||
| **45** | factura restaurant | **Nu** — lipseste din `Do Case` | **nesetat** | **nesetat** (implicit) | **nesetat** (ramane "nu e pe stoc!" default, `:15108`) | **nesetat** (ramane vizibil) | **Da, ramane** (nescoasa) | **nesetat** | `cursor_preturi`, `:275-278` | `cursor_preturi`, `:754-757` | — (exclus explicit din bookkeeping, `:12871,17178`) | **gol real de completat** — reachable din `Meniuri\politica.mn2:18` |
|
||||
| **46** | nota de plata restaurant | Nu | — | — | — | — | — | — | *nicio ramura* | *nicio ramura* | n/a | **neatins** — zero apeluri `factureaza(46`; zero documente in date de test (`tipuri_documente_facturare.md`, capcana 2) |
|
||||
| **48** | custodie cu descarcare K | **Nu** — lipseste din `Do Case` | **nesetat** | **nesetat** | **nesetat** | **nesetat** | **Da, ramane** | **nesetat** | `cursor_articole_k`, `:271-273` | `cursor_articole_k`, `:750-752` | — | **gol real de completat** — reachable din `Meniuri\politica.mn2:29` (submeniu `Marfaincus`) |
|
||||
| **49** | custodie fara descarcare K | **Nu** — lipseste din `Do Case` | **nesetat** | **nesetat** | **nesetat** | **nesetat** | **Da, ramane** | **nesetat** | `cursor_articole_k` | `cursor_articole_k` | — | **gol real de completat** — reachable din `Meniuri\politica.mn2:26` |
|
||||
| **50** | *(in lucru)* retur custodie | Nu | — | — | — | — | — | — | *nicio ramura* | *nicio ramura* | n/a | **neatins**, marcat explicit "in lucru" in `tipuri_documente_facturare.md` |
|
||||
| **51** | factura ROAACNPRO | Nu | — | — | — | — | — | — | *nicio ramura* | *nicio ramura* | n/a | **neatins** — `id_set=50100`, interval separat; probabil scris direct de ROAACNPRO, nu prin `factureaza()` local |
|
||||
| **52** | contract, factura fiscala valuta | **Nu** — lipseste din `Do Case` | **nesetat** | **nesetat** | **nesetat** | **nesetat** | **Da, ramane** | **nesetat** | `cursor_contract` (grup 2,26,6,52) | ***lipseste*** din grupul contract (`:762`) — `lcSqlCursor` nedefinit pe prototip | — (confirmat, vezi §2) | **gol real de completat** — reachable din `Meniuri\contracte.mn2:18` |
|
||||
|
||||
### Avize de expeditie
|
||||
|
||||
| tip | denumire | Case propriu | titlu | cap cantitate | mesaj stoc | discount | `cSerie` | butoane vizibile | cursor standard | cursor prototip | Rol | stare S5 |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| 21 | catre clienti, din comanda | **Da** `:15168` (grup 21,28,42,47) | "AVIZ DE EXPEDITIE DIN COMANDA" | — (implicit) | "avizata cantitatea comandata" | **ascuns** | **Nu** | `but_urmator_tot1` | `cursor_comanda` | `cursor_comanda` | **A** | acoperit azi, de portat |
|
||||
| 22 | catre clienti, din lista | **Da** `:15178` (grup 22,29) | "AVIZ DE EXPEDITIE DIN LISTA DE PRETURI" | — | "nu e pe stoc!" | **ascuns** | **Nu** | — | `cursor_preturi` | `cursor_preturi` | B | acoperit azi, de portat |
|
||||
| **23** | transfer subunitati, din lista | **Da** `:15187` | "TRANSFER INTRE SUBUNITATI" | — | "nu e pe stoc!" | **ascuns** | **Nu** | — | **`cursor_preturi`** (grup 1,22,5,29,7,10,**23**), `:279` | **`cursor_gestiune`** (grup **23**,41), `:776-778` | **B** (cod comun, indiferent de sursa) | acoperit azi, **dar sursa de cursor diverge intre forme — vezi §3** |
|
||||
| 24 | aviz retur | **Da** `:15242` | "RETUR AVIZ DE EXPEDITIE" | "Cant. max. de returnat" | "nu se mai poate returna" | (nemodificat aici) | **Nu** | `but_urmator_tot1` | `cursor_retur` (grup 8,9,**24**), `:306-307` | ***lipseste*** din grupul retur (`:819`, doar 8,9) — `lcSqlCursor` nedefinit pe prototip | B (invers) | acoperit azi, **dar prototipul n-are ramura de cursor — vezi §3** |
|
||||
| 25 | transfer subunitati, din comanda | **Da** `:15206` | "TRANSFER INTRE SUBUNITATI PE BAZA DE COMANDA" | — | "avizata cantitatea comandata" | **ascuns** | **Nu** | `but_urmator_tot1` | `cursor_comanda` | `cursor_comanda` | **A** | acoperit azi, de portat |
|
||||
| 26 | catre clienti, din contract | **Da** `:15216` | "AVIZ DE EXPEDITIE DIN CONTRACTUL …" | "Cantitate in stoc" | "nu e pe stoc!" | **ascuns** | **Nu** | — | `cursor_contract` (grup 2,26,6,52) | `cursor_contract` (grup 2,26,6 — fara 52, dar 26 e prezent) | — (confirmat, §2) | acoperit azi, de portat |
|
||||
| **27** | transfer subunitati, pe lucrare | n/a — **ramane pe calea lui** | n/a | n/a | n/a | n/a | n/a | n/a | `cursor_lucrare`, `:302-304` | `cursor_lucrare`, `:815-817` | n/a | **ramas pe calea veche** — `frm_avizare_lucrare`, confirmat §4 |
|
||||
| 28 | catre clienti debitori, din comanda | **Da** `:15168` (grup 21,28,42,47) | "AVIZ DE EXPEDITIE DIN COMANDA" | — | "avizata cantitatea comandata" | **ascuns** | **Nu** | `but_urmator_tot1` | `cursor_comanda` | `cursor_comanda` | **A** | acoperit azi, de portat |
|
||||
| 29 | catre clienti debitori, din lista | **Da** `:15178` (grup 22,29) | "AVIZ DE EXPEDITIE DIN LISTA DE PRETURI" | — | "nu e pe stoc!" | **ascuns** | **Nu** | — | `cursor_preturi` | `cursor_preturi` | B | acoperit azi, de portat |
|
||||
| **30** | transfer subunitati, pe NIR | n/a — **ramane pe calea lui, dar prin acelasi formular** | (irelevant — formular niciodata aratat) | (irelevant) | (irelevant) | (irelevant) | (irelevant) | (irelevant) | `cursor_aviz_nir`, `:299-300` | `cursor_aviz_nir`, `:813` | n/a | **ramas pe calea veche, cu nuanta** — vezi §4 |
|
||||
| 41 | retur transfer, lista pret | **Da** `:15197` | "RETUR TRANSFER" | — | "nu e pe stoc!" | **ascuns** | **Nu** | — | `cursor_gestiune`, `:296-298` | `cursor_gestiune` (grup 23,41) | **B** | acoperit azi, de portat |
|
||||
| 42 | catre clienti custodie, din comanda | **Da** `:15168` (grup 21,28,42,47) | "AVIZ DE EXPEDITIE DIN COMANDA" | — | "avizata cantitatea comandata" | **ascuns** | **Nu** | `but_urmator_tot1` | `cursor_comanda` | `cursor_comanda` | **A** | acoperit azi, de portat |
|
||||
| 47 | catre clienti custodie K, din comanda | **Da** `:15168` (grup 21,28,42,47) | "AVIZ DE EXPEDITIE DIN COMANDA" | — | "avizata cantitatea comandata" | **ascuns** | **Nu** | `but_urmator_tot1` | `cursor_comanda` | `cursor_comanda` | **A** | acoperit azi, de portat |
|
||||
| **50** | *(in lucru)* retur clienti custodie | Nu | — | — | — | — | — | — | *nicio ramura* | *nicio ramura* | n/a | **neatins**, "in lucru" |
|
||||
|
||||
**Tipuri negative** (`-1..-13`, ROAGEST/ROAAUTO): **ramase pe calea altui produs** — nu trec
|
||||
niciodata prin `factureaza()`/`factureaza2` din ROAFACTURARE (cautare exhaustiva, zero potriviri),
|
||||
deci nu intra in perimetrul Do Case-ului acestui formular. Declarate aici explicit, nu omise.
|
||||
|
||||
---
|
||||
|
||||
## 2. Tipurile care nu intra in niciun `Case` — inventar complet
|
||||
|
||||
Cerinta explicita a misiunii: "nu doar 52". Lista completa, verificata pe intreg `Do Case`-ul
|
||||
(`ofacturare.vc2:15109-15248`, citit integral, nu esantion) fata de lista de referinta:
|
||||
|
||||
**Nu apar in niciun `Case` al `frm_facturare_articole.Init`:**
|
||||
|
||||
| tip | reachable prin `factureaza()`? | ce pierde concret |
|
||||
|---|---|---|
|
||||
| 43 | Nu (0 apeluri in tot `D:\ROA`) | irelevant — nu ajunge la acest formular |
|
||||
| 44 | Nu | irelevant |
|
||||
| **45** | **Da** (`Meniuri\politica.mn2:18`) | titlu, cap coloana cantitate, mesaj de stoc, `cSerie` nescoasa (ramane vizibila, desi tip 45 e explicit exclus din bookkeeping-ul de cantitate — cele doua lucruri nu sunt legate) |
|
||||
| 46 | Nu | irelevant — zero documente si in datele de test |
|
||||
| **48** | **Da** (`Meniuri\politica.mn2:29`, submeniu `Marfaincus`) | idem 45 |
|
||||
| **49** | **Da** (`Meniuri\politica.mn2:26`) | idem 45 |
|
||||
| 50 | Nu, "in lucru" | irelevant azi |
|
||||
| 51 | Nu (interval `id_set` separat, alt produs) | irelevant pentru acest formular |
|
||||
| **52** | **Da** (`Meniuri\contracte.mn2:18`) | titlu (ramane cel implicit al formularului), `cSerie` nescoasa, cap coloana cantitate implicit — **cel mai vizibil defect, pentru ca 2/6 (acelasi grup logic) au titlu corect** |
|
||||
|
||||
**Concluzie**: din cele noua tipuri fara `Case`, **patru sunt reale si vizibile utilizatorului azi**
|
||||
(`45, 48, 49, 52`) — acestea sunt golul de completat cu valoare, nu doar `52`. Celelalte cinci
|
||||
(`43,44,46,50,51`) nu ajung niciodata la acest formular in fluxul curent — nu au nevoie de ramura in
|
||||
`Do Case` **pana cand** ceva le conecteaza la `factureaza()` (posibil, dar in afara perimetrului
|
||||
observabil aici; de tratat ca risc, nu ca bug, la sectiunea 10).
|
||||
|
||||
**De ce raman "invizibile" azi cu `cSerie`/titlu implicit, nu cu eroare**: `Do Case ... Endcase` fara
|
||||
ramura `Otherwise` in VFP nu genereaza nicio eroare cand nimic nu se potriveste — pur si simplu sare
|
||||
peste tot blocul. De-asta tip 45/48/49/52 "merg" (formularul se deschide, factureaza cu succes), doar
|
||||
cu UI-ul netratat pentru cazul lor specific — un defect tacut, nu un crash, motiv probabil pentru care
|
||||
n-a fost observat/raportat pana acum.
|
||||
|
||||
---
|
||||
|
||||
## 3. Divergentele standard vs. prototip
|
||||
|
||||
| Aspect | Standard (`factureaza`) | Prototip (`factureaza2`) | Comportament corect de pastrat |
|
||||
|---|---|---|---|
|
||||
| **Cursor pe tip 23** | `cursor_preturi` (grup `1,22,5,29,7,10,23`, `:279`) — tratat ca lista de preturi | `cursor_gestiune` (grup `23,41`, `:776-778`) — tratat ca transfer | **`cursor_gestiune`**, impreuna cu 41 (deja stabilit de S4/S4b: transferul e o singura familie de tip, indiferent daca porneste "din lista" sau "retur"; tratarea ca lista de preturi pe standard e inconsistenta cu propriul titlu "TRANSFER INTRE SUBUNITATI" pe care tot standardul il afiseaza pentru tip 23) |
|
||||
| **Cursor pe tip 52** | prezent, grupat cu `2,26,6` (`:283`) | **absent** din grupul contract (`:762`, doar `2,26,6`) — `lcSqlCursor` ramane nedefinit daca cineva factureaza tip 52 prin prototip | **prezent**, grupat cu `2,6,26` — lipsa lui pe prototip e o eroare de portare, nu o alegere deliberata (nimic in cod sugereaza ca 52 trebuia tratat diferit de 2/6/26 la nivel de cursor) |
|
||||
| **Cursor pe tip 24** | prezent, grupat cu `8,9` (`:306-307`) | **absent** din grupul retur (`:819`, doar `8,9`) — `lcSqlCursor` nedefinit | **prezent**, grupat cu `8,9` — acelasi tip de omisiune ca la 52 |
|
||||
| **Init: diferentiere pe tip** | 14 ramuri, seteaza titlu/cap coloana/mesaj/discount/`cSerie`/butoane | practic nimic — doar `lcTipDoc` ("factura"/"aviz"), pe o lista **fara tip 24** | **toata logica standardului**, portata — prototipul nu are nimic de pastrat aici in afara de pozitia `lcTipDoc` |
|
||||
| **Coloana `cSerie`** | exista in grid prin design, se scoate condiționat (10 din 21 tipuri acoperite) | **nu exista deloc** ca si coloana in `grd_factura` (gridul unic al prototipului) | de decis explicit la proiectare (§5) — nu e o simpla portare, gridul insusi trebuie sa capete coloana |
|
||||
| **`but_urmator_tot1` (sau echivalentul lui)** | vizibil pe 9 din 21 de tipuri (§1) | nu exista conceptul in Init — prototipul nu are nimic care sa corespunda azi | de portat lista completa de vizibilitate din standard |
|
||||
| **`clb_discount.Visible`** | ascuns explicit pe toate tipurile de aviz (`21,28,42,47,22,29,23,41,25,26`) | niciodata atins in Init | de portat integral |
|
||||
|
||||
**De ce conteaza asta pentru S5**: planul spune ca formularul unificat se bazeaza pe prototip
|
||||
(arhitectura lui: grid unic, editare inline, cautare pe server — deja deciziile S1-S4). Dar
|
||||
**diferentierea pe tip nu vine "aproape gata" din prototip** — vine aproape in intregime din
|
||||
standard, si trebuie portata, nu doar completata cu cele patru tipuri lipsa. Cele doua liste (tipuri
|
||||
lipsa din standard: 45/48/49/52; tot ce lipseste din prototip: aproape totul) sunt probleme
|
||||
**diferite**, care se rezolva **in aceeasi miscare** daca proiectarea de la §5 porneste de la o
|
||||
sursa unica de configurare portata integral din standard, cu cele patru completari incluse de la
|
||||
inceput (nu adaugate separat, dupa portare).
|
||||
|
||||
---
|
||||
|
||||
## 4. Tipurile speciale (27, 30) — confirmate pe cod
|
||||
|
||||
### Tip 27 — transfer pe baza de lucrare
|
||||
|
||||
Confirmat la trei niveluri, toate in `ofacturare.prg`:
|
||||
- `Do Case tnTip = 27 -> poDate.nIdTipDoc = 6` (`:188-189`, tip document AVIZ);
|
||||
- `Do Case tnTip = 27 -> lcObiect = [frm_date_aviz_lucrare]` (`:218-219`) — **formular de antet
|
||||
diferit**, nu `frm_date_aviz`/`frm_date_factura`;
|
||||
- `Do Case tnTip = 27 -> lcObject = [frm_avizare_lucrare]` (`:386-387`) — **formular de articole
|
||||
diferit**, nu `frm_facturare_articole`. Cursorul sursa e si el propriu: `cursor_lucrare`
|
||||
(`:302-304`), populat pe `poDate.id_lucrare`, un camp pe care restul tipurilor nu-l au.
|
||||
|
||||
**Ce il tine pe calea lui**: `id_lucrare` — o legatura pe care niciun alt tip de document n-o are
|
||||
(lucrare de service/executie, nu comanda/aviz/contract). `frm_avizare_lucrare` grupeaza gestiunile
|
||||
destinatie diferit (`crsgestiunidest`, `:388-393`, cu optiunea `<TOATE>`), o structura pe care
|
||||
`frm_facturare_articole`/`2` n-o au. **Formularul unificat n-ar avea `id_lucrare` si n-ar avea
|
||||
gruparea pe gestiuni destinatie** — motiv suficient sa ramana separat, confirmat pe cod, nu
|
||||
presupus.
|
||||
|
||||
### Tip 30 — transfer pe baza de NIR
|
||||
|
||||
**Nuanta importanta, gasita aici**: tip 30 **nu ocoleste** `frm_facturare_articole` — il
|
||||
instantiaza, exact ca orice alt tip din grupul "otherwise" (`ofacturare.prg:395`, `lcObject =
|
||||
[frm_facturare_articole]`, ramura `Else` a lui `If tnTip = 27`). Trece prin acelasi `Init`, acelasi
|
||||
`Do Case` de la `:15109-15248` (unde `30` nu are ramura proprie — ar avea aceleasi goluri ca 45/48/49
|
||||
daca ar fi vreodata aratat). Diferenta reala: **formularul nu e niciodata aratat**
|
||||
(`ofacturare.prg:444-453`):
|
||||
|
||||
```
|
||||
IF tnTip = 30 && AVIZ DIN NIR
|
||||
ofrmdetaliifactura.do_calculeaza_totaluri()
|
||||
ofrmdetaliifactura.but_termin1.Click()
|
||||
plVizibil = .F.
|
||||
...
|
||||
ELSE
|
||||
...
|
||||
If plVizibil
|
||||
ofrmdetaliifactura.Show()
|
||||
Else
|
||||
ofrmdetaliifactura.Release()
|
||||
pnButon = 2
|
||||
Endif
|
||||
ENDIF
|
||||
```
|
||||
|
||||
**Ce il tine pe calea lui**: nu structura formularului (e acelasi obiect), ci **automatizarea
|
||||
completa a fluxului** — cursorul sursa (`cursor_aviz_nir`, populat din `VRUL`/tranzactii de receptie,
|
||||
nu din comanda/lista de preturi) vine deja complet, iar codul apeleaza direct metodele de finalizare
|
||||
fara interactiune. **Pentru formularul unificat**: daca arhitectura noua pastreaza acelasi tipar
|
||||
("creeaza obiectul, populeaza, cheama finalizarea, `Release()` fara `Show()`"), tip 30 continua sa
|
||||
functioneze neschimbat — nu are nevoie de ramura in configurarea vizuala (§5), pentru ca vizualul nu
|
||||
se vede niciodata. **Singurul risc real**: daca `do_calculeaza_totaluri()`/`but_termin1.Click()` ale
|
||||
formularului unificat ajung sa citeasca vreo proprietate pe care doar `Do Case`-ul vizual o seteaza
|
||||
azi (de exemplu, un cod care ar verifica `This.cmesaj_cantitate` sau `lcTipDoc` in logica de calcul,
|
||||
nu doar in UI) — **de verificat explicit la implementare**, nu presupus ca "nu conteaza pentru ca nu
|
||||
se vede".
|
||||
|
||||
---
|
||||
|
||||
## 5. Ce structura inlocuieste `Do Case`-ul de 140 de linii
|
||||
|
||||
### Optiunile comparate
|
||||
|
||||
**(a) Pastreaza `Do Case`, doar completeaza-l** (adauga ramuri pentru 45/48/49/52, porteaza restul in
|
||||
prototip). Cost minim imediat, dar **nu rezolva problema de fond**: un `Do Case` fara `Otherwise` nu
|
||||
semnaleaza niciodata un tip lipsa — exact mecanismul care a produs golul de azi (patru tipuri reale
|
||||
pierdute, ani la rand, fara nicio eroare). Orice tip nou de document adaugat in viitor (suita are deja
|
||||
`46,50` "in lucru", `43,44,51` din alte fluxuri) risca aceeasi soarta.
|
||||
|
||||
**(b) Metoda separata per grup de tipuri** (`configureaza_lista_preturi()`, `configureaza_comanda()`,
|
||||
...). Mai clar decat un `Do Case` unic, dar tot **implicit** — un tip nou tot nu declanseaza nicio
|
||||
eroare daca nimeni nu-l adauga in metoda corecta; doar muta problema din 140 de linii intr-un fisier
|
||||
cu mai multe metode mici, fara sa adauge un mecanism de detectie.
|
||||
|
||||
**(c) Tabel de configurare per tip (RECOMANDAT)**. Un cursor/tabel cu **un rand per `tip`**, coloanele
|
||||
fiind exact proprietatile pe care `Do Case`-ul le seteaza azi: `titlu`, `cap_cantitate`, `mesaj_stoc`,
|
||||
`discount_vizibil` (`L`), `are_serie` (`L`), `tip_doc` (`factura`/`aviz`), `buton_tot_vizibil` (`L`),
|
||||
`buton_retur_vizibil` (`L`), `grup_sursa` (pentru meniul S4b: `lista/comanda/aviz-comanda/transfer/
|
||||
retur/contract-articole/contract-rate`). Populat printr-un singur bloc de `INSERT INTO` (sau un DBF
|
||||
static, `configuratie_tip_document.dbf`, editabil fara compilare) — **un rand per tip din
|
||||
`tipuri_documente_facturare.md`**, inclusiv cele patru azi lipsa.
|
||||
|
||||
`Init` devine:
|
||||
```
|
||||
SELECT * FROM configuratie_tip_document WHERE tip = poDate.tip INTO CURSOR crscfgtip
|
||||
If Reccount('crscfgtip') = 0
|
||||
* tip necunoscut -- eroare explicita, nu formular netratat tacut
|
||||
AMESSAGEBOX("Tip de document necunoscut in configurare: " + Transform(poDate.tip), 16, "Eroare configurare")
|
||||
Thisform.Release()
|
||||
Return
|
||||
Endif
|
||||
This.lb_titlu_alb_b121.Caption = crscfgtip.titlu
|
||||
This.grd_articole.cCantitate.header1.Caption = crscfgtip.cap_cantitate
|
||||
This.cmesaj_cantitate = crscfgtip.mesaj_stoc
|
||||
This.clb_discount.Visible = crscfgtip.discount_vizibil
|
||||
If !crscfgtip.are_serie
|
||||
This.grd_articole.RemoveObject('cSerie')
|
||||
Endif
|
||||
This.but_urmator_tot1.Visible = crscfgtip.buton_tot_vizibil
|
||||
This.but_retur.Visible = crscfgtip.buton_retur_vizibil
|
||||
```
|
||||
|
||||
**De ce e mai bun decat (a)/(b) pe cost de intretinere**:
|
||||
- **Un tip lipsa devine o eroare vizibila la deschidere**, nu un formular netratat tacut — exact
|
||||
defectul care a permis golul de azi sa treaca neobservat ani la rand.
|
||||
- **"Cat de usor se vede un tip lipsa" e mecanic, nu vizual** — vezi §8, o interogare simpla compara
|
||||
lista de tipuri din configurare cu lista de referinta din `tipuri_documente_facturare.md`, fara sa
|
||||
ruleze formularul.
|
||||
- **Grupurile identice raman explicite, nu implicite** — azi, "tipurile 21,28,42,47 au acelasi titlu"
|
||||
se vede doar citind `Inlist(...)`; intr-un tabel, acelasi lucru se vede ca patru randuri cu aceeasi
|
||||
valoare in coloana `titlu` — usor de generat cu un singur `INSERT` per grup (`FOR EACH tip IN
|
||||
(21,28,42,47) ... INSERT ...`), nu mai putin explicit, dar auditabil cu `SELECT titlu, COUNT(*)
|
||||
GROUP BY titlu`.
|
||||
- **Coloana `are_serie` rezolva si divergenta standard/prototip de la §3** — prototipul nu are azi
|
||||
conceptul deloc; cu configurarea noua, adaugarea coloanei `cSerie` in gridul unificat devine
|
||||
conditionata de aceeasi sursa unica, indiferent de forma de baza.
|
||||
|
||||
**Cost**: portarea initiala a ~21 de randuri (14 ramuri distincte de azi + 4 completari + grupare
|
||||
explicita), plus un nou tabel/cursor de intretinut. Nu e cod nou complex — e date, nu logica; riscul
|
||||
de regresie e in acuratetea portarii (fiecare valoare trebuie sa corespunda exact cu ce face azi
|
||||
`Do Case`-ul), verificabil linie cu linie fata de tabelul din §1.
|
||||
|
||||
**Recomandare finala**: **(c)**, cu tabelul de configurare implementat ca `DBF` static (nu cursor
|
||||
generat in cod) — editabil de oricine fara sa recompileze, si direct verificabil cu `SELECT` fara sa
|
||||
porneasca formularul (vezi §8).
|
||||
|
||||
---
|
||||
|
||||
## 6. Grupuri naturale de tipuri
|
||||
|
||||
Din tabelul §1, grupurile care au azi (sau ar trebui sa aiba) valori identice pe toate coloanele:
|
||||
|
||||
| Grup | Tipuri | Ce difera **in interiorul** grupului |
|
||||
|---|---|---|
|
||||
| **Lista de preturi, fara stoc special** | 1, 5, 7, 10 | Nimic in Init — difera doar valuta/tip document la nivel de antet (`poDate.in_valuta`, `nIdTipDoc`), nu in acest formular |
|
||||
| **Contract, factura** | 2, 6 (+ **52** de adaugat) | Nimic in Init dupa completare — `52` e valuta, ca `6`, dar cu alt `id_set`; titlul/coloanele sunt identice |
|
||||
| **Aviz din comanda (clienti/debitori/custodie)** | 21, 28, 42, 47 | Nimic in Init — difera doar destinatia comerciala (client normal/debitor/custodie), invizibila la acest nivel |
|
||||
| **Aviz din lista de preturi** | 22, 29 | Nimic — difera doar client normal/debitor |
|
||||
| **Retur facturi** | 8, 9 | Nimic — lei/valuta |
|
||||
| **Transfer subunitati** | 23, 41 | Sens (din lista vs. retur) — titlu diferit ("TRANSFER..." vs "RETUR TRANSFER"), restul identic; **trebuie unificate pe cursor** (§3) inainte de unificare vizuala |
|
||||
| **Comanda proprie** | 3 | Singur — cap de coloana propriu ("Cantitate comandata") |
|
||||
| **Avize proprii** | 4 | Singur — discount vizibil (spre deosebire de toate celelalte avize) |
|
||||
| **Aviz din contract** | 26 | Singur — titlu propriu, dar cursor comun cu grupul contract |
|
||||
| **Aviz retur** | 24 | Singur — cursor comun cu 8/9, dar titlu si `but_urmator_tot1` proprii |
|
||||
| **Custodie K** | 48, 49 | Identice ca structura vizuala (ambele lipsesc azi) — difera doar `cu`/`fara` descarcare K, invizibil la acest nivel |
|
||||
| **Restaurant** | 45 | Singur, azi lipsa |
|
||||
|
||||
Observatie de proiectare: grupurile "aviz din comanda" (21/28/42/47) si "comanda" (3) au **acelasi**
|
||||
cap de coloana si mesaj de stoc conceptual ("cantitate comandata"), dar text usor diferit
|
||||
("facturata"/"avizata") — pastrate distincte in tabelul de configurare (nu fortate identice), pentru
|
||||
ca diferenta e deliberata in codul de azi (`:15149` vs `:15176`, verb diferit).
|
||||
|
||||
---
|
||||
|
||||
## 7. Pasi de implementare, ordonati
|
||||
|
||||
1. **Extrage tabelul de configurare din `Do Case`-ul standard, exhaustiv** — un rand per tip din
|
||||
`tipuri_documente_facturare.md` care intra prin acest formular (Facturi + Avize, exclus 27/30/
|
||||
negative), valorile copiate exact din §1. *Gata cand*: `SELECT DISTINCT tip FROM
|
||||
configuratie_tip_document` produce exact multimea `{1,2,3,4,5,6,7,8,9,10,21,22,23,24,25,26,28,29,
|
||||
41,42,45,47,48,49,52}` (23 de tipuri) — nici unul in minus, nici unul in plus fata de lista
|
||||
calculata in §8.
|
||||
2. **Completeaza cele patru randuri azi lipsa (45,48,49,52)** cu valori coerente cu grupul lor logic
|
||||
(45 langa lista de preturi cu stoc dezactivat conceptual; 48/49 langa custodie K; 52 langa 2/6) —
|
||||
decizie de continut, nu doar de structura; **de validat cu Marius inainte de a le considera
|
||||
"gata"**, pentru ca azi nu exista niciun titlu/mesaj de referinta pentru ele (nimeni nu l-a vazut
|
||||
pe ecran). *Gata cand*: cele patru randuri au valori nenule pe toate coloanele obligatorii
|
||||
(`titlu`, `cap_cantitate`, `mesaj_stoc`).
|
||||
3. **Corecteaza rutarea cursorului**: `23` trece pe `cursor_gestiune` (unificat cu `41`, nu mai divide
|
||||
standard/prototip); `52` si `24` primesc ramura de cursor pe orice cale ramane vie din prototip
|
||||
(daca formularul unificat pastreaza `factureaza2`-stil, sau devine parte din calea unica daca
|
||||
`factureaza`/`factureaza2` se unesc — decizie separata, in afara acestei povesti). *Gata cand*:
|
||||
deschiderea formularului pe tip `23`, `24` si `52` prin calea noua produce acelasi continut in
|
||||
`crsarticole` ca varianta care functiona deja (`23`→prototip vechi pentru comparatie de continut,
|
||||
`24`/`52`→standard).
|
||||
4. **Adauga coloana `cSerie` in gridul unificat, condiționata pe `are_serie`** — azi absenta din
|
||||
gridul prototipului; adaugata o singura data, aratata/ascunsa din configurare, nu prin
|
||||
`RemoveObject` scris de mana pe fiecare tip. *Gata cand*: pe un tip cu `are_serie=.T.` (ex. 4)
|
||||
coloana e vizibila; pe un tip cu `are_serie=.F.` (ex. 3) nu e.
|
||||
5. **Inlocuieste `Do Case`-ul din `Init` cu citirea din configurare** (structura din §5), inclusiv
|
||||
ramura de eroare explicita pe tip necunoscut. *Gata cand*: pentru fiecare din cele 23 de tipuri,
|
||||
deschiderea formularului seteaza exact valorile din tabelul §1/pasul 2 (comparatie automata, nu
|
||||
vizuala — proprietatile sunt citibile headless).
|
||||
6. **Verifica tipurile speciale raman neatinse**: 27 (cale total separata, neschimbata), 30 (acelasi
|
||||
formular, dar `do_calculeaza_totaluri`/`but_termin1.Click()` nu citesc nimic setat doar de vechiul
|
||||
`Do Case` vizual — verificare explicita, §4). *Gata cand*: un document tip 30 de test se
|
||||
finalizeaza cu acelasi rezultat in `VANZARI`/`VANZARI_DETALII` inainte si dupa migrare.
|
||||
7. **Documenteaza tipurile neatinse (43,44,46,50,51) ca decizie explicita**, nu ca omisiune — un
|
||||
comentariu in tabelul de configurare (`* 43,44,46,50,51: neconectate la factureaza() in
|
||||
ROAFACTURARE, verificat <data>`) ca viitorii cititori sa nu presupuna ca lipsesc din greseala.
|
||||
*Gata cand*: comentariul exista si linkeaza spre acest raport.
|
||||
|
||||
*Depinde de*: S4 (cautarea articolelor pe server) pentru arhitectura gridului unic — pasul 4 de aici
|
||||
presupune ca gridul unificat exista deja in forma stabilita de S4; S4b (bara de butoane) pentru
|
||||
`buton_tot_vizibil`/`buton_retur_vizibil`, care alimenteaza si meniul `xmenu()` de acolo — coloanele
|
||||
`grup_sursa` din tabelul de configurare (§5) sunt exact ce cere S4b sectiunea 3.
|
||||
|
||||
---
|
||||
|
||||
## 8. Cum se verifica ca acoperirea e completa — proba mecanica
|
||||
|
||||
**Nu o citire — o interogare care compara doua liste.** Doua surse de adevar:
|
||||
|
||||
1. **Lista de referinta**: tipurile din `COMUN\docs\tipuri_documente_facturare.md`, sectiunile
|
||||
"Facturi" si "Avize de expeditie", **minus** cele confirmate neatinse azi de acest formular (27, 30
|
||||
raman — vezi nuanta §4 — dar 43,44,46,50,51 se exclud daca raman neconectate; de recalculat lista
|
||||
la fiecare rulare, nu de la o constanta inghetata).
|
||||
2. **Lista din configurare** (dupa implementarea §5): `SELECT DISTINCT tip FROM
|
||||
configuratie_tip_document`.
|
||||
|
||||
**Script de verificare** (headless, fara UI, rulabil oricand):
|
||||
|
||||
```foxpro
|
||||
* verifica_acoperire_tip.prg — proba mecanica pentru S5
|
||||
LOCAL lnLipsa, lnInPlus
|
||||
* 1. lista de referinta -- tinuta manual sincron cu tipuri_documente_facturare.md
|
||||
* (facturi + avize, exclus negative; 27/30 raman in lista, tratate separat la pasul 3)
|
||||
DIMENSION laReferinta[23]
|
||||
laReferinta = [1,2,3,4,5,6,7,8,9,10,21,22,23,24,25,26,27,28,29,30,41,42,47,52] && + 45,48,49 dupa Pasul 2
|
||||
|
||||
* 2. lista din configurare
|
||||
SELECT DISTINCT tip FROM configuratie_tip_document INTO CURSOR crsCfg
|
||||
|
||||
* 3. tipuri de referinta fara configurare (exclus 27, 30 -- cale separata confirmata)
|
||||
* 4. tipuri in configurare fara corespondent in referinta (config "orfana")
|
||||
* -- ambele liste trebuie sa fie goale la "gata"
|
||||
```
|
||||
|
||||
Alternativ, **fara sa astepte implementarea §5**: acelasi principiu se aplica azi direct pe
|
||||
`Do Case`-ul din `ofacturare.vc2:15109-15248`, extragand tipurile din fiecare `Case ... Inlist/=` prin
|
||||
`vfp_symbols.ps1 -Grep 'Case (poDate\.tip|Inlist\(poDate\.tip'` si comparand rezultatul cu lista de
|
||||
referinta — exact tehnica folosita in aceasta cercetare pentru a produce tabelul din §1 (nu o
|
||||
citire vizuala, o extractie sistematica).
|
||||
|
||||
**Pentru cursor (rutare, §3)**: acelasi principiu, pe `ofacturare.prg`, comparand tipurile din fiecare
|
||||
`Do Case`/`Inlist` de la `:266-308` (standard) cu cele de la `:748-822` (prototip) — orice tip prezent
|
||||
intr-una si absent in cealalta e o divergenta de raportat (asa au fost gasite `52` si `24` in aceasta
|
||||
sesiune).
|
||||
|
||||
---
|
||||
|
||||
## 9. Ce nu se poate testa headless
|
||||
|
||||
- **Titlul, capul de coloana, mesajul de stoc ca text afisat efectiv pe ecran** — verificabile
|
||||
headless doar ca *proprietati setate* (`This.lb_titlu_alb_b121.Caption` dupa `Init()`, apelat direct
|
||||
cu un `poDate` de test), nu ca randare vizuala. Diferenta conteaza: o proprietate corect setata pe
|
||||
un control care nu exista (`lb_titlu_alb_b121` lipsa din prototip azi) ar trece "headless" fara sa
|
||||
arate nimic real — de confirmat mai intai ca ambele controale exista in formularul unificat.
|
||||
- **Coloanele de grid (`grd_articole`/`grd_factura`, coloana `cSerie` noua)** — capcana deja cunoscuta
|
||||
pe acest proiect: sub `-A -T` (rulare headless), `ColumnCount=0`/`RecordSource` raman artefacte,
|
||||
coloanele nu se materializeaza. Exista un harness UI **vizibil** care le citeste corect — orice
|
||||
verificare a `are_serie`/coloanelor trebuie sa treaca prin acela, nu prin `-A -T`.
|
||||
- **Tip 30 — fluxul complet fara `Show()`** — se poate rula headless (nu deschide nicio fereastra prin
|
||||
constructie), dar verificarea "rezultatul in Oracle e identic inainte/dupa" cere date de test reale
|
||||
(un NIR cu articole), nu doar apelul metodei.
|
||||
- **Popup-ul/dialogul viitor din S4b (`xmenu()`, `cauta_alfa`)**, daca `grup_sursa` din tabelul de
|
||||
configurare (§5/§6) ajunge sa-l alimenteze direct — mostenit ca limitare de la raportul S4b (`§8`
|
||||
de acolo): continutul `lcMeniu` verificabil ca text, popup-ul afisat nu.
|
||||
- **Comportamentul real al meniurilor `politica.mn2`/`contracte.mn2`** pentru tipurile 45/48/49/52 —
|
||||
se poate confirma ca exista intrarea de meniu (citire `.mn2`, facuta in aceasta cercetare), dar nu
|
||||
ca apasarea ei in productie deschide exact formularul asteptat, fara o rulare UI vizibila.
|
||||
|
||||
---
|
||||
|
||||
## 10. Riscuri si ce ramane de decis de Marius
|
||||
|
||||
1. **Continutul exact (titlu/mesaj) pentru cele patru tipuri azi netratate (45,48,49,52)** — codul nu
|
||||
ofera niciun precedent vizual (n-au fost vazute niciodata corect pe ecran), deci textele propuse in
|
||||
Pasul 2 (§7) sunt o **propunere**, nu o recuperare a unui text existent. **Recomandare**: 45 langa
|
||||
grupul "lista de preturi fara stoc" (e exclus explicit din bookkeeping de stoc, `:12871`); 48/49 cu
|
||||
titlu care mentioneaza "custodie" (singurul lucru care le distinge conceptual azi, in afara de
|
||||
coeficientul K, invizibil la acest nivel); 52 **identic cu 2/6** ("FACTURA PE CTR. ..."), pentru
|
||||
coerenta cu gruparea deja facuta corect in `frm_date_factura.Init` (`:9530,9632,9670`, grupul
|
||||
`2,6,52`).
|
||||
2. **Daca 23 trece pe `cursor_gestiune` pe calea unificata, comportamentul vizibil pentru operator se
|
||||
schimba** (sursa de articole devine stocul din gestiune, nu lista de preturi) — **decizie de produs,
|
||||
nu doar tehnica**, deja semnalata de S4/S4b, dar repetata aici pentru ca afecteaza direct §5/§7
|
||||
(tabelul de configurare trebuie sa reflecte alegerea finala, nu ambele variante). **Recomandare**:
|
||||
`cursor_gestiune`, argumentat de coerenta cu titlul "TRANSFER INTRE SUBUNITATI" pe care insusi
|
||||
standardul il afiseaza azi pentru 23 (titlul spune "transfer", cursorul azi spune "lista de
|
||||
preturi" — inconsistenta interna de rezolvat, nu de pastrat).
|
||||
3. **Daca 43,44,46,50,51 raman permanent neconectate la `factureaza()`, sau exista planuri sa fie
|
||||
activate** — nu s-a gasit nicio dovada de cod ca ar fi in curs, dar nici o confirmare ca sunt
|
||||
abandonate definitiv (in afara de `50`, marcat explicit "in lucru" in sursa). **De intrebat pe
|
||||
Marius direct**, pentru ca raspunsul schimba daca tabelul de configurare (§5) trebuie sa le includa
|
||||
preventiv sau poate ramane cu 23 de randuri.
|
||||
4. **Coloana `cSerie` pe gridul unificat — cost de adaugare** — prototipul n-are azi conceptul deloc;
|
||||
adaugarea ei presupune modificari de grid (nu doar de cod), posibil in afara perimetrului text-only
|
||||
(`.vc2`/`.sc2` prin `txt2vcx.ps1`) daca structura de coloane a gridului cere editare in IDE — **de
|
||||
confirmat la implementare**, nu presupus ca e o simpla proprietate.
|
||||
5. **Tabel de configurare ca `DBF` static vs. `INSERT`-uri in cod** — recomandarea (§5) e DBF, pentru
|
||||
editabilitate fara recompilare, dar suita foloseste azi predominant cod pentru acest fel de
|
||||
configurare (niciun precedent de DBF static de configurare gasit in `frm_facturare_articole`/
|
||||
`frm_date_factura`) — **de validat cu Marius daca abaterea de la conventia existenta merita
|
||||
beneficiul**, sau daca un cursor generat in cod (mai aproape de stilul actual, dar mai putin
|
||||
editabil) e preferat.
|
||||
|
||||
## Handoff
|
||||
|
||||
Cercetare + proiectare incheiata in aceasta sesiune, fara sa fie nevoie de predare de context.
|
||||
Toate cele zece sectiuni cerute de misiune sunt completate, cu `fisier:linie` verificat direct pe
|
||||
fisierele text reale (`ofacturare.vc2`, `ofacturare.prg`, nu `.bak`), plus meniurile `.mn2` si
|
||||
raportul S4/S4b/S4_punct2 citate ca sursa pentru punctele deja stabilite (nereinvestigate).
|
||||
|
||||
Descoperiri dincolo de cerinta explicita a misiunii, semnalate clar in text: (1) patru tipuri lipsa
|
||||
din `Do Case`, nu unul (45/48/49/52, sectiunea 2); (2) prototipul (`frm_facturare_articole2.Init`)
|
||||
e aproape complet gol pe diferentiere de tip, nu doar incomplet (sectiunea 3) — cea mai mare
|
||||
descoperire a acestei sesiuni, cu impact direct asupra efortului de implementare estimat pentru S5;
|
||||
(3) doua divergente noi de rutare a cursorului (52, 24), pe langa cea deja cunoscuta (23) (sectiunea
|
||||
3); (4) tipurile 26 si 52 confirmate fara niciun bookkeeping `crsarticole`, inchizand punctul lasat
|
||||
deschis de raportul S4 punctul 2 (sectiunea 1, nota de subsol pe tabel).
|
||||
|
||||
Niciun fisier de cod atins, niciun `git_sync.ps1`/`txt2vcx.ps1` rulat, nicio scriere pe Oracle (numai
|
||||
`Read`/`Grep`/`vfp_symbols.ps1` pe fisiere de pe disc).
|
||||
Reference in New Issue
Block a user