El mockup muestra que una fila es etiqueta + uno o varios controles en la misma línea (Cliente = input + "...", Canal / Zona = dos mitades, Serie + Número = 72 px + resto, select + número + botón) y que la cabecera tiene a lo sumo 2 columnas. Los campos de un solo control no lo permitían. - Controles sin etiqueta combinables dentro de sbo-field: sbo-input, sbo-textarea, sbo-number, sbo-date, sbo-select y el botón .sbo-btn; ocupan el espacio sobrante o un width fijo. - El primer control de la fila toma el id de la etiqueta (claimId); los demás se nombran con ariaLabel. El error de la fila marca todos sus controles (aria-invalid / aria-describedby). - Los campos con etiqueta (sbo-text-field, sbo-number-field, ..., sbo-lookup-field) pasan a ser atajos de un solo control con la misma API. - CSS global: .sbo-group y .sbo-btn reemplazan a .sbo-pick/.sbo-pair. - CLAUDE.md apunta al mockup renombrado (tools/oferta_venta.html). - Verificado en Chrome contra SAP real, con una cabecera que reproduce las filas compuestas del mockup. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
31 lines
1.9 KiB
Markdown
31 lines
1.9 KiB
Markdown
# 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_*`) salvo `U_WEB_USER` / `U_WEB_PASS` de `EmployeesInfo`, 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/oferta_venta.html` (mockup de ejemplo: tiene algunos campos no estándar, pero se conserva la idea: filas de etiqueta + controles, máx. 2 columnas).
|
|
|
|
## 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 compila `libs/sap-types` (postinstall).
|
|
- `npm run dev:api` · `npm run dev:web` · `npm run build` · `npm test`.
|
|
|
|
## Flujo de trabajo por cliente (branches)
|
|
|
|
1. `main` es la versión base/genérica, sin personalizaciones de cliente.
|
|
2. Cada cliente tiene su branch (`cliente/<nombre-cliente>`); ahí viven sus personalizaciones y fixes.
|
|
3. Los cambios de una branch de cliente no se mezclan con `main` ni con otro cliente, salvo backport genérico decidido explícitamente.
|
|
4. Antes de crear branches, mergear a `main`, o hacer merge/backport entre clientes, confirmar con el usuario. No hacer `git push` sin confirmación.
|