Integrar Carta Porte con un TMS y un ERP consiste en conectar los datos del viaje con el proceso de generación del comprobante. El trabajo empieza antes del XML: mercancías identificadas, ubicaciones coherentes, información del transporte y responsables capaces de corregir lo que falta. Automatizar un formulario incompleto solo acelera el problema.
El portal del SAT sobre Carta Porte explica que el complemento relaciona mercancías, ubicaciones y medios de transporte. La aplicación concreta depende del tipo de operación. Este artículo propone un diseño de software; la determinación fiscal y las excepciones deben quedar a cargo del responsable competente con la normativa vigente.
Una mañana en el área de despacho
Imaginemos un distribuidor ficticio. Ventas registra un pedido, almacén confirma parte de la mercancía y transporte asigna una unidad. Antes de salir, cambia el punto de entrega. La persona que prepara el comprobante recibe tres mensajes y una hoja de cálculo con información que ya no coincide.
El problema no se resuelve obligándola a escribir más rápido. Hace falta una representación compartida del viaje, con referencias a los pedidos y a la carga confirmada. Cada cambio debe tener un origen, una versión y una persona que determine su efecto sobre los documentos.
El TMS puede ser responsable del viaje, el ERP del cliente y almacén de la carga efectiva. Una integración bien delimitada conserva esas responsabilidades y evita crear una cuarta copia que nadie reconoce como fiable.
Construye el expediente del viaje
Define un identificador interno estable que permita reunir los datos operativos y los comprobantes relacionados. No lo confundas con el identificador fiscal del documento. Un viaje puede necesitar seguimiento operativo antes de que exista un comprobante emitido.
El expediente puede incluir:
- ▸Pedidos y referencias de mercancía que justifican la carga.
- ▸Ubicaciones revisadas y responsable de cada dato.
- ▸Unidad y personal asignados según el proceso aplicable.
- ▸Versión de la información enviada para generar el documento.
- ▸Referencias y respuestas del proveedor de timbrado.
- ▸Cambios posteriores, decisiones y vínculos con los documentos afectados.
Esta lista es una propuesta funcional, no un catálogo de campos fiscales obligatorios. El esquema concreto y las reglas deben obtenerse de las fuentes oficiales y del proveedor autorizado que participe en la emisión.
Valida cerca de quien puede corregir
Si falta un dato de mercancía, conviene que el problema llegue al responsable del catálogo o del almacén. Si falta información del transporte, debe llegar a quien organiza el viaje. Una bandeja única con mensajes técnicos no ayuda cuando todos los errores terminan en la misma persona.
Separa errores de formato, información ausente e inconsistencias de negocio. Un valor puede tener una estructura válida y pertenecer al cliente equivocado. Presenta el dato de origen, la razón del bloqueo y el lugar donde debe corregirse.
Evita corregir únicamente la copia preparada para el documento. Cuando corresponda, la solución debe volver al sistema propietario del dato. De lo contrario, el siguiente viaje repetirá exactamente la misma incidencia.
Versiones fiscales y versiones operativas
El SAT publica preguntas frecuentes para autotransporte y un repositorio de normativa de 2026. Parte de la documentación explicativa conserva referencias a ejercicios anteriores. Antes de codificar una excepción, comprueba su vigencia y alcance con el responsable fiscal.
En el software, registra qué versión del esquema, catálogo y reglas se utilizó. No actualices silenciosamente una validación en producción sin probar los casos que puede afectar. Mantén ejemplos representativos y una persona responsable de aprobar el cambio.
Por separado, conserva las versiones del viaje. Una modificación de destino, carga o unidad no debería borrar los datos con los que se emitió un documento anterior. El sistema necesita explicar ambos momentos sin presentar uno como si siempre hubiera sido el otro.
El timbrado no describe todo el transporte
Una respuesta favorable del servicio de emisión no demuestra por sí sola que la mercancía fue recogida, llegó completa o se entregó en el lugar esperado. Mantén esos eventos operativos separados y relacionados con la documentación correspondiente.
Si una solicitud queda sin respuesta, muestra un estado de revisión y consulta el mecanismo de recuperación del proveedor antes de repetirla. Define cómo se reconocen solicitudes ya procesadas y quién investiga una discrepancia entre el TMS y el servicio de emisión.
La pantalla de despacho debe explicar qué falta para la siguiente acción. Evita un botón de reintento que permita generar nuevas solicitudes sin que el usuario conozca el resultado de las anteriores.
Una primera entrega que pueda probarse
Empieza con un tipo de operación, una entidad y un flujo de transporte bien descrito. Incluye una carga normal, mercancía pendiente, cambio de destino, corrección de catálogo y respuesta incierta del proveedor. Los usuarios deben poder reconstruir cada caso desde el pedido hasta sus documentos.
Compara un módulo existente del TMS con el desarrollo necesario para cubrir los huecos reales. Nuestro artículo sobre validar un proyecto antes de programar ayuda a convertir esos huecos en decisiones concretas.
TuniCyberLabs puede ayudarte con el desarrollo de software a medida para conectar sistemas y mejorar el tratamiento de excepciones. Cuéntanos qué ERP, TMS y proveedor de emisión utilizas, y dónde se interrumpe el flujo para plantear una integración revisable con tus responsables operativos y fiscales.