Aún no han empezado a contar los 9 meses para los desarrolladores
 

Yo creo que no (aparte de los logs de eventos del 8.3, que están por definir con más detalle en la O.M.)
Pero se puede discutir.

Creo que no es posible, porque te olvidas de que cuando le entregas o le envías la factura/ticket al cliente, esa factura incluye el código QR (que para eso obligan a ponerlo).
Ese código QR lleva información del firmado de la factura y del encadenamiento.

Si vuelves a generar como tú dices y "regeneras" toda esa información, no coincidirá con lo que tiene el cliente.
Por eso una vez enviada/impresa ya no se puede modificar.

Imagino que si generas 2 facturas, no las envías al cliente (es decir, no han salido de tu sistema), esas 2 últimas facturas podrías borrarlas y volver a generarlas (y sus encadenamientos), pero en cuando el cliente tiene una copia, eso ya no es posible (al menos de esa factura y las anteriores).

Bueno yo me pongo como abogado del diablo. Seguro que te pillan si se hacen con una copia de factura emitida a un cliente, pero no es eso lo que me preocupa. Lo que intento averiguar es cómo garantizar lo que pide el apartado a), justificar que los registros que hemos generado son los originales con algún método técnico fiable, cito dicho apartado

La integridad e inalterabilidad de los datos registrados se asegurará utilizando
cualquier proceso técnico fiable que garantice el carácter fidedigno y completo de los
registros de facturación desde que hayan sido grabados en el sistema informático

¿Dónde pone que todavía no ha empezado el tiempo a contar? :confused::confused:

Edito:

Vaaaaaaaaaaaaaaaaaaale... ha sido enviar el mensaje y ya lo he visto:

"A este real decreto le seguirá la orden ministerial de desarrollo técnico, a partir de la cual los desarrolladores de programas informáticos deberán someterse a sus disposiciones en un plazo máximo de 9 meses."

O sea, que hasta no publiquen el desarrollo técnico no empieza el plazo. Vale.

Y ya puestos pregunto: También dicen que la gente puede usar el Kit Digital para estas modificaciones y yo tenía entendido que el Kit Digital no financia modificaciones de programas, solo nuevas soluciones y con unos requerimientos casi imposibles de cumplir. ¿Alguien sabe algo de esto?

Saludos.

Buenas,

Los requerimientos para la solución de Facturación Electronica del Kit Digital para los segmentos II y III estan adaptados para Veri*Factu. De hecho, los requerimientos son compatibles con TicketBAI y nosotros hemos justificado y financiado con los fondos del Kit Digital cientos de clientes que usan nuestro software de TicketBAI. Las evidencias que piden son, entre otras cosas, la posibilidad de la verificación de la factura (QR), REGISTRO DE FACTURACIÓN,(integridad, conservación, accesibilidad, legibilidad, trazabilidad, e inalterabilidad de los datos), una declaración responsable etc...

Cruzamos dedos que quedan fondos para adaptar a todas las empresas y autonomos de españa ;-)

Gracias por tu respuesta pero (corrígeme si estoy equivocado). ¿No piden que el programa tenga API? ¿por ejemplo? Aparte de que quiero recordar que dice expresamente que no financia modificaciones a lo que hay, tendría que rebuscar en la normativa pero creo que lo he leido en alguna parte.


¿Tú en las justificaciones de software no has tenido que informar del tema API?



Saludos.

Entiendo que están pidiendo que tu sistema informático implemente "algún sistema" para no permitir modificar una factura que ya se ha generado (entendiendo por "generada" cuando ya la tiene el cliente)o la has enviado si tienes VERI*FACTU (ese momento se puede discutir*).

A partir de ese momento (*) no se puede modificar y tu sistema debe implementar "algo" para asegurarlo. El qué ya será cosa de cada uno.

• Una marca en la factura (check)
• Regenerar el XML y comprobar que no ha cambiado
• Ponerla en sólo-lectura
• ...

Apartado 8.INTEGRACIÓN CON OTRAS SOLUCIONES,

Adjuntar, a continuación, las capturas de pantalla en
las que se muestren, por ejemplo, la funcionalidad
de integración y las opciones de integración que
ofrece.

Mostramos la integración con Hacienda y mas cosas.

Cuando se guardan deben ir firmados. Entiendo q la firma ya garantiza q no se modifica después. Vendrá el día y la hora en la firma o algo asi

La firma no garantiza que no se modifique, la firma garantiza que si se modifica, se pueda detectar.
Tu sistema deberá implementar algo" para que el usuario final no pueda modificar una factura ya "generada". A eso creo que es a lo que se refiere ese párrafo.

Buenas a todos de nuevo,
los que hemos tenido "la suerte" de implementar el TBAI, volvemos a las andadas...

Estoy empezando a mirar la info que acaba de salir, para ver que podré aprovechar del TBAI y no puedo parsear los xsd del documento principal.

el wsdl sin problemas,

El primer xsd sí,
https://prewww2.aeat.es/static_files...nformacion.xsd


pero el resto no...

https://prewww2.aeat.es/static_files...ministroLR.xsd

ni

https://prewww2.aeat.es/static_files...Suministro.xsd


¿Os ha funcionado a los demás?

Pues creo q lo mejor es hacer un sistema verifactu que como el envío es inmediato ya tiene la aeat el registro y se entiende q has cumplido. Creo q sí no optamos por este sistema nos van a molestar mucho

Creo que al Reglamento le da igual nuestras facturas registradas en el sistema informático. Lo único que le interesa son los registros de facturación en xml y son sobre estos, no sobre las facturas de nuestro sistema, sobre los que hay que aplicar los apartados de la ley. Al fin y al cabo, lo que le vamos a remitir son esos registros xml. Estoy de acuerdo en que lo más sencillo es aplicar VERI*FACTU ya que según reza en el reglamento, se le supondría que se cumple con éste sólo por remitir de forma instantánea y continua los registros. Pero esa decisión es del cliente, no nuestra. Si el cliente decide remitir sus registros sólo por requerimiento, debemos cumplir con los apartados, para eso nos exigen una declaración responsable.
Por eso sigo buscando una solución "Técnico/Fiable" que garantice que un registro de facturación en xml es el originalmente creado en su momento. A pensarrrr

A mi me los ha generado sin problemas.
Te adjunto los tres ficheros generados por si te sirven.

Mil gracias Germán!

Creo que al final estamos hablando de los mismo.
Está claro que por un lado están las facturas en nuestro sistema y luego una representación en XML que se firma y se encadena. Esa representación se envía de forma inmediata o por requerimiento a la AEAT.

Los XML no se van a poder modificar y para eso ya se especifica el cómo técnicamente en la documentación (firma y encadenamiento).
Cuando el párrafo anterior habla de "La integridad e inalterabilidad de los datos registrados..." creo que se refiere a las facturas de nuestros sistema.
Para mi tiene lógica, porque son los datos iniciales, a partir de los cuales se genera el XML (y la factura del cliente).

Por la propia ley de facturación no se debería poder modificar en un sistema informático una factura ya "generada". Si se pudiera hacer ¿qué pasaría si al cabo de 2 meses un cliente nos pide una copia? Lo mismo con el XML.
Para eso ya existen las facturas rectificativas.
Ninguna de las 2 se debería modificar. Ni la factura almacenada en nuestro sistema, ni por supuesto el XML.

Ok, gracias compañero.

El tema está claro, no se puede modificar las facturas en nuestro sistema y por ende, los registros xml ya que tanto el encadenamiento como la generación de códigos QR quedaría alterada. Con esto certificamos que nuestra ristra de registros de facturación está sintáctica y semánticamente bien construida. Mi discusión no va por ahí, te pregunto ¿ Con qué método técnico fiable garantizo que los xml generados son los originales que se expidieron en un primer momento como nos exige el apartado a) de la ley ?. En el sistema inmediato esto está garantizado porque cuando comunicamos los registros nos devuelve un CSV (Código seguro de verificación) expedido por la aeat que dota de integridad e inalterabilidad el registro comunicado.
¿ Nos están pidiendo algún método técnico fiable parecido para los clientes que informan sólo por requerimiento (no Verifactu) de que los registros que vamos a enviarle son los originales generados en el preciso momento de expedir la factura ?

Pues por ejemplo, implementar en tu sistema que una factura "generada" ya no se puede modificar por parte del cliente.
O al menos no se pueda modificar los campos que afectan al XML.
Si el acceso a la Base de Datos está protegido (como debería ser) esa información ya no es modificable.