Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[antoine0]

Empezado por edari

Yo también le estoy dando vueltas a esto, me parece muy importante hacer ese Webservice de verificación porque, como sea como TicketBai, cada vez que subes una factura y es rechazada por algún tema de NIF...puede provocar errores de encadenamiento

No debe provocar ningún problema de encadenamiento.

Cuando creas una factura, la encadenas. Este registro tiene código S0 en el campo TipoRegistroSIF
Si hay un problema de NIF o de IVA o cosa similar con esta factura, y se debe modificar algo, creas otro registro con la misma identificación (número de factura y fecha) pero código S1 en el campo TipoRegistroSIF. Dado que es un registro distinto, tiene otra huella y está encadenado en su sitio (orden temporal), independientemente del primero registro. Este segundo registro se debe subir independientemente a la AEAT.

Si luego tienes que anular la factura, será otro registro, esta vez de tipo S2 y con un contenido diferente en el XML, registro que se debe subir por un webservice diferente.
Y para cerrar el circulo, teóricamente también puedes modificar el registro de anulación, será otro registro esta vez con tipo S3, que también sube por el segundo webservice.

Al final, cada vez que con una factura se hace una operación (crear, modificar, «borrar»), se crea un nuevo registro de facturación; este registro debe ser encadenado en su sitio, con las informaciones relevantes de la factura en este momento. Y luego no se toca nunca más.

[sglorka]

Empezado por antoine0

No debe provocar ningún problema de encadenamiento.

Cuando creas una factura, la encadenas. Este registro tiene código S0 en el campo TipoRegistroSIF
Si hay un problema de NIF o de IVA o cosa similar con esta factura, y se debe modificar algo, creas otro registro con la misma identificación (número de factura y fecha) pero código S1 en el campo TipoRegistroSIF. Dado que es un registro distinto, tiene otra huella y está encadenado en su sitio (orden temporal), independientemente del primero registro. Este segundo registro se debe subir independientemente a la AEAT.

Si luego tienes que anular la factura, será otro registro, esta vez de tipo S2 y con un contenido diferente en el XML, registro que se debe subir por un webservice diferente.
Y para cerrar el circulo, teóricamente también puedes modificar el registro de anulación, será otro registro esta vez con tipo S3, que también sube por el segundo webservice.

Al final, cada vez que con una factura se hace una operación (crear, modificar, «borrar»), se crea un nuevo registro de facturación; este registro debe ser encadenado en su sitio, con las informaciones relevantes de la factura en este momento. Y luego no se toca nunca más.

Yo no lo veo así.
Estás suponiendo que el primer registro S0 te lo ha aceptado, y la suposición (creo que es así... ya veremos ) es que no te lo va a aceptar por un error en el NIF (mal informado) o por un tipo de IVA inexistente. Entonces ocurre que el siguiente registro que quieres enviar está encadenado con el registro rechazado y al enviarlo te va a dar error de encadenamiento ya que el servidor no tiene ese registro anterior en su sistema. El registro S1 sólo se debe crear si el/los dato(s) a corregir no implican la creación de una factura rectificativa. Si el error es de un tipo de iva inexistente, o un nif mal informado, entonces hay que emitir una factura rectificativa por sustitución, o sea, otro registro S0. El registro S1 corrige un registro S0 aceptado pero que tiene algún dato mal (como por ejemplo el régimen de tributación ).
En definitiva, la duda es cómo debemos resolver el encadenamiento de los registros de facturación posteriores al rechazo de un registro anterior.

[antoine0]

Empezado por sglorka

Yo no lo veo así.
Estás suponiendo que el primer registro S0 te lo ha aceptado, y la suposición (creo que es así... ya veremos ) es que no te lo va a aceptar por un error en el NIF (mal informado) o por un tipo de IVA inexistente. Entonces ocurre que el siguiente registro que quieres enviar está encadenado con el registro rechazado y al enviarlo te va a dar error de encadenamiento ya que el servidor no tiene ese registro anterior en su sistema. [...]
En definitiva, la duda es cómo debemos resolver el encadenamiento de los registros de facturación posteriores al rechazo de un registro anterior.

Vale. Efectivamente no había pillado bien la casuística.

Si te sigo bien, tenemos lo siguiente:

• En el SIF (la aplicación en casa del cliente, que realice el encadenamiento) se genera una serie de registro R1, R2, R3, R4, encadenados entre sí;
• Se remitirán a los clientes las 4 facturas correspondientes;
• Luego, en un tiempo un poco diferido, se envían a Hacienda estos 4 registros, en 1 o más envíos, da igual. Y Hacienda dice, «el R2 está mal, no lo acepto y hago como si no lo había visto nunca»; luego al validar los registros R3 y luego R4, el sistema de Haciendo no debería aceptarlos, porque «falta» el intermediario... pero es solo el inicio de los problemas;
• Al recibir el aviso sobre el registro R2, se modifica la factura correspondiente (corrección, rectificativa, anulación, lo que sea) lo genera en el SIF el registro R5 (y potencialmente R6, y eventualmente pasar al cliente una nueva copia de la factura; aquí entran los códigos S1 o S2 para R5). Pero no se ha resuelto el problema, y Hacienda seguirá rechazando estos registros R5 o R6 en el sistema Veri*factu...
• Pero visto en la casa del cliente, en el SIF el registro R2 sigue "correcto", no se puede modificar por qué el sistema es inalterable, y todos los registros que lo siguen dependen de él...

No me extraña ahora que en Hacienda están «pensando en esto», o «estudiando internamente» según te han escrito.

Lo único que podemos esperar es que los controles para pasar R2 al estado "AcceptadaConErrores", que sí permite reconocer el encadenamiento (creo), sigan lo más básico posible; es decir, poco más que controlar que el XML es descifrable y luego que la huella anterior es la esperada dado el SistemaInformatico indicado (o parte de). Y desde luego que se publiquen normas claras al respecto.

[keno_71]

Perdonad la ignorancia pero este tema que comentáis antoine0 y sglorka no está resuelto en Ticketbai?, pensaba que se habían basado en este sistema y entiendo en la experiencia que ya hay sobre él para la implantación y todos estos problemas de encadenamiento por ejemplo ya estaban más que pensados por Hacienda. En el momento que salga el Reglamento Técnico creo que es cuando van a desvelarse muchas dudas. Saludos

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

Empezado por antoine0

Lo único que podemos esperar es que los controles para pasar R2 al estado "AcceptadaConErrores", que sí permite reconocer el encadenamiento (creo), sigan lo más básico posible; es decir, poco más que controlar que el XML es descifrable y luego que la huella anterior es la esperada dado el SistemaInformatico indicado (o parte de). Y desde luego que se publiquen normas claras al respecto.

Empezado por keno_71

Perdonad la ignorancia pero este tema que comentáis antoine0 y sglorka no está resuelto en Ticketbai?, pensaba que se habían basado en este sistema y entiendo en la experiencia que ya hay sobre él para la implantación y todos estos problemas de encadenamiento por ejemplo ya estaban más que pensados por Hacienda. En el momento que salga el Reglamento Técnico creo que es cuando van a desvelarse muchas dudas.

Os explico un poco cómo se hace en TicketBAI por si el tema va similar.
Lo primero es que una factura en la cual falla el encadenamiento es "ACEPTADA CON ERRORES"; Es decir, una factura que lleva el encadenamiento mal no se rechaza. Hay situaciones en las que se puede dar esta situación. Algunas son correctas (por ejemplo, cambio de serie al final del año) y otras por situaciones inesperadas (backup/restore después de un error). Lo que es posible que hacienda te pida explicaciones de porqué se ha roto ese encadenamiento y tengas que justificarlo.
Seguramente si tienes 3 errores de encadenamiento en un año no se molesten, pero si cada semana estás enviando "roturas" de encadenamiento te llamarán para saber "qué estás haciendo"

Por otro lado, que una factura sea RECHAZADA, no significa que hacienda no se quede con información de ella.
Por ejemplo, yo he creado estas 3 facturas:


Las tres van encadenadas de forma consecutiva y de esta forma:

viz 2 --> viz 3 err --> viz 4

La primera ACEPTADA (viz 2), la segunda está RECHAZADA (viz 3 err) encadenada con la anterior y la tercera al enviarla está ACEPTADA (y está encadenada con la segunda, que está RECHAZADA).
No hay error de encadenamiento, porque yo las he encadenado bien.
Como la segunda está RECHAZADA, tendré que corregirla o realizar una rectificativa y volver a enviarla por los cauces que me digan (en el caso de TicketBAI hay diferentes formas según la tribitación).

Lo que quiero decir es, que aunque la segunda esté rechazada (eso es a posteriori), sí que entra en el encadenamiento. Ahora mismo la factura no es válida (por el error que sea), pero hacienda sí que se ha quedado con información se esa factura (como debe ser). Porque lo que no vale ahora es decir, "como está RECHAZADA, la borro en mi sistema y la creo nueva" . Hay arreglar esa que ya has enviado.

Hay situaciones en las que sí se puede BORRAR una factura (ANULACION) pero son casos especiales. Una factura, aunque esté RECHAZADA no se puede BORRAR. Hay que corregirla y enviarla de nuevo o rectificarla, según el caso.

Espero haber aclarado algo.

[pablog2k]

yo espero que Verifactu sea como ticketbai, como el ejemplo tal cual que ha puesto Neftali

[antoine0]

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

Hay situaciones en las que sí se puede BORRAR una factura (ANULACION) pero son casos especiales. Una factura, aunque esté RECHAZADA no se puede BORRAR. Hay que corregirla y enviarla de nuevo o rectificarla, según el caso.

Espero haber aclarado algo.

Sí que has aclarado, y bastante, muchas gracias al respecte.

Una pregunta (relacionada pero distinta) me queda, sobre estos casos especiales. En el caso que una factura siga enviada (estado S0 en SIF) y luego anulada (estado S2 en SIF), ¿es posible «resucitarla»?
Es decir, cancelar la anulación y recuperar esta factura como legítima y válida. El caso más habitual es el caso de una factura anulada por algún bug en el programa.
En el SII, funciona enviando una transacción A1 sobre la factura dada de baja; así que por paralela, sería encadenar y enviar un registro de rectificación (estado S1 en SIF) con todos los datos sobre la factura que era últimamente marcada borrada. ¿Este caso existe en TicketBAI?

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

Empezado por antoine0

En el caso que una factura siga enviada (estado S0 en SIF) y luego anulada (estado S2 en SIF), ¿es posible «resucitarla»?
¿Este caso existe en TicketBAI?

En el caso de TicketBAI no existe esa posibilidad.
Creas una nueva y la subes.

[sglorka]

Gracias Neftali. Parece que era lo obvio que funcionara así, de lo contrario sería un desastre