# Sistema de Compras y Gastos ## Descripcion General Documento canonico para el proceso integrado de Compras y Gastos del ERP, con trazabilidad end-to-end desde la necesidad inicial hasta el pago y conciliacion. Objetivo integral: - Unificar el flujo operativo y fiscal de compras y gastos. - Integrar Contabilidad, Tesoreria y Bancos en puntos de control clave. - Mantener un camino evolutivo por fases, sin romper contratos actuales. Alcance: - Compras de bienes y servicios. - Gastos operativos y administrativos. - Cuentas por pagar (CxP), ordenes de pago (OP) y ejecucion de pagos. - Soporte multiempresa y multimoneda. - Preparacion para conciliacion bancaria y workflow de aprobaciones. --- ## Opciones Configurables del Flujo | Opcion | Default | Aplica a | Impacto | |---|---|---|---| | Requisicion de compra | Opcional | Compras | Habilita o no la captura previa de necesidad antes de OC/Factura | | Modo de flujo de compras (`directo` / `requisicion_opcional` / `requisicion_obligatoria`) | `directo` | Compras | Define si se puede registrar compra directa sin requisicion | | Momento de impacto de stock en compra directa | `factura` | Compras directas | Permite operacion simplificada para empresas que no usan requisicion ni recepcion formal | | Orden de compra | Activado | Compras formales | Agrega cotizacion, aprobacion y control documental | | Recepcion | Activado | Bienes fisicos | Controla entrega, calidad e impacto de inventario | | Orden de pago | Activado | Compras y gastos a credito | Centraliza programacion y ejecucion de pagos | | Matching 3 vias | Activado | Compras con OC + recepcion + factura | Valida coherencia OC/recepcion/factura | | `config_compras.requiere_aprobacion` | `false` | OP y pagos | Si se activa, habilita flujo de aprobacion | | `config_compras.generar_cxp_automatico` | `true` | Compras | Genera CxP al registrar compra | | `config_compras.permitir_pago_parcial` | `false` | OP/CxP | Define politica de pago parcial | | `config_compras.usar_workflow` | `false` | OP | Habilita flujo base de aprobacion de OP (enviar/aprobar/rechazar) cuando la politica lo exige | | `config_compras.aplicar_pago_al_guardar` | `true` | OP | Si true, al guardar OP se aplica pago en la misma operacion | | `config_compras.permite_pago_sin_aprobacion` | `false` | OP | Excepcion controlada al `requiere_aprobacion`; si es `true` la OP puede ejecutarse sin pasar por workflow aun cuando la empresa lo exige | --- ## Arquitectura por Fases ### Fase 1 - Requisicion y solicitud **Objetivo:** capturar necesidad operativa antes de comprometer compra/gasto, con aprobacion por niveles. Pasos clave: 1. Solicitud con descripcion, cantidad y centro de costo. 2. Calculo automatico de monto estimado referencial (backend) para ruteo de aprobacion. 3. Aprobacion por nivel de monto y perfil. Integraciones esperadas: - Contabilidad: validacion de centro de costo y cuenta. - Tesoreria: impacto en flujo proyectado. Estado esperado: - `solicitada`, `en_revision`, `aprobada`, `rechazada`. Estado actual: - **Operativo configurable (F1 base)** con API publica de requisiciones y aprobaciones. - Presupuesto de requisiciones queda desacoplado del flujo operativo de aprobacion en esta release. - No es el flujo por defecto: la empresa puede operar en `directo` via `config_compras`. Regla de configuracion requerida: - Debe poder activarse o desactivarse por empresa. - Si la empresa opera en modo `directo`, se permite registrar compra/factura sin requisicion previa y con impacto de stock segun politica de la empresa. Politica operativa vigente F1: - Permiso real para aprobar y ver montos: `COMPRAS + EDITAR`. - Solicitante sin `COMPRAS + EDITAR`: no visualiza montos estimados en lista/detalle. - Requisicion de compra con item libre (`sin producto_id`) puede enviarse a aprobacion por necesidad y usa solo `nivel 1` activo. - Si todos los items son con producto/costo referencial, se mantiene aprobacion por monto. - El control economico final de items libres se completa en OC (precio en generacion/edicion de OC). ### Fase 2 - Orden de compra **Objetivo:** formalizar compra con proveedor, condiciones e impuestos. Pasos clave: 1. Cotizaciones y seleccion de proveedor. 2. Generacion de OC con detalle y condiciones. 3. Aprobacion de OC y envio al proveedor. Reglas clave: - Validacion de proveedor y datos fiscales. - Numeracion y estados controlados. Estado esperado (set base implementado): - `pendiente_aprobacion`, `pendiente`, `parcial`, `completada`, `cancelada`. Estado actual: - **Operativo (F2 base)** con API propia de OC, estados y validaciones de negocio. - `pendiente_aprobacion` se asigna automáticamente cuando `requiere_aprobacion` o `workflow_obligatorio` están activos; al aprobar pasa a `pendiente`. ### Fase 3 - Recepcion de bienes/servicios **Objetivo:** registrar recepcion total o parcial y validar calidad. Pasos clave: 1. Recepcion fisica o conformidad de servicio. 2. Control de diferencias y rechazos. 3. Documento de recepcion con trazabilidad a OC. Reglas clave: - Ajustes por cantidades recibidas. - Control de inventario para bienes fisicos. Estado actual: - **Operativo (F3 base)** con recepcion formal, control de excedentes y anulacion protegida por facturacion. ### Gate de avance a Fase 4 (cierre obligatorio de Fase 2 y 3) Antes de avanzar funcionalmente en Fase 4+ se debe cerrar Fase 2 y Fase 3 con estos criterios minimos: 1. Reglas de estado y transiciones estabilizadas para OC y recepcion (`pendiente_aprobacion`, `pendiente`, `parcial`, `completada`, `cancelada`). 2. Matching OC/recepcion/factura validado en escenarios de alta, edicion y anulacion sin regresiones. 3. Configuracion operativa visible en UI para activar/desactivar OC, recepcion y matching por empresa. 4. Pruebas de regresion (backend + frontend) ejecutadas sobre flujos OC y recepcion parcial/multiple. 5. Documentacion del comportamiento final alineada con implementacion real (sin estado "roadmap" para F2/F3 una vez cerradas). ### Estado de cierre F2/F3 (Bloque C) - 27/04/2026 1. Reglas de estado y transiciones OC/Recepcion: **Cumplido**. - OC: `pendiente_aprobacion`, `pendiente`, `parcial`, `completada`, `cancelada`. - Recepcion: `aplicada` y `anulada`. 2. Matching OC/Recepcion/Factura en alta/edicion/anulacion: **Cumplido (reglas backend)**. - Validacion de cantidades recibidas/facturadas por linea. - Bloqueo de anulacion de recepcion si la facturacion ya supera lo recibido tras revertir. 3. Configuracion operativa visible en UI por empresa: **Cumplido**. - Pestañas y campos dependientes de `config_compras` se habilitan/ocultan segun flags. 4. Pruebas de regresion backend + frontend: **Cumplido**. - Backend (Jest): `35 passed, 35 total` en suites de compras, pagos-proveedor, ordenes, recepciones y requisiciones. - Build backend: `npm run build` OK. - Build frontend: `npm run build` OK. 5. Documentacion alineada con implementacion real: **Cumplido**. - F2/F3 actualizadas a estado operativo base (no roadmap). 6. Gate de liberacion visual (QA UI + smoke): **Cumplido**. - Checklist A/B/C registrada con evidencia y rutas de reproduccion. - Ajuste aplicado: bloqueo explicito en UI de OC directa para `requisicion_obligatoria`. ### Fase 4 - Registro de compra/factura y gasto **Objetivo:** registrar documento fuente y consolidar impacto fiscal/contable. Compras (operativo actual): - Registro de compra con cabecera + detalle (`/compras`). - Soporte de impuestos, moneda, condicion operativa y anulacion. - Integracion con CxP y OP via `config_compras`. - Integracion contable no bloqueante: si falta mapeo o periodo, la compra persiste y se registra `cont_documentos` en estado BORRADOR para reintento via `POST /compras/:id/reintentar-contabilidad`. Gastos (operativo actual): - Registro de gasto con cabecera + items (`/gastos`). - Modelo hibrido: item por producto o libre por descripcion. - Validacion documental condicional: - si se informa documento, exige `timbrado`, `establecimiento`, `punto_expedicion`, `numero_factura` con zero-pad; - sin documento, permite guardar con `deducible=false`. - Integracion contable no bloqueante (si falta mapeo, no rompe persistencia); reintento via `POST /gastos/:id/reintentar-contabilidad`. Matching: - 3 vias (OC/recepcion/factura) operativo en validaciones transaccionales de compras. - Matching formal operativo por OC con reporte dedicado de estado global, detalle por linea y hallazgos. ### Fase 5 - Cuentas por pagar y orden de pago **Objetivo:** administrar deuda y pago a proveedor en flujo unificado. Operativo actual: - CxP unificada por origen (`origen_tipo`: `compra` | `gasto`, `origen_id`). - OP manual y automatica en compras (`origen`). - OP mixta (cuentas de compra + gasto del mismo proveedor). - Workflow base de OP operativo por configuracion (`enviar-aprobacion`, `aprobar`, `rechazar`). - Filtros por `origen_tipo` y campos normalizados de salida: - `origen_tipo`, `origen_id`, `documento_ref`, `fecha_origen` (y `monto_origen` donde aplica). Reglas clave: - Politica actual: pago exacto al saldo (sin pago parcial operativo). - No permitir pagar mas que saldo pendiente. - Si la aprobacion es obligatoria por `config_compras`, no se puede ejecutar OP desde `BORRADOR`. - Uso obligatorio de transacciones para consistencia CxP/pagos/OP. ### Fase 6 - Ejecucion de pagos y conciliacion bancaria **Objetivo:** ejecutar pago, cerrar deuda y preparar conciliacion. Operativo actual: - Ejecucion de OP (`POST /pagos-proveedor/:id/ejecutar`). - Anulacion de OP con reversa de impacto (`PATCH /pagos-proveedor/:id/anular`). - Aprobacion de OP (`PATCH /pagos-proveedor/:id/enviar-aprobacion`, `PATCH /pagos-proveedor/:id/aprobar`, `PATCH /pagos-proveedor/:id/rechazar`). - Reintento contable de OP `PAGADO` cuando la integracion quedo en BORRADOR (`POST /pagos-proveedor/:id/reintentar-contabilidad`). - Actualizacion de estados en CxP, compras y gastos segun saldo. - Puente OP -> Tesoreria: - al ejecutar/aplicar OP se genera `tes_movimientos` (`EGRESO`, `CONFIRMADO`) con `origen_tipo='ORDEN_PAGO_PROVEEDOR'`; - al anular OP se revierte movimiento y saldo de `tes_cuentas`; - depende de regla activa `tes_reglas.tipo_operacion='PAGO_PROVEEDOR'`. - Conciliacion manual endurecida: - conciliacion linea/movimiento valida cuenta, tipo, monto y unicidad de movimiento; - importacion PDF exige archivo valido y validaciones de payload por DTO. - Conciliacion automatizada base: - endpoint `POST /tes/conciliacion/extractos/:id/auto-conciliar`; - auto-match exacto por tipo/monto/fecha con tolerancia configurable; - tolerancia y `diferencia_maxima` con defaults escalados por moneda de la cuenta (PYG: tolerancia 1, diferencia 50.000; monedas con decimales: tolerancia 0.01, diferencia 10); - auto-creacion y conciliacion de movimientos para lineas bancarias de comision e ITF; - ajuste automatico de diferencias dentro de umbral configurable y marcado `sin_correspondencia` para remanentes. Roadmap: - Integracion bancaria completa multi-banco (formatos nativos/APIs) y reglas avanzadas por entidad. - Ajustes por comisiones, ITF y diferencias bancarias. ### Fase 7 - Clasificación contable de terceros (Acreedores / Proveedores del Exterior) **Objetivo:** distinguir contablemente proveedores locales, proveedores del exterior y acreedores varios sin fragmentar el catálogo maestro. Referencia canónica: `docs/plan-acreedores-proveedores-exterior.md`. Modelo: - `proveedores.tipo_entidad`: `PROVEEDOR_LOCAL` | `PROVEEDOR_EXTERIOR` | `ACREEDOR_VARIO`. Sincronizado con `proveedores.es_extranjero` (legacy). - `proveedores.cuenta_contable_id`: override manual (opcional). Debe ser cuenta hoja PASIVO/ACREEDORA. - `cuentas_pagar.cuenta_pasivo_id`: cuenta pasivo **congelada** al momento del asiento de compra/gasto/importación. La OP debita la misma cuenta que acreditó el documento origen, incluso si el proveedor se reclasifica posteriormente. - Conceptos contables: `PROVEEDORES`, `PROVEEDORES_EXTERIOR`, `ACREEDORES_VARIOS` en el mapeo por empresa (re-mapeables desde `Contabilidad → Mapeo`). Resolución de cuenta pasivo (`ContabilidadIntegracionService.resolverCuentaPasivo`): 1. Override manual (`proveedores.cuenta_contable_id`) si existe, activo y acepta movimientos. 2. Concepto contable según `tipo_entidad`. 3. Fallback duro a concepto `PROVEEDORES` (compatibilidad legacy). Bloqueos operativos (Fase 2 acreedores): - `ACREEDOR_VARIO` no puede usarse en Compras (`validateCabeceraRefs`), Órdenes de Compra ni Importaciones (`validateEmbarqueRefs`). Sólo opera vía Gastos. - Reclasificar un tercero a `ACREEDOR_VARIO` está bloqueado si tiene OC (estado ∉ `completada`/`cancelada`) o embarques activos (estado ∉ `CERRADO`/`CANCELADO`). Validaciones fiscales relajadas para `PROVEEDOR_EXTERIOR` (Fase 3): - `compras.service.ts::validateCreateOrUpdatePayload` pre-fetch `tipo_entidad`; para exterior salta los regex `\d{8}` (timbrado) y `\d{3}` (establecimiento/punto_expedición). Sólo controla largo máximo (invoice text puede contener letras/guiones). - `gastos.service.ts::normalizeDocumentoFiscal(input, { esExterior })`: acepta texto libre y fuerza `deducible=false` (sin IVA crédito local; se maneja vía aranceles de importación). - Frontend (`ComprasTemplate.jsx`): al seleccionar proveedor exterior, labels dinámicos ("Invoice / Nº documento", "Serie/prefijo", "Timbrado opcional") y bypass del zero-pad. Sólo obliga `numero_factura` para trazabilidad interna. Reclasificación asistida: - `PATCH /proveedores/:id/tipo-entidad` cambia `tipo_entidad` + `cuenta_contable_id` opcional + `motivo`. Auditado con snapshot de valor anterior/nuevo. - Devuelve `warning`: los saldos y asientos existentes **no migran**. Solo documentos nuevos usan la cuenta destino (la `cuenta_pasivo_id` ya está congelada en cada CxP). Reporte de clasificación: - `GET /proveedores/reporte-clasificacion?tipo_entidad=&activo=` — por tercero: tipo, cuenta override, `cuenta_efectiva_origen` (`OVERRIDE` | `CONCEPTO_PROVEEDORES` | `CONCEPTO_PROVEEDORES_EXTERIOR` | `CONCEPTO_ACREEDORES_VARIOS`), CxP abiertas y saldo agregado. - UI: `/reportes/compras/clasificacion-terceros` (Reportes → Administrativos y Financieros). Estado actual: **COMPLETADA** (Fase 1 schema + Fase 2 integración contable diferenciada + Fase 3 reclasificación/reporte/validaciones fiscales). --- ## Reglas de Negocio Transversales - Multiempresa obligatorio en todo documento operativo. - Validaciones fiscales PY en compras/gastos (RUC, timbrado, documentos, IVA) — **condicionales por `proveedores.tipo_entidad`**: `PROVEEDOR_EXTERIOR` acepta invoice text libre (ver Fase 7). - `ACREEDOR_VARIO` sólo opera vía Gastos; queda bloqueado en Compras, OC, Recepciones e Importaciones. - Transaccionalidad obligatoria para operaciones que afectan CxP, pagos y estados. - No sobrepago: el monto aplicado no puede exceder saldo pendiente. - Consistencia contable: - registro documental no debe romperse por faltante de mapeo; - la integracion contable puede quedar pendiente y reintentarse. - Diferencias contado vs credito: - Compras: CxP segun configuracion y condicion operativa. - Gastos: siempre generan CxP; contado crea CxP pagada (`saldo=0`), credito crea CxP pendiente. - Anulaciones protegidas: - no anular gasto con pagos aplicados; - anular OP revierte impactos y recalcula estados relacionados. --- ## Modelo de Datos Integrado (actual + extensible) Entidades operativas actuales: - `compra_cab`, `compra_det`, `compra_forma_pagos`, `compra_subtotales` - `gasto_cab`, `gasto_det`, `tipo_gasto` - `cuentas_pagar` (con `origen_tipo`, `origen_id`, `compra_id` legacy, `cuenta_pasivo_id` congelada) - `orden_pago_proveedor_cab`, `orden_pago_proveedor_det` - `pagos_proveedor` - `proveedores` (con `tipo_entidad`, `cuenta_contable_id`, `swift`, `banco_corresponsal`, `pais`) - `config_compras` Campos y conceptos clave: - `config_compras`: controla aprobaciones, auto-CxP, pagos parciales, workflow y aplicacion al guardar. - `cuentas_pagar`: - estados: `pendiente`, `parcial`, `pagada`, `vencida`, `anulada` - origen tipado para unificar compras y gastos. - `orden_pago_proveedor_cab`: - `origen`: `manual` o `compra_auto` - estado operativo: `BORRADOR`, `PENDIENTE_APROBACION`, `PENDIENTE`, `RECHAZADA`, `PAGADO`, `ANULADA`. ### Especificacion tecnica de `config_compras` (decision-complete) Campos operativos (backend + UI): - `habilitar_requisicion_compra: boolean` (default `false`) - `modo_flujo_compra: 'directo' | 'requisicion_opcional' | 'requisicion_obligatoria'` (default `'directo'`) - `afectar_stock_en_compra_directa: boolean` (default `true`) - `habilitar_orden_compra: boolean` (default `true`) - `habilitar_recepcion_compra: boolean` (default `true`) - `habilitar_matching_3_vias: boolean` (default `true`) - `requiere_aprobacion: boolean` (default `false`) - `usar_workflow: boolean` (default `false`) - `workflow_obligatorio: boolean` (default `false`) - `habilitar_orden_pago: boolean` (default `true`) - `generar_cxp_automatico: boolean` (default `true`) - `permitir_edicion_cxp: boolean` (default `true`) - `permitir_pago_parcial: boolean` (default `false`) - `aplicar_pago_al_guardar: boolean` (default `true`) - `permite_pago_sin_aprobacion: boolean` (default `false`) Reglas de precedencia y validacion: 1. Si `modo_flujo_compra='directo'`, se permite registrar compra/factura sin requisicion. 2. Si `modo_flujo_compra='requisicion_opcional'`, se permiten ambos caminos (directo y con requisicion). 3. Si `modo_flujo_compra='requisicion_obligatoria'`, compras y OC deben originarse en requisicion aprobada. 4. `afectar_stock_en_compra_directa=true`: la compra directa impacta stock al confirmar factura/compra. 5. `afectar_stock_en_compra_directa=false`: la compra directa no impacta stock en factura; el impacto debe ejecutarse en recepcion. 6. Si `afectar_stock_en_compra_directa=false`, entonces `habilitar_recepcion_compra=true` es obligatorio. 7. Si `afectar_stock_en_compra_directa=false` y `habilitar_recepcion_compra=false`, la configuracion es invalida y debe rechazarse. 8. Si `habilitar_recepcion_compra=false`, `habilitar_matching_3_vias` debe forzarse a `false`. 9. Si `workflow_obligatorio=true`, `usar_workflow=true` y `requiere_aprobacion=true`. 10. Si `habilitar_orden_compra=false`, no se permite operar endpoints de OC y recepcion formal. 11. Si `habilitar_orden_pago=false`, no se permite crear/ejecutar nuevas OP. 12. Si `permite_pago_sin_aprobacion=true`, la OP puede ejecutarse aunque `requiere_aprobacion=true`; aplica solo a OP y no afecta el bloqueo del flujo de compras u OC. Matriz de comportamiento (resumen): - Empresa simplificada: `modo_flujo_compra='directo'`, `habilitar_orden_compra=false`, `habilitar_recepcion_compra=false`, `habilitar_matching_3_vias=false`. - Empresa mixta: `modo_flujo_compra='requisicion_opcional'`, OC/recepcion habilitados, matching configurable. - Empresa controlada: `modo_flujo_compra='requisicion_obligatoria'`, OC + recepcion + matching + aprobaciones activas. Politica de stock por escenario: - `directo + afectar_stock_en_compra_directa=true`: impacto en factura/compra. - `directo + afectar_stock_en_compra_directa=false`: requiere recepcion habilitada; impacto en recepcion. - `requisicion_opcional` o `requisicion_obligatoria` con recepcion activa: impacto de stock definido por politica de empresa (factura o recepcion), manteniendo coherencia con matching configurado. Extensiones previstas: - workflow de aprobaciones (`workflow_id`, instancias, pasos, auditoria). - conciliacion bancaria y trazabilidad de extractos. - reglas avanzadas de matching (tolerancias configurables por proveedor/rubro y auto-resolucion asistida). --- ## APIs e Interfaces ### Órdenes de Compra / Recepciones - `POST /ordenes-compra` - `GET /ordenes-compra` - `GET /ordenes-compra/:id` - `GET /ordenes-compra/:id/matching-3-vias` - `PATCH /ordenes-compra/:id` - `PATCH /ordenes-compra/:id/aprobar` - `PATCH /ordenes-compra/:id/cancelar` - `POST /recepciones-compra` - `GET /recepciones-compra` - `GET /recepciones-compra/:id` - `PATCH /recepciones-compra/:id/anular` ### Compras - `POST /compras` - `GET /compras` - `GET /compras/:id` - `PATCH /compras/:id` - `PATCH /compras/:id/anular` - `POST /compras/:id/reintentar-contabilidad` - `GET /compras/proveedores/search` - `GET /compras/config` - `GET /compras/ultimo-costo` - `GET /compras/dashboard` - `GET /compras/libro-iva-compras` ### Proveedores / Acreedores (clasificación contable) - `GET /proveedores/search?tipo_entidad=` — filtro CSV para excluir `ACREEDOR_VARIO` en OC/importaciones o para listar solo acreedores en Gastos. - `PATCH /proveedores/:id/tipo-entidad` — reclasificación asistida (con motivo, auditado). - `GET /proveedores/reporte-clasificacion?tipo_entidad=&activo=` — vista consolidada con cuenta efectiva y saldo CxP abierto por tercero. ### Gastos - `POST /gastos` - `GET /gastos` - `GET /gastos/:id` - `PATCH /gastos/:id` - `PATCH /gastos/:id/anular` - `GET /gastos/tipos` - `POST /gastos/:id/reintentar-contabilidad` ### CxP y Orden de Pago Proveedor - `GET /pagos-proveedor` - `GET /pagos-proveedor/:id` - `POST /pagos-proveedor` - `POST /pagos-proveedor/:id/ejecutar` - `POST /pagos-proveedor/:id/reintentar-contabilidad` - `PATCH /pagos-proveedor/:id/anular` - `PATCH /pagos-proveedor/:id/enviar-aprobacion` - `PATCH /pagos-proveedor/:id/aprobar` - `PATCH /pagos-proveedor/:id/rechazar` - `GET /pagos-proveedor/dashboard` - `GET /pagos-proveedor/config` - `PUT /pagos-proveedor/config` - `GET /pagos-proveedor/cuentas-pendientes` - `GET /pagos-proveedor/cuentas-pagar` - `GET /pagos-proveedor/cuentas-pagar/dashboard` - `GET /pagos-proveedor/:id/pdf` ### Tesorería / Conciliación bancaria - `GET /tes/conciliacion/extractos` - `POST /tes/conciliacion/extractos` - `POST /tes/conciliacion/importar-pdf` - `GET /tes/conciliacion/extractos/:id` - `POST /tes/conciliacion/extractos/:id/auto-conciliar` - `POST /tes/conciliacion/lineas/:lineaId/conciliar` - `POST /tes/conciliacion/lineas/:lineaId/desconciliar` - `POST /tes/conciliacion/lineas/:lineaId/sin-correspondencia` - `DELETE /tes/conciliacion/lineas/:lineaId/sin-correspondencia` - `POST /tes/conciliacion/lineas/:lineaId/crear-movimiento` - `PATCH /tes/conciliacion/lineas/:lineaId` - `GET /tes/conciliacion/extractos/:id/diferencias` Extensiones de interfaz para configuracion de flujo: - `GET /pagos-proveedor/config` y `PUT /pagos-proveedor/config` deben incluir, sin breaking changes: - `habilitar_requisicion_compra` - `modo_flujo_compra` - `afectar_stock_en_compra_directa` - `habilitar_orden_compra` - `habilitar_recepcion_compra` - `habilitar_matching_3_vias` - `habilitar_orden_pago` Compatibilidad de contratos: - Sin cambios breaking en endpoints base. - Respuesta de CxP/OP documenta extension de campos: - `origen_tipo`, `origen_id`, `documento_ref`, `fecha_origen`, `monto_origen`. - Se mantiene compatibilidad con `compra_id` y relaciones legacy. --- ## Mapa de Integraciones por Area - **Contabilidad** - Integracion de compra, gasto y orden de pago. - IVA credito fiscal, cuentas de gasto y CxP proveedor. - Reversion contable en anulaciones. - **Tesoreria** - Programacion y ejecucion de pagos. - Politicas operativas por `config_compras`. - **Bancos** - Generacion de comprobantes y base para conciliacion. - Evolucion a flujo de extractos y conciliacion automatizada. - **Inventario** - Impacto de compras y movimientos asociados. - Control de recepcion/stock en fases avanzadas. --- ## Trazabilidad y Auditoria Cadena objetivo: - Requisicion -> Orden de compra -> Recepcion -> Factura/Compra o Gasto -> CxP -> Orden de pago -> Pago -> Conciliacion. Puntos de control: - Auditoria de anulaciones y cambios de estado. - Integracion contable con reintento y registro de pendientes. - Evidencia documental por proveedor y por origen (`compra`/`gasto`). --- ## Plan de Pruebas End-to-End 1. Cobertura de fases: - validar que el flujo documentado cubra Fase 1 a Fase 6 sin huecos. 2. Compras: - alta, listado, dashboard, anulacion y consistencia con CxP/OP. 3. Gastos: - alta con/sin documento, deducibilidad, estado por forma de pago, anulacion protegida. 4. CxP/OP unificado: - listado filtrado por `origen_tipo`, ordenes mixtas compra+gasto, ejecucion y anulacion. 5. Consistencia de estados: - compra/gasto/CxP/OP/pago deben quedar coherentes tras ejecutar o revertir operaciones. 6. Compatibilidad de interfaces: - validar que contratos actuales se mantienen y extensiones son opcionales. 7. Calidad documental: - revisar legibilidad, no redundancia y alineacion con formato estandar de docs. 8. Configuracion de flujo de compra: - validar modo `directo` vs `requisicion_opcional` vs `requisicion_obligatoria` y su impacto en stock y validaciones. 9. Gate F2/F3: - no habilitar avance funcional de fases siguientes sin check verde de criterios de cierre de OC y recepcion. 10. Configuracion por empresa (matriz): - validar reglas de precedencia de `config_compras` y bloqueo/habilitacion correcta de endpoints/acciones UI. --- ## QA Manual UI F2/F3 (Checklist de pantallas + Go/No-Go) Fecha de control: **27/04/2026**. ### Alcance de pantallas - Requisiciones - Ordenes de compra - Recepciones - Facturas (compra) ### Precondiciones - Build backend y frontend en verde. - Datos base de proveedor, sucursal, moneda y productos disponibles. - Configuracion `config_compras` accesible para alternar flags. ### Matriz de ejecucion obligatoria | Escenario | Configuracion esperada | Resultado esperado en UI | |---|---|---| | A. Flujo directo simplificado | `habilitar_requisicion_compra=false`, `habilitar_orden_compra=false`, `habilitar_recepcion_compra=false` | Solo pestaña `Facturas` (y `Gastos` si modulo activo). Sin campos de requisicion/OC en formulario de compra. | | B. Flujo mixto | `modo_flujo_compra='requisicion_opcional'`, OC/Recepcion habilitadas | Pestañas visibles: Requisiciones, Ordenes de compra, Recepciones, Facturas. | | C. Flujo controlado | `modo_flujo_compra='requisicion_obligatoria'`, OC/Recepcion habilitadas | Alta de compra/OC sin requisicion debe bloquear con mensaje funcional claro. | ### Checklist por pantalla | Pantalla | Verificacion manual | Estado | |---|---|---| | Requisiciones | Respeta filtros rapidos, busqueda, paginacion y botones de accion sin romper layout desktop/mobile | OK | | Requisiciones | En escenario A la pestaña no debe mostrarse | OK | | Ordenes de compra | Selector de proveedor visible/usable (texto completo, sin recortes invalidos) | OK | | Ordenes de compra | Alta, aprobacion y cancelacion muestran estados correctos y refrescan listado | OK | | Ordenes de compra | En escenario A la pestaña no debe mostrarse | OK | | Recepciones | Alta parcial/multiple desde OC valida cantidades y evita excedentes | OK | | Recepciones | Anulacion bloqueada cuando la facturacion ya supera lo recibido tras revertir | OK | | Recepciones | En escenario A la pestaña no debe mostrarse | OK | | Facturas | Mantiene UX base (filtros, resumen, tabla y acciones) consistente con modulo Compras | OK | | Facturas | Si OC/Requisicion estan deshabilitadas, no renderiza campos asociados ni mensajes residuales | OK | | Facturas | Con matching activo, bloquea inconsistencias de cantidad/precio por linea | OK | ### Evidencia tecnica disponible - Backend smoke F1/F2/F3: `npm run test:smoke:f2f3` -> `35/35` en verde. - Backend smoke flujo integrado Compras/Gastos: `npm run test:smoke:compras-gastos-e2e` -> `1/1` en verde. - Smoke de flujo UI A/B/C: `npm run smoke:f2f3` -> `OK smoke F2/F3 config flow A/B/C`. - Tests backend globales: `npm test -- --runInBand` -> `45/45` en verde (incluye correccion de `app.controller.spec.ts` y smoke integrado Compras/Gastos). - Build backend: `npm run build` OK. - Build frontend: `npm run build` OK. - Evidencias por caso (resultado, severidad, ruta): `backend/docs/qa-f2f3-evidencia-2026-04-27.md`. ### Dictamen Go/No-Go F2/F3 - Estado actual: **GO**. - Nota de cierre documental: evidencia visual (capturas desktop/mobile) pendiente de adjuntar en `qa-f2f3-evidencia-2026-04-27.md` para auditoría formal. - Condiciones cumplidas: 1. Checklist A/B/C completo sin defectos bloqueantes. 2. Sin bloqueos funcionales en alta/edicion/anulacion de OC/Recepciones/Facturas. 3. Verificacion tecnica integral en verde (smokes, tests y builds). --- ## Supuestos y Defaults - Documento canonico unico para este dominio: `backend/docs/plan-compras-gastos.md`. - Alcance de diseno: end-to-end completo con implementacion por etapas. - Nivel de detalle: mixto funcional + tecnico. - Prioridad de ejecucion: cerrar Fase 2 y 3 antes de expandir alcance operativo de Fase 4+. - Requisicion de compra configurable por empresa (incluyendo modo de compra directa para empresas que no usan requisicion). - Estado actual: - requisiciones, compras, gastos, CxP y OP operativos (con F1 configurable por empresa); - workflow base de aprobacion OP operativo; workflow integral multinivel y conciliacion bancaria automatizada en roadmap. - Se prioriza continuidad operativa y compatibilidad de contratos existentes.