Ley antifraude 2021 (VERIFACTU) - Programas informáticos

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

[antoine0]

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

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

Vale. Tiene todo el sentido del mundo. Aunque no creo que se debe al reglamento de facturación; me explico:

En el S.I.I. estamos apañando la subida de un número grande de facturas hasta Hacienda. Por tanto el sistema debe gestionar casos complejos de comunicación de sistemas; y si me han pasado unos casos de facturas que he tenido que anular en el S.I.I., han sido por causas relacionadas con bien el sistema de facturación bien la aplicación SII; y cuando hay un bug en una de los dos, pues resulta ser un problema.

En los SIF, igualmente que en TicketBAI, no debe ocurrir «tantos» problemas de anulación por qué debe haber muy pocos casos de anulación y todos tienen que ver con el sistema de facturación. La subida a Hacienda no puede generar problemas dado que lo que se sube es lo que hay en la cadena dentro del SIF, no es una elaboración hecha a posteriori (como sí es el caso del SII en todos los casos donde el SII se ha añadido a un sistema existente; aquí está a mi juicio la razón).

Dónde tienes razón es que los casos de anulación (registros tipo S2+S3 en el SIF, uso del webservice BajaFactuSistemaFacturacion) deben ser estrictamente los enunciados en las normas de aplicación del reglamento de facturación (el reglamento en sí no contempla esta oportunidad).

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

A mi tampoco se me ocurre. Pero existe una clase que se llama usuarios, que tienen unas ideas distintas a las mías.
Y pasa que cuando descubren una función de anulación, les parece puede apañar problemas que han tenido, digamos que el ratón se ha ido al mal sitio o el ordenador ha presionado la mala tecla o el café se ha vertido o cualquier razón me inventen (son muy ricos en eso), y resulta que les parece bien anular la factura sin pensar en cosas «informáticas» que les parecen chino austral. Y luego vendrán a pedir que se les arregle el programa de [censurado] que no funciona bien porqué no saber pasar la factura que se ha entregado al cliente. ¿Os suena de algo?
Y no me digáis que la función tiene que ser reservada al administrador o al supervisor: los supervisores también pueden tener ideas parecidas (o solo para dar la razón a los usuarios) si les parece razonable hacerlo, sin tener en cuenta las dichosas razones informáticas... Entonces sí debe ser reservada y/o tener doble validación, por supuesto que sí, pero esto no resultará ser una protección suficiente.

Dicho esto, si anulan una factura, la factura quedará como anulada en el SIF y no se podrá «rescatar» o «resucitar» el número. Un problema menos para mí.

[sglorka]

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