Diseñar una aprobación de presupuesto antes del envío automático

Guía preparada con apoyo de IA. Casos y resultados didácticos, con datos ficticios; adapta y comprueba las plantillas antes de utilizarlas.

Dibuja estados antes de añadir botones

En el caso ficticio, el presupuesto P-61 pasa por borrador, pendiente de revisión, aprobado, enviado o devuelto para corregir. El estado aprobado debe identificar la versión, el aprobador autorizado y el destinatario confirmado. El ejercicio no fija precios ni condiciones: organiza cómo impedir que un documento sin revisar salga por correo.

Separa preparar el archivo de enviarlo. Un documento generado puede estar completo en formato y seguir pendiente de una decisión comercial. La automatización debe hacer visible ese límite en lugar de deducir aprobación porque el archivo se haya guardado en una carpeta.

Pide un circuito con invalidación de cambios

Define qué cambios exigen nueva revisión: importe, alcance, condiciones, adjunto o destinatario, según la política del equipo. La aprobación no se hereda automáticamente a una versión posterior. Pide un registro de transiciones que permita saber por qué se pasó de pendiente a aprobado y qué versión quedó autorizada.

Diseña circuito ficticio P-61: borrador, revisión, aprobado, enviado, devuelto. Aprobación ligada a versión y destinatario autorizado. V1 aprobada; después cambia alcance y nace V2. Devuelve transición esperada, bloqueo de envío, nueva revisión y controles de repetición. No envíes nada. Incluye autorización del aprobador y validación de adjunto. Una aprobación anterior no autoriza automáticamente la nueva versión.

Resultado esperado de P-61

P-61 versión 1 se aprueba para el destinatario de prueba A. Después se modifica el alcance y se guarda versión 2. El resultado esperado es versión 2 pendiente de revisión y ningún envío. Si se intenta enviar, el flujo debe bloquear esa acción por no coincidir con la versión aprobada.

Tras aprobar la versión 2, una prueba de envío a un buzón de ensayo puede producir un registro único con versión y destinatario. Repetir la misma orden no debería generar otro correo según la regla de deduplicación acordada. No basta comprobar que alguna versión del presupuesto tuvo una aprobación en el pasado.

Contempla rechazos y aprobaciones concurrentes

Una devolución para corregir no equivale a una cancelación definitiva. Conserva el motivo y permite preparar una nueva versión sin borrar el historial. Si dos personas revisan a la vez, define quién tiene autoridad y cómo se resuelve un cambio de estado para evitar que una aprobación tardía reabra un documento ya modificado.

La identidad del aprobador no debe obtenerse de un nombre escrito libremente en un mensaje. La implementación necesita verificar el mecanismo de autorización elegido. Este artículo describe el requisito de diseño, sin atribuir esa capacidad a una herramienta concreta.

Ejercicio de versión y destinatario

Ensaya cuatro casos ficticios: documento aprobado sin cambios, documento modificado, destinatario cambiado y orden de envío repetida. Anota qué casos permiten continuar y cuáles vuelven a revisión. Hazlo con buzones de prueba y documentos sin datos reales para observar el comportamiento sin contactar a clientes.

Revisa la salida completa: estado, versión, adjunto y registro del envío. Un correo enviado a la dirección correcta con el archivo anterior sigue siendo un fallo. La prueba debe comprobar el conjunto, no solo que el nodo o paso de envío termine sin mensaje de error.

Cómo seguir aprendiendo

Para situar este caso dentro de un método más amplio, consulta nuestra guía de automatización y flujos. Si quieres practicar con acompañamiento, revisa el programa del curso relacionado y comprueba sus objetivos, requisitos y modalidad antes de elegir.