VERI*FACTU - Ejemplo de declaración responsable

[espinete]

Es que ellos se quedan tan contentos con poner la palabra "componentes" y hala, nosotros a averiguar a qué se refieren con eso. Con la de opciones que existen hoy en día (opciones que no conocen ni ellos, probablemente).

Nuestro software permite también facturar desde la APP para iOS/Android, pero en realidad quien genera y guarda la factura es un PC que actúa como Servidor. ¿Qué hacemos, mostramos la DR también en los móviles, o solo al instalar la aplicación "servidor" en el Servidor?

Quiero pensar que todo esto es más tecnicismo que otra cosa, para cumplir la normativa y punto. Luego en el día a día nadie va a mirar esto con lupa.
Lo que quiero decir es que si nos falta por especificar algún "componente", no creo que se nos vaya a caer el pelo. Ya hemos indicado en la DR que nos hacemos responsables de lo que haga nuestro software. Ponerse tiquismiquis con los "componentes" ya es pasarse un poco.

[[newtron]]

Empezado por espinete

Es que ellos se quedan tan contentos con poner la palabra "componentes" y hala, nosotros a averiguar a qué se refieren con eso. Con la de opciones que existen hoy en día (opciones que no conocen ni ellos, probablemente).

Nuestro software permite también facturar desde la APP para iOS/Android, pero en realidad quien genera y guarda la factura es un PC que actúa como Servidor. ¿Qué hacemos, mostramos la DR también en los móviles, o solo al instalar la aplicación "servidor" en el Servidor?

Quiero pensar que todo esto es más tecnicismo que otra cosa, para cumplir la normativa y punto. Luego en el día a día nadie va a mirar esto con lupa.
Lo que quiero decir es que si nos falta por especificar algún "componente", no creo que se nos vaya a caer el pelo. Ya hemos indicado en la DR que nos hacemos responsables de lo que haga nuestro software. Ponerse tiquismiquis con los "componentes" ya es pasarse un poco.

Yo lo que creo es que una parte importante de las respuestas que dan los de verifactu no dejan de ser interpretaciones del funcionario que te responde y que en muchas ocasiones igual no es lo exacta/correcta que debería de ser pero que a nosotros nos vuelven un poco "pallá".

[razorxxx]

Empezado por ermendalenda

Vaya, nuevo giro a lo que yo tenía pensado.
Hago resumen de capítulos anteriores, como en Netflix.
Al hilo de las respuestas que me iban haciendo verifactu sobre las declaraciones responsables, me incluyen un par de cosas, resumiendo, que si cobra es un componente principal, por tanto, en mi caso, componentes principales son: app con pedidos, terminales de comandas que puedan cobrar, el tpv, un kiosko desatendidos y todo graba en el mismo servidor, con lo cual solo es un SIF con varios componentes principales y cada uno con su declaración responsable, vaya lío de declaración responsable que tengo que hacer, fijaos que para certificar las app de datafonos co n redsys y otros privados tengo que decirles como funcionan los programas de venta y al final no se enteran, así que fijaos para ponerlo en una D.R y que cuando lo lea un humanoide lo entienda.
Yo pensaba que el componente principal era el del program del tpv, que es la UI principal, la que envía, la que emite rectificativas, anulaciones...
O sea, nunca terminó dios.
Bueno al menos, les he explicado más o menos el esquema y me han dicho que es correcto..algo tranquilo me quedo.

No te rayes aún con lo de la declaración responsable. Según la web de VeriFactu en la AEAT, dice que estará disponible como modelo en Sede Electrónica.

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

[YellowStone]

Por si os sirve de guía, atendiendo a lo especificado en el BOE indicado más arriba, he apañado una primera versión de nuestra declaración responsable:

DECLARACIÓN RESPONSABLE DEL SISTEMA INFORMÁTICO DE FACTURACIÓN

INFORMACIÓN:

• a) Nombre del sistema informático de facturación: @sistema.

• b) Código identificador del sistema informático de facturación: @identificador.

• c) Identificador completo de la versión actual del sistema informático de facturación: @version.

• d) Componentes, hardware y software, de que consta el sistema informático de facturación: (A DESARROLLAR)

• e) El presente sistema informático de facturación funciona exclusivamente en la modalidad "VERI*FACTU".

• f) El presente sistema informático de facturación permite ser usado por varios obligados tributarios, o por un mismo
usuario para dar soporte a la facturación de varios obligados tributarios.

• g) El presente sistema informático de facturación, al funcionar exclusivamente en la modalidad "VERI*FACTU", al no estar
obligado a ello no firma los registros de facturación. Se utiliza el certificado digital propio del obligado tributario
exclusivamente para identificarse en el envío de los registros de facturación a la Agencia Tributaria.

• h) Razón social de la entidad productora del sistema informático de facturación: @razon_social.

• i) Número de identificación fiscal de la entidad productora del sistema informático de facturación: @nif

• j) Dirección postal de la entidad productora del sistema informático de facturación: @direccion

• k) La entidad productora del sistema informático de facturación, hace constar que el presente sistema, en su versión
actual, cumple con lo dispuesto en el artículo 29.2.j) de la Ley 58/2003, de 17 de diciembre, General Tributaria, en el
Reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que
soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de
facturación, aprobado por el Real Decreto 1007/2003, de 5 de diciembre, en esta orden y en la sede electrónica de la Agencia
Estatal de Administración Tributaria para todo aquello que complete las especificaciones de esta orden.

• l) La entidad productora del sistema informático de facturación, suscribe la presente declaración en @lugar a @fecha.

INFORMACIÓN ADICIONAL:

• a) Otras formas de contacto con la entidad productora del sistema informático de facturación: @email, @telefono, @whatsapp

• b) Página web de la entidad prodcutora del sistema informático de facturación: @web

• c) Explicación detallada de cómo cumple el presente sistema informático de facturación las diferentes especificaciones
técnicas y funcionales: (A DESARROLLAR)

• d) Información adicional de interés (A DESARROLLAR)

[ermendalenda]

Seguimos sin ejemplos
Subo el post, por si alguien quiere aprovechar alguna consulta a verifactu para ver cuando lo ponen.

[sEngine]

Por lo que yo he entendido.. hay que rellenar algo similar a lo que han puesto por arriba, y que en el SIF se pueda leer (como ejemplo, una opción de menú)?

[espinete]

Nosotros hemos tirado del ejemplo que pusieron hace poco, rellenándolo con los datos de la empresa, etc. y listo.
Tampoco creo que haya que fliparse con esto. Si fuera algo tan serio, que hubieran exigido firmar un documento de responsabilidad, como hizo TicketBAI.

[RUBEN_SP]

Empezado por espinete

Nosotros hemos tirado del ejemplo que pusieron hace poco, rellenándolo con los datos de la empresa, etc. y listo.
Tampoco creo que haya que fliparse con esto. Si fuera algo tan serio, que hubieran exigido firmar un documento de responsabilidad, como hizo TicketBAI.

Hola ¿Me puedes decir donde pusieron ese ejemplo?

[espinete]

Aquí en este hilo, en los primeros posts creo.
Es solo un texto con varios puntos: a), b), c) etc

[pablog2k]

Empezado por RUBEN_SP

Hola ¿Me puedes decir donde pusieron ese ejemplo?

este boe: https://www.boe.es/diario_boe/txt.ph...E-A-2024-22138

Artículo 15. Contenido de la declaración responsable y ubicación de la misma.

[gcqZW]

enlace roto este sí va

Artículo 15. Contenido de la declaración responsable y ubicación de la misma.
1. La declaración responsable comenzará con el título «DECLARACIÓN RESPONSABLE DEL SISTEMA INFORMÁTICO DE FACTURACIÓN» y, a continuación, deberá contener, al menos, la siguiente información, en el mismo orden en que se indica. Cada dato aportado deberá precederse del texto que lo describe, de acuerdo con lo redactado en la letra con la cual se corresponde:

a) Nombre del sistema informático a que se refiere la declaración responsable. Con carácter general será la denominación genérica dada al mismo para su distribución o comercialización.

b) Código identificador del sistema informático a que se refiere el apartado 1.a), de acuerdo con las especificaciones dadas en el apartado 2.6 del anexo. Se trata de una codificación a establecer por la persona o entidad productora del sistema informático a que se refiere la declaración responsable de manera que sirva para identificar unívocamente al mismo de una forma breve, en lugar de hacerlo de una forma más extensa mediante el nombre indicado en el apartado 1.a). Este código no podrá coincidir con el de otro sistema informático distinto que pueda producir dicha persona o entidad.

c) Identificador completo de la versión concreta del sistema informático a que se refiere la declaración responsable.

d) Componentes, hardware y software, de que consta el sistema informático a que se refiere la declaración responsable, junto con una breve descripción de lo que hace dicho sistema informático y de sus principales funcionalidades.

e) Indicación de si el sistema informático a que se refiere la declaración responsable se ha producido de tal manera que, a los efectos de cumplir con el Reglamento, solo pueda funcionar exclusivamente como «VERI*FACTU», de acuerdo con las especificaciones dadas en el apartado 2.6 del anexo.

f) Indicación de si el sistema informático a que se refiere la declaración responsable permite ser usado por varios obligados tributarios o por un mismo usuario para dar soporte a la facturación de varios obligados tributarios, de acuerdo con las especificaciones dadas en el apartado 2.6 del anexo.

g) Tipos de firma utilizados para firmar los registros de facturación y de evento en el caso de que el sistema informático a que se refiere la declaración responsable no sea utilizado como «VERI*FACTU».

h) Nombre y apellidos de la persona o razón social de la entidad productora del sistema informático a que se refiere la declaración responsable.

i) Número de identificación fiscal (NIF) español de la persona o entidad productora del sistema informático a que se refiere la declaración responsable. Si no dispone de NIF español, deberá hacer constar otro número de identificación de que disponga, indicando de qué tipo de identificación se trata y el país que lo ha emitido, todo ello de acuerdo con las especificaciones dadas al respecto en el apartado 2.6 del anexo.

j) Dirección postal completa de contacto de la persona o entidad productora del sistema informático a que se refiere la declaración responsable.

k) La persona o entidad productora del sistema informático a que se refiere la declaración responsable deberá hacer constar que dicho sistema informático, en la versión indicada en ella, cumple con lo dispuesto en el artículo 29.2.j) de la Ley 58/2003, de 17 de diciembre, General Tributaria, en el Reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el Real Decreto 1007/2023, de 5 de diciembre, en esta orden y en la sede electrónica de la Agencia Estatal de Administración Tributaria para todo aquello que complete las especificaciones de esta orden.

l) Fecha y lugar en los que la persona o entidad productora del sistema informático suscribe la declaración responsable del mismo. La fecha ha de ser completa, es decir, deberá indicar día, mes y año, en ese orden. El lugar deberá contener, al menos, el nombre de la localidad y el nombre del país, en ese orden.

2. Tras la información obligatoria, se recomienda que, a modo de anexo, la declaración responsable contenga la siguiente información adicional:

a) Otras formas de contacto con la persona o entidad productora del sistema informático a que se refiere la declaración responsable, distintas a la indicada en el apartado 1.j).

b) En caso de que existan, direcciones de Internet de la persona o entidad productora del sistema informático a que se refiere la declaración responsable, especialmente aquellas con información sobre dicho sistema informático.

c) Explicación detallada de cómo cumple el sistema informático a que se refiere la declaración responsable las diferentes especificaciones técnicas y funcionales contenidas en esta orden.

d) Cualquier otra información adicional que la persona o entidad productora del sistema informático a que se refiere la declaración responsable considere de interés al respecto.

3. La declaración responsable deberá encontrarse disponible de manera legible e individualizada dentro del propio sistema informático a que se refiere y ser accesible por el usuario de forma rápida, fácil e intuitiva. Asimismo, deberá ponerse a disposición del comercializador y del cliente, tanto en el momento de su adquisición como posteriormente, en papel o electrónicamente en un formato de uso ampliamente extendido y gratuito.

4. En caso de que el sistema informático sea ampliado con otros componentes, hardware o software, producidos por otras personas o entidades distintas a quien ha producido dicho sistema informático, estas deberán aportar las correspondientes declaraciones responsables de todas y cada una de las ampliaciones realizadas, en sus diferentes versiones.

Asimismo, cuando el propio sistema informático esté formado por varios componentes, hardware o software, producidos por diferentes personas o entidades, todas ellas deberán aportar las correspondientes declaraciones responsables de sus componentes, en sus diferentes versiones.

[YellowStone]

Empezado por RUBEN_SP

Hola ¿Me puedes decir donde pusieron ese ejemplo?

El ejemplo está cuatro mensajes más arriba de tu mensaje.

[ramaral]

Ya tenemos un ejemplo:

https://sede.agenciatributaria.gob.e...sponsable.html

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

Empezado por ramaral

Ya tenemos un ejemplo:
https://sede.agenciatributaria.gob.e...sponsable.html

Gracias por el enlace.

[bmfranky]

Empezado por ramaral

Ya tenemos un ejemplo:

https://sede.agenciatributaria.gob.e...sponsable.html

Gracias por el enlace, anda que les gusta esconder las cosas, publican en 3 sitios diferentes, así a ver quien encuentra nada.

[gcqZW]

anda que les gusta esconder las cosas

Tal cual, todos los días miro el tablón de anuncios y solo ponen una de cada cinco jajaja, ayer me enteré de la actualización de validación de errores por pura casualidad.

[Faneka]

Gracias.

[[newtron]]

Gracias compañero.


Echando un vistazo me escama y me sorprende este último párrafo. ¿Esto será obligatorio?

Existe la posibilidad de elegir una forma especial que permite entrar enla aplicación de facturación de tal manera que solo se da acceso a lainformación con trascendencia tributaria, ocultando o impidiendo el
acceso a la posible información confidencial de carácter no patrimonial,de forma que la Administración tributaria pueda acceder directamente ala consulta y al resto de funcionalidades exigidas sobre la informaciónde los registros de facturación y de eventos. En este caso se haimplementado mediante un control tipo “check” que puede serseleccionado (por defecto no lo está) antes de entrar en la aplicación.

[bmfranky]

Empezado por newtron

Gracias compañero.


Echando un vistazo me escama y me sorprende este último párrafo. ¿Esto será obligatorio?

Hola, si es obligatorio, si en el modo "Normal", de acceso se puede ver datos de tus clientes, ajenos a los registros de facturación, por ejemplo, cuentas bancarias,emails y demás datos reflejados en la ley de protección de datos.