Errores <<Subsanables>>?
 

Extraído del documento de errores de verifactu
Aquí hay algo que no me cuadra sobre el error 2004.lo reviso.

Ya está, es correcto, pensaba que en el QR iba la fecha de generación del registro, pero no,

Me ha dado un microictus cuando he leido esto en las faqs de como we corrige un gmregustro de facturación generado erroneamente:
O sea, una factura sustitutiva y marcar también subsanacion?
Esto es muy raro

Entiendo que puede haber sustitutivas de facturas correctas y sustitutivas de facturas con errores y que esa sea la diferencia.


Saludos.

Si claro. Pero una factura rectificativa por sustitucion ya es una subsanacion, no entiendo que haya que marcar también un ea subsanacion
No me cuadra el lio.

Pero si supuestamente no se puede modificar una factura emitida... ¿Cómo se va a subsanar la factura que se devuelva con el error 2001?
Yo creo que o se anula la errónea y se emite una nueva o se hace rectificativa (no sé si sustitutiva o por diferencias) de la errónea y se emite una nueva

Porque el Nif sí está construido correctamente pero la Aeat no lo tiene censado (el contribuyente no ha realizado trámites con la administración en los que haya dejado un rastro tributario). Por lo tanto, siendo válido el Nif, ya que en caso contrario no te hubiera devuelto ese error, toca subsanar enviando registro con campo IDOtro con IDType = 07 (No censado)

Me parece recordar que ese error también aparece si es una persona física y se ha escrito el nombre y apellidos de forma bastante diferente a lo que tienen registrado en la AEAT. En ese caso se tendría que enviar subsanación corrigiendo el nombre y apellidos.

Según tengo entendido, lo que no puedes modificar es el registro de facturación, el XML creado al emitir la factura. Pero la factura en si, puede ser mínimamente modificada en algunos puntos, por ejemplo para corregir un apellido que está mal escrito. Posteriormente generar un nuevo registro de facturación, con la corrección y para enviar como subsanación.

Por favor corríjanme si estoy equivocado.

P.D. no se si para debatir ese punto (de "modificar" una factura y ) haría falta un nuevo hilo. Creo que en el foro original ya se debatió en varios mensajes

Si no hay concordancia entre NombreRazón y Nif (y el Nif es correcto) entonces te rechaza la factura. No puedes subsanarla, debes emitir factura rectificativa con el nombre corregido ya que en una subsanación no cabe este tipo de corrección.

Si el nif no está censado pero es válido, no tienes que cambir nada en la factura, sólo debes emitir una subsanación

¿Eh? :confused:
Una rectificativa es una nueva factura, con número independiente, fecha independiente etc.
Su relación con la(s) factura(s) que rectifica es otra que la relación de subsanación de registros de un SIF.
Su alta inicial no debe ser marcada como subsanación.

A lo mejor tendríamos que poner ejemplos concretos con sus XML de envió y respuesta de errores subsanables. Porque esto se está liando más que otra cosa.

No pongo ninguno porque la verdad es que no tengo nada claro el tema.

Tienes razón sglorka, me he confundido con el SII.

En Veri*factu si nombre y apellidos no coinciden con lo que tiene registrada la AEAT (casi al 100%) se rechaza.
Si coincide bastante (por ejemplo le falta una letra al final) se acepta como correcta.
No es el caso del error de no censado que se comentaba.
Disculpad la confusión.

La factura que te rechaza te la devuelve como INCORRECTA si no me equivoco, esta factura se queda así y ya no se vuelve a enviar por lo que veo. Luego hay que hacer la rectificativa corregida y es la que envias. El tema que tengo aquí con el ERP es que el tema de las rectificativas hay que entrar a la factura rectificativa una vez generada y modificar los campos de la factura original de la que se hizo esta rectificativa, como esta el proceso de verifactu no podría hacerlo porque al generar la factura se envia, es algo que tengo anotado para hablarlo con los compañeros. ¿Como haceis vosotros el tema de las rectificativas? cuando se hace el albarán ya se indica que va a rectificar a la factura X ....., la verdad que estoy pez en este tema, yo estaba en contabilidad pero se jubilo un compañero justo ahora y me ha tocado el caramelo del verifactu, jaja.

Si mal no recuerdo yo he hecho pruebas enviando un NIF+NOMBRE erróneo, me la devuelve como incorrecta, la corrijo y la reenvío como subsanación y se la traga. Viendo esto mi táctica va a ser poder modificar las facturas rechazadas como incorrectas para reenviarlas como subsanación y las ya subidas de forma correcta no dejar tocarlas.

Hay casos como éste, hay que cambiar datos en la identificación del destinatario, donde puedes automatizar el proceso. Simplemente, establece los datos correctos en la ficha del Cliente y luego estando sobre la factura que quieres rectificar, muestras un submenú (es un ejemplo ) con la entrada, Emitir Rectificativa debidos a errores de Destinatario y ya procedes a realizar la operación sin intervención del usuario, bien rectificando con el método de 1 paso o con el de dos pasos si es el que usas de forma general.

Cualquier registro rechazado, independientemente de la causa, puede ser subsanado con un Alta x Rechazo donde se corrige el fallo y Verifactu te lo va a aceptar sin problemas. El único "pero", como se ha ido advirtiendo en este foro a raudales, es que no todo es subsanable. Si vas a ir por ese camino me temo que vas a errar.

Entiendo pero la verdad es que yo veo difícil que un número grande de mis clientes acierten a manejar las posibles incidencias con sus múltiples opciones. No es tarea fácil para un usuario normal y esto puede ser un caos.

Puedes hacer un "Flujo de intentos de subsanacion".
En las subsanaciones si no has enviado previamente la factura te da error, con lo cual sería otra cosa a tener en cuenta. Así que vamos a tener que romper la cabeza para hacer flujos de subsanaciones según el caso, pero al operador no podemos dejarlo xon el culo al aire, por que la va a liar y al final va a recaer en nosotros.
A ver si entre los que podamos podemos "inventar" una hilera de subsanaciones/rectificaciones según el error devuelto.

Me parece una idea estupenda y que igual se merece un hilo específico porque igual entre todos podemos aclarar un procedimiento fácil para el usuario y que cumpla la normativa dentro de lo posible.


Neftali, si lees esto... qué opinas?

Yo vería bien 2 hilos
Uno para discutir/exponer/intercambiar ideas de cada escenario y en otro hilo ir poniendo los que creamos ya oks.

Yo veo mejor un hilo especifico por error/errores relacionados, por ejemplo los que tienen que ver con la identificacion del usuario final , los que tienen que ver con los tipos, etc...

Con tanto hilo igual nos dispersamos más de la cuenta. :rolleyes:


A mi me parece bien la idea de tener uno genérico de discusión y otro que sea: "Procedimientos de respuesta a rechazos" (o algo así), que se quede "achinchetado" al principio donde los demás post de interés y que se vaya actualizando según las soluciones a las que vayamos llegando.

A primera vista, me parece una buena idea. ¿En TicketBAI también lo tienes así? Yo en TicketBAI no dejo modificar datos incluidos en la factura una vez emitida y he tenido algún que otro dolor de cabeza con esto cuando se ha cometido algún error como indicar un tipo de IVA incorrecto, por ejemplo...

Yo vendo a clientes medio cercanos, soy de andalucía y no he necesitado resolver el tema TicketBAI. El tema es que si la factura no se ha subido por algún error entiendo que debería poderse modificar para subirla de forma correcta y si ha subido si que no se podrá tocar pero bueno... es mi idea, igual me equivoco (como comenta algún colega) y tengo que repensar el sistema.

Es que el problema no es siempre el mismo:
-Aceptada con errores
-Rechazada y no la guardan por que no cumple esquema
-Rechazada por que temas de certificado electronico (Caducado, no coincide con el OT...)
-Rechazada y no la guardan por error en <<cabecera>> del registro

Después estan los temas de encadenamiento (huella y QR ) que tienes que tener en cuenta:
-Has generado una huella y el qr con datos que no vas a tocar
-Has generado una huella y el qr pero lo que tienes que arreglar afecta a uno de los 2 o a ambos.

A partir de ahí tienes que tener en cuenta:
-Si es una subsanación de un registro que te han aceptado
-Si es una subsanación de un registro que te han rechazado
-Si es una subsanación de un registro que no existe en verifactu (Rechazado por el esquema, o por que el certificado estaba mal...)
-Si es un error en los datos del cliente (Receptor) y aqui tambien se divide en mas de 1 solución según el problema, si se han equivocado de cliente, si el cif está mal y lo rechazan....
-Si es un error en cualquier otro lado dentro del nodo del registro de alta o anulación, tienes que hacer rectificativa o una anulación, pero dependiendo del error puede ser rectificativa por sustitución o por diferencias.


Ojalá fuera así de facil, lo regenero y listo

Entiendo, gracias por el detalle de la explicación. Lo que sigo pensando es que si yo (por ejemplo) que estoy medio al tanto de este tema me está costando entender qué hacer en un caso u otro, o como resolverlo, la gran mayoría de los usuarios no van a dar respuesta a esto nidecoña. ¿Entonces qué pasará? Imagino que una de dos: o nos llamarán para preguntarnos qué hacer (que ya nos pasa) o harán lo que les "zumbe", meterán la pata y luego nos llamarán igualmente. Creo que esto es muy complicado para el usuario medio y habría que buscar la forma de automatizarlo lo máximo posible como ya hemos comentado.


Gracias y un saludo.

Esto va para todos los usuarios.
Si detectáis hilos similares o que van sobre el mismo tema, avisad con un privado y los "unimos/combinamos" en uno sólo.

A veces a los moderadores se nos escapan o no nos la da vida para tanto. :o:o A ver si entre todos mantenemos esto un poco ordenado.


Gracias.

Se intentará... Gracias por tu esfuerzo.

En el SII son flexibles, no creo que en Verifactu sean menos.
Supongo que si ven fallos puntuales, en un comercio con una facturación media normalmente de importes no muy altos, no van a pedir explicaciones. Pero tampoco hay que fiarse. Lo haremos lo mejor que podamos, los que lo hagan muy mal pues estaran los primeros en la lista, tonto el último!!

Para los usuarios no creo que podamos llevarlo de la mano para que resuelva todo, como bien dices,ya hemos visto que nos cuesta.

Ok, lo intentamos gracias por todo. De todas formas lo que estaban discutiendo era eso mismo, si mejor un hilo o varios para subdivir el tema de subsanaciones errores y cual era tu opinión sobre ese tema concreto.
Se han dado 2 ideas:
-1 hilo chinchetado al principio con los temas ya hablados y cerrados por cada tipo de error, + 1 hilo de discusion de lo mismo
-1 hilo para todo, tanto para la discusion como para cerrar cada tema

Ok. Para aclarar el tema he hecho una consulta directa a la aeat sobre el las facturas incorrectas. La pregunta básicamente ha sido si se puede enviar todo como subsanación y como indicáis y yo me temía la respuesta ha sido esta:

-----------------------------------------------------------------------------------------------------------------
Tenga en cuenta que el reglamento VERIFACTU no realiza ningún cambio en el reglamento de obligaciones de facturación. Por lo cual, si el cambio a realizar supone la emisión de una factura rectificativa, así deberán proceder y generar el correspondiente registro de facturación de alta de la factura rectificativa. En cambio, si el cambio a realizar no supone la emisión de una factura rectificativa, entonces sí pueden optar por realizar un registro de ALTA DE SUBSANACION para su corrección.

En definitiva y por si lo quieren usar como base para remitir a sus usuarios. La forma de proceder sería la siguiente:

- Si los errores se detectan "mientras se está confeccionando la factura", es decir, cuando se está editando pero aún no se ha emitido, se corrigen antes de emitirla y posteriormente se procede a una emisión ordinaria (cuando se emita, se supone que estará correcta).

- Si los errores se detectan tras la emisión, se rectifican de acuerdo con lo que diga el reglamento de obligaciones de facturación (ROF), aprobado por el Real Decreto 1619/2012, según el tipo de error de que se trate, según la regulación del ROF (RD 1619/2012) y atendiendo a los códigos que se detallan en la OMHAC 1177/2024.

- Si son errores no contemplados en el ROF, pero que afectan a campos del registro de facturación (RF) generado al emitir la factura, se debe corregir la factura y se debe dar de alta un RF de alta de subsanación con los datos pertinentes.

- Si son errores no contemplados en el ROF pero que no afectan a campos del registro de facturación (RF) generado al emitir la factura, se corrige la factura sin que sea preciso rectificar el RF generado.

- Si se considera que "toda la factura" en sí misma está mal o no debería haberse emitido, siempre que para solucionarlo no deba emplearse algún procedimiento (de rectificativa u otro) previsto en el ROF, se podrá "anular" y generar un RF de anulación
-----------------------------------------------------------------------------------------------------
Así que claramente habrá que tener en cuenta el motivo de la "incorrección" para hacer una cosa u otra. Miedomeda....

Podríamos ir preparando tal y como se ha comentado un pequeño protocolo de motivos de errores y cómo actuar en cada caso.

Saludos.

Exacto, supongo que tendremos que hacer una lista de códigos de error que devuelva hacienda y en cada casa hacer una cosa u otra. Pero igualmente tendrá que intervenir el usuario para hacer la corrección, en algunos casos.

Ya puestos les he preguntado si en el caso de rechazarse una factura porque el NIF es incorrecto o no está censado si era posible corregirlo y enviar la factura como subsanación y me responden esto:


------------------------------------------------------------------------------------------------------------
En el caso de no identificarse correctamente un NIF de los indicados en el mensaje XML (Cabecera, emisor, destinatario, etc ) el registro queda rechazado y no se acepta en el sistema. En ese caso deben corregir el NIF y generar un nuevo registro de facturación de tipo ALTA POR RECHAZO y realizar la presentación. Solo hay una excepción a este procedimiento y es cuando el problema de identificación es en el destinatario y se obtiene el error "1123 El formato del NIF es incorrecto.. NIF: XXXXXX". Si el NIF no está censado (pero les consta que es correcto) y rechazamos la factura, la forma de proceder para enviarla se realizará identificando a la persona a través del bloque IDOtro con los siguientes contenidos: CodigoPais=ES - IDType=07. No censado – ID=NIF no censado del receptor de la factura y en el campo “NombreRazon” los datos identificativos (apellido1 apellido2 nombre). En este caso, la factura figurará como aceptada con errores con el código de error 2001.

En el caso de entorno de producción, el comportamiento será idéntico a cómo ya ocurre actualmente en el SII:
Tras presentar una factura con destinatario no censado, se inicia un proceso de auto censo. Si tras las validaciones internas pertinentes se considera que el NIF es correcto, transcurridas unas 48 horas se censa de forma automática. Son casos muy puntuales pero pueden ocurrir en ciertas ocasiones (por ejemplo, un NIE expedido por la policía recientemente y que aun no consta en el censo de la AEAT).
--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Después de todo esto la verdad es que no se me ocurre cuando se puede reenviar una factura como subsanación :confused:. Al final todo van a ser altas por rechazos, rectificativas, sustitutivas, etc.

Saludos.

Cuando dicen ALTA POR RECHAZO ya se refieren a subsanación no?
Viendo el Excel DsRegistroVerifactu.xlsx en la pestaña "A)Cuadro Operativa Alta" en el caso de "ALTA POR RECHAZO" lo indica.

Te refieres a esto?

Ok, el texto me había confundido. ALTA POR RECHAZO=SUBSANACION entiendo.


Bueno.. ya me voy aclarando algo: Si el rechazo es porque el nif es incorrecto o no censado se corrige en la factura y se reenvía marcado como subsanación. Si la factura se ha subido correctamente y hay que modificar algo se crea una nueva factura bien sustitutiva o rectificativa por diferencias. ¿No?


La duda que me surge entonces es si se ha rechazado por otros motivos qué pasa.


Saludos.

A ver, el Alta x Rechazo es una Subsanación. Cada técnico al que se le pregunta, normalmente, no se explica de forma correcta y te induce a errores, es raro el técnico que te explica algo y te queda claro. La respuesta que posteaste ayer es de las más claras que he visto y debería ser el camino a seguir para resolver estos problemas.

Fíjate en esa respuesta lo que te dice
"Si son errores no contemplados en el ROF pero que no afectan a campos del registro de facturación (RF) generado al emitir la factura, se corrige la factura sin que sea preciso rectificar el RF generado."
Por ejemplo la cabecera del mensaje (no del registro de facturación) , si está mal el Nif o el nombre del Obligado, puedes hacer una modificación de tu mensaje sin tocar la factura y enviar una subsanación de Alta x Rechazo.

Si lo que está mal es Nif del Emisor de factura en el nodo IDFactura que pertenece al registro de facturación, entonces como este campo sí está regulado por el ROF (Nif del emisor incorrecto), debes generar una rectificativa con el Nif correcto y enviarla como alta nueva.

Si lo que está mal es el NIf del destinatario dentro del registro de facturación, entonces como este campo sí está regulado por el ROF (Nif del destinatario incorrecto), debes generar una rectificativa con el Nif correcto y enviarla como alta nueva

Si el nif del destinatario es válido y no está censado no estás incumpliendo el ROF, por lo tanto puedes enviar una subsanación (error 1123) con los datos de Nif no censado

Ok gracias por la aclaración. A ver cómo planteamos todo esto para que el usuario medio sea capaz de manejarlo (que lo veo complicado). Me estoy viendo poniendo un canal de atención exclusivo de atención al cliente que se llame "Ñapas VeriFactu"... Cuando llame alguien se responderá con un..."Ha llamado a Ñapas VeriFactu. ¿En qué puedo ayudarle?" :D:D

El NIF del obligado es igual al nif del emisor por lo que tenía entendido hasta ahora, con este mensaje anterior me sembro la duda. Es la empresa (obligado) el que genera la factura (emisor).

Y ya puestos y como me atienden tan amablemente y con tanto detalle :D les he preguntado en qué situaciones se puede enviar la factura como subsanación. Esta es la respuesta:



------------------------------------------------------------------------------------------
Si son errores no contemplados en el Reglamento de Obligaciones de Facturación, pero que afectan a campos del registro de facturación (RF) generado al emitir la factura, se debe corregir la factura y se debe dar de alta un Registro de Facturación de alta de subsanación con los datos pertinentes. Por ejemplo, un registro presentado con una huella o hash erróneo es algo que no está contemplado en el reglamento de facturación, solo en los registros de facturación. Por lo tanto, se debe presentar un nuevo registro de facturación de tipo ALTA DE SUBSANACION.

------------------------------------------------------------------------------------------


Saludos.

Volviendo a este tema que te rechace una factura como incorrecta (por tema de NIF por ejemplo) y tengas que hacer una rectificativa, la factura original hacienda no se la quedo, en mi sistema la tengo como INCORRECTA, ¿esta factura ya no se va a volver a subir, no? tengo que marcarla de algún modo como que se hizo una rectificativa y aunque este incorrecta no se debe intentar volver a subir porque no se va a subsanar.
Tenía anotado algo de esto y estaba ahora dandole vueltas y quería dejar un poco atado el tema.