mini-erp/CLAUDE.md

mini-erp

Integración web para SAP Business One (Service Layer). Es un monorepo con dos proyectos que siempre se instalan y despliegan juntos, orquestados por docker-compose.yml en la raíz.

Estructura

• mini-backend/ — API FastAPI (Python) que hace de puente hacia SAP Business One Service Layer (HANA).
  • main.py — entrypoint, registro de routers y middlewares.
  • routers/ — endpoints por dominio: auth, business_partners, items, sales, purchases, catalogs, batch, permissions, apigateway, reports.
  • core/ — lógica compartida: sap.py / hana.py (integración SAP/HANA), session.py (sesión y refresco), api_gateway.py, crud_router.py.
  • menu_permissions.json — se lee del disco en cada request (no se cachea), por lo que editarlo en el host aplica el cambio sin reiniciar el contenedor.
• mini-frontend/ — SPA en React 19 + TypeScript + Vite, Tailwind CSS 4, React Router 7.
  • src/views, src/components, src/layout, src/hooks, src/config, src/types, src/utils.

Levantar el entorno

docker compose up --build

• Backend expuesto en :8000, frontend en :80.
• Variables de entorno vía .env (backend) y build args VITE_API_URL/TZ (frontend). Ver .env.example.

Flujo de trabajo por cliente (branches)

Este repo es la base genérica del ERP. El flujo real de trabajo es:

1. main contiene la versión base/genérica de mini-backend + mini-frontend, sin personalizaciones de ningún cliente.
2. Cuando un cliente solicita el sistema, se crea una branch dedicada para ese cliente (convención: cliente/<nombre-cliente>).
3. Todas las personalizaciones, agregados y fixes específicos de ese cliente se desarrollan y versionan dentro de esa branch, nunca directamente en main.
4. Los fixes o cambios hechos en la branch de un cliente no deben mezclarse con main ni con la branch de otro cliente, salvo que se trate explícitamente de una mejora genérica que se decide llevar a main (backport consciente, no automático).
5. Antes de crear una branch nueva, mergear a main, o hacer merge/backport entre branches de clientes, confirmar con el usuario — son operaciones que afectan el versionamiento compartido y no deben asumirse.

Implicancias para el trabajo diario

• Si no se especifica lo contrario, asumir que el trabajo en curso es sobre la branch actual (base o de un cliente puntual), no sobre main.
• No hacer git push, merge hacia main, ni cherry-pick entre branches de clientes sin confirmación explícita.
• Si se detecta que se está en main y se pide una personalización que suena específica de un cliente, preguntar si corresponde crear/usar una branch de cliente en vez de modificar main directamente.