Partes de taller en papel, recepciones de almacén que se teclean horas después, albaranes firmados que alguien escanea, pedidos que se copian de la tienda al ERP a mano. Si tu empresa trabaja con SAP, Navision, Business Central, Odoo u otro ERP y algún proceso se queda fuera de él, eso es lo que resolvemos: desarrollamos integraciones y aplicaciones que conectan el ERP con tu tienda online y con el resto de la empresa. Basta con que cada sistema tenga una vía de acceso: una API, servicios web, una base de datos o un intercambio de ficheros. En este artículo repasamos qué se puede construir, cómo se plantea según el caso y un proyecto real que el cliente necesitaba con urgencia.
El hueco entre el ERP y el resto de la empresa
Un ERP sabe lo que pasa en la empresa solo si alguien se lo cuenta. En las oficinas eso funciona: hay un ordenador y alguien que teclea. En el taller, en el almacén o en la furgoneta de reparto, quien genera el dato suele tener las manos ocupadas, no tiene usuario en el ERP o trabaja con un dispositivo que el ERP no contempla. Lo habitual entonces es el papel o la hoja de cálculo, y alguien que horas después lo pasa al sistema.
El coste no aparece en ninguna factura, pero se nota: datos que llegan tarde, errores de transcripción y automatismos del ERP que no se disparan porque nadie ha registrado el evento que los activa. Lo mismo pasa entre sistemas: una tienda, un marketplace o un transportista que no se hablan con el ERP obligan a alguien a copiar datos de una pantalla a otra.
Qué se puede construir: desarrollos habituales alrededor de un ERP
Estos son algunos ejemplos de desarrollos habituales en empresas que trabajan con un ERP. Todos siguen el mismo principio: el ERP manda y la aplicación o la integración le acerca los datos.
- Partes de producción en planta. Registro del avance de cada pedido por sección o puesto con lectores de códigos de barras, incidencias incluidas, para saber en qué punto está cada pedido sin ir a preguntar.
- Recepción y expedición en almacén. Entradas de compra, preparación de pedidos, inventarios y ubicaciones con PDA o tablet, contra los pedidos reales del ERP.
- Albarán digital y prueba de entrega. Firma del cliente en pantalla, fotos o incidencias en el momento de la entrega, y el albarán firmado en el ERP sin escanear papel.
- Portal B2B para clientes. Pedidos, tarifas personalizadas, stock, facturas y albaranes consultados directamente del ERP.
- Portal de proveedores. Confirmación de pedidos de compra, fechas de entrega y documentación sin ir y venir por correo.
- App comercial. Catálogo, precios y toma de pedidos en la visita al cliente, también con mala cobertura.
- Partes de servicio técnico. Avisos, horas, material y firma del cliente desde el móvil del técnico.
- Middleware de marketplaces y transporte. Pedidos de varias tiendas o marketplaces hacia un único ERP, y etiquetas y seguimiento de los transportistas de vuelta.
- Cuadros de mando. Ventas, márgenes o producción con datos del ERP, para quien no necesita entrar en él.
Un caso real: urgente y entregado a tiempo
Un cliente industrial con quien ya trabajábamos en su tienda online nos pidió una aplicación para registrar desde el taller el avance de cada pedido y digitalizar las recepciones y entregas del almacén, con firma del cliente en una tablet. Su sistema central es Microsoft Dynamics NAV (Navision), y la condición era clara: todo tenía que quedar en NAV, que es quien factura, imprime y avisa al cliente.
Lo necesitaba con urgencia. Construimos una sola aplicación web con dos herramientas, una para las PDA del taller y otra para las tablets del almacén, conectada a NAV por sus servicios web. La aplicación no tiene base de datos propia: todo lo que muestra lo consulta a NAV y todo lo que registra lo escribe en NAV, que sigue disparando sus propios automatismos. Lo único que guarda es, en la PDA, lo registrado mientras no hay cobertura, y solo hasta que vuelve la red y se envía a NAV. En nuestra opinión, esa fue la decisión más importante del proyecto, porque no deja una segunda base de datos que sincronizar ni que mantener.
La entregamos en siete hitos entre julio y septiembre de 2026, y cada uno llegó en la fecha comprometida. El cliente pudo probar cada parte (primero el taller, después las recepciones, por último las entregas con firma e impresión) antes de pasar a la siguiente.
Cómo cumplir plazos con un ERP de por medio
En un proyecto con prisa, el riesgo no suele estar en la aplicación. Está en todo lo que depende de otros: que el ERP publique los servicios que hacen falta, que den acceso al entorno de pruebas, que alguien responda a las dudas a tiempo. Esto es lo que nos permitió cumplir:
- Un documento de alcance compartido entre el cliente, quien mantiene su ERP y nosotros: qué hace cada pantalla, qué servicios hacen falta, qué queda fuera y qué dudas siguen abiertas. Se actualiza con cada respuesta.
- Un simulador del ERP para desarrollar sin esperar a que los servicios web reales estuvieran listos. Con una regla: ningún hito se da por terminado hasta probarlo contra el ERP real.
- Entregas por hitos que el cliente puede probar, en lugar de una entrega única al final.
- Dejar por escrito quién valida qué. Hay reglas que el ERP no comprueba y que debe aplicar la aplicación. Si no se acuerda al principio, el error aparece con los datos ya mal.
- Pensar en la cobertura desde el primer día. En un taller el wifi falla. Lo que se registra en la PDA se guarda en el dispositivo y se envía solo al volver la red, sin duplicarse.
Creemos que la urgencia se gestiona mejor con este tipo de orden que con horas extra: cuando todo el mundo sabe qué se entrega, cuándo y qué falta por resolver, los bloqueos aparecen pronto y se resuelven a tiempo.
SAP, Navision, Business Central, Odoo o cualquier sistema con acceso
El enfoque no depende del ERP. Lo que necesitamos es una vía de acceso y los permisos para usarla:
- SAP. En SAP S/4HANA, la vía habitual son sus API OData publicadas en el SAP Business Accelerator Hub, y en sistemas más antiguos, BAPI e IDoc. SAP Business One, pensado para empresas medianas, ofrece su Service Layer, una API REST. En empresas grandes suele haber un equipo SAP propio o un partner que publica lo que falta y da los permisos, y conviene implicarlo desde el principio.
- Navision (Dynamics NAV). Servicios web SOAP u OData publicados desde el propio NAV. Suele haber que crear o ampliar alguno, y eso lo hace quien mantiene el ERP.
- Business Central. Microsoft recomienda sus API REST para las integraciones nuevas y ha anunciado que retirará SOAP en una próxima versión. Quien migra de NAV a Business Central tiene que revisar sus integraciones antiguas.
- Odoo. Su API externa permite leer y escribir los datos a los que tenga permiso el usuario de la integración, y los módulos propios amplían lo que falte. Desde Odoo 19, la vía recomendada es la nueva API JSON-2, y las antiguas XML-RPC y JSON-RPC quedan en desuso. En Odoo Online, el acceso a la API depende del plan contratado.
- Cualquier otro sistema. Otros ERP, CRM, software de gestión de almacén, transportistas o aplicaciones hechas a medida hace años. Si tiene una API, servicios web, acceso a su base de datos o un intercambio de ficheros que podamos automatizar, se puede integrar.
Un consejo práctico: concentrar en un solo punto de la aplicación todo lo que habla con el ERP. Si el día de mañana la empresa pasa de Navision a Business Central, el cambio de SOAP a API REST se hace ahí, sin tocar las pantallas que usa el equipo.
La forma de la integración se elige según dónde vive el proceso y cuántos sistemas intervienen:
- Dentro de la tienda. Cuando el proceso es de la tienda online y solo hay que hablar con un sistema, un módulo propio es lo más directo. Así funcionan nuestros conectores de Magento con Navision, Business Central y Odoo (más detalle en la integración de Magento con el ERP). También trabajamos las integraciones de Shopify con el ERP.
- Un middleware entre la tienda y el resto. Una aplicación intermedia que recibe los pedidos de la tienda, los traduce al formato del ERP y devuelve stock, precios o estados de envío. La tienda no tiene que esperar a que responda el ERP, los pedidos esperan en cola si el ERP está parado, y las reglas de traducción viven en un solo sitio. Compensa cuando hay varias tiendas o marketplaces contra el mismo ERP, cuando entran más sistemas en juego (almacén, transporte, PIM) o cuando el ERP es lento.
- Una aplicación independiente. Cuando el proceso no pasa por la tienda, como un parte de taller o una entrega firmada, igual que en el caso anterior.
Para el middleware y las aplicaciones independientes solemos trabajar con Node.js o Next.js.
¿Aplicación a medida o módulo del ERP?
No siempre compensa una aplicación propia. Si el ERP o un módulo estándar de tu partner cubre el proceso, suele ser la mejor opción. Estas preguntas ayudan a decidir:
- ¿El proceso se hace en un dispositivo que el ERP no contempla (pistola lectora, tablet, móvil)?
- ¿Lo hacen personas que no tienen, ni deben tener, usuario en el ERP?
- ¿Necesita funcionar con mala cobertura?
- ¿Es un proceso propio de tu empresa, que ningún módulo estándar describe bien?
- ¿Lo que te ofrecen exige cambiar de ERP o una licencia por usuario para gente que solo necesita pulsar tres botones?
Si respondes que sí a dos o más, nos inclinamos a pensar que una aplicación a medida, pequeña y centrada en ese proceso, te saldrá mejor que forzar el ERP.
Por qué nos lo encargan a nosotros
Ninguno de estos proyectos empezó con un cliente buscando "desarrollo de aplicaciones". Empezaron con clientes con los que ya trabajábamos en su tienda online, que nos conocían y que sabían que ya habíamos conectado su tienda con su ERP. Cuando apareció otro proceso que conectar, y además con prisa, preguntaron primero a quien ya conocía sus sistemas.
A nuestro juicio, esa es la ventaja de un socio tecnológico frente a un proveedor por proyecto: conocemos tu ERP, tus datos y la forma en que trabaja tu equipo, y no hay que explicarlo todo desde cero cada vez.
Preguntas frecuentes
¿Se puede integrar SAP con una tienda online o una aplicación propia?
Sí. SAP S/4HANA expone API OData, y los sistemas más antiguos, BAPI e IDoc; SAP Business One tiene su Service Layer. La integración se hace contra esas interfaces, con los permisos que dé el equipo que mantiene SAP.
¿Se puede conectar una aplicación propia a Navision?
Sí, a través de los servicios web que publica NAV (SOAP u OData). Si los que necesitas no existen, quien mantiene tu ERP puede crearlos, y nosotros desarrollamos la aplicación que los usa.
¿Funciona igual con Business Central en la nube?
Sí. Business Central ofrece API REST, que es la vía que recomienda Microsoft, y el acceso se autoriza con OAuth. Cambia la forma de conectarse, pero el planteamiento de la aplicación es el mismo.
¿Qué es un middleware y cuándo hace falta?
Es una aplicación intermedia que conecta la tienda (o varias) con el ERP y otros sistemas, traduce los datos entre ellos y guarda en cola lo que no se puede enviar en ese momento. Hace falta cuando intervienen varios sistemas o cuando la tienda no debe depender de la velocidad del ERP.
¿Hay que cambiar de ERP para hacer esto?
No. La aplicación se adapta a tu ERP y lo deja como sistema central. Basta con que tenga una vía de acceso (API, servicios web, base de datos o ficheros) y que nos den permisos para usarla.
Si tienes un proceso que hoy vive en papel o en una hoja de cálculo y debería estar en tu ERP, o dos sistemas que no se hablan, cuéntanos cuál es.
