Errores <<Subsanables>>?

[[newtron]]

Empezado por unomasmas

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.

[ermendalenda]

Empezado por newtron

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

[[newtron]]

Empezado por ermendalenda

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.

[ermendalenda]

Empezado por newtron

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.

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.

[Neftali [Germán.Estévez]]

Empezado por bmfranky

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...

Empezado por newtron

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

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. A ver si entre todos mantenemos esto un poco ordenado.


Gracias.

[[newtron]]

Empezado por Neftali [Germán.Estévez]

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. A ver si entre todos mantenemos esto un poco ordenado.


Gracias.

Se intentará... Gracias por tu esfuerzo.

[ermendalenda]

Empezado por Neftali [Germán.Estévez]

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. A ver si entre todos mantenemos esto un poco ordenado.


Gracias.

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

[[newtron]]

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.

[rci]

Empezado por newtron

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.

[[newtron]]

Empezado por rci

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 . Al final todo van a ser altas por rechazos, rectificativas, sustitutivas, etc.

Saludos.