[[newtron]]

Hola a tod@s.


Han tardado algo más de tres meses desde que les hice la consulta pero al final han contestado y la verdad es que es una respuesta bastante ilustrativa. La pregunta era por la posibilidad de instalar un paquete con varios componentes, uno genera la factura, otro la envía, etc. a ver cómo se plasmaba eso en relación a la ley.

Buenos días:

La participación en el sistema informático de facturación (SIF) de varios componentes de facturación (CF: ver en la orden ministerial "OM" HAC/1177/2024 su artículo 1.2.b) para implementar las tres principales funcionalidades necesarias para expedir facturas (cargar datos de facturación, conservar esos datos y procesar los mismos) y cumplir con los requisitos exigidos por el RRSIF (reglamento de los requisitos de los SIF, aprobado por el Real Decreto 1007/2023) y la OM, es una arquitectura admisible.

Sin embargo, para que todo el proceso se lleve a cabo de acuerdo con lo especificado por el RRSIF y la OM, ha de tenerse en cuenta que debe garantizarse la indefectibilidad de la conexión entre los componentes (es decir, que siempre se produce y, por tanto, no es posible que no se produzca), así como la inmediatez(*) de la misma y la no alteración de la información intercambiada, además de estar debidamente coordinados para gestionar posibles acciones necesarias posteriores (como, por ejemplo, responder adecuadamente ante un rechazo por parte de la AEAT de un registro de facturación "RF" remitido en el caso de un SIF VERI*FACTU). Una forma -auditable- de garantizar esto es mediante la invocación por programa desde un componente (el componente principal de facturación o CPF: ver en la OM su artículo 1.2.c) a los CF "especializados" en la implementación de ciertos requisitos. Además, todos ellos (CPF y CF) deberán estar certificados por su fabricante con su correspondiente declaración responsable por las funcionalidades que implementen requisitos exigidos.

Por la descripción que se hace de este caso, parece que su planteamiento es que cada SIF conste de dos CF: el CPF que expide las facturas -con su QR tributario incluido- (¿y genera sus RF?) y el CF que (¿genera sus RF y?) remite dichos RF a la AEAT (en el caso de que se trate de un SIF que funcione en modo VERI*FACTU), por lo que, de ser así, se deben garantizar las características indicadas en el párrafo anterior.

(*) De acuerdo con el RRSIF y la OM, debe asegurarse que la generación del RF se produzca de forma simultánea a la expedición de la factura, para su instantánea remisión a la AEAT.

Dado que puede resultar bastante ilustrativa en este caso, seguidamente se adelanta -en su actual estado de confección- una aclaración al respecto a dudas de desarrolladores que se están elaborando en estos momentos y que se prevé publicar en breve en la sede electrónica de la AEAT.
ARQUITECTURAS DE LOS SIF.
POSIBILIDAD DE UN SIF INTEGRADO POR VARIOS COMPONENTES.
POSIBILIDAD DE DISPONER DE COMPONENTES DIFERENTES PARA INTRODUCCIÓN DE DATOS Y GENERACIÓN DE REGISTRO DE FACTURACIÓN (RF), EXPEDICIÓN DE FACTURA CON QR Y REMISIÓN DE LOS RF A LA SEDE ELECTRÓNICA DE LA AEAT.
DECLARACIÓN/ES RESPONSABLE/S.
CERTIFICADOS ELECTRÓNICOS CUALIFICADOS VÁLIDOS ADMITIDOS.
En el mundo de los sistemas informáticos de facturación (SIF), existen diversas y variadas arquitecturas. En la implementación o aplicación de las obligaciones emanadas de la LGT art 29.2.j), del RD 1007/23 que aprueba el Reglamento SIF Veri*factu y de la OMHAC 1177/2024, es del mayor interés permitir que todas esas arquitecturas hoy existentes (e incluso otras novedosas), puedan operar con normalidad, si bien deben cumplir los requisitos de seguridad, inalterabilidad… y certificación que la normativa impone. Por ese motivo las arquitecturas “mixtas”, que son aquellas en las que intervienen varios programas, componentes o sistemas, incluso de fabricantes distintos, no son contrarias a la normativa y pueden utilizarse.
Una de esas arquitecturas, muy común, es aquella basada en un sistema en el que existen terminales que sirven de TPV, pero que están conectadas en tiempo real con un sistema o servidor de backoffice centralizado.

I.- En este sentido y PARA LA MODALIDAD VERI*FACTU resulta admitido que:
a) Una vez introducidos los datos de facturación a través de la terminal TPV, estos se consoliden en tiempo real en el backoffice centralizado y desde allí se genere y se devuelva a las TPVs un “Registro de alta de factura”, tal y como lo describe el Real decreto 1007/23 y la Orden Ministerial para su desarrollo. Recibido por las TPVs el “Registro de alta de factura”, estas procederían a imprimir la factura y entregarla al cliente con el preceptivo QR.
b) Como quiera que la conexión es en tiempo real (o cercano al tiempo real), en ese momento (es decir, después de impresa y entregada la factura) la propia TPV puede lanzar un mensaje al servidor backoffice central, de modo que desde este último se produzca inmediatamente su envío a la sede electrónica en la modalidad VERI*FACTU. Se hace notar que el conjunto formado por los módulos que intervienen en la funcionalidad del SIF deberá prever y gestionar adecuadamente, en su caso, las situaciones que pudieran hacer necesario generar RF de alta de subsanación o RF de anulación. Para ello, ambos componentes deberán estar preparados y correctamente integrados y coordinados para atender posibles respuestas con error o avisos en la remisión a la AEAT.
Alternativamente, a todo lo anterior (letras a) y b)), igualmente sería válida una arquitectura en la que sea la propia TPV la que genere el “Registro de alta de factura” directamente, procediendo también a su impresión con el código QR y entrega al cliente, y en tiempo real traslade todo ello al backoffice central, para que este último sistema proceda a su envío a la sede electrónica en la modalidad VERI*FACTU. Ese backoffice haría de instrumento para la remisión del fichero sin más (y sin perjuicio de su conservación, si bien en la modalidad veri*factu esta última no se regula).

II.- Por lo que se refiere A LA MODALIDAD NO VERI*FACTU:
Es preciso señalar, en primer lugar, que los requisitos de seguridad tanto en la producción, como especialmente la conservación de los Registros de facturación y el chequeo permanente del funcionamiento del sistema, a través del Registro de eventos, hacen mucho más exigente técnicamente a esta modalidad que la de VERI*FACTU. En esta última se dan por cumplidos los requisitos de seguridad, simplemente con el envío de los Registros de alta de factura a la sede electrónica de la AEAT. Por ello, si se dispone de la capacidad de remisión y conexión a la red, contando con que la norma exige la inmutabilidad de los registros (y otra cosa sería ilegal y sancionable), se entiende como preferible el envío de estos, por resultar más sencillo y seguro de gestionar, por sencillez y seguridad tanto para la empresa desarrolladora de software, como para la propia Agencia Tributaria, evitando los problemas técnicos que derivan de la conservación segura de los registros una vez producidos. Por lo demás, la arquitectura mixta a la que se refiere esta FAQ es perfectamente compatible con la normativa, siempre que cumplan ciertos requisitos:⁃ Que ambos sistemas (TPVs y backoffice) estén certificados, cada uno por la parte del proceso de facturación de la que se encarguen.⁃ Que en ninguno de los sistemas ni en la transmisión entre ambos (TPVs y backoffice) se produzca alteración alguna del registro de facturación. De modo que los registros conservados o transmitidos sean exactamente los mismos que se generaron, dieron lugar a la factura y generaron el QR.⁃ Que la conexión entre los sistemas sea indefectible y necesaria, es decir que no quede a decisión del usuario sino que se produzca de forma automática y necesaria. De esta manera, no pueden quedar “huérfanos” ni facturas expedidas ni registros de facturación (RF) generados, es decir, no puede haber facturas expedidas sin sus RF generados, ni RF generados sin sus correspondientes facturas expedidas. Y en el caso de SIF VERI*FACTU, esto se amplía a los RF remitidos, o sea, no pueden quedar RF generados sin remitir a la AEAT.⁃ Que el registro de facturación, en general, esté íntegramente producido en el momento de generar la factura y el código QR y entregarla al cliente o de forma simultánea e inmediata. Sería válido que se carguen datos en la TPV, se genere el registro de facturación en el Back Office, desde el que se envíe y se devuelva una vez generado a la TPV para que sea esta la que lo imprima y entregue al cliente con el QR. Este requisito de inmediatez en general aplica a los 3 grandes procesos involucrados: emisión de la factura con QR, generación del RF y, en su caso, remisión del RF a la AEAT.⁃ Que se respeten los elementos de seguridad, que para la modalidad NO VERI*FACTU, incluyen (además del hash encadenado) la firma del registro por parte del sistema emisor. A este respecto, se recuerda que cuando se utiliza un SIF que actúa bajo la modalidad NO VERI*FACTU, quien expide la factura (con su QR tributario) también debe generar "simultáneamente" el RF debidamente firmado. Es decir, no se puede disociar la autoría del proceso de expedir y generar RF (porque en NO VERI*FACTU, el RF solo se considera generado cuando está firmado).⁃ Que se respeten, las condiciones de conservación inalterable de los registros y, particularmente, en el caso de NO VERI*FACTU, la llevanza del “registro de eventos” del sistema que, en este sentido, dependiendo del tipo de implementación y siempre que la conexión sea en tiempo real, podría limitarse al BackOffice central.En cualquier caso, debe hacerse notar que no sería acorde a la normativa, la producción de los registros de facturación por parte de la TPV y un reproceso posterior de los mismos (que los altere) desde el servidor Back Office central para su conservación u otro fin, como tampoco lo sería la emisión de las facturas desde la TPV, sin que de forma simultánea existiera el registro de facturación de alta (se recuerda que es obligatorio que la factura que se entregue al cliente contenga el código QR con los datos requeridos). Estas últimas consideraciones, naturalmente, son válidas para ambas modalidades. Se recuerda también que los SIF que estén formados por dos, o más componentes, ya sean desarrollados por el mismo fabricante, ya especialmente si son desarrollados por distintos fabricantes, deberán contar todos ellos con la preceptiva Certificación mediante Declaración Responsable (DR). En ella, los fabricantes de cada componente se responsabilizarán del cumplimiento de las obligaciones definidas en la norma en relación con las funcionalidades que presten al conjunto. Por excepción, no será preciso certificar aquellos componentes que presten funcionalidades que sean irrelevantes para el cumplimiento de los requisitos y obligaciones de la normativa SIF (esto es, fundamentalmente, las que no afecten a la generación del RF, a su encadenamiento, a la impresión de facturas, a la generación del QR, al envío a sede electrónica, al enlace indefectible entre componentes, a la conservación inalterada ni al registro de eventos, estos últimos en modalidad no VERI*FACTU). Siguiendo con la certificación en el caso de utilización de varios módulos en diversas arquitecturas, también debe tenerse en cuenta que, al estar compuesto el SIF por varios módulos "componentes de facturación" (CF), de acuerdo con las definiciones dadas en el art. 1.2 de la OM HAC/1177/2024, uno de ellos será el componente principal de facturación o CPF, que “integraría” de alguna forma dentro de él a algún componente de facturación (típicamente invocado desde el CPF mediante una API). En función de la arquitectura empleada, de la vinculación en el desarrollo entre módulos y de si el productor de los módulos es el mismo o distinto, se pueden dar diversas formas de certificación:<!--[if !supportLists]-->a) <!--[endif]-->Si el CF fuera producido por un tercero (que, como se ha dicho, también debería certificarlo con su propia DR, por sus funcionalidades de facturación que implementen requisitos del RRSIF), evidentemente, se trata de un producto con un ciclo (de desarrollo) evolutivo propio, dependiente del tercero, y distinto al del CPF. Dado que es importante conocer cómo funciona la totalidad del SIF y cómo cumple con la normativa, en la DR del CPF debería indicarse que invoca indefectiblemente dichos CF (con mención expresa a la versión concreta usada de esos CF), y también cómo lo hace, cuándo y para qué (es decir, la parte de requisitos que implementan los CF). <!--[if !supportLists]-->b) <!--[endif]-->El caso anterior también puede darse aunque los módulos sean del mismo fabricante, cuando estos tengan un ciclo evolutivo propio, independiente del CPF. Podría ser el caso de módulos que son considerados productos separados, que pueden dar servicio a múltiples CPF (y que incluso podrían comercializarse de forma independiente).<!--[if !supportLists]-->c) <!--[endif]-->Si los módulos fueran un desarrollo del mismo fabricante que el CPF y sus ciclos evolutivos estuvieran vinculados, podría considerarse que no es necesaria una DR específica para los CF pero, en este caso, en la DR del CPF se debería explicar la integración con los CF y su uso indefectible como parte del funcionamiento del sistema, indicando qué parte implementan los CF. Así, un cambio en los CF (en su desarrollo ó “versión”), supondría un cambio en la versión del CPF que los integra (porque realmente significa un cambio del CPF). Por último, en este tipo de situaciones en que participan diversos componentes, debe asegurarse que el certificado electrónico cualificado válido que se emplee por parte de cualquier componente para firmar RF y/o remitir RF a la AEAT sea alguno admitido (respetando normativas de seguridad, como las del Reglamento UE 910/2014, del Parlamento y del Consejo, y, en su caso, contando con el otorgamiento de las facultades necesarias). Atentamente,Atención al UsuarioDepartamento de Informática TributariaEmail: [email protected]

Resumiendo un poco la conclusión a la que llego es que es correcto montar un sistema con varios componentes pero que tiene que haber la seguridad de que el proceso no se va a interrumpir con el resultado del "no envío" de la factura y que tienen que estar lo suficientemente integrados como para poder enviar y recibir las respuestas sin problemas.


Saludos.