open cobros - manual de soporte v2.1

3

Open Cobros - Manual de soporte

Open CobrosManual de soporte

Descripción de las acciones a realizar para asegurar el correcto mantenimiento del aplicativo Open Cobros.

3


CONTROL DE CAMBIOS DEL DOCUMENTO

Versión Motivo del Cambio Responsable Fecha

1.1

Se incluye apartado para “Informe de Disponibilidad de ficheros” y se documenta error surgido en la generación del mismo.

everis

04/12/2012

1.2Decomisión SMS´S certificados por el Proyecto Notifica Experian.

everis20/12/2012

1.3Se incluye el proceso de Venta de Deuda

everis 27/12/2012

1.4 Se incluye el proceso de marcado de incobrables

everis 27/12/2012

1.5 Se incluye Contingencia Devoluciones Erróneas

Everis 14/01/2013

1.6Fallo FTP CBCCAM110 Fichero de control a ACCON

Everis 17/01/2013

1.7Rectificar factura importe 0 (Tiermansa)

Everis 17/01/2013

1.8 Informe preliminar Everis 25/01/2012

3


Versión Motivo del Cambio Responsable Fecha

1.9 Revision de checksum Everis 06/02/2013

2.0 Revision de Hotlines Everis 01/04/2013

2.1

Se añade en la revisión del bancario que se revisen el numero de operaciones para los ficheros descargados desde editran

Everis 18/06/2013

3


PLANIFICACIÓN DIARIA

ITEM Ventana HORAL M X J V S D

PROCESOS OPERATIVA DIARIA Si el batch nocturno de bancario no ha recogido algún archivo requerido TIVOLI lanzará una alarma a las 7:15. Al menos la carga de transferencias deberá estar hecha antes de que empiecen a trabajar las plataformas a las 8:00. Si no lo están abrirán una incidencia masiva.

RECOGIDA Y CARGA MANUAL DE TRANSFERENCIAS DE UNICAJA

A diferencia del resto de entidades bancarias, Unicaja sí envía transferencias los Lunes. Sin embargo, el proceso bancario nocturno no las recogerá. Se deben recoger por EDItran a partir de las 7:15, y su carga deberá estar hecha antes de que empiecen a trabajar las plataformas a las 8:00.

RECOGIDA MANUAL DE DEVOLUCIONES DE LA CAIXA

La Caixa incumple de forma sistemática los SLAs establecidos entre Orange / Bancos para la generación de los ficheros de devoluciones. El fichero de devoluciones lo suelen dejar para su recogida sobre las 04:00-06:00 de la mañana, por lo que habrá que recogerlo a diario, salvo los lunes. El viernes habrá, además, que renombrarlo como TRI. Recoger por EDItran a partir de las 8:00.

INFORME DIARIO DE LA OPERATIVA DE MANTENIMIENTO DEL MÓVIL

En su caso, después de recoger y cargar los ficheros de forma manual y de realizar la revisión de Hotlines, se envía el Informe Diario de la Operativa de Mantenimiento del móvil.Enviar información entre 8:30 y 9:00.

PROCESOS OPERATIVA DIARIA PROCESOS OPERATIVA DIARIA

La publicación de HLs comienza en ventana de 6:00 a 9:00 con cadencia de 120 eventos por minuto, y suele estar finalizado antes de las 8:00.Iniciar la revisión aprox. a las 8:00, después de la hora de fin de ejecución de la publicación de HLs.Enviar información a las 8:30

INFORME DE REINTENTOS Se envían dos informes diarios desde el buzón ES/C/AUNA/AUNA//Sop. al Proceso. Facturacion 3 [[email protected]], el primero en torno a las 9:00-9.30 de la mañana y el segundo a las 23:00-23:30 de la noche.

REVISIÓN DE HOTLINES, CALLBARRING O REACTIVACIONES TRAS SUPERAR NÚMERO MÁXIMO DE REINTENTOS

El reintento de publicación comienza a las 9:00 sobre aquellos eventos de publicación de HotLines, CallBarring o Reactivaciones que se saldaron con error. Se reintenta su envío tres veces.Se validará aprox. 10:00 si existen publicaciones que hayan superado los 3 reintentos y cuyo error no sea filtrable (“cliente sin contratos activos”).Abrir TK remedy a continuación.

COMUNICACIÓN DE CARTAS GENERADAS DE OPENCOBROS A DOC1 Y A LAS UNIDADES DE NEGOCIO

Iniciar la revisión a las 8:30.Enviar la información a las 9:00Abrir TKs Remedy para cartas de OMVs a lo largo de la mañana.Informar de las TK remedy para cartas de OMVs a lo largo de la mañana.Los lunes se deben enviar las cartas del Sábado y Domingo.

3


PROCESOS OPERATIVA DIARIA

REVISIÓN Y RECOGIDA MANUAL DE FICHEROS DE LOS BANCOS POR EDITRAN

El batch de bancario se ejecuta diariamente y carga los pagos (transferencias y ventanillas) y devoluciones tratadas por los bancos el día anterior. El domingo no se lanza el batch y el lunes se ejecuta dos veces, para los pagos y devoluciones del sábado y el domingo.

El proceso de bancario realiza de forma automática dos recogidas de EDITRAN, la primera a la 1:00 y, en caso de que la revisión de ficheros pendientes que se ejecuta a las 2:00 determine que existe alguno que no ha llegado, una segunda a las 2:01.

La siguiente tabla almacena las entidades y los archivos susceptibles de ser recuperados (nombre de sesión y patrones):

BANCO TRANSFERENCIAS (N43)

VENTANILLAS(N57)

DEVOLUCIONES(N19)

SCH (0049)

000049CSB043E.HT.

(sólo sobre recibos)M-S

000049VENTANE.HTM-S

000049DEVOLUE.HT

L-V

BBVA (0183)

000182TRANSF TL.

(sólo sobre recibos)M-S

Existen sesiones de ventanillas en EDItran, pero no se usan. Los archivos llegan vacíos, se

tratan y no se carga nada.000182VENTAN

TL. (ventanillas BBVA)002038VENTAN

E8536 (ventanillas CM)

000182DEVOLUTLL-V

CAJA MADRID(2038)

002038TRANSF E8536TRANSF01

(sólo sobre recibos y recibos de grandes cuentas)

M-S

002038DEVOLUE8536DE

L-V

BANESTO(0030)

000030DEVOLUEXP1.

L-VLA CAIXA (2100)

La Caixa no envía devoluciones hasta las 4:00, por lo que no existe recogida automática. Se

recoge el fichero de forma manual y la carga se realiza en el bancario nocturno del día siguiente, excepto el lunes, cuando se realiza la carga del

fichero del viernes con las operaciones del jueves, que sí existe en el sistema.

002100DEVOLU ITR.L-V

Los martes, miércoles, jueves y viernes la recogida es manual

UNICAJA (2103)

002103TRANSFDP.OB

(sólo sobre Pagos Anticipados de residencial y de empresa)

L-SEnvía transferencias los Lunes. Se recogen

y cargan manualmente

002103DEVOLUDP.OB

L-V

Las alarmas planificadas en el sistema vinculadas con la ausencia de archivos enviados por los bancos se reflejan en la siguiente tabla:

HORA CAUSA ACCIÓN

3


SMSBATCH

2:01 Si alguno de los ficheros recibidos de los bancos viene vacío (0kb)

n/a

2:01 Si no se recibe alguno de los ficheros de los bancos n/a

ALERTATIVOLI

7:15 Si no se ha recibido algún fichero de los bancos Recogida manual y carga de los ficheros ausentes

Error Control-M

-- Error en cadena del bancario 24x7

Son numerosas las ocasiones en que las entidades financieras no envían los archivos, por lo que será necesario validar todos los días que se han recibido los ficheros y tratadas las cargas.

Las carpetas para validar la información son las siguientes:

Las ventanillas, devoluciones y transferencias recogidas de forma manual o planificada desde EDItran se almacenan, por configuración de las sesiones de EDItran, en las siguientes carpetas de Opencobros:

/openp1/opencobp/editran se almacenan ventanillas, devoluciones y transferencias de forma centralizada.

1) Ventanillas:/openp1/opencobp/storage/ventanillaEn condiciones normales de MARTES a SABADO existirán 3 ficheros para el día en curso de los que únicamente el fichero de SCH (E.HT) tendrá contenido. Por ejemplo:

Si no existiese el fichero del SCH (E.HT…) deberíamos recuperarlo obligatoriamente de forma manual. Si los que no existen son cualquiera de los otros dos, no nos preocupamos.

2) Devoluciones/openp1/opencobp/storage/devolucionesEn condiciones normales los LUNES existirán 6 ficheros. Por ejemplo:

Si no existiese alguno de los ficheros deberíamos recuperarlo obligatoriamente de forma manual.

El resto de días (Martes - Viernes) existirán sólo 5 ficheros, pues el fichero de devoluciones de La Caixa sólo se recoge de forma automática los LUNES. En el siguiente ejemplo vemos cómo la obtención del fichero de devoluciones de La Caixa se ha producido de forma manual a una hora posterior (y se carga en el sistema a día vencido):

3) Transferencias/openp1/opencobp/storage/transferenciaLos LUNES sólo envía transferencias UNICAJA, pero no se recoge automáticamente, por lo que su recogida y carga se realiza de forma manual a las 7:30. Por ejemplo:

En condiciones normales el resto de días existirán 4 ficheros. Por ejemplo:

3


Una vez tratadas las ventanillas, devoluciones y transferencias por sus procesos correspondientes, ya sean planificados o manuales, se trasladan de forma automática a las siguientes carpetas:

1) Ventanillas:/openp1/opencobp/storage/bancos/recibido/ventanillaPor ejemplo:

2) Devoluciones:/openp1/opencobp/storage/bancos/recibido/devoluciones

El lunes existirán 7 ficheros. Se dará traslado también al fichero de devoluciones de La Caixa renombrado como TRI. el viernes para su tratamiento el lunes. Por ejemplo:

El martes, como no hay carga de La Caixa, sólo existirán 5 ficheros. Por ejemplo:

En condiciones normales (Miércoles - Viernes) existirán 6 ficheros para el día en curso. Por ejemplo:

3) Transferencias/openp1/opencobp/storage/bancos/recibido/transferenciaLos LUNES sólo existirá un fichero después de la carga manual de transferencias de UNICAJA en torno a las 7:30. Por ejemplo:

En condiciones normales el resto de días existirán 5 ficheros. Por ejemplo:

Debemos tener en cuenta los siguientes aspectos:- Los procesos no cargarán transferencias, devoluciones y ventanillas aunque existan en las carpetas

centralizadas si ya se encuentran en las carpetas “storage/bancos/recibido”.- Los archivos se historifican los viernes (archivos .cpio), y se almacenan en las rutas:

3


/openp1/opencobp/bck/ventanilla Ventanillas/openp1/opencobp/bck/devoluciones Devoluciones/openp1/opencobp/bck/transferencia Transferencias/openp1/opencobp/bck/bancos/recibido/ventanilla Ventanillas/openp1/opencobp/bck/bancos/recibido/devoluciones Devoluciones/openp1/opencobp/bck/bancos/recibido/transferencia Transferencias

En caso de que no hayan llegado ficheros que se esperan recibir de forma automática o de que existan recogidas planificadas de ficheros, accederemos a EDItran para realizar la recogida manual de ficheros.

Las tareas que realizaremos serán:

- Conectarnos a la máquina de EDItran con el usuario y contraseña correctos.- Acceder al directorio /ora_data3/editran/SOURCE.- Ejecutar menup. La pantalla será similar a la siguiente:

- Marcar la opción 1 “1.- OPERADOR”. Esto nos permitirá acceder al siguiente menú:

- Seleccionar la opción 2 “2.- PETICIÓN DE CONEXIÓN”.

3


Esta acción es necesaria para cualquier acción que ejecutemos contra EDItran. En el caso de la recogida de ficheros indicaremos además la sesión contra la que nos queremos conectar, que será alguna de las recogidas en el cuadro de la sección siguiente:

Para cargar transferencias lanzaremos desde /openp1/opencobp/Lanzador_Root

nohup LanzaTransferencias_una.sh &

3


Env / Recp

AUTO / Manual

COMPONENTE Y MÓDULO Ubicación ficheros envío

Sesión Formato archivo

Descripción

Transferencias (/ora_data3/editran/REC_COBROS/transferencia.ini)

RECP

AUTO.En caso de error recogida manual

EDITRAN/ora_data3/editran/REC_COBROS/

COBROS1P – BANCARIO/openp1/opencobp/opensgc/secuencial/enio_sms/exec

EL proceso lo deja aquí /openp1/opencobp/editran/transferencias lo trata y lo envía a /openp1/opencobp/storage/transferecias

000049CSB043 E.HT Transferencias SCH000182TRANSF TL Transferencias BBVA002038TRANSF E8536TRANSF0

1Transferencias Caja Madrid

002103TRANSF DP.OB Transferencias Unicaja

Ventanillas (/ora_data3/editran/REC_COBROS/ventanilla.ini)

RECP


Idem. Transferencias EL proceso lo deja aquí /openp1/opencobp/editran/ventanillas lo trata y lo envía a /openp1/opencobp/storage/ventanillas

000049VENTAN E.HT Ventanillas SCH000182VENTAN TL Ventanillas BBVA002038VENTAN E8536 Ventanillas Caja Madrid

Devoluciones (/ora_data3/editran/REC_COBROS/devolucion.ini)

RECP


Idem. Transferencias EL proceso lo deja aquí /openp1/opencobp/editran/devolucion lo trata y lo envía a /openp1/opencobp/storage/devoluciones

000049DEVOLU E.HT Devoluciones SCH000182DEVOLU TL Devoluciones BBVA002038DEVOLU E8536DEVOLU0

1Devoluciones Caja Madrid

000030DEVOLU EXP1 Devoluciones Banesto002100DEVOLU ITR Devoluciones La Caixa002103DEVOLU DP.OB Devoluciones Unicaja

Envío de Oks a la recepción de devoluciones (/ora_data3/editran/REC_COBROS/okdevolucion.ini)

3


ENV

AUTO.Caso de error

nunca se ha dado.

COBROS1P - BANCARIO 000049DEVOLU 01001 Envío de OK a recepción de devoluciones de SCH000182DEVOLU 01005 Envío de OK a recepción de devoluciones de BBVA002038DEVOLU 01004 Envío de OK a recepción de devoluciones de Caja Madrid000030DEVOLU 01009 Envío de OK a recepción de devoluciones de Banesto002100DEVOLU 01006 Envío de OK a recepción de devoluciones de La Caixa002103DEVOLU 01010 Envío de OK a recepción de devoluciones de Unicaja

Remesas de móvil (/ora_data3/editran/REC_COBROS/remesas.ini)

ENV

Petición a CONTROL-M.

En caso de error reintento manual.

COBROS1P - REMESADOEnv_Cobros.sh NP remesas

000049REMESA 01001 Remesas de móvil SCH002038REMESA 01004 Remesas de móvil Caja Madrid000030REMESA 01005 Remesas de móvil Banesto000182REMESA 01009 Remesas de móvil BBVA002100REMESA 01006 Remesas de móvil La Caixa 002103REMESA 01010 Remesas de móvil Unicaja

Recepción de Oks a la recepción de remesas (/ora_data3/editran/REC_COBROS/okremesa.ini)

RECP

AUTO. La cadena de envío valida la recepción de OK

dos horas después del lanzamiento.En caso de error recogida manual

COBROS1P – REMESADORec_Cobros.sh NP okremesa

000049REMESA E Recepción de OKs a recepción de remesas de SCH002038REMESA E8536 Recepción de OKs a recepción de remesas de Caja Madrid000030REMESA EXP. Recepción de OKs a recepción de remesas de Banesto000182REMESA TL. Recepción de OKs a recepción de remesas de BBVA002100REMESA ITR Recepción de OKs a recepción de remesas de La Caixa002103REMESA DP.OB Recepción de OKs a recepción de remesas de Unicaja

Remesas de fijo (/ora_data3/editran/REC_COBROS/ORANRE.ini)IMPORTANTE: El archivo hay que prepararlo para el envío. Mensualmente se realiza un envío del fijo empresa/residencial y se descomentan las líneas de Banesto/BSCH/BBVA. Cuando se envía ALPI o TELECOR se comentan el resto de líneas y se descomenta la línea de la remesa que se vaya a enviar. Los colores abajo indican agrupaciones de envíos.

ENV

MANUAL EDITRAN/ora_data3/editran/REC_COBROS/

Env_FIJO.sh ORANRE

0030ORANRE E Remesas de fijo Banesto0049ORANRE E Remesas de fijo BSCH0182ORANRE E Remesas de fijo BBVA2013ORANRE E Remesas de fijo ALPI Caixa Cataluña8600ORANRE E Remesas de fijo TELECOR

Devoluciones de fijo (/ora_data3/editran/REC_COBROS/ORANDE.ini)IMPORTANTE: El archivo hay que prepararlo para la recepción.A diferencia de las sesiones de envío no existe sesión de devolución para fijo de TELECOR.

RECP AUTO (L-V 8:15). EDITRAN 0030ORANDE EXP1 Devoluciones de fijo de Banesto

3


En caso de error recogida manual

/ora_data3/editran/REC_COBROS/OPEN_FIJO_24H_PROC_001_Recogida_Devoluciones_FIJO

ejecuta proceso Rec_FIJO.sh ORANDE

0049ORANDE E.HT Devoluciones de fijo de BSCH0182ORANDE TL Devoluciones de fijo de BBVA2013ORANDE CECFR Devoluciones de fijo de ALPI Caixa CataluñaNo existen devoluciones de fijo de TELECOR, aunque sí existe envío de remesas

Remesas de Ya.com (/ora_data3/editran/REC_COBROS/YACOM_RMCARE.ini)

ENV

MANUAL EDITRAN/ora_data3/editran/REC_COBROS/Env_YACOM.sh YACOM_RMCARE

Recepción OK/ora_data3/editran/REC_COBROS/Rec_YACOM.sh YACOM_RMCARE

0049RMCARE REM_ Remesas de Ya.com

Devoluciones de Ya.com (/ora_data3/editran/REC_COBROS/YACOM_RMCADE.ini)

RECP

AUTO (L-V 8:15)En caso de error recogida manual


OPEN_FIJO_24H_PROC_001_Recogida_Devoluciones_YACOM ejecuta proceso Rec_YACOM.sh YACOM_RMCADE

0049RMCADE E Devoluciones de Ya.com

Remesas de SISTEL (/ora_data3/editran/REC_COBROS/SISREM.ini)

ENVMANUAL EDITRAN

/ora_data3/editran/REC_COBROS/Env_FIJO.sh SISREM

0030SISREM DO Remesas de SISTEL

Devoluciones de SISTEL (/ora_data3/editran/REC_COBROS/SISDEV.ini)

RECP

AUTO (L-V 18:15 y S 15:30)

En caso de error recogida manual


OPEN_FIJO_24H_PROC_001_Recogida_Devoluciones_SISTEL ejecuta proceso Rec_FIJO.sh SISREM

0030SISDEV dd Devoluciones de SISTEL

Archivos de Prepago (APRS) – Recargas y Lista Negra 4B IMPRTANTE: parametrización de cada cadena en su ReloadTransfer.ini o parametrización directamente en la cadena

ENV AUTO (L-D: 7:00) EDITRAN/ora_data3/editran/control_m/exec/

OPEN_4B_24H_PROC_001_CuatroB.ksh

000049RECARG Prepago - Recargas 4B

AUTO (L-D 9:30) EDITRAN/ora_data3/editran/control_m/exec/

002000ANCECA Prepago – Recargas CECA

AUTO (L-D 4:00) EDITRAN/ora_data3/editran/control_m/exec/

008600CONCIL Prepago – Recargas TELECOR

3


AUTO (L-D 1:00) EDITRAN/ora_data3/editran/CAIXA

002100ENVCAI(ReloadTransfer.ini)

Prepago – Recargas La Caixa

AUTO (L-D 2:00) EDITRAN/ora_data3/editran/DIA

730046RECARG(ReloadTransfer.ini)

Prepago – Recargas DIA Directo

AUTO (L-D 4:00) EDITRAN/ora_data3/editran/SOLRED

FTP Prepago - SOLRED

RECP AUTO (L-D 14:00) EDITRAN/ora_data3/editran/CUATROB

010444B60012(ReloadTransfer.ini)

Lista Negra – 4BSe recoge de 4B y se envía por FTP a BSCS

Envío a ASNEF (EQUIFAX) (/ora_data3/editran/ASNEF/ReloadTransfer.ini)

ENV

CONTROL-M. Llamada de

teléfono tras finalizar proceso

en ACCON (J antes 24:00)

EDITRAN/ora_data3/editran/control_m/exec/

008335FOTOES ASNEF – móvil (desde ACCON)

RECP AUTO (V 10:00) EDITRAN/ora_data3/editran/control_m/exec/

008335FOTOES ASNEF – móvil. Fichero de feedback. No se hace nada con él.

3


Envío a EXPERIAN (BADEXCUG) (/ora_data3/editran/EXPERIAN/ReloadTransfer.ini)ENV CONTROL-M.

Llamada de teléfono tras finalizar proceso en ACCON (J antes 24:00)

EDITRAN/ora_data3/editran/EXPERIAN

008500EXPER1 ExperianRecogida previa del fichero por FTP a la máquina 10.132.7.123

RECP AUTO (V 10:00) EDITRAN/ora_data3/editran/EXPERIAN

008500EXPER1 ExperianFichero de feedback. Se envía por FTP a la máquina 10.132.7.122.

Envío de alertas a BADEXCUG (/ora_data3/editran/BADEX/ReloadTransfer_badex.ini)ENV MANUAL

Petición remedyEDITRAN

/ora_data3/editran/BADEX008500BATCR Alertas a BADEX

RECP AUTO (L 9:00)Petición remedy si

es urgente

EDITRAN/ora_data3/editran/BADEX

008500BATCR Recepción de fichero de feedback de alertas a BADEX

Envío a ASNEF del fijo de ALPI (/ora_data3/editran/REC_COBROS/FOTOAL.ini)

ENV

AUTO (M 17:30) EDITRAN/ora_data3/editran/REC_COBROS

008335FOTOAL ASN ASNEF – fijo ALPI.

RECP

AUTO (J 14:00) EDITRAN/ora_data3/editran/REC_COBROS

008335FOTOAL ASN Recogida de fichero de feedback de FIJO de ALPI

Pagos a favor del cliente (/ora_data3/editran/REC_COBROS/PAGO.ini)IMPORTANTE: El archivo hay que prepararlo para el envío en función de qué pagos se pretenda enviar, además de tener en cuenta que un envío manual no coincida con los envíos planificados de forma automática para Banesto.

ENV AUTO (L-V 09:00, 14:00 y

16:30)

EDITRAN/ora_data3/editran/REC_COBROS

0030N34 P0030 Pagos Banesto – Norma 34

AUTO (L-V 09:00, 14:00 y

16:30)

0030N341 N0030 Pagos Banesto – Norma 34.1

MANUAL 2038N34 P2038 Pagos Caja Madrid – Norma 34MANUAL 0182N34 P0182 Pagos BBVA – Norma 34MANUAL 0049N34 P0049 Pagos SCH – Norma 34

3


MANUAL 0049N341 N0049 Pagos SCH – Norma 34.1

RECP

AUTO (L-V 09:00, 14:00 y

16:30)

Aprox. 1 hora después del envío.

EDITRAN/ora_data3/editran/REC_COBROS

0030N34 P0030 Recogida de fichero de feedback de Pagos Banesto – Norma 34

AUTO (L-V 09:00, 14:00 y

16:30)

0030N341 N0030 Recogida de fichero de feedback de Pagos Banesto – Norma 34.1

MANUAL 2038N34 P2038 Recogida de fichero de feedback de Pagos Caja Madrid – Norma 34

MANUAL 0182N34 P0182 Recogida de fichero de feedback de Pagos BBVA – Norma 34

MANUAL 0049N34 P0049 Recogida de fichero de feedback de Pagos SCH – Norma 34MANUAL 0049N341 N0049 Recogida de fichero de feedback de Pagos SCH – Norma

34.1Envío WHOLESALES a BANESTO (/ora_data3/editran/WHOLESALE/ReloadTransfer.ini)

RECP AUTO (L-V 19:30)Se escala a 24x7 si

hay error en recogida AUTO.

Reintento manual hasta las 21:00 y

escalado a Santiago Tomas si

persiste.

EDITRAN/ora_data3/editran/WHOLESALE

LOG/ora_data3/editran/LOGS

Formato:RECEDI_WHOLESALE_20110601

Cadena: COBROS_AP_24H_PROC_001_Wholesale

Documento: COBROS_AP_24H_PROC_001_Wholesale_V03.doc

DIRECTORIO RECEPCIÓN:/ora_data3/editran/wholesale/recepcion

Formato:EXP1.BTO.LR.EDITRAN.E.R008536.AWHOLES.N01

000030WHOLES Recogida WHOLESALES.

Habitualmente llaman de la guardia indicando que ha habido un error “FALLA EL JOB recedi_editranp1930 DEL GRUPO COBROS_24H_PROC DE LA APLICACION COBROS_APSYSOUT:+ /ora_data3/editran/WHOLESALE/RecEDI WHOLES”

SOLUCIÓNVamos al LOG/ora_data3/editran/LOGSFormato de log: RECEDI_WHOLESALE_20110601

Veremos que en el archivo existe el error:20110603:193235:W:Fichero remoto no esta listo20110603:193235:E:FICHERO REMOTO NO ESTA LISTO

Reintentamos cada media hora hasta las 22:00 (y si tampoco lo recogemos entonces, lo dejamos para el día siguiente) ejecutando desde:/ora_data3/editran/WHOLESALEnohup RecEDI WHOLES &

Miramos el LOG cada vez hasta que exista un mensaje como el siguiente:20110603:200330:I:TRANSMISION DE RECEPCION CORRECTA20110603:200330:I:Dados permisos sobre los ficheros

3


En la ruta /ora_data3/editran/wholesale/recepcionexistirá un fichero de tipo EXP1.BTO.LR.EDITRAN.E.R008536.AWHOLES.N01

Por último ejecutamos el job de envío por FTP (si no lo hacemos no le llegará el fichero a TA y nos llamarán diciendo que tendrán que aplicar HLs a clientes):/ora_data3/editran/WHOLESALEnohup EmiFTPsufijoHora WHOLES &

Veremos que el fichero descargado ha desaparecido de la ruta de recepción y se habrá almacenado en /ora_data3/editran/wholesale/backup

Cerramos la incidencia indicando en la pestaña de solución que “Se recoge el fichero de WHOLESALES manualmente y se envía por FTP”. Por ejemplo HD1000003088661

Recibos refacturados de La Caixa (/ora_data3/editran/REFACT_CAIXA/ReloadTransfer.ini)AUTO (L-V 19:00)

Aunque se ejecuta a diario sólo se espera recibir

fichero el día 19 de cada mes, y 15

días después.Actualmente sin

uso.

EDITRAN/ora_data3/editran/REFACT_CAIXA

002100REFACT Recibos refacturados de La Caixa

/ora_data3/editran/SOURCEtail -100 salida.dat

Ejemplo de envío

********************************************************RESULTADO DE LA EMISION DE LA PRESENTACION E0049RMCARE

Numero de presentacion : 0001

3


Fecha y hora de inicio de transmision: 09/09/2009 11:59:04Fecha y hora de fin de transmision : 09/09/2009 11:59:25

# Emitido Nombre--- ------- ------1 100% REM_DOD01 080********************************************************

Ejemplo de recepción

****************************************************************************RESULTADO DE LA RECEPCION DE LA PRESENTACION R0049RMCARE

Numero de sesion de presentacion : 0001Fecha y hora de inicio de transmision : 09/09/2009 12:54:56Fecha y hora de fin de transmision : 09/09/2009 12:55:01

# C F T L.Reg Fecha creacion Fecha modificacion Long. Real Comprimido Nombre________________________________________________________________________________________1 F F N 04020 00/00/0000 00:00:00 00/00/0000 00:00:00 000000000170 000000000108 /ora_data3/editran/rmca/remesas/okko/E.HT.R0008536.ARMCARE.MOD****************************************************************************

-

3


INFORME PRELIMINARTodos los días debe enviarse a negocio a primera hora de la mañana un informe indicando las incidencias acontecidas durante la noche, el proceso que se encuentra en ejecución asi como los procesos que le proceden y una estimación de cuando habrá finalizado el informe de devoluciones de personal.

Este informe se enviara al siguiente grupo de destinatarios:

Para cobros movilcontrol <[email protected]>; DE BLAS LOPEZ, Alberto <[email protected]>; GONZALEZ GARCIA, Leticia <[email protected]>; VELASCO ARRIBAS, Angel Luis <[email protected]>; FUENTES MORALES, Gema <[email protected]>; BARRIO VIEDMA, Mar <[email protected]>; ES, Soporte Accon <[email protected]>; TOMAS GORGAS, Santiago <[email protected]>; MIGUELEZ FUERTES, Francisco <[email protected]>; DAVID JARRIGE, Olivia FT <[email protected]>; FORTEA RODRIGUEZ, Marta <[email protected]>

CC SAN FELIPE MARTIN, David Ext <[email protected]>; RODRIGUEZ ARTEAGA, RAUL Ext <[email protected]>; GONZALEZ CAMPOS, Adolfo Ext <[email protected]>; SAN CASIANO CANSECO, Miguel Angel Ext <[email protected]>; GARCIA MARCO, Laura Ext <[email protected]>; David González Fernández <[email protected]>

Incidencias acontecidas durante la noche Solo indicaremos aquellas incidencias que han afectado a Open Cobros y sean de carácter importante.

Incidencias habituales en la guardia que no especificamos en el informe:

Open Cobros:

Filesystem

Netplus

Errorres en los procesos de Netplus: Puesto que es mas que habitual y se debe a una monitorización incorrecta.

En caso de que no haya habido incidencias en el sitema indicaremos:

No han existido incidencias derivadas a la guardia.

El proceso que se encuentra en ejecución asi como los procesos que le proceden.Dependiendo del proceso que se encuentre en ejecución indicaremos un texto u otro:

Se indican los procesos habituales:

Planificador: /bin/ksh /openp1/opencobp/control_m/exec/OPEN_350_24H_PROC_001_planificador.ksh Actualmente está en ejecución el planificador, posteriormente se ejecutara el proceso encargado de realizar la extracción de datos del Informe de Devoluciones de Personal. Una vez haya terminado dicho proceso se ejecutaran

3


el proceso encargado de generar el fichero de Control del informe generado y por ultimo los procesos encargados de realizar la extracción y envío de los ficheros con las devoluciones erróneas.

Informe de devoluciones de personal:Actualmente está en ejecución el proceso encargado de realizar la extracción de datos del Informe de Devoluciones de Personal. Una vez haya terminado dicho proceso se ejecutaran el proceso encargado de generar el fichero de Control del informe generado y por ultimo los procesos encargados de realizar la extracción y envío de los ficheros con las devoluciones erróneas.

Una estimación de cuando habrá finalizado el informe de devoluciones de personal.Dependiendo de la cadena que este en ejecución utilizaremos una comprobación u otra:

Planificador: /bin/ksh /openp1/opencobp/control_m/exec/OPEN_350_24H_PROC_001_planificador.kshDebemos recoger los datos:

Inicio del planificador:

Hora actual:

Comando date

Devoluciones de personal de hoy:

Consulta sobre la base de datos:

SELECT COUNT (*) FROM devoluciones_bancarias db, clientes c, lista_clientes lc, mcodigos_devolucion md, tipo_cliente tc WHERE db.f_proceso = TO_DATE (TO_CHAR (SYSDATE, 'YYYYMMDD'), 'YYYYMMDD') AND db.radical_emp = '01' AND c.radical_emp = '01' AND tc.radical_emp = '01' AND lc.radical_emp = '01' AND db.tipo_cliente IN ('0A', '0B', '0C', '0D', '0E') AND lc.id_segmento IN ('S00000', 'S00011', 'S00012', 'S00013') AND md.codigo = db.motivo_devolucion AND db.external_id = c.external_id AND tc.tipo_cliente = db.tipo_cliente AND c.id_cliente = lc.id_cliente;

Acciones planificadas actualmente:

Accedemos a la ruta:

/openp1/opencobp/opensgc/secuencial/planificador/log

3


Y sobre el fichero de hoy con el formato:

Acc_Planificadas_20130125.dat

Hacemos:

Grepp SS [fichero] | wc –l

Informe de devoluciones de personal:

REVISIÓN DE HOTLINES

Tras el proceso de recobro nocturno se habrán publicado N hotlines (evento 42001).Desde el buzón de cobros se recibirá un correo con asunto Hotlines YYYYMMDD, que especifica el número de HotLines de empresa y personal que se van a publicar. El correo lo envía automáticamente el servidor de cobros una vez finalizado el proceso nocturno de recobro.

De [email protected]

Para GONZALEZ GARCIA, Leticia; RUIZ CASAS, Raul; VELASCO ARRIBAS, Angel Luis; DE BLAS LOPEZ, Alberto; FUENTES MORALES, Gema; [email protected]; TOMAS GORGAS, Santiago; VALENZUELA ARROYO, Francisco; OTERO GOMEZ, Juan Jose; ARIAS MUINA, JUAN CARLOS; ROMERO SANCHEZ, Rosalia; [email protected]; [email protected]; MIGUELEZ FUERTES, Francisco; cobros movilcontrol; PEREZ PEREZ, David Ext; SOLOMANDO SANCHEZ, Francisco Javier Ext; TOLEDANO GARCIA, Carlos Ext; HORRILLO SANCHO, Ignacio Jose Ext

Asunto Hotlines YYYYMMDD

Buenos días,La cantidad de Hotlines generados hoy es la siguiente:

Empresa: 1365Personal: 7229

Tras la ejecución automática del proceso de publicación de HLs, obtenemos los siguientes resultados:

Se van a publicar un total de 8594 HLs, de la siguiente manera: - Cadencia: 120 eventos por minuto - Comienzo de la ejecucion: 09/02/2011 a las 06:00:00 - Fin de la ejecucion: 09/02/2011 a las 07:11:37

Muchas graciasUn saludoCobros y Recobros – Control

Los datos de publicación enviados en el correo pueden verificarse en /openp1/opencobp/opensgc/secuencial/middleware/log/CBCCAM50_42001_YYYYMMDDHHMISS.RPT

Existirán dos ficheros de aprox. las 05.00 horas. Esto sucede porque la tasa de publicación que se establece en BBDD es de 1 (1 evento por segundo), pero durante la ventana de 00:00 a 03:00 se publican eventos a una tasa de 120 eventos/minuto. Por tanto se programa la tarea CBCCAM50 dos veces, dando como resultado la existencia de dos ficheros.

mailto:[email protected]

3


También son verificables a través del fichero de consulta de recobros del día, ubicado en /openp1/opencobp/opensgc/secuencial/Informes/infbackup/Consulta_Recobros_YYYYMMDDHHMISS.dat.

En ese archivo se declaran los eventos MDW publicados, entre otros los Hotlines (42001). 42001 @ Generados @ 20110331 @ 11604 @ EMP @ 2747 @ RES @ 8857

Dentro de la operativa diaria, el equipo de cobros revisará después de la hora de Fin de la ejecución si se han producido TIMEOUTS en la comunicación con BSCS a partir de las tablas de MDW. Se revisa si entre los errores que se han producido (eventos en estado 6) existe algún evento con código de error “GDP_ERR-420101”. La consulta a ejecutar será la siguiente:

------------------------------------------------------------------------------------------------- Consulta para revisar los timeouts producidos durante la publicacion de HL-----------------------------------------------------------------------------------------------

SELECT LTRIM ( SUBSTR ( b.parametro, INSTR (b.parametro, '<CustId>') + 8, (INSTR (b.parametro, '</CustId>') - (INSTR (b.parametro, '<CustId>') + 8))), '0') AS custid, a.referencia AS referencia, c.codigo_error AS codigo_error, a.fecha_hora_ejecucion AS fc_ejecucion, c.descripcion_error FROM table_x_ae_eventos a, table_x_ae_datos b, table_x_ae_resp c WHERE a.objid = b.x_mid_datos2x_mid_event AND a.objid = c.x_mid_resp2x_mid_event AND a.estado_envio = 6 AND c.codigo_error = 'GDP_ERR-420101' AND c.fecha_hora_respuesta >= TO_DATE (TO_CHAR (SYSDATE, 'DD/MM/YYYY'), 'DD/MM/YYYY')

3


AND c.fecha_hora_respuesta <= SYSDATE AND LTRIM ( SUBSTR ( b.parametro, INSTR (b.parametro, '<CustId>') + 8, (INSTR (b.parametro, '</CustId>') - (INSTR (b.parametro, '<CustId>') + 8))), '0') IN (SELECT c.id_cliente FROM clientes c WHERE EXISTS (SELECT * FROM restricciones_cuenta rc WHERE rc.external_id = c.external_id));

Las características de la consulta son:- Recupera el identificador del cliente del XML enviado en el evento MDW:

TABLE_X_AE_DATOS.PARAMETRO. ¡!OJO con los tres ceros, que los eliminamos!!.- Los parámetros estado_envio y codigo_error son estáticos.- Las fechas que utilizaremos para obtener datos es la fecha actual.

La consulta devolverá datos si se han producido TIMEOUTS. Dependiendo del caso actuaremos como sigue:

a. Se han producido TIMEOUTS.

El equipo de soporte deberá realizar dos tareas:

- Abrir un ticket remedy a BSCS para la revisión de los TIMEOUTS en la publicación de HLs.

Grupo GC FACTURACION 1Resumen Ejecución de HLsTexto Plantilla catálogo: Buenos días:

Hoy se han producido 2 Timeouts en la ejecución de los HL's

34126805 42001 GDP_ERR-420101 02/09/2011 06:00:3328300177 42001 GDP_ERR-420101 02/09/2011 06:14:28

Saludos

Tipo petición: Petición EstándarAplicación: Area: Aplicaciones OrangeAcuerdo SLA(5x8):Nombre Petición: Alineamiento de números plus entre PS, OE, ARBOR y BSCS - Facturación Descripción: Solicitud para alinear números plus entre todos los sistemas involucrados en el flujo de alta y baja. Numero Unidades Max: Teléfono Contacto Peticionario: 695564701 Nombre Peticionario:PEDRO GARCIA-LAJARA MORAGrupo Peticionario:COBROS Y RECOBROS - CONTROLEmail Peticionario:[email protected]

Anexo Hoja Excel con los HLs para los que se ha detectado Timeout. Se obtienen los datos a partir de la consulta anterior.

3


Ejemplo HD1000002959480

- Enviar un correo a los usuarios indicando el número de TIMEOUTS generados. Se re-utilizará el hilo del correo nocturno recibido del servidor.

De cobros movilcontrol

Para GONZALEZ GARCIA, Leticia; RUIZ CASAS, Raul; VELASCO ARRIBAS, Angel Luis; DE BLAS LOPEZ, Alberto; FUENTES MORALES, Gema; [email protected]; TOMAS GORGAS, Santiago; VALENZUELA ARROYO, Francisco; OTERO GOMEZ, Juan Jose; ARIAS MUINA, JUAN CARLOS; ROMERO SANCHEZ, Rosalia; [email protected]; [email protected]; MIGUELEZ FUERTES, Francisco; PEREZ PEREZ, David Ext; SOLOMANDO SANCHEZ, Francisco Javier Ext; TOLEDANO GARCIA, Carlos Ext; HORRILLO SANCHO, Ignacio Jose Ext

CC cobros movilcontrol

Asunto RE: Hotlines YYYYMMDD

Buenos días Hoy se han producido 84 timeouts. Hemos abierto remedy para que nos indiquen el motivo En la ventana de 0 a 3 se han publicado los siguientes HL's - 4350 clientes residenciales- 3452 clientes empresa Saludos

b. No se han producido TIMEOUTS.

El equipo de soporte deberá enviar un correo a los usuarios indicando que no se ha producido ningún TIMEOUT.


Para GONZALEZ GARCIA, Leticia; RUIZ CASAS, Raul; VELASCO ARRIBAS, Angel Luis; DE BLAS LOPEZ, Alberto; FUENTES MORALES, Gema; [email protected]; TOMAS GORGAS, Santiago; VALENZUELA ARROYO, Francisco; OTERO GOMEZ, Juan Jose; ARIAS MUINA, JUAN CARLOS; ROMERO SANCHEZ, Rosalia; [email protected]; [email protected]; MIGUELEZ FUERTES, Francisco; PEREZ PEREZ, David Ext; SOLOMANDO SANCHEZ, Francisco Javier Ext; TOLEDANO GARCIA, Carlos Ext; HORRILLO SANCHO, Ignacio Jose Ext

CC cobros movilcontrol

Asunto RE: Hotlines YYYYMMDD

Buenos días Hoy no se han producido tiemouts en la ejecucion de HL's Saludos

Además de lanzar la consulta anterior con el error 'GDP_ERR-420101', se deberá lanzar también sin esta cláusula de forma que podamos advertir otra serie de errores que sean susceptibles de ser comunicados a BSCS. Por ejemplo, los sucedidos el día 14/03/2011, donde sucedieron numerosos errores de tipo NL7727. Se abrió el TK HD1000002996741 para informar a BSCS y conocer la causa de los errores por si los equipos de cobros o de BSCS tuviesen que realizar alguna acción extraordinaria.

3


Actualmente la revisión de estos tipos de errores (NL7727 y RC3001) está contemplada como una contingencia operativa y se requiere su revisión cada cierto tiempo. Ver, por ejemplo, la petición HD1000003006376.

Sistema Incidencia Descripción de la contingencia

Proyecto con la solución definitiva

Comentario Habilitada/Deshabilitada

Open Cobros

Errores HLs BSCS

Reclamación diaria de errores tipo RC3001 y NL7727 para su tratamiento manual

Incidencia BSCS BSCS indica que el error NL7727 dice que no es reintentable y el error RC3001 lo es semanalmente, estamos a la espera de indicaciones de Sistemas para ajustar proceso de reintentos automáticos

Habilitada

Este proceso es complementario de los siguientes:

- Generación de informes de Indicadores HOTLINE, CallBarring y Reactivación del servicio.- REVISIÓN DE HOTLINES, CALLBARRING O REACTIVACIONES TRAS SUPERAR NÚMERO MÁXIMO DE

REINTENTOS.

La historificación de datos de las tablas de MDW es responsabilidad del equipo de soporte de cobros. La historificación se realiza de forma automática los lunes y viernes.

3


INFORME DIARIO DE LA OPERATIVA DE MANTENIMIENTO DEL MÓVIL

El informe diario de la operativa de mantenimiento del móvil es un informe a alto nivel que refleja el estado de los procesos que se ejecutan en ventana nocturna. Lo envía el equipo de soporte de cobros a primera hora de la mañana después de que hayan terminado todos los procesos nocturnos con la siguiente información.

- Incidencias que se hayan producido en los procesos nocturnos.- Estado de ejecución del recobro.- Estado de ejecución del bancario.- Estado de ejecución de los informes de Pagos, Devoluciones y PARI.- Estado de ejecución de los procesos del Sábado y Domingo- Estado de la carga manual del fichero de transferencias de Unicaja, los lunes.


Para GONZALEZ GARCIA, Leticia; VELASCO ARRIBAS, Angel Luis; FUENTES MORALES, Gema; RUIZ CASAS, Raul; LÓPEZ ARNAL, José Enrique; BARRIO VIEDMA, Mar; [email protected]; DE BLAS LOPEZ, Alberto

CC TOMAS GORGAS, Santiago; Arribas Mingela, Ana; MIGUELEZ FUERTES, Francisco; [email protected]; HORRILLO SANCHO, Ignacio Jose Ext; [email protected]; SOLOMANDO SANCHEZ, Francisco Javier Ext; REDONDO MARIÑO, Francisco Borja Ext; TOLEDANO GARCIA, Carlos Ext; cobros movilcontrol

Asunto Informe diario de la operativa de mantenimiento operativo del móvil - DD/MM/YYYY

Buenos días, No se han detectado incidencias en los procesos de esta noche. El recobro se ha ejecutado correctamente generándose restricciones y cartas. El bancario se ha ejecutado correctamente. El sábado no se recibió el fichero de Santander a la hora programada, realizamos su recogida y su carga manual en el sistema, se han cargado un total de 4395 transferencias sin duplicados. En el día de hoy hemos realizado la carga manual del fichero de Unicaja, un total de 9 operaciones. Se ha generado el informe de Pagos, de Devoluciones y el informe del PARI. Un saludo

El informe diario de la operativa de mantenimiento del móvil es un informe a alto nivel que refleja el estado de los procesos que se ejecutan en ventana nocturna. Lo envía el equipo de soporte de cobros a primera hora de la mañana después de que hayan terminado todos los procesos nocturnos, extrayendo la información de los siguientes puntos:

- Estado del recobro Log del recobro: /openp1/opencobp/opensgc/secuencial/ctrl_m/log/RECOBROYMMDDHHMISS.log

Al editar el archivo, por ejemplo (tail -10 RECOBROY0331010512.log) aparecerá un mensaje de ejecución OK.

3


Además, podemos acudir al informe de consultas del recobro para ver estadísticas concretas de la ejecución (/openp1/opencobp/opensgc/secuencial/Informes/infbackup/Consulta_Recobros_YYYYMMDDHHMISS.dat).

- Estado del recobro (cartas) Log de cartas:/openp1/opencobp/storage/recobros/envimpr

Se verificará que se hayan generado archivos para el día actual, sin necesidad de entrar en más detalle.

Además, podemos acudir al informe de consultas del recobro para ver estadísticas concretas de la ejecución (/openp1/opencobp/opensgc/secuencial/Informes/infbackup/Consulta_Recobros_YYYYMMDDHHMISS.dat).

- Estado del bancario:

A diferencia del recobro, no existe un log específico para el bancario. La validación de si todo ha ido correctamente se realiza como sigue:

o Se recibe un SMS de la guardiao Se revisan los logs de los procesos principales de cada cadena. o Se revisan el número de operaciones en los ficheros correspondientes fijandonos que es el

mismo que el número de operaciones en la bbdd.o Se revisan el número de operaciones de los ficheros descargados desde editran fijándonos

que sea el mismo que el revisado en el punto anterior.

Cada entidad bancaria tiene un nombre de fichero asociado y un código llamado centro de cobro, la asociación se muestra en el siguiente cuadro:

3


Banco Codigo

CENTRAL HISPANO 1

Fichero: E.HT

Caja Madrid 4

Fichero: E8536

BANESTO 5

Fichero: EXP1

LA CAIXA 6

Fichero: ITR

EL CORTE INLGES M.TT 8

BBVA 9

Fichero: TL

UNICAJA 10

Fichero: DP.OB

DEVOLUCIONESLog de devoluciones:/openp1/opencobp/control_m/log_control_m/out_CBCC0810_YYYYMMDDHHMISS

Ejecutar “tail -1 out_CBCC0810_YYYYMMDDHHMISS” y verificar que aparece el mensaje “TERMINOBIEN”

Numero de operaciones en los ficheros:

Ir a la ruta /openp1/opencobp/storage/bancos/recibido/devoluciones

Ejecutar la sentencia “grep ^5690 fichero | wc –l” con cada uno de los ficheros de devoluciones recogidos en la fecha actual.

Numero de operaciones en la bbdd:Ir a la base de datos de OPEN COBROS en el entorno de PRODUCCION

3


Ejecutar las consultas:

SELECT COUNT (*), cod_cencobro FROM devoluciones_bancarias WHERE f_proceso = TO_DATE (:hoy, 'YYYYMMDD')GROUP BY cod_cencobro

SELECT COUNT(*), cod_cencobro FROM devolu_err der, recibos reb WHERE der.referencia = reb.referencia AND der.f_fact = reb.f_fact AND der.RADICAL_EMP = reb.RADICAL_EMP AND der.SECUENCIAL_REC = reb.SECUENCIAL_REC AND f_proceso = TO_DATE (:hoy, 'YYYYMMDD') GROUP BY cod_cencobro

El primer dígito del campo cod_cencobro es el centro de cobro, por tanto para saber el número de operaciones cargadas en la bbdd habrá que sumar lo que devuelva ambas consultas agrupadas por centro de cobro.

Numero de operaciones en los ficheros descargados desde editran:

Ir a la ruta /openp1/opencobp/storage/devoluciones


El número de operaciones del fichero de una entidad bancaria tiene que ser igual al número de operaciones que hay en la base de datos asociado al centro de cobro correspondiente y este a su vez tiene que ser igual al número de operaciones del fichero descargado de editran de esa entidad bancaria.

TRANSFERENCIASLog de transferencias:/openp1/opencobp/control_m/log_control_m/out_CBCC1010_YYYYMMDDHHMISS



Ir a la ruta /openp1/opencobp/storage/bancos/recibido/transferencia

Ejecutar la sentencia “grep ^33 fichero | cut -c 41-44” con cada uno de los ficheros de transferencias recogidos en la fecha actual.

3



Ejecutar la consulta:

SELECT COUNT (*), cod_cencobro FROM transferencias WHERE fecha_operacion = TO_DATE (:ayer, 'YYYYMMDD')GROUP BY cod_cencobro

El primer dígito del campo cod_cencobro es el centro de cobro, por tanto el número de operaciones cargadas en la bbdd estarán ya agrupadas por centro de cobro.


Ir a la ruta /openp1/opencobp/storage/transferencia

Ejecutar la sentencia “grep ^33 fichero | cut -c 41-44” con cada uno de los ficheros de transferencias recogidos en la fecha actual.


VENTANILLASLog de ventanillas:/openp1/opencobp/control_m/log_control_m/out_CBCC0910_YYYYMMDDHHMISS



Ir a la ruta /openp1/opencobp/storage/bancos/recibido/ventanilla



Ejecutar las consultas:

3


SELECT COUNT (*), cod_cencobro FROM cobros_recibo WHERE forma_pago = '02' AND f_cobro >= TO_DATE (:ayer, 'YYYYMMDD') AND f_cobro <= TO_DATE (:hoy, 'YYYYMMDD') GROUP BY cod_cencobro SELECT COUNT (*), cod_cencobro FROM recibos_ven_err WHERE f_cobro = TO_DATE (:ayer, 'YYYYMMDD') GROUP BY cod_cencobro

El primer dígito del campo cod_cencobro es el centro de cobro, por tanto para saber el número de operaciones cargadas en la bbdd habrá que sumar lo que devuelva ambas consultas agrupadas por centro de cobro.


Ir a la ruta /openp1/opencobp/storage/ventanilla



En caso de que existan errores y, a medida que se vayan solucionando, se reutilizará el hilo de este correo para informar sobre la evolución de los problemas.

3


INFORME DE REINTENTOS

El informe de reintentos contiene información detallada relativa a los siguientes aspectos:

- Eventos historificados.- Eventos que han llegado al número máximo de reintentos.- Eventos reintentados.- Reconexiones.

El informe se genera de forma automática dos veces por día, a las 9:30 y a las 23:30 y se envía al buzón de cobros. El proceso que genera el informe de reintentos es el CBCCAM50 (RU-427).

El proceso se ejecutará una vez al día y chequeará todos los eventos que hayan entrado con error (estado 6 o 7) en la tabla TABLE_X_AE_EVENTOS desde la última ejecución del proceso. Para cada uno de estos eventos, se realizará una re-publicación hasta el número máximo de reintento por eventos. Esta publicación se hará en base a la cadencia de publicación que quede definida en el fichero de configuración, por defecto 1 evento/seg.

Se genera un informe detallando el número de reintentos diferenciado por tipo de evento, la cadencia utilizada y el intervalo de las fechas/horas de publicación del conjunto de los eventos reintentados. Este informe se genera en la ruta /openp1/opencobp/opensgc/secuencial/REINTENTOS/out y se envía por correo electrónico a los destinatarios definidos en el fichero de configuración.

Por ejemplo:

De ES/C/AUNA/AUNA//Sop. al Proceso. Facturacion 3 [[email protected]]

ParaCCAsunto Informe reintentos

Eventos historificados:

OBJID OBJID_PUBLIC

ADO RA

ID_CLIENTE

EXTERNAL_ID REFERE

NC MAX_REINTE

NTOS NUM_REINTE

NTOS ORDE

N PUBLICA

DO RECON

EX REINTENT

AR CREATE

_D CHG_DA

TE

102942862

103137177 01 21756999

00021756999.00000

42001 3 3 192 0 0 1 20110322

20110324

102945672

103137178 01 35039876

00035039876.00000

42001 3 3 192 0 0 1 20110322

20110324

Eventos que han llegado al número máximo de reintentos:

OBJID OBJID_PUBLIC

ADO RA

ID_CLIENTE

EXTERNAL_ID REFERE

NC MAX_REINTE

NTOS NUM_REINTE

NTOS ORDE

N PUBLICA

DO RECON

EX REINTENT

AR CREATE

_D CHG_DA

TE

103026968

103237025 01 33807641

00033807641.00000

42001 3 3 193 0 0 1 20110323

20110325

3


103000960

103237042 01 30472114

00030472114.00000

42004 3 3 193 0 0 1 20110323

20110325

103003847

103237043 01 35868585

00035868585.00000

42004 3 3 193 0 0 1 20110323

20110325

Informe eventos reintentados: REFERENC INTERVAL_BEGIN INTERVAL_END CADENCIA COUNT()

42001 2011/03/22 08:55:53 2011/03/23 08:55:54 1 1

42001 2011/03/23 08:55:54 2011/03/24 08:56:51 1 2

42001 2011/03/24 08:56:51 2011/03/25 08:56:41 1 12

42004 2011/03/22 08:56:01 2011/03/23 08:56:03 1 2

42004 2011/03/23 08:56:03 2011/03/24 08:57:01 1 2

42006 2011/03/24 08:57:09 2011/03/25 08:56:58 1 4

Informe reconexiones: REFERENCIA FECHA TOTAL PROCESADOS_OK PROCESADOS_KO_NOREPROCESABLES PROCESADOS_KO_REPROCESABLES

42006 20110324 5750 5747 0 3

42006 20110325 1515 1513 1 1

Intervalo fecha ejecución HL-CB: INTERVAL_BEGIN INTERVAL_END

2011/03/25 09:08:06 2011/03/25 09:08:24

3


REVISIÓN DE HOTLINES, CALLBARRING O REACTIVACIONES TRAS SUPERAR NÚMERO MÁXIMO DE REINTENTOS

A las 9:00 de la mañana se reintenta el envío de todos aquellos eventos vinculados con HL, CB o Reactivaciones que se hayan solventado con error. Se reintenta su envío un máximo de 3 veces.

A las 10:00 se deberá lanzar la siguiente consulta de cara a verificar qué eventos fallidos se deben enviar a BSCS para validar la causa por la que no se haya conseguido aplicar la restricción o la reactivación.

---------------- HOTLINEs, CALLBARRING ----------------SELECT c.id_cliente, e.referencia, r.codigo_error, e.fecha_hora_ejecucion--, e.OBJID,--re.MAX_REINTENTOS,--re.NUM_REINTENTOS,--d.parametroFROM table_x_ae_eventos e, table_x_ae_datos d, table_x_ae_resp r, clientes c, reintentos_eventos re WHERE e.objid = d.x_mid_datos2x_mid_event AND e.objid = r.x_mid_resp2x_mid_event AND e.objid = re.objid_publicado AND c.external_id = REPLACE (SUBSTR (d.parametro, INSTR (d.parametro, '<CustId>'), ( INSTR (d.parametro, '</CustId>') - INSTR (d.parametro, '<CustId>') ) ), '<CustId>', '' ) || '.00000' AND e.estado_envio = 6 AND re.chg_date >= TO_DATE (TO_CHAR (SYSDATE, 'YYYYMMDD'), 'YYYYMMDD')--AND re.chg_date >= TO_DATE ('20100730', 'YYYYMMDD') --AND re.chg_date <= TO_DATE ('20100731', 'YYYYMMDD') AND re.max_reintentos = re.num_reintentos AND r.descripcion_error NOT LIKE '%contratos activos%'UNION---------------- RECONEXIONES -------------------SELECT c.id_cliente, e.referencia, r.codigo_error, e.fecha_hora_ejecucion--, e.OBJID, --re.MAX_REINTENTOS, --re.NUM_REINTENTOS, --d.parametro FROM table_x_ae_eventos_reconex e, table_x_ae_datos_reconex d, table_x_ae_resp_reconex r, clientes c, reintentos_eventos re WHERE e.objid = d.x_mid_datos2x_mid_event AND e.objid = r.x_mid_resp2x_mid_event AND e.objid = re.objid_publicado AND c.external_id = REPLACE (SUBSTR (d.parametro, INSTR (d.parametro, '<CustId>'), ( INSTR (d.parametro, '</CustId>') - INSTR (d.parametro, '<CustId>') ) ), '<CustId>',

3


'' ) || '.00000' AND e.estado_envio = 6 AND re.chg_date >= TO_DATE (TO_CHAR (SYSDATE, 'YYYYMMDD'), 'YYYYMMDD')--AND re.chg_date >= TO_DATE ('20100730', 'YYYYMMDD')--AND re.chg_date <= TO_DATE ('20100731', 'YYYYMMDD') AND re.max_reintentos = re.num_reintentos AND r.descripcion_error NOT LIKE '%contratos activos%'

Las características de la consulta son:- Recupera el id_cliente de la tabla CLIENTES, que es lo que necesita BSCS. Para ello cruza el

external_id del cliente en la tabla CLIENTES con el cust_id (complementado con .00000) que contiene el evento MDW.

3


En General le damos a “calcular prioridad”

3


Plantilla catálogo: Hoy han fallado estos eventos. ¿Podéis revisar el motivo?

24774775 42001 RC3001 01/06/2011 9:07:3827164734 42001 RC3001 01/06/2011 9:07:3930076415 42004 NL7719 01/06/2011 9:07:5630586270 42001 RC3001 01/06/2011 9:07:4130588713 42001 RC3001 01/06/2011 9:07:4231439308 42004 NL7719 01/06/2011 9:07:5731822302 42004 NL7719 01/06/2011 9:07:5834501186 42001 NL7727 01/06/2011 9:07:4336366356 42001 RC3001 01/06/2011 9:07:4436847620 42001 NL7727 01/06/2011 9:07:45

Gracias

3


COMUNICACIÓN DE CARTAS GENERADAS DE OPENCOBROS A DOC1 Y A LAS UNIDADES DE NEGOCIO

El batch de recobros genera diariamente ficheros con la información de las cartas de recobros para enviarlos al gestor de impresión Doc1.

De lunes a viernes, sobre las 9 de la mañana, hay que realizar una revisión de las cartas generadas por el recobro nocturno y facilitarle un pequeño informe a Doc1, para que puedan revisar la integridad de los datos recibidos en su sistema.

La tipología de cartas es la siguiente.- POSTAV - POSTUA - PORTAV Portabilidad- ROAMAV Roaming

La revisión se hace de la siguiente manera:

Las cartas enviadas, quedan almacenadas en la ruta de la máquina de Open Cobros $HOME/storage/recobros/envimpr

Se revisan cuántas cartas se han generado de cada tipología de cartas (POSTAV, POSTUA, PORTAV, ROAMAV) segmentando la información en empresa y residencial.o Ejemplo del comando para ver cuántas cartas de tipo POSTAV se han enviado para residencial: grep

'#RES' POSTAV*20101113*|wc -l o Ejemplo del comando para ver cuántas cartas de tipo POSTUA se han enviado para empresa: grep

'#EMP' POSTUA*20101113*|wc -l

IMPORTANTE. En OMVs no hay segmentación de clientes, por lo que las cartas no distinguen entre empresa y residencial.

Se recopila esta información y los nombres de todos los ficheros generados y se envía por correo a una lista de direcciones predeterminada.

Consideraciones a tener en cuenta:o Si no se generan cartas para alguna tipología de ORANGE no se incluye este dato en el correo.o En cambio, si no existen cartas para algún OMV se indicará que no se han generado cartas de

recobro para ese OMV.o El tratamiento de cartas de OMVs requieren un tratamiento extra. Se abrirán tantas peticiones

remedy como tipologías de cartas existan para cada OMV.o Los lunes se deberán recuperar también las cartas del sábado y domingo.

Las tareas a desarrollar serán las siguientes:

a. Envío del correo informativo.

3


Tomaremos como ejemplo el correo enviado un lunes con datos del sábado y domingo.


Para cobros movilcontrol; [email protected]; TOMAS GORGAS, Santiago; SIESO ESTAUN, Jesus; DE BLAS LOPEZ, Alberto; ROIG VAZQUEZ, Maria Elena; GONZALEZ GARCIA, Leticia; RUIZ CASAS, Raul; FUENTES MORALES, Gema

CC [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; HORRILLO SANCHO, Ignacio Jose Ext; [email protected]; SOLOMANDO SANCHEZ, Francisco Javier Ext; TOLEDANO GARCIA, Carlos Ext

Asunto Comunicación OC-DOC1-Unidades de Negocio DD/MM

Buenos días,

En el día de hoy se han enviado hacia DOC1 desde Open Cobros el siguiente número de cartas:

Cartas Orange Sábado------------------------------------------

Los ficheros enviados son:195 26Feb 08:08 POSTUA-2-06383520110226_0101.dat.2011-02-26:08H08min184193 26Feb 08:08 POSTAV-2-06444220110226_0101.dat.2011-02-26:08H08min784 26Feb 08:08 POSTAV-1-06445020110226_0101.dat.2011-02-26:08H08min

Cartas Orange Domingo------------------------------------------- -ORANGE POSTAV: Se han generado 8934 cartas, divididas en 80 Empresa y 8854 Residencial

Los ficheros enviados son:1669132 27Feb 02:45 POSTAV-2-01555920110227_0101.dat.2011-02-27:02H45min4813 27Feb 02:45 POSTAV-1-01595620110227_0101.dat.2011-02-27:02H45min742 27Feb 02:45 POSTAV-3-02142520110227_0101.dat.2011-02-27:02H45min

Cartas Orange Lunes 28/02/2011---------------------------------------------------- -ORANGE POSTAV: Se han generado 1948 cartas, divididas en 1809 Empresa y 139 Residencial

Los ficheros enviados son:2829 28Feb 02:17 POSTAV-1-01451720110228_0101.dat.2011-02-28:02H17min197 28Feb 02:17 POSTAV-3-01474920110228_0101.dat.2011-02-28:02H17min365615 28Feb 02:17 POSTAV-2-01441620110228_0101.dat.2011-02-28:02H17min

Cartas OMV Pendientes (se os enviarán a través de una remedy a lo largo del día de hoy)------------------------------------------------------------------------------------------------------------------------------------------------ -CARREFOUR: Se han generado 30 cartas de Recobro Fichero: POSTAV-CARREFOUR-2-08324020110228_0101.dat.2011-02-28:08H34min -CARREFOUR: Se han generado 14 cartas de Recobro Fichero: POSTAV-CARREFOUR-2-08315020110227_0101.dat.2011-02-27:08H33min -CARREFOUR: Se han generado 18 cartas de Recobro Fichero: POSTAV-CARREFOUR-2-08291520110226_0101.dat.2011-02-26:08H30min

-YOUMOBILE: Se han generado 22 cartas de Recobro Fichero: POSTAV-YOUMOBILE-2-08461720110225_0202.dat.2011-02-26:07H13min -YOUMOBILE: Se han generado 47 cartas de Recobro Fichero: POSTAV-YOUMOBILE-2-08460820110226_0202.dat.2011-02-28:07H04min -YOUMOBILE: Se han generado 22 cartas de Recobro Fichero: POSTAV-YOUMOBILE-2-08460420110227_0202.dat.2011-02-28:07H04min

Un Saludo.

Un correo de martes a viernes sería similar al anterior, pero tratando exclusivamente ese día.



CC [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; HORRILLO SANCHO, Ignacio Jose Ext; [email protected]; SOLOMANDO

3


SANCHEZ, Francisco Javier Ext; TOLEDANO GARCIA, Carlos Ext

Asunto Comunicación OC-DOC1-Unidades de Negocio DD/MM

Buenos días,En el día de hoy se han enviado hacia DOC1 desde Open Cobros el siguiente número de cartas: Cartas Orange HOY 02/02/2011----------------------------------------------------ORANGE POSTAV: Se han generado 17481 cartas, divididas en 13 Empresa y 17468 Residencial-ORANGE PORTAV: Se han generado 1 cartas, divididas en 0 Empresa y 1 Residencial Los ficheros enviados son:176 02Feb 03:45 PORTAV-02525820110202_0101.dat.2011-02-02:03H45min3251324 02Feb 03:45 POSTAV-2-02025220110202_0101.dat.2011-02-02:03H45min16847 02Feb 03:45 POSTAV-1-02205720110202_0101.dat.2011-02-02:03H45min2970 02Feb 03:45 POSTAV-3-02214320110202_0101.dat.2011-02-02:03H45min Cartas OMV Pendientes (se os enviarán a través de una remedy a lo largo del día de hoy)-------------------------------------------------------------------------------------------------------------------------------------------------CARREFOUR: No se han generado cartas de Recobro -YOUMOBILE: Se han generado 1 cartas de RecobroFichero: POSTAV-YOUMOBILE-2-08461220110201_0202.dat.2011-02-02:07H04min

b. Apertura de los TKs remedy para OMVs.

A lo largo de la mañana, y una vez que hayamos finalizado otras tareas prioritarias, se abrirán tantas peticiones remedy como tipologías de cartas existan para cada OMV. Por ejemplo, para el caso de los dos correos anteriores se abrirán 6 peticiones remedy en el caso del primero, y 1 en el caso del segundo.

La petición remedy tendrá las siguientes características:

Grupo Operador (A.G.I.)Resumen Tratamiento de fichero de cartas OMV Carrefour 26/02/2011

Texto Plantilla catálogo: Asignar a FIJO FAPL Mto. DOC1 - Tratamiento de fichero de cartas OMV YouMobile 01/06/2011Tipo petición: Petición EstándarAplicación: Todos los Entornos Area: CPDAcuerdo SLA(5x8):5 díasNombre Petición: ABM Procedimiento / Operativa CPD Descripción: Nos pasaran los nuevos procedimientos para el Operador Numero Unidades Max: 1Teléfono Contacto Peticionario: 605962536Nombre Peticionario:CARLOS TOLEDANO GARCÍAGrupo Peticionario:COBROS_OMVSEmail Peticionario:[email protected] Instalación deseada:

Anexo Fichero .dat recuperado del servidor de OC-OMV, con las cartas a tratar.

Ejemplo HD1000002980573

Una vez se hayan abierto todos los TK remedy, se enviará un correo a los usuarios de negocio re-utilizando el correo informativo inicial.

3




CC [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; HORRILLO SANCHO, Ignacio Jose Ext; [email protected]; SOLOMANDO SANCHEZ, Francisco Javier Ext; TOLEDANO GARCIA, Carlos Ext

Asunto RE: Comunicación OC-DOC1-Unidades de Negocio DD/MM

Hola,se han creado las siguientes peticiones Remedy para en tratamiento de los siguientes ficheros de cartas. HD1000002982128 POSTAV-YOUMOBILE-2-08460520110228_0202.dat Saludos

3


RECOGIDA MANUAL DE DEVOLUCIONES DE LA CAIXA

Nos conectamos a la máquina de EDITRAN.

Vamos a ora_data3/editran/SOURCE y ejecutamos menup.

Establecemos conexión con la sesión

3


Lunes Martes Miércoles Jueves Viernes Sábado DomingoBancario BATCH: Carga V de Sábado y Domingo. Para

transferencias se carga sólo con opción de reintento, puesto que no hay ficheros de T los lunes.MANUAL: carga T de sábado de Unicaja.

BATCH: carga T, V y D Lunes

BATCH: carga T, V y D Martes

BATCH: carga T, V y D Miércoles

BATCH: carga T, V y D Jueves

BATCH: carga T, V y D Viernes

Recogida manual de EDItran y carga manual de los ficheros indicados arriba si no se reciben después de la segunda recogida de EDItran. Aviso TIVOLI a las 07:15. En caso de que no se recojan tampoco ficheros requeridos de forma manual, avisar a Finanzas y a Negocio, y abrir una incidencia al banco (correo + llamada). Véase Contactos Bancos.· Transferencias: Si no hay carga a las 8:00 de transferencias de SCH, BBVA y CM las plataformas abren una incidencia masiva. ¡¡OJO con cargas duplicadas!!. Hay días en que es necesario realizar dos cargas, porque el banco aporta· Ventanillas: Negocio dará pautas para cargarlas o no. Si solicita cargarlas habrá que regenerar el informe de Pagos (con todos los pagos, o sólo con las ventanillas a cargar).. DevolucionesNegocio dará pautas para realizar la carga hoy o mañana. Si deciden que sea para mañana se cambia el nombre del fichero E.HT por H.TE y se avisa a RAID.Si deciden que se carguen hoy, (1) se cargan las devoluciones, (1) se genera el informe de Devoluciones EMP (es posible que negocio solicite que contenga sólo las nuevas, por lo que habrá que filtrar el banco en la salida del 130), (3) se ejecuta el planificador para aplicar acciones de recobro a clientes de Personal y (4) se genera el informe de Devoluciones PER (es posible que negocio solicite que contenga sólo las nuevas, por lo que habrá que filtrar el banco en la salida del 170). En ambos casos habrá que enviar el informe a ACCON con su fichero de control.

RecobroCompensación de ventanillas erróneas

CONTROL-M (19:00)

Informe de pagos Scoring (semanal)

CONTROL-M (03:00)

Informe de pagos Scoring (mensual)

Día 1 del mes a las 03:00

47


REVISION DE CHECKSUMTodos los días, a primera hora, debe realizarse una revisión de los cambios producidos en determinados ficheros del servidor.

Para ello nos conectamos al servidor de producción de Open Cobros.

Accedemos a la ruta:

/openp1/opencobp/everis/informes_sum

Hay que mirar los archivos resultados del día (si es lunes también hay que mirar los del sábado y los del domingo) con more o cat. Los archivos suelen ser resultado_script.txt y resultado_bin.txt

Con el comando ll podemos listar los ficheros del directorio.

Debemos revisar los ficheros con los formatos siguientes:

FECHA_resultado_script.txt

FECHA_resultado_bin.txt

Ejemplos de ficheros (correspondientes al dia 06/02/2013):

20130206075500_resultado_script.txt

20130206075500_resultado_bin.txt

Debemos enviar un correo indicando el contenido de estos dos ficheros.

Para ver dichero contenido de estos ficheros utilizaremos la siguiente instrucción:

more 20130206075500_resultado_script.txt

more 20130206075500_resultado_bin.txt

Vemos el resultado de estos ficheros:

47


Este correo deberá enviarse a los siguientes destinatarios:

Para cobros movilcontrol <[email protected]>

CC SAN CASIANO CANSECO, Miguel Angel Ext <[email protected]>; GARCIA MARCO, Laura Ext <[email protected]>; PIÑA RAMIREZ, Sandra Ext <[email protected]>; LOPEZ GARCIA, Rebeca Ext <[email protected]>; RODRIGUEZ ARTEAGA, RAUL Ext <[email protected]>; MORAL GEA, Inmaculada Ext <[email protected]>;

Como ya se ha indicado en el texto del correo indicaremos el contenido de estos ficheros.

Para este caso enviamos el correo con la siguiente información:

Buenos días,

EXISTEN DIFERENCIAS EN EL FICHERO DE SCRIPTS

cobros1p:/everis/informes_sum$ more 20130206075500_resultado_script.txt

32c32

< 51218 ./CONTROL/UTIL/AUTO_TARJETAS/script_1_tarjetas_v3.sh

---

> 00364 ./CONTROL/UTIL/AUTO_TARJETAS/script_1_tarjetas_v3.sh

228c228

< 55176 ./CONTROL/RECOBRO/CRUCE_SITAM/exe/cruce_sitam_paso1.ksh

---

> 64870 ./CONTROL/RECOBRO/CRUCE_SITAM/exe/cruce_sitam_paso1.ksh

NO EXISTEN DIFERENCIAS EN EL FICHERO DE BINARIOS

Un saludo

En caso de que no haya habido cambios en los sum indicaremos en el texto del correo lo siguiente:

Buenos días,

NO EXISTEN DIFERENCIAS EN EL FICHERO DE SCRIPTS

NO EXISTEN DIFERENCIAS EN EL FICHERO DE BINARIOS

47


Un saludo

DOCUMENTACIÓN ASOCIADA

Contactos Bancos

Documento donde se encuentran los contactos con cada uno de los bancos y con los responsables de las sesiones que mantiene activas EDItran.

Ruta documentación \BICFM\OTROS DOCUMENTOS\Telefonos (Bancos) E.xls

47


PROCESOS VARIOS

Contenido

PUBLICACIÓN MANUAL DE HOTLINES 3

CRUCE DE DEVOLUCIONES CON RAID 7

CONDONACIÓN DE DEUDA < 1 € 14

CREACIÓN DEL INFORME SEMANAL GFPA 15

PROCEDIMIENTO DE CRUCE CON SITAM 18

Enviamos datos de la base de datos con información de HL y CB a SITAM................................................................18

Recepción de datos de HL y CB de SITAM..................................................................................................................21

Envío de datos de HL y CB de base de datos para los clientes recibidos por SITAM..................................................23

Anexo 1. Orden y eliminación de valores duplicados en Excel...................................................................................28

Anexo 2. Concatenar valores en Excel.......................................................................................................................30

CORRECCIÓN DE DEVOLUCIONES ERRÓNEAS (Por estado incorrecto de remesas) 32

ENVÍO DEL CORREO A RAID.......................................................................................................................................36

CORRECCIÓN DE DEVOLUCIONES ERRÓNEAS (Por solicitud de finanzas) 39

ENVÍO DEL CORREO A RAID.......................................................................................................................................42

EJECUCIÓN DE BAJAS POR IMPAGO EN ORIGEN (42007)44

EJECUCIÓN DE BAJAS POR IMPAGO (42007) 48

EJECUCIÓN DE BAJAS POR IMPAGO DE CLIENTES FUSION (42007) 52

SUBIDA DE ASNEF 53

SUBIDA DE EXPERIAN 61

TIMEOUT NETPLUS (17001) 63

Descripción................................................................................................................................................................63

Solución.....................................................................................................................................................................63

Análisis acciones a realizar.....................................................................................................................................64

Información al peticionario de las acciones...........................................................................................................67

Resolución de las acciones posibles por OC...........................................................................................................67

Responder al correo...............................................................................................................................................68

OBSERVACIONES:.......................................................................................................................................................68

INFORME NORSE (Procesos Nocturnos) 69

47


BINES NACIONALES 70

DECLARACIÓN DE INCOBRABLES 73

CAMBIO DE CONTRASEÑA DE UNA APLICACIÓN. 76

CONTINGENCIA PAs / PUBLICACION MASIVA PAs 77

PASAR A RECOBRO 81

Listado de los HOTLINES generados en OMV 84

Envío Checklist OC trimestral 86

Publicaciones fuera de ventana 86

Reseteo de contraseñas de usuario 87

138

Open Cobros – Manual de soporte

PUBLICACIÓN MANUAL DE HOTLINES

Debido a problemas diversos sucede que los HOTLINES no se publican de forma automática en las ventanas previstas para ello. Esto implica que la publicación debe realizarse manualmente.

El proceso kernel que ejecuta el recobro habrá dejado el fichero de publicación de Hotlines en la ruta /openp1/opencobp/opensgc/secuencial/middleware/in.

Si por motivos de tiempo se ha holdeado la cadena PUBLICACION_HL tendremos los ficheros en /openp1/opencobp/opensgc/secuencial/middleware.

La notación que siguen los archivos en esta ruta será la siguiente: MDW-[nº evento middleware]-[hhmissyyyymmdd]_[RadicalEmp].dat

Por ejemplo: MDW-42001-02414220110405_0101.dat.

La publicación consistirá en los siguientes pasos:

1) Contactar con Operaciones para que nos digan qué número de eventos podemos publicar y en qué ventana horaria. Alberto De Blas:

2) Contactar con BSCS para que nos digan con qué cadencia podemos publicar. BSCS HelpDesk: 656161677.

3) Contar el número de HLs que existen en el fichero y que se pretendan publicar. Se cuentan las líneas existentes en el archivo anterior:

Con la cantidad de HLs devueltos tendremos que modificar el archivo Antes_Recobro_eventos.conf.

4) Modificar el archivo Antes_Recobro_eventos.conf, ubicado en la ruta /openp1/opencobp/opensgc/secuencial/middleware/exec.

El archivo contiene los eventos susceptibles de ser lanzados. Se deberá modificar la columna marcada en rojo indicando el número de HLs (o de cualquier otro evento que se pretenda publicar) recuperado del conteo anterior; teniendo siempre en cuenta los comentarios de Operaciones y de BSCS con respecto a la ventana horaria disponible, al número de eventos que se pueden publicar (todos por lo general).

Por ejemplo: CBCCAM50#42004#0#0|000004#6212

138


El resto de eventos se deberán dejar a 0.MUY IMPORTANTE: Debemos asegurarnos con el resto del equipo de soporte de que no existe ningún otro proceso automático o manual que esté publicando eventos en ese momento.

5) Consultar en base de datos la cadencia especificada para la publicación de HLs.

SELECT * FROM parameters_to_bscs WHERE programa = 'CBCCAM50' AND id_parametro = 'F_H_EJEC_42001';

Dependiendo de la cadencia que nos haya indicado BSCS para la publicación de eventos deberemos modificar el campo VALOR_PARAMETRO del registro:

Habitualmente la cadencia indicada por BSCS es de 60 eventos minuto, por lo que no será necesario modificar nada. Si fuese necesaria una cadencia diferente, las más habituales son las siguientes:

Eventos por minuto Valor (evento cada N segundos)60 130 220 3

UPDATE parameters_to_bscs SET valor_parametro = [valor] WHERE programa = 'CBCCAM50' AND id_parametro = 'F_H_EJEC_42001';

MUY IMPORTANTE: Después de la ejecución manual de eventos el valor se debe dejar de nuevo en 1, para que el proceso nocturno de recobro ejecute a cadencia de 60 eventos minuto (ejecuta 2 veces el proceso CBCCAM50 para emular una publicación con cadencia 120 eventos minuto).

6) Lanzar el proceso OPEN_BIN_24H_PROC_001_EventosAntesRecobro.ksh ubicado en la misma ruta: /openp1/opencobp/opensgc/secuencial/middleware/exec.

El proceso iniciará la publicación de eventos en las tablas de MDW con fecha de SYSDATE. Si desde operaciones nos hubiesen indicado una ventana horaria concreta tendríamos que utilizar el proceso OPEN_BIN_24H_PROC_001_EventosAntesRecobro_programados.ksh.

7) Validación en las tablas de MDW de que los eventos están siendo publicados correctamente:

SELECT * FROM table_x_ae_eventos WHERE referencia = '42001' AND fecha_hora_ejecucion > TO_DATE ('01/04/2011 10:00:00', 'DD/MM/YYYY HH24:MI:SS') AND fecha_hora_ejecucion < TO_DATE ('04/04/2011 19:00:00', 'DD/MM/YYYY HH24:MI:SS') ORDER BY fecha_hora_ejecucion DESC; SELECT COUNT (*), estado_envio

138


FROM table_x_ae_eventos WHERE referencia = '42001' AND fecha_hora_ejecucion > TO_DATE ('01/04/2011 10:00:00', 'DD/MM/YYYY HH24:MI:SS') AND fecha_hora_ejecucion < TO_DATE ('04/04/2011 19:00:00', 'DD/MM/YYYY HH24:MI:SS')GROUP BY estado_envio;

Se encontrarán inicialmente en estado 5. A medida que se vayan publicando se irán encontrando en estado 4 (envío correcto) o 6 (envío erróneo). Es habitual encontrar registros en este último estado cuando no existen, por ejemplo, contratos activos para el cliente en BSCS.

La publicación de HLs implicará también las siguientes acciones:- Verificar que no se hayan producido TIMEOUTS en BSCS tras lanzar los HLs.- Crear el informe diario de revisión de hotlines, emulando el que se que envía automáticamente al

finalizar el recobro en planificación nocturna.

8) Crear el informe diario de revisión de hotlines. Para ello se deberán seguir los siguientes pasos:

a. Distinguir los HLs de empresa y residencial. Para ello se ejecutará el proceso FiltraEventos_EMP_RES.sh, que se encuentra en la ruta /openp1/opencobp/opensgc/secuencial/middleware pasándole como parámetros el fichero original que contiene los hotlines y el evento middleware que se pretende monitorizar (42001).

Para ello moveremos el fichero que se encuentra en la ruta /openp1/opencobp/opensgc/secuencial/middleware/in al directorio donde se encuentra el proceso de filtrado.

Por ejemplo: FiltraEventos_EMP_RES.sh MDW-42001-02414220110405_0101.dat 42001

b. El proceso habrá generado dos ficheros, con notación similar al fichero original pero con la coletilla “_EMP” o “_RES” en función de los tipos de clientes que contenga, por ejemplo:

MDW-42001-02414220110405_0101_EMP.datMDW-42001-02414220110405_0101_RES.dat

c. Para poder obtener los datos del número de HLs publicados para cada tipo de cliente necesitaremos contar las líneas de cada uno de ellos, por ejemplo:

wc -l MDW-42001-02414220110405_0101_EMP.dat

d. Buscar la hora de inicio y fin de la ejecución en BBDD ordenando de forma ascendente y descendente la consulta sobre BBDD respectivamente sobre las tablas de eventos de middleware.

SELECT * FROM table_x_ae_eventos

138


WHERE referencia = '42001' AND fecha_hora_ejecucion > TO_DATE ('01/04/2011 10:00:00', 'DD/MM/YYYY HH24:MI:SS') AND fecha_hora_ejecucion < TO_DATE ('04/04/2011 19:00:00', 'DD/MM/YYYY HH24:MI:SS') ORDER BY fecha_hora_ejecucion DESC;

El resultado final será un correo informativo similar al siguiente:

De [email protected]

Para GONZALEZ GARCIA, Leticia; RUIZ CASAS, Raul; VELASCO ARRIBAS, Angel Luis; DE BLAS LOPEZ, Alberto; FUENTES MORALES, Gema; [email protected]; TOMAS GORGAS, Santiago; VALENZUELA ARROYO, Francisco; OTERO GOMEZ, Juan Jose; ARIAS MUINA, JUAN CARLOS; ROMERO SANCHEZ, Rosalia; [email protected]; [email protected]; MIGUELEZ FUERTES, Francisco; cobros movilcontrol; PEREZ PEREZ, David Ext; SOLOMANDO SANCHEZ, Francisco Javier Ext; TOLEDANO GARCIA, Carlos Ext; HORRILLO SANCHO, Ignacio Jose Ext

Asunto Hotlines YYYYMMDD

Buenos días,La cantidad de Hotlines generados hoy es la siguiente:

Empresa: 1365 Nº DE LINEAS DEL FICHERO DE EMPRESA Personal: 7229 Nº DE LINEAS DEL FICHERO DE RESIDENCIAL

Tras la ejecución automática del proceso de publicación de HLs, obtenemos los siguientes resultados:

Se van a publicar un total de 8594 HLs, de la siguiente manera: - Cadencia: 60 eventos por minuto CADENCIA INDICADA POR BSCS - Comienzo de la ejecucion: 09/02/2011 a las 06:00:00 HORA DE INICIO A PARTIR DE LA CONSULTA CONTRA TABLAS DE BBDD DE MDW - Fin de la ejecucion: 09/02/2011 a las 07:11:37HORA DE FIN A PARTIR DE LA CONSULTA CONTRA TABLAS DE BBDD DE MDW

Muchas graciasUn saludoCobros y Recobros – Control


138


CRUCE DE DEVOLUCIONES CON RAID

Regularmente RAID realiza cruces con OpenCobros para validar el alineamiento de los sistemas de Orange. Cuando se detecta un descuadre de datos entre OC y RAID se solicita al equipo de soporte de OC su revisión.

RAID cruza datos con OpenCobros utilizando dos fuentes de datos:- Los datos de la BBDD de OpenCobros.- Los datos de los ficheros recibidos de EDItran, que se envían regularmente (diariamente) a RAID

por FTP.

Habitualmente nos solicitan verificar datos de un día para un centro de cobro concreto. Los datos a aportar son:

- Número de operaciones en Editran. Para validar la recepción correcta de devoluciones por centro de cobro, la fuente de datos de referencia es el archivo de devoluciones que existirá en la carpeta de backup: /openp1/opencobp/storage/bancos/recibido/devoluciones.

- Número de operaciones e importe cargado en OpenCobros. Para validar la carga, la fuente de datos de referencia es la tabla DEVOLUCIONES_BANCARIAS.

1) Validación en OpenCobros.

Utilizaremos la siguiente consulta, especificando la fecha que nos llegue desde el usuario de Orange:

SELECT cod_cencobro, COUNT (*), SUM (imp_devol) FROM opendba.devoluciones_bancarias WHERE f_devol = TO_DATE ('20110325', 'YYYYMMDD') AND programa != 'ue_pdte_rec'GROUP BY cod_cencobro;

Por ejemplo, el día 01/04/2011 llegó un correo donde nos indicaban que verificásemos los datos de La Caixa del día 25/03/2011, que tenían descuadre con respecto a los datos de RAID:

De VILLAVIEJA ROMERO, Ana Luisa

Para cobros movilcontrol

Asunto Editran_Cobros

Buenos días, ¿Podéis revisar que ocurre en el fichero del día 25, para la Caixa?Gracias, Ana

138


Del correo identificamos que existen 13699 operaciones que RAID obtiene de EDItran, aunque no refleja ninguna de OpenCobros. Por el contrario, no refleja importe de EDItran, pero sí de OpenCobros, lo que nos indica que los datos que nos envían son, en principio, incorrectos.

Si lanzamos nuestra consulta en OC para el día 25 que nos indican como incorrecto tenemos que para La Caixa (centro de cobro 604) existen 13699 devoluciones por un importe de 1.111.138,74. Deducimos que:

- El cuadro que nos envían es incorrecto y el número de operaciones cargadas en OC no es 0, si no 13699. Debemos entender que se han equivocado al completar el cuadro asignando el valor al número de operaciones de EDItran.

Como los datos de devoluciones de La Caixa se cargan en el sistema el lunes (día 28), verificamos también las devoluciones que existen para el día 28.

2) Validación en EDItran.

Una vez validada la carga de operaciones y de importe en OpenCobros, validamos el número de operaciones recibidas en EDItran.

Nos conectamos a la máquina de cobros1p con el usuario de Editran y accedemos a la ruta de devoluciones recibidas de los bancos: /openp1/opencobp/storage/bancos/recibido/devoluciones. Si el fichero no existe en esta ruta, entonces estará almacenado en los directorios de backup /openp1/opencobp/bck/devoluciones. En los archivos de backup los archivos de devoluciones estarán almacenados en archivos comprimidos cpio.

- Para ver los archivos incluidos dentro del archivo comprimido: cpio -itv <[nombre del archivo.cpio]

Por ejemplo:cpio -itv <devoluciones_20110401110005.cpio

138


- Para descomprimir los archivos incluidos dentro del archivo comprimido:cpio -itv <[nombre del archivo.cpio]

Por ejemplo:cpio -idmv <devoluciones_20110401110005.cpio

Los ficheros de devoluciones están mapeados a un centro de cobro concreto a partir de su formato inicial, así, los ficheros de devoluciones de La Caixa tienen los siguientes formatos:

- Inicio por ITR. Ficheros de devoluciones recogidos los Lunes, Martes, Miércoles, Jueves y Viernes.

Recogida Generado por La Caixa Con Devoluciones del CargaAutomática el Lunes Lunes Viernes Automática el MartesManual el Martes Martes Lunes Automática el MiércolesManual el Miércoles Miércoles Martes Automática el JuevesManual el Jueves Jueves Miércoles Automática el ViernesManual el Viernes Renombrado como TRI.

Viernes Jueves Automática el Lunes

Por ejemplo:

- Inicio por TRI. Ficheros de devoluciones recogidos los Viernes con devoluciones del jueves.

El fichero se recoge el viernes como ITR.[lo que sea], pero se renombra por el equipo de soporte como TRI.[lo que sea] en el mismo momento de la recogida: move ITR.[lo que sea] TRI.[lo que sea]. Esto se realiza porque los procesos de recogida de EDItran validan que no exista ya un fichero con el mismo formato dentro del directorio de recogida. Si existiese, la recogida no se realizaría.

A continuación lo que hay que hacer es contar las líneas enviadas en cada fichero enviado por el banco perteneciente al día que nos solicita el usuario:

grep ^5690 [fichero] | wc -l

Este conteo nos servirá para verificar que, efectivamente, en EDItran existen datos.

Para el ejemplo anterior, nuestra respuesta será similar a:

138



Para VILLAVIEJA ROMERO, Ana Luisa; ES, ssbb revenue

Asunto RE: Editran_Cobros

Buenos días, El día 28/03 como es lunes se procesan en Open Cobros 2 ficheros de devoluciones de la caixa, el fichero de La Caixa del día 25/03 (devoluciones del día 24/03) tiene 13.734 operaciones y el fichero de la caixa del día 28/03 (devoluciones del día 25/03) tiene 195 operaciones. Todas las operaciones se encuentran cargadas en Open Cobros como cualquier lunes normal con estos datos, devoluciones OK: Número operaciones Importe Total Fecha Devolución

13.699 1.111.138,74 25/03/2011

165 23.415,06 28/03/2011

Los ficheros de EDItran se encuentran también en la ruta habitual para que los reviséis. Un Saludo

Para el ejemplo anterior, nuestra respuesta será similar a:

COD_CENCOBRO

PROPIOS / AJENOS

CODIGO BANCO

BANCO ACRÓNIMO FICHEROS

104 PROPIOS 0049 CENTRAL HISPANO E.HT.105 AJENOS404 PROPIOS 2038 C.A.M.P. MADRID E8536405 AJENOS504 PROPIOS 0030 BANESTO EXP1.505 AJENOS604 PROPIOS 2100 LA CAIXA ITR.605 AJENOS804 -- 8888 EL CORTE INGLES M.TT904 PROPIOS 0182 BILBAO VIZCAYA (BBV) TL.905 AJENOS1004 PROPIOS 2103 UNICAJA

DP.OB1005 AJENOS

3) Consultas que utiliza RAID para realizar sus cruces:

-- DEVOLUCIONES DE OPENCOBROS SELECT cod_cencobro || '|' || TO_CHAR (f_proceso, 'YYYYMMDD') || '|' || TO_CHAR (f_fact, 'YYYYMMDD') || '|' || TO_CHAR (f_devol, 'YYYYMMDD') || '|' || imp_devol || '|' || num_ccc FROM opendba.devoluciones_bancarias WHERE f_proceso = TO_DATE ('&&1', 'YYYYMMDD') AND programa != 'ue_pdte_rec';

-- DEVOLUCIONES ERRÓNEAS DE OPENCOBROS SELECT TO_CHAR (f_proceso, 'YYYYMMDD') || '|'

138


|| TO_CHAR (f_fact, 'YYYYMMDD') || '|' || TO_CHAR (f_devol, 'YYYYMMDD') || '|' || impor_dev || '|' || desc_error FROM devolu_err, mcodigos_devolu_err WHERE f_proceso = TO_DATE ('&&1', 'YYYYMMDD') AND devolu_err.co_error = mcodigos_devolu_err.cod_error;

-- DEVOLUCIONES MANUALES --> Devoluciones erróneas anteriores a 31 días, cargadas a petición de finanzas.SELECT cod_cencobro || '|' || TO_CHAR (f_proceso, 'YYYYMMDD') || '|' || TO_CHAR (f_fact, 'YYYYMMDD') || '|' || TO_CHAR (f_devol, 'YYYYMMDD') || '|' || imp_devol || '|' || num_ccc FROM devoluciones_bancarias WHERE f_proceso = TO_DATE ('20110330', 'YYYYMMDD') AND programa != 'ue_pdte_rec' AND f_devol > f_abono + 32

-- VENTANILLAS OPENCOBROS SELECT a.cod_cencobro || '|' || TO_CHAR (b.f_asociacion, 'YYYYMMDD') || '|' || TO_CHAR (a.f_cobro, 'YYYYMMDD') || '|' || a.imp_cobrado FROM cobros_recibo a, fecha_recepcion_ve b WHERE a.forma_pago = '02' AND b.f_asociacion = TO_DATE ('&&1', 'YYYYMMDD') AND a.referencia = b.referencia AND TRUNC (a.f_cobro) = TRUNC (b.f_cobro) AND a.importe_original = b.imp_recibo AND a.f_fact = b.f_fact;

-- TRANSFERENCIAS DE OPENCOBROS -- Para identificar las transferencias asociadas manualmente el usuario será diferente de "opencob". SELECT cod_cencobro || '|' || TO_CHAR (fecha_recepcion, 'YYYYMMDD') || '|' || TO_CHAR (fecha_operacion, 'YYYYMMDD') || '|' || TO_CHAR (fecha_valor, 'YYYYMMDD') || '|' || importe FROM transferencias a, fecha_recepcion b WHERE b.fecha_recepcion = TO_DATE ('20110202', 'YYYYMMDD') AND a.referencia1 = b.referencia1;

4) Devoluciones manuales.

En ocasiones también se solicita información de devoluciones manuales por centro de cobro para un día concreto. Por ejemplo:




Buenos días,

138


Editran_Cobros El 29 de marzo, ¿me podéis decir si hay devoluciones manuales?.

Un Saludo

Los datos los podemos extraer de dos fuentes:

- Del archivo de log que obtenemos al realizar la carga de devoluciones erróneas en el sistema.

Los archivos de salida de carga de devoluciones erróneas se encuentran en /openp1/opencobp/CONTROL/RECOBRO/DEVOLUCIONES_ERRONEAS/log.

Se denominan Raid_yyyymmddhhmiss.

- A partir de una consulta de BBDD.

-- DEVOLUCIONES MANUALES --> Devoluciones erróneas anteriores a 31 días, cargadas a petición de finanzas, agrupadas por centro de cobroSELECT db.cod_cencobro, ag.nom_agencia || DECODE (SUBSTR (db.cod_cencobro, LENGTH (db.cod_cencobro)), '4', ' (propios) ', '5', ' (ajenos) ', '' ) tipo, COUNT (*), SUM (imp_devol) FROM devoluciones_bancarias db, agencias ag, cencobro cc WHERE f_proceso = TO_DATE ('20110330', 'YYYYMMDD') AND db.programa != 'ue_pdte_rec' AND f_devol > f_abono + 32 AND db.cod_cencobro = cc.cod_cencobro AND cc.cod_agencia_env = ag.cod_agenciaGROUP BY db.cod_cencobro, ag.nom_agencia;

El resultado obtenido en ambos casos debería ser igual y se informará al usuario que nos solicita la validación. Por ejemplo:

138





Buenos días, Sí las hubo, te facilitamos los datos:

CODIGO CENTRO DE COBRO IMPORTE_TOTAL

104Central Hispano (Propio) 5923,21

105Central Hispano (Ajeno) 14558,58

405Caja Madrid (Ajeno) 15421,92

504Banesto (Propio) 5111,07

505Banesto (Ajeno) 20748,63

604Banesto (Ajeno) 21227,69

904Bilbao Vizcaya (Propio) 8975,37

905Bilbao Vizcaya (Ajeno) 946,6

1004Unicaja (Propio) 1128,85

1005Unicaja (Ajeno) 2207,56

Un saludo

138


CONDONACIÓN DE DEUDA < 1 €

Nos llegará un correo al buzón de cobros solicitando la condonación de deuda < 1 €.

Este proceso es automático, pero en alguna ocasión nos han solicitado que lo realicemos manualmente

138


CREACIÓN DEL INFORME SEMANAL GFPA

La información que se debe escribir en este informe es la de las actuaciones realizadas sobre los pagos anticipados.

Se contabilizan los DUMMYs arreglados automáticamente y los resueltos de forma manual. Esta información se extrae de los ficheros de nombre ddmmyyyy_dummys.csv que se encuentran almacenados en la ruta:

HOME/CONTROL/REMESADOS/PAGOS_ANTICIPADOS/csv

Máquina de OPENCOBROS.

Existe un fichero así por cada día de la semana. La acción a realizar sobre cada uno de ellos es la de abrirlo con un:

more ddmmyyyy_dummys.csv

Se trata de contabilizar el número de intervenciones manuales y automáticas. Para ello, se analiza cada traza y por cada una en la que aparezca la palabra DUMMY se suma un uno a la columna DUMMY y por cada una en la que no aparezca se suma un uno a la columna NIF.

Estos datos se escriben en la hoja de Excel con el siguiente formato:

DIA DUMMY NIF30/05/2011 6 231/05/2011 6 101/06/2011 6 102/06/2011 6 103/06/2011 6 304/06/2011 7 205/06/2011 6 3 DUMMY NIF

43 13

Y automáticamente se rellenará el gráfico:

138


Mensualmente deberá rellenarse la tabla de resumen del mes que tiene la siguiente forma:

DUMMY NIFene-11 205 61feb-11 183 72

mar-11 203 72abr-11 197 75

may-11 91 34

Totales Anual 879 314

Y dará también como resultado una gráfica:

138


Para finalizar el fichero se guarda con el nombre yyyymmdd_Informe_semanal_GFPA.xls en la carpeta de red en la siguiente ruta:

\\5.0.2.162\cfm\04 - Informes\00 - Aplicaciones\02 - OPENCOBROS\Informes GFPA

y en el acceso remoto de ORANGE

https://213.143.32.18/dana-na/auth/url_87/welcome.cgi

138


PROCEDIMIENTO DE CRUCE CON SITAM

Procedimiento por el cual se comparan los datos para HL y CB entre las aplicaciones OPEN COBROS y SITAM.

Los pasos para realizar el proceso son los siguientes:

1. Envío de datos de la base de datos con información de HL y CB a SITAM2. Recepción de datos de HL y CB de SITAM3. Envío de datos de HL y CB de base de datos para los clientes recibidos por SITAM

Enviamos datos de la base de datos con información de HL y CB a SITAM

Todos los Martes está planificada mediante el crontab la ejecución del proceso:

/openp1/opencobp/CONTROL/RECOBRO/CRUCE_SITAM/exe/cruce_sitam_paso1.ksh

Este proceso generará los datos requeridos y enviará un correo a la lista de direcciones indicada en el fichero:

/openp1/opencobp/CONTROL/RECOBRO/CRUCE_SITAM/exe/ mail_cruce_sitam.conf

Recibiremos un correo como el siguiente:

Unicamente debemos renviar el correo indicando:

En el para: ES, Sitam <[email protected]>; BLAYA ALMAGRO, Andres Ext ([email protected])

En el cc: GIMENEZ GOMEZ, Vicente Ext <[email protected]>; TOMAS GORGAS, Santiago <[email protected]>; cobros movilcontrol <[email protected]>; RODRIGUEZ ARTEAGA, RAUL Ext [email protected]

Una vez renviado el correo ya habríamos realizado el primer paso del cruce.

Ejecución del paso de forma manualEn caso de que dicha automatización fallase la ejecución manual del primer paso del cruce seria la siguiente:

Lanzamos la siguiente consulta para los HL (dejarla tal cual está):

SELECT DISTINCT lc.id_cliente



138


FROM lista_clientes lc, clientes c, re_desconexiones rd WHERE lc.id_cliente = c.id_cliente AND c.cuenta_formato_largo LIKE '1.%' AND lc.id_segmento NOT IN ('S00021','S00024','S00007','S00038', 'S00023','S00015','S00010','S00032', 'S00033','S00034','S00031','S00009', 'S00027','S00005','S00022','S00006', 'S00026','S00025','S00008','S00028') AND lc.ID_CLIENTE = RTRIM (RTRIM (LTRIM (rd.EXTERNAL_ID, '0'), '0'), '.') AND lc.radical_emp = c.radical_emp AND lc.RADICAL_EMP = rd.RADICAL_EMP AND NOT EXISTS (SELECT 1 FROM re_desconexiones rd2 WHERE rd.EXTERNAL_ID = rd2.EXTERNAL_ID AND rd.RADICAL_EMP = rd2.RADICAL_EMP AND rd2.RADICAL_EMP = '01' AND rd2.f_reconexion = TO_DATE ('31/12/2999', 'dd/mm/yyyy') AND rd2.tipo_desc = 'IF012') AND NOT EXISTS (SELECT 1 FROM table_x_ae_resp rp1, table_x_ae_eventos_aux eva1 WHERE eva1.objid = rp1.X_MID_RESP2X_MID_EVENT AND rd.external_id = eva1.external_id AND rd.radical_emp = eva1.radical_emp AND (rp1.codigo_error = 'NL7731')) AND lc.DEUDA > 0 AND rd.radical_emp = '01' AND rd.f_reconexion = TO_DATE ('31/12/2999', 'dd/mm/yyyy') AND rd.tipo_desc = 'IF011';

Exportamos los datos a un fichero .dat con la nomenclatura “Extraccion_HL_AÑOMESDIA100000”. Tras exportarlo lo abrimos con el Ultraedit y lo convertimos a formato Unix.

138


Fichero Extraccion_HL_20110322100000.dat

Lanzamos la siguiente consulta para los CB:

SELECT DISTINCT lc.id_cliente FROM lista_clientes lc, clientes c, re_desconexiones rd WHERE lc.id_cliente = c.id_cliente AND c.cuenta_formato_largo LIKE '1.%' AND lc.id_segmento NOT IN ('S00021','S00024','S00007','S00038', 'S00023','S00015','S00010','S00032', 'S00033','S00034','S00031','S00009', 'S00027','S00005','S00022','S00006', 'S00026','S00025','S00008','S00028') AND lc.ID_CLIENTE = RTRIM (RTRIM (LTRIM (rd.EXTERNAL_ID, '0'), '0'), '.') AND lc.radical_emp = c.radical_emp AND lc.RADICAL_EMP = rd.RADICAL_EMP AND NOT EXISTS (SELECT 1 FROM table_x_ae_resp rp1, table_x_ae_eventos_aux eva1 WHERE eva1.objid = rp1.X_MID_RESP2X_MID_EVENT AND rd.external_id = eva1.external_id AND rd.radical_emp = eva1.radical_emp AND rp1.codigo_error = 'NL7731') AND lc.DEUDA > 0 AND rd.radical_emp = '01' AND rd.f_reconexion = TO_DATE ('31/12/2999', 'dd/mm/yyyy') AND rd.tipo_desc = 'IF012';

Exportamos los datos a un fichero .dat con la nomenclatura “Extraccion_CB_AÑOMESDIA100000”. Tras exportarlo lo abrimos con el Ultraedit y lo convertimos a formato Unix.

138


Fichero Extraccion_CB_20110322100000.dat

Una vez tengamos los ficheros, con extensión .dat, los comprimimos en un fichero zip con la nomenclatura “AÑOMESDIA” siendo el día el actual de recogida de los datos.

Seguidamente enviaremos el mail con los siguientes datos:

Para [email protected];[email protected];[email protected];[email protected]

CC [email protected]; [email protected]; [email protected]; [email protected]; [email protected]

Asunto Extracción OC para cruce SITAM - DD/MM/YYYY

Achivos Adjuntos

Fichero ZIP con los dos EXCEL.

Hola,

Os enviamos la extracción semanal para el cruce en SITAM.

Saludos






mailto:[email protected];[email protected];[email protected];[email protected]


138


Recepción de datos de HL y CB de SITAM

Se recibe al día siguiente los datos de HL y CB de SITAM.

de [email protected];

Asunto Re: Extracción OC para cruce SITAM - DD/MM/YYYY

Achivos Adjuntos

HL_20110412.xlsCB_20110412.xls

Recibiremos los datos de SITAM en dos ficheros con el siguiente contenido:


138


Y para CB, el mismo formato:

138


Envío de datos de HL y CB de base de datos para los clientes recibidos por SITAM

Nos quedamos con la primera columna CUSTOMER_ID, eliminamos duplicados y la pegamos al ultraedit.

Pasamos el fichero a formato UNIX procurando dejar la última línea en blanco (es decir enter en la ultima fila).

Lo Guardamos en un .dat en formato ASCII en openp1/opencobp/CONTROL/UTIL/AUTO_CRUCE

FORMATOS: HL_YYYYMMDD.dat

CB_YYYYMMDD.dat

En la RUTA: /openp1/opencobp/CONTROL/UTIL/AUTO_CRUCE

EJECUTAMOS: ksh cruceSitam.paso3.sh [NOMBRE_CB] [NOMBRE_HL] [FECHA_CRUCE] &

Siendo FECHA_CRUCE la fecha en la cual realizamos el primer paso del cruce.

EJEMPLO: ksh cruceSitam.paso3.sh CB_20120321.dat HL_20120321.dat 20120320 &

Esto nos enviara un correo con ficheros adjuntos que contendrán los datos revisados.

Abrimos los datos revisado y los importamos a un fichero xls teniendo cuidado de que la columna CUST_CODE (CUENTA FORMATO LARGO) sea de tipo texto para que no se modifique.

Respondemos sobre el correo recibido de Sitam adjuntando los ficheros resultantes e indicando:

Buenos díasAdjuntamos los informes revisadosSaludos

Y resolvemos la remedy adjuntando esos mismos ficheros e indicando lo mismo.

Ya habría finalizado el cruce con Sitam

Ejecución del paso de forma manualEn caso de realizar esto manualmente, deberíamos seguir los siguientes pasos:

Con los datos recibidos de SITAM realizamos la consulta para comprobar que los ID de los usuarios tienen HL o CB. Los pasos son los siguientes:

a. Descarga al PC los dos ficheros en formato EXCEL del mail recibido.b. Seleccionamos la columna CUSTOMER_ID.

138


c. Nos llevamos los valores a Excel para ordenar dichos valores y eliminar duplicados. Ver anexo 1 (Orden y eliminación de valores en Excel).

d. Indicar esos valores entre los caracteres ´ y ´,Ver anexo 2 (Concatenar valores en Excel).

e. Se realizan las consultas de los HL y CB introduciendo de 1000 en 1000 los id tratados de los clientes enviados por SITAM:

Realizamos primero la consulta de los HL teniendo en cuenta que en la condición AND lc.id_cliente in () deben introducirse los ID de clientes de 1000 en 1000.

Cambiar la fecha del comentario

SELECT c.cuenta_formato_largo AS cust_code, lc.id_cliente, lc.tipo_cliente, lc.deuda, s.nombre AS segmento, 'NO_PROTEGIDO' AS condicion, 'NO' AS filtrado_x_tipo, TO_CHAR (MAX (rd.f_desconexion), 'DD/MM/YYYY') AS f_desconexion, TO_CHAR (MAX (rd.f_reconexion), 'DD/MM/YYYY') AS f_reconexion FROM lista_clientes lc, clientes c, re_segmentos s, re_desconexiones rd

138


WHERE lc.id_cliente = c.id_cliente AND c.external_id = rd.external_id AND lc.id_segmento = s.id_segmento AND rd.tipo_desc = 'IF011' -- IF011 PARA HL's Y IF012 PARA CB's AND c.radical_emp = lc.radical_emp AND c.radical_emp = s.radical_emp AND c.radical_emp = rd.radical_emp AND c.radical_emp = '01' AND rd.f_desconexion <= TO_DATE ('20110405', 'YYYYMMDD') -- PONER LA FECHA EN LA QUE SE HIZO EL CRUCE AND f_reconexion = TO_DATE ('29991231', 'YYYYMMDD') AND lc.deuda >= 1 AND lc.tipo_cliente NOT IN ('0P', '0Q', '0R', '0S', '0T', '0U', '0V', '0W', '0X', '0Y', '0Z') AND s.nombre NOT IN ('AUNAGGCC', 'AUT_FRAU', 'CORPORAT', 'DHA', 'EMP_FRAU', 'EMP_MEBA', 'EUSKAL', 'GCAAPP', 'GCCORP', 'GCGESTIO', 'GCGESTOR', 'GRANCUEN', 'MPO', 'PORTAB', 'RES_FRAU', 'ROAMPRE', 'STAPARCI', 'STATOTAL', 'VIPS', 'VIPS_EMP') AND c.REFERENCIA IN (SELECT DISTINCT r.referencia FROM recibos r, re_desconexiones rd WHERE rd.external_id = r.external_id AND rd.radical_emp = r.radical_emp AND r.radical_emp = '01' AND rd.f_reconexion = TO_DATE ('29991231', 'YYYYMMDD') AND r.id_factura = rd.id_factura AND (r.est_actu = 'RE001' OR EXISTS (SELECT * FROM recibos r2, re_historico rh WHERE r2.referencia = rh.referencia AND r2.f_fact = rh.f_fact AND r2.est_actu = 'RE001' AND rh.id_fichero = 'IF011' -- IF011 PARA HL's Y IF012 PARA CB's AND r2.referencia = r.referencia))) AND lc.id_cliente in () -- METER DE 1000 EN 1000 LOS ID_CLIENTESGROUP BY c.cuenta_formato_largo, lc.id_cliente, lc.tipo_cliente, lc.deuda, s.nombre;

138


Cargamos esos datos en un fichero de EXCEL que nombraremos HL_AÑOMESDIA_REVISADO.xls.Ejemplo de fichero enviado: HL_20110406_revisado.xls

Para recuperar los datos de las CB realizamos la siguiente query, teniendo en cuenta que en la condición AND lc.id_cliente in () deben introducirse los ID de clientes de 1000 en 1000.

--1ª query: Vamos pegando el resultado en una excel. Lanzamos de 1000 en 1000 --¡¡¡OJO!!! hay que cambiar los datos necesarios que se indican en la querySELECT c.cuenta_formato_largo AS cust_code, lc.id_cliente, lc.tipo_cliente, lc.deuda, s.nombre AS segmento, 'NO_PROTEGIDO' AS condicion, 'NO' AS filtrado_x_tipo, TO_CHAR (MAX (rd.f_desconexion), 'DD/MM/YYYY') AS f_desconexion, TO_CHAR (MAX (rd.f_reconexion), 'DD/MM/YYYY') AS f_reconexion FROM lista_clientes lc, clientes c, re_segmentos s, re_desconexiones rd WHERE lc.id_cliente = c.id_cliente AND c.external_id = rd.external_id AND lc.id_segmento = s.id_segmento AND rd.tipo_desc = 'IF012' -- IF011 PARA HL's Y IF012 PARA CB's AND c.radical_emp = lc.radical_emp AND c.radical_emp = s.radical_emp AND c.radical_emp = rd.radical_emp AND c.radical_emp = '01' AND rd.f_desconexion <= TO_DATE ('20110802', 'YYYYMMDD') -- PONER LA FECHA EN LA QUE SE HIZO EL CRUCE AND f_reconexion = TO_DATE ('29991231', 'YYYYMMDD') AND lc.deuda >= 1 AND lc.tipo_cliente NOT IN ('0P',

138


'0Q', '0R', '0S', '0T', '0U', '0V', '0W', '0X', '0Y', '0Z') AND s.nombre NOT IN ('AUNAGGCC', 'AUT_FRAU', 'CORPORAT', 'DHA', 'EMP_FRAU', 'EMP_MEBA', 'EUSKAL', 'GCAAPP', 'GCCORP', 'GCGESTIO', 'GCGESTOR', 'GRANCUEN', 'MPO', 'PORTAB', 'RES_FRAU', 'ROAMPRE', 'STAPARCI', 'STATOTAL', 'VIPS', 'VIPS_EMP') AND c.REFERENCIA IN (SELECT DISTINCT r.referencia FROM recibos r, re_desconexiones rd WHERE rd.external_id = r.external_id AND rd.radical_emp = r.radical_emp AND r.radical_emp = '01' AND rd.f_reconexion = TO_DATE ('29991231', 'YYYYMMDD') AND r.id_factura = rd.id_factura AND (r.est_actu = 'RE001' OR EXISTS (SELECT * FROM recibos r2, re_historico rh WHERE r2.referencia = rh.referencia AND r2.f_fact = rh.f_fact AND r2.est_actu = 'RE001' AND rh.id_fichero = 'IF012' -- IF011 PARA HL's Y IF012 PARA CB's AND r2.referencia = r.referencia))) AND lc.id_cliente in () -- METER DE 1000 EN 1000 LOS ID_CLIENTESGROUP BY c.cuenta_formato_largo, lc.id_cliente, lc.tipo_cliente, lc.deuda, s.nombre;

Cargamos esos datos en un fichero de EXCEL que nombraremos CB_AÑOMESDIA_REVISADO.xls.Ejemplo de fichero enviado: CB_20110406_revisado.xls

138


A continuación enviamos un correo de respuesta adjuntando estos dos ficheros EXCEL, indicando el siguiente texto:

Buenos días

Adjuntamos los informes revisados

Saludos

138


Anexo 1. Orden y eliminación de valores duplicados en Excel

Excel permite la opción de eliminar duplicados.

Para ello seleccionamos la columna a ordenar, que en este caso será CUSTOMER_ID

Nos lo llevamos a una pestaña nueva para tratar esa columna.

Eliminamos la fila con la cabecera “CUSTOMER_ID”

A continuación accedemos a la pestaña Datos Ordenar y filtrar, opción Avanzadas, donde nos aparecerá la un check con “Solo registros únicos”. Marcamos ese check.

138


138


Anexo 2. Concatenar valores en Excel.

Una vez hecho esto, sobre la primera fila y segunda columna escribimos ‘’ (Escribimos doble carácter ‘ para que en la celda se visualice uno), sobre la tercera celda escribimos ‘’, (doble carácter ‘ y una coma) y sobre la tercera celda escribimos =CONCATENAR(B1;A1;C1).

De tal forma que quedaría así:

A continuación pulsamos sobre la esquina inferior derecha de las celdas B1, C1 y D1, tras haber sido seleccionadas, con el objetivo de que se replique el mismo valor en su respectiva columna.

138


En la columna C ya tenemos los valores preparados para incluirlos en la cláusula IN de las consultas de comprobación para los clientes recibidos de SITAM

138


CORRECCIÓN DE DEVOLUCIONES ERRÓNEAS (Por estado incorrecto de remesas)

Nos llega un correo diario al buzón de cobros, incluyendo las devoluciones que se han cargado como erróneas en el sistema en el proceso de carga nocturna del bancario.

Para DE BLAS LOPEZ, Alberto; TOMAS GORGAS, Santiago; SOLOMANDO SANCHEZ, Francisco Javier Ext; TOLEDANO GARCIA, Carlos Ext; [email protected]; cobros movilcontrol

CCAsunto Resumen Devoluciones ErroneasBuenos días,

En el día de hoy 20110706 se han cargado las siguientes devoluciones erróneas con estas fechas de factura

NUMERO F_FACT------ ------ 9711 20110626 51 20110521 15 20110516 16 20110512 28 20110508 13 20110501 3 20110426

Una fecha de factura anterior a 31 días aproximadamente implica una devolución fuera de plazo.

Un Saludo.

Son preocupantes las devoluciones erróneas cuya fecha de factura es anterior a 31 días, porque implica que las remesas no se habrán pasado a “recepcionadas” después del envío de los recibos a los bancos. Por ejemplo, las que marcamos en rojo arriba.

SELECT count(*) FROM devolu_err WHERE f_fact = to_date('26/06/2011','DD/MM/YYYY');

Es probable de que la causa de que existan estas devoluciones erróneas anteriores a 31 días de forma tan elevada sea porque no se hayan pasado a “Recepcionadas” las remesas de un ciclo de facturación (el coincidente con la fecha de factura de las devoluciones erróneas) enviado al banco. Por tanto, nuestra primera tarea será validar el estado de las remesas del ciclo:

SELECT /*+ USE_HASH(rem r) */ REM.cod_cencobro AS cencobro, DECODE (REM.cod_cencobro, '104', 'CH PROPIOS', '105', 'CH AJENOS', '404', 'CM PROPIOS', '405', 'CM AJENOS', '504', 'BAN PROPIOS', '505', 'BAN AJENOS', '604', 'LA CAIXA PROPIOS', '605', 'LA CAIXA AJENOS', '704', 'SABADELL PROP', '705', 'SABADELL AJE', '804', 'TELECOR', '904', 'BBVA PROPIOS', '905', 'BBVA AJENOS', '1004', 'UNICAJA PROPIOS', '1005', 'UNICAJA AJENOS', '1304', 'BARCLAYS PROPIOS',

138


'1305', 'BARCLAYS AJENOS', '12804', 'BANK PROPIOS', '12805', 'BANK AJENOS' ) AS centro_cobro, REM.tipo_negocio AS tipo_negocio, REM.sec_remesa AS sec_rem, DECODE (REM.formato_largo, 'S', 'LARGO', 'CORTO') formato, REM.num_recibos AS numero_recibos, REM.imp_tot_rec AS importe_euros, DECODE (REM.est_remesa, 'RM005', 'Recepcionada', 'RM004', 'Peticionada', 'RM001', 'En formacion', 'RM003', 'Enviada', 'RM006', 'Vencida', 'RM007', 'Descuadrada', 'RM100', 'Bloqueada' ) AS estado_remesa, REM.f_env, REM.f_venc FROM remesas REM, recibos r WHERE r.f_fact = TO_DATE ('26/06/2011', 'DD/MM/YYYY') -- fecha del ciclo AND r.radical_emp = '01' AND REM.num_recibos > 0 AND REM.cod_cencobro <> '99999' AND REM.cod_cencobro <> '804' AND REM.f_iform IN (TO_DATE ('29/06/2011', 'DD/MM/YYYY'), -- primera formación TO_DATE ('29/06/2011', 'DD/MM/YYYY'), -- segunda formación TO_DATE ('30/06/2011', 'DD/MM/YYYY') -- cambio CCC ) AND REM.cod_cencobro = r.cod_cencobro AND REM.sec_remesa = r.sec_remesaGROUP BY REM.cod_cencobro, REM.sec_remesa, REM.num_recibos, REM.imp_tot_rec, REM.f_venc, REM.f_env, REM.est_remesa, REM.f_env, REM.tipo_negocio, REM.formato_largoORDER BY REM.est_remesa, REM.cod_cencobro;

Si las remesas están en estado “Enviada”, el problema es claro, y habrá que actualizar su estado a “Recepcionada”. En este caso se ejecutará el siguiente script de actualización:

UPDATE remesas SET est_remesa = 'RM005' WHERE (cod_cencobro, sec_remesa, radical_emp) IN ( SELECT cencobro, sec_rem, radical_emp FROM (SELECT /*+ USE_HASH(rem r) */ REM.cod_cencobro AS cencobro, DECODE (REM.cod_cencobro, '104', 'CH PROPIOS', '105', 'CH AJENOS', '404', 'CM PROPIOS', '405', 'CM AJENOS', '504', 'BAN PROPIOS', '505', 'BAN AJENOS', '604', 'LA CAIXA PROPIOS', '605', 'LA CAIXA AJENOS', '704', 'SABADELL PROP', '705', 'SABADELL AJE', '804', 'TELECOR', '904', 'BBVA PROPIOS', '905', 'BBVA AJENOS', '1004', 'UNICAJA PROPIOS', '1005', 'UNICAJA AJENOS', '1304', 'BARCLAYS PROPIOS', '1305', 'BARCLAYS AJENOS', '12804', 'BANK PROPIOS', '12805', 'BANK AJENOS' ) AS centro_cobro, REM.tipo_negocio AS tipo_negocio, REM.sec_remesa AS sec_rem, DECODE (REM.formato_largo, 'S', 'LARGO', 'CORTO'), REM.num_recibos AS numero_recibos,

138


REM.imp_tot_rec AS importe_euros, DECODE (REM.est_remesa, 'RM005', 'Recepcionada', 'RM004', 'Peticionada', 'RM001', 'En formacion', 'RM003', 'Enviada', 'RM006', 'Vencida', 'RM007', 'Descuadrada', 'RM100', 'Bloqueada' ) AS estado_remesa, REM.f_env, REM.f_venc FROM remesas REM, recibos r WHERE r.f_fact = TO_DATE ('26/06/2011', 'DD/MM/YYYY') -- fecha del ciclo AND r.radical_emp = '01' AND REM.num_recibos > 0 AND REM.cod_cencobro <> '99999' AND REM.cod_cencobro <> '804' AND REM.f_iform IN (TO_DATE ('29/06/2011', 'DD/MM/YYYY'), -- primera formación TO_DATE ('29/06/2011', 'DD/MM/YYYY'), -- segunda formación TO_DATE ('30/06/2011', 'DD/MM/YYYY') -- cambio CCC ) AND REM.cod_cencobro = r.cod_cencobro AND REM.sec_remesa = r.sec_remesa GROUP BY REM.cod_cencobro, REM.sec_remesa, REM.num_recibos, REM.imp_tot_rec, REM.f_venc, REM.f_env, REM.est_remesa, REM.f_env, REM.tipo_negocio, REM.formato_largo ORDER BY REM.est_remesa, REM.cod_cencobro))

En caso de que el problema haya sido no haber pasado a recepcionadas las remesas, probablemente los recibos estarán en estado “pendiente de abono banco” hasta el pase de recobro del día siguiente. La contingencia no se podrá aplicar de forma inmediata. Si los recibos vinculados a las remesas ya estuviesen en estado “cobrado” se podrá aplicar la contingencia.

Contingencia

MUY IMPORTANTE: Avisar a Negocio antes de aplicar la contingencia.

Para resolver estas devoluciones se deberá generar un archivo en texto plano con las devoluciones erróneas. Las exportaremos a un fichero de texto plano que se guardará en formato UNIX (opción de conversión DOS a UNIX de ultraedit). Para ello utilizaremos la siguiente consulta:

SELECT cli.id_cliente || ' ' || to_char(de.f_fact, 'YYYYMMDD') cliente_fechaFROM devolu_err de, clientes cliWHERE de.referencia = cli.referenciaAND de.radical_emp = cli.radical_empAND de.f_fact = to_date('26/06/2011','DD/MM/YYYY');

Guardamos el archivo como:

-Texto: ASCII-formato: UNIX-tipo: .TXT-nombre: dev_erroneas_YYYYMMDD (de hoy)

138


Debemos tener en cuenta los siguientes aspectos MUY IMPORTANTES:- Antes de lanzar el proceso deberemos validar que no existe ningún fichero de devoluciones en la

ruta de descarga de ficheros de EDITRAN. Habitualmente el proceso lo lanzaremos en horario de oficina, por lo que es probable que en la ruta esté el fichero de La Caixa que habremos descargado por la mañana. /openp1/opencobp/editran/devolucion

Por ejemplo:-rw-rw-r-- 1 openpftp cobros 1855755 Jul 06 07:57 ITR.ITR04257.F1706.H052352.devo1.20110706

- Así pues, el fichero de devoluciones de La Caixa lo moveremos a una ruta neutra. Por ejemplo:/openp1/opencobp/everis

MUY IMPORTANTE. No debemos olvidarnos, una vez lanzado el proceso de carga de devoluciones erróneas, de que los ficheros de devoluciones que existiesen previamente en /openp1/opencobp/editran/devolucion se deberán volver a depositar de nuevo en esta ruta para que los cargue el bancario.

- Una vez realizadas las tareas anteriores se copiará el fichero generado en la ruta:/openp1/opencobp/CONTROL/RECOBRO/DEVOLUCIONES_ERRONEAS/in

- Se lanza el proceso que marca las devoluciones erróneas para que sean tratadas por el recobro del día siguiente:/openp1/opencobp/CONTROL/RECOBRO/DEVOLUCIONES_ERRONEAS/exeMUY IMPORTANTE: Lanzaremos el proceso sin nohup.DevErroneas.ksh

Elegimos opción 1

El proceso tardará un tiempo en ejecutarse dependiendo del número de devoluciones.

Para validar que la carga de devoluciones erróneas ha sido correcta podemos realizar las siguientes comprobaciones. Tomamos un cliente y le quitamos los ceros.

138


Lo metemos en el 2N

Si existe el recibo en estado “Recibo devuelto por ON-LINE” para la fecha de factura correspondiente, indicará que el proceso ha sido correcto.

Una vez marcadas las devoluciones erróneas, el recobro las tratará y quedarán reflejadas en el informe de devoluciones del día siguiente.

Las devoluciones realizadas por este procedimiento se deben reportar a RAID para sus cruces segmentados por centro de cobro.


ENVÍO DEL CORREO A RAIDTras cargar las devoluciones erróneas es necesario enviar un correo a RAID informándoles de que tendrán disponible la información de las devoluciones ejecutadas de forma manual al día siguiente.

138


La fecha del asunto se corresponde con el día después de haber lanzado el proceso de carga de las devoluciones erróneas. Debemos tener en cuenta que la carga real de devoluciones se realiza después del recobro. Así pues:

- Si enviamos el correo a RAID el mismo día en que impulsamos la carga de las devoluciones erróneas el correo será:

cobros movilcontrol [email protected]; RUIZ GARCIA, Javier Ext [email protected]; cobros movilcontrol <[email protected]>; ES,

Soporte.revenue <[email protected]>;

Devoluciones Manuales DD/MM/YYYY (Fecha de mañana)Buenos días, El DD/MM/YYYY (Fecha de mañana) se procesarán las siguientes devoluciones solicitadas por finanzas:


104 Central Hispano (Propio) 6981.94

105 Central Hispano (Ajeno) 22490.89

404 Caja Madrid (Propio) 4798.45

405 Caja Madrid (Ajeno) 6043.68

504 Banesto (Propio) 8071.48

505 Banesto (Ajeno) 4767.54


904 Bilbao Vizcaya (Propio) 11959.93

905 Bilbao Vizcaya (Ajeno) 16942.94

1004 Unicaja (Propio) 1172.93

1005 Unicaja (Ajeno) 3800.58

Un Saludo

- Si enviamos el correo a RAID al día siguiente de impulsar la carga de las devoluciones erróneas el correo será:

cobros movilcontrol [email protected]; RUIZ GARCIA, Javier Ext

[email protected]; ES, Soporte.revenue <[email protected]>;

Devoluciones Manuales DD/MM/YYYY (Fecha de hoy)Buenos días, El DD/MM/YYYY (Fecha de hoy) se han procesado las siguientes devoluciones solicitadas por finanzas:















138







Un Saludo

El cuerpo del correo con el detalle de las devoluciones erróneas cargadas manualmente lo obtendremos del archivo Raid_20110811135057.csv ubicado en la ruta de LOG del proceso /openp1/opencobp/CONTROL/RECOBRO/DEVOLUCIONES_ERRONEAS/log

138


CORRECCIÓN DE DEVOLUCIONES ERRÓNEAS (Por solicitud de finanzas)

El caso es similar al anterior, salvo que el área de finanzas nos envía un correo con un excel indicando las devoluciones erróneas que pretende que se incorporen al sistema como devoluciones normales. Finanzas abre una petición Webco que se traduce en una Remedy del siguiente tipo:

Se compone el fichero de la misma forma que en el caso anterior, generando un archivo con los datos de las columnas C (ID_CLIENTE) y D (F_FACT) y se lanza el proceso teniendo en cuenta las restricciones con respecto a la existencia de ficheros de carga de devoluciones en la ruta /openp1/opencobp/editran/devolucion.

El contenido de la Excel deberá contener, de forma aproximada, los datos de la siguiente consulta:

SELECT cli.id_cliente || ' ' || to_char(de.f_fact, 'YYYYMMDD') cliente_fecha, impor_dev

138


FROM devolu_err de, clientes cliWHERE de.referencia = cli.referenciaAND de.radical_emp = cli.radical_empAND de.f_fact >= to_date('25/05/2011','DD/MM/YYYY') -- Menor f_fact de la excelAND de.f_fact <= to_date('30/06/2011','DD/MM/YYYY') -- Mayor f_fact de la excelAND de.f_devol >= to_date('27/07/2011','DD/MM/YYYY') -- Menor f_devol de la excelAND de.f_devol <= to_date('10/08/2011','DD/MM/YYYY') -- Mayor f_devol de la excelorder by impor_dev asc

Guardamos el archivo como:

-Texto: ASCII-formato: UNIX-tipo: .TXT-nombre: dev_erroneas_YYYYMMDD (de hoy)

Debemos tener en cuenta los siguientes aspectos MUY IMPORTANTES:

- Antes de lanzar el proceso deberemos validar que no existe ningún fichero de devoluciones en la ruta de descarga de ficheros de EDITRAN. Habitualmente el proceso lo lanzaremos en horario de oficina, por lo que es probable que en la ruta esté el fichero de La Caixa que habremos descargado por la mañana. /openp1/opencobp/editran/devolucion

Por ejemplo:-rw-rw-r-- 1 openpftp cobros 1855755 Jul 06 07:57 ITR.ITR04257.F1706.H052352.devo1.20110706

- Así pues, el fichero de devoluciones de La Caixa lo moveremos a una ruta neutra. Por ejemplo:/openp1/opencobp/everis


- Una vez realizadas las tareas anteriores se copiará el fichero generado en la ruta:/openp1/opencobp/CONTROL/RECOBRO/DEVOLUCIONES_ERRONEAS/in

- Se lanza el proceso que marca las devoluciones erróneas para que sean tratadas por el recobro del día siguiente:/openp1/opencobp/CONTROL/RECOBRO/DEVOLUCIONES_ERRONEAS/exeMUY IMPORTANTE: Lanzaremos el proceso sin nohup.DevErroneas.ksh

138


Elegimos opción 1

El proceso tardará un tiempo en ejecutarse dependiendo del número de devoluciones.

Para validar que la carga de devoluciones erróneas ha sido correcta podemos realizar las siguientes comprobaciones. Tomamos un cliente y le quitamos los ceros.

Lo metemos en el 2N

138


Si existe el recibo en estado “Recibo devuelto por ON-LINE” para la fecha de factura correspondiente, indicará que el proceso ha sido correcto.

Una vez marcadas las devoluciones erróneas, el recobro las tratará y quedarán reflejadas en el informe de devoluciones del día siguiente.

Las devoluciones realizadas por este procedimiento se deben reportar a RAID para sus cruces segmentados por centro de cobro.


ENVÍO DEL CORREO A RAIDTras cargar las devoluciones erróneas es necesario enviar un correo a RAID informándoles de que tendrán disponible la información de las devoluciones ejecutadas de forma manual al día siguiente.

La fecha del asunto se corresponde con el día después de haber lanzado el proceso de carga de las devoluciones erróneas. Debemos tener en cuenta que la carga real de devoluciones se realiza después del recobro. Así pues:

- Si enviamos el correo a RAID el mismo día en que impulsamos la carga de las devoluciones erróneas el correo será:

cobros movilcontrol [email protected]; RUIZ GARCIA, Javier Ext [email protected]; cobros movilcontrol <[email protected]>; ES,

Soporte.revenue <[email protected]>;

Devoluciones Manuales DD/MM/YYYY (Fecha de mañana)Buenos días, El DD/MM/YYYY (Fecha de mañana) se procesarán las siguientes devoluciones solicitadas por finanzas:













Un Saludo





138


- Si enviamos el correo a RAID al día siguiente de impulsar la carga de las devoluciones erróneas el correo será:

cobros movilcontrol [email protected]; RUIZ GARCIA, Javier Ext

[email protected]; ES, Soporte.revenue <[email protected]>;

Devoluciones Manuales DD/MM/YYYY (Fecha de hoy)Buenos días, El DD/MM/YYYY (Fecha de hoy) se han procesado las siguientes devoluciones solicitadas por finanzas:













Un Saludo

El cuerpo del correo con el detalle de las devoluciones erróneas cargadas manualmente lo obtendremos del archivo Raid_20110811135057.csv ubicado en la ruta de LOG del proceso /openp1/opencobp/CONTROL/RECOBRO/DEVOLUCIONES_ERRONEAS/log

Cerrar REMEDY

Resolveremos la remedy que nos hayan abierto indicando en el detalle de la solución el texto inicial del archivo de LOG del proceso. El archivo de LOG LOG_CBCCAM312_20110811135057.log está ubicado en la ruta /openp1/opencobp/CONTROL/RECOBRO/DEVOLUCIONES_ERRONEAS/log:

Por ejemplo:

Hemos tratado las devoluciones solicitadas a excepción de las siguientes facturas que han sido rectificadas y no pueden devolverse directamente.

REFERENCIA F_FACT SEC_RECIBO COD_CENCOBRO SEC_REMESA 000035847879 20110426 1 0 0 000036871805 20110512 1 0 0 000015587827 20110508 1 0 0 000034624952 20110508 1 0 0 000025383375 20110516 1 0 0




138


un saludo.

138


EJECUCIÓN DE BAJAS POR IMPAGO EN ORIGEN (42007)

Ver sesiones de Formación de Indra (Recobro II). Regularmente los usuarios de negocio nos envían un correo para que publiquemos las bajas por impago en origen a final de mes. El correo incluye dos archivos adjuntos: bajas por impago de personal y de empresas.

De LÓPEZ ARNAL, José Enrique


Asunto Ejecución bajas impago en origen - Junio 2011

Hola, Os mando los ficheros con las bajas por impago en origen, correspondientes al mes de Junio. Fichero_bajas_ejecutadas_JUNIO_FRAUDE_SUSC_EMP.xls -> 125 clientes 320 líneas.Fichero_bajas_ejecutadas_JUNIO_FRAUDE_SUSC_RES.xls -> 1.858 clientes 2.361 líneas. Por favor confirmarnos cuando se programe su ejecución, siendo imprescindible de cara a cumplir con el calendario aprobado que las bajas se ejecuten durante el día de hoy. Un saludo.José Enrique López

Cogemos la columna A de ambos ficheros y las colocamos en un archivo de ULTRAEDIT. Activamos el modo columna y reemplazamos el salto de carro del final ^p por #323^p

El resultado será:1.46110203#3231.45782460#3231.45704182#3231.45840496#3231.45720327#323….

Guardamos el archivo en modo UNIX en nuestro local como bajas_YYYYMMDD.dat y lo trasladamos al servidor a la siguiente ruta:/openp1/opencobp/opensgc/secuencial/filtradobajas/in

A continuación se pasa el proceso que descarta los recibos que cumplen determinadas condiciones, por ejemplo, cuya deuda sea menor de 1€.

138


/openp1/opencobp/control_m/execnohup OPEN_230_24H_PROC_001_filtradobajas.ksh &

El proceso el proceso reformatea el contenido y el nombre del fichero y lo mueve a la ruta:/openp1/opencobp/opensgc/secuencial/filtradobajas/out El nuevo nombre del fichero será: MDW-42007-15375520110627_230.dat

Contamos el número de eventos que se van a publicar, para indicarlo después en el fichero eventos.conf:wc –l MDW-42007-15375520110627_230.dat

Llamamos a BSCS online (656161677) para avisarles de que se van a publicar los eventos. Les sugerimos la publicación habitual de 60 eventos por minuto.

Modificamos el fichero de configuración de publicación de eventos NO PLANIFICADOS indicando el número de eventos que 42007 que se van a publicar:/openp1/opencobp/opensgc/secuencial/middleware/execvi Antes_Recobro_eventos.conf

Por ejemplo, en el caso inferior, pondremos a 0 todos los eventos, salvo los NNNN eventos 42007 que pretendemos publicar inmediatamente.CBCCAM50#42007#0#0|000001#1983CBCCAM50#42001#0#0|000009#0CBCCAM50#42013#4#0|000003#0CBCCAM50#42004#0#0|000004#0CBCCAM50#42011#0#0|000005#0CBCCAM52#13003#7#0|000006#0

Sólo como inciso informativo, los eventos planificados se configuran en:/openp1/opencobp/CONTROL/RECOBRO/ENVIAR_EVENTOS/cfgvi eventos.conf

Por ejemplo, en el caso inferior, pondremos a 0 el número de eventos 42001 del Lunes, que se publican automáticamente en los rangos horarios que tienen establecidos, y se indicará el número de eventos 42007 que se van a publicar.

L#42001#10000L#42004#0L#42007#0L#42011#0M#42001#0M#42004#10000M#42007#0M#42011#3X#42001#0X#42004#10000X#42007#0X#42011#0J#42001#0J#42004#10000J#42007#0J#42011#0V#42001#0V#42004#0V#42007#0V#42011#9S#42001#0S#42004#10000S#42007#0S#42011#0D#42001#0D#42004#0

138


D#42007#0D#42011#0

La cadencia que nos haya provisto BSCS se modifica en BBDD, en la tabla PARAMETERS_TO_BSCS. Los parámetros que nos interesa modificar son:

- F_H_EJEC_42007 Cadencia provista por BSCS. Una cadencia de 1 indica 1 evento al segundo.- ULTIMA_FECHA_42007 Fecha a partir de la que queremos publicar

select *from parameters_to_bscswhere id_parametro in ('F_H_EJEC_42007', 'ULTIMA_FECHA_42007')

UPDATE parameters_to_bscs SET valor_parametro = '20110627 170000' WHERE id_parametro = 'ULTIMA_FECHA_42007' AND programa = 'CBCCAM50' AND radical_emp = '01';

Desde la ruta donde se haya generado el fichero, lo movemos el fichero a la ruta de tratamiento:Ruta de origen: /openp1/opencobp/opensgc/secuencial/filtradobajas/outmv MDW-42007-15375520110627_230.dat /openp1/opencobp/opensgc/secuencial/middleware/in

Podemos publicar de dos formas diferentes:- Respetando la hora que hemos indicado en PARAMETERS_TO_BSCS.

Desde la ruta:openp1/opencobp/opensgc/secuencial/middleware/execnohup OPEN_BIN_24H_PROC_001_EventosAntesRecobro_programados.ksh &

- Comenzando a publicar inmediatamente.Desde la ruta:openp1/opencobp/opensgc/secuencial/middleware/execnohup OPEN_BIN_24H_PROC_001_EventosAntesRecobro.ksh &

Para la publicación de bajas por impago se suele publicar inmediatamente.

El log del proceso, de tipo CBCCAM50_20110629102132.LOG está en la ruta /openp1/opencobp/opensgc/secuencial/middleware/log. Es probable que el proceso 50 intente publicar otros eventos si existen ficheros de HLs, CBs, o cualquier otro. Aunque si hacemos “pr”cabe la posibilidad de que el proceso esté tratando un archivo diferente del que hemos movido no nos preocuparemos si hemos corregido el fichero de configuración correctamente. El proceso lo que hará será tratar todos los archivos presentes para su tratamiento y sólo los tratará de forma efectiva si en el archivo de configuración hemos marcado eventos por tratar. Estos archivos el proceso los dejará como _PDTE, para su tratamiento por los procesos nocturnos.

En el log podremos ver el número de registros tratados e insertados en las tablas de eventos de MDW para su publicación:

138


**************Tratados: 4015Insertados: 4015Pendientes: 4015****************************Insertados: 4015**************Se han tratado 4015 clientesCBCCAM50_Cerrar_fichero_entrada: InicioFichero cerradoCBCCAM50_Cerrar_fich_insertados: InicioFichero cerradoLos Depurados son: 0CBCCAM50_Escribir_fichero_segmentación: Iniciogi_residenciales=0gi_empresa_depurados=0gi_totales_depurados=0CBCCAM50_Abrir_archivo_segmentacion: InicioSe ha abierto el fichero :MDW-42007-09561620110629_230.dat.segLa línea a escribir es: DEPURADOS@RES@0@EMP@0@TOTALES@0TRATADOS@RES@2067@EMP@1943@TOTALES@4015GENERADOS@RES@2067@EMP@1943@TOTALES@4020MDW-42007-09561620110629_230.dat

CBCCAM50_Hacer_commit: InicioTERMINOBIEN

Terminar distinto de 0Se ha tratado el fichero MDW-42007-09561620110629_230.datSe ha tratado el maximo

Validaremos que los eventos se han insertado correctamente en BBDD y que se están publicando:

SELECT count(*), estado_envioFROM table_x_ae_eventosWHERE referencia = '42007'AND fecha_hora_ejecucion >= TO_DATE ('27/06/2011 00:00:00', 'DD/MM/YYYY HH24:MI:SS')GROUP BY estado_envio;

Por último enviaremos un correo informativo a quien haya solicitado la ejecución de bajas por impago para informarle de cuál ha sido el estado de la publicación de bajas, pidiéndole orientación sobre qué se debe hacer con las bajas cuya publicación ha sido errónea.


Para LÓPEZ ARNAL, José Enrique

Asunto RE: Ejecución bajas impago en origen - Junio 2011

Buenas tardes,

Se ha procedido a ejecutar la publicación de bajas por impago en origen, con los siguientes resultados:Bajas intentadas: <suma de las bajas del fichero inicial>Bajas filtradas: <wc –l del fichero MDW-42007-15375520110627_230.dat >Bajas publicadas con resultado OK de BSCS: <Eventos en estado 4 de la consulta sobre table_x_ae_eventos >Bajas publicadas con resultado KO de BSCS: <Eventos en estado 6 de la consulta sobre table_x_ae_eventos >

Un saludo.

Es probable que, además de los ficheros de empresas y de residencial, el área de negocio nos envíe un fichero RPV. La baja por impago de estos clientes no se puede ejecutar directamente desde cobros, por lo que deberemos abrir una petición remedy al grupo de GC FACTURACIÓN 1 para que las impulsen ellos directamente. Por ejemplo: HD1000003175367.

138


EJECUCIÓN DE BAJAS POR IMPAGO (42007)

Ver sesiones de Formación de Indra (Recobro II). Regularmente los usuarios de negocio nos envían un correo para que publiquemos las bajas por impago a final de mes. El correo incluye tres archivos y excepcionalmente un 4º: bajas por impago de personal y de empresas.

De LÓPEZ ARNAL, José Enrique


Asunto Ejecución bajas impago en origen - Junio 2011

Hola, Os mando los ficheros con las bajas por impago, correspondientes al mes de Junio. 1.- Fichero_bajas_ejecutadas_JUNIO_EMP.xls -> 1.911 clientes 4.517 líneas.2.- Fichero_bajas_ejecutadas_JUNIO_RES.xls -> 10.221 clientes 13.039 líneas.3.- Fichero_bajas_extra_JUNIO_EMP.xls -> 41 clientes 195 líneas.

4.- Fichero_bajas_extra_RPV_JUNIO_EMP.xls -> 156 clientes 1.105 líneas – Muy importante, este fichero hay que tratarlo al ser clientes 4. fuera del proceso normal de baja, para ello deberéis solicitar al equipo de BSCS, que ejecuten directamente la baja de los servicio, teniendo en cuenta que la baja debe cursarse en sistemas antes del día 30 de Junio.

Por favor confirmarnos cuando se programe su ejecución.

Un saludo.José Enrique López

Cogemos la columna A de ambos ficheros y las colocamos en un archivo de ULTRAEDIT. Activamos el modo columna y reemplazamos el salto de carro del final ^p por #91^p

El resultado será:1.46110203#3231.45782460#3231.45704182#3231.45840496#3231.45720327#323….

Guardamos el archivo en modo UNIX en nuestro local como bajas_YYYYMMDD.dat y lo trasladamos al servidor a la siguiente ruta:/openp1/opencobp/opensgc/secuencial/filtradobajas/in

138


A continuación se pasa el proceso que descarta los recibos que cumplen determinadas condiciones, por ejemplo, cuya deuda sea menor de 1€.

/openp1/opencobp/control_m/execnohup OPEN_230_24H_PROC_001_filtradobajas.ksh &

El proceso el proceso reformatea el contenido y el nombre del fichero y lo mueve a la ruta:/openp1/opencobp/opensgc/secuencial/filtradobajas/out El nuevo nombre del fichero será: MDW-42007-15375520110627_230.dat

Contamos el número de eventos que se van a publicar, para indicarlo después en el fichero eventos.conf:wc –l MDW-42007-15375520110627_230.dat

Llamamos a BSCS online (656161677) para avisarles de que se van a publicar los eventos. Les sugerimos la publicación habitual de 60 eventos por minuto.

Modificamos el fichero de configuración de publicación de eventos NO PLANIFICADOS indicando el número de eventos que 42007 que se van a publicar:/openp1/opencobp/opensgc/secuencial/middleware/execvi Antes_Recobro_eventos.conf

Por ejemplo, en el caso inferior, pondremos a 0 todos los eventos, salvo los NNNN eventos 42007 que pretendemos publicar inmediatamente.CBCCAM50#42007#0#0|000001#1983CBCCAM50#42001#0#0|000009#0CBCCAM50#42013#4#0|000003#0CBCCAM50#42004#0#0|000004#0CBCCAM50#42011#0#0|000005#0CBCCAM52#13003#7#0|000006#0

Sólo como inciso informativo, los eventos planificados se configuran en:/openp1/opencobp/CONTROL/RECOBRO/ENVIAR_EVENTOS/cfgvi eventos.conf

Por ejemplo, en el caso inferior, pondremos a 0 el número de eventos 42001 del Lunes, que se publican automáticamente en los rangos horarios que tienen establecidos, y se indicará el número de eventos 42007 que se van a publicar.

L#42001#10000L#42004#0L#42007#0L#42011#0M#42001#0M#42004#10000M#42007#0M#42011#3X#42001#0X#42004#10000X#42007#0X#42011#0J#42001#0J#42004#10000J#42007#0J#42011#0V#42001#0V#42004#0V#42007#0V#42011#9S#42001#0

138


S#42004#10000S#42007#0S#42011#0D#42001#0D#42004#0D#42007#0D#42011#0

La cadencia que nos haya provisto BSCS se modifica en BBDD, en la tabla PARAMETERS_TO_BSCS. Los parámetros que nos interesa modificar son:

- F_H_EJEC_42007 Cadencia provista por BSCS. Una cadencia de 1 indica 1 evento al segundo. En caso de que nos dijeran una cadencia de 30, deberíamos entender 1 cada dos segundos y por tanto actualizaríamos el campo VALOR_PARAMETRO a 2. Actualizando a 1 nuevamente cuando acabe la publicación.

- ULTIMA_FECHA_42007 Fecha a partir de la que queremos publicar

select *from parameters_to_bscswhere id_parametro in ('F_H_EJEC_42007', 'ULTIMA_FECHA_42007')

UPDATE parameters_to_bscs SET valor_parametro = '20110627 170000' WHERE id_parametro = 'ULTIMA_FECHA_42007' AND programa = 'CBCCAM50' AND radical_emp = '01';

Desde la ruta donde se haya generado el fichero, lo movemos el fichero a la ruta de tratamiento:Ruta de origen: /openp1/opencobp/opensgc/secuencial/filtradobajas/outmv MDW-42007-15375520110627_230.dat /openp1/opencobp/opensgc/secuencial/middleware/in

Podemos publicar de dos formas diferentes:- Respetando la hora que hemos indicado en PARAMETERS_TO_BSCS.

Desde la ruta:/openp1/opencobp/opensgc/secuencial/middleware/execnohup OPEN_BIN_24H_PROC_001_EventosAntesRecobro_programados.ksh &

- Comenzando a publicar inmediatamente.Desde la ruta:/openp1/opencobp/opensgc/secuencial/middleware/execnohup OPEN_BIN_24H_PROC_001_EventosAntesRecobro.ksh &

Para la publicación de bajas por impago se suele publicar inmediatamente.

El log del proceso, de tipo CBCCAM50_20110629102132.LOG está en la ruta /openp1/opencobp/opensgc/secuencial/middleware/log. Es probable que el proceso 50 intente publicar otros eventos si existen ficheros de HLs, CBs, o cualquier otro. Aunque si hacemos “pr”cabe la posibilidad de que el proceso esté tratando un archivo diferente del que hemos movido no nos preocuparemos si hemos

138


corregido el fichero de configuración correctamente. El proceso lo que hará será tratar todos los archivos presentes para su tratamiento y sólo los tratará de forma efectiva si en el archivo de configuración hemos marcado eventos por tratar. Estos archivos el proceso los dejará como _PDTE, para su tratamiento por los procesos nocturnos.

En el log podremos ver el número de registros tratados e insertados en las tablas de eventos de MDW para su publicación:

**************Tratados: 4015Insertados: 4015Pendientes: 4015****************************Insertados: 4015**************Se han tratado 4015 clientesCBCCAM50_Cerrar_fichero_entrada: InicioFichero cerradoCBCCAM50_Cerrar_fich_insertados: InicioFichero cerradoLos Depurados son: 0CBCCAM50_Escribir_fichero_segmentación: Iniciogi_residenciales=0gi_empresa_depurados=0gi_totales_depurados=0CBCCAM50_Abrir_archivo_segmentacion: InicioSe ha abierto el fichero :MDW-42007-09561620110629_230.dat.segLa línea a escribir es: DEPURADOS@RES@0@EMP@0@TOTALES@0TRATADOS@RES@2067@EMP@1943@TOTALES@4015GENERADOS@RES@2067@EMP@1943@TOTALES@4020MDW-42007-09561620110629_230.dat

CBCCAM50_Hacer_commit: InicioTERMINOBIEN

Terminar distinto de 0Se ha tratado el fichero MDW-42007-09561620110629_230.datSe ha tratado el maximo

Validaremos que los eventos se han insertado correctamente en BBDD y que se están publicando:

SELECT count(*), estado_envioFROM table_x_ae_eventosWHERE referencia = '42007'AND fecha_hora_ejecucion >= TO_DATE ('27/06/2011 00:00:00', 'DD/MM/YYYY HH24:MI:SS')GROUP BY estado_envio;

Por último enviaremos un correo informativo a quien haya solicitado la ejecución de bajas por impago para informarle de cuál ha sido el estado de la publicación de bajas, pidiéndole orientación sobre qué se debe hacer con las bajas cuya publicación ha sido errónea.


Para LÓPEZ ARNAL, José Enrique

Asunto RE: Ejecución bajas impago en origen - Junio 2011

Buenas tardes,

Se ha procedido a ejecutar la publicación de bajas por impago en origen, con los siguientes resultados:Bajas intentadas: <suma de las bajas del fichero inicial>Bajas filtradas: <wc –l del fichero MDW-42007-15375520110627_230.dat >Bajas publicadas con resultado OK de BSCS: <Eventos en estado 4 de la consulta sobre table_x_ae_eventos >Bajas publicadas con resultado KO de BSCS: <Eventos en estado 6 de la consulta sobre table_x_ae_eventos >

Un saludo.

138


EJECUCIÓN DE BAJAS POR IMPAGO DE CLIENTES FUSION (42007)

Similar a la publicación de bajas por impago.

La única diferencia con respecto a la publicación de bajas por impago consiste en que los clientes que se hayan publicado de forma errónea en BSCS (estado 6 en las tablas de MDW) se los tendremos que enviar a negocio para su tratamiento. Estos datos los obtendremos con la siguiente consulta:

SELECT REPLACE (SUBSTR (b.parametro, INSTR (b.parametro, '<CustId>'), ( INSTR (b.parametro, '</CustId>') - INSTR (b.parametro, '<CustId>') ) ), '<CustId>000', '' ) AS custid, a.referencia AS referencia, c.codigo_error AS codigo_error, a.fecha_hora_ejecucion AS fc_ejecucion, c.descripcion_error FROM table_x_ae_eventos a, table_x_ae_datos b, table_x_ae_resp c WHERE a.objid = b.x_mid_datos2x_mid_event AND a.objid = c.x_mid_resp2x_mid_event AND a.estado_envio = 6 AND a.referencia = '42007' AND c.fecha_hora_respuesta >= TO_DATE ('20110728 13:00:00', 'YYYYMMDD HH24:MI:SS') AND c.fecha_hora_respuesta <= TO_DATE ('20110728 14:30:00', 'YYYYMMDD HH24:MI:SS');

Exportamos los datos y los adjuntamos en una Excel que anexamos al correo.

138


SUBIDA DE ASNEF

Todos los jueves cuando llegue el siguiente sms al móvil de guardia:

“El proceso de generación del fichero de Asnef ha terminado con exito”

O el siguiente correo:

Llamamos a Control_m Argentina al número 917147847 diciéndoles que ejecuten la cadena Envio_ASNEF.ksh del

grupo ENVIAR_ASNEF de la aplicación COBROS_AP. La persona que nos atiende al teléfono nos puede decir que la petición la hagamos también por email. Entonces escribiremos un email a [email protected] como el siguiente:

Para [email protected]

Asunto Ejecución de cadena de producción

Buenos días,

Solicitamos la ejecución de la cadena Envio_Asnef.ksh del grupo Enviar_ASNEF de la aplicación COBROS_AP.

Gracias.

Un saludo.


138


Si en este número te sale el contestador automático, colgamos y llamamos al 917147965 (CPD) y les decimos que si nos pueden pasar con Control_m Argentina y entonces la siguiente persona que nos saldrá hablando ya será de Control_m Argentina. Y si no pues ya llamamos a Control-m España 915294221 y les pedimos a ellos que lancen la cadena.

Una vez que se ha terminado de ejecutar la cadena nos enviarán un sms indicándonos si el proceso ha ido bien o mal.

Si el proceso ha ido bien el sms será:

“Ha finalizado el proceso de envío del fichero ASNEF a EquiFax por EDItran”

Si el proceso ha ido mal el sms será:

“Ha fallado el proceso de envío del fichero ASNEF a EquiFax por EDItran”

En este caso también nos abrirán una remedy indicándonos el porqué del fallo (En este caso):

HD1000003094558

FALLO EL JOB EnvioAsnef.ksh DEL GRUPO ENVIAR_ASNEF DE LA APLICACION COBROS_AP

SYSOUT+ /ora_data3/editran/control_m/exec/OPEN_ASN_24H_PROC_001_EnvioAsnef.kshexit 1

Para saber que ha ocurrido en el proceso podemos hacer dos cosas:

- Meternos en el servidor de EDITRAN una vez allí ir a la ruta: cd LOGS

Y allí buscar el fichero de logs de Asnef que se va a llamar FOTOES_fechaActual, en este caso FOTOES_20110609. Hacemos un more del fichero para ver las trazas. Al final de este fichero nos viene el mensaje de error:

“IMPOSIBLE ESTABLECER CONEXION CON EDITRAN REMOTO de EMISION”

- Otra forma de verlo es metiéndonos en el servidor de EDITRAN y yendo a la ruta:

cd SOURCE

Y allí ejecutar el menup. Una vez metidos en el menúp escpgemos la opción 2 “CONSULTA DE FICHEROS” y allí volvemos a escoger la opción 2 “CONSULTA DE LOG”. Una vez allí nos pedirá la sesión, la fecha y la hora. Para Asnef la sesión es “008335FOTOES”y la fecha y la hora serán a la que se ha empezado a ejecutar el proceso. Una vez metidos estos datos, se nos mostrarán las trazas de dicho proceso.

138


138


Mirando el log sabremos cual ha sido el fallo, en este caso el fallo consistía en que no se podría conectar por remoto en EDITRAN. Para descartar posibles fallos, vemos si nosotros nos podemos conectar a EDITRAN para ello vamos al principio del menup, escogemos la opción 1 “OPERADOR” y escogemos la opción 2 “PETICIÓN DE CONEXIÓN” con la sesión “008335FOTOES”. Entonces veremos si nos podemos conectar, mirando si en la esquina inferior derecha pone “CONECTADO”. Un vez realizada la comprobación liberaremos la conexión escogiendo la opción 3 “PETICION DE LIBERACION” con la misma sesión y veremos en la parte inferior izquierda que pone “DESCONECTADO”

138


138


Como nos podemos conectar correctamente lo que haremos será volver a ejecutar el proceso de subida del fichero Asnef. Para ello nos metemos en el menup elegimos la opción 1 “OPERADOR” y escogemos la opción 4 “PETICIÓN DE EMISIÓN” con la sesión de Asnef “008335FOTOES”.

138


Una vez hecho esto, para saber si el proceso se ejecutado satisfactoriamente, lo que haremos es ir a SOURCE y poner “tail -100 editrang.out” , en este fichero veremos si el proceso se ha ejecutado entero y cuando ha terminado.

138


SUBIDA DE EXPERIAN

Todos los jueves cuando llegue el siguiente sms al móvil de guardia:

“El proceso de generación del fichero Experian ha terminado con exito”

O el siguiente correo:

Llamamos a Control_m Argentina al número 917147847 diciéndoles que ejecuten la cadena startEdi.ksh del grupo

EXPERIAN_ENVIO de la aplicación COBROS_AP. La persona que nos atiende al teléfono nos puede decir que la petición la hagamos también por email. Entonces escribiremos un email a [email protected] como el siguiente:

Para [email protected]

Asunto Ejecución de cadena de producción

Buenos días,

Solicitamos la ejecución de la cadena startEdi.ksh del grupo EXPERIAN_ENVIO de la aplicación COBROS_AP.

Gracias.

Un saludo.

Si en este número te sale el contestador automático, colgamos y llamamos al 917147965 (CPD) y les decimos que si nos pueden pasar con Control_m Argentina y entonces la siguiente persona que nos saldrá hablando ya será de


138


Control_m Argentina. Y si no pues ya llamamos a Control-m España 915294221 y les pedimos a ellos que lancen la cadena.

Una vez que se ha terminado de ejecutar la cadena nos enviarán un sms y un email indicándonos si el proceso ha ido bien o mal.

Si el proceso ha ido bien el sms será:

“Ha finalizado el proceso de envío del fichero Experian a Badex por EDItran”

Si el proceso ha ido mal el sms será:

“Ha fallado el proceso de envío del fichero Experian a Badex por EDItran”

Si ha fallado tendremos que realizar las misma comprobaciones que hemos realizado con ASNEF anteriormente pero con la sesión “008500EXPER1”

138


TIMEOUT NETPLUS (17001)

Descripción.

Diariamente se recibe un correo similar al que se muestra a continuación.

Asunto: Informe de errores del día 10 de abril del 2011

Este correo contiene adjunto un fichero [ desc timeouts2017001-18004 ], con todos los timeouts ocurridos ayer, los cuales hay que verificar y comprobar si tenemos constancia de las operaciones que se han realizado.

Solución.

Para ello usaremos los últimos 10 dígitos del campo num de tarjeta para buscar en los ficheros e ir comprobando el resultado de las operaciones y el campo IdCuenta, que se corresponde con el id_cliente para realizar las búsquedas en la BBDD y en el 2N.

A partir del id_cliente podre obtener:- Referencia: añadiendo 0 en la izq hasta completar 12 dígitos.- External_id: añadiendo 0 en la izq hasta completar 11 dígitos, añado un punto y 5 ceros. EJ:

000ID_CLIENTE.00000- Cuenta_formato_largo: lo obtengo de la tabla cliente.

138


Al lanzar la instrucción anterior, nos devolverá una traza de las operaciones que se han realizado con ese número de tarjeta.

De la traza obtenida podemos observar la siguiente información relevante:

La traza debemos a analizarla como en el siguiente ejemplo y comprobar si esta información se encuentra igual en nuestra BBDD.

Análisis acciones a realizar.La comprobación, podemos realizarla de dos formas:

A través de consultas en el 2NEn Gestión de cobros, consulta de recibos, introducimos el id_cliente, y comprobamos si existe la misma información, que en los ficheros de netplus. Finalmente anotamos la acción a realizar en cada uno de los casos.

CASO A) Anular Cobro:

138


En este ejemplo comprobamos que la informacion no se encuentra correcta, ya que existe un recibo cobrado (con igual fecha e importe), al cual vemos en los ficheros que se anuló. Tras comprobar cuál es la situación de desalineamiento anotamos la acción en la Excel inicial, para posteriormente resolverla y/o informar al usuario.

Del recibo correcto, comprobamos que se trata del mismo que en los ficheros.

Y finalmente anotamos la acción a realizar.

138


CASO B) Devolver al cliente:

Seguimos los mismos pasos que en caso anterior y en el 2N solo encontramos un cobro de 40,76€. Comprobamos que hemos cobrado dos veces al cliente la misma factura, por tanto será necesario devolver al cliente el importe de 40.76€

CASO C) Realizar cobro online:

En 2n vemos que el recibo esta en recobros, por tanto ese recibo no se ha cobrado.

La acción a realizar en este caso será un cobro online con ese importe 64.66€, ya que la única operación ok te tenemos es la realizada por la tienda 2525, que es la que realiza los cobros online.

NOTAS:Tienda 2525:

- SIEBEL – cobros online. (95% operaciones)- WOC, permite cobro online. (es como un mini Siebel, Siebel pero con menos

características). (Resto operaciones)Tienda 2529:

IVR: contestador automático recobros.

A través de consultas en la BBDDLas mismas consultas realizadas anteriormente en el 2N se pueden realizar en directamente en BBDD.

138


SELECT *FROM cobros_reciboWhere referencia='000024929576'

El campo referencia, se corresponde con el id_cuenta, añadiendo a la izquierda los 0 necesarios para tener 12 dígitos.

Busco la operación en la que coincide el importe y la fecha y obtengo el campo id_cobro para realizar la siguiente consulta.select *From cobro_documentowhere ID_cobro=''XXXXXXX’

Información al peticionario de las acciones.

Tras definir las acciones a realizar en cada caso. Montamos un fichero similar al siguiente con la información más relevante para el usuario y las acciones a realizar. Diferenciamos en colores las diferentes acciones ofrecer mayor facilidad al usuario.

Resolución de las acciones posibles por OC.

De todas las acciones a realizar para resolver los des alineamientos, nosotros solo podemos realizar las de:

- Anular el cobro.- Realizar el pago el online.-

Para anular el cobro:- En 2N, en menú gestión de cobros, en cobro online.- Introducimos el cuenta_formato_largo, obtenido en la tabla clientes a partir del id_cuenta, sin los

0,s que se corresponde con el id_cliente.- Introducimos en el campo fecha > 16/05/2009, para que nos salgan todos.- Buscamos la transacción a anular, la seleccionamos.- Pulsamos el botón, anular cobros sin pasarela (dibujo similar a un escarabajo).

138


Para Realizar el pago el online.- En 2N, en menú gestión de cobros, consulta de recibos.- Introducimos el id_cliente. - Buscamos la transacción a cobrar, la seleccionamos.- Selecciono la opción de abajo a la derecha “cobro online”- Pulsamos el botón, cobro online (rayo).- Aparece una nueva pantalla y damos a aceptar.

Responder al correo.Finalmente respondemos al usuario.

OBSERVACIONES:

Dentro del correo enviado por el usuario también se incluye un fichero con las trazas de obtenidas de MDW para tener más información sobre los timeup ocurridos, permitoiendonos verificar si ha sido causa de OC.Este fichero se obtiene de la siguiente ruta:

openp1/tibe5/los/Adaptados OC

Aunque en esta ruta el más antiguo que encontramos es de ayer, por tanto si queremos ver un fichero anterior, debemos buscar en:

/CONTROL/rotación_log/rotaciones/Que es donde cada noche se van guardando automáticamente todas las noches a partir de las 22:00.

138


INFORME NORSE (Procesos Nocturnos)

Diariamente se lanza a las 18:30 la siguiente cadena en Control-M: OPEN_INF_24H_PROC_001_Informe_NORSE.

Esta cadena lanza el siguiente proceso:

/openp1/opencobp/CONTROL/RECOBRO/INFORME_NORSE/exe/Informe_NORSE.ksh

Este proceso recogerá los datos de horas de finalización y recepción de archivos de los bancos de los procesos nocturnos y rellena un informe que se enviará el día 1 de cada mes.

Los logs de envío FTP se almacenan en:

/opensgc/secuencial/tools/check_opencobros

El informe que se genera es similar a este:

Se guarda un backup de este informe de manera trimestral el día 1 del mes que forma parte del siguiente trimestre, por ejemplo, los siguientes archivos:

-rw-rw-r-- 1 opencobp cobros 495736 Dec 31 2010 check_01_01_2011.mht

-rw-rw-r-- 1 opencobp cobros 492640 Mar 31 12:01 check_01_04_2011.mht

-rw-rw-r-- 1 opencobp cobros 493815 Jun 30 12:01 check_01_07_2011.mht

138


Son los backups del informe del último trimestre de 2010, primer trimestre de 2011 y segundo trimestre de 2011 respectivamente.

138


INFORME DISPONIBILIDAD DE FICHEROS

Mensualmente (día 5 de cada mes), se genera y envía por FTP un informe a VULCANO que contiene:

FECHA Fecha de envío del informe de Pagos (a las UNs); Fecha de envío del informe de Deuda Viva (a las UNs); Fecha de envío de informe de Devoluciones Bancarias (a las UNs); Fecha fin de entrega de las Devoluciones Bancarias por parte de las Entidades ( a SSII); Número de Pagos procesados; Número de Recibos en Recobros; Número de Devoluciones Bancarias;

A partir de este informe, se genera el email mensual con el Informe de Disponibilidad de Ficheros de Cobros, con el que se ven los incumplimientos de los SLAs.

El script que ejecuta esto es:

cobros1p:/CONTROL/RECOBRO/INFORME_NORSE/exe$ more Informe_NORSE.ksh

La ruta del fichero es /openp1/opencobp/CONTROL/RECOBRO/INFORME_NORSE/

Su formato es .csv, con nomenclatura ddmmyyyy-disponibilidad_fichero_cobros.csv

ERRORES ASOCIADOS

En diciembre de 2011, se produjo una incidencia por la no generación de este informe. Se realizó su seguimiento en el ticket REMEDY número HD1000003300577, en el cual se detalla el problema, tal y como se indica a continuación:

Tras realizar el estudio de los fallos en la generación del fichero de disponibilidad de Open Cobros, podemos determinar que:

1. El fichero de disponibilidad se genera en base a la fecha de envío del informe de Pagos, a la fecha de envío del informe de Deuda Viva (PARI), a la fecha de envío de informe de Devoluciones Bancarias, a la fecha fin de entrega de las Devoluciones Bancarias por parte de las Entidades, al número de Pagos procesados, al número de Recibos en Recobros y al número de Devoluciones Bancarias.

2. Los errores en la generación tuvieron como origen Junio de este año, tras los problemas de rendimiento de la máquina de Open Cobros, ya que en caso de que alguno de los informes mencionados en el punto uno no este generado, no se registrará valor en el informe de disponibilidad, quedando este de forma incompleta.

138


3. Como medida de urgencia y debido a la situación acontecida durante dicho mes, lanzamos manualmente el proceso incluyéndole un rango de fechas para poder generar el fichero con los datos deseados y así subsanar la situación de manera temporal, hasta poder estudiar el caso con mayor detenimiento e implantar las correcciones oportunas. Se ha aplicado esta contingencia hasta encontrar la solución definitiva.

4. Tras revisar con detenimiento el problema vimos que el fallo en la correcta ejecución se debió a que el proceso que completa el fichero diariamente, al buscar el fichero ya generado encontró en la ruta dos ficheros, el fichero correcto y un nohup.out generado a causa de las ejecuciones extra del proceso debido a los problemas de rendimiento de la máquina en Junio. La existencia de dos ficheros en la ruta es completamente incompatible y por tanto el proceso no escribía datos para el día correspondiente..

5. Tras estas conclusiones eliminamos de la ruta el fichero nohup.out. Desde entonces llevamos unos días verificando la correcta ejecución del proceso y completado del fichero

138


BINES NACIONALES

A principios de cada mes recibiremos dos correos de Santiago Tomás para actualizar los bines en el sistema. El proceso atañe tanto a OpenCobros como a NET+, por lo que habrá que reenviar los correos al soporte de NETPLUS para que realicen también su carga ( [email protected] ).

De TOMAS GORGAS, SantiagoPara cobros movilcontrol; HORRILLO SANCHO, Ignacio Jose ExtAsunto RV: [POTENTIAL VIRUS] BINES NACIONALES -COMERCIOS-Achivos Adjuntos Fichero ZIP con los BINES a actualizar.

De TOMAS GORGAS, SantiagoPara cobros movilcontrol; HORRILLO SANCHO, Ignacio Jose ExtAsunto RV: BINES NACIONALESPassword para abrir el ZIP enviado en el archivo anterior

Descomprimimos el archivo zip con la password proporcionada en el segundo correo. La validación de bines consiste en buscar en la BBDD, tanto de Orange como de OMVs, si los bines que nos proporcionan están dados de alta y, en caso de que no estén dados de alta, generar un archivo complementario que se ubica en el servidor para que lo trate el proceso CBUXAMBIN.unx.

El proceso de validación de bines y de generación del archivo complementario está automatizado por la clase JAVA ActualizarBinesNacionales.

Por convención:

- Renombramos el archivo original como bines_hiper_julio2011.TXT.- Lo ubicamos en la ruta local C:\ORANGE\ARCHIVOS\bines.- Especificamos en la clase el nombre y ruta del archivo a tratar:

archivoBines = new File("C:/ORANGE/ARCHIVOS/bines/bines_hiper_julio2011.TXT");

Tratamiento para ORANGE

- Ejecutamos el proceso para ORANGE. Validamos que la clase ConectorBBDD tenga descomentada la línea de conectividad con la BBDD de Orange, y que tenga comentada la línea de conectividad con la BBDD de OMVs.

//PRODUCCIÓN - ORANGEconn = DriverManager.getConnection("jdbc:oracle:thin:@10.132.7.203:1526:OPENP", "OPENCOBE",

"temp03ral");//PRODUCCIÓN - OMVs//conn = DriverManager.getConnection("jdbc:oracle:thin:@10.132.5.145:1526:OPENOMVP", "OPENCOB", "libre");


138


- Una vez terminado el proceso de validación verificamos si se ha generado un archivo de BIN a tratar en la ruta local C:/ORANGE/ARCHIVOS/bines/ con formato BINES_Julio_20110707.txt:

- Si se ha generado archivo se trasladará al servidor cobros1p a la siguiente ruta /openp1/opencobp/opensgc/secuencial/cargaBIN/in

Se ejecutará el proceso/openp1/opencobp/opensgc/secuencial/cargaBIN/execnohup CBUXAMBIN.unx &

Verificaremos que se han dado de alta los nuevos bines en la tabla BIN:

SELECT count(*)FROM BINWHERE cod_banco IN ( .... )

Coincidirán el número de registros devueltos y el número de bines de la cláusula IN.

Tratamiento para OMVs

El proceso será similar a ORANGE, pero sustituyendo el conector de BBDD

//PRODUCCIÓN - ORANGE//conn = DriverManager.getConnection("jdbc:oracle:thin:@10.132.7.203:1526:OPENP", "OPENCOBE",

"temp03ral");//PRODUCCIÓN - OMVsconn = DriverManager.getConnection("jdbc:oracle:thin:@10.132.5.145:1526:OPENOMVP", "OPENCOB", "libre");

El archivo lo dejaremos en la ruta /openp1/opecobop/opensgc/secuencial/cargaBIN/in, y el proceso lo lanzaremos desde la ruta /openp1/opecobop /opensgc/secuencial/cargaBIN/exec.

138


Por último contestaremos el correo a Santiago Tomás indicándole el resultado del tratamiento de los BINES en OC y en NETPlus.

138


DECLARACIÓN DE INCOBRABLES

La declaración de incobrables se realiza con carácter semestral a solicitud del área de negocio. El proceso global tardará aprox. 10 días y consiste en:

- Generar los archivos (java).- Marcar los archivos para que los trate el recobro.- Dejar pasar un proceso nocturno de recobro.- Actualizar el estado de los recibos a Incobrable. Hasta aquí es lo que interesa al área de negocio.- Publicar el estado de la deuda a los sistemas afectados: SIEBEL (que marcará la pauta), HPFMS y RESER.

Tradicionalmente el paso a incobrables ha generado numerosos problemas por el volumen de datos a tratar, que se resumen en:

- No se pueden marcar para su paso a incobrable más de 25.000 registros de una sola vez, porque afectamos a los call center.

- Después del marcado de recibos, y una vez pasado un recobro nocturno, se ejecuta el proceso CMCC5810, que actualiza el estado de los recibos a incobrable. Esta tarea es incompatible con los procesos de remesado, recobro, compensación de sobrepagos, carga del bancario, historificación parcial y cualquier otro proceso que opere sobre las tablas de recibos. Esto implica que se deberán buscar ventanas de tratamiento óptimas, que generalmente coinciden con el horario diurno de sábado y domingo.

- La actualización del estado del recibo implica la actualización de la deuda del cliente en la tabla LISTA_CLIENTES y, por tanto, la comunicación de la nueva deuda a los sistemas SIEBEL, HPFMS y RESER. Por el elevado volumen de eventos a procesar (entre 1.000.000 – 250.000 recibos) se deberá impedir la publicación masiva de eventos tal como se especifica en el punto 4. Si no se impide la publicación masiva se correrán los siguientes riesgos:

o Afectar al archivado de la BBDD. Podría provocar que se agote el espacio disponible en el FileSystem.o Afectar a los sistemas receptores de los eventos. Se pueden colapsar los adaptadores MDW de los

sistemas, fundamentalmente de SIEBEL. Se generarán numerosos timeouts.o Afectar a la publicación de otros eventos de salida de OpenCobros. Otros eventos con prioridad

menor podrían quedar relegados e impediría su tratamiento. Esto ha sucedido en ocasiones, dejando sin tratamiento, por ejemplo, autorizaciones de Pagos Anticipados hacia COCO.

Teniendo en cuenta estas premisas, los pasos a realizar son los siguientes:

1) Generar los ficheros para realizar la actualización del estado y la publicación de los eventos.

La clase DeclaracionIncobrables.java se encarga de realizar esta tarea a partir de la fecha que proporcione el área de negocio. La clase consultará los recibos en estado “Recobros” iguales o anteriores a la fecha proporcionada por negocio, parcelando los resultados en archivos de 25.000 registros. El inicial lo completará con 10.000 registros para evaluar el comportamiento del sistema con un volumen menor de datos.

Para ello deberemos tener en cuenta los siguientes aspectos:

- La salida estándar de la clase se realizará en la siguiente ruta:C:/ORANGE/ARCHIVOS/declaracionIncobrables/

138


- Tendremos en cuenta las fechas proporcionadas por el área de negocio, modificando la siguiente línea.GregorianCalendar cal = new GregorianCalendar(2010, Calendar.JUNE, 12);

- Validamos que la clase ConectorBBDD tenga descomentada la línea de conectividad con la BBDD de Orange, y que tenga comentada la línea de conectividad con la BBDD de OMVs.

//PRODUCCIÓN - ORANGEconn = DriverManager.getConnection("jdbc:oracle:thin:@10.132.7.203:1526:OPENP", "OPENCOBE",

"temp03ral");//PRODUCCIÓN - OMVs//conn = DriverManager.getConnection("jdbc:oracle:thin:@10.132.5.145:1526:OPENOMVP", "OPENCOB", "libre");

Los ficheros que haya generado la clase en el entorno local desde donde se lance el proceso se deberán trasladar al servidor, pero de forma ordenada. La generación de los ficheros tardará entre 1 y 2 horas.

Por cada fichero generado se realizarán los pasos 2 y 3, que se especifican a continuación. No se procesarán de forma conjunta todos los ficheros generados, porque se ralentizaría la actividad de las plataformas. En su lugar, procesamos los ficheros de uno en uno.

2) Formateo de ficheros en el servidor.

Dejamos el fichero generado en la siguiente ruta:

/openp1/opencobp/opensgc/secuencial/incobrable

Se lanza el proceso:/openp1/opencobp/control_m/execnohup CMUX4315.ksh &

El archivo procesado se mueve de forma automática a:/openp1/opencobp/opensgc/secuencial/incobrable_open

El nombre del fichero modificado será: CBSE4315

3) Introducir la acción de Recobro para los recibos incluidos en el fichero: Marcado de los recibos para que el recobro lo pase a incobrable.

Esto puede ser problemático si están trabajando los Call Centers.Se lanza el proceso:/openp1/opencobp/control_m/execnohup CMCC4315.ksh &Al hacer "pr" veremos en ejcución:opencobp 3104984 2850892 0 11:42:07 pts/14 0:00 /bin/ksh ./CMCC4315.ksh

Verificar que la acción de recobro de paso a incobrable se ha marcado con cualquiera de los recibos del archivo:

SELECT hist.*, r_ac.* FROM re_historico hist, re_acciones r_ac WHERE hist.id_accion = r_ac.id_accion AND hist.referencia = (SELECT referencia FROM recibos WHERE id_factura = '0A60000000000383675390210') AND hist.programa = 'CBCC4315';

138


Después de haber realizado los pasos 2 y 3 para cada fichero deberemos dejar transcurrir un proceso de recobro nocturno para que trate las acciones de paso a incobrable que hemos marcado en el punto 3.

4) Paso a incobrables.

MUY IMPORTANTE 1 Tiene que haber transcurrido un pase de recobro desde que marcamos la acción de paso a incobrable y la ejecución del proceso que realiza el cambio de estado y la publicación en MDW.

MUY IMPORTANTE 2 El proceso que realiza el cambio de estado comenzará a publicar eventos MDW 21001 inmediatamente. Lo que hace esta historia es actualizar el estado del recibo a IN004 y actualiza la deuda del cliente en "lista_clientes". A actualizar la deuda se dispara el trigger EASY_PHONE que empieza a publicar eventos MDW a los sistemas impactados: SIEBEL, RESER, HPFMS.

MUY IMPORTANTE 3 Aunque no será habitual, en caso de que sea necesario que el 5810 trate acciones programadas por el 4315 el mismo día que se han puesto sería necesario modificar la fecha del fichero FECHAB de BATR (alias de /openp1/opencobp/exec/batch/exec) y ejecutar el proceso CBCC5810 directamente.

cobros1p:/exec/batch/exec$ more FECHAB20110624

En caso de que lo modifiquemos (improbable) nos debemos acordar de ponerlo como estaba.

MUY IMPORTANTE 4 En caso de que el proceso 5810 se esté ejecutando y vaya a coincidir con el 100, con el recobro, o con cualquier otro proceso incompatible, lo paramos (kill -9 <pid>), y lo ejecutamos en otra ventana donde no coincida con ellos. Al reiniciarse empezará con los recibos que aún no haya marcado.

Se lanza el proceso:/openp1/opencobp/control_m/execnohup CMCC5810.ksh &

Podemos validar el cambio de recibos con la siguiente consulta:

SELECT est_actu FROM recibos WHERE id_factura = 'RFPE 00000000000000433635'

Paralizar la publicación de eventos, para que lo podamos ejecutar de forma controlada durante los días siguientes. Lo que hacemos es poner los eventos en estado 9, de tal forma que MDW no los trate. Esto no evitará que durante el proceso de CMCC5810 haya algunos eventos que se hayan podido procesar, pero evitaremos que se procesen de forma incontrolada el 80 – 90% de los eventos. El siguiente script de actualización lo lanzaremos cada 5-10 minutos mientras esté en ejecución el proceso CMCC5810.

UPDATE table_x_ae_eventos SET prioridad = '8', estado_envio = '9' WHERE referencia = '21001' -- Indicar fecha y 5 minutos antes a partir de la que se ha lanzado el proceso CMCC5810. AND fecha_hora_ejecucion >= TO_DATE ('25/06/2011 07:55:00', 'DD/MM/YYYY HH24:MI:SS') AND ( estado_envio = '0' -- Sin enviar OR estado_envio = '6' -- Error en envío OR estado_envio = '7' -- Agotado nº de reintentos (gte. TIMEOUT entre OC y MDW) );

Validaremos el estado general de la publicación con la siguiente consulta. SELECT COUNT (*), estado_envio FROM table_x_ae_eventos WHERE referencia = '21001' -- Indicar fecha y 5 minutos antes a partir de la que se ha lanzado el proceso CMCC5810. AND fecha_hora_ejecucion >= TO_DATE ('25/06/2011 07:55:00', 'DD/MM/YYYY HH24:MI:SS')GROUP BY estado_envio;

138


5) A partir de las ventanas diarias acordadas con sistemas y con los usuarios, se deberán ir actualizando los eventos que se dejaron en estado 9, pendientes de tratamiento (entre 1.000.000 y 250.000). La idea es que cada hora, aproximadamente se verifique si existen eventos en estado 0, y si no existen, se lance el siguiente script de actualización para ir procesando eventos en estado 9 en bloques de 3600 (aprox. 3600 eventos a la hora).

UPDATE table_x_ae_eventos SET estado_envio = '0' WHERE objid IN ( SELECT b.objid FROM (SELECT a.objid, ROWNUM rnum FROM (SELECT objid FROM table_x_ae_eventos WHERE referencia = '21001' -- Indicar fecha y 5 minutos antes a partir de la que se ha lanzado el proceso CMCC5810. AND fecha_hora_ejecucion >= TO_DATE ('25/06/2011 06:00:00', 'DD/MM/YYYY HH24:MI:SS' ) --AND ( estado_envio = '6' -- Error en envío -- OR estado_envio = '9' -- Estado en pausa -- ) AND estado_envio = '9' -- Estado en pausa ) a WHERE ROWNUM <= 3600) b WHERE rnum >= 1);

Una vez actualizados todos los eventos y comunicada la deuda a todos los sistemas podremos dar por finalizada la declaración de incobrables.

CAMBIO DE CONTRASEÑA DE UNA APLICACIÓN.

En caso de tener que solicitar el reseteo o cambio de contraseña de una maquina concreta, deberemos seguir los siguientes pasos:

1. Abrir una petición REMEDY.

Grupo Operador (A.G.I)Aplicación La que corresponda (COBROS, EDITRAN,

NETPLUS)Asunto / Resumen Reseteo de contraseñaDescripciónBuenos días, Se requiere el reseteo la contraseña del usuario editran de la maquina cobros1p. Puede indicarse la nueva contraseña que deseemos.Un saludo.

2. Lamamos al CPD de Orange, cuyo número de teléfono es 917147965, indicando que se ha abierto una incidencia y que es de carácter urgente.

PASAR A RECOBRO

SI NUNCA HA ESTADO EL RECIBO EN RECOBRO.

138


-- 1) Actualizar el recibo cobrado para dejarlo con toda la deuda y en estado pendiente de recobros para que el CBCC4010 lo inserte de nuevo correctamente

SELECT * FROM clientes WHERE id_cliente='12146503'

-- opencob 02/09/2011 23:30:45 000012146503 00012146503.00000 01 ALTA_CLIENTES 12146503 0 M00002 0 0 0 4.2018.10 CG0000000000000 0Z

SELECT * FROM recibos WHERE REFERENCIA = '000012146503' AND F_FACT = to_date('20110401','yyyymmdd') AND SECUENCIAL_REC = 0 AND RADICAL_EMP = '01' -- 01 Carrefour , --02 Youmobile

-- Antes-- ABLASLOP 02/09/2011 23:36:43 CBCCAM142 000012146503 01/04/2011 ACCIONA FACILITY SERVICES, S A 5918,71 27/06/2011 10:14:45 RE002 0 0 RFPE 00000000000000588684 01 0 0Z 5918,71 0 0 01/03/2011 01 0 M00002 A08175994 01/04/2011 00012146503.00000 3 0 0 0 0 0 0 0 0 06/04/2011 RFPE 00000000000000588684 01 5918,71 M00002 N

UPDATE RECIBOS SET USUARIO = 'OPEN', F_ACTUAL = '07092011', -- Poner la fecha de hoy EST_ACTU = 'PR001', IMP_COBRADO = 0WHERE REFERENCIA = '000012146503' AND F_FACT = to_date('20110401','yyyymmdd') AND SECUENCIAL_REC = 0 AND RADICAL_EMP = '01' ;

Una vez realizado el update , no se actualizara el recibo a recobro hasta que no pasen los procesos nocturnos del recobro, una vez finalizado los procesos nocturnos tendrá que quedarse el recibo en estatado RECOBRO como aparece en el recuadro verde.

SI YA HA ESTADO EN RECOBRO

-- 1) Actualizar el recibo cobrado para dejarlo con toda la deuda y en estado pendiente de recobros para que el CBCC4010 lo inserte de nuevo correctamenteselect * from clientes where id_cliente='12146503'-- opencob 02/09/2011 23:30:45 000012146503 00012146503.00000 01 ALTA_CLIENTES 12146503 0 M00002 0 0 0 4.2018.10 CG0000000000000 0Z

select * from recibos where REFERENCIA = '000012146503' AND F_FACT = to_date('20110401','yyyymmdd') AND SECUENCIAL_REC = 0 AND RADICAL_EMP = '01'

138


-- Antes-- ABLASLOP 02/09/2011 23:36:43 CBCCAM142 000012146503 01/04/2011 ACCIONA FACILITY SERVICES, S A 5918,71 27/06/2011 10:14:45 RE002 0 0 RFPE 00000000000000588684 01 0 0Z 5918,71 0 0 01/03/2011 01 0 M00002 A08175994 01/04/2011 00012146503.00000 3 0 0 0 0 0 0 0 0 06/04/2011 RFPE 00000000000000588684 01 5918,71 M00002 N

UPDATE RECIBOS SET USUARIO = 'OPEN', F_ACTUAL = '07092011', EST_ACTU = 'PR001', IMP_COBRADO = 0WHERE REFERENCIA = '000012146503' AND F_FACT = to_date('20110401','yyyymmdd') AND SECUENCIAL_REC = 0 AND RADICAL_EMP = '01' ; -- Ahora -- OPEN 07/09/2011 CBCCAM142 000012146503 01/04/2011 ACCIONA FACILITY SERVICES, S A 5918,71 27/06/2011 10:14:45 PR001 0 0 RFPE 00000000000000588684 01 0 0Z 5918,71 0 0 01/03/2011 01 0 M00002 A08175994 01/04/2011 00012146503.00000 3 0 0 0 0 0 0 0 0 06/04/2011 RFPE 00000000000000588684 01 5918,71 M00002 N -- 2) Borrar la fila correspondiente al cobro del recibo. cuando pase el CBCC4010 insertará otra vez el cambio de pendiente de recobros a recobros por lo que después de pasar el proceso deberíamos borrar la última fila generada con programa = 'CBCC4010' y estado = 'PR001'select * from HIST_ESTADOS WHERE REFERENCIA = '000012146503' AND F_FACT = to_date('20110401','yyyymmdd') AND SECUENCIAL_REC = 0 AND RADICAL_EMP = '01' AND ESTADO = 'RE001' AND PROGRAMA = 'Tratar_recibo'; --opencob 27/06/2011 10:14:45 Tratar_recibo 000012146503 01/04/2011 RE001 19/05/2011 01 0 27/06/2011 10:14:45 DELETE FROM HIST_ESTADOS WHERE REFERENCIA = '000012146503' AND F_FACT = to_date('20110401','yyyymmdd') AND SECUENCIAL_REC = 0 AND RADICAL_EMP = '01' AND ESTADO = 'RE001' AND PROGRAMA = 'Tratar_recibo'; -- Con estos pasos que hemos realizado el recibo queda en pendiente de recobros entonces o esperamos a que se pase el recobro por la noche o lo ejecutamos en este momento, verificando que lo podemos hacer ya que -- no se esta ejecutando ningun otro proceso para ejecutarlo: -- 5) PASAR EL CBCC4010 para introducir el recibo nuevamente en recobros. -- 6) DELETE HIST_ESTADO, borrar la última fila generada para este recibos con programa = 'CBCC4010' y estado = 'PR001' select * from HIST_ESTADOS WHERE REFERENCIA = '000012146503' AND F_FACT = to_date('20110501','yyyymmdd') AND SECUENCIAL_REC = 0 AND RADICAL_EMP = '01' AND ESTADO = 'PR001' AND PROGRAMA = 'CBCC4010' AND F_ESTADO = '06082011' -- Sin poner fecha estado devuelve -- opencob 19/05/2011 CBCC4010 000012146503 01/04/2011 PR001 19/05/2011 01 0 19/05/2011 0:56:09 DELETE FROM HIST_ESTADOS WHERE REFERENCIA = '000012146503' AND F_FACT = to_date('20110401','yyyymmdd') AND SECUENCIAL_REC = 0 AND RADICAL_EMP = '01' AND ESTADO = 'PR001' AND PROGRAMA = 'CBCC4010' AND F_ESTADO = '27062011'; -- 7) Actualizar la fecha de entrada en recobros del recibo con la que tenía antes del cobro (02/08/2011) select * from RE_CONTROL_FLUJO WHERE REFERENCIA = '000012146503' AND F_FACT = to_date('20110401','yyyymmdd') AND SECUENCIAL_REC = 0 AND

138


RADICAL_EMP = '01' AND DESACTIVADO = '0'; -- No devuelve nada hoy -- Esto lo realizamos si teníamos el recibo en esta tabla, en este caso no lo tenemosUPDATE RE_CONTROL_FLUJO SET USUARIO = 'OPEN', F_ACTUAL = '20110908', F_ENTRADA_RECOBRO = '19052011'WHERE REFERENCIA = '000012146503' AND F_FACT = to_date('20110401','yyyymmdd') AND SECUENCIAL_REC = 0 AND RADICAL_EMP = '01' AND DESACTIVADO = '0'; -- Insertamos el recibo en la tabla INSERT INTO RE_CONTROL_FLUJO VALUES ('opencob',sysdate,'CBCCAM142','000012146503',to_date('01/04/2011','DD/MM/YYYY'),'0','0','0','5918,71','M00002','12146503','A00021','R00025','E00016','1',to_date('11/09/2011 23:36:43','DD/MM/YYYY HH24:MI:SS'),'0','01','00012146503.00000',to_date('02/09/2011 23:36:43','DD/MM/YYYY HH24:MI:SS'),'0','RFPE 00000000000000588684',to_date('01/03/2011','DD/MM/YYYY'),to_date('1/04/2011','DD/MM/YYYY'),'0','0','0Z',to_date('31/12/2999','DD/MM/YYYY'),'0','0','0',to_date('04/07/2011','DD/MM/YYYY'),to_date('01/04/2011','DD/MM/YYYY'),'0',to_date('06/04/2011','DD/MM/YYYY'),to_date('31/12/2999','DD/MM/YYYY'),'RFPE 00000000000000588684',null,'0','0','CG0000000000000',null,to_date('06/04/2011','DD/MM/YYYY'))

select * from re_historico where referencia='000012146503'

-- Insertamos el recibo en el historico de estados del recobro INSERT INTO re_historico VALUES ('opencob',sysdate,'CBCC4110','000012146503',to_date('01/04/2011','DD/MM/YYYY'),'0','0','0','12146503','00012146503.00000','E00016','Z00000','0',to_date('01/01/0001','DD/MM/YYYY'),'01',to_date('19/05/2011 2:36:43','DD/MM/YYYY HH24:MI:SS'),'RFPE 00000000000000588684',to_date('01/03/2011','DD/MM/YYYY'),to_date('1/04/2011','DD/MM/YYYY'),'0','RA0001',null,null,'S00021')

-- 8) Actualizar la fecha de cambio de estado del recibo con la que tenía antes del cobro (02/08/2011)select * from RECIBOS WHERE REFERENCIA = '000012146503' AND F_FACT = to_date('20110401','yyyymmdd') AND SECUENCIAL_REC = 0 AND RADICAL_EMP = '01' ; -- ABLASLOP 02/09/2011 23:36:43 CBCCAM142 000012146503 01/04/2011 ACCIONA FACILITY SERVICES, S A 5918,71 27/06/2011 10:14:45 RE002 0 0 RFPE 00000000000000588684 01 0 0Z 5918,71 0 0 01/03/2011 01 0 M00002 A08175994 01/04/2011 00012146503.00000 3 0 0 0 0 0 0 0 0 06/04/2011 RFPE 00000000000000588684 01 5918,71 M00002 N UPDATE RECIBOS SET USUARIO = 'OPEN', F_ACTUAL = '08092011', F_ESTADO_ACTU = '27062011' WHERE REFERENCIA = '000012146503' AND F_FACT = to_date('20110401','yyyymmdd') AND SECUENCIAL_REC = 0 AND RADICAL_EMP = '01' ;

Listado de los HOTLINES generados en OMV Cada cierto tiempo Angel Luis nos envía un correo como el siguiente.

Buenos días,

Necesitamos el listado de los hot-lines generados de You Mobile entre mayo de 2011 y octubre de 2011. El fichero tiene que incluir la fecha de publicación y la fecha de eliminación de los mismos.

Muchas gracias.Un saludo,

138


Lanzamos la siguiente consulta en OMV

SELECT external_id, f_desconexion, DECODE (TO_CHAR (f_reconexion, 'DD/MM/YYYY'), '31/12/2999', 'NO RECONECTADO', TO_CHAR (f_reconexion, 'DD/MM/YYYY')) AS f_reconexion FROM re_desconexiones WHERE radical_emp = '02' --01 para carrefour AND f_desconexion >= TO_DATE (:f_inicio, 'DD/MM/YYYY') AND f_desconexion <= TO_DATE (:f_fin, 'DD/MM/YYYY') AND tipo_desc = 'IF009'ORDER BY f_desconexion;

Siendo para este caso concreto: F_INICIO = 01/05/2011 F_FIN = 31/10/2011

NOTA: En caso de que soliciten los HOTLINES de CARREFOUR en lugar de los de YOUMOBILE indicaremos en la consulta en el campo radical_emp el valir ‘01’

Una vez obtenidos los resultados de la consulta, los exportaremos a un fichero EXCEL que adjuntaremos en el correo de respuesta.

Mostramos la respuesta dada a la solicitud tratada como ejemplo.

Buenos días Angel Luis

Adjuntamos la extracción los hot-lines generados de YouMobile entre noviembre de 2011 y abril de 2012 con las fechas de publicación y las fechas de eliminación de los mismos

Un saludo.

Luis Miguel Cano Martinez.Servicio Opencobros.

138


Envío Checklist OC trimestral

Todos los días generamos una checklist con los tiempos de los procesos y el SLA de los bancos y la enviamos a las 09 y a las 12 tanto por mail a nosotros como por ftp a la VPN de Orange. El FTP diario como se realiza del fichero check.mht, siempre lo machaca (dado que la información del fichero se incrementa cada día) hasta que finaliza un trimestre y comienza de nuevo (esto lo confirmaremos la semana que viene ya que el sábado es último día de trimestre, es mi teoría). Entonces, cada fin de trimestre se genera un *.mht con los datos de la checklist de OC de los 3 meses anteriores, es decir, el último día de marzo (tendrá enero, febrero,marzo), junio (bla,bla,bla), septiembre(…,…,…) y diciembre. Tenemos que realizar manualmente el ftp del fichero a la VPN renombrándolo con el formato: check_[NUMERO TRIMESTRE]_trimestre_[AÑO].mht

Ejemplo:

Es abril, tenemos generado el “check_01_04_2012.mht” Hacemos cp -p check_01_04_2012.mht check_1_trimestre_2012.mht Y luego el ftp del fichero renombrado. Los datos del FTP están en el fichero ReloadTransfer.ini

RUTAS exec /openp1/opencobp/opensgc/secuencial/tools/check_opencobros

Backup /backup Log /log

Publicaciones fuera de ventanaTodos los Martes hay que enviar a Fito un informe semanal con las publicaciones fuera de ventana.

Para realizar esta publicación ejecutamos la siguiente consulta, indicando los días desde el Miercoles anterior hasta el Lunes.

SELECT e.REFERENCIA, e.ESTADO_ENVIO, COUNT (1) FROM TABLE_X_AE_EVENTOS e WHERE (e.REFERENCIA = '42001' OR e.REFERENCIA = '42004') AND e.FECHA_HORA_EJECUCION >= TO_DATE (:dia || '100000', 'YYYYMMDDHH24MISS') AND e.FECHA_HORA_EJECUCION <= TO_DATE (:dia || '235959', 'YYYYMMDDHH24MISS')GROUP BY e.REFERENCIA, e.ESTADO_ENVIOUNION ALL SELECT h.REFERENCIA, h.ESTADO_ENVIO, COUNT (1) FROM HIST_TABLE_X_AE_EVENTOS h WHERE (h.REFERENCIA = '42001' OR h.REFERENCIA = '42004') AND h.FECHA_HORA_EJECUCION >= TO_DATE (:dia || '100000', 'YYYYMMDDHH24MISS') AND h.FECHA_HORA_EJECUCION <= TO_DATE (:dia || '235959', 'YYYYMMDDHH24MISS')GROUP BY h.REFERENCIA, h.ESTADO_ENVIOORDER BY REFERENCIA, estado_envio;

138


Con esta consulta generamos un fichero EXCEL con los resultados:

Y enviamos un correo:

Para GONZALEZ CAMPOS, Adolfo Ext <[email protected]>; CC SAN CASIANO CANSECO, Miguel Angel Ext <[email protected]>; RODRIGUEZ ARTEAGA, RAUL Ext

[email protected]; FERNANDEZ NIETO, Alberto Ext <[email protected]>

Buenas tardes Fito Adjunto el informe de publicaciones fuera de ventana.

Un saludo.

Reseteo de contraseñas de usuario

Desde REMEDY nos solicitan un reseteo de contraseñas.

La descripción de la remedy es:

OPEN COBROS-

OPEN tsfgp002

Buenos tardes:

Necesitamos que se reseteen los siguientes usuarios de los distintos aplicativos:

Podéis abrir incidencia a nombre de Marina Fernández.

Tlfno. De contacto: 615.982.681

Sede: Transcom San Fernando.

Por favor, necesitamos respuesta a estos correos con los números de ticket, estamos teniendo problemas con los reseteos masivos ya que no recibimos respuesta.

Muchas gracias.

Un saludo

Marina Fernández BarcenillaTraffic


138


TranscomAv. Castilla Nº 2 Edif. Hungría

Parque Empresarial de San Fernando

28830 San Fernando de Henares

España

Mobile: +34 615 982 681Direct: +34 935 133 116

Extension : 8345223

Fax: +34 916 787 214Email: [email protected]

Realizamos los siguientes pasos:

Acedemos al 2N con usuario OPENCOB.

Accedemos al mantenimiento de perfiles/usuarios:

Buscamos el usuario indicado en la REMEDY, en este caso nos indican TSFGP002.

138


Pulsamos el botón derecho y seleccionamos la opción “Editar”.

Nos aparecerá la siguiente pantalla:

En esta pantalla debemos revisar que el check “Bloqueado” no este marcado. En caso contrario lo desmarcaremos. Además introduciremos la nueva contraseña en los campos “Password” y “Confirmacion Password”

Al cambiar la PWD es necesario lanzar el proceso para que almacene los cambios en BBDD

cobros1p:/control_m/exec$ OPEN_SEG_24H_PROC_001_pack_seguridad.ksh

Reviso el log:

Ruta: /openp1/opencobp/control_m/log_control_m

Fichero: out_package_body_seguridad_YYYYMMDDHHMISS

tail -1 out_package_body_seguridad_YYYYMMDDHHMISS

Y revisamos que obtenemos la palabra TERMINOBIEN

138


Compruebo con el 2N que puedo acceder

No saben si el `proceso correcto es el anterior o este:

cobros1p:/control_m/exec$ CMpackage_body_seguridad.ksh

Compruebo con el 2N que puedo acceder

Si sigue dando error es que el usuario está bloqueado en la BBDD

Abrimos una petición remedy a operador AGI para que la reseten

HD1000003125566

Cuando nos den la contraseña.

Nos dan nueva123

La contraseña para el 2N será: n321aveu

Para obtener la del 2N, invierto la contraseña y mantengo el 1º digito y esa es la del 2N.

Lanzo el proceso anterior para que se guarden los cambios.

En caso de no poder acceder al 2N debemos abrir una petición a Operador AGI para que reseteen en base de datos la contraseña del usuario. Aquí podemos hacer dos cosas:

1. Una vez abierta la petición llamarles indicándoles la contraseña que deseamos.2. Indicar en la petición que nos llamen y nos indiquen la contraseña que han seleccionado.

Hay que tener en cuenta que si pongo en el 2n nueva123 cuando llame a cpd tengo que decir que pongan n321aveu (La primera letra se mantiene y el resto cambian de posicion)

Mostramos un ejemplo de la petición abierta a Operador AGI, en la que se indica cual queremos que sea la nueva contraseña y desde Operador AGI nos indican que por operativa no volvamos a indicar la contraseña en una petición.

Remedy HD1000003442502Asunto Reseteo contraseña oracle del usuario TSFGP002 en bbdd openpDescripción

Hola,

Necesitamos que se resetee la contraseña de los usuarios TSFGP002 de Oracle de la instancia OPENP.

Hostname: cobros2p – Nodo actual debido a que estamos en la semana del SRDIP: 10.132.7.201 – IP actual debido a que estamos en la semana del SRDInstancia: openp

Muchas gracias

Otro ejemplo de remedy abierta para otro caso:

138


Ojo, hay que indicar los datos:

Hostname: cobros2p – Nodo actual debido a que estamos en la semana del SRDIP: 10.132.7.201 – IP actual debido a que estamos en la semana del SRDInstancia: openp

Alternativa:

Además del ejecutable para crear usuarios (exec crea_usuario(:USUARIO,:CONTRASEÑA);) podemos usar el de cambiar psw:

exec ops$oracle.CAMBIAPWD_USUARIO('LGONZALG','o51egnar');

138


Con esto cambiamos la contraseña del usuario, en este ejemplo LGONZALG, por la contraseña ‘orange15’ invertida.

Luego vamos al 2N y reseteamos el usuario con ‘orange15’ y ya funciona.

Envío SMS´s certificados

Con el Proyecto NOTIFICA EXPERIAN (OPER2012-5149 - Servicio Notifica Experian) se decomisa el envío de SMS´s certificados y el envío de cartas de OPENCOBROS tipo POSTAV a DOC1.

Remesado

Documentación sobre cambios de centro de cobro solicitados por negocioCada cierto tiempo recibimos por parte de negocio un correo donde nos solicitan el cambio de centros de cobro.

Un ejemplo del correo podría ser:

Asunto NUEVA PETICION CAMBIO CENTRO DE COBRO DICIEMBRE 2011Adjunto Fichero Word: PETICION UGP CAMBIO CENTROS DE COBRO DICIEMBRE 2011DescripciónBuenas días Os enviamos una nueva petición UGP para cambiar el centro de cobro los recibos , para el ciclo 12 de Diciembre "Peticiones a Sistemas de Información" con número 1468065 Este cambio afecta a dos bancos según el nuevo reparto bancario firmado para el 2011. Por favor, infórmanos de las fechas en las que podrá estar disponible en producción , Cualquier cosa no dudéis en decírmelo Muchas gracias Mercedes

Vemos que en el contenido del documento Word adjunto en el correo nos indican los cambios concretos:

CAMBIO DE CAIXA PROPIOS A BBVA AJENOS

2100 CAIXA CAIX BBVA

138


CAMBIO DE CAJA MADRID PROPIOS A UNICAJA AJENOS

2038 CAJA MADRID CM UNJ

Una vez que sabemos los cambios que debemos realizar, accedemos al 2N para implantarlos.

Vemos el centro de cobro asignado para la Caixa:

Para cambiarlo, debemos desasociar el banco la Caixa al centro de cobro 601.

Esto se hace pinchando sobre el banco “LA CAIXA” y manteniéndolo pulsado, arrastramos hasta el cuadro “Lista de bancos”

138


Nos aparecería la siguiente ventana:

E indicaríamos la opción “Si”

Quedaría de la siguiente manera:

138


El siguiente paso es asociar el banco “La Caixa” al BBVA Ajenos como nos indican en el documento adjunto al correo.

Para ello acedemos al banco BILBAO VIZCAYA a la rama “Ajeno”.

138


Vemos que en la “Lista de bancos” ya se encuentra “LA CAIXA”.

Asociamos “LA CAIXA” a BILBAO VIZACAYA pinchando sobre ella y manteniéndola pulsada, arrastraríamos al cuadro “Bancos asociados”

Quedaría de la siguiente manera:

138


Venta de Deuda

El proceso de Venta de Deuda es un conjunto de acciones que se realizan entre OC, BSCS y GED para vender a una agencia externa la deuda de los clientes denominados incobrables correspondientes a un periodo de tiempo previamente definido.

Previo a la extracción de la Venta de deuda se debe haber generado el marcado de los recibos a incobrables, este un proceso independiente de este proceso y no se tiene por qué realizar de forma inmediatamente antes a la extracción.

Procesos de Venta de deuda

138


Generación de Ficheros (Toda la deuda en Incobrable y deuda > 1€). Inclusión de

datos de Bscs.

OC

No ImpagadosDeuda VivaHistórico de

Recobros

1

CIF’sy Facturas

(Formato GED)

GED

CIF’s(contratos.

encontrados)

Facturas(doc.

encontrados)

Post Proceso(nuevos campos indicando

la existencia de documentos)

OPENCOB BSCS

Créditos

FacturasFiltradas (Fraude,

Pagos Anticipados,VIP’s

Gestión (JJMM))

Post. Proceso (Se eliminan las

Facturas que no están

en el Pari)

Marcado en OC

Recibos Vendidos

Deuda Viva

No ImpagadosDeuda VivaHistórico de

Recobros

GED

CREDITOS

1

2

3

4

CIF’sa eliminar en

GED

Facturasa eliminar en

GED

SelecciónCIF’s y

Facturas a eliminar en

GED

5

Generación de ficheros iniciales:

La primera acción a realizar es la generación de los tres ficheros base que se emplearán en el resto de procesos y que contiene todos los recibos marcados como incobrables y ninguno en recobro.

Así como todos sus recibos asociados de cada cliente con sus recibos de forma histórica.

Los tres ficheros generados son:

Deuda Viva : Contiene todos los recibos marcados como incobrables, y por lo tanto con deuda, los denominados impagados.

Histórico de Recobro : Recoge todos los recibos asociados a los marcados previamente como incobrable, es decir contiene la vida de cada incobrable a nivel de recibo.

No impagados : Contiene todos los recibos de cobrados de los clientes previamente seleccionados como incobrable.

CBCCAM107

CBCCAM108

CBCCAM109

CBCCAM110

138


Para la generación de estos ficheros iniciales emplearemos el proceso CBCCAM107.

RUTA: /opensgc/secuencial/extracciones/exec

PROCESO: CBCCAM107.unix

PARAMETRO: Para cada uno de los ficheros ha extraer se le añade uno de los siguientes parámetros:

o DV: Para deuda viva

o HR: Para histórico de recobro.

o NI: Para No impagados

Se debe añadir al final un parámetro de fecha con formato YYYYMMDD, en el que indicaremos los recibos marcados como incobrables entre el periodo de fecha señalado en el formato mencionado.

EJEMPLO DE EJECUCION DE PROCESO:

Deuda Viva -> CBUXAM107.unx 20080101 20101212 DV

Hist_Recobro -> CBUXAM107.unx 20080101 20101212 HR

No impagados -> CBUXAM107.unx 20080101 20101212 NI

RUTA SALIDA: Se dispondrá de un fichero por cada ejecución, que se encuentra en la ruta: /opensgc/secuencial/extracciones/backup y con el formato:

Deuda Viva -> OC_DOCEXTRAER_VD_YYYYMMDD.txt

Hist_Recobro -> OC_DOCEXTRAER_HR_YYYYMMDD.txt

No impagados -> OC_DOCEXTRAER_NI_YYYYMMDD.txt

Nota: La fecha que aparece en el fichero de extracción es la fecha de ejecución y no la fecha del intervalo de extracción empleado.

RUTA LOG: El log de cada ejecución podemos encontrarlo en:

/opensgc/secuencial/extracciones/log y con el formato: CBCCAM107_YYYYMMDDHHmmssLOG (la fecha corresponde con la fecha de ejecución del proceso.)

FUNCIONALIDAD DEL PROCESO CBCCAM107:

El proceso CBCCAM107.unix es el encargado de realizar las siguientes acciones por cada fichero a extraer (DV, HR o NI):

Lo primero que realiza este proceso es comprobar el número de parámetros que se le pasan en la ejecución, según este parámetro sabe que fichero ha de crear: Deuda Viva, Hist_Recobro o No_Impagados, así como la fecha a emplear en la extracción, si hay dos fechas se trata del periodo a extraer y con una fecha ejecuta la extracción desde

138


esa fecha hasta la fecha actual, en caso de no incluir fechas realiza una extracción de todos los incobrables que encuentre marcados como tal en BBDD.

Una vez que se dispone de los parámetros hace un llamamiento al paquete de BBDD de OC para realizar la extracción:

Paquete empleado: pack_extracciones, que dependiendo de los parámetros de fecha introducidos llamará a las siguientes funciones:

extr_venta_deuda_a -> Sin fechas, extrae todo lo que hay en la BBDD.

extr_venta_deuda_b -> Una única fecha (fecha desde)

extr_venta_deuda_c -> Con dos fechas (desde y hasta)

En el siguiente punto nos centraremos en el contenido de estas consultas y los cambios sufridos, ahora seguimos con el proceso de generación de estos ficheros.

Una vez realizada la extracción de los datos “brutos” de la BBDD, se crea un fichero temporal con los datos obtenidos y en el formato adecuado, es decir, incluye una cabecera separada por “|” listo para ser empleado por el próximo proceso.

El fichero temporal generado dispone de un formato:

CBCCAM107_Extr_deuda_viva_yyyymmdd.tmp

CBCCAM107_Extr_hist_recob_ yyyymmdd.tmp

CBCCAM107_Extr_no_recobros_ yyyymmdd.tmp

Campos que se extrae en cada fichero:

Campos Tipo

Cust_Code VARCHAR2(25)

External_id VARCHAR2(48)

Tipo_Cliente VARCHAR2(40)

Titular VARCHAR2(40)

Nif_pagador VARCHAR2(10)

Direccion VARCHAR2(150)

Municipio VARCHAR2(35)

Cod_Postal VARCHAR2(5)

Cuenta VARCHAR2(20)

Num_fact VARCHAR2(31)

138


Campos Tipo

F_devolucion DATE

Motivo_devolución VARCHAR2(3)

Imp_facturado NUMBER(19,6)

Imp_recibo NUMBER(19,6)

Imp_ajustado NUMBER(19,6)

Imp_adeudado NUMBER(19,6)

Tipo_cobro VARCHAR2(2)

F_cobro DATE

Escenario VARCHAR2(8)

Estado VARCHAR2(8)

F_entrada_estado DATE

F_salida_recobros DATE

Mot_paralizacion VARCHAR2(80)

F_desactivacion DATE

F_activacion DATE

Est_factura VARCHAR2(80)

F_pago_ven DATE

F_Fact DATE

Cuenta_Estudio VARCHAR2(5)

Imp_original NUMBER(19,6)

Moneda_original VARCHAR2(6)

Id_Moneda VARCHAR2(6)

F_entrada_recobros DATE

Agencia_Externa VARCHAR2(40)

Una vez generado este fichero el proceso CBCCAM107.unix continúa ejecutándose para ahora, conectarse a BSCS y enriquecer este fichero con los siguientes campos, que añade al final del proceso:

Campos Tipo

Nombre VARCHAR2(40)

Apellidos VARCHAR2(40)

138


Campos Tipo

Telf1 VARCHAR2(25)

Telf2 VARCHAR2(25)

Existe CIF

Varchar2(1)

1: Si existe doc en GED

0: Si no existe doc en GED

Existe Factura

Varchar2(1)

1: Si existe doc en GED

0: Si no existe doc en GED

Con esto obtenemos los ficheros definitivos que se emplearan en el resto de procesos.

TRATAMIENTO DE FICHEROS PARA GED:

Una vez que se encuentran extraídos y validados los ficheros de DV, HR y NI, se continúa con el proceso de Venta de Deuda, siendo el siguiente paso: procesos que envían y reciben información a GED.

En la anterior venta de deuda uno de los errores más frecuente fue el de la incompatibilidad de formatos de CIF y facturas entre Opencobros y GED.

CIF: GED no admite espacios que el CIF tenga espacios dando fallo en su procesamiento. Por otra parte, los CIFS de GED se vio que tenían siempre longitud 9 de manera que se rellenaban con ceros por delante en caso de ser inferiores. Así, se van a modificar los procesos de intercambio de CIFs entre sistemas enviando y recibiendo de GED siempre los CIF de longitud 9, sin espacios y ceros por la izquierda.

Facturas rectificativas: En la anterior venta de deuda hubo errores ya que GED esperaba el formato para los ID Factura de las Rectificativas sin el formato denominado doc1 que se aplica para las facturas normales .Por este motivo se enviarán todas estas facturas que comienzan con R en formato Opencobros, sin pasarlo a formato GED. Para esto también deben modificarse los procesos de generación y procesamiento de ficheros.

Los procesos a cambiar son los 3 procesos principales de la venta de deuda:

CBCCAM107, CBCCAM108 y CBCCAM111

A continuación se detallan las numerosas ejecuciones, validaciones y manualidades que deben ejecutarse en la venta de deuda.

También los ficheros resultantes deberán analizarse minuciosamente ya que cualquier fallo en el formato o mala calidad del dato puede provocar errores y los tiempos con que se cuentan hacen que estos errores deban reducirse al mínimo

138


PASO1 Proceso CBCCAM107:

Para GED se genera otro fichero basado en los anteriores y debe contener todos los NIFs/CIFs, y los números de factura asociados.CIFs| Facturas | Tipo cliente

Campo Tipo

NIF/CIF VARCHAR2(10)

Núm. Factura VARCHAR2(17)

Tipo Cliente VARCHAR2(2)

Este fichero es el que se envían a DOC1 : OC_DOCEXTRAER_VD_yyyymmdd.tx

Una vez generado los ficheros se deben concatenar por grupos. Importante revisar y eliminar las cabeceras para que no queden entre medio de los ficheros.

RUTA EJECUTABLE:

RUTA DEL LOG: opencobr/opensgc/secuencial/extracciones/log


SE reciben de GED 3 ficheros indicando en cada uno de ellos la siguiente información:

•NIFs/CIFsencontrados en GED

•Factuarsencontradas en GED

•SMS Certificados encontrados en GED

A partir de esta información el proceso CBUXAM108 en OC actualiza los tres ficheros iniciales. Se comparan los ficheros creados en el proceso CBCCAM107 con los ficheros GED y se añade un 1 en cada línea por cada dato en caso de encontrarlo y un 0 en caso contrario.

El fichero de salida se debe revisar que esté correctamente enriquecido, para ello se revisa que los flags de final de línea sean correctos (1|1|0) con 1 o 0 según se haya encontrado la información en GED.

138


Los ficheros que enriquecerá este proceso se encuentran en: opensgc/secuencial/extracciones/backup y tendrán el siguiente formato:

CBCCAM107_Extr_deuda_viva_fecha.DAT

CBCCAM107_Extr_hist_recob_fecha.DAT

CBCCAM107_Extr_recibos_no_recobros_fecha.DAT

RUTAS:

RUTA EJECUTABLE: opensgc/secuencial/venta_deuda/GED/exe

RUTA DEL LOG: opensgc/secuencial/venta_deuda/GED/log

RUTA SALIDA: opensgc/secuencial/venta_deuda/GED/out


Tras revisar negocio la información de los ficheros anteriores se ejecuta en Open Cobros un proceso que filtra los tres ficheros enriquecidos en busca de posibles cambios de estado en OC (Cobrados) y los elimina.

El usuario nos debe pasar un fichero en formato Pari previamente filtrado. Este es el que utilizaremos como alimentación del proceso 109

RUTAS:

RUTA EJECUTABLE: /opensgc/secuencial/venta_deuda/CREDITOS/exec

RUTA DEL LOG: /opensgc/secuencial/venta_deuda/CREDITOS/log

PASO4 Cesión de deuda

Tras realizar la Venta de Deuda (firma del contrato) los usuarios de Negocio solicitan el cambio de estado a CESION DEUDA de los recibos vendidos.

Dado que el fichero de entrada que se facilitó en 2010 por los usuarios y se espera sea como el de este año tenía formato PARI en vez del requerido por este proceso será necesario extraer la información del mismo y realizar una adaptación de formato para los Id Facturas para cumplir el formato del fichero CBSEDEVERR.

138


Este proceso debe lanzarse en partes para lo que habrá que trocear el fichero de entrada y realizar varias ejecuciones.

Como paso final se realiza una revisión de todas las facturas que han sido solicitadas pasar a CESION DEUDA.

Para ello se compara manualmente la información del fichero de entrada con la información de los recibos que han sido insertados en la tabla CESION_DEUDA o que tienen el estado ER999 en la tabla RECIBOS.

Con la salida del 109 hay que lanzar también el proceso CBCCAM111 para generar los dos ficheros de Cifs y facturas erróneas a borrar en GED.

PROBLEMAS PROCESO DE EXTRACCION DE BBDD DETECTADOS EN ANTERIORES EXTRACCIONES:

Tras la primera ejecución de la extracción de Venta de Deuda para generar estos ficheros iniciales (DV, HR y NI) se detectaron una serie de errores y casuísticas no contempladas en el proceso actual de extracción.

Como hemos mencionado, el proceso CBCCAM107 no se modifica, tan sólo, dependiendo de los parámetros de entrada, hace un llamamiento al paquete de BBDD y realiza una extracción de los datos:

La query original, para deuda viva, lo que decía es: búscame todos los recibos que se encuentren en estado incobrable entre las fechas marcadas de la tabla de deuda viva, no filtraba por nada más

SELECT cust_code, external_id, tipo_cliente, titular, edv1.nif_pagador as nif_pagador, direccion, municipio, cod_postal, cuenta,num_fact,

NVL(TO_CHAR(f_devolucion, 'YYYYMMDD'), 'N/A') as fecha_dev, motivo_devolucion, imp_facturado, imp_recibo, imp_ajustado, imp_adeudado, tipo_cobro, NVL(TO_CHAR(f_cobro, 'YYYYMMDD'), 'N/A') as f_cobro, escenario,

estado, NVL(TO_CHAR(f_entrada_estado, 'YYYYMMDD'), 'N/A') as fecha_ent_est, NVL(TO_CHAR(f_salida_recobros, 'YYYYMMDD'), 'N/A') as fecha_sal_rec, mot_paralizacion, NVL(TO_CHAR(f_desactivacion, 'YYYYMMDD'), 'N/A') as fecha_desact, NVL(TO_CHAR(f_activacion, 'YYYYMMDD'), 'N/A') as fecha_act, est_factura, NVL(TO_CHAR(f_pago_ven, 'YYYYMMDD'), 'N/A') as fecha_ven, NVL(TO_CHAR(f_fact, 'YYYYMMDD'), 'N/A') as fecha_fact, cuenta_estudio, imp_original, moneda_original, id_moneda, NVL(TO_CHAR(f_entrada_recobros, 'YYYYMMDD'), 'N/A') as

fecha_ent_rec, agencia_externa

FROM extr_deuda_viva edv1where (TO_CHAR(edv1.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta)

and not exists (select * from extr_deuda_viva edv2 where edv1.external_id=edv2.external_id

and est_factura<>'Incobrable');

Esta consulta no tiene en cuenta, en nuestro caso, aquellos clientes que tienen recibos marcados como incobrables en el periodo empleado de extracción pero con recibos en fechas superiores a la de corte pero que no está en recobro, estos registros deben salir en la extracción, sólo deben quedar fuera aquellos que están marcados como incobrables dentro del rango seleccionado de fechas y que no tengan ningún recibo en estado incobrable o en recobro posterior a la fecha de corte.

La query correcta final es:

138


SELECT cust_code, external_id, tipo_cliente, titular, nif_pagador, direccion, municipio, cod_postal, cuenta,num_fact, NVL(TO_CHAR(f_devolucion, 'YYYYMMDD'), 'N/A') as fecha_dev, motivo_devolucion, imp_facturado, imp_recibo, imp_ajustado, imp_adeudado, tipo_cobro, NVL(TO_CHAR(f_cobro, 'YYYYMMDD'), 'N/A') as f_cobro, escenario, estado, NVL(TO_CHAR(f_entrada_estado, 'YYYYMMDD'), 'N/A') as fecha_ent_est, NVL(TO_CHAR(f_salida_recobros, 'YYYYMMDD'), 'N/A') as fecha_sal_rec, mot_paralizacion, NVL(TO_CHAR(f_desactivacion, 'YYYYMMDD'), 'N/A') as fecha_desact, NVL(TO_CHAR(f_activacion, 'YYYYMMDD'), 'N/A') as fecha_act, est_factura, NVL(TO_CHAR(f_pago_ven, 'YYYYMMDD'), 'N/A') as fecha_ven, NVL(TO_CHAR(f_fact, 'YYYYMMDD'), 'N/A') as fecha_fact, cuenta_estudio, imp_original, moneda_original, id_moneda, NVL(TO_CHAR(f_entrada_recobros, 'YYYYMMDD'), 'N/A') as fecha_ent_rec, agencia_externa FROM extr_deuda_viva where (TO_CHAR(f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and est_factura='Incobrable' and cust_code is not null and external_id not in (select /*+ Hash_aj */ edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD')) and external_id is not null;

Es importante mencionar que es fundamental el disponer de la correcta extracción de los recibos marcados como incobrables para el resto de consultas, ya que es la base con la que se trabaja para buscar sus recibos históricos en recobro y los cobrados.

Respecto a la query de histórico de recobro, los principales fallos detectados son:

- No tiene en cuenta los recibos en estado facturado, estos deben incluirse.

- La fecha que se empleaba para el periodo de extracción no era correcta, ya que no mostraba todo el histórico de facturas correspondientes a un cliente marcado como incobrable, es decir, por debajo de la fecha de corte no sacaba ningún recibo.

- Deben aparecer todas las facturas asociadas a un cliente, tanto las originales, las de importe cero como las rectificativas, esto no se tenía en cuenta en el filtro de la query original.

- Por último, hay que aplicar el mismo criterio de clientes marcados como incobrables empleado en la consulta de Deuda Viva, ya que este filtro es el correcto y mantiene una coherencia de recibos en todos los ficheros.

where (TO_CHAR(f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and est_factura='Incobrable' and cust_code is not null and external_id not in (select /*+ Hash_aj */ edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD'))

Query original de extracción de Histórico de recobros:

SELECT cust_code, external_id, tipo_cliente, titular, lpad(ehr.nif_pagador,9,'0')as nif_pagador, direccion, municipio, cod_postal, cuenta,num_fact,

NVL(TO_CHAR(f_devolucion,'YYYYMMDD'),'N/A') as fecha_dev, motivo_devolucion, imp_facturado, imp_recibo, imp_ajustado, imp_adeudado, tipo_cobro, NVL(TO_CHAR(f_cobro,'YYYYMMDD'),'N/A') as f_cobro, escenario, estado,

NVL(TO_CHAR(f_entrada_estado,'YYYYMMDD'),'N/A') as fecha_ent_est, NVL(TO_CHAR(f_salida_recobros,'YYYYMMDD'),'N/A') as fecha_sal_rec, mot_paralizacion, NVL(TO_CHAR(f_desactivacion,'YYYYMMDD'),'N/A') as fecha_desact, NVL(TO_CHAR(f_activacion,'YYYYMMDD'),'N/A') as fecha_act, est_factura, NVL(TO_CHAR(f_pago_ven,'YYYYMMDD'),'N/A') as fecha_ven, NVL(TO_CHAR(f_fact,'YYYYMMDD'),'N/A') as fecha_fact, cuenta_estudio, imp_original, moneda_original, id_moneda, NVL(TO_CHAR(f_entrada_recobros,'YYYYMMDD'),'N/A') as

fecha_ent_rec, agencia_externa

FROM extr_hist_recobros ehrwhere (TO_CHAR(ehr.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta)

and not exists (select * from extr_deuda_viva edv where ehr.external_id=edv.external_id

and est_factura<>'Incobrable')and exists (select * from extr_deuda_viva edv

where ehr.external_id=edv.external_id and est_factura='Incobrable');

Remarcamos en amarillo uno de los fallos fundamentales de esta consulta, si un cliente marcado como incobrable dentro de las fechas solicitadas, ha tenido recibos en recobro por debajo de la fecha de inicio (20080101) no aparecerán en esta consulta.

138


Query modificada:

SELECT c.cuenta_formato_largo as cust_code, r.external_id as external_id, ti.descripcion as tipo_cliente, r.titular as titular, lpad(r.nif_pagador,9,'0') as nif_pagador, NVL(d.domicilio, 'N/A') as direccion, NVL(d.pza_domicilio, 'N/A') as municipio, NVL(d.cod_postal, 'N/A') as cod_postal, NVL(r.banco_csb||r.suc_csb||r.dig_control||r.num_ccc,'N/A') as cuenta, r.id_factura as num_fact, r.motivo_devolucion as motivo_devolucion, r.imp_facturado as imp_facturado, r.imp_recibo as imp_recibo, r.imp_ajustado as imp_ajustado, r.tipo_cobro as tipo_cobro, NVL(TO_CHAR(/*f_cobro*/f_estado_actu,'YYYYMMDD'),'N/A') as f_cobro, r.est_actu as est_factura/*est_factura*/, NVL(TO_CHAR(r.f_pago_ven,'YYYYMMDD'),'N/A') as fecha_ven, NVL(TO_CHAR(r.f_fact,'YYYYMMDD'),'N/A') as fecha_fact, TRUNC(r.importe_original,3) as imp_original/*imp_original*/, r.moneda_original as moneda_original, r.id_moneda as id_moneda FROM recibos r, clientes c, direccion_pago d, tipo_cliente ti where ti.tipo_cliente=r.tipo_cliente and c.referencia=r.referencia and d.referencia=r.referencia and c.radical_emp=r.radical_emp and d.radical_emp=r.radical_emp and d.f_fact=r.f_fact and d.secuencial_rec=r.secuencial_rec and(TO_CHAR(r.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and r.est_actu ='ER010' and c.cuenta_formato_largo is not null and r.external_id not in (select /*+ Hash_aj */ edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD')) and r.external_id is not null;

Modificación:

Ahora se tiene en cuenta los clientes incobrables y sus recibos para buscar su histórico de forma correcta, ya no hay cortes en el fichero al extraer todos los recibos y muestra los recibos existentes por debajo de la fecha de corte.

Todos los recibos pertenecientes a los clientes de la venta de deuda que hayan estado en algún momento en recobros a excepción de aquellos ya incluidos en el anterior fichero (incobrables y facturados entre las fechas del 1 de Enero de 2008 y del 12 de Diciembre de 2010), en este caso se recogen los ficheros anteriores y posteriores a este periodo

Las facturas rectificadas o de importe negativo asociadas a alguna factura del punto anterior. Estas facturas nunca han estado en recobro como tal de manera que habrá que buscarlas en la tabla de recibos.

Query que extrae los recibos en estado Facturado:

CURSOR cur_deuda_viva_solo_facturado IS SELECT c.cuenta_formato_largo as cust_code, r.external_id as external_id, ti.descripcion as tipo_cliente, r.titular as titular, lpad(r.nif_pagador,9,'0') as nif_pagador, NVL(d.domicilio, 'N/A') as direccion, NVL(d.pza_domicilio, 'N/A') as municipio, NVL(d.cod_postal, 'N/A') as cod_postal, NVL(r.banco_csb||r.suc_csb||r.dig_control||r.num_ccc,'N/A') as cuenta, r.id_factura as num_fact, r.motivo_devolucion as motivo_devolucion, r.imp_facturado as imp_facturado, r.imp_recibo as imp_recibo, r.imp_ajustado as imp_ajustado, r.tipo_cobro as tipo_cobro, NVL(TO_CHAR(/*f_cobro*/f_estado_actu,'YYYYMMDD'),'N/A') as f_cobro, r.est_actu as est_factura/*est_factura*/, NVL(TO_CHAR(r.f_pago_ven,'YYYYMMDD'),'N/A') as fecha_ven, NVL(TO_CHAR(r.f_fact,'YYYYMMDD'),'N/A') as fecha_fact, TRUNC(r.importe_original,3) as imp_original/*imp_original*/, r.moneda_original as moneda_original, r.id_moneda as id_moneda FROM recibos r, clientes c, direccion_pago d, tipo_cliente ti where ti.tipo_cliente=r.tipo_cliente and c.referencia=r.referencia and d.referencia=r.referencia and c.radical_emp=r.radical_emp and d.radical_emp=r.radical_emp and d.f_fact=r.f_fact and d.secuencial_rec=r.secuencial_rec and(TO_CHAR(r.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and r.est_actu ='ER010' and c.cuenta_formato_largo is not null and r.external_id not in (select /*+ Hash_aj */ edv2.external_id

138


from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD')) and r.external_id is not null;

Query modificada de la tabla de recibos:

SELECT c.cuenta_formato_largo as cust_code/*cust_code*/, recib_f.external_id as external_id, ti.descripcion as tipo_cliente, recib_f.titular as titular, lpad(recib_f.nif_pagador,9,'0') as nif_pagador, NVL(recib_f.banco_csb||recib_f.suc_csb||recib_f.dig_control||recib_f.num_ccc,'N/A') as cuenta/*cuenta*/, SUBSTR(recib_f.ID_TRANS,7,5)||SUBSTR(recib_f.ID_TRANS,-1*12) as num_fact/*num_fact*/, recib_f.motivo_devolucion as motivo_devolucion, recib_f.imp_facturado as imp_facturado, recib_f.imp_recibo as imp_recibo, recib_f.imp_ajustado as imp_ajustado, recib_f.tipo_cobro as tipo_cobro, NVL(TO_CHAR(/*f_cobro*/recib_f.f_estado_actu,'YYYYMMDD'),'N/A') as f_cobro, recib_f.est_actu as est_factura/*est_factura*/, NVL(TO_CHAR(recib_f.f_pago_ven,'YYYYMMDD'),'N/A') as fecha_ven, NVL(TO_CHAR(recib_f.f_fact,'YYYYMMDD'),'N/A') as fecha_fact, TRUNC(recib_f.importe_original,3) as imp_original/*imp_original*/, recib_f.moneda_original as moneda_original, recib_f.id_moneda as id_moneda from tipo_cliente ti, clientes c, (select recib.* from recibos recib join (select rhcomp.external_id, rhcomp.num_fact, rhcomp.f_fact from ( select ehr.external_id, ehr.num_fact, ehr.f_fact FROM extr_hist_recobros ehr join ( (select distinct ant.external_id from (SELECT extr.external_id FROM extr_deuda_viva extr where (TO_CHAR(extr.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and extr.est_factura='Incobrable' and extr.cust_code is not null and extr.external_id is not null) ant left outer join (select distinct edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD') ) bnt on ant.external_id=bnt.external_id where bnt.external_id is null) union (select distinct ant.external_id from (SELECT r.external_id FROM recibos r where (TO_CHAR(r.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and r.est_actu ='ER010' and r.external_id is not null) ant left outer join (select distinct edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD') ) bnt on ant.external_id=bnt.external_id where bnt.external_id is null) ) an on ehr.external_id=an.external_id ) rhcomp left outer join (( select ant.external_id , ant.f_fact from (SELECT extr.external_id , extr.f_fact FROM extr_deuda_viva extr where (TO_CHAR(extr.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and extr.est_factura='Incobrable' and extr.cust_code is not null and extr.external_id is not null) ant left outer join (select distinct edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD') ) bnt on ant.external_id=bnt.external_id where bnt.external_id is null) union (select ant.external_id, ant.f_fact from (SELECT r.external_id, r.f_fact FROM recibos r where (TO_CHAR(r.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and r.est_actu ='ER010' and r.external_id is not null) ant left outer join (select distinct edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD') ) bnt on ant.external_id=bnt.external_id where bnt.external_id is null) ) an on rhcomp.external_id=an.external_id and rhcomp.f_fact=an.f_fact

138


where an.f_fact is null) recobro on recib.external_id=recobro.external_id and recib.f_fact=recobro.f_fact where recib.external_id=recobro.external_id and recib.f_fact=recobro.f_fact and SUBSTR(recib.ID_TRANS,7,5)||SUBSTR(recib.ID_TRANS,-1*12) <> recobro.num_fact) recib_f where recib_f.external_id=c.external_id and recib_f.radical_emp=c.radical_emp and ti.tipo_cliente=recib_f.tipo_cliente;

Query del fichero de No Impagados:

SELECT c.cuenta_formato_largo as cust_code/*cust_code*/, r.external_id as external_id, r.tipo_cliente as tipo_cliente, r.titular as titular, lpad(r.nif_pagador,9,'0') as nif_pagador,

NVL(r.banco_csb||r.suc_csb||r.dig_control||r.num_ccc,'N/A') as cuenta/*cuenta*/, SUBSTR(R.ID_TRANS,7,5)||SUBSTR(R.ID_TRANS,-1*VLONGITUDFACT) as num_fact/*num_fact*/,

r.motivo_devolucion as motivo_devolucion, r.imp_facturado as imp_facturado, r.imp_recibo as imp_recibo, r.imp_ajustado as imp_ajustado,

r.tipo_cobro as tipo_cobro, NVL(TO_CHAR(/*f_cobro*/f_estado_actu,'YYYYMMDD'),'N/A') as f_cobro, r.est_actu as est_factura/*est_factura*/, NVL(TO_CHAR(r.f_pago_ven,'YYYYMMDD'),'N/A') as fecha_ven,

NVL(TO_CHAR(r.f_fact,'YYYYMMDD'),'N/A') as fecha_fact, TRUNC(r.importe_original,3) as imp_original/*imp_original*/, r.moneda_original as moneda_original, r.id_moneda as id_moneda from recibos r, clientes c

where (TO_CHAR(r.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta)and r.re_switch=0

/*relaciones entre tablas*/ /*Relaciones entre tablas: recibos y clientes*/ and r.external_id=c.external_id and r.radical_emp=c.radical_emp

and not exists (select * from extr_deuda_viva edv where r.external_id=edv.external_id

and est_factura<>'Incobrable') and exists (select * from extr_deuda_viva edv where r.external_id=edv.external_id

and est_factura='Incobrable')UNION

SELECT c.cuenta_formato_largo as cust_code/*cust_code*/, r.external_id as external_id, r.tipo_cliente as tipo_cliente, r.titular as titular, lpad(r.nif_pagador,9,'0') as nif_pagador,




NVL(TO_CHAR(r.f_fact,'YYYYMMDD'),'N/A') as fecha_fact, TRUNC(r.importe_original,3) as imp_original/*imp_original*/, r.moneda_original as moneda_original, r.id_moneda as id_moneda from opcbr_h_recibos r, clientes c

where (TO_CHAR(r.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta)and r.re_switch=0

/*relaciones entre tablas*/ /*Relaciones entre tablas: recibos y clientes*/ and r.external_id=c.external_id and r.radical_emp=c.radical_emp

and not exists (select * from extr_deuda_viva edv where r.external_id=edv.external_id

and est_factura<>'Incobrable') and exists (select * from extr_deuda_viva edv where r.external_id=edv.external_id

and est_factura='Incobrable');

Query modificada:

Ahora aparecen todos los recibos pertenecientes a los clientes de la venta de deuda que no aparezcan en ninguno de los ficheros anteriores.

(SELECT c.cuenta_formato_largo as cust_code/*cust_code*/, r.external_id as external_id, ti.descripcion as tipo_cliente, r.titular as titular, lpad(r.nif_pagador,9,'0') as nif_pagador,




NVL(TO_CHAR(r.f_fact,'YYYYMMDD'),'N/A') as fecha_fact, TRUNC(r.importe_original,3) as imp_original/*imp_original*/, r.moneda_original as moneda_original, r.id_moneda as id_moneda from

tipo_cliente ti, (select rectodmen1.* from (select rectodos.* from (select rec.* FROM recibos rec join ( (select distinct ant.external_id from (SELECT extr.external_id FROM extr_deuda_viva extr where (TO_CHAR(extr.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and extr.est_factura='Incobrable' and extr.cust_code is not null and extr.external_id is not null) ant left outer join (select distinct edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable'

138


or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD') ) bnt on ant.external_id=bnt.external_id where bnt.external_id is null) union (select distinct ant.external_id from (SELECT r.external_id FROM recibos r where (TO_CHAR(r.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and r.est_actu ='ER010' and r.external_id is not null) ant left outer join (select distinct edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD') ) bnt on ant.external_id=bnt.external_id where bnt.external_id is null) ) an on rec.external_id=an.external_id) rectodos left outer join ( (select ant.external_id , ant.f_fact from (SELECT extr.external_id, extr.f_fact FROM extr_deuda_viva extr where (TO_CHAR(extr.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and extr.est_factura='Incobrable' and extr.cust_code is not null and extr.external_id is not null) ant left outer join (select distinct edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD') ) bnt on ant.external_id=bnt.external_id where bnt.external_id is null) union (select ant.external_id, ant.f_fact from (SELECT r.external_id , r.f_fact FROM recibos r where (TO_CHAR(r.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and r.est_actu ='ER010' and r.external_id is not null) ant left outer join (select distinct edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD') ) bnt on ant.external_id=bnt.external_id where bnt.external_id is null)) excluir1 on rectodos.external_id=excluir1.external_id and rectodos.f_fact=excluir1.f_fact where excluir1.f_fact is null) rectodmen1 left outer join (select rec.* FROM extr_hist_recobros rec join ( (select distinct ant.external_id from (SELECT extr.external_id FROM extr_deuda_viva extr where (TO_CHAR(extr.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and extr.est_factura='Incobrable' and extr.cust_code is not null and extr.external_id is not null) ant left outer join (select distinct edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD') ) bnt on ant.external_id=bnt.external_id where bnt.external_id is null) union (select distinct ant.external_id from (SELECT r.external_id FROM recibos r where (TO_CHAR(r.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and r.est_actu ='ER010' and r.external_id is not null) ant left outer join (select distinct edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD') ) bnt on ant.external_id=bnt.external_id where bnt.external_id is null) ) an on rec.external_id=an.external_id) excluir2 on rectodmen1.external_id=excluir2.external_id and rectodmen1.f_fact=excluir2.f_fact where excluir2.f_fact is null) r, clientes c

where r.external_id=c.external_id and ti.tipo_cliente=r.tipo_cliente)

UNION

138


(SELECT c.cuenta_formato_largo as cust_code/*cust_code*/, r.external_id as external_id, ti.descripcion as tipo_cliente, r.titular as titular, lpad(r.nif_pagador,9,'0') as nif_pagador,




NVL(TO_CHAR(r.f_fact,'YYYYMMDD'),'N/A') as fecha_fact, TRUNC(r.importe_original,3) as imp_original/*imp_original*/, r.moneda_original as moneda_original, r.id_moneda as id_moneda from

tipo_cliente ti, (select rectodmen1.* from (select rectodos.* from (select rec.* FROM opcbr_h_recibos rec join ( (select distinct ant.external_id from (SELECT extr.external_id FROM extr_deuda_viva extr where (TO_CHAR(extr.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and extr.est_factura='Incobrable' and extr.cust_code is not null and extr.external_id is not null) ant left outer join (select distinct edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD') ) bnt on ant.external_id=bnt.external_id where bnt.external_id is null) union (select distinct ant.external_id from (SELECT r.external_id FROM recibos r where (TO_CHAR(r.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and r.est_actu ='ER010' and r.external_id is not null) ant left outer join (select distinct edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD') ) bnt on ant.external_id=bnt.external_id where bnt.external_id is null) ) an on rec.external_id=an.external_id) rectodos left outer join ( (select ant.external_id , ant.f_fact from (SELECT extr.external_id, extr.f_fact FROM extr_deuda_viva extr where (TO_CHAR(extr.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and extr.est_factura='Incobrable' and extr.cust_code is not null and extr.external_id is not null) ant left outer join (select distinct edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD') ) bnt on ant.external_id=bnt.external_id where bnt.external_id is null) union (select ant.external_id, ant.f_fact from (SELECT r.external_id , r.f_fact FROM recibos r where (TO_CHAR(r.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and r.est_actu ='ER010' and r.external_id is not null) ant left outer join (select distinct edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD') ) bnt on ant.external_id=bnt.external_id where bnt.external_id is null)) excluir1 on rectodos.external_id=excluir1.external_id and rectodos.f_fact=excluir1.f_fact where excluir1.f_fact is null) rectodmen1 left outer join (select rec.* FROM extr_hist_recobros rec join ( (select distinct ant.external_id from (SELECT extr.external_id FROM extr_deuda_viva extr where (TO_CHAR(extr.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and extr.est_factura='Incobrable' and extr.cust_code is not null and extr.external_id is not null) ant left outer join (select distinct edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD') ) bnt on ant.external_id=bnt.external_id where bnt.external_id is null) union (select distinct ant.external_id from

138


(SELECT r.external_id FROM recibos r where (TO_CHAR(r.f_fact, 'YYYYMMDD') BETWEEN vf_fact_desde AND vf_fact_hasta) and r.est_actu ='ER010' and r.external_id is not null) ant left outer join (select distinct edv2.external_id from extr_deuda_viva edv2 where (edv2.est_factura='Incobrable' or edv2.est_factura='Recobros') and edv2.external_id is not null and edv2.f_fact > to_date(vf_fact_hasta,'YYYYMMDD') ) bnt on ant.external_id=bnt.external_id where bnt.external_id is null) ) an on rec.external_id=an.external_id) excluir2 on rectodmen1.external_id=excluir2.external_id and rectodmen1.f_fact=excluir2.f_fact where excluir2.f_fact is null) r, clientes c

where r.external_id=c.external_id and ti.tipo_cliente=r.tipo_cliente);

PASO A INCOBRABLESEsta petición nos llega como SSBB dos veces al año, una a finales de agosto y otra a finales de diciembre, este proceso consiste en marcar como incobrables aquellos clientes que dispongan de facturas que no se van a cobrar dentro del periodo de fechas que nos indiquen desde Negocio, para su posterior venta de deuda.

Todas las acciones se han de realziar mediante GGCC, tanto el marcado de incobrables en la BBDD como la publicación al restod e sistemas de la actualziación del estado de la deuda de estas facturas y clientes al resto de sistemas (SIEBEL, SGMR, RESER Y HPFMS.)

1º.- Ejemplo de petición:

HD1000003678516

Asunto: Paso a estado incobrable de los recibos comprendidos entre fechas.

Descripción:Servicio Basico / Solicitudes a grupos de Sistemas de Información / OPENCOBROS / Gestión de Pagos Anticipados /:

Write Off: Paso a estado incobrable de los recibos comprendidos entre las siguientes fechas factura: 16/06/2011 a 12/12/2011 Incluidos

Persona de contacto: Alberto De Blas

Teléfono de contacto: 656160748

Número de unidades solicitadas: 1

Acuerdo SLA:

2º.- Mediante la herramienta ECLIPSE emplearemos nuestra clase de Java para marcar los incobrables.

Los SCRIPS a usar son:

138


1º Configuramos el conector de la BBDD

Y vemos que esta descomentada la conexión a producción:

138


Como 2º configuramos. Declaracionincobrbles.java

Tenemos que cambiar la fecha, y poner la que nos paso negocio:

Le damos a ejecutar y al cabo de unos 20 minutos, nos tiene que aparecer:

Obtener conexión con la BBDD ....

Conexión con la BBDD obtenida ....

Iniciando el proceso principal ....

==============================

Obtener el número de registros

==============================

Número de recibos a pasar a incobrables: 216770

=======================================

Obteniendo registros

=======================================

Guardamos el número marcado en negrita, y luego se irán guardando ficheros en la ruta local:

C:\ORANGE\ARCHIVOS\declaracionIncobrables

=======================================

Obteniendo registros

=======================================

1 - La lista de recibos contiene 10000

Generando archivo

138


C:/ORANGE/ARCHIVOS/declaracionIncobrables/declaracionIncobrables_20111212_bloque_1.TXT

Archivo generado ....

Recuperando los registros 10001 a 35000

2 - La lista de recibos contiene 25000 elementos

Generando archivo C:/ORANGE/ARCHIVOS/declaracionIncobrables/declaracionIncobrables_20111212_bloque_2.TXT











Una vez finalizado muestra el siguiente mensaje en el eclipse





Proceso principal finalizado ....

Conexión con la BBDD cerrada ....

138


Observamos los ficheros generados están en nuestro pc.

Ejemplo de GGCC para esta Fase:

Una vez finalizados, nos pondremos a subirlos a la ruta indicada a continuación y se deben cargar uno a uno de la siguiente manera

a) Dejamos el 1º fichero generado en la siguiente ruta:

/openp1/opencobp/opensgc/secuencial/incobrable

b) Se lanza el proceso: de la ruta /openp1/opencobp/control_m/exec

nohup CMUX4315.ksh &

c) Los archivos se mueven de forma automática a:

/openp1/opencobp/opensgc/secuencial/incobrable_open

El nombre del fichero modificado será: CBSE4315

d) Se lanza el proceso: de la ruta /openp1/opencobp/control_m/exec

138


nohup CMCC4315.ksh &

e) Realizar monitorización (comando pr en UNIX) hasta que finalice dicho proceso, una vez que termine , cargamos el 2º fichero generado y volvemos a empezar desde el punto a)

Se espera a que pase el Proceso nocturno del Recobro, Una vez pasado el proceso del recobro, ya quedan los recibos para ser tratados al estar marcados como incobrables, y empezaremos a publicar el estado de la deuda al resto sistemas: SIEBEL, SGMR, RESER Y HPFMS

A la espera de negocio lanzamos a primera hora CMCC5810.ksh,

Este proceso es incompatible con:

Recobro Bancario Formación Bajada

Se lanza el proceso a primero hora de la mañana:

/openp1/opencobp/control_m/exec

nohup CMCC5810.ksh &

Ejemplo de GGCC para esta fase: CHG000000043974

Debemos tener el eclipse de JAVA y lanzar el proceso a la vez.

Para ir pasándolo a estado 9 los recibos, y tenerlos controlados, para que no se publiquen de forma masiva y automáticamente mediante eventos MDW y que saturemos sistemas como SIEBEL:

138


Se debe seguir monitorizando de forma contínua el proceso para ver que se ejecuta correctamente.

3º.- Como paso final, se debe conocer e informar en un mail a Servicio y Negocio el número de recibos que se han tratado y el importe total de los recibos.

Ejecutaremos la siguiente consulta parametrizando:

1) La fecha de fctura que nos hayan indicado.

2) La fecha o fechas de actualización del estado

3) El programa que realiza la actualización: CBCC5810.

select count(*) nmRecibos, sum(imp_recibo) importe

from recibos

where est_actu = 'IN001'

and radical_emp = '01'

and f_fact <= to_date('12/12/2010','DD/MM/YYYY')

and programa = 'CBCC5810'

and (f_estado_actu = to_date ('23/12/2011','DD/MM/YYYY')

or f_estado_actu = to_date ('24/12/2011','DD/MM/YYYY')

or f_estado_actu = to_date ('25/12/2011','DD/MM/YYYY'));

138


Contingencia Resumen Devoluciones Erróneas

Desde la implantación del proyecto "OPER2011-5349. Adaptación del Recobro 40-60 días" todas las devoluciones caen en el fichero de menos de 58 y es erróneo puesto que las remesas activas son las de plazo de devolución a 30 días.

Analizando la fecha en que deberían de empezar a generarse los ficheros de “dev_erroneas_menos_58_dias_yyyymmdd.dat”, “dev_erroneas_58_a_60_dias_yyyymmdd.dat” y “dev_erroneas_mas_60_dias_yyyymmdd.dat” se observa que hay un intervalo de tiempo en que conviven ambos plazos de devolución (30 y 60) por lo que es necesaria realizar la Contingencia para según el plazo de devolución de incluya en el fichero correspondiente.

Se identifican que el periodo de convivencia es del 14/01/2013 al 31/01/2013. En este tiempo se ejecutarán los siguientes scripts:

Contingencia_dev_erroneas_31_a_33_dias.shContingencia_dev_erroneas_58_a_60_dias.shContingencia_dev_erroneas_mas_33_dias.shContingencia_dev_erroneas_mas_60_dias.shContingencia_dev_erroneas_menos_31_dias.shContingencia_dev_erroneas_menos_58_dias.sh

Cada script creará el fichero correspondiente a su nombre con las devoluciones que procedan y los enviará por ftp como se hacía anteriormente.

La contingencia estará activa hasta el 31/01/2013 y a partir del 01/02/2013 se ejecutará en planificación los scripts desarrollados por el proyecto al haber vencido todas las remesas con plazo de devolución a 30 días.

138


Fallo FTP CBCCAM110 Fichero de control a ACCON

Tras el fallo del día 26/12/2012 de ftp de informe de pagos se observa que el fichero de control no se genera correctamente por no haberse movido el fichero a backup (se queda en /out hasta su envío)

Se modifica con petición HD1000003695177 la criticidad del fallo en ftp del informe de Pagos de forma que desde Soporte:

Si falla el ftp a la máquina del usuario o a adda1p se moverá de forma manual el informe de pagos a la ruta de backup y se dará condición al resto de Jobs para que el fichero de control se ejecute correctamente. En paralelo se subirá el informe cuando la máquina esté disponible.

Si falla el ftp a la máquina de sitamp, habrá que esperar a que tenga espacio para continuar el resto de Jobs, ya que no se debe generar el fichero de control hasta que se genere el informe de pagos (el informe de control solo es aplicable a ACCON y es lo que quedaría pendiente de ejecutar). Si hay que revisar si el ftp se ha realizado correctamente.

De esta forma se evita el impacto en ACCON.

Casos de rectificación de una factura de importe 0

Tras ser costoso de resolver el caso de rectificación de una factura de importe 0 para la empresa Tiermansa, entre Oc y Abacus se definió la siguiente oper

1º Por parte de ABACUS generaremos un fichero con los datos de la factura original, con los importes a 0, siguiendo el AI que hay en la actualidad entre BSCS y Open.

2º Open tratará este fichero, de manera que quede cargada en su base de datos la factura original con el importe a 0.

3º Desde ABACUS procederemos a generar un nuevo evento Middleware con los datos de la rectificación, de manera que ya quede correctamente tramitada al existir la factura original en Open.

Siguiendo estos pasos es como conseguimos regularizar el caso de Tiermansa.

open cobros - manual de soporte v2.1

Documents

recogida manual de ficheros

ficheros de devoluciones

ficheros de forma manual

open cobros open cobros

carga manual de transferencias

informe diario

revisin de hotlines

aplicativo open cobros