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.

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

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.

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.

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

El dato del QR no tiene que ir en el fichero xml de factura, este es un codigo que se pondrá en la factura impresa. Y se obtendrá a partir de ciertos datos del fichero. O por lo menos así es en TBAI.

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 el aviso.
Actualizado el pimer mensaje con la fecha y los enlaces.

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.

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

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

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á

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.

Se produce una anomalia meter 2 veces el mismo dato, en fin tendrán que aclararlo

Parece q se quiere encadenar las anulaciones con la anterior como cualquier otra factura.

El encadenamiento incluye esto:



Este encadenamiento, a priori, no puede referirse a la anterior "anulación", porque la "anulación" no incluye ni serie ni número.

Los campos serie y número de factura de una anulación (según la documentación) son los de la "factura anulada".

De todas formas, al igual que en TicketBAI, a medida que vayan contestando dudas y si sacan un "Preguntas/Respuestas frecuentes" iremos aclarando estas cosas.
En algún momento también (que no lo he visto hasta ahora) habilitarán un buzón o una dirección de correo para poder enviar dudas.

De acuerdo con Neftali. Actualmente mi ERP y mi Contabilidad están en ejecutables y bases de datos diferentes. Una vez emitida una factura, se duplica la información con relevancia fiscal en la contabilidad. El usuario no puede "borrar" facturas, pero puede marcarla como "Anulada" (se queda el registro de la factura pero sin peso logístico, financiero, estadístico ni fiscal). Al marcar una factura como anulada el registro queda, aunque en el sistema contable esa factura sí se borra físicamente del libro de IVA, por que a efectos fiscales deja de existir.
Imagino que el que las altas y las anulaciones se hagan con mensajes diferentes es relativo a esto. Una anulación lanza una marca contra la factura originalmente subida para que esa misma factura conste como NO-VALIDA, pero realmente no se está emitiendo una "Factura Rectificativa".

Hablando de Facturas Rectificativas, el modelo diferencia entre dos tipos de rectificaciones: Por sustitución o por diferencia... Creo entender que :

a) Por sustitución creo que se refiere a emitir una factura nueva (nueva serie, numero, fecha, importe....) que sustituye a una factura previamente enviada, con lo cual sería un proceso equivalente a lanzar una anulación de la primera, y una nueva alta de la segunda, pero en un sólo paso... ¿Lo entendéis así?. El cliente que recibe la factura sustitutiva debería destruir y/o borrar la primera y declarar sólo la segunda... pero corremos el riesgo de que el cliente mande a su gestor las dos facturas (tendrán numeración diferente, y las facturas recibidas no se transmiten a Hacienda)

b) Por Rectificación... se refiere a que emito una nueva factura con importe que se suma o resta a la factura anterior. Es decir, las típicas facturas de devolución de mercancía, o abonos por error en precios, cambio de titular... las dos facturas quedan como válidas y el cliente abonará y registrará ambas facturas.

Otra cosa: El envío por bloques... parece ser que cada vez que envías un registro de factura, Hacienda te dirá cuando y cuantas facturas tienes que enviar en la siguiente comunicación, y normalmente será: Una sola factura y en el momento que se haga.... aunque te pueden decir que envíes hasta 1000 facturas o las que hayas generado en un máximo de 2 horas.... y tendrás que atenerte a suministrar el siguiente XML como lo piden, (aclaran que lo normal será el envío de cada factura individualmente). Esto quitaría el problema de los encadenamientos en caso de facturas rechazadas, ya que se podría parar de enviar facturas cuando una no cuela. ¿pero hasta cuando puedo parar el servicio de envío? En los clientes que tengo que están sujetos al SII no paran de tener problemas con NIF mal identificados... sobre todo si las altas de los clientes las hacen los propios clientes vía web, hay muchos reacios a meter datos identificativos válidos.. o comerciales que crean clientes en sistemas móviles, y ponen el NIF, CIF, NIE como le parecen (sin la letra, números cambiados, demasiado largos o cortos...) Luego toca a los administrativos localizar y rectificar ese datos para poder subirlas al SII, pero a veces tardan hasta 3 y 4 días en arreglar una factura que tenga un error de este tipo. Puede ser este fallo, o cualquier otro... si una factura está mal, parará el envío de las siguientes hasta que no esté bien, pues no se puede generar la huella para la siguiente factura.... ¿Esto entendéis que debe ser así?.

Ultima cosa en cuanto al SII: Se supone que un SIF debe obligatoriamente enviar las facturas, es decir, no puedo tener un programa de TPV en un cash o supermercado que esté emitiendo facturas (simplificadas o no) y que de forma asíncrona (o síncrona) las envíe a un servidor que cuando le parece, proceda a subir estas facturas a Hacienda. Bastaría que un TPV lo desconecten de la red para que esas facturas no vayan a ningún lado. (Aclaro que en nuestro sistema, los TPV tienen capacidad de funcionar autónomamente tanto en datos como en suministro eléctrico, por si hay un apagón, caída de red, avería del servidor o actualizaciones de sistema, los lineales de supermercados puedan seguir facturando y cobrando a los clientes).

En un modelo normal (por lo menos para mí) cada cierto tiempo preestablecido (segundos, minutos u horas), los TPV vuelcan la información capturada al ERP y sincronizan sus datos maestros (artículos, precios y ofertas). Al final del día se produce el volcado de toda la facturas recogidas en el ERP a la base de datos contable. Al día siguiente, las facturas contabilizadas el día anterior se envían al SII a través de otro programa que está en un puesto de trabajo con Firma Digital instalada (no lo puede hacer cualquiera), y quedan pendientes las facturas con error para ser subsanadas y subidas a la mayor brevedad.

Ahora se supone que el envío lo tiene que hacer cada TPV en cuanto se genera la factura, a no ser que estés sujeto al SII, entonces podrás configurar los TPV para que no hagan envío y sigan el método normal para el SII... ¿no da pie esto a que se pueda configurar qué TPV envían facturas y cuales no? Yo no podría certificar ante hacienda que con mi programa es imposible hacer facturas que no se declaren, ya que incluso el no enviar las facturas puede deberse a fallos de hardware o de las propias comunicaciones (tener el puesto desconectado de la red y actualizar los datos con un pendrive).

*lo de las rectif8caciones por sustitución o por diferencias es como dices, y por ello a mi me gusta más por diferencias,.
No creo, ya que imagínate que estas en el escenario de envío de varias y te da error una intermedia.
Lo lógico, como en ticketbai, es que sigas enviando, aún con el encadenamiento roto, arregles y envíes la defectuosa cuando esté arreglada indicando en el último campo<incidencia>S</incidencia>
Pero queda la duda de si se envia encadenando de nuevo con la última enviada, que supongo que sí.
Lo de desconectar un tpv da igual, emitidas un qr que culaquier cliente qur lo escanea da la alarma de que no se ha enviado.