Errores y códigos de rechazo en SILICIE: diagnóstico por síntoma

El asiento se rechaza y el error no dice por qué

Lo primero: AEAT responde HTTP 200 aunque rechace. Un envío no admitido llega como 200 con un error funcional dentro del cuerpo, un fallo de estructura llega como SOAP Fault y un XML corrupto revienta el analizador antes de leer nada. Si tu integración da por bueno el 200, marcarás como presentados asientos que Hacienda no ha registrado. Cuando el rechazo apunta al primer elemento de la cabecera y no menciona ningún asiento, el problema está en el sobre y no en el contenido. El caso clásico al migrar a los servicios v2 es dejar los esquemas comunes, los de cabeceras, tipos, listas y error, apuntando todavía a la ruta de la versión 1. AEAT contesta que esperaba un nodo del espacio de nombres v2 y ha venido uno de v1. Con eso no pasa ni un envío ni una consulta.

• Comprueba que todos los espacios de nombres, también los comunes, cuelgan de la ruta v2.
• Centraliza los namespaces en una constante única; nada de literales sueltos por operación.
• Trata tres ramas explícitas al leer la respuesta: SOAP Fault, error funcional y éxito.

Dice que falta un campo que sí estoy mandando

Este es el rechazo que más tiempo cuesta porque el mensaje engaña. AEAT dice que esperaba el cierre de un bloque y ha venido tu campo, y suena a que el campo sobra. Lo que está mal es el prefijo. Con validación cualificada, el prefijo depende de dónde se declara el elemento, no de dónde vive su tipo. Los identificativos del asiento, como la referencia interna, el asiento previo o el asiento previo de reintroducción, y también las observaciones, están declarados dentro del propio esquema de entrada del mensaje: llevan su prefijo aunque el tipo esté en el fichero de tipos. Y al revés: movimiento, régimen, tipo de justificante, unidad de medida y diferencias de menos parecen del fichero de listas, pero ese fichero solo contiene tipos enumerados y no declara ni un elemento. Van con el prefijo de tipos.

• Abre el XSD: si el campo aparece como elemento propio en tipos, prefijo de tipos; si está inline en el mensaje, prefijo del mensaje.
• Las observaciones solo rompen cuando vienen rellenas: los asientos limpios pasan y el fallo salta luego, en un lote real.
• Prueba siempre con al menos un asiento que rellene todos los campos opcionales antes de dar la integración por buena.

Se cae el lote entero por el valor de un campo

Dentro de una llamada el modelo es todo o nada: si un asiento falla, se rechaza el lote completo. Por eso un detalle tonto tumba cientos de asientos buenos de golpe. Dos causas habituales. Una: limpiar los códigos al mapearlos desde tu base de datos. El servicio quiere el código tal cual aparece en la plantilla oficial, con su letra delante, tanto en tipo de movimiento como en tipo de justificante. Si se la quitas, responde que el valor del campo no es válido y no dice cuál esperaba. Ojo al camino inverso: en la consulta algunos asientos vuelven sin esa letra, así que al importar hay que reponerla. Dos: una reintroducción necesita el número de asiento que AEAT asignó a la operación original. Si ese original todavía no está aceptado, no hay número que poner y bloquea la presentación entera.

• Resuelve antes del envío el mapa de números AEAT y aparta las reintroducciones que no puedas resolver.
• Ordena el lote por fecha y número para que las dependencias del mismo día salgan en orden.
• Aparta, no canceles: el resto de la tanda puede presentarse igual.

AEAT dice que la referencia ya está repetida

Ese aviso no significa que el asiento esté mal. Significa que AEAT ya lo tiene aceptado con esa referencia interna para tu CAE. Es información, no rechazo. El daño lo hace la integración cuando lo trata como error: marca el lote completo como rechazado, machaca el estado aceptado anterior y deja huérfanos números de asiento que en el sistema de Hacienda siguen siendo perfectamente válidos. La pantalla vuelve a considerarlos pendientes, se reenvían, vuelve el mismo aviso, y así indefinidamente. Hemos visto ese bucle en producción con un lote que había sido aceptado horas antes. La regla es simple: un asiento que ya tiene número de asiento de AEAT no se degrada nunca.

• Filtra por estado aceptado y por presencia de número AEAT antes de marcar nada como rechazado.
• Para reparar datos ya corrompidos, restaura los rechazados por duplicado que conserven número AEAT.
• Guarda código y motivo de error por asiento: sin eso no distingues un duplicado de un rechazo real.

La anulación no la acepta

La anulación es el servicio con más trampas encadenadas. El espacio de nombres lleva subcarpeta propia; si te la comes, la respuesta es que no encuentra la etiqueta de inicio y parece un XML roto. Cada elemento a anular exige tres bloques anidados en secuencia: el asiento contable anulado, los datos de la anulación con su referencia interna y su fecha de registro contable, y el motivo, que es un enumerado de un solo carácter. El punto crítico es cuál es el número que se anula: el número largo que asignó AEAT al aceptar el alta, no la referencia interna corta que enviaste tú. Sin él no se puede anular ni por web service ni por la sede. Otra: la respuesta de anulación no devuelve lista de aceptados, así que si reutilizas el analizador del alta contarás cero anulados aunque haya ido todo bien.

• Guarda siempre el número de asiento largo que devuelve el alta; sin él te quedas sin salida.
• La referencia interna de la propia anulación tiene longitud limitada: genera un identificador corto.
• Anular no borra: AEAT marca el original y da de alta una anotación nueva que contamina consultas e importaciones si no la filtras.

El envío se cortó y no sé qué llegó

Con ejercicios grandes AEAT tarda decenas de segundos en responder. Si tu cliente HTTPS corta antes, o si la función que lo llama tiene un límite de ejecución más corto que el propio cliente, obtienes un timeout intermitente que solo aparece cuando el volumen crece. Los dos plazos tienen que ser coherentes: el que corta antes enmascara al otro. Y hay un fallo silencioso peor: en entornos serverless, las tareas de cierre lanzadas sin esperar respuesta se cancelan en cuanto la función devuelve, y quedan documentos sin marcar sin ningún error visible. Cuando no sabes qué entró, no reenvíes a ciegas: consulta el ejercicio y reconcilia. AEAT detecta reenvíos por el identificador del mensaje, así que ese identificador se genera una vez, se guarda y se reutiliza en los reintentos.

• Sube el timeout del cliente por encima del peor tiempo de AEAT, y el de la función por encima del cliente.
• Persiste XML enviado, XML recibido, identificador de mensaje y CSV de verificación de cada presentación.
• Si un lote falla, aborta los siguientes: es peor dejar el ejercicio a medias.

La consulta viene vacía o con campos en blanco

Dos causas distintas y ninguna es un error del servicio. La primera es la paginación: la consulta devuelve un máximo de asientos por llamada y avisa de que hay más con una marca literal, no con un booleano. En un ejercicio con historial, las primeras páginas van llenas de asientos antiguos y anulados, y los movimientos recientes están al final. Quien pide solo la primera concluye que faltan asientos. La segunda son los nombres de campo: el origen o destino y la repercusión llegan anidados, con etiquetas prefijadas propias. Si lees nombres planos, la razón social, el NIF y el CAE salen vacíos en todas las consultas y parece que Hacienda no tiene el dato. Añade que en v2 el filtro perdió todos sus envoltorios intermedios: mantener uno provoca el mismo error críptico de validación.

• Bucle de paginación con tope de seguridad y aviso de progreso: son decenas de segundos.
• Lee primero las etiquetas prefijadas y deja los nombres planos como respaldo defensivo.
• Filtra en tu cliente en vez de en el servidor: es más robusto y permite combinar criterios que el servicio no soporta.

Errores que el servicio acepta y la Inspección no

Que el XML pase la validación no significa que el asiento esté bien. Tres focos. Unidades: internamente puedes trabajar en mililitros y gramos, pero el mensaje viaja en litros y kilogramos, y presentar la cifra sin convertir multiplica por mil tus existencias declaradas. Eso es transporte, ojo: la base imponible del impuesto se determina en mililitros y en gramos según el artículo 64 sexies.1 de la Ley 38/1992, y ahí no se convierte nada. Campos que no aplican: los del grupo de operaciones de fabricación existen en el esquema y el servicio los acepta, pero rellenarlos en un depósito fiscal, que no fabrica, es motivo de reproche meses después. Y fechas: si tu proceso corre en UTC, la fecha de registro contable puede irse al día anterior de madrugada.

• Centraliza la conversión de unidades con redondeo explícito y muestra en pantalla las mismas unidades que ve Hacienda.
• Marca como prohibidos en tu propio esquema los campos que no aplican a tu tipo de establecimiento.
• Usa siempre la fecha en zona Europe/Madrid en cualquier campo con efectos fiscales.

Preguntas frecuentes