Para diseñar flujos API entre tu ERP y tus canales de venta tenés que definir, para cada flujo, qué evento lo dispara, qué sistema envía y cuál recibe, qué datos se transforman en el camino, cómo se autentica la conexión, qué pasa cuando falla y cómo se verifica que nada se perdió. Un flujo API bien diseñado deja rastro de cada dato que entra y sale. Esa trazabilidad es la diferencia práctica entre una integración que se puede auditar y una que solo se revisa cuando aparece un problema.
En una operación multicanal, los flujos se multiplican rápido: pedidos que bajan de cinco marketplaces, stock que sube del ERP, precios que cambian por canal y estados de envío que vuelven al cliente. Cada flujo sin diseño previo se convierte en un punto ciego de la operación. En esta guía vas a ver cómo diagramar los flujos, qué decisiones tomar sobre autenticación y reintentos, cómo registrar errores y conciliar eventos, y qué cubre una integración nativa frente a un desarrollo adicional.
Cómo diagramar origen, destino y transformación en los flujos API entre sistemas
Antes de escribir una línea de código o activar un conector, conviene dibujar cada flujo en una hoja. El diagrama tiene que responder cinco preguntas: qué evento lo inicia, qué sistema es origen, cuál es destino, qué datos viajan y qué transformación sufren. Diagramar cada flujo antes de integrar evita descubrir los problemas en producción. La tabla siguiente muestra los flujos más comunes en una operación con ERP, hub y marketplaces.
| Flujo | Origen y destino | Evento disparador | Transformación típica |
|---|---|---|---|
| Pedidos | Marketplace, hub y ERP | Venta confirmada | Mapeo de SKU, cliente e impuestos |
| Stock | ERP, hub y canales | Ingreso, venta o ajuste | Reserva por canal y depósito |
| Precios | ERP, hub y canales | Cambio de lista | Reglas de precio por canal |
| Estados y seguimiento | Paquetera, hub y canal | Despacho o entrega | Equivalencia de estados entre sistemas |
| Facturas | Hub y ERP | Pedido pagado | Datos fiscales y numeración |
Los flujos de la tabla son una referencia general y cada operación puede sumar otros, como devoluciones o pagos. Lo importante es que cada flujo tenga un dueño y un recorrido documentado. Con ese mapa, cualquier persona del equipo puede entender por dónde pasa un dato y dónde buscar cuando algo falla.
La transformación es la parte que más errores genera. Un marketplace llama “enviado” a lo que tu ERP llama “despachado”, un canal usa unidades y otro packs, y los códigos de producto no siempre coinciden. Las tablas de equivalencia son tan importantes como la conexión técnica. Documentá cada mapeo: estados, códigos de producto, alícuotas de impuestos, medios de pago y transportistas.
Un hub de integración reduce la cantidad de flujos que tenés que construir. En lugar de conectar el ERP con cada marketplace por separado, conectás todo al hub y el hub resuelve la comunicación con cada canal. Un hub central reemplaza muchas conexiones punto a punto por una sola. Con las integraciones de Base podés conectar marketplaces, tiendas online, paqueteras y ERP desde un mismo punto.
Qué decisiones tomar sobre autenticación, sincronización y reintentos
Con los flujos dibujados, el siguiente paso es decidir cómo se conectan los sistemas y qué pasa cuando algo no responde. Las decisiones de conexión definen cuán estable va a ser la integración. Son tres los temas que conviene resolver antes de implementar:
- Autenticación: usá credenciales dedicadas para la integración, separadas de las cuentas de los usuarios. Dales solo los permisos que necesitan y definí un procedimiento para renovar contraseñas o tokens sin cortar el servicio.
- Modo de sincronización: los eventos en tiempo real sirven para pedidos y stock, donde la demora cuesta ventas. La consulta periódica alcanza para datos que cambian poco, y los procesos por lote funcionan para cargas masivas fuera del horario pico.
- Reintentos: si un sistema no responde, el flujo tiene que reintentar con esperas crecientes y un número máximo de intentos. Si después de esos intentos sigue fallando, el mensaje pasa a una cola de errores para revisión manual.
Los límites de uso de las APIs merecen atención aparte. Los marketplaces y los ERP limitan la cantidad de llamadas por minuto, y un flujo que funciona en un día normal puede bloquearse en un pico como Black Friday. Diseñar para el pico de demanda evita bloqueos en los días de más ventas. Agrupá operaciones cuando sea posible y priorizá los flujos críticos, como pedidos y stock, sobre los descriptivos.
Cómo registrar errores, idempotencia y conciliación de eventos
Toda integración falla en algún momento: un sistema se cae, un dato llega incompleto o una respuesta se pierde. Lo que diferencia a una integración confiable es que el error queda registrado y se puede resolver sin perder información. Registrar cada mensaje con su resultado permite reconstruir cualquier incidente. Un registro mínimo incluye identificador del mensaje, fecha y hora, sistema origen, datos enviados, respuesta recibida y estado final.
La idempotencia es el concepto que evita el problema más caro de una integración: los duplicados. Un flujo es idempotente cuando procesar dos veces el mismo mensaje produce el mismo resultado que procesarlo una sola vez. Sin idempotencia, cada reintento puede crear un pedido o una factura duplicada. La forma práctica de lograrlo es usar el identificador del pedido en el canal como clave: si el ERP ya tiene un pedido con ese identificador, el reintento no crea otro.
La conciliación completa el circuito. Aunque los registros muestren que todo salió bien, conviene comparar periódicamente los datos de ambos extremos. La conciliación detecta los errores que el registro no llegó a capturar. Estos son los controles más útiles:
- Pedidos por canal: la cantidad de pedidos del día en cada marketplace tiene que coincidir con la registrada en el hub y en el ERP.
- Stock por SKU: las diferencias entre el stock del ERP y el publicado en cada canal muestran flujos demorados o fallidos.
- Facturas por pedido: cada pedido pagado tiene que tener su factura. Los pedidos sin factura indican un flujo interrumpido.
- Estados pendientes: los pedidos que llevan más tiempo del esperado en un mismo estado señalan eventos que no se actualizaron.
Centralizar los pedidos en un mismo panel hace que la conciliación sea mucho más simple. Con el administrador de pedidos de Base tenés los pedidos de todos los canales con su estado e historial en una sola vista. Un panel único de pedidos reduce la conciliación a comparar dos sistemas. Además, podés configurar acciones automáticas en Base para marcar o notificar los pedidos que quedan detenidos en un estado.
Qué flujos admite la integración de SAP Business One y cuáles requieren desarrollo adicional
Un caso real ayuda a ver dónde termina una integración nativa y dónde empieza el desarrollo adicional. La integración de Base con SAP Business One se conecta a través del SAP Service Layer, con usuario y contraseña de SAP, y Base mantiene la sesión activa en segundo plano. Conocer el alcance documentado evita prometer flujos que la integración no cubre. Según la información publicada, estos son los flujos nativos:
- De SAP a Base: productos con stock, precios, grupo impositivo, peso, dimensiones e imágenes opcionales; stock desde el depósito de SAP elegido; y precios desde la lista de precios seleccionada.
- De Base a SAP: pedidos como órdenes de venta, facturas en forma automática o manual con anulaciones reflejadas, y clientes identificados por código, identificación fiscal o email.
- Facturas en PDF: las facturas generadas en SAP pueden usarse en Base para imprimir o enviar, con una conexión adicional a través del API Gateway de SAP.
La misma documentación marca los flujos que no están disponibles en forma nativa. Los flujos fuera del alcance nativo necesitan un desarrollo o un conector adicional. Entre ellos están la descarga de pedidos desde SAP hacia Base, el envío de productos o stock desde Base hacia SAP, los recibos, correcciones y facturas proforma, y el número de seguimiento como dato estructurado, que solo aparece en comentarios del pedido o la factura. También cada conexión trabaja con una sola base de datos de empresa.
Si tu operación gestiona el depósito en SAP, existe otra alternativa. La integración de Base con SAP WMS se implementa en forma dedicada con especialistas de Base y conecta inventario, productos, pedidos y estados de preparación. Las implementaciones dedicadas cubren escenarios que exceden un conector estándar. El alcance exacto de cada proyecto conviene validarlo con el equipo de Base antes de diseñar los flujos.
Diseñar flujos API es, en el fondo, una tarea de orden operativo antes que técnico. Las empresas que diagraman sus flujos, definen reglas de error y conocen el alcance de cada conector integran más rápido y con menos sorpresas. Una integración se diseña en papel antes de construirse en sistemas.
Conectá tu ERP y tus canales con trazabilidad completa
Si hoy tus pedidos, stock y facturas viajan entre sistemas con cargas manuales o conexiones punto a punto, cada canal nuevo agrega complejidad. En Base funcionamos como hub de integración entre tu ERP, marketplaces, tiendas online y paqueteras, con pedidos centralizados y estados visibles en un mismo panel. Cada dato tiene un recorrido claro y cada pedido queda registrado. Así podés sumar canales sin perder trazabilidad.
Integrá tu ERP con tus canales. Centralizá pedidos, stock y facturación en un hub. → Conocé el plan Business de Base
