Unificacion de carreras de distintas sedes

Buenas tardes

Tengo una carrera en dos bases diferentes de G2. Es exactamente la misma, con el mismo plan y las mismas materias. Cada base responde a una sede.

¿Tengo forma de unificar en la migración esos planes e identificar posteriormente los alumnos a cuál sede pertenecía cada uno? ¿Qué pasa con las comisiones en ese caso?

Gracias

Hola Sabrina, la migración es por base, con lo cual migrarias por ejemplo la base de la Sede 1.
Luego en la 2da migración que corresponde a la Sede 2 podes unificar las actividades (esto lo hace automáticamente el script de migración), pero se va a crear el plan de la 2da sede que migras con los alumnos en ese plan.
Luego de la 2da migración lo que podes hacer es aplicar un cambio de plan a los alumnos de esa sede que migraste al plan que ya existe de la Sede 1 de la 1er migracion.
Hay otra opción que es que en la 2da migración no se migre el módulo de planes, es decir no migres ese plan sino que haciendo algunos seteos en las tablas de migracion de planes, relacionar el plan de la 2da Sede con el id del plan de la 1er sede que ya existe en G3, con lo que al final de la migración tendrias a todos los alumnos en el mismo plan, el plan de la Sede 1. Esta opcion es un poco mas complicada. Pero podrias hacer unas pruebas y ver que tan dificil/complicado resulta.

Hola Alejandro

A mi me pasa que tengo alumnos que están en dos bases diferentes en las mismas carreras. Completo la migración de la primera base y cuando llego al módulo matricula de la migración de la segunda base me aparece un mensaje de error en el q me dice que el alumno no se puede insertar en la tabla sga_alumnos porque ya es alumno de la carrera. El alumno es el mismo, la carrera es la misma y lo que difiere es la ubicación. Cual podria ser el problema?

Saludos

Diego Maza
UNPA

Caso: Alumno de una base a migrar ya existe en la base de Guarani 3 en la misma propuesta.

Hola Diego, si este tema se ha planteado en otras instituciones.
Los casos que vi son alumnos que cambiaron de sede, es decir dejaron de cursar en una sede y continuaron cursando la misma carrera en otra sede.
Y al momento de migrar la 2da base de Guarani 2 se encuentran con este problema.

Una posible solución sin hacer cambios en los scripts de migracion sería::

PRE-MIGRACION:
1). Identificar aquellos alumnos que se encuentran en la base de Guarani 3 en la misma propuesta que en la base de Guarani 2 a migrar.

Para ello correr esta consulta:

SELECT
-- Datos G2
g2a.unidad_academica, g2a.carrera, c.nombre, g2a.legajo, g2p.nro_inscripcion, g2p.apellido, g2p.nombres, g2s.nombre as sede_g2,
-- Datos G3
g3p.apellido, g3p.nombres, g3a.alumno, g3p.persona, g3a.propuesta, p.nombre as propuesta_nombre, g3a.plan_version, g3s.nombre as sede_g3
FROM
   -- Tablas G2
   mig.sga_alumnos as g2a
   JOIN mig.sga_sedes as g2s ON g2s.sede = g2a.sede
   JOIN mig.sga_carreras as c ON (c.unidad_academica = g2a.unidad_academica and c.carrera = g2a.carrera)
   JOIN mig.sga_personas as g2p ON (g2p.unidad_academica = g2a.unidad_academica and g2p.nro_inscripcion = g2a.nro_inscripcion)
   -- Tablas G3
   JOIN sga_propuestas as p ON p.codigo = g2a.carrera
   JOIN mdp_personas_documentos as g3pd ON (g3pd.tipo_documento = g2p.tipo_documento AND g3pd.nro_documento = g2p.nro_documento)
   JOIN mdp_personas as g3p ON (g3p.persona = g3pd.persona)
   JOIN sga_alumnos as g3a ON (g3a.persona = g3pd.persona AND g3a.propuesta = p.propuesta)
   JOIN sga_ubicaciones as g3s ON g3s.ubicacion = g3a.ubicacion
   
  WHERE TRUE
    AND UPPER(TRIM(g3a.legajo)) = UPPER(TRIM(g2a.legajo))
    AND UPPER(TRIM(g3p.apellido)) = UPPER(TRIM(g2p.apellido))
    
ORDER BY g2p.apellido, g2p.nombres, g2a.legajo      

Fijate que en esta consulta considera que el alumno tiene el mismo apellido y legajo en la base a migrar y en Guarani 3. En todo caso podes comentar esos dos filtros si es que el apelldio puede no estar igual o le asignaron otro legajo en la 2da sede.

  1. Para cada uno de esos alumnos cambiar el nro de documento en la tabla del esquema de migracion (mig.sga_personas) anteponiendo un dato que luego nos sirva para poder ubicarlos, por ejemplo al documento 35412560 anteponerle un “-” quedando “-35412560”.
    Esto hará que la validación al migrar el módulo de matrícula no de error de que ya existe un alumno con el mismo documento.

La idea aqui es migrarlo a Guarani 3. Entonces ese alumno quedará dos veces en la tabla de personas (mdp_personas) y tablas asociadas, y tambien en la tabla de alumnos (sga_alumnos) para la misma propuesta.

POS-MIGRACION:
3) Finalizada la migración deberán unificar esos legajos y esas personas en una. Para ello en el SIU tenemos unos scripts para poder hacer esto. Debe hacerse alumno por alumno.

El script para unificar dos legajos de una misma persona en una misma propuesta: Tendran que identificar alumno por alumno que id de alumno dejar (tabla sga_alumnos)

Luego de esto, tendran que unificar los registros de personas (tabla mdp_personas) corriendo el script para unificar personas, y despues borrar el dato de persona que esta duplicado.
Si el dato de persona que quedo es el Migrado, entonces luego deberán cambiar el nro de documento sacando ese caracter que se agregó inicialmente (punto 2)

4). Cambios de Plan: Ademas deberán registrar para esos alumnos el cambio de plan, recuerden que al migrar una 2da base con una misma propuesta de la que ya esta en Guarani 3, este alumno ahora unificado en un solo registro en sga_alumnos deberán ver con que plan queda. Si es el que estaba en Guarani 3 o el plan migrado, cambiando el dato en sga_alumnos.plan_version, y registrando los cambios de plan que haya tenido el alumno en la 2da base migrada (tabla sga_alumnos_hist_planes)

  1. Cambios de Ubicacion: tambien tendran que verificar la sede que corresponda tener ese alumno (sga_alumnos.ubicacion), si es la que ya tenia en la base de Guarani 3 o la ubicación de la base de Guarani 2 migrada.

Los puntos 4 y 5 dependerán de donde el alumno esta activo actualmente o estuvo activo mas recientemente. Si el dato válido del alumno es el que se esta migrando entonces hay que hacer los ajustes de los campos “ubicacion” y “plan_version” en la tabla de alumnos “sga_alumnos” y registrar correctamente los cambios de ubicacion en la tabla “sga_alumnos_hist_ubicacion” y de “plan_version” en la tabla “sga_alumnos_hist_planes”.

  1. Si a esos alumnos cuando ingresó en la 2da sede le otorogaron equivalencias por lo realizado en la 1er sede entonces deberán invalidar esas equivalencias porque al estar ahora unificada las bases de las sedes, existirá el registro original que dieron pie a esas equivalencias por haber cambiado de sede, sino en su historia academica aparecerá el registro original (examen, promocion, eequivalencia) y las equivalencias otorgadas de esas actividades en la 2da sede.

Esta opción planteada funciona si es que unificaron las propuestas. Es decir que la propuesta a migrar que ya existe en Guarani 3, no la migran, reutilizan el id de propuesta que ya existe en Guarani 3 y migran los planes en esa propuesta. Quedando los planes de la propuesta qu eestan en G3 mas los planes de esa misma propuesta que van a migrar.
Esta unifcación se hace en la tabla de migracion mig._cnv_pk_propuestas

Hola Alejandro

Gracias por la solución! Voy a probar a ver que sale.
Creia que las historias académicas de los alumnos quedaban asociadas a la ubicación, es decir, que podia tener historia académica en la misma carrera pero con diferentes ubicaciones y no habría problema de registros duplicados o algo parecido.

La solución q planteas creo que nos va a servir. Los otros scripts que mencionás a quien a que pedírselos?

Saludos

Diego Maza

UNPA

Pedilos por el GDS.
Es que el alumno va a quedar, luego que lo unifiques (un solo registro en sga_alumnos y mdp_personas) con historia academica registrada en diferentes sedes. Eso no se cambia, tendrá examenes, cursadas promociones registradas en una sede y tambien en la otra.
Lo que no puede quedar es que el ese alumno quede con dos registros en sga_alumnos para la misma propuesta, por eso la unificación.

Ok, ahora me queda mas claro.

Gracias Alejandro!

Saludos

Diego

Hola, reabro este hilo porque tenemos el mismo problema con una facultad.
Estamos migrando a 3.18.1 (todavía en prueba), y tenemos bases de G2 por sede (algunas)
Por ejemplo:

  • Carrera 1 se dicta en sede A y B
  • Carrera 2 se dicta en sede C y D
  • Carrera 3 se dicta en sede A y D

y así por el estilo.
Ya tenemos migradas la bases mas ordenadas y donde no se repiten las carreras.
probamos tratar de unificar antes de migrar pero no pudimos.

Esta sigue siendo la recomendación para estos casos? migrar duplicado y despues unificar personas?

gracias!

Alfredo, tienen una base por sede?
Para el ejemplo planteado tienen una base por cada sede: A, B, C, D

Para el caso:

  • Carrera 1 se dicta en sede A y B
    Al migrar la base de la sede A, se va a crear la carrera 1 con sus planes de estudios y versiones de planes de estudios.

Cuando migren la sede B, deberian unificar la Carrera 1, indicando que ya existe en G3. Pero se van a crear los planes de estudios y las versiones de planes de estudios de esta carrera de la se de B y los alumnos asociados a estos planes.
Finalizando la migracion de la sede B, van a tener:
Carrera 1.
- Plan A1, A2… (Sede A)
- Plan B1, B2… (Sede B)
Cada uno con sus alumnos.
En este punto hay dos opciones:

  1. Crear un nuevo plan de estudios para la carrera 1, y hacer un cambio de plan a todos los alumnos activos que esten en los planes Ax y Bx…
  2. Cambiar de plan a los alumnos de los planes Ax a algun plan B o al reves.

En esta migración no hay una forma sencilla de unificar planes y versiones de planes de estudio (como se hace con las propuestas o las actividades, etc), porque es dificil garantizar que sean exactamente iguales (tengan el mismo versionado, etc).

En lo posible vean de migrar con la version 3.19, porque hubo ajustes y mejoras respecto a los scripts de la version 3.18.

Saludos.

Hola Alejandro.

tienen una base por sede?
Si, y no. En algunos casos una base incluye varias sedes A,B y C. La sede principal es la base D y solo tiene las carreras de la sede principal. A tiene una carrera en común con D y C tiene otra carrera distinta a A en común con D. Así mas o menos es el caso. Ya tenemos migradas en prueba la sede principal y 2 sedes mas que no tenían estos problemas.

Hola, hago otra pregunta con respecto a este tema.
Me da error en la migración de docentes, en el modulo 40 Doctenes, script 10_sga_docentes_ra.
Esta tratando de insertar docentes que ya están en la responsable académica.

Como son 2 bases distintas algunos docentes están en ambas bases. todavía estamos en pruebas así que lo solucioné modificando el sql del trabajo y me permitió continuar, ¿Que debería modificar para cuando migremos de forma definitiva?.
Gracias!

el sql modificado quedo así:


-- Los docentes que en G2 NO estaban asociados a algun departamento
-- Los asocio a la responsable academica relacionada con la Unidad Academica
INSERT INTO sga_docentes_ra (docente, responsable_academica)
SELECT DISTINCT 
	doc.docente,
	mdepto.responsable_academica
FROM
	mig.sga_docentes as md 
	JOIN mig._cnv_pk_docentes as doc ON doc.legajo_g2 = md.legajo
	JOIN sga_docentes as d ON d.docente = doc.docente
	JOIN mig._cnv_pk_personas as cpp ON cpp.persona = d.persona,
    mig._cnv_pk_departamentos as mdepto
 
WHERE	
	md.legajo NOT IN (SELECT legajo FROM mig.sga_docentes_dpto) AND
-- agregado
	not exists(select '' from sga_docentes_ra sda where doc.docente = sda.docente and mdepto.responsable_academica = sda.responsable_academica)
--- fin agregado
	and mdepto.tabla = 'sga_unidades_acad';

Hola Alfredo, agregar la sentencia al final que esta en negrita:
INSERT INTO sga_docentes_ra (docente, responsable_academica)
SELECT DISTINCT
doc.docente,
mdepto.responsable_academica
FROM
mig.sga_docentes as md,

WHERE
mdd.legajo = md.legajo AND

mdepto.tabla IN (‘sga_departamentos’, ‘sga_unidades_acad’)
EXCEPT
SELECT docente, responsable_academica FROM sga_docentes_ra;

Gracias!