Respuestas y Errores -> ¿Es posible envío así de simple?

[GorkaB]

Buenas tardes a todos/as:
Estoy adaptando un programa de facturación para uso personal en php. Me gustaría poder simplificar al máximo la lógica.
¿Veis este diagrama correcto?


Muchas gracias de antemano,


¿Respuesta AEAT contiene errores?


├── NO → Registro aceptado correctamente
│ → Consolidar factura
│ → Fin
│
└── SÍ → ¿Qué tipo de error es?


├── ERROR 2000–2009 (registro aceptado con errores)
│
│ ├── Es error 2004?
│ │ ├── SÍ → No hacer nada
│ │ └── NO → Subsanación
│ │
│ └── (NO rectificativa salvo que haya un error regulado por ROF)
│
├── ERROR 1100–1290 (rechazo de factura)
│ → No hay RF creado
│ → Tratar como si nunca se hubiera emitido
│ → Pedir al usuario que corrija y reenviar
│
├── ERROR 4102–4141 (rechazo de envío / cabecera / XML)
│ → No hay RF creado
│ → Corregir XML/datos/firmas
│ → Reintentar
│ → Tratar como si nunca se hubiera emitido
│
├── ERROR 3000–3004 (duplicado, baja previa, etc.)
│ → No hay RF nuevo
│ → Revisar situación interna
│ → Puede obviarse como no emitido
│
└── Otros errores técnicos
→ No consolidar
→ Corregir y reintentar


Por otro lado, en lugar de hacer una rectificativa, ¿no se puede simplemente hacer una factura en negativo por el mismo importe y aquí no ha pasado nada?

[GorkaB]

Me intento corregir a mi mismo a ver si alguien me puede confirmar:

├── NO → Registro aceptado correctamente
│ → Consolidar factura
│ → Fin
│
└── SÍ → ¿Qué tipo de error es?


├── ERROR 2000–2009 (registro aceptado con errores)
│
│ ├── Es error 2004?
│ │ ├── SÍ → No hacer nada
│ │ └── NO → Subsanación
│ │
│ └── (NO rectificativa salvo que haya un error regulado por ROF)
│
├── ERROR 1100–1290 (rechazo de factura)
│ → No hay RF creado.
│ → Guardar encadenamiento secuencial
│ → Pedir al usuario que rehaga la factura solucionando la descripción del error devuelta
│
├── ERROR 4102–4141 (rechazo de envío / cabecera / XML)
│ → No hay RF creado
│ → Mostrar mensaje de error, advertencia sobre certificado, fallo técnico
│ → Reintentar
│ → Tratar como si nunca se hubiera emitido
│
├── ERROR 3000–3004 (duplicado, baja previa, etc.)
│ → No hay RF nuevo
│ → Revisar situación interna
│ → Guardar encadenamiento secuencial
│
└── Otros errores técnicos
→ No consolidar
→ Corregir y reintentar

[Carlos]

Lo de consolidar factura no tiene nada que ver con Veri*factu.
Las facturas se generan, se consolidan (igual que en el 2020, 2021, 2022,...) y con ellas los RF para Veri*factu, ya veremos que hago con los RF.

Tal como está redactada la documentación (19/11/2025), el error 2004 se DEBE subsanar.
Por qué?
La documentación dice:
"Si se ha informado en el campo FechaHoraHusoGenRegistro una fecha y hora
mayor que la fecha del sistema de la AEAT, admitiéndose un margen de error. Se
excepciona este error de la necesidad de ser subsanado."
Dice 'MAYOR', no distinta; y por tanto si es 'MENOR' sí debe subsanarse.
Pero claro, el error 2004 lo envían tanto para mayor como para menor, entonces no se cuando debo o no subsanar, ante la duda -> subsano.

Los RF se crean, si no están creados no se ha podido crear el XML, independientemente de que Veri*factu responda con error, el RF existe y debe considerarse su existencia en cuanto que el siguiente RF debe ir encadenado a este 'erróneo'.

>>No hay RF creado.
>>│ → Guardar encadenamiento secuencial
Esto no lo entiendo. Pero si tengo claro que en el encadenamiento participan TODOS los RF que he generado independientemente de su resultado.

[ermendalenda]

Empezado por Carlos

Lo de consolidar factura no tiene nada que ver con Veri*factu.
Las facturas se generan, se consolidan (igual que en el 2020, 2021, 2022,...) y con ellas los RF para Veri*factu, ya veremos que hago con los RF.

Tal como está redactada la documentación (19/11/2025), el error 2004 se DEBE subsanar.
Por qué?
La documentación dice:
"Si se ha informado en el campo FechaHoraHusoGenRegistro una fecha y hora
mayor que la fecha del sistema de la AEAT, admitiéndose un margen de error. Se
excepciona este error de la necesidad de ser subsanado."
Dice 'MAYOR', no distinta; y por tanto si es 'MENOR' sí debe subsanarse.
Pero claro, el error 2004 lo envían tanto para mayor como para menor, entonces no se cuando debo o no subsanar, ante la duda -> subsano.

Los RF se crean, si no están creados no se ha podido crear el XML, independientemente de que Veri*factu responda con error, el RF existe y debe considerarse su existencia en cuanto que el siguiente RF debe ir encadenado a este 'erróneo'.

>>No hay RF creado.
>>│ → Guardar encadenamiento secuencial
Esto no lo entiendo. Pero si tengo claro que en el encadenamiento participan TODOS los RF que he generado independientemente de su resultado.

Vale Carlos, he leido detenidamente el mensaje y realmente no es descifrable, la interpretación que das puede que no sea la que han intentado transmitir.
La frase esta dividida en 2 partes separada por un punto, lo que hay después del punto parece que es un intento de ackaracion al conjunto del error, es más se puede interpretar que han querido decir justo lo contrario dr lo que comentas, que puede que sea necesaria su subsanacion si es superior a la hora de la aeat+ el margen(240seg)., cosa que sería mas lógica, o sea, es lógico subsanar si envias a futuro pero si envias con rettaso lp pueden dar por bueno.
De todas formas me mantengo en lo que transmiten una y otra vez en el canal de que no hay que subsanar, pero evidentemente si detectas que tu reloj estaba mal es lógico hacerlo.

[razorxxx]

Empezado por ermendalenda

Vale Carlos, he leido detenidamente el mensaje y realmente no es descifrable, la interpretación que das puede que no sea la que han intentado transmitir.
La frase esta dividida en 2 partes separada por un punto, lo que hay después del punto parece que es un intento de ackaracion al conjunto del error, es más se puede interpretar que han querido decir justo lo contrario dr lo que comentas, que puede que sea necesaria su subsanacion si es superior a la hora de la aeat+ el margen(240seg)., cosa que sería mas lógica, o sea, es lógico subsanar si envias a futuro pero si envias con rettaso lp pueden dar por bueno.
De todas formas me mantengo en lo que transmiten una y otra vez en el canal de que no hay que subsanar, pero evidentemente si detectas que tu reloj estaba mal es lógico hacerlo.

Exacto. Error 2004 lo darán por bueno, y no será necesario reenviarlo. O al menos así lo entiendo yo también.

Es decir, el RF en sí mismo está bien y el único problema es un desfase con las fechas de generación del RF. Esto te puede dar por ejemplo si en el momento de generarlo no pudiste contactar con el servidor ROA para obtener la fecha-hora oficial y tuviste que coger la fecha-hora del sistema y resultó que estaba unos minutos desfasada respecto a la del ROA.

[Carlos]

Empezado por razorxxx

Exacto. Error 2004 lo darán por bueno, y no será necesario reenviarlo. O al menos así lo entiendo yo también.

Es decir, el RF en sí mismo está bien y el único problema es un desfase con las fechas de generación del RF. Esto te puede dar por ejemplo si en el momento de generarlo no pudiste contactar con el servidor ROA para obtener la fecha-hora oficial y tuviste que coger la fecha-hora del sistema y resultó que estaba unos minutos desfasada respecto a la del ROA.

Si, si, el caso es así de sencillo, es un desfase temporal.
Pero bueno yo por si acaso tengo preparado un botón para que si me piden algo sobre el '2004' lo pulso y empieza a enviar subsanaciones.
Y si, considero que el redactado si no quiere especificar lo que entiendo, lo ha escrito un diestro con la izquierda, o un zurdo con la derecha. (es que puede haber gente muy susceptible)

[razorxxx]

Empezado por GorkaB

Me intento corregir a mi mismo a ver si alguien me puede confirmar:

├── NO → Registro aceptado correctamente
│ → Consolidar factura
│ → Fin
│
└── SÍ → ¿Qué tipo de error es?


├── ERROR 2000–2009 (registro aceptado con errores)
│
│ ├── Es error 2004?
│ │ ├── SÍ → No hacer nada
│ │ └── NO → Subsanación
│ │
│ └── (NO rectificativa salvo que haya un error regulado por ROF)
│
├── ERROR 1100–1290 (rechazo de factura)
│ → No hay RF creado.
│ → Guardar encadenamiento secuencial
│ → Pedir al usuario que rehaga la factura solucionando la descripción del error devuelta
│
├── ERROR 4102–4141 (rechazo de envío / cabecera / XML)
│ → No hay RF creado
│ → Mostrar mensaje de error, advertencia sobre certificado, fallo técnico
│ → Reintentar
│ → Tratar como si nunca se hubiera emitido
│
├── ERROR 3000–3004 (duplicado, baja previa, etc.)
│ → No hay RF nuevo
│ → Revisar situación interna
│ → Guardar encadenamiento secuencial
│
└── Otros errores técnicos
→ No consolidar
→ Corregir y reintentar

¿Esto finalmente es así? Pa saber si me lo copio, que estoy en esta fase final .

[razorxxx]

Empezado por GorkaB

Me intento corregir a mi mismo a ver si alguien me puede confirmar:

├── NO → Registro aceptado correctamente
│ → Consolidar factura
│ → Fin
│
└── SÍ → ¿Qué tipo de error es?


├── ERROR 2000–2009 (registro aceptado con errores)
│
│ ├── Es error 2004?
│ │ ├── SÍ → No hacer nada
│ │ └── NO → Subsanación
│ │
│ └── (NO rectificativa salvo que haya un error regulado por ROF)
│
├── ERROR 1100–1290 (rechazo de factura)
│ → No hay RF creado.
│ → Guardar encadenamiento secuencial
│ → Pedir al usuario que rehaga la factura solucionando la descripción del error devuelta
│
├── ERROR 4102–4141 (rechazo de envío / cabecera / XML)
│ → No hay RF creado
│ → Mostrar mensaje de error, advertencia sobre certificado, fallo técnico
│ → Reintentar
│ → Tratar como si nunca se hubiera emitido
│
├── ERROR 3000–3004 (duplicado, baja previa, etc.)
│ → No hay RF nuevo
│ → Revisar situación interna
│ → Guardar encadenamiento secuencial
│
└── Otros errores técnicos
→ No consolidar
→ Corregir y reintentar

Los errores 1100 al 1290 se supone que son los rechazos por no cumplir la famosa "Validación de Errores". El RF no se habría registrado en la AEAT, pero ya se habría generado en el programa y por tanto la factura ya estaría finalizada (no se podría tocar). ¿Qué se debería hacer en estos casos? Lo digo por si acaso nos hemos olvidado de gestionar alguna casuística de la Validación de Errores que tengo implementada justo antes de generar el RF. La facturación no puede parar.

[GorkaB]

Creo que debes generar un registro de anulación o subsanación. Hasta que no subsanes esa factura no consta en el registro de AEAT. Si no subsanas una factura rechazada en VeriFactu, esa factura no tiene validez fiscal y queda como un registro no emitido ante la AEAT, exponiéndote a riesgos de sanciones y problemas en inspecciones.

Para una subsanación de una factura rechazada:

• Si el registro que dio error fue el alta original (primera vez que la mandaste y la AEAT la rechazó), en el nuevo registro de subsanación se informa "rechazoPrevio = X" (hubo rechazo del alta anterior).
• Si lo que se está subsanando es un intento anterior de subsanación que también fue rechazado, en el nuevo registro se informa "rechazoPrevio = S" (hay rechazo de un registro de subsanación anterior).

En todos los casos, debes llevar "Subsanacion = S", si marcas "rechazoPrevio" sin "Subsanacion = S", la AEAT devuelve errores como 1153 o 1161.

En mi caso creo que es mejor anularla automáticamente generando el registro de anulación, referenciando IDEmisorFactura, NumSerieFactura y FechaExpedicionFactura de la original e incluyendo importes en negativo (o cero) y motivo claro (ej. “operación no realizada”). Y aviso al usuario de que esa factura está anulada por los motivos de rechazo.

Así que si rechazan la factura 25, la factura 25 no existe (dejando un hueco) hasta que no la subsanes (será la factura 25 ok) o la anules (será la 25 anulada).

[Carlos]

Empezado por GorkaB

Creo que debes generar un registro de anulación o subsanación. Hasta que no subsanes esa factura no consta en el registro de AEAT. Si no subsanas una factura rechazada en VeriFactu, esa factura no tiene validez fiscal y queda como un registro no emitido ante la AEAT, exponiéndote a riesgos de sanciones y problemas en inspecciones.

Para una subsanación de una factura rechazada:

• Si el registro que dio error fue el alta original (primera vez que la mandaste y la AEAT la rechazó), en el nuevo registro de subsanación se informa "rechazoPrevio = X" (hubo rechazo del alta anterior).
• Si lo que se está subsanando es un intento anterior de subsanación que también fue rechazado, en el nuevo registro se informa "rechazoPrevio = S" (hay rechazo de un registro de subsanación anterior).

En todos los casos, debes llevar "Subsanacion = S", si marcas "rechazoPrevio" sin "Subsanacion = S", la AEAT devuelve errores como 1153 o 1161.

En mi caso creo que es mejor anularla automáticamente generando el registro de anulación, referenciando IDEmisorFactura, NumSerieFactura y FechaExpedicionFactura de la original e incluyendo importes en negativo (o cero) y motivo claro (ej. “operación no realizada”). Y aviso al usuario de que esa factura está anulada por los motivos de rechazo.

Así que si rechazan la factura 25, la factura 25 no existe (dejando un hueco) hasta que no la subsanes (será la factura 25 ok) o la anules (será la 25 anulada).

Cuidado con anular a la ligera. si la factura le ves en papel y está bien, no se debe anular, que leches le vamos a explicar al cliente si quizás ya se ha ido? Se deberá subsanar con los datos adecuados a la operación.
Se anula una factura si por ejemplo se ha emitido por error, pero una factura que se corresponde con una operación comercial en la que los datos que se imprimen son correctos no hay justificación para anularla, se debe subsanar.

[GorkaB]

Empezado por Carlos

Cuidado con anular a la ligera. si la factura le ves en papel y está bien, no se debe anular, que leches le vamos a explicar al cliente si quizás ya se ha ido? Se deberá subsanar con los datos adecuados a la operación.
Se anula una factura si por ejemplo se ha emitido por error, pero una factura que se corresponde con una operación comercial en la que los datos que se imprimen son correctos no hay justificación para anularla, se debe subsanar.

Gracias por el aviso. Es un caso concreto en el que cuadra mejor así y se respeta la norma.

Un saludo

[razorxxx]

Empezado por GorkaB

Creo que debes generar un registro de anulación o subsanación. Hasta que no subsanes esa factura no consta en el registro de AEAT. Si no subsanas una factura rechazada en VeriFactu, esa factura no tiene validez fiscal y queda como un registro no emitido ante la AEAT, exponiéndote a riesgos de sanciones y problemas en inspecciones.

Para una subsanación de una factura rechazada:

• Si el registro que dio error fue el alta original (primera vez que la mandaste y la AEAT la rechazó), en el nuevo registro de subsanación se informa "rechazoPrevio = X" (hubo rechazo del alta anterior).
• Si lo que se está subsanando es un intento anterior de subsanación que también fue rechazado, en el nuevo registro se informa "rechazoPrevio = S" (hay rechazo de un registro de subsanación anterior).

En todos los casos, debes llevar "Subsanacion = S", si marcas "rechazoPrevio" sin "Subsanacion = S", la AEAT devuelve errores como 1153 o 1161.

En mi caso creo que es mejor anularla automáticamente generando el registro de anulación, referenciando IDEmisorFactura, NumSerieFactura y FechaExpedicionFactura de la original e incluyendo importes en negativo (o cero) y motivo claro (ej. “operación no realizada”). Y aviso al usuario de que esa factura está anulada por los motivos de rechazo.

Así que si rechazan la factura 25, la factura 25 no existe (dejando un hueco) hasta que no la subsanes (será la factura 25 ok) o la anules (será la 25 anulada).

Yo sigo con dudas con el tema de las subsanaciones. Por lo que leo, y no sé si he leído bien, ¿hay casos en los que hay que generar nuevos RF sin generar una nueva factura? Y si es así, ¿cuáles serían todas estas casuísticas?

[GorkaB]

Creo que así queda bastante claro

[ermendalenda]

Empezado por GorkaB

Creo que así queda bastante claro

Es extraño en tu esquema no usas nada dd correcciones segun el ROF.
Enfin que Dios nos pille confesados.

[GorkaB]

Empezado por ermendalenda

Es extraño en tu esquema no usas nada dd correcciones segun el ROF.
Enfin que Dios nos pille confesados.

Hola ermendalenda, gracias por el apunte.

Efectivamente, el esquema se centra exclusivamente en el ciclo de vida técnico del envío (Capa de Transporte Verifactu) para resolver la gestión de errores 1100/4100, que es el foco de este hilo.


La gestión funcional de Facturas Rectificativas (Capa de Negocio/ROF) es otro módulo que tu mismo puedes desarrollar en este u otro hilo si te apetece.

Muchas gracias

[razorxxx]

Empezado por GorkaB

Creo que así queda bastante claro

Muchas gracias por el aporte.

[ermendalenda]

No si yo no te digo si esta bien o mal, me parece extraño que hemos estado discutiendo que es susceptible a ROF y que a subsanación y veo un esquema que recoge un montón de errores de todo tipo e indicas subsanar, lo mismo no lo he entendido bien o llevas toda la razón, el tema de los errores no es tarea facil, disculpa si te he ofendido y gracias por el esquema lo tendré que ver más pausadamente

[GorkaB]

Empezado por ermendalenda

No si yo no te digo si esta bien o mal, me parece extraño que hemos estado discutiendo que es susceptible a ROF y que a subsanación y veo un esquema que recoge un montón de errores de todo tipo e indicas subsanar, lo mismo no lo he entendido bien o llevas toda la razón, el tema de los errores no es tarea facil, disculpa si te he ofendido y gracias por el esquema lo tendré que ver más pausadamente

Nada que disculpar, al contrario. Te agradezco mucho el comentario porque este tema es un laberinto y todos estamos aprendiendo sobre la marcha.
Solo hay que leer el título del hilo para darse cuenta de que que yo mismo abrí este hilo estando bastante perdido, intentando simplificar la comunicación SOAP. Después de pelearme con la documentación técnica de la AEAT leyendo comentarios en este hilo y foro y con IA y todo lo que he podido hacer, llegué a este esquema, que si no lo he hecho mal, refleja la lógica de transporte pura y dura.
Creo que la confusión viene de diferenciar 'cuándo subsanar' y 'cuándo rectificar', así que te explico cómo lo he entendido yo por si te ayuda a ubicar tus dudas sobre el ROF:

1. El Muro de Entrada (Mi esquema) Mi esquema se centra en conseguir que la factura entre. Si la AEAT me devuelve un error 1100-1299 (ej: NIF no censado o formato incorrecto), para ellos la factura no existe.

• Solución: Arreglo el dato técnico y reenvío la misma factura (mismo número) con la marca de <Subsanacion>.
• Aquí es donde aplica el esquema que subí.

2. Una vez dentro (Donde aplica el ROF) Si el esquema termina en "Aceptada/Correcto", la factura ya es legal y firme.

• Si después de esto nos damos cuenta de que el importe estaba mal o el cliente era otro, ya no puedo subsanar (el envío técnico ya terminó).
• Solución: Aquí entra lo que tú comentas del ROF: hay que hacer una Factura Rectificativa (nueva numeración, serie R) que anule a la anterior.

En resumen: mi esquema cubre solo la batalla técnica para cruzar la puerta de la AEAT. Tu preocupación sobre el ROF es lo que ocurre justo después, cuando ya estamos dentro. Échale un ojo con calma cuando puedas porfavor y me dices si te cuadra esta distinción.


¡Un saludo!

[ermendalenda]

Hola,
acabo de echar un vistazo y la solución que propones inicialmente y técnicamente te va a valer, pero...
El problema es que en el rango de errores que señalas para realizar una sustitutiva hay ciertos errores, como te comenté, que están recogidos en el ROF y teniendo enb cuenta que la factura se la lleva el cliente (ya hay una emisión y entrega) y teniendo en cuenta que la has emitido por que no sabias del error hasta que la has remitido a Verifactu(en caso de instalación con remisión), entonces nos encontramos con los siguientes riesgos:
-En ciertos casos de los errores puede no ser valido el QR al realizar la subsanación, ejemplo correcciones de cuotas o importes totales, dando como resultado un importe distinto y generandose, por tanto, un QR diferente. Si el cliente receptor de las facturas Inicial , procede a leerla con un lector, puede surgir una discrepancia y una alerta en los servidores de la AEAT. Si estás en No-Verifactu el riesgo es que lea la inicial y la subsanada, o que declare el importe de la inicial.
-En caso de los errores por NIF's erroneos, ocurre algo parecido, si el NIF erroneo es el del emisor y subsanas, el QR final va a ser diferente, si el NIF del cliente es erroneo el ROF indica que debes proceder a rectificar, ya que la factura debe constar con los datos correctos.ún el caso

Lo que hemos estado discutiendo en innumerables hilos son las soluciones a estas incertidumbres, cuando tienes un rechazo y el elemento del rechazo está recogido en el ROF, tienes 2 opciones:
-1 Anularla y remitirla sin registro previo (si aún no la has entregado al cliente)
-2 Rectificativa por sustitución o un abono y reemisión
Y en el punto 2 está el gran problema ¿Como queda una factura rectificativa o 2 en caso de abono al cliente erroneo, de las que no tienen por que te han rechazado?... pues considerando tu esquema, técnicamente es la mejor solución, pero nos encontramos en una laguna técnica de que no hemos cumplido con el ROF, pero en caso de una discrepancia de lo declarado por el cliente (compras) y lo declarado por el emisor(ventas) tenga diferencias.
¿Solución?
Nadie lo tiene claro, cada uno va a proceder como vea más congruente, pero existe una inseguridad jurídica que queda a interpretación de quien mire.
Por otro lado, se supone, que estos errores serán iniciales y/o muy puntuales.
En resumen, yo voy a proceder como comentas "subsanación", pero teniendo en cuenta que habría que intentar contactar con el cliente que recibió la factura si el error puede suponer alguna discrepancia.

Saludos y feliz año