Los particulares en general están fuera del tema. Artículo 1 del proyecto de RDL del reglamento:
El reglamento de facturación también se aplica solo a los empresarios y profesionales, más los demás que tiene obligaciones respecto del IVA (que no será el caso de de los clases particulares según entiendo).
Los taxistas y los food trucks entiendo que sí entren.

Una cosa es la factura simplificada (ticket). Cómo lo has explicado antes, y he concurrido, esta es lo que se debe declarar dentro del SIF o a VeriFactu, una por una.
Otra cosa es el resumen. Que si he entendido bien, no es una factura tal como lo entiende el reglamento de facturación (y por tanto no le toca Verifactu).
Pero en la contabilidad, no veo porqué no se podrá continuar haciendo lo mismo que antes, es decir registrar un solo asiento con un gran número de tiques. Ni ha cambiado el reglamento de facturación, ni las normas de contabilidad.
Después, a ver cómo se articula el puente entre el SIF y la contabilidad en este caso... en cada programa sería cosa distinta, creo.

Para los del SII, no veo por qué el asiento resumen (F4) pasaría a ser prohibido, y los tiques deberían ser registrado exclusivamente como un montón de facturas F2 independientes. No veo el interés de Hacienda en pedir esto; pero sí veo inconvenientes (tamaño de bases de datos, ancho de banda, puntos de extremo, tiempo de respuesta, necesidad de más alta disponibilidad; todo esto cuesta dinero).

Leyendo el papel asignado al consumidor final en el proyecto de RDL, se ve que la idea es incentivar a remitir [las facturas] a la Administración tributaria para asegurar el cumplimiento tributario de los obligados a su emisión. Luego es Hacienda (no el consumidor) que tiene la potestad de controlar si está registrado correctamente o no.

La dificultad en este punto es que el proyecto de RDL no preveía, al menos no explícitamente, el hecho que los del SII estén excluidos en practica de su aplicación. Al día de hoy (realmente desde las modificaciones de junio), entiendo que las facturas en papel de los del SII no llevarán QR; pero no he leído un conjunto concreto de cómo quedará en 2024.

Sigo con el mismo tema (disculpadme). Estaba pensando en una clase de solución.
El reglamento pone condiciones a los SIF para las facturas... pero no obliga que sigan exclusivamente para estas facturas españolas. Por ejemplo, no veo por qué un mismo programa no se pudiera usar al mismo para las facturas españolas conformas al SIF, y también para facturas conformas a otras normas, posiblemente TicketBAI (me arriesgo un poco aquí), o los recibos de la agricultura, o «facturas» que respondan a normas de otros países.
O «facturas resumen de tickets» tal como lo estas usando.

Creo que lo que solo es preciso

• respectar las normas de un SIF, integridad, trazabilidad e inalterabilidad, también documentación (que realmente son imperativos informáticos que nos parecen básicos);
• encadenar de forma separada las facturas que esperan la Hacienda española (y deben informarse a Verifactu) de las que son excluidas del ámbito, y por tanto no deberán informarse (pero sí pueden generar registros)

¿Les parece un esquema posible?

En la documentación de Verifactu no está el tipo de factura F4 q si está en SII. Entiendo por tanto q con verifactu no se puede usar ese tipo de factura. Los del SII si los pueden seguir usando. Si estas en SII no tienes q hacer verifactu. Están excluidos.

Respuesta aeat/verifactu recapitulstivas
 

El concepto recapitulativa definitivamente no existe para verifactu, para ellos recapitulativa es una factura normal de una serie de servicios dentro del mismo mes y se declaran como factura normal, así que lo que yo entendíaa por recapitulativa de tiquets va a pasar a ser sustitutiva/canje.
Lo que sí haré es permitir hacer sustitutivas de varios tiquets(tal y como contemplan en el xml) pero no mezclar meses de tiquets para generar una.
Saludos
Saludos.

Hola a todos,

veo por los mensajes que no avanza mucho el tema (aún no hay servidores de prueba...)
Tengo una consulta acerca de la ley, afecta a los presupuestos, albaranes, pedidos,.... es decir, a otros documentos que no sean factura ?
Me refiero en cuanto a la trazabilidad, inalterabilidad de los registros...

muchas gracias

Yo creo que sólo facturación.
Para un pedido o una oferta no hay que hacer nada aquí.

Es más, yo me aventuraría a decir que ni con los albaranes hay problema de modificación. Todo lo que hablan se refiere a facturas/facturas simplificadas.

Saludos.

Tampoco afecta a las empresas que estén en Ticketbai-Batuz en las haciendas del Pais Vasco.
La semana pasada en un Webinar de Cebek lo pregunte a Subinspectores de la hacienda y así lo dijeron.

Solo las facturas son documentos legales con efecto fiscal. Por tanto esta ley y sus reglamentos no puede alcanzar los demás documentos.

Y ni siquiera afecta a la totalidad de la factura... el detalle de los facturado, costos, servicios, logística, reparto, cobros, cálculo de beneficios, trazabilidad sanitaria y demás tampoco tienen que comunicarse ni encadenarse... lo suyo es ceñirse a un fichero de facturas con los campos que son de obligado envío y dejar el resto de la información relativa a la factura fuera del proceso. (Esto es de mi cosecha... realmente no sé si querrán obligarte a que el detalle de lo facturado también esté bloqueado y encadenado).

Planteamiento de un sistema real
 

A continuación propongo un escenario real para discutir si el modelo planteado se ajusta al nuevo reglamento de facturación.

Nuestro SIF (sistema informático de facturación) está compuesto por dos programas distintos y geográficamente separados
- Un sistema de facturación central
- Un terminal punto de venta

Sistema de Facturación Central (SFC)

- Puede emitir documentos de entrega de bienes como albaranes que, posteriormente, serán recopilados en factura final de mes.
Por cada documento de entrega ( albarán ) NO se genera registro de facturación y pueden ser modificados, eliminados, etc hasta que se emita factura
ordinaria de estos, bien de forma individual o bien de forma recapitulativa.

- Puede generar facturas ordinarias sobre cuatro series distintas. Identificador Serie+Número (01-000001),(02-000001),(03-000001),(04-000001)
Por cada factura ordinaria se genera un registro de facturación

- Puede generar facturas simplificadas. Identificador Serie+Número (05-000001)
Por cada factura simplificada se genera un registro de facturación

- Puede generar facturas rectificativas sobre 4 series distintas (una por cada serie de facturación). Identificador Serie+Número (06-000001),(07-000001),(08-000001),(09-000001)
Por cada factura rectificativa se genera un registro de facturación

- Puede anular cualquier tipo de factura
Por cada anulación se genera un regitro de anulación.

Terminal Punto de Venta (TPV)

-Puede emitir documentos de entrega de bienes como albaranes que, posteriormente, serán recopilados en factura final de mes por el SFC.
Por cada documento de entrega ( albarán ) NO se genera registro de facturación y pueden ser modificados, eliminados, etc hasta que se emita factura
ordinaria de estos, bien de forma individual o bien de forma recapitulativa por el SFC.

- Puede generar facturas ordinarias. Identificador (NmáquinaSerie)+Número (9901-000001)
Por cada factura ordinaria se genera un registro de facturación en el TPV

- Puede generar facturas simplificadas. Identificador (NmáquinaSerie)+Número (9902-000001)
Por cada factura simplificada se genera un registro de facturación en el TPV

- Puede generar facturas rectificativas. (NmáquinaSerie)+Número (9903-000001)
Por cada factura rectificativa se genera un registro de facturación en el TPV

- Puede anular cualquier tipo de factura
Por cada anulación se genera un regitro de anulación.

El SFC recolecta todos los documentos emitidos por el Terminal Punto de Venta.
- En el SFC, los albaranes recibidos del TPV, pueden ser modificados y eliminados cuando proceda. En el momento de emitir la factura, se generará el registro
de facturación correspondiente en el SFC
- En el SFC, se puede crear facturas rectificativas por diferencia o sustitución de cualquier documento emitido por el TPV

En resumen:
Nuestro SIF tiene dos líneas de registros de facturación.
- Una línea creada por la emisión de documentos en el SFC
- Otra línea creada por la emisión de documentos en el TPV

En la línea de registros de facturación de SFC existen operaciones de rectificación de documentos emitidos por el TPV
En la línea de registros de facturación de SFC existen facturas recapitulativas de albaranes de entrega emitidos por el TPV.

Sin problema, supngo que lo sabrás, no tienes que mandar albaranes y tampoco tienes que indicar que albaranes pertenecen las facturas,.
Esos escenarios no tienen nada fuera de la línea de verifactu.

Escenario Verifactu
 

Gracias por tu respuesta. Este escenario es bastante común, lo importante es que debe ser el TPV el que genere su propio línea de registros de facturación. Es decir, si tenemos tablets de venta, tpvs, etc.. cada dispositivo que emite una factura debe generar sus registros. Luego el sistema central puede operar con los documentos recibidos y facturarlos, sustituirlos, rectificarlos, etc..
Al final, un SIF puede tener bastantes líneas de registros para comunicar a la aeat
Saludos

La comunicación es otro cantar, y el encadenamiento cuando hay varios dispositivos aún está pendiente de que nos indiquen muchos detalles, hay muchas formas de guardar los registros, por ejemplo yo tengo varios pdas taboets e incluso tpvs satélites en la en la misma maquina
Y hago el encadenamiento del conjunto, bloqueo cuando se está grabando y me aseguro que no ocurran inconsistencias. Pero a ver que dicen.
Por otro lado el envío si tendrás que hacerlo en FiFO por que en el envio te devolverán errores de encadenamiento, si los hubiera, y si no lo has hecho en orden secuencial vas a tener errores.

Uff. Veo un poco temerario ese planteamiento. Quieres decir que cada dispositivo comparte la misma línea de registros de facturación ?. No te parece más simple que cada dispositivo genere su línea de registros y sea el encargado de comunicarlos a la aeat?. Ten en cuenta que si tienes un dispositivo en remoto, necesitarás comunicación online para poder generar el registro de facturación antes de emitir la factura. Si se trata de una factura simplificada a cliente de contado, ésta se debe emitir de inmediato. No sé, lo planteo para ver que ideas surgen
Saludos

Para generar la factura no hace falta tener conexión a internet, solo es necesario a la hora de enviarlo. Se pueden generar en un dispositivo y luego enviarlo desde otro.

Un Saludo.

No me he explicado.
Me refiero a que si tienes un terminal remoto que emite una factura y solo dispones de una línea de facturación compartida, el terminal remoto deberá, de alguna manera, crear dicho registro de facturación en dicha línea compartida (recuerda que el registro de facturación se debe generar antes o de forma simultánea a la emisión de la factura), que imagino, estará en su servidor central. Por eso decía, que el terminal remoto debe de estar en online con su servidor central para crear su registro de facturación. Después algún proceso se encargará del envío a la aeat.

En TicketBAI, si los dispositivos que facturan no estan conectados, se debe generar una serie distinta por cada dispositivo y realizar el encadenamiento por cada serie en ese dispositivo.

Un Saludo.

Tengo el circuito bien cerrado. Es un programa de escritorio en Red local., varios dispositivos graban en wl mismo tpv principal y tiene 1 programa (en segundo plano) que se encarga de los envíos, cada vez que un dispositivo grabqa bloquea y los demás dispositivos si intentan grabar un registro, se quedan en bucle unas centésimas de segundo para poder grabar y comprueba la secuencia, todos siguen los mismos numerador3s de serie(los comparten.lleva unos meses en prueba y va bien, ya estoy enviando a un cloud propio.