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 - federicosayd

Páginas: [1] 2 3 4
1
Técnicos / Error en ficha de la persona Guarani 3.17.1
« on: Junio 16, 2021, 12:17:54 pm »
Hola:

Estamos teniendo un problema que al parecer ya fue reportado aquí: http://foro.comunidad.siu.edu.ar/index.php?topic=18172.0 con la ficha de la persona.

Adjunto captura de pantalla del error

Nos podrían decir cómo proceder?

Gracias!


2
Hola:

Estamos migrando actas fuera de calendario de sistemas externos en 3.17.1 y encontramos un error en el job de la migración al ejecutar el script 02_migrar_mesas_examen_fc.sql.

Código: [Seleccionar]
02_migrar_mesas_examen_fc - ERROR: no existe la columna «espacio» en la relación «sga_llamados_mesa»

 Al parecer,  según leí en el foro,  la columna espacio fue eliminada de la tabla llamados_mesa  a partir de 3.16.2

Habría que actualizar los scripts de migración para no incluir este campo.

Gracias y saludos

3
Técnicos / Actualizar a partir de checkout
« on: Febrero 23, 2021, 10:59:44 pm »
Hola:

Tengo una duda con respecto al proceso de actualización de Guaraní.

En la documentación para actualizar Guaraní a 3.18.1 se recomienda hacer un svn switch de la working copy apuntando a la rama de la nueva versión, luego regenerar el proyecto, migrar la base de negocio y mergear las personalizaciones previamente commiteadas.

En capacitaciones anteriores del SIU se presentaba como alternativa empezar con una checkout limpia de la nueva version, realizar una instalación desde cero y luego pisar la base de datos con un dump de la versión anterior para luego regenerar la instancia, migrar la base de negocio y  mergear las personalizaciones.

¿Sigue siendo válido este segundo procedimiento de actualización a partir de un checkout de la  nueva versión? Nos interesa el procedimiento porque nos permite empezar en un server nuevo (Nuevo S.O y versiones de software) a  la vez que mantenemos las dos versiones para comparar.

Les agradezco cualquier aclaración.


4
Migración de Datos / Error poscontrol actas cursadas
« on: Febrero 14, 2020, 11:40:48 am »
Hola:

Estamos migrando actas de regulares (cursadas) a Guaraní 3.17.1

En el poscontrol del módulo actas tenemos un error en la cantidad de actas de cursadas migradas a Guaraní:

Código: [Seleccionar]
sga_actas_detalle Error: Cantidad de alumnos en actas de cursada no coninciden... 9.240,00 865.330,00
Efectivamente en ext.mig_actas_cursada_promoción tenemos 9240 registros todos con origen 'R' (regularidad) repartidos en 483 actas diferentes.

Al parecer el poscontrol tiene un error. Falta filtrar por alumno (o quizás número de acta). Porque en la consulta, cada registro de ext.mig_acta_cursada_promocion (origen 'R') se cruza con sga_actas_detalle y da un número enorme de registros de alumnos en actas de regulares en Guaraní (865.330).

   
Código: [Seleccionar]
-- Actas de Cursadas en G3   
SELECT count(*) INTO cnt_actas_det_g3
     FROM ext.mig_acta_cursada_promocion as mig,
           vw_comisiones as com,
   sga_actas,
   sga_actas_detalle
     WHERE mig.origen = 'R'
   AND mig.comision_nombre        = com.comision_nombre
       AND mig.anio_academico         = com.anio_academico
       AND mig.periodo_lectivo_nombre = com.periodo_lectivo_nombre
       AND mig.actividad_codigo       = com.elemento_codigo
   
   AND sga_actas.comision  = com.comision
   AND sga_actas.origen    = 'R'
   AND sga_actas.tipo_acta = 'N'
   AND sga_actas.estado    = 'C'
   AND sga_actas_detalle.id_acta = sga_actas.id_acta;

También vimos que este poscontrol se cambió en 3.16.0 (Antes en 3.15.1  no nos daba este error en la migración de actas de cursada).

Nos confirmarían si es un bug?

Gracias!

Federico

5
Hola:

Esta consulta es técnico/funcional

Tuvimos que versionar un plan y pasamos algunos de los alumnos al nuevo plan. Nos pasó que al tratar de inscribir a comisiones, a los  alumnos del plan viejo les aparecían comisiones con inscripciones vigentes y a los nuevos no les aparecía nada.

Vimos por la base que el sistema filtra los períodos de inscripción asociados a comisiones de la tabla sga_periodos_inscripcion_aplanado, pero en esta tabla no veíamos ningún período de inscripción asociado al nuevo plan/versión.

Solo cuando creamos un nuevo período de inscripción para el período lectivo de la comisión, el sistema nos mostró comisiones con períodos de inscripcion vigentes.

Entendemos que tiene que ver con que cuando se creó el período de inscripción del período lectivo, el plan/versión nuevo no existía y por lo tanto no se agregó a la tabla sga_periodos_inscripcion_aplanado.

El nivel de aplicación del período de inscripción era "Toda la institución" por eso creíamos que no hacía falta redefinir o crear un nuevo período de inscripción luego de versionar.

¿Se trata de un error, o es el comportamiento normal? En todo caso ¿se podría advertir al usuario al versionar o crear un nuevo plan o propuesta que será necesario redefinir los niveles de aplicación?

Gracias

Federico

6
Hola:

Estamos mirando el tema de parámetros en la inscripciones a cursadas con respecto al control de requisitos

No entendemos la diferencia entre los parámetros:

cur_ejecuta_controles
  • S: Se ejecutan los controles, la inscripción queda en el estado que indican los controles.
  • N: No se ejecutan los controles y la inscripción siempre queda en estado pendiente.

y

cur_insc_siempre_pendiente
  • S: Estado de la inscripción siempre pendiente
  • N: La inscripción mantendrá el estado de acuerdo al control de requisitos

Pareciera ser que los dos parámetros realizan lo mismo: Por un lado no se ejecutan los controles y las inscripciones quedan pendiente y por el otro se ejecutan los controles y las inscripción queda en el estado que indiquen los requisitos.

Podrían indicarme en qué se diferencian estos dos parámetros o algún  ejemplo donde funcionen en conjunto para una configuración determinada

Muchas Gracias

Federico

7
Hola:

Tuvimos un problema al matricular ingresantes desde preinscripción. Estamos usando Guaraní 3.15.1 y preinscripción 3.8.0

En un caso en particular el proceso da error con una foreing key para el dato de Guaraní correspondiente a tipo_vivienda de la tabla mdp_datos_personales

Preinscripción pasa un valor 1 que no se condice con ningún valor de la tabla mdp_tipo_vivienda.

Código: [Seleccionar]
Foreign key violation: 7 ERROR:  inserción o actualización en la tabla 'mdp_datos_personales' viola la llave foránea  'fk_mdp_datos_personales_mdp_tipo_vivienda'
DETAIL:  La llave (tipo_vivienda)=(1) no est<E1> presente en la tabla 'mdp_tipo_vivienda'
[DEBUG][toba] ************ ABORTAR transaccion (toba_2_7@localhost) ****************
[ERROR][toba] toba_error_db: <p><b>SQLSTATE:</b> db_23503</p><p><b>CODIGO:</b> 7</p><p><b>MENSAJE:</b> ERROR:  inserción o actualización en la tabla 'mdp_datos_personales' viola la llave foránea  'fk_mdp_datos_personales_mdp_tipo_vivienda'
DETAIL:  La llave (tipo_vivienda)=(1) no está presente en la tabla  'mdp_tipo_vivienda'.</p><p><b>SQL:</b> INSERT INTO mdp_datos_personales
                                        dato_censal
                                        , estado_civil, situacion_padre, situacion_madre, cantidad_hijos, cantidad_familia, tipo_vivienda, vive_con, unido_hecho, cobertura_salud, periodo_lectivo_calle, periodo_lectivo_numero, periodo_lectivo_localidad, periodo_lectivo_barrio, periodo_lectivo_codigo_postal, procedencia_calle, procedencia_numero, procedencia_localidad, procedencia_barrio, procedencia_codigo_postal, es_celiaco
                                )
                                VALUES
                                (
                                        '34327'
                                        , '1', 'V', 'V', '0', '0', '1', '3', 'N', '1', 'CANDELARIA', '252', '13217', 'SUAREZ', '5501', 'CANDELARIA', '252', '13217', 'SUAREZ', '5501', 'N'
                                )


Mirando el código de preinscripción vemos que el dato que Guaraní carga como tipo_vivienda en mdp_datos_personales proviene del campo tipo_res_per_lect de la tabla sga_preinscripcion.

Sin embargo no entendemos por qué algunos ingresantes pudieron elegir la opción 1 ya que al parecer las opciones correspondientes al tipo de vivienda se traen  desde Guaraní gestión llamando a la función get_tipo_vivienda en el archivo siu/modelo/g3/consultas_bd/tipos_vivienda.php

Según los diferenciales de la BD los valores 1, 2 y 3 se eliminaron de la base de datos en 3.14.0. Nosotros la preinscripción la hicimos estando en 3.15.1

Por ahora solucionamos el problema poniendo el campo tipo_res_per_lect a NULL

¿A qué se deberá el problema?

8
Hola:

Estamos migrando la matricula de algunos alumnos y nos dió un error con un alumno al tratar de matricularlo porque el script no encuentra el periodo de inscripción.

Vemos que el csv por donde se ingresan los datos (mig_alumnos.csv) solo pide el año de ingreso y luego en el script de migración se usa este año para buscar un periodo de inscripción asociado.

Pero no hay ningún precontrol que falle si no se encuentra un periodo de inscripción para dicho año. Sencillamente ese valor se deja nulo y falla cuando se trata de llenar la columna periodo_insc de la tabla sga_propuestas_aspira.

El precontrol debería considerar además que para un plan_version dado haya un periodo de inscripcion. En nuestro caso un plan_version erróneo generó el valor NULL en el campo periodo_insc, ya que se toma tanto el año de ingreso como el plan_version de la persona.

Lo dejamos como nota para ver si se puede agregar el precontrol en futuras versiones.

Saludos

9
Hola:

Estamos migrando comisiones por sistemas externos hacia nuestra instalación de Guaraní 3.15.1

En el mismo módulo (Calendario Académico) también migramos algunos periodos lectivos. Las comisiones que estamos migrando referencian periodos lectivos que ya están en Guaraní o que se migran junto con las comisiones.

Encontramos un error al ejecutar la migración de las comisiones en el paso 03_migrar_comisiones.

Basicamente el script no migra comisiones con periodos lectivos existentes en Guaraní 3.

Vemos que en la consulta que se hace se cruzan los datos de las comisiones con los periodos lectivos que se estan migrando (tabla ext.mig_periodos_lectivos).  Pero no se cruzan con los periodos lectivos que ya existen en Guaraní 3. Por lo tanto estas comisiones no se migran y el script sql da error en los subsiguientes pasos.

Para solucionarlo en la consulta que agrega las comisiones pusimos una UNION con una consulta que cruza las comisiones con los periodos lectivos de guaraní (sga_peridoros_lectivos y sga_periodos)

Consulta que da error:

Código: [Seleccionar]
SET search_path = 'negocio';
-- comisiones
INSERT INTO sga_comisiones(comision, nombre, periodo_lectivo, elemento, turno, cupo, ubicacion, observaciones)
  SELECT com.comision, com.nombre, per.periodo_lectivo, elem.elemento, com.turno, com.cupo, com.ubicacion, com.observaciones
    FROM ext.mig_comisiones as com,
    ext.mig_periodos_lectivos as per,
    sga_elementos as elem
    WHERE com.anio_academico = per.anio_academico
    AND   com.periodo_lectivo_nombre = per.nombre
    AND   com.actividad_codigo = elem.codigo;

Consulta modificada:

Código: [Seleccionar]
SET search_path = 'negocio';

-- comisiones
INSERT INTO sga_comisiones(comision, nombre, periodo_lectivo, elemento, turno, cupo, ubicacion, observaciones)
  SELECT com.comision, com.nombre, per.periodo_lectivo, elem.elemento, com.turno, com.cupo, com.ubicacion, com.observaciones
    FROM ext.mig_comisiones as com,
    ext.mig_periodos_lectivos as per,
    negocio.sga_elementos as elem
    WHERE com.anio_academico = per.anio_academico
    AND   com.periodo_lectivo_nombre = per.nombre
    AND   com.actividad_codigo = elem.codigo
    UNION
      SELECT com.comision, com.nombre, per.periodo_lectivo, elem.elemento, com.turno, com.cupo, com.ubicacion, com.observaciones
    FROM ext.mig_comisiones as com,
    negocio.sga_periodos_lectivos as per,
    negocio.sga_elementos as elem,
    negocio.sga_periodos as p
    WHERE com.anio_academico = pg.anio_academico
    AND   com.periodo_lectivo_nombre = p.nombre
    AND   com.actividad_codigo = elem.codigo
    AND   per.periodo = p.periodo
    ORDER BY comision;
Con esta consulta nos traemos el total de las comisiones en la tabla ext.mig_comisiones. Les pedimos que nos indiquen si esta modificación está bien.

Gracias!

Federico

10
Hola:

Estamos configurando las correlativas de un plan de estudio y tenemos una duda que parece muy básica pero que nos parece importante:

Cuando se define como requisito tener una actividad "Regularizada", si el alumno ya tiene la actividad aprobada, ¿Guaraní lo calcula como "Regularizada" o es necesario agregar otro grupo de opciones que incluya la opción "Aprobada"?

11
Hola:

Nuestra institución maneja el concepto de regularidad "Libre" para el caso de que el alumno no apruebe la cursada.
Esta condición la cargamos como una condición con el mismo nombre "Libre" pero con resultado Reprobado (A diferencia de  la condición "Libre" por defecto cuyo resultado es "Ausente")

Nuestra consulta es la siguiente: Cuando se habilita la mesa de la actividad en cuestión y se parametriza el sistema para que inscriba al alumno en la instancia (Libre/Regular) que le corresponde de forma automática, ¿qué valor toma el sistema para determinar que debe inscribir a un alumno como Libre?
¿Evalúa la condición de regularidad?
¿Evalúa el resultado de la condición de regularidad?
¿Inscribe como libres a aquellos que tengan resultado distinto de Aprobado?

Les agradecemos cualquier aclaración

Saludos

Federico

12
Usuarios / Cantidad de veces que se puede recursar una actividad
« on: Octubre 29, 2018, 03:42:49 pm »
Hola:

Necesitamos saber si hay algún parámetro que controle la cantidad de veces que un alumno puede recursar una actividad.

Estuvimos viendo los parámetros del sistema en cursadas pero no vimos nada al respecto.

Estamos usando Guaraní 3.15.1

Gracias y saludos

13
Técnicos / Creación de nuevas reglas de cálculo de notas
« on: Octubre 26, 2018, 05:04:25 pm »
Hola:

Estamos trabajando para implementar nuevas reglas de cálculo de notas para calcular la nota de la cursada en base a las notas de las evaluaciones parciales.
Entendemos que se pueden personalizar y agregar nuevas reglas especificando el archivo de la clase PHP por gestion bajo la operacion " Administrar Reglas para el Cálculo de Notas "

No hemos visto este proceso dentro de los procesos que se pueden personalizar en la documentación: http://documentacion.siu.edu.ar/wiki/SIU-Guarani/Version3.15.0/personalizaciones/procesos_personalizables

Tenemos dudas, por ejemplo, si podemos crear una regla que devuelva un resultado (Aprobado, Reprobado, etc.) en vez de una nota.
¿Dónde podemos encontrar más información sobre esta clase de personalización?

Estamos trabajando sobre Guaraní 3.15.1

Gracias y saludos

Federico

14
Usuarios / Alumnos recursantes - cálculo de la regularidad
« on: Octubre 22, 2018, 06:24:30 pm »
Hola:

Tenemos una duda sobre cómo calcula Guaraní la regularidad de un alumno en una actividad a la hora de ejecutar controles.

Por ejemplo en el caso de un alumno que cursó (pero no aprobó) una actividad más de una vez: La primera vez la dejó regular y la segunda vez quedó libre.
¿Qué condición tomaría Guaraní a la hora de ejecutar controles: libre o regular?

Gracias

15
Técnicos / Bajas a exámen por 3w no aparecen en sitio móvil
« on: Agosto 29, 2018, 02:00:14 pm »

Hola, en Guaraní 3.15.1 en autogestión (3W) cuando el alumno ingresa desde un dispositivo móvil no se visualiza la opción para darse de baja de una materia. Según leímos en este thread http://foro.comunidad.siu.edu.ar/index.php?topic=13735.0 se debe a un problema con las plantillas de Twig

El thread es de diciembre de 2017. ¿Cuál es el estado de este bug en Guaraní 3.15.1 ?

Gacias y saludos

Páginas: [1] 2 3 4