Mostrar Mensajes

Esta sección te permite ver todos los mensajes hechos por este usuario, recuerda que solo puedes ver los mensajes en áreas en donde tu tienes acceso.


Temas - Marco Mora

Páginas: [1] 2 3 4
1
Técnicos Mapuche / Problemas al descargar Reporte de Novedades
« on: Abril 12, 2022, 09:10:28 am »
Hola gente, En Uncoma estamos teniendo un inconveniente con la descarga del reporte de novedades. Acá se usa como documento a auditar para cada UA por lo que cada informante lo genera y lo envía adonde se audita lo que cargó/modificó.

Tenemos una UA que comenzó hace relativamente poco a cargar novedades y a informar pero cuando quiere sacar el reporte de novedades le tira un error. Lo único distinto de otras UA's es que está alejada (aprox 500kms) de la central (datacenter) y desconocemos si la conexión es buena.
En el Log del sistema dice
Cita
11/04/2022 12:02:32   10537157   64000004   Generar PDF   0,09 seg.   0

En el Log de Postgresql nada pero en el log de Apache tira el siguiente error:
Cita
[Mon Apr 11 12:02:32.793409 2022] [php7:error] [pid 30883] [client 190.109.39.23:52552] script '/usr/local/mapuche_3170/www/temp/pdf_st625443082619e8.85656147.php' not found or unable to stat

El mismo reporte generado por nosotros sale sin inconvenientes, desde la UA alejada probaron cambiando de PC y de conexión pero sigue sin poder imprimir el reporte de novedades.

Hay algo que pueda llegar a cortar por timeout? alguna configuración de php? algo de apache?

2
Técnicos Mapuche / Error conexión Wichi Mapuche
« on: Octubre 26, 2021, 10:59:59 am »
Hola, soy técnico Mapuche y estamos laburando con el técnico Wichi porque extrañamente dejó de funcionar la conexión entre ambos sistemas.

Lo tenía funcionando sobre un server de copia (no es producción) por lo que cada mes levanto una copia antes de cerrar el mes y sacamos reportes y generamos los datos que importa Wichi. Tenía Mapuche en versión 3.15.0 y Wichi está en 6.8.1. Wichi sigue en la misma versión y yo cambié de versión a 3.16.0 por el impuesto y debería haber seguido funcionando normal ya que los archivos de configuración son los mismos y está todo igual a como estaba antes de dejar de funcionar.

El error que me tira es : "Error en la conexión, verifique la URL configurada en el archivo cliente.ini" (adjunto imagen)

Donde puedo mirar o probar la conexión esta? Ya cambié la url que tenía por el número IP, el http por https y sigue tirando el mismo error.

En los logs del sistema (sistema.log en /mapuche/instalacion/i__produccion/p__mapuche/logs) me muestra lo siguiente. No veo ningún error ni warning.
Código: [Seleccionar]
-o-o-o-o-o-^M
Fecha: 26-10-2021 10:57:33^M
Operacion: Generar solicitud de extracción de datos^M
Usuario: MMora^M
Version-PHP: 7.3.23-4+0~20201018.71+debian9~1.gbpfc8934^M
Servidor: mapucheconsulta.uncoma.edu.ar^M
URI: /siuanterior/mapuche/aplicacion.php?ah=st617807114e1693.93288760&ai=mapuche%7C%7C64000029^M
Referrer: https://mapucheconsulta.uncoma.edu.ar/siuanterior/mapuche/aplicacion.php?tm=1&tcm=central&ai=mapuche||64000029^M
Host: 181.28.176.8^M
==========^M
[DEBUG][mapuche] PUNTO DE MONTAJE: se cargó exitosamente el autoload del punto de montaje proyecto
[INFO][mapuche] PUNTO MONTAJE: se cargó la clase extension_toba/mapuche_sesion.php del punto de montaje proyecto. El path del mismo es /usr/local/siuanterior_3160/php
[DEBUG][mapuche] Inicializando perfil de datos para el proyecto mapuche
[INFO][mapuche] PUNTO MONTAJE: se cargó la clase comunes/mapuche_fuente_datos.php del punto de montaje proyecto. El path del mismo es /usr/local/siuanterior_3160/php
[DEBUG][toba] [SECCION] Iniciando componentes...
[INFO][mapuche] PUNTO MONTAJE: se cargó la clase comunicacion/consorcio_SIU/wichi/ci_generar_extraccion_datos_wichi.php del punto de montaje proyecto. El path del mismo es /usr/local/siuanterior_3160/php
[DEBUG][toba] componente(64000127): Pantalla de eventos: 'pant_inicial'
[DEBUG][toba] [SECCION] Procesando eventos...
[DEBUG][toba] componente(64000127): [ evento ] 'generar' -> [ evt__generar ]
[DEBUG][mapuche] INSERT INTO mapuche.wichi_generacion(periodo_mes_generacion, periodo_ano_generacion) VALUES(09,2021) returning id_generacion
[DEBUG][mapuche] SQL con perfil de datos: INSERT INTO mapuche.wichi_generacion(periodo_mes_generacion, periodo_ano_generacion) VALUES(09,2021) returning id_generacion
[DEBUG][mapuche] INSTALACION "/usr/local/siuanterior_3160/instalacion"
[DEBUG][mapuche] Parametros instancia produccion: array (
  'base' => 'toba_3_3',
  'proyectos' => 'toba_usuarios, mapuche',
  'tipo' => 'normal',
  'toba_usuarios' =>
  array (
    'path' => '/usr/local/siuanterior_3160/vendor/siu-toba/framework/proyectos/toba_usuarios',
    'url' => '/siuanterior_toba_usuarios',
    'full_url' => 'https://mapucheconsulta.uncoma.edu.ar/siuanterior_toba_usuarios',
  ),
  'mapuche' =>
  array (
    'path' => '/usr/local/siuanterior_3160',
    'url' => '/siuanterior/mapuche',
    'usar_perfiles_propios' => '1',
    'full_url' => 'https://mapucheconsulta.uncoma.edu.ar/siuanterior/mapuche',
  ),
)
[DEBUG][mapuche] INSTANCIA "produccion"
[DEBUG][mapuche] Conectando a base 'toba_3_3'
[DEBUG][mapuche] PROYECTO "mapuche"
[DEBUG][toba] [SECCION] Configurando dependencias para responder al servicio...
[DEBUG][toba] componente(64000127): Pantalla de servicio: 'pant_inicial'
[DEBUG][toba] componente(64000127): [ callback ] 'conf__pant_inicial'
[INFO][mapuche] PUNTO MONTAJE: se cargó la clase comunicacion/consorcio_SIU/wichi/filtro_wichi_extraccion.php del punto de montaje proyecto. El path del mismo es /usr/local/siuanterior_3160/php
[DEBUG][toba] componente(64000127): [ callback ] 'conf__filtro_extraccion'
[DEBUG][toba] componente(64000127): [ callback ] 'conf__cuadro_generaciones'
[DEBUG][toba] [SECCION] Respondiendo al servicio__generar_html...

3
Técnicos Mapuche / Demora en recálculo de ganancias v3.16.0
« on: Octubre 06, 2021, 08:55:07 am »
Hola gente. les comento la preocupación de la gente de liquidaciones en cuanto a la nueva versión y el recálculo de ganancias.

Tenemos el server en producción montado en una MV con 16cores y 32GB de RAM. El cambio de versión (+ release) lo realizamos sobre el mismo server. Realizamos la liquidación y el cálculo de ganancias por web.

Antes del cambio de versión la operación de "Servicios -> Impuesto a las Ganancias -> Cálculo de ganancias" tardaba 15/20 minutos pero este mes tardó 50 minutos en la base de pruebas y 60 en producción. Al parecer se hace bien el cálculo y por lo que entiendo esta operación realiza el recálculo desde Enero 2021 a la fecha pero pasó a tardar mucho.

Revisé los logs de postgresql y de apache y ninguno de los 2 tira errores.

Habrá algo de configuración que estamos pasando por alto en este proceso? Donde puedo empezar a mirar el porqué de la tardanza en la operación? A alguien le pasó lo mismo que tarde tanto esta operación?

4
Usuarios / Concepto de legajo por escalafón
« on: Mayo 21, 2021, 02:34:27 pm »
Hola. En Comahue estamos armando el concepto de adicional por conectividad para docentes. Es por legajo y lo definimos como se ve en la imagen adjunta. En la solapa Grupos Escalafón seleccionamos los Docentes, ni Autoridades ni Nodocentes están seleccionados.

El cálculo se hace bien, pero al momento de visualizarlo en el Detalle de Liquidación y en los recibos de sueldo viene el problema. En agentes que tienen cargos docentes y nodocentes o docentes y autoridad el concepto puede caer en un cargo o en otro dentro del detalle de liquidación(y recibos) si seleccionamos la Distribución por Mayor Bruto o Mayor Cargo.

Pensé que al seleccionar en la Solapa Grupos Escalafón a los docentes, este concepto sólo iba a aparecer en las liquidaciones docentes pero no es así.

Alguien le encontró la vuelta de otra forma? Hay alguna forma de configurar que este concepto sólo salga en el detalle de liquidación de cargos docentes?

Estamos en la versión 3.12.1.

Saludos!

5
Técnicos Mapuche / Consulta LAO
« on: Diciembre 16, 2020, 12:19:59 pm »
Hola, estamos tratando de comenzar con LAOS docentes y encontramos que llegando al paso de Servicios->Licencias->Licencia Anual Ordinaria para el escalafon Docente no podemos modificar el parámetro "Fecha Hasta Antiguedad" y nos tira numeros aleatorios a mi entender.

Estamos en la versión 3.12.1

Adjunto las imagenes pero para poner un contexto, si seleccionamos el escalafón Nodocente nos deja cargar el parámetro "Fin" con la fecha 31/12/2020 y eso mismo se copia en "Fecha Hasta Antiguedad" lo que es correcto. Cuando lo hacemos en el escalafon docente no tenemos el parámetro "Fin" y al parámetro "Fecha Hasta Antiguedad" se carga con la fecha "25/06/2015"(no sabemos de donde sale esta fecha).  Si en el parámetro "Año de cálculo" cargamos  2020, se modifica "Fecha Hasta Antiguedad" al 25/06/2020 y si dejamos en blanco  "Año de Cálculo" al salir con TAB modifica a una fecha Aleatoria "Fecha Hasta Antiguedad".

Entiendo que el parámetro "Fecha Hasta Antiguedad" debería ser 31/12/2020 en todos los casos  pero en Docentes no nos deja.

Si tienen alguna idea para ver de donde salen esas fechas aleatorias o como configurar algo que tenemos mal para que quede correcto, necesitamos esto para hacer pruebas y generar LAOS.

Saludos!

6
Técnicos Mapuche / Error en versión 3.12.1
« on: Diciembre 02, 2020, 03:46:07 pm »
Hola gente.  Cambiamos Mapuche de versión ayer a 3.12.1

Tuvimos una serie de errores raros que no surgieron en las pruebas. Por ejemplo cuando vamos a Informes->Liquidacion->Detalle de liquidación con un usuario con perfil distinto a Administrador, la consulta se colgaba y se volvía cada vez mas lento el servidor. Por primera vez el servidor me llegó a usar 32GB de RAM cosa que no pasó nunca.

Pasaba que entraron todos a sacar el detalle de liquidación y se colgaba la consulta, se conectaban de otro lugar y volvían a intentar sacarlo y quedaban procesos de postgres colgados con  el 100% de un procesador en uso.

En el log de postgresql encontré la consulta que colgaba el servidor  y era  la siguiente:
Código: [Seleccionar]
SELECT dh21h.nro_legaj, dh01.tipo_docum || ' ' || dh01.nro_docum AS documento,
dh01.desc_appat || ', ' || dh01.desc_nombr AS agente,
dh01.desc_appat || ', ' || dh01.desc_nombr || ' (' || dh21h.nro_legaj || ')' AS agente_corte,
LPAD(dh01.nro_cuil1::varchar, 2, '0') || '-' || LPAD(dh01.nro_cuil::varchar, 8, '0') || '-' || dh01.nro_cuil2 AS cuil,
dh01.tipo_estad,
dh01.fec_nacim,
dh01.tipo_sexo,
dh21h.nro_cargo,
dh03.fec_alta,
dh03.fec_baja,
dh03.codc_categ,
dh03.codc_agrup,
dh03.hs_dedic,
dh03.nro_exped,
dh03.nro_norma,
dh90.nro_cargoasociado,
dh90.tipoasociacion,
estado_civil.desc_estado_civil,
aporte_jubilatorio.desc_aporte_jubilatorio,
dh09.fec_ingreso,
dh09.codc_uacad as dep_cabecera,
dh35.tipo_carac,
dh35.tipo_escal,
COALESCE(dh35.desc_grupo,'No existe Caracter') as desc_carac,
dh35.codc_carac as codc_carac,
dh11.desc_categ,
dh31.desc_dedic,
dh31.cant_horas,
dh11.codc_dedic || ' (' || dh03.nro_cargo || ')' AS dedicacion_cargo,
dh11.codc_dedic,
dh11.impp_basic,
dh21h.nro_liqui,
dh21h.impp_conce::numeric(10,2),
dh21h.tipoescalafon,
dh22.desc_liqui,
LPAD(dh21h.tipo_ejercicio::VARCHAR, 1, '0') AS tipo_ejercicio,
LPAD(dh21h.codn_grupo_presup::VARCHAR, 4, '0') AS codn_grupo_presup,
LPAD(dh21h.codn_area::VARCHAR, 3, '0') AS codn_area,
LPAD(dh21h.codn_subar::VARCHAR, 3, '0') AS codn_subar,
LPAD(dh21h.codn_subsubar::VARCHAR, 3, '0') AS codn_subsubar,
LPAD(dh21h.codn_progr::VARCHAR, 2, '0') AS codn_progr,
LPAD(dh21h.codn_subpr::VARCHAR, 2, '0') AS codn_subpr,
LPAD(dh21h.codn_proye::VARCHAR, 2, '0') AS codn_proye,
LPAD(dh21h.codn_activ::VARCHAR, 2, '0') AS codn_activ,
LPAD(dh21h.codn_obra::VARCHAR, 2, '0') AS codn_obra,
LPAD(dh21h.codn_final::VARCHAR, 1, '0') AS codn_final,
LPAD(dh21h.codn_funci::VARCHAR, 1, '0') AS codn_funci,
dh21h.codn_fuent,
dh21h.nro_orimp,
dh21h.nov1_conce,
dh21h.nov2_conce,
dh21h.detallenovedad,
dh21h.ano_retro,
dh21h.mes_retro,
dh21h.nrogrupoesc,
dh21h.codc_uacad,
dh21h.codc_regio,
LPAD(dh21h.tipo_ejercicio::VARCHAR, 1, '0')||'-'||LPAD(dh21h.codn_grupo_presup::VARCHAR, 4, '0')||'-'|| LPAD(dh21h.codn_area::VARCHAR,3, '0')||'.'||LPAD(dh21h.codn_subar::VARCHAR,3, '0')||'.'||LPAD(dh21h.codn_subsubar::VARCHAR, 3, '0')||'-'|| LPAD(dh21h.codn_fuent::VARCHAR,2, '0')||'-'|| LPAD(dh21h.codn_progr::VARCHAR,2, '0')||'.'||LPAD(dh21h.codn_subpr::VARCHAR,2, '0')||'.'||LPAD(dh21h.codn_proye::VARCHAR,2, '0')||'.'||LPAD(dh21h.codn_activ::VARCHAR,2, '0')||'.'|| LPAD(dh21h.codn_obra::VARCHAR,2, '0')||'-'|| LPAD(dh21h.codn_final::VARCHAR,1, '0')||'.'||LPAD(dh21h.codn_funci::VARCHAR,1, '0') as imputacion,
dh21h.codn_conce,
dh21h.tipo_conce,
dh12.desc_corta,
dh12.desc_conce,
dh89.codigoescalafon,
trim(to_char(dh21h.codn_progr, '00')) || trim(to_char(dh21h.codn_subpr, '00')) || trim(to_char(dh21h.codn_proye, '00')) || trim(to_char(dh21h.codn_activ, '00')) || trim(to_char(dh21h.codn_obra, '00')) AS categ_programatica,
dh17.objt_gtote

INTO TMP_DETALLE_LIQUIDACION_prueba2

FROM mapuche.dh21h
LEFT OUTER JOIN mapuche.dh22 ON (dh22.nro_liqui = dh21h.nro_liqui)
LEFT OUTER JOIN mapuche.dh01 ON (dh01.nro_legaj = dh21h.nro_legaj)
LEFT OUTER JOIN mapuche.dh03 ON (dh03.nro_cargo = dh21h.nro_cargo)
LEFT OUTER JOIN mapuche.dh09 ON (dh09.nro_legaj = dh01.nro_legaj)
LEFT OUTER JOIN mapuche.dh11 ON (dh03.codc_categ = dh11.codc_categ)
LEFT OUTER JOIN mapuche.dh35 ON (dh35.tipo_escal = dh11.tipo_escal AND dh03.codc_carac = dh35.codc_carac)
INNER JOIN mapuche.depcia ON  ( mapuche.depcia.cod_depcia IN ('INFO','ASMA','AUZA','BIBL','CRUB','CUZA','DECO','DBAS','FAME','FAAS','FATA','FACA','FACE','FADE','FAEA','FAHU','FAIF','FAIN','FALE','FATU','FEA ','FDHU','FAT ','FOME','IBMP','IUC ','SESO','RECT','CRUZ','SEBU','SECO','SEAC','SEHA','SEIN','SEGE','SEXU','TACZ','TESO','VICE') ) 
AND (dh21h.codc_uacad = depcia.cod_depcia)
LEFT OUTER JOIN mapuche.regional ON (dh21h.codc_regio = regional.cod_regional)
LEFT OUTER JOIN mapuche.aporte_jubilatorio ON (dh09.codc_bprev = aporte_jubilatorio.cod_aporte_jubilatorio)
LEFT OUTER JOIN mapuche.estado_civil ON (dh09.codc_estcv = estado_civil.cod_estado_civil)
LEFT OUTER JOIN mapuche.dh89 ON (dh21h.codigoescalafon = dh89.codigoescalafon)
LEFT OUTER JOIN mapuche.dh31 ON (dh11.codc_dedic = dh31.codc_dedic)
LEFT OUTER JOIN mapuche.dh12 ON (dh21h.codn_conce = dh12.codn_conce)
LEFT OUTER JOIN mapuche.dh17 ON (dh21h.codn_conce = dh17.codn_conce)
LEFT OUTER JOIN mapuche.dh90 ON (dh21h.nro_cargo = dh90.nro_cargo) --Tabla de Categorías Programáticas'
LEFT JOIN mapuche.dh27 ON (dh21h.codn_progr = dh27.codn_progr AND dh21h.codn_subpr = dh27.codn_subpr AND dh21h.codn_proye = dh27.codn_proye AND dh21h.codn_activ = dh27.codn_activ AND dh21h.codn_obra = dh27.codn_obra )
WHERE dh21h.nro_liqui = '537' AND dh01.nro_legaj = '22635'

Con ese comentario --Tabla de Categorías Programáticas'   con una comilla simple andaba mal.
Busqué donde estaba esta consulta y encontré el archivo /instalacion_mapuche/php/modelos/negocio/liquidacion/conceptos.php
Eliminé la comilla demás y ahora funciona el detalle de liquidación con todos los usuarios pero me quedan algunas dudas.

Porque solamente daba el error con algunos usuarios? Con esto se habrá eliminado ese error? o tengo que mirar en otro lado para ver si puedo encontrar algo mas? Si tienen alguna linea por donde mirar se los agradezco.

Saludos!

7
Técnicos Mapuche / Error en cambio versión a 3.12.0
« on: Octubre 26, 2020, 09:58:20 am »
Hola gente. La semana pasada cambiamos de versión a 3.12.0 y al parecer quedó bien.

El viernes me avisan que no se puede modificar los estudios de los agentes. En Legajo-> Curriculum-> Estudios están cargados los estudios del agente y los muestra pero al querer entrar a editar,  la pantalla queda en blanco.

El log de apache dice esto:
Código: [Seleccionar]
[Mon Oct 26 09:38:43.906328 2020] [php7:error] [pid 1982] [client 190.247.179.172:53718] PHP Fatal error:  Declaration of arai_estudio::guardar($doc, $datos) must be compatible with digitalizacion_arai::guardar($doc, $datos, $tipo = 'recibo') in /usr/local/mapuche_3120/php/modelos/negocio/digitalizaciones/arai_estudio.php on line 10, referer: https://mapuche.uncoma.edu.ar/mapuche/aplicacion.php?ah=st5f96c350e1de44.99885876&ai=mapuche%7C%7C2000004
No entiendo porque me tira algo de arai. No lo tenemos instalado todavía pero quizas me falta configurar algo y se me pasó.

8
Técnicos Mapuche / Error en reporte de Novedades
« on: Agosto 05, 2020, 10:18:53 am »
Hola gente. Estamos en la versión 3.9.1 y las facultades una vez que terminan la carga de novedades/licencias del mes imprimen el reporte de novedades y lo envían para que se auditen sus cargas.

A una usuaria le sale un error en el reporte de novedades relacionado a la carga de licencias de cargo. Cuando filtra le sale lo siguiente en una hoja en blanco:

ERROR: diferencia en cantidad de registros anteriores y recientes en "licencias_cargo"
Registro anterior: 4

Array
(Array con 4 registros.....)

Registro reciente: 5

Array
(Array con 5 registros)

Por donde puedo empezar a mirar?

9
Técnicos Mapuche / Cambio de versiòn a 3.9.1 carpeta logs_procesos
« on: Junio 01, 2020, 07:54:37 am »
Hola gente. Vengo con una consulta que nos pasa hace tiempo.

Cada vez que realizamos un cambio de versión, la carpeta logs_procesos no se crea por lo que tengo que hacerlo manualmente y darle permisos.

Veniamos de la versión 3.7.0 y en bases de pruebas realicé cambios de versión a la 3.9.1 y 3.10.x. El tema es que siempre que hice estos cambios de versión y realizamos un cierre de mes para probar, se truncaba diciendo que no tenía permisos sobre la carpeta /instalacion/logs_procesos y la cuestión es que nunca está por lo que la creo manualmente y luego le doy permisos.

Hoy realizamos el cambio de versión en la base en producción y al realizar el cierre de mes no tiró ningun error (ya creé la carpeta manualmente) pero cuando llegó al reporte final nos tiró un cartel diciendo "No hay datos cargados".

Estamos en la duda porque no sabemos si realizó el proceso de cierre de mes correctamente y la carpeta logs_procesos está vacía. En logs de postgres y apache no hay ningún error. Se puede ver en algún otro lado si el proceso finalizó bien?

Saludos!

10
Técnicos Mapuche / Novedad reintegro de seguro no se liquida
« on: Enero 22, 2020, 09:54:07 am »
Hola gente. Mi consulta tiene que ver con un caso raro que no logro entender.

Se nos solicitó la creación de un concepto para "reintegro de excedentes de Seguro Adicional" para devolver dinero en ese concepto para meses retroactivos.  Se creó un concepto x legajo(no x cargo) de tipo Descuento proporcional con una novedad que se carga manualmente. La fórmula del concepto es el valor de la novedad1 solamente.

Se procedió a la carga de la novedad (de liquidacion, por legajo, clase seguro)  a 50 agentes aproximadamente y detectamos 4 casos a los que no se les liquida el concepto. Todas las novedades cargadas son retroactivas pero estos 4 casos no los toma en cuenta.

El caso raro es que en los casos de estos 4 agentes les borro el reajuste a un mes retro y se liquida normalmente.

Encontré este tema buscando información pero no logro entender lo que allí se explica (igualmente es del año 2012)
http://foro.comunidad.siu.edu.ar/index.php?topic=4488.msg17719#msg17719
Ahí le explican que "los conceptos de legajo en el caso de liquidaciones retro si existe una liquidación no se liquidan." lo que no sería mi caso porque es un concepto nuevo pero no sé, quizás haya algo ahí.

Que mas puedo mirar? Porque se podría liquidar ese concepto sin mes retro, pero con mes retro no?

11
Técnicos Mapuche / Usuario no_autentificado en liquidación
« on: Diciembre 09, 2019, 09:48:50 am »
Hola gente.  Estamos  con algo medio raro.

La semana pasada se cerró la liquidación de Noviembre, cierre de mes y comienzo de carga de novedades para Diciembre y 2do SAC.

La cuestión es que al día de hoy tenemos 2 legajos liquidados y no sabemos quien pudo liquidarlos (nadie tiene permisos todavía para eso) y al ingresar al logs de datos del sistema nos aparece un usuario no_autentificado (Imagen 1) y al entrar al nro de acceso nos aparece la imagen 2 con un error.

Suponemos que es el liquidador web que realizó el proceso pero por qué no aparece el usuario? En la carga de novedades o de cargos los logs registran correctamente usuarios y accesos.

Estamos en la versión 3.7.0 y rastreé hasta la 3.6.0 y las liquidaciones en dh21 salen iguales (usuario no_autentificado). Esto es así desde siempre? O quizas a nosotros en algún cambio de versión se nos perdió algo?

12
Técnicos Mapuche / funcion valor_concepto
« on: Noviembre 19, 2019, 12:25:24 pm »
Hola, estamos probando el uso de esta función en la fórmula de algunos conceptos.

Resulta que tenemos un concepto (385) que se debe calcular por legajo y  y otro por cargo (311). El caso es que en el concepto 311 debemos controlar que no tenga nada cargado en el 385 y al usar la función valor_concepto(385)  no hace nada. Calculo que es porque estoy ejecutando desde la formula de un concepto de cargo una función en un concepto por legajo. Al modificar el concepto 385 para que sea por cargo me devuelve valores en la fórmula del 311 aunque son erróneos porque por definición deberia calcularlo por legajo.

La consulta es: Hay alguna forma de llamar a esta función desde la fórmula de un concepto por cargo a un concepto por legajo?

13
Técnicos Mapuche / Problemas en cambio de versión 3.7.0
« on: Noviembre 05, 2019, 12:14:25 pm »
Hola gente les comento que esta semana hicimos el cambio de versión a la 3.7.0 y se vé que tenemos algunos problemas de datos con los esquemas toba_mapuche y ahora surgió otro con toba_mapuche_logs.

Comienzo:

1) Al hacer el cambio de versión nos tiró errores con un perfil de usuarios que accede al proyecto toba_usuarios (perfil de logs). nos tiró el siguiente error:
Cita
[2019-11-01 10:18:28] MAIN.ERROR: 0 - SQL ERROR: SQLSTATE[23503]: Foreign key violation: 7 ERROR:  inserción o actualización en la tabla «apex_usuario_proyecto» viola la llave foránea «apex_usu_proy_fk_grupo_acc» DETAIL:  La llave (proyecto, usuario_grupo_acc)=(toba_usuarios, logs) no está presente en la tabla «apex_usuario_grupo_acc». INSERT INTO apex_usuario_proyecto (proyecto, usuario_grupo_acc, usuario, usuario_perfil_datos) VALUES ('toba_usuarios', 'logs', 'prueba', NULL);
La solución que encontramos fue desvincular a todos los usuarios que tienen ese perfil funcional "logs" que accede al proyecto toba_usuarios.
Luego hicimos el cambio de versión y el perfil funcional "logs"no fue creado por lo que volvimos a crearlo manualmente.

Como sé donde buscar que es lo que está haciendo ruido acá?

2) Realizando el cambio de versión nos dió 2 errores mas en perfiles funcionales. Los perfiles "liquidacion" y "liquidacion_1" al parecer tenían errores de datos pero siguió el cambio de versión y terminó OK. Los mensajes que dieron fueron estos:
log de postgresql
Cita
2019-11-01 10:00:41.373 -03 [2628] mapuche@siu DETALLE:  La llave (proyecto, item)=(mapuche, 53000015) no está presente en la tabla «apex_item».
2019-11-01 10:00:41.373 -03 [2628] mapuche@siu SENTENCIA:  INSERT INTO apex_usuario_grupo_acc_item (proyecto, usuario_grupo_acc, item_id, item) VALUES ('mapuche', 'liquidacion', NULL, '53000015');
2019-11-01 10:00:41.417 -03 [2628] mapuche@siu ERROR:  inserción o actualización en la tabla «apex_usuario_grupo_acc_item» viola la llave foránea «apex_usu_item_fk_item»
2019-11-01 10:00:41.417 -03 [2628] mapuche@siu DETALLE:  La llave (proyecto, item)=(mapuche, 53000015) no está presente en la tabla «apex_item».
2019-11-01 10:00:41.417 -03 [2628] mapuche@siu SENTENCIA:  INSERT INTO apex_usuario_grupo_acc_item (proyecto, usuario_grupo_acc, item_id, item) VALUES ('mapuche', 'liquidacion_1', NULL, '53000015');

Log instalador.log
Cita
[2019-11-01 11:17:34] MAIN.INFO: [ TOBA ] ATENCION! No fue posible cargar por completo el 'perfil_liquidacion', posiblemente a causa de que al menos una operación, restricción o derecho ha dejado de existir en 'mapuche'. A continuación el detalle:    ERROR ejecutando SQL:   [CODIGO]: 7   [SQLSTATE]: db_23503    [MENSAJE]: ERROR:  inserción o actualización en la tabla «apex_usuario_grupo_acc_item» viola la llave foránea «apex_usu_item_fk_item»  DETAIL:  La llave (proyecto, item)=(mapuche, 53000015) no está presente en la tabla «apex_item».   [SQL EJECUTADA]: INSERT INTO apex_usuario_grupo_acc_item (proyecto, usuario_grupo_acc, item_id, item) VALUES ('mapuche', 'liquidacion', NULL, '53000015');    De todas formas se continúa la carga, se recomienda revisar la definición de este perfil.
[2019-11-01 11:17:34] MAIN.INFO: [ TOBA ]
[2019-11-01 11:17:34] MAIN.INFO: [ TOBA ] ATENCION! No fue posible cargar por completo el 'perfil_liquidacion_1', posiblemente a causa de que al menos una operación, restricción o derecho ha dejado de existir en 'mapuche'. A continuación el detalle:
[2019-11-01 11:17:34] MAIN.INFO: [ TOBA ] .
[2019-11-01 11:17:34] MAIN.INFO: [ TOBA ] ERROR ejecutando SQL:   [CODIGO]: 7   [SQLSTATE]: db_23503    [MENSAJE]: ERROR:  inserción o actualización en la tabla «apex_usuario_grupo_acc_item» viola la llave foránea «apex_usu_item_fk_item»  DETAIL:  La llave (proyecto, item)=(mapuche, 53000015) no está presente en la tabla «apex_item».   [SQL EJECUTADA]: INSERT INTO apex_usuario_grupo_acc_item (proyecto, usuario_grupo_acc, item_id, item) VALUES ('mapuche', 'liquidacion_1', NULL, '53000015');    De todas formas se continúa la carga, se recomienda revisar la definición de este perfil.
[2019-11-01 11:17:35] MAIN.INFO: [ TOBA ] .OK

Estos perfiles se migraron y quedaron funcionando para las personas que tenian asociados los 2 perfiles pero quiero saber que es lo que esta funcionando mal y como arreglarlo.


3) Cuando termino el cambio de versión y quiero ingresar a Administración -> Usuarios (luego de insertar en la tabla toba_mapuche.apex_usuario_proyecto los datos necesarios para que me dé acceso ya que antes del cambio de versión tuve que sacarle el permiso de acceder a este módulo a TODOS) me abre una ventana en blanco, vacía.

Según el log de apache2 el error está en que no encuentra el archivo ubicado en /usr/local/mapuche_370/vendor/siu-toba/framework/proyectos/toba_usuarios/metadatos_compilados/gene/toba_mc_gene__grupo_logs.php y buscandoló efectivamente no está. Copio el de la versión 3.6.1 y logro acceder.

Esto me estará rompiendo algo? Que importancia tiene este archivo?

4) El mas importante! Al finalizar el cambio de versión el sistema anda un poco mas lento de lo normal pero lo empiezan a utilizar normalmente para carga de datos.

Hoy sigo revisando y detecté que en el esquema toba_mapuche_logs no migró las primary key y foreign keys de algunas tablas. Entre ellas las de apex_solicitud, apex_solicitud_browser, apex_solicitud_consola, etc.
De ahí surge la lentitud del sistema.
Mi consulta es si puedo correr estas restricciones para que se creen los indices adecuadamente o se va a romper todo? 
Ví en el foro que alguien hizo un script para borrar datos de estas tablas que en mi caso llegan a 7 millones de registros. Se pueden borrar estos datos? se guardan sólo los accesos a las operaciones de los usuarios en estas tablas de éste esquema? Se puede hacer un truncate de todas las tablas de este esquema y volver a crear las pk y fk?

14
Técnicos Mapuche / Servicios Web
« on: Octubre 30, 2019, 12:59:34 pm »
Hola. Estamos empezando a ver los servicios web ofrecidos por Mapuche.

Nos interesa mostrar y descargar los recibos de sueldo desde un nextcloud implementado en el correo institucional de cada empleado.

Estamos intentando consumir servicios web desde php y no llegamos siquiera a que nos devuelva los recibos disponibles.

Estamos siguiendo este ejemplo -> https://github.com/gpilla/ejemplo-mapuche-rest/blob/master/README.md

Al llamar al servicio web nos dá el siguiente error
Código: [Seleccionar]
Código: 401
Mensaje: Client error: `GET http://170.210.81.28:50080/mapuche/rest/agentes/22723/recibos` resulted in a `401 Unauthorized` response: { "mensaje": "autenticaci\ufffdn cancelada" }
Archivo: /var/www/html/nextcloud/3rdparty/guzzlehttp/guzzle/src/Exception/RequestException.php
Línea: 113

Hay algo mas de documentación de este tema? Alguien hizo algo parecido que nos tire una soga?

Gracias!

15
Usuarios / Consulta Antiguedad
« on: Septiembre 03, 2019, 02:07:15 pm »
Tenemos un caso extraño que ingresó el 01/06/2017 y al día de hoy se sigue liquidando 1 año de antiguedad.

Según estuvimos viendo no tiene licencias y las fechas entre cargos son consecutivas. La antiguedad nos dá 26 meses - 1 año.

Los parámetros para antiguedad no docente están así: (como en la foto)

Antiguedad NO DOCENTE -> al 31-Diciembre
Fracción 6 meses primer año?  Si
Fracción solo mayor 6 meses  Si
Día hasta cuando se computa mes de antigüedad 30

Modificando el parámetro de Fracción sólo mayor 6 meses y haciendo el recálculo de antiguedad nos da 26 meses - 2 años.

La consulta es: Que significa ese parámetro? que implicancia tiene si lo modificamos (digo, en que otro caso se verían modificaciones)?

Gracias de antemano!

Páginas: [1] 2 3 4