gomag-vending/CLAUDE.md

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:

1. Lucrezi pe branch fix/* sau feat/*
2. ./test.sh ci manual inainte de push (~30s); la git push pe branch non-main, CI Gitea (.gitea/workflows/test.yaml) ruleaza ./test.sh ci automat
3. Inainte de PR → ./test.sh full manual (~2-3 min)
4. 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

1. Download GoMag API → JSON → parse → validate SKU-uri → import Oracle
2. Ordinea: parteneri (cauta/creeaza) → adrese → comanda → factura cache
3. SKU lookup: ARTICOLE_TERTI (mapped) are prioritate fata de NOM_ARTICOLE (direct)
4. Complex sets (kituri/pachete): un SKU → multiple CODMAT-uri cu cantitate_roa; preturile se preiau din lista de preturi Oracle
5. 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: IMPORTED existent NU se suprascrie cu ALREADY_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_fiscal doar RO<cifre> si RO <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.

Retry/resync/batch retry TREBUIE sa paseze retry_service.anaf_import_kwargs(order) la import_single_order (altfel cauta dual si prinde gemenul fara RO). Diagnostic prod partener gresit + acces SSH read-only: docs/diagnostic-prod-partener-gresit.md

Preturi

• Dual policy: articolele sunt rutate la id_pol_vanzare sau id_pol_productie pe 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_* pe orders (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