Guía técnica
El web service del RNDC: cómo es la integración por dentro
Si en tu empresa evalúan conectarse al RNDC por API, esta guía explica cómo funciona el web service del Ministerio: el protocolo SOAP, el procesoid de cada documento y las reglas que más rompen una integración. En español claro, sin rodeos.
¿Qué es el web service del RNDC?
El RNDC (Registro Nacional de Despachos de Carga) es el sistema del Ministerio de Transporte donde las empresas reportan cada viaje de carga en Colombia. Se puede usar a mano desde el portal, pero también ofrece un web service: una puerta de entrada por la que tu sistema le habla al RNDC de máquina a máquina, sin que nadie copie datos en una pantalla.
Para un jefe de TI o un desarrollador, esto es lo importante: el RNDC no es una API REST moderna con JSON. Es un servicio SOAP, un estilo de integración más antiguo que viaja en mensajes XML sobre HTTP. Eso significa que armar bien el XML, respetar el orden de las etiquetas y enviar cada campo en el formato exacto es la mitad del trabajo. La otra mitad es mantener todo eso cuando el Ministerio cambia algo.
En esta guía recorremos cómo está construido ese web service, qué documentos se envían por él y cuáles son las reglas concretas que hacen que un reporte sea aceptado o rechazado. Son detalles confirmados en producción, no teoría.
El protocolo
Cómo funciona: SOAP y procesoid
Un solo endpoint, una sola operación y un número que decide qué documento estás enviando.
Toda la integración pasa por un único punto. El web service vive en plc.mintransporte.gov.co:8080/soap/IBPMServices, la operación que se invoca es AtenderMensajeRNDC y el encabezado SOAPAction debe ser urn:BPMServicesIntf-IBPMServices#AtenderMensajeRNDC. No hay una operación distinta por documento: todo entra por la misma puerta.
¿Y cómo sabe el RNDC si le mandas una remesa, un manifiesto o una consulta? Por el procesoid. Es un número que viaja dentro del mensaje e identifica el tipo de documento. Cambias el procesoid y el contenido del XML, y el mismo web service atiende cosas muy distintas. Estos son los procesoid que vas a usar:
procesoid 3 — Remesa intermunicipal
La remesa de un viaje entre municipios. Es el documento más grande: 44 campos, todos obligatorios aunque vayan vacíos.
procesoid 83 — Remesa urbana
La remesa de carga que se mueve dentro de una misma ciudad. Tiene un formato propio, más corto que la intermunicipal.
procesoid 4 — Manifiesto de carga
El documento del viaje completo: vehículo, conductor, flete y las remesas que ampara. Se asocia a una o varias remesas.
procesoid 32 — Anulación de manifiesto
El mensaje para anular un manifiesto ya reportado, indicando el motivo de la anulación.
procesoid 26 — Consulta SICETAC
La consulta del flete mínimo legal de una ruta. La usas para validar que el manifiesto no quede por debajo del mínimo.
Hay un detalle más que decide si estás escribiendo o leyendo: el atributo tipo. Para reportar (crear) un documento envías con tipo=1. Para consultar o leer lo que ya existe usas tipo=3. Es fácil pasarlo por alto, y confundirlos genera respuestas que parecen errores cuando en realidad estás pidiendo la operación equivocada.
Lo que se rompe
Las reglas que más rompen una integración
Cuatro detalles pequeños que el RNDC rechaza sin piedad. Cada uno te puede costar días si lo descubres en producción.
1. Las fechas van en dd/MM/yyyy
El RNDC solo acepta fechas con el orden día, mes y año, separadas por barras: 10/03/2026. Parece obvio, pero es la causa número uno de rechazo porque la mayoría de los sistemas guardan las fechas en otro formato. Probado en producción: 2026-03-10 (yyyy-MM-dd) es rechazado y 2026/03/10 (yyyy/MM/dd) también es rechazado. Convierte siempre a dd/MM/yyyy justo antes de enviar.
2. variables es hermana de solicitud, no va dentro
Dentro del mensaje conviven dos etiquetas: <solicitud> y <variables>. El error clásico es anidar la segunda dentro de la primera. No: las dos son hermanas, hijas del mismo nodo padre, una al lado de la otra. En forma compacta, la estructura correcta se parece a <root><solicitud>…</solicitud><variables>…</variables></root>, y nunca a <solicitud><variables>…</variables></solicitud>. Si las anidas, el RNDC no procesa el mensaje y el error que devuelve no siempre lo dice con claridad.
3. La remesa intermunicipal tiene 44 campos, todos obligatorios
La remesa de procesoid 3 lleva exactamente 44 campos, y todos son obligatorios aunque vayan vacíos. Es decir: no basta con enviar los que tienen valor; las 44 etiquetas deben estar presentes en el XML. Si omites una porque no aplica a tu caso, el mensaje queda incompleto. La forma segura de manejarlo es tener una plantilla con las 44 etiquetas siempre, y llenar solo las que correspondan.
4. El código de mercancía va a 4 dígitos
El campo MERCANCIAREMESA espera el código armonizado (partida arancelaria) a 4 dígitos, por ejemplo 2523. Si envías el código a 6 dígitos, el RNDC lo rechaza. Es tentador mandar el código completo que tienes en tu base de datos, pero aquí hay que recortarlo a los primeros 4 dígitos. Tampoco acepta texto libre en ese campo.
Estas cuatro reglas no están solas: cada documento tiene las suyas, y la lista cambia entre remesa, remesa urbana, manifiesto y anulación. Por eso una integración propia no es «un endpoint y listo»: es un conjunto de validaciones que hay que escribir, probar y mantener para cada procesoid.
La decisión
¿Construir tu propia integración o usar Fassiltrans?
Una respuesta honesta: se puede construir. La pregunta real es cuánto de tu equipo quieres dedicar a mantenerla.
Conectarse al web service del RNDC es totalmente posible para un equipo de desarrollo. Pero conviene tener claro lo que implica: armar y mantener un cliente SOAP, replicar las reglas de cada documento (fechas, 44 campos, código a 4 dígitos, orden de etiquetas), cubrir los cinco procesoid, manejar las respuestas y los errores del Ministerio, y después sostener todo eso en el tiempo. Y encima viene la migración al RNDC2, la nueva plataforma anunciada por el Ministerio, que tarde o temprano va a obligar a adaptar la integración.
| Tu propia integración | Con Fassiltrans | |
|---|---|---|
| Conexión SOAP | Armas y mantienes el cliente SOAP, la autenticación y el manejo de la respuesta del Ministerio. | La conexión al web service ya está hecha y probada en producción. |
| Reglas de formato | Controlas a mano las fechas dd/MM/yyyy, los 44 campos y el código de mercancía a 4 dígitos. | El sistema valida cada campo antes de enviar y te avisa si algo está mal. |
| procesoid y documentos | Implementas remesa, remesa urbana, manifiesto, anulación y SICETAC uno por uno. | Los cinco procesoid ya están cubiertos y mantenidos. |
| Migración al RNDC2 | Tendrás que volver a desarrollar cuando entre la nueva plataforma del Ministerio. | Nosotros asumimos la migración; tu operación sigue igual. |
| Mantenimiento | Cada cambio del Ministerio se vuelve trabajo de tu equipo de TI. | Las actualizaciones del RNDC corren por nuestra cuenta. |
Esa es la propuesta de un software RNDC como Fassiltrans: el web service, las reglas y los procesoid ya están resueltos y probados en producción, y la migración al RNDC2 corre por nuestra cuenta. Tu equipo de TI se enfoca en tu operación, no en perseguir cada cambio de formato del Ministerio. Si prefieres construir, esta guía te deja claro el terreno; si prefieres no hacerlo, ya está hecho.
Preguntas frecuentes
- El RNDC expone un servicio SOAP en plc.mintransporte.gov.co:8080/soap/IBPMServices. La operación es AtenderMensajeRNDC y el SOAPAction es urn:BPMServicesIntf-IBPMServices#AtenderMensajeRNDC. Por ahí viajan todos los documentos: remesas, manifiestos, anulaciones y consultas.
Salta la integración y empieza a reportar al RNDC
En lugar de construir y mantener el web service, crea tu cuenta y envía remesas y manifiestos validados desde el primer día.
Probar gratis