Cuando el sitio y el sistema administrativo viven separados, alguien en tu empresa hace de puente: captura dos veces, corrige diferencias y manda estados de cuenta en PDF. Conectar tu sitio web con tu ERP y tu facturación elimina ese trabajo, pero es un proyecto de operaciones antes que de programación. Lo primero que se decide no es la tecnología, sino qué dato manda en cada caso y qué pasa cuando la conexión falla.
Qué se puede sincronizar entre el sitio web y el ERP
Casi cualquier dato que hoy consultas en tu sistema puede mostrarse o capturarse en un portal. Los seis que más valor aportan en una empresa que vende a otras empresas son estos:
- Inventario. Existencias por almacén o sucursal. Conviene decidir si se muestra la cantidad exacta, un rango o solo «disponible», y si se descuenta lo apartado en pedidos sin surtir.
- Precios por cliente. Listas de precios, descuentos por volumen y condiciones negociadas. El cliente ve su precio después de iniciar sesión, no el de lista.
- Pedidos. El pedido nace en el sitio y entra al ERP como pedido o cotización, con el mismo folio que después verá almacén y cobranza.
- Clientes. Alta, datos fiscales, direcciones de entrega, límite de crédito y agente asignado.
- Estados de cuenta. Saldo, facturas vencidas y por vencer, pagos aplicados. Reduce las llamadas a cobranza.
- Facturas CFDI. Descarga de XML y PDF de cada factura, y en algunos casos autofacturación de compras hechas como público en general.
Para cada dato hay que definir una fuente de verdad y una dirección. Lo habitual es que inventario, precios y saldos viajen del ERP al sitio, y que los pedidos viajen del sitio al ERP. Los datos de clientes son los delicados: si se pueden editar en ambos lados sin una regla clara, terminas con dos versiones del mismo cliente.
Cuatro formas de integrar, con ventajas y riesgos
No hay una vía correcta para todos. Depende de lo que tu ERP permita, de si está en la nube o en un servidor propio y de qué tan actualizado necesitas cada dato.
| Forma de integrar | Cómo funciona | Ventajas | Riesgos |
|---|---|---|---|
| API del ERP | El sitio consulta y escribe mediante los servicios web que publica el fabricante del sistema. | Datos casi en tiempo real; respeta las reglas de negocio del ERP; es la vía que el fabricante soporta. | Puede requerir licencia o módulo adicional; hay límites de peticiones; si el ERP se cae, el sitio debe saber qué hacer. |
| Middleware | Una capa intermedia recibe los datos de ambos lados, los transforma, los encola y reintenta. | Aísla al sitio de los cambios del ERP; deja bitácora de cada movimiento; permite sumar después un CRM o un marketplace. | Es una pieza más que mantener y vigilar; mal diseñada se vuelve una caja negra que nadie entiende. |
| Archivos programados | El ERP exporta archivos CSV o XML cada cierto tiempo y el sitio los importa. | Funciona con sistemas antiguos sin API; es barato y fácil de auditar. | Los datos llegan con retraso; un archivo incompleto puede borrar precios o existencias si no se valida antes de aplicarlo. |
| Base de datos intermedia | Una réplica con las tablas necesarias, separada del ERP, de la que lee el sitio. | Consultas rápidas; el sitio no carga al servidor del ERP ni toca sus tablas. | Hay que cuidar la frecuencia de réplica; escribir directo en tablas del ERP se salta sus validaciones y puede anular el soporte del fabricante. |
En la práctica se combinan: existencias y precios por réplica o archivo cada pocos minutos, y pedidos por API en el momento. Lo que sí es regla es que el sitio nunca debe depender de que el ERP responda para poder mostrar una página.
Qué preguntar al proveedor de tu ERP
Antes de pedir cotizaciones de desarrollo, lleva estas preguntas a quien te vende o te da soporte del sistema, sea un ERP internacional como SAP Business One, Microsoft Dynamics u Odoo, un sistema administrativo de uso común en México como CONTPAQi o Aspel, o un desarrollo propio:
- ¿La versión que tenemos instalada incluye API o servicios web? ¿Hay documentación y un ambiente de pruebas?
- ¿Usar la API tiene costo de licencia, por usuario o por volumen de peticiones?
- ¿Qué operaciones permite: solo consulta, o también crear pedidos, clientes y pagos?
- ¿Qué límites de peticiones tiene y cómo avisa cuando se rebasan?
- ¿Qué cambia en la integración cuando actualicemos de versión?
- ¿Quién timbra las facturas, el ERP o un sistema aparte, y se puede consultar el XML y el PDF desde fuera?
- ¿Leer o escribir directo en la base de datos afecta el contrato de soporte?
Las respuestas definen el alcance real. Un proveedor de desarrollo serio te las pedirá antes de dar una cifra; si alguien cotiza una integración sin haberlas hecho, está cotizando a ciegas.
Facturación CFDI desde el sitio
El timbrado lo hace un proveedor autorizado de certificación (PAC), normalmente a través de tu ERP o de tu sistema de facturación. Lo sensato es que el sitio no timbre por su cuenta: solicita la factura al sistema que ya lleva tus folios y series, y muestra el resultado. Así no terminas con dos series ni con facturas que contabilidad no conoce.
Si ofreces autofacturación, el formulario debe pedir RFC, nombre o razón social, régimen fiscal, código postal del domicilio fiscal y uso del CFDI, tal como aparecen en la constancia de situación fiscal del cliente. Con CFDI 4.0 una diferencia en esos datos hace que el timbrado se rechace, así que conviene validar el formato antes de enviar y mostrar el motivo del rechazo en lenguaje claro. Define también el plazo para facturar y qué pasa con las ventas que ya entraron a la factura global.
Errores típicos
- Doble captura disfrazada. El pedido llega por correo y alguien lo teclea en el ERP. Se ve como integración, pero conserva el retraso y los errores de dedo.
- Sincronización sin manejo de fallos. Si el ERP no responde y el pedido se pierde sin aviso, lo descubres cuando el cliente reclama. Hacen falta cola, reintentos, alertas y una pantalla donde alguien vea qué quedó pendiente.
- Pedidos duplicados. Un reintento mal hecho crea el mismo pedido dos veces. Cada operación debe llevar un identificador único que el ERP reconozca.
- Catálogos sin limpiar. Claves duplicadas, unidades inconsistentes y productos sin descripción se vuelven visibles para tus clientes el día del lanzamiento.
- Sin responsable. Cuando falla, sistemas dice que es el sitio y el proveedor dice que es el ERP. Define desde el contrato quién vigila la integración.
Cómo se planea la integración por etapas
- Diagnóstico. Mapa de datos: qué campo del ERP corresponde a qué campo del sitio, quién es la fuente de verdad y con qué frecuencia se necesita.
- Solo lectura. Catálogo, existencias y precios por cliente visibles en el portal. Riesgo bajo, porque nada se escribe en el ERP.
- Pedidos. Se escribe en el ERP, primero con un grupo pequeño de clientes y con revisión manual antes de surtir.
- Autoservicio. Estados de cuenta y descarga de facturas, que es donde cobranza recupera más tiempo.
- Pagos y facturación en línea, si el volumen lo justifica.
- Operación. Monitoreo, bitácora y una póliza de mantenimiento que cubra los cambios de versión del ERP.
Cada etapa debe poder usarse por sí sola. Si el proyecto solo sirve cuando está completo, cualquier retraso lo pone en riesgo entero. Y si tu sistema actual no tiene forma razonable de conectarse, a veces la conversación correcta es otra: un módulo o un sistema a la medida que cubra justo el proceso que el ERP no resuelve.
En ZPartner trabajamos integraciones por API con ERP y CRM, portales de clientes y tiendas en línea conectadas al sistema administrativo. Empezamos con una consultoría para entender tu operación y lo que tu ERP permite, y desarrollamos por etapas con entregas frecuentes.