Define la solicitud y quién puede decidir
Guarda referencia, solicitante, concepto, importe, moneda, documento y responsable de aprobación. Valida los campos antes de enviar la petición. Aclara qué ocurre con varias monedas o documentos corregidos y si se admite que una persona apruebe su propia solicitud.
Define aprobadores por tu política interna y registra una sustitución cuando alguien esté ausente. Los importes del ejemplo siguiente son ficticios y no son recomendaciones de control financiero. Aprobar una solicitud tampoco ejecuta ni autoriza técnicamente el pago en este recorrido.
Prueba el recorrido en una lista de ensayo
En un entorno autorizado de Microsoft, prepara una lista de SharePoint de prueba con los campos anteriores y un estado inicial. Crea un flujo cuando se añada una solicitud y valida referencia, importe y aprobador. Añade la acción de iniciar y esperar una aprobación. Microsoft documenta este recorrido; comprueba conectores, permisos y licencias en tu cuenta.
Separa las ramas de aprobación y rechazo. Cada una actualiza la misma solicitud con decisión y fecha, y comunica el resultado a quien la creó. Añade una salida para error o espera agotada que deje la solicitud pendiente de atención. Usa direcciones de prueba autorizadas, sin avisar a personas ajenas al ensayo.
Ensaya una corrección que invalida la decisión anterior
Ejemplo ficticio: SG-04 solicita 120 € para un material y queda aprobada. Después se cambia a 180 €. La regla del ejercicio exige nueva revisión cuando cambia el importe. Conserva la versión anterior y devuelve la nueva a pendiente; no reutilices automáticamente la aprobación.
En otra prueba, el destino guarda la decisión pero falla el aviso al solicitante. La recuperación repite el aviso según la regla acordada, sin crear otra solicitud ni pedir otra aprobación. Distingue el estado de la decisión del estado de su comunicación.
| Caso de prueba | Salida esperada |
|---|---|
| Solicitud completa | Una petición al aprobador previsto. |
| Sin importe o sin aprobador | Pendiente de corrección, sin petición. |
| Aprobador ausente | Sustitución autorizada o revisión visible. |
| Cambio tras aprobación | Nueva versión pendiente según la política. |
| Evento de alta repetido | Una solicitud y una petición para esa versión. |
Comprueba el historial antes de activarlo
Revisa quién decidió, qué versión vio y dónde se puede consultar el documento. Prueba que una persona sin permiso no pueda abrirlo por recibir el enlace. Si la plataforma mantiene la aprobación pero no actualiza la lista, deja un procedimiento para conciliar ambas.
Antes de construir, comprueba las aprobaciones de tu programa de gastos o ERP. Puede bastar su configuración. El desarrollo adicional tiene sentido cuando hay un tramo entre aplicaciones que las funciones existentes no cubren. Delimita ese tramo y prueba su recuperación con las mismas solicitudes de ensayo.
Fuentes y documentación
Las recomendaciones de esta guía son de MENOS. Estos documentos permiten comprobar las funciones de las herramientas que se mencionan.