Date post: | 04-Dec-2015 |
Category: |
Documents |
Upload: | gabriel-valencia |
View: | 39 times |
Download: | 12 times |
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
/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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
AUTO.En caso de error recogida manual
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
AUTO.En caso de error recogida manual
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
EDITRAN/ora_data3/editran/REC_COBROS/
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
EDITRAN/ora_data3/editran/REC_COBROS/
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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.
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.
3
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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.
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 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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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.
De cobros movilcontrol
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Ejecutar la sentencia “grep ^5690 fichero | wc –l” con cada uno de los ficheros de devoluciones recogidos en la fecha actual.
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
Ejecutar “tail -1 out_CBCC1010_YYYYMMDDHHMISS” y verificar que aparece el mensaje “TERMINOBIEN”
Numero de operaciones en los ficheros:
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
Open Cobros - Manual de soporte
Numero de operaciones en la bbdd:Ir a la base de datos de OPEN COBROS en el entorno de PRODUCCION
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.
Numero de operaciones en los ficheros descargados desde editran:
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.
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.
VENTANILLASLog de ventanillas:/openp1/opencobp/control_m/log_control_m/out_CBCC0910_YYYYMMDDHHMISS
Ejecutar “tail -1 out_CBCC0910_YYYYMMDDHHMISS” y verificar que aparece el mensaje “TERMINOBIEN”
Numero de operaciones en los ficheros:
Ir a la ruta /openp1/opencobp/storage/bancos/recibido/ventanilla
Ejecutar la sentencia “grep ^6070 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
Ejecutar las consultas:
3
Open Cobros - Manual de soporte
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.
Numero de operaciones en los ficheros descargados desde editran:
Ir a la ruta /openp1/opencobp/storage/ventanilla
Ejecutar la sentencia “grep ^6070 fichero | wc –l” con cada uno de los ficheros de devoluciones recogidos en la fecha actual.
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.
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
'' ) || '.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
Open Cobros - Manual de soporte
En General le damos a “calcular prioridad”
3
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
Tomaremos como ejemplo el correo enviado un lunes con datos del sábado y domingo.
De cobros movilcontrol
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.
De cobros movilcontrol
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
3
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
De cobros movilcontrol
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 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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros - Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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:
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
- 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
Open Cobros – Manual de soporte
De cobros movilcontrol
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
Open Cobros – Manual de soporte
|| 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:
De cobros movilcontrol
Para VILLAVIEJA ROMERO, Ana Luisa; ES, ssbb revenue
Asunto RE: Editran_Cobros
Buenos días,
138
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
De cobros movilcontrol
Para VILLAVIEJA ROMERO, Ana Luisa; ES, ssbb revenue
Asunto RE: Editran_Cobros
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
138
Open Cobros – Manual de soporte
Recepción de datos de HL y CB de SITAM
Se recibe al día siguiente los datos de HL y CB de SITAM.
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
Open Cobros – Manual de soporte
Y para CB, el mismo formato:
138
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
'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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
138
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
'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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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.
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.
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
Open Cobros – Manual de soporte
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:
CODIGO CENTRO DE COBRO IMPORTE_TOTAL
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
604 Banesto (Ajeno) 20627.11
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:
CODIGO CENTRO DE COBRO IMPORTE_TOTAL
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
138
Open Cobros – Manual de soporte
604 Banesto (Ajeno) 20627.11
904 Bilbao Vizcaya (Propio) 11959.93
905 Bilbao Vizcaya (Ajeno) 16942.94
1004 Unicaja (Propio) 1172.93
1005 Unicaja (Ajeno) 3800.58
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
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
138
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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.
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.
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:
CODIGO CENTRO DE COBRO IMPORTE_TOTAL
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
604 Banesto (Ajeno) 20627.11
904 Bilbao Vizcaya (Propio) 11959.93
905 Bilbao Vizcaya (Ajeno) 16942.94
1004 Unicaja (Propio) 1172.93
1005 Unicaja (Ajeno) 3800.58
Un Saludo
138
Open Cobros – Manual de soporte
- 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:
CODIGO CENTRO DE COBRO IMPORTE_TOTAL
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
604 Banesto (Ajeno) 20627.11
904 Bilbao Vizcaya (Propio) 11959.93
905 Bilbao Vizcaya (Ajeno) 16942.94
1004 Unicaja (Propio) 1172.93
1005 Unicaja (Ajeno) 3800.58
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
Open Cobros – Manual de soporte
un saludo.
138
Open Cobros – Manual de soporte
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
Para cobros movilcontrol
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
Open Cobros – Manual de soporte
/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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
**************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.
De cobros movilcontrol
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
Open Cobros – Manual de soporte
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
Para cobros movilcontrol
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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.
De cobros movilcontrol
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
138
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
138
Open Cobros – Manual de soporte
138
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
Son los backups del informe del último trimestre de 2010, primer trimestre de 2011 y segundo trimestre de 2011 respectivamente.
138
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
- 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
Open Cobros – Manual de soporte
Por último contestaremos el correo a Santiago Tomás indicándole el resultado del tratamiento de los BINES en OC y en NETPlus.
138
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
- 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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
-- 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
Open Cobros – Manual de soporte
-- 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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
Nos aparecería la siguiente ventana:
E indicaríamos la opción “Si”
Quedaría de la siguiente manera:
138
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
PASO2 Proceso CBCCAM108:
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
Open Cobros – Manual de soporte
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
PASO3 Proceso CBCCAM109:
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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(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 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(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
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
(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(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
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
Open Cobros – Manual de soporte
(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
Open Cobros – Manual de soporte
1º Configuramos el conector de la BBDD
Y vemos que esta descomentada la conexión a producción:
138
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Archivo generado ....
Recuperando los registros 35001 a 60000
3 - La lista de recibos contiene 25000 elementos
Generando archivo C:/ORANGE/ARCHIVOS/declaracionIncobrables/declaracionIncobrables_20111212_bloque_3.TXT
Archivo generado ....
Recuperando los registros 60001 a 85000
4 - La lista de recibos contiene 25000 elementos
Generando archivo C:/ORANGE/ARCHIVOS/declaracionIncobrables/declaracionIncobrables_20111212_bloque_4.TXT
Archivo generado ....
Recuperando los registros 85001 a 110000
Una vez finalizado muestra el siguiente mensaje en el eclipse
Recuperando los registros 210001 a 235000
10 - La lista de recibos contiene 6763 elementos
Generando archivo C:/ORANGE/ARCHIVOS/declaracionIncobrables/declaracionIncobrables_20111212_bloque_10.TXT
Archivo generado ....
Proceso principal finalizado ....
Conexión con la BBDD cerrada ....
138
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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
Open Cobros – Manual de soporte
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.