[tc]-recibos en lote con sucursal cero y sin usur que carga

INFORME DE PRUEBA
Usuario Quality: Ing. Miliris Rincón
“BUG O CAMBIO DE FUNCIONALIDAD”
TAREA 7019: [T.C]-RECIBOS EN LOTE CON SUCURSAL CERO Y SIN USUR QUE
CARGA
DESARROLLADOR: Ing. Elvis Olivar
REQUERIMIENTO
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
órdenes de desconexión por SMS está 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 órdenes 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 órdenes de morosidad del abonado.
FALLA REPORTADA
El proceso de la finalización de órdenes de desconexión por SMS está ocasionando
algunas de estas inconsistencias, ya que, se están generando lotes con sucursal en cero,
generalmente con origen de cobranza 16 – Depósitos en Garantía. Los recibos no tienen
usuario de generación ni sucursal.
DESCRIPCIÓN DE FUNCIONALIDAD
Se modificó 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 órdenes de morosidad del abonado correctamente generando
los recibos correspondiente con usuario y sucursal asociado.
1.-Notas del Desarrollador.
Los cambios se realizaron en GxEv1, consumiendo un webservice hecho en
GxEv2 para finalizar las órdenes de desconexión por morosidad por sms.
Al momento de hacer la liberación, se debe consumir el webservice con la
siguiente URL:
http://appweb2.inter.com.ve:8080/GxVisionX_K2BToolsJavaEnvironment/servlet/afi
nalizarordenmorosidad?wsdl
2.- Notas de Configuración.
2.1.- Querys
No tiene Query
2.2.- Creación de Opciones y Menús
No tiene Opciones y Menús de inicialización
2.3.- Configuraciones Iniciales
No tiene configuraciones iniciales.
2.4.- Versiones de Navegador y Java
Navegador: Mozilla
Versión de Java: Java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
PRUEBAS REALIZADAS
 Finalización de orden por Xalala
Se ingresó a la siguiente ruta: GxVision Integrado  Técnica  Administración Técnica
Trabajar con órdenes
Se tiene el abonado 125890 que posee un depósito en garantía y dos facturas impagas
Al mismo se le aplica el proceso de desconexión por morosidad quedando moroso en los
tres (3) servicios
Se verifica que el abonado queda en estatus desconectado en todos sus servicios
Se emite la orden de equipo que se encuentra en status Pendiente
Se verifica que se ha generado el código en la tabla Xalord
Select * from xalord where percod=1 and xalordabocod=125890
Se utilizó el simulador de Xalala para finalizar las órdenes vía SMS, en el cual se debe
ingresar el código seguido del código del técnico y del operario
Se visualiza el recibo que es generado con forma de pago depósito en garantía luego de
finalizar todas las órdenes de desconexión por morosidad, donde se confirma que guarda
usuario y sucursal
Se verifica que desde Win tambien se visualize la sucursal de lote
 Validaciones
El sistema valida que se ingrese la cantidad correcta de parámetros
El sistema valida que el técnico ingresado corresponda al asociado a las ordenes del
abonado
APROBADA EN BETA 