SIU-Guarani/Version3.21.0/Migracion/Desde SIU Guarani 2/Migracion/consideraciones finales

Consideraciones Finales a la Migración de Guaraní 2 a Guaraní 3

En este apartado se indicarán los aspectos que deberán revisar luego de realizar la migración de una base de Guaraní 2.

Escala de Notas

Deben revisarse las escalas de notas que se migraron desde Guaraní 2. Hay datos que definen como es una escala de notas los cuales deben ajustarse ya que en la migración se setean con datos por defecto. Los campos a revisar son:

• Tabla: sga_escalas_notas
• Campos:
  • nombre = Nombre de escala de notas. Es la descripción que el usuario ve en los combos de escalas de notas en comisiones/mesas de examen/evaluaciones parciales/etc. Como las escalas de notas cuando tenían un resultado P-Promoción, se dividían en 2 escalas, una para regulares y otra para promociones, es que el nombre de la escala de notas se modificó agregando la palabra "Promoción".
    
  • tipo = Tipo de escala de notas.
    • Valores posibles:
      • DISCRETA = Cuando el conjunto de notas puede contener cualquier valor (numeros, letras, etc. Ejemplo: A, B, C, 1, 3, 5)
      • CONTINUA = Usado cuando las notas son numéricas y consecutivas (Ej: 1, 2, 3, 4,5...10)
        
  • es_numerica = Define si la escala de notas es numérica (no importa si es discreta o continua)
    • Valores posibles:
      • S - Es Numérica
      • N - Es Alfanumérica
        
  • cantidad_decimales = En el caso que la escala de notas sea numérica (es_numerica = S) define la cantidad de decimales que tiene cada nota. Valores posibles: 0 a 3
    
  • separador_decimal = Cuando las notas son numéricas y tiene decimales (es_numerica = S y cantidad_decimales es mayor a 0) debe indicarse cual es el separador decimal que tiene cada nota.
    • Valores posibles:
      • . = Punto
      • , = Coma
        
  • nota_inicial = En el caso que las notas sean numéricas (tipo = CONTINUA) se debe definir cual es el valor de inicio de las notas
    
  • nota_final = En el caso de que las notas sean numéricas (tipo = CONTINUA) se debe definir cual es el ultimo valor del conjunto de notas
    
  • estado = Estado de la escala de notas.
    • Valores posibles:
      • A - Escala de notas Activa. Será visualizada en el sistema
      • B - Escala de notas dada de Baja

• Tabla: sga_escalas_notas_det

Para escalas de notas numéricas, revisar que el campo valor_numerico tenga definido el valor numerico que corresponde a la nota, ya que este dato es el utilizado para calcular el promedio de notas del alumno.
Si quedaron sin valor numerico, se puede actualizar este campo con la siguiente query:
UPDATE sga_escalas_notas_det

 SET valor_numerico = cast(replace(nota,',','.') as decimal(8,3))
WHERE valor_numerico IS NULL
  AND escala_nota IN (select escala_nota from sga_escalas_notas where es_numerica = 'S');

---

Revisar la configuracion de escala de notas e instancias para las que estará disponible la escala de notas. Tabla sga_escalas_notas_instancias
Tabla de instancias: sga_instancias

---

Si se pasa de una escala de notas de tipo DISCRETA a CONTINUA se deberan registrar los valores en las siguientes tablas:

• sga_escalas_notas_rangos_resultados: En esta tabla se registran cada resultado (R-Reprobado / A-Aprobado) segun el rango de notas.
  
• sga_escalas_notas_rangos_conceptos: En esta tabla se registran los conceptos de cada nota segun rango de notas.
  

---

Validación ingreso de notas en interfaz de autogestión

En la interfaz de autogestión docente en las operaciones de carga de notas en actas la validación de las notas y resultado ingresado por el docente se hace a través de javascript consultando el archivo de escalas de notas que se encuentra en el sistema de archivos en la carpeta www/js/escalas. Al realizar la validación de lo que ingresa el docente no se hace en la base sino sobre lo que este registrado en estos archivos (uno por cada punto de acceso).
Este archivo con las escalas de notas se debe actualizar luego de que se registre una nueva escala de notas en la base. Para realizar esta actualización se debe ejecutar el siguiente comando: ./bin/guarani generar_escalas punto_de_acceso.

---

Escalas de notas de cursadas

En el proceso de migración, las escalas de notas que estaban asignadas a las comisiones que eran promocionales se convirtieron en dos nuevas escalas de notas, una que se asignó a la instancia de Regularidad y otra a la instancia de Promoción. Estas escalas son iguales en cantidad de notas pero diferente en cuanto al resultado de algunas de sus notas.
Ejemplo:
Escala de notas de Guaraní 2 utilizada en una comision promocional, que tiene las siguientes notas:
0 = Reprobado
1 = Reprobado
2 = Reprobado
3 = Reprobado
4 = Aprobado
5 = Aprobado
6 = Aprobado
7 = Promocionado
8 = Promocionado
9 = Promocionado
10 = Promocionado

Esta escala de notas de promoción deja de utilizarse y se generan dos escalas de notas, como ser:
Escala de notas para Acta de Cursada:
0 = Reprobado
1 = Reprobado
2 = Reprobado
3 = Reprobado
4 = Aprobado
5 = Aprobado
6 = Aprobado
7 = Aprobado
8 = Aprobado
9 = Aprobado
10 = Aprobado

Y una escala de notas para Acta de Promoción, donde el "Reprobado" corresponde a "No Promocionado" y el "Aprobado" a "Promocionado":
0 = Reprobado
1 = Reprobado
2 = Reprobado
3 = Reprobado
4 = Reprobado
5 = Reprobado
6 = Reprobado
7 = Aprobado
8 = Aprobado
9 = Aprobado
10 = Aprobado

Correlativas especiales

Cada correlativa especial que estaba definida en Guaraní 2 (tabla sga_correlativas_esp) fueron migradas a Guaraní 3 como Requisitos.

En la migración de correlativas especiales se crea lo siguiente por cada correlativa especial:

• Un requisito (tabla sga_requisitos) con el mismo nombre que tenia la correlativa especial en el campo "funcion_validacion", que es el nombre del stored procedure de Informix que tiene la lógica de la correlativa.
  

El requisito se crea con el tipo de requisito "Procesos - Actividad".

• Una regla (tabla sga_reglas) que es asignada al requisito. Esta regla lleva el mismo nombre que el requisito.
  

La lógica que contenia la correlativa especial debe programarse en la clase php que queda definida en esta tabla en el campo "clase_php" que es el mismo nombre de la regla/requisito.
Esta clase php será la que contiene la función de validación de la correlativa.

Ejemplo:
Se migra la correlativa especial con nombre sp_5mataprob_1eraño. Por esta correlativa se crea un requisito (sga_requisitos) con el mismo nombre y una regla (sga_reglas) asociada a ese requisito también con el mismo nombre.

Pasos para desarrollar esta correlativa especial:
1) Deben crear un archivo php con el nombre sp_5mataprob_1erño.php en la carpeta de personalizaciones /personalizacion/php/nucleo/_lib/reglas.

2) La regla debe contener la funcion validar() el cual contendra el código de la correlativa especial.
La clase debe extender de la clase regla.
Ejemplo del archivo:

<?php
class sp_5mataprob_1eraño extends regla
{
        function validar()
        {
                // Parámetros de contexto
                $alumno = $this->get_parametro('alumno');
                $fecha  = $this->get_parametro('fecha');

                // Consulta que recupera la cantidad de materias aprobadas de 1er año del alumno.
                $cant_actividades_aprobadas = toba::consulta_php('co_alumnos')->get_cantidad_materias_aprobadas_x_año($alumno, $fecha, 1);  

                if ($cant_actividades_aprobadas < 5) {
                        // Falla el control El alumno tiene menos de 5 materias aprobadas de 1er año.
                        $resultado = false;
                        $nombre_alumno = $datos['alumno_nombre'];
                        $this->set_parametros_mensaje_validacion(array($nombre_alumno), true);
                } else {
                        // Control OK. El alumno tiene 5 o mas materias aprobadas de 1er año.
                        $resultado = true;
                }
                // Retorna el resultado de la correlativa especial.
                return $resultado;
        }
}

3) Una vez creado el archivo debe correrse el comando:

/.guarani pers_autoload.

4) Agregar los nombres de los parámetros que se usan en la regla en la tabla sga_reglas_param_contexto para la nueva regla creada:

INSERT INTO sga_reglas_param_contexto (regla, parametro) VALUES ( 1006,'alumno');
INSERT INTO sga_reglas_param_contexto (regla, parametro) VALUES ( 1006,'fecha');

5) Cambiar el nombre del requisito ya que cuando falle la correlativa especial, se mostrará como mensaje de error del control de correlativas el nombre del requisito, que en este caso por defecto tiene el nombre del stored procedure de informix.

UPDATE sga_requisitos
   SET nombre = 'xxxxxxxxxxxx',
       descripcion = 'yyyyyyyyyyyyy'
 WHERE nombre = 'sp_5mataprob_1eraño'
   AND requisito_tipo = 6;

---

Pueden ver ejemplos de clases php que corresponden a los requisitos que se ejecutan en las diferentes operaciones del sistema en \php\nucleo\_lib\reglas
Documentación para desarrollar un requisito de tipo proceso.

Para verificar si se crearon requisitos que corresponden a correlativas especiales, buscarlo con la siguiente consulta:

SELECT * FROM sga_requisitos as r1 JOIN sga_reglas as r2 ON r2.regla = r1.regla WHERE r1.requisito_tipo = 6 ORDER BY r1.nombre;

Importante: Deben revisar cada correlativa especial de Guarani 2 si es que esta lógica implementada alli a traves de un stored procedure puede ser reemplazada con los requisitos o formas de cumplimiento de modulos que provee Guarani 3. De ser asi, deberían editar el plan y modificar la correlativa especial por el requisito que corresponda.

Perdidas de Regularidad en las propuestas

Hay casos de pérdida de regularidad en las propuestas que quedan sin un registro de la/s causa/s por las que perdió la regularidad el alumno. Esto hace que en la operación de Readmisión cuando se quiera readmitir al alumno no se encuentre la pérdida de regularidad.
Para resolver este problema, deberán registrar al menos una causa de pérdida de regularidad a esos registros.

1) Verificar si hay registros de pérdida de regularidad sin una causa registrada:

SELECT * FROM sga_perdida_regularidad
WHERE perdida_regularidad IN (
   SELECT perdida_regularidad FROM sga_perdida_regularidad
     EXCEPT
  SELECT perdida_regularidad FROM sga_perdida_regularidad_det)
ORDER BY alumno;

3) Elegir una causa de perdida de regularidad para setar por defecto:

SELECT * FROM sga_perdida_regularidad_causas;

4) Registrar una causa de pérdida de regularidad por defecto a esos registros:

INSERT INTO sga_perdida_regularidad_det (perdida_regularidad, causa_perdida_reg)
SELECT prd.perdida_regularidad, <id causa perdida regularidad del punto 3>
FROM (select perdida_regularidad from sga_perdida_regularidad
       except
      select perdida_regularidad from sga_perdida_regularidad_det
     ) as prd;

5) Requisitos para evaluar la regularidad/readmisión vencida
Deben revisar los causas de perdida de regularidad que quedaran activas para ser ejecutadas al momento de controlar la regularidad o vencimiento de readmisión a los alumnos. En la tabla sga_perdidas_regularidad_causas se migran las causas de pérdida de regularidad que tenian configuradas en Guarani 2, pero si alguna era una personalización deberán desarrollar la regla que corresponde a esa causa de perdida de regularidad personalizada.
Las causas de pérdida de regularidad que no deban ejecutarse deben darlas de baja cambiando el estado a B (Baja).

< Migración desde SIU-Guaraní 2

Configuración de Requisitos por Acción, Requisitos de Ingreso y Períodos de Inscripción

Al migrar una nueva base sobre una instalación con datos deberán reconfigurarse los requisitos por acción, requisitos de ingreso y períodos de inscripción para incluir las nuevas versiones de planes de estudios que fueron migradas.
Las tablas involucradas son:
sga_requisitos_aplanado: Requisitos por acción.
sga_periodos_inscripcion_aplanado: Períodos de inscripción a propuestas, mesas de examen y comisiones.
sga_requisitos_ingreso_aplanado: Requisitos de ingreso a propuestas.

Esto puede realizarse desde el sistema desde las siguientes operaciones:

• Requisitos » Reporte de Requisitos por Propuesta
• Calendario » Reporte de Períodos de Inscripción por Propuesta
• Requisitos » Requisitos de Ingreso » Reporte de Requisitos de Ingreso por Propuesta
  

Generación de Número de Legajo de Alumnos

Para que en la generación de números de legajos de alumnos continúe con el siguiente número al último nùmero de legajo de alumno migrado entonces deber recuperase el último número de legajo migrado y setear la secuencia nro_legajo_alumno_seq.
Suponiendo que el último número de legajo existente en la base es el 5486, entonces deben correr lo siguiente en la base:

SELECT setval('nro_legajo_alumno_seq',5486);

Actualización Secuencia de Nros de Transacción

Luego de migrar hay que actualizar la secuencia aud_nro_transaccion_seq utilizada en diferentes tablas que identifican univocamente cada transacción (Inscripcion a propuesta, Inscripción a Cursada, Inscripción a Examen, ....) Para que esta secuencia quede actualizada con el número de transacción mas alto de los datos migrados, correr la siguiente query:

SET search_path = negocio;

SELECT setval('aud_nro_transaccion_seq',
get_mayor((SELECT last_value FROM aud_nro_transaccion_seq)::integer,                  
(SELECT MAX(t.a) FROM (
SELECT MAX(nro_transaccion) FROM int_sq_morosos UNION
SELECT MAX(nro_transaccion) FROM sga_constancias_solicitud UNION
SELECT MAX(nro_transaccion) FROM sga_insc_cursada UNION
SELECT MAX(nro_transaccion) FROM sga_insc_cursada_actividad UNION
SELECT MAX(nro_transaccion) FROM sga_insc_cursada_log UNION
SELECT MAX(nro_transaccion_log) FROM sga_insc_cursada_log UNION
SELECT MAX(nro_transaccion) FROM sga_insc_examen UNION
SELECT MAX(nro_transaccion) FROM sga_insc_examen_log UNION
SELECT MAX(nro_transaccion_log) FROM sga_insc_examen_log UNION
SELECT MAX(nro_transaccion) FROM sga_propuestas_aspira UNION
SELECT MAX(nro_transaccion) FROM sga_propuestas_aspira_log UNION
SELECT MAX(nro_transaccion_log) FROM sga_propuestas_aspira_log UNION
SELECT MAX(nro_transaccion) FROM sga_reinscripciones
) as t (a))::integer
));