Nodo SistemaInformatico con varios componentes

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

[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