Buenas tardes:
Queriamos reportarles un problema de visualización de las carreras por cargo en mapuche (la versión que estamos utilizando es 1.12.1, pero en la 1.15 también ocurre lo mismo).
El tema es que cada una de las carreras está asociada a las Dependencias (que en total son cinco) para que así puedan ser asociadas a cargos respectivamente, pero si se ingresa a consultar algún cargo en particular, el sistema muestra duplicadas las carreras asociadas por cada una de las dependencias en lugar de solo mostrar la/s que efectivamente se encuentra/n cargada/s en la tabla (es decir que pareciera que aplica el perfil de datos para la selección, pero hace un producto cartesiano con las otras).
También informa que el porcentaje es inferior al 100% cuando en realidad suma el 100% y además por la duplicidad que realiza contabiliza un 500%, por ejemplo en la imagen adjuntada de la pantalla.
Hola Claudia, te cuento que no estoy pudiendo reproducir el error.
Te voy a pasar dos consultas sql para que ejecutes desde el pg_admin para ver que te retornan.
En primer lugar tendrías que ejecutar el siguiente sql reemplazando el texto <nro_de_cargo> por el número de cargo así obtenemos el código de unidad académica codc_uacad que vamos a usar en el segundo sql.
SELECT
dh03.nro_cargo,
dh03.codc_uacad,
dh31.desc_dedic,
dh11.tipo_escal,
dh11.codc_dedic,
dh11.codigoescalafon as escalafon,
dh35.tipo_carac
FROM
mapuche.dh03 dh03
LEFT OUTER JOIN mapuche.dh11 ON (dh03.codc_categ = dh11.codc_categ)
LEFT OUTER JOIN mapuche.dh31 ON (dh11.codc_dedic = dh31.codc_dedic)
LEFT OUTER JOIN mapuche.dh35 ON (dh35.tipo_escal = dh11.tipo_escal AND dh03.codc_carac=dh35.codc_carac)
WHERE
dh03.nro_cargo = <nro_de_cargo>;
Luego con el codc_uacad, ejecutamos el siguiente sql, el cual te tendría que dar para esa Unidad Adémica las carreras que tienen Cargadas.
SELECT
codn_carrera,
codc_uacad,
desc_carrera
FROM
mapuche.dd90
WHERE
dd90.codc_uacad = <valor_dh03.codc_uacad_para_nro_cargo_seleccionado>
ORDER BY desc_carrera;
Por favor informame si te dan valores duplicados, tanto en el primer sql como en el segundo.
Hola Emiliano:
Te cuento que ejecuté ambos sql (como me indicaste) y en ninguno de los casos me dá duplicados o sea que la información en las tablas no está duplicada, por eso es que comentaba anteriormente que estimo el problema tiene que ver con el perfil de datos (te adjunto dos imagenes, una que muestra las carreras ingresando con un usuario con perfil de datos asociado, en este caso llamado ‘BASI’ y otro ingresando con un usuario sin perfil de datos).
La realidad es que la única asociación que vale para este cargo es la que corresponde a la relación “DEPARTAMENTO CS. BASICAS” - “Analista de Sistemas”, con el 100% de dedicación.
Por otro lado en la tabla de carreras por dependencia, cada una de las dependencias tiene relacionada esta carrera, para luego poder asociarla a un cargo en cada una de ellas.
Hola Claudia, tenés razón …el problema se manifiesta con los perfiles y revisando un poco ya lo teníamos registrado en el ticket 2101. El asunto con eso es que el problema es un poco mas profundo ya que en la tabla dd99 (Relación Cargo - Carrera) no se encuentra la unidad académica. En el comité de usuarios que se realizó en la Universidad Nacional de Quilmes propusimos quitar esta funcionalidad ya que no se estaba usando en el envio de RHUN (la misma nació con el SIPUVER) pero como es el caso de ustedes la funcionalidad sigue siendo usada.
Conclusión, tenemos que tratar de resolver esto con un cambio de base de datos pero el conversor no es menor ya que hay cambios que no se pueden hacer automáticos. Vamos a estudiar el caso para tratar de resolverlo en la próxima conversión. Si tienen alguna idea que pueda ayudar, bienvenidas !
Saludos,
Ariel Zoia
Coordinador Desarrollo SIU-Mapuche
Consorcio SIU
Tel/Fax+54+02293-432304 http://www.siu.edu.ar
Hola Ariel:
Por lo que entendimos mirando el código de ci_cargos_solapas.php en el conf__ml_carreras, las carreras se cargan con cargo_carreras::get_cargo_carreras().
En el método antes mencionado, se realiza una consulta que es la que finalmente trae los datos
$sql = "SELECT
dd99.nro_cargo,
dd99.codn_carrera,
dd99.porcentaje,
dd90.codc_uacad,
dd90.desc_carrera
FROM
".MAP_ESQUEMA.".dd99
LEFT OUTER JOIN ".MAP_ESQUEMA.".dd90 ON (dd99.codn_carrera = dd90.codn_carrera)
WHERE
nro_cargo = $nro_cargo
";
Se nos ocurre que quizás se podría aquí filtrar la codc_uacad, pasandola como un parámetro al método, tal como ocurre con el nro_cargo (obteniendolo del perfil del usuario que está logueado).
La otra opción sería crear en la base una vista similar, pero sin filtrar el cargo
SELECT dd99.nro_cargo, dd99.codn_carrera, dd99.porcentaje, dd90.codc_uacad,dd90.desc_carrera FROM mapuche.dd99 LEFT OUTER JOIN mapuche.dd90 ON (dd99.codn_carrera = dd90.codn_carrera)
Para después crear un gatillo en el campo codc_uacad. Entonces luego en cargo_carreras::get_cargo_carreras:
static function get_cargo_carreras($nro_cargo) {
$nro_cargo = quote($nro_cargo);
$sql = "SELECT
vista.nro_cargo,
vista.codn_carrera,
vista.porcentaje,
vista.codc_uacad,
vista.desc_carrera
FROM
".MAP_ESQUEMA.".vista
WHERE
nro_cargo = $nro_cargo
";
$sql = toba::perfil_de_datos()->filtrar($sql);
return mapuche::consultar($sql);
}
Este tema salió finalmente corregido en la versión 1.22.0 (ticket #2101). El texto del boletín dice lo siguiente:
“Se corrige problema en la solapa vertical Carreras en Actualización > Legajos > Cargos, para que se puedan dar de alta correctamente todas las carreras necesarias, siempre y cuando no superen un porcentaje del 100%. En el caso de que no sumaricen el 100% requerido se observa una advertencia indicando el problema.”