Inconsistencias en el circuito de boleto SUBE - version 3.20.x

Buenas tardes,

Me comunico para consultar algunas inconsistencias y modo de procedimiento para distintas situaciones particulares en la solicitud del Boleto.
Tenemos toda la aplicacion instalada y configurada correctamente. Ya la venimos utilizando desde el año pasado, y con los comandos para procesar y notificar croneados. En general funciona bien, pero encontramos 3 situaciones de error:

  1. Tenemos alumnos nuevos, provenientes de otras universidades en donde solicitaron el beneficio. Por un lado no tienen la opcion para dar de baja su solicitud voluntariamente, pero además, la institucion le generó la baja manualmente. Esto hizo que quede deshabilitado el beneficio, y cuando quiere solicitarla desde nuestra institucion por autogestion, el sistema le responde que ya tiene asignado y deshabilitado el beneficio. En nuestro sistema no presenta historial del beneficio, por lo que manualmente intentamos reactivar su beneficio, pero el sistema responde “student not found”. Contactamos al ministerio por este error y estamos esperando respuesta. ¿Cual seria el procedimiento correcto en este caso?

  2. En relacion a la situacion anterior, tenemos inconveniente al dar de baja la solicitud de un alumno que decide irse a otra institucion. Es decir, el alumno solicita la baja del beneficio aun siendo activo y regular, lo realizamos correctamente, pero luego los comandos de reactivacion corren automaticamente, y volveria a reactivar al alumno. ¿Como esta cotemplada esta situacion? ¿existe un estado de la base para no dejarlo en Baja, y asignarlo por ejemplo en ‘Finalizado’? Entonces de esa forma quedaria cerrado definitivamente, sin reactivarse, y el alumno deberia volver a solicitar por autogestion una nueva alta.

  3. ¿Es posible ofrecer desde el tramite de Autogestion, poder la baja /finalizacion de la solicitud voluntaria por parte del alumno? De esta manera, simplificaria el proceso en el cambio de instituciones por parte de los alumnos, prescindir del trabajo manual desde la base de datos, y ofrecer una operacion mas transparente y rapida para el alumno que generó el alta poder finalizar el beneficio hasta una nueva alta.

Saludos.

Ir a la issue.

Hola Gabriel,

Tenes razón, no están contemplados esos casos, lo vamos a analizar para una versión futura.

Te adjunto el documento de los Web Services de e-gate para Boleto Estudiantil, no veo que exista forma de dar de baja el beneficio, si permite deshabilitarlo pero esto hace que luego no lo puedas volver a pedir.

Si te fijas desde la versión 3.21.0 de SIU-Guaraní contas con una colección de Postman para Boleto Estudiantil, podes ver los request en este otro foro. Ocurre lo siguiente:

Pedís el beneficio por primera vez con benefit-request:


{"status":201,"data":{"redirect-url":"http:\/\/test.boletoestudiantil.gba.gob.ar\/0b50558411e66bc1d66f3643c57f1725fe838406_5bde051fff6508b513dbc882664cd2492ef9001e","tid":"T204569881683117127","in_progress":"0"}}

Te devuelve la URL para completar el formulario.

Si lo volves a pedir con benefit-request te devuelve que “el proceso ya ha sido completado”, ya que he completado dicho formulario:

{"status":409,"message":"The process has already been completed"}

Si lo deshabilito con benefit-update devuelve OK:

{"results":[{"code":"200","message":"Ok","request_id":"7","tid":"T204569871683116239"}]}

Pero cuando lo vuelvo a pedir con benefit-request reconoce que existe y esta deshabilitado:

{"status":423,"message":"Benefit disabled"}

Vamos a tener que analizarlo también con el Ministerio de Infraestructura y Servicios Públicos de la Provincia de Buenos Aires.

saludos.
2


BoletoEstudiantil.pdf (219 KB)

Hola buenas! Quería hacer una consulta al respecto del punto 2 que mencionaba el compañero:

  1. En relacion a la situacion anterior, tenemos inconveniente al dar de baja la solicitud de un alumno que decide irse a otra institucion. Es decir, el alumno solicita la baja del beneficio aun siendo activo y regular, lo realizamos correctamente, pero luego los comandos de reactivacion corren automaticamente, y volveria a reactivar al alumno. ¿Como esta cotemplada esta situacion? ¿existe un estado de la base para no dejarlo en Baja, y asignarlo por ejemplo en ‘Finalizado’? Entonces de esa forma quedaria cerrado definitivamente, sin reactivarse, y el alumno deberia volver a solicitar por autogestion una nueva alta.

Estamos teniendo el mismo inconveniente y queríamos consultarle si ya hay alguna forma de poder darle la baja definitiva a la solicitud del boleto del estudiante desde nuestra institución. Nosotros estamos en 3.21.0, pensamos que quizás una posibilidad es ponerlos pasivos en la propuesta o insertar algún registro en mbe_solicitudes que nos permita hacer la baja.
Leí varios hilos del foro pero no encuentro solución.

Desde ya muchas gracias.
Saludos! Florencia.

Hola @mfayala

Cuando se ejecuta el comando bin/guarani pro_solicitudes_sube se llama la función verificar_beneficio de php/nucleo/boleto_estudiantil/boleto_estudiantil_nucleo.php que se puede personalizar en personalizacion/php/nucleo/boleto_estudiantil/boleto_estudiantil.php, la misma por ahora se fija que el alumno sea activo y regular en al menos una propuesta. Podes personalizar a tu gusto, es mas, podes personalizar verificar_beneficio de php/nucleo/boleto_estudiantil/co_boleto_estudiantil.php y modificar la query.

SUBE no tiene un Web Service para dar de baja (borrar) un beneficio, solo te permite habilitarlo y deshabilitarlo.

$cumple_condiciones_beneficio = boleto_estudiantil::verificar_beneficio($solicitud['persona']);

Si $cumple_condiciones_beneficio = true lo mantiene, si $cumple_condiciones_beneficio = false lo pierde.

Saludos.