Una persona necesita un material o servicio. Escribe a su responsable, adjunta un presupuesto y espera. El correo se reenvía a compras, falta un centro de coste, aparece una alternativa y nadie sabe si la petición sigue pendiente o ya fue autorizada. Esta fricción no se resuelve enviando más recordatorios, sino convirtiendo la solicitud en un proceso de automatización administrativa con estados, reglas y responsables.
Por qué las solicitudes de compra quedan atrapadas
El correo transporta información, pero no gobierna el proceso. No obliga a completar campos, no conoce los límites de gasto y no distingue entre una petición nueva, una corrección y una duplicada. Cuando el volumen crece, compras dedica demasiado tiempo a perseguir contexto antes de poder evaluar la operación.
- Solicitud incompleta: falta proveedor, importe, necesidad, proyecto o fecha.
- Responsable ambiguo: no está definido quién aprueba cada categoría o nivel.
- Versión confusa: el presupuesto adjunto cambia, pero el hilo conserva documentos anteriores.
- Ausencias: una persona bloquea el recorrido porque no existe sustituto.
- Registro tardío: el ERP se actualiza después de aprobar y obliga a copiar la información.
Cómo funciona un workflow de aprobación de compras
Un buen circuito representa el proceso real, pero evita trasladar todas sus excepciones al primer día. La solicitud avanza por estados y cada transición deja una evidencia.
- 01
Solicitar
Recoger necesidad, importe, categoría, proveedor, centro de coste y documentos.
- 02
Validar
Comprobar campos, duplicados, presupuesto y cumplimiento de políticas.
- 03
Enrutar
Elegir aprobador según importe, departamento, proyecto o tipo de compra.
- 04
Decidir
Aprobar, rechazar o devolver con una causa y un comentario trazables.
- 05
Registrar
Crear o preparar la orden en el ERP con los datos ya validados.
- 06
Notificar
Informar al solicitante, compras y proveedor cuando corresponda.
La solicitud debe contener lo necesario para decidir
El formulario no tiene que ser largo, pero sí adaptarse al tipo de compra. Una renovación de software, una inversión en maquinaria y un consumible no requieren las mismas preguntas. Los campos condicionales ayudan a pedir información únicamente cuando aporta valor.
El estado debe ser visible
Borrador, pendiente de información, en aprobación, aprobado, rechazado y registrado son estados distintos. Hacerlos visibles evita llamadas y correos de seguimiento, además de permitir medir dónde se acumula la espera.
Reglas por importe, categoría y responsabilidad
Las reglas convierten la política de compras en un recorrido ejecutable. Pueden combinar condiciones: una compra inferior a cierto límite dentro de catálogo puede avanzar directamente; una inversión no presupuestada puede necesitar responsable de área y dirección financiera.
| Situación | Recorrido posible |
|---|---|
| Compra habitual dentro del límite | Validación y aprobación automática |
| Importe superior al autorizado | Responsable y dirección financiera |
| Proveedor nuevo | Compras y validación documental |
| Sin presupuesto asignado | Revisión del centro de coste |
| Información incompleta | Devolución al solicitante |
La documentación de Dynamics 365 contempla la posibilidad de enrutar la solicitud completa o sus líneas a revisores distintos, y utilizar límites de gasto para decidir cuándo interviene un responsable. El modelo exacto debe reflejar la organización, no copiar una configuración estándar.
Las excepciones no deben romper el flujo
Una solicitud puede cambiar de importe, necesitar una alternativa o llegar durante la ausencia del aprobador. El workflow debe admitir devolución, sustitución, delegación, cancelación y nueva aprobación cuando cambia un dato relevante.
Solicitud
Mostrar datos, adjuntos, presupuesto y motivo.
Responsable
Asignar la decisión a la persona adecuada.
Escalado
Recordar y sustituir sin perder el historial.
Decisión
Conservar versión, fecha, resultado y comentario.
Qué ocurre después de aprobar: integración con el ERP
La aprobación no debería terminar en una tarea de copia. Los datos validados pueden preparar o crear la orden de compra, adjuntar el presupuesto, asignar el centro de coste y devolver el número del documento al workflow. Si el ERP requiere una revisión adicional, el circuito debe reflejarla.
Una vez emitido el pedido, comienza otro proceso operativo: recepción, incidencias y facturación. La automatización de pedidos y registros en el ERP muestra cómo estructurar la captura y validación sin perder el control sobre las excepciones.
Trazabilidad sin convertir la aprobación en burocracia
El objetivo no es añadir más pasos, sino eliminar búsquedas y decisiones repetidas. Cada solicitud debería permitir responder quién la creó, qué versión se aprobó, con qué regla, quién decidió y qué documento se generó.
Esta evidencia también facilita la revisión posterior de la factura. Sin embargo, solicitud, orden y factura son objetos diferentes. El caso de automatización de facturas aborda la recepción y tratamiento documental, mientras este workflow gobierna la autorización previa de la compra.
Qué medir para mejorar el circuito
- Tiempo total: desde la solicitud hasta la decisión.
- Tiempo por etapa: dónde se concentra la espera.
- Devoluciones: solicitudes que vuelven por datos incompletos.
- Excepciones: compras que salen de las reglas habituales.
- Aprobaciones automáticas: operaciones seguras que no consumen revisión.
- Registro posterior: tiempo y errores al trasladar la compra al ERP.
Estas métricas permiten estimar el retorno del proyecto de automatización con ahorro de tiempo, reducción de errores y mayor control.
Cómo empezar sin modelar toda la política de compras
Conviene elegir un tipo de solicitud frecuente y reconocible, con uno o dos niveles de aprobación. Primero se documentan campos mínimos, límites, responsables y situaciones de devolución. Después se prueba con un grupo reducido y se comparan tiempos, dudas y excepciones.
Las reglas que solo existen como acuerdos informales aparecerán durante el piloto. Es mejor convertirlas en decisiones explícitas antes de ampliar el circuito a nuevas categorías o sociedades.
Preguntas frecuentes sobre aprobación de compras
¿Qué es un workflow de aprobación de compras?
Es un circuito que registra una solicitud, valida sus datos y la dirige al responsable adecuado según reglas empresariales.
¿Todas las compras requieren aprobación manual?
No. Las operaciones dentro de políticas y límites pueden avanzar automáticamente y reservar la revisión para las excepciones.
¿Puede conectarse con el ERP?
Sí. Tras la aprobación puede preparar o crear la orden, adjuntar documentación y devolver identificador y estado.
¿Qué ocurre si el aprobador está ausente?
El flujo debe contemplar delegaciones, sustituciones, recordatorios y escalados con plazos definidos.
¿Cómo conviene empezar?
Con un tipo de compra frecuente, pocos niveles y reglas conocidas, midiendo tiempos, devoluciones y excepciones.
La aprobación debe concentrar el criterio, no la espera
Cuando la solicitud llega completa y el responsable recibe una decisión concreta, aprobar deja de ser una tarea de investigación. Las compras normales avanzan con fluidez y las excepciones conservan la atención que merecen.
Un workflow bien diseñado no elimina la responsabilidad: la hace visible, trazable y proporcional al riesgo de cada operación.
Fuentes y documentación
- Microsoft Learn: workflow de solicitudes de compra, sobre revisión, condiciones, rutas y responsables.
- Microsoft Learn: visión general de solicitudes de compra, sobre estados, líneas y generación posterior de órdenes.
- Microsoft Learn: aprobación de compras en Business Central, sobre aprobadores, límites y notificaciones.
- Microsoft Learn: propiedades de workflow, sobre propietarios, condiciones, instrucciones y avisos.