Buenos días.
Tenemos alumnos que fueron informados como no regulares el año pasado, su tràmite fue dado de baja y este año recuperaron su regularidad.
Veo que las funciones que ejecuta el benefit-update están preparadas (parcialmente) para enviar también las altas, pero en el llamado a la función el parámetro sólo bajas viene siempre en true.
Las altas las hace el alumno a través del 3W, ya hay una personalización en el COLAB donde el alumno puede solicitar el beneficio a través de la operación “Tramites => Boleto Estudiantil”.
También esta el Web Service que SUBE invoca cuando rechaza una solicitud.
Hola !!
Cuando el alumno ingresa a solicitarlo nuevamente le figura “Trámite ya solicitado” al consultar $tiene_solicitud = $this->modelo()->info__tiene_solicitud();, le trae la solicitud anterior aceptada
El alumno lo tenía y fue dado de baja por no cumplir con la regularidad el año pasado y ahora vuelve a ser regular.
Hola, por ahora lo vas a tener que arreglar por base de datos!!!
Fíjate que tenes la tabla mbe_solicitudes. Para solo estos alumnos que me comentas les podes cambiar los valores de las columnas procesado, respuesta y operacion para que puedan volver a solicitar el beneficio, te paso como quedaría la query:
UPDATE mbe_solicitudes
SET procesado = 'S',
respuesta = 'RECHAZADA',
respuesta_desc = 'TRAMITE_EXPIRADO',
operacion = 'A'
WHERE persona IN (1, 2, 3, 4);
Donde 1, 2, 3, 4 son los IDs de personas (tabla mdp_personas) de los alumnos en cuestión.
por eso, luego de hacer el update que me dijiste, cuando ingresa a 3W y pone Iniciar Trámite le arroja ese mensaje: Aviso. Ya tiene el beneficio asignado, pero el mismo se encuentra deshabilitado., te dejo un print.
Gracias!
Hola, va a estar solucionado para nuevas versiones?
Porque nosotros tenemos estudiantes en la misma situacion, le sale el mismo mensaje que ya tiene asignado el beneficio pero se encuentra deshabilitado.
Estamos en la version 3.16.1
La documentación dice hacer un svn export, y NO un svn checkout. Si bien se puede colaborar (por eso se llama “contrib”), veo que estan subiendo credenciales y cambios propios de la universidad.
Hola Leonel, recién veo lo que comentás de Laura, seguramente se trató de un error.
Ustedes podrán eliminarlo para que no sigan expuestas las credenciales?
Ustedes podrán eliminarlo para que no sigan expuestas las credenciales?
Ya deshice los cambios, el problema es que en el historial de commits queda el cambio y no se puede borrar.
Les recomiendo cambiar la contraseña del servicio de SUBE (la que configuran en la constante WS_PASS de src/pers/boleto_estudiantil/modelo/transacciones/boleto_estudiantil.php).
Hola, hay novedades sobre esto? Estamos recibiendo el mismo error cuando los alumnos intentan solicitar el beneficio luego de haberlo perdido por regularidad.
Verificamos que en el comando ‘pro_solicitudes_sube’ solo procesa las bajas de regularidad en los alumnos, pero no genera las nuevas altas para alumnos que la habian perdido.
¿Cual es la solucion? Modificamos el comando de procesar, para que contemple bajas y altas por igual?
Al procesar las solicitudes del boleto, la funcion guarani_modelo->verificar_beneficio($persona), devuelve 0 (cumple) o -1 (no cumple).
Sin embargo, cuando se analiza reactivar una Baja, el procesar revisa si la verificacion devuelve >0, cosa que no ocurre nunca.
Además el Insert para reactivar la Baja tiene faltante el campo Persona, necesario para insertar en la tabla de solicitudes.
De que manera esta contemplado que se reactiven las Bajas del beneficio? Ya que el formulario de Autogestion no deja volver a pedirlo; y el comando procesar solicitudes no contempla reactivar los estados de Baja.
Hola buenas! Tienen alguna resolución de este inconveniente para la versión 3.20.0 porque a nosotros nos pasa igual. Para los alumnos que recuperaron regularidad, a la hora de hacer una nueva petición les sale:
Aviso. Ya tiene el beneficio asignado, pero el mismo se encuentra deshabilitado.
El ws está funcionando correctamente ya que las solicitudes que expiran por tiempo las resuelve de manera correcta.