romfast/roafacturare
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
5b52cb39991987f98cc0e34dbb5d0768d122836d
roafacturare/docs/plan_index.md
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

6.1 KiB
Raw Blame History

Planuri ROAFACTURARE — index si ordine de executie

Sursa: punctele ROAFACTURARE din COMUN\docs\todos.txt (6, 7, 8, 10, 11, 12). Ordinea e pe risc crescator, cu proiectele mari la final. Se executa pe rand, fiecare cu commit si verificari proprii, ca sa nu se amestece.

# Plan Volum Ce atinge Stare
— #8 — denormalizare VANZARI mediu (scop extins 06.08) PACK_FACTURARE + ambele view-uri (COMUN) + reparare date TERMINAT si COMIS 07.08.2026 (r17990-r17993). Planul a fost sters la curatenie; istoricul e in progres.md
— #7 — pret cu TVA pe linie mic-mediu doar VFP, gridul de articole din frm_facturare_articole TERMINAT 08.08.2026 (changelog 2.11.14). Editarea flagului pe o factura deja salvata a fost mutata explicit in #6
1 #6 — editare factura emisa mediu omodificari.vc2 (COMUN) + PACK_FACTURARE IN LUCRU, aproape gata — S1-S7 si S9 comise (S4b incheiat 11.08.2026). Ramane S8: 2 esecuri reale pe „factura din aviz" (rulajele nu se refac pe nota noua) + 3 tipuri de sursa neacoperite. Stare: antetul planului
2 #13 — formular unificat + editare prin regenerare mare ofacturare.vc2 + ofacturare.prg + PACK_FACTURARE (COMUN) PROIECTAT INTEGRAL, cod neatins (17 runde de proiectare, 11.08.2026). Etapele I si II sunt proiectate story cu story (S1-S14); raman testele (S6, S12) si inchiderea (S13). 65 de decizii luate, niciuna deschisa. Perimetrul cu #6 e transat: #13 incepe dupa terminarea lui #6 (decizia 30). Mockup: mockup_13_formular_unificat.html. Stare curenta: handoff_13_formular_unificat.md
— #12 — nomenclator ca sursa de pret mediu depinde de varianta valabil, amanat
— #11 — integrare politici de preturi mare COMUN + ROAPRETURI valabil, amanat
— #10 — integrare contracte mare COMUN + ROACONTRACTE valabil, amanat

De ce sunt amanate #12, #11 si #10

Decizia lui Marius, 06.08.2026. Nu sunt abandonate si nu sunt invalidate — planurile si faptele stabilite in ele raman valabile ca punct de plecare. Sunt amanate pentru ca sunt proiecte complexe, care mai au nevoie de analiza inainte de a fi pornite:

  • #12 — varianta nu e inca aleasa (C singura, sau C urmata de A restransa). Alegerea schimba perimetrul, de la un atribut optional de articol pana la coloane de pret in nomenclator.
  • #11 — atinge COMUN si ROAPRETURI, iar ROAPRETURI nu e inca inrolat in fluxul text, deci clasele lui nu se pot edita decat manual in IDE.
  • #10 — go/no-go-ul nu e inchis. Datele de la un client inclina spre no-go, dar e un singur client; mai trebuie aceleasi cifre de la 2-3 clienti care chiar lucreaza pe contracte.

Se reiau dupa terminarea lui #8, #7 si #6, cu analiza reluata de unde s-a oprit (rapoartele din docs\cercetare\).

Dependente reale intre planuri

  • #7 -> #6: editarea flagului pret_cu_tva pe o factura emisa (story S4 din #6) are sens doar dupa ce #7 stabileste comportamentul la introducere.
  • #8 -> #6: story S5 din #6 refoloseste calculul totalurilor din scrie_in_vanzari, atins in #8. Daca ordinea se inverseaza, calculul se dubleaza si cele doua cai diverg.
  • #11 -> #10: sablonul de incarcare lazy se stabileste o singura data, in #11 (S4), si se refoloseste in #10 (S3).
  • #12 e independent de restul.

Deciziile deschise — stare la 05.08.2026, de reluat cand se reiau #12 si #10

Ambele au fost investigate read-only pe schema de productie VENDING. Concluziile raman valabile; ce lipseste e decizia, nu investigatia.

  1. #12, varianta — investigatia a reformulat problema. Pretul nu e cauza duplicarii: nota contabila e. 14 politici poarta 12 note distincte (VANZARE AUTO EUR, VANZARE AUTO LEI, SERVICII, TRANSPORT...), iar articolele sunt introduse in medie de 3 ori (3 354 articole -> 10 130 randuri de pret). Varianta B e exclusa; recomandarea e varianta C (nota contabila ca atribut optional de articol), eventual urmata de o varianta A restransa doar la pret, pentru cele 807 articole fara niciun pret. Ramane de aprobat.
  2. #10, go/no-go — la clientul verificat: 4 contracte, 0 create in ultimul an, 0 facturi emise vreodata pe baza de contract. Mecanismul exista si nu a fost folosit niciodata. Inclina clar spre no-go, dar e un singur client — mai trebuie aceleasi cifre de la 2-3 clienti care chiar lucreaza pe contracte.

Precoditii de mediu

  • Orice DDL: sursa de referinta e MARIUSM_AUTO pe ROA_CENTRAL, nu productia, si numai dupa ce s-a verificat ca are toate scripturile aplicate — COMUN\docs\scripturi-migrare-db.md, sectiunea "Sursa de referinta pentru DDL". Verificat la 06.08.2026: toate cele 2 567 de scripturi ff_ sunt aplicate.
  • #8 se dezvolta si se testeaza integral pe MARIUSM_AUTO — bug-ul se reproduce si acolo (846 randuri, o singura valoare distincta de AVIZE). Accesul la VENDING ramane optional, ca al doilea set de date, strict in citire, prin tunel SSH.
  • #11 si #10 au nevoie ca ROAPRETURI, respectiv ROACONTRACTE, sa fie inrolate in fluxul text (COMUN\docs\inrolare-proiect-git-text.md) — altfel clasele lor nu se pot edita decat manual in IDE-ul VFP.

Note transversale

  • PACK_FACTURARE si clasele din COMUN\ sunt partajate de toata suita ROA. Planurile #8, #6, #11 si #10 ies din perimetrul ROAFACTURARE si cer commit in doua repo-uri.
  • Scripturile Oracle se scriu la nivel 10.2 (un client, ROMCONSTRUCT, e inca acolo), CRLF, idempotente — COMUN\docs\scripturi-migrare-db.md.
  • Sursa completa PACK_FACTURARE nu e in working copy VFP. Referinta se exporta din MARIUSM_AUTO (COMUN\docs\oracle_export.md); copia pe disc, cu alta numerotare de linii, e D:\ROA\DATABASE\SCRIPTURI_CLAR\2026\03\ff_2026_03_23_04_COMUN_PACK_FACTURARE.sql (16948 linii).