Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[antoine0]

Empezado por keys

parece que no quieren que nos vallamos de vacaciones.

No sé por qué, lo veo más bien como que alguien ha conseguido a poner en línea una versión 0.1 justo antes de sus propias vacaciones (toda semejanza con eventos pasados del querido lector sería, evidentemente, mera coincidencia).

[ermendalenda]

He echado un primer vistazo y parece mucho más fácil que ticketbai, pero veo alguna incongruencia en el encadenamiento con las anulaciones que tendrán que aclarar, al ser una versión borrador supongo que habrá muchos cambios.
En cuanto al encadenamiento de la anulaciones se encadenan con la factura anterior y el hash anterior, pero teniendo en cuenta que una anulación no genera un muevo número de factura se crea un problema al generar 2 anulaciones seguidas, ya que hay una incertidumbre sobre si se repite la secuencia de encadenamiento. Esto es raro tendrán que corregirlo, y me temo que nos obliguen a crear un número especial de serie para las anulaciones, aunque eso no está en la normativa de facturación.
Por otra parte leo que los registros erróneo se podrán corregir y volver a enviar, pero ahí veo que falta mucho por explicar, ya que las facturas rechazadas rompen encadenamiento y al volverla a enviar ya no se envian en la misma secuencia, ni de encadenamiento, ni de número de factura, no se si hay que enviarlo de otra f9rma a otro servicio o seguir por el encadenamiento que va en ese momento...
O han explicado poco o le falta mucho curro básico o como es lógico ambas cosas.

[ermendalenda]

Ahora solo falta empezar a subir ejemplos con los curros que vayais/mos haciendo

[keys]

Mirando un poco los ficheros, mi primera valoración es la siguiente.

- Es muy parecido a TicketBAI y al SII pero con menos información (De momento), solo se refiere a totales.


- En cuanto a la información de IVA, el tipo de operación del SII, en el campo "DESGLOSE" que se repite de 1 a 10, que parece mas "sencillo" que en el SII y TicketBAI. No hay que desglosar a nivel de factura/operación. Espero que hayan calculado todas las combinaciones posibles.

Entiendo que hay menos información ya que el hacer esto no exime de hacer del SII u otras declaraciones como TicketBAI/BATUZ. Si haces el SII de exime de hacer Verifactu, en TicketBAI es al revés, si estás dentro de TICKETBAI/BATUZ te exime de hacer el SII (ventas en Gipuzkoa/alava) y en bizkaia si estas dentro de BATUZ te exime del SII, 347, etc y en un futuro de calcularan el iva e incluso sociedades/renta.

- El encadenamiento tiene pinta de ser igual que en TicketBAI.

- El campo IdSistemaInformatico me hace sospechar que va a ser como TicketBAI, va a ser un número que te van a dar a cada empresa de software que entre el sistema/ se homologue/ registre ¿?.

- El campo NumSerieFacturaEmisor, sigue teniendo Nº Serie+Nº Factura como en el SII. En TicketBAI lo han desglosado en 2 campos Serie y Numero.

[antoine0]

Empezado por ermendalenda

En cuanto al encadenamiento de la anulaciones se encadenan con la factura anterior y el hash anterior, pero teniendo en cuenta que una anulación no genera un muevo número de factura se crea un problema al generar 2 anulaciones seguidas, ya que hay una incertidumbre sobre si se repite la secuencia de encadenamiento

No te sigo.
Ejemplo de orden tal como aparece en el libro de facturas:

1. factura 22012 del 14/7
2. factura 22013 del 14/7
3. se anula la factura 22012
4. se anula la factura 22013
5. factura 22014 del 14/7 (nota: es la 22012 corregida)
6. factura 22015 del 14/7 (nota: es la 22013 corregida)

Evidentemente, están enlazadas entre sí; en concreto, la 3 (una anulación) recoge la huella de la anterior 2; la 4 (otra anulación) recoge la huella de la 3; y la 5 (una alta) recoge la huella de la 4, una anulación.

Ahora bien, a la hora de subir las facturas, Hacienda nos pide de separar las altas y las anulaciones.
Para evitar problemas de indeterminación, creo que se debe subir primero las altas 1 y 2, luego las bajas 3 y 4, y finalmente las altas 5 y 6.

Fíjate que en el borrador de febrero los registros aparentemente no tenían (artículo 11) de huellas propias; pero esto se ha subsanado en el PDF de julio, página 12/15.

[ermendalenda]

Empezado por antoine0

No te sigo.
Ejemplo de orden tal como aparece en el libro de facturas:

1. factura 22012 del 14/7
2. factura 22013 del 14/7
3. se anula la factura 22012
4. se anula la factura 22013
5. factura 22014 del 14/7 (nota: es la 22012 corregida)
6. factura 22015 del 14/7 (nota: es la 22013 corregida)

Evidentemente, están enlazadas entre sí; en concreto, la 3 (una anulación) recoge la huella de la anterior 2; la 4 (otra anulación) recoge la huella de la 3; y la 5 (una alta) recoge la huella de la 4, una anulación.

Ahora bien, a la hora de subir las facturas, Hacienda nos pide de separar las altas y las anulaciones.
Para evitar problemas de indeterminación, creo que se debe subir primero las altas 1 y 2, luego las bajas 3 y 4, y finalmente las altas 5 y 6.

Fíjate que en el borrador de febrero los registros aparentemente no tenían (artículo 11) de huellas propias; pero esto se ha subsanado en el PDF de julio, página 12/15.

En el camppnde encadenamiento de cada factura enviada tienes que poner efectivamente el número de la anterior, pero las 2 anulaciones 3 y 4 carecen de número de factura, los números 3 y 4 son num3r9s correlativos que has puesto por seguir un orden, pero no es el número que piden. El encadenamiento tampoco es el número de factura que se anula eso es otro campo, en principio veo esos 2 errores de blockchain, el de las anulaciones y el de las repeticiones de envíos. Esperemos que lo aclaren

[ermendalenda]

Además yo puedo anular primero la factura 2 y después la factura 1, por qu3 es una situación bastante probable. Y además en ese orden y seguidas con lo cual veo un pequeño lío que las anulaciones lleven encadenamiento, en ticketbai no encadenan las anulaciones por este inconveniente, cualquier parche que intenten hacer para encadenarlo complican la situación.

[ermendalenda]

He visto el último campo <incidencia\>
En el que habrá que informarle de las facturas enviadas cuando hay fallos informáticos... supongo que tb vale para indicar el reenvio de las rechazadas, pero me sigue quedando la duda de los encadenamientos en estos casos, se informan?
Esta claro que cuando hay una factura rechazada implica una rotura de encadenamiento en la siguiente factura, pero eso no sdebe sumar un fallo más.

[ermendalenda]

No veo la estructura eel dato del QR, aunque es de suponer que llevará parte del hash generado seria un alivio si no fue4a así, ya que eso permitiría enviar las facturas con otro software/api sin que tengan una comunicacion bidireccional y sincrons, pero claro volveríamos a dejar puertas abiertas para fraudes. En resumen es seguro que en el QR vaya parte del hash y que por ende el xml lo generemos nosotros o haya una comunicación bodorecc9onnal con una api/dll/servicio res aue nos devuelva losdatos que tenmos que poner en la factura...

[antoine0]

Empezado por ermendalenda

En el camppnde encadenamiento de cada factura enviada tienes que poner efectivamente el número de la anterior, pero las 2 anulaciones 3 y 4 carecen de número de factura, los números 3 y 4 son num3r9s correlativos que has puesto por seguir un orden, pero no es el número que piden. El encadenamiento tampoco es el número de factura que se anula eso es otro campo, en principio veo esos 2 errores de blockchain, el de las anulaciones y el de las repeticiones de envíos. Esperemos que lo aclaren

Efectivamente, los números de registros del 1 al 6 no son números de facturas; estos son, respectivamente, 22012, 22013, 22012, 22013, 22014 y 22015; las referencias a anteriores serían estos números, junto con el NIF del emisor, sus fechas, aquí 14/7, y sus respectivas huellas.
Resulta entonces en mi ejemplo que el registro 4 lleva el mismo número de factura que el registro 2, también mismo emisor, y también misma fecha de emisión de la factura; pero no la misma huella.
Realmente para realizar el encadenamiento, con solo la huella es suficiente (asumiendo que SHA256 es una función de hash perfecta). Las demás informaciones sobran, o mejor dicho son redundantes (y sabemos que estas redundancias ayudan y mucho al rendimiento).

Si resulta confuso, me parece hasta lógico, dado que en un diseño inicial, no había encadenamiento de los registros de anulación, esto se ha añadido en un segundo tiempo. No sé por qué, pero puedo ver dos razones:

• hay una posibilidad de fraude anulando registros, por ejemplo en relación con problemas con el sistema de llevar estos registros a Hacienda
• en practicas habituales, los registros de anulación serían mezclados con los registros de alta (por ejemplo tal como se ve si se mira empezando desde la contabilidad); sería por tanto el resultado del retorno de los editores de software

[keys]

Empezado por antoine0

Efectivamente, los números de registros del 1 al 6 no son números de facturas; estos son, respectivamente, 22012, 22013, 22012, 22013, 22014 y 22015; las referencias a anteriores serían estos números, junto con el NIF del emisor, sus fechas, aquí 14/7, y sus respectivas huellas.
Resulta entonces en mi ejemplo que el registro 4 lleva el mismo número de factura que el registro 2, también mismo emisor, y también misma fecha de emisión de la factura; pero no la misma huella.
Realmente para realizar el encadenamiento, con solo la huella es suficiente (asumiendo que SHA256 es una función de hash perfecta). Las demás informaciones sobran, o mejor dicho son redundantes (y sabemos que estas redundancias ayudan y mucho al rendimiento).

Si resulta confuso, me parece hasta lógico, dado que en un diseño inicial, no había encadenamiento de los registros de anulación, esto se ha añadido en un segundo tiempo. No sé por qué, pero puedo ver dos razones:

• hay una posibilidad de fraude anulando registros, por ejemplo en relación con problemas con el sistema de llevar estos registros a Hacienda
• en practicas habituales, los registros de anulación serían mezclados con los registros de alta (por ejemplo tal como se ve si se mira empezando desde la contabilidad); sería por tanto el resultado del retorno de los editores de software

Yo no veo que las facturas de anulación tengan encadenamiento. Yo interpreto que el campo EncadenamientoFacturaAnterior de la anulación se refiere a lo mismo que tiene la factura original.

Factura 1
Factura 2 -->Factura anterior es la 1
Factura 3 -->Factura anterior es la 2
Anulo Factura 2 --> Sin encadenamiento Pongo los datos de la factura 2
Factura 4 -->Factura anterior es la 3

Sino es una locura. El tiempo lo dirá

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

Empezado por keys

Yo no veo que las facturas de anulación tengan encadenamiento. Yo interpreto que el campo EncadenamientoFacturaAnterior de la anulación se refiere a lo mismo que tiene la factura original.

Pues yo estaba pensando más o menos lo mismo.
Una anulación NO ES UNA FACTURA como tal, sino que es una operación sobre una factura anterior.

Una anulación no tiene SERIE (por lo dicho anteriormente). Por lo tanto cuando habla de EncadenamientoFacturaAnterior, que incluye NumSerieFacturaAnterior, me hace pensar que son datos de la original que estamos anulando, no de la anterior anulación.
En concreto dice: Nº Serie+Nº Factura que identifica a la factura anterior; No tiene sentido que hable de la anterior anulación (creo).

Esto coincide con lo que se hace en TicketBAI.

[antoine0]

Empezado por keys

Yo no veo que las facturas de anulación tengan encadenamiento.

Presentación del 21/6 (qué has anunciado, gracias por ello), página 12/15

Registro de facturación de anulación (artículo 11.2):
> Se incluye el encadenamiento de huellas sobre el registro de facturación anterior, sea este de alta o de anulación.

Son los registros, sigan de alta o de anulación, que se encadenan.
De hecho, en mi experiencia del SII, he llegado (a mi gran sorpresa) a la conclusión que para una misma factura inicial en mi sistema, podía tener más de 2 registros en el S.I.I.

1. el primero es siempre una alta, tipo A0 en S.I.I.
2. aquí puedo tener que hacer una corrección de forma, con un registro tipo A1
3. luego digamos que hay que dar el registro de baja, por ejemplo porqué hay equivocación en la contrapartida: nuevo registro, esta vez de anulación («baja» en S.I.I.)
4. luego doy de alta nuevamente la factura, con la contrapartida corregida; otra vez un registro de tipo A1

No hay equivalente a los registros de tipo A1 en el nuevo reglamento; pero tengo la sensación que los «registros de alta» pueden ser más de uno para un determinado número de factura (dentro de una serie), con la condición que el número de registros de anulación (para el mismo número de factura) siga el mismo o uno menos; dicho de otra forma, no he visto aún que no se pudiera resucitar una factura después de ser anulada; o siga, que se pudiera efectivamente modificar el contenido de una factura (remplazando UPDATE por DELETE más INSERT).
Y estoy leyendo el preámbulo (no normativo) del proyecto de reglamento de febrero dice, página 12:

Cualquier necesidad de rectificación o anulación de los datos registrados deberá ser realizada mediante al menos un registro de facturación adicional posterior, de forma que se conserven inalterables los datos originalmente registrados

Pero ahora estoy seguramente estirando demasiado el hilo de las suposiciones.

Y sí, choca con mis ideas predeterminadas sobre cómo construir una facturación; pero de la misma manera choca el hecho que el respecto a ciertas condiciones de forma (importes, determinación de la contrapartida) preexiste a la obtención de un nuevo número de factura: yo siempre he programado la reservación del número de factura antes de validar el detalle de los importes; y esto lo tengo que cambiar sí o sí...