Reglas de marcaje. Ejemplos.

Configuración de reglas de marcaje

¿Qué son las reglas de marcaje?

Son un conjunto de parámetros que con los marcajes y el horario planificado permiten
establecer qué tiempo de presencia cuenta como tiempo trabajado y cuál no.

Tipos de reglas de marcaje

Hay 2 tipos:

  • Cortesía
    • Modelo más restrictivo.
    • Los márgenes de entrada/salida suelen ser de pocos minutos y tienen un impacto nulo en el cálculo de la jornada efectiva.
    • Se contempla la cortesía por parte de la empresa y la cortesía por parte del empleado/a.
  • Flexibilidad
    • Modelo más flexible.
    • Se indican los minutos de adelanto/retraso máximos respecto a las entradas/salidas teóricas que se validarán como correctos.

Al crear un convenio desde el Asistente y definir las reglas de marcaje, se crea un nuevo conjunto de reglas y quedan asociadas a ese convenio. No obstante, las reglas de marcaje son independientes del convenio y se pueden crear independientemente desde Datos maestros -> Contadores. De modo que puede haber más de un convenio con las mismas reglas de marcaje.

Parámetros

Al crear/editar un convenio, desde el apartado reglas marcaje visualizamos los parámetros que debemos configurar.

Estos parámetros también están visibles desde el editor avanzado de las reglas de marcaje. Para acceder a esta ventana hay 2 formas:

  • A partir de un convenio ya creado, al abrirlo desde el asistente aparecerá un link al lado de “Reglas de marcaje”. Presionando este link se abrirá el editor avanzado.
  • Desde Datos maestros -> Contadores, presionando una reglas de marcaje del listado.

Así se visualizan los parámetros desde el editor avanzado.

Pestaña Marcajes1:

Pestaña Marcajes2:

Márgenes

En los márgenes se indica si se trata de un sistema flexible o de cortesía.
Se utiliza para validar si los marcajes introducidos son correctos y si los minutos de estos márgenes se deben considerar como presencia en horario o no.

Ámbito de jornada

Se utiliza para definir cómo cuentan las horas trabajadas. Se puede definir mediante una referencia a la hora del día o mediante una referencia relativa al inicio/fin del horario.

Referencia a hora del día
Cualquier marcaje previo al inicio de ámbito nunca cuenta como hora trabajada.
Cualquier marcaje posterior al fin de ámbito nunca cuenta como hora trabajada.

Referencia relativa al inicio/fin del horario
Esta referencia se contabiliza en minutos, indicando un umbral de entrada y un umbral de salida.

Pausa

Hay 2 casillas que sirven para indicar cómo deben evaluarse los descansos no retribuidos y las pausas de los turnos partidos.

  • Pausa no retribuida (PNR)*: Se informa en minutos y siempre va entre corchetes en la definición del turno. Ejemplo: 9-18[60] -> es una pausa de 60 minutos.
  • Pausa del turno partido: Se encuentra en los horarios con punto y coma en su definición. Ejemplo: 9-14;15-18 -> es una pausa de 14 a 15.

Si las casillas están marcadas, se descontarán siempre estas pausas.

*Modos de contar pausa no retribuida (PNR)

Si configuras un ciclo con pausas incluidas (las que se colocan con los símbolos [] ) contarán como horas trabajadas:

  • Cuando no fichan la pausa: Descontará siempre el valor entre corchetes.
  • Cuando fichan la pausa: Descontará directamente la duración de la pausa fichada, salvo que ésta sea menor que la configurada entre corchetes. En ese caso tenemos dos opciones, escoger que el programa descuente la duración real del fichaje (es la opción por defecto) o bien que reste la duración entre corchetes íntegra, para ello hemos de marcar la opción en el convenio Descontar pausa no retribuida de forma íntegra siempre.

% de verosimilitud

También llamado “Margen horario alternativo”, es el porcentaje mínimo de verosimilitud para considerar un horario válido a partir de los marcajes. Es decir, cuánto en porcentaje se debe parecer el horario que ficha un empleado (horario basado en los marcajes) con el horario previsto para que sea un horario válido.

Su función es identificar el parecido entre los marcajes y un horario, con el objetivo de que salte una alerta cuando los marcajes no se parezcan lo suficiente al horario planificado o a cualquiera de los turnos válidos de la persona.

Su fórmula de calculo es la siguiente:

%verosimilitud = (tiempo_de_presencia_que_solapa_con_el_horario/tiempo_horario – tiempo_de_presencia_fuera_del_horario/tiempo_de_presencia_que_solapa_con_el_horario)*100

Ejemplo: horario 6-14 y marcajes 09:00 y 17:00.

  • Tiempo de presencia que solapa con el horario = 5h (de 9-14)
  • Tiempo de presencia fuera del horario = 3h (de 14-17)
  • Tiempo del horario = 8h (de 6-14)
  • %verosimilitud = ((5/8)-(3/5))*100 = 2.5%
  • Con unas reglas cuyo porcentaje sea superior al 2.5%, esta jornada quedará por revisar con el motivo “Sin horario aproximado”.

Admite horas de más

Indica si el número de horas que cuentan inferidas de los marcajes puede superar la duración de la jornada prevista (horas del horario asignado).

Se puede limitar el tiempo de más con el parámetro “Máximo tiempo de más”.

Casilla “No tratar marcajes con incidencias-marcas”

Cuando se activa “No tratar marcajes con incidencias-marcas” ocurre lo siguiente.

En el caso de fichar una incidencia del tipo permiso ausencia existen 3 hipótesis de trabajo:

  • Si el primer marcaje asociado a la incidencia es posterior al inicio teórico del horario de ese día, GT interpreta que la ausencia va del inicio teórico hasta ese marcaje.
  • Si es un marcaje asociado a la incidencia y es intermedio, GT interpreta que la ausencia va desde ese marcaje hasta el siguiente de ese día.
  • Si es un marcaje asociado a la incidencia y es el último del día y es anterior al fin teórico del horario de ese día, GT interpreta que la ausencia va desde ese marcaje hasta el fin teórico.

En cualquier otro caso, no hace nada. Esto cuando las incidencias implican ausencia.

En el caso de las marcas:

  • Cuando es el primer motivo de marcaje y es anterior al inicio teórico, se aplica una marca desde ese primer fichaje y hasta el siguiente fichaje.
  • Si el marcaje es el último y es posterior al fin teórico, aplica la marca desde el fin teórico hasta ese último fichaje.
  • Si el marcaje es el último y es anterior al fin teórico, no aplica marca.

Si no se activa la casilla “No tratar marcajes con incidencias-marcas”:

  • Si el primer marcaje asociado a la incidencia es posterior al inicio teórico del horario de ese día, GT interpreta que la incidencia va del inicio teórico hasta ese marcaje.
  • Si es un marcaje asociado a la incidencia y es intermedio, GT interpreta que la incidencia va desde ese marcaje hasta el siguiente de ese día.
  • Si es un marcaje asociado a la incidencia y es el último del día y es anterior al fin teórico del horario de ese día, GT interpreta que la incidencia va desde ese marcaje hasta el fin teórico.

En el siguiente artículo hay más información y ejemplos gráficos: https://gps-plan.com/ayuda/kgps/comportamiento-de-los-motivos-de-marcaje

Ejemplos

En este artículo mostraremos, a modo de ejemplo, diferentes configuraciones de las reglas de marcaje que pueden resultar útiles para entender el funcionamiento de la herramienta.

Ejemplo Convenio CORTESÍA

Trabajadora con horario LMX 9-18[60] JV 15-22[30].

El lunes 03/02 tiene las mismas horas de presencia que el miércoles 05/02 (9h), pero en cambio las horas efectivas de estos 2 días son diferentes:

  • Horas efectivas 03/02 = 8:00
  • Horas efectivas 05/02 = 6:30

El motivo es que el día 05/02 hace horas presenciales fuera de los márgenes indicados en las reglas de marcaje, por tanto, es tiempo fuera de horario que no cuenta. Lo podemos ver en el informe Tramos horarios:

En todos los días se resta el tiempo de la pausa no retribuida, ya que tenemos marcada la casilla “Descontar pausa no retribuida de forma íntegra siempre”. Si la casilla no está marcada, ésta sólo se descontará íntegramente en aquellos casos en los que la empleada no fiche la pausa. En caso de ficharla, si es inferior a la teórica, no se añadirá la diferencia (entre la pausa teórica y la real) como PNR.

Si analizamos el día 06/02, la trabajadora le quita 10 minutos de cortesía a la empresa, pero este tiempo cuenta como horas efectivas.

  • Horario 06/02: 15-22[30]
  • Marcajes 06/02: 15:05 y 21:55.
  • Horas presencia 06/02: 06:50. Pero si descontamos la pausa no retribuida (30min) quedarían 06:20. En cambio las Horas efectivas son 06:30, es decir, está contando los 10 minutos de cortesía a cargo de la empresa.

Otro aspecto importante es ver si los marcajes son correctos o no. Hemos editado el informe Marcajes para añadir las columnas “Tipo marcaje” (indica si es Entrada o Salida), “Tipo de registro” y “Status”.

Si comparamos los días 05/02 y 06/02, en los dos hay entradas y salidas anticipadas. No obstante, los marcajes del 05/02 no son correctos y los del 06/02 sí son correctos, ya que estos últimos están contemplados como cortesía.

Ejemplo Convenio FLEXIBILIDAD

Las reglas de marcaje siguientes son un ejemplo de flexibilidad en la entrada y la salida.

Trabajador con horario 9-18[60].

En todos los días se resta el tiempo de la pausa no retribuida, ya que tenemos marcada la casilla “Descontar pausa no retribuida de forma íntegra siempre”.

Por ejemplo, si comparamos el 03/02 con el 05/02, vemos que las horas de presencia son idénticas (9h), pero las horas efectivas cambian. El día 03/02 tiene 7h efectivas, una menos que el día 05/02, ya que el tramo de 6-7 está fuera de los márgenes indicados en las reglas.

Ejemplo Convenio FLEXIBILIDAD TOTAL

Las reglas de marcaje siguientes son un ejemplo de flexibilidad total.

Al poner en los márgenes todo a 1440 min (1 día), nos aseguramos que en el informe Tramos horarios se indicará “horas de presencia en horario” y no “horas fuera de horario que cuentan”. Es decir, consideraremos el tiempo como presencia en horario. A nivel de horas efectivas, da lo mismo 1440 que 0.

Al marcar “Admite horas de más inferidas de los marcajes”, todas las horas de más contarán como Horas efectivas.

Trabajadora con horario 9-18[60].

Otros ejemplos

Horario de lunes a viernes de 8 a 18 con flexibilidad habiendo que trabajar 8’5h al día

Definimos el ciclo L-V 8-18 [90]. Esto indica que trabajan de lunes a viernes de 8 a 18 con 90 minutos de pausa no retribuida.

En la configuración de reglas de marcaje tenemos las opciones:

  • “Descontar pausa no retribuida de forma íntegra siempre”
    • Si está seleccionado, siempre restaremos los 90 minutos de pausa aunque haya comido en media hora.
    • Si no está seleccionado, se contará el tiempo real de presencia (hasta 8,5 o no en función del siguiente punto).
  • “Admite horas de más inferidas de los marcajes”
    • Si lo tiene seleccionado, si se queda hasta las 19, le contaríamos 9,5 horas.
    • Si no lo tiene seleccionado, solo le contaremos las 8,5. Excepcionalmente le podemos cambiar el horario planificado para que le cuente las horas de más.

Horario con flexibilidad según los requerimientos siguientes

  • De lunes a jueves
    • Horario flexible de entrada de 8-9:30h.
    • Pausa comida:
      • Software Dev. & Ops y Product Management: 13:30h
      • Resto: 14h
    • Flexibilidad de comida entre 45 y 80 minutos.
    • Salida a partir de las 17:25h en función de la hora de entrada y duración de la comida.
    • Se dispondrá de una pausa de 15 minutos para desayuno a cargo del trabajador.
  • Viernes
    • Horario flexible de entrada de 8-9:30h.
    • Salida a partir de las 15h en función de la hora de entrada.
    • Se dispondrá de una pausa de 15 minutos a cargo de la empresa.
  • Jornada intensiva
    • Del 25/06/2018 al 31/08/2018.
    • Horario flexible de entrada de 8-9:30h.
    • Salida a partir de las 15h en función de la hora de entrada.
    • Se dispondrá de una pausa de 15 minutos a cargo de la empresa.

Definimos el ciclo que le debemos aplicar a esos empleados: L-J 8-17:25 [60] V 8-15

Este indica que el horario de lunes a jueves es de 8 a 17-25 con 60 minutos de pausa no retribuida (15 desayuno +45 comida). El viernes, como la pausa es retribuida, no lo indicamos en el ciclo.

  • Al haber Flexibilidad las cortesías deben ser de 0 minutos en todos los lados
  • Descontar pausa no retribuida de forma íntegra siempre, si no lo marcamos, solo la descontará si se hace… por lo que no obliga a hacerla
  • Ámbito de jornada:
    • Inicio: si no vamos a contar horas de presencia antes de las 8, pondremos las 8:00.
    • Fin: Sumamos la hora más tarde de salida posible: 19:35 (hora de entrada 8:00 + flexibilidad de 1:30+ flexibilidad en comida)
    • Admite horas de más inferidas de los marcajes, si no está seleccionado, solo vamos a contar las horas máximas del horario: 9:25 menos las pausas (íntegras o no).

Ficha del empleado

Desde la ficha del empleado se puede consultar información sobre los horarios, contratos, fichajes y mensajes de una persona, además de acceder a los datos personales.

Ficha del empleado

PDF calendario anual

Desde la ficha, pulsando el icono de Imprimir, se obtiene el calendario anual de la persona.

ATENCIÓN: El siguiente contenido es de uso avanzado y su utilización puede ocasionar daños irreparables en la configuración del sistema

En este calendario es posible parametrizar el logo mostrado, desde el menú de administración “Info configuración -> App – Conf. Cliente –> Configuración de documentos”

Los textos representados en el PDF se parametrizan a través de las variables del informe llamada TextoCaja1, TextoCaja2 y TextoCaja3

Cliente Windows

Lista de contratos

La información que se muestra en la lista de contratos de la ficha del empleado se puede personalizar modificando la consulta ContractWorkerForWorker.

Para acceder al editor de vistas y desde allí modificar el orden de las columnas que se muestran en la lista de contratos de la ficha del empleado se debe:

1.- Pulsar y MANTENER PULSADAS las teclas CONTROL+SHIFT

2.- Botón derecho en la lista de contratos

Saldrá lo siguiente:

3.- Pulsar tecla ESC en el teclado

4.- Escoger opción “Seleccionar el tipo de filtro”

Se mostrará el editor de vistas del listado de contratos del empleado.

Como vemos en la pantalla, ahora está seleccionada la vista “Inicial” que es remota.

Al ser remota, si hago cambios en ella (moviendo columnas, por ejemplo), al abrir otro empleado volverá a la definición original.

Tenemos dos opciones.

1.- Modificar la vista remota llamada “Inicial” para agregar o modificar el orden de las columnas. Esto afectará a todos los usuarios

2.- Escoger en el selector de vistas, una que no sea remota. Y a partir de ahí, podrá hacer cambios que serán persistentes. Esto sólo afecta al usuario que realiza ese cambio.

Impresión de tarjeta identificativa

Desde la ficha del empleado, existe la opción de imprimir la tarjeta identificativa de la persona. Ésta incluye información personal y un código de barra asociado a su código como persona trabajadora. Para hacerlo, podemos acceder a:

Tarjeta identificativa
Tarjeta identificativa

Configuración

En la sección <ServerConfig> del fichero QueryCustom.xml se pueden establecer las siguientes propiedades:

SecciónClaveDescripciónValor por defecto
GeneralLoadInfoHorarisIndica si en el calendario se ha de cargar la información relativa a los horarios planificados.true
ShowSuperTextInfoCalendarIndica si en el calendario se han de mostrar los nombres de los los horarios jornada planificados (Ver LoadInfoHoraris). Si se deseactiva esta variable, sólo se verán los colores asociados a los horarios, en lugar del nombre de los mismos.true
LimitNumberOfCharsIndica si se ha de limitar o no el nº de carácteres a utilizar para mostrar el nombre de los horarios.true
NumberOfCharsToLimitNúmero de carácteres límite que tendrá el nombre del horario jornada mostrado en el calendario.1
DrawAllIncidencesOnWorkerEditorIndica si se digujan en el calendario todas las incidencias (true) o se ocultan las No Visibles (false) .true

Opciones disponibles como empleado/a

La aplicación para móviles se puede obtener desde las tiendas online y proporciona la siguiente funcionalidad:

  • Acceso a los calendarios de trabajo
  • Información sobre los contadores de presencia
  • Acceso a petición de permisos y consulta de su estado
  • La posibilidad de realizar fichajes desde la App y mediante geolocalización
  • Consulta de datos personales

Importante: para que un empleado pueda acceder a la App es necesario que se haya activado la opción “Acceso portal” desde su ficha personal en la aplicación. Además el usuario del login que utilice debe estar vinculado con dicha ficha de empleado.

Marcajes

Registrar marcaje

Con esta la funcionalidad es posible introducir las horas de entrada y salida desde la App:

  1. Activar la geolocalización en el móvil v
  2. Seleccionar la opción del menú “Marcajes”
  3. Seleccionar el botón “+” para introducir el marcaje
  4. Seleccionar el motivo del marcaje (opcional)
  5. Pulsar Introducir marcaje

A continuación aparecerá el marcaje registrado en el día en curso.

Consulta de marcajes

Desde la pantalla de marcaje de la App: hacer clic el día mostrado y modificarlo por el que se quiere consultar.

Requisitos previos

Al inicio del proyecto es esencial asegurarse del cumplimiento de una serie de requisitos previos de hardware & software de terceras partes, relativos a las aplicaciones a instalar. Estos requisitos dependerán del tipo de instalación que se pretende hacer, que puede ser de 2 tipos: instalación en la nube y instalación on premise:

Requisitos generales

  1. Navegador Google Chrome (v69 aprox.)
  2. MICROSOFT EXCEL (versión 2010 en adelante): Es imprescindible tener instalado y activado en el PC para las exportaciones de informes, así como las importaciones de datos maestros (cargas desde excel).
  3. Sistema operativo de la estación de trabajo o terminal: Windows 8 o Windows 10.

Tipo de instalación

INSTALACIÓN GT EN LA NUBE (Cloud)

  1. No requiere instalación previa.

INSTALACIÓN GT ON PREMISE

  1. La instalación en el servidor seleccionado por el cliente se realizará por parte de técnicos cualificados (ver Instalación en Servidor).
  2. Requisitos básicos: Windows Server 2016 R2 o superior con 8GB de RAM.
  3. Mínimo 20GB libres de disco.
  4. Para recibir actualizaciones será necesario un acceso a Internet
  5. Configuración de la App . Consulta los detalles en Instalación App

SISTEMA DE FICHAJES

En general, se recomienda que el sistema de fichadas esté en funcionamiento con anterioridad a la implantación de GT y se tiene que saber en qué directorio guardará el fichero para que se programe la tarea de lectura de dicho fichero.

Hay 2 Opciones:

  • Opción 1: lectura de fichajes desde una página web de GT o bien desde la App para móviles. Es parte del producto, y sólo hay que asegurarse de que se han creado los usuarios adecuados.
  • Opción 2: fichajes mediante relojes de lectura instalados por el cliente (de tercera partes). En este caso se deben cumplir los siguiente requisitos previos adicionales:
    • Relojes instalados. los relojes ya deben estar ya instalados en la red del cliente y funcionando.
    • Empleados y huellas ya configurados: los empleados deben haber sido ya registrados en el software de control de dichos relojes (ya sea por huella o tarjeta) y haber sido asociados a cada marcaje registrado mediante algún código.
    • MUY IMPORTANTE – exportación de marcajes: el software de control debe ser capaz de volcar los datos de fichajes en un fichero de texto de forma periódica (5 minutos, 10, 30, 60, ó 1 vez al día) sobre una carpeta de la red que será accesible desde GT .Por ejemplo: \\Servidor_A\marcajes o bien una carpeta local del servidor. Nota: se recomienda enviar una muestra de este fichero, indicando también el fabricante de los relojes, antes de la configuración de la aplicación GT, para verificar su compatibilidad, aunque en general se puede configurar una amplia variedad de formatos diferentes.
    • Listado de nombre y códigos asociados: un volcado en texto/excel de todos los empleados registrados incluyendo: nombre completo, código asociado en el reloj, y (si tiene nómina integrado) si es posible se usará el mismo código asignado por la nómina al empleado como código de fichaje.

Si la instalación es cloud: en el caso que GT vaya a usarse directamente en la nube se precisará también la instalación de un programa en la red del cliente o clienta para poder transferir los datos contenidos en ese fichero a la nube. Será necesario proporcionar un acceso remoto a un servidor de la red para efectuar esta configuración. En el apartado Envío de marcajes en instalaciones cloud se detalla toda la información.

Atención! Importante: el software responsable de gestionar las huellas de las empleadas y empleados y registrar todos los relojes conectados a la red es el propio software de control suministrado con los mismos, quedando esta configuración fuera del alcance de GT.

INTERFACE CON NÓMINA

El proveedor de Nómina (A3) debe haber instalado el programa de sincronización (interface) entre NÓMINA y GT. En tal caso se tiene que tener preparado una serie de datos para poder configurar correctamente el GT al iniciarlo por primera vez (por ej. Codigo Cliente, Usuario & Clave que da acceso al sistema de nominas para la extracción de datos, etc.). Estos datos seran necesarios para configurar el Asistente de GT.

Si se integran datos de nómina, antes de empezar la implantación, ya tendríamos algunos datos en BOLD (Absentismos, contratos, Empresa, etc…) Que podremos aprovechar para la implantación de GT.

Anulaciones

Desde este apartado podemos anular, según los criterios de cada cliente, las solicitudes creadas.

Dentro del apartado anulaciones, encontramos la anulación de permisos / vacaciones, la anulación de intercambios y la anulación de reducción / excedencia.

Anulación de permisos/vacaciones, anulación de intercambios y anulación de reducción/excedencia

Si pulsamos sobre anulación de permisos/vacaciones, anulación de intercambios o anulación de reducción/excedencia aparece el siguiente desplegable. En caso de querer anular un permiso o solicitud, hay que pulsar sobre rellenar solicitud.

En otra pestaña, emerge el listado de peticiones sobre permisos o vacaciones que tiene la persona empleada. En el listado, se muestra el ID del formulario, la fecha de petición, el motivo de la petición, el inicio y el fin del mismo. Se selecciona el formulario deseado para anularlo.

Otras opciones que hay en este mismo apartado, son visualizar las anulaciones de permisos o solicitudes, en proceso, denegadas, aprobadas y todas las solicitudes.

En el caso de solicitar una anulación sobre un permiso que aún no estaba aprobado por ningún responsable, esa anulación se completa automáticamente y no precisa de gestión alguna posterior.

Procesar marcajes

El procedimiento de procesar marcajes consiste en revisar y corregir los marcajes erróneos de las jornadas.

La función del gestor o gestora es la de corregir las incidencias (faltas de marcaje, entradas y/o salidas anticipadas, retrasos, etc.) e ir revisando los registros conflictivos, como resultado del procesado de marcajes.

Marcajes

Los marcajes horarios se pueden visualizar (o no) sobre el Gantt.

Para activar la visualización por el Gantt:


1. Pulsa en Filtros / Visualización de datos.
2. Marca Mostrar marcas de reloj.


Existen distintas marcas en colores verderojoazul o negro dependiendo de si son: entradas o salidas, antes o después de su horario planificado, marcajes imprevistos, manuales o faltas de marcaje.

Indicadores

Indicadores con marcas de distintos colores:

  Azul (marcaje manual)

  Verde (marcaje real con entrada antes de hora o salida después de su horario).

  Rojo (marcaje real con entrada después de hora o salida antes de su horario previsto)

  Líneas discontinuas (significa ausencia de marcaje)

Negro (marcajes inesperados)

Lila (marcajes automáticos, fruto de un automatismo)*

Naranja (solicitudes de marcaje aprobadas manualmente o automáticamente)*

Gris (marcaje real que coincide con el horario planificado)**

*Para más información, en este enlace se explica el funcionamiento de los automatismos.

**Disponible desde la versión 2.1. En versiones anteriores a la v2.1, los marcajes reales que coincidían con el horario planificado no se mostraban con ninguna marca identificativa y las marcas se usaban para indicar que algo NO coincidía con lo planificado.

Incidencias

Es importante distinguir entre dos tipos de incidencias:

  • Las de recogida de datos: marcajes impares, ausencia de marcajes.
  • Las relativas a la hora en que se ha realizado el marcaje (entra más tarde, se va antes, etc.), o bien a otros cambios posteriores al procesamiento original.

Procesamiento de marcajes y revisión de registros

Cabe destacar que, aunque el sistema se alimenta de los marcajes, se debe asegurar que todos han sido procesados antes de analizar cualquier dato. Los resultados de contadores y cálculos solo serán válidos si todos los marcajes han sido procesados. Es por ello que la persona gestora, al iniciar su jornada de trabajo, deberá clicar en el botón Procesar, para que los marcajes recibidos se procesen.

En el caso de los clientes de Wolters Kluwer esta acción se hace de forma automática cada noche. En otros clientes, por defecto está desactivado, pero se podría activar el procesado automático. Y la idea es que, si no es automático, la acción de PROCESAR se haga una vez al día.

Una vez pulsado el botón, el color deberá pasar de ROJO a LILA:

  

Una vez corregidos los marcajes, el número en el interior de la bola deberá ir disminuyendo:

  ⇒ 

La herramienta ofrece un resumen sobre la situación de los marcajes cuando se pasa el cursor sobre el botón PROCESAR, aparece un mensaje detallando los errores pendientes:

Para ver las jornadas por revisar hay que ir al informe de Revisión de marcajes. Posicionando el cursor encima de PROCESAR se despliega “Revisión de marcajes” y haciendo click encima se abrirá el informe. Pueden aparecer varios motivos de revisión de marcajes:

  • Ausencia de marcajes: no hay marcajes en la jornada.
  • Marcajes impares: los marcajes de la jornada son impares.
  • Incompatibilidad de ausencias: en una jornada hay una ausencia y marcajes. Por ejemplo, un empleado está de IT y esa jornada ficha, esto no tiene sentido y debe revisarse.
  • Sin horario aproximado: el sistema no encuentra un horario válido a partir de los marcajes con el % de verosimilitud informado en las reglas de marcaje.
  • Cambio en el horario planificado: cambios en horario del plan con con posterioridad al instante de procesado (es poco común porque normalmente un cambio de horario manual reprocesa la jornada automáticamente).
  • Cambio en las marcas del reloj: inserción de marcajes con fecha de inserción posterior al instante de procesado (no confundir con la fecha que refleja el marcaje).
  • Cambio en las incidencia del empleados: inserción de incidencias con posterioridad al instante de procesado.

Las 3 últimos no son tan usuales y aparecen siempre que la jornada conste como procesada correctamente, pero su fecha (instante en el que se procesó) es anterior a cualquiera de esos tres cambios.

Procesar marcajes por Revisión de marcajes

Hay una opción para procesar una parte de los trabajadores que tiene el usuario dentro de sus permisos, que es a través del informe de revisión de marcajes:

En el Gantt debe haber el área de planificación o el grupo de personas que de los que se quiera procesar sus marcajes.

Seleccionar: Procesar –> Revisión de marcajes.

Nos ofrecerá fechas de inicio y fin y se deberá clicar Generar a partir del Gantt. Estas fechas de inicio y fin se pueden modificar.

Una vez tengamos el informe:

A- nos permite modificar las fechas de inicio y fin. B- Para poder refrescar en caso de cambio de fechas.

C- Seleccionar todos los elementos de la página. Podemos seleccionar todos los elementos o ir clicando uno por uno.

D- Revisar marcajes para procesar, reprocesar o eliminar el procesado. Siempre de la página que esté en pantalla, para las siguientes páginas se debe avanzar y volver a realizar la operación.

Procesar los marcajes seleccionados.
Reprocesar marcajes seleccionados ya procesados.
Elimina el procesado. No elimina el marcaje procesado, elimina la acción de procesar de los marcajes seleccionados.

Procesar año en curso

Existe una opción que permite procesar los marcajes de un intervalo de tiempo determinado, pudiendo procesar hasta todo el año. Es la opción “Procesar año en curso” ( Seleccionar: Procesar –> Procesar año en curso):

Al presionar esta opción aparecerá una ventana donde indicar la fecha de inicio y la fecha de fin del intervalo a procesar. A partir de la v1.9.2 está disponible la casilla “Forzar procesado”, que al marcarla se eliminará la información procesada anteriormente antes de reprocesarse nuevamente. Es útil marcar la casilla cuando hay cambios de configuración que precisan reprocesar nuevamente todo el periodo.

  • Si no se marca la casilla: se procesarán las jornadas del intervalo indicado, pero solo aquellas que no estaban procesadas. Las jornadas que ya estaban procesadas anteriormente se quedarán como estaban, no se realizará ninguna acción sobre ellas. No se realiza un reprocesado, solo un procesado.
  • Si se marca la casilla: se reprocesarán todas las jornadas del intervalo indicado, estuvieran procesadas o no. Es decir, se eliminará el procesado de las jornadas dejándolas “por procesar” y seguidamente se procesarán.

Corrección

Los conflictos resultantes se pueden resolver básicamente de dos formas (que pueden ser complementarias):

  1. Desde el propio diagrama de Gantt.
  2. Desde la lista de Revisión de marcajes:
  • Se accede desde cualquier pantalla clicando en Procesar y a continuación, en la opción que aparece a continuación: revisión de marcajes.

A continuación, se explicará cómo resolver tres conflictos, en primer lugar, a través del Gantt y después a través de la lista de revisión de marcajes.

Los conflictos son:

  1. Daniel Cruz 17/7, Marcajes impares (le falta la salida).
  2. Iván Muñoz 17/7, Se le hizo un cambio en horario planificado después de procesar la jornada (además tiene ausencias de marcajes).
  3. Paloma Blasco 16/7, Ausencia de marcajes (E/S).

Desde el Gantt

Los 3 conflictos anteriores se ven con claridad en esta captura del Gantt:

Para corregir el primer caso, Daniel Cruz:
 Clica en Editar marcajes

 A continuación, clica en el día 17/07/2018: solo aparece el marcaje de entrada, a las 07:40, pero falta el de la salida.

En este caso, el gestor o responsable debería aclarar con el empleado Daniel Cruz por qué no consta en la herramienta el marcaje de salida.

  • Si se tratara de un descuido, el gestor podría introducir manualmente dicho marcaje, reconociendo al empleado que había cumplido su horario hasta las 15 horas, es decir, escribiría manualmente las 15:00 para que el marcaje quedara recogido y corregido en el Gantt:

Al finalizar esta acción, nos aparecerá una marca azul, al final de la jornada, indicando que hubo una corrección manual del marcaje.

Desde la opción Revisión de marcajes

En la vista del informe de revisión de marcajes, selecciona el empleado, individualmente, y, con el botón izquierdo del ratón, aplica lo que corresponda en cada caso: Corregir, Añadir, Modificar un horario o Aplicar una incidencia, en el caso de falta de marcaje.

A continuación, se explicará detalladamente cómo resolver los marcajes de los demás casos hipotéticos, es decir, una ausencia de marcaje de Paloma Blasco y un cambio en horario planificado de Iván Muñoz.

Aplicar incidencia

Paloma Blasco tiene una ausencia de marcaje. Para corregirla, se aplicará una incidencia: un día de baja:

Una vez corregido este marcaje, debe desaparecer del listado:

Aplicar marcajes según horario

Selecciona a Iván Muñoz y reconoce el horario que tenía previsto (08-15), con la opción Aplicar marcajes según horario:


El listado ha quedado limpio y sin ningún aviso de marcajes por procesar / corregir:

Al volver al Gantt, los cambios de marcajes se verán con las siguientes marcas en éstos tres casos hipotéticos:

  • Daniel Cruz ahora tiene una marca azul al final de la jornada ⇒ Corrección en el horario de salida.
  • Iván Muñoz tiene dos marcas azules ⇒ Se le reconocen los horarios tanto de entrada como salida.
  • Paloma Blasco tiene indicada la ausencia como BAJA, en rojo.

Está sería la vista del Gantt con los tres errores de marcaje, una vez corregidos:

Cambiar horario

(*) Todas las opciones que se describirán se pueden realizar directamente en el Gantt o en el informe.

Hay otras opciones de incidencia, en el que la solución sea un cambio de horario, ya que los marcajes difieren de la jornada planificada.

Un trabajador finaliza su turno más tarde, o entra antes de la hora planificada, por lo que el marcaje es posterior al fin de su jornada. En este caso, en el Gantt nos aparecerá una marca verde.

Clicando encima de la jornada a la opción Editar marcaje, podemos ver la hora exacta que ha marcado el trabajador. Posicionándonos encima de la marca del Gantt también podríamos obtener la misma información.

Tenemos un horario planificado que difiere de los marcajes del trabajador. Si ese tiempo de más, es un tiempo que le debemos reconocer como trabajado, debemos modificar su horario, y esto lo podemos hacer de diferentes maneras.

1.Opción Cambiar horario + flecha verde: BOLD nos sugiere los horarios más parecidos al horario fichado. Si uno de ellos es el correcto, clicamos en el check verde.

2.Opción Cambiar horario + introducir horario: Clicar en Cambiar horario y escribir el horario que sería correcto con los marcajes.

3.Cambiar el horario directamente en el Gantt: Clicar encima de la jornada y escribir el horario que queremos asignar.

Un trabajador finaliza su turno antes, o entra más tarde de la hora planificada, por lo que el marcaje es anterior al fin de su jornada. En este caso, en el Gantt nos aparecerá una marca roja.

Clicando encima de la jornada a la opción Editar marcaje, podemos ver la hora exacta que ha marcado el trabajador. Posicionándonos encima de la marca del Gantt también podríamos obtener la misma información.

Tenemos un horario planificado que difiere de los marcajes del trabajador. Si ese tiempo que ha faltado, es un tiempo que le debemos reconocer como no trabajado, debemos modificar su horario, y esto lo podemos hacer de las mismas formas que el caso anterior.

Aparecen marcajes inesperados, puede ser uno o más. En este caso, en el Gantt nos aparecerá una o más marcas negras, dependiendo de los marcajes realizados.

Clicando encima de la jornada a la opción Editar marcaje, podemos ver la hora exacta que ha marcado el trabajador. Posicionándonos encima de la marca del Gantt también podríamos obtener la misma información.

Tenemos un horario planificado que difiere de los marcajes del trabajador. Si se tiene que reconocer ese tiempo como trabajado, debemos modificar su horario, y esto lo podemos hacer de las mismas formas que el caso anterior.

Motivos de marcaje

Podemos relacionar los marcajes a un motivo concreto que implicará la asignación de una incidencia desde/hasta el momento del marcaje. Pincha aquí para mas información.

La forma de fichar una ausencia se define en el siguiente gáfico:

Añadir anexo de jornada

Hay una opción de añadir de manera directa, al modificar el horario una incidencia que identifique el anexo de jornada. Esta opción se explica en el siguiente link.

RTI – Real Time Interface

Introducción

La integración entre varios sistemas se suele plantear mediante cargas batch programadas con una frecuencia determinada. Dependiendo de la entidad a sincronizar entre las aplicaciones BOLD y los sistemas corporativos, esta frecuencia es diferente. Por ejemplo, en el caso del traspaso de días festivos, es suficiente con una o dos cargas anuales, pues se trata de una información que no suele cambiar repetidas veces. Sin embargo para entidades como los empleados en plantilla, es necesario aumentar la frecuencia, para evitar que los diferentes sistemas relacionados trabajen con información diferente.

En entornos donde se trabaja con múltiples aplicaciones interdependientes, resulta fundamental que éstas compartan los datos de la forma más rápida posible. De no ser así es inevitable que los procesos de trabajo se acaben por amoldar a la velocidad en que los datos se trasladan. Por poner un ejemplo, si la sincronización de contratos nuevos se realiza una vez al día, eso supone que tras la generación de un contrato en los sistemas de información correspondientes, resulte imposible trabajar con él desde el punto de vista de planificación hasta pasado un día, momento en el cual el nuevo contrato será trasladado a otras aplicaciones. Este problema lleva a la necesidad de incrementar la frecuencia de traspaso de datos. Al llevar esta solución al límite nos encontramos con una barrera insuperable: la duración de la tarea batch. No tiene sentido volver a lanzar una tarea antes de haber terminado su anterior ejecución. Así, si el proceso de carga de empleados dura una hora, nos veremos forzados a efectuar sincronizaciones como máximo cada hora. Lo cual es un grave inconveniente por la carga de CPU que conlleva, siendo ésta, continua y afectando directamente a los usuarios. Al existir estas dificultades, tanto de limitación en la frecuencia máxima y de consumo de CPU elevado, es necesario plantearse otro método de sincronización de sistemas cuando el tiempo resulta un factor fundamental a la hora de trabajar con varias aplicaciones que comparten datos.

BOLD Real Time Interface aparece por la necesidad de conseguir una integración incremental y en tiempo real de las aplicaciones BOLD con los sistemas corporativos del cliente. La idea es transferir la información en el mismo momento en que ésta se introduce en alguna de las aplicaciones implicadas en el proceso de sincronización. Con ello conseguimos, por una parte que el proceso sea incremental (solo transferimos la entidad afectada), logrando por tanto que los requerimientos de CPU sean mucho menores, y por otra parte, conseguimos también que la información esté disponible en los diferentes sistemas de forma inmediata, pues la transferencia se inicia justo cuando se produce un cambio en alguno de los sistemas. BOLD Real Time Interface se ocupa de almacenar, traducir y transmitir de forma ordenada los mensajes que se producen en las diferentes aplicaciones de forma que todas ellas se encuentren sincronizadas.

El sistema BOLD Real Time Interface

BOLD Real Time Interface utiliza protocolo SOAP para recibir los mensajes procedentes de las diferentes aplicaciones. Estos mensajes se reciben a través de una serie de WebServices publicados directamente por el servidor BOLD RTI. Existe la posibilidad de comunicar la nueva información directamente sobre una base de datos SQL Server. BRTI es un servidor de webservices que se instala como servicio de sistema y permanece a la espera de que le sea comunicada información a transmitir al resto de aplicaciones. El sistema permite la recepción de los mensajes en cualquier formato (siempre dentro de los standards XML), pues antes de que los mensajes sean enviados a los destinatarios, se efectúa una, o varias, traducciones. De esta forma al contar con BRTI como intermediario a la hora de transmitir información aseguramos las transformaciones necesarias para trasladar un mismo dato que en varias aplicaciones se representa de forma diferente.

Arquitectura del sistema BOLD RTI

Es importante comprender que BOLD RTI es un sistema bidireccional, con lo cual los mensajes pueden partir tanto de las aplicaciones BOLD y continuar con el traslado de información hacia el resto de sistemas corporativos como en sentido contrario. Podría darse el caso incluso de utilizar BRTI para comunicar dos sistemas corporativos entre sí, sin necesidad de que intervengan en el proceso otras aplicaciones BOLD aparte de BRTI. La dirección y procedencia de los mensajes se indican mediante información extra que añaden los emisores a los mensajes SOAP.

Detalles de funcionamiento

Estados:

Cada operación del RTI tiene asociado un estado que indica como se encuentra actualmente. Los diferentes estados posibles y su significado se explican a continuación:

  • Estado = 0 (Pendiente de validar); Son aquellas operaciones que han llegado a la BD pero que no han sido confirmadas como tratables y por tanto se omiten.
  • Estado = 1 (Validado); Es el primer estado en que figuran las operaciones cuando llegan al BRTI. Son operaciones completamente pendientes de tratar.
  • Estado = 2 (Transformado); Aparece normalmente despues del estado 1. Se corresponde con las operaciones a las que se les ha aplicado su transformación, quedando entonces pendiente solamente el envío del mensaje.
  • Estado = 3 (Encolado); No se utiliza.
  • Estado = 4 (Enviado); Este estado indica que una operación se ha enviado correctamente al otro sistema y estamos esperando su ACK (negativo o positivo). Los mensajes que viajan desde un sistema externo a WP no utilizan este estado pues WP no retorna ACK.
  • Estado = 5 (Error); Este estado indica que se ha producido un error durante el tratamiento del mensaje.
  • Estado = 6 (Descartado); La operación se ha descartado manualmente, esta marca indica que no se ha de tratar.
  • Estado = 7 (Correcto); La operación ha completado todas sus etapas y se puede considerar como completada.

Recepción:

Tal y como se ve en el gráfico, BRTI comienza su secuencia de trabajo al recibir un mensaje webservice. Este mensaje WebService ha de contener:

  • Información acerca del origen del mensaje.
  • Destino deseado del mensaje (puede ser múltiple)
  • Tipo de entidad. (por ejemplo… calendarios)
  • Identificador de objeto. (por ejemplo… 000654)
  • Contenido con información de la operación (alta, baja, modificación…)

Validación

Una vez el mensaje ha llegado al servidor BRTI se efectúan unas validaciones técnicas básicas que indicarán si almacenamos el mensaje como adecuado para ser tratado o se ha de rechazar:

  • El origen y el destino han de estar definidos como válidos en BRTI.
  • El mensaje XML ha de ser válido.
  • No pueden existir operaciones sin completar en BRTI sobre el mismo objeto y que tengan diferente origen. (Ver punto 3.4. Gestión de colas)

Si el mensaje que se ha recibido pasa estas comprobaciones, será grabado en la base de datos de BRTI, para que posteriormente sea transformado y transferido al destino correspondiente.

Tanto si la validación acaba correctamente como si no lo hace, se informa al sistema de origen del mensaje. Si se ha producido un error, es necesario comunicarlo para que al emisor le conste que ha de realizar alguna acción (modificar algún dato, comprobar las comunicaciones, esperar a que todas las operaciones con otro origen se completen…) y volver a repetir el mensaje. Si se ha conseguido almacenar el mensaje correctamente en BD, lo comunicaremos también para que el emisor del mensaje pueda dar por válida su operación.

Gestor traducción

De forma continua, BRTI procesa los mensajes. –Incompleto-…

Gestión de colas

TBF

Requerimientos técnicos

BRTI en su modo más básico necesita únicamente de la instalación de MS SQL Server. Sin embargo, dependiendo de la complejidad de las transformaciones necesarias para traducir los mensajes que se intercambiarán las aplicaciones, es posible necesitar • Windows Script 5.6 (o superior) • MSXML4 (o superior) • BOLD XML (Para comunicar los mensajes con aplicaciones BOLD APS/WP)

Configuración de BOLD RTI

Instalación

TBF

Árbol de instalación

TBF

Carpetas de integración

TBF

URL’s WP y EXT

Para poder modificar las URL’s donde se envían los mensajes, hay que entrar en Workplanner e ir al icono: (actualizar icono)

Existen dos nodos “ConfigSystem” uno para cada sentido de la comunicación.

  • EXT-WP: entrada de información de un sistema externo hacia WorkPlanner
  • WP-EXT: envío de información de WorkPlanner hacia un sistema externo

La variable “ComunicationDir” de los nodos “ConfigSystem” nos indica donde están los ficheros de importación, en esas ubicaciones debe existir un bat llamado configure.bat que defina las variables de configuración.

Las variables relevantes para indicar los sistemas a comunicar son:

  • SERVER_SAP: establece si la comunicación será con un servidor de SAP de productivo, desarrollo, integración, etc.
  • BOLD_WP_SERVER: indica con que servidor WorkPlanner se está realizando la comunicación.

IMPORTANTE: como existen dos ComunicationDir diferentes, existirán dos configure.bat, uno en cada ubicación. Es importante modificar las variables existentes en ambos ficheros de configuración para que el sistema conserve su coherencia.

Nota: Los paths mencionados se pueden encontrar en la máquina de instalación de BRTI. Sólo existe una instalación de BRTI en cada máquina, por lo que se ha de tener en cuenta a cual se está accediendo antes de modificar los valores de las variables.

Ficheros de configuración de BOLDXML2

Los ficheros de configuración del módulo de integración BOLDXML2 se encuentra normalmente en la carpeta <cliente>/integration y son los siguientes:

BOLDXML.json

Contiene la configuración general del módulo. Las variables disponibles son:

  • “HTTPSAllowAll”: true / false. Cuando se utilizan conexiones https, indica si se permitirá crear los canales de comunicación SSL aunque los certificados proporcionados por los servidores no permitan realizar una verificación completa. Normalmente debe ponerse a true cuando se utilizan certificados temporales o que no permiten su validación a través de internet.
  • “BOLDXML_INSTALL” : “C:\\Proyectos\\Clientes\\BOLDXML2”. Indica la ubicación de la instalación del módulo.
  • “bUseSOAP_API” : true. Permite seleccionar si en las llamadas se importación de objetos contra el servidor BOLD se utilizará el protocolo SOAP o REST. Existe una limitación actualmente que obliga usar SOAP al enviar documentos XML grandes al servidor (ej.: aprox. más de 30KB)
  • TBD

Los ficheros de transformación se encuentran en la carpeta por defecto (ej.: BOLDXML2\a3), pero pueden especializarse de forma particular copiando la plantilla estándar en la cartpeta de configuración de la instancia (ver personalizar XSLT)

BOLDServer.json

Contiene la configuración de acceso al servidor BOLD. Las variables disponibles son:

  • “CLUSTER”: indica la URL completa del cluster, si está configurado (ej.: “http://localhost/bold/BOLDCluster.dll“)
  • “HOST”: “localhost” (indica la máquina que tiene instalado el servidor de WP)
  • “SYSTEM”: “/Servers/a3_local/ISAPIBoldWP.dll/soap” (indica la URL donde está instalado el servidor de WP)
  • “user”: “adm” (indica el usuario que se utilizará para las tareas de integración e interfaces)
  • “pwd”: “adm” (pwd del usuario anterior)
  • “timeout”: 180 (tiempo de espera máximo -segundos- a usar por defecto esperando una respuesta del servidor en las interfaces)
  • “SQLServer”: indica el hostname que tiene el servidor de base de datos (SQL Server) utilizado por el servidor de BOLD. Ejemplo: “sgps01”.
  • “SQLServer_database”: indica la base de datos utilizada por el servidor BOLD. Ejemplo: “OHSJD_ZAR_TEST”
  • “SQLServer_username”: usuario de acceso al SQL Server. Ejemplo: “usrdba”
  • “SQLServer_pwd”: password de acceso.

Ficheros de configuración específicos de una integración

Existen algunas integraciones preconfiguradas “estándard” contra los siguientes sistemas: a3EQUIPO, SAP ICS y SPEC. Cada una de estas integraciones dispone de su propio archivo de configuración particular.

Integración con a3EQUIPO: A3Server.json

Ver también el artículo principal: Interface con a3EQUIPO.

Integración con SAP ICS: SAPICS.json

  • “enableSFTP”: false/true. Indica si se accede o no al servidor SFTP para recoger los ficheros de intercambio de datos.
  • “SFTP_PROD” : “SFTP_server.dominio.intranet”
  • “sft_user_PROD” : “usuario”
  • “sft_pwd_PROD” : “password”
  • TBD

Integración con relojes de marcajes: SPECServer.json

Permite configurar la conexión con los Relojes SPEC (u otros):

  • “Clockings_file”: “C:/ImportExport/ohsjd/NativeXML/clockings/marcajes.csv”. Ubicación del fichero donde van apareciendo los marcajes.
  • “Export_workers_dir”: “C:/ImportExport/ohsjd/NativeXML”. Ubicación donde WP irá dejando los ficheros para el alta/baja de empleados en los relojes.
  • “ClockNames”: { “Planta Principal”: -1 }. JSON map con la lista de nombres de los relojes y su nº identificador. Atención! si no se da de alta en la lista de terminales de la aplicación este identificador no aparecerán los marcajes en pantalla.
  • TBD