Plan de Pruebas — Módulo de Compras y Gastos --- Conceptos clave antes de empezar ┌──────────────────────────────┬──────────────────────────────────────────────────────────────────────────────────────────────┐ │ Término │ Qué es en la práctica │ ├──────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤ │ Requisición │ Solicitud interna de compra/gasto antes de comprometer dinero │ ├──────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤ │ Montos en requisición │ Se calculan por costo referencial backend; solicitante no carga precios │ ├──────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤ │ Permiso de aprobación F1 │ `COMPRAS + EDITAR`: habilita aprobar/rechazar y ver importes │ ├──────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤ │ Orden de Compra (OC) │ Documento formal al proveedor, con estados operativos y control de cantidades │ ├──────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤ │ Recepción │ Registro de lo efectivamente recibido (total/parcial) contra la OC │ ├──────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤ │ Matching 3 vías │ Validación entre OC + Recepción + Factura/Compra por línea (cantidad/precio) │ ├──────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤ │ Compra (Factura de compra) │ Documento fiscal de proveedor que impacta inventario (según configuración) y CxP │ ├──────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤ │ Gasto │ Egreso operativo/administrativo, con o sin documento fiscal │ ├──────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤ │ CxP │ Cuenta por pagar generada por compra o gasto (`origen_tipo`: compra | gasto) │ ├──────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤ │ OP │ Orden de pago a proveedor (manual o automática según configuración) │ ├──────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤ │ Política de pago en OP │ Depende de `permitir_pago_parcial`: exacto al saldo (`false`) o monto <= saldo (`true`) │ ├──────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤ │ Modo de flujo de compra │ `directo`, `requisicion_opcional`, `requisicion_obligatoria` │ ├──────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤ │ Escenario A/B/C │ A: directo simplificado, B: mixto, C: controlado con requisición obligatoria │ └──────────────────────────────┴──────────────────────────────────────────────────────────────────────────────────────────────┘ --- Flujo obligatorio antes de cualquier prueba 1. Definir escenario de configuración por empresa (A, B o C) en `config_compras`. 2. Verificar datos maestros: - proveedor activo, sucursal, moneda, productos con IVA, tipo de gasto, centro de costo. 3. Confirmar que las pestañas de Compras se muestran según escenario (Requisiciones/Órdenes/Recepciones/Facturas). 4. Ejecutar pruebas operativas por fase (F1 a F6) en orden. 5. Ejecutar bloque de QA técnico al final. --- Datos de prueba reutilizables ┌──────────────────────────┬──────────────────────────────────────┐ │ Dato │ Valor sugerido │ ├──────────────────────────┼──────────────────────────────────────┤ │ Proveedor │ Proveedor Demo Compras SA │ ├──────────────────────────┼──────────────────────────────────────┤ │ Sucursal │ Casa Matriz │ ├──────────────────────────┼──────────────────────────────────────┤ │ Moneda │ PYG │ ├──────────────────────────┼──────────────────────────────────────┤ │ Producto 1 │ Papel A4 (stock, IVA 10%) │ ├──────────────────────────┼──────────────────────────────────────┤ │ Producto 2 │ Tóner (stock, IVA 10%) │ ├──────────────────────────┼──────────────────────────────────────┤ │ Tipo de gasto │ Servicios administrativos │ ├──────────────────────────┼──────────────────────────────────────┤ │ Centro de costo │ Administración │ ├──────────────────────────┼──────────────────────────────────────┤ │ Fecha base │ Hoy │ ├──────────────────────────┼──────────────────────────────────────┤ │ OC monto referencia │ Gs. 1.500.000 │ ├──────────────────────────┼──────────────────────────────────────┤ │ Gasto monto referencia │ Gs. 450.000 │ └──────────────────────────┴──────────────────────────────────────┘ --- FASE 1 — Requisiciones (operativas y configurables) --- PRUEBA 1.1 — Crear requisición de compra en borrador Dónde: Compras → pestaña Requisiciones → Nueva requisición Pasos: 1. Seleccionar origen `compra`. 2. Completar cabecera con sucursal y descripción. 3. Agregar ítem con centro de costo + producto + cantidad. 4. Guardar. Resultado esperado: - Requisición creada en estado `borrador`. - El solicitante no carga ni visualiza precios. - Queda visible en listado con acciones de edición/envío. Resultado negativo (si falla): - Si falta centro de costo o cantidad <= 0: mensaje de validación y no guarda. --- PRUEBA 1.2 — Enviar requisición a aprobación Dónde: Compras → Requisiciones → acción "Enviar aprobación" Pasos: 1. Tomar requisición en `borrador`. 2. Ejecutar "Enviar aprobación". Resultado esperado: - Estado cambia a `pendiente_aprobacion`. - Se registran niveles de aprobación configurados. Resultado negativo (si falla): - Si no hay configuración de niveles para monto/origen: bloqueo con mensaje funcional. --- PRUEBA 1.3 — Envío de requisición con ítem libre en origen compra Dónde: Compras → Requisiciones → acción "Enviar aprobación" Pasos: 1. Crear requisición de compra con al menos una línea sin producto (`ítem libre`). 2. Intentar enviar a aprobación. Resultado esperado: - El sistema permite el envío y crea workflow de aprobación con solo `nivel 1` activo para compra. - La requisición queda en `pendiente_aprobacion`. Resultado negativo (si falla): - Si bloquea el envío con ítem libre: defecto funcional. - Si asigna niveles distintos de `nivel 1`: defecto de regla de negocio. --- PRUEBA 1.4 — Aprobar y rechazar requisición (rol aprobador) Dónde: Compras → Requisiciones → Detalle Pasos: 1. Ingresar con usuario que tenga `COMPRAS + EDITAR` y perfil aprobador del nivel. 2. Aprobar una requisición en `pendiente_aprobacion`. 3. En otra requisición, ejecutar rechazo con motivo. Resultado esperado: - Aprobada: estado `aprobada`. - Rechazada: estado `rechazada` y motivo registrado. Resultado negativo (si falla): - Si se intenta aprobar/rechazar fuera de `pendiente_aprobacion`: operación bloqueada. - Si el usuario no tiene `COMPRAS + EDITAR`: bloqueo por permiso. --- PRUEBA 1.5 — Visibilidad de montos por rol Dónde: Compras → Requisiciones (lista y detalle) Pasos: 1. Ingresar con solicitante sin `COMPRAS + EDITAR`. 2. Revisar lista y detalle de requisiciones. 3. Ingresar con aprobador con `COMPRAS + EDITAR` y repetir la revisión. Resultado esperado: - Solicitante: no ve `Total estimado` ni importes por línea. - Aprobador: sí ve montos para decisión. Resultado negativo (si falla): - Si un solicitante sin permiso ve montos: defecto crítico de seguridad funcional. --- PRUEBA 1.6 — Cancelar requisición por estado permitido/no permitido Dónde: Compras → Requisiciones Pasos: 1. Cancelar requisición en `borrador` o `aprobada`. 2. Intentar cancelar requisición `ejecutada_total`. Resultado esperado: - Caso permitido: estado `cancelada`. - Caso no permitido: mensaje de bloqueo sin cambios. Resultado negativo (si falla): - Si permite cancelar `ejecutada_total`: defecto crítico. --- PRUEBA 1.7 — Generar OC y gasto desde requisición aprobada Dónde: - Requisición origen compra → acción "Crear orden de compra" - Requisición origen gasto → acción "Crear gasto" Pasos: 1. Crear requisición de compra, aprobarla y generar OC. 2. Crear requisición de gasto, aprobarla y generar gasto. Resultado esperado: - Se crean documentos de salida vinculados a la requisición. - Avance de ejecución de requisición se actualiza (`ejecutada_parcial`/`ejecutada_total` según cobertura). Resultado negativo (si falla): - Si origen no coincide (ej. gasto -> OC): bloqueo con mensaje funcional. --- FASE 2 — Órdenes de Compra (OC) --- PRUEBA 2.1 — Crear OC en escenario B (`requisicion_opcional`) Dónde: Compras → pestaña Órdenes de compra → Nueva orden Pasos: 1. Configurar escenario B. 2. Crear OC con proveedor, moneda e ítems. 3. Guardar. Resultado esperado: - OC creada en `pendiente` o `pendiente_aprobacion` según `requiere_aprobacion`. - Número de orden generado. Resultado negativo (si falla): - Si faltan ítems o proveedor: no guarda y muestra validación. --- PRUEBA 2.2 — Bloqueo de OC directa en escenario C (`requisicion_obligatoria`) Dónde: Compras → pestaña Órdenes de compra Pasos: 1. Configurar escenario C. 2. Intentar crear OC directa sin origen en requisición. Resultado esperado: - UI bloquea acción "Nueva orden" y/o muestra advertencia funcional. - Backend rechaza creación sin `requisicion_id`. Resultado negativo (si falla): - Si permite OC directa en escenario C: defecto crítico de regla de negocio. --- PRUEBA 2.3 — Aprobar OC en pendiente de aprobación Dónde: Compras → Órdenes de compra → acción Aprobar Pasos: 1. Tomar OC en `pendiente_aprobacion`. 2. Aprobar. Resultado esperado: - Estado pasa a `pendiente`. Resultado negativo (si falla): - Si aprueba OC `cancelada` o `completada`: debe bloquearse. --- PRUEBA 2.4 — Cancelación protegida por recepciones Dónde: Compras → Órdenes de compra → acción Cancelar Pasos: 1. Cancelar una OC sin recepciones. 2. Intentar cancelar una OC que ya tiene recepciones aplicadas. Resultado esperado: - Sin recepciones: estado `cancelada`. - Con recepciones: bloqueo con mensaje funcional. Resultado negativo (si falla): - Si cancela OC con recepciones activas: defecto crítico. --- PRUEBA 2.5 — Usar OC en factura de compra Dónde: Compras → Órdenes de compra → acción "Usar en factura" Pasos: 1. Tomar OC con líneas pendientes de facturar. 2. Ejecutar "Usar en factura". Resultado esperado: - Abre formulario de compra en Facturas con proveedor + OC + ítems cargados. - Ítems quedan vinculados a `orden_compra_det_id`. Resultado negativo (si falla): - Si OC no tiene pendientes de factura: advertencia y no carga formulario. --- PRUEBA 2.6 — Cancelación de OC vinculada y efecto en requisición (regla multi-OC) Dónde: Compras → Órdenes de compra y Requisiciones Pasos: 1. Crear una requisición y generar 2 OCs vinculadas. 2. Cancelar una OC y verificar estado de requisición. 3. Cancelar la segunda OC sin recepciones/facturas asociadas. Resultado esperado: - Tras la primera cancelación, la requisición no pasa a `rechazada` si queda otra OC vigente. - Cuando todas las OCs vinculadas quedan canceladas y no hay ejecución materializada, la requisición pasa a `rechazada`. - Se registra historial en OC y en requisición con motivo/fecha. Resultado negativo (si falla): - Si la requisición se rechaza con la primera OC cancelada aun existiendo otra vigente: defecto crítico. - Si no se genera trazabilidad en historial cruzado: defecto mayor. --- FASE 3 — Recepciones de compra --- PRUEBA 3.1 — Recepción parcial válida Dónde: Compras → pestaña Recepciones → Nueva recepción Pasos: 1. Seleccionar OC vigente. 2. Registrar cantidades menores a lo pendiente. 3. Guardar recepción. Resultado esperado: - Recepción creada con estado `aplicada`. - Cantidad recibida por detalle se incrementa. - OC pasa a `parcial` si corresponde. Resultado negativo (si falla): - Si cantidad recepcionada <= 0: debe bloquearse. --- PRUEBA 3.2 — Bloqueo por excedente en recepción Dónde: Compras → Recepciones Pasos: 1. Intentar recepcionar cantidad superior a lo pendiente de una línea. Resultado esperado: - Operación rechazada con mensaje de excedente. Resultado negativo (si falla): - Si permite excedente: defecto crítico en control de cantidades. --- PRUEBA 3.3 — Bloqueo de recepción por estado de OC Dónde: Compras → Recepciones Pasos: 1. Intentar recepcionar una OC en `pendiente_aprobacion`. 2. Intentar recepcionar una OC `cancelada`. Resultado esperado: - Ambas operaciones se bloquean con mensaje funcional. Resultado negativo (si falla): - Si crea recepción en esos estados: defecto crítico. --- PRUEBA 3.4 — Anulación de recepción válida Dónde: Compras → Recepciones → acción Anular Pasos: 1. Seleccionar recepción sin conflicto de facturación. 2. Anular indicando motivo. Resultado esperado: - Estado de recepción pasa a `anulada`. - Cantidades recibidas se revierten. - Estado de OC se recalcula. Resultado negativo (si falla): - Si no revierte cantidades/estado: defecto mayor. --- PRUEBA 3.5 — Bloqueo de anulación por sobrefacturación Dónde: Compras → Recepciones → Anular Pasos: 1. Tener detalle con facturación que quedaría mayor a recibido tras revertir. 2. Intentar anular recepción. Resultado esperado: - Anulación bloqueada con mensaje de consistencia. Resultado negativo (si falla): - Si anula dejando más facturado que recibido: defecto crítico. --- FASE 4 — Compras y Gastos --- PRUEBA 4.1 — Compra directa (escenario A o B) al contado Dónde: Compras → pestaña Facturas → Nueva compra Pasos: 1. Cargar cabecera fiscal y al menos un ítem. 2. Registrar pago contado que cubra total. 3. Guardar. Resultado esperado: - Compra creada correctamente. - Estado compra coherente (`pagada` si aplica pago total). Resultado negativo (si falla): - Si total de pagos contado no coincide con total compra: bloqueo. --- PRUEBA 4.2 — Compra vinculada a OC con matching 3 vías activo Dónde: Compras → Facturas (desde acción "Usar en factura") Pasos: 1. Configurar matching 3 vías activo. 2. Crear compra desde OC con referencias por línea. 3. Guardar. Resultado esperado: - Compra se guarda solo si precio/cantidad respetan regla de matching. Resultado negativo (si falla): - Si falta `orden_compra_det_id` por línea o precio no coincide: rechazo. --- PRUEBA 4.3 — Bloqueo de compra directa con stock cuando configuración lo prohíbe Dónde: Compras → Facturas Pasos: 1. Configurar `afectar_stock_en_compra_directa=false`. 2. Intentar compra directa de ítem de stock sin OC. Resultado esperado: - Bloqueo con mensaje indicando usar OC + Recepción. Resultado negativo (si falla): - Si permite compra directa de stock en esta configuración: defecto crítico. --- PRUEBA 4.4 — Gasto con documento completo (deducible) Dónde: Compras → pestaña Gastos → Nuevo gasto Pasos: 1. Cargar cabecera con documento fiscal completo: - timbrado (8), establecimiento (3), punto de expedición (3), número factura (7). 2. Agregar ítem de gasto. 3. Guardar. Resultado esperado: - Gasto creado. - Documento normalizado (zero-pad). - `deducible=true`. Resultado negativo (si falla): - Si documento está incompleto o formato inválido: debe rechazar. --- PRUEBA 4.5 — Gasto sin documento (no deducible) Dónde: Compras → Gastos Pasos: 1. Crear gasto sin informar documento fiscal. 2. Guardar. Resultado esperado: - Gasto creado con `deducible=false`. Resultado negativo (si falla): - Si exige documento completo cuando no se informó ninguno: defecto. --- PRUEBA 4.6 — Anulación protegida de gasto con pagos aplicados Dónde: Compras → Gastos → Anular Pasos: 1. Tomar gasto con pagos aplicados en CxP. 2. Intentar anular. Resultado esperado: - Operación bloqueada por pagos aplicados. Resultado negativo (si falla): - Si anula gasto con pagos activos: defecto crítico. --- PRUEBA 4.7 — Matching 3 vías formal por OC (reporte operativo) Dónde: API `GET /ordenes-compra/:id/matching-3-vias` (Postman/Swagger) Pasos: 1. Tomar una OC con recepciones y facturas parciales o completas. 2. Ejecutar `GET /ordenes-compra/:id/matching-3-vias`. 3. Validar `estado_matching` global y cada `linea.estado_matching`. 4. Verificar coherencia de: - `cantidad_ordenada` - `cantidad_recibida` - `cantidad_facturada` - `cantidad_pendiente_recepcion` - `cantidad_pendiente_factura` 5. Si hay desvíos, validar presencia de `hallazgos` con códigos de inconsistencia. Resultado esperado: - El endpoint responde estructura completa de matching formal: - `config`, `resumen`, `lineas`, `hallazgos`, `actualizado_en`. - El estado global refleja la realidad operativa: - `completo`, `parcial`, `pendiente`, `inconsistente` o `no_aplica` (si depende de `config_compras.habilitar_matching_3_vias=false`). Resultado negativo (si falla): - Si el resumen no cuadra con el detalle por línea: defecto mayor. - Si no reporta inconsistencias reales de precio/cantidad: defecto crítico. --- FASE 5 — Cuentas por pagar (CxP) y Orden de pago (OP) --- Precondición para pruebas con OP en BORRADOR: - Para ejecutar `PRUEBA 5.2` exactamente como está escrita, configurar temporalmente: - `config_compras.aplicar_pago_al_guardar=false`. - Para ejecutar `PRUEBA 5.3` en modo pago exacto: - `config_compras.permitir_pago_parcial=false`. - Para ejecutar `PRUEBA 5.3` en modo pago parcial: - `config_compras.permitir_pago_parcial=true`. - Para ejecutar `PRUEBA 5.4`, `PRUEBA 5.5` y `PRUEBA 6.1` en modo workflow: - `config_compras.requiere_aprobacion=true` - `config_compras.permite_pago_sin_aprobacion=false` - o `config_compras.workflow_obligatorio=true` (implica aprobación previa). - Motivo: - Con aprobación obligatoria, la OP no puede ejecutarse en `BORRADOR`; debe pasar por `PENDIENTE_APROBACION` -> `PENDIENTE`. --- PRUEBA 5.1 — Validar CxP unificada por origen Dónde: Cuentas por pagar / Pagos proveedor Pasos: 1. Listar cuentas por pagar filtrando `origen_tipo=compra`. 2. Repetir con `origen_tipo=gasto`. Resultado esperado: - Se observan cuentas según origen. - Campos de salida incluyen `origen_tipo`, `origen_id`, `documento_ref`, `fecha_origen` (y monto cuando aplique). Resultado negativo (si falla): - Si mezcla orígenes con filtro activo: defecto mayor. --- PRUEBA 5.2 — Crear OP mixta (compra + gasto) Dónde: Pagos proveedor → Nueva orden de pago Pasos: 1. Seleccionar proveedor con CxP de compra y gasto. 2. Incluir ambas cuentas en la misma OP. 3. Guardar en `BORRADOR` (con `aplicar_pago_al_guardar=false`). Resultado esperado: - OP creada con detalle mixto por proveedor. - Total corresponde a suma de saldos seleccionados. Resultado negativo (si falla): - Si cuenta no corresponde al proveedor o está repetida: rechazo. --- PRUEBA 5.3 — Política de pago según configuración (`permitir_pago_parcial`) Dónde: Pagos proveedor → crear OP Pasos: 1. Caso A (`permitir_pago_parcial=false`): - cargar monto menor al saldo; - cargar monto mayor al saldo; - cargar monto exacto al saldo. 2. Caso B (`permitir_pago_parcial=true`): - cargar monto menor al saldo; - cargar monto mayor al saldo; - cargar monto exacto al saldo. Resultado esperado: - Caso A: - menor al saldo: rechazo; - mayor al saldo: rechazo; - exacto al saldo: permitido. - Caso B: - menor al saldo: permitido; - mayor al saldo: rechazo; - exacto al saldo: permitido. Resultado negativo (si falla): - Si el comportamiento no respeta `permitir_pago_parcial`: defecto crítico. --- PRUEBA 5.4 — Workflow base de aprobación de OP Dónde: Pagos proveedor → listado OP Pasos: 1. Con configuración de aprobación obligatoria activa, crear OP en `BORRADOR`. 2. Ejecutar acción "Enviar a aprobación". 3. Aprobar la OP pendiente. 4. En otra OP, repetir envío y ejecutar rechazo con motivo. Resultado esperado: - OP 1: `BORRADOR` -> `PENDIENTE_APROBACION` -> `PENDIENTE`. - OP 2: `BORRADOR` -> `PENDIENTE_APROBACION` -> `RECHAZADA` con motivo visible en observaciones/historial funcional. Resultado negativo (si falla): - Si permite aprobar/rechazar fuera de `PENDIENTE_APROBACION`: defecto mayor. - Si permite ejecutar OP en `BORRADOR` con aprobación obligatoria: defecto crítico. --- PRUEBA 5.5 — Matriz de creación/ejecución de OP por configuración de aprobación Dónde: Pagos proveedor → Nueva OP + listado OP Pasos: 1. Ejecutar los siguientes subcasos sobre la misma cuenta por pagar (reiniciar datos entre casos): | Caso | Configuración | Resultado esperado al guardar OP | Resultado esperado de ejecución | |---|---|---|---| | 5.5.A | `aplicar_pago_al_guardar=true`, `requiere_aprobacion=false`, `usar_workflow=false` | OP queda `PAGADO` en el mismo guardado | No requiere acción manual adicional | | 5.5.B | `aplicar_pago_al_guardar=false`, `requiere_aprobacion=false`, `usar_workflow=false` | OP queda `BORRADOR` | Se puede ejecutar desde `BORRADOR` | | 5.5.C | `aplicar_pago_al_guardar=true`, `requiere_aprobacion=true`, `permite_pago_sin_aprobacion=false` | OP queda `BORRADOR` (no autoejecuta por política) | Requiere `ENVIAR/APROBAR` antes de ejecutar | | 5.5.D | `aplicar_pago_al_guardar=true`, `requiere_aprobacion=true`, `permite_pago_sin_aprobacion=true` | OP puede quedar `PAGADO` al guardar (excepción activa) | No requiere aprobación previa | | 5.5.E | `workflow_obligatorio=true` | OP queda `BORRADOR` y debe pasar por workflow | Solo ejecutable en `PENDIENTE` | Resultado esperado: - Cada subcaso respeta estrictamente la combinación de flags. - No hay ejecución en estado no permitido. Resultado negativo (si falla): - Si `workflow_obligatorio=true` permite ejecutar desde `BORRADOR`: defecto `blocker`. - Si `permite_pago_sin_aprobacion=true` no libera ejecución según política: defecto `major`. --- FASE 6 — Ejecución y anulación de pagos proveedor Precondición obligatoria de configuración (depende de `config_compras` y Tesorería): 1. `config_compras.habilitar_orden_pago=true`. 2. Regla de Tesorería activa para puente OP→banco: - `tipo_operacion='PAGO_PROVEEDOR'` - `cuenta_id` válida y activa en `tes_cuentas`. --- PRUEBA 6.1 — Ejecutar OP válida Dónde: Pagos proveedor → listado OP → Ejecutar Pasos: 1. Tomar OP en estado ejecutable: - `BORRADOR` si la aprobación NO es obligatoria. - `PENDIENTE` si la aprobación es obligatoria. 2. Ejecutar. Resultado esperado: - Estado OP pasa a `PAGADO`. - CxP asociadas quedan en `pagada` (saldo 0). - Estados relacionados de compra/gasto se recalculan. - Si existe regla `PAGO_PROVEEDOR` activa: se crea `tes_movimientos` (`EGRESO`, `CONFIRMADO`) con `origen_tipo='ORDEN_PAGO_PROVEEDOR'` y `origen_id=`. Resultado negativo (si falla): - Si OP no tiene detalles o cuenta ya sin saldo: bloqueo. - Si no se crea movimiento de tesorería con regla activa: defecto `major`. --- PRUEBA 6.2 — Bloqueo de ejecución por estado no permitido Dónde: Pagos proveedor Pasos: 1. Intentar ejecutar OP ya `PAGADO` o `ANULADA`. 2. Con aprobación obligatoria activa, intentar ejecutar OP `PENDIENTE_APROBACION` y `RECHAZADA`. Resultado esperado: - Rechazo con mensaje funcional. Resultado negativo (si falla): - Si vuelve a ejecutar una OP cerrada: defecto crítico. --- PRUEBA 6.3 — Anular OP y revertir impacto Dónde: Pagos proveedor → acción Anular Pasos: 1. Anular OP previamente ejecutada. 2. Confirmar motivo. Resultado esperado: - OP queda `ANULADA`. - Se revierte impacto en CxP/pagos y se recalculan estados de compra/gasto. - Si había movimiento de tesorería vinculado por `origen_tipo/origen_id`, queda `ANULADO` y se revierte `saldo_actual` de la cuenta. Resultado negativo (si falla): - Si no revierte saldos/estados: defecto crítico. --- PRUEBA 6.4 — Bloqueo de doble anulación Dónde: Pagos proveedor Pasos: 1. Intentar anular una OP ya anulada. Resultado esperado: - Operación bloqueada. Resultado negativo (si falla): - Si permite múltiples anulaciones: defecto crítico. --- PRUEBA 6.5 — Conciliación bancaria automática (comisión / ITF / diferencias) Dónde: Tesorería → Conciliación bancaria → detalle de extracto Pasos: 1. Importar extracto con líneas mixtas: - línea con match exacto a movimiento confirmado; - línea de comisión bancaria sin movimiento previo; - línea de ITF sin movimiento previo; - línea con diferencia de monto contra movimiento (dentro de umbral). 2. Ejecutar auto-conciliación del extracto. Resultado esperado: - Match exacto: línea conciliada contra movimiento existente. - Comisión/ITF: se auto-crea movimiento confirmado con categoría del sistema y la línea queda conciliada. - Diferencia dentro de umbral: se crea ajuste automático y la línea queda conciliada. - Remanentes no resolubles: se marcan `sin_correspondencia` (si opción activada). Resultado negativo (si falla): - Si una línea auto-conciliada queda con tipo inverso (ingreso/egreso): defecto `blocker`. - Si no se generan ajustes de diferencia dentro de umbral configurado: defecto `major`. --- Matriz de configuración A/B/C (desktop + mobile) | Escenario | Configuración | Verificación esperada | |---|---|---| | A. Directo simplificado | `habilitar_requisicion_compra=false`, `habilitar_orden_compra=false`, `habilitar_recepcion_compra=false` | Solo pestaña Facturas (y Gastos si módulo activo). Sin tabs de Requisiciones/OC/Recepciones. | | B. Requisición opcional | `modo_flujo_compra=requisicion_opcional`, OC/Recepción habilitadas | Tabs visibles: Requisiciones, Órdenes, Recepciones, Facturas (y Gastos). Permite caminos directo y con requisición. | | C. Requisición obligatoria | `habilitar_requisicion_compra=true`, `modo_flujo_compra=requisicion_obligatoria`, `habilitar_orden_compra=true`, `habilitar_recepcion_compra=true` | Bloquea alta directa de compra y OC sin requisición. Mensaje funcional claro en UI y backend. | Evidencias a registrar por cada check: - Resultado: OK / FAIL - Severidad: blocker / major / minor - Ruta de reproducción - Captura desktop - Captura mobile --- Matriz ampliada de configuraciones (obligatoria para cierre) Objetivo: - Validar que el flujo operativo completo respeta no solo A/B/C, sino también políticas de documentos, stock, pagos y workflow. Bloque M1 — Documentos formales y stock | Caso | Configuración mínima | Validación obligatoria | |---|---|---| | M1.1 | `habilitar_orden_compra=false` | Debe bloquear alta/edición por endpoints y UI de OC/Recepciones. | | M1.2 | `habilitar_recepcion_compra=false` | No debe existir flujo de recepción; `habilitar_matching_3_vias` debe quedar en `false`. | | M1.3 | `habilitar_matching_3_vias=true` + OC/Recepción activas | Compra con OC debe validar cantidad/precio por línea y rechazar inconsistencias. | | M1.4 | `afectar_stock_en_compra_directa=true` | Compra directa de ítem de stock impacta stock al confirmar. | | M1.5 | `afectar_stock_en_compra_directa=false` + recepción activa | Compra directa no impacta stock; impacto ocurre en recepción. | | M1.6 | `modo_flujo_compra=requisicion_obligatoria` | Debe bloquear compra directa y OC directa sin `requisicion_id`. | Bloque M2 — Aprobaciones y ejecución de OP | Caso | Configuración mínima | Validación obligatoria | |---|---|---| | M2.1 | `requiere_aprobacion=false`, `usar_workflow=false` | OP puede ejecutarse desde `BORRADOR` según política de guardado. | | M2.2 | `requiere_aprobacion=true`, `permite_pago_sin_aprobacion=false` | OP no puede ejecutarse en `BORRADOR`; exige aprobación previa. | | M2.3 | `usar_workflow=true` | Deben estar disponibles acciones enviar/aprobar/rechazar y estados coherentes. | | M2.4 | `workflow_obligatorio=true` | Debe forzar workflow completo y bloquear saltos de estado. | | M2.5 | `permite_pago_sin_aprobacion=true` con aprobación activa | Debe permitir excepción operativa de ejecución sin aprobar, según configuración. | | M2.6 | `habilitar_orden_pago=false` | Debe bloquear creación y ejecución de nuevas OP. | Bloque M3 — Política de montos en OP | Caso | Configuración mínima | Validación obligatoria | |---|---|---| | M3.1 | `permitir_pago_parcial=false` | Solo permite monto exacto al saldo por cada CxP. | | M3.2 | `permitir_pago_parcial=true` | Permite monto parcial (`0 < monto <= saldo`). | | M3.3 | cualquier configuración | Nunca permite sobrepago (`monto > saldo`). | Bloque M4 — Efecto de `aplicar_pago_al_guardar` | Caso | Configuración mínima | Validación obligatoria | |---|---|---| | M4.1 | `aplicar_pago_al_guardar=true` sin aprobación obligatoria | OP debe quedar aplicada/pagada al guardar. | | M4.2 | `aplicar_pago_al_guardar=false` | OP debe quedar en `BORRADOR` hasta ejecutar manualmente. | | M4.3 | `aplicar_pago_al_guardar=true` con aprobación obligatoria | No debe autoejecutar; debe respetar workflow/aprobación. | Plantilla de evidencia por caso (usar en QA interno): | Campo | Valor a completar | |---|---| | Caso | Ej: `M2.4` | | Configuración aplicada | JSON o captura de `config_compras` | | Ruta de reproducción | Menú > pantalla > acción | | Resultado observado | OK / FAIL | | Severidad (si falla) | blocker / major / minor | | Evidencia | captura desktop + mobile + request/response relevante | | Fecha y responsable | dd/mm/yyyy - usuario QA | --- QA técnico (smoke y regresión) Ejecutar desde raíz del proyecto: 1. Backend smoke F1/F2/F3: - `cd backend && npm run test:smoke:f2f3` - Esperado: `35 passed, 35 total`. 2. Frontend smoke flujo A/B/C: - `cd frontend && npm run smoke:f2f3` - Esperado: `OK smoke F2/F3 config flow A/B/C`. 3. Backend test global: - `cd backend && npm test -- --runInBand` - Esperado: suites en verde. 4. Backend smoke flujo integrado Compras/Gastos (E2E de servicios): - `cd backend && npm run test:smoke:compras-gastos-e2e` - Esperado: 1 suite en verde (`requisición -> OC -> recepción -> gasto -> CxP -> OP -> ejecutar/anular`). 5. Backend smoke F4/F6 (incluye puente OP/Tesorería en unit tests de OP): - `cd backend && npm run test:smoke:f4f6` - Esperado: suites de compras, gastos y pagos proveedor en verde. 6. Backend smoke conciliación F6: - `cd backend && npm run test:smoke:f6-conciliacion` - Esperado: validaciones de matching estricto y edición de línea en verde. 7. Build backend: - `cd backend && npm run build` - Esperado: compilación exitosa. 8. Build frontend: - `cd frontend && npm run build` - Esperado: build exitosa (puede mostrar warnings no bloqueantes de tamaño de chunks). Opcional de control adicional: - `cd backend && npx prisma migrate status` - Esperado: esquema al día. --- Criterio de cierre GO Se declara GO cuando se cumplen simultáneamente: 1. Cobertura funcional: - F1 a F6 ejecutadas con al menos un caso positivo y uno negativo por fase. 2. Configuración: - Matriz A/B/C validada en desktop y mobile sin defectos `blocker`. - Matriz ampliada M1/M2/M3/M4 validada sin desvíos críticos. 3. Integridad financiera: - No hay sobrepago ni pago parcial operativo fuera de política. - Anulaciones protegidas funcionan en compras/gastos/recepciones/OP. 4. Calidad técnica: - Smokes, tests y builds en verde. 5. Evidencia: - Todas las pruebas con resultado, severidad, ruta y capturas documentadas. Si existe al menos un defecto `blocker`, el estado es NO-GO hasta corrección y revalidación.