Download Icon
Document related concepts
no text concepts found
Transcript
INSTITUTO POLITÉCNICO NACIONAL UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS “DISEÑO DE IMPLEMENTACIÓN DEL SISTEMA SPEI PARA OPTIMIZAR PROCESOS INTERNOS DE VWBANK” T E QUE PARA S OBT ENER I N G E N I E R O P R E D A R I O J U A N I S E N E P A M E L A MÉXICO. DF EL A T ÍT ULO DE: I N F O R M Á T I C A N E S T R A D A F R A N C I S C O N T A : M É N D E Z J U À R E Z H U R T A D O N M U Ñ O Z A L V A R A D O 2009 2009 Índice Resumen. I Introducción. III CAPÍTULO I. MARCO METODOLÓGICO. 1.1 Planteamiento del problema. 1 1.2 Objetivos. 2 1.3 Técnicas e Instrumentos de Medición. 2 1.4 Universo y muestra 2 1.5 Justificación 2 CAPÍTULO II. MARCO TEÓRICO. 2.1 Sistema SPEI 3 2.1.1 Antecedentes 4 2.1.2 ¿Cómo funciona SPEI? 4 2.1.3 Beneficios del SPEI 5 2.1.4 Requisitos para uso del SPEI 2.2 Reporte de necesidades y requerimientos 7 2.2.1 Funcionalidad Requerida 8 2.2.2 Pruebas Requeridas 8 2.2.3 Recursos Necesarios 9 2.2.4 Seguridad 9 2.2.5 Riesgos 9 2.2.6 Producto Final 2.3 Java Platform, Enterprise Edition o Java EE 10 10 2.3.1 Historia de Java 10 2.3.2 Plataforma Java 11 2.3.2.1 Java Runtime Environment 12 2.3.2.2 Bytecode 12 2.3.2.3 Máquina Virtual de Java 13 Servidor de Aplicaciones 14 2.3.3.1 Servidor de Aplicaciones J2EE 14 2.3.4 API 15 2.3.5 Programación Orientada a Objetos 15 2.3.5.1 Objetos 15 2.3.5.2 Clases 16 2.3.5.3 Abstracción 16 2.3.5.4 Mensajes y Métodos 17 2.3.3 2.3.6 2.3.5.5 Encapsulamiento 17 2.3.5.6 Herencia 18 2.3.5.7 Polimorfismo 19 Elementos del Lenguaje 19 2.3.6.1 Definición de Clases 19 2.3.6.2 Declaración de Variables de Instancia 20 2.3.6.3 Implementación de Métodos 20 2.3.6.4 Creación de Objetos 21 2.3.6.5 Constructores 21 2.3.6.5.1 Constructores Múltiples 21 2.3.6.6 Acceso a Variables y Métodos 21 2.3.6.7 Herencia de Clases en Java 22 2.3.6.8 Sobrecarga de métodos y de constructores 22 2.3.6.9 Sobre escritura de Métodos 23 2.4 JBASE 23 2.4.1 Introducción 23 2.4.2 Estructura de directorios JBASE 24 2.4.2.1 Demonios JBASE 25 2.4.3 Características de JBASE 25 2.4.4 Beneficios 26 2.4.5 Infobasic 27 2.4.5.1 Sintaxis 27 2.4.5.2 Procesos y Control de Flujo 28 2.5 TEMENOS T24 Core Banking 29 2.5.1 Tecnología 29 2.5.2 Funcionalidad 30 2.5.3 Opciones de base de datos 31 2.5.4 TCServer 31 2.5.4.1 Requisitos para instalar TCServer 31 2.5.4.2 Tecnología 32 2.5.4.3 Arquitectura 32 2.6 Web services 2.6.1 34 Estándares Empleados 34 2.6.1.1 Web Services Protocol Stack 34 2.6.1.2 XML 35 2.6.1.2.1 Ventajas 36 2.6.1.3 SOAP 36 2.6.1.4 WSDL 36 2.6.1.5 UDDI 37 2.6.1.6 WS-Security 37 2.6.2 Ventajas de los Web Services 38 2.6.3 Funcionamiento 38 2.6.4 Implementación 40 CAPÍTULO III. ANÁLISIS DE LOS PROCESOS INTERNOS DE VWBANK PARA LA IMPLEMENTACIÓN DEL SISTEMA SPEI (DIAGNÓSTICO) 3.1 Área de Captación. 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 Definición Políticas 3.1.2.1 Políticas Generales del Área de Captación 3.1.2.1.1 Proceso para aprobación de productos de captación tradicional 3.1.2.1.2 Proceso de baja de productos de Captación 3.1.2.1.3 Políticas de Comunicación Interna (Captación) 3.1.2.1.3.1 Lineamientos de Formato 43 3.1.2.1.3.2 Lineamientos generales 3.1.2.2 Productos de Captación Tradicional 3.1.2.2.1 Productos de captación para personas Físicas y Morales 3.1.2.2.1.1 “Depósito retirable con previo aviso”. 3.1.2.2.1.2 Inversión. 3.1.2.2.1.3 Inversión Corporativa 3.1.2.3 Apertura de Cuentas 3.1.2.3.1 Alta de Cliente 3.1.2.3.2 Alta de Cuenta 3.1.2.3.2.1 Clientes Nuevos / Inactivos. 3.1.2.3.2.2 Clientes Activos (con cuenta de “D.R.P.A.” activa) Alta de Clientes Inversión 3.1.4.1 Diagrama de Flujo de Inversión. Generación de movimientos contables (CAPTACION) 3.1.5.1 Diagrama de Flujo de Generación de Movimientos Contables 3.2 Área de Colocación. 41 41 42 42 42 43 43 43 44 44 44 45 46 47 47 47 47 48 48 52 54 54 56 56 3.2.1 Introducción 56 3.2.2 Domiciliación 57 3.2.2.1 Flujo de Domiciliación 59 Devolución de Dinero 59 3.2.3.1 Flujo de Devolución de Dinero 61 Reclasificación de Pago 61 3.2.4.1 Flujo de Reclasificación de Pago 63 Generación de Movimientos Contables 63 3.2.5.1 Flujo de Generación de Movimientos Contables 65 Casos Post Venta 65 3.2.3 3.2.4 3.2.5 3.2.6 3.2.6.1 Flujo de Casos Post Venta 3.3 Área de Tesorería. 67 68 3.3.1 Introducción 68 3.3.2 Money Market 69 3.3.2.1 Money Market a la vista 69 3.3.2.2 Money Market a plazo 69 3.3.2.3 Money Market Cedido 69 3.3.2.4 Money Market Tomado 70 Pagos a terceros 70 3.3.3 CAPÍTULO IV. PROPUESTA DE ARQUITECTURA Y DISEÑO DE COMPONENTES SPEI 4.1 Propuesta de Arquitectura 71 4.2 Conectividad y relación entre T24 y Servidor de Enlace SPEI 72 4.2.1 Comunicación de Web Services 72 4.3 Conectividad y relación entre Servidor de Enlace SPEI y Application Server Geronimo 72 4.3.1 Comunicación de Web Services 72 4.3.2 Configuración de TCServer y TCClient 73 4.3.3 TCServer 74 4.3.3.1 Formaters 75 4.3.3.2 Adapters 75 4.3.3.3 Listeners 75 4.3.3.4 Inter conectividad de TCServer. 75 TCClient 76 4.3.4 4.4 Componentes Java 4.4.1 76 Geronimo 77 4.4.1.1 WSSpei.war 77 4.4.1.2 MessageDrivenBean.jar 77 4.4.1.3 TCClient 77 4.4.2 MQ-Series 77 4.4.3 Server T24mxP (T24) 78 4.5 Diseño de nueva arquitectura y componentes básicos 4.5.1 78 Componentes T24 78 4.5.1.1 Tabla MX.Domiciliación 79 4.5.1.2 Tabla FUNDS.TRANSFER 79 4.5.1.3 Tabla MM.MONEY.MARKET 80 4.5.1.4 Tabla VW.SPEI.DESC.ESTATUS 80 4.5.1.5 Tabla MX.DOMI.SPEI.ERR 80 4.5.1.6 Tabla VW.SPEI.PARAM 81 4.5.1.7 Tabla VW.SPEI.DESCR.ERRORES 81 4.5.1.8 Versiones 81 4.5.1.9 Rutinas 83 4.5.1.10 Enquiries 85 4.6 Parametrización T24 4.6.1 Parametrización Tabla VW.SPEI.PARAM 85 86 CAPÍTULO V. IMPLEMENTACIÓN Y BENEFICIOS QUE SE OBTENDRÁN COMO CONSECUENCIA. 5.1 Impacto del nuevo diseño e integración de compontes. 87 5.1.1 Proceso de Captación sin SPEI 87 5.1.2 Proceso de Captación con SPEI 89 5.1.3 Proceso de Colocación sin SPEI 90 5.1.4 Proceso de Colocación con SPEI 91 5.1.5 Tesorería con SPEI 92 5.2 Análisis de Requerimientos para la implementación 93 5.2.1 Servidor Geronimo 93 5.2.2 Requisitos previos en T24 94 5.2.3 Estructura de Directorios en T24 95 5.3 Procedimiento de Instalación. 5.3.1 Componentes de T24 5.4 Relación de costo-beneficio en las nuevas áreas 96 96 97 5.4.1 Costos 97 5.4.2 Beneficios 97 5.4.2.1 Beneficios Cuantificables 97 5.4.2.2 Beneficios No Cuantificables 100 Conclusión 102 Bibliografía 104 Glosario 106 Anexo 109 Resumen La ciencia de la informática en los últimos años ha jugando un factor muy importante en el crecimiento de nuestra sociedad, los sistemas de información han obtenido un lugar significativo dentro del funcionamiento de las organizaciones. Las instituciones financieras no podían ser la excepción, actualmente la operatividad de estas instituciones se debe en gran medida a los sistemas de información, el significativo crecimiento de la informática ha permitido sin lugar a dudas la incorporación de servicios que facilitan la expansión y mejora en el servicio a los clientes de las instituciones financieras. De acuerdo con los artículos 2do y 3ero de la Ley de Bancos de México, El Banco de México ha informado con efectos de mejorar y proporcionar un buen funcionamiento de los sistemas de pago, la necesaria incorporación del Sistema de Pagos Electrónicos Interbancarios en el banco VW Bank S.A. Institución de banca múltiple, en adelante VW Bank, así como en todos las entidades financieras que aun no cumplan con este servicio. Este trabajo detalla y explica el diseño de una herramienta indispensable en la banca nacional: el Sistema de Pagos Electrónicos Interbancarios. En estos días donde el mejor servicio proporcionado significa considerablemente mayor captación de dinero y por ende de clientes, es sin duda, de suma importancia la incorporación de este sistema al banco de estudio y desde luego para dar cumplimiento a ley a la que están sujetas todas las entidades financieras. La mayoría de los bancos que actualmente se encuentran en funcionamiento en México cuentan ya con su Sistema de pagos Electrónicos - SPEI, cada uno adaptado a sus necesidades, sin embargo por tratarse de un banco nuevo y sobre todo por el tipo de banco que es VW Bank es necesario adaptar un sistema SPEI que facilite su operación y procesos internos. Primero se detallan los requerimientos realizados por los usuarios y diferentes áreas dentro de VW Bank, para tener así un panorama completo de todas las necesidades, alcances y objetivos del proyecto. Más delante se plasman todas las herramientas, técnicas y conocimientos que serán utilizados en este primer diseño del sistema SPEI. Habiendo tantas herramientas y técnicas disponibles en la actualidad, se decidió incorporar herramientas “open source”, es decir, herramientas informáticas como lenguajes de programación que son gratuitos, sin embargo es necesario también trabajar sobre la plataforma o Core bancario que fue adquirido por VW Bank. Tomando en cuenta la situación actual de cada una de las áreas dentro de VW Bank se comenzará a analizar y diseñar la nueva arquitectura que deberán seguir los nuevos procesos internos, esta arquitectura facilitara y agilizara dichos procesos de manera significativa, no solo reducirá los tiempos de cada uno de los procesos, también permitirá la incorporación de nuevas operaciones y la reducción de costos de cada transferencia interbancaria. Una vez rediseñados todos los procesos de VW Bank esta tesis detallara la implementación, consecuencias, mejora, impacto y beneficios que se obtendrán después de incorporar este sistema de pagos en los procesos actuales de VW Bank. II Introducción A partir del 2 de enero del presente año como resultado de los acuerdo establecidos entre la Asociación de Bancos y Banco de México (BANXICO) no es posible realizar envíos de capital por un monto mayor a $50,000.00 con los actuales procesos de VW Bank. Situación que limita las posibilidades de cobro y pago de la conexión vía HSBC por pagos referenciados. En la actualidad esta es una limitante importante, la cual impide el crecimiento de VW Bank, los clientes requieren una agilidad en dichos procesos de envío de capital. Esta movilidad de recursos sin importar el monto de tales transferencias sólo será posible mediante la conexión al Sistema de Pagos Electrónicos Interbancarios (SPEI), sistema creado y administrado por el Banco Central (BANXICO) para este fin. La idea general del proyecto es contar con una herramienta eficaz (Interfase) que logre la conexión en línea entre el sistema T24 y BANXICO, utilizando el sistema SPEI para agilizar los procesos de las áreas de Colocación, Captación y Tesorería Back Office que se verán influenciados por el volumen de clientes que maneje la institución y así evitar posibles riesgos en la transferencia de la información. Por lo antes expuesto es de suma importancia contar con un proceso en línea para que VW Bank pueda mejorar la calidad en el servicio a los terceros y participantes y lograr que el flujo de información y efectivo sea de forma clara, precisa y eficaz. La prioridad de este proyecto es alta, ya que VWB actualmente esta realizando las operaciones por medio de archivos razón por la cual el proceso es lento, por lo que se tiene la necesidad de ejecutarlas en línea desde T24 a BANXICO a través del Enlace SPEI. III CAPÍTULO I. MARCO METODOLÓGICO 1.1 Planteamiento del problema VW Bank desde sus inicios se planteo como un banco directo sin sucursales, donde todas las transacciones se realizan por teléfono, para ser cliente de VW Bank es necesario tener una cuenta en otro banco, dicho banco deberá de ser uno de los cuales tiene convenio con VW Bank, y así, de esta cuenta externa se toma el dinero para invertir, también se depositan los rendimientos generados y/o regresara el capital inicialmente invertido para que el cliente pueda disponer de este mismo, los pagos a los créditos adquiridos en VW Bank deberán ser depositados también en dichas cuentas externas, de manera que VW Bank haciendo uso de procesos interbancarios retirara ese dinero de dichas cuentas. En VW Bank la generación de las órdenes de pago y devoluciones de dinero a los clientes se realiza por medio de la generación de archivos los cuales contienen las transacciones recopiladas vía telefónica por los clientes, en primera instancia se registran y generan las transacciones en el sistema Collection System ( SAP ) y posteriormente se envía el archivo para ser procesado en la plataforma central del banco T24 (Core bancario), una vez procesados en T24 es enviado un segundo archivo al banco destino el cual realiza la transacción y envía de regreso a VW Bank un acuse de recibido, todo esto en un tiempo T+1 día. El área de Cash Management (CM) recibe las peticiones de Captación y Colocación, posteriormente CM genera un archivo y este es enviado al servidor T24 donde existe una aplicación que monitorea que algún archivo llegue y este es procesado automáticamente en el sistema T24. Después de ser procesado en T24 se genera un archivo de petición con el formato CECOBAN en este proceso se dispersan las órdenes de pago a los distintos bancos destino, dependiendo el origen de la cuenta espejo del cliente. Una vez que el banco destino aplico la transacción envía de regreso a VW Bank un tercer archivo con acuse de recibido para que en T24 se aplique contablemente el cargo a la cuenta en el Core bancario T24. Con la incorporación del sistema SPEI en línea a los actuales procesos de captación y colocación se espera que cuando las peticiones de pago sean realizadas se registren contablemente en el sistema local T24 y en la cuenta espejo del cliente en el banco Externo en un tiempo no mayor a 20 minutos como lo marcan las regulaciones de Banco de México. También están consideradas las operaciones que realice la tesorería y las operaciones entrantes es decir los depósitos que provengan de otro banco. 1 1.2 Objetivo Diseñar el entorno necesario para la implementación del sistema SPEI online, basado en la arquitectura J2EE Web Services, fusionando el enlace de BANXICO y T24 Core bancario, optimizando y cuidando en todo momento los procesos de captación, colocación y tesorería de VW Bank. La implementación debe cumplir con las especificaciones establecidas (por BANXICO) para las órdenes de pago, como receptor (tiempos de contestaciones, aplicación, devoluciones) y como emisor (Formato de la información), a su vez debe integrarse un módulo de reporteo que permita monitorear toda la actividad del sistema SPEI. 1.3 Técnicas e Instrumentos de Medición Se utilizaran técnicas de investigación documental, para obtener información de los requerimientos del usuario, las áreas involucradas en el proyecto de SPEI, dentro de VW Bank, así como las bases de datos de transacciones diarias y estadísticos que reflejen la relación costo-beneficio actual entre los procesos de captación, tesorería y colocación y el tiempo de respuesta para dichos servicios. 1.4 Universo y muestra La implementación del sistema SPEI en línea para VW Bank comprende las áreas de colocación (devoluciones), captación y tesorería, con el propósito de mejorar la calidad y confiabilidad en los servicios a terceros y participantes que se efectúan dentro de estas tres áreas. La muestra que se tomará consiste en el costo y tiempo de una transacción utilizando en enlace actual y la comparación contra una transacción efectuada utilizando el enlace SPEI. 1.5 Justificación El inicio de operaciones de VW Bank y su inclusión en el sistema financiero como Institución de Banca Múltiple, requiere herramientas tecnológicas que permitan la movilidad de recursos automatizada, en tiempo real entre sus clientes, y otras instituciones financieras. Dicha movilidad de recursos de alto valor, sólo será posible mediante la conexión al Sistema de Pagos Electrónicos 2 Interbancarios (SPEI), sistema creado y administrado por el Banco Central (BANXICO) para este fin. VW Bank, necesita actualizar sus procesos actuales de captación, colocación y tesorería para convertirse en una institución financiera competitiva, reduciendo el tiempo de respuesta presente de 1 día hacia sus clientes, al momento de realizar transferencias electrónicas. De igual modo estos cambios reflejarán un ahorro para el banco en los costos por transacción. El presente proyecto demuestra el diseño y la factibilidad de la implementación del sistema SPEI en línea, para la optimización de los procesos de captación, colocación y tesorería, así como la disminución de costos, con el fin de elevar el posicionamiento de VW Bank como entidad financiera. 3 CAPÍTULO II. MARCO TEÓRICO Y REFERENCIAL 2.1 Sistema SPEI El Banco de México propuso el desarrollo de un sistema de pagos interbancarios, capaz de liquidar un gran número de transacciones, integrando tecnologías avanzadas de comunicación y seguridad. Este sistema se denomina Sistema de Pagos Electrónicos Interbancarios (SPEI). El SPEI es un sistema diseñado para realizar pagos entre participantes del sistema y clientes de los participantes. Lleva información para indicar si un cliente ordenó el pago y, en sus caso, para identificarlo. Asimismo, puede llevar información para instruir al participante receptor para que acredite el pago a uno de sus clientes. El Sistema de Pagos Electrónicos Interbancarios (SPEI), permite, a las Instituciones participantes indicar directamente a los bancos de sus clientes el depósito de recursos en la cuenta de dichos ellos mismos. Así mismo, un cliente podría instruir a su banco transferir recursos a favor de él mismo en la cuenta que mantiene en la Institución. Para lograr lo anterior, este instituto central propuso que el sistema SPEI se integre a los sistemas de las Instituciones, con el fin de contar con conectividad Host to Host (Máquina a Máquina) eficiente, segura y económica. 2.1.1 Antecedentes. En marzo del 1995 entró en operación un sistema de pagos electrónicos de uso ampliado (SPEUA), con un límite inferior para el saldo de cada operación igual al equivalente en moneda nacional a 50 mil dólares. A partir de 1996 se redujo a 10 mil dólares mínimo para las órdenes de transferencia. Para agosto de 1997 dicho importe pasó a 5 mil dólares. En el segundo semestre del 2001, dentro de la Reforma de Pagos que llevó a cabo Banco de México, se avisó a las instituciones de crédito de la implementación del primer módulo del SPEI, otorgando a la banca múltiple y de desarrollo, la capacidad de realizar pagos en tiempo real de terceros a terceros. 4 El 14 de agosto de 2004, el Banco de México implementó un nuevo sistema de pagos denominado Sistema de Pagos Electrónicos Interbancarios (SPEI) el cual sustituyó al SPEUA, que dejó de funcionar el 19 de agosto de 2005, dicho sistema, liquidaba las instrucciones de pago con dinero de los participantes en una cuenta del sistema en el SIAC (Sistema de Atención a Cuentahabientes de Banco de México). En julio de 2005, la Junta de Gobierno de Banco de México autorizó la apertura del Sistema de Pagos de Alto Valor (SPAV) a los intermediarios financieros no bancarios, como es el caso de las Instituciones y las Operadoras de Fondos de Inversión, a través de la utilización del Sistema Electrónico de Pagos Interbancarios (SPEI). El 15 de noviembre de 2005, funcionarios de Banxico hicieron una presentación a los Intermediarios sobre la Reforma al Sistema de Pagos en el Mercado de Valores. Con esta medida las intermediarias no bancarias podrían participar en los sistemas que conforman el SPAV. El SPEI no tiene restricción en el saldo de traspaso, por lo que 75 por ciento de las operaciones registradas diariamente corresponden a montos menores a 100 mil pesos, lo que muestra que son personas físicas quienes en su mayoría utilizan el sistema vía internet. 2.1.2 ¿Cómo funciona SPEI? Para describir la forma en que funciona el SPEI, es necesario definir a las personas y bancos que intervienen en las transferencias: • El Ordenante es la persona que desea transferir dinero desde su cuenta bancaria. • El Beneficiario es la persona que recibe el dinero de la transferencia directamente en su cuenta bancaria. • El Banco Emisor es el banco comercial que le lleva la cuenta al Ordenante. • El Banco Receptor es el banco comercial que le lleva la cuenta al Beneficiario. • El Banco de México es el banco central de la nación, y actúa como “puente” entre el Banco Emisor y el Banco Receptor ya que ambos mantienen una cuenta en el banco central. Una transferencia típica a través del SPEI sigue los siguientes pasos: 1. El Ordenante instruye a su Banco Emisor que transfiera dinero, a través de su banca por Internet. La instrucción debe indicar el monto de la transferencia y los datos del Beneficiario, 5 como lo son su cuenta CLABE (18 dígitos) o su número de tarjeta de débito (16 dígitos), su nombre y el de su Banco Receptor. El Ordenante también tiene la opción de incluir alguna referencia (7 dígitos) o concepto (40 letras o dígitos) para una mejor identificación de la transferencia. 2. Al recibir la instrucción, el Banco Emisor verifica la identidad de su cliente Ordenante y que el saldo en su cuenta sea suficiente para cubrir la transferencia; aceptando sólo procesar las transferencias que cumplan estos requisitos. En tal caso, el Banco Emisor le avisa al Ordenante, a través de Internet, la hora precisa en que aceptó la transferencia, así como una clave de identificación única, llamada “número de rastreo” que serviría para futuras aclaraciones. 3. Unos minutos después, el Banco Emisor transmite, a través del SPEI, toda la información de la transferencia al Banco de México. 4. Al recibir la información, el Banco de México transfiere el dinero de la cuenta que le lleva al Banco Emisor hacia la cuenta que le lleva al Banco Receptor y retransmite, también a través del SPEI, toda la información necesaria al Banco Receptor. 5. El Banco Receptor contará con la información necesaria y los recursos para depositarlos a favor del Beneficiario. 2.1.3 Beneficios del SPEI Se considera que el SPEI, aumenta la competitividad y productividad en el Sistema Financiero Mexicano. Además de que fue uno de los proyectos prioritarios de BANXICO en el 2004, debido a que su impacto en las transacciones electrónicas obedece a las regulaciones internacionales y de tendencia mundial. Algunos de los beneficios que obtienen los participantes son los siguientes: • La reducción en los tiempos de traspaso de recursos (20 minutos duración máxima de transferencia de recursos). • No existen sobregiros. • Cuenta con información para identificar pagos. • El sistema es seguro (Las transacciones son a través de firmas electrónicas y certificados digitales validados por entidades internacionales especializadas). • Cuenta con servidores “redundantes”, es decir, la información se encuentra replicándose prácticamente de forma inmediata. • Facilita la automatización de procesos como captación y tesorería. 6 • Conexión a tiempo real con SIAC y la S.D. Indeval. • La posibilidad de procesar miles de pagos por minuto genera valor en las entidades bancarias y en los clientes de las mismas, quienes observan reducidos los tiempos de espera al momento de realizar transacciones. • En el SPEI los participantes pueden asignar prioridad alta a algunos pagos y reservar parte de su saldo para liquidar exclusivamente estos pagos. Cuando el sistema recibe una instrucción de pago, la almacena en una cola de pagos pendientes. El SPEI ejecuta con frecuencia un proceso que determina que pagos pueden liquidarse con los saldos que los participantes tienen en ese momento. • Si un pago no puede realizarse por falta de liquidez del participante que lo envía, éste permanece en la cola de pagos pendientes. 2.1.4 Requisitos para el uso de SPEI Los participantes deben enviar los pagos que soliciten sus cuenta-habientes a más tardar diez minutos después de aceptar la solicitud. Asimismo, la institución receptora de un pago deberá acreditar la cuenta de su cliente beneficiario a más tardar 10 minutos después de recibir el aviso de que se ha liquidado el pago. Cabe señalar que en operación normal el tiempo de transferencia es casi inmediato. Los pagos que queden pendientes al cierre de operaciones se cancelan y los saldos de las cuentas del SPEI se transfieren a las Cuentas Únicas en el SIAC de los Participantes. La seguridad del SPEI está basada en mensajes firmados digitalmente. Para ello, los participantes usarán los certificados digitales y las claves de las personas autorizadas, quienes deberán obtener estos certificados de acuerdo con las normas de la Infraestructura Extendida de Seguridad (IES) del Banco de México. Cuyo propósito es fortalecer la seguridad de la información que se transmite en los sistemas de pagos y a su vez acreditar la identidad del remitente, mediante el uso de firmas electrónicas y certificados digitales. El SPEI utiliza un protocolo abierto (reglas públicas de comunicación con el sistema) lo que permite a los participantes automatizar sus procesos y brindar más y mejores servicios a sus clientes. 7 2.2 Reporte de necesidades y requerimientos De acuerdo con el proceso de negocio de la Institución es necesario contar con la aplicación en línea para las operaciones de pago a terceros (captación y colocación) y las operaciones denominadas entrantes, así como las operaciones participante a participante (Tesorería Back Office). En el momento en que se autorice el pago a terceros desde T24 para el área de Colocación y en cuanto sea cargado el archivo del área de Captación proveniente de SAP CS (Collection System) estos deben visualizarse instantáneamente en el sistema SPEI (sin ningún paso previo), para su envío a terceros utilizando dicho sistema (Enlace SPEI). Ver Anexo1. En T24 debe quedar un registro de las operaciones solicitadas en SAP CS para su posterior verificación y así dar cumplimiento a los lineamientos de Control Interno. Todas las operaciones entrantes que se reciban por el sistema SPEI deben ser aplicadas en las cuentas de los clientes en T24. Para las operaciones de Tesorería Back Office (Call Money) se deberá enlazar el proceso entre T24 y el Sistema SPEI para que cada vez que se realice un movimiento en T24 pueda visualizarse su concepto correspondiente en el Sistema SPEI y posteriormente autorizar el envío (participante – participante). 2.2.1 Funcionalidad Requerida El proceso debe tener la funcionalidad de ser en línea, es decir, cada vez que se generen o carguen en T24 las transacciones correspondientes al pago a los clientes estos deberán ser tomados y enviados a Enlace SPEI tanto para los pagos a terceros como a los participantes para su autorización, si estas rebasan los límites establecidos. En cuanto a la respuesta en caso de tener disponible se deberán actualizar los saldos en las cuentas de los clientes en T24. De igual forma esta funcionalidad debe estar en línea para las operaciones entrantes que se reciban en el SPEI y que posteriormente serán aplicados en T24. Puntos clave necesarios: 8 1. Registros transaccionales. 2. Reportes de las transacciones procesadas, exportables a Excel y visibles desde el Desktop. 3. Los reportes deben permitir realizar las conciliaciones entre Collection System, T24 y SPEI. 4. El Application Server que se desarrolle deberá contemplar, el caso de que la comunicación se rompa por una caída del enlace a Alemania, no deberá perder las transacciones e informar cuales fueron enviados y cuales están pendientes de enviar, con la finalidad de que el usuario pueda informar al cliente el estado de su transacción. 5. Se deben prever los cambios y afectaciones en los estados de cuenta tanto de Captación como de Colocación. 6. El sistema deberá manejar operaciones Salientes, Entrantes y las operaciones de la tesorería (Call Money). 7. Las transacciones de Captación deberán aplicarse a la cuenta del cliente hasta saber si la operación fue exitosa. En caso de no ser exitosa deberá regresar a la cuenta del cliente el importe de la operación. 2.2.2 Pruebas Requeridas Será necesario contar: • Con el visto bueno de los consultores que desarrollen la aplicación. • Matriz de Prueba pruebas unitarias y evidencias de la ejecución. • Entrega de los resultados. Una vez realizadas y revisadas las pruebas por parte de los Consultores, los usuarios de las áreas de Tesorería Back Office, Cash Management y Sistemas IT realizarán las pruebas correspondientes, tanto internas como con los bancos externos (con operaciones ficticias). 2.2.3 Recursos Necesarios Los recursos que serán necesarios para llevar a cabo este proyecto dependen de la compañía participante y apegada al plan de trabajo que proporcione el proveedor. VW Bank deberá proporcionar 2 PC para la comunicación con los servidores en Alemania. Adicionalmente es necesario contar con la disposición de recursos del área de Tesorería Back Office, Cash Management y Sistemas IT, para poder tomar acción en caso de alguna contingencia. 9 2.2.4 Seguridad Las áreas que deben tener acceso al sistema SPEI en línea son: - Tesorería Back Office - Captación - Colocación 2.2.5 Riesgos Si la funcionalidad no cubre las reglas de funcionamiento impuestas por Banco de México se puede incurrir en diversas multas teniendo un impacto económico y de Imagen, por otro lado si no finaliza en un pronto plazo de implementación no se puede atraer a los clientes morales los cuales son necesarios para poder incrementar la captación y poder cumplir los objetivos planeados. El sistema de SPEI en línea debe aprobar todos los casos de prueba solicitados por BANXICO y VW Bank; así como cumplir con todas las reglas y leyes impuestas por la SHCP y la Comisión Nacional Bancaria y de Valores CNBV. El tiempo máximo de respuestas de transacciones recibidas debe ser de 10 min. 2.2.6 Producto Final Al finalizar este proyecto se VW Bank contará con una herramienta eficaz (Interface) que logre la conexión en línea entre el sistema T24 y BANXICO, para agilizar los procesos de las áreas de Colocación, Captación y Tesorería Back Office que se verán influenciados por el volumen de clientes que maneje la institución y así evitar un posibles riesgos en la transferencia de la información. Finalmente VW Bank contará con el proceso en línea para el envío y recepción de archivos de pago (operaciones entrantes y salientes), así como las operaciones de Tesorería Back Office. 2.3 Java Platform, Enterprise Edition o Java EE 2.3.1 Historia de Java Las computadoras personales han tenido un profundo impacto en la vida de las personas, y en la manera en que las empresas realizan y administran su negocio. Muchas personas creen que la 10 siguiente área importante en que los microprocesadores tendrán un profundo impacto es en los dispositivos electrónicos de uso doméstico. Al reconocer esto, Sun Microsystems patrocino en 1991 un proyecto interno de investigación denominado Green. El proyecto desemboco en el desarrollo de un lenguaje de programación basado en C++ al que su creador James Gosling, llamó Oak debido a un roble que tenía a la vista de su ventana en las oficinas de Sun. Posteriormente descubrió que ya existía un lenguaje de programación con el mismo nombre. Cuando un grupo de gente de Sun visitó una cafetería local, sugirieron el nombre de Java (una variedad de café) y así se quedó. Sun anunció formalmente a Java en una conferencia importante que tuvo lugar en mayo de 1995. Esté, generó un gran interés inmediato en la comunidad de negocios, debido al fenomenal interés en World Wide Web. En la actualidad Java se utiliza para desarrollar aplicaciones empresariales de gran escala, para mejorar la funcionalidad de los servidores de Web, para proporcionar aplicaciones para los dispositivos domésticos (celulares, radio-localizadores, PDA, etc.) y para muchos otros propósitos. 1 2.3.2 Plataforma Java Es una plataforma de programación (parte de la Plataforma Java) para desarrollar y ejecutar software de aplicaciones en Lenguaje de programación Java con una arquitectura de N niveles de manera distribuida, basándose ampliamente en componentes de software modulares ejecutándose sobre un servidor de aplicaciones. Java EE incluye varias especificaciones de API, tales como JDBC, RMI, e-mail, JMS, Servicios Web, XML, etc. Y define cómo coordinarlos. Java EE también configura algunas especificaciones únicas para Java EE para componentes. Estas incluyen Enterprise JavaBeans, servlets, portlets (siguiendo la especificación de Portlets Java), Java Server Pages y varias tecnologías de servicios web. 2 Lo anterior permite al desarrollador crear una Aplicación de Empresa portable entre plataformas y escalable, a la vez que sea posible de integrar con tecnologías diversas. Otros beneficios añadidos son, por ejemplo, que el servidor de aplicaciones puede manejar aspectos cómo transacciones, la seguridad, escalabilidad, concurrencia y gestión de los componentes desplegados; beneficiando en 1 2 Deitel, “Java, Cómo Programar”, Ed. Prentice Hall, p. 8 http://es.wikipedia.org/wiki/J2EE 11 que los desarrolladores pueden concentrarse más en la lógica de negocio de los componentes en lugar de en tareas de mantenimiento de bajo nivel. Este entorno o plataforma es capaz de ejecutar aplicaciones desarrolladas usando el Lenguaje de programación Java u otros lenguajes que compilen en bytecode, es decir, la plataforma no es un hardware específico o un sistema operativo, sino más bien una máquina virtual encargada de la ejecución de aplicaciones, y un conjunto de librerías estándar que ofrecen funcionalidad común. 3 La Plataforma Java se compone de un amplio abanico de tecnologías, cada una de las cuales ofrece una parte del complejo de desarrollo o del entorno de ejecución en tiempo real. Por ejemplo, los usuarios finales suelen interactuar con la máquina virtual de Java y el conjunto estándar de bibliotecas. Además, las aplicaciones Java pueden usarse de forma variada, por ejemplo pueden ser incrustadas en una página Web. Para el desarrollo de aplicaciones, se utiliza un conjunto de herramientas conocidas como JDK (Java Development Kit o herramientas de desarrollo para Java). 2.3.2.1 Java Runtime Environment Un programa destinado a la Plataforma Java necesita dos componentes en el sistema donde se va a ejecutar: una máquina virtual de Java (JVM), y un conjunto de librerías para proporcionar los servicios que pueda necesitar la aplicación. La JVM que proporciona Sun Microsystems, junto con su implementación de las librerías estándar, se conocen como Java Runtime Environment (JRE) o Entorno en tiempo de ejecución para Java. El JRE es lo mínimo que debe contener un sistema para poder ejecutar una aplicación Java sobre el mismo. 4 2.3.2.2. Bytecode El bytecode es un código intermedio más abstracto que el código máquina. Habitualmente es tratado como un archivo binario que contiene un programa ejecutable similar a un módulo objeto, el cual es un archivo binario producido por el compilador cuyo contenido es el código objeto o código máquina. El bytecode recibe su nombre porque usualmente cada código de operación tiene una longitud de un byte, si bien la longitud del código de las instrucciones varía. Cada instrucción tiene un código de operación entre 0 y 255 seguido de parámetros tales como los registros o las direcciones de memoria. 3 4 http://es.wikipedia.org/wiki/Plataforma_Java http://es.wikipedia.org/wiki/Java_Runtime_Environment 12 Como código intermedio, se trata de una forma de salida utilizada por los implementadores de lenguajes para reducir la dependencia respecto del hardware específico y facilitar la interpretación. Menos frecuentemente se utiliza el bytecode como código intermedio en un compilador. Algunos sistemas, llamados traductores dinámicos o “compiladores just-in-time” traducen el bytecode a código máquina inmediatamente antes de su ejecución para mejorar la velocidad de ejecución. Los programas en bytecode suelen ser interpretados por un intérprete de bytecode (en general llamado máquina virtual, dado que es análogo a un ordenador). Su ventaja es su portabilidad: el mismo código binario puede ser ejecutado en diferentes plataformas y arquitecturas. Es la misma ventaja que presentan los lenguajes interpretados. Sin embargo, como el bytecode es en general menos abstracto, más compacto y más orientado a la máquina que un programa pensado para su modificación por humanos, su rendimiento suele ser mejor que el de los lenguajes interpretados. A causa de esa mejora en el rendimiento, muchos lenguajes interpretados, de hecho, se compilan para convertirlos en bytecode y después son ejecutados por un intérprete de bytecode. Entre esos lenguajes se encuentran Perl, PHP y Python. El código Java se suele trasmitir como bytecode a la máquina receptora, que utiliza un compilador just-in-time para traducir el bytecode en código máquina antes de su ejecución. 5 2.3.2.3 Maquina virtual de Java El corazón de la Plataforma Java es el concepto común de un procesador “virtual” que ejecuta programas escritos en el lenguaje de programación Java. En concreto, ejecuta el código resultante de la compilación del código fuente, conocido como bytecode. Este “procesador” es la máquina virtual de Java o JVM (Java Virtual Machine), que se encarga de traducir (interpretar o compilar en el momento) el bytecode en instrucciones nativas de la plataforma destino. Esto permite que una misma aplicación Java pueda ser ejecutada en una gran variedad de sistemas con arquitecturas distintas, siempre y cuando se cuente con una implementación adecuada de la JVM. Este hecho es lo que ha dado lugar a la famosa frase: “write once, run anywhere” (escribir una vez, ejecutar en cualquier parte). La condición es que no se utilicen llamadas nativas o funciones específicas de una plataforma. Sin embargo, no puede decirse que el resultado de la compilación de Java pueda compilar el código con un máximo de eficiencia, y aprovechar los beneficios en cuanto a velocidad de código máquina nativo. Aunque los compiladores cada vez son más avanzados, no todas las librerías de Java tienen asociado un código máquina equivalente que aprovechar. Java no fue la primera plataforma basada en el concepto de una máquina virtual, aunque es la que de más amplia 5 http://es.wikipedia.org/wiki/Bytecode 13 difusión ha gozado. El empleo de máquinas virtuales se había centrado principalmente en el uso de emuladores para ayudar al desarrollo de hardware en construcción o sistemas operativos, pero la JVM fue diseñada para ser implementada completamente en software, y al mismo tiempo hacer que fuera portable a todo tipo de hardware. Figura 2.2.1 Ejemplo de interpretación del código fuente Java en distintos sistemas operativos. 2.3.3 Servidor de Aplicaciones Se le denomina así, a un servidor dentro de una red de computadoras que ejecuta ciertas aplicaciones. Usualmente se trata de un dispositivo de software que proporciona servicios de aplicación a las computadoras cliente. Un servidor de aplicaciones generalmente gestiona la mayor parte (o la totalidad) de las funciones de lógica de negocio y de acceso a los datos de la aplicación. 2.3.3.1 Servidor de Aplicaciones J2EE Como consecuencia del éxito del lenguaje de programación Java, el término servidor de aplicaciones usualmente hace referencia a un servidor de aplicaciones Java EE. WebSphere (IBM) y WebLogic (Oracle, antes BEA Systems) están entre los servidores de aplicación Java EE privativos más conocidos. EAServer (Sybase Inc.) es también conocido por ofrecer soporte a otros lenguajes diferentes a Java, como PowerBuilder. El servidor de aplicaciones JOnAS, desarrollado por el consorcio ObjectWeb, fue el primer servidor de aplicaciones libre en lograr certificación oficial de compatibilidad con J2EE. JBoss es otro servidor de aplicaciones libre y muy popular en la actualidad, así como el GlassFish de SUN. Mucha gente confunde Tomcat (The Apache Software Foundation) como un servidor de aplicaciones; sin embargo, es solamente un contenedor de servlets. 6 6 http://tomcat.apache.org/tomcat-6.0-doc/index.html 14 Java EE provee estándares que permiten a un servidor de aplicaciones servir como "contenedor" de los componentes que conforman dichas aplicaciones. Estos componentes, escritos en lenguaje Java, usualmente se conocen como Servlets, Java Server Pages (JSP) y Enterprise JavaBeans (EJB). Permiten implementar diferentes capas de la aplicación, como la interfaz de usuario, la lógica de negocio, la gestión de sesiones de usuario o el acceso a bases de datos remotas. La portabilidad de Java también ha permitido que los servidores de aplicación Java EE se encuentren disponibles sobre una gran variedad de plataformas, como Unix, Microsoft Windows y GNU/Linux. Los servidores de aplicación típicamente incluyen también middleware (o software de conectividad) que les permite intercomunicarse con variados servicios, para efectos de confiabilidad, seguridad, no-repudio, etc. Los servidores de aplicación también brindan a los desarrolladores una Interfaz para Programación de Aplicaciones (API), de tal manera que no tengan que preocuparse por el sistema operativo o por la gran cantidad de interfaces requeridas en una aplicación web moderna. Los servidores de aplicación también brindan soporte a una gran variedad de estándares, tales como HTML, XML, IIOP, JDBC, SSL, etc., que les permiten su funcionamiento en ambientes web (como Internet) y la conexión a una gran variedad de fuentes de datos, sistemas y dispositivos. Un ejemplo común del uso de servidores de aplicación (y de sus componentes) son los portales de Internet, que permiten a las empresas la gestión y divulgación de su información, y un punto único de entrada a los usuarios internos y externos. Teniendo como base un servidor de aplicación, dichos portales permiten tener acceso a información y servicios (como servicios Web) de manera segura y transparente, desde cualquier dispositivo. 7 2.3.4 API Del inglés “Application Programming Interface” o Interfaz de Programación de Aplicaciones, es el conjunto de funciones y procedimientos (o métodos, si se refiere a programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción. Una API representa una interfaz de comunicación entre componentes software. Se trata del conjunto de llamadas a ciertas bibliotecas que ofrecen acceso a ciertos servicios desde los 7 Deitel, “Java, Cómo Programar”, Ed. Prentice Hall, p. 314 15 procesos y representa un método para conseguir abstracción en la programación, generalmente entre los niveles o capas inferiores y los superiores del software. Uno de los principales propósitos de una API consiste en proporcionar un conjunto de funciones de uso general, por ejemplo, para dibujar ventanas o iconos en la pantalla, las APIs asimismo son abstractas. 2.3.5 Programación Orientada a Objetos 2.3.5.1 Objetos Un objeto es una encapsulación genérica de datos y de los procedimientos para manipularlos. Al igual que los objetos del mundo real, los objetos de software tienen un estado y un comportamiento. El estado de los objetos se determina a partir de una o más variables y el comportamiento con la implementación de métodos. Figura 2.2.2.Representación común de los objetos de software Como se observa en la figura, todos los objetos tienen una parte pública (su comportamiento) y una parte privada (su estado). En este caso, se muestra una vista transversal pero desde el mundo exterior, el objeto se observará como una esfera. 8 2.3.5.2 Clases Una clase está formada por los métodos y las variables que definen las características comunes a todos los objetos de esa clase. Precisamente la clave de la POO está en abstraer los métodos y los datos comunes a un conjunto de objetos y almacenarlos en una clase. Una clase equivale a la generalización de un tipo específico de objetos. Una instancia es la acumulación de una clase. Clase X 8 http://profesores.fi-b.unam.mx/carlos/java/java_basico3_1.html 16 Figura 2.2.3. Cada uno de los objetos tiene su propia copia de las variables definidas en la clase de la cual son instanciados y comparten la misma implementación de los métodos. 2.3.5.3 Abstracción Consiste en aislar un elemento de su contexto o del resto de los elementos que lo acompañan. La abstracción encarada desde el punto de vista de la programación orientada a objetos expresa las características esenciales de un objeto, las cuales distinguen al objeto de los demás. Además de distinguir entre los objetos provee límites conceptuales. Entonces se puede decir que el encapsulamiento separa las características esenciales de las no esenciales dentro de un objeto. Si un objeto tiene más características de las necesarias los mismos resultarán difíciles de usar, modificar, construir y comprender. Durante años, los programadores se han dedicado a construir aplicaciones muy parecidas que resolvían una y otra vez los mismos problemas. Para conseguir que los esfuerzos de los programadores puedan ser utilizados por otras personas se creó la Programación Orientada a Objetos (POO). 9 2.3.5.4 Mensajes y Métodos Los objetos interactúan enviándose mensajes unos a otros. Tras la recepción de un mensaje el objeto actuará. La acción puede ser el envío de otros mensajes, el cambio de su estado, o la ejecución de cualquier otra tarea que se requiera que haga el objeto. Un método se implementa en una clase, y determina cómo tiene que actuar el objeto cuando recibe un mensaje. 9 http://es.wikipedia.org/wiki/Abstracción_(programación_orientada_a_objetos) 17 Figura 2.2.4. Cuando un objeto “A” necesita que el objeto “B” ejecute alguno de sus métodos, el objeto “A” le manda un mensaje al objeto “B”. Al recibir el mensaje del objeto “A”, el objeto “B” ejecutará el método adecuado para el mensaje recibido. 2.3.5.5 Encapsulamiento El encapsulamiento es el proceso por el cual los datos que se deben enviar a través de una red se deben colocar en paquetes que se puedan administrar y rastrear. El encapsulado consiste pues en ocultar los detalles de implementación de un objeto, pero a la vez se provee una interfaz pública por medio de sus operaciones permitidas. 10 Típicamente, el encapsulamiento es utilizado para esconder detalles de la puesta en práctica no importantes de otros objetos. Entonces, los detalles de la puesta en práctica pueden cambiar en cualquier tiempo sin afectar otras partes del programa. El encapsulamiento de variables y métodos en un componente de software ordenado es, todavía, una simple idea poderosa que provee dos principales beneficios a los desarrolladores de software: • Modularidad. El código fuente de un objeto puede ser escrito, así como darle mantenimiento, independientemente del código fuente de otros objetos. Así mismo, un objeto puede ser transferido alrededor del sistema sin alterar su estado y conducta. • Ocultamiento de la información, es decir, un objeto tiene una "interfaz publica" que otros objetos pueden utilizar para comunicarse con él. El objeto, puede mantener información y métodos privados que pueden ser cambiados en cualquier tiempo sin afectar a los otros objetos que dependan de ello. 11 Los atributos son variables comunes en cada objeto de una clase y cada uno de ellos puede tener un valor asociado, para cada variable, diferente al que tienen para esa misma variable los demás objetos. Los métodos, por su parte, pertenecen a la clase y no se almacenan en cada objeto, 10 11 http://www.mastermagazine.info/termino/4880.php http://profesores.fi-b.unam.mx/carlos/java/java_basico3_3.html 18 puesto que sería un desperdicio almacenar el mismo procedimiento varias veces y ello va contra el principio de reutilización de código. La encapsulación crea nuevos tipos de datos mediante la combinación de características y comportamientos. La ocultación de la implementación separa la interfaz de la implementación haciendo los detalles privados. 12 2.3.5.6 Herencia Es un mecanismo que permite la definición de una clase a partir de la definición de otra ya existente. La herencia permite compartir automáticamente métodos y datos entre clases, subclases y objetos. La herencia está fuertemente ligada a la reutilización del código en la Programación Orientada a Objetos. Esto es, el código de cualquiera de las clases puede ser utilizado sin más que crear una clase derivada de ella, o bien una subclase. Hay dos tipos de herencia: Herencia Simple y Herencia Múltiple. La primera indica que se pueden definir nuevas clases solamente a partir de una clase inicial mientras que la segunda indica que se pueden definir nuevas clases a partir de dos o más clases iníciales. Java sólo permite herencia simple. 13 2.3.5.7 Polimorfismo Proporciona otra dimensión de separación de la interfaz de la implementación, separa el qué del cómo. El polimorfismo permite una organización de código y una legibilidad del mismo mejorada, además de la creación de programas ampliables que pueden "crecer", no sólo durante la creación original del proyecto sino también cuando se deseen añadir nuevas características. Esta característica es crítica porque permite que varios tipos (derivados de un mismo tipo base) sean tratados como si fueran uno sólo, y un único fragmento de código se pueda ejecutar de igual forma en todos los tipos diferentes. La llamada a un método polimórfico permite que un tipo exprese su distinción de otro tipo similar, puesto que ambos se derivan del mismo tipo base. Esta distinción se expresa a través de diferencias en comportamiento de los métodos a los que se puede invocar a través de la clase base. 14 12 Eckel, Bruce. “Piensa en Java 2da. Edición”, Ed. Prentice Hall, p. 223 Deitel, “Java, Cómo Programar”, Ed. Prentice Hall, p. 331 14 Eckel, Bruce. “Piensa en Java 2da. Edición”, Ed. Prentice Hall, p. 224 13 19 2.3.6 Elementos del Lenguaje 2.3.6.1 Definición de Clases La definición de una clase especifica cómo serán los objetos de dicha clase, esto es, de que variables y de que métodos constarán. La siguiente es la definición más simple de una clase: class nombreClase /* Declaración de la clase */ { /* Aquí se coloca la definición de variables y métodos */ } Como se puede observar, la definición de una clase consta de dos partes fundamentales: • La declaración de la clase. Indica el nombre de la clase precedido por la palabra clave class. • El cuerpo de la clase. El cuerpo de la clase sigue a la declaración de la clase y está contenido entre la pareja de llaves ({ y }). El cuerpo de la clase contiene las declaraciones de las variables de la clase, y también la declaración y la implementación de los métodos que operan sobre dichas variables. 2.3.6.2 Declaración de variables de instancia El estado de un objeto está representado por sus variables (variables de instancia). Las variables de instancia se declaran dentro del cuerpo de la clase. Típicamente, las variables de instancia se declaran antes de la declaración de los métodos, pero esto no es necesariamente requerido. 2.3.6.3 Implementación de Métodos Los métodos de una clase determinan los mensajes que un objeto puede recibir. Las partes fundamentales de un método son el valor de retorno, el nombre, los argumentos 20 (opcionales) y su cuerpo. Además, un método puede llevar otros modificadores opcionales que van al inicio de la declaración del método. La sintaxis de un método es la siguiente: <otrosModificadores> valorRetorno nombreMetodo( <lista de argumentos> ) { /* Cuerpo del método */ Sentencias; } Los signos <> indican que no son obligatorios. Los métodos en Java pueden ser creados únicamente como parte de una clase. Cuando se llama a un método de un objeto se dice comúnmente que se envía un mensaje al objeto. 2.3.6.4 Creación de objetos Una vez que se tiene definida la clase a partir de la cual se crearán los objetos se está en la posibilidad de instanciar los objetos requeridos. Suponiendo que se tuviera una clase llamada Usuario es posible crear un objeto de la siguiente manera: Usuario usr1; //usr1 es una variable del tipo Usuario usr1 = new Usuario(); • La primera línea corresponde a la declaración del objeto, es decir, se declara una variable del tipo de objeto deseado. • La segunda línea corresponde a la iniciación del objeto. • El operador new crea una instancia de una clase asignando la cantidad de memoria necesaria de acuerdo al tipo de objeto. El operador new se utiliza en conjunto con un constructor, posteriormente regresa una referencia a un nuevo objeto. 21 2.3.6.5 Constructores Un constructor es un tipo específico de método que siempre tiene el mismo nombre que la clase, y que se utiliza cuando se desean crear objetos de dicha clase, es decir, se utiliza al crear e iniciar un objeto de una clase. 2.3.6.5.1 Constructores Múltiples Cuando se declara una clase en Java, se pueden declarar uno o más constructores (constructores múltiples) opcionales que realizan la iniciación cuando se instancia un objeto de dicha clase. Para la clase Usuario del ejemplo anterior no se especificó ningún constructor, sin embargo, Java proporciona un constructor por omisión que inicia las variables del objeto a sus valores predeterminados. 2.3.6.6 Acceso a variables y métodos Una vez que se ha creado un objeto, seguramente se querrá hacer algo con él. Tal vez se requiera obtener información de éste, se quiera cambiar su estado, o se necesite que realice alguna tarea. Los objetos tienen dos formas de hacer esto: • Manipular sus variables directamente. Para acceder a las variables de un objeto se utiliza el operador punto ( . ). La sintaxis es la siguiente: nombreObjeto.nombreVariable; • Llamar a sus métodos. Para llamar a los métodos de un objeto, se utiliza también el operador punto ( . ). La sintaxis es la siguiente: nombreObjeto.nombreMetodo( <lista de argumentos opcionales> ); 2.3.6.7 Herencia de clases en Java El concepto de herencia conduce a una estructura jerárquica de clases o estructura de árbol, lo cual significa que en la Programación Orientada a Objetos todas las relaciones entre clases deben ajustarse a dicha estructura. En esta estructura jerárquica, cada clase tiene sólo una clase padre. La clase padre de cualquier clase es conocida como su superclase. La clase hija de una superclase es llamada una subclase. 22 De manera automática, una subclase hereda las variables y métodos de su superclase. Además, una subclase puede agregar nueva funcionalidad (variables y métodos) que la superclase no tenía, sin embargo, los constructores no son heredados por las subclases. Para crear una subclase, se incluye la palabra clave “extends” en la declaración de la clase: class nombreSubclase extends nombreSuperclase{ } En Java, la clase padre de todas las clases es la clase Object y cuando una clase no tiene una superclase explícita, su superclase es Object. 2.3.6.8 Sobrecarga de métodos y de constructores La firma de un método es la combinación del tipo de dato que regresa, su nombre y su lista de argumentos. La sobrecarga de métodos es la creación de varios métodos con el mismo nombre pero con diferentes firmas y definiciones. Java utiliza el número y tipo de argumentos para seleccionar cuál definición de método ejecutar. Java diferencia los métodos sobrecargados con base en el número y tipo de argumentos que tiene el método y no por el tipo que devuelve. También existe la sobrecarga de constructores: Cuando en una clase existen constructores múltiples, se dice que hay sobrecarga de constructores. 2.3.6.9 Sobre escritura de Métodos Una subclase hereda todos los métodos de su superclase que son accesibles a dicha subclase a menos que la subclase sobre escriba los métodos. Una subclase sobre escribe un método de su superclase cuando define un método con las mismas características (nombre, número y tipo de argumentos) que el método de la superclase. Las subclases emplean la sobre escritura de métodos la mayoría de las veces para agregar o modificar la funcionalidad del método heredado de la clase padre. 2.4 jBASE 2.4.1 Introducción jBASE fue lanzado en 1991 por una pequeña empresa en el Reino Unido, después llamada James Anthony Consultores, (JAC), que más tarde llego a ser jBASE Software Limited. Formada el 6 de 23 marzo de 1989 por Martin James Idle y Clive Anthony Ketteridge la compañía creció a nivel mundial durante la década de los 90. El 1 de diciembre de 1999, jBASE Software Limited y sus filiales fueron adquiridos por el Grupo TEMENOS AG, una empresa suiza de aplicaciones bancarias. jBASE es único en el sentido de que fue diseñado desde el primer día para permitir la aplicación de datos a residir en cualquier base de datos no sólo su propia cuenta. Además jBASE compila aplicaciones en código máquina nativo, en lugar de un código de bytes intermedios. jBASE se utiliza en miles de aplicaciones a nivel mundial por en su mayoría por Temenos GLOBUS y Temenos T24 banking. jBASE ofrece una suite de gestión de bases de datos de productos y herramientas de desarrollo. jBASE, el producto, ofrece una base de datos multidimensional o multivalor, un entorno de desarrollo incluyendo un lenguaje de desarrollo, y un componente de middleware que permite la integración con otros productos a base de normas para comunicarse con los productos jBASE. El middleware (jEDI) permite el acceso a otras bases de datos como Oracle, DB2 y SQL Server. Microsoft Windows, todas las principales plataformas Unix incluyendo Linux e IBM son compatibles. La mayoría de comandos UNIX pueden ser ejecutados desde JBASE jBASE es un sistema de desarrollo de aplicaciones y manejador de base de datos que mejora y extiende al sistema operativo UNIX. Una base de datos que utiliza el concepto de multivalores y además usa el compilador ‘C’ para compilar. jBASE le ofrece todas las características y funcionalidades necesarias para migrar al próximo nivel de integración y obtener la satisfacción del cliente. Con la migración de primera clase de apoyo y evaluación de las licencias libres, su camino está claro para avanzar y dar nueva vida a su negocio. 2.4.2 Estructura de directorios jBASE Una vez instalada la BD jBASE genera una estructura de directorios como a continuación se presenta: 24 Bin Contiene todos los ejecutables que comprenden el sistema jBASE, incluyendo compiladores. Config Contiene varios archivos de configuración relacionados con los archivos principales del sistema jBASE, el archivo de configuración para la creación de librerías y otros archivos de configuración. lib Contiene todas las librerías de jBASE que son requeridas para su correcto funcionamiento, estas librerías son equivalentes a los archivos .DLL de Windows. tmp Este es un directorio temporal de propósito general para su uso en tiempo de ejecución. Jspooler Contiene los archivos de JBASE requeridos para habilitar las facilidades de impresión. 2.4.2.1 Demonios JBASE El trabajo de jBASE es controlado por tres principales demonios o procesos internos: jPML – jBASE Process Managment Licensing 25 Este demonio es responsable del manejo de procesos, puertos y licenciamiento de jBASE. Lee el archivo de configuración Config_jPML bajo el directorio ‘config’ para obtener los números de puerto. jRLA – jBASE Record Locking Arbiter Este demonio es responsable de resolver todos los conflictos de apropiación de registros que los procesos jBASE suelen utilizar. Si no esta activado se utiliza el mecanismo de apropiación de UNIX. A diferencia de UNIX el jRLA ejecuta bloqueos de registros y no de archivos. jBTP – jBASE Background Task Processor Controla los procesos que se están ejecutando en jBASE. Este demonio puede ser usado para asignar / desasignar, arrancar / detener y suspender / reanudar procesos en segundo plano. 2.4.3 Características de jBASE • Opción de declaración etiquetas. • Múltiples declaraciones en una línea. • Las llamadas de subrutina. • Cadena de longitud variable con la manipulación. • Exteriores pide a "C" bibliotecas. • Factores externos subrutina llamadas. • Directos e indirectos llamadas. • Cinta magnética de entrada y salida. • Cadena, número, fecha de la conversión de datos y capacidad. • Acceso a los archivos y actualizar la capacidad de cualquier archivo residente en UNIX, tales como archivos o j-C-ISAM). • Capacidad de procesamiento de registros de archivo en cualquier formato. • Sofisticado depurador jBASIC. • Capacidad para ejecutar cualquier jBASE sistema o base de datos de información de mando. • El conjunto de comandos estándar de UNIX está disponible para gestionar bibliotecas de código. • Apoyo a la creación de redes y comunicación entre procesos. 2.4.4 Beneficios • Las aplicaciones son ejecutadas en una plataforma de sistemas abiertos 26 • Las solicitudes son muy eficaces como la velocidad de ejecución de código jBASIC esté próxima a la mano de la mano "C". • Las solicitudes son portables entre cualquier binario compatible entorno UNIX. No se requieren cambios en el código fuente cuando se portan nuevas aplicaciones a las nuevas versiones de UNIX, como cualquier código específico de UNIX ya han sido aplicadas por JAC. • Las aplicaciones se benefician de la constante mejora en la optimización del compilador. • Uso de jBASIC ofrece grandes mejoras de la productividad en "C". • La estrecha compatibilidad con UNIX permite a los desarrolladores de jBASIC producir librerías de de subrutinas estándar o llamadas a funciones con cualquier programa. • El conjunto de comandos estándar de UNIX está disponible para gestionar bibliotecas de código. • El suministro de la base de datos es para aplicaciones a través de genéricos de lectura / escritura / bloqueo de las declaraciones que divorcia la aplicación de la propia base de datos. Los Bloqueos se mantienen a distancia a través de sistemas y enlaces de comunicación, lo que permite la aplicación del programador para concentrarse en la aplicación, no en la base de datos o su ubicación. • JBASIC importa y compila código básico de sistemas abiertos sistemas RDBMS con poca o ninguna modificación. • Aplicaciones de SELECCIÓN portado o realidad ejecutarse como "C" con todas las aplicaciones relacionadas con el rendimiento y la perfecta interoperabilidad de ventajas con respecto a correr en un tipo de emulación de la aplicación escrita en C. • Las inversiones en aplicaciones existentes jBASIC y el desarrollo y habilidades de programación en BASIC son totalmente conservados. • JBASIC proporciona conexión a dispositivos externos y bases de datos externas de una manera que sea transparente para las aplicaciones existentes. 2.4.5 InfoBasic Es un lenguaje de programación diseñado para trabajar eficientemente con la base de datos jBASE y su entorno. InfoBasic es un lenguaje de programación estructurado, es una variación del lenguaje de programación BASIC. Los programas que son utilizados desde T24 para modificar la Base de Datos jBASE son escritos en el lenguaje BASIC y son llamados subrutinas. 2.4.5.1 Sintaxis La sintaxis mínima de BASIC sólo necesita los comandos LET, INPUT, PRINT, IF y GOTO. Un intérprete que ejecuta programas con esta sintaxis mínima no necesita una pila. Algunas de las 27 primeras implementaciones eran así de simples. Si se le agrega una pila, se pueden agregar también ciclos FOR anidados y el comando GOSUB. Un intérprete de BASIC con estas características necesita que el código tenga números de línea. Los números de línea fueron un aspecto muy distintivo del BASIC clásico. Sin embargo, el uso de números de línea tiene la desventaja de requerir que el programador estime cuántas líneas ocupará la parte del programa que escribe. Este requerimiento se cumple generalmente incrementando los números de línea en un intervalo regular, como 10, pero esto lleva a problemas a la hora que el código después agregado exceda el espacio disponible entre las líneas originales. Para aliviar este problema de los primeros intérpretes de BASIC, los usuarios expertos pronto escribieron sus propios programas utilitarios para renumerar sus programas, después del ingreso inicial. Más tarde aparecieron intérpretes de BASIC que incluían un comando específico RENUMBER, el que permitía renumerar rápidamente (y las veces que se quisiera) todo el código nuevamente, con cualquier intervalo entre líneas indicado y a partir de un número entero dado; eliminando así el principal problema de la numeración de líneas obligatoria. En los dialectos modernos de BASIC MIUN ya no es necesario incluir números de línea (aunque son permitidos), y la mayoría (o todos) han añadido control de flujo estructurado y los constructores de declaración de datos similares a los de otros lenguajes, tales como C y Pascal: do loop while until exit on... goto gosub select ... case Variantes recientes como Visual Basic han introducido algunas características orientadas a objetos, y hasta herencia en la última versión. La administración de memoria es más fácil que con muchos otros lenguajes de programación orientados a procedimientos, esto debido al uso de un Recolector de basura (y a costas de la velocidad de ejecución). 28 2.4.5.2 Procedimientos y Control de Flujo BASIC no tiene una biblioteca externa estándar como otros lenguajes como C. En cambio, el intérprete (o compilador) contiene una biblioteca incorporada de procedimientos intrínsecos. Estos procedimientos incluyen la mayoría de las herramientas que un programador necesita para aprender a programar y escribir aplicaciones sencillas, así como funciones para realizar cálculos matemáticos, manejar cadenas, entrada desde la consola, gráficos y manipulación de archivos. Viejos dialectos de BASIC no permitían a los programadores escribir sus propios procedimientos. Los programadores en cambio debían escribir sus programas con un gran número de enunciados GOTO para hacer las derivaciones de flujo y retorno del programa. Esto podía producir un código fuente muy confuso (la mayoría de las veces era así), comúnmente conocido como Código espagueti; el cual era sumamente difícil de mantener, mucho menos por programadores ajenos al desarrollo del software. Con la inclusión posterior de enunciados GOSUB (Go-Subroutine) se ramificaba el programa a especies de subrutinas, sin parámetros o variables locales. Ellas proveen una forma de implementar una suerte de procedimientos (realmente no lo son, sencillamente es un "salto y retorno") y estructurar más el programa, evitando bastante la utilización de la dañina sentencia GOTO. La mayoría de las versiones de BASIC más modernas, como Microsoft QuickBASIC (1985-1988) y BASIC PDS (Profesional Developmen System - 1990) añadieron soporte completo para subrutinas, funciones y programación estructurada. Esta es otra área donde BASIC difiere de muchos lenguajes de programación. Sin embargo la primitiva GOSUB se ha mantenido hasta las versiones actuales, por razones compatibilidad. BASIC, como Pascal, hace una distinción entre un procedimiento que no devuelve un valor (llamado subrutina) y un procedimiento que lo hace (llamado función). Muchos otros lenguajes (como C) no hacen esa distinción y consideran todo como una función (algunas que devuelven un valor “void” [vacío]). Mientras que las funciones que devuelven un valor son una adición relativamente reciente a los dialectos de BASIC, muchos de los primeros sistemas soportaban la definición de funciones matemáticas en línea, con DEF FN (“DEFine FunctioN” [DEFinir FuncióN]). El Dartmouth BASIC original también soportaba funciones al estilo de Algol, así como subrutinas desde sus primeros tiempos. 29 2.5 Temenos T24 Core Banking Temenos T24 Core Banking, es un sistema bancario que provee una poderosa flexibilidad y funcionalidad gracias a la escalable y avanzada arquitectura que posee. Construido con una arquitectura flexible permite costos bajos de mantenimiento y usa estándares establecidos como XML, J2EE, HTTP, entre otros. 2.5.1 Tecnología T24 fue diseñado desde un principio basado en estándares ya establecidos de la industria del software, respetando dichos estándares y no dándoles un significado particular como otros productos en el mercado. T24 funciona mediante: • Open hardware. • Open database. • Open J2EE application server. • Open UI mediante de browser, HTML y XSLT. • Conectividad mediante XML y Web Services. • Lenguaje de programación C abierto. • Ambientes de desarrollo JAVA. • Mediante el uso de tecnologías y/o estándares Microsoft. Dichas características permiten al cliente seleccionar las tecnologías que más le convengan para la implementación y funcionamiento de T24. Grandes volúmenes y escalabilidad T24 puede manejar cualquier tamaño de organización financiera, desde la más pequeña hasta la más grande. Múltiples Servidores T24 alcanza y permite granes volúmenes de información mediante una eficiente y escalable arquitectura basada en múltiples Servidores. Esto significa que así como el volumen de información se incremente, mas adelante pueden ser fácilmente incorporados nuevos servidores para mejorar el performance y también mejor la disponibilidad de los recursos. 30 Sin fin de día T24 es un verdadero sistema 24 por 7. Este elimina la necesidad del tradicional proceso de cierre de día, permitiendo a usuarios y clientes el total acceso al sistema todo el tiempo las 24 hrs. del día 7 días ala semana. Desarrollos locales T24 permite el uso de programación local para incrementar la funcionalidad y flexibilidad del sistema. Los programas locales son escritos en InfoBasic o Java y pueden ser insertados en la lógica de negocio de T24. Provee una división en capas la cual permite la integración de nuevos desarrollos sin perjudicar la posibilidad de migrar a una versión superior de T24. 2.5.2 Funcionalidad T24 incorpora todas las funcionalidades de un sistema de información bancario, permitiendo la incorporación de nuevas funcionalidades locales desarrolladas por los clientes. Entre algunas de las funciones principales de T24 se encuentran las siguientes: • Manejo de clientes CRM. • Créditos. • Cuentas y Clientes. • Cobranza. • Reportes. • Rentas. • Fiduciarios. • Manejo de sucursales. • Mercado de dinero. • Administración de usuarios y seguridad. • Conectividad con sistemas satélite. 2.5.3 Opciones de Base de Datos La compañía Temenos ofrece una gran flexibilidad hablando en Bases de Datos, el sistema T24 puede funcionar eficientemente con varias bases de datos de diferentes compañías incluso con diferentes tecnologías. 31 Témenos T24 puede funcionar con las siguientes bases de datos: • IBM DB2. • jBASE. • ORACLE. • Microsoft SQL. 2.5.4 TCServer El TCServer Temenos Conector Server es una herramienta o modulo perteneciente al sistema T24 Core banking, el cual permite que el sistema T24 interactué con el mundo exterior” es decir, es una colección de aplicaciones desarrolladas en JAVA para recibir y enviar transacciones desde y hacia cualquier sistema externo. 2.5.4.1 Requisitos para instalar TCServer T24 Es necesario contar con una instalación y licencia de Temenos T24 Core banking para poder instalar y utilizar el TCServer. Así como una instalación igual o superior a Globus Desktop G13 que es el front (interfaz de usuario) de T24. Java Una Máquina Virtual de Java JRE versión 1.3.0 o superior. Plataforma El TCServer puede ser instalado y utilizado en las siguientes plataformas: Windows 32, AIX, HPUX, Solaris, Linux, OS390, AS400 2.5.4.2 Tecnología El TCServer es un conjunto de aplicaciones y herramientas desarrolladas en Java 2EE bajo la arquitectura cliente servidor, la cual permite recibir y enviar transacciones hacia otros sistemas permitiendo la persistencia y continua transacción de las operaciones. 32 La forma de comunicar T24 y los sistemas externos es por medio de sockets y protocolos de comunicación TCP/IP. Para enviar una operación a T24 vía TCServer es necesario respetar la sintaxis nativa del TCServer llamada OFS. 2.5.4.3 Arquitectura Listeners Son aplicaciones desarrolladas en java montadas dentro de la estructura de directorios del TCServer en la carpeta /tcserver/ext .Por lo regular estas aplicaciones son sockets Servers las cuales están en la espera de una trama en un determinado puerto. Todas las operaciones recibidas son enviadas al Adapter definido en la configuración del Listener. Adapters Una vez recibida la trama u operación en la sintaxis correcta (OFS) automáticamente la transacción es enviada al Adapter asociado al Listener de trabajo, el Adapter identifica hacia que instancia de 33 la base de datos o ambiente de trabajo será enviada la petición. Es posible que en un servidor existan varios ambientes de trabajo, por ejemplo: desarrollo, pruebas y productivo. En la configuración del Adapter se debe indicar el destino de la transacción, de esta forma todas las transacciones recibidas por el Adapter serán enviadas siempre al mismo destino especificado en la configuración. Formaters De manera opcional este modulo sirve para dar formato “encoding” a la trama recibida por el Listener y que posteriormente fue enviada al Adapter. El encoding por default es UTF 8, sin embargo podemos especificar en la configuración del Formater que encoding debe ser utilizado para que el interprete de T24 el OFS.GLOBUS.MANAGER decodifique la trama u operación recibida. OFS.GLOBUS.MANAGER Modulo integrado del lado de T24 y el motor de la base de datos jBASE, se encarga de recibir las peticiones que fueron ingresadas vía TCServer, verifica la sintaxis de la trama recibida y si es correcta entonces aplica la transacción en la base de datos de T24. Responde de manera inmediata, en cuanto recibe la respuesta de la BD. La respuesta es enviada al Adapter y este a su vez la envía al Listener, como ya se menciono el Listener es un socketServer por lo que le responderá a su vez al socket cliente u sistema externo que inicio la petición. Configuración La configuración del TCServer y sus componentes Listeners, Adapters y Formaters, se realiza en el archivo tcserver.xml que se encuentra en la ruta /tcserver/conf/TCServer/ 2.6 Web Services Un servicio web (en inglés, Web Service) es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de computadoras como Internet. La 34 interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y reglamentación de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I, encargado de desarrollar diversos perfiles para definir de manera más exhaustiva estos estándares. La principal razón para usar servicios Web es que se basan en HTTP sobre TCP (Transmission Control Protocol) en el puerto 80. Dado que las organizaciones protegen sus redes mediante firewalls (filtran y bloquean gran parte del tráfico de Internet), cierran casi todos los puertos TCP salvo el 80, que es, precisamente, el que usan los navegadores. Los servicios Web utilizan este puerto, por la simple razón de que no resultan bloqueados. Otra razón por la que los servicios Web son muy prácticos es que pueden aportar gran independencia entre la aplicación que usa el servicio Web y el propio servicio. De esta forma, los cambios a lo largo del tiempo en uno no deben afectar al otro. Esta flexibilidad será cada vez más importante, dado que la tendencia a construir grandes aplicaciones a partir de componentes distribuidos más pequeños es cada día más utilizada. 15 2.6.1 Estándares empleados 2.6.1.1 Web Services Protocol Stack La Pila de protocolos para Servicios Web (Web Services Protocol Stack) es una colección de protocolos para redes de computadoras que son utilizados para definir, localizar, implementar y hacer que un Servicio Web interactúe con otro. Dicha pila se encuentra comprendida principalmente por cuatro áreas: • Servicio de Transporte: Responsable del transporte de mensajes entre las Aplicaciones de red y los protocolos en los cuales se incluyen protocolos tales como HTTP, SMTP, FTP, así como también el más reciente “Blocks Extensible Exchange Protocol” (BEEP). • Mensajería XML: Responsable por la codificación de mensajes en un formato común XML así que ellos puedan ser entendidos en cualquier extremo de una conexión de red. Actualmente, esta área incluye protocolos tales como XML-RPC, SOAP y REST. • Descripción del Servicio: Usado para describir la interfaz pública de un Servicio Web especifico. El formato de interfaz “Web Services Description Language” - WSDL es típicamente usado para este propósito. • Descubrimiento de servicios: Centraliza servicios en un registro común tal que los servicios Web de la red puedan publicar su localización y descripción, y hace que sea fácil descubrir 15 http://es.wikipedia.org/wiki/Servicio_Web 35 que servicios están disponibles en la red. Actualmente, la API “Universal Description Discovery and Integration” - UDDI se utiliza normalmente para el descubrimiento de servicios. 16 2.6.1.2 XML Por sus siglas en inglés de “Extensible Markup Language” (lenguaje de marcas extensible), es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). Es una simplificación y adaptación del SGML y permite definir la gramática de lenguajes específicos (de la misma manera que HTML es a su vez un lenguaje definido por SGML). Por lo tanto XML no es realmente un lenguaje en particular, sino una manera de definir lenguajes para diferentes necesidades. Algunos de estos lenguajes que usan XML para su definición son XHTML, SVG, MathML. XML no ha nacido sólo para su aplicación en Internet, sino que se propone como un estándar para el intercambio de información estructurada entre diferentes plataformas. Se puede usar en bases de datos, editores de texto, hojas de cálculo, etcétera. XML es una tecnología sencilla que tiene a su alrededor otras que la complementan y la hacen mucho más grande y con unas posibilidades mucho mayores. Tiene un papel muy importante en la actualidad ya que permite la compatibilidad entre sistemas para compartir la información de una manera segura, fiable y fácil. 2.6.1.2.1 Ventajas • Es extensible: Después de diseñado y puesto en producción, es posible extender XML con la adición de nuevas etiquetas, de modo que se pueda continuar utilizando sin complicación alguna. • El analizador es un componente estándar, no es necesario crear un analizador específico para cada versión de lenguaje XML. Esto facilita el empleo de cualquiera de los analizadores disponibles. De esta manera se evitan bugs (agujeros de seguridad) y se acelera el desarrollo de aplicaciones. • Si un tercero decide usar un documento creado en XML, es sencillo entender su estructura y procesarla. Mejora la compatibilidad entre aplicaciones. 16 http://roadmap.cbdiforum.com/reports/protocols/ 36 17 2.6.1.3 SOAP Por sus siglas de “Simple Object Access Protocol” es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. Este protocolo deriva de un protocolo creado por David Winer en 1998, llamado XML-RPC. SOAP fue creado por Microsoft, IBM y otros y está actualmente bajo el auspicio de la W3C. Es uno de los protocolos utilizados en los servicios Web. 18 2.6.1.4 WSDL WSDL son las siglas de “Web Services Description Language”, un formato XML que se utiliza para describir servicios Web. La versión 1.0 fue la primera recomendación por parte del W3C y la versión 1.1 no alcanzó nunca tal estatus. La versión 2.0 se convirtió en la recomendación actual por parte de dicha entidad. WSDL describe la interfaz pública a los servicios Web. Está basado en XML y describe la forma de comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados en su catálogo. Las operaciones y mensajes que soporta se describen en abstracto y se ligan después al protocolo concreto de red y al formato del mensaje. Así, WSDL se usa a menudo en combinación con SOAP y XML Schema. Un programa cliente que se conecta a un servicio web puede leer el WSDL para determinar qué funciones están disponibles en el servidor. Los tipos de datos especiales se incluyen en el archivo WSDL en forma de XML Schema. El cliente puede usar SOAP para hacer la llamada a una de las funciones listadas en el 19 WSDL. 2.6.1.5 UDDI UDDI son las siglas del catálogo de negocios de Internet denominado “Universal Description, Discovery and Integration”. El registro en el catálogo se hace en XML. UDDI es una iniciativa industrial abierta (sufragada por la OASIS) enlazada en el contexto de los servicios Web. El registro de un negocio en UDDI tiene tres partes: 17 http://es.wikipedia.org/wiki/XML http://www.w3.org/TR/2007/REC-soap12-part0-20070427/ 19 http://www.w3.org/TR/wsdl 18 37 • Páginas blancas - dirección, contacto y otros identificadores conocidos. • Páginas amarillas - categorización industrial basada en taxonomías. • Páginas verdes - información técnica sobre los servicios que aportan las propias empresas. UDDI es uno de los estándares básicos de los servicios Web cuyo objetivo es ser accedido por los mensajes SOAP y dar paso a documentos WSDL, en los que se describen los requisitos del protocolo y los formatos del mensaje solicitado para interactuar con los servicios Web del catálogo de registros. 20 2.6.1.6 WS-Security WS-Security (Seguridad en Servicios Web) es un protocolo de comunicaciones que suministra un medio para aplicar seguridad a los Servicios Web. En Abril de 2004 el estándar WS-Security 1.0 fue publicado por Oasis-Open. En 2006 fue publicada la versión 1.1. Originalmente desarrollado por IBM, Microsoft, y VeriSign, el protocolo es ahora llamado oficialmente WSS y está desarrollado por un comité en Oasis-Open. Este protocolo contiene especificaciones sobre cómo debe garantizarse la integridad y seguridad en mensajería de Servicios Web. El protocolo WSS incluye detalles en el uso de SAML y Kerberos, y formatos de certificado tales como X.509. La Integridad de datos y confidencialidad pueden garantizarse sobre Servicios Web a través del uso de la Transport Layer Security (TLS), por ejemplo enviando mensajes sobre HTTPS (HTTP sobre SSL). Esto puede reducir significativamente la sobrecarga, ya que se elimina la necesidad de codificar claves y firmas de mensaje en ASCII antes de enviar. La parte negativa de usar TLS sería si los mensajes necesitaran pasar a través de un servidor proxy, ya que sería necesario ver la petición para enrutar (encaminar) el paquete. WS-Security incorpora características de seguridad en el encabezado de un mensaje SOAP, trabajando en la capa aplicación. Así asegura seguridad de extremo a extremo. 20 21 21 http://www-306.ibm.com/software/solutions/webservices/uddi/ http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html 38 2.6.2 Ventajas de los Web Services • Aportan interoperabilidad entre aplicaciones de software independientemente de sus propiedades o de las plataformas sobre las que se instalen. • Los servicios Web fomentan los estándares y protocolos basados en texto, que hacen más fácil acceder a su contenido y entender su funcionamiento. • Al apoyarse en HTTP, los servicios Web pueden aprovecharse de los sistemas de seguridad cómo firewall, sin necesidad de cambiar las reglas de filtrado. • Permiten que servicios y software de diferentes compañías ubicadas en diferentes lugares geográficos puedan ser combinados fácilmente para proveer servicios integrados. • Permiten la interoperabilidad entre plataformas de distintos fabricantes por medio de protocolos estándar y abiertos. Las especificaciones son gestionadas por una organización abierta, la W3C, por tanto no hay predilección por intereses particulares de fabricantes concretos y se garantiza la plena interoperabilidad entre aplicaciones. 2.6.3 Funcionamiento En un escenario típico de Web Services, una aplicación de negocio envía una petición vía HTTP a un servicio situado en una URL. El servicio recibe la petición, la procesa y devuelve una respuesta también sobre HTTP. La idea es sencilla pero requiere: • Un protocolo de intercambio de mensajes petición/respuesta sobre HTTP. • Una forma de que clientes y proveedores puedan interactuar a través de los mensajes, es decir, un “lenguaje de especificación de interfaces”. Se ha optado por utilizar SOAP (Simple Object Access Protocol) como protocolo de intercambio de mensajes. Es un protocolo sencillo basado en XML y estandarizado por el W3C. El lenguaje de especificación de interfaces utilizado en servicios web es WSDL (Web Services Description Language). WSDL permite especificar en XML las operaciones y tipos de datos de un servicio web. Así, aunque el cliente y el servidor estén escritos en lenguajes distintos (por tanto, con sintaxis y tipos de datos diferentes) pueden interactuar al utilizar un lenguaje neutral para comunicarse. Una petición de un servicio web constaría de los siguientes pasos: 1. En el cliente elabora una petición de una operación con ciertos parámetros. 2. La petición se transforma a formato XML utilizando WSDL. 3. La petición transformada se envía vía HTTP utilizando SOAP. 4. El servidor de servicios web recibe la petición. 39 5. El servidor determina que operación debe realizarse y transforma los parámetros de formato XML a su representación correspondiente en el lenguaje utilizado para implementar el servidor. 6. El servidor invoca la operación con los parámetros enviados, elabora una respuesta y se la envía al cliente de la misma forma. También se dispone del UDDI en el que se publicitan los servicios web, en este, se ofrece un servicio gratuito para registrar y buscar servicios web. Cada servicio web se registra dando, entre otras cosas, su nombre, su punto de acceso y una descripción del servicio. 22 Figura 2.5.1 Funcionamiento de los Web Services. 2.5.4 Implementación Para implementar servicios web existen varias APIs (comerciales y gratuitas) para los lenguajes más usuales. Las APIs no son estándares pero esto no afecta a la interoperabilidad ya que la interoperabilidad es posible porque los protocoles (SOAP, WSDL, UDDI) están estandarizados. Se pueden distinguir dos tipos de APIs: • APIs de programación basadas en mensajes: tanto el receptor como el emisor disponen de un proveedor de mensajería. Permiten mensajes síncronos y asíncronos, enviar a más de un receptor y calidad de servicio. Son APIs muy potentes pero complejas. • APIs de programación basadas en RPC: en el caso de un lenguaje orientado a objetos, este tipo de APIs permiten definir interfaces (en WSDL) cuyos métodos se pueden invocar remotamente. No es tan potente como las APIs basadas en mensajes pero es mucho más sencilla de usar. 22 http://www.elrincondelprogramador.com/default.asp?pag=articulos/leer.asp&id=32 40 Dentro de la tecnología Microsoft, los servicios web forman parte de .NET y en cuanto a Java, existen muchas APIs de distintos fabricantes Iona, Inprise, Oracle, IBM, Sun, etc. Sun está estandarizando el API Java para servicios web. Consta de varias APIs que forman parte de J2EE: • JAXM: Java API for XML Messaging. • JAX-RPC: Java API for XML-based RPC. • JAXR: Java API for XML Registries. 41 CAPÍTULO III. ANÁLISIS DE LOS PROCESOS INTERNOS DE VWBANK PARA LA IMPLEMENTACIÓN DEL SISTEMA SPEI (DIAGNÓSTICO) 3.1 Área de Captación 3.1.1 Definición Con este término se indica la absorción de recursos del público por parte de los bancos u otras 23 instituciones financieras, mediante el pago de un interés o la oferta de ciertos servicios . Operaciones pasivas Conformadas por aquellas operaciones por las que el banco capta, recibe o recolecta dinero de las personas. Las operaciones de captación de recursos, denominadas operaciones de carácter pasivo se materializan a través de los depósitos. Los depósitos bancarios pueden clasificarse en tres grandes categorías: • Cuentas corrientes. • Cuenta de ahorro o libreta de ahorros. • Depósito a plazo fijo. Cuenta corriente.- La cuenta corriente bancaria es un contrato en virtud del cual un banco se obliga a cumplir las órdenes de pago de otra persona (llamada "cuentacorrentista") hasta el límite de la cantidad de dinero que estuviere depositado en dicha cuenta, o del crédito que se haya estipulado entre las partes. La cuenta corriente es un instrumento básico en el negocio bancario pues permite a los bancos captar dinero del público, con lo que se obtienen fondos para préstamos y otras actividades, ofreciendo a los clientes la seguridad de la custodia de su dinero y un medio de pago ágil y ampliamente aceptado. 23 http://www.eumed.net/cursecon/dic/C.htm#captación 42 La competencia ha llevado a los bancos, en la actualidad, a ofrecer diversos servicios conexos a las cuentas corrientes: pagos de intereses sobre saldos mínimos, servicio de conformación telefónica, banca electrónica, etc. Cuenta de ahorro.- Contrato similar al de la cuenta corriente pero en el que los depositantes no pueden movilizar sus fondos mediante cheques, y sólo pueden retirar su dinero en las oficinas del banco. Las cuentas de ahorro siempre pagan interés a los depositantes. En la actualidad la diferencia entre cuentas de ahorro y cuentas corrientes tiende a hacerse cada vez menor. Depósito a plazo fijo.- Es una operación financiera por la cual una entidad financiera, a cambio del mantenimiento de ciertos recursos monetarios inmovilizados en un periodo de tiempo 24 determinado, reporta una rentabilidad financiera fija o variable, en forma de dinero o en especie . El término plazo fijo proviene del hecho de que el tiempo durante el cual la inversión permanece inmovilizada se estipula al comienzo de la misma: un año, tres meses, un mes, etc. Al llegar la fecha de vencimiento de la imposición, la persona puede retirar todo el dinero o parte del mismo. Si las condiciones pactadas lo permiten, podría también renovar la imposición por un periodo de tiempo suplementario: en este último caso, si no se toma una decisión el mismo día del vencimiento, no se pierden los intereses generados hasta el momento, pero sí se pierden días durante los cuales se podrían estar generando nuevos intereses. Siempre que se contrata un depósito hay que tener en cuenta la posible necesidad de liquidez del capital invertido ya que algunas entidades cobran una cantidad o porcentaje por la cancelación anticipada del depósito, mientras que en otros casos no existe tal comisión de cancelación anticipada. Estos depósitos, dependiendo del tipo de cuenta, pagan intereses (intereses de captación). 3.1.2. Políticas 3.1.2.1 Políticas Generales del Área de Captación. 3.1.2.1.1 Proceso para aprobación de productos de captación tradicional. A. El área de Marketing y Desarrollo de Productos, es la encargada de generar las propuestas para nuevos productos, basándose en un estudio que permita conocer las condiciones existentes 24 http://es.wikipedia.org/wiki/Dep%C3%B3sito_a_plazo_fijo 43 en el mercado, para la aprobación y revisión de nuevos productos. B. Una vez concluido el proceso anterior iniciará la promoción del producto a clientes y público en general. 3.1.2.1.2 Proceso de baja de productos de captación A. Cuando un producto o cuenta quiera ser retirado del mercado, será necesario que el área de Marketing y Desarrollo de Productos informe mediante un escrito en el que se expongan los motivos de la baja del producto; una vez aprobada la baja, el área de Planeación Financiera será encargada de darlo de baja en los sistemas correspondientes. 3.1.2.1.3. Políticas de Comunicación Interna (Captación) 3.1.2.1.3.1 Lineamientos de Formato 1. Formato: Todo comunicado oficial del área de captación, deberá de redactarse en el formato preestablecido por el área de captación. 2. Autorización: Para su distribución a través del correo oficial VW-BANK COMUNICACIÓN, los comunicados deberán llevar la firma de visto bueno y de enterado del Gerente del área de captación así como del coordinador del departamento remitente. 3. Canal oficial: El envío de los Comunicados se realizará a través de la cuenta de correo electrónico VW-Bank COMUNICACIÓN. 4. Área Responsable: El departamento de Marketing y Desarrollo de Productos es responsable de la administración de la cuenta de correo oficial, así como del envió de los comunicados, debiendo asignar un número de folio a cada comunicado así como asegurar el respaldo de los mismos. 3.1.2.1.3.2 Lineamientos generales 1. Periodicidad: El “comunicado de captación” se enviará al personal del área una vez por semana. Mientras que el “comunicado especial” se enviará con la regularidad que requieran los departamentos pertenecientes a la gerencia de captación. 2. Contenido: El “comunicado de captación” contendrá principalmente información relativa al área de captación, como: Características de productos, ofertas especiales, procesos, eventos, 44 etc., así como información referente a las instituciones de crédito. La información contenida en los “comunicados especiales” estará definida por el departamento remitente. 3. Distribución: El “comunicado de captación” está dirigido a todo el personal de área, mientras que los “comunicados especiales” estarán dirigidos a los colaboradores que el departamento remitente considere pertinente. 4. Consulta: Al ser los comunicados una forma de notificación oficial, la lectura y consulta de ellos es de carácter obligatorio, ya que VW Bank dará por enterado acerca de la información contenida en el “comunicado de captación” y en los “comunicados especiales” al personal del área. 3.1.2.2. Productos de Captación Tradicional. 3.1.2.2.1. Productos de captación para personas Físicas y Morales 3.1.2.2.1.1. “Depósito retirable con previo aviso”. Características Generales Las cuentas de “D.R.P.A.” (Deposito Retirable con Previo Aviso) para personas físicas y morales cuentan con disponibilidad diaria y ofrecen a los clientes rendimientos diarios sobre su saldo. Las cuentas de “D.R.P.A.” tienen las siguientes características generales: • La tasa de interés está ligada a una tasa de referencia, pero puede diferir en función de las necesidades del mercado. Dicha tasa se fija los días miércoles de cada semana. • La generación de intereses es diaria y el cálculo de rendimientos se realiza sobre la base de los saldos promedio diarios que la cuenta tenga en el periodo. • La generación de intereses está garantizada desde el momento en que se reciban los fondos de la apertura. • Los rendimientos generados en el periodo son abonados a la cuenta del cliente el último día de cada mes. • El tiempo de vida de la cuenta se mantiene hasta que el cliente solicite la cancelación. • En base al perfil del cliente o prospecto VW Bank se reserva el derecho de ofrecer o no, una tasa preferencial, a través de sus funcionarios facultados para ello. • En base al perfil del cliente o prospecto y a las necesidades de VW Bank, este último se reserva el derecho de recibir o no, depósitos del público para este tipo de cuentas. 45 • Este producto podrá ser segmentado con características particulares para cada mercado objetivo. 3.1.2.2.1.2 Inversión. Características Generales Las cuentas de “Inversión” para personas físicas y morales, son cuentas de inversión con disposición en la fecha de vencimiento, que ofrecen a los depositantes una tasa de rendimiento fija que varía dependiendo del plazo y monto contratado. Las cuentas de inversión fija tienen las siguientes características: • La tasa de interés está ligada a una tasa de referencia, pero puede diferir en función de las necesidades del mercado. Dicha tasa se fija los días miércoles de cada semana. • Las cuentas de inversión se encuentran ligadas a las cuentas de “D.R.P.A.”, por lo tanto es necesario contar con una para poder realizar una inversión, en caso de no contar con una y si el cliente desea abrir una cuenta de inversión, se le abrirá al cliente una cuenta de “depósito retirable con previo aviso” la cual se utilizará como cuenta eje. • Una vez abierta la cuenta los rendimientos se calcularán con una tasa de interés fija. El día que se conviene la operación se fija la tasa de interés, la cual se mantiene durante el número de días contratados. • La generación de intereses está garantizada desde el momento en que se reciban los fondos de la apertura en la cuenta eje (cuenta de “D.R.P.A.”). • El plazo de la cuenta podrá variar entre 1 y 360 días definido por VW Bank y será de acuerdo a la selección del cliente en número de días dentro del rango. • Una vez acordado el plazo, no se podrá hacer alguna modificación sobre el mismo. • En base al perfil del cliente o prospecto, VW Bank se reserva el derecho de ofrecer o no, una tasa preferencial, a través de sus funcionarios facultados para ello. Este producto podrá ser segmentado con características particulares para cada mercado objetivo. 46 3.1.2.2.1.3. Inversión Corporativa La "Inversión Corporativa" es un instrumento diseñado para personas morales que permite obtener rendimientos sobre los excedentes de tesorería de las empresas, permitiendo su inversión a plazos cortos y que ofrece una tasa de rendimiento fija que varia dependiendo del plazo y el monto Invertido. La “Inversión Empresarial” tiene las siguientes características: • La tasa de interés está ligada a una tasa de referencia, pero puede diferir en función de las necesidades del mercado. Dicha tasa se fija los días miércoles de cada semana. • Una vez abierta la cuenta los rendimientos se calcularán con una tasa de interés fija. El día que se conviene la operación se fija la tasa de interés, la cual se mantiene durante el número de días contratados. • La generación de intereses está garantizada desde el momento en que recibamos los fondos de la apertura. • Se requiere un monto mínimo de apertura. • El plazo de la cuenta podrá variar entre 3 y el 360 definido por VW Bank y será de acuerdo a la selección del cliente en número de días dentro del rango. • Las cuentas de inversión Corporativa se encuentran ligadas a las cuentas de “D.R.P.A.”, por lo tanto es necesario contar con una para poder realizar una inversión, en caso de no contar con una y si el cliente desea abrir una cuenta de inversión, se le abrirá al cliente una cuenta de “depósito retirable con previo aviso” la cual se utilizará como cuenta eje. • Para la determinación de las tasas de interés correspondientes se utiliza una tabla. • En base al perfil del cliente o prospecto, VW Bank se reserva el derecho de ofrecer o no, una tasa preferencial, a través de sus funcionarios facultados para ello. • Este producto podrá ser segmentado con características particulares para cada mercado objetivo. 47 3.1.2.3. Apertura de Cuentas 3.1.2.3.1 1. Alta de cliente El CACC (Centro de Atención a Clientes Captación) revisará que la documentación proveniente de las concesionarias para la contratación de los productos esté completa de acuerdo con una lista de verificación que acompaña a los documentos de apertura de cada cliente. 2. Una vez recibida la documentación completa, los datos del cliente son ingresados por el personal del CACC al sistema, el cual le asignará un número de cliente único dentro del banco. 3.1.2.3.2. Alta de Cuenta 3.1.2.3.2.1. 1) Clientes Nuevos / Inactivos. “Depósito retirable con previo aviso”. Después del alta del cliente, el personal del CACC genera una cuenta de “depósito retirable con previo aviso” (cuenta eje) con referencia a la cuenta bancaria externa del cliente. Después se realiza el envió físico de los documentos del cliente al área de Mesa de Trámite en donde se confirmará que la información física y la información ingresada en el sistema coincidan para otorgar la autorización de la activación de la cuenta y se cumplan con los requerimientos establecidos para su autorización. Una vez autorizada la activación de la cuenta Mesa de Trámite será la encargada de enviar la documentación física al área de Servicios Internos para su resguardo. Posteriormente se genera una propuesta de cobro de la nueva cuenta de “D.R.P.A.” de VW Bank a la cuenta bancaria externa del cliente y se envían los archivos con las operaciones (de depósito) a procesar a través del sistema. El CACC recibirá un archivo donde se especifique que la operación de depósito se ha realizado, en caso de que la operación se realice exitosamente se abonan los ingresos a la cuenta de “D.R.P.A.” del cliente. 2) Inversión • Para la apertura de una cuenta de inversión, una vez creada y fondeada la cuenta “D.R.P.A.”, se generará la cuenta de inversión en el sistema especificando las condiciones generales de la misma. 48 • Toda la documentación recibida para el proceso de apertura será resguardada por el área de Servicios Administrativos. • Para generar una cuenta de inversión será necesario abrir una cuenta de “depósito retirable con previo aviso” eje. • Para iniciar una cuenta de inversión es necesario que los fondos a invertir se encuentren en la cuenta de “D.R.P.A.” eje. • Una vez que la transferencia de fondos de la cuenta externa se ha realizado exitosamente, se activará la cuenta y se realizará la transferencia de fondos de la cuenta de “D.R.P.A.” a la cuenta de inversión. 3.1.2.3.2.2. 1) Clientes Activos (con cuenta de “D.R.P.A.” activa) “Depósito retirable con previo aviso”. En caso de que un cliente ya tenga una o varias cuentas de “D.R.P.A.” (eje) activas y desee abrir otra cuenta de “depósito retirable con previo aviso” sólo deberá comunicarse con el personal del CACC para solicitarla, siempre y cuando esta nueva cuenta se ligue a la misma cuenta externa, con los mismos beneficiarios y perfil transaccional que maneje en una de sus cuentas previamente activas. La nueva cuenta de “D.R.P.A.” debe ser autorizada por el área de Mesa de trámite. 2) Inversión de cliente con cuenta eje activa. Para iniciar una cuenta de inversión es necesario que los fondos a invertir se encuentren en la cuenta de “D.R.P.A.” eje. • Se crea la cuenta de inversión en el sistema especificando las condiciones de la misma como: monto, tasa de interés y plazo; se realiza la conexión entre la cuenta de inversión y la cuenta de “depósito retirable con previo aviso” (eje). • Las cuentas de inversión no se pueden relacionar a cuentas bancarias externas, de tal manera que al término de la inversión los fondos son transferidos a la cuenta de “D.R.P.A.”. • Una vez que el depósito se ha realizado exitosamente se activará la cuenta y se realizará la transferencia de fondos de la cuenta de “D.R.P.A.” a la cuenta de inversión. 3.1.3. Alta de Clientes A continuación se muestran los pasos a seguir para dar de alta en el sistema a los nuevos clientes de VW Bank que han solicitado una cuenta mediante su solicitud de apertura de cuenta de VW Bank. 49 Área y/o Actividades puesto 1. Centro Atención de a Promoción de ejecuta el “Contratación Entradas Captación proceso: de Productos Salidas Documentación Expediente solicitada completo completa incluyendo formato: (documentación del cliente). Clientes Captación” con el cual se “Solicitud / Contrato Captación invitará a clientes prospectos de Servicios Múltiples” identificados debidamente llenada. potencialmente para el banco a visitar alguna concesionaria para realizar la contratación de los productos bancarios llevando documentación Genera su completa. expediente documentación con completa de los clientes. CAC Captación recibe, revisa, verifica, arma expediente con documentación del cliente y firma contrato. Punto de Control: Verificar relación de expedientes enviados con el número físico de expedientes. 2. Centro Atención Registra información de datos Expediente de del cliente en el sistema CRM (documentación a para la generación del mismo cliente). Clientes con base en documentación. Captación En caso de documentación del Verificación de prevención y lavado dinero. esté Cliente completa avisará al asesor de en ventas para que informe al CRM cliente la (Interfaz documentación que faltó (paso cliente). que entregue 8). En el momento de realizar el guardado de la información paralelamente se realiza el proceso de verificación 50 del de clientes en listas la que no completo el de creado sistema – T24 de Área y/o Actividades puesto Entradas Salidas cliente (PLD). Una vez que se ha pasado por el proceso de verificación del cliente (PLD), al guardar al cliente en el sistema SAP- CRM los datos maestros del cliente se traspasan al sistema T24 para su consulta y para la creación de la(s) cuenta(s). Punto de Control: Reporte de clientes creados (alta). Reporte de resultado de verificación de clientes de prevención de lavado de dinero. 3. Centro Atención de a En caso de que el prospecto Expediente sea (documentación una Persona Realizar dictamen Moral. de acta Clientes constitutiva y de Captación anexos la solicitud a completo del cliente). Atención de documentos. poderes “Apertura de Cuenta de Cliente Nuevo”. Destruir Centro de Proceso apertura. 4. Destrucción documentos de prospecto. Resultado Documentos desaprobatorio a dictamen Clientes de del acta constitutiva y poderes Captación destruidos. Llamada informativa a promotor. Analizar el caso de Persona Resultado positivo de En de Expuesta Políticamente (PEP). proceso de Vo.Bo. a Para otorgar o no, autorización “Verificación de tratarse de una Clientes de apertura de cuenta a dicho Clientes” del área de Persona Captación prospecto. En caso de que el Prevención y Lavado Dictamen resultado de la consulta en de Dinero. acta constitutiva 5. Centro Atención listas de prevención resulte en caso de Y Moral: de y poderes. una persona de riesgo B ó C, será necesaria la firma del En Ejecutivo Vo.Bo. que apertura la caso de Y cuenta, así como la firma del tratarse de una responsable Persona Física: del CACC, 51 en Área y/o Actividades puesto Entradas Salidas caso de tener dudas solicitar Proceso Vo.Bo. “Apertura Del Oficial de Cumplimiento. En los casos de Cuenta prospectos con riesgo tipo A, Nuevo”. de Cliente no se realiza la apertura de cuenta y los documentos / En caso de no expediente se otorgar Vo.Bo.: físicamente al envían área de Envío Auditoría Interna. de documentos área al de Auditoría Interna. Punto de Control: Reporte de cuentas creadas. 6. Centro Atención de a Enviar documentos al área de Revisión de PEP, y Llamada Auditoría Interna. negativa para apertura informativa de cuenta. Promotor Clientes a Captación Punto de Control: Reporte de cuentas creadas. 7. Centro Atención Realizar Llamada a Promotor Revisión de PEP, y Llamada de informándole que la apertura negativa para apertura informativa a no pudo realizarse debido a de cuenta. Prospecto. a políticas internas de VW Bank. Clientes Captación Resultado desaprobatorio dictamen de del acta constitutiva y poderes. 8. Centro Atención Clientes Realizar Llamada a prospecto, Llamada informativa a Envío de correo de informándole que la apertura Promotor. informativo a a no pudo realizarse debido a prospecto en políticas internas de VW Bank. caso no Captación de establecer contacto telefónico. Fin del proceso, 52 Área y/o Actividades puesto Entradas Salidas en caso de establecer contacto. 9. Centro Atención de a Enviar correo electrónico a prospecto informándole que la Clientes apertura no pudo realizarse Captación debido a políticas internas de Llamada informativa a Fin del proceso. prospecto. VW Bank. 1 Centro 0. Atención de a Clientes Destruir documentación Expediente completo incompleta en caso de no (documentación recibir complemento en 72 hrs. cliente). del Centro 1. Atención de documentación incompleta Captación 1 Llamada a prospecto. de a Clientes Realizar llamada a Promotor Expediente de (documentación Ventas solicitando documentación faltante. completo del cliente). Captación Proceso “Contratación Productos Captación”. 3.1.4. Inversión A continuación se muestra el procedimiento a seguir para abrir una cuenta de Inversión a los clientes que lo han solicitado, y cuyos fondos ya se encuentran en su cuenta eje. Área y/o puesto Actividades 1 Centro de Consultar en Proceso: “Solicitud Creación de . Atención a sistema de Inversión”. Inversión. Clientes operaciones de Captación apertura de Inversión creada. Entradas Salidas cuenta de inversión pendientes por atender. 2 Centro de Creación de la Consulta en . Atención a Inversión en el sistema de Clientes sistema T24 (sin operaciones de 53 Autorización de Área y/o puesto Actividades Captación autorización). Entradas Salidas apertura de Cuenta de Inversión inversión Si no existen fondos pendientes. suficientes, proceso de: “Confirmación de Operaciones”. Punto de Control: Reporte de cuentas creadas. 3 Centro . Atención de a Revisar y autorizar inversión Inversión creada. creada en sistema. Clientes Inversión autorizada. Captación Registro de operación en sistema. 4 Centro . Atención Clientes de Registrar a Operación en Inversión Proceso de autorizada “Confirmación de Collection System Captación Punto de Control: Autorización de Inversión. 54 Operación”. 3.1.4.1 Diagrama de flujo de Inversión 3.1.5 Generación de movimientos contables (CAPTACIÓN) Los pasos a seguir para generar movimientos en las cuentas de los clientes cuando estos requieran algún tipo de ajuste se muestran en la siguiente tabla y se ejemplifican más adelante en el diagrama de flujo. 55 Descripción de la actividad Después de recibir una solicitud de aclaración de Captación, el 1 Back Office CAC determina si es necesario realizar movimientos contables en la cuenta del cliente, solicita al área de Facturación realizar los movimientos correspondientes. Área Back Office CAC / Administración de Contratos (Facturación) El área de Administración de Contratos (Facturación), recibe el 2 formato autorizado con el desglose de los conceptos a generar Administración o cancelar, se verifican las firmas de autorización del de Contratos documento; y si no cumple con los requisitos se regresa el (Facturación) formato al Back Office CAC. Facturación genera la póliza contable en T24, afectando las 3 cuentas correspondientes. Administración Una vez generadas todas las pólizas se entrega al área de de Contratos Terminaciones las solicitudes con el folio asignado por el (Facturación) sistema 4 Recibe las solicitudes, verifica y autoriza en T24 dichas pólizas. Administración Una vez autorizadas todas las solicitudes se entregan de Contratos Facturación las solicitudes. (Terminaciones) Como control de la operación y soporte de haber efectuado dicho 5 movimiento, se guardan las solicitudes de generación y/o cancelación con las firmas de autorización y a fin de mes se envían todas las solicitudes al Archivo general de VW Bank S. A. En caso de ser necesario algún movimiento adicional, 5 Facturación turna el caso al CACC a través de la carpeta AD2, para que realicen los movimientos correspondientes 56 Administración de Contratos (Facturación) / Servicios Internos Administración de Contratos (Facturación)/ CACC 3.1.5.1 Diagrama de Flujo de Generación de Movimientos Contables 3.2 Área de Colocación 3.2.1 Introducción La gerencia de Cobranza es la encargada de dar seguimiento y controlar los contratos autorizados por VW Bank., así mismo también se encarga de recuperar tanto administrativa como judicialmente los créditos adeudados por sus clientes y ofrecer a estos atención telefónica para resolver dudas y 57 atender sus requerimientos. Está formada por 3 Coordinaciones y un equipo conformado por 2 especialistas en Gestión de Calidad y un Ejecutivo responsable de Sistemas y Proyectos, con esta estructura se atienden temas relacionados con: - Facturación. - Cargos y abonos a cuentas bancarias (Cash Management). - Seguros y Siniestros. - Cobranza. - Terminación de Contratos. - Atención a Clientes. - Atención y seguimiento de quejas. - Calidad en servicios y procesos. En este apartado se describen los procedimientos que se llevan a cabo en el proceso de Colocación efectuado en las cuentas de los clientes de VW Bank. 3.2.2 Domiciliación El cobro domiciliado, es decir, el cargo directo a las cuentas de los clientes de VW Bank se describe a continuación así como las áreas responsables de cada proceso, en el diagrama de flujo 3.2.2.1, se representa gráficamente cada proceso. Descripción de la actividad Área Diariamente se generan de forma individual en T-24 las capturas manuales que los clientes les solicitan cobrar (cobros parciales y de 1 inversiones), el proceso de domiciliación debe de iniciar después de CAC (Centro de terminar el proceso de aplicación de pagos enviados por Domiciliación Atención a Clientes) del día anterior, para poder enviar a cobro el saldo actualizado exigible en el contrato. Posteriormente a las generaciones manuales se prepara en T-24 el archivo de cobranza que incluirá los siguientes conceptos: 2 • Vencimientos del día • Cartera morosa (incluye todos los conceptos que estén generados en la cuenta del cliente) Una vez que se confirma que están correctos los archivos, se coloca la información en el servidor de Tesorería. Para solicitar a tesorería que procese los archivos de cobro se debe 58 Administración de Contratos (Cash Management) de enviar un correo electrónico con copia a los responsables de la operación, este correo deberá de incluir una carta con el total de registros e importe generados en T-24. Adicionalmente se debe de descargar diariamente del sistema el reporte de cobros enviados para monitoreo y control de la operación. Recibe el correo y compara con el archivo que tiene en el servidor, en caso de no tener problemas, lo procesa para que se envíe a los bancos HSBC o Bancomer. El archivo de envío y respuesta debe tener el formato necesario para que pueda ser transferido en el sistema RVS de T-Systems. 3 Al día siguiente se reciben las respuestas bancarias, con las razones Tesorería de los cobros rechazados y los pagos por aplicar. Los archivos de respuesta bancaria deben ser registrados por tesorería lo más temprano posible en el servidor designado para ello, con el objetivo de tener saldos actualizados antes de generar la nueva cobranza Al procesar los archivos de respuesta bancaria, el ingreso del pago entra primero en la cuenta eje del cliente. T-24 genera un reporte de respuesta bancaria con las razones de rechazo y éxito para los movimientos enviados, e incluye los 4 movimientos que entraron como pagos por ventanilla los cuales se Administración aplican directamente a la cuenta eje del cliente. de Contratos Cash Management descarga el reporte de respuesta bancaria para su (Cash Management) control y gestión de cobranza. Al cierre de día un proceso automático toma el ingreso de la cuenta eje del cliente y lo aplica al contrato referenciado de acuerdo con la prelación. 59 3.2.2.1 Flujo de Domiciliación Diagrama de flujo 3.2.2.1 3.2.3 Devolución de Dinero Para llevar a cabo la devolución de saldos a favor de los clientes de VW Bank se sigue la secuencia que a continuación se describe, así como las áreas responsables de cada actividad. El diagrama de flujo 3.2.3.1, ejemplifica este proceso. Descripción de la actividad 1 Área Cuando algún área de la gerencia de Cobranza detecta un saldo a Administración favor y confirma su procedencia, hace una solicitud de devolución a de Contratos 60 Administración de Contratos (Cash Management) con las firmas de autorización vigentes para que sean procesadas. En los productos de captación del banco, la devolución de saldos (totales o parciales) debe ser solicitada directamente a los asesores CAC Captación, para que estos capturen una transferencia a la cuenta externa del cliente. Cash Management diariamente capturará las devoluciones en T-24 de las solicitudes físicas de colocación. Posteriormente a las generaciones manuales se prepara en T-24 el archivo de devoluciones que incluirá las capturas manuales por 2 solicitudes recibidas. Administración Cuando se visualiza la Consulta de Pagos Generados, se confirma de Contratos que se encuentren correctos los archivos y se coloca la información en (Cash Management) el servidor de Tesorería. Para solicitar a Tesorería que procese los archivos se debe entregar físicamente el contenido de cada archivo y anexarle la carta con el total de registros e importe, además de las firmas de autorización. Envía el archivo al banco HSBC o Bancomer, y al día siguiente recibe el archivo de respuesta que incluye tanto los pagos exitosos como los 3 no exitosos, así como la razón de rechazo. Tesorería Los archivos de respuesta bancaria deberán ser registrados por Tesorería lo mayor pronto posible para actualizar saldos. 4 En forma diaria, Cash Management descarga los reportes de respuesta bancaria para su control y resguardo histórico. 61 Administración de Contratos (Cash Management) 3.2.3.1 Flujo de Devolución de Dinero Diagrama de flujo 3.2.3.1 3.2.4 Reclasificación de Pago Para los casos en que sea necesario realizar reclasificaciones de movimientos en las cuentas de los clientes de VW Bank, se lleva a cabo el siguiente procedimiento, posteriormente se ejemplifica el mismo en el diagrama 3.2.4.1 Descripción de la actividad 1 En determinadas ocasiones la operación del ciclo de vida del contrato 62 Área Tesorería / CAC cuando existe la necesidad de hacer reclasificación de movimientos (Centro de Atención entre cuentas de los clientes o entre cuentas contables. a Clientes) a) En los siguientes eventos el banco hace un cargo a las cuentas bancarias de V.W.B., S.A. y tesorería le informa a Administración de Contratos para que haga el ajuste. - Rechazo de Cobro: Cuando el cliente no reconoce el cobro directo en su cuenta y le exige al banco que regrese el cobro, por lo anterior el banco hace un cargo para poder devolverle al cliente su dinero. - Cheque Devuelto: cuando el cliente hizo un pago por ventanilla con cheque. Sin embargo poco tiempo después el banco reporta que ese cheque no cuenta con fondos suficientes. b) Se recibe solicitud del CAC (Centro de Atención a Clientes) Error en Referencia del Pago por Ventanilla. Cuando el cliente se equivoca en el número de contrato al cual hace referencia, por lo que exige se aplique el pago al contrato correcto. En caso de que el pago se haya aplicado, Cash Management analiza 2 la cuenta de ambos contratos para identificar el adeudo real del contrato al que se le aplicó el dinero de forma incorrecta, esto es reportado para proceder a corregir el contrato. Administración de Contratos (Cash Management) Una vez corregido el contrato se deben hacer las reclasificaciones correspondientes. En los casos A se realiza una póliza contable para hacer un traspaso entre las cuentas, cargo a cuenta del cliente y abono a la cuenta de 3 egresos. Administración En el caso B se debe generar una póliza contable de acuerdo con el de Contratos requerimiento que se solicito físicamente, traspasando el pago del (Cash Management) cliente erróneo al cliente correcto y el ajuste correspondiente en caso que se haya aplicado el pago al adeudo del cliente erróneo. Finalmente cash Management mantiene un control de pólizas generadas por este proceso. 63 3.2.4.1 Flujo de Reclasificación de Pago Diagrama de flujo 3.2.4.1 3.2.5 Generación de Movimientos Contables Los pasos a seguir para generar movimientos en las cuentas de los clientes cuando estos requieran algún tipo de ajuste se muestran en la siguiente tabla y se ejemplifican más adelante en el diagrama de flujo 3.2.5.1. 1 Descripción de la actividad Área Después de recibir una solicitud de aclaración, el Back Office CAC Back Office CAC / (Centro de Atención a Clientes) determina si es necesario realizar Administración movimientos contables en la cuenta del cliente, posteriormente solicita Contratos al área de Facturación realizar los movimientos correspondientes, y en (Facturación) 64 de caso de existir una devolución al cliente, se incluye la solicitud de dicha devolución. El área de Administración de Contratos (Facturación), recibe el 2 formato autorizado con el desglose de los conceptos a generar o cancelar, se verifican las firmas de autorización del documento; y si no cumple con los requisitos se regresa el formato al Back Office CAC. Administración de Contratos (Facturación) Facturación genera la póliza contable en T24, afectando las cuentas 3 correspondientes a los conceptos mencionados en el formato. Y Administración habilita la cuenta bancaria externa para domiciliación. de Contratos Una vez generadas todas las pólizas se entrega al área de (Facturación) Terminaciones las solicitudes con el folio asignado por el sistema 4 Administración de Contratos recibe las solicitudes, verifica y autoriza Administración en T24 dichas pólizas. Una vez autorizadas todas las solicitudes se de Contratos entregan al área de Facturación. (Terminaciones) Facturación recibe las solicitudes, verifica si incluyen evoluciones y en caso de existir alguna la pasa a Cash Management para que se realice 5 el proceso de Devolución de Saldos a Favor o el proceso de Administración Reclasificación de Saldos. de Contratos Cuando no sean necesarios más movimientos el crédito seguirá la (Facturación) / vida normal que se refiere al proceso de Domiciliación. Cash Management / Como control de la operación y soporte de haber efectuado dicho Servicios movimiento, se guardan las solicitudes de generación y/o cancelación Internos con las firmas de autorización y a fin de mes se envían todas las solicitudes al Archivo general de VW Bank S. A. 65 3.2.5.1 Flujo de Generación de Movimientos Contables Diagrama de Flujo 3.2.5.1 3.2.6 Casos Post Venta Cuando es necesario realizar un ajuste en la cuenta del cliente por motivo de una negociación con la marca del automóvil, se sigue el procedimiento descrito a continuación. Posteriormente se ejemplifica en el Diagrama de flujo 3.2.6.1. Descripción de la actividad Área Durante la vida del contrato puede ocurrir que el automóvil que está siendo financiado por el V.W.B., S.A., llegue a tener reclamaciones 1 Post-venta por parte del cliente, tales como: • Problema Técnico de la Unidad • Demora por parte de la concesionaria en la entrega de la unidad 66 CAC (Centro de Atención a Clientes) que ha sufrido Siniestro. • Colisión con daños menores • Mal servicio brindado al cliente por parte de la concesionaria El cliente deberá hacer la reclamación a través del CAC (Centro de Atención a Clientes) de forma escrita o por llamada telefónica. Dicha queja será turnada al área de Administración de Contratos (Terminaciones) y debe incluir los datos del contrato para poder darle seguimiento. Se debe informar a VW México / Servicio de Atención a Clientes de la marca en cuestión acerca del caso y adicionalmente se documenta en sistema el seguimiento del caso. A través de una evaluación del problema técnico las marcas correspondientes determinan que la unidad puede ser sustituida por una nueva sin que se cancele el contrato. VW México / Servicio a Clientes informará a Administración de Contratos (Terminaciones) la decisión de las salidas que puede tener este proceso: a) Terminación Anticipada (TA): Puede deberse a la demora en la solución del caso y el cliente no quiera continuar con el 2 contrato dejando la unidad en la concesionaria, siempre y cuando la marca convenga esta solución y realice el pago correspondiente para liquidar el contrato. Este proceso de TA Administración de Contratos (Terminaciones) lo ejecuta Administración de Contratos después de confirmar el pago en la cuenta del cliente b) Buy Back. Un cambio de unidad convenido y autorizado por la marca. Para procesarse es necesario contar el análisis financiero y la autorización de la operación. Adicionalmente a esto elaborará la factura por la nueva unidad a nombre del cliente y previamente endosada la entregará a VW Bank S.A. para su resguardo. En ambos casos se solicita la factura original al archivo general. En el caso A se le envía la factura a la persona que pago el auto 3 (marca o VW México). En el caso B, una vez que tiene la factura se la envía a VW México para que sustituya por la factura nueva. 4 Administración de Contratos (Terminaciones) Una vez que se tiene la nueva factura se regresa al archivo para que Administración sea integrado al expediente. de Contratos Adicionalmente a esto se le informa a la compañía aseguradora del (Terminaciones) 67 cambio de la unidad para que realice el endoso correspondiente, se / (Seguros) realizan los cambios en el sistema T-24 de la nueva garantía y se Recursos registra en Collection System la solución otorgada al cliente. Humanos / Servicios internos / Seguridad 3.2.6.1 Flujo de Casos Post Venta Diagrama de flujo 3.2.6.1 68 3.3 Área de Tesorería 3.3.1 Introducción Debido a la confidencialidad del área de Tesorería dentro del banco VW Bank el tema se abordara desde una perspectiva general. Por sus características, la organización de tesorería debe ser orientada a procesos. Al tesorero deberían reportarle dos organizaciones staff, una para la planificación y otra para el control; y dos organizaciones de línea, una como responsable del manejo de las deudas y las inversiones (largo plazo) y otra responsable por el flujo de caja (corto plazo). La tesorería podría ser vista como un radar de aproximación que maneja en forma coordinada el largo y el corto plazo; todos los días hay una transacción que pasa, total o parcialmente del largo al corto plazo, y es así como se coordina la actividad entre las dos organizaciones de línea que le reportan al tesorero. El manejo de los bancos y el efectivo (Cash Management) requiere de tiempos, talentos, ritmos y tecnologías diferentes que el manejo de fondos (Funds Management). Además de la organización formal de tesorería, según la importancia relativa de la tesorería en el negocio, es recomendable que se constituya un comité de tesorería en el cual participe el presidente, el responsable por las ventas, el de abastecimiento o procura y el de la producción; y en forma rotativa participen los que en diferentes oportunidades tengan algo que aportar. El secretario de ese comité debe ser el tesorero. Debe ser centralizada desde el punto de vista de la gerencia y las decisiones, y altamente descentralizada desde el punto de vista operacional, delegando en los procesos transaccionales del negocio la ejecución del componente financiero. Dentro de VW Bank la tesorería realiza diversas operaciones internas y externas, en este proyecto se enfoca en las operaciones Money Market que VW Bank realiza entre entidades financieras de la misma índole. Otra de las operaciones que se verán beneficiadas con la implementación de este proyecto es el pago a proveedores considerada como un pago PT (Participante- Tercero). 69 3.3.2 Money Market Mercado de dinero en México: (Money Market in México). Es aquel mercado que incluye todas las formas de crédito e inversiones a corto plazo, tales como los descuentos de documentos comerciales, los pagarés a corto plazo, los descuentos certificados de depósitos negociables, reportes, depósitos a la vista, pagarés y aceptaciones bancarias. El mercado de dinero nace de la relación de oferentes y demandantes de fondos a corto plazo. Por un lado particulares, empresas, gobiernos e intermediarios financieros, tienen fondos temporalmente ociosos, que esperan les generen alguna utilidad y, por otro, hay particulares, empresas y gobiernos que necesitan financiamientos. Los instrumentos de mercado de dinero en el Sistema Financiero Mexicano son los siguientes:-Cuenta Maestra - (CEDES) - Mesa de Dinero – Certificados de la Tesorería de la Federación (CETES) – Bonos de Desarrollo del Gobierno Federal (BONDES) – Aceptaciones Bancarias – Pagaré con rendimiento liquidable al vencimiento - Pagarés de la Tesorería de la Federación (PAGAFES) – Bonos de la Tesorería de la Federación (TESOBONOS) – Papel Comercial Quirografario – Papel Comercial Avalado – Papel Comercial Bursátil – Papel Comercial Extrabursátil –Pagaré Empresarial Bursátil – Papel Comercial Indizado. 3.3.2.1 Money Market a la vista Un MM a la vista es una operación que se realiza con una tasa y un plazo no mayor a 3 días, aun y cuando son cantidades relativamente grandes el rendimiento a 3 días no es significativo, sin embargo lo importante de estas operaciones es que servirán para fondear al banco que recibió el dinero como una inversión. 3.3.2.2 Money Market a plazo Los MM a plazo a diferencia de los MM cedidos tienen un plazo mayor a 3 días que va de los 7 a los 20 días, lo cual significa que el banco que capta el dinero tiene un plazo mayor para manipular el dinero que entro. 3.3.2.3 Money Market Cedido Se puede decir que la definición de un MM (Money Market) cedido es una inversión que el banco realiza con otra entidad financiera, es decir una cantidad de dinero es colocada en otro banco a un cierto plazo y tasa pactada para obtener al final un rendimiento, cabe mencionar que la tasa y el plazo son pactados entre los tesoreros de ambos bancos, al final se llega a un acuerdo y se crea el MM. 70 3.3.2.4 Money Market tomado A diferencia del MM cedido el MM tomado tiene lugar cuando una entidad financiera recibe una cantidad de dinero para ser invertida en VW Bank, la tesorería tiene este dinero y puede ser usado para fondear varias operaciones y movimientos, sin embargo tiene que regresar el dinero en el plazo determinado junto con un rendimiento. 3.3.3 Pagos a Terceros Otra de las operaciones que será optimiza con la utilización del sistema SPEI es el pago a Terceros que la Tesorería realiza a proveedores o Personas Físicas y Morales en general. El dinero sale de las cuentas internas desbanco y es depositado en la cuenta de un Tercero en otro banco. Actualmente el proceso se realiza por un pago referenciado. 71 CAPÍTULO IV PROPUESTA DE ARQUITECTURA Y DISEÑO DE COMPONENTES SPEI 4.1 Propuesta de Arquitectura A continuación se presenta el modelo sugerido para la implementación del sistema SPEI en línea dentro de VW Bank, con el cual se pretende dar solución a la problemática actual descrita en el CAPÍTULO anterior de diagnostico. Figura 4.1.a Propuesta de Arquitectura. 72 4.2 Conectividad y relación entre T24 y Servidor de Enlace SPEI 4.2.1 Comunicación de Web Services En la figura 4.1.a se observan los conectores 1 < – > 2 que representan la comunicación entre el Web Service Cliente (WS Cliente) instalado en el servidor T24 y el Web Service Praxis (WS Praxis) El WS Cliente será instanciado cuando se realice una transacción SPEI desde T24, ya sea por Globus Desktop o bien en el proceso Batch, el cual se ejecuta con el Servicio T24.LEAS.CS.SAP, y a su vez carga el archivo proveniente de Servicios al Cliente de SAP (CS-SAP) con las transacciones que serán enviadas a otro banco. De esta manera los movimientos realizados en T24 pertenecientes al nuevo proceso SPEI serán enviados como órdenes de pago a la Base de Datos “Enlace”. 4.3 Conectividad y relación entre Servidor de Enlace SPEI y Application Server Geronimo. 4.3.1 Comunicación de Web Services En la figura 4.1.a se muestra el flujo de comunicación 3 < – > 4 que representa la comunicación entre el WS Cliente Praxis y el WS Proveedor montado en el servidor Geronimo. El WS Proveedor (Figura 4.1.a localizado en el Geronimo Application Server) será instanciado en 2 procesos diferentes, el primero será cuando una transacción proveniente de otro banco llegue al sistema Enlace SPEI y la segunda cuando una transacción enviada desde T24, sea liquidada o en su defecto devuelta en el Enlace SPEI. El Enlace SPEI puede mandar peticiones al WS Proveedor con un máximo de 50 órdenes de pago, este a su vez, debe ser configurado con un retraso de manera que cada n segundos verifique en su Base de Datos si existen órdenes pendientes, y de ser así, las envié. El WS Proveedor recibirá peticiones en paquetes de 50 órdenes de pago como máximo, respondiendo al WS Cliente Praxis con un acuse de recibido por cada una y al mismo tiempo encolando las órdenes para que un proceso hermano dentro de Geronimo las tome y las envíe a T24. 73 En la figura 4.1.a se muestra la comunicación entre los puntos 5 < – > 6 que representa la conectividad entre el Geronimo Application Server y el TCServer (T24). Una vez encoladas las órdenes de pago (utilizando MQ-Series) se utilizara el servidor Geronimo para tomar dichas órdenes y enviarlas a T24 utilizando los componentes TCClient y TCServer. 4.3.2 Configuración de TCServer y TCClient Para ingresar una transacción en modo “background” a T24, es decir, sin necesidad de ingresar a Globus Desktop se emplearan dos herramientas TCServer y TCClient, ambas APIs o paquetes desarrollados con el lenguaje de programación Java, por lo que en su mayoría los componentes principales de estas dos APIS serán archivos .jar. A continuación se explica y representa el flujo comunicación. 1. Se recibe la transacción SPEI en el Application Server en el WS Proveedor. 2. Se procesará el mensaje mediante WSSPEI.war y MessageDriven.jar 3. Empleando el TCClient del Application Server, se enviará la transacción al servidor T24, dónde el TCServer la recibirá y dependiendo el tipo de operación, aplicará las modificaciones correspondientes en T24. 4. Para el correcto funcionamiento del Sistema SPEI será necesaria una configuración específica del TCServer y de las dos instancias del TCClient. 74 Figura 4.3.2.a Flujo de Comunicación en TCServer y TCClient 4.3.3 TCServer El principal archivo de configuración del TCServer es el tcserver.xml. Dicho archivo contiene 3 secciones Formaters, Adapters y Listeners 75 4.3.3.1 Formaters Las funciones de esta sección no serán utilizadas en la instalación del TCServer para VW Bank, sin embargo, el objetivo de las mismas es interpretar mensajes recibidos por un Listener. 4.3.3.2 Adapters En esta sección se configuraran los Adapters, que son las vías de comunicación entre la arquitectura TCServer y el OFS.CONNECTION.MANAGER el cual, es el Engine (ó Motor Principal) de T24 para recibir peticiones OFS que posteriormente se transformaran en Registros en la Base de Datos de T24. 4.3.3.3 Listeners En esta sección se configuraran los Listeners, los cuales, son aplicaciones Java que se comunican con el mundo exterior, es decir reciben las peticiones OFS realizadas por diferentes protocolos o estándares de comunicación como son TCP/IP, XML ó sockets Cada Listener deberá estar asociado a un archivo .jar que contenga toda la lógica de recepción de peticiones. Existe una lista de Listeners genéricos, sin embargo, es posible crear los propios Listeners y gracias a la flexibilidad del lenguaje Java, será posible ingresar transacciones a T24 en distintas formas, cada vez que VW Bank así lo requiera. 4.3.4 Inter conectividad de TCServer. A continuación se representa el flujo de información en las tres secciones del TCServer, para posteriormente enviarlas al OFS.CONNECTION.MANAGER. 76 Figura 4.3.4.a Diagrama de Inter conectividad de TCServer 4.3.5 TCClient El TCClient es el componente que se conecta al TCServer y a su vez, envía las transacciones hacia T24. Para la implementación de esta arquitectura será necesaria una instancia de dicho componente en el Server Geronimo así como una instancia en el propio servidor T24. 4.4 Componentes Java Para establecer la comunicación de envío/recepción de peticiones se utilizara la tecnología Web Services empleando como lenguaje de programación Java, es por ello que resulta necesario instalar una serie de componentes en el servidor T24 y en el Application Server Geronimo, dichos componentes se describen a continuación: 77 4.4.1 Geronimo Se requieren de tres componentes necesarios en el servidor Geronimo. Dos de ellos deben encontrarse hospedados en el mismo, WSSPEI.war y MessageDrivenBean.jar 4.4.1.1 WSSPEI.war Web Service el cual recibirá las peticiones enviadas desde el Servidor Praxis mediante el Web Service Cliente. El Web Service responderá con un acuse de recibido y casi simultáneamente "encolará" las órdenes de pago para posteriormente enviarlas a T24. 4.4.1.2 MessageDrivenBean.jar Este componente tomara todas las peticiones que fueron puestas en cola de espera por el Web Service, las interpretara y las transformara en mensajes OFS que posteriormente serán enviados a T24. La comunicación hacia T24 se realizará utilizando los componentes TCClient y TCServer. 4.4.1.3 TCClient El conjunto de componentes o APIs que se encuentran instaladas en el Servidor Geronimo y que serán utilizadas por el MessageDriverBean para establecer la comunicación con T24. 4.4.2 MQ-Series Es un producto de IBM que tiene objetos en tiempo de ejecución para la Administración de Encoladores. Un “Encolador” es un objeto que mantiene mensajes en cualquier formato de texto, byte o XML. Mediante el uso del Administrador de Encoladores será posible enviar mensajes de un encolador a otro, empleando canales de comunicación, esto con el fin de encolar órdenes de pago que serán procesadas por los servidores Geronimo y T24. 78 4.4.3 Servidor T24mxP (T24) En este servidor se localizaran 3 directorios con componentes Java necesarios para el proceso SPEI: 1. Directorio: /bnk/bnk.run/Interfaces/java/spei/class/ Los archivos que integrarán el Web Service Cliente para comunicarse con el Web Service Praxis en el Servidor de Enlace son: 2. Directorio /bnk/bnk.run/Interfaces/java/spei/class2/ Con la versión actual de Temenos T24 no es posible enviar OFS mediante una subrutina adjunta a una Versión. Dicha limitante implica el manejo CALLJ para invocar a clases Java que a su vez llamen a los componentes TCClient para mandar un OFS. En este directorio se encontraran las clases que serán usadas desde Subrutinas T24 para invocar a los componentes de TCClient. 3. Directorio /T24P/bnk/bnk.run/Interfaces/tcclient/ En este directorio se localizaran todos los componentes de TCClient que serán instalados, los cuales, se configuran para ser utilizados desde subrutinas adjuntas a Versiones de T24. 4.5 Diseño de nueva arquitectura y componentes básicos. El sistema SPEI Online permitirá optimizar los procesos de captación, colocación y tesorería de VW Bank, basándose en la arquitectura J2EE y utilizando Web Services se establecerá la comunicación necesaria entre el Core Bancario T24 y el Enlace SPEI, el cual, posee un sistema de conexión directa con Banco de México, para explotar al máximo los recursos de VW Bank es necesario tomar como base la arquitectura actual y proponer mejoras en la misma. 4.5.1 Componentes T24 A continuación se presenta un resumen de todos los componentes T24 que serán creados y/o modificados para el correcto funcionamiento del SPEI Online: 79 4.5.1.1 Tabla MX.DOMICILIACION La tabla de MX.DOMICILIACION permite el registro de las operaciones que serán efectuadas durante el envío de archivos de texto para realizar los cobros o depósitos en otros bancos. Su estructura permite el registro de datos del origen y beneficiario, lo cual se ajusta al requerimiento para SPEI. Los campos agregados en la estructura son: Campo SPEI.ESTATUS Descripción Estatus SPEI Acción Describirá el ESTATUS en que se encuentra el registro para SPEI de acuerdo con la tabla VW.SPEI.DESC.ESTATUS (Ver tabla 4.XXXX) SPEI.FT SPEI.CVE.DEV Operación FT Almacenará el ID de la Transferencia de Relacionada Recursos relacionado con la transferencia SPEI Clave de Devolución Almacenará el código de rechazo para SPEI SPEI 4.5.1.2 Tabla FUNDS.TRANSFER Para la realización de la transferencia de recursos (FT) de las cuentas se utilizaran versiones (vistas) de la tabla de FUNDS.TRANSFER que cuentan con campos ya definidos para registro de RFC del beneficiario, Monto de IVA, Tipo de SPEI y Clave de Rastreo. Es posible utilizar las versiones existentes con los códigos definidos para SPEI de acuerdo con la siguiente tabla: Versión Descripción Condición FUNDS.TRANSFER,VPM.O Registro de FT Registra el FS.SPEI.ENV Envío movimiento de envío FUNDS.TRANSFER,VPM.O Registro de FT Registra el FS.SPEI.REV Reverso movimiento de Código asignado por VW BANK ACSE SPEI Enviado ACSD SPEI Devuelto reverso FUNDS.TRANSFER,VPM.O Registro de FT Registra el FS.SPEI.REC Recepción movimiento de ACSR SPEI Recibido recepción FUNDS.TRANSFER,VPM.O Registro de FT Registra el FS.SPEI.DEVOL Devolución movimiento de devolución 80 ACSD SPEI Devuelto 4.5.1.3 Tabla MM.MONEY.MARKET Para la realización de la transferencia de recursos para Tesorería se utilizaran las versiones de la tabla de MM.MONEY.MARKET la cual, ya realiza la contabilización de los movimientos de Call Money “A la Vista” y “A Plazo”. De acuerdo con la siguiente tabla, será posible utilizar las versiones existentes: Versión Descripción Condición MM.MONEY.MARKET, Registro de Call Money Registra el movimiento de CALLALAVISTA.CEDIDO A la Vista Cedido envío en Front Office y lo autoriza Back Office. MM.MONEY.MARKET, Registro de Call Money Registra el movimiento de CALLAPLAZO.CEDIDO A Plazo Cedido envío en Front Office y lo autoriza Back Office. MM.MONEY.MARKET, Registro de Call Money Registra el movimiento de CALLALAVISTA.TORNADO A la Vista Tomado recepción envío en Front Office y lo autoriza Back Office. MM.MONEY.MARKET, Registro de Call Money Registra el movimiento de CALLAPLAZO.TORNADO A Plazo Tomado recepción envío en Front Office y lo autoriza Back Office. 4.5.1.4 Tabla VW.SPEI.DESC.ESTATUS Es un catalogo para almacenar los códigos de estatus para la operación realizada mediante SPEI. A continuación los campos que se incluirán en este catalogo son: Nombre Descripción Longitud/Tipo Obligatorio @ID CODIGO ESTATUS A/4 SI DESCRIPCION DESCRIPCION DEL ESTATUS A/35 SI 4.5.1.5 Tabla MX.DOMI.SPEI.ERR Se agregara una bitácora para el registro de los movimientos que presenten algún error en el proceso de envío de los mensajes al Enlace SPEI. La estructura de la tabla será la siguiente: 81 Nombre Descripción Longitud/Tipo Obligatorio @ID CODIGO DOMICILIACION A/16 SI FECHA.HORA FECHA Y HORA DEL ERROR A/16 SI USER.ID USUARIO QUE INTENTO EL REGISTRO A/35 SI SPEI.ERROR CODIGO DE ERROR A/4 SI 4.5.1.6 Tabla VW.SPEI.PARAM Se agregara una tabla local para almacenar los parámetros que requiere SPEI para registrar las operaciones en T24. Esto incluye usuario y password (contraseña), junto con datos de las cuentas internas para VW Bank y Banxico. 4.5.1.7 Tabla VW.SPEI.DESCR.ERRORES Se agregara una tabla local para almacenar los códigos de error para las operaciones rechazadas por SPEI. La estructura de la tabla es la siguiente: Nombre Descripción Longitud/Tipo Obligatorio @ID CODIGO ERROR A/4 SI DESCRIPCION DESCRIPCION DEL ERROR A/50 SI 4.5.1.8 Versiones Se definirán versiones (vistas) para Captación, Colocación y Tesorería que puedan ser utilizadas para registrar los SPEI Salientes y recibir las confirmaciones de las operaciones desde Enlace SPEI. Tipo de SPEI Versión Descripción o Función Captación CAPTACION MX.DOMICILIACION,RET.FONDOS.SPEI SALIENTE P-T Registrar un SPEI Saliente para Captación. CAPTACION MX.DOMICILIACION,RET.FONDOS.SPEI.O Registrar un SPEI Saliente SALIENTE P-T NLINE para Captación (En línea) Colocación (Devoluciones) COLOCACION MX.DOMICILIACION,DEVOL.SPEI 82 Registrar una Devolución para SALIENTE P-T Colocación y esperar la autorización para generar el mensaje SPEI. COLOCACION MX.DOMICILIACION,DEVOL.AUT.SPEI SALIENTE P-T Al autorizar el registro realizar el envío del mensaje a Enlace-SPEI Manejo de respuesta enlace SPEI COLOCACION MX.DOMICILIACION,RESPUESTA.SPEI Y CAPTACION Actualizar el estatus del envío FT para confirmarlo o rechazarlo. COLOCACION MX.DOMICILIACION,AUDIT Datos de auditoría para Y CAPTACION registros en MX.DOMICILIACION. Tesorería TESORERIA MM.MONEY.MARKET,CALLALAVISTA.CE Al autorizar el registro SALIENTE P-P DIDO.COMP.SPEI generado por Front Office generar el envío del mensaje a Enlace SPEI. TESORERIA MM.MONEY.MARKET,CALLAPLAZO.CEDI Al autorizar el registro SALIENTE P-P DO.COMP.SPEI generado por Front Office generar el envió del mensaje a Enlace SPEI. TESORERIA MM.MONEY.MARKET,AUTORIZA.SPEI Confirmar el SPEI enviado. SALIENTE P-P SPEI Salientes T-T, P-T Y T-P SALIENTE T-T MX.DOMICILIACION,VW.SPEI.SAL.TT Registrar un SPEI saliente para Tercero-Tercero SALIENTE P-T MX.DOMICILIACION,VW.SPEI.SAL.PT Registrar un SPEI saliente para Participante-Tercero SALIENTE T-P MX.DOMICILIACION,VW.SPEI.SAL.TP Registrar un SPEI saliente para Tercero-Participante SPEI Entrantes ENTRANTES MX.DOMICILIACION,RECEPCION.SPEI Registrar SPEI Entrante con error ENTRANTES MX.DOMICILIACION,RECEPCION.SPEI.OK Registrar SPEI Entrante correcto TESORERIA MM.MONEY.MARKET,CALLALAVISTA.TO 83 Registrar un SPEI Entrante ENTRANTE P-P RNADO.COMP para Participante-Participante. TESORERIA MM.MONEY.MARKET,CALLAPLAZO.TORN Registrar un SPEI Entrante ENTRANTE P-P ADO.COMP para Participante-Participante. Versiones adicionales MX.DOMI.SPEI.ERR,REG.ERROR Versión para registro de errores en bitácora. MX.DOMI.SPEI.ERR,AUDIT Versión de auditoría para registro de errores en bitácora. VW.SPEI.DESC.ESTATUS,REG.ESTATUS Versión para registro de descripciones de estatus. VW.SPEI.DESC.ESTATUS,AUDIT Versión de auditoría para registro de descripciones de estatus VW.SPEI.PARAM,REG.PARAM Versión para registro de parámetros VW.SPEI.PARAM,AUDIT Versión de auditoría para registro de parámetros. 4.5.1.9 Rutinas Se definirán las siguientes rutinas para este desarrollo: Rutina VW.SPEI.CALLJ.IXPAN Descripción Rutina de entrada para la Funciones o características • Aplicar FT para tomar los versión de Captación en recursos de la cuenta T24 del línea o en proceso de T24. cliente. • Enviar mensaje para registrar petición en Enlace-SPEI. • Aplicar FT para deshacer movimiento si ocurre un error en el registro de la petición. VW.POP.DOMI.SPEI.PT Rutina de Validación para • Validar que exista la cuenta, que la cuenta que obtiene los sea una categoría valida y tipo datos necesarios para el de pago DIRECTO. envío a SPEI. • Extraer datos de banco y cuenta destino de la cuenta T24. VW.SPEI.CALLJ.IXPAN. Rutina de DEVOL AUTHORISATION para la versión de Colocación. • Extraer datos del cliente • Enviar mensaje para registrar petición en Enlace-SPEI. • Aplicar FT para tomar los recursos de la cuenta T24 del 84 Rutina Descripción Funciones o características cliente. VW.POP.DOMI.PAG Rutina de Validación para • el Contrato CRM que Validar que exista el contrato y obtiene la cuenta eje. obtiene los datos • necesarios para el envío a SPEI. Validar que exista la cuenta y que acepte pago DIRECTO. • Obtener datos de banco y cuenta destino del cliente. VW.SPEI.CALLJ.IXPAN. Rutina de entrada PP registro de para • Extraer datos del cliente. • Enviar mensaje para registrar mensajes Participante-Participante. petición en Enlace-SPEI. • Enviar mensaje de error para indicar falla en el registro de la petición. VW.SPEI.CALLJ.SALIEN Rutina de entrada para las TES versiones de los tipos de recursos de la cuenta T24 del SPEI: T-T, T-P y P-T. cliente. • • Aplica FT para tomar los Enviar mensaje para registrar petición en Enlace-SPEI. • Aplicar FT para deshacer movimiento si ocurre un error en el registro de la petición VW.POP.DOMI.SPEI.SA Rutina de Validación para L las versiones de los tipos • Validar la cuenta del Tercero y su categoría para T-T y T-P. de SPEI: T-T, T-P y P-T. • Extraer datos del cliente para TT y T-P • Extraer datos del banco para P-T • Validar la cuenta CLABE para TT y P-T. VPM.V.SPEI.CLABE Rutina de validación para la • captura de cuenta CLABE. Obtener la cuenta CLABE capturada y calcular el digito verificador de la misma para confirmar que sea correcta. VW.SPEI.CALLJ.RESPU Rutina de entrada ESTA recibir la SPEI de respuesta un para de mensaje 85 • Actualizar los campos de DOMI.STATUS y DEV.STATUS para marcar como liquidado o Rutina Descripción Funciones o características enviado. rechazado. VW.SPEI.CALLJ.ENTRA Rutina de entrada para las NTES versiones de Registrar en • SPEI MX.DOMICILIACION el mensaje Entrantes VW.V.DOMI.AMT entrante. Rutina de Validación para Validar el monto contra el saldo • revisar que la cuenta tenga (WORKING.BALANCE) de la saldo para aplicar. cuenta. VPM.2BR.VALNUEVO.D Rutina de ID para evitar OMI que se modifique un que registro ya existente. versión. Verificar si existe el ID y evitar • sea modificado con la 4.5.1.10 Enquiries Se definirán consultas con las siguientes características: Nombre del Enquiry Descripción o Funciones %MX.DOMICILIACION$NAU,DEVOL.AUT.SPEI Consultar mensajes autorización desde en INAU para Devolución para en para Colocación. %MX.DOMICILIACION$NAU,RECEPCION.SPEI Consultar mensajes INAU autorización de devoluciones por mensajes Entrantes con error. MX.DOMICILIACION.CONS Consultar Registros de X.DOMICILIACION VW.SPEI.PARAM.SYSTEM Consultar parámetros para SPEI 4.6 Parametrización T24 Después de instalarse todos los componentes de T24, Java y TCServer es necesario parametrizar algunos de ellos, para su correcto funcionamiento e interconexión. 4.6.1 Parametrización Tabla VW.SPEI.PARAM El registro System de la tabla VW.SPEI.PARAM deberá contener las siguientes variables necesarias para el correcto funcionamiento del Sistema SPEI. 86 Nombre Descripción Longitud/Tipo Obligatorio @ID CODIGO “SYSTEM” A/6 SI USER.T24 USUARIO PARA REALIZAR LOS FT A/50 SI PASS.T24 PASSWORD PARA USER.T24 A/50 SI ACCT.VWB CUENTA INTERNA VBW ANT/13 SI NOMBRE.VWB NOMBRE VWB PARA A/50 SI RECEPCION/ENVIO RFC.VWB RFC VBW PARA RECEPCION/ENVIO A/20 SI CVEINST.VWB CLAVE DE INSTITUCION VWB A/5 SI ACCT.BANXICO CUENTA INTERNA BANXICO ANT/13 SI NOMBRE.BANXICO NOMBRE BANXICO PARA A/50 SI A/20 SI RECEPCION/ENVIO RFC.BANXICO RFC BANXICO PARA RECEPCION/ENVIO 87 CAPÍTULO V. IMPLEMENTACIÓN Y BENEFICIOS QUE SE OBTENDRÁN COMO CONSECUENCIA 5.1 Impacto del nuevo diseño e Integración de componentes. Como consecuencia de la implementación de este Sistema se obtendrá un beneficio en cuanto a costos y tiempos dentro del banco VW Bank. Para tener una visión más clara del impacto de la implementación de este sistema en los procesos de VW Bank se describen a continuación las 3 áreas afectadas, el antes y el después a la implantación. 5.1.1 Proceso Captación sin SPEI 5 . 1 . 1 P r o c e s o 88 El proceso inicia cuando un cliente hace una petición vía telefónica para disponer de su dinero, VW Bank tiene que depositar el dinero requerido por el cliente en su cuenta externa para que de esta forma el pueda disponer del mismo en la sucursal del banco externo. En Collection System (SAP) son acumuladas todas las peticiones de los clientes. 1.- El archivo proveniente de CollectionSystem (SAP) es colocado en el servidor T24 2.-El trabajo (Job) programado dentro del Servidor T24 toma el archivo y lo procesa dentro de T24, en este instante las transacciones se encuentran dentro de la Base de Datos pero aún no se aplica contablemente el retiro de fondos. 3.-Otro Job dentro de T24 extrae todas las transacciones provenientes de CollectionSystem y crea un archivo en formato CECOBAN el cual es enviado en el día (T) a HSBC. 4.-HSBC envía la transacción al banco correspondiente, dependiendo de la cuenta externa del cliente VW Bank. 5.- En un día T+1 los cambios aplican y envían a HSBC la confirmación del depósito en las cuentas externas. 6.- HSBC consolida todas las confirmaciones exitosas y no exitosas y envía el archivo de confirmación a VW Bank en un día T+1. 7.-VW Bank Procesa dentro de sus sistemas T24 las confirmaciones y en este momento es cuando aplica las transacciones contablemente, es decir, hace el cargo (retiro) dentro de la cuenta VW Bank del cliente. 89 5.1.2 Proceso Captación con SPEI 1.-Una vez colocado en el Servidor T24 el archivo con las transacciones de los clientes es procesado en T24, en este momento se hace el cargo a la cuenta del cliente y se envía el mensaje al Enlace SPEI de VW Bank. 2.- Si el monto es menor a 1 millón de pesos mexicanos el mensaje es enviado en automático del Enlace SPEI VW a Banco de México, si es mayor se requerirá una simple autorización de la transacción en el Enlace SPEI VW para ser enviado, esta ultima autorización la hace el encargado del Enlace SPEI en este caso la tesorería. 3.- La transacción llega de Banco de México al Enlace SPEI del banco externo. 4.-El banco externo aplica el depósito en la cuenta del cliente y de esta forma se concluye la transacción. 90 5.1.3 Proceso Colocación sin SPEI El proceso comienza cuando en al termino de un crédito queda un remanente en la cuenta de cobro del cliente. Es necesario devolver ese dinero depositándolo en la cuenta externa de dicho cliente. 1.-El área de colocación realiza la transacción directamente en el Sistema T24 mediante la aplicación cliente servidor Globus Desktop, en este momento se registra la transacción pero no se realiza contablemente. 2.- Un Job extrae todas las transacciones de este tipo registradas y las guarda en un archivo en formato CECOBAN. 3.- El archivo es enviado a HSBC para que posteriormente disperse las transacciones en los bancos externos. 4.- Los bancos aplican la transacción en un día T+1, es decir hacen el depósito a la cuenta externa del cliente, después envían la confirmación a HSBC. 5.- HSBC concilia las confirmaciones, las recopila en un archivo de confirmación y lo envía a VW Bank. 91 6.- El archivo llega a VW Bank en un día T+1 y en este momento procesa todas las transacciones y las aplica contablemente, es decir, hasta este instante es cuando se hace el cargo a la cuenta del cliente. 5.1.4 Proceso Colocación con SPEI 1.- El área de colocación genera la transacción en T24 mediante el cliente Globus Desktop, en este instante la transacción es enviada al Enlace SPEI VW y es aplicado el cargo en la cuenta VW Bank del cliente. 2.- Si el monto es menor a 1 millón de pesos mexicanos el mensaje es enviado en automático del Enlace SPEI VW a Banco de México, si es mayor se requerirá una simple autorización de la transacción en el Enlace SPEI VW para ser enviado, esta ultima autorización la hace el encargado del Enlace SPEI en este caso la tesorería. 92 3.- La transacción llega de Banco de México al Enlace SPEI del banco externo. 4.-El banco externo aplica el depósito en la cuenta del cliente y de esta forma se concluye la transacción. 5.1.5 Tesorería con SPEI 1.- El tesorero de VW Bank y el de cualquier otro banco que este dado de alta en el programa de mercado de dinero se ponen de acuerdo vía telefónica para generar una operación de Call Money (en T24 MM.MONEY.MARKET). La llamada es grabada para propósitos de seguridad y durante ella son pactados datos como el monto, tasa, plazo, referencias etc. 2.- Una vez pactada la transacción, el tesorero VW Bank registra la transacción en T24 utilizando el cliente Globus Desktop. En este momento es enviada la transacción al Enlace SPEI VW y se registra en T24 pero no se aplica contablemente. 3.- El tesorero VW Bank autoriza la transacción dentro del sistema Enlace SPEI VW y en ese momento es enviada a Banco de México. 93 4.- El banco Receptor recibe la transacción en su Enlace SPEI y procede a aplicarla en su sistema. 5.-El banco receptor envía la confirmación a Banco de México el cual posteriormente la envía al Enlace SPEI VW. 6.- T24 recibe la confirmación de la operación la cual ha sido enviada desde el Enlace SPEI VW. En este momento es cuando se registra la operación contablemente en T24 y termina el proceso. 5.2 Análisis de Requerimientos para la Implementación 5.2.1 Servidor Geronimo Para la instalación del Servidor Geronimo se requiere de un equipo al menos con las siguientes 25 características para hospedar la aplicación . 1. 120 MB de espacio en Disco Duro, para almacenar los archivos de instalación, configuración inicial y archivos de log. 2. 256 MB de memoria RAM o mayor preferentemente. 3. De acuerdo con la siguiente tabla se especifican las plataformas que son soportadas para la correcta ejecución de la aplicación: a. R – Recomendada b. C – Compatible c. N – No soportada Plataformas Linux x86-32 NOVELL SUSE Linux Enterprise Server (SLES) 9 SP2 o SP3 SUSE Linux Enterprise Server (SLES) 10 y SP1 R R SUSE Linux Enterprise Desktop (SLED) 10 y SP1 C SUSE Linux OSS 10.1 o 10.2 C Ubuntu 25 Ubuntu 6.06 LTS y Ubuntu 6.10 C Ubuntu 7.04 C http://www-01.ibm.com/support/docview.wss?rs=2327&uid=swg27006536 94 Red Hat Red Hat Enterprise Linux Versión 4 Actualización 4 o 5 AS, ES, WS R Red Hat Enterprise Linux Versión 5 AS, ES, WS R Fedora 6 C Fedora 7 C Mandriva Linux 2006 C Corporate Server 4.0 C Plataforma Solaris Solaris 10 N Plataforma Windows® Windows XP Professional SP2 R Windows 2003 Server SP1 or SP2 R MAC OS MacOS X 10.4 C 4. Requerimientos de JVM (JAVA Virtual Machine) Java JRE y SDK Nivel de Soporte Sun Java 32-bit SE 5 (1.4 posterior) 5.2.2 C Requisitos Previos en T24 Antes de implementar la solución deben cubrirse los siguientes aspectos: 1. Debe ser instalado el paquete que se relaciona con las plantillas locales en T24, de acuerdo con VW Bank, dicho paquete se denomina VOLK001-BC.FJSTB.20090123.1. 2. Es necesario crear 3 registros en la tabla “LOCAL.TABLE” de T24 los cuales se describen a continuación: a. Registro 4250, el cual será creado para almacenar el ID de los bancos con los que se realicen operaciones de CALL MONEY en el área de tesorería. 95 Registro 4250 Descripción BANCO DESTINO CALLMONEY Nombre_Corto SPEI.BANCO Caracteres 3 Aplicación VPM.BANCOS b. Registro 4251, el cual mantiene el estado de una transacción de SPEI para los procesos de colocación y captación. Registro 4251 Descripción ESTATUS MENSAJE SPEI Nombre_Corto SPEI.STATUS Caracteres 4 Aplicación VW.SPEI.DESC.ESTATUS c. Registro 4252, la referencia que utilizará VW Bank para almacenar las operaciones efectuadas por SPEI. Registro 4252 Descripción REFERENCIA NÚMERICA Nombre_Corto SPEI.REF.NUM 3. El TCClient debe encontrarse instalado en la siguiente ruta: bnk.run/Interfaces/java/tcclient 5.2.3 Estructura de Directorios en T24 Para la instalación de la interfaz de órdenes de pago de T24 a enlace SPEI, es necesario crear la siguiente estructura de directorios en la ruta de instalación: Sub directorio bnk.run/Interfaces/java/spei/class bnk.run/Interfaces/java/spei/class2 bnk.run/Interfaces/java/spei/lib bnk.run/Interfaces/java/spei/log Propósito Clases de java principales para la interface de SPEI Clases de ayuda Librerías requeridas Contendrá los logs (registros) generados por la interface 96 bnk.run/Interfaces/java/spei/properties 5.3 Contendrá el archive de configuración de la interface Procedimiento de Instalación 5.3.1 Componentes de T24 Una vez creada la estructura de directorios anterior, es necesario contar con las credenciales de súper usuario “root” en el sistema. 1. Iniciar o cambiar sesión a súper usuario 2. Compilar los archivos que contendrá el paquete para la implementación: ID 1 Sub directorio bnk.run/Interfaces/java/spei/class 2 bnk.run/Interfaces/java/spei/class2 3 bnk.run/Interfaces/java/spei/properties Archivos ClientWSPraxisSpei.java ClientWSPraxisSpei.class ClientWSPraxisSpeiHelper.java ClientWSPraxisSpeiHelper.class SpeiHostEndPointService.java SpeiHostEndPointService.class SpeiHostEndPointServiceLocator.java SpeiHostEndPointServiceLocator.class ConnectivityT24.java ConnectivityT24.class ConnectivityHelper.java ConnectivityHelper.class ConnectivityT24Client.java ConnectivityT24Client.class spei.properties 1. Clases fundamentales de los Web Services de Praxis y Web Services para SPEI, incluyendo el cliente de conexión y clases auxiliares. 2. Clases fundamentales para establecer las interfaces de conexión con el servidor de T24, incluyendo cliente de conexión y clases auxiliares. 3. Archivo de configuración para los Web Services. 4. Los comandos a ejecutar como “root” serán los siguientes: o # cd bnk.run/Interfaces/java/spei/ o # javac T24P/bnk/bnk.run/Interfaces/java/spei/class2/*.java o # javac T24P/bnk/bnk.run/Interfaces/java/spei/class/*.java 3. Finalmente deberán ser establecidos los permisos adecuados para que solamente el dueño de los archivos pueda modificarlos y los usuarios del grupo permitido puedan leerlos o ejecutarlos: 97 • # chmod 750 bnk.run/Interfaces/ 5.4 Relación Costo - Beneficio en las áreas. 5.4.1 Costos Este proyecto implica únicamente el costo por el personal que llevará acabo el análisis, diseño, desarrollo y la implementación del mismo. Para la ejecución del mismo se requiere de tres personas distribuidas de la siguiente forma: un consultor encargado de todo lo relacionado con T24 (programación, subrutinas, versiones, paquetes de instalación, por ejemplo BCTRL (BUILD.CONTROL), etc.), un consultor Java J2EE encargado de la programación en la conexión del Web Service y la comunicación hacia el servidor Geronimo. Finalmente es necesario un líder de proyecto quien coordinará a las dos áreas, de igual modo verificará el rumbo correcto y dará seguimiento a todo el proyecto, poniendo especial atención en el cumplimiento de acuerdos en cuanto a tiempos de entrega y requerimientos de VW Bank. Para concluir, realizara las pruebas necesarias para llevar a cabo la puesta en marcha del Sistema SPEI. El proyecto tiene un tiempo de duración de 5 meses con un costo total de $ 365,000.00 distribuidos como se muestra en la siguiente tabla: Proceso Análisis y diseño Desarrollo Desarrollo Implementación Pruebas Meses 1 2 3 4 5 Consultor T24 Consultor J2EE $ 30,000.00 $ 50,000.00 $ 30,000.00 $ 50,000.00 $ 30,000.00 $ 90,000.00 5.4.2 $ 100,000.00 Líder de proyecto $ 35,000.00 $ 35,000.00 $ 35,000.00 $ 35,000.00 $ 35,000.00 $ 175,000.00 Total $ 365,000.00 Beneficios 5.4.2.1 Beneficios cuantificables Como se ha comentado en capítulos anteriores el procedimiento que lleva a cabo VW Bank puede ser en su mayoría mucho más eficiente y menos costoso utilizando el sistema SPEI en las áreas de captación, colocación y tesorería. 98 Actualmente VW Bank cuenta con alrededor de 19 mil clientes de los cuales se realizan inversiones (captación) y devoluciones (colocación) de dinero en cuentas de inversión en promedio de 300 diarias, de ellas 50 aproximadamente son de devoluciones. Con los procedimientos anteriores (como se ejemplifica en los diagramas de los puntos 5.1.1. y 5.1.3), estas transacciones se realizan con el enlace que tiene VW Bank por medio del banco HSBC, teniendo un costo de $3.50 por cada transacción. Con el sistema SPEI y la conexión directa a Banco de México se tendrá un costo únicamente de 50 centavos por transacción, obteniendo así un ahorro de $3.00 por cada transacción. En resumen: • Cada transacción enviada por HSBC le cuesta a VW Bank $3.50. • Cada transacción enviada por SPEI a Banco de México cuesta solo 50 centavos • Ahorro de $ 3.00 por cada transacción. En la siguiente tabla se muestra un promedio de las transacciones diarias y como se incrementará el valor del ahorro de acuerdo con el periodo, es posible observar que VW Bank puede ahorrar $324,000.00, si mantiene un nivel constante de transacciones durante un año, tomando como base 30 días por mes. 99 Grafica 5.4.2.1.a Ahorro en Pesos Grafica 5.4.2.1.b Comparación de los costos obtenidos con el sistema SPEI y sin el sistema SPEI 100 Grafica 5.4.2.1.c Gráfica Costo- Beneficio Como se observa en la gráfica costo-beneficio, se tuvo un costo significativo en los primeros 5 meses sin embargo, en lo subsecuente, el beneficio se convierte en una pendiente mucho mayor y constante. En el periodo aproximado de 1 año 2 meses se habrá recuperado el costo de la inversión para la implantación de este proyecto y posterior a ello VW Bank obtendrá únicamente ganancias. 5.4.2.2 Beneficios no cuantificables Como se menciona en un principio la implementación y el beneficio del Sistema SPEI será para tres áreas, habiendo mencionado dos de ellas, en los beneficios cuantificables y restando solamente el área de Tesorería. Actualmente el área de Tesorería no trabaja con el producto mercado de dinero de manera automática, los casos que se dan son esporádicos sin embargo la implementación del Sistema SPEI permitirá que VW Bank explote los instrumentos Call Money o mercado de dinero y realice operaciones con todos los bancos registrados dentro del sistema. 101 Con la incorporación de Call Money VW Bank tendrá la posibilidad de hacer inversiones con otros bancos y a su vez que otros bancos realicen inversiones con VW Bank de una manera más sencilla y automatizada, lo que conseguirá posicionar a VW Bank en un buen lugar dentro de las instituciones financieras más importantes de México. 102 Conclusión La problemática actual de VW Bank, se basa en la inadecuada automatización en sus procesos de captación, colocación y tesorería, debido a la forma de operar de VW Bank, sin sucursales y siendo un banco directo, emplean a la entidad financiera de HSBC como intermediario para realizar transacciones de los clientes y de esta manera poder interactuar con otros bancos. Lo anterior genera un costo de $3.50 para VW Bank por cada operación con HSBC y a su vez, conlleva un tiempo de 1 día a partir de cuándo se inicio dicha operación. El objetivo de este proyecto consistió en realizar el diseño de una nueva arquitectura para llevar a cabo la implementación del sistema SPEI, haciendo uso de la infraestructura proporcionada por Banco de México para conectar el sistema T24 de VW Bank, cuya funcionalidad es la de Core bancario, con otras entidades financieras de manera casi instantánea y poder realizar operaciones en menor costo y tiempo. Optimizando así, los procesos antes mencionados de captación, colocación y tesorería. De acuerdo con el estudio realizado en este proyecto fue posible ubicar las áreas de oportunidad, dónde puede aplicarse una mejora de manera eficaz, produciendo una disminución de costos para VW Bank y una ganancia altamente significativa con respecto al tiempo de realización en las transferencias. A razón del análisis llevado a cabo, fue factible diseñar un nuevo modelo de arquitectura basado en la integración del sistema SPEI con los procesos que se llevan a cabo en las tres áreas de análisis en VW Bank. Haciendo uso de herramientas y técnicas informáticas de vanguardia como el Application Server Geronimo y el lenguaje de programación Java se diseño una nueva arquitectura capaz de soportar la operatividad del banco. Por otra parte, procurando a su vez, adecuar o acoplar los componentes que actualmente son empleados en el Core bancario T24 de VW Bank, esto con el fin de no elevar el costo del proyecto. Si bien la implementación de una arquitectura como la propuesta en este trabajo implica una inversión en recursos, tiempo y dinero por parte de VW Bank, empleando un análisis costo beneficio se demuestran los beneficios de la automatización con la arquitectura propuesta, destacando la reducción de costos para VW Bank en transferencias bancarias, puesto que, el establecer la conexión directa con Banco de México mediante el sistema SPEI, tiene un costo de únicamente 50 centavos por operación, con ello se pretende que anualmente se obtengan ganancias alrededor de $324000, considerando una constante en las transacciones bancarias y en el número de clientes, además, la implementación de esta solución, conlleva beneficios secundarios los cuales se reflejan en un mejor y más rápido servicio para los clientes de VW Bank, 103 razón por la cual, la captación de nuevos clientes tenderá a ir en aumento. Al mismo tiempo se dará cumplimiento a la ley, la cual indica que es obligación de las entidades financieras proporcionar a sus clientes los servicios de SPEI, una herramienta segura y fácil para la transferencia de dinero entre diferentes entidades financieras. En consecuencia de la ganancia provista por la optimización de tiempos, el cumplimiento adecuado a la ley y en la proyección de las ganancias futuras, la aceptación de este proyecto permitirá situar a VW Bank como una de las entidades financieras altamente competitivas en México, además de abrir la posibilidad de expandir sus horizontes explotando los instrumentos de Mercado de dinero y realizando operaciones con todas las entidades financieras registradas en el sistema SPEI, teniendo la posibilidad de hacer inversiones con otros bancos y a su vez que otros bancos realicen inversiones con VW Bank de una manera más sencilla y automatizada. 104 Bibliografía Hernández Sampieri Roberto, Fernández Collado Carlos, Baptista Lucio Pilar. Metodología de la Investigación 4° edición, McGraw Hill, México. 2007. Ortiz Frida, García Nieto Ma. del Pilar. Metodología de la Investigación, Limusa México 2006. Schmelkes Corina. Manual para la Presentación de Anteproyectos e Informes de Investigación (Tesis). 2a. Edición. Oxford University Press. México. 2000. Pressman Roger S. Ingeniería de Software 6° edición, McGraw Hill, México. 2005. Baca Urbina Gabriel. Fundamentos de Ingeniería Económica 4° edición, McGraw Hill, México. 2007. Mannino Michael V. Administración de Base de Datos 3° edición, McGraw Hill, México.2007. Deitel, “Java, Cómo Programar”, Ed. Prentice Hall, México. 2004 Eckel, Bruce. “Piensa en Java 2da. Edición”, Ed. Prentice Hall, México. 2000 Referencias de Internet J2EE, http://es.wikipedia.org/wiki/J2EE, Consulta Marzo-2009 Plataforma Java, Java Runtime Environment, http://es.wikipedia.org/wiki/Plataforma_Java, Consulta Marzo-2009 http://es.wikipedia.org/wiki/Java_Runtime_Environment, Consulta Marzo-2009 Bytecode, http://es.wikipedia.org/wiki/Bytecode, Consulta Marzo-2009 Servidores de Aplicaciones J2EE, http://tomcat.apache.org/tomcat-6.0-doc/index.html, Consulta Marzo-2009 Java Básico, http://profesores.fi-b.unam.mx/carlos/java/java_basico3_1.html, Consulta Marzo-2009 Programación Orientada a Objetos – Abstracción http://es.wikipedia.org/wiki/Abstracción_(programación_orientada_a_objetos), Consulta Marzo-2009. Encapsulamiento, http://www.mastermagazine.info/termino/4880.php, Consulta Marzo2009 Servicio Web, http://es.wikipedia.org/wiki/Servicio_Web, Consulta Marzo-2009 Web Services Protocols, http://roadmap.cbdiforum.com/reports/protocols/, Consulta Marzo-2009 XML , http://es.wikipedia.org/wiki/XML, Consulta Marzo-2009 Soap, http://www.w3.org/TR/2007/REC-soap12-part0-20070427, Consulta Marzo-2009 WSDL, http://www.w3.org/TR/wsdl, Consulta Marzo-2009 105 Web Services- UDDI, http://www-306.ibm.com/software/solutions/webservices/uddi/, Consulta Marzo-2009 WS Security, http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html, Consulta Marzo- 2009 Funcionamiento de Web Services http://www.elrincondelprogramador.com/default.asp?pag=articulos/leer.asp&id=32, Consulta Marzo-2009 Captación, http://www.eumed.net/cursecon/dic/C.htm#captación, Consulta Julio-2009 Depósito a Plazo Fijo, http://es.wikipedia.org/wiki/Dep%C3%B3sito_a_plazo_fijo, Consulta Julio-2009 106 Glosario B Back Office.- Área de tesorería que autoriza las transacciones. C CAC.- Centro de Atención a Clientes CALLJ.- Instrucción Basic que permite llamar a un método específico de Java. Es útil cuando se utilizan terceras aplicaciones que ofrecen un API de Java. Sintaxis: CALLJ ClassName,method,param SETTING ret ON ERROR errStatment Captación.- Absorción de recursos del público por parte de los bancos u otras instituciones financieras, mediante el pago de un interés o la oferta de ciertos servicios. CECOBAN.- Formato empleado por el Centro de Cómputo Bancario de Banco de México. Collection System.- Herramienta que permite la administración de la información contenida en el sistema SAP y en T-24 y en el cual se registran las gestiones de los clientes Colocación.- Operación por medio de la cual el emisor obtiene efectivo contra la entrega de documentos que representan sus obligaciones CRM.- Modulo en ambiente SAP en el cual se da de alta la información general de los clientes y donde se generan, activan y modifican los contratos. D Domiciliación.- Forma de pago en la cual a los clientes se les realiza el cobro directamente a la cuenta bancaria externa designada por ellos. D. R. P.A. - Deposito Retirable con Previo Aviso F Front Office.- Área de tesorería encargada de realizar los tratos con otros bancos proveedores y a su vez, responsable de ingresar las transacciones. FT.- FUNDS.TRANSFER. Tabla en T24 donde se encuentran almacenadas las cuentas de los clientes incluyendo los montos en las mismas. Las operaciones efectuadas sobre la misma, registran las transacciones contablemente por cada registro que se modifique. G Globus Desktop. Cliente mediante el cual los usuarios se conectan al servidor T24, en el se presentan todas las pantallas y vistas de todas las tablas y menús, dependiendo del Rol que desempeñen. 107 I ID. Identificador asignado como referencia llave o campo clave para una tabla. Instanciar.- Crear una instancia de una clase. Reservar dinámicamente el espacio de memoria necesario para almacenar sus campos y el resto de los datos que permitirán su operación mediante una llamada al constructor de la clase. M Movimiento Reverso.- Cuando se ha procesado una transacción y se ha enviado al servidor de enlace aplicando el cargo correspondiente, sin embargo, ocurre algún imprevisto en la conclusión de la operación con SPEI, por tanto debe abonarse nuevamente la cantidad retirada de la cuenta del cliente. P Parametrización.- Es la propiedad de un módulo, o de una construcción sintáctica del lenguaje, para utilizar datos de varios tipos. Permite aplicar el mismo algoritmo a tipos de datos diferentes, a su vez, permite separar los algoritmos de los tipos de datos, aumentando de esta manera la modularidad de los programas y minimizando la duplicación de código. Proceso Batch.- También llamado proceso por lotes, es una técnica mediante la cual, un número de tareas se agrupan y se procesan en un orden determinado. Una lista de tareas en espera de ser procesadas es conocida como cola de espera y el orden de ejecución de cada uno de los procesos es controlado por el administrador de trabajos del sistema operativo S SIAC.- Sistema Integral de Administración de Cartera. Software utilizado por las entidades financieras para la gestión de sus cuentas internas. T T24.- Sistema Bancario de Administración de Contratos Activos Tesorería.- Cada referencia en el presente manual a Tesorería, corresponde al Back Office de esta área, la cual es encargada de procesar las solicitudes de cobro y pago a los clientes generadas por el área de Cash Management de la gerencia de Cobranza. 108 Tipo de SPEI.- Clasificación de operaciones SPEI de acuerdo con el tipo de participantes. Las abreviaciones empleadas son las siguientes. Tercero se refiere a una persona física o una moral. Participante está referido a una entidad financiera. • Tercero – Participante (T-P). Referido a una operación cuando un Tercero deposita a una en una cuenta de una entidad financiera. • Tercero – Tercero (T-T). Empleado en los procesos de captación y colocación de VW Bank, ocurre cuando en una operación de la cuenta de un cliente a su misma cuenta en otro banco. • Participante – Tercero (P-T). Ocurre cuando VW Bank paga a un proveedor. • Participante – Participante (P-P). Operaciones entre entidades financieras. Transferencia electrónica.- Forma de pago en la cual los clientes efectúan depósitos a través del portal de Internet de su banco (Banca Electrónica), trasladando el dinero de su cuenta a una cuenta de VW Bank. V Versión.- Una vista de una tabla con el mismo o menor número de campos que la tabla original, en la cual se pueden incluir rutinas de validación o disparadores de eventos. 109 Anexo 1 PROCESO DESEADO CAPTACION Y COLOCACION (SPEI) Proceso Deseado SPEI T24 SAP T24 Cuentas de los clientes T24 Carga Archivo de Collection System en T24 Collection System Captación Alemania T24 Application Server Canal de Comunicación Enlace SPEI Visualiza los registros “liberados” Enlace SPEI Autoriza registros “enviados” Enlace SPEI TEBO verifica que finalice el proceso en “liquidadas” Operaciones Entrantes BANXICO México 110