Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[nuevo1234]

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

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
• ...

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

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

Empezado por nuevo1234

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.

[nuevo1234]

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

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.

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

[sglorka]

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

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.

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

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

Empezado por sglorka

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

Empezado por sglorka

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...

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.

[sglorka]

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

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.

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 ?

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

Empezado por sglorka

¿ 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.

[antoine0]

Empezado por sglorka

¿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?

Técnicamente, el Reglamento está redactado al revés: dice que los sistemas de Hacienda cumplen al menos las mismas normas (artículos 16.1 y 16.4). Dicho de otra forma, que no se puede pedir a los productores más de lo que ofrece Hacienda (y ya es algo). Entonces no exactamente parecido; de hecho no hay comparación entre los métodos técnicos.

Luego, los artículos 8.2 a y b obligan a usar un «proceso técnico fiable» y a que «Todos los datos registrados deberán encontrarse correctamente fechados, indicando el momento en que se efectúa el registro.» Si por «registros originales» tu entiendes «registros con los datos originalmente grabados», entonces sí, están pidiendo esto (con la excepción de la palabra «parecido»); tanto a Hacienda para la aplicación quien soporta Veri*factu como a cualquier otro proveedor de SIF que usan el método del registro local encadenado y firmado.

[antoine0]

Empezado por sglorka

[aplicar VERI*FACTU] Pero esa decisión es del cliente, no nuestra.

¿Uh? ¿Dónde está escrito que un proveedor de sistema de facturación debe proponer ejercitar, o no, la opción propuesta en el artículo 15, acudir al Veri*factu?

Cierto que el cliente puede elegir. Pero una posibilidad de elección es decidir entre dos proveedores.

[sglorka]

Empezado por antoine0

¿Uh? ¿Dónde está escrito que un proveedor de sistema de facturación debe proponer ejercitar, o no, la opción propuesta en el artículo 15, acudir al Veri*factu?

Cierto que el cliente puede elegir. Pero una posibilidad de elección es decidir entre dos proveedores.

No entiendo lo que dices

[antoine0]

A ver si me explico mejor... (la énfasis es mía)

Empezado por sglorka

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.

A lo cual he contestado:

Empezado por antoine0

¿Dónde está escrito que un proveedor de sistema de facturación debe proponer ejercitar, o no, la opción propuesta en el artículo 15, acudir al Veri*factu?

Cierto que el cliente puede elegir. Pero una posibilidad de elección es decidir entre dos proveedores.

Quiero decir que, al mi entender, un proveedor de SIF puede proponer, y certificar, un sistema que SOLO propone la opción de usar el sistema Veri*factu, sin la posibilidad de desactivar la remisión automática del artículo 15. Sin implementar ni firma, ni archivo de los registro (pero sí de los eventos del 8.3)

La opción la tiene el cliente; pero no dentro del ámbito del programa, sino dentro del ámbito de sus obligaciones de tributación, que es más amplia.
Por ejemplo, en el artículo 15 está escrito «podrán remitir [...] todos los registros de facturación generados por los sistemas informáticos» (mi énfasis); no «generados por [strike]el sistema informático[/strike]».

[sglorka]

Empezado por antoine0

A ver si me explico mejor... (la énfasis es mía)


A lo cual he contestado:


Quiero decir que, al mi entender, un proveedor de SIF puede proponer, y certificar, un sistema que SOLO propone la opción de usar el sistema Veri*factu, sin la posibilidad de desactivar la remisión automática del artículo 15. Sin implementar ni firma, ni archivo de los registro (pero sí de los eventos del 8.3)

La opción la tiene el cliente; pero no dentro del ámbito del programa, sino dentro del ámbito de sus obligaciones de tributación, que es más amplia.
Por ejemplo, en el artículo 15 está escrito «podrán remitir [...] todos los registros de facturación generados por los sistemas informáticos» (mi énfasis); no «generados por [strike]el sistema informático[/strike]».

Ok aclarado. En mi mente estaba que los desarrolladores de SIF deberían tener ambas opciones para ampliar el público objetivo. Pero estoy de acuerdo en que si tu solución desarrolla sólo una de ellas entonces el cliente no puede elegir.

[nuevo1234]

Empezado por sglorka

Ok aclarado. En mi mente estaba que los desarrolladores de SIF deberían tener ambas opciones para ampliar el público objetivo. Pero estoy de acuerdo en que si tu solución desarrolla sólo una de ellas entonces el cliente no puede elegir.

Entonces como proveedores podemos hacer un sistema verifactu, no verifactu o con las dos opciones. Creo que se puede explicar al cliente q un sistema no verifactu complica el tema y puede finalizar con requerimientos. Podían haber definido solo verifactu como sistema único y no enredar mas

[antoine0]

Empezado por nuevo1234

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

Una firma solo garantiza que el firmante (él que tiene la clave privada del certificado de firma) tenía a mano los datos firmados.
Si después de la (primera) firma, los datos se modifican fuera del poder del firmante, entonces la firma resultará inválida; pero técnicamente los datos modificados se pueden supuestamente firmar de nuevo (nota: es delito hacerlo; también es delito proponer de hacerlo) si lo hace el firmante...

El día o la hora no vienen en la firma; solo se puede añadir una marca (o sello) de tiempo a lo que se está firmando.

Si usas Veri*factu, la firma la realiza efectivamente Hacienda y sus sistema dan la hora y por tanto Hacienda tiene la garantía que los datos no se modifican en el momento de la generación.
Si es otra clase de SIF, el programador puede añadir una marca de tiempo a la hora de firmar; así sí se garantiza que no se modifican después (a no ser que se manipulen las marcas de tiempo; otro probable delito). Pero la marca de tiempo no es una obligación en lo que sabemos ahora de las especificaciones, entre otras cosas porque no hay un sistema de marca de tiempo disponible que resulte de agradecimiento tanto de Hacienda como de todos los grandes productores de software.