Hola,

Logramos reproducir el error: el problema se produce cuando vuelven al form de búsqueda con el botón del navegador en lugar del botón "Volver" de toba.
Muchos usuarios tienen presente que siempre deben usar ese botón pero algunos, no tanto. Siempre fue un problema ese comportamiento de toba.
Entiendo que es algo muy del core, pero habría que revisar esta cuestión, puede traer problemas serios.

Saludos!

Buenas, me sumo en este tema ya que nos han reportado una situación muy similar y tampoco lo pudimos reproducir. Por lo que nos cuentan los usuarios, sucede cuando consultan una ficha y luego otra, como si cacheara los datos de la primera consulta. Sucede tanto en la sección de historia académica de la ficha de la persona, como en el pdf que exporta.
El usuario que consulta solo tiene acceso a la operación ficha de la persona.

Ya verificamos la tabla sga_equiv_otorgada y de hecho estamos trabajando en un script sobre el modelo para eliminar las equivalencias que se otorgaron de forma errónea, rastreando en base a esta tabla para determinar la propuesta y actividad de origen que figuran en la matriz y grupo. Si la propuesta que figura en la matriz no coincide con la propuesta donde aprobó la actividad, es una equivalencia mal otorgada.

El asunto es lo que te comentaba antes y que charlamos en reuniones previas a la migración: la idea de hacer esto surge de la necesidad de separar materias (ej. 80003) que en G2 no era un problema por estar configurado para que mismo código no sea equivalente entre propuestas. El mecanismos que entendíamos podía resolver la situación era crear nuevas versiones de los planes donde la materia original no estuviese y se crearan nuevas materias específicas de cada propuesta. Para los alumnos que no hubiesen acreditado la materia era una solución limpia pero para aquellos que ya la hubiesen acreditado, no, porque al no estar en la nueva versión la perderían. Ahí entran las matrices entre versiones para acreditar esas materias de modo tal que quien hizo la 80003 en Música (aprobada por esta propuesta) tuviese la equivalencia de la 8003C y no la de la 8003N.

Entiendo todo lo que me decís que al tener aprobada la 80003 es transparente para ambas propuestas y de hecho es nos dimos cuenta que sucede desde que nos encontramos con el problema y luego verificamos en el código. El asunto es que entendíamos que la solución que te comentaba antes, debía funcionar porque al ser una matriz entre versiones con un origen bien definido, lo iba a respetar.

No logro ver la imágen adjuntada, pero la forma de correr la operación "Procesar matrices de equivalencia" es procesar matrices entre versiones, no sé si consultabas por otro parámetro.

Hola Alejandro

Siguiendo el ejemplo, aprueba 80003 por G1 v1 y pasado de versión, le termina acreditando

- 8003C en G1 v2
- 8003N en W v2

Hola, estamos trabajando en la implementación de regularidad y nos surgieron varias dudas respecto al funcionamiento de las operaciones de guaraní.
En el caso de la operación "Administrar readmisiones" no sabemos a qué corresponde vencimiento de readmisión (obligatorio).
Por otro lado en la operación "verificar regularidad" no sabemos tampoco a qué corresponde el parámetro "Vencimiento de readmisiones automaticas".