Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[antoine0]

Empezado por ermendalenda

[...] ya que es raro que vayas a un comercio y tenga el qr en la factura y otros no, lo cual, pposiblemente, provocaría continuas denuncias/sospechas...

Efectivamente.

También me parece raro que el QR conforme a TicketBAI fuese distinto del QR que aparezca en las facturas «SIF» de los demás comunidades.

Sin pensar en los SIF del reglamento que deben cumplir TicketBAI, y por tanto las facturas llevarían dos QR

[Sistel]

Empezado por antoine0

Efectivamente.
También me parece raro que el QR conforme a TicketBAI fuese distinto del QR que aparezca en las facturas «SIF» de los demás comunidades.
Sin pensar en los SIF del reglamento que deben cumplir TicketBAI, y por tanto las facturas llevarían dos QR

Hola antoine0,

En España hay 5 Haciendas diferentes: Álava, Bizkaia, Gipuzkoa, Navarra y Agencia Tributaria.

Si una empresa o autónomo tiene su domicilio fiscal en una de las provincias del País Vasco (Álava, Bizkaia o Gipuzkoa) sus obligaciones fiscales son con la Hacienda Foral de esa provincia.

Entiendo que si hace todas sus declaraciones fiscales (o su SII, si le corresponde) a su Hacienda Foral (y no hace declaraciones a la Agencia Tributaria estatal), sólo tendrá que cumplir con TicketBAI (o con Batuz si es de Bizkaia), que es la normativa que le impone su Hacienda Foral.

Saludos

[keys]

Hola a todos.

Han publicado cositas nuevas, parece que no quieren que nos vallamos de vacaciones.

https://www.agenciatributaria.es/AEA...ERI_FACTU.html

[ermendalenda]

Empezado por keys

Hola a todos.

Han publicado cositas nuevas, parece que no quieren que nos vallamos de vacaciones.

https://www.agenciatributaria.es/AEA...ERI_FACTU.html

Si no me equivoco, parece que los xmls son de totales, no hay que hacer desglose de los productos/servicios y solo hay que desglosar por tipo impositivo.

[antoine0]

Empezado por ermendalenda

Si no me equivoco, parece que los xmls son de totales, no hay que hacer desglose de los productos/servicios y solo hay que desglosar por tipo impositivo.

No puede imaginarlo de otra manera. Piensa en una factura de centenares de líneas en cualquier moneda que no siga euros, cada una con sus asociados descuentos: para poner une ejemplo: BTL, una moneda que va con 8 dígitos detrás de la coma. Si se debería subir todas las líneas en el XML, según la lógica de Hacienda debería todo en EUR; el resultado será muy probablemente imposible de controlar por los redondeos.
Pero con solo los totales en euros, se queda en una cosa manejable.

[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

[antoine0]

Empezado por keys

Han publicado cositas nuevas

Hay una cosa que no entiendo; pero supongo que la problemática será la misma que para TicketBAI:
Es el caso de enviar que una sola vez varias registros, algunos válidos y otros inválidos (tal como lo determine Hacienda).

Los primeros (siguiendo el orden del encadenamiento) que sigan válidos, no hay problema.
Pero a partir del primero (siempre en el orden de encadenamiento) que es inválido y por tanto rechazado y debe ser presentado de nuevo más tarde, creo que todos los demás («siguientes») que siguen no pueden ser aceptados: ¿es así con TicketBAI (suponiendo ciegamente que se puede enviar varios registros de una vez)?

Si se aceptan uno de los siguientes, existirá en la base de los registros aceptados, sin que su antecesor existe; en este punto, ya no se puede averiguar la validez del encadenamiento.
Por mucho que se supone que estamos en una situación supuestamente temporal que se debe subsanar, no me parece un estado aceptable para cualquier sistema.
Y luego está el punto que si se cambia cualquier contenido del registro, la huella debe cambiar y por tanto todos los registros siguientes también.

Otra vez supongo que estos casos ya se han visto con TicketBAI, y habrá resultados de discusión que expliquen lo que hay que hacer; pero yo soy muy perezoso, y no me he leído los 3200 mensajes del hilo.

[keys]

Empezado por antoine0

Hay una cosa que no entiendo; pero supongo que la problemática será la misma que para TicketBAI:
Es el caso de enviar que una sola vez varias registros, algunos válidos y otros inválidos (tal como lo determine Hacienda).

Los primeros (siguiendo el orden del encadenamiento) que sigan válidos, no hay problema.
Pero a partir del primero (siempre en el orden de encadenamiento) que es inválido y por tanto rechazado y debe ser presentado de nuevo más tarde, creo que todos los demás («siguientes») que siguen no pueden ser aceptados: ¿es así con TicketBAI (suponiendo ciegamente que se puede enviar varios registros de una vez)?

Si se aceptan uno de los siguientes, existirá en la base de los registros aceptados, sin que su antecesor existe; en este punto, ya no se puede averiguar la validez del encadenamiento.
Por mucho que se supone que estamos en una situación supuestamente temporal que se debe subsanar, no me parece un estado aceptable para cualquier sistema.
Y luego está el punto que si se cambia cualquier contenido del registro, la huella debe cambiar y por tanto todos los registros siguientes también.

Otra vez supongo que estos casos ya se han visto con TicketBAI, y habrá resultados de discusión que expliquen lo que hay que hacer; pero yo soy muy perezoso, y no me he leído los 3200 mensajes del hilo.

Cuando una factura es rechazada en TBAI, esta lógicamente no se puede modificar y volver a enviar al sevicio de TicketBAI, ya que esta produciría una modificación en todas las siguientes. Lo que hay que hacer es enviarlas a un servicio distinto que TicketBAI, (Zuzendu Gipuzkoa, Araba) (Software no Garante BIZKAIA).

[antoine0]

Empezado por keys

Cuando una factura es rechazada en TBAI, esta lógicamente no se puede modificar y volver a enviar al sevicio de TicketBAI, ya que esta produciría una modificación en todas las siguientes. Lo que hay que hacer es enviarlas a un servicio distinto que TicketBAI, (Zuzendu Gipuzkoa, Araba) (Software no Garante BIZKAIA).

Gracias. Por tanto aquí hay una diferencia bastante importante de comportamiento después de recibir un rechazo (a nivel de registro).

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

Empezado por keys

Han publicado cositas nuevas, parece que no quieren que nos vallamos de vacaciones.

https://www.agenciatributaria.es/AEA...ERI_FACTU.html

Gracias por el aviso.
Actualizado el pimer mensaje con la fecha y los enlaces.