¶ Histórico de versiones: Vigilante
¶ 14/03/2023
¶ Vigilante
¶ Mejoras
- Cambios en soporte para el validador externo de acceso de Gympass.
- Se provee por parte de Gympass de una nueva API que será la estándar a partir de 2023, funcionando la anterior en transición durante todo 2023.
- Funciona como el protocolo anterior, pero cambiando la configuración de acceso y autenticación a la API.Se define como un nuevo protocolo Gympass 2023 para mantener la compatibilidad con el anterior y poder realizar la transición a los clientes con tiempo, creando una nueva linea en Parametros Validaciones Externa Accesos y pasando el perfil Gympass al nuevo protocolo.
|
[DEPORWIN] [PARAMETROSVALIDACIONEXTERNAACCESOS]
|
| Protocolo = 6 | 'Gympass 2023 |
| URL=https://api.partners.gympass.com/access/v1/validate |
| Usuario= | Valor correspondiente a la cabecera X-Gym-ID que proporciona Gympass para el centro deportivo. |
Password=
Valor del Bearer Token que proporcione Gympass para la validación
| TipoPaseExterno=1 | Parámetro obsoleto en la nueva API (se puede mantener en 1 por compatibilidad) |
| IdConceptoEntradaPuntual= | Al igual que en Gympass anterior, concepto que se usará para generar la entrada que dará acceso si la validación es correcta. Se puede usar el mismo que tuviéramos en el protocolo Gympass previo |
- Nota: A diferencia del Gympass anterior, este no hace check in previo al asignar el perfil a la persona si no que solicita el Gympass ID que nos hayan dado en el alta en Gympass y que veremos en la app instalada en el móvil o en la web de Gympass. El operador deberá entrar este valor al asignar el perfil.
¶ 23/12/2022
¶ Vigilante
¶ Mejoras
- Nuevo validador externo para "Matchpoint" para el protocolo STS3000 con lectores QR.
|
[Puerto p Terminal t]
|
| IdTerminal=IP:puerto | Esta dirección IP podría ser usada en el WebService de Matchpoint para identificar al torno. |
| ValidarAccesoEnValidadorExterno=Si |
| TipoValidadorExterno=Matchpoint |
| URLValidadorExterno=https://cnspadel.matchpoint.com.es/Services/Externos/TInnova/ControlAccesos.svc | Diferente para cada cliente |
| NombreCertificadoValidadorExterno=Ninguno |
| HTTPProxyValidadorExterno=Ninguno |
|
[Puerto p Terminal t Dispositivo d]
|
| ForzarUsarMascaraProximidad=No | Para no enmascarar las lecturas del QR de Matchpoint |
- En los accesos manuales ahora se soportarán los "Validadores externos", de esta manera podremos probarlos sin necesidad de un lector físico. Útil por ejemplo para el validador de acceso externo de "Matchpoint".
- Validación remota de accesos vía DeporNetWS.
- Esta validación remota está especialmente diseñada para el escenario donde DeporWin (y sus correspondientes BB.DD.) están ubicados en la nube (cloud).
- Con especial énfasis a:
1) Seguir dando servicio al control de acceso en los casos en que la conexión al cloud no esté disponible. Realizando una validación local simplificada, por ejemplo, vía listas blancas.
2) No requerir de redirección de puertos ni de uso de VPN - La arquitectura será entonces:
- Un "Vigilante local" ejecutándose en un equipo ubicado en la red local LAN de un determinado centro, que será el encargado de control los distintos elementos hardware (lectores, controladores, tornos,...).
- Este "Vigilante local", al recibir una petición de acceso desde unos de los lectores, solicitará que se realice remotamente la validación de dicho acceso.
- La petición de validación será mediante la llamada al correspondiente método del DeporNetWS (POST /accesos/accesoremoto).
- En una primera fase, el DeporNetWS realizará la validación de dicho acceso mediante una llamada TCP/IP a un "Vigilante remoto", que estará ejecutándose en un equipo ubicado en la propia "nube".
- En una segunda fase, el DeporNetWS realizará la validación de dicho acceso directamente (mediante una nueva implementación nativa de la lógica de acceso).
|
[PUERTO p] del Vigilante Local
|
| ValidarAccesoEnVigilanteRemoto=Si |
| ValidacionPrioritariaEnVigilanteRemoto=Si | ' Indica si un acceso se validará primero en el Vigilante remoto |
| CantidadVigilantesRemotos=1 | ' Cantidad de Vigilantes remotos con los que se intentará validar |
|
[PUERTO p TERMINAL t] del Vigilante Local
|
IdTerminal=xxxx |
' Identificador del terminal (normalmente una dirección IP y puerto, siguiendo la configuración de cada tipo de lector) |
| ValidarAccesoEnVigilanteRemoto=Si |
|
[Puerto p Vigilante Remoto 1] del Vigilante Local
|
| TipoVigilanteRemoto=DeporNetWS | ' (DeporNetWS=validación vía WS, Vigilante=validación clásica vía TCP/IP contra vigilante remoto) |
| URLDeporNetWS=http://dominio:puerto | ' URL del DeporNetWS |
| DesarrolladorDeporNetWS=T-Innova | ' Nombre del usuario para realizar el LoginDesarrollador en el DeporNetWS |
| PasswordDeporNetWS={{3E3A3B5CC401586F65}} | ' Contraseña encriptada del usuario para realizar el LoginDesarrollador en el DeporNetWS |
| HTTPProxyDeporNetWS=Ninguno | ' En caso necesario, proxy para el acceso a DeporNetWS |
| IP=xx.xx.xx.xx | ' Dirección IP local del Vigilante remoto en el cual se validarán los accesos |
PuertoTCP=5010 |
' Puerto TCP del Vigilante remoto (este Vigilante tiene que tener activado el ServidorVigilante) |
| Puerto=5 | ' Puerto de la sección [Puerto ?] del Vigilante remoto que representa a la puerta remota |
| Fotos=NINGUNO | ' NINGUNO si no se tiene ninguna réplica de las fotos de los usuarios en local |
| Alias=VR1 | ' Alias del Vigilante remoto en el cual se validarán los accesos |
|
[PUERTO 5] del Vigilante remoto 1
|
| TipoLector=PUERTA_REMOTA | 'PUERTA_REMOTA (si no queremos mostrar los accesos por pantalla) o VIRTUAL (si queremos ver los accesos por pantalla) |
|
[PUERTO 5 TERMINAL 1] del Vigilante remoto 1
|
| IdTerminal=xxxx | ' Debe coincidir con el identificador del terminal en el Vigilante local ' Los demás parámetros "lógicos" de esta sección serán los que se usarán para la validación del acceso (Tipo de entrada, puerta lógica, coherencias, edades, ...) |
¶ Correcciones
- El la ventana de información de un acceso, al pulsar el botón "Datos Persona", se incluían por error aquellas entradas/bonos que habían sido "anuladas" (sin acceso permitido).
¶ 20/07/2022
¶ Vigilante
¶ Mejoras
- Control de acceso para piscinas de verano:
- Este control de acceso estará basado en controlar el aforo mediante reservas de recursos.
- Es decir, un cliente con derechos de acceso al recinto de la piscina podrá entrar si dispone de una entrada vendida a través de una reserva de recurso.
- Para clientes con derecho de acceso al recinto pero que no dispongan de reserva previa (por ejemplo, clientes abonados o clientes con bono de X usos para todo el verano), podrán entrar siempre y cuando todavía haya disponibilidad del recurso. En ese caso se les autogenerará una reserva.
- Para esos clientes con derecho de acceso sin reserva previa, tendremos la opción de "prereservar" un número de plazas concretas con el objetivo de garantizarles un servicio mínimo (configurable desde ReserWin por recurso).
- Para los clientes que compren una entrada presencial sin reserva directamente en la recepción de la piscina, igualmente tendremos la opción de "prereservar" un número de plazas concretas con el objetivo de garantizarles un servicio mínimo (configurable desde ReserWin por recurso).
- Adicionalmente, para poder optimizar la ocupación del recinto, tendremos la opción de liberar la plaza cuando un cliente realice la salida. Para ello, esencialmente se recortará la hora de finalización de la reserva automáticamente.
|
[Puerto p Terminal t]
|
| ClientesConPermisoAccesoRequierenReserva=Sí | Indica si los clientes con permiso de acceso (abonados, bonos, ...) requieren haber reservado para poder acceder |
| ClientesConPermisoAccesoAutogeneranReserva=Sí | Indica si a los clientes con permiso de acceso (abonados, bonos, ...) sin reserva previa se les autogenerará una |
| LiberarPlazaReservaEnSalida=Sí | Indica si se liberará la plaza de la reserva en los accesos de salida. |
- En los protocolos vía COM Remoto (por ejemplo, un PCR300), si activamos el KeepAliveCOMRemoto, ahora se forzará una reapertura del puerto de comunicaciones en los casos que se detecte un cierre de dicho puerto.
- Ejemplo 1, si se pierde la red en el lado del PC del ComRemoto, cuando vuelva la red el Vigilante será capaz de recuperar la comunicación automáticamente.
- Ejemplo 2, si se pierde la red en el lado del servidor donde esté el Vigilante, cuando vuelva la red, el Vigilante avisará de error de conexión y para recuperarla solamente necesitamos pasar una tarjeta por el lector o bien usar la opción "Cerrar comunicaciones y pasar a modo escucha" del ComRemoto.
- Ahora podremos tener la configuración del Vigilante en ficheros separados, de tal manera que tendremos un fichero para la configuración "Técnica" y otro para la configuración de "Lógica de acceso".
- Por ejemplo, esta configuración separada nos será de utilidad cuando haya dos equipos/personal de implantación del Vigilante.
- Podremos migrar automáticamente a esta nueva configuración ejecutando el Vigila.exe (desde el entorno que deseemos migrar) con el parámetro /MigrarConfiguracionTecnicaYLogica.
- Esta migración automática dejará una copia de seguridad del antiguo fichero Vigila.ini, en el entorno correspondiente y con el nombre Vigila_Backup_20220627_135305.ini (los números corresponden a la fecha y hora del momento de la migración).
- También dejará un fichero VigilaParametrosNoUsados.INI correspondiente con aquellos parámetros del antiguo fichero Vigila.ini que el Vigilante no está usando (ya sea por qué estaban comentados o por qué no aplicaban según otros parámetros).
|
Vigila.ini [Parametros]
|
| ConfiguracionTecnicaYLogicaSeparada=Si | Indica si la configuración técnica y la configuración de la lógica de acceso están separadas en los ficheros VigilaTecnica.ini y VigilaLogica.ini |
|
VigilaTecnica.ini
|
| ... | En este fichero estarán todos los parámetros que tienen que ver con la configuración técnica/hardware del control de acceso |
|
VigilaTecnica.ini [Puerto P Terminal T]
|
| IdLogica=X | Identificador de la lógica de acceso vinculada a este terminal. Correspondiente a la sección [Logica X] en el fichero VigilaLogica.ini. Si no se informa este parámetro se supondrá que la lógica estará en la sección [Logica Puerto P Terminal T] del fichero VigilaLogica.ini |
|
VigilaLogica.ini
|
| ... | En este fichero estarán todos los parámetros que tienen que ver con la configuración de la lógica de acceso |
|
VigilaLogica.ini [Logica Comun]
|
| ... | En esta sección estarán todos los parámetros comunes a las distintas lógicas, de tal manera que en la sección [Logica X] solamente estarán aquellos parámetros específicos de esa lógica o los que no comparta valor con la lógica común. |
- Ahora tendremos la opción de generar un fichero de ayuda de los parámetros de configuración, para ello ejecutaremos el Vigila.exe (desde el entorno que deseemos) con el parámetro /GenerarFicheroAyudaConfiguracion.
- Aplicable tanto con un fichero Vigila.ini como cuando tenemos la configuración separada en VigilaTecnica.ini y VigilaLogica.ini
- Los ficheros generados tendrán el mismo nombre que los originales pero con el sufijo "_Ayuda" (por ejemplo VigilaLogica_Ayuda.INI)
- Ahora si ejecutamos la aplicación Vigila.exe desde un entorno sin configuración (ya sea en el propio entorno o en la raíz) ya NO se nos preguntarán los parámetros de configuración uno por uno. Sino que se crearán automáticamente con su valor por defecto.
- Coherencia de accesos por IdPersona
- Nueva funcionalidad para comprobar que la persona que está accediendo NO esté dentro del recinto independientemente de cómo acceda, ya sea con un carné de persona o con carné de entrada.
- Útil, por ejemplo, en las reservas de piscinas de verano (no anónimas) donde se ha generado una entrada para cada integrante y además los integrantes disponen también de un carné personal. De esta manera se evita que un mismo integrante tengo dos accesos para entrar.
- No aplicable a accesos de salida
- No aplicable a accesos de entidades
|
[Puerto P Terminal T]
|
| ComprobarAccesosCoherentesPorIdPersona=Verdadero | Indica si se comprobará que la persona que está accediendo NO esté dentro del recinto independientemente de como acceda (con carné de persona o con carné de entrada) |
¶ Correcciones
- Cuando se vincula un terminal Virtual con un terminal de un STS (habitualmente para reaprovechar una misma electrónica para entrada y salida) si se realizaban lecturas por el terminal vinculado durante la inicialización del Vigilante, se producía un "Error 91: La variable de tipo Object o la variable de bloque With no está establecida".
¶ 06/04/2022
¶ Vigilante
¶ Mejoras
- Adaptación del Vigila.exe para poder iniciarlo cómo un servicio Windows mediante la utilidad NSSM.exe
- Instalaremos el servicio mediante la utilidad NSSM.exe (ubicada en C:\Deporwin\Instalacion), indicando que arranque el Vigila.exe con el parámetro /Invisible (además de los parámetros para autologin).
¶ Correcciones
- En el cálculo de los permisos de acceso con origen "servicios NMS", las restricciones de "número máximo de usos en intervalo" y "tiempo máximo de estancia en intervalo" no funcionaban correctamente si el intervalo definido era diferente a "Diario", "Semanal" o "Mensual".
- Al utilizar el nuevo sistema de licencias, si existía un problema de conexión a base de datos (por conectividad, reinicio del servicio SQL, etc) se podía producir una excepción que provocaba el cierre abrupto de la aplicación.
- Se estaba permitiendo registrar más de 1 dispositivo mediante SmartTagQR para la misma persona. A partir de ahora, se eliminará cualquier dispositivo previo antes de añadir el nuevo.
- Si no se tenía activado el parámetro "MultiCarnetsPersonas", la verificación de puntos de licencia de SmartTag QR no se realizaba correctamente, ya que en ese caso no se contabilizan los carnés SmartTag QR guardados en la tabla "Carnets".
¶ 10/11/2021
¶ Vigilante
¶ Mejoras
- Cambios en la validación externa de accesos con el protocolo de "Ayuntamiento de Vitoria" para soportar códigos QR.
- Nueva funcionalidad para arrancar un Vigilante en un entorno en "Modo Virtual".
- Podremos arrancar un Vigilante con la misma configuración que tengamos en el entorno, excepto que todos los puertos serán considerados virtuales. Es decir, como si en el Vigila.ini todos los [Puerto p] tuvieran el TipoLector = VIRTUAL.
- Para ello ejecutaremos el Vigila.EXE con el parámetro /Virtual.
- Y se mostrará en la barra de título del Vigilante que estamos en este modo especial con el texto "(Modo: VIRTUAL)".
- Los mensajes de error en la inicialización de los protocolos STS3000, Gantner, Kimaldi KXP y BioMax ahora se mostrarán temporizados a 5 segundos. De esta manera no se impide la inicialización completa del Vigilante.
- Soporte en la BioMax2 de lectores QR/RF RS232 para la lectura de tags RFID, Código de Barras, QR estáticos y QR dinámicos del SmartTag QR.
- En la BioMax2 hay que configurar la UART donde esté conectado el lector para que soporte 115200 baudios con FIM (para 0x8C)
¶ 06/08/2021
¶ Vigilante
¶ Mejoras
- Soporte del dispositivo bluetooth QRv3 DRT para la lectura vía buffer de teclado de carnés RFiD y/o códigos QR.
|
[Puerto p]
|
| TipoLector=TECLADO |
|
[Puerto p Terminal t]
|
| CodigoInicioTramaTeclado=0 |
| CodigoFinTramaTeclado=13 |
| PermitirLecturasSmartTagQR=Sí | Sí queremos permitir la lectura de códigos QR dinámicos del SmartTag QR |
- Adaptación del proceso de grabación de biometría en los terminales Gantner para que sea compatibles tanto con GATAccess6100Enroll como con GT7Enroll.
- El protocolo de lectores por interfaz de teclado (TipoLector=TECLADO) ahora soporta grabación.
¶ Correcciones
- Corrección en la lectura del parámetro CampoBusquedaPersona, ahora soporta el valor "FormatoPropio_O_NumeroCarnet" además del incorrecto "FormartoPropio_O_NumeroCarnet".
¶ 26/03/2021
¶ Vigilante
¶ Mejoras
- Ahora no será necesario activar MultiCarnetsPersonas para el uso de carnets SmartTag QR.
De esta forma, un cliente que use sólo SmartTag QR como otro tipo de carnet + SmartTag QR podrá realizarlo sin necesidad de activar MultiCarnetsPersona
¶ Correcciones
- Al leer el parámetro "ComprobarAccesoPermitidoPersonaParaGenerarEntradaPuntual" del Vigila.ini se producía un error de "No coinciden los tipos".
¶ 10/11/2020
¶ Vigilante
¶ Mejoras
- En las grabaciones de SmartTag QR desde el Vigilante, ahora se avisará al operador cuando queden 10 o menos grabaciones disponibles.
- Ahora podremos definir el aforo de un recinto directamente desde "DeporWin -> Mantenimiento -> Tablas auxiliares -> Recintos".
- De esta manera no será necesario informarlo en el Vigila.ini (sección [Recinto r] campo "Aforo").
- Por compatibilidad, si en la tabla "Recintos" el aforo está a 0, se seguirá usando el aforo definido en el Vigila.ini
- WatchDog para STS
- Módulo independiente que getionará las electrónicas STS en el caso de caída del Vigilante
|
[Parametros]
|
| NivelWatchDog=1 | ¿Usar un WatchDog? 0-No, 1-Solo si Vigilante no responde, 2-Siempre |
| IPWatchDog=x.x.x.x | IP del WatchDog |
| PuertoWatchDog=5000 | Puerto UDP del WatchDog |
- Si está activado el parámetro MultiCarnetsPersonas, al grabar un carnet de persona se grabará como carné principal en la propia ficha de la persona, moviendo el existente a la tabla Carnets, excepto en el caso de que sea un SmartTagQR o un carné acompañante que siempre se grabarán en la tabla Carnets.
¶ Correcciones
- Al realizar una regularización del aforo desde el Vigilante, si existía un hueco en la codificación de puertas, la regularización se realizaba sobre un código de puerta incorrecto (por culpa del decalaje).
- Si una persona tenía contratado un servicio (NMS) no renovable, no se le permitía el acceso en el último día del periodo de contratación.
- Al calcular los orígenes de acceso posibles por "Reservas de Recursos" (CalcularOrigenesPosiblesReservas), si la reserva estaba dentro de una transacción pendiente de cerrarse (por ejemplo, en medio de un proceso de reserva en DeporSite), se le permitía el acceso con dicho origen.
¶ 29/06/2020
¶ Vigilante
¶ Mejoras
- Los mensajes de error de "No se ha podido abrir el puerto COM" y el de "La conexión ha sido rechazada por el COMRemoto" ahora se mostrarán temporizados a 5 segundos. De esta manera no se impide la inicialización completa del Vigilante.
- En el protocolo STS3000, ahora se controlarán de grabaciones de SmartTag QR vía el nuevo sistema de licencias por puntos.
- SmartPanel QR
- Nuevo protocolo para la lectura/grabación de códigos QR vía SmartPanel.
- Para invocar una lectura de QR lo realizaremos mediante el mecanismo de "Abrir Puerta".
- Será necesario una licencia de SmartQR para poder usar este nuevo protocolo.
- Además, este protocolo es compatible con códigos QR dinámicos generados desde la App SmartTag QR.
- En este caso será necesario también una licencia de SmartTag QR. Y, adicionalmente, se controlarán de grabaciones de SmartTag QR vía el nuevo sistema de licencias por puntos.
|
[Puerto p]
|
| TipoLector=SMARTPANELQR | SMARTPANELQR o SMARTQR |
|
[Puerto p Terminal t]
|
PermitirLecturasSmartTagQR=Sí |
Indica si este terminal podrá procesar lecturas de códigos dinámicos QR generados por la aplicación móvil SmartTag QR |
| TiempoMaximoValidezSmartTagQR=7 | Tiempo máximo validez (en segundos) entre la generación de un código dinámico QR y el uso de dicho código |
- En los accesos de "Entradas/Bonos" que provienen de una reserva de recurso, ahora se tendrán en cuenta los permisos de accesos definidos en el recurso.
- En este caso lo habitual será que, el tipo de entrada definido en el concepto que se usó en la venta de la reserva, no tenga definida ninguna matriz de accesos (puertas/días/horas). Y dicho tipo de entrada tendrá definida una validez "heredada" para que coincida con la fecha de la reserva.
- Se registrará en accesos detallados, la información sobre qué reserva de recurso a permitido el acceso.
- Desde "DeporWin -> Fichas -> Personas -> Accesos" se mostrará información de estos accesos con el número de la Entrada/Bono así como el número de la reserva de recursos.
|
[Parametros]
|
| CalcularOrigenesPosiblesReservas=Sí |
- Nuevo protocolo en STS3000 para el dispositivo HCCTG HM20:
- Lector de códigos QR
- Lector de códigos de barras 2D
- Lector de tags RFID de 125 KHz (para el modelo HM20-ID)
- Lector de tags RFID Mifare (para el modelo HM20-IC)
|
[Puerto p Terminal t Dispositivo d]
|
| TipoDispositivo=HCCTG HM20 | HM20 o HM20-ID o HM20-IC |
¶ 26/02/2020
¶ Vigilante
¶ Mejoras
- En el protocolo de terminales Flexy TOC de Kimaldi, ahora podremos definir el umbral (nivel de seguridad) para identificaciones (1:N) así como el umbral (nivel de seguridad) para verificaciones (1:1).
|
[Puerto p]
|
| UmbralIdentificacion=6 | umbral para identificaciones (1:N). Valores desde 6 hasta 9 |
| UmbralVerificacion=5 | umbral para verificaciones (1:1). Valores desde 1 hasta 9 |
- SmartTag QR
- Nuevo sistema de control de acceso mediante una App en un dispositivo móvil (compatible con iOS y Android)
- La App SmartTag QR generará un código QR dinámico que se usará como carné de acceso.
- El código QR es dinámico para evitar que éste pueda ser copiado y/o traspasado entre usuarios.
- Como dispositivo de control de acceso, usaremos un terminal STS3000 con un lector de códigos QR capacitado para leer pantallas de móvil.
|
[Puerto p]
|
| TipoLector=STS3000 |
|
[Puerto p Terminal t]
|
| PermitirLecturasSmartTagQR=Sí | Indica si este terminal podrá procesar lecturas de códigos dinámicos QR generados por la aplicación móvil SmartTag QR |
| TiempoMaximoValidezSmartTagQR=7 | Tiempo máximo validez (en segundos) entre la generación de un código dinámico QR y el uso de dicho código |
|
[Puerto p Terminal t Dispositivo d]
|
| TipoDispositivo=GenericReader |
| FormatoTrama=<DATA> | Según lector QR |
- Nueva funcionalidad para denegar el acceso (a nivel de terminal) a determinadas personas según su perfil.
- Nos puede ser útil para impedir el acceso por perfil a una puerta concreta (por ejemplo, por una sanción), mientras que esas mismas personas puedan entrar por otras puertas.
|
[Puerto p Terminal t]
|
| PerfilesDenegados=31,36 | 'Lista de códigos de perfil a denegar el acceso (separada por comas). Valor por defecto NINGUNO (es decir, no se denegará el acceso a las personas por este motivo independientemente de los perfiles que tengan). |
¶ Correcciones
- En el protocolo de autentificación 1:N de los terminales Flexy TOC de Kimaldi, fallaba el proceso de grabación de nuevas huellas cuando el terminal grabador tenía ya almacenadas muchas huellas (en torno a 2000).
- Al mostrar la ocupación (ya fuera por recintos o por orígenes), no se tenía en cuenta si los accesos de empleados computaban o no en función de lo configurado en cada recinto.
¶ 28/11/2019
¶ Vigilante
¶ Correcciones
- Desde el vigilante se estaba inicializando por error la nueva librería DeporJet, que en determinadas circunstancias provocaba un error en el arranque del propio Vigilante.
¶ 21/11/2019
¶ Vigilante
¶ Mejoras
- Nuevo protocolo de autentificación en los terminales Flexy TOC de Kimaldi
- El protocolo de autentificación recomendado continua siendo el de "Verificación 1:1", es decir, la huella solamente está almacenada en la tarjeta Mifare del usuario (TOC: Template on card), el usuario presenta su tarjeta y se realiza una verificación directa con dicha huella.
- Ahora soportamos el protocolo de autenticación de "Identificación 1:N", es decir, el terminal tiene una BB.DD. con las huellas de los usuarios, el usuario presenta su huella y el terminal la identifica dentro de las N huellas almacenadas.
- En este caso, al estar almacenada la huella del usuario en BB.DD, se requerirá de un consentimiento explícito del usuario (RGPD)
|
[PUERTO P]
|
| TipoLector=KXP | ' Protocolo de comumicaciones KXP de Kimaldi |
| CalidadMinimaGrabacion=80 | ' Calidad mínima de grabación (valor de 0 a 100). 0=Desactivado |
|
[PUERTO P TERMINAL T]
|
| IdTerminal=x.x.x.x:6000 | ' Dirección IP del terminal Flexy y puerto UDP (6000 por defecto) |
| TipoTerminal=FLEXYTOC |
| ProtocoloAutentificacion=1 | ' 1=Identificación, 2=Verificación. |
| GrupoSincronismo=A | ' Grupo de sincronismo de las huellas |
| SincronizarFingerTemplates=Sí |
| PermitirDescargarBBDDFingerTemplates=Sí | ' Si permitimos o no descargar BB.DD. en este terminal. |
- Ahora podremos conectarnos a puertos COM procedentes de conversores USB-Serie, usando un patrón del nombre del dispositivo USB-Serie.
- De esta manera, los cambios del número del puerto COM que se produzcan (por ejemplo, al desconectar y volver a conectar el dispositivo en otro puerto USB) no afectarán a la configuración.
- Esta configuración del puerto COM vía un patrón del nombre del dispositivo, nos servirá tanto para puertos locales como para puerto remotos vía "COM Remoto".
- Hay que tener en cuenta que esta configuración NO funcionará si tenemos más de un adaptador USB-Serie del mismo tipo/fabricante en una misma máquina.
- Por ejemplo, para un conversor "Prolific USB-to-Serial Comm Port" que en el administrador de dispositivos se muestra así, lo configuraríamos de esta manera:
|
[Puerto P]
|
| PuertoCOM=PROLIFIC USB-to-Serial Comm Port (COM*) EN IP:Puerto | *: Comodín para autodetectar el número del puerto COM, IP: IP donde se ejecuta el COM Remoto, Puerto: Puerto TCP que escucha el COM Remoto |
¶ 10/07/2019
¶ Vigilante
¶ Mejoras
- Nuevo protocolo para los terminales Flexy TOC (Template on card) de Kimaldi
- Se permite la grabación de tarjetas para usuarios con o sin huella.
- Se permite la grabación de tarjetas para entradas/bonos (sin huella en este caso).
- La huella solamente se almacenará en la tarjeta Mifare del usuario (por lo que no se requerirá de consentimiento RGPD).
|
[PUERTO P] |
| TipoLector=KXP | ' Protocolo de comumicaciones KXP de Kimaldi |
| NumeroSectorTOC=1 | ' Número del sector inicial. 1 por defecto |
| ClaveTOC=FFFFFFFFFFFF | Clave para hacer el login en los datablock Mifare (FFFFFFFFFFFF por defecto) |
| CalidadMinimaGrabacion=80 | ' Calidad mínima de grabación (valor de 0 a 100). 0=Desactivado |
|
[PUERTO P TERMINAL T]
|
| IdTerminal=x.x.x.x:6000 | ' Dirección IP del terminal Flexy y puerto UDP (6000 por defecto) |
| TipoTerminal=FLEXYTOC |
| ProtocoloAutentificacion=2 | ' Verificación |
- Al realizar un acceso con un carné de persona, si éste le consume una "entrada/bono" y el concepto de la "entrada/bono" tiene una imagen asociada, ésta se mostrará en vez de la foto de la persona.
- Aplicable tanto para el Vigilante como para el Monitor del Vigilante.
- Ahora, el cálculo de los permisos de acceso con origen "entrada/bono" tendrán en cuenta las entradas/bonos que hayan sido venidas y prestadas dentro de una reserva/planificación de programa.
¶ Correcciones
- Al realizar una búsqueda de personas desde el Vigilante, ya sea al realizar un acceso manual como al grabar un carné, se producía un error "Error 91: La variable de tipo Object o la variable de bloque With no está establecida".
¶ 03/05/2019
¶ Vigilante
¶ Mejoras
- Nueva función para ignorar el "Acceso Ilimitado" de una persona en determinados terminales.
- Nos puede ser útil por ejemplo para terminales tipo "Máquina de bebidas", "Parking", ...
|
[PUERTO P TERMINAL T]
|
| IgnorarAccesoIlimitado=Sí |
- Nueva funcionalidad en los "Terminales en modo de consulta" para mostrar los perfiles de una persona.
|
[PUERTO P TERMINAL T]
|
| TerminalConsulta=Sí |
| TerminalConsulta_MostrarPerfiles=Sí |
| Perfiles=TODOS | Lista separada por comas de los códigos de perfil de la persona que se desean mostrar. |
- Nuevas restricciones funcionales por grupo de operadores para:
- Permitir realizar accesos manuales (REALIZAR ACCESO MANUAL)
- Permitir aperturas manuales (ABRIR PUERTA) con dato "Puerto Terminal"
- Se registrará en la vulneración de dichas restricciones a qué IdAcceso corresponden.
- Soporte para el validador externo de acceso de DeporPass. Este protocolo es similar a GymPass y GymForLess, cambiando los parámetros de validación.
- Definimos un concepto correspondiente a la entrada puntual que se generará para poder acceder en caso de validación correcta.
- Definimos un nuevo perfil "DeporPass" vinculándole unos "ParametrosValidacionExternaAccesos".
- Proceso de "Check-in" nueva persona: En DeporWin, al realizar una búsqueda de una persona tendremos la opción de buscar en DeporPass. Se solicitará en qué perfil "DeporPass" buscar (por si tenemos más de un servicio DeporPass, por ejemplo 1 por centro), el código de la persona, el DNI y el correo electrónico. Se realizará la búsqueda según los parámetros introducidos en el DeporWin remoto asociado al perfil "DeporPass" y se mostrarán las personas resultantes. Al seleccionar una de ellas, se importará automáticamente dicha ficha.
- Proceso de "Check-in" persona existente: Si ya tuviéramos una ficha en DeporWin de la persona, al asignarle el perfil "DeporPass" se invocará el mismo procedimiento anterior (con los datos de búsqueda auto rellenados).
- Proceso de "Acceso": Al acceder el cliente, si no tiene nada contratado que le otorgue acceso (por esa puerta/fecha/hora), se validará el acceso en DeporPass.
- La validación remota en DeporPass, se realizará mediante la llamada al servicio web de DepornetWS v2 "POST /accesos/accesoexterno".
- A su vez, este servicio web, delegará la validación al procedimiento almacenado de SQL Server "_ValidarAccesoExterno" donde deberá implementarse los criterios de validación personalizados que se deseen. Para ello dicho procedimiento recibirá los parámetros de entrada: @IdPersona, @IdCentroExterno (se obtiene del campo AbreviaturaCodigo del centro vinculado al recinto de acceso), @IdPersonaExterna, @IdRecintoExterno, @IdPuertaExterna, @IdAccesoExterno, @Fecha, @Hora, @NumeroCarnet, @TipoAcceso y retornará los parámetros de salida: @AccesoCorrecto, @Error, @Motivo, @IdPuerta.
- Además, el servicio web registrará en la tabla AccesosExternos (en la BB.DD. de Accesos) las peticiones atendidas por dicho web services.
|
[DEPORWIN] [PARAMETROSVALIDACIONEXTERNAACCESOS]
|
| Protocolo=4 | DeporPass |
| URL= http://IP:puerto | URL del servicio web DepornetWS v2 |
| Usuario= | Usuario del servicio web DepornetWS v2 |
| Password={{xxxxx}} | Password del usuario del servicio web DepornetWS v2. Se aconseja guardarlo encriptado {{ }} |
| IdConceptoEntradaPuntual= | El código del concepto correspondiente a la entrada puntual que se generará para poder acceder en caso de validación correcta. |
|
[PUERTO P TERMINAL T]
|
| GenerarEntradaPuntualPersonasSinPermisoAccesoEnValidadorExternoSegunPerfilesPersona=Sí |
| ComprobarAccesoPermitidoPersonaParaGenerarEntradaPuntual=Sí | Indica si se tiene en cuenta el acceso permitido de la persona |
¶ 11/02/2019
¶ Vigilante
¶ Mejoras
- Al realizar un acceso de una persona cuyo origen sea de una inscripción puntual a actividades dirigidas (Reserclass), si la reserva tiene asignado un elemento (por ejemplo, para spinning, un número de bicicleta):
- Se informará en el Vigilante de dicho número en la descripción detallada del acceso.
- Y, además, si el acceso lo estamos realizando desde un terminal Gantner, se mostrará en su Display dicho número (entre corchetes al inicio de la descripción del acceso). Tanto en los accesos correctos como en los incorrectos.
- Y en el caso de tener configurado el "last minute" en Reserclass, se asignará automáticamente un elemento (el primero libre respetando el orden).
- Ahora registraremos el tiempo en milisegundos que se ha empleado en la procesar la lógica de los permisos de acceso.
- Se guardará en el campo TiempoProcesamientoLogicaAcceso de la tabla Accesos
- Se mostrará en el vigilante en el tooltip del icono que indica entrada/salida, así como en la grid de accesos.
- El nombre del fichero del log del Vigilante (guardado en C:\DeporWin\Logs\Vigilante) ahora contendrá el nombre del entorno (Vigilante_Entorno_Fecha.log).
- En la validación externa de accesos a Gympass/GymForLess, ahora podremos asociar un centro en los "parámetros de validación externa de accesos".
- De esta manera tendremos la posibilidad de que una persona tenga asociado más de un perfil (incluso con parámetros del mismo tipo de protocolo) cada uno vinculado a un centro.
- Para su correcto funcionamiento tendremos que tener definidos los recintos de acceso asociados a sus correspondientes centros.
- En el "nuevo sistema de control de acceso para acompañantes", ahora podremos limitar la cantidad máxima de accesos "por acompañamiento" que pueda realizar un acompañante al día.
|
[Puerto p Terminal t]
|
| CantidadMaximaAcompañamientosPorDia=0 | Indica la cantidad máxima de accesos "por acompañamiento" que pueda realizar un acompañante al día (0=Ilimitados) |
¶ Correcciones
- Se producía "Error 94: Uso no válido de Null" al comprobar la validez de entradas generadas con un tipo de entrada cuyo periodo de validez estaba definido como absoluto y sin haber especificado una fecha de finalización. Ahora se considerarán válidas in aeternum.
¶ 10/08/2018
¶ Vigilante
¶ Mejoras
- Soporte para el validador externo de acceso de Gympass
- Definimos un concepto correspondiente a la entrada puntual que se generará para poder acceder en caso de validación correcta.
- Definimos un nuevo perfil "Gympass" vinculándole unos "ParametrosValidacionExternaAccesos".
- Proceso de "Check-in": Al asignarle el perfil a un cliente, se solicita el "número del pase" y se valida con Gympass, guardándonos un "token" que se usará para validar los accesos posteriores.
- Proceso de "Acceso": Al acceder el cliente, si no tiene nada contratado que le otorgue acceso (por esa puerta/fecha/hora), se validará el acceso en Gympass.
- Proceso de "Acceso": Si falla la validación en Gympass, se registrará un acceso incorrecto con error nº 15 y se registrará en el log del Vigilante los detalles de la comunicación.
|
[Puerto p Terminal t]
|
| GenerarEntradaPuntualPersonasSinPermisoAccesoEnValidadorExternoSegunPerfilesPersona=Sí |
| ComprobarAccesoPermitidoPersonaParaGenerarEntradaPuntual=Sí | ' Indica si se tiene en cuenta el acceso permitido de la persona |
|
[DeporWin] [ParametrosValidacionExternaAccesos]
|
| Protocolo=2 | ' Gympass |
| URL=https://api.gympass.com/es/transacciones/validar_numero.json |
| Usuario= | ' Valor correspondiente a gym_number de Gympass |
| Password= | ' Valor correspondiente a auth_token de Gympass |
| TipoPaseExterno=1 | ' Valor correspondiente a pass_type_number de Gympass |
| IdConceptoEntradaPuntual= | ' El código del concepto correspondiente a la entrada puntual que se generará para poder acceder en caso de validación correcta. |
- Soporte para el validador externo de acceso de GymForLess. Este protocolo es similar a GymPass, cambiando los parámetros de validación.
|
[Puerto p Terminal t]
|
| GenerarEntradaPuntualPersonasSinPermisoAccesoEnValidadorExternoSegunPerfilesPersona=Sí |
| ComprobarAccesoPermitidoPersonaParaGenerarEntradaPuntual=Sí | ' Indica si se tiene en cuenta el acceso permitido de la persona |
|
[DeporWin] [ParametrosValidacionExternaAccesos]
|
| Protocolo=3 | ' GymForLess |
| URL Producción=https://api.gymforless.com/api/public/v1/affiliation |
| URL Pruebas=https://gymforless-staging.herokuapp.com/api/public/v1/affiliation |
| Usuario= | 'Identificador del centro de GymForLess |
| Password= | ' Valor correspondiente al token de autorización de GymForLess |
| IdConceptoEntradaPuntual= | ' El código del concepto correspondiente a la entrada puntual que se generará para poder acceder en caso de validación correcta. |
- Al realizar una grabación de biometría, ahora se verificará que el usuario haya OTORGADO el consentimiento de "Almacenar sus datos biométricos".
- Protocolos STS3015, Sagem MorphoAccess, Sagem MSO, Gantner, Nitgen FDU y Handkey Remoto.
¶ Correcciones
- El lector PCR300 no emitía señal sonora al realizar una grabación.
¶ 19/04/2018
¶ Vigilante
¶ Mejoras
- En el cálculo de los permisos de acceso con origen "servicios NMS multicentro" y "tipo de acceso multicentro", se tendrán en cuenta las puertas de acceso en función del centro de contratación.
- En el cálculo de los permisos de acceso con origen "servicios NMS" se tendrán en cuenta las restricciones de "número máximo de usos en intervalo" y "tiempo máximo de estancia en intervalo" asociadas a cada puerta.
- Si se incumple alguna de estas restricciones, el Vigilante informará de ello.
- Aún así se podrá permitir manualmente un acceso (activando un acceso ilimitado puntual).
- Ahora, al tener activada la matriz dinámica de permisos de accesos, se priorizarán los intervalos de acceso de los cursillos que no tengan restringidos los usos/periodo.
- En el cálculo de los permisos de acceso con origen "servicios NMS" se tendrán en cuenta los permisos para el estado de contratación "Baja temporal".
- En los lectores biométricos de Sagem MorphoAccess SIGMA, ahora soportamos el TipoTerminal=SIGMA o TipoTerminal=SIGMAPLUS, para 10.000 huellas o para 50.000 huellas respectivamente.
- En los lectores biométricos de Sagem MorphoAccess MA300, MA500 o SIGMA, si se intenta grabar una huella sobre una ficha de usuario que ya tuviera otra huella grabada, se borrará dicha huella antes de iniciar el proceso de Enroll. De esta manera, facilitamos la regrabación de huellas.
.jpg "DeporNews")
- En el cálculo de los permisos de acceso con origen "servicios NMS" se tendrán en cuenta las cesiones de permisos de acceso realizadas en los contratos de servicio.
- Durante el periodo de vigencia de una cesión de permisos de acceso, el usuario del contrato no podrá acceder. Y su vez, la persona que reciba la sesión podrá acceder con los mismo horarios, puertas y limitaciones que le otorgaba el contrato de servicio.
- En el sistema IQ - Touch & Bebida con identificación biométrica con lectores STS3015, no se sincronizaban las huellas recién grabadas.
- En el protocolo STS3000, no se aplicaba la máscara de proximidad para los dispositivos MF7.
¶ 24/01/2018
¶ Vigilante
¶ Mejoras
- En el cálculo de los permisos de acceso con origen "servicios NMS multicentro" se tendrá en cuenta los horarios específicos del centro (de dicho servicio) correspondientes al centro del contrato.
- En los lectores de proximidad y biometría de Gantner GATAccess ahora se soporta la lectura de tags Mifare con UID de 7 bytes.
- Se recomienda no usar máscara y longitud mínima 16.
¶ Correcciones
- No se controlaba correctamente el "número de máximo de usos en un periodo" o el "tiempo máximo de estancia en un periodo" para los orígenes de acceso de un Servicio NMS.
- En el supuesto de NO comprobar la coherencia de accesos, no se permitía la salida a un usuario si éste se identificaba con su carné de persona y solamente tenía permiso de acceso por disponer de una entrada/bono, y además, no había realizado con anterioridad el acceso de entrada.
¶ 11/10/2017
¶ Vigilante
¶ Correcciones
- Bug en bonos de más de un uso para CTA3000 se capturaba siempre en primer uso.
- Si teníamos definido el parámetro "IgnorarAccesoPermitido", se ignoraba correctamente la marca de "acceso permitido" de la persona, pero no se cargaban los orígenes de acceso (para el caso de matriz dinámica), con lo que finalmente obteníamos un error de "Puerto incompatible" u "Horario incompatible".
¶ 21/06/2017
¶ Vigilante
¶ Mejoras
- El sistema IQ - Touch & Bebida ahora soporta identificación de teclado con lectores STS3015
- Soporte de los nuevos lectores de Sagem MorphoAccess SIGMA.
|
[Puerto p]
|
| NumeroTemplatesPorPersona=2 | ' Obligatorio |
|
[Puerto p Terminal t]
|
| TipoTerminal=MA500P |
| ProtocoloAutentificacion=1 | ' Identificación |
| UsarSolo1BDIdentificacion=Sí | ' Solo soporta 1 BB.DD. |
¶ Correcciones
- En los terminales MorphoAccess SIGMA, la respuesta al ENROLL daba un error genérico (255) en vez de TR_ALREADY_ENROLLED para el caso de una huella ya existente. Lo que impedía regrabar dicha huella.
¶ 12/04/2017
¶ Vigilante
¶ Mejoras
- El sistema IQ - Touch & Bebida ahora soporta identificación biométrica con lectores STS3015
|
[Puerto 2 Terminal 1]
|
| IdPuertoVinculado=1 | Corresponde al Puerto de la STS |
| IdTerminalVinculado=192.168.2.211:5210 | Corresponde al IdTerminal de la STS |
- También soporta un método de Ping-Pong para verificar la comunicación con la máquina de bebidas
- En el nuevo modelo de servicios (NMS o NMS Mixto), nueva funcionalidad de para NO calcular los orígenes de acceso de servicios.
- Esto nos será útil, por ejemplo, para controles de acceso de sala. Donde solamente hace falta revisar los orígenes de acceso de "reservas de clase".
|
[Parametros]
|
| NoCalcularOrigenesPosiblesServiciosNMS=Sí |
¶ 23/01/2017
¶ Vigilante
¶ Mejoras
- En el control de acceso de monitores ahora se tendrá en cuenta los monitores definidos en los intervalos horarios de las actividades.
¶ Correcciones
¶ 22/11/2016
¶ Vigilante
¶ Correcciones
- Al realizar reservas a clases puntuales mediante el Vigilante, se producía un error que no permitía registrar la reserva.
¶ 17/10/2016
¶ Vigilante
¶ Mejoras
- Integración con el sistema IQ - Touch & Bebida.
Consiste en dispensadores de bebida refrigerada mediante sistema de selección con pantalla táctil e identificación RFID. - Nuevo protocolo en Vigilante
|
[PUERTO P]
|
| TipoLector=IQQuantum |
|
[PUERTO P TERMINAL T]
|
| IdTerminal=192.168.1.223:23222:23223 | El IdTerminal corresponde a la dirección IP del sistema IQ - Touch El puerto que viene a continuación (23222) corresponde al puerto de recepción RX de IQ - Touch (o TX en el Vigilante) El puerto que viene a continuación (23223) corresponde al puerto de envío TX de IQ - Touch (o RX en el Vigilante) |
- Ahora podremos definir si se permiten o no las aperturas manuales para un terminal concreto.
|
[PUERTO P TERMINAL T]
|
| PermitirAperturasManuales=Sí |
¶ 08/03/2016
¶ Vigilante
¶ Correcciones
- En NMS, si accedía un usuario con un servicio dado de baja a medio periodo de contratación (baja futura), no se permitía el acceso durante la parte del periodo contratada.
- Durante el proceso de lectura de un carné donde se traspasa al TPVWin (vía F7) información para iniciar una nueva venta de conceptos a nombre del usuario de dicho carné, si el sistema operativo estaba en inglés, no se traspasaban correctamente los campos de tipo booleano.
¶ 18/01/2016
¶ Vigilante
¶ Mejoras
- Nueva funcionalidad en el protocolo STS3000 para el control de acceso de un parking donde se generen entradas puntuales con códigos de barra:
- Definiremos un concepto que genere entrada
- Recomendamos que ese tipo de entrada tenga activado "Autogenerar código de tarjeta EAN" y se defina un "Proceso ReporWin" para poder imprimirla.
- Se emitirá/generará la entrada puntual solo si se ha detectado la presencia y además solamente se emitirá 1 por cada presencia.
|
[Puerto p Terminal t]
|
| CodigoConceptoEntradaPuntual= | El código del concepto que hemos definido |
| EntradaDigitalGenerarEntradaPuntual= | Nº de la entrada digital que usaremos para generar una entrada puntual |
| EntradaDigitalPresenciaObjeto= | Nº de la entrada digital que nos indicará cuando hay presencia/ausencia de un objeto (por ejemplo, un vehículo) |
- En la comprobación de taquillas liberadas, si una persona mantiene su taquilla ocupada en un acceso de salida, pero se le permite salir (ya sea porque su perfil así lo tiene definido o porque la entrada/bono con la que accede así lo indica) se mostrará un aviso indicando qué taquillas sigue ocupando (semáforo naranja).
- Recordamos que se puede resaltar con un semáforo grande parpadeante, los accesos incorrectos o correctos con aviso desde [Parametros] ResaltarAccesosIncorrectos=Sí.
¶ Correcciones
- Al pulsar doble click sobre la foto de la persona se producían errores no controlados en el caso de que en DeporWin no estuviera abierta la pantalla de ficha de personas.
- En el protocolo de Gantner, si se leía un carnet con valor numérico igual a 0 (por ejemplo: 0000000000000000), se producía una excepción de argumentos inválidos.
¶ 10/11/2015
¶ Vigilante
¶ Mejoras
- En el nivel de seguridad 1 ahora también se validará la contraseña tecleada (si tenemos activado el parámetro AutentificacionRequerida en terminales con teclado físico).
- Nueva función para ignorar las lecturas de un terminal hasta que no se haya finalizado el análisis de la lectura en curso de ese mismo terminal.
|
[PUERTO P TERMINAL T]
|
| IgnorarLecturasHastaFinalizarAnalisisLecturaEnCurso=Sí |
- Nueva opción para poder activar el relé secundario situado en otro terminal STS3000.
|
[Puerto p Terminal p]
|
| NombreTarjetaRele=STS3000 |
| TerminalRele2Entrada=1,1,1 | Formato: p,t,r (p: puerto, t: terminal, r: relé) (r=-1 para no activar ningún relé secundario) |
| TerminalRele2Salida=1,1,1 | Formato: p,t,r (p: puerto, t: terminal, r: relé) (r=-1 para no activar ningún relé secundario) |
| TiempoPulso2=500 | En milisegundos |
- Mejoras para el tratamiento de ruido en la línea entre STS3000 y lectores ProgramGP.
¶ Correcciones
- No se registraban las aperturas manuales realizadas desde el VigilaMonitor.
¶ 15/09/2015
¶ Vigilante
¶ Correcciones
- Si una persona tenía un origen de acceso (cursillo, servicio, abono,...) con control del número de máximo de usos en un periodo (o de tiempo máximo de estancia en un periodo) y estos usos estaban ya agotados, no se descartaba este origen si la persona también tenía un bono/entrada válido para el mismo instante de acceso.
¶ 22/07/2015
¶ Vigilante
¶ Mejoras
- Ahora se registrará en cada acceso si la persona era o no un empleado en el momento de acceder.
- Ahora podremos parametrizar si los accesos de los empleados cuentan o no en la ocupación de un recinto.
- El campo Ocupacion de la tabla de Accesos tendrá en cuenta esta parametrización.
- Configurable en la tabla Recintos, campo ContarEmpleadosEnOcupacion.
- Se registrarán en el historial de una persona las grabaciones/vinculaciones de carnés (normalmente de proximidad). Podremos distinguir los siguientes casos:
- "Se ha vinculado el carné nº XXXXXXXXXX como carné principal de la persona"
- "Se ha vinculado el carné nº XXXXXXXXXX como carné alternativo de la persona"
- "Se ha vinculado el carné nº XXXXXXXXXX como carné de acompañante de la persona"
- Nueva funcionalidad para emitir varios carnés a una entidad (en una misma ficha) sin tener que activar "Multicarnés" para todas las personas.
|
[Parametros]
|
| MultiCarnetsPersonas=No |
| MultiCarnetsEntidades=Sí |
- En el protocolo STS3000, si se tiene activado el "KeepAlive" de un terminal, ahora se "reiniciará la escucha" por el puerto TCP del canal de recepción (aunque el canal de envío estuviera "vivo").
¶ 15/06/2015
¶ Vigilante
¶ Mejoras
- Para el caso del nuevo modelo de servicios (NMS o NMS Mixto) siempre estará habilitada la matriz dinámica (independientemente del valor del parámetro "MatrizPermisosAccesoPersonasDinamica" del Vigila.ini).
- Ahora podremos personalizar la imagen de las personas que no tengan foto.
- Personalizable para hombres, mujeres y empresas.
- Para la aplicación "Monitor del Vigilante" solamente se soporta los parámetros ArchivoHombreSinFoto y ArchivoMujerSinFoto.
|
[Parametros]
|
| ArchivoHombreSinFoto=FotoHombreSinFoto.bmp | Nombre del archivo que se usará para los hombres que no tengan foto (por defecto se buscará en la ruta definida en [Ficheros] Fotos del Vigila.INI). Usar NINGUNO si queremos el comportamiento por defecto |
| ArchivoMujerSinFoto=FotoMujerSinFoto.bmp | Nombre del archivo que se usará para las mujeres que no tengan foto (por defecto se buscará en la ruta definida en [Ficheros] Fotos del Vigila.INI) Usar NINGUNO si queremos el comportamiento por defecto |
| ArchivoEntidadSinFoto=FotoEntidadSinFoto.bmp | Nombre del archivo que se usará para las entidades que no tengan foto (por defecto se buscará en la ruta definida en [Ficheros] Fotos del Vigila.INI) Usar NINGUNO si queremos el comportamiento por defecto |
¶ Correcciones
- En el "nuevo sistema de control de acceso para acompañantes", si un acompañante accedía en el horario de alguno de sus acompañados pero ninguno de ellos estaba dentro, no dejaba acceder al acompañante (por motivo "Usuario no está dentro") aunque dicho acompañante tuviera contratado una entrada/bono vigente.
¶ 15/05/2015
¶ Vigilante
¶ Mejoras
- Soporte para sensores biométrico Sagem MSOCBM en el protocolo en STS3000.
|
[Puerto p Terminal t]
|
| TipoTerminal=STS3000 |
| DisponibleDispositivoBiometrico=Sí |
| PermitirDescargarBBDDFingerTemplates=No | Si permitimos o no descargar BB.DD. en este terminal. |
|
[Puerto p Terminal t Dispositivo 2]
|
¶ 02/04/2015
¶ Vigilante
¶ Mejoras
- Nuevo protocolo para los terminales grabadores de huellas dactilares Sagem MSO 1300.
¶ 16/02/2015
¶ Vigilante
¶ Mejoras
- En el nuevo modelo de servicios "NMS puro", nueva funcionalidad de poder calcular los posibles orígenes de acceso del modelo clásico (abonos/cursillos/...). Esto nos será útil, por ejemplo, si todavía tenemos alguna actividad vigente del modelo clásico (y no queremos activar el modelo mixto).
| TipoDispositivo=MSOCBM |
|
[Parametros]
|
| CalcularOrigenesPosiblesSistemaClasicoEnNMSPuro=Sí |
- En el protocolo STS3000, nueva opción para indicar si queremos enviar una orden de "Reset físico" al terminal tras iniciar el Vigilante.
|
[Puerto p Terminal t]
|
| ResetTerminalAlIniciar=Sí |
¶ Correcciones
- Al acceder al centro un monitor de una actividad se producía un error de "3265-No se encontró el elemento en la colección" al obtener la hora inicio/fin de la actividad a impartir.
- ActualizarTerminalBD en BB.DD. MsAccess daba error de integridad referencial en ciertos casos.
¶ 09/01/2015
¶ Vigilante
¶ Mejoras
- Nueva funcionalidad para realizar excepciones en la comprobación de los criterios de edad (edad mínima/máxima) para determinadas personas según su perfil.
|
[Puerto p Terminal t]
|
| EdadMinima=14 | ' Edad mínima |
| EdadMaxima=100 | ' Edad máxima |
| PerfilesSinControlEdad=32 | 'Lista de códigos de perfil sin control de edad (separada por comas). Valor por defecto NINGUNO (es decir, todas las personas pasarán la verificación). |
¶ Correcciones
- No se permitía el acceso a un cliente con una reserva de recurso si ésta tenía una hora temprana, tal que, restándole el margen de acceso de entrada sobre la hora de inicio de la reserva el resultado fuera una hora anterior las 00:00:00.
- En la pestaña de "Accesos", al mostrar los accesos con la marca "Sólo los últimos accesos" activada, no se ordenaban los registros resultantes para SQL Server.
¶ 11/12/2014
¶ Vigilante
¶ Mejoras
- En los accesos correspondientes a cursillistas y/o a inscripciones puntuales de actividades (ReserClass) se registrará la hora de inicio/fin de la "clase".
- Tiene que estar habilitada la matriz dinámica en Vigila.ini
- Se registrarán en AccesosDetallados.HoraInicioActividad y AccesosDetallados.HoraFinActividad.
¶ Correcciones
- Si una persona tiene un origen de acceso (cursillo, servicio, abono,...) con control del número de máximo de usos en un periodo y éstos usos estuvieran ya agotados, también se descartará este origen en los accesos de salida (a expensas de que tengo otro para el mismo instante de acceso válido).
¶ 10/11/2014
¶ Vigilante
¶ Mejoras
- Nueva funcionalidad para resetear la ocupación de los recintos de control de acceso al cambiar de día.
- Útil cuando se está controlando el aforo de un recinto y el Vigilante siempre está abierto (no se cierra y abre diariamente).
- De esta manera, al cambiar de día (teniendo en cuenta la hora nocturna límite), se reseteará la ocupación del recinto y evitaremos problemas de "falsa ocupación acumulada entre días" por culpa de accesos no coherente (entradas sin salidas,...)
|
[Recinto r]
|
| ResetearOcupacionHoraNocturnaLimite=Sí |
- Nueva funcionalidad en la versión 3.0 para poder indicar si se debe comprobar o no, para un tipo de entrada concreto, que el usuario haya liberado su taquilla al realizar un acceso de salida.
- Lo definiremos desde "DeporWin -> Fichas -> Conceptos -> Seleccionamos el concepto -> Acceso -> Tipo de entrada -> Comprobar taquillas liberadas.
- En la configuración del Vigilante hay que activar la comprobación de taquillas liberadas:
[Puerto p Terminal t] ComprobarTaquillasLiberadas=Sí
Y en ese caso, se comprobará la liberación de la taquilla según lo establecido en el "tipo de entrada" - Si el usuario saliera de un recinto mediante una entrada/bono (con tipo de entrada donde NO se controla la liberación de la taquilla) y tuviera la taquilla bloqueada, no se consumirán los usos con el objetivo de que pueda volver a entrar en este u otro recinto.
- Recordamos que, si fuera un acceso con un carné de persona (en vez de carné de entrada/bono), la comprobación de la liberación de la taquilla tendrá en cuenta lo establecido en el perfil del usuario (Perfiles.ComprobarTaquillasLiberadas).
- Nueva funcionalidad en la versión 3.0 para indicar si NO queremos controlar en los accesos de salida los consumos pendientes de cobro (realizados durante la estancia) si la taquilla NO está liberada.
- Útil por ejemplo cuando hay que salir momentáneamente para ir a otro recinto y después regresar.
- Si el usuario tuviera consumos pendientes y mantuviera la taquilla bloqueada, se mostrará el importe de dichos consumos a modo de aviso (semáforo naranja). Recordamos que se puede resaltar con un semáforo grande parpadeante, los accesos incorrectos o correctos con aviso desde [Parametros] ResaltarAccesosIncorrectos=Sí.
|
[Puerto p Terminal t]
|
| ControlarConsumosPendientesEstancia=Sí |
| NoControlarConsumosPendientesEstanciaSiTaquillaNoLiberada=Sí |
- Nueva funcionalidad en la versión 3.0 para indicar si queremos traspasar los consumos pendientes de cobro entre accesos del mismo día.
- Los traspasos de los consumos pendientes sólo se realizarán en los accesos de entrada a un recinto.
- Se traspasarán los consumos realizados con la misma entrada/bono o la misma persona.
- Se traspasarán los consumos pendientes indistintamente del recinto donde se hubieran realizado.
|
[Puerto p Terminal t]
|
| TraspasarConsumosPendientesEstancia=Sí |
- Nueva funcionalidad para comprobar que la venta de las entradas/bonos no esté pendiente de completar.
- Útil por ejemplo cuando se compra una entrada/bono desde la web, no se completa el pago por TPV Virtual, y en menos de 15 minutos (tiempo de vida de las transacciones) se intenta acceder con dicha entrada.
|
[Puerto p Terminal t]
|
| ComprobarTransaccionesPendientesEnVentasEntradas=Sí |
- Añadida la posibilidad de forzar el uso de máscara de carnés para protocolo GenericReader de STS3000.
- El campo se añadirá automáticamente a Vigilante con valor False.
|
[Puerto p Terminal t Dispositivo d]
|
| ForzarUsarMascaraProximidad=Si |
¶ 10/10/2014
¶ Vigilante
¶ Mejoras
- En la generación de "entradas puntuales" para los usuarios que no tengan permiso de acceso en una zona de la instalación (por ejemplo un Parking), podremos indicar que NO se genere otra "entrada puntual" si anteriormente ya había entrado (en el mismo día) pero no había salido correctamente. Con lo que, en este supuesto, daría error de acceso por "incoherencia".
|
[Parametros]
|
| ConsumirEntradasPersonasSinPermisoAcceso=Sí |
|
[Puerto p Terminal t]
|
| ComprobarAccesosCoherentes=Sí |
| CodigoConceptoEntradaPuntual= | 'El código del concepto que luego facturaremos. Tiene que tener validez 1 día y varios usos (por ejemplo 10). |
| GenerarEntradaPuntualPersonasSinPermisoAcceso=Sí |
| GenerarEntradaPuntualPersonasSinPermisoAccesoPorIncoherencia=No |
- Nueva funcionalidad para no almacenar las huellas en terminales biométricos SagemMA grabadores.
- Nos puede ser útil en instalaciones con muchos usuarios con el fin de que los tiempos de grabación sean rápidos.
- También puede ser útil para instalaciones con terminales "mezclados" SagemMA300 y SagemMA500 con BB.DD. única.
- La implementación consistirá en vaciar la BD de huellas de dichos terminales grabadores cada vez que se ejecute el Vigilante (NO al reiniciar el Vigilante con F6). Y aunque tengamos varios terminales grabadores no se sincronizarán entre ellos.
|
[PUERTO P TERMINAL T]
|
| TerminalGrabador=Sí |
| SincronizarFingerTemplates=No |
¶ 05/08/2014
¶ Vigilante
¶ Mejoras
- Si una persona tiene 2 o más orígenes de acceso del mismo tipo (cursillo, servicio, abono,…) que le dan permiso de acceso en un instante dado, se seleccionará como candidato el origen de acceso que comience más cercano al instante del acceso.
Si una persona tiene un origen de acceso (cursillo, servicio, abono,…) con control del número de máximo de usos en un periodo y éstos usos estuvieran ya agotados, se descartará este origen (a expensas de que tengo otro para el mismo instante de acceso válido).
- Nueva funcionalidad donde se registrará en cada acceso la ocupación actual del recinto que se está accediendo.
- La ocupación será la ocupación que habrá justo después del acceso.
- Esta información registrada nos facilitará poder explotar la ocupación de los recintos vía listados, tablas dinámicas, indicadores, …
- Ni la puerta ni el recinto deben ser interiores (en BB.DD. e INI).
- Tienen que estar correctamente definidos en Vigila.ini los recintos de control de aforo:
[Parametros]
NumeroRecintosControlAforo=
Una sección [Recinto r] para cada recinto que queramos controlar.
¶ 25/07/2014
¶ Vigilante
¶ Mejoras
- En el protocolo de los lectores biométricos Sagem MorphoAccess (MA300, MA500,...) ahora podremos definir el puerto de comunicaciones TCP. Útil cuando el Vigilante tiene que acceder a lectores que se encuentran detrás de un router, con una única IP fija y hay que redirigir puertos.
|
[Puerto p Terminal t]
|
| IdTerminal=192.168.1.186:11010 | ' Podremos opcionalmente indicar el puerto añadiendo ":" más el puerto TCP correspondiente |
¶ 20/06/2014
¶ Vigilante
¶ Mejoras
- En el "nuevo sistema de control de acceso para acompañantes" podremos configurar si se permitirá el acompañamiento de un menor por varios acompañantes simultáneamente.
|
[Puerto p Terminal t]
|
| PermitirAcompañamientoPorVariosAcompañantesSimultaneos=No |
- Nuevo protocolo en STS3000 del dispostivo LPP020. Lector de banda magnetica para exterior y por RS-232.
|
[Puerto P Terminal T Dispositivo D]
|
| TipoDispositivo=LPP020 |
¶ Correcciones
- Cuando se iniciaba el Vigilante automáticamente desde DeporWin/ReserWin/... en modo ActivarVigilante=Sí y VigilanteRemoto=No, si luego se realizaba un "Acceso manual" o una "Grabación de carné" y se buscaba una persona salía un error de "No coinciden los tipos".
- Con nuevas versiones de firmware de STS que empiezan por 1.00.01, no se trataba correctamente la inicialización y no funcionaban los mensajes por pantalla
¶ 21/05/2014
¶ Vigilante
¶ Mejoras
- En el protocolo Digitek ML20 Ethernet, las grabaciones de huellas realizadas con el terminal BioMini se considerarán prioritarias. Por lo que, tras cada acceso, se sincronizarán automáticamente hasta 3 de ellas.
- En el protocolo Digitek ML20 Ethernet se capa a longitud 8 los datos recibidos para compatibilizarlo con las lecturas de los lectores de diferentes instalaciones en la Fundació Claror.
- En el protocolo Digitek ML20 Ethernet, cada 2 horas, se enviará la configuración de los sensores biométricos (MVCONF9336) debido a que de forma aleatoria se pierde dicha configuración y en ese caso el sensor tiene mayor tasa de error en la identificación.
- En el protocolo SyC1616 se modifica el comportamiento del dispositivos cuando incluye display físico o no, para mejorar el tiempo de respuesta en caso de no incorporarlo.
- En el protocolo SyC1616 se permite el traspaso de lecturas entre dispositivos conetados al mismo terminal.
¶ Correcciones
- En el protocolo Biomax, si se usaba el TipoAutentificacionControlAccesoBiometrico = Teclado, mostraba un mensaje de "Password incorrecto". Se corrige para permitir usar esta opción.
- En el protocolo GenericReader de STS3000, si se introducía un formato de trama del tipo "STX DATA X ETX" no se eliminaba el carácter por estar situado tras los datos. Ahora se permite eliminar múltiples carácteres tras los datos.
¶ 09/04/2014
¶ Vigilante
¶ Mejoras
- Nuevo protocolo para los terminales Digitek ML20 Ethernet.
- Este terminal trabaja en online (conectado y controlado por el Vigilante) pero también permite trabajar en offline. Mientras trabaja en offline el terminal concede el paso siempre y, cuando se recupera el modo online, se registrarán en la BB.DD. de accesos aquellos marcajes que se produjeron en offline (registrados con el campo Accesos.ErrorOriginal = 6).
- Este terminal permite tener conectados hasta 2 lectores, por ejemplo una biométrica (por identificación) y otra de proximidad. También soporta el traspaso de lecturas entre terminales, permitiendo tener una controladora y dos lectores.
- El formato de las huellas dactilares es compatible con los terminales de identificación biométrica STS3015 así como el grabador de huellas Biomini.
|
[Puerto p]
|
| TipoLector=DIGITEK_ML20E |
| TimeOutIdle=60 | Tiempo de inactividad (en segundos), tras el cual se lanzará el proceso de sincronización de huellas. |
|
[Puerto p Terminal t]
|
| IdTerminal=x.x.x.x | Dirección IP del terminal Digitek (sin especificar ningún puerto UDP) |
| SistemaLector=6 | ' Tipo de la primera lectora (1=Banda magnética, 4=Proximidad, 6=Biometría, 0=Ninguna) |
| SistemaLectorTTL=4 | ' Tipo de la segunda lectora (1=Banda magnética, 4=Proximidad, 6=Biometría, 0=Ninguna) |
- Nuevo protocolo para los terminales Digitek ML20 Serie.
- Este terminal trabaja en online (conectado y controlado por el Vigilante) pero también permite trabajar en offline. Mientras trabaja en offline el terminal concede el paso siempre y cuando se recupera el modo online, se registrarán en la BB.DD. de accesos aquellos marcajes que se produjeron en offline (registrados con el campo Accesos.ErrorOriginal = 6).
- Este terminal permite tener conectados hasta 2 lectores soportando el traspaso de lecturas entre terminales, permitiendo tener una controladora y dos lectores.
|
[Puerto p]
|
| TipoLector=DIGITEK_ML20S |
- Nueva opción para poder contabilizar los orígenes de acceso de abonados cómo candidato de selección.
|
[Parametros]
|
| CalcularOrigenesPosibles=Sí |
| PermitirSeleccionarOrigen=Sí | ' Si queremos poder seleccionar entre orígenes manualmente |
| ContarAbonosComoNumeroOrigenesCandidatosSeleccion=Sí |
- En la ventana de resumen de datos de una persona se ha añadido los servicios (NMS) que pudiera tener contratados (contratos vigentes).
¶ 06/03/2014
¶ Vigilante
¶ Correcciones
- En el "nuevo sistema de control de acceso para acompañantes", si un acompañante tenía varios acompañados en el mismo horario de acceso (por ejemplo una madre que acompaña a sus dos hijos inscritos en el mismo cursillo), solamente se comprobaba si el primer acompañado estaba dentro, en vez de si alguno de los acompañados estuviera dentro.
¶ 17/01/2014
¶ Vigilante
¶ Mejoras
- Nueva funcionalidad en la versión 3.0 para consumir solamente 1 uso por día.
- En la definición de los usos de un bono (DeporWin -> Fichas -> Conceptos -> Seleccionamos el bono -> Acceso -> Tipo de entrada) indicaremos que queremos consumir solo 1 uso por día.
- Ya no hace falta activar el parámetro del Vigila.ini [Puerto p Terminal t].Consumir1UsoPorDia (si lo activáramos todos los bonos de acceso serían consumidos a ratio de 1 uso por día).
- Nueva funcionalidad en la versión 3.0 para consumir solamente 1 uso si el tiempo entre usos se ha superado.
- En la definición de los usos de un bono (DeporWin -> Fichas -> Conceptos -> Seleccionamos el bono -> Acceso -> Tipo de entrada) indicaremos que queremos consumir solo 1 uso por tiempo entre usos e indicaremos el tiempo mínimo entre usos correspondiente (expresado en minutos).
.jpg "DeporNews")
- Cuando se configura el umbral 0 en la ficha de un usuario y el sistema utilizado es Biomax 1, estos usuarios pondran el dedo pero no hará caso de la lectura. Es un método de acceso placebo para cuando no exista sistema de respaldo de la biometría y un usuario tenga problemas de verificación.
¶ Correcciones
- Hasta ahora los lectores de Gantner serie GAT6100 no hacían caso al tiempo ( configurado mediante la aplicación GAT Config Manager) durante el cual semuestran los mensajes (permitido o denegado) en el display.
¶ 19/12/2013
¶ Vigilante
¶ Mejoras
- Se integra dispositivo de sobremesa Nitgen FDU con interfaz USB compatible con sensores integrados en Biomax 1 y Biomax 2. Se almacena un único template consolidado de las dos huellas (índice mano derecha e índice mano izquierda).
- Para Vigilantes instalados vía Terminal Server, existen varias aplicaciones en el mercado que mapean los puertos usb locales vía Terminal Server. Nosotros hemos probado el software de la casa Eltima: http://www.net-usb.com/downloads/ y la velocidad de respuesta es muy buena. Con lo que podríamos instalarlo en versión 2.95
|
[Puerto P]
|
| TipoLector=NITGEN_FDU |
- Se añade la compatibilidad de biometría en el sistema de Biomax 1.
- El protocolo de comunicación existente para Biomax 1 es ampliado para soportar el lector FIM30 en modo verificación (teclado + huella). Se almacena la huella en la base de datos en el formato TextEncodeFIR. Se han realizado mejoras en el protocolo en relación a los mensajes mostrados por display y la compatibilidad con método de acceso de teclado + PIN.
|
[Puerto P]
|
| TipoLector=Biomax |
| TipoPuertoCOM=X | 'Define el tipo de origen de datos durante la adquisición. Puede tomar un valor único entre [1,5,6]. |
| IPFingerPrintServer=NINGUNO | 'Con esta parametrización, es el propio Vigilante el que realiza el matching entre el template leído y el almacenado. |
|
[Puerto P Terminal T]
|
| TipoTerminal= Biomax1 |
| SistemaLector=6 | '6 = Biometría, 4 = Proximidad |
¶ 29/11/2013
¶ Vigilante
¶ Mejoras
- Nueva funcionalidad para realizar el control de acceso de inscripciones puntuales para actividades dirigidas (Reserclass).
- Los permisos de acceso de dichas actividades podrán ser en función de los horarios de acceso de la actividad o en función de las reservas generadas (según se especifique en DeporWin -> Fichas -> Actividades -> Horario -> Disponibilidad inscripciones puntuales por Reservas.)
- Se guardará en el acceso detallado el código del pago correspondiente a la inscripción puntual del usuario (útil para su posterior explotación de datos).
|
[Parametros]
|
| CalcularOrigenesPosibles=Sí |
| CalcularOrigenesPosiblesInscripcionesPuntuales=Sí |
- Nueva funcionalidad para permitir la inscripción automática en actividades puntuales (Reserclass) si no tenemos un terminal en modo de consulta.
|
[Parametros]
|
| CalcularOrigenesPosiblesInscripcionesPuntuales=Sí |
|
[Puerto p Terminal t]
|
| TerminalConsulta=No |
| TerminalConsulta_PermitirInscripcionesPuntuales=Sí |
| TerminalConsulta_CodigoFormaPagoInscripcionesPuntuales=1 | ' Código de la forma de pago en que se realizarán las inscripciones automáticas. |
- Se integra una nueva controladora del fabricante SyC que permite comunicación a través de radiofrecuencia.
- SyC1616 que permite gestionar hasta 16 salidas de relé y 16 entradas digitales, 1 puerto RS-232, 1 puerto RS-485 y display. La comunicación entre la pasarela y las controladoras se realiza mediante radiofrecuencia, permitiendo ser instalado en ubicaciones remotas sin necesidad de tirar cableado de datos. La integración se realiza mediante un control Active X SyCRFComm.ocx.
|
[Puerto P]
|
| PuertoCOM=1 en 192.168.1.103:1001 | Existen dos modos de trabajo: 1. Modo directo donde IP y puerto se corresponden a pasarela 2. Modo a través de servicio. Permite compartir la controladora con E-Domo y la IP y puerto se corresponen a los datos del PC que ejecuta el servicio |
| TipoLector=syc1616 |
| TimeOut = 10 | Usado para configurar los tiempos entre ordenes (en Seg). |
- En el control de acceso de servicios NMS, al acceder una persona por una puerta/fecha/hora concreta, si no tiene acceso a esa hora concreta pero sí lo tiene en otra/s franja/s horaria/s de la misma fecha/puerta se mostrará un texto informativo con éstas últimas.
- Se integra nuevo lector de proximidad Mifare RD200 con interfaz USB pero emulación de puerto serie.
- TipoLector=RD200
¶ Correcciones
- Limitación del número de motivos de acceso debido a un problema de desbordamiento. Ahora se permiten hasta 255 motivos.
¶ 12/11/2013
¶ Vigilante
¶ Mejoras
- Nueva pantalla para mostrar el progreso en la inicialización del Vigilante. Útil cuando dicho proceso es lento (muchos dispositivos, dispositivos off-line,..).
¶ Correcciones
- En los servicios NMS, si se definía un tipo de permiso de acceso con un intervalo tal que, al calcular la hora fin de acceso para un servicio concreto superara a las 23:59:59 se producía un error de "Puerta incompatible".
¶ 16/10/2013
¶ Vigilante
¶ Mejoras
- Nuevo parámetro pare definir el puerto TCP local en la validación remota de accesos entre Vigilantes.
|
[PUERTO 1 VIGILANTE REMOTO 1]
|
| PuertoTCPLocal=5010 | 'Puerto TCP LOCAL (socket) para la conexión inversa que realizará el Vigilante Remoto (0=dinámico) |
- En los lectores de proximidad y biometría de Gantner GATAccess se mostrará un mensaje de "Validación en curso" si se está realizando un proceso de validación remota entre Vigilantes.
- Al realizar una grabación con los terminales de Gantner GATAccess6100Enroll se registrará en la BB.DD. si hemos grabado una tarjeta de proximidad con huella vinculada o no.
- Desde Deporwin -> Fichas -> Personas -> Accesos -> podremos ver el icono de huella dactilar grabada.
- Podremos consultar en un listado qué personas se le ha grabado la huella vinculada a la tarjeta.
- Se registra en la BB.DD. en la tabla FingerTemplates con TipoHuella=4 (Gantner).
- Soporte para los terminales de Gantner GATAccess6100Bio del doble paso en el acceso de acompañantes.
- Admisión de la generación de entradas puntuales para los usuarios que no tengan permiso de acceso en una zona de la instalación (por ejemplo un Parking) según un Perfil concreto.
|
[Puerto p Terminal t]
|
| CodigoConceptoEntradaPuntual= | 'El código del concepto que luego facturaremos |
| GenerarEntradaPuntualPersonasSinPermisoAcceso=Si |
| Perfiles= | 'Lista de códigos de perfil admitidos. |
- Nueva funcionalidad en el control de acceso de acompañantes para el nuevo modelo de servicios (NMS) de manera que el padre/madre/tutor del menor solamente pueda acompañarlo en el horario de las actividades/cursillos (obviando de esa manera otros permisos de acceso del menor como por ejemplo por el hecho de ser socio/abonado, etc.)
- Para diferenciar que un servicio sea una "Actividad" usaremos la asociación de servicios con "Flags".
- Necesitaremos un flag "Cursillista" con la marca "EsCursillista" activada.
- Asociaremos dicho flag al servicio/s (normalmente a nivel de tipo de familia de servicio nos será suficiente).
|
[Puerto p Terminal t]
|
| PermisoAcompañamientoSoloParaActividades=Si |
|
[Parametros]
|
| MatrizPermisosAccesoPersonasDinamica=Si | ' Tiene que estar habilitada la matriz dinámica. |
- En el "nuevo sistema de control de acceso para acompañantes" podremos definir si queremos o no comprobar las restricciones de acompañamiento en los accesos de salida.
|
[Puerto p Terminal t]
|
| ComprobarAcompañamientoEnSalida=Si |
¶ Correcciones
- En la validación remota entre Vigilantes, en determinadas circunstancias (concurrencia alta), se producía un error al conectar con el Vigilante Remoto ("propiedad no válida en este contexto").
¶ 18/09/2013
¶ Vigilante
¶ Mejoras
- Durante el proceso "Reconexión con los clientes del Vigilante" tendremos la opción de cancelarlo.
.jpg "DeporNews")
- Nuevo protocolo para los terminales Biomini, grabadores de huellas dactilares compatibles con los terminales de identificación biométrica STS3015.
- Se deberán instalar previamente los drivers del dispositivo (Suprema_Fingerprint_Scanner_Driver)
- Solo compatible para Vigilantes instalados en local (versión 3.0)
- Para Vigilantes instalados vía Terminal Server, existen varias aplicaciones en el mercado que mapean los puertos usb locales vía Terminal Server. Nosotros hemos probado el software de la casa Eltima: http://www.net-usb.com/downloads/ y la velocidad de respuesta es muy buena. Con lo que podríamos instalarlo en versión 2.95
|
[Puerto p]
|
| TipoLector=BIOMINI | ' Biomini |
| CalidadMinimaGrabacion=60 | ' valor de 0 a 100 |
| NumeroTemplatesPorPersona=1 | ' 1 o 2 |
| TimeOutGrabacion=5 | ' en segundos |
|
[Puerto p Terminal t]
|
| IdTerminal=1 | ' Número del dispositivo BioMini (para el caso de tener varios conectados por USB) |
| GrupoSincronismo=A | ' El grupo de los terminales STS3015 correspondiente |
.jpg "DeporNews")
.jpg "DeporNews")
- Nuevo sistema de control de acceso para acompañante.
- Los acompañantes tendrán su propia ficha personal. Por lo que accederán con su propio carné o biometría.
- Un usuario podrá tener 1 o más acompañantes.
- Los acompañantes podrán acceder en los horarios de acceso válidos de quien estén acompañando.
- Para que el acompañante pueda acceder, el acompañado tendrá que estar dentro de las instalaciones (tanto para entrar como para salir).
- Se podrá definir el tiempo máximo que el acompañado haya entrado para admitir la entrada del acompañante (solo aplicable en la entrada).
- Cuando la persona acompañante acceda con dicho rol, no se le tendrán en cuenta las restricciones de edad, sexo, permiso de acceso y aforo (si accediera con su rol propio de usuario sí se tendrán en cuenta).
- El acceso del acompañante se registrará a nombre del propio acompañante.
- Es necesario tener activada la matriz dinámica de permisos de acceso (MatrizPermisosAccesoPersonasDinamica=Sí)
- Se implementa la funcionalidad que permite leer datos con un lector externo (banda magnética o proximidad) en los lectores Handkey por el puerto wiegand 26 bits que incoporar dicho lector. Para que dicha funcionalidad sea compatible con el resto de dispositivos, la lectura se transforma en hexadecimal.
- Implementado para los protocolos Handkey y Handkey_Remoto
|
[Puerto P TERMINAL T]
|
| ConvertirAHexadecimalProximidad=True | ' Por defecto el parámetro esta a falso, habilitándolo permitimos convertir el valor leído a hexadecimal |
- Nuevo valor en el campo de búsqueda de persona para realizar la búsqueda solamente teniendo en cuenta el formato propio de DeporWin (11 caracteres) o sino buscando en el campo NumeroCarnet.
|
[Parametros]
|
| CampoBusquedaPersona=FORMARTOPROPIO_O_NUMEROCARNET |
- Nueva funcionalidad para la versión 3.0 para permitir o no el acceso de las reservas con venta aplazada.
|
[Puerto P TERMINAL T]
|
| PermitirAccesoReservasConVentaAplazada=Sí | ' Por defecto Sí |
- Nuevo parámetro para el HandKey Server (HKServer.exe) para no permitir ocultarlo en la barra de notificaciones de Windows. Nos puede ser útil en sesiones de terminales sin escritorio.
- Parámtro por la línea de comandos /NoPermitirOcultarEnBarraNotificaciones
¶ Correcciones
- En el protocolo de lectores por interfaz de teclado (TipoLector=TECLADO), usado por ejemplo en lectores de códigos de barras, no se tenía en cuenta el parámetro (del Vigila.ini) CampoBusquedaPersona cuando este tenía como valor NUMEROCARNET.
¶ 22/07/2013
¶ Vigilante
¶ Correcciones
- En terminales STS3000 siempre se pedía el motivo de acceso cuando un usuario accede con teclado y PIN y tiene el flag es empleado en su ficha. Ahora será necesario tener habilitado el parámetro:
- Habilitar Control Presencia = Sí
- Se estaba mostrando consecutivamente el texto del origen y el nombre del usuario en el display de los lectores SAGEM MA cuando dicha configuración estaba habilitada. Se separan dichos mensajes para poder mostrar solo el nombre o solo el origen. Ambas opciones a la vez no es posible dada una limitación del hardware.
¶ 19/06/2013
¶ Vigilante
¶ Mejoras
- Se permite mostrar u ocultar información detallada en el display del lector Handkey II.
- MostrarInformacionDetalladaEnDisplay=Si
- Se permite mostrar u ocultar el nombre del usuario en el display del lector Handkey II.
- MostrarNombreUsuariosEnDisplay=Si / No
- Los lectores Sagem MA generan las acciones de sincronismo para petición de desactivación/activación/borrado recogidos en la tabla FingerTemplatesPeticionesSincronismoPersona.
- Se permite mostrar u ocultar información detallada en el display de los lectores Sagem MA.
- MostrarInformacionDetalladaEnDisplay=Si
- Ahora, al tener activada la matriz dinámica de permisos accesos, se tendrán en cuenta la definición de los intervalos de acceso (de abonos, cursillistas y servicios) para días festivos/no festivos.
.jpg "DeporNews")
- Nueva funcionalidad en los "Terminales en modo de consulta" para permitir la inscripción automática en actividades puntuales (Reserclass).
- Al pasar la tarjeta por el terminal de consultas, encontrándonos en el horario válido de una actividad puntual gratuita (entre la hora inicio de acceso hasta la hora de fin de la clase), si todavía hay plazas disponibles y no estamos ya inscritos, se realizará una inscripción automática a dicha actividad.
- Con el objetivo de primar la ocupación máxima de la clase, en este caso no se realizará la comprobación de las restricciones de "Antelación" ni la de "Cantidad de reservas en un periodo", pero si el resto "Perfiles", "Horario de abonado", "Acceso per timito", "Plazas", "Ya inscrito", etc.
|
[Puerto p Terminal t]
|
| TerminalConsulta=Sí |
| TerminalConsulta_MostrarInscripcionesPuntuales=Sí |
| TerminalConsulta_PermitirInscripcionesPuntuales=Sí |
| TerminalConsulta_CodigoFormaPagoInscripcionesPuntuales=1 | ' Código de la forma de pago en que se realizarán las inscripciones automáticas. |
- Nueva funcionalidad para controlar que los integrantes de una reserva estén todos presentes antes de conceder el acceso (útil por ejemplo para control de acceso en pista de pádel,...).
- Los integrantes de la reserva irán pasado su carné de persona, se les registrará el acceso como correcto, pero no les abrirá la puerta hasta que la última persona pase su carné.
- Las reservas tienen que ser con integrantes (por ejemplo modalidad dobles, simples,...)
- El recurso tiene que tener definido un recinto de control de acceso propio, además de los permisos por puerta.
|
[Puerto p Terminal t]
|
| ControlarIntegrantesReservaPresentes=Sí |
|
[Parametros]
|
| CalcularOrigenesPosibles=Sí |
| CalcularOrigenesPosiblesReservas=Sí |
¶ Correcciones
- Se corrige un error en la consulta DesactivarHuellasPersonasSinPermisosAcceso en el caso de la versión de Access.
- Se corrige error en comportamiento de lector Handkey II cuando es usado para entrada y salida mediante un terminal virtual. La configuración como lector virtual no consideraba el parámetro AutentificacionRequerida y por lo tanto no solicitaba la mano en la salida.
- Se corrige un error vinculado en la sincronización de fingertemplates en Sagem MA cuando el error no estaba controlado, el sincronismo quedaba pendiente de ejecutar e impedia que los siguientes sincronismos se ejecutaran correctamente.
- Cuando se tiene activada la matriz dinámica de permisos accesos, no se calculaban correctamente los permisos de los abonados con altas futuras pero con vigencia inmediata.
- El vigilante no lanzaba el evento "NuevaLectura" cuando realizábamos un acceso manual. Por lo que los clientes del vigilante no la recibían (Kiosco, etc..).
- El dispositivo Datalogic TC1100 ya permite utilizar la máscara de carnés de proximidad.
¶ 13/05/2013
¶ Vigilante
- Los mensajes durante la descarga y al finalizar la descarga de la base de datos en los terminales de biometría dáctilar STS3015 y SAGEM MA estan temporizados para el cierre automático, evitando así el bloqueo durante la descarga.
- En los terminales SAGEM MA en modo verificación, se permite que un usuario con problemas durante la lectura de la huella se pueda identificar solo con el IdPersona.
- Es necesario configurar en la ficha del usuario, pestaña Accesos el Tipo Autentificación como "Teclado"
- Se implementa la funcionalidad que permite a una electrónica ISBIO que tengas varios dispositivos conectados en sus entradas de Wiegand/RS-232 puedan operar como Terminales lógicos diferenciados en Vigilante.
|
[Puerto 1]
|
| IdTerminal=01 AliasTerminal=Lector 1 |
Terminal real |
|
[Puerto 2 ]
|
| IdTerminal=02 AliasTerminal=Lector4 IdPuertoVinculado=1 IdTerminalVinculado=01 ; Isbio dispone de 4 puertos (1 al 4) IdDispositivoVinculado=4 |
Terminal virtual |
¶ 09/04/2013
¶ Vigilante
¶ Mejoras
- Nuevo parámetro para indicar si se tiene en cuenta el acceso permitido de la persona para el consumo de bonos.
|
[Parametros]
|
| ConsumirEntradasPersonasSinPermisoAcceso=Sí | ' Parámetro existente. |
| ComprobarAccesoPermitidoPersonaParaConsumirEntradas=Sí | ' Nuevo parámetro |
- Ampliado el modo mixto del protocolo biométrico STS3015 para especificar que un usuario pueda autentificarse con "Sólo Biometría o Teclado+PIN".
¶ 22/03/2013
¶ Vigilante
¶ Mejoras
- Se ha añadido un nuevo campo para guardar la clave/pin que usará en el control de acceso (Vigilante). Hasta ahora se usaba el mismo campo ("password") que para la Web o Kiosco, lo que provocaba incompatibilidades ya que los controles de acceso normalmente solo admiten números.
- Nuevo modo mixto para el protocolo biométrico STS3015 donde se permitirá especificar para cada usuario cómo desea autentificarse: con teclado, con teclado+PIN, con teclado+Biometría, con tarjeta, con tarjeta+PIN, con tarjeta+Biometría o con sólo Biometría.
|
[Puerto p Terminal t]
|
| TipoTerminal=STS3015 |
| ProtocoloAutentificacion=3 | '3=modo mixto |
| AutentificacionRequerida=Sí |
| AutentificacionRequeridaConBiometria=Sí |
| TiempoReLecturaMismaTarjeta=3000 | Para evitar solapamientos entre verificaciones e identificaciones. |
.jpg "DeporNews")
- En los protocolos de control de acceso biométrico SagemMA, HandKey y Biomax se ha cambiado la manera de indicar que un usuario concreto no se le solicite autenticarse biométricamente. Anteriormente se usaba el campo Clave/password o el campo Usuario/login con el valor "NO". Ahora pasa a usarse el campo "tipo de autentificación" estableciendo el valor a "teclado" por ejemplo.
- Nuevo método para facilitar la desactivación/activación de usuarios en terminales biométricos STS3015. Por ejemplos nos puede ser útil cuando tenemos una BB.DD. con muchos usuarios, de los cuales no todos son "activos" (abonados, cursillistas,…), y no nos interese "engordar" la BB.DD. de huellas en los terminales.
- El procedimiento a seguir será crear una consulta donde se decida que usuarios con huella ya no son activos, e insertarlos en la tabla "FingerTemplatesPeticionesSincronismoPersona" con el tipo de huella = 2 (STS3015) y la acción = 1 (desactivar huellas).
- También podríamos realizar el procedimiento contrario para "reactivar" usuarios que pasan a ser de nuevo "activos". Solamente cambiaría la acción = 2 (reactivar huellas).
- El Vigilante se encargará de crear los "sincronismos pertinentes" para desactivar o reactivar a los usuarios especificados sin necesidad de tener que "descargar la BB.DD. de huellas".
- Nueva funcionalidad en DeporWin 3.0 en los permisos de acceso de las Actividades. Podremos indicar para una actividad concreta, si los permisos de acceso de sus inscritos/monitores son en función de las reservas generadas o, como hasta ahora, en función de los horarios de acceso. Esta nueva modalidad nos permite, por ejemplo, realizar excepciones (cambios de horario, de recurso, etc...) para un día concreto de la actividad mediante el ReserWin.
.jpg "DeporNews")
|
[Parametros]
|
| MatrizPermisosAccesoPersonasDinamica=Sí |
¶ Correcciones
- En el protocolo STS3015, tras realizar el borrado de una huella, no se desactivaba dicha huella en la BB.DD. de DeporWin, por lo que se continuaba viendo el icono de huella en la pestaña de Fichas->Personas->Acceso.
- Al reactivar la huella de un persona en los terminales biométricos STS3015 se duplicaba la longitud de la misma en la BB.DD. (FingerTemplates.Dedo1 y FingerTemplates.Dedo2).
¶ 14/02/2013
¶ Vigilante
¶ Mejoras
- Nueva funcionalidad para los carnés de acompañante de manera que el padre/madre/tutor del menor solamente pueda acompañarlo en el horario de las actividades/cursillos (obviando de esa manera otros permisos de acceso del menor como por ejemplo por el hecho de ser socio/abonado, etc.)
|
[Puerto p Terminal t]
|
| PermisoAcompañamientoSoloParaActividades=Si |
|
[Parametros]
|
| MatrizPermisosAccesoPersonasDinamica=Si | ' Tiene que estar habilitada la matriz dinámica. |
- Nueva funcionalidad para conocer el estado de las baterías de las cerraduras Ojmar OTS (mediante tarjetas de proximidad Mifare).
- Cuando se desbloquea/libera una cerradura Ojmar OTS, si ésta tuviera su batería baja, se guarda en la tarjeta de proximidad Mifare dicha incidencia junto con el número de cerradura/taquilla. De manera que, al realizarse el acceso de salida por parte del usuario, se guardará en la BB.DD. de Accesos dicha incidencia (Tablas Taquillas y AccesosTaquillas).
- Compatible con el protocolo STS3000 y lectores Obid o Ojmar Collector.
- Ahora se registran en la tabla de Accesos el número de carné usado (al menos para el protocolo STS3000). Por ejemplo:
- 0000000004EB4739 para un carné de proximidad.
- MANUAL (161784) para un acceso manual de la persona nº 161784.
- 300161784XX para un acceso tecleado en el lector de la persona nº 161784
- Se ha temporizado el mensaje de pérdida de conexión con el Vigilante Remoto de manera que tras 10 segundos desaparecerá.
¶ 17/12/2012
¶ Vigilante
¶ Mejoras
- Nueva funcionalidad en la versión 3.0 para el consumo de bonos en función del tiempo de estancia por tramos.
- En la definición de los usos de un bono (DeporWin -> Fichas -> Conceptos -> Seleccionamos el bono -> Acceso -> Tipo de entrada) indicaremos que queremos consumir usos en función del tiempo de estancia y definiremos un tipo de consumo.
- Si no definimos ningún tipo de consumo el consumo será por minutos.
- Ya no hace falta activar el parámetro del Vigila.ini [Parametros].ConsumirUsosEnFuncionTiempoEstancia (si lo activáramos todos los bonos de acceso sería consumidos en función del tiempo de estancia).
.jpg "DeporNews")
.jpg "DeporNews")
¶ 15/11/2012
¶ Vigilante
¶ Mejoras
- Añadido soporte para los terminales de Gantner GATAccess6100Enroll para permitir la grabación de tarjetas de proximidad sin huella vinculada (útil, por ejemplo, para personas con problemas en la identificación biométrica).
.jpg "DeporNews")
- En los dispositivos STS3015 (biométricos), cuando su protocolo de autentificación es la verificación (1:1), se podrá personalizar el umbral de identificación (security level) para cada usuario.
- El terminal tiene que tener actualizada la versión del firmware a la 0.04.00,Oct 5 2012 o superior.
- Una vez grabada la huella para una persona podremos personalizar el umbral de identificación desde el DeporWin -> Fichas -> Personas -> Acceso -> Doble click en el icono de la huella.
- Al estar configurado el terminal en modo de verificación ya no se permitirán identificaciones (1:N). Si se quisiera admitirlas tendríamos que usar el protocolo de autentificación mixto (el 3).
.jpg "DeporNews")
|
[Puerto p]
|
| UmbralIdentificacion=9 | ' umbral de identificación por defecto [1-1/10, 2-3/100, 3-1/100, 4-3/1.000, 5-1/1.000, 6-3/10.000, 7-1/10.000, 8-3/100.000, 9-1/100.000, 10-3/1.000.000, 11-1/1.000.000, 12-3/10.000.000, 13-1/10.000.000, 14-3/100.000.000, 15-1/100.000.000] |
|
[Puerto p Terminal t]
|
| TipoTerminal=STS3015 |
| ProtocoloAutentificacion=2 | ' Verificación |
| AutentificacionRequerida=Si |
| AutentificacionRequeridaConBiometria=Si |
- En los dispositivos STS3015 (biométricos), cuando su protocolo de autentificación es la identificación (1:N), se podrá personalizar el umbral de identificación (security level) por defecto.
|
[Puerto p]
|
| UmbralIdentificacion=9 | ' umbral de identificación por defecto [1-1/10, 2-3/100, 3-1/100, 4-3/1.000, 5-1/1.000, 6-3/10.000, 7-1/10.000, 8-3/100.000, 9-1/100.000, 10-3/1.000.000, 11-1/1.000.000, 12-3/10.000.000, 13-1/10.000.000, 14-3/100.000.000, 15-1/100.000.000] |
- En los dispositivos Sagem MorphoAccess se podrá personalizar el umbral de identificación y/o verificación (matching threshold) por defecto.
- Una vez grabada la huella para una persona podremos personalizar el umbral de identificación desde el DeporWin -> Fichas -> Personas -> Acceso -> Doble click en el icono de la huella
|
[Puerto p]
|
| UmbralIdentificacion=5 | ' umbral de identificación por defecto [0-1/10, 1-1/100, 2-3/1.000, 3-1/1.000, 4-3/10.000, 5-1/10.000, 6-1/100.000, 7-1.000.000, 8-1/10.000.000, 9-1/100.000.000] |
¶ Correcciones
- No funcionaban los accesos manuales ni las aperturas manuales para el protocolo Gantner.
- En el protocolo Sagem Morpho Access, si la tabla de sincronismos pendientes tenía muchos registros, la consulta para sincronizarlos tardaba en exceso.
- En el protocolo STS3000, al tener habilitado el control de presencia con autentificación requerida, si el empleado se identificaba con una tarjeta de proximidad y tecleaba su contraseña, aunque ésta fuera correcta siempre se le denegaba el acceso.
- En el protocolo STS3000, al tener habilitado el control de presencia sin autentificación requerida, si el empleado se identificaba con una tarjeta de proximidad no se le dejaba acceder por motivo contraseña incorrecta.
- El lector PCR300 no emitia señal sonora diferenciada entre acceso correcto e incorrecto. Se implementa 2 beeps para acceso correcto y 3 beeps para acceso incorrecto.
- No se permitía el acceso a un cliente con una reserva de recurso si esta tenía una hora tardía tal que sumándole el margen de acceso de salida sobra la hora fin de la reserva se superaba las 23:59:59.
¶ 03/10/2012
¶ Vigilante
¶ Mejoras
- Nueva funcionalidad para los terminales BioMax con teclado, donde el usuario podrá teclear un identificador de reserva y poder entrar/salir en el horario de acceso correspondiente.
|
[Parametros]
|
| CalcularOrigenesPosibles=Si |
| CalcularOrigenesPosiblesReservas=Si |
|
[Puerto p Terminal t]
|
| NumeroCarnetProximidadConIdReservaDecimal=Si |
- Nuevo protocolo implementado para control de dispositivos Provis de proximidad. Cada puerto puede controlar 2 dispositivos conectados en el mismo puerto COM.
|
[Puerto p]
|
| TipoLector= Provis o ProvisProx |
|
[Puerto p Terminal t]
|
| IdTerminal = 1 'Master IdTerminal = 2 ' Slave |
- Se implementa nuevo tipo de codificación para tarjetas de banda magnética de Infinit Igualada.
|
[Parametros]
|
| TipoCodificacionCarnets=3 |
¶ 31/08/2012
¶ Vigilante
¶ Mejoras
- Nuevo protocolo para los lectores de proximidad y biometría de Gantner GATAccess.
- Se necesita tener instalado el Microsoft FrameWork 3.5 para su correcto funcionamiento.
|
[Puerto p]
|
| TipoLector=GANTNER |
|
[Puerto p Terminal t]
|
| IdTerminal=IP:Puerto | ' Puerto por defecto 8000 |
| TipoTerminal=GATAccess6100 | ' GATAccess6100 (Lector de proximidad), GATAccess6100Bio (Lector de proximidad con biometría), GATAccess6100Enroll (Grabador biometría) |
- Validación remota con múltiples centros. Cuando un usuario realice un acceso con una tarjeta de proximidad desconocida para el centro actual, el Vigilante podrá intentar validar el acceso con otros Vigilantes remotos. Esta funcionalidad será útil para "Cadenas de centros", donde cada uno dispone de su propia BB.DD., pero tienen un convenio para que determinados usuarios pueden acceder a todos (o parte) de dichos Centros.
|
[Puerto 1]
|
| ValidarAccesoEnVigilanteRemoto=Si |
| CantidadVigilantesRemotos=2 | ' Cantidad de Vigilantes remotos con los que se intentará validar |
|
[Puerto 1 Terminal 1]
|
| IdTerminal=1 |
| ValidarAccesoEnVigilanteRemoto=Si |
|
[Puerto 1 Vigilante Remoto 1]
|
| IP=80.81.156.120 | ' Dirección IP (normalmente WAN) del centro remoto |
| PuertoTCP=5010 | ' Puerto TCP del Vigilante remoto (este Vigilante tiene que tener activado el ServidorVigilante) |
| Puerto=5 | ' Puerto de la sección [Puerto ?] que representa la puerta remota |
| Fotos=\\SERVIDOR REMOTO 1\Fotos | ' Ruta UNC de las fotos del centro remoto . Tiene que ser una ruta compartida y accesible remotamente. Si no queremos mostrar fotos ponemos "Fotos=NINGUNO" |
| Alias=TER | ' Alias del centro remoto. Se mostrará como prefijo del nombre del usuario. |
|
[Puerto 1 Vigilante Remoto 2]
|
| IP=80.81.145.13 |
| PuertoTCP=5014 |
| Puerto=4 |
| Fotos==\\SERVIDOR REMOTO 2\Fotos |
| Alias=ENV |
|
[Puerto 5] en el Vigila.ini correspondiente al Vigilante Remoto 1
|
| TipoLector=PUERTA_REMOTA | ' Representa a la puerta remota |
|
[Puerto 5 Terminal 1]
|
| IdTerminal=1 | ' Debe coincidir con el identificador del terminal en el Vigilante original |
| ' Los demás parámetros "lógicos" de esta sección deberían coincidir con el original (Tipo de entrada, puerta lógica, coherencias, edades, ...) |
¶ Correcciones
- En el protocolo HandKey Remoto se producía un error "91 La variable de tipo Object o la variable de bloque With no está establecida" en el comando "ComandoAccesoCorrecto" para el caso de NO reutilizar un Handkey como entrada y salida.
- Cuando reutilizábamos un mismo lector HandKey en un torno con control de entrada y salida, si el usuario que accedía solamente tenía derecho de acceso por haber contratado un bono de entradas, no se le permitía el acceso en la salida (se detectaba como acceso de entrada incoherente).
¶ 19/07/2012
¶ Vigilante
¶ Mejoras
- Registro de fecha y hora de creación en la tabla de accesos,
- Nueva funcionalidad para reutilizar un mismo lector HandKey en un torno con control de entrada y salida. La solución planteada pasa por vincular terminales virtuales a los diferentes dispositivos de esa misma electrónica.
- Se usará la parametrización del terminal virtual para definir su lógica funcional y de acceso (tipo de entrada, coherencias, salida de relé, tiempo de zumbador para accesos incorrectos, ...)
|
[Puerto 1]
|
| TipoLector=HANDKEY_REMOTO | Sólo disponible para el protocolo HandKey con HandKey Server |
|
[Puerto 1 Terminal 1]
|
| IdTerminal=6 | Terminal que representa al HandKey a compartir |
| TipoEntrada=1 | Entrada |
|
[Puerto 2]
|
| TipoLector=VIRTUAL | Virtual |
|
[Puerto 2 Terminal 1]
|
| IdPuertoVinculado=1 |
| IdTerminalVinculado=6 | El identificador del terminal vinculado |
| TipoEntrada=2 | Salida |
¶ 27/04/2012
¶ Vigilante
¶ Mejoras
- Nueva funcionalidad en la versión 3.0 para controlar que se hayan cobrado todos los consumos realizados durante la estancia/acceso.
- Los consumos se realizarán en puntos interiores del reciento de acceso generando ventas desde DeporWin v3.0 con una forma de pago "Cargo a Estancia" usando la aplicación InfoTerminal.
- El cobro de estos consumos pendientes se realizará con DeporWin v3.0 desde un punto de recepción cercano a la salida del recinto de acceso. Mediante un concepto de caja con tarificación horaria para cobrar el tiempo excedido, y a su vez, estos consumos pendientes.
|
[Puerto p Terminal t]
|
| ControlarConsumosPendientesEstancia=Si |
- Nueva opción, en el protocolo STS3000, para mostrar la información relativa a la taquilla de un acceso concreto. Seleccionamos con el botón secundario del ratón el acceso y pulsamos el botón "Taquilla".
|
[Puerto p Terminal t Dispositivo d]
|
| TipoTarjetaTaquilla=OjmarMifare | Hay que tener definido algún tipo de tarjeta de taquilla válido |
¶ Correcciones
- Integración recuperador pulseras Ojmar
- Se realiza la integración del recuperador de pulseras Ojmar con el objetivo de situarlo en la salida de un acceso y recuperar las pulseras de las entradas puntuales. La misma pulsera se utilizará para el control de acceso y las taquillas.
|
[Puerto p Terminal t Dispositivo d]
|
| TipoDispositivo=OjmarCollector | Necesario para inicializar protocolo |
| Baudios=115200 |
| DisponibleDisplay=si | Se permite mostrar mensajes de Vigilante en dispositivos conectados a STS3000 |
¶ 15/02/2012
¶ Vigilante
¶ Mejoras
- Terminales en modo de consulta. La idea es disponer de terminales donde los usuarios pueden consultar cierta información sobre su "tarjeta".
- Estos terminales deberían ser terminales con display (de pared por ejemplo). Implementado de momento para los protocolos STS3000 y Biomax.
- La información que de momento se podrá consultar será:
- 1) La situación de los bonos vigentes que tenga contratados (número de usos pendientes/totales de cada uno de ellos)
- 2) Las inscripciones puntuales que tenga contratadas (clase, sala, fecha, hora, plaza, ...). Se emitirá un doble sonido para indicar si ahora está en el horario de una clase.
- Estas consultas, obviamente, no registran ningún acceso ni consumen ningún uso.
|
[Puerto x Terminal y]
|
| TerminalConsulta=Si |
| TerminalConsulta_MostrarBonos=No |
| TerminalConsulta_MostrarInscripcionesPuntuales=Si |
| TerminalConsulta_FormatoInscripcionesPuntuales=%ABREVIATURANOMBREACTIVIDAD% - %ABREVIATURARECURSO%%CRLF%%FECHA% %HORAINICIO% %NUMEROPLAZA%/%TOTALPLAZAS% | ' Formato |
¶ Correcciones
- En la pestaña de "Accesos" no se mostraba el nombre de la persona si ésta tenía el nombre, el primer apellido o el segundo a nulo.
¶ 25/01/2012
¶ Vigilante
¶ Mejoras
- Para el protocolo BioMax1, en las lecturas procedente de la entrada TTL, podremos configurar el carácter de inicio por defecto de la trama.
|
[Puerto p Terminal t]
|
| CaracterInicioTramaOnTrackBiomaxTTL=! | ! o bien * para la entrada TTL0, $ para la entrada UART0 |
¶ 13/12/2011
¶ Vigilante
¶ Correcciones
- Se permitía acceder a las personas que habían pertenecido a una entidad que ahora ya no lo es (EsEntidad = No) si ésta última tenía una reserva de recursos para ella.
¶ 16/11/2011
¶ Vigilante
¶ Mejoras
- Nuevos parámetros para indicar si queremos controlar o no, para un terminal dado, el número máximo de usos y/o el tiempo de estancia máximo en un periodo. Puede sernos útil para en determinados terminales NO realizar estas comprobaciones y, de esta manera, hacer excepciones a la norma de acceso.
|
[Puerto p Terminal t]
|
| ControlarNumeroMaximoUsosPeriodoPersona=Sí |
| ControlarTiempoEstanciaMaximoPeriodoPersona=Sí |
- Nueva funcionalidad para reutilizar de una misma electrónica (STS3000 o BioMax) para 2 o más puntos de acceso. Por ejemplo, puede ser útil para ahorrar costes en un torno con control de entrada y salida. La solución planteada pasa por vincular terminales virtuales a los diferentes dispositivos de esa misma electrónica.
- Se usará la parametrización del terminal virtual para definir su lógica funcional y de acceso (tipo de entrada, coherencias, salida de relé, tiempo de zumbador para accesos incorrectos, ...)
|
[Puerto 1]
|
| TipoLector=STS3000 | Disponible para los protocolos STS3000 o Biomax |
|
[Puerto 1 Terminal 1]
|
| IdTerminal=IP:Puerto | Terminal que representa a la electrónica a compartir |
| TipoTerminal=STS3000 | (con sus distintas variantes) |
|
[Puerto 2]
|
| TipoLector=VIRTUAL |
|
[Puerto 2 Terminal 1]
|
| IdPuertoVinculado=1 |
| IdTerminalVinculado=IP:Puerto |
| IdDispositivoVinculado=3 | 0-Cualquier dispositivo, 1=(Serie 0), 2=(Serie 1), 3=(Wiegand 0), 4=(Wiegand 1) |
¶ 24/10/2011
¶ Vigilante
¶ Mejoras
- Nueva funcionalidad en el protocolo STS3015 para reactivar las huellas de usuarios que estuvieran desactivados. Se recupera la huella que anteriormente teníamos grabada, por lo que no hace falta que grabarla de nuevo.
- Nueva funcionalidad en la validación de accesos con "validador externo" para controlar la relectura de una misma tarjeta. Se usará la misma parametrización que en el caso de validaciones normales.
- Nueva funcionalidad para permitir el acceso a los integrantes de un equipo que hayan efectuado una reserva de recursos en nombre de dicho equipo.
¶ 10/10/2011
¶ Vigilante
¶ Mejoras
- Nueva funcionalidad para soportar la identificación por NIE (número de identificación de extranjero) tecleándolo desde un terminal STS3000. Para teclear la {X, Y, Z} del primer dígito del NIE tendremos que usar la tecla "*" (varias pulsaciones rotará entre X, Y, Z, blanco)
¶ Correcciones
- En el protocolo STS3000 si se tecleaban valores numéricos de más de 9 dígitos se producía un error de desbordamiento.
¶ 27/09/2011
¶ Vigilante
¶ Correcciones
- VigilaMonitor. Si un usuario había estado más 32767 minutos dentro del centro, se producía una excepción de "desbordamiento" en la aplicación "Monitor del Vigilante".
¶ 09/09/2011
¶ Vigilante
¶ Mejoras
- Restricciones de acompañamiento: Nueva funcionalidad para comprobar las restricciones de acompañamiento también en los accesos de salida
|
[Puerto p Terminal t]
|
| ComprobarAcompañamientoEnSalida=Si |
- Inicialización de tarjetas Ojmar OTS. Nueva funcionalidad para inicializar y grabar en un mismo paso tarjetas de proximidad Mifare compatibles con el sistema de bloqueo de taquillas Ojmar OTS. Desde el "Vigilante -> Grabar carnet" tendremos una nueva opción "Inicial. + Grabar" (importante seguir los pasos de colocación/retiro de la tarjeta tal como el programa nos irá indicando).
|
[Puerto p Terminal t Dispositivo d]
|
| TipoDispositivo=ObitCPR |
| Baudios=38400 | ' Parámetro INI |
| Bits=8 | ' Parámetro INI |
| Paridad=E | ' Parámetro INI |
| Stop=1 | ' Parámetro INI |
| LeerDataBlock=Si | ' Necesario |
| DataBlock_DireccionInicial=16 | ' 4*Sector de datos de Ojmar OTS |
| DataBlock_ByteInicial=0 | ' Parámetro INI |
| DataBlock_Longitud=32 | ' Parámetro INI |
| DataBlock_TipoClave=B | ' Parámetro INI |
| DataBlock_Clave=00008627C10A | ' Parámetro INI |
| DataBlock_NecesarioParaLeer=No | ' Parámetro INI |
| TipoTarjetaTaquilla=OjmarMifare | ' Parámetro INI |
| TarjetaTaquilla_CodigoInstalacion=1234 | ' Código de la instalación en hexadecimal (4 dígitos) |
| TarjetaTaquilla_NumeroSectorDatos=4 | ' Sector 4 para no interferir con Technogym |
| TarjetaTaquilla_ZonasAccesoPermitido=0000 | ' Zonas de acceso de las taquillas. En hexa (4 dígitos). (Matriz de bits 0-permitido, 1-no permitido) |
| TarjetaTaquilla_CantidadTaquillasLibres=1 | ' Cantidad de taquillas que podrá tener bloqueadas simultaneamente |
¶ Correcciones
- En los accesos de acompañantes se estaba validando el "tiempo mínimo para volver a entrar", con lo que, en el caso de más de un acompañante, al segundo de ellos (o siguientes) no le dejaba entrar.
¶ 05/08/2011
¶ Vigilante
¶ Mejoras
- COM Remoto: nueva funcionalidad para configurar que, o bien use puertos de comunicaciones de Microsoft, o bien de Sax.
|
[COMRemoto] del Vigila.INI en la máquina local que ejecuta el COM Remoto
|
| TipoPuertoCOM_Conexion5001=2 | ' 1 - Microsoft, 2 - Sax |
- Nueva funcionalidad para la librería STS3000.ocx. Ahora podrá usarse para lectores conectados directamente al puerto serie (o puerto serie vía COM Remoto) sin necesidad de disponer de un terminal STS físico.
- Inicialmente se soporta el protocolo para los lectores Obit CPR
|
[Puerto p Terminal t]
|
| IdTerminal=COMx en IP:Puerto | ' x: puerto COM, en IP:Puerto (opcional) la dirección IP y puerto del COM Remoto |
- Nueva funcionalidad para acceder mediante un carné de proximidad con número de serie el IdReserva codificado en hexadecimal. Útil, por ejemplo, para los terminales con teclado que generan un número de carné en hexadecimal de lo que se haya tecleado y luego se transmiten vía puerto Weigand (por ejemplo: lectores Rosslare con proximidad).
|
[Puerto p Terminal t]
|
| NumeroCarnetProximidadConIdReservaHexadecimal=Si |
¶ 14/06/2011
¶ Vigilante
¶ Mejoras
- Validación de acceso con un "validador externo". Para el caso de accesos de personas "externas" que se les quiera dejar entrar en nuestras instalaciones tendremos la opción de delegar la validación del acceso en un "validador externo". Se considerarán personas externas aquellas que accedan con un carné de proximidad que no esté dado de alta en nuestro sistema. La comunicación entre el Vigilante y el "validador externo" será normalmente mediante un "Servicio Web".
- Nuevo validador externo para el "Ayuntamiento de Vitoria" para el protocolo STS3000 con lectores de proximidad Mifare Obit CPR.
|
[Puerto p Terminal t]
|
| IdTerminal=192.168.2.199:2000 | Esta dirección IP será la usada en el WebService para identificar al torno. |
| ValidarAccesoEnValidadorExterno=Si |
| TipoValidadorExterno=AyuntamientoVitoria |
| URLValidadorExterno=https://dwww.vitoria-gasteiz.org:443/j2203/ws/services/ControlAccesoBAKH |
|
[Puerto p Terminal t Dispositivo d]
|
| TipoDispositivo=ObitCPR |
| Baudios=38400 |
| Bits=8 |
| Paridad=E |
| Stop=1 |
| LeerDataBlock=Si |
| DataBlock_DireccionInicial=4 |
| DataBlock_ByteInicial=0 |
| DataBlock_Longitud=64 |
| DataBlock_TipoClave=A |
| DataBlock_Clave=A0A1A2A3A4A5 |
| DataBlock_UsarComoNumeroTarjeta=No |
| DataBlock_UsarComoIdTercero=No |
| DataBlock_NecesarioParaLeer=No |
' Parámetro INI
¶ 23/05/2011
¶ Vigilante
¶ Mejoras
- Se soporta lectores de proximidad conectados a los puertos UART0 y/o UART1 para los terminales BioMax2.
- Nueva funcionalidad para no almacenar las huellas en terminales biométricos STS3015 grabadores (nos puede ser útil en instalaciones con muchos usuarios con el fin de que los tiempos de grabación sean rápidos). La implementación consistirá en vaciar la BD de huellas de dichos terminales grabadores cada vez que se reinicie el Vigilante o cada vez que se pulse F6. Y aunque tengamos varios terminales grabadores no se sincronizarán entre ellos.
|
[Puerto p Terminal t]
|
| TerminalGrabador=Sí |
| SincronizarFingerTemplates=No |
- Si tenemos activada para los terminales de salida la opción de "AbrirPuertaSiempre" el mensaje que veremos en el Vigilante así como en el "display" del terminal será el configurado para las "salidas correctas" (normalmente "vuelva pronto"). En caso del que el acceso sea incorrecto (p.ej. no identificado biométricamente) tampoco se mostrará información detalla del error.
- Ampliados los mecanismos de acceso desde el teclado de una STS.
- F1 - Acceso por código de usuario (hay que habilitar el parámetro DisponibleTecladoParaPersonas del Vigila.INI)
- F2 - Acceso por DNI del usuario (hay que habilitar el parámetro DisponibleTecladoParaPersonas del Vigila.INI)
- F3 - Acceso por código de la entrada/bono (hay que habilitar el parámetro DisponibleTecladoParaEntradas del Vigila.INI).
- F4 - Acceso por código de tarjeta (hay que habilitar el parámetro DisponibleTecladoParaTarjetas del Vigila.INI).
- Sin tecla de función - Acceso por código según el siguiente heurístico:
- --> Códigos de 7 u 8 dígitos -> acceso por DNI del usuario
- --> Código de otras longitudes y sí tarjeta vigente --> acceso por código de la tarjeta
- --> Código de otras longitudes y sí entrada vigente --> acceso por código de la entrada/bono
- --> Código de otras longitudes y ni entrada ni tarjeta vigente -> acceso por código de usuario
¶ 02/05/2011
¶ Vigilante
¶ Mejoras
- Máscara de proximidad en los puertos Wiegand. Tendremos la opción de forzar usar una máscara de proximidad a los dispositivos conectados a los puertos Wiegand de una STS3000.
|
[Puerto p Terminal t Dispositivo 4]
|
| ForzarUsarMascaraProximidad=Si |
¶ Correcciones
- En el caso de calcular la matriz de permisos de acceso de las personas dinámicamente ('al vuelo'), no se registraba correctamente en la tabla AccesosDetallados el campo IdAbono.
¶ 18/04/2011
¶ Vigilante
¶ Mejoras
- Para los terminales STS3000 se permitirá el funcionamiento con identificadores de personas de hasta 8 dígitos (anteriormente estaba limitado a 6 dígitos).
¶ Correcciones
- En los accesos con carné de persona no se permitía la entrada/salida a una "zona interior", en el último uso de uno bono, porqué éste ya se había consumido en el acceso de la "zona principal". La configuración correcta sería 2 recintos (una para la zona principal y otra para la interior) y en el recinto interior tener los parámetros ComprobarUsosEntradas=No y PuertaInterior=No.
¶ 04/04/2011
¶ Vigilante
¶ Mejoras
- Control de acceso en partidos externos. Se permite el acceso a las personas que hayan realizado una reserva de un "partidos externo", tanto para el caso que la reserva esté a su nombre directamente (particular) como para el caso que esté a nombre de una entidad, a la cual deberá pertenecer.
¶ 21/03/2011
¶ Vigilante
¶ Correcciones
- En el VigilanteMonitor, aunque se tuviera el parámetro MostrarInformacionDetalladaAcceso=No, se seguía mostrando la información detallada si en el Vigila.exe se tenía activada el parámetro MostrarInformacionDetalladaEnDisplay.
- Correcciones en el protocolo para el lector de proximidad Promag PCR300 por USB (con emulación de puerto serie integrada)
¶ 01/03/2011
¶ Vigilante
¶ Correcciones
- En los lectores de huellas Sagem MA500 no se estaba usando el parámetro TiempoPulso para determinar la duración de la activación del relé en los accesos correctos.
¶ 25/02/2011
¶ Vigilante
¶ Mejoras
- Nueva opción para mostrar o no los accesos de determinados terminales en la pantalla principal del Vigilante. Podremos diferenciar entre los accesos correctos e incorrectos.
|
[Puerto p Terminal t]
|
| MostrarAccesosCorrectos=Sí |
| MostrarAccesosIncorrectos=Sí |
- Nueva protocolo para el lector de proximidad Promag PCR300 por USB (con emulación de puerto serie integrada)
|
[Puerto p]
|
| TipoLector=PCR300 |
| TipoPuertoCOM=2 |
¶ 11/02/2011
¶ Vigilante
¶ Correcciones
- En la versión anterior del DSuite se distribuyó una versión de la librería de Microsoft para el tratamiento de comunicaciones TCP/IP (MSWINSCK.OCX) perteneciente al "Cumulative Update del VB6 del 2009" que tenía un error crítico (no obtenía correctamente la dirección IP del Vigilante). Hemos revertido el cambio a la anterior librería del 2004.
¶ 17/01/2011
¶ Vigilante
¶ Mejoras
- En los accesos manuales se ha habilitado la búsqueda rápida de personas mediante F3
- Menores acompañados. Nueva funcionalidad para controlar que una persona menor de X años no pueda entrar si ninguno de sus "tutores" no se encuentra dentro de la instalación. Se consideraran como tutores a:
- El cabeza de familiar de su abono familiar
- Los demás integrantes de su abono familiar que sean mayores de edad.
- Su titular económico tutor (definido desde Fichas -> Personas -> Económico).
- Su tutor (definido desde Fichas -> Personas -> Personal)
- Otros tutores (definidos desde Fichas -> Personas -> Perfiles -> Tutores)
|
[Puerto p Terminal t]
|
| EdadAcompañamiento=12 | Edad hasta la cual se controla la presencia de un acompañante de un menor |
| AcompañanteDentro=Si |
| TiempoMaximoAcompañanteHaEntrado=0 | Tiempo límite (en minutos) para que pueda entrar el menor desde que su acompañante haya entrado (0-sin control) |
¶ Correcciones
- No se permitía el acceso a las entradas/bonos vendidas dentro de una reserva de tratamientos.
¶ 24/12/2010
¶ 29/11/2010
¶ Vigilante
¶ Mejoras
- En el control del tiempo máximo de estancia de los abonados (cuando esté definido en minutos/diarios), se descontará del tiempo total de estancia la duración de los cursillos que estén incluidos en dicha estancia.
- Nueva opción para calcular la matriz de permisos de acceso de las personas dinámicamente ('al vuelo'). De esta manera ya no sería necesario que DeporWin recalcule la matriz cada día en la BD de Permisos.
|
[Parametros]
|
| MatrizPermisosAccesoPersonasDinamica=Si |
- Desactivada la emulación de teclas de función para los teclados externos de la familia Rosslare AYC-Qx4 conectados al puerto serie de una STS3000
¶ 29/10/2010
¶ Vigilante
¶ Mejoras
- Cambiado el mensaje por defecto de "Supera Umbral Identificación" por "No identificado". Se modifica el Vigila.INI si estuviera mal.
¶ Correcciones
- A veces no se activaba el relé en los accesos correctos. Esto sucedía cuando la conexión de red era muy lenta y se producían 2 órdenes de apertura muy rápidas.
¶ 20/10/2010
¶ Vigilante
¶ Mejoras
- Grupos de sincronismo en la descarga de bases de datos de huellas para los protocolos STS3015 y Sagem MorphoAccess. Por ejemplo, nos puede ser útil para separar en grupos los usuarios de una BB.DD. conjunta por centros.
¶ 27/09/2010
¶ Vigilante
¶ Mejoras
- Configurable el tiempo de activación del zumbador en los accesos incorrectos para los terminales STS3000
|
[Puerto p Terminal t]
|
| TiempoZumbidoAccesosIncorrectos=1000 | 'tiempo en milisegundos |
¶ 30/07/2010
¶ Vigilante
¶ Mejoras
- Control de taquillas liberadas de Ojmar. Nuevo parámetro para impedir las lecturas de tarjeta donde no se haya podido leer el bloque de datos con la información de la taquilla. Esto sucedía si por ejemplo el usuario no dejaba la tarjeta en el campo magnético del lector el tiempo suficiente.
|
[Puerto p Terminal t Dispositivo d]
|
| DataBlock_NecesarioParaLeer=Si | ' Fuerza una lectura completa de la tarjeta |
¶ 13/07/2010
¶ Vigilante
¶ Mejoras
- En terminales con display tendremos la opción de mostrar el nombre el usuario que está accediendo.
|
[Puerto p Terminal t]
|
| MostrarInformacionDetalladaEnDisplay=Si | ' Mostrará detalles del acceso en el display |
| MostrarNombreUsuariosEnDisplay=Si | ' Mostrará el nombre del usuario en el display |
- El Vigilante ya no usará la BD de Permisos para obtener la matriz horaria de las entradas puntuales/bonos sino que la calculará "al vuelo" según la definición de dicha entrada/bono.
¶ Correcciones
- Aumentado el time-out a 60 segundos en la grabación de huellas STS3015 para que dé tiempo suficiente si se registran dos dedos en el proceso de grabación.
¶ 05/07/2010
¶ Vigilante
¶ Mejoras
- La consumición de entradas/bonos para las personas sin matriz horaria de acceso ya no requerirá que tengan la marca "acceso permitido" activada.
- Acceso a los monitores de las actividades. Se permite el acceso a los monitores en el horario de las actividades de estén impartiendo. Dichos accesos se registrarán con NumeroCursillista=0.
¶ 23/06/2010
¶ Vigilante
¶ Mejoras
- Control de taquillas liberadas de Ojmar. Nueva funcionalidad para impedir la salida de un usuario si éste NO ha liberado todas las taquillas de uso libre. Necesitaremos un lector ObitCPR conectado a una STS3000 y tarjetas Mifare.
|
[Puerto p Terminal t]
|
| ComprobarTaquillasLiberadas=Si | ' Activar el control de salida solo para taquillas liberadas |
|
[Puerto 1 Terminal 1 Dispositivo 1]
|
| TipoDispositivo=ObitCPR |
| TipoTarjetaTaquilla=OjmarMifare |
| LeerDataBlock=Si |
| DataBlock_DireccionInicial=16 | 'Sector 4 |
| DataBlock_ByteInicial=0 |
| DataBlock_Longitud=32 | '32 bytes |
| DataBlock_TipoClave=B |
| DataBlock_UsarComoNumeroTarjeta=No |
| DataBlock_UsarComoIdTercero=No |
| DataBlock_Clave=00008627C10A | 'Clave para lectura del bloque de datos |
¶ Correcciones
- Al regrabar la huella de un usuario que ya existía (lectores biométricos STS3015), en su posterior sincronización en los demás terminales, si alguno de ellos daba el error TerminalIsBusy no se reintentaba la grabación.
- Ampliado el tiempo de Time-Out en la sincronización de huellas de los terminales STS3015 (para evitar fallos de sincronización con lectores con más de 5.000 huellas grabadas)
¶ 11/06/2010
¶ Vigilante
¶ Correcciones
- Al regularizar la ocupación de un recinto no se refrescaba en la barra de título ni en el relé de control de aforo.
¶ 10/06/2010
¶ Vigilante
¶ Correcciones
- Modificado el valor por defecto del parámetro DisponibleTeclado a "No" para el protocolo STS3000.