Sincronización GT

Asistente: Selecciona el tipo de integración

En esta primera fase del asistente de configuración de GT habrá que seleccionar si BOLD GT debe coger datos de alguna herramienta de nómina o bién vamos a introducir todos los datos manualmente (o mediante cargas de excel).
Podremos seleccionar entre:

• Sin integración: tendremos que introducir todos los datos manualmente o mediante cargas de Excel
• Integración en a3Nom
• Integración en a3Equipo.com / a3nóminacloud / a3innuva. Deberemos introducir el código de cliente utilizado en esta herramienta
• Integrado en un servidor de a3Equipo local

Si es sin integración cuando presionemos “siguiente” se va pasar a las siguientes fases y tendremos que rellenar todos los datos

Si hay integración, una vez seleccionada la opción correcta y presionemos “siguiente” se va a realizar la sincronización de datos y al pasar a las siguientes fases nos encontraremos con algunos datos que ya constaban en la herramienta seleccionada.

Importación-Exportación

Al ejecutar esta tarea se pueden cargar (importar) en BOLD (en función de la configuración y el tipo de sincronización):

• Empresas
• Convenios
• Centros
• Permisos (tabla maestra)
• Puestos de trabajo
• Empleados
• Contratos
• Centros de coste
• Histórico de absentismos: (periodo de carga se corresponde desde el año anterior en adelante)

Se pueden exportar dos tipos de informaciones al programa de nómina.

• Absentismos: A través de la opción de menú Utilidades->Exportar absentismos a nómina. Se exportarán los absentismos que se hayan configurado en el asistente con el campo Sentido exportación establecido con el valor GT a nómina. Se puede elegir el periodo que se exporta en la ventana de Configurar interfaces, pestaña Datos a exportar. (En versiones anteriores a la 1.9.0 el periodo era fijo respecto a la fecha en curso, desde 120 días desde hoy y hasta 90 días después).
• Conceptos variables de nómina: Se suben al programa de nóminas a través del informe de Variables de nómina. Este informe dispone de un botón específico para realizar esta acción.

Se pueden realizar 2 tipos de sincronizaciones: total (Sincronización total nómina) o incremental (Sincronización incremental nómina).

La sincronización incremental no carga los datos maestros (centros, convenios o nuevos permisos); solo carga empleados, contratos y absentismos, de estos los nuevos o los cambios a partir de la fecha que se indica en la configuración.

La primera sincronización siempre tiene que ser total.

Esta tarea debe de ejecutarse manualmente cada vez que se desee traspasar nueva información desde nómina a GT.

Lanzar sincronización

Desde el Asistente > 1.Inicio seleccionar “Con integración”, abrir el desplegable y seleccionar la interface externa a sincronizar con GT.

Clicar en DATOS DE CONEXIÓN e informar los datos requeridos de la interface externa. Para probar que funciona (que la conexión sea correcta), se tiene que presionar TEST.

Si el test es correcto, aparecerá el siguiente mensaje:

Si no es correcto, aparecerá un mensaje de error y se tendrán que revisar los datos de conexión.

Clicar en CONFIGURAR INTERFACES. La pantalla de configuración se visualiza así:

Datos a cargar:

• Selector de empresas: permite elegir qué empresas se quieren sincronizar.
• Incluir solo: permite sincronizar todos los trabajadores o solo los trabajadores en plantilla (los que están con nómina).
• Convenios y pactos: se puede decidir si se sincronizan (“Importar”) o no (“Ignorar”).
• Centros de costes: se puede decidir si se sincronizan (“Importar”) o no (“Ignorar”).
• Cargar contratos a partir del día: solo se sincronizan los contratos de nómina que han estado vigentes a partir de la fecha seleccionada.
• Casilla “Actualizar siempre los centros de los empleados/as”: permite recoger el cambio de centro de un empleado en nómina y aplicar ese cambio de centro en GT.

Configuración técnica:

• Nivel de log: aquí se define qué nivel de información queremos que se muestre en los logs de la sincronización. Ordenado de menor a mayor cantidad de información, quedaría así: ERROR, WARN, INFO, DEBUG, TRACE. El nivel de log recomendado es DEBUG.
• Tiempo espera (seg.): es el tiempo máximo de espera para comenzar a recibir algún nuevo dato desde a3. Es decir, es el tiempo definido para que de TIMEOUT si no se encuentran datos.
• Fecha sincronización y Hora: A partir de la versión 1.8.2 se tiene en cuenta esta fecha para extraer los datos de a3 que hayan sido modificados después de esta fecha, tanto si se lanza una sincronización total como una sincronización incremental (en versiones anteriores a la 1.8.2 esta fecha solo se usaba para la sincronización incremental). En caso de haber lanzado una sincronización y no haya dado ningún error ni ningún aviso, estos datos se actualizarán automáticamente con la fecha y hora de la última sincronización. Si aparecen errores y/o avisos, la fecha y hora se mantendrán igual. Para los absentismos, cuando se lanza una sincronización total se tiene en cuenta como fecha de extracción de incidencias las introducidas en a3 desde el año anterior al año en curso (desde el 01/01 del año anterior al actual).

• Pestaña a3Equipo: esta opción solo sirve para aquellos clientes que migran de a3Nom a a3Equipo.

Una vez realizado el test de conexión y con los datos configurados ya se puede sincronizar:

• Clicar en SINCRONIZAR TODO (realiza una sincronización total)

• Cuando termine la sincronización, se puede acceder a los logs clicando en el botón

Otra manera de realizar una sincronización es desde:

• UTILIDADES > Sincronización total nómina (para una sincronización total)
• UTILIDADES > Sincronización incremental nómina (para una sincronización incremental)

Y para revisar los logs: UTILIDADES > Logs de importación

Integración con productos A3

Integración con las diferentes versiones de a3EQUIPO

Existe dos opciones de importación de datos:

1. Utilidades –> Sincronización total nómina: recarga todos los datos en un horizonte amplio y verifica que todos los datos del programa de nóminas están cargados en a3GT

2. Utilidades –> Sincronización incremental nómina: esta opción carga los nuevos datos introducidos en el programa de nóminas a partir de una fecha determinada de: empleados, contratos y ausencias. Está disponible desde la versión 1.7.13. Nota: en la versión 1.7.13, si cambian datos maestros como centros, convenios o nuevos permisos es necesario efectuar previamente la sincronización total anterior. La fecha de revisión de cambios se actualiza automáticamente, pero se puede forzar en la configuración (Utilidades –> Logs de importación: botón “Mostrar configuración”).

Versiones en el cloud

Las versiones cloud son:

• a3Innuva
• a3EQUIPO versión SAAS
• a3Nómina cloud
• a3ASESOR RRHH

En los tres casos se debe indicar la dirección cloud (se rellena automáticamente), el código de cliente y las credenciales de acceso correspondientes. Realizar el test de conexión antes de continuar.

Integración a3innuva

En el caso de a3 innuva (https://a3innuva.wolterskluwer.es), funciona igual que con a3equipo pero debemos fijarnos especialmente en el número de cliente asignado en el momento que nos dan de alta de la licencia, ya que ese código de cliente no nos lo pregunta con cada login. Por ejemplo, este código puede localizarse aquí :

Para acceder a la pantalla anterior, si ya estamos logados en la página inicial de innuva: Area clientes –> Aplicaciones y usuarios (solo para el usuario administrador de la licencia).

Una vez tengamos el código de cliente anterior, necesitaremos entrar en la nómina y crear un usuario técnico. Esto se hace acciendo a la opción: Utilidades –> Usuarios –> Mantenimiento de usuarios y perfiles –> ir la pestaña “Usuarios técnicos” y dar de alta uno con perfil de administrador (quizás sea posible reducirle los permisos, pero con este seguro que funcionará la integración cono GT).

Nota importante! La pantalla anterior ha cambiado en la versión actual de WKE y el número de licencia no aparece directamente reflejado. Habrá que preguntar por el mismo al Wolters Kluwer.

Integración a3EQUIPO versión local

Hay que seleccionar esta opción si el servidor de a3EQUIPO está en nuestra red local (una instalación on premise). En este caso sólo hay que indicar: dirección del servidor (por ejemplo: https://A3EQUIPO) y las credenciales de acceso a utilizar por parte de la interface.

El servidor de GT debe de tener acceso a la URL especificada en el campo “Servidor”. Si el servidor de GT es cloud, la URL de acceso debe de ser accesible desde internet (por ejemplo: https://www.a3equipo.com o bien https://88.56.174.14/a3equipo) , si es on premise, la URL puede ser local (del tipo http://192.138.1.3/a3equipo)

Nota: el usuario debe tener acceso total.

Integración a3equipo / a3innuva: campos importados en GT

Resumen: Integración via API A3 estándar

Entrada: Empresas (seleccionables), Convenios, Centros, Lista de Permisos, Categorías profesionales (puestos trabajo contractuales), Empleados, Contratos, Lista de Centros de coste, Asignación actual a centros de coste por trabajador, Ausencias por trabajador (seleccionables).

Salida: Variables (incidencias) de nómina por trabajador y mes, Ausencias por trabajador (seleccionables)

detalle

A continuación, desde GT ejecutar la opción “Sincronización total nómina”. Esta acción carga el detalle de los datos siguientes:

• Empresa:
  • código (K)
  • descripción
  • código externo (identificador interno a3: IDA3Empresa).
• Centros: También se crean indirectamente los calendarios de festivos asociados a cada centro.
  • código (K),
  • descripción (U),
  • código externo (identificador interno a3: IDA3Centro).
• Permisos retribuidos:
  • código,
  • descripción (U),
  • código externo (K). El código externo se corresponde con el código de permiso en A3 con el formato siguiente: “14-número”.
• Categorías profesionales: se correponden con los “Puestos de tranbajo” definidos en a3. Los campos sincronizados son:
  • código (K),
  • descripción (U),
  • código externo (U) (identificador interno a3: IDA3PuestoTrabajo).
• Empleados:
  • código (K): se construye con el formato siguiente: o.EmpresaTrabajador – o.CodigoTrabajador
  • código externo (U) (identificador interno a3: IDA3Trabajador).
  • nombre completo (U)
  • DNI (U)
  • Fecha de nacimiento (U)
• Contratos:
  • fecha inicio (U)
  • fecha fin (U)
  • empresa (U)
  • centro
  • calendario asociado a ese centro
  • categoría profesional (sólo si está definido el puesto de trabajo en a3)
  • convenio

Nota:

‘K’: indica que este campo clave es el que se utiliza para relacionar la información entre ambos sistemas. Es decir: primero se busca en GT si existe este valor en GT, si existe se trata como una actualización, y si no existe se trata como una alta.

‘U’: cuando se trate de una actualización de los datos (se repite la carga y el registro ya existe), sólo los campos con esta marca se actualizarán automáticamente cada vez que cambien en la nómina

Problemas frecuentes

Timeout durante la extracción de datos de una empresa

Al parecer esto sucede cuando algún empleado tiene en su ficha de A3 mal imputados los costes (p.ej. tiene 2 imputaciones al 100%), esto provoca que no se complete la operación de descarga de la información al 100% quedando encallada la API de A3 en la empresa en la que está ese trabajador. Es decir, provoca un timeout en la descarga de datos de la empresa. Si es el caso, se deberían corregir esas imputaciones y entonces ya debería descargar los datos.

Integración con a3NOM

https://gps-plan.com/ayuda/kgps/integracion-con-a3asesor-nom-a3nom

Revisión de los logs de sincronización

Ir a UTILIDADES > Logs de importación, se abre la ventana Estado de las interfaces, con este menú:

“Descargar último log global”: muestra la información del último log global, el cual contiene los logs de todas las tareas realizadas durante la última sincronización. Tiene disponible la opción de “Copiar al portapapeles” y así poder pegarlo en un documento para una mejor lectura y comprensión.

“Mostrar configuración”: permite configurar y visualizar los datos para realizar la sincronización.

“Actualizar los datos de la tabla”: cada vez que termine una sincronización se tiene que refrescar la página presionando este botón, con esto se actualiza la ventana con los resultados obtenidos de la última sincronización.

Las tareas que se visualizan en los logs son las marcadas con “V”:

En el caso de sincronizar con a3ASESOR|nom las tareas que se ejecutan son las siguientes (no existe sincronización incremental, solo se puede ejecutar la sincronización total):

En las tablas anteriores las tareas están ordenadas por orden de ejecución, es decir, de la más antigua a la más reciente. Por ejemplo, para la sincronización total, la primera tarea en ejecutarse es Empresas y la última, Incidencias.

Hay errores en determinadas tareas que desencadenan errores en otras, por ejemplo, un error en un trabajador seguramente provoque un error en su contrato. Por este motivo, recomendamos realizar la revisión desde la primera tarea que se sincroniza (la que está más abajo en la ventana de logs) e ir subiendo hacia arriba, de más antigua a más reciente.

Cada una de las tareas tiene 3 subtareas:

• GetNativeXML: obtención de los datos de origen
• Tranformación: transformación de los datos de origen a datos de GT
• Importación: importación de los datos transformados a GT

Para cada subtarea se muestra el resultado (OK, ERROR), el número de Errores, el número de Advertencias y los Logs (Logfile). El logfile de cada subtarea está incluido en el log global.

A la derecha de la tabla se visualiza la columna Archivos, que contiene 3 archivos para cada tarea:

• Archivo output: contiene el resultado de los datos que se sincronizan, tal cual se cargarán en GT.
• Archivo result: contiene el resultado de los datos transformados que se sincronizarán con GT, con todo el detalle (incluye errores).
• Otro archivo (no es del tipo output ni del tipo result): contiene los datos origen, los de a3.

Ejemplo para la tarea Incidencias:  

Tiene los archivos Incidencias_output.xml, Incidencias_result.json, Incidencias.xml.

En resumen, cuando la sincronización da errores hay que revisar cada tarea, desde la primera tarea sincronizada hasta la última. Hay que revisar los errores y las advertencias, para ello clicaremos en el Logfile de la subtarea con error o advertencia. A veces el Logfile no da suficiente información y deberemos revisar los archivos de la columna de la derecha.

Ejemplos prácticos de revisión de logs

Hemos recopilado varios ejemplos de errores que han ido apareciendo en tickets y los presentamos a continuación:

Permisos

• Permisos. Error en Importación.

Abrir el Permisos_result.json. Busco “error” y encuentro lo siguiente:

"id": 126,
      "name": "P17-Realizar funciones sindicales o representación",
      "extcode": "14-17",
"description": "Realizar funciones sindicales o representación del personal",
      "start": "",
      "end": "",
      "incidence": "",
      "ok": false,
"err": "Error-E1501:En la BD ya existe un objeto 'Incidencias y absentismos' con el código P17-Realizar funciones sindicales o representación - "

Esto significa que en las Incidencias existe el permiso “P17-Realizar funciones sindicales o representación”, pero tiene otro código externo distinto al 14-17, que sería el correcto.

El código externo debe ser 14-17, este dato no hay que modificarlo, ya que llega de a3. En este caso hay que corregirlo y poner como código externo el 14-17.

• Permisos. Código externo único.

      Error: Se ha intentado definir el mapping: 4-1 (a3) --> IT (BOLD). La relación a3-BOLD debe ser 1-1. La única excepción permitida es 'VAA'. Revise el maestro de incidencias de BOLD puesto que ya se había definido el mapping siguiente: 4-1 (a3) --> 4-1 ENFERMEDAD COMÚN (BOLD)

Este mensaje indica que ya existe otra incidencia en GT con código externo 4-1 que no es IT y que el código externo debe ser único.

Desde a3 se está intentando sincronizar la incidencia IT con código externo 4-1 (es el código que viene de a3), pero el sistema se encuentra que en GT el 4-1 está asignado a otra incidencia, la 4-1 ENFERMEDAD COMÚN (BOLD). Para solventarlo hay que eliminar el código externo 4-1 de la incidencia ENFERMEDAD COMÚN y dejar solo el 4-1 a la de IT. 

Empleados

• STD_ObtenerTrabajadoresIncremental. 6 avisos en el GetNativeXML (i) y 1 error en Importación (ii). 

1. Revisamos el GetNativeXML

Abrimos el Logfile del GetNative.xml, que nos da información de si se han obtenido datos para cada empresa. En este ejemplo hay 7 empresas a sincronizar: [“1″,”2″,”1100″,”1200″,”1500″,”1600″,”99999”]. Y solo se han obtenido datos de la empresa 1100, por tanto, se muestran 6 avisos que se corresponden con las 6 empresas de las que no se han obtenido datos.

En estos casos hay que comprobar si ha habido cambios en el resto de las empresas desde la fecha en la que se lanza la sincronización (fecha sincronización), ya que, de ser así, se tendrían que sincronizar. Si no ha habido cambios, ya es correcto que no se sincronicen.

Si ha habido cambios en el sistema con posterioridad a la fecha de extracción incremental y no se sincronizan, seguramente se tenga que ampliar el timeout. Este dato es configurable desde la ventana de configuración (Configurar interfaces> Configuración técnica): Tiempo espera (seg.). Está disponible desde la v1.7.15, en las versiones anteriores no era un dato configurable. Se recomienda un timeout de 40s. Si aun ampliando el timeout no se sincronizan los datos, será necesario informar a a3 para que revisen la configuración de este caso, pues podría tratarse de un problema interno.

Hay que remarcar que, para las empresas sin cambios, el proceso de sincronización tardará todo el tiempo de timeout para cada empresa. Es decir, si configuramos un timeout de 300s (5min, el máximo), para cada empresa que no tenga cambios deberemos esperar todo el tiempo de timeout (5min). Esto es un error que lleva mucho tiempo sin solución por parte de a3 y alarga innecesariamente el tiempo de sincronización.

Ejemplo de cómo se visualiza el Logfile:

Empieza con la empresa 1 y no obtiene resultados en 40 segundos

1582811881739    SOAP REQUEST Method: ObtenerListaEmpresas
************************************* 

["1","2","1100","1200","1500","1600","99999"]
Extrayendo trabajadores empresa: 1
Extrayendo trabajadores modificados en a3 desde...20050101 01:00:00
 
1582811881962    SOAP REQUEST Method: ObtenerTrabajadores
Inicio EstadoTicket: 7be2e3e1-872f-412b-9f78-fd4589548032
 
1582811883147    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
 
1582811885394    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
 
1582811887628    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
 
1582811889963    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
 
1582811892184    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
 
1582811894471    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
 
1582811896755    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
 
1582811898962    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
 
1582811901217    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
 
1582811903518    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
 
1582811905802    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
 
1582811908015    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
 
1582811910225    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
 
1582811912466    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
 
1582811914724    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
 
1582811916976    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
 
1582811919200    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
 
1582811921394    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
 
1582811923617    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1
NO se han obtenido resultados! 1 (el ticket no terminó en el tiempo máximo esperado: 40000ms)

Lo mismo sucede con el resto de las empresas, excepto para la 1100, que sí obtiene resultados:

1582811967563    SOAP REQUEST Method: CerrarTicket
Extrayendo trabajadores empresa: 1100
Extrayendo trabajadores modificados en a3 desde...20050101 01:00:00
1582811967738    SOAP REQUEST Method: ObtenerTrabajadores
Inicio EstadoTicket: d8c506a0-3177-4328-813d-e2fe200fb2f6
1582811968893    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (0%): empresa: 1100
1582811971121    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (18%): empresa: 1100
1582811973323    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (66%): empresa: 1100
1582811975547    SOAP REQUEST Method: EstadoTicket
STD_ObtenerTrabajadoresIncremental (100%): empresa: 1100
Se han obtenido resultados. Empresa: 1100 (ticket: d8c506a0-3177-4328-813d-e2fe200fb2f6)
Datos descargados.

2. Revisamos la Importación.

Abrimos el Logfile de Importacion y el error es el siguiente:  E1501:En la BD ya existe un objeto ‘Empleado’ con el código 1111-000001.

Si abrimos el STD_ObtenerTrabajadoresIncremental_result.json y buscamos “error”, obtenemos más información sobre el error anterior, donde se indica el id del empleado, su código (name), su código externo (extcode) y su nombre (description):

    {

      "id": 137,
      "name": "1111-000001",
      "extcode": "XXXXXX-XXXXXXXXXXXXX",
      "description": "TEST TEST, TEST",
      "start": "",
      "end": "",
      "incidence": "",
      "ok": false,
"err": "Error-E1501:En la BD ya existe un objeto 'Empleado' con el código 1111-000001- "
    }

Hay que consultar en GT el empleado con código 1111-000001 en datos maestros de empleados y revisar cuál es su código externo. Nos hemos encontrado varios casos de clientes con estos errores de sincronización y cuando consultamos estos empleados su código externo está vacío (sin informar). El código externo se informa automáticamente al sincronizar con a3 y es un dato que llega de a3. Seguramente el cliente haya hecho cargas de empleados por Excel y posteriormente hayan lanzado una sincronización con a3.

Cuando se lanza la sincronización el campo clave es el código externo del trabajador. Estos empleados con errores justamente no tienen el código externo informado en GT y lo que detecta el sistema es que ya existe un empleado con ese código (código de GT, ejemplo 1111-000001), pero sin código externo y eso provoca los errores.

Para solventarlo se tiene que informar manualmente el código externo de estos empleados en GT, grabar el objeto y volver a lanzar la sincro. Este dato (código externo) de momento no es editable, es un dato que se visualiza en la tabla de datos maestros, pero no está visible en la ficha del empleado (editor ampliado del empleado). Informadnos de los casos que encontréis con estos errores y así pondremos visible y editable este campo en el editor de empleado para que lo podáis informar.

Contratos

• STD_ContratosCompletoIncremental. 1 error en Importación. 

Es el mismo caso de cliente del ejemplo anterior (b). El error en el trabajador con código 1111-000001 provoca un error en su contrato.

Abrimos el Logfile de Importación:

Fallo leyendo los datos del XML en import (clase 'Contrato-empleado'): 1111-000001_2019-01-02
  Ocurrió una excepción al deserializar (XML) la propiedad Worker: No existe ningún 'Worker' con el código externo (ExtCode) 'XXXXXX-XXXXXXXXXXXXX’.
1 errores leyendo las filas de datos. Compruebe la sintaxis del documento origen.

Una vez se corrija lo del código externo del trabajador en el apartado b, cuando se lance la sincronización este error en el contrato ya no aparecerá.

Absentismos

• Incidencias. Error en Transformación.

Abrimos el Logfile y aparece repetido el siguiente mensaje:

"El código de ausencia de A3 (TipoIncidencia=15, TipoContingencia=undefined no tiene correspondencia en BOLD (no existe una incidencia en BOLD con esa clave de código externo: 15-0)"

Durante la sincronización de incidencias el sistema no encuentra ninguna incidencia con código externo igual a 15-0 y por eso muestra este error.

La incidencia con código externo 15-0 siempre se corresponde con VACACIONES. Si al consultar la incidencia VACACIONES en GT su código externo no es este, esto significa que lo han modificado manualmente y no es correcto hacerlo. En este caso han puesto un valor incorrecto y por eso la sincronización falla:

Para solventarlo tienen que volver a poner 15-0 en el código externo de la incidencia VACACIONES.

En el siguiente enlace se puede consultar la relación de incidencias de A3 y sus códigos externos.

• Incidencias. Por días y por horas.

        El código de ausencia de A3 (TipoIncidencia=14, TipoContingencia=undefined) con código externo en WP=14-15, debe estar definida con asignación en DIAS para poder tratarse.

Esto significa que están llegando de a3 incidencias definidas en horas y actualmente GT solo puede tratar aquellas que vienen definidas en días.

En este ejemplo, la incidencia  con código externo igual a 14-15 viene de a3 definida en horas y en GT también está marcada que se asigna en horas. Aun así, el mensaje de error indica que se debe definir en días, ya que actualmente GT solo puede tratar aquellas incidencias que vienen de a3 definidas en días y no las que vienen por horas. El motivo es que en a3 no se informa la fecha de inicio ni la de fin de la incidencia, solo la duración. Con estos datos, la incidencia no se puede ubicar correctamente en su horario en GT.

• Incidencias. No encuentra al empleado/a de la incidencia.

Fase 1: Preparando los datos de entrada.
  Número de objetos de entrada... 6
Analizando objetos... 0 de 6.
  Se trató de actualizar un objeto que no ha podido localizarse. Su identidad XML es la siguiente:
<?xml version="1.0" encoding="ISO-8859-1" ?><Worker><ID value="0" /><Name value="" /><Type value="0" /><Active value="1" /><IsSimulated value="False" /><IsTemplate value="False" /><ExtCode value="5db5960f-436a-41e9-9c22-2f418f4748d7" /><Description value="" /><_LastChange value="2020-10-20T09:59:09" /><Template value="0" valueRef="" /><O_OWNER value="Unknown" /><O_CREATEDATE value="1899-12-30T00:00:00" /><O_LASTUSER value="Unknown" /><O_ACCESS value="1" /><ID_VERSION value="0" /><Color value="16777215" /><FullName value="" /><DNI value="" /><PhotoURL value="" /><CreationDate value="2020-10-20T00:00:00" /><Skills value="0" valueRef="" /><Worker_Status value="0" /><Control value="0" /><PeriodListActive value="0" /><Telefono value="" /><TelefonoMovil value="" /><RelocationType value="0" /><InfiniteCapacity value="False" /><LocationPL value="MOD_ZIPH4sIAAAAAAAAALMJCUgtysxP8cksLrGz0UfmAQC7KMm3GwAAAAMAAAAAABsAAAA=" /><ID_DefaultLocation value="0" valueRef="" /><CardID value="" /><CARDID2 value="" /><SystemProps ><tfno value="" /><tfno_movil value="" /><eMail value="" /><Adress value="" /><CP value="" /><City value="" /><BirthDate value="2020-10-15T03:45:46" /><FechaAntiguedad value="2020-10-15T03:45:46" /><NumHijos value="0" /><Genero value="0" /><CivilState value="0" /><Nacionalidad value="" /><WebAccess value="True" /><MultipleHourZone value="False" /><Responsable value="0" valueRef="" /><CampoLibre value="0" /></SystemProps><CustomProps ></CustomProps><Categories></Categories><IncidenceList><TTimePeriod StartTime="44179" DurationValue="5" DurationUnity="9" PeriodType="2" Quantity="1" IdType="23" /></IncidenceList></Worker>
Fin análisis objetos a actualizar

Es un error relacionado con las incidencias. Cuando cargamos ausencias de a3 se identifica dentro de GT a qué empleado se le tienen que asignar utilizando el código interno de a3, que es el código que nos aparece dentro del campo ExtCode value = “5db5960f-436a-41e9-9c22-2f418f4748d7” del XML reportado por el error.

Salta este error cuando no existe ninguna persona en GT con ese código. Esto es porque la persona a la que corresponde esa ausencia no ha sido nunca cargada en GT (o ha podido haber un error de carga con esta persona o la podrían haber eliminado de GT). Habría que localizar a qué fechas corresponden las ausencias de esa persona entre los datos que llegan de a3. Revisando el fichero origen Incidencias.xml se puede obtener el tipo de incidencia y las fechas de inicio y fin. Con esta información, se puede filtrar en a3 las incidencias existentes entre estas fechas y del mismo tipo para obtener el código de empleado y revisar su fecha de alta. Para solventarlo, se trataría de realizar una carga incremental desde unos cuantos días antes al inicio de dicha ausencia (tener en cuenta la fecha de alta del empleado) o incluso realizar una sincronización total. Normalmente esto hará que esa persona se cargue en GT y nos desparecerá el error anterior.

Puestos de trabajo

     Actualizado Categoría profesional ID 41, Código 00000001 (ext. 8e317f1b-a1c4-4413-81ab-a4e54f64bc43), resultado ERROR.
     Actualizado Categoría profesional ID 45, Código 00000002 (ext. 24915b50-f2bf-4165-9074-1f354749d252), resultado ERROR.
     Actualizado Categoría profesional ID 41, Código 00000001 (ext. c99ec981-129d-4c7d-b519-8807c47b5bdf), resultado ERROR.
     Actualizado Categoría profesional ID 41, Código 00000001 (ext. b9aba504-d21b-4e22-8f12-c6203520053b), resultado ERROR.
     Actualizado Categoría profesional ID 45, Código 00000002 (ext. d4f7019f-1246-4613-ac5f-dd80cc2de219), resultado ERROR.
     Actualizado Categoría profesional ID 41, Código 00000001 (ext. 0658ecdd-8230-4b21-af5d-9bb6109e72aa), resultado ERROR.

En este ejemplo vemos varios mensajes de error en los que se repite el mismo ID y código de categoría, pero hacen referencia a códigos externos diferentes.

Ejemplo: la categoría con ID = 41 y Código = 00000001 tiene 4 códigos externos distintos:

• 8e317f1b-a1c4-4413-81ab-a4e54f64bc43
• c99ec981-129d-4c7d-b519-8807c47b5bdf
• b9aba504-d21b-4e22-8f12-c6203520053b
• 0658ecdd-8230-4b21-af5d-9bb6109e72aa

Lo mismo sucede para la categoría con ID = 45, con 2 códigos externos diferentes.

Están llegando diferentes categorías profesionales de a3 (códigos externos distintos) que comparten el mismo CodigoPuestoTrabajo (ej. 00000001) y en GT esto no es posible y por eso da error. En GT cada categoría profesional/puesto de trabajo debe tener un código único.

El problema viene de que en a3 se permite repetir el mismo el CodigoPuestoTrabajo si pertenece a diferentes empresas-convenios. Actualmente, la única manera de solventarlo es usar un único código en a3 (por ejemplo, añadiendo al código algún prefijo-sufijo).

Otros

• URL pública:

     Error: ServiciosA3Equipo.downloadTicketFile. Error: ServiciosA3Equipo.BajarFichero: .net error (BajarFichero: no llegan los datos): ERROR:Error no controlado al subir/bajar fichero: The remote name could not be resolved: 'srh01'

En este ejemplo, “srh01” es el nombre del servidor donde está instalado a3equipo y no es público. Para solventarlo, se tiene que informar los parámetros de la URL pública de la aplicación (a3) siguiendo estos pasos:

• En el directorio donde está instalada la aplicación buscar el fichero A3FileTransferConfig.xml del directorio XMLfiles
• Pulsar botón derecho sobre el fichero y abrirlo con un editor avanzado de texto tipo el Notepad.
• Buscar el apartado <A3Protocol ID=’WS’> y editar el <server> cambiando la URL privada a su URL pública.
• Guardar los cambios y lanzar la sincronización.

• Credenciales inválidas usuario adm:

   Error: SOAP Exception2: ERR_LOGIN_FAILED:Credenciales inválidas.

Este error aparece en el GetNativeXML de las tareas y la sincronización ya no avanza con las otras dos subtareas de Transformación ni Importación. El usuario adm es un usuario interno de la aplicación y por alguna razón se ha quedado con una contraseña que no es la correcta.

En casos de clientes CLOUD lo solucionaremos desde GPS, ya que es necesario conectarse al servidor cloud. Para los clientes intranet (on premise), os indicamos a continuación los pasos a seguir, ya que se tendrán que aplicar en el servidor del cliente:

1. Ir a la ruta siguiente: C:\Program Files (x86)\Global Planning Solutions\Custom_Files\Integration\configuration\production\boldweb\config
2. Abrir “BoldWebcfg.xml”con un editor de notas.
3. Buscar <bolduser> y entonces encontraréis esto:   <bolduser>adm</bolduser> Cambiar adm por administrador.
4. Guardar el archivo “BoldWebcfg.xml”.
5. Volver a iniciar sesión en GT con el usuario administrador. Esto actualizará la contraseña del adm. Para comprobarlo hay que ir al C:\Program Files (x86)\Global Planning Solutions\Custom_Files\Integration\configuration\production\boldweb\config\BoldWebcfg.xml y ver que donde se había indicado “administrador” vuelve a aparecer “adm” (<bolduser>adm</bolduser>) y la contraseña es otra, la ha cambiado. Ir a C:\Program Files (x86)\Global Planning Solutions\Custom_Files\Integration\configuration\production\BOLDServer.json y ver que “user”:”adm” y que en “pwd” está la misma contraseña que la del usuario adm en el fichero BoldWebcfg.xml.
6. Lanzar la sincronización.

Importante. El fichero BoldWebcfg.xml es un fichero de configuración que no debe modificarse en otros casos. Solo en este caso concreto hay que corregirlo.

Nota: para casos cloud GT, si la solución anterior no funciona, significa que se trata de otro problema y se debe reiniciar el pool gt (FRE-01) y el pool del cliente.

• Archivo de configuración BOLDXML.json

Incidencia eliminada en WP pendiente de exportar del empleado: 1-003474, Incidencia: ACL , Inicio: Date(2020,9,15,0,0,0), Fin: Date(2020,9,23,0,0,0)

Se trata de un error en las incidencias derivado de una configuración incorrecta del fichero BOLDXML.json (fichero de configuración). Para los casos cloud afectados, tendréis que reportarlo a GPS para que lo modifiquemos en el servidor cloud. Si lo detectáis en un cliente on premise, deberéis modificar el fichero BOLDXML.json para incluir la siguiente entrada:

"bA3IncidencesFirst": true,
(la coma de final de la línea sólo se pone si no es la última entrada)

El fichero se encuentra en la siguiente ruta es: C:\Program Files (x86)\Global Planning Solutions\Custom_Files\Integration\configuration\production
Una vez modificado el fichero, al lanzar la sincro ya no aparecerá el error.
Este error no debería ser muy común, ya que se detectó en casos de clientes antiguos y los casos más recientes ya tienen este fichero bien configurado.

En el siguiente artículo hay información sobre cómo vincular empleados con A3 que se dieron de alta en GT con una codificación que no es la de A3: https://gps-plan.com/ayuda/kgps/vincular-empleados-dados-de-alta-previamente-en-gt-con-a3