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

De SIU
Saltar a: navegación, buscar


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.

Esquema de migracion

Es recomendable dejar por un tiempo el esquema de migración con las tablas y datos de la base de datos de Guarani 2 migrada hasta tanto la base de G3 este estable y no deba hacerse ningún ajuste en los datos migrados.
Se debe renombrar el esquema mig por un nombre que identifique a la unidada academica recientemente migrada. Por ejemplo si se migró una base de la unidad académica "Facultad de Ingeniería", se podría renombrar ese esquema a mig_ingenieria.
Esto permitirá contar con los datos originales migrados ante cualquier análisis posterior o ajuste en datos de migración que haya que realizar, ya que se tendrán aun los datos de las tablas de conversión de Primary Key de las tablas (relaciones entre tablas de G2 y G3).

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



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.


Correlativas especiales

Cada correlativa especial que estaba definida en Guarani 2 (tabla sga_correlativas_esp) fueron migradas a Guarani 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 funcion 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;



< Migración desde SIU-Guaraní 2