Bloque del esquema SistemaInformatico
 

Hola,

quería preguntar por los datos a rellenar en la parte de SistemaInformatico.
no me queda claro, entre otros, el campo NumeroInstalacion, como controlarlo en instalaciones locales ? y si se usa en modo web cloud saas ?

¿alguien puede ayudarme con este bloque ?

Muchas gracias

Nosotros por ahora lo estamos rellenando así:

Buenas Neftali, el IdSistemaInformatico son maximo 2 caracteres alfanumericos, en el esquema veo que has puesto 7

muchas gracias por las respuestas

Pero sigo teniendo dudas con nº de instalación, a qué se refiere ? a llevar un contador nosotros de las instalaciones ?

Y si software es en modo web (cloud saas) ?

Hola, es como el numero de serie de cada programa instalado, cada copia que instales/ distribuyas deveria tener el suyo propio.

Y si se trata de un programa que se usa en web a través del navegador que ponemos ?

y en los móviles ?

Hola, en esos casos , quien es el que asigna los números de factura y encadena los datos, el servidor no, pues el número de serie será del servidor, en ese caso el SIF , se considera el conjunto de cliente -servidor.

Tienes razón son 2.
Al intentar modificar algunos datos identificativos que no quería que aparecieran, se me ha ido la mano.

Hola, si el idSistemaInformatico es el identificador de la instalación del programa como puede ser que tenga solo 2 dígitos, no entiendo, ¿si tienes 300 instalaciones como lo haces? ¿codificando en hexadecimal el número?
O no estoy entendiendo el campo o me dejo algo...

Yo entiendo que ese Id es tu número de referencia del programa, es decir, si tienes un ERP de gestión sería el 01, un TPV 02, etc. El que distingue una instalación de otra es Nº de instalación que creo que si debe de ser distinto para cada instalación.


Saludos.

Yo entiendo:
"NombreSistemaInformatico" como el nombre que le damos a nuestro SIF ejemplo "Soluciones gest"
"IdSistemaInformatico" Identifica al SIf ejemplo: Soluciones gest tiene un software que gestiona talleres de mecanica y pintura y su identificador va a ser el 01, tiene otro que gestiona clinicas veterinarias y va a ser el 02 y así hasta 99.
"Version" es el numero de versión que irá en aumento cada vez que compilamos una nueva actualización por implementación de mejoras o adaptación en el código y que en ocasiones está relacionado con el IdSistemaInformatico.
"NumeroInstalacion" es el número de veces que se ha instalado ese SIF con el mismo "NombreSistemaInformatico" y con el mismo "IdSistemaInformatico"
"Soluciones gest" 02 05 310
Esto es: El Software "Soluciones gest" en la especialidad de Veterinaria ha tenido 5 actualizaciones y se ha instalado en distintos clientes 310 veces

Yo no estoy de acuerdo con la interpretación que hacéis del dato "NumeroInstalacion".

Creo que no es necesario informar de cuantas instalaciones de ese SIF has hecho.

En mi caso, todas las instalaciones partirán con NumeroInstalacion=1.
Si el OT, dispone de tiendas no conectadas a la central, y que, por tanto emiten sus propias facturas, todos los datos del bloque "SistemaInformatico" coincidirán, salvo el NumeroInstalación, que será diferente por cada tienda, es decir, si la central tiene el valor 1, la primera tienda tendrá el 2, la segunda el 3, y así sucesivamente.

Pues yo tampoco lo veo así, jeje.

A mi modo de ver, si yo tengo 300 clientes con mi programa, en cada uno de ellos tendré un NumeroInstalacion distinto

Desde VeriFactu me contestaron como generar el Nº de instalación:

Es decir algo como:
OEF + SIF + Version + Timestamp o GUI

Pero de esta respuesta yo entiendo que en el campo NumeroInstalacion sólo deberías poner el Timestamp o GUI. Los otros 3 (OEF + SIF + Version) ya tienen sus propios campos

¿sólo lo veo yo así?

Hola, el numero de instalacion es para poder distinguir univocamente una instalacion(Valga la redundancia), para un Obligado tributario, de un Sistema de Facturacion, que usa, tened en cuenta que si un cliente os compra 100 instancias del programa, todas tendran el mismo NIF de propietario, Probablemente el mismo numero de version y seguro que es mismo identificador de programa, entonces la unica forma de saber que usuario/oficina a emitido que registro de facturacion es el numero de instalacion, podeis asignarle a cada uno que vendais o a para cada cliente reiniciar el numero de instalacion, que a mi forma de ver es la mas sencilla de mantener.
Personalmente he modificado el instalador para que al instalar desde 0 o actualizar una instancia anterior a verifactu existente, me pida un numero de instalacion, que apartir de ese momento se queda asignado en la base de datos, de forma que no pueda ser modificado por el usuario, yo solo tengo 2 instalaciones asi que no tengo problema, pero deveis crear algun tipo de validador que asigne numeros de instalacion a cada uno de vuestros clientes, como os digo preferiblemente numerados desde 1 para cada cliente.

Nosotros lo hacemos por venta... cada programa que vendemos tenemos que ponerle una licencia, y para generar esa licencia tenemos un mantenimiento donde la instalación es clave: 1, 2, 3, etc. Cada programa que vendemos tiene un número distinto, y ese número es el que ponemos en NumeroInstalacion.

Y si un cliente que nos compra el programa va a gestionar 2 empresas (el programa es multiempresa), llevarán las 2 el mismo número. Pero ahí es donde entran los otros campos que se comentaban más arriba (Id.OEF + Id.SIF + VersiónSIF + NºInstalación). El Id del SIF, Versión y Nº Instalación serán el mismo, pero cambiará el Id OEF.

Vale, visto lo que se ha comentado creo que voy a poner el identificador "único" de cliente en NúmeroInstalación, que tiene 100 caracteres y así puedo poner nuestro código de cliente.
NombreSistemaInformático y IdSistemaInformatico será siempre el mismo, el nombre del programa y una abreviación de dos caracteres, ya que solo tenemos un programa que pueda hacer facturas.
En versión pondremos la versión del programa como la usamos nosotros, p.ej. 1.02.32
Creo que con esto será correcto.
¡Muchas gracias por todos los comentarios!

Creo que cada centro de facturación o cliente tendría que tener un numero diferente al resto. Hasta aquí todo estamos de acuerdo, pero este número puede y debe cambiar cuando hacemos una nueva actualizacion al igual que cuando damos de alta un nuevo cliente. Si damos de alta un nuevo cliente sumariamos uno a NumeroInstalacion y cuando actualizamos el software sumariamos uno a la versión. Podemos tener como constantes los campos en tablas "NombreSistemaInformatico" "IdSistemaInformatico" y "NumeroInstalacion". NumeroInstalacion estará identificando a cada cliente como si fuera su ID dentro del SIF. Pero cuando tengamos que actualizar a todos los clientes a la vez tendremos que identificar esa actualizacion y el software tendria que leer la version como variable y asignarsela a los XML´s puesto que se está facturando con un software modificado y diferente al anterior. Solo con modificar un literal en un formulario ya es diferente.

Dudillas
 

En la documentación de "Dudas de los desarrolladores" pone :

Ha de tenerse en cuenta que si se utiliza un SIF que permite llevar distintas
facturaciones, como contempla el artículo 7.a) del RRSIF, cada una de esas
facturaciones distintas (sean de distintos OEF o del mismo OEF pero de distintos
centros de facturación independientes, como tiendas) debe tener un nº de instalación
propio y distinto al resto (pasado, presente o futuro) porque se consideran SIF
independientes, como si fueran “SIF virtuales”, dentro de un producto SIF más
completo que los gestiona y administra.

¿Ósea que no es por instalación es por empresa ?
¿Si en mi aplicación tengo 3 empresas cada una tiene que tener un numero de instalación?


y encima les tengo que preguntar antes si esas empresas que van a hacer SII, Verifactu , tbai o que para poder rellenar "TipoUsoPosibleMultiOT
" y el "IndicadorMultiplesOT"


¿Lo entendéis así?

justo esto me viene al pelo para un problema que me estaba surgiendo, y era como encadenar registros , si había 2 tiendas que usan el mismo SIF, pero el SIF es programa de escritorio (exe hecho con delphi), y la base de datos es local (firebird). Al no poder conectarse una tienda con otra para saber cual ha sido el ultimo registro, la opción era que cada tienda trabajara con una serie distinta, y cada serie llevara un encadenamiento propio. (lo que señalan como 'centros de facturación independientes, como tiendas')
La solución según esta documentación, es utilizar el mismo IdSistemaInformatico y Version, pero distinto NumeroInstalacion, de tal manera que cada tienda lleva su numero de instalación y su encadenamiento.

He hecho las pruebas y efectivamente, si envías con el mismo NifObligado+IdSistemaInformatico+Version, pero distinto NumeroInstalacion, puedes trabajar con encadenamientos distintos

Buenas compañeros, a mi lo que me lleva loco es esta frase de las últimas FAQ de desarrolladores:

"Incluso si se formatea el ordenador donde estaba instalado un SIF y se reinstala el mismo software de nuevo en ese mismo ordenador, el nuevo SIF así constituido debe llevar otro nº de instalación diferente al anterior que tenía, y que no coincida con la de ningún otro SIF de ese OEF (pasado, presente o futuro)."

No entiendo para nada... es como si al reinstalar el programa este fuera otro SIF distinto y tuviera que empezar a encadenar o llevar un encadenamiento propio cuando no es así dado que por ejemplo hemos recuperado una copia del SIF y queremos continuar... En fin ... que retorcidos son estos hijos de p....

Bueno, tampoco creo que puedan saber si el programa se ha reinstalado o no.
A no ser que vayan a mirar las fechas de los archivos en la carpeta del programa, el programa será el mismo, y si has recuperado un backup los datos también...
No le veo ningún tipo de lógica.

Es justo eso lo que quieren que se haga. Si reinstalas o formateas el número de instalación tiene que ser distinto al que tenía antes, con lo cual el encadenamiento tiene que empezar de 0 (lo que significa que el primer registro no irá encadenado a nada)

Lo que se encadena son los registros de facturación por la huella y el registro anterior.
Si mis clientes están trabajando normalmente y yo decido cambiar algún literal del SIF o mostrar la API de otra forma mas clara, tendría que cambiar la versión del SIF porque se ha modificado con respecto al anterior y posteriormente colgar la actualización para que mis clientes se actualicen online, pero sigo encadenando los RF´s igual que antes. El emisor de las facturas no cambia.

Del encadenamiento se hablo en varios hilos, y como bien dijo @sglorka:
Como un SIF se identifica con los 3 parámetros OT+IDISTEMA+IDINSTALACION, la respuesta a la pregunta de cómo hay que encadenar los registros de facturación de un OT sería, por cada SIF que tenga desplegado.

¿ Y que pasa si la empresa cierra por vacaciones 1 mes ?
¿ Como leches van a diferenciar entre una reinstalación, (si se tarda varios días) o un periodo de vacaciones ?

Creo que no tienen forma de saberlo.

No entiendo el tema de vacaciones con la reinstalación.
Yo por ejemplo me guardo en cada equipo un fichero con el nº de instalación, que el nº es el datetime (es uno de los ejemplos que pusieron ellos mismos), ese fichero se crea la primera vez que se genere un RF, mientras el fichero exista sera la misma instalación, en el caso que se formatee o se cambie de equipo, como no encuentra ese fichero se vuelve a crear el nº de instalación.
Y al igual que ese fichero para el nº de instalación tengo otros para saber cual fue el ultimo RF enviado y así realizar el encadenamiento.

Quería hacer referencia a como van a distinguir si se ha producido una reinstalación que, salvo que se haya perdido toda la información, si se recupera todo lo anterior no tienen forma salvo que controlen tiempos de inactividad (de ahí mi comentario de vacaciones). Incluso una reinstalación, puede producirse de una forma rápida, y por tanto veo imposible que se enteren de una reinstalación.

Yo la verdad que estoy releyendo 27 veces todo y no se si cada vez lo tengo menos claro. Solo me faltaría atinar si en una red local donde se instala el programa en el servidor el numero de instalación es la del servidor o en cada puesto que tenga su acceso al servidor es una instalación distinta, ahora mismo despues de las últimas lecturas lo tengo como la última opción, cada puesto que accede al servidor tiene un número de instalación distinta. Así se por OT+IdSistema+Instalación (puesto) quien realiza los envios y cada uno tiene su encadenamiento propio.

Hola, me he perdido algo?, cuando actualices la aplicación, hay que reiniciar el encadenamiento??

Faneka, sólo tiene número de instalación el puesto de trabajo que actúa como un SIF, o sea, si es capaz de emitir, enviar y en su caso, conservar el RF por si sólo. Si necesita estar conectado al servidor central para realizar este proceso, entonces no es un SIF y la línea de encadenamiento de este puesto de trabajo será la del servidor central.
Si el puesto de trabajo o TPV es capaz de generar un RF, enviarlo (aunque lo podría hacer otro subsistema) y en su caso, conservarlo, entonces es un SIF y por ende, debe tener su número de instalación para identificarlo unívocamente y tendrá su propia línea de encadenamiento independiente del servidor central. Si se reinstala el servidor central se cambia su número de instalación pero no el del Tpv(en modo SIF) y viceversa.

Muchas gracias @sglorka, ahora lo tengo claro, nosotros lo tenemos que cada puesto que factura crea el RF, lo envia y guarda tango envios, respuestas, etc.. , no tenemos algo centralizado (un servicio) que reciba las peticiones que se van generando de facturas para crear y enviar los RF.
Con lo cual cada puesto tiene que llevar su nº de instalación.

^\||/

No no... el hecho de actualizar la aplicación no hace que cambie el SIF. Pero el hecho de cambiar de servidor, o de formatear un servidor y tener que volver a poner el programa sí.

Si tienes el programa en el servidor y equipos de la red tiran de él es un único SIF, sólo va a haber un encadenamiento. Por tanto, sólo debería haber un equipo que enviara los datos, porque si cada equipo envía sus registros no vas a cumplir con los 60 segundos de espera entre envío y envío (a no ser que encuentres la manera de solucionarlo, ver quién y cuando envió y esperar)

Nosotros tenemos ERP de escritorio y la mayoría es un equipo el que factura y muchas veces una vez a la semana. En algunas instalaciones si que es de venta al publico en mostrador pero esas son grandes y estan en el SII. No creo que hay problema por eso.
Pero hablando de los 60 segundos, el que tiene que esperar ese tiempo es el OT+ID+NºInstalación supongo, no todas las instalaciones del programa ¿no? eso si que no lo había pensado. Si cada puesto es independiente para el encadenamiento tambien lo debería ser para el flujo de envío, o al menos así lo veo yo.

Sí, claro. Si son SIFs distintos cada uno tiene su flujo. El caso que decía yo es cuando varios equipos de red apuntan a un servidor y es un único SIF

^\||/ Ok, gracias por la puntualización.

Se hace inviable tener varios SIF o líneas de facturación instalado en cada pc con el mismo OT, IdSistemaInformatico, Version y distinto NumeroInstalacion. Esto obligaría a tener numeraciones diferentes en las altas, incluido las rectificativas y aunque tengan la misma BD en la nube esto sería ya el colmo. Creo que este quebradero de cabeza se podría simplificar y que nadie se dará cuenta de, si se ha actualizado el servidor o se ha añadido un nuevo puesto a la red. Si el titular del negocio cierra durante un periodo de tiempo por lo que sea, cuando vuelva a abrir seguirá con el siguiente RF y esto no quiere decir nada(ni que se ha formateado ni se ha defraudado ni nada). Otra cosa seria una nueva instalación de un nuevo OT.
----EDITO
Lo que me choca es la idea de que cada vez que actualizemos tengamos que tener un registro como primer RF sin registro anterior. No le puedo poner sentido comun a esto:
Un OT emite el RF NumSerieFactura = 1, NumSerieFactura =2, NumSerieFactura =3, NumSerieFactura =4 y ese dia actualiza con un nuevo NumeroInstalacion por modificacion del SIF. Cuando procede a emitir un nuevo RF es el NumSerieFactura =5 pero como si fuera el primer RF sin registro anterior. ¿Esto como es así? no le encuentro lógica. Lo único que se me viene a la cabeza es que al haber un salto en la trazabilidad, existe un antes y un después, por si se hubiese tocado para hacer defalcos o algo así.

Es que actualizar la versión del programa no hace que cambie el NumeroInstalacion, o no debería hacerlo. ¿donde habéis leído que tiene que hacer eso?