Nodo SistemaInformatico con varios componentes

[pablog2k]

Buenos días, no se si a nadie mas se le ha dado el siguiente caso:
Nosotros para adaptarnos a verifactu, como ya teníamos nuestro ERP desde hace años hecho (en delphi, claro) , simplemente la parte del ERP la hemos adaptado para cumplir con la ley antifraude, generar qr..etc
A su vez, hemos creado otro programa, en delphi también, que se ejecuta en el server, que es el que envía los registros de facturación cada 60 segundos(o lo que sea segun la ley), además de poder visualizar todos los registros, poder filtrar, ver estado (pendiente , enviado , enviado con errores, subsansaciones, anulaciones...etc)
La cuestión es, cada uno de ellos es 'independiente', lleva su control de versiones, nombre distinto..etc (aunque lógicamente usan la misma base de datos).

Con lo que, en el nodo del xml de SistemaInformatico , que nombre y versión debemos indicar, el del ERP que hace las facturas/QR/etc? o el del nuevo programa que solo se encarga d hacer los envios con el certificado de la empresa, y recoger la respuesta?

Les he preguntado a verifactu pero me han respondido un ladrillo con enlaces a las preguntas frecuentes, que no me han aclarado nada

Alguien más pasa por esta situación, y tiene claro que poner en ese nodo, y (dicho sea de paso) si hay que hacer dos declaraciones responsables, una por software , o solo una

muchas gracias

[novatico]

Empezado por pablog2k

Buenos días, no se si a nadie mas se le ha dado el siguiente caso:
Nosotros para adaptarnos a verifactu, como ya teníamos nuestro ERP desde hace años hecho (en delphi, claro) , simplemente la parte del ERP la hemos adaptado para cumplir con la ley antifraude, generar qr..etc
A su vez, hemos creado otro programa, en delphi también, que se ejecuta en el server, que es el que envía los registros de facturación cada 60 segundos(o lo que sea segun la ley), además de poder visualizar todos los registros, poder filtrar, ver estado (pendiente , enviado , enviado con errores, subsansaciones, anulaciones...etc)
La cuestión es, cada uno de ellos es 'independiente', lleva su control de versiones, nombre distinto..etc (aunque lógicamente usan la misma base de datos).

Con lo que, en el nodo del xml de SistemaInformatico , que nombre y versión debemos indicar, el del ERP que hace las facturas/QR/etc? o el del nuevo programa que solo se encarga d hacer los envios con el certificado de la empresa, y recoger la respuesta?

Les he preguntado a verifactu pero me han respondido un ladrillo con enlaces a las preguntas frecuentes, que no me han aclarado nada

Alguien más pasa por esta situación, y tiene claro que poner en ese nodo, y (dicho sea de paso) si hay que hacer dos declaraciones responsables, una por software , o solo una

muchas gracias

Nosotros lo hemos montado algo diferente. El módulo que envía los registros, no tiene opciones ni pantalla, sólo procesa en segundo plano, en una tarea minimizada y no visible. Las opciones que indicas de visualización, filtro, estado, etc. las hemos incluido en el ERP habitual, el que hace las facturas. Además, ten en cuenta que a la AEAT de has de facilitar una forma sencilla de acceder a ésta información.

[ermendalenda]

Hola, da igual quetodo este en la misma BD, pero segun como lo tengas planteado, si solo controlas el envio desde uno pero los encadenamientos, instalaciones etc son independientes, debes generar un envio(o conjunto de envios) inpendiente de cada uno, aunque uses el mismo seevicio. Cada paquetw emviado llevara wn cada registro, el numero de instalacio, versió, etc...por tanto el control de respuestas tambien debe ser independiente.

[[newtron]]

Buenas.


En nuestro caso hemos montado igualmente el tema de forma que el erp envía un fichero de cada factura a otro programa que se encarga de hacer el envío. Este otro programa "enviador" se instala de forma parecida a un servicio pero se puede abrir para ver los ficheros que se van enviando, resultados, es el que tiene el certificado, etc.


Por lo que he podido averiguar serían dos sifs distintos con sus versiones y declaraciones responsables distintas y en la declaración responsable del erp hacemos mención a que va indisolublemente unido al programa "enviador".


Saludos.

[Carlos]

Empezado por pablog2k

Buenos días, no se si a nadie mas se le ha dado el siguiente caso:
Nosotros para adaptarnos a verifactu, como ya teníamos nuestro ERP desde hace años hecho (en delphi, claro) , simplemente la parte del ERP la hemos adaptado para cumplir con la ley antifraude, generar qr..etc
A su vez, hemos creado otro programa, en delphi también, que se ejecuta en el server, que es el que envía los registros de facturación cada 60 segundos(o lo que sea segun la ley), además de poder visualizar todos los registros, poder filtrar, ver estado (pendiente , enviado , enviado con errores, subsansaciones, anulaciones...etc)
La cuestión es, cada uno de ellos es 'independiente', lleva su control de versiones, nombre distinto..etc (aunque lógicamente usan la misma base de datos).

Con lo que, en el nodo del xml de SistemaInformatico , que nombre y versión debemos indicar, el del ERP que hace las facturas/QR/etc? o el del nuevo programa que solo se encarga d hacer los envios con el certificado de la empresa, y recoger la respuesta?

Les he preguntado a verifactu pero me han respondido un ladrillo con enlaces a las preguntas frecuentes, que no me han aclarado nada

Alguien más pasa por esta situación, y tiene claro que poner en ese nodo, y (dicho sea de paso) si hay que hacer dos declaraciones responsables, una por software , o solo una

muchas gracias

Es un solo SIF, la identificación del cual debe usarla en 'enviador'; seran 2 declaraciones responsables por lo que hace cada uno.

[Carlos]

Empezado por newtron

Buenas.


En nuestro caso hemos montado igualmente el tema de forma que el erp envía un fichero de cada factura a otro programa que se encarga de hacer el envío. Este otro programa "enviador" se instala de forma parecida a un servicio pero se puede abrir para ver los ficheros que se van enviando, resultados, es el que tiene el certificado, etc.


Por lo que he podido averiguar serían dos sifs distintos con sus versiones y declaraciones responsables distintas y en la declaración responsable del erp hacemos mención a que va indisolublemente unido al programa "enviador".
Saludos.

No la liemos, es un solo SIF, el enviador no factura nada, no es un SIF, a lo mejor encadena, crea huellas, envía y demás pero no factura, el enviador no es un SIF.

Y cada uno tendrá su declaración responsable.
Saludos,

[[newtron]]

Vale, me corrijo, efectivamente no son dos sifs sino un sif con dos componentes. Lo que si me dicen es que cada uno de ellos debe de llevar su declaración responsable, que era lo que quería comentar.


Esta es la respuesta a esa consulta que les hice a los de la aeat:

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.

[pablog2k]

nuestro 'enviador' hecho en delphi solo envía, no hace nada más (bueno, puedes consultar los registros de facturación, clasificados por enviados, erroneos etc, poder filtrar...)
La cuestión, aunque sea un solo SIF y dos declaraciones responsables, es que valores hay que poner en el nodo SistemaInformatico (nombre y version).... el nombre y versión del ERP ,o el del 'enviador'?
según lo que comenta Carlos:
"la identificación del cual debe usarla en 'enviador';"
es decir, habría que poner en ese nodo, nombre y versión del enviador?

[emailesc]

Empezado por pablog2k

nuestro 'enviador' hecho en delphi solo envía, no hace nada más (bueno, puedes consultar los registros de facturación, clasificados por enviados, erroneos etc, poder filtrar...)
La cuestión, aunque sea un solo SIF y dos declaraciones responsables, es que valores hay que poner en el nodo SistemaInformatico (nombre y version).... el nombre y versión del ERP ,o el del 'enviador'?
según lo que comenta Carlos:
"la identificación del cual debe usarla en 'enviador';"
es decir, habría que poner en ese nodo, nombre y versión del enviador?

Por lo que entiendo, el nombre que le des AL CONJUNTO de los dos componentes, que es lo que compone el SIF. Tienes un software, llamémosle Software Verifactu, que se compone de dos componentes, valga la redundancia, Software Verifactu Que factura y Software Verifactu Que Envía. Y la versión va en Software Verifactu: si actualizas uno tienes que actualizar el otro, al menos la versión y de cara a Verifactu.

[ermendalenda]

Empezado por pablog2k

nuestro 'enviador' hecho en delphi solo envía, no hace nada más (bueno, puedes consultar los registros de facturación, clasificados por enviados, erroneos etc, poder filtrar...)
La cuestión, aunque sea un solo SIF y dos declaraciones responsables, es que valores hay que poner en el nodo SistemaInformatico (nombre y version).... el nombre y versión del ERP ,o el del 'enviador'?
según lo que comenta Carlos:
"la identificación del cual debe usarla en 'enviador';"
es decir, habría que poner en ese nodo, nombre y versión del enviador?

El del componente principal. La decision de cual es el componente principal la tienes que decidir segun una serie de parametro.
Se suele tomar en cuenta lo siguiente:

1. El que controla el ciclo completo de la factura

Si un módulo es el que genera, numera, firma y envía las facturas (ej. tu ERP o tu TPV principal), ese es el candidato natural a ser el principal.



2. El que gestiona la numeración única

El SIF debe garantizar que no se duplican facturas ni se salta numeración.

Si un módulo es el que asigna la serie y número correlativo (aunque la factura se origine en otro), ese debería ser el principal.



Es wl que tiene acceso a todos los demás módulos

Si tienes varios submódulos (ejemplo: comandero → TPV → backoffice), el que está en el nivel más alto de control y consolidación debe ser el principal.

El principal debe ser el que tenga implementada la conexión VeriFactu para el envío automático de registros de facturación, pero no es la conexion la principal.


En resumen:
Si usas módulos de terceros, normalmente, tu propio software actúe como principal.

[novatico]

Nosotros, en la Declaración Responsable del módulo principal, que emite las Facturas con su QR, crea correspondiente Registro de Facturación debidamente encadenado y marcado como pendiente de envío, hemos añadido, en la descripción del SIF, el siguiente párrafo para detallar la existencia del servicio de envío de los registros de facturación:

- Así mismo, incluye un sistema de Control de Flujo trabajando en segundo plano,
que revisa periódicamente, la existencia de Registros de Facturación Pendientes
de enviar a la sede electrónica de la Agencia Estatal de Administración Tributaria,
enviándolos si procede, y gestionando las respuestas de la Agencia.

[pablog2k]

Empezado por novatico

Nosotros, en la Declaración Responsable del módulo principal, que emite las Facturas con su QR, crea correspondiente Registro de Facturación debidamente encadenado y marcado como pendiente de envío, hemos añadido, en la descripción del SIF, el siguiente párrafo para detallar la existencia del servicio de envío de los registros de facturación:

- Así mismo, incluye un sistema de Control de Flujo trabajando en segundo plano,
que revisa periódicamente, la existencia de Registros de Facturación Pendientes
de enviar a la sede electrónica de la Agencia Estatal de Administración Tributaria,
enviándolos si procede, y gestionando las respuestas de la Agencia.

gracias por el aporte , supongo que haremos algo parecido

[[newtron]]

Igualmente lo he hecho yo. Haciendo referencia en el SIF que va obligatoriamente ligado a otro programa que se dedica a enviar los registros. En mi caso ese programa "enviador" tiene también su número de licencia y su declaración responsable porque tendrá sus actualizaciones independientemente del SIF (que serán varios). No sé si será la mejor forma pero si es la mejor que se me ha ocurrido.

[Carlos]

Empezado por pablog2k

nuestro 'enviador' hecho en delphi solo envía, no hace nada más (bueno, puedes consultar los registros de facturación, clasificados por enviados, erroneos etc, poder filtrar...)
La cuestión, aunque sea un solo SIF y dos declaraciones responsables, es que valores hay que poner en el nodo SistemaInformatico (nombre y version).... el nombre y versión del ERP ,o el del 'enviador'?
según lo que comenta Carlos:
"la identificación del cual debe usarla en 'enviador';"
es decir, habría que poner en ese nodo, nombre y versión del enviador?

Perdonad la corrección, yo he dicho:
"Es un solo SIF, la identificación del cual debe usarla en 'enviador'; seran 2 declaraciones responsables por lo que hace cada uno."

Con ello me refiero a que el 'enviador' al tener que generar el XML (entiendo que lo genera él), deberá indicar en el XML los datos identificativos del SIF que es lo que pide Veri*factu.
Si al 'enviador' ya se le da el XML hecho, pués nada lo envía y punto.

[ermendalenda]

Empezado por newtron

Igualmente lo he hecho yo. Haciendo referencia en el SIF que va obligatoriamente ligado a otro programa que se dedica a enviar los registros. En mi caso ese programa "enviador" tiene también su número de licencia y su declaración responsable porque tendrá sus actualizaciones independientemente del SIF (que serán varios). No sé si será la mejor forma pero si es la mejor que se me ha ocurrido.

Aquí os dejo una respuesta, al hilo de las DR, que me dieron en Marzo, el apartado C os puede despejar la duda respecto a la DR de modulos del mismo fabricante, como veis podeis hacerlo en la misma DR o en distintas:

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:
a) 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).
b) 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).
c) 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 si alguien tiene dudas:
CPF =Componente principal
CF= Componente secundario