Cómo reportar remesas y manifiestos al RNDC de forma masiva

El portal del RNDC (Registro Nacional de Despachos de Carga) está pensado para digitar un documento a la vez. Funciona bien cuando una operación reporta pocos viajes al día. El problema aparece cuando el volumen crece: la misma persona que digita remesas también tiene que digitar manifiestos, anulaciones y cumplidos, y cada documento toma minutos.

Hay señales claras de que ya se llegó a ese punto. Una o varias personas dedicadas solo a digitar en el portal. Rechazos frecuentes por errores de tipeo, porque copiar a mano un NIT, un código de mercancía o una fecha siempre tiene riesgo de equivocarse. Retrasos en el cumplido porque la cola de documentos por digitar no baja al ritmo de los despachos reales.

Cuando varias sedes reportan al mismo tiempo, o cuando el sistema de la empresa (un ERP o un TMS) ya tiene cada remesa y manifiesto completo antes de que nadie los toque, digitar de nuevo en el portal es trabajo repetido que no agrega nada. Ahí es donde conviene mirar las opciones de reporte en volumen: que un sistema le hable directamente al RNDC en lugar de que una persona transcriba lo mismo dos veces.

La forma más conocida es el portal del RNDC: cada remesa, cada manifiesto y cada anulación se digitan en una pantalla web, uno a la vez. Es la opción más simple de usar, pero no escala bien cuando el volumen de documentos crece, porque el tiempo que toma reportar un lote completo depende de cuántas personas estén digitando y de cuánto dure cada una en el turno.

Antes de escribir este artículo revisamos a fondo el Manual de Generadores de Carga y la Guía de Uso del Web Service en el RNDC, buscando específicamente una opción de cargue masivo por archivo. Ninguno de los dos la describe: el primero cubre el módulo de valor del flete y sus consultas, y el segundo documenta un único servicio SOAP que recibe un documento por mensaje. Por eso, para un volumen real de remesas y manifiestos, los caminos que sí están confirmados por los manuales que revisamos son el portal y el web service.

El web service SOAP del RNDC es la puerta de entrada técnica para reportar sin digitar: el sistema propio de la empresa le envía cada documento con su procesoid, campo por campo, en el formato exacto que exige el Ministerio. No es un cargue de archivo: es una integración que un equipo de TI programa, prueba y mantiene en el tiempo, un documento a la vez por cada llamada al servicio. Esa misma puerta es la que usa una API intermedia como la de Fassiltrans para ofrecer lotes de documentos en una sola llamada.

No hay una única respuesta correcta: la opción que conviene depende de cuántos documentos reporta la operación al día, de si esos datos ya existen en un sistema propio y de cuánto tiempo de desarrollo puede dedicar el equipo de TI. Esta tabla compara las tres vías en lo que más importa cuando el volumen crece: quién las usa, cuánto trabajo manual queda y cómo se enteran de un error.

El portal gana en simplicidad cuando el volumen es bajo: no hay nada que programar, cualquier persona capacitada puede usarlo y los errores se ven de inmediato porque cada campo se valida mientras se digita. Pierde justo donde ganan las otras dos opciones: no hay forma de reportar diez o cien documentos más rápido que uno, porque el cuello de botella es la persona, no el sistema.

La integración SOAP propia resuelve el volumen, pero traslada el costo al desarrollo: hay que programar el cliente que arma el XML, interpretar los códigos de respuesta del Ministerio y sostener esa integración cuando cambie una regla. Una API como la de Fassiltrans ofrece el mismo resultado —reportar sin digitar— pero con ese trabajo de desarrollo y mantenimiento ya hecho, y con validación previa y mensajes claros por campo, que el web service SOAP, por sí solo, no entrega.

Enviar un lote grande de remesas y manifiestos no sirve de mucho si, al final, nadie sabe cuáles se reportaron bien y cuáles no. Por eso el punto central del reporte masivo no es el envío en sí, sino el manejo de los errores. Con la API RNDC de Fassiltrans cada documento del lote devuelve su propio resultado: el que pasa sigue su camino al RNDC, y el que tiene un error se detiene con un mensaje por campo.

La validación previa evita que un error de datos (un código de mercancía mal cortado, una fecha en el formato equivocado) llegue siquiera al Ministerio. Es más rápido corregir un dato antes de enviar que esperar el rechazo del RNDC y volver atrás. Cuando un documento sí falla, lo normal es poder reenviar solo ese documento, sin repetir todo el lote.

Los webhooks cierran el ciclo: en vez de que alguien consulte uno por uno si cada documento ya quedó aceptado, el sistema recibe un aviso automático cuando el RNDC responde. Así, el equipo solo revisa lo que de verdad necesita atención: los documentos con error.

Esto es justo lo que una integración SOAP propia tiene que construir desde cero si quiere manejar errores en volumen: el web service del Ministerio responde con un código por mensaje, pero traducir ese código a «qué documento falló y por qué» es trabajo que cae sobre el equipo de TI. Cuando el reporte masivo pasa por una API que ya resuelve eso, la diferencia se nota más en el día a día que en el envío mismo.

1. Llamada técnica. Se revisa el volumen de la operación, el sistema que origina los datos (ERP, TMS o propio) y el alcance de la integración: cuántos tipos de documento hay que cubrir y qué tan automático debe quedar el flujo.
2. Sandbox. El equipo de TI prueba el envío de lotes en un ambiente que no reporta documentos reales al RNDC, para ajustar el mapeo de campos sin riesgo y ver cómo responde la API ante datos incompletos o mal formateados.
3. Piloto con una sede. Se pasa a producción con una sola sede o un subconjunto de la operación, para ver cómo se comporta el reporte masivo con datos reales antes de escalar. Es el momento de confirmar que el volumen y la frecuencia acordados funcionan en la práctica, no solo en pruebas.
4. Toda la operación. Con el piloto validado, se extiende la integración al resto de sedes y al volumen completo de remesas y manifiestos. A partir de ahí, el trabajo del equipo de TI deja de ser reportar documento por documento y pasa a ser vigilar el proceso y corregir las excepciones.

Si tu empresa ya conecta su ERP o TMS siguiendo la guía para conectar un ERP con el RNDC, el reporte masivo es el mismo trabajo a mayor escala: en lugar de un documento por llamada, se envía un lote y se revisa el resultado de cada uno por separado.