![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
|||
|
|||
|
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.
|
|
#2
|
|||
|
|||
|
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.
|
|
#3
|
||||
|
||||
|
Hola, me he perdido algo?, cuando actualices la aplicación, hay que reiniciar el encadenamiento??
__________________
Uno se alegra de ser útil. (Isaac Asimov) |
|
#4
|
|||
|
|||
|
Cita:
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í. Última edición por Jarogo08 fecha: 30-05-2025 a las 08:17:33. |
|
#5
|
|||
|
|||
|
Cita:
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. |
|
#6
|
|||
|
|||
|
Cita:
Con lo cual cada puesto tiene que llevar su nº de instalación. ![]() |
|
#7
|
|||
|
|||
|
Cita:
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) |
|
#8
|
|||
|
|||
|
Cita:
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. |
|
#9
|
|||
|
|||
|
Cita:
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 |
|
#10
|
|||
|
|||
|
Cita:
Ok, gracias por la puntualización. |
|
#11
|
|||
|
|||
|
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í. Última edición por Rja750 fecha: 30-05-2025 a las 11:18:51. |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Esquema BD | Zina | Varios | 8 | 10-11-2016 17:00:01 |
| Acceso al Esquema de una BD de Oracle | lgarcia | Oracle | 2 | 02-07-2013 15:09:32 |
| Esquema programación. | REHome | Varios | 6 | 12-04-2007 22:03:05 |
| crear archivos esquema *.sch | KmoCuesta | Tablas planas | 0 | 16-09-2005 21:48:05 |
| Saber si existe un tablespace y/o un esquema | Jose Manuel | Oracle | 2 | 17-12-2004 17:13:32 |
|