Discúlpame si te he entendido mal, pero voy a dar mi propia interpretación, basada en esta publicación de la Agencia Tributaria:

https://sede.agenciatributaria.gob.e...amentario.html

Allí dice claramente, que las letras a), b), c) y d) son de directa aplicación desde el 11 de Octubre de 2021, y que las letras e) y f) están pendientes del desarrollo reglamentario.
Por otro lado, yo también he hecho consultas a la AEAT, y en una de ellas, me contestan que, "aunque haya parcelas de mi Sistema Informático que estén pendientes de desarrollo reglamentario, para salvaguardar mi responsabilidad de desarrollador, debo abstenerme de realizar cualquier trabajo, modificación y/o corrección sobre programas que no cumplan esas 4 letras, de a) a d)". De hecho la frase exacta de la contestación es: Por tanto, a partir de dicha fecha solo pueden venderse sin incurrir en infracción, los productos que cumplan estas características.
Por último, utilizas la palabra intencionalmente en tu explicación como uno de los elementos necesarios para ser sancionado, que yo no he encontrado en ninguna de las publicaciones ni en el BOE, ni en Reglamento, ni en el RD, más bien al contrario pues la Ley dice "explicitamente" que la mera tenencia de sistemas que no cumplan con la Ley es motivo de sanción. Esto, a mi entender, significa que la AEAT se desliga de su obligación de demostrar que se está cometiendo una ilegalidad, y nos traslada a los desarrolladores esa responsabilidad, de modo que si un "obligado tributario" tiene instalados en sus ordenadores varios programas, y alguno de ellos no cumple la Ley, podría ser sancionado.

Un saludo.

Ya han publicado documento de PREGUNTAS y RESPUESTAS del seminario (webminar) sobre VERI*FACTU.
Descargable desde la web de hacienda y desde el FTP del club.

Actualizo el mensaje #1 recopilatorio de información.

Intencionalmente lo han usado como respuesta a una pregunta, supongo que para aclarar el concepto, ya que hay muchas normativas que se establecen y hasta que no haya desarrollo reglamentario no tienen apenas efecto, a veces no se hace el desarrollo reglamentario y por tanto la normativa queda olvidada.
De todas formas en las preguntas y respuestas del seminario podrás ver una pregunta al hilo del mismo escenario en el que estanos intentando aclarar y verás que lo que te he comentado en el post está reforzado por la respuesta que dan. Es cierto que el tema roza la ambigüedad en lss respuestas de la AEAT, pero mi interpretación es clara, que si cumples con el envío de la facturación, hasta que no haya otro desarrollo reglamentario, el resto de lo que tengas respecto a la contabilidad, no solo no les importa, además es que a efectos fiscales no vale para nada si no cuadra con lo enviado.
Pregunta
En la ley habla en algunos apartados de los procesos contables. Quiere decir que habría que llevar una auditoria contable en el caso de se modifique dicha información en contabilidad o que no sea posible alterarla?
RESPUESTA
El artículo 29.2.j) de la Ley General Tributaria aplica a los sistemas informáticos utilizados para dar soporte a los procesos contables, de facturación y de gestión, por lo que todos ellos están obligados a garantizar los 6 requisitos exigidos sobre los registros empleados (es decir, sobre la información y datos que maneja cada uno) y, por tanto, no permitir interpolaciones, omisiones o alteraciones de las que no quede la debida anotación en los sistemas mismos. Sin embargo, solo se concreta cómo cumplir con este mandato para el caso de la facturación, lo que se hace mediante el reglamento aprobado por el RD 1007/2023, que desarrolla los requisitos que se deben implementar en los sistemas informáticos de facturación para cumplir con el 29.2.j).

Hola como y cuando se supone que sería conveniente o la mejor opción para realizar la comprobación de la fecha del sistema, ¿En el momento que se va a confeccionar una nueva factura o serie de facturas? y ¿que se debería hacer, comprobar y comparar la fecha de la última factura y si la actual es anterior a la última marcar un error?

El sistema comprueba y se auto-asigna la fecha de Windows al entrar al mismo. Cierto que lleva una opción en la que se puede alterar la fecha de trabajo. Esta se hizo necesaria ya que si cambiamos de ejercicio y hay que hacer alguna operación en el ejercicio anterior con esta opción se cambiaba por ejemplo al 31/12/2023 y se podían entrar facturas de compra y realizar últimas ventas en el ejercicio anterior. El sistema no permite hacer estas operaciones en el ejercicio 2023 con fecha 02/01/2024.
¿Vosotros anularíais la opción de cambio de fecha de trabajo?
Venga gracias, a ver si me podeis orientar y echar un cable al respecto.

Tao y como comentaros los compañeros en post anterior4s y tal y como han r4spondido hacienda en el seminario, la fecha de operwxion de la factura puede ser anterior a hoy, no s8endo así con la fecha de wxpedicion, para ello disponemos de 2 nodos en verifactu con lo cual, yo veo conveniente controlar que no senpueda modificar la fecha del sistema de windows o del S.O que sea, comprobando contra un servidor de hora externo como el que puse. Como lo he hecho yo... si no coincide en más menos unos 4 min. No dejo hacer factura. Por otro lado si puedes dejar el campo fecha de operación abierto a fechas anteriores a la de hoy. Y la fecha de expedición la del sistema sin opciones a cambiarla.

A alguien le funciona los enlaces de los videos?

Por mi experiencia con los clientes en TicketBAI, recomiendo mirar la fecha en internet, ya que nos hemos encontrado con clientes listillos que para saltarse lo de la fecha de expedición cambiaban la fecha del sistema.

¿Qué enlaces?

Hola,

Nosotros también utilizamos para la fecha-hora de expedición de facturas, en TicketBAI, la fecha-hora de un servidor en Internet.
Fiarse de la honestidad de todos los clientes es jugársela.
Seguro que los hay que en cuanto se dan cuenta de que pueden cambiar la fecha-hora del sistema, hacen de las suyas para poder emitir las facturas con la fecha que quieran.
Hay que cerrar puertas a los "listillos", que siempre los hay.

Saludos

Estos https://www.agenciatributaria.es/AEA...actu_EEDD.html

Vale entiendo que se puede realizar una ultima factura a fecha de 31/12/2023 con fecha 02/01/2024, cuya fecha de factura constará como 31/12/2023 y fecha de expedidición 02/01/2024, siendo fecha de factura y fecha de expedición cosas distintas en verifactu. Por tanto como bien indicas dejo un margen de 4 minutos de diferencia entre la fecha del sistema y la obtenida de Internet para permitir o no realizar la factura. Por lo que creo que lo más lógico es ejecutar la comprobación en el momento de expedir la factura con el comando curl.exe (que indicaste en post anteriores y que tengo integrado) y comprobando desde el json generado.
Tenemos diferenciada en la aplicación la fecha de trabajo que es la que asigna la fecha y hora de factura y la fecha y hora del sistema que sería la que se asignaría a la de expedición de factura.

Gracias Ermendalenda

No.
A mi tampoco.
No deben haber puesto bien los links o no tenemos permisos.

Al principal deja acceder pero a parte.1, parte.2, etc no

Te recomiendo que dejes un parámetro a nivel de superusuario en la que puedas desactivar esa co probación, imagínate que falla el se4vidor de Internet y devuelve un dato erróneo y no dejas facturar. Así lo tengo hecho

Si, si por supuesto, seguire tu recomendación. Perfectamente podría pasar un fallo en el servidor horario.

Incidencia no recogida en reglamento
 

Buenas, voy a plantear otra duda a Veri*Factu que he visto que en las consultas la han planteado pero veo que hay que apretar un poco más.
La duda es sobre los registros que se pueden perder después de imprimirlo.
La respuesta de Veri*Factu es que el reglamento es claro de que no podemos imprimirlos hasta que se hayan grabado correctamente y el envio debe ser "inmediato", en el mismo seminario aclaran que lo de de inmediato es siguiendo el flujo, pero claro, el flujo depende de circunstancias que pueden ver alterada la inmediatez por Conexión lenta o por otras circunstancias.
Ejemplo Real que me ha pasado en 1 de más de 4.000.000 de tiquets en las que llevo hecha las pruebas, pero me ha pasado:
Genero ticket en papel.
Se corta la luz y se pierde el contenido de la caché que aún no se ha grabado en el disco y aún no se habia enviado a Veri*Factu por que el corte de luz hua sido inmediatamente al imprimirse. Y la impresión es más rápida que el envio, por tanto, hay un periodo de decimas de segundos en la que existe la posibilidad de que no se envie.
El desarrollador se compromete a que todo ha sido con el control de flujo establecido pero no puede controlar esa incidencia puntual en la que en ocasiones solo se puede detectar un cierre de programa fuera de control, pero al encender podemos haber perdido información irrecuperable, el siguiente registro podemos marcarlo como incidencia y encadenado con el anterior grabado correctamente, por que es lo que el programa puede saber.

Imagina que el receptor de la factura envia el QR pero yo nunca lo envio por que no lo tengo. Suelen ser importes pequeños pero he roto el flujo de encadenamiento correcto.
Culpa: Hardware
Solución: Tendrían que obligar a usar equipos con posibilidad de usar baterias de caché, por lo tanto encarecimiento del hardware, pero eso es otro cantar que no tiene nada que ver con los desarrolladores.

Nosotros en TicketBAI no marcamos una factura como enviada hasta que hacienda no devuelve que ellos lo han recibido. Cuando abra la aplicación otra vez tendrá que enviar esas facturas que no se han enviado.

El problema es que se pierde la caché de disco y se pierde el registro

Creo que estáis confundiendo los términos Fecha de operación y Fecha de expedición.

La Fecha de operación es la fecha en que realmente se ha generado el hecho imponible (entrega de bienes / prestación de servicios).
Para el caso de operaciones con empresario o profesionales ambas fechas pueden ser distintas. Por ejemplo, el día 10/02/2024 se entregaron 5 cajas del producto "X" y no se emitió factura se emitió albarán (fecha de operación = 10/02/2024). Posteriormente, el día 15/02/2024 se entregaron 15 cajas del producto "Y" y no se emitió factura, se emitió albarán (fecha de operación= 15/02/2024).
Llegado el día 01/03/2024, voy a generar la factura por los suministros del mes de febrero al empresario pero lo voy a hacer con fecha 29/02/2024 ya que no he emitido todavía ninguna factura el día 01/03/2024 y no se va a producir desfase (número factura / fecha)
Fecha de Expedición = 29/02/2024, Fecha de Operación = 15/02/2024 (la más reciente de entre todas las operaciones del mes)

Para el caso de NO empresarios o profesionales, no le podemos emitir albaranes. Estamos obligados a emitir factura el mismo día en que prestamos el servicio o entregamos bienes, por lo tanto la fecha de operación y la fecha de expedición es la misma.
Si para este caso, queremos emitir una recapitulativa de las operaciones a cliente particular a final de mes, por que el cliente no quiere contabilizar las 35 facturas emitidas en dicho mes, podemos anular / abonar las 35 facturas emitidas y luego incluir dichas facturas en una factura recapitulativa cuya fecha de emisión tiene que ser sí o sí la fecha de final de mes.
Por lo tanto, en este caso, la fecha de operación = la fecha más cercana a final de mes donde se hubiera emitido una factura al cliente, la fecha de expedición = 29/02/2024

Con esto quiero decir que la fecha de operación de la que estás hablando no establece una fecha para la factura. La única fecha que importa en una factura y que el reglamento de facturación obliga a identificar es la fecha de expedición.

Al hilo de esto


Cuando encontráis una factura que no ha subido bien, fue rechazada por algún motivo etc... supongo que esa factura queda "retenida" dentro del ERP hasta que se arregle...


Cuando digo retenida me refiero a que no continua el circuito habitual de las facturas (grabarla en contabildad, vaya)