[Solucionado] Inconveniente en vinculación de propuestas (CPU y Licenciatura)

Buen día a todxs,

En la Universidad, se nos presenta un inconveniente en la prueba que venimos realizando al vincular una propuesta de grado con un curso de ingreso.

Los pasos que hemos realizado hasta aquí son:
1.vincular plan-propuesta Licenciatura X con CPU (curso preparación universitaria compuesto con plan de 3 actividadeas/materias). Definimos que la inscripción se automática entre una propuesta y otra.
2. Luego agregamos el requisito de cumplimiento del 100% de la actividades en el curso de ingreso vinculado a la propuesta Licenciatura X.
3. A continuación, matriculamos a un alumno en la Licenciatura X (allí figuraba el requisito previo)

El caso es que, para hacer una experiencia concreta de la funcionalidad, probamos intentar matricular al alumno en una materia de la Licencatura, asumiendo que el sistema no nos lo iba a dejar hacer. Sin embargo, el alumno fue correctamente inscripto a la actividad, salteando el CPU, lo cual obviamente está mal.

¿Nos podrían orientar en qué cosas estamos haciendo mal?

Saludos cordiales y el agradecimiento anticipado a quién no dé una mano en el tema.
Javier.

pd. Versión Guarani 3.11.2

¿Como/donde agregaron el requisito de cumplimiento del 100% de las actividades del CPU?

¿La inscripcion en la Licenciatura quedo en estado Pendiente o Aceptada?

Si lo que debian controlar es que no permitiera inscribir a las actividades (al menos las de 1er año o las del comienzo de la Licenciatura) sino tiene cumplido el 100% de las actividades del CPU, entonces este requisito debio agregarse desde la carga de “correlativas” a esas actividades de la Licenciatura.

Buenas tardes Alejandro,

Lo hicimos desde » REQUISITOS » REQUISITOS DE INGRESO » DEFINIR REQUISITOS DE INGRESO

Que el alumno tenga alguna de las opciones de propuestas vinculadas aprobadas en un x%
Propuestas
Grado (Algunas)
Licenciatura en Estudios de la Comunicación (LESTC)

Sobre tu segunda pregunta,. tanto la Licenciatura , como la propuesta de curso de Ingreso se encuentran en estado: ACEPTADAS.

No asignamos ninnguna correlatividad, pensamos que vinculando la propuesta madre (Licenciatura) con la propuesta hijo (CPU/curso de ingreso) + esa regla o requisito, ya haría que el alumno se anotara a la carrera, se le antepusiera el curso de ingreso y solo si aprueba esas materias, pasa directo a la carrera.
Pero no debería dejar eque el oprador inscriba en una materia al alumno directamente en la carrera…

¿No es así?

Saludos y gracias por tu respuesta,
Javier.

Te consultaba donde a que le habias registrado ese requisito. En este caso como lo incluiste como un “requisito de ingreso a la licenciatura” entonces solo actúa o debería actuar alli, es decir que no debería dejarlo con la inscripción en la licenciatura en estado aceptada si es que no cumple con ese requisito porque como mencionas ese alumno aun no aprobó todas las actividades del CPU.

Que la inscripción en la Licenciatura este aceptada cuando aun el alumno no terminó el CPU, puede ser que el requisito de ingreso no lo hayan definido como requisito obligatorio. ¿Pueden verificar como esta definido?
Ya que es aqui (en el estado de la inscripción a propuesta - Aceptada/Pendiente) donde debería actuar ese requisito de cumplimiento de CPU que fue registrado como requisito de ingreso a la Licenciatura.

Diferente es el control para no permitir inscribir a la cursada de una actividad si no tiene el CPU completado. Para poder controlar esto deben agregar este requisito en cada una de las actividades que deseen que se controle este tema, que en principio pareciera ser las 1eras actividades del plan de estudio que el alumno puede realizar. Para este caso este requisito debe agregarse como correlativa de cursada en esas actividades.

¡Buen día Javier!, es como te comenta Alejandro. Si uds necesitan que el control se ejecute en dos instamcias, van a tener que configurarlo en ambas.
En este caso deberían agregar el requisito por acción Cursada y luego por Operación Inscripción a cursada
¡Avisanos por favor!
¡Saludos!

Buenas tardes Emilse y Alejandro,

Efectivamente, el problema radicaba en que no estaba puesta la opción “obligatorio” en el requisito de ingreso, es por eso que lo dejaba en ambas propuestas: CPU y licenciatura, como aceptadas. Ésto ya quedó resuelto, muchas gracias.

Entiendo lo que menciona Alejandro sobre armar correlatividades y resolverlo de esa forma, pero ¿No son demasiada vueltas? Entendía que vincular propuestas cubría de forma automática un curso de ingreso y la correspondiente carrera.
¿Qué diferencia tiene con armar un CPU como módulo dentro de una propuesta y luego diferenciar certificados?

En la Universidad tenemos múltiples CPU, por eso necesitamos encontrar algo que cubra todas las posibilidades de forma funcional y que no requiera de una personalización como la que tenemos actualmente en el G2.

Saludos y gracias nuevamente,
Javier.

Si Javier, en ese caso deberían ser dos configuraciones, requisito de ingreso obligatorio como te comentó Ale, y el requisito en la operación inscripción a cursada, para las propuestas que uds indiquen.
¡Saludos!

Perfecto, ahora entendí, no era poner requisitos en la actividades de la carrera (me parecía invendible a los operadores en cada Unidad Académica), era poner el mismo requisito “Que el alumno tenga alguna de las opciones de propuestas vinculadas aprobadas en un x%” pero a nivel de cursada, en este caso, a la propuesta formativa: licenciatura en comunicación .

Ahora, al querer inscribirlo en una actividad de la carrera, el sistema advierte que no puede continuar la inscripción porque el alumno no cumple la aprobación de CPU.

Muchas gracias por la ayuda.

Cordiales saludos, Javier.

Javier, cuanto te mencioné el caso de cargar el requisito de que tenga el CPU cumplido como correlativa, era porque de esa forma podrias solo ponerlo en las actividades de 1er año o las actividades que empiece a cursar el alumno cuando ingresa en la Licenciatura y que requiera que se evalue ese requisito.
El agregar el requisito en la acción “Inscripcion a Cursada”, esto hace que el requisito se evalue en cualquier inscripción a cursada, sea una actividad de 1er año, 2do, … 5to.
No esta mal definirlo asi, solo que de esta forma se estaría controlando este requisito en casos que pareciera que no tendria sentido controlarlo. Por ejemplo si una actividad de 1er año (Ingles I) es correlativa de una actividad de 2do año (Ingles II) no tendria sentido evaluar ese requisito de CPU cumplido para Ingles II, ya que se supone que el alumno debio aprobar Ingles I y es en esta actividad que ya se evaluó ese requisito.

Resumiendo: definirlo de las dos formas esta bien, solo que uno sería mas óptimo (y mas trabajoso para su definición) que el otro.

Entendido Alejandro, como mencionaba en el hilo inicial, hay diferentes casos de ingreso en la Universidad, por lo tanto, iremos haciendo pruebas ante cada situación. Lo importante es evaluar las alternativas y plasmar en el sistema lo que resulte más prolijo en termino de datos.
Nuevamente gracias!
Javier.