Cómo conectar tu ERP con el RNDC

Tu ERP ya guarda casi todo lo que el RNDC (Registro Nacional de Despachos de Carga) necesita: el número del pedido, el cliente con su NIT, la mercancía que se mueve, el peso y el origen y el destino del viaje. Cuando un transportador o un generador de carga crea un despacho en SAP, Oracle, Dynamics o un ERP propio, esos datos ya quedan registrados en alguna tabla del sistema.

El problema no es que falte información, sino que el RNDC exige ese mismo dato con otro nombre, otro formato o en otra unidad. El pedido de tu ERP tiene que convertirse en una remesa y, cuando corresponda, en un manifiesto, con sus campos exactos. Conectar el ERP con el RNDC es, en el fondo, un trabajo de traducción: tomar lo que ya existe en tu sistema y entregarlo en el formato que el Ministerio entiende, de forma automática y sin que nadie lo vuelva a escribir a mano.

Esa automatización tiene un beneficio directo: menos errores de digitación. Cuando una persona copia el peso, el NIT o la ciudad de destino desde el ERP hacia el portal del RNDC, siempre hay riesgo de equivocarse. Si el dato sale del ERP tal como está, el único trabajo que queda es traducirlo bien una vez, al construir la integración.

Antes de programar nada, conviene sentar el mapeo campo por campo: de dónde sale cada dato en el ERP y cómo debe llegar al RNDC. Esta tabla muestra un ejemplo simplificado de los cruces más comunes.

• Fechas en otro formato. El ERP suele guardar la fecha como yyyy-MM-dd. El RNDC solo acepta dd/MM/yyyy; si no la conviertes antes de enviar, rechaza el documento.
• Código de mercancía a 6 dígitos. El ERP a veces maneja el código arancelario completo. El RNDC espera solo los primeros 4 dígitos; hay que recortarlo antes de mapearlo.
• Municipio por nombre. El ERP guarda «Bogotá» o «Medellín». El RNDC pide el código DANE del municipio, no el nombre de la ciudad.
• Terceros que no existen en el RNDC. Un cliente o proveedor puede estar en el ERP pero no estar registrado como tercero en el RNDC, y el documento se rechaza por ese dato.

La mayoría de estos errores se detectan antes de que lleguen al RNDC si la integración hace una validación previa. La API RNDC de Fassiltrans revisa el formato de cada campo y devuelve el error por campo, en lugar de un código genérico que hay que interpretar.

Lo importante es dónde se detecta el error. Si solo se descubre cuando el RNDC lo rechaza, el pedido ya se procesó en el ERP y alguien tiene que volver atrás a corregirlo. Validar antes de enviar evita ese retroceso y deja el dato correcto desde el origen.

1. Las credenciales del RNDC de la empresa.
2. El mapeo de los campos del ERP a los campos del RNDC.
3. El catálogo de terceros ya registrados en el RNDC.
4. Los códigos DANE de los municipios que usa la operación.
5. Un ambiente de pruebas para no reportar documentos reales mientras desarrolla.
6. Un responsable que revise y resuelva los errores de validación.

Con la API RNDC de Fassiltrans, el sandbox y una skill para agentes de código como Claude Code, Codex o Cursor vienen incluidos con el acceso, así que tu equipo puede probar el mapeo y escribir la integración sin exponer datos reales desde el primer día.