Guía editorial del equipo Akaen. El caso citado fue liderado por Víctor Muñoz, hoy socio de Akaen.
Un cliente envía un pedido en PDF por correo. Alguien lo abre, busca las referencias en el ERP, comprueba la tarifa, teclea las líneas y confirma. Multiplica eso por varios cientos de pedidos al mes y tienes uno de los procesos que más se automatizan en empresas industriales y de distribución. La cuestión es cómo.
Hay tres enfoques. Los tres funcionan en la demo. Se diferencian en lo que pasa el día que un cliente cambia el formato de su pedido, y en quién mantiene el sistema cuando la cartera crece.
El problema no es leer el PDF, es validarlo
Leer el texto de un PDF es lo fácil. Lo que consume el tiempo del equipo es lo de después: saber que "REF 42" es la referencia REF-042, que la cantidad viene en cajas y no en unidades, que el precio del pedido no coincide con la tarifa vigente y que la dirección de entrega es la delegación de Girona y no la central. Cualquier solución que no valide contra tus maestros solo traslada el trabajo: en vez de teclear, alguien corrige.
Por eso la comparación no debe hacerse sobre la extracción, donde los tres enfoques acaban pareciéndose, sino sobre tres preguntas: qué pasa con un formato nuevo, quién mantiene el sistema cuando entran veinte clientes más y dónde acaban las excepciones.
Opción 1: OCR con plantillas
Se define una plantilla por formato de pedido: dónde está el número, dónde empiezan las líneas, qué columna es la cantidad. El OCR extrae el texto y un motor de reglas lo mapea a los campos del ERP.
Cuándo encaja
- Pocos clientes con formatos estables, por ejemplo cinco grandes cuentas que envían siempre el mismo documento generado por su sistema.
- Cuando hay que arrancar con el presupuesto mínimo y se acepta que alguien mantenga las plantillas.
Dónde se rompe
- Cada vez que un cliente cambia su plantilla, añade una columna o envía el pedido escaneado torcido. El mantenimiento crece con el número de clientes, no con el número de pedidos.
- La validación suele quedarse en reglas fijas: sirve para lo previsible, no para "esta referencia se parece a aquella" ni para un precio que difiere de la tarifa por un descuento pactado.
Opción 2: portal de cliente o EDI
Se pide al cliente que cambie su forma de pedir: que entre en un portal o que conecte su sistema por EDI. El pedido nace ya estructurado y no hay nada que interpretar.
Cuándo encaja
- Con grandes cuentas que ya trabajan así con otros proveedores; para ellas el EDI es lo normal y lo piden.
- Cuando el volumen de un solo cliente justifica el proyecto de integración con su sistema.
Dónde se queda corto
- Casi nunca cubre toda la cartera: el cliente mediano sigue enviando su PDF por correo, y el pequeño, un WhatsApp. Se queda con la parte del volumen que ya era la más ordenada.
- Depende de la voluntad del cliente. Un portal que nadie usa es un proyecto terminado y un proceso sin resolver.
Opción 3: IA que interpreta el documento
Un modelo de lenguaje lee el pedido como lo leería una persona: entiende qué es la cabecera y qué son las líneas aunque el formato sea nuevo, y devuelve los datos estructurados. Después, cada dato se contrasta con los maestros del ERP y lo que no encaja va a una cola de revisión.
Cómo es el flujo
Cuatro fases. Clasificar: qué ha llegado y de quién, sea PDF, Excel, foto o texto en el cuerpo del correo. Comprender: extraer cabecera y líneas con la confianza de cada dato. Validar: referencia contra el maestro de artículos, precio contra la tarifa vigente, cantidad contra el múltiplo de venta y dirección contra las del cliente. Integrar: registrar el pedido en el ERP y devolver al cliente la confirmación. Solo lo que no pasa la validación llega a una persona, con el documento y la duda señalada.
Qué exige
- Diseñar las excepciones como parte del sistema, no como fallo: quién las resuelve, con qué información y en cuánto tiempo.
- Una vía de entrada al ERP: API, importación o, si no hay otra, un robot que teclee el pedido ya validado.
- Maestros razonablemente al día, porque la validación es donde está el valor y necesita contra qué contrastar.
Comparativa de los tres enfoques
| OCR con plantillas | Portal o EDI | IA con validación | |
|---|---|---|---|
| Arranque | Rápido y barato | Un proyecto por cliente | Semanas, con un piloto acotado |
| Formato nuevo de un cliente | Nueva plantilla | No aplica: el cliente se adapta | Se lee sin configurar nada |
| Mantenimiento al crecer la cartera | Crece con cada cliente | Crece con cada integración | Estable |
| Validación contra maestros | Reglas fijas | La hace el cliente al elegir | Equivalencias, tarifa, múltiplos y direcciones |
| Cobertura de la cartera | Los clientes con plantilla | Los clientes que aceptan | Todo lo que llega por correo |
| Excepciones | Fallo de la plantilla | Las evita a costa del cliente | Cola de revisión diseñada |
Qué mirar antes de decidir
- Volumen: por debajo de unas decenas de pedidos al mes, una importación bien hecha basta.
- Heterogeneidad: cuantos más formatos distintos, menos sentido tienen las plantillas.
- Estado de los maestros: si están muy desactualizados, la validación no tendrá contra qué contrastar y hay que limpiarlos como parte del piloto.
- El ERP: SAP, Business Central, Business One, Odoo, Sage o A3 tienen vías de entrada distintas; conviene comprobarlas la primera semana, antes de construir.
Ninguna de las tres opciones excluye a las demás. Lo habitual en una empresa mediana es EDI con dos o tres grandes cuentas, IA para el correo y el PDF del resto, y una importación para lo residual. Lo que no funciona es esperar a que todos los clientes cambien su forma de pedir.
Un caso real: de 15 minutos a 30 segundos por pedido
En una corporación líder de alimentación y bebidas, los pedidos B2B llegaban en PDF y correos heterogéneos y se validaban a mano antes de entrar en SAP. Con una arquitectura event-driven sobre Azure, extracción con IA generativa y validación contra los maestros de SAP, el tiempo por pedido pasó de 15 minutos a 30 segundos. El caso completo está publicado.
Preguntas frecuentes
¿Funciona con pedidos escaneados o fotografiados?
Sí. Los modelos actuales leen la imagen directamente. La calidad del escaneo afecta a la confianza de cada dato, y la validación lo recoge: un dato dudoso va a revisión en lugar de entrar mal en el ERP.
¿Y los pedidos en el cuerpo del correo o por WhatsApp?
Reciben el mismo tratamiento que un PDF: texto libre que hay que estructurar y validar. La diferencia está en la vía de entrada al canal, que en el caso de la mensajería hay que resolver antes.
¿Hay que entrenar el modelo con mis pedidos?
No en el sentido clásico. Se configura con ejemplos y reglas de negocio. Lo que sí se acumula con el uso son las equivalencias confirmadas: la referencia con la que te pide un cliente y la tuya, la unidad que usa y la que vende tu ERP. Cada excepción resuelta una vez deja de serlo.
¿Cuánto se tarda en ver el primer pedido entrando solo?
Un piloto acotado a los clientes de más volumen se mide en semanas. La primera de ellas se dedica a comprobar la vía de entrada al ERP y el estado de los maestros, que es lo que decide el resto del plazo.
Cómo funciona el flujo completo, qué necesita tu empresa y cuándo compensa, en automatización de la entrada de pedidos. Y si quieres verlo aplicado a tu sector antes de hablar con nadie, pide el primer vistazo gratuito indicando "entrada de pedidos".