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