Procesamiento de inscripciones con Prioridades

Buen día,

Estamos viendo el procesamiento de inscripciones con Prioridades y tenemos algunas dudas de si puede servirnos respecto de como se trabajaba en G2 en una facultad, que migramos recientemente a G3 (la idea es eliminar personalizaciones e ir al estandar):

Como es la Inscripción a cursadas en un cuatrimestre en una facultad particular:

Los alumnos se inscriben libremente a las actividades y dentro de ellas pueden inscribirse a todas las comisiones que deseen, siendo implícitamente, la fecha-hora de inscripción, el preferido para quedar aceptado en la misma.
Los alumnos presentan certificado de trabajo, lo que sirve para que los mismos tengan prioridad de aceptación.
Si bien las comisiones tienen cupo y bandas horarias, los mismos no se controlan en la inscripción.

Una vez finalizada la inscripción se procesaban las mismas y luego se corría un proceso que rankeaba las mismas según 2 criterios: Certificado de trabajo y cantidad de materias aprobadas del alumno. También en ese momento se hace el control de Cupo y superposición horaria. El alumno que presento certificado de trabajo tiene máxima prioridad de ingreso en la comisión, en caso de no haber presentado certificado, tienen prioridad los que tengan mayor cantidad de materias aprobadas, hasta completar el cupo.

Hemos hecho algunas pruebas y queríamos verificar lo siguiente:

1. El procesamiento de Inscripciones con prioridades, solo se puede realizar sobre actividades que tengan prioridad definida?
   El campo Cantidad máxima de prioridades, que significa? y como actúa cuando una actividad tiene N comisiones? Esto tiene que tener alguna correlación con el parámetro cur_cant_max_insc_igual_actividad_periodo_lectivo?

2. El procesamiento de Inscripciones en estado pendiente, solo se puede realizar sobre actividades que NO tengan prioridad definida?

3. Si el alumno se inscribe a mas de una comisión de la misma materia, y queda aceptado en 1, en que estado queda en las demas?

4. La operación de Reprocesar inscripciones a actividades, sirve para inscripciones con prioridades? en ese caso, como actua respecto de las prioridades?

Saludos

Hola Jorge! Cómo estás?

Sí, el circuito de Inscripciones por Prioridad serviría bien para el caso que detallan.
Pero deben tener en cuenta aquí dos puntos:

1. La institución debe desarrollar las reglas que utilizarán como criterios a la hora de procesar las inscripciones (en su caso el tener presentado el certificado de trabajo y la cantidad de materias aprobadas).
2. Actualmente hay un bug en el circuito ya que se está considerando el cupo a la hora de las inscripciones (cuando sólo debería considerarse a la hora de su procesamiento). Pero ya estamos trabajando para solucionarlo.

Ahora sí pasamos a responder las consultas que nos hacés:

1. El procesamiento de Inscripciones con prioridades, solo se puede realizar sobre actividades que tengan prioridad definida? El campo Cantidad máxima de prioridades, que significa? y como actúa cuando una actividad tiene N comisiones? Esto tiene que tener alguna correlación con el parámetro cur_cant_max_insc_igual_actividad_periodo_lectivo?

Así es, desde "Administrar Actividades" deben indicar que la actividad utiliza la inscripción por prioridades y establecer la cantidad máxima de prioridades. Este número lo que indica es la cantidad de comisiones que va a poder seleccionar el alumno. Es decir, si allí establecen una cantidad de 3, entonces el alumno al momento de inscribirse deberá seleccionar hasta 3 actividades entre las existentes para la actividad y ordenarlas según la prioridad que desea. No tiene relación con el parámetro [b]cur_cant_max_insc_igual_actividad_periodo_lectivo[/b]. Dicho parámetro no debería afectar a las inscripciones por prioridades, pero si en las pruebas notan que está interfiriendo avísennos así lo arreglamos.

2. El procesamiento de Inscripciones en estado pendiente, solo se puede realizar sobre actividades que NO tengan prioridad definida?

Así es! Existen dos operaciones diferentes: [b]Procesar Inscripciones Pendientes a Actividades[/b] que sirve para procesar las inscripciones pendientes de aquellas actividades que no utilizan prioridad; y [b]Procesar Inscripciones con Prioridades[/b] que es la que utilizarían para estos casos.

3. Si el alumno se inscribe a mas de una comisión de la misma materia, y queda aceptado en 1, en que estado queda en las demas?

Al momento de inscribirse el sistema registrará una inscripción en estado "Pendiente" para cada una de las comisiones seleccionadas. Cuando estas inscripciones se procesen el sistema decidirá, en base a los criterios definidos, en qué comisión quedará cada alumno. La inscripción pasará a estado "Aceptada" para dicha comisión, y las inscripciones al resto de las comisiones pasarán a estado "Rechazada".

4. La operación de Reprocesar inscripciones a actividades, sirve para inscripciones con prioridades? en ese caso, como actua respecto de las prioridades?

Esta operación tiene como objetivo permitir aceptas las inscripciones en estado aceptada o pendiente a una o mas instancias en las cuales se inscribió un alumno a una comisión. Esta operación es muy útil cuando, por ejemplo, en medio de un cuatrimestre hay mesas de exámenes que pueden implicar que cambie la condición de un alumno y le permita alcanzar la instancia de Promoción cuando, al momento de la inscripción, no podía. En este sentido está pensada solo para inscripciones que no utilicen prioridad. Pero podrían utilizarla para este tipo de inscripciones siempre y cuando ya las hayan procesado previamente y ya esté cada alumnos en su comisión definitiva. Se entiende?

Hay varios foros con consultas sobre las inscripciones por prioridad que pueden buscar para tener más detalles sobre este circuito.
Y también todas las dudas que les vayan surgiendo consúltennos.

Saludos!

3

Hola Martín, gracias por la respuesta, consulta sobre el Bug: 2) Actualmente hay un bug en el circuito ya que se está considerando el cupo a la hora de las inscripciones (cuando sólo debería considerarse a la hora de su procesamiento). Pero ya estamos trabajando para solucionarlo.

Como nosotros al momento de la inscripción con Prioridades NO Controlamos Cupo, lo que me decis aqui es que, aunque tenga configurado el sistema para que No se Controle cupo en la inscripción, por haber sido definida la materia con Prioridad lo controla igual? y por otro lado: si al crear la comisión de la materia con Prioridad no le pongo Cupo como funcionaría? Podemos salvarlo asi al Bug de la inscripcion por el momento?

Hola Jorge!

Así es, podrían salvar el problema de alguna de estas dos formas:

1. configurando el sistema para que NO controle el cupo durante el transcurso de las inscripciones, y volviendo a configurarlo para que sí lo controle al momento en que van a procesar esas inscripciones (aquí el inconveniente es que esa configuración va a afectar a todas las inscripciones y posiblemente en otras actividades sí quieran que se controle el cupo).

2. No establecer el cupo a las comisiones durante el transcurso de las inscripciones. Establecérselo recién una vez que van a procesarlas.

Cualquiera de estos dos caminos les serviría para sortear este inconveniente hasta que esté resuelto.
La idea es que una vez resuelto, uno pueda configurar el cupo y tener habilitado su control pero que para las inscripciones por prioridad no lo controle al momento de la inscripción pero sí al momento de procesarlas.

Saludos!

2

Perfecto.
muchas gracias Martín

Consulta,

Si desarrollo un criterio de materias aprobadas, ¿como le indico al sistema qué les de mayor ponderación a quienes tengan mayor cantidad?

En los criterios que vienen por defecto pareciera que el orden es ascendente. Por ejemplo, el criterio de “fecha y hora de inscripcion” entiendo que tendrán mayor prioridad los que se inscriben antes (fecha de inscripcion menor)

EDIT:
Por lo que estuve investigando, todo termina en el metodo [b]co_inscripciones_cursadas ->get_actividades_insc_prioridad/b que arma la consulta asi:

SELECT 
f_criterio_trabaja(sga_alumnos.persona), 
f_criterio_tiene_hijos(sga_alumnos.persona), 
f_criterio_cursa_otra_prop(sga_alumnos.persona, sga_alumnos.propuesta), 
sga_insc_cursada.fecha_inscripcion, 
f_criterio_certificado_trabajo(sga_alumnos.persona), 
f_criterio_cant_aprobadas(sga_alumnos.alumno), 

sga_insc_cursada.inscripcion, sga_insc_cursada.alumno, sga_alumnos.persona, sga_alumnos.propuesta, sga_comisiones.elemento, sga_insc_cursada.comision, sga_insc_cursada.prioridad, sga_comisiones.cupo, sga_insc_cursada.tipo, sga_insc_cursada.estado_preinscripcion, sga_insc_cursada.plan_version, sga_insc_cursada.fecha_inscripcion, CAST(sga_insc_cursada.fecha_inscripcion AS DATE) AS fecha_inscripcion_formato_date, sga_insc_cursada.fuera_de_termino, sga_insc_cursada.autorizado_por, sga_insc_cursada.nro_transaccion, sga_insc_cursada.motivo_excepcion, sga_insc_cursada.exceptuado, sga_insc_cursada.interfaz, sga_insc_cursada.estado, 
-- Campos a mostrar en reportes -------------------- 
sga_elementos.nombre || ' (' || sga_elementos.codigo || ')' AS actividad_descr, 'Comision: ' || sga_comisiones.nombre || COALESCE(' - Turno: ' || sga_turnos_cursadas.nombre, '') || ' - Cupo: ' || COALESCE(CAST(sga_comisiones.cupo AS VARCHAR), 'Sin cupo definido') AS comision_descr, mdp_personas.apellido, mdp_personas.nombres, mdp_personas.apellido || ' ' || mdp_personas.nombres AS apellido_y_nombre, mdp_tipo_documento.desc_abreviada || ' ' || mdp_personas_documentos.nro_documento AS identificacion, '(' || sga_elementos.codigo || ') ' || sga_elementos.nombre AS actividad_codigo_y_nombre, sga_comisiones.nombre AS comision_nombre, sga_propuestas.nombre_abreviado AS propuesta_nombre_abreviado, sga_periodos.anio_academico, sga_periodos_genericos.nombre AS periodo_generico_nombre, f_instancias_insc_cursada(sga_insc_cursada.inscripcion) AS instancias, sga_periodos.nombre AS periodo_nombre 

FROM sga_insc_cursada 
JOIN sga_alumnos ON sga_insc_cursada.alumno = sga_alumnos.alumno 
JOIN mdp_personas ON sga_alumnos.persona = mdp_personas.persona 
JOIN mdp_personas_documentos ON mdp_personas.documento_principal = mdp_personas_documentos.documento 
JOIN mdp_tipo_documento ON mdp_personas_documentos.tipo_documento = mdp_tipo_documento.tipo_documento 
JOIN sga_propuestas ON sga_alumnos.propuesta = sga_propuestas.propuesta 
JOIN sga_comisiones ON sga_insc_cursada.comision = sga_comisiones.comision 
JOIN sga_elementos ON sga_comisiones.elemento = sga_elementos.elemento 
JOIN sga_periodos_lectivos ON sga_comisiones.periodo_lectivo = sga_periodos_lectivos.periodo_lectivo 
JOIN sga_periodos ON sga_periodos_lectivos.periodo = sga_periodos.periodo 
JOIN sga_periodos_genericos ON sga_periodos.periodo_generico = sga_periodos_genericos.periodo_generico 
LEFT JOIN sga_turnos_cursadas ON sga_comisiones.turno = sga_turnos_cursadas.turno 

WHERE sga_comisiones.periodo_lectivo = '823' AND sga_comisiones.elemento IN (28946) AND sga_insc_cursada.tipo = 'P' AND sga_insc_cursada.estado_preinscripcion = 'P' 

ORDER BY sga_comisiones.elemento, 1, 2, 3, 4, 5, 6, sga_insc_cursada.prioridad

Alli se ve que el ordenamiento es obligatoriamente ascendente y no veo forma de poder cambiar eso. Me podrian decir si hay alguna forma?

Graciass

Hola Jorge!

En los criterios que vienen por defecto pareciera que el orden es ascendente. Por ejemplo, el criterio de "fecha y hora de inscripcion" entiendo que tendrán mayor prioridad los que se inscriben antes (fecha de inscripcion menor)

A la hora de procesar las inscripciones por prioridades, al pasar por la solapa de “Criterios de Prioridad” se les van a listar los criterios disponibles para que seleccionen los que deseen utilizar y van a ver que hay unas flechas que les permitirá modificar el orden de esos criterios. VER IMÁGEN ADJUNTA.

Es esto a lo que te referís?

Saludos!

2

Hola Martin,

No no… eso lo tengo claro. A lo que me refiero es al criterio como una regla aislada. Por darte un ejemplo, imaginate una comision con cupo de 15 y que al procesar solo dejo el criterio de “fecha y hora de inscripcion” (destildando el resto); ESE criterio posee un orden ascendente si o si. Es decir, yo no podria (al menos no veo cómo) hacer que entren en la comision los ultimos 15 que se inscribieron, sino que van a ingresar los primeros 15. Obvio que esto no tiene sentido, por qué querrias que los ultimos sean los primeros jajaja. Es solo para ilustrar el problema

La regla que desarrollé calcula la cantidad de materias aprobadas de un alumno, pero luego al utilizar ese criterio creo que van a ingresar los 15 que tengan MENOS materias aprobadas (al reves de lo que se quiere)

Emiliano, creo es cambiando el orden

SELECT
f_criterio_trabaja(sga_alumnos.persona),
f_criterio_tiene_hijos(sga_alumnos.persona),
f_criterio_cursa_otra_prop(sga_alumnos.persona, sga_alumnos.propuesta),
sga_insc_cursada.fecha_inscripcion,
f_criterio_certificado_trabajo(sga_alumnos.persona),
f_criterio_cant_aprobadas(sga_alumnos.alumno),  -- Campo nro 6 del select
....
FROM sga_insc_cursada
....
WHERE ....

ORDER BY sga_comisiones.elemento, 6, sga_insc_cursada.alumno , sga_insc_cursada.prioridad

ORDER BY , , ,

ORDER BY sga_comisiones.elemento, [, …], sga_insc_cursada.alumno, sga_insc_cursada.prioridad

Si la prioridad es por cantidad de materias aprobadas y fecha de inscripcion segun query anterior:

ORDER BY sga_comisiones.elemento, 6, 4, sga_insc_cursada.alumno, sga_insc_cursada.prioridad

Ejemplo. Si tenes las siguientes inscripciones:
alumno | cantidad de actividades aprobadas | fecha de inscripcion
44 | 12 | 15/02/2023 14:25:00
86 | 11 | 15/02/2023 15:50:00
125 | 12 | 15/02/2023 08:33:00
241 | 2 | 14/02/2023 09:40:00
102 | 22 | 16/02/2023 15:00:00

Procesara en este orden: 102, 125, 44, 86, 241

Perfecto, Aleandro. Gracias!

Ya tenemos implementados los criterios. La duda que tenemos ahora es sobre las inscripciones rechazadas por correlativas o cualquier otro control. Para revertir el rechazo utilizamos la operación Revertir Rechazo de Inscripción a Actividad pero luego cuando quisimos volver a usar la operacion
Procesar Inscripciones con Prioridades no la procesa, es decir, no la acepta ni la rechaza ¿Se nos está escapando algo?

Hola Emiliano!

En qué versión se encuentran?

La duda que tenemos ahora es sobre las inscripciones rechazadas por correlativas o cualquier otro control.

Estos controles se deberían correr al momento de la inscripción. Es decir, si al momento de inscribirse el alumno no cumple con los controles no debería dejarlo proseguir. Por lo que los rechazos realizados al momento de procesar las inscripciones por prioridades sólo deberían deberse a que no quedan cupos en las comisiones disponibles. En este sentido, el rechazar inscripciones y luego revertir el rechazo no debería entrar dentro de la lógica de las inscripciones por prioridades.

Si buscan las inscripciones en el Reporte de Inscripciones a Cursadas cómo les aparecen las mismas (en qué estado y con qué instancias asociadas)?

3

Hola Martin,
Estamos en la version 3.20.1.
Entiendo lo que decis en cuanto a que el momento en que se realizan los controles deberia ser durante la inscripción en lugar de luego en el procesamiento. Pero en nuestro caso, necesitamos de todas maneras poder revertir estas inscripciones ya que la unidad academica realiza ajustes a los cupos de las comisiones una vez hecho el procesamiento.

Por lo que estuvimos analizando, para que la operacion de Procesar Inscripciones con Prioridades pueda volver a procesar una inscripcion rechazada, el campo estado_preinscripcion de la tabla sga_insc_cursada debe estar en ‘P’ y no ‘R’ que es el estado en el que quedan luego de ser rechazadas y “revertidas”. Ese campo lo modifica en la funcion f_anular_rechazo_insc_cursada:

  -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  -- Vuelvo a registrar la inscripcion rechazada
  -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  INSERT INTO sga_insc_cursada (
           inscripcion, comision, alumno, plan_version, tipo, prioridad, estado_preinscripcion, 
           fuera_de_termino, estado, interfaz, fecha_inscripcion, nro_transaccion, motivo_excepcion, exceptuado, autorizado_por)
   VALUES (log.inscripcion, log.comision, log.alumno, log.plan_version, log.tipo, log.prioridad, log.estado_preinscripcion, log.fuera_de_termino, 
           log.estado, log.interfaz, log.fecha_inscripcion, log.nro_transaccion, log.motivo_excepcion, log.exceptuado, log.autorizado_por);

Fijate que al campo estado_preinscripcion le asigna el valor de log.estado_preinscripcion que logicamente está en ‘R’

¿Puede que haya un error ahi?

Por lo que estuvimos analizando, para que la operacion de Procesar Inscripciones con Prioridades pueda volver a procesar una inscripcion rechazada, el campo estado_preinscripcion de la tabla sga_insc_cursada debe estar en 'P'

Es correcto, para que pueda ser procesada nuevamente, debe quedar en el estado inicial, que es el estado pendiente de procesar ([b]estado_preinscripcion = P[/b])

¿Podes detallarnos el caso?
Se procesó la inscripción con prioridades a un alumno, y quedo inscripto finalmente en alguna comision? No quedo inscripto en ninguna comisión?
Porque la situación de anulación de rechazo seria solo en el caso que el alumno no haya quedado inscripto en una comsion. ¿Este es el caso? ¿O quedó inscripto en una comisión de esa actividad?

Vamos a revisar el proceso completo: preinscripcion, procesamiento de las preinscripciones y anulación de las preinscripciones rechazadas.

Hola Emiliano!

Estuvimos reunidos con Ale haciendo pruebas del caso y analizando la situación.

Lo que notamos es que al momento de procesar las inscripciones con prioridades, si algún alumno no queda en ninguna de las comisiones disponibles por falta de cupo, sus inscripciones no se rechazan sino que siguen en estado pendiente de procesar. Por lo tanto no debería presentarse el problema que mencionan.

Ustedes cómo llegaron a tener estas inscripciones rechazadas? Las rechazaron manualmente?
O deshabilitaron los controles al momento de la inscripción y los habilitaron para el momento del procesamiento? (en este caso deberían modificar esto).

Sí notamos algunos ajustes necesarios en este circuito que ya estamos armando los tickets para incluirlos en una próxima versión. Estas mejoras serían las siguientes:

• En el Reporte de Inscripciones a Cursada indicar si es una inscripción por prioridad y qué número de prioridad tiene.

• En Procesar Inscripciones por Prioridad, en la sección final con los reportes agregar el registro de alumnos que no quedaron en ninguna comisión, con su respectivo botón de “Reporte” y un botón “Rechazar Inscripciones” (para aquellos casos en que sí quieran rechazar esas inscripciones).

• En Revertir Rechazo de Inscripciones a Actividades no mostrar inscripciones por prioridad si el alumno ya quedó inscripto en alguna. Pero si el alumno fue rechazado en todas, mostrar la comisión de prioridad 1. Al revertir el rechazo se revierte en todas las comisiones en las que estaba como pendiente. El estado y estado_preinscripcion debe quedar en P para poder ser procesada nuevamente.

Con estas mejoras el circuito debería quedar mucho mejor preparado para estos casos.

4

Hola Alejandro!

Te detallo la secuencia de prueba:

[ol]- Inscribimos alumnos a comisiones con prioridad

• Realizamos el procesamiento con prioridad
• Alumnos quedan rechazados por controles de correlativas. No quedan aceptados en ninguna comisión
• Deshabilitamos todos los controles con la idea de volver procesar y ver si estan funcionando nuestros criterios
• Revertimos los rechazos
• Procesamos nuevamente pero sin resultado (0 aceptados - 0 rechazados)[/ol]

Hola Martin! Exacto. Nuestros rechazos no fueron por cupo sino que para realizar estas pruebas deshabilitamos los controles al momento de la inscripción pero los dejamos activos en el procesamiento. Por eso no debería ocurrir que en producción sean rechazados por dicho motivo. De todas maneras nos pusimos a investigar el por qué no se podía revertir el rechazo.

Hola Emiliano!

Claro, es por ese motivo que se les rechazaron las inscripciones.
En la práctica no debería suceder ya que deberían tener los controles habilitados en el momento de la inscripción para así frenar el proceso en ese momento si el alumno no cumple con los requisitos.

De todas formas, con los tickets que armamos el inconveniente quedaría solucionado para una futura versión. De esta forma, si por algún motivo se rechazan las inscripciones al momento de procesarlas se va a poder revertir este rechazo y procesarlas nuevamente sin inconvenientes.
Si quieren pueden levantar un GDS haciendo referencia a este foro así les asociamos los tickets y les avisamos cuando estén listos.

Saludos!

Se continua via gds 62336

Hola Martin!
Vuelvo con este comentario porque aca en el equipo dabamos por contado ese comportamiento que describis pero al continuar las pruebas vimos que no es asi. En nuestro caso, al procesar las inscripciones con prioridades los alumnos sí son rechazados y con el motivo de rechazo 1- Comisión sin cupo disponible en la tabla sga_insc_cursada_log. Te recuerdo que nosotros estamos en la versión 3.20.1, ¿será que fue modificado en la 3.21?

Aclaro que el parámetro de sistema cur_controlar_cupo está [u}desactivado[/u] por NIVEL para la unidad academica en la que estamos probando.

Disculpá la insistencia pero es que las inscripciones arrancan la semana que viene y necesitamos tener este circuito listo y pulido.

Hola Emiliano!

Vamos a armar una instalación de 3.20.1 cerrada para hacer la prueba y les comentamos lo que veamos.

Hola Emiliano!

Por favor levanten un GDS por este tema y lo seguimos por allí.

Saludos!

3