david
cf07de4836
- Implemented `evaluateProformaCustomerChange` function to assess changes in customer details for proforma invoices. - Introduced types for customer change details, blockers, field differences, and fiscal targets. - Added utility functions for normalizing text and formatting recipient information. test: add unit tests for customer payment resolver - Created tests for `CustomerPaymentResolver` to validate payment term retrieval and handling of inactive terms. - Ensured proper behavior when clearing payment terms and handling non-existent terms. test: add unit tests for customer default payment term resolver - Developed tests for `CustomerDefaultPaymentTermResolver` to verify default payment term resolution logic. - Included scenarios for creating customers with and without explicit payment term IDs. feat: implement customer default payment term resolver - Created `CustomerDefaultPaymentTermResolver` to manage default payment term resolution during customer creation. - Integrated with company finder and payment resolver services. test: add unit tests for create customer use case - Implemented tests for `CreateCustomerUseCase` to ensure correct handling of payment term IDs during customer creation. - Validated behavior when no explicit payment term ID is provided. test: add unit tests for update customer use case - Developed tests for `UpdateCustomerUseCase` to verify payment term handling during customer updates. - Ensured that inactive payment terms are not assigned and that explicit null values are respected. feat: add dependency injection for customer company services - Implemented DI for customer company dependencies to facilitate service resolution. test: add tests for customer create data utility - Created tests for `buildCustomerCreateData` to validate payment term handling based on user input. |
||
|---|---|---|
| .. | ||
| architecture | ||
| catalogs | ||
| companies/sql | ||
| customer-invoices | ||
| customers | ||
| dev | ||
| document-series | ||
| factuges | ||
| frontend | ||
| settings | ||
| API.md | ||
| backend-prompt-base.md | ||
| CONVENCION NOMBRADO DE ESQUEMAS DTO.md | ||
| DsRegistroVeriFactu.xlsx | ||
| DTOS - GUÍA DE DISEÑO.md | ||
| FACTURAS DE CLIENTE.md | ||
| prompt-auth.md | ||
| prompt-customer-invoices.md | ||
| README.md | ||
| REQUISITOS CLIENTES.md | ||
| REQUISITOS GENERALES.md | ||
| TEMPLATE.md | ||
ERP Docs
Este directorio reúne la documentación técnica, operativa y de apoyo del ERP.
Cómo leer esta documentación
- Empieza por este índice si necesitas orientarte.
- Usa los documentos en subdirectorios temáticos como fuente de verdad operativa.
- Trata los documentos marcados como históricos o legacy como contexto, no como contrato vigente.
Estructura documental
Documentación vigente
Arquitectura y runtime
- Arquitectura general
- Contexto tenant y
X-Company-Id - Tratamiento de errores HTTP en frontend
- API de autenticación de
identity - Relación entre
identityycompanies - Estado de migración a
identity
Frontend
- Flujo de auth y selección de empresa
- Sistema modular de Settings
- Integración de módulos con Settings
- README de
apps/web
Customer invoices y proformas
- Índice de
customer-invoices - Plazos de pago
- Diseño backend del perfil VeriFactu empresarial
- Diseño frontend de Settings para VeriFactu
- Contrato de series de proformas
- Contrato de create de proformas
- Configuración fiscal persistida en proformas
- Reports de proformas
Document series
- README de
document-series - Diseño de
document-series - Validación manual de
document-series - Validación manual de concurrencia
Módulos y runtime local
- README de
modules/identity - README de
modules/companies - README de
modules/auth - API pública de selección y alta rápida de clientes
Guías y estándares
- [Guía de diseño de DTOs](./DTOS - GUÍA DE DISEÑO.md)
- [Convención de nombres de schemas DTO](./CONVENCION NOMBRADO DE ESQUEMAS DTO.md)
SQL operativos y runbooks
Material auxiliar
Histórico, transicional o de descubrimiento
Estos documentos se conservan por trazabilidad, auditoría o contexto de decisiones. No deben usarse como fuente de verdad del runtime actual sin contrastarlos con la documentación vigente.
- Borrador legacy de API
- [Requisitos generales históricos](./REQUISITOS GENERALES.md)
- [Requisitos históricos del módulo de clientes](./REQUISITOS CLIENTES.md)
- [Notas históricas de facturas de cliente](./FACTURAS DE CLIENTE.md)
- Split histórico Proforma / IssuedInvoice
- Migración desde
customer_invoice_series - InvoiceSeries legacy
Regla práctica de mantenimiento
- Los documentos operativos vigentes deben vivir en subdirectorios temáticos y tener una responsabilidad clara.
- Los documentos raíz en mayúsculas o con naming heredado deben considerarse legacy o auxiliares salvo que este índice los declare explícitamente vigentes.
- Si una regla ya tiene fuente canónica, los demás documentos deben resumirla y enlazarla, no copiarla.