Plan de Pruebas — Modulo de Presupuestos Fecha: 2026-05-28 Referencia: `plan-presupuestos.md` y `qa-plan-presupuestos.md` --- Conceptos clave antes de empezar | Termino | Que es en la practica | |---|---| | Presupuesto | Cotizacion comercial editable solo en BORRADOR | | Versionado | Nueva version del mismo numero comercial | | Seguimiento | Vista comercial en Dashboard (widget + expansion de graficos) | | Portal publico | Enlace sin login para que el cliente acepte o rechace | | Conversion | Paso de presupuesto ACEPTADO a Orden de Venta y luego Facturacion | | Facturado | Estado final del presupuesto luego de facturar completamente la OV origen | | Numeracion por sucursal | Numeracion de presupuesto por punto/sucursal (tipo documento Presupuesto) | | Condiciones de pago | Catalogo reutilizable para nuevos presupuestos | --- Flujo obligatorio antes de cualquier prueba 1. Confirmar empresa de pruebas con modulo `PRESUPUESTOS` activo. 2. Ejecutar provision si corresponde: `pnpm provision:presupuestos`. 3. Verificar permisos del usuario (LEER/CREAR/EDITAR/ELIMINAR/IMPRIMIR + `PRES_APROBAR`/`PRES_CONVERTIR` cuando aplique). 4. Confirmar catalogos minimos: clientes, monedas, productos y condiciones de pago. 5. Confirmar que el microservicio `generador-pdf` este accesible desde backend. 6. Confirmar UX actual: en `Presupuestos` no existe pestana `Pipeline` (el seguimiento esta en Dashboard). 7. Confirmar alcance vigente de conversion: solo `convert-to-order` (OV). `convert-to-credit` queda diferido. 8. Confirmar migraciones aplicadas: `20260705_presupuesto_sucursal_numeracion` y `20260706_presupuesto_estado_facturado`. 9. Confirmar que existe tipo_documento `Presupuesto` (codigo 500) para configurar numeracion por sucursal. --- Datos de prueba reutilizables | Dato | Valor sugerido | |---|---| | Empresa | Demo Comercial | | Sucursal | Matriz (y al menos una sucursal adicional) | | Cliente | Cliente Demo Presupuestos | | Moneda | PYG (y opcional USD para tipo de cambio) | | Producto A | IVA 10% | | Producto B | IVA 5% | | Usuario operador | Perfil con permisos base de presupuestos | | Usuario aprobador | Perfil con `PRES_APROBAR` | --- FASE 1 — Configuracion y catalogos base (M36) --- PRUEBA 1.0 — Numeracion de presupuesto por sucursal Donde: Sucursales > Numeraciones Pasos: 1. Configurar numeracion activa para tipo documento `Presupuesto` en Sucursal A. 2. Configurar numeracion activa para tipo documento `Presupuesto` en Sucursal B. 3. Crear presupuesto en cada sucursal. Resultado esperado: - El numero de presupuesto se genera por sucursal/punto (no global unico por empresa). - Si no hay numeracion configurada, usa fallback de prefijo/correlativo de empresa. Resultado negativo (si falla): - Si ambas sucursales consumen el mismo correlativo sin distinguir punto/sucursal: defecto de numeracion. --- PRUEBA 1.1 — Configuracion del modulo Donde: Configuracion > Presupuestos Pasos: 1. Abrir parametros globales de Presupuestos. 2. Ajustar dias de vigencia/alerta y guardar. Resultado esperado: - Guarda sin error. - Al recargar pantalla, los valores persisten. Resultado negativo (si falla): - Si no persiste o rompe carga de pantalla: defecto de configuracion. --- PRUEBA 1.2 — Condiciones de pago Donde: Presupuestos > Pestana Condiciones de pago Pasos: 1. Crear una condicion de pago activa. 2. Marcar una condicion como `Por defecto`. 3. Cambiar el `Por defecto` a otra condicion y confirmar que queda una sola marcada. 4. Editarla. 5. Eliminarla (si no tiene uso) o desactivarla. Resultado esperado: - ABM funcional y listado actualizado. - El default operativo del modulo sale de esta pestana (no de Configuracion global). Resultado negativo (si falla): - Si no refleja cambios o bloquea sin mensaje: defecto funcional. --- FASE 2 — Flujo operativo de presupuesto (M37) --- PRUEBA 2.1 — Crear nuevo presupuesto (campos obligatorios) Donde: Presupuestos > Nuevo presupuesto Pasos: 1. Intentar guardar sin completar `Moneda` y `Vigencia`. 2. Intentar guardar sin `Sucursal` en alta. 3. Completar cliente, titulo, sucursal, moneda, vigencia e items. 4. Guardar sin elegir condicion de pago, teniendo una condicion marcada `Por defecto`. 5. Quitar todas las marcas `Por defecto` en catalogo (dejando condiciones activas) y crear otro presupuesto sin elegir condicion. Resultado esperado: - Paso 1 y 2: muestra validaciones de campos obligatorios. - Paso 4: crea presupuesto en estado `BORRADOR` usando la condicion marcada `Por defecto`. - Paso 5: crea presupuesto en `BORRADOR` usando fallback a primera condicion activa (orden/nombre). Resultado negativo (si falla): - Si permite guardar vacio en campos obligatorios: defecto critico de validacion. --- PRUEBA 2.2 — Editar solo en BORRADOR Donde: Presupuestos > Lista / Detalle Pasos: 1. Editar presupuesto en BORRADOR. 2. Mover presupuesto a estado no borrador (por envio/aprobacion). 3. Intentar editar nuevamente. Resultado esperado: - Solo BORRADOR permite edicion. - En otros estados debe bloquear. Resultado negativo (si falla): - Si permite editar un estado no BORRADOR: incumplimiento de regla core. --- PRUEBA 2.3 — Cancelar y nueva version Donde: Presupuestos > Lista Pasos: 1. Cancelar un presupuesto no convertido. 2. Generar nueva version desde acciones. Resultado esperado: - Cancelado queda en `CANCELLED` (soft delete funcional). - Nueva version mantiene trazabilidad comercial (numero/version). Resultado negativo (si falla): - Si se pierde historial o no se distingue version: defecto de negocio. --- FASE 3 — PDF, envio y portal publico (M39, M40) --- PRUEBA 3.1 — PDF (preview y descarga) Donde: Presupuestos > Acciones / Detalle Pasos: 1. Abrir vista previa PDF. 2. Descargar PDF. 3. En presupuesto en moneda USD, verificar que el PDF muestre cotizacion. Resultado esperado: - Preview visible sin error. - Descarga correcta (`presupuesto-*.pdf`). - En moneda distinta de PYG: muestra `Cotizacion: 1 = Gs ...`. Resultado negativo (si falla): - Si `generador-pdf` cae, mostrar error controlado (toast/mensaje), sin romper UI. --- PRUEBA 3.2 — Envio por email (destinatario principal + copias) Donde: Presupuestos > Accion Enviar Pasos: 1. Abrir dialogo de envio. 2. En cliente con email cargado, dejar `Destinatarios` vacio y enviar. 3. Cargar 1 o mas destinatarios adicionales separados por coma y reenviar. 4. Repetir con cliente sin email principal configurado. Resultado esperado: - Si `Destinatarios` esta vacio, usa email principal del cliente como destinatario principal. - Los destinatarios adicionales se envian como copias. - Si el cliente no tiene email principal y `Destinatarios` esta vacio, bloquea envio con mensaje claro para cargar email. - Registro de envio/seguimiento actualizado. Resultado negativo (si falla): - Si no adjunta PDF o falla sin feedback: defecto de integracion mail/PDF. - Si envia sin email principal y sin destinatarios manuales: defecto critico de validacion. --- PRUEBA 3.3 — Generar/copy enlace publico (sin cerrar dialogo) Donde: Presupuestos > Accion Enviar Pasos: 1. Abrir dialogo de envio. 2. Elegir opcion de generar enlace. 3. Copiar enlace para compartir por WhatsApp. 4. Verificar estado del dialogo despues de copiar. Resultado esperado: - Permite generar y copiar enlace publico sin enviar email obligatorio. - El dialogo permanece abierto luego de `Copiar enlace`. - Enlace copiado es utilizable en navegador externo. Resultado negativo (si falla): - Si obliga a enviar por email para obtener enlace: defecto funcional. - Si cierra dialogo automaticamente al copiar: defecto UX respecto al flujo definido. --- PRUEBA 3.4 — Portal publico (aceptar/rechazar) Donde: URL publica `/pub/presupuesto/:token` Pasos: 1. Abrir enlace desde email. 2. Probar aceptar. 3. Probar rechazar en otro presupuesto. Resultado esperado: - Muestra datos y PDF. - Cambia estado correctamente (`ACCEPTED` / `REJECTED`) y registra fecha de respuesta. Resultado negativo (si falla): - Si token no valida o cambia estado incorrecto: defecto critico del flujo comercial. --- FASE 4 — Aprobacion y conversion (M41, M42) --- PRUEBA 4.1 — Aprobacion interna por umbral Donde: Presupuestos > Detalle / Acciones Pasos: 1. Crear presupuesto por debajo del umbral y enviar a revision. 2. Crear presupuesto por encima del umbral y enviar a revision. 3. Aprobar/rechazar con usuario aprobador. Resultado esperado: - Bajo umbral: autoaprobado segun configuracion. - Alto umbral: pasa a `IN_REVIEW`. - Aprobacion/rechazo respeta permisos y deja historial. Resultado negativo (si falla): - Si usuario sin permiso aprueba o envia email sin aprobacion requerida: defecto de seguridad/regla. --- PRUEBA 4.2 — Conversion a Orden de Venta Donde: Presupuestos > Detalle y Ordenes de venta > Nueva Pasos: 1. Convertir un presupuesto `ACCEPTED` a Orden de Venta. 2. Validar flujo alterno desde `OrdenVentaNueva` usando selector de presupuestos aceptados. 3. Si el presupuesto tiene descuento global, validar que la OV guarde `descuento_global_porcentaje`. Resultado esperado: - Presupuesto pasa a `CONVERTED`. - Se crea OV confirmada con items de producto. - Se arrastran datos comerciales: moneda/tipo cambio/condicion de pago/descuento global. Resultado negativo (si falla): - Si permite reconvertir presupuesto ya convertido: defecto critico de consistencia. - Si descuento global del presupuesto no aparece en la OV: defecto funcional de conversion. --- PRUEBA 4.3 — Facturacion de OV origen presupuesto y cambio a FACTURADO Donde: POS Admin + Presupuestos > Detalle Pasos: 1. Tomar una OV creada desde presupuesto con descuento global (ej. 30%). 2. Cargar la OV en POS y verificar precarga de descuento global. 3. Registrar factura cubriendo el total pendiente de la OV. 4. Volver al detalle del presupuesto origen. Resultado esperado: - En POS, el descuento global se recupera correctamente (incluye fallback para OVs historicas sin ese campo, via `presupuesto_id`). - Al facturar completamente la OV: - OV queda en estado `facturada`. - Presupuesto pasa de `CONVERTED` a `FACTURADO`. - Historial del presupuesto registra `CONVERTED -> FACTURADO` con referencia de OV/factura. Resultado negativo (si falla): - Si la OV no precarga el descuento global del presupuesto: defecto critico de consistencia comercial. - Si no cambia a `FACTURADO` o no registra historial: defecto de trazabilidad. --- FASE 5 — Seguimiento en Dashboard (M43 + UX actual) --- PRUEBA 5.1 — Widget de Presupuestos en Dashboard Donde: Dashboard principal Pasos: 1. Validar que usuario con modulo `PRESUPUESTOS` vea widget de seguimiento. 2. Validar que usuario sin modulo no lo vea. Resultado esperado: - Visibilidad correcta por modulo. - KPIs cargan con datos reales. - Seguimiento accesible desde Dashboard sin depender de una pestana Pipeline en Presupuestos. Resultado negativo (si falla): - Si muestra widget a usuario sin modulo: defecto de permisos UI. --- PRUEBA 5.2 — Expandir seguimiento Donde: Dashboard > Widget Presupuestos > Ver seguimiento Pasos: 1. Expandir seguimiento. 2. Verificar graficos. 3. Colapsar seguimiento. Resultado esperado: - No duplica KPIs en la vista expandida. - Renderiza graficos de embudo/estados/serie mensual sin errores. Resultado negativo (si falla): - Si duplica bloques o rompe responsive: defecto de UX. --- Cierre de pruebas de usuario Checklist final: 1. `frontend`: `npm run build` en verde. 2. Flujo completo validado: crear -> aprobar/enviar -> portal -> convertir OV -> facturar OV -> presupuesto FACTURADO. 3. Seguimiento en dashboard operativo y sin duplicaciones. 4. `convert-to-credit` explicitamente fuera de alcance (pendiente del plan; no bloquear cierre por ese punto). 5. Evidencia cargada en un archivo de ejecucion con fecha.