achizitie import: TVA DVI cu valuta proprie, discount financiar, cote multiple
- TVA-ul de pe DVI poate avea valuta si curs proprii, diferite de ale facturii (rand "protejat": rand_dvi/valuta_proprie pe introdc, sparge_tva_protejat). - Discount financiar pe factura: rand tip_rand='G' (401 = 767), TVA calculat pe baza diminuata, marfa si preturile articolelor pe valoarea integrala. - Factura multi-cota: randurile S, G si T se sparg pe cotele articolelor, cu explicatia TVA din familia coloanei si alinierea T -> S. - Teste noi in utile/Teste/achizitie_import (discount, DVI, cote, e2e). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U9uDgDfUQXbh2Neib36CN8
This commit is contained in:
@@ -38,3 +38,63 @@ Regula (valabila in toate proiectele ROA/VFP): un singur subagent care duce o mi
|
||||
completeaza-l, nu repeta investigatia.
|
||||
- Orchestratorul face el insusi munca de volum -> deleaga si pastreaza-si contextul
|
||||
pentru decizii, verificari si deblocari.
|
||||
|
||||
## Disciplina de context a ORCHESTRATORULUI
|
||||
|
||||
Pragul de ~200-250k e pentru subagenti, dar orchestratorul se umple la fel de repede daca isi
|
||||
lasa in sesiune munca de CITIT. Masurat pe o runda reala (implementare + 4 rulari ale unei suite
|
||||
de 25 de teste): sesiunea principala a ajuns la ~570k desi tot codul fusese scris de subagenti.
|
||||
Consumul, in ordinea marimii: (1) citirea rezultatelor de test dupa fiecare test terminat, cu tot
|
||||
cu liniile "OK"; (2) citirea codului ca sa diagnosticheze esecurile; (3) diagnostic si fixuri
|
||||
aplicate direct in loc de delegate.
|
||||
|
||||
- **Nu citi log-uri brute.** Scripturile de raportare afiseaza DOAR esecurile plus un total
|
||||
("22 OK, 3 FAIL: <nume + linia de esec>"). Tabelul complet se citeste o singura data, la
|
||||
baseline - nu dupa fiecare rulare. Pentru suitele VFP exista deja:
|
||||
`COMUN\utile\Teste\raport_teste.ps1 -Dir <folder> [-Tot] [-Baseline <fisier>]` - fara `-Tot`
|
||||
afiseaza doar esecurile, iar cu `-Baseline` le marcheaza `[preexistent]` vs `[NOU - REGRESIE]`.
|
||||
- **Nu citi cod ca sa diagnostichezi.** Deleaga cu "adu-mi dovada, nu fisierul": agentul intoarce
|
||||
cauza + linia + citatul minim. Verifici afirmatia, nu o redescoperi.
|
||||
- **Verifica prin assert, nu prin citire.** Daca vrei sa stii ca ceva e adevarat, cere o comanda
|
||||
care intoarce da/nu, nu continutul din care ai deduce singur.
|
||||
- **Nu aplica fixuri direct** decat sub ~5 linii si doar daca ai deja contextul in sesiune.
|
||||
- **Prag si pe orchestrator**: la ~50% din fereastra, scrie handoff-ul si reia orchestrarea
|
||||
dintr-o sesiune noua. Handoff-ul e deja pe disc - exact pentru asta exista.
|
||||
|
||||
## Model de lucru: backlog de story-uri mici, context mic per story
|
||||
|
||||
Impartirea pe "lane-uri" mari (o clasa, un modul) produce subagenti cu context mare si serializare
|
||||
pe fisier. Alternativa mai ieftina si mai robusta: **backlog de story-uri mici, fiecare rezolvabila
|
||||
cu context mic, rulate in bucla de agenti PROASPETI.**
|
||||
|
||||
Doua fisiere pe disc tin toata starea:
|
||||
|
||||
- `docs/handoff_<subiect>.md` - **contextul stabil**: reguli de editare, cai, ancore verificate,
|
||||
capcane confirmate, decizii luate. Il citeste fiecare agent; se actualizeaza rar.
|
||||
- `docs/backlog_<subiect>.md` - **starea vie**: story-uri cu ID, criteriu de acceptare
|
||||
VERIFICABIL, fisiere atinse, stare (`todo` / `in lucru` / `gata` / `blocat de #N`).
|
||||
|
||||
Bucla:
|
||||
1. orchestratorul ia primul story `todo` neblocat;
|
||||
2. spawneaza un agent proaspat cu prompt = trimitere la handoff + textul story-ului + criteriul
|
||||
de acceptare. **Nimic altceva** - fara istoric, fara rapoartele celorlalti agenti;
|
||||
3. agentul modifica, ruleaza verificarea din criteriu si raporteaza **verdict + ce a schimbat +
|
||||
ce a descoperit neasteptat**, atat;
|
||||
4. orchestratorul marcheaza story-ul in backlog si trece la urmatorul.
|
||||
|
||||
O story buna: are criteriu de acceptare care se poate RULA (un test, un grep, o comanda da/nu);
|
||||
atinge un singur fisier sau o singura zona (altfel story-urile se serializeaza intre ele); incape
|
||||
in 15-20 de linii de descriere; nu cere citirea intregului fisier ca sa fie inteleasa.
|
||||
|
||||
Sablon:
|
||||
|
||||
### S7 - garda pe randul protejat in recalcule
|
||||
Fisiere: COMUN\clase\<x>.vc2 (do_executa, recalc_tva_document)
|
||||
Blocat de: S4
|
||||
De facut: <2-4 propozitii>
|
||||
Acceptare: test_<y>.ps1 trece 12/12 SI `rand_protejat()` nu mai apare in nicio clauza Where
|
||||
Stare: todo
|
||||
|
||||
Cand un story pica de doua ori la rand, nu-l reincerca a treia oara cu acelasi prompt: semnul e ca
|
||||
descrierea sau criteriul e gresit, nu executia. Rescrie story-ul (mai mic, sau cu criteriul
|
||||
corectat) inainte de a mai cheltui un agent.
|
||||
Reference in New Issue
Block a user