Cita:
Empezado por rfernandez
La duda es que como hay la obligación de imprimir el código QR para la trazabilidad Verifactu deducimos que cada tíquet, factura simplificada, debe llevar su QR por lo que se deben reportar a Verifactu todas los tiquets, facturas simplificadas, aunque sabemos que no hace falta reportar una a una sino que se pueden reportar en bloque.
|
Cita:
Empezado por Sistel
Lo primero que debes tener en cuenta es que cada ticket generado (actualmente los "tickets" se llaman facturas simplificadas) debe ser tratado de forma individual.
Debe incluir su código QR y debe ser enviada su información, de forma inmediata (nada más generarse) al sistema Verifactu de la Agencia Tributaria.
Ya sé que esto romperá tus esquemas pensados para agrupar los tickets de cada día y procesarlos después. Pero es lo que hay.
Cada "ticket" es una factura simplificada individual. Y debe ser tratada de forma inmediata.
|
Una puntualización a lo que dice [sistel] y podemos comentarlo si estoy equivocado.
Como bien dice, los tickets se tratan
a nivel Individual, cada uno con su QR y su registro de facturación,
pero el envío puede ser agrupado (o eso creo yo). Es decir, puedes hacer un envío de n Registros de facturación juntos.
Es más, hay que tener el sistema previsto para hacerlo así, porque la AEAT tiene previsto que en momentos de saturación, te puedan obligar a esperar "t" segundos o que el envio tenga como mínimo "n" registros.
Concretamente el esquema de funcionamiento segun la documentación es este:
2. Los sistemas informáticos «VERI*FACTU» deberán implementar un mecanismo de control de flujo basado en el tiempo de espera entre envíos, el cual tomará inicialmente el valor de 60 segundos, y en el número máximo de registros admitidos en cada envío.
Los mensajes de respuesta de la Agencia Estatal de Administración Tributaria informarán sobre el valor de este parámetro, el cual deberá ser tenido en cuenta para el siguiente envío.
El número máximo de registros a remitir en cada envío queda determinado por el diseño de registro incluido en el apartado 2.2 del anexo.
El funcionamiento será el siguiente:
a) El sistema informático realiza el envío del primer conjunto de registros de facturación a la Agencia Estatal de Administración Tributaria.
b) La Agencia Estatal de Administración Tributaria devuelve, entre otros datos, un valor actualizado del parámetro de tiempo de espera «t» entre envíos.
c) Para poder realizar el siguiente envío, el sistema informático deberá esperar a que transcurran «t» segundos desde el anterior envío o deberá esperar a tener acumulados un número de registros de facturación igual al límite establecido en el diseño de registro para cada envío, la circunstancia que ocurra primero.
d) El sistema informático realiza un nuevo envío cumpliendo con lo establecido en la letra c). En la respuesta puede recibir una nueva actualización del valor del parámetro «t»
Es decir, puede decidir enviar registros de forma individual (nosotros lo hacemos así porque nuestras empresas no generan tickets y el volumen ens más pequeño), pero también puedes hacer
envíos agrupados de hasta 1000 registros. Y aunque nosotros no lo hagamos, nuestro sistema debe estar preparado par ello.
En este documento lo tienes todo explicado:
https://terawiki.clubdelphi.com/Otro...Web_v0.3.0.pdf
6.3.1.1.Mecanismo de control de flujo.
6.4.2. Respuesta de alta y anulación de registros de facturación.
Todos los registros de facturación de la remisión tienen estado “Correcto”.
Ya asume que puedes enviar N registros en un envío de Alta o Anulación
3.Esquema general de funcionamiento.
...
El número máximo de registros por envío es de 1.000.
La unidad de información, representada por un registro de facturación, podrá ser
aceptada, rechazada o aceptada con errores, consecuencia de las validaciones que se
realizan en el momento de la remisión.