Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[PepCat]

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

Hoy me he puesto el video "en segundo plano" y me ha llamado la atención algo que han comentado, tal vez porque yo no lo había entendido bien en un primer momento.
Aquí habíamos hablado de que había 2 posibilidades:

Opción a) Guardar la factura en local, firmada, sin enviarla a la administración (evitaba tener que programar nada de envíos en la aplicación -esto había entendido yo-).
Opcion b) Enviar las facturas a la AEAT a medida que se generan.

Yo había entendido que la (opción a) evitaba de tener que lidiar en la aplicación con todo el tema de envíos, pero segun el vídeo he visto que no.

50.50 A partir de aquí explica las 2 alternativas.
51:35 Habla de que la remisión es opcional.
51:40 Hable de algo que es obligatorio en el proyecto (sea cual sea la opción escogida):

"La potencialidad de envío. TODOS los sistemas deben tener la capacidad de enviar. ... de forma que si la agencia tributaria se interesara por un contribuyente, podría llegar a decirle, oye por favor enviame tu registro de facturas del mes de Abril, en este formato legal, y la AEAT lo recibirá y lo tratará. Eso es un requerimiento...
Si el día de mañana por medio de una ampliación normativa llegara a ser obligatorio, en ese caso ya el sistema ya estaría capacitado para realizar el envío..."

Por lo tato me parece claro que se escoja la opción que se escoja, el sistema debe tener implementado todo lo necesario para enviar.

Si yo también he llegado a la misma conclusión después de ver el video.

Es decir que las aplicaciones obligatoriamente deberán ofrecer la opción de envió de las facturas a la agencia tributaria y el cliente es el que podrá escoger que opción quiere adoptar.

Desde el punto de vista de un desarrollador de una aplicación de facturas, creo que la mejor opción es enviar siempre las facturas a la agencia tributaria y olvidadarse de los problemas de posibles alteraciones de la base de datos, logs, …

En el video en el minuto 64 (1h:03). También afirman que las empresas acogidas al sistema SII, ya están cumpliendo la ley por lo que no deben cambiar nada.

En el caso del SII los usuarios tienen hasta 4 días para remitir las facturas por lo que entiendo que el nuevo sistema también dará un plazo parecido para el envío de las facturas.

[antoine0]

Empezado por PepCat

Desde el punto de vista de un desarrollador de una aplicación de facturas, creo que la mejor opción es enviar siempre las facturas a la agencia tributaria y olvidarse de los problemas de posibles alteraciones de la base de datos, logs, …

Tienes toda la razón, obviamente el sistema está diseñado en este sentido: la vía de menor esfuerzo para el desarrollador debe ser la qué permite a Hacienda tener la «mejor» información posible (de su punto de vista, claro). Si no fuese así, el dispositivo sería mal diseñado.

Añadiría otra aspecto: debe resultar que siga lo mismo para el cliente también: es decir, la vía de menor esfuerzo (y menor gasto) para el cliente debe ser la qué permite a Hacienda tener la «mejor» información posible.

[ermendalenda]

Que pereza tanto cambio que habrá que rehacer en poquísimos años con las nuevas tecnologías (ver estado procesadores cuánticos, quantum cryptography.. ), el sha2, sha3 etc se va a quedar para primero de infantil. Está claro que las inversiones en cambios de equipos que tendremos que hacer en pocos años va a ser bestial, así que si podéis estrujar al máximos los equipos que tengáis para esto del verifactu no os recomiendo el uso de vuestra pasta ni la del kit digital, si lo podéis usar en otros finesque no sea la adquisición para renovar la flota de equipos a no ser que ya sean muy viejunos.

[antoine0]

Empezado por PepCat

También afirman que las empresas acogidas al sistema SII, ya están cumpliendo la ley por lo que no deben cambiar nada.

Esto sí que deberán explicármelo con detalles. Y es que le veo muchísima lógica a la idea. Pero por el otro lado está el texto del borrador...

Para empezar, hoy en día yo no calculo ningún hash (art. 12) ni hago ningún encadenamiento explicito (art. 10.1 ñ).

Claramente la DA3ª nos exime del artículo 8, y no es poca cosa. Pero no dice que estar en el SII significa automáticamente cumplir lo dispuesto en 16.1; con lo poco que sería añadirlo... Así se cubriría gran parte del problema: los registros pasarían a ser los que hemos subidos al SII, Hacienda sería él que encadena, y calcula los hashes (pequeño problema añadido aquí, el 16.3 dice exactamente el contrario). Pero de momento, nada de esto está escrito.

Y luego está el texto del 10.2 (bajo de la página 15). Se refiere a los del SII (vía art 62.6 del RIVA). Dice que sus registros de facturación deben cumplir con lo del RIVA (63.3, que solapan en gran parte lo del 10.1), cómo no puede ser de otra forma; y añade

[...] también les será de aplicación lo dispuesto en las letras ñ), o), p), q) y r) del apartado anterior.

Si realmente los del SII no debemos cambiar nada, este texto sobraría completamente.

Es cierto que solo es un borrador, puede ser que en el final, hay que esperar, paciencia etc. etc.
También es posible que pronto veamos un SII versión 1.2, con todas estas novedades de la ñ) a la r) añadidas en los registros, con fecha de aplicación, por ejemplo, 1/1/2024.