La aplicación de los técnicos, el portal de pedidos o la tienda online necesitan los clientes, los artículos y el stock del ERP, y el ERP necesita lo que esas aplicaciones generan. Conectarlos bien ahorra horas de tecleo; conectarlos mal crea pedidos duplicados, stocks que no cuadran y errores que nadie ve. Esta es una guía técnica, escrita por fabricantes de ERP, sobre las tres vías de integración, cómo sincronizar los datos y qué hacer cuando tu ERP no tiene API.
Resumen rápido
| Pregunta | Respuesta corta |
|---|---|
| ¿Mejor vía? | La API del ERP, si existe y cubre lo que necesitas |
| ¿Y si no hay API? | Lectura de la base de datos, tablas intermedias o ficheros programados |
| ¿Escribir directamente en las tablas del ERP? | No, salvo que el fabricante lo controle |
| ¿Al momento o cada cierto tiempo? | Al momento lo que ve el cliente; cada cierto tiempo, el resto |
| ¿Lo más importante? | Un dueño para cada dato, sin duplicados y con aviso si algo falla |
| ¿Facturar desde la aplicación? | Mejor que facture el ERP, ya adaptado a Verifactu |
Qué es integrar un ERP con una aplicación propia
Integrar un ERP con una aplicación propia es hacer que los dos programas intercambien datos solos y de forma fiable: la aplicación lee del ERP clientes, artículos, precios o stock, y le devuelve pedidos, partes o lecturas. Se hace por API, por la base de datos o con ficheros, con control de errores y sin duplicar información.
En la página de integración del ERP explicamos qué conectamos y cómo trabajamos. Aquí entramos en el detalle técnico: cómo funciona cada vía por dentro, qué decisiones de diseño evitan problemas y qué preguntar a quien vaya a hacer la integración. Si estás pensando en la aplicación en sí, empieza por programas a medida.
Las integraciones más habituales en una pyme son estas:
Cinco preguntas antes de elegir la vía de integración
La vía técnica es la última decisión, no la primera. Antes hay que responder a esto:
| Pregunta | Ejemplo de respuesta | Por qué importa |
|---|---|---|
| 1. ¿Qué datos viajan? | Clientes, artículos, precios, stock, pedidos | Define el alcance y el esfuerzo |
| 2. ¿En qué sentido? | Artículos del ERP a la aplicación; pedidos de la aplicación al ERP | Un sentido es mucho más sencillo que dos |
| 3. ¿Cada cuánto? | Stock al momento; tarifas cada noche | Decide si hace falta API o basta con ficheros |
| 4. ¿Cuántos? | Unos pocos pedidos al día o miles de lecturas por hora | Afecta al rendimiento y al diseño |
| 5. ¿Quién manda sobre cada dato? | El precio lo manda el ERP; la firma del parte, la aplicación | Evita que un programa machaque lo del otro |
La quinta es la más importante. Cada dato tiene que tener un único programa «dueño», el único donde se crea y se modifica. Los demás solo lo leen. Cuando dos programas pueden cambiar el mismo dato (por ejemplo, el teléfono de un cliente en el ERP y en la aplicación), tarde o temprano aparecen conflictos que nadie sabe resolver.
Vía 1: conectar con la API del ERP
Una API (Application Programming Interface) es una puerta que el ERP abre a otros programas. La aplicación no toca las tablas del ERP: le hace peticiones («dame el stock del artículo A-100», «crea este pedido») y el ERP responde aplicando sus propias reglas, igual que si el pedido se hubiera introducido en pantalla.
Hoy, lo normal es una API de servicios web que intercambia datos en formato JSON a través de HTTPS. Estos son los conceptos que conviene conocer:
- Autenticación: la aplicación se identifica con un usuario técnico, una clave o un token. Nunca con el usuario de una persona.
- Permisos: ese usuario técnico solo puede hacer lo que la integración necesita. Si solo crea pedidos, no debería poder borrar clientes.
- Validación: el ERP comprueba cada operación (cliente existente, artículo activo, precio correcto) y la rechaza con un mensaje claro si algo no cuadra.
- Versiones: una API versionada permite que el ERP evolucione sin romper las integraciones que ya funcionan.
- Límites: algunas API limitan el número de peticiones por minuto; hay que tenerlo en cuenta en integraciones con mucho volumen.
- Avisos (webhooks): algunas API pueden avisar a la aplicación cuando algo cambia, en lugar de que la aplicación pregunte constantemente.
Así viaja, por ejemplo, un pedido desde una aplicación propia hasta el ERP. Los datos son ficticios:
| Campo enviado | Valor de ejemplo | Qué comprueba el ERP |
|---|---|---|
| Identificador de origen | APP-2026-000154 | Que no exista ya: evita duplicados |
| Cliente | Código 4300125 | Que exista y no esté bloqueado |
| Línea 1 | A-100 · 12 unidades | Artículo activo y stock disponible |
| Precio | Lo calcula el ERP | Tarifa y descuentos del cliente |
| Fecha de entrega | 14/11/2026 | Fecha válida y día laborable |
| Respuesta del ERP | Pedido PV-26-03318 creado | La aplicación guarda el número para consultarlo después |
Fíjate en la fila del precio: la aplicación no envía el precio, lo calcula el ERP. Es un ejemplo de la regla del dueño: si las tarifas viven en el ERP, ningún otro programa debería decidir el precio.
Vía 2: conectar a través de la base de datos
Cuando el ERP no ofrece API, o la que ofrece no cubre lo que se necesita, la integración puede trabajar con su base de datos. Aquí hay que distinguir claramente entre leer y escribir.
| Operación | Cómo se hace bien | Riesgo si se hace mal |
|---|---|---|
| Leer | Usuario de solo lectura y vistas preparadas con los datos justos | Consultas pesadas que ralentizan el ERP en horas punta |
| Escribir | En tablas intermedias que el ERP valida y procesa con su propia lógica | Saltarse validaciones: stock, contabilidad o numeración descuadrados |
| Escribir directamente en las tablas del ERP | Solo el fabricante, que sabe qué otras tablas dependen de cada dato | Datos incoherentes y pérdida del soporte del fabricante |
Un ejemplo de por qué no se debe escribir a ciegas: crear un albarán en un ERP no es insertar una fila. Suele implicar mover stock, actualizar el pendiente del pedido, calcular precios y descuentos, reservar numeración y, más adelante, contabilizar. Si la aplicación solo inserta la cabecera y las líneas, el albarán «existe», pero el resto del ERP no se ha enterado.
Por eso, como fabricantes del ERP Praxis desde 1988, insistimos tanto en este punto: leer de la base de datos es una vía rápida y muy útil para consultas e informes; escribir hay que hacerlo siempre a través de procesos que el propio ERP controla.
Vía 3: el intercambio de ficheros
Es la vía más antigua y la más universal: un programa deja un fichero en una carpeta o en un servidor, y el otro lo recoge y lo procesa. Funciona casi con cualquier programa, incluidos los que no tienen API ni permiten acceder a su base de datos.
Una integración por ficheros fiable necesita cuatro cosas: nombres únicos (con fecha, hora y número), mover cada fichero a «procesados» o «con errores» para no leerlo dos veces, un formato acordado por escrito (separador, decimales, codificación de caracteres) y un aviso cuando un fichero no llega o no se puede procesar. Su límite es que no es al momento: los datos viajan cada cierto tiempo.
Estudiamos qué permite tu ERP y te decimos con claridad qué vía es viable y segura.
Comparativa: API, base de datos o ficheros
| Criterio | API | Base de datos | Ficheros |
|---|---|---|---|
| Rapidez de los datos | Al momento | Al momento para leer | Cada cierto tiempo |
| Validaciones del ERP | Sí, las del propio ERP | Solo con tablas intermedias | Las del proceso de importación |
| Seguridad | Alta, con usuario y permisos | Buena con solo lectura | Buena con servidor cifrado |
| Resistencia a actualizaciones del ERP | Alta si está versionada | Puede necesitar ajustes | Alta si el formato no cambia |
| Requisito | Que el ERP tenga API | Conocer el ERP por dentro | Casi ninguno |
| Ideal para | Pedidos, stock, portales, apps móviles | Informes, cuadros de mando, consultas | Tarifas, catálogos, EDI, programas antiguos |
En la práctica, muchas integraciones combinan vías: la aplicación lee el catálogo de una vista de la base de datos, consulta el stock al momento por API y recibe las tarifas de la nueva temporada en un fichero.
Cómo y cuándo sincronizar los datos
Además de la vía, hay que decidir el momento en que viajan los datos. Hay cuatro patrones:
| Patrón | Cómo funciona | Cuándo usarlo |
|---|---|---|
| Consulta al momento | La aplicación pregunta al ERP cuando lo necesita | Stock, riesgo de un cliente, estado de un pedido |
| Aviso por evento | El ERP avisa cuando algo cambia (webhook o cola de mensajes) | Cambios que la aplicación debe conocer enseguida |
| Sondeo periódico | Cada pocos minutos, la aplicación pide «lo que ha cambiado desde la última vez» | Cuando el ERP no puede avisar |
| Lotes programados | Una vez al día o por la noche se envía todo un bloque | Catálogos, tarifas, informes |
El sondeo periódico necesita que cada registro tenga una fecha de última modificación fiable: así la aplicación solo pide lo nuevo y no tiene que descargarlo todo cada vez. Si el ERP no la tiene, la alternativa es comparar, lo que es más lento.
Este es el recorrido completo de un pedido bien integrado:
- 1. Pedido en la aplicacióncon un identificador único de origen
- 2. Cola de envíoel pedido queda guardado aunque falle la conexión
- 3. Envío al ERPpor API o tabla intermedia, con usuario técnico
- 4. Validación del ERPcliente, artículos, stock, precios y duplicados
- 5. Registro y respuestanúmero de pedido del ERP o motivo del rechazo
- 6. Confirmaciónla aplicación muestra el estado; si hay error, se avisa a una persona
Duplicados, errores y reintentos: lo que separa una buena integración
La mayoría de las integraciones que fallan lo hacen en silencio. Estas son las decisiones de diseño que lo evitan:
- Identificador único de origen. Cada pedido, parte o lectura lleva un código propio de la aplicación. Antes de crear nada, el ERP comprueba si ya lo tiene. Así, enviar dos veces lo mismo no crea dos documentos.
- Tabla de correspondencias. La aplicación y el ERP no siempre usan los mismos códigos. Una tabla relaciona cada código de un programa con el del otro, y se mantiene sola.
- Cola y reintentos. Si el ERP no responde (copia de seguridad, actualización, corte de red), la operación se guarda y se reintenta. Nada se pierde.
- Errores con nombre y apellidos. «Artículo A-100 dado de baja» se puede resolver; «Error 500», no. El mensaje tiene que decir qué falla y en qué documento.
- Registro de cada intercambio. Qué se envió, cuándo, qué respondió el ERP. Es lo primero que se mira cuando alguien dice «este pedido no llegó».
- Aviso a una persona. Lo que no se puede resolver solo, llega por correo o a una bandeja de incidencias, no se queda escondido en un registro.
Qué hacer si tu ERP no tiene API
Es más habitual de lo que parece, sobre todo con programas que llevan años en la empresa. Las opciones, de la más recomendable a la menos:
| Opción | Cómo funciona | A tener en cuenta |
|---|---|---|
| Pedir la conexión al fabricante | El fabricante del ERP desarrolla la API o el proceso de importación | La más segura, pero depende de su disposición y sus plazos |
| Lectura + tablas intermedias | Se lee con solo lectura; se escribe en tablas que el ERP procesa | Necesita que el ERP tenga, o permita, ese proceso de importación |
| Ficheros programados | Se usan las importaciones y exportaciones que ya tiene el ERP | No es al momento, pero es robusta |
| Un programa intermedio | Una pieza a medida traduce entre la aplicación y el ERP y centraliza errores y registros | Añade una pieza, pero aísla a la aplicación de los cambios del ERP |
| Automatizar las pantallas | Un robot introduce los datos en las pantallas del ERP como una persona | Último recurso: frágil ante cualquier cambio de pantalla |
Si llegas a la última fila, conviene preguntarse si el problema es la integración o el ERP. A veces, la respuesta honesta es que hace falta cambiar de ERP sin parar la empresa.
Seguridad, datos personales y Verifactu
¿Y Verifactu? El Real Decreto 1007/2023, el reglamento de Verifactu, afecta a los programas con los que se emiten facturas. Si tu aplicación propia emite facturas, también es un sistema de facturación y tiene que cumplirlo. Por eso, en la mayoría de los casos recomendamos que la aplicación envíe pedidos, albaranes o partes al ERP, y que sea el ERP, ya adaptado, quien facture. Te lo explicamos en la guía completa de Verifactu.
Lista de comprobación antes de poner en marcha una integración
- ¿Está escrito qué datos viajan, en qué sentido, cada cuánto y quién manda sobre cada uno?
- ¿La vía elegida usa las validaciones del ERP, o las reproduce?
- ¿Cada operación lleva un identificador único que impide duplicados?
- ¿Hay cola y reintentos si el ERP no responde?
- ¿Los errores dicen qué falla y en qué documento?
- ¿Hay registro de cada intercambio y alguien que recibe los avisos?
- ¿El usuario técnico tiene solo los permisos necesarios?
- ¿Se ha probado con una copia de los datos, incluidos casos raros (cliente bloqueado, artículo de baja, sin stock)?
- ¿Está documentada, para que no dependa de una sola persona?
- ¿Quién la mantiene cuando se actualice el ERP o la aplicación?
Glosario rápido
- API: interfaz que un programa ofrece para que otros le pidan datos o le envíen operaciones.
- Servicio web: API a la que se accede a través de internet o de la red, normalmente con HTTPS.
- JSON: formato de texto para intercambiar datos estructurados entre programas.
- Webhook: aviso automático que un programa envía a otro cuando algo cambia.
- Tabla intermedia: tabla donde una aplicación deja datos para que el ERP los valide y los procese.
- Idempotencia: propiedad de una operación que, repetida, no produce efectos duplicados.
- EDI: intercambio electrónico de documentos comerciales en formatos estándar.
Preguntas frecuentes sobre la integración del ERP
¿Qué es la API de un ERP?
Es una puerta de entrada que el ERP ofrece a otros programas para pedirle datos o enviarle operaciones de forma controlada, normalmente a través de servicios web, con usuario, permisos y validaciones propias del ERP.
¿Se puede integrar un ERP que no tiene API?
Casi siempre. Se puede leer de la base de datos con un usuario de solo lectura, escribir a través de tablas intermedias que el ERP procesa, intercambiar ficheros programados o pedir al fabricante que desarrolle la conexión.
¿Es peligroso que una aplicación escriba directamente en la base de datos del ERP?
Sí, si se hace sin conocer el ERP por dentro: se pueden saltar validaciones, descuadrar stock o contabilidad y perder la garantía del fabricante. Lo seguro es escribir a través de la API o de procesos controlados que el propio ERP valida.
¿Qué es mejor, sincronizar al momento o cada cierto tiempo?
Depende del dato. El stock o la disponibilidad que ve un cliente conviene consultarlos al momento. Catálogos, tarifas o informes se pueden sincronizar cada cierto tiempo, lo que reduce la carga y simplifica la integración.
¿Cómo se evitan los pedidos duplicados en una integración?
Cada operación lleva un identificador único de origen, por ejemplo el número de pedido de la aplicación. Antes de crear el documento, el ERP comprueba si ese identificador ya existe; si existe, no lo vuelve a crear.
¿Qué pasa si la conexión falla a mitad de un envío?
Una integración bien hecha guarda la operación pendiente, la reintenta y, si sigue fallando, avisa a una persona. Gracias al identificador único, el reintento no crea duplicados.
¿Mi aplicación propia puede emitir facturas con Verifactu?
Si la aplicación emite facturas, es un sistema de facturación y tiene que cumplir el reglamento de Verifactu. Lo más sencillo suele ser que la aplicación envíe pedidos, albaranes o partes al ERP y que sea el ERP, ya adaptado, quien facture.
¿Cuánto cuesta integrar un ERP con otra aplicación?
Depende de la vía disponible, del número de datos que viajan, de los sentidos de la comunicación y del control de errores necesario. Lo razonable es un estudio técnico previo y un presupuesto cerrado.
¿Se rompe la integración cuando se actualiza el ERP?
Una integración por API versionada suele resistir las actualizaciones. Las que leen la base de datos o dependen de ficheros pueden necesitar ajustes, por eso conviene un mantenimiento y avisos que detecten el fallo al momento.
¿Integráis el ERP Praxis con aplicaciones propias?
Sí. Como fabricantes de Praxis desde 1988 conocemos su estructura y elegimos en cada caso la vía más segura. También estudiamos integraciones con otros ERP.
Integración del ERP con CSI
En CSI somos fabricantes de ERP y desarrollamos las aplicaciones que se conectan a él, así que conocemos los dos lados de la integración. Estudiamos qué permite tu ERP, elegimos la vía más segura y la programamos con control de errores, registro y avisos. Mira qué conectamos en integración del ERP, qué aplicaciones podemos hacer en programas a medida, o casos concretos como un portal de pedidos B2B, una app de partes de trabajo o nuestro lector OCR de facturas, un proyecto real.
Artículo informativo elaborado por CSI en noviembre de 2026. Los datos de los ejemplos son ficticios. La normativa de Verifactu puede cambiar: consulta tu caso con tu asesor fiscal.