Hola, buenas tardes!
Estamos en la versión v3.13.0, actualizada hace pocas semanas, y nos damos cuenta que ahora el combo llamado "Contenedor" en el filtro de la pantalla => "Gastos -> Consultas y listados  -> Liquidaciones  -> Listado de liquidaciones" se encuentra sin datos. Antiguamente las opciones eran: "CINT - Sin Contenedor" - "EXP - Expediente" - "TRI - Trámite interno". No vemos ningún error en los log.
Sabrían si puede estar faltando alguna configuración previa?

Gracias

Buen día!
Estamos realizando por primera vez, en un ambiente de desarrollo, la liquidación web en la versión de Mapuche 3.16. Forzados a utilizarla ya que no se encuentra mas el mapuche escritorio.

Al liquidar por web el resultado de la gran mayoría da 0 o solo apareciendo el concepto "seguro de vida". Luego de hacer varias prueba y revisar encontramos que al forzar el concepto 1 (sueldo básico) con un monto fijo comenzaba a liquidar con muchos mas conceptos. Descubrimos que en esa formula, luego de cambiar varias cosas, la sentencia "NOT" al quitarla o en este caso reemplazándola por "variable = 0" ya que antes figuraba "... NOT variable", comenzó a liquidar correctamente los básicos junto con el resto de conceptos que están relacionados con el.

Encontramos 92 formulas que utilizan la sentencia "NOT" en la gran mayoría no se pueden reemplazar fácilmente como lo hicimos con el básico.
Consultas:
1) Con que otro operador se puede reemplazar "NOT" para que lo acepte el liquidador web ?
2) Existe algún migrador de formulas para el liquidador de mapuche escritorio a liquidador web?
3) Hay alguna documentación, ya que no la encontré, sobre las formulas y acumuladores, y donde indique que sentencias / operadores no son admitidos en el nuevo liquidador web?
4) En caso de no haber documentación o no estar completa, podríamos enviarles por GDS con nuestras formulas y que la puedan revisar e indicarnos las incompatibilidades o errores en ellas?

Les agradeceríamos mucho una pronta respuesta.

Muchas Gracias!

Javier Trillo

Hola, buen día!
Actualmente tenemos instalada la versión 6.2.0 del sistema Wichi en un servidor no muy potente. Nuestra idea era pasarnos a un servidor con mejores prestaciones y migrar wichi a su ultima versión, la 6.9.0. Existe algún proceso de migración de la base para asi poder instalar la 6.9.0 como una instalación de cero en el nuevo servidor?
La otra opción es levantar la imagen de nuestro servidor actual de wichi al nuevo y actualizar. Tendríamos que pasar por todas las versiones para actualizarlo o se puede actualizar desde alguna versión puntual y pasar a la ultima?

Muchas Gracias!

Saludos!

Buen día!
Realizamos la actualización de Pilaga 3.5.6 a la 3.7.1, terminado todos los pasos de "Actualización de una instalación sin personalizaciones" del instructivo https://documentacion.siu.edu.ar/wiki/SIU-Pilaga/version3.7.0/instalacion_actualizacion. El sistema inicio sin problemas pero al momento de ir a los ejercicios anteriores no dejaba entrar, ahí recordamos de antiguas instalaciones de ejecutar ".bin/instalador pilaga:migrar-ejercicios-historico". Este proceso nos arrojo errores en los ejercicios 2014 al 1017 con el siguiente texto: "[ ERROR ] Base de datos 'pilaga_2017'. No se pudo realizar la conversión de la base de datos para la versión 3.7.1, ejecutando el archivo de conversión /usr/local/siu/pilaga_371/sql/conversion/script_3.7.1.sql".
En el archivo instalador.log se indican las siguientes lineas:
".... MAIN.ERROR: Base de datos 'pilaga_2017'. No se pudo realizar la conversión de la base de datos para la versión 3.7.1, ejecutando el archivo de conversión /usr/local/siu/pilaga_371/sql/conversion/script_3.7.1.sql SQL ERROR: SQLSTATE[42703]: Undefined column: 7 ERROR:  column "adjunto" of relation "logs_sau_em_mensaje" does not exist CONTEXT:  SQL statement "alter table auditoria.logs_sau_em_mensaje drop column adjunto" PL/pgSQL function mod_sau_em_mensaje() line 6 at SQL statement  SET search_path TO public;          -- Jorge Version 3.6.0 - 2010-08-24   -- version 3.7.1 INSERT INTO par_version (version, descripcion, fecha, fecha_instalacion) SELECT (SELECT max(version)+1 FROM par_version), '3.7.1','2020-10-29', now() FROM par_version p WHERE p.version = 2 AND NOT EXISTS (SELECT '' FROM par_version as pv WHERE pv.descripcion='3.7.1');      CREATE OR REPLACE FUNCTION public.psau_actualizar_secuencias() RETURNS TEXT AS $$ DECLARE       _secuencias   CURSOR FOR SELECT --distinct                c.relname as nombre_sequencia                 ,tabla.relname as nombre_tabla                 ,columna.attname as nombre_columna                ,esquema.schemaname as nombre_esquema          FROM                 pg_class as c,                 pg_attrdef as a,                 pg_class as ta...  "

Nos estará faltando algún paso?

Desde ya muchas gracias!
Saludos.

Hola buenas tardes!
Tenemos una duda sobre el estado de los legajos. Cuando se le da de baja el único cargo que tiene un legajo y no se lo pasa a pasivo, el legajo luego de un tiempo se pasa a pasivo por algún proceso?

Gracias, quedo a la espera.

Hola buen día!
Estamos por actualizar nuestra versión 3.5.1 y queremos ir a la 3.6.1. Obviamente tenemos que pasar por la 3.6.0. Debemos también hacer los 5 Release que hay de la 3.6.0 ? O en la 3.6.1 se corrige todo esos release?

Gracias

Buenas Tardes!
Quería consultar si es normal que la tabla "mapuche_auditoria.logs_dh21" pese 3,2GB mientras que la base pesa 5,3GB. Cuando se hacen los backups el archivo pesa solo 350MB. Podrían indicarme si es normal y si se podría sacar o hacer algo para que esta tabla no ocupe tanto espacio en la base?

Saludos!