RECIBOS EN LOTE CON SUCURSAL CERO Y SIN USUARIO QUE

Coordinación de Requerimientos
Tarea 7019: “[T.C] - RECIBOS EN LOTE CON
SUCURSAL CERO Y SIN USUARIO QUE CARGA”
Solicitado por: Sistemas Nacionales
Fecha: 16-12-2014
ESPECIFICACIONES DE LA TAREA:
Se reportó bajo el caso 4411 - RECIBOS EN LOTE CON SUCURSAL CERO Y SIN
USUARIO QUE CARGA, lo siguiente:
Se solicita revisar el siguiente caso ya que al parecer algún proceso de la finalización de
ordenes de desconexión por SMS están ocasionando algunas de estas inconsistencias.
Se están generando lotes con sucursal en cero, generalmente con origen de cobranza 16
– Depósitos en Garantía. Al revisar a fondo los recibos se puede observar que los mismos
son generados producto de la finalización de órdenes de desconexión por morosidad por
SMS. Algunos de los recibos ni siquiera tienen usuario que lo genera por lo que presumo
que a raíz de ahí no se logra calcular la sucursal que le corresponde, pero hay otros que a
pesar de tener usuario que genera también queda con sucursal cero.
Anexo algunos ejemplos:
1.- Recibo sin Usuario y en lote con sucursal cero:
2.- Recibo con usuario pero en un lote con sucursal cero.
Les pedimos verificar las razones por las cuales está sucediendo esto, ya que todos los
recibos deben quedar con su respectivo usuario y en la sucursal correcta a nivel de los
lotes. Posiblemente, sea una configuración errada de algunos usuarios-técnicosoperarios, pero necesitamos nos ayuden a indagar cuál pueda ser esa configuración que
hace falta o esta errada.
Anexo también, un ejemplo de cómo queda el lote. Se puede observar por la Win, ya que
por K2B no muestra los lotes con estas características cuando si debería hacerlo, ya que
es la herramienta con la cual cuentan los administradores de sistemas y tesoreros para
determinar los problemas.
En cierre del caso de parte de Dpto. de Desarrollo se concluyó lo siguiente:
Los recibos no tienen usuario de generación ni sucursal. Descubrimos que prácticamente
el 99% de los casos son recibos de devolución de depósitos en garantía que se generaron
por una finalización de orden. Todas estas ordenes son finalizadas por SMS.
Se necesita una tarea que modifique el procedimiento "ProcesarEnvioSMSTedexis2" que
es llamado por el webservice EnvioSMSTedexis, de modo tal que al finalizar la orden
llame a un nuevo webservices hecho en EV2 que evalúe los errores al finalizar la orden y
devuelve el error si lo hay y si no finalice las ordenes de morosidad del abonado.