Qué exigirle a un proveedor de integración con el RNDC

Cuando tu empresa reporta remesas y manifiestos al RNDC, puede hacerlo directo por el portal, por el web service SOAP del Ministerio, o apoyada en un proveedor que le ofrece una API, una app o un programa para reportar más rápido. En cualquiera de los tres caminos, el documento queda registrado con el NIT y las credenciales de tu empresa. El proveedor es quien construye y mantiene el software; tu empresa sigue siendo la responsable del reporte.

Esta figura es distinta de una Empresa de Monitoreo de Flota (EMF), que sí es una figura que tu empresa autoriza ante el RNDC para reportar en su nombre la ubicación del vehículo y las horas reales de cargue y descargue. Aquí usamos «proveedor tecnológico» en el sentido de empresa de software, no de una habilitación oficial: no se registra ante el Ministerio con ese rol, sino que te entrega el software para que tu propia empresa reporte sus remesas y manifiestos con sus propias credenciales. Verifica siempre con el Ministerio cualquier requisito vigente. Puedes necesitar las dos cosas a la vez: una EMF para los tiempos del viaje y un proveedor de integración para los documentos del viaje.

Esta distinción importa porque cambia quién responde si un dato queda mal en el RNDC. Si el proveedor es solo un software de integración, un error en el reporte sigue siendo un asunto entre tu empresa y el Ministerio: el proveedor te ayudó a construir y enviar el mensaje, pero el documento, el NIT y las credenciales detrás del envío son los de tu empresa.

Por eso esta lista no habla de autorizaciones ni de habilitaciones del Ministerio. Habla de qué debe mostrarte un proveedor de software antes de que le conectes tu ERP o tu TMS.

Esta lista no es un formulario para marcar con un cheque. Cada punto debe verse funcionando en una pantalla real, no solo describirse en una ficha comercial. Al conversar con el proveedor, agrúpalos en los mismos tres frentes: pruebas sin riesgo (puntos 1 a 3), confiabilidad del día a día (puntos 4 a 6) y protección de tus datos y credenciales (puntos 7 a 10).

1. Ambiente de pruebas. Debes poder probar la integración completa — remesas, manifiestos, errores— sin que nada llegue como documento real al RNDC.
2. Validación previa con errores por campo. Antes de enviar al Ministerio, el proveedor debe revisar los datos y decirte qué campo falló y por qué, no solo un código genérico.
3. Resultado por documento en envíos masivos. Si subes un lote de manifiestos o remesas, necesitas saber cuáles pasaron y cuáles no, uno por uno, no solo un total de éxitos y fallos.
4. Webhooks. El proveedor debe avisarle a tu sistema cuando el RNDC acepta, rechaza o cambia el estado de un documento, en lugar de obligarte a consultar una y otra vez.
5. Registro de auditoría consultable. Debes poder ver, para cada documento, quién lo envió, cuándo y qué respondió el RNDC, y consultarlo cuando lo necesites, no solo pedirlo por ticket.
6. Qué pasa cuando el RNDC no responde. El Ministerio puede estar lento o caído. El proveedor debe explicarte cómo reintenta, cómo evita duplicar un documento y qué le muestra a tu equipo mientras tanto.
7. Custodia cifrada de credenciales RNDC. Tu usuario y contraseña del RNDC deben guardarse cifrados, nunca aparecer en pantallas, respuestas de la API ni registros de soporte, y debes poder cambiarlos cuando quieras.
8. Documentación técnica y soporte con nombre. Necesitas una referencia técnica clara de cada endpoint o pantalla, y una persona o equipo identificable que responda cuando algo falla, no solo un formulario de contacto.
9. Plan ante cambios del Ministerio (RNDC2). El RNDC ya pasó a una nueva plataforma. Pregunta cómo se adaptó el proveedor a esa migración al RNDC2 y qué pasa la próxima vez que el Ministerio cambie algo.
10. Salida sin ataduras: exportar tus datos. Si decides irte, debes poder sacar tus remesas, manifiestos y terceros en un formato que puedas reutilizar, sin depender de que el proveedor te lo entregue como favor.

Lleva estas seis preguntas escritas a la llamada y pide que te las respondan mostrando la pantalla, no solo describiéndolas de palabra. Si una respuesta no se puede demostrar ahí mismo, anótala y vuelve a preguntar antes de avanzar a la siguiente etapa.

1. ¿Puedo ver ahora mismo un envío de prueba en el sandbox, de principio a fin?
2. Si envío un dato mal, ¿qué mensaje de error me muestra la plataforma, exactamente?
3. ¿Me pueden mostrar el registro de auditoría de un documento real, con fecha y usuario?
4. ¿Dónde y cómo quedan guardadas mis credenciales del RNDC?
5. Si el RNDC no responde o cambia de plataforma, ¿qué pasa con mis envíos pendientes?
6. Si decido cambiar de proveedor, ¿cómo saco mis remesas, manifiestos y terceros?

Ninguna de estas señales es, por sí sola, una prueba definitiva. Pero si se repiten, vale la pena preguntar más antes de conectar tu sistema en producción.

• No hay ambiente de pruebas, o te piden conectar directo a producción "para ver cómo funciona". Probar así implica reportar documentos reales al RNDC desde el primer intento, sin poder deshacerlos si algo sale mal.
• Los errores llegan como un código corto sin explicación, y nadie te sabe decir qué campo falló. Tu equipo termina adivinando qué corregir en cada reenvío, en lugar de leer un mensaje claro.
• Te piden tu usuario y contraseña del RNDC por correo, chat o un formulario sin cifrado. Esas credenciales quedan expuestas apenas las envías, y recuperar el control después es más difícil que negarte desde el principio.
• No hay una forma clara de exportar tus remesas, manifiestos o terceros si decides irte. Te enteras de esa limitación justo cuando más la necesitas: al momento de cambiar de proveedor.

Cualquiera de estas situaciones es una razón para seguir preguntando antes de firmar, no para resignarte a que "así funciona siempre".

Fassiltrans ofrece una API RNDC para empresas de transporte con llaves por empresa, un ambiente de pruebas, validación previa con errores por campo, resultado por documento en envíos masivos, webhooks y un registro de auditoría. Las credenciales del RNDC de cada empresa se guardan cifradas y nunca viajan por correo ni por chat. Si quieres comparar esta API con el web service SOAP directo del Ministerio, puedes leer la comparación entre la API REST y el SOAP del RNDC.

Fassiltrans también entrega una skill para agentes de código como Claude Code, Codex o Cursor: trae los esquemas de remesas y manifiestos y los errores más comunes de la API, y ayuda a tu equipo a escribir y probar la integración contra el sandbox. El asistente propone y prueba código; tu desarrollador sigue siendo quien revisa y aprueba lo que se conecta a producción, y nunca tiene las credenciales del RNDC.

Ninguno de estos puntos se queda en una afirmación. Pide una llamada técnica: revisamos contigo cada criterio de esta lista y los pasos para darte acceso al sandbox.