Ley antifraude 2021 (VERIFACTU) - Programas informáticos

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

[antoine0]

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

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

Quieres decir qué ¿el sistema te deja «crear» dos facturas con el mismo número?

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

Empezado por antoine0

Quieres decir qué ¿el sistema te deja «crear» dos facturas con el mismo número?

No.
Factura nueva, número distinto.
Pero creo que eso no tiene que ver con TicketBAI sino con la ley de facturación.

La ley de facturación especifica unos casos muy concretos para poder ANULAR una factura. Lo habitual y lo correcto es RECTFICARLA si hay errores.
Pero si en algún caso DEBES anularla, entiendo que no puedes repetir en número. En ese caso deje un "hueco" y si es necesario justificas la anulación (con las razones pertinentes).

NOTA IMPORTANTE: No soy experto en temas legales así que por favor si alguien ve que esto es incorrecto que lo comente.

A mi personalmente no se me ocurriría repetir y menos si esa factura debe subir luego a algún sitio (SII, TBAI, VERI*FACTU,...). Crep que va a generar más posibles problemas, que no justificar la anulación y el "hueco".

Nosotros en TBAI lo hacemos así:
1) Creo la factura con numero 3000
2) Creo la factura con número 3001
3) Anulo la factura con número 3001
4) La siguiente que creo coge el número 3002
...

Eso en TBAI no da ningún problema.
Si te piden el porqué de la anulación se justifica y ya está.

[sglorka]

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