- apps/web: Angular 22 standalone, zoneless, OnPush, vitest; proxy /api hacia el backend; presupuesto de bundle (aviso 260 kB, error 400 kB). - libs/sap-types: tipos de auth/permisos/Service Layer y el evaluador de patrones de menú, compartidos por api y web (se compila en postinstall). El backend deja de tener su propia copia del evaluador. - Temas por variables CSS: claro por defecto con la paleta del mockup de Oferta de ventas, oscuro incluido; ThemeService + selector, con el tema guardado aplicado antes del primer pintado. Agregar un tema = 1 css + 1 import + 1 entrada. - Criterios de interfaz ligera en CLAUDE.md y README. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
1.8 KiB
1.8 KiB
basic-erp
ERP base para SAP Business One (Service Layer). Monorepo npm workspaces:
apps/api— NestJS: proxy hacia el Service Layer, login, sesión SAP compartida, permisos de menú (SQLite).apps/web— Angular: componentes reutilizables estilo SAP Business One.libs/sap-types— tipos TypeScript compartidos entre api y web.tools/— mockups y colecciones de pruebas.
Reglas del proyecto base
- Solo campos estándar de SAP Business One. Ningún campo de usuario (
U_*) salvoU_WEB_USER/U_WEB_PASSdeEmployeesInfo, usados para el login web. - Los formularios se construyen con componentes reutilizables y configuración declarativa; no se duplica markup por documento.
- Los colores y el aspecto salen de variables CSS (temas). Tema por defecto: claro, con la paleta de
tools/Cotizador Aberio · Oferta de ventas.html.
Criterios de la interfaz
Es un ERP, no una página de publicidad: ligera y rápida. Sin librerías de componentes (Material/PrimeNG), sin webfonts ni animaciones, componentes propios y densos, zoneless + OnPush, rutas con carga diferida, presupuesto de bundle en angular.json, listas largas paginadas en el servidor.
Comandos
npm install(npm 11) instala todo y compilalibs/sap-types(postinstall).npm run dev:api·npm run dev:web·npm run build·npm test.
Flujo de trabajo por cliente (branches)
maines la versión base/genérica, sin personalizaciones de cliente.- Cada cliente tiene su branch (
cliente/<nombre-cliente>); ahí viven sus personalizaciones y fixes. - Los cambios de una branch de cliente no se mezclan con
mainni con otro cliente, salvo backport genérico decidido explícitamente. - Antes de crear branches, mergear a
main, o hacer merge/backport entre clientes, confirmar con el usuario. No hacergit pushsin confirmación.