Definición de las tablas de los RF y RE

[razorxxx]

Buenas a todos!

Ando un poco perdido con el tema de cómo definir las tablas de la base de datos de mi SIF para albergar la información de los registros de facturación (RF) y de eventos (RE).

Mi idea inicial era poner tantos campos en las tablas de RF y RE como los indicados en el BOE como obligatorios, además de otro campo para almacenar la respuesta obtenida del WebService.

Pero viendo los conceptos de cadenas de registros, huella hash, etc, me causa dudas.

¿Cómo lo estáis haciendo vosotros?:
1. Una tabla para RF y otra para RE, cada una con tantos campos como los indicados en la información obligatoria del BOE, más otro para el XML de respuesta en el caso de acogerse a VERI*FACTU, y que se generen los XML a petición desde el SIF cuando lo quiera el usuario o lo requiera la AEAT.
2. Una tabla para RF y otra para RE, cada una con sólo 2 campos: uno con el XML ya generado con el RF o RE según sea, más otro para el XML de respuesta del WebService.

Por otra parte, creo que las bases de datos de los SIF van a crecer una barbaridad. Yo particularmente uso SQL Server. ¿Cómo creéis que convendría definir las bases de datos?:
1. Una BD única para todo el SIF, que guarde las tablas de RF y RE los datos de todos los ejercicios y de todos los obligados tributarios.
2. Una BD por cada ejercicio fiscal, que guarde las tablas de RF y RE de todos los obligados tributarios.
3. Una BD por cada ejercicio fiscal y por cada obligado tributario (es decir, cada obligado tributario tiene un archivo de BD independiente por cada ejercicio fiscal).

Si vuestro cliente se acoge a VERI*FACTU, ¿igualmente guardáis los registros en la base de datos del SIF, o la borráis porque esa información ya la tiene la AEAT?

Ya por último, ¿el plazo para guardar los RF y RE es de mínimo 4 años, verdad?

Gracias de antemano, Saludos a todos y a luchar con esto que nos ha caído encima!

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

Empezado por razorxxx

¿Cómo lo estáis haciendo vosotros?:

2 tablas diferentes, una para registros de eventos y otra para los de facturas.
En cuanto a los campos, cada una tiene el XML en un campo y luego una serie de campos "importantes" o claves (no todos los del registro). Y que nos pueden hacer falta para obtener información o acelerar las consultas.

Empezado por razorxxx

Por otra parte, creo que las bases de datos de los SIF van a crecer una barbaridad. Yo particularmente uso SQL Server. ¿Cómo creéis que convendría definir las bases de datos?:
1. Una BD única para todo el SIF, que guarde las tablas de RF y RE los datos de todos los ejercicios y de todos los obligados tributarios.
2. Una BD por cada ejercicio fiscal, que guarde las tablas de RF y RE de todos los obligados tributarios.
3. Una BD por cada ejercicio fiscal y por cada obligado tributario (es decir, cada obligado tributario tiene un archivo de BD independiente por cada ejercicio fiscal).

Una única Base de Datos, con la posibilidad de "limpiar" ejercicios antiguos (con más de 4 años). Es responsabilidad de los usuarios guardar copia de lo que borran, si lo hacen.

Empezado por razorxxx

Si vuestro cliente se acoge a VERI*FACTU, ¿igualmente guardáis los registros en la base de datos del SIF, o la borráis porque esa información ya la tiene la AEAT?

Nosotros por ahora los guardamos igualmente los de factura; estos se envían o no. Los de eventos no se registran si el usuario está en Veri*factu.
Pero todo esto puede cambiar. No es definitivo.

[razorxxx]

Gracias por responder.

Perfecto, es justo lo que ya hacía yo con el SII. Guardar los campos clave, los campos para los XML completos y alguno más para acelerar consultas.

Y también trabajo con una base de datos única que almacena todos los ejercicios (y todos los obligados tributarios, en el caso de SIF multiempresa). Así que lo que dices de poder borrar los datos referentes a ejercicios antiguos (anteriores a 4 años) tiene todo el sentido del mundo, tendré que echarle cabeza para ver qué hacer con esos datos antes de borrarlos (por ejemplo, exportarlos a algún formato o bien hacer un .BAK de SQL justo antes de borrar).

En cuanto a lo que dices de que los RE no se registran si el usuario está en VERI*FACTU no lo veo por ningún sitio del BOE. Lo que dice es que todo evento importante ha de registrarse, no me queda claro que discrimine por sistemas VERI*FACTU y NO VERI*FACTU.

[rci]

Empezado por razorxxx

En cuanto a lo que dices de que los RE no se registran si el usuario está en VERI*FACTU no lo veo por ningún sitio del BOE. Lo que dice es que todo evento importante ha de registrarse, no me queda claro que discrimine por sistemas VERI*FACTU y NO VERI*FACTU.

Mira este hilo:
https://www.clubdelphi.com/foros/showthread.php?t=97003


Pregunté a verifactu y me contestaron lo siguiente:

Buenas tardes:

Le confirmamos que en sistemas en la modalidad con remisión inmediata de los registros(modo VERI*FACTU) no deben incorporar el registro de eventos.

Pueden revisar la Orden HAC/1177/2024, de 17 de octubre en su artículo 3. En el cual se mencionan ..."en tanto actúen como «VERI*FACTU», no les serán de aplicación los artículos 6.b), 6.c), 6.d), 6.e), 6.f), 7.f), 7.h), 7.i), 7.j), 8 y 9 de esta orden". Precisamente podrá ver que el artículo 9, uno de los que se mencionan, es el que trata del registro de eventos.

Atentamente,
Atención al Usuario
Departamento de Informática Tributaria
Email: verifactu@correo.aeat.es

[razorxxx]

Sí, acabo de recibir respuesta por mail desde verifactu@correo.aeat.es y me dicen que "los registros de eventos sólo deben aplicarse si el SIF funcionara en modo sin remisión inmediata de los registros (NO VERI*FACTU), si se remiten los registros de facturación inmediatamente en los términos indicados en la Orden, no deberán implementar el registro de eventos".

Aquí la clave está en la palabra "deben", así que yo creo que lo mejor debería ser que nosotros como desarrolladores implementemos el soporte al registro de eventos igualmente. Además, para un obligado tributario es voluntario acogerse a VERI*FACTU, es quien elige trabajar en modo VERI*FACTU o NO VERI*FACTU, por lo que creo que el SIF debería permitir usarse en ambos modos, y por tanto los desarrolladores debemos programar la compatibilidad para ambos, no sólo para VERI*FACTU.

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

Empezado por razorxxx

Aquí la clave está en la palabra "deben", así que yo creo que lo mejor debería ser que nosotros como desarrolladores implementemos el soporte al registro de eventos igualmente.

Puedes hacerlo, pero estarás "sobrecargando" el sistema con algo que no es necesario (bajo mi punto de vista).
Nosotros tenemos implementado eso, pero si el usuario está en Veri*factu no ejecutamos ese código.

[ermendalenda]

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

Puedes hacerlo, pero estarás "sobrecargando" el sistema con algo que no es necesario (bajo mi punto de vista).
Nosotros tenemos implementado eso, pero si el usuario está en Veri*factu no ejecutamos ese código.

En el reglamento la parte de eventos para verifactu pone que no es obligatoria y después el deben, es contradictorio.yo ya mande la consulta y me dijeron que se lo pasaban a los responsables y me dirían cuando respondieran, croe que se han tropezado. A ver como resuelven, pero como metan eventos saben que la gente va a empezar a echarse para atrás en el envío, por que si hay que crear eventos y conservarlos por si lo requieren hay que firmarlos y para eso ya se hace no verifactu, no creo que lo hagan, vaya miedein me da ese parrafo, por que por otro lado pueden estar pensando, venga lo metemos en marzo que ya casi todos habrán adaptado para envios y ya no pueden echarse para atrás, y táctica, eventos de incidencias firmados, no lo descarto, pero espero que deb marcha atrás.
Por favor
Alguien seria tan amable de poner un xnl de como quedaría un evento del tipo "otros" con una inciedencia por no tener internet

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

Este hilo está relacionado:
https://www.clubdelphi.com/foros/sho...995#post559995