Avisos PLD en XML: los errores de formato más comunes y cómo prevenirlos con validación automática

Los avisos que exige la LFPIORPI se presentan ante el SAT como archivos XML que deben cumplir con el esquema publicado para cada actividad vulnerable. En la práctica, muchos de esos archivos se generan con plantillas de Excel, con exportaciones de otros sistemas o editándolos a mano, y es ahí donde aparecen los problemas. Un aviso puede ser correcto en el fondo y aun así no ser recibido por un detalle de formato, o ser recibido con datos inconsistentes. Tras revisar archivos de avisos reales en nuestros proyectos de cumplimiento, estos son los errores que vemos con más frecuencia y la forma en que los prevenimos.

1. Códigos postales sin el cero inicial

El código postal mexicano tiene siempre cinco dígitos. Los de la Ciudad de México, por ejemplo, empiezan con cero. Cuando un código postal pasa por una hoja de cálculo que lo interpreta como número, el cero inicial desaparece y el archivo termina con cuatro dígitos.

El error es silencioso: en pantalla el dato parece correcto y nadie lo revisa. Además, suele repetirse en todos los domicilios de un mismo aviso, porque se origina en la columna de la plantilla y no en un registro aislado.

Cómo prevenirlo:

• Tratar el código postal como texto en todo el flujo, desde la captura hasta la generación del XML.
• Validar que tenga exactamente cinco dígitos y que exista en el catálogo de códigos postales vigente.
• Revisar que el código postal sea congruente con la entidad federativa y la colonia declaradas.

2. Montos y cantidades con formato inconsistente

El segundo grupo de errores tiene que ver con números. Los más comunes:

• Montos escritos como enteros en un archivo donde el resto de los valores lleva dos decimales.
• Separadores de miles, símbolos de moneda o coma como separador decimal.
• Dígitos perdidos al volver a capturar o convertir un monto, lo que produce un archivo válido en forma pero con una cantidad equivocada.

Este último caso es el más delicado, porque ninguna validación de esquema lo detecta: un número con un cero de menos sigue siendo un número válido.

Cómo prevenirlo:

• Fijar un único formato para todos los montos: punto decimal, dos decimales, sin separadores de miles ni símbolos.
• Generar el XML desde los datos de origen y no desde una copia capturada a mano.
• Conciliar totales: la suma de las operaciones del aviso debe coincidir con la suma registrada en el sistema fuente.

3. Fechas y mes reportado

Cada aviso declara un mes reportado y contiene fechas de las operaciones. Los errores típicos son de dos tipos:

• De formato: fechas con guiones o diagonales, o en orden día-mes-año, cuando el esquema espera una cadena numérica continua en el orden que define.
• De congruencia: un mes reportado que no guarda relación con las fechas de las operaciones incluidas.

No toda diferencia entre el mes reportado y la fecha de una operación es un error; depende de la regla aplicable al tipo de aviso, por ejemplo cuando el umbral se alcanza por acumulación de operaciones en varios meses. Por eso una buena validación no corrige el mes de forma automática: señala la discrepancia y pide confirmarla contra la información de origen.

La validación automática no sustituye el criterio de quien presenta el aviso; lo que hace es asegurar que ese criterio se aplique sobre un archivo sin errores de forma.

4. Claves de catálogo, textos e identificadores

Buena parte del contenido de un aviso se expresa con claves de catálogo: tipo de operación, tipo de alerta, prioridad, país, moneda, entidad federativa, actividad económica, instrumento monetario. Los errores habituales:

• Usar la descripción en lugar de la clave, o una clave de una versión anterior del catálogo.
• Textos con acentos, minúsculas o caracteres que el patrón del campo no admite.
• RFC o CURP con estructura inválida, o incongruentes con la fecha de nacimiento o de constitución declarada.
• Referencias internas duplicadas entre avisos, o conteos declarados que no coinciden con el número real de registros incluidos.

Cómo prevenirlo:

• Consultar los catálogos desde una fuente actualizada y ligada a la versión del esquema, en lugar de copiarlos a cada plantilla. En AmigoApi publicamos los catálogos de LFPIORPI con este propósito.
• Normalizar los textos antes de generar el archivo, de acuerdo con el patrón que exige cada campo.
• Aplicar reglas cruzadas entre campos, como la coherencia entre CURP y fecha de nacimiento.

5. Validar en capas, antes de presentar

La forma más confiable de evitar rechazos es validar el aviso en varias capas y hacerlo antes de generar el archivo definitivo, no después de un intento fallido de carga:

1. Esquema: validar el XML contra el XSD oficial de la versión correspondiente. Esto detecta elementos faltantes, orden incorrecto y tipos de dato inválidos.
2. Patrones: verificar cada campo contra su expresión regular: longitud, caracteres permitidos, estructura de RFC y CURP.
3. Reglas cruzadas: comprobar la coherencia entre campos y contra los catálogos vigentes.
4. Conciliación: comparar totales, conteos y referencias con el sistema de origen.

Cada capa debe reportar el error en términos del dato de negocio, por ejemplo el domicilio de un cliente específico, y no solo con la ruta técnica dentro del XML. Así, quien corrige sabe exactamente qué registro editar. Además, conviene fijar la versión del esquema con la que se generó cada archivo, porque el SAT actualiza formatos y un archivo válido para una versión puede no serlo para la siguiente.

Este es el enfoque que aplicamos en las plataformas de cumplimiento que desarrollamos: ningún aviso se genera sin pasar antes por las cuatro capas.

Si tu equipo genera avisos y quieres automatizar su validación, Escríbenos.