[sglorka]

Empezado por CarlosR

Corrígeme si me equivoco, pero el aplicativo debe poder acogerse a veri*factu o no, es decisión de la empresa acogerse o no. El aplicativo debe tener las dos versiones.
En el caso de que te acojas a veri*facto deberás enviar las facturas a la Agencia Tributaria de forma casi inmediata, y poco mas. En el caso de que no te acojas a veri*factu no podrás poner ningún QR en tus facturas y debes tener todos los protocolos de encadenamiento, cifrado, garantía de no cambio, archivo, exportación de logs..., etc.etc.
Como el aplicativo debe tener las dos, en mi caso he optado por seguir todos los pasos tanto si se envía a la Agencia Tributaria como si no.
Sigo teniendo dudas de si hay que llevar dos o mas tablas separadas de la tabla de cabecera de factura y pies de documento o bien serviría con encadenar las mismas facturas en un campo XML en la misma tabla de cabecera de facturas que es como realmente lo tengo diseñado. Creo entender que no hay una norma fijada a tenor de lo que estoy leyendo.
He estado en numerosos weminars y aparte de hablar de fechas de entrada en vigor y algún link de la AEAT poco mas se dice.
Aprecio enormemente la colaboración de foros como este, que en determinados momentos se vuelve una necesidad.

Yo tenía en mente también desarrollar el aplicativo para que cubriese el modo VeriFactu y el modo Requerimiento, pero esa idea voló de mi cabeza nada más ver en la OM, la tabla de eventos que hay que gestionar, además de hacerte cargo de la copia de seguridad de los registros de facturación durante los últimos 4 años que tienen que estar disponibles para un requerimiento. La aplicación no tiene porqué cubrir ambos modos, es más, creo que la inmensa mayoría sólo va a desarrollar VeriFactu y el cliente tendrá lentejas. El reglamento define un campo en el xml donde tú dices si tu aplicación va a trabajar en un modo u otro.

Respecto de las tablas que te traen loco, te haría una reflexión. A veces programamos para resolver un problema y una vez que tenemos el proceso funcionando lo cerramos y a otra cosa. No nos paramos a pensar cómo deberíamos actuar en caso de que dicho proceso tuviera que responder a un imprevisto. Mientras va todo bien el programa funciona pero si surge un problema, restauración del sistema con una copia de hace dos días por encriptación del equipo, envío incorrecto del algún campo como, fecha de operación, régimen tributario, huella calculada con un retorno de carro de más, etc. tenemos que poder resurgir de estas cenizas y que nuestro proceso pueda salir más o menos airoso.
Te digo esto porque da igual las tablas que uses para resolver el problema, te tienes que preguntar lo siguiente. ¿ Con la estructura que he diseñado para el mundo de las mil maravillas donde todo funciona, podría rehacerme de un imprevisto ?

En mi caso particular, le emisión de documentos de venta no la he tocado en el sistema. He creado tablas de apoyo, Cabeceras, Líneas de venta, Bases-Tipos-Cuotas, etc que almacenan una foto estática de cómo se ha emitido la factura, con descripciones de productos, nombre, dirección, provincia de cliente, etc. sin identificadores, sólo texto descriptivo. Estas tablas las uso para generar los registros de facturación y no guardan integridad referencial con mis tablas maestras. Cuando imprimo una factura ya no lo hago desde mis tablas de facturas si no de estas tablas de apoyo que están aisladas ( recuerda que si reimprimes una copia de factura debe decir lo mismo que la primera vez que lo hiciste, si has cambiado datos personales del cliente o descripciones de productos, no pueden influir en esta copia).
Estas tablas no participan de ningún repositorio de informes con lo que no penalizan la obtención de los mismos.

En resumen, espero que te sirva de un poco de ayuda.