1. SQLite order_items overwrite on re-import (VELA CAFE #484669620): add_order_items, save_orders_batch, mark_order_deleted_in_roa now use DELETE + INSERT so GoMag quantity changes propagate to dashboard. 2. PL/SQL strict CUI lookup tolerates whitespace (FG COFFE #485065210): cauta_partener_dupa_cod_fiscal regex ^RO\d → ^RO\s*\d; IN-set uses canonical v_ro_cui. Platitor/neplatitor business rule preserved. Python defensive: re.sub whitespace collapse in determine_partner_data. 3. New PJ partners use ANAF official denumire (denumire_override) instead of GoMag company_name. Existing partners (found by CUI) untouched. Tests: 18 new (5 SQLite unit, 8 Python unit, 5 Oracle PL/SQL). All green locally: 228 unit + 26 oracle + 33 e2e. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
5.3 KiB
CLAUDE.md
Project Overview
System: Import Comenzi Web GoMag → Sistem ROA Oracle Stack: FastAPI + Jinja2 + Bootstrap 5.3 + Oracle PL/SQL + SQLite
Documentatie completa: README.md
Implementare cu TeamCreate
OBLIGATORIU: Folosim TeamCreate + TaskCreate, NU Agent tool cu subagenti paraleli. Skill-ul superpowers:dispatching-parallel-agents NU se aplica in acest proiect.
- Team lead citeste TOATE fisierele implicate, creeaza planul
- ASTEAPTA aprobare explicita de la user inainte de implementare
- Task-uri pe fisiere non-overlapping (evita conflicte)
- Cache-bust static assets (
?v=N) la fiecare schimbare UI
Development Commands
# INTOTDEAUNA via start.sh (seteaza Oracle env vars)
./start.sh
# NU folosi uvicorn direct — lipsesc LD_LIBRARY_PATH si TNS_ADMIN
Testing & CI/CD
# Teste rapide (unit + e2e, ~30s, fara Oracle)
./test.sh ci
# Teste complete (totul inclusiv Oracle + sync real + PL/SQL, ~2-3 min)
./test.sh full
# Smoke test pe productie (read-only, dupa deploy)
./test.sh smoke-prod --base-url http://79.119.86.134/gomag
# Doar un layer specific
./test.sh unit # SQLite CRUD, imports, routes
./test.sh e2e # Browser tests (Playwright)
./test.sh oracle # Oracle integration
./test.sh sync # Sync real GoMag → Oracle
./test.sh qa # API health + responsive + log monitor
./test.sh logs # Doar log monitoring
# Validate prerequisites
./test.sh --dry-run
Flow zilnic:
- Lucrezi pe branch
fix/*saufeat/* git push→ pre-push hook ruleaza./test.sh ciautomat (~30s)- Inainte de PR →
./test.sh fullmanual (~2-3 min) - Dupa deploy pe prod →
./test.sh smoke-prod --base-url http://79.119.86.134/gomag
Output: qa-reports/ — health score, raport markdown, screenshots, baseline comparison.
Markers pytest: unit, oracle, e2e, qa, sync
Reguli critice (nu le incalca)
Flux import comenzi
- Download GoMag API → JSON → parse → validate SKU-uri → import Oracle
- Ordinea: parteneri (cauta/creeaza) → adrese → comanda → factura cache
- SKU lookup: ARTICOLE_TERTI (mapped) are prioritate fata de NOM_ARTICOLE (direct)
- Complex sets (kituri/pachete): un SKU → multiple CODMAT-uri cu
cantitate_roa; preturile se preiau din lista de preturi Oracle - Comenzi anulate (GoMag statusId=7): verifica daca au factura inainte de stergere din Oracle
Statusuri comenzi
IMPORTED / ALREADY_IMPORTED / SKIPPED / ERROR / CANCELLED / DELETED_IN_ROA
- Upsert:
IMPORTEDexistent NU se suprascrie cuALREADY_IMPORTED - Recovery: la fiecare sync, comenzile ERROR sunt reverificate in Oracle
Parteneri
- Prioritate: companie (PJ, cod_fiscal + registru) daca exista in GoMag (name SAU code), altfel persoana fizica cu shipping name
- Adresa livrare: intotdeauna GoMag shipping
- Adresa facturare PJ: adresa billing din GoMag (sediul firmei)
- Adresa facturare PF: adresa shipping din GoMag (ramburs curier pe numele destinatarului)
Cautare partener PJ dupa cod fiscal (ANAF strict mode)
Cand avem date ANAF (anaf_strict=1), PL/SQL cauta_partener_dupa_cod_fiscal diferentiaza intre platitor si neplatitor TVA:
- Platitor TVA (scpTVA=True) → cauta in
nom_parteneri.cod_fiscaldoarRO<cifre>siRO <cifre>(cu/fara spatiu) - Neplatitor TVA (scpTVA=False) → cauta doar forma bare
<cifre> - Nu cross-match intre platitor si neplatitor — entitati fiscal distincte
- Fallback non-strict (
NULL): toate 3 formele (anti-dedup la ANAF down)
Python normalizeaza CUI-ul (re.sub(r'\s+', '', ...)) inainte de apel Oracle. La creare partener NOU PJ, se foloseste numele oficial ANAF (denumire_anaf) in loc de GoMag company_name (poate avea typos); partenerii existenti nu sunt atinsi.
Preturi
- Dual policy: articolele sunt rutate la
id_pol_vanzaresauid_pol_productiepe baza contului contabil (341/345 = productie) - Daca pretul lipseste, se insereaza automat pret=0
Dashboard paginare
- Contorul din paginare arata totalul comenzilor din perioada selectata (ex: "378 comenzi"), NU doar cele filtrate
- Butoanele de filtru (Importat, Omise, Erori, Facturate, Nefacturate, Anulate) arata fiecare cate comenzi are pe langa total
- Aceasta este comportamentul dorit: userul vede cate comenzi totale sunt, din care cate importate, cu erori etc.
Invoice cache
- Coloanele
factura_*peorders(SQLite), populate lazy din Oracle (vanzari WHERE sters=0) - Refresh complet: verifica facturi noi + facturi sterse + comenzi sterse din ROA
Sync articole VENDING → MARIUSM_AUTO
# Dry-run (arată diferențele fără să modifice)
python3 scripts/sync_vending_to_mariusm.py
# Aplică cu confirmare
python3 scripts/sync_vending_to_mariusm.py --apply
# Fără confirmare (automatizare)
python3 scripts/sync_vending_to_mariusm.py --apply --yes
Sincronizează via SSH din VENDING (prod Windows) în MARIUSM_AUTO (dev ROA_CENTRAL): nom_articole (noi by codmat, codmat updatat) + articole_terti (noi, modificate, soft-delete).
Design System
Always read DESIGN.md before making any visual or UI decisions. All font choices, colors, spacing, and aesthetic direction are defined there. Do not deviate without explicit user approval. In QA mode, flag any code that doesn't match DESIGN.md.
Deploy Windows
Vezi README.md