Automatizar pedidos por email y PDF: qué exigir antes de conectarlos al ERP

Hablamos de una orden enviada por tu cliente que debe convertirse en un pedido de venta. No es el circuito de facturas de proveedores, ni un bot que conversa para tomar pedidos por WhatsApp. El comprador de este proyecto es operaciones o administración comercial, junto con IT, y quiere dejar de transcribir documentos sin perder control comercial.

Primero elegí qué parte necesitás comprar

Compará tres caminos sobre los mismos documentos y reglas:

En Argentina, Bejerman publica un gestor de pedidos con IA mediante integración con OrderToB. La página aclara que esas capacidades llegan a través de terceros. Es una razón para consultar primero al proveedor del ERP, no para asumir que tu instalación ya las incluye.

También importa qué significa “captura automática”. La página específica de Vreo para México describe carga manual de PDF o Word, un lector configurado por formato y confirmación humana en Odoo. Aclara que no monitorea correo ni reconoce imágenes escaneadas. Ese alcance puede servirte, pero no equivale a procesar un buzón sin intervención.

No elijas por la etiqueta IA. Si un lector de formatos repetitivos resuelve el trabajo, pedí probarlo antes de sumar componentes.

Definí qué dato manda cuando hay diferencias

El documento dice qué solicita el cliente. No autoriza por sí solo a cambiar precios, crear productos, reemplazar una dirección o saltear aprobaciones. Las reglas deben quedar fuera del texto libre del correo.

Acordá con ventas e IT estas decisiones:

• Cliente y referencia: cómo vincular la orden con la cuenta correcta y conservar su número externo.
• Producto: qué tabla traduce el código del cliente a tu SKU, el identificador interno del artículo. Una descripción parecida no alcanza para sustituirlo.
• Unidad: de dónde sale la equivalencia entre cajas, unidades o kilos. Si falta, el pedido queda en revisión.
• Precio y moneda: qué lista o acuerdo vigente se consulta y quién resuelve diferencias con el documento.
• Entrega: qué fuente valida dirección y disponibilidad; leer una fecha solicitada no significa comprometerla.
• Aprobación: quién puede autorizar el alta y qué excepciones deben detenerla.

La pantalla de revisión debería mostrar el original, los datos extraídos y el motivo de cada bloqueo. Corregir un campo tiene que dejar rastro de quién lo cambió y por qué. No conviertas una corrección puntual en una nueva regla comercial automática.

Un correo recibido no es un pedido confirmado

La documentación de n8n para Email Trigger IMAP permite configurar el buzón y la descarga de adjuntos. Eso resuelve una entrada técnica, no la identidad comercial, la aprobación ni la escritura en tu ERP.

Separá los estados que el equipo necesita ver: recibido, requiere revisión, aprobado para registrar y registrado con identificador. Si el ERP admite borradores, definí si el alcance termina ahí o incluye confirmar el pedido. Facturación, cobro y despacho son otras operaciones.

Pedí además dos controles:

• Reenvíos y revisiones. La clave del correo no alcanza para identificar el pedido comercial. Un reenvío puede tener otro mensaje; una corrección puede conservar el número de orden. Acordá una clave por cliente y referencia, conservá versiones y mostrá diferencias antes de reemplazar cantidades.
• Resultado incierto. Si la conexión se corta al crear el pedido, consultá si quedó registrado antes de volver a escribir. HTTP 202 significa aceptado para procesamiento, no completado; si tu interfaz usa ese estado, debe existir una forma de comprobar el desenlace.

Un acuse de recepción puede decir “recibimos tu solicitud”. Confirmar cantidades, precio o fecha al cliente requiere el estado y la autorización acordados. No mezcles ambos mensajes.

Una prueba que debería estar en la propuesta

Este escenario es ficticio y sirve como prueba de aceptación, no como caso de éxito.

Llega la orden P-42: dos cajas de un producto. El catálogo identifica el artículo, pero no tiene definida la cantidad de unidades por caja. Después llega un reenvío idéntico y, más tarde, una corrección que pide tres cajas con la misma referencia.

El resultado esperado es:

• El primer documento queda en revisión por unidad sin equivalencia; no se carga como dos unidades.
• El reenvío se asocia al mismo pedido y no genera otra alta.
• La corrección conserva ambas versiones y exige revisar el cambio de cantidad.
• Una persona autorizada valida la equivalencia, el precio y la versión vigente.
• La integración registra una sola versión aprobada y permite recuperar su identificador y comprobar sus líneas en el ERP.

Si el primer pedido ya estaba registrado, la corrección debe seguir el procedimiento de modificación del ERP. No se resuelve borrando evidencia ni creando otro pedido silenciosamente.

Probá también un archivo ilegible, un cliente desconocido y una interrupción durante el alta. Acordá por escrito qué resultados bloquean la aceptación. Una demostración con un PDF fácil no cubre estas situaciones.

Qué llevar a una evaluación y cómo medirla

Prepará formatos de muestra sin información confidencial, ERP y versión, volumen de documentos y líneas, pasos actuales y excepciones frecuentes. No envíes contraseñas ni precios privados en el primer contacto.

La propuesta debería separar configuración, integración, servicios externos, revisión humana y soporte. Medí tiempo total hasta el registro, correcciones por campo, duplicados y minutos de revisión, comparando documentos similares. Procesar más archivos no demuestra ahorro si el equipo termina corrigiéndolos uno por uno.

En DuoTach ofrecemos automatización e integración de sistemas con n8n. Podemos evaluar el tramo entre tu correo y tu ERP; la viabilidad y el alcance se definen según interfaces, permisos y controles disponibles. Consultá por la integración de pedidos. El enlace abre un formulario, no reserva una reunión.

Preguntas frecuentes