Conectar Sage 200 o Business Central con tu transportista: por qué el seguimiento acaba escribiéndose a mano

Cuando el bulto sale, tu ERP registra un hecho documental: el albarán. Ese documento lleva el cliente, la dirección, las líneas servidas y la fecha. Lo que no lleva por sí solo es nada de lo que ocurre después, porque después el control ha pasado a un tercero y tu ERP no tiene forma de enterarse salvo que alguien se lo cuente.

En Business Central sí hay dónde anotarlo. El albarán de venta registrado tiene código de transportista, nivel de servicio y un campo llamado Package Tracking No. Eso resuelve la mitad del problema: hay un sitio. Lo que no resuelve es quién pone el dato ahí, y la respuesta no hay que suponerla: está documentada por Microsoft, y es la siguiente sección.

En Sage 200 España, el recurso de albaranes de la API de ventas ni siquiera tiene el sitio. Se puede comprobar en un minuto y sin credenciales, porque la especificación es pública: en los 132.864 caracteres del documento del recurso SalesDeliveryNotes no aparece ni una vez carrier, ni transport, ni tracking, ni shipping, ni courier, ni delivered. Sí aparecen, y muchas veces, cliente, fecha e identificador — que es la forma de saber que la búsqueda funciona y que el cero es un cero de verdad.

Porque el propio manual lo describe así. El procedimiento que Microsoft publica para seguir un paquete desde Business Central tiene cinco pasos, y los dos del medio son literales: abrir el albarán registrado y elegir la acción de actualizar el documento es el segundo, y el tercero es escribir en el campo Package Tracking No. el número que has recibido del transportista. No hay ninguna llamada de por medio. El número llega por donde llegue —un correo, un portal, el software de etiquetado— y lo teclea una persona.

El quinto paso completa el cuadro: elegir la acción Track Package abre el servicio de seguimiento del transportista. Es un hipervínculo construido con la dirección de internet que configuraste para esa agencia. Funciona, es útil y no es una sincronización: nada de lo que se vea en esa pestaña vuelve a Business Central. Tu ERP te ha llevado a la web de otro y se ha quedado igual de ciego que estaba.

Así que cuando una agencia o un integrador te dicen que «se integra con Business Central», lo que están describiendo no puede ser esa función nativa. Es algo que han construido: una extensión, un conector suyo, o un intermediario que escribe en el ERP por otra vía. No es malo — es la única forma de hacerlo. Lo que hay que saber es que estás comprando software a medida, y el software a medida hay que mantenerlo cuando cambie cualquiera de los dos extremos.

Esta tabla no sale de ninguna comparativa ni de un informe: sale de abrir las dos especificaciones publicadas y contar. Cada fila se puede volver a comprobar con las URL del final, y conviene hacerlo, porque son documentos de terceros que cambian.

La fila que más decide es la última. En una integración, la pregunta «¿puedo llevar este campo de aquí a allá?» parece una pregunta de configuración y no lo es: es una pregunta sobre si existe una superficie donde ese campo quepa. Cuando la respuesta es que hay que publicar una API propia, el campo que falta ha dejado de ser una casilla y ha pasado a ser un proyecto con su código, su despliegue y su mantenimiento.

Porque hay dos productos con ese nombre y el propio Sage los publica por separado. En su portal de desarrollador aparecen como entradas distintas: 200 (UKI), descrito como un ERP de mercado medio de Reino Unido e Irlanda, y 200c (España), con su propia documentación y su propia API. No son versiones del mismo software con otra bandera a efectos de integración: son dos superficies técnicas que no se pueden usar la una por la otra.

La consecuencia es incómoda porque afecta a cómo buscas. Lo que vas a encontrar escrito sobre «la API de Sage 200» —foros, artículos técnicos, listados de conectores— puede ser del producto británico, que lleva más tiempo con documentación pública en inglés. Leerlo y planificar sobre ello es una forma silenciosa de empezar un proyecto con premisas del producto equivocado, y el descubrimiento llega tarde: no cuando se lee, sino cuando alguien intenta llamar a un endpoint que en tu instalación no existe.

Y hay un dato que la API española declara de sí misma y que conviene leer antes de diseñar nada: su cometido es exponer los datos de venta de instalaciones on-premise. Eso no impide conectar nada, pero sí determina dónde tiene que estar quien llama y qué conversación hay que tener con sistemas antes que con el integrador.

Cinco preguntas. Ninguna necesita que sepas programar y todas se contestan en una reunión, que es justo lo que las hace útiles: lo que no se contesta en una reunión no se va a contestar en producción.

1. 1

   Pregunta en qué campo concreto del ERP queda el número de seguimiento, y quién lo escribe

   Si la respuesta es «en un campo personalizado», pregunta qué pasa con ese campo cuando actualicéis el ERP. Si la respuesta es «lo mete una persona», ya tienes la cifra que importa: no es el precio del proyecto, es el minuto por envío multiplicado por tus envíos del año.
2. 2

   Pregunta qué vuelve del transportista, a qué campo y con qué frecuencia

   Estado, incidencia, segundo intento, dirección errónea, rehúse, prueba de entrega. De cada uno: si vuelve, dónde aterriza y cada cuánto. Lo que no tenga destino no vuelve, aunque el transportista lo publique en su portal.
3. 3

   Exige el caso de fallo, no la demo

   Qué ocurre si el alta del envío falla después de que la etiqueta se haya impreso. Quién se entera, en qué pantalla y cuánto tarda. Una demo siempre enseña el camino bueno; el trabajo perdido vive entero en el otro.
4. 4

   Comprueba de qué producto habla la documentación que te están enseñando

   Con Sage 200, cuál de los dos. Con Business Central, si es la API estándar o una API publicada por ellos, porque no cuestan lo mismo de mantener ni se rompen en los mismos momentos.
5. 5

   Acuerda quién mira la cola de lo que no cuadró

   Ésta no es una pregunta técnica y es la que decide si el proyecto sirve. Una conexión mueve datos; no decide si un envío que lleva cuatro días sin escanear merece una llamada. Si nadie tiene esa lista asignada, la conexión funcionará y los casos seguirán descubriéndose por teléfono.

Si al terminar la reunión las cinco tienen respuesta y está escrita, el proyecto es evaluable. Si tres de ellas se responden con «eso lo vemos en la implantación», lo que te están vendiendo es el camino de ida, y el de vuelta lo vas a seguir haciendo tú con un albarán delante y el cliente al teléfono.

Pliuz no es un conector de transportistas y no va a sustituir al software que imprime tus etiquetas. Ese trabajo está resuelto y lo hace bien quien lo hace. Lo que no está resuelto —y es de lo que hablamos— es lo que pasa con el envío cuando el dato de vuelta no llega, llega tarde o llega diciendo algo que nadie estaba esperando.

Hacia dónde va esto, dicho en condicional porque el motor de casos se está construyendo y no sería honesto contarlo en presente: un envío sin escaneo desde hace días, o con una incidencia del transportista, tendría un expediente con objetivo, plazo y responsable, en vez de un aviso que alguien lee y se olvida. Y lo que se hace con él —a partir de cuántos días se llama, qué incidencia se escala y cuál se resuelve sola— lo definirían reglas tuyas, escritas por ti, porque depende del cliente y de la mercancía.

Lo que sí está construido hoy es la parte de la que nadie quiere hablar hasta que toca: el control de qué puede leer y escribir un sistema automático dentro de tu ERP, con límites por operación y registro de lo que hizo. Está explicado, con sus bordes, en qué permisos se le dan a una IA sobre el ERP, y en la página de cómo se conectan el ERP, el almacén y el transporte están las cuatro formas de conexión y lo que deja fuera cada una.