Errores <<Subsanables>>?

[bmfranky]

Empezado por ermendalenda

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

[[newtron]]

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

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


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.

[unomasmas]

Empezado por newtron

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.

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

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

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

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

[rci]

Empezado por newtron

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.

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?

[[newtron]]

Empezado por rci

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.

[sglorka]

Empezado por newtron

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.

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

[[newtron]]

Empezado por sglorka

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?"

[Faneka]

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

[[newtron]]

Y ya puestos y como me atienden tan amablemente y con tanto detalle 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.

[Faneka]

Empezado por Faneka

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.

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.