DISEÑO DE IMPLEMENTACIÓN DEL SISTEMA SPEI PARA …

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 S I N A

Q U E P A R A O B T E N E R E L T Í T U L O D E :

I N G E N I E R O E N I N F O R M Á T I C A

P R E S E N T A N :

D A R I O E S T R A D A M É N D E Z

J U A N F R A N C I S C O J U À R E Z M U Ñ O Z

P A M E L A H U R T A D O A L V A R A D O

MÉXICO. DF 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 10

2.3 Java Platform, Enterprise Edition o Java EE 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

2.3.3 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.5.5 Encapsulamiento 17

2.3.5.6 Herencia 18

2.3.5.7 Polimorfismo 19

2.3.6 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 34

2.6.1 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. 41

3.1.1 Definición 41 3.1.2 Políticas 42

3.1.2.1 Políticas Generales del Área de Captación 42 3.1.2.1.1 Proceso para aprobación de productos de captación

tradicional 42 3.1.2.1.2 Proceso de baja de productos de Captación 43 3.1.2.1.3 Políticas de Comunicación Interna (Captación) 43

3.1.2.1.3.1 Lineamientos de Formato 43 3.1.2.1.3.2 Lineamientos generales 43

3.1.2.2 Productos de Captación Tradicional 44 3.1.2.2.1 Productos de captación para personas Físicas y Morales 44

3.1.2.2.1.1 “Depósito retirable con previo aviso”. 44 3.1.2.2.1.2 Inversión. 45 3.1.2.2.1.3 Inversión Corporativa 46

3.1.2.3 Apertura de Cuentas 47 3.1.2.3.1 Alta de Cliente 47 3.1.2.3.2 Alta de Cuenta 47

3.1.2.3.2.1 Clientes Nuevos / Inactivos. 47 3.1.2.3.2.2 Clientes Activos (con cuenta de “D.R.P.A.” activa) 48

3.1.3 Alta de Clientes 48 3.1.4 Inversión 52

3.1.4.1 Diagrama de Flujo de Inversión. 54 3.1.5 Generación de movimientos contables (CAPTACION) 54

3.1.5.1 Diagrama de Flujo de Generación de Movimientos Contables 56

3.2 Área de Colocación. 56


3.2.2 Domiciliación 57

3.2.2.1 Flujo de Domiciliación 59

3.2.3 Devolución de Dinero 59

3.2.3.1 Flujo de Devolución de Dinero 61

3.2.4 Reclasificación de Pago 61

3.2.4.1 Flujo de Reclasificación de Pago 63

3.2.5 Generación de Movimientos Contables 63

3.2.5.1 Flujo de Generación de Movimientos Contables 65

3.2.6 Casos Post Venta 65

3.2.6.1 Flujo de Casos Post Venta 67

3.3 Área de Tesorería. 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

3.3.3 Pagos a terceros 70

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

4.3.4 TCClient 76

4.4 Componentes Java 76

4.4.1 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 78

4.5.1 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 85

4.6.1 Parametrización Tabla VW.SPEI.PARAM 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. 96

5.3.1 Componentes de T24 96

5.4 Relación de costo-beneficio en las nuevas áreas 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.

II

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.

III

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.

1

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.

2

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

3

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.

4

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.

5

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,

6

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.

7

• 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.

8

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:

9

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.

10

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

11

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 Deitel, “Java, Cómo Programar”, Ed. Prentice Hall, p. 8 2 http://es.wikipedia.org/wiki/J2EE

12

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 http://es.wikipedia.org/wiki/Plataforma_Java 4 http://es.wikipedia.org/wiki/Java_Runtime_Environment

13

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

14

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

15

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

16

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

17

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)

18

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 http://www.mastermagazine.info/termino/4880.php 11 http://profesores.fi-b.unam.mx/carlos/java/java_basico3_3.html

19

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 13 Deitel, “Java, Cómo Programar”, Ed. Prentice Hall, p. 331 14 Eckel, Bruce. “Piensa en Java 2da. Edición”, Ed. Prentice Hall, p. 224

20

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

21

(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.

22

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.

23

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

24

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:

25

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

26

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

27

• 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

28

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).

29

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.

30

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.

31

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.

32

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, HP-

UX, 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.

33

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

34

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

35

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

36

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.17

16 http://roadmap.cbdiforum.com/reports/protocols/

37

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

WSDL.19

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 18 http://www.w3.org/TR/2007/REC-soap12-part0-20070427/ 19 http://www.w3.org/TR/wsdl

38

• 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.21

20 http://www-306.ibm.com/software/solutions/webservices/uddi/ 21 http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html

39

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.

40

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

41

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.

42

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

instituciones financieras, mediante el pago de un interés o la oferta de ciertos servicios23.

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

43

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

determinado, reporta una rentabilidad financiera fija o variable, en forma de dinero o en especie24.

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

44

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,

45

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.

46

• 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:



• 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,


Este producto podrá ser segmentado con características particulares para cada mercado objetivo.

47

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:



• 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,


• Este producto podrá ser segmentado con características particulares para cada mercado

objetivo.

48

3.1.2.3. Apertura de Cuentas 3.1.2.3.1 Alta de cliente

1. 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. Clientes Nuevos / Inactivos.

1) “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.

49

• 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. Clientes Activos (con cuenta de “D.R.P.A.” activa)

1) “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.

50

Área y/o

puesto Actividades Entradas Salidas

1.

Centro de

Atención a

Clientes

Captación

Promoción de Captación

ejecuta el proceso:

“Contratación de Productos

Captación” con el cual se

invitará a clientes prospectos

identificados potencialmente

para el banco a visitar alguna

concesionaria para realizar la

contratación de los productos

bancarios llevando su

documentación completa.

Genera expediente con

documentación completa de

los clientes.

CAC Captación recibe, revisa,

verifica, arma expediente con

documentación del cliente y

firma contrato.

Documentación

solicitada completa

incluyendo formato:

“Solicitud / Contrato

de Servicios Múltiples”

debidamente llenada.

Expediente

completo

(documentación

del cliente).

Punto de Control: Verificar relación de expedientes enviados con el número físico de

expedientes.

2.

Centro de

Atención a

Clientes

Captación

Registra información de datos

del cliente en el sistema CRM

para la generación del mismo

con base en documentación.

En caso de que la

documentación no esté

completa avisará al asesor de

ventas para que informe al

cliente que entregue la

documentación que faltó (paso

8).

En el momento de realizar el

guardado de la información

paralelamente se realiza el

proceso de verificación del

Expediente completo

(documentación del

cliente).

Verificación de

clientes en listas

de prevención y

lavado de

dinero.

Cliente creado

en el sistema

CRM – T24

(Interfaz de

cliente).

51

Área y/o


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 de

Atención a

Clientes

Captación

En caso de que el prospecto

sea una Persona Moral.

Realizar dictamen de acta

constitutiva y de poderes

anexos a la solicitud de

apertura.

Expediente completo

(documentación del

cliente).

Destrucción de

documentos.

Proceso

“Apertura de

Cuenta Cliente

Nuevo”.

4.

Centro de

Atención a

Clientes

Captación

Destruir documentos de

prospecto.

Resultado

desaprobatorio del

dictamen de acta

constitutiva y poderes

Documentos

destruidos.

Llamada

informativa a

promotor.

5.

Centro de

Atención a

Clientes

Captación

Analizar el caso de Persona

Expuesta Políticamente (PEP).

Para otorgar o no, autorización

de apertura de cuenta a dicho

prospecto. En caso de que el

resultado de la consulta en

listas de prevención resulte en

una persona de riesgo B ó C,

será necesaria la firma del

Ejecutivo que apertura la

cuenta, así como la firma del

responsable del CACC, en

Resultado positivo de

proceso de

“Verificación de

Clientes” del área de

Prevención y Lavado

de Dinero.

En caso de

Vo.Bo. Y

tratarse de una

Persona Moral:

Dictamen de

acta constitutiva

y poderes.

En caso de

Vo.Bo. Y

tratarse de una

Persona Física:

52

Área y/o


caso de tener dudas solicitar

Vo.Bo. Del Oficial de

Cumplimiento. En los casos de

prospectos con riesgo tipo A,

no se realiza la apertura de

cuenta y los documentos /

expediente se envían

físicamente al área de

Auditoría Interna.

Proceso

“Apertura de

Cuenta Cliente

Nuevo”.

En caso de no

otorgar Vo.Bo.:

Envío de

documentos al

área de

Auditoría

Interna.

Punto de Control: Reporte de cuentas creadas.

6. Centro de

Atención a

Clientes

Captación

Enviar documentos al área de

Auditoría Interna.

Revisión de PEP, y

negativa para apertura

de cuenta.

Llamada

informativa a

Promotor


7.

Centro de

Atención a

Clientes

Captación

Realizar Llamada a Promotor

informándole que la apertura

no pudo realizarse debido a

políticas internas de VW Bank.

Revisión de PEP, y

negativa para apertura

de cuenta.

Resultado

desaprobatorio del

dictamen de acta

constitutiva y poderes.

Llamada

informativa a

Prospecto.

8.

Centro de

Atención a

Clientes

Captación

Realizar Llamada a prospecto,

informándole que la apertura

no pudo realizarse debido a

políticas internas de VW Bank.

Llamada informativa a

Promotor.

Envío de correo

informativo a

prospecto en

caso de no

establecer

contacto

telefónico.

Fin del proceso,

53

Área y/o


en caso de

establecer

contacto.

9. Centro de

Atención a

Clientes

Captación

Enviar correo electrónico a

prospecto informándole que la

apertura no pudo realizarse

debido a políticas internas de

VW Bank.

Llamada informativa a

prospecto.

Fin del proceso.

1

0.

Centro de

Atención a

Clientes

Captación

Destruir documentación

incompleta en caso de no

recibir complemento en 72 hrs.

Expediente completo

(documentación del

cliente).

Llamada de

documentación

incompleta a

prospecto.

1

1.

Centro de

Atención a

Clientes

Captación

Realizar llamada a Promotor

de Ventas solicitando

documentación faltante.

Expediente completo

(documentación del

cliente).

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 Entradas Salidas

1

.

Centro de

Atención a

Clientes

Captación

Consultar en

sistema

operaciones de

apertura de

cuenta de

inversión

pendientes por

atender.

Proceso: “Solicitud

de Inversión”.

Creación de

Inversión.

2

.

Centro de

Atención a

Clientes

Creación de la

Inversión en el

sistema T24 (sin

Consulta en

sistema de

operaciones de

Inversión creada.

Autorización de

54

Área y/o puesto

Actividades Entradas Salidas

Captación autorización). apertura de

inversión

pendientes.

Cuenta de Inversión

Si no existen fondos

suficientes, proceso

de: “Confirmación de

Operaciones”.


3

.

Centro de

Atención a

Clientes

Captación

Revisar y autorizar

inversión creada

en sistema.

Inversión creada. Inversión autorizada.

Registro de

operación en

sistema.

4

.

Centro de

Atención a

Clientes

Captación

Registrar

Operación en

Collection System

Inversión

autorizada

Proceso de

“Confirmación de

Operación”.

Punto de Control: Autorización de Inversión.

55

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.

56

Descripción de la actividad Área

1

Después de recibir una solicitud de aclaración de Captación, el

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.

Back Office

CAC /

Administración

de Contratos

(Facturación)

2

El área de Administración de Contratos (Facturación), recibe el

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)

3

Facturación genera la póliza contable en T24, afectando las

cuentas correspondientes.

Una vez generadas todas las pólizas se entrega al área de

Terminaciones las solicitudes con el folio asignado por el

sistema

Administración

de Contratos

(Facturación)

4

Recibe las solicitudes, verifica y autoriza en T24 dichas pólizas.

Una vez autorizadas todas las solicitudes se entregan

Facturación las solicitudes.

Administración

de Contratos

(Terminaciones)

5

Como control de la operación y soporte de haber efectuado

dicho

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.

Administración

de Contratos

(Facturación) /

Servicios

Internos

5

En caso de ser necesario algún movimiento adicional,

Facturación turna el caso al CACC a través de la carpeta AD2,

para que realicen los movimientos correspondientes

Administración

de Contratos

(Facturación)/

CACC

57

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

58

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.


1

Diariamente se generan de forma individual en T-24 las capturas

manuales que los clientes les solicitan cobrar (cobros parciales y de

inversiones), el proceso de domiciliación debe de iniciar después de

terminar el proceso de aplicación de pagos enviados por Domiciliación

del día anterior, para poder enviar a cobro el saldo actualizado exigible

en el contrato.

CAC (Centro de

Atención a Clientes)

2

Posteriormente a las generaciones manuales se prepara en T-24 el

archivo de cobranza que incluirá los siguientes conceptos:

• 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

Administración

de Contratos

(Cash Management)

59

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.

3

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.

Al día siguiente se reciben las respuestas bancarias, con las razones

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

Tesorería

4

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

movimientos que entraron como pagos por ventanilla los cuales se

aplican directamente a la cuenta eje del cliente.

Cash Management descarga el reporte de respuesta bancaria para su

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.

Administración

de Contratos

(Cash Management)

60

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.


1 Cuando algún área de la gerencia de Cobranza detecta un saldo a

favor y confirma su procedencia, hace una solicitud de devolución a

Administración

de Contratos

61

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.

2

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

solicitudes recibidas.

Cuando se visualiza la Consulta de Pagos Generados, se confirma

que se encuentren correctos los archivos y se coloca la información en

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.

Administración

de Contratos

(Cash Management)

3

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

no exitosos, así como la razón de rechazo.

Los archivos de respuesta bancaria deberán ser registrados por

Tesorería lo mayor pronto posible para actualizar saldos.

Tesorería

4 En forma diaria, Cash Management descarga los reportes de

respuesta bancaria para su control y resguardo histórico.

Administración

de Contratos

(Cash Management)

62

3.2.3.1 Flujo de Devolución de Dinero


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


1 En determinadas ocasiones la operación del ciclo de vida del contrato Tesorería / CAC

63

cuando existe la necesidad de hacer reclasificación de movimientos

entre cuentas de los clientes o entre cuentas contables.

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.

(Centro de Atención

a Clientes)

2

En caso de que el pago se haya aplicado, Cash Management analiza

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)

3

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

egresos.

En el caso B se debe generar una póliza contable de acuerdo con el

requerimiento que se solicito físicamente, traspasando el pago del

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.

Administración

de Contratos

(Cash Management)

64

3.2.4.1 Flujo de Reclasificación de Pago


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

Después de recibir una solicitud de aclaración, el Back Office CAC

(Centro de Atención a Clientes) determina si es necesario realizar

movimientos contables en la cuenta del cliente, posteriormente solicita

al área de Facturación realizar los movimientos correspondientes, y en

Back Office CAC /

Administración de

Contratos

(Facturación)

65

caso de existir una devolución al cliente, se incluye la solicitud de

dicha devolución.

2

El área de Administración de Contratos (Facturación), recibe el

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)

3

Facturación genera la póliza contable en T24, afectando las cuentas

correspondientes a los conceptos mencionados en el formato. Y

habilita la cuenta bancaria externa para domiciliación.

Una vez generadas todas las pólizas se entrega al área de

Terminaciones las solicitudes con el folio asignado por el sistema

Administración

de Contratos

(Facturación)

4

Administración de Contratos recibe las solicitudes, verifica y autoriza

en T24 dichas pólizas. Una vez autorizadas todas las solicitudes se

entregan al área de Facturación.

Administración

de Contratos

(Terminaciones)

5

Facturación recibe las solicitudes, verifica si incluyen evoluciones y en

caso de existir alguna la pasa a Cash Management para que se realice

el proceso de Devolución de Saldos a Favor o el proceso de

Reclasificación de Saldos.

Cuando no sean necesarios más movimientos el crédito seguirá la

vida normal que se refiere al proceso de Domiciliación.

Como control de la operación y soporte de haber efectuado dicho

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.

Administración

de Contratos

(Facturación) /

Cash Management /

Servicios

Internos

66

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.


1

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

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

CAC (Centro de

Atención a Clientes)

67

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.

2

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

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

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.

Administración

de Contratos

(Terminaciones)

3

En el caso A se le envía la factura a la persona que pago el auto

(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.

Administración

de Contratos

(Terminaciones)

4

Una vez que se tiene la nueva factura se regresa al archivo para que

sea integrado al expediente.

Adicionalmente a esto se le informa a la compañía aseguradora del

Administración

de Contratos

(Terminaciones)

68

cambio de la unidad para que realice el endoso correspondiente, se

realizan los cambios en el sistema T-24 de la nueva garantía y se

registra en Collection System la solución otorgada al cliente.

/ (Seguros)

Recursos

Humanos /

Servicios

internos /

Seguridad

3.2.6.1 Flujo de Casos Post Venta


69

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).

70

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.

71

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.

72

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.

73

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.

74

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.

75

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

76

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.

77

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:

78

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.

79

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:

80

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 Descripción Acción

SPEI.ESTATUS Estatus SPEI 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 Operación FT

Relacionada

Almacenará el ID de la Transferencia de

Recursos relacionado con la transferencia SPEI

SPEI.CVE.DEV Clave de Devolución

SPEI

Almacenará el código de rechazo para 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 Código asignado por

VW BANK

FUNDS.TRANSFER,VPM.O

FS.SPEI.ENV

Registro de FT

Envío

Registra el

movimiento de envío

ACSE SPEI Enviado


FS.SPEI.REV

Registro de FT

Reverso

Registra el

movimiento de

reverso

ACSD SPEI Devuelto


FS.SPEI.REC

Registro de FT

Recepción

Registra el

movimiento de

recepción

ACSR SPEI Recibido


FS.SPEI.DEVOL

Registro de FT

Devolución

Registra el

movimiento de

devolución

ACSD SPEI Devuelto

81

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,

CALLALAVISTA.CEDIDO

Registro de Call Money

A la Vista Cedido

Registra el movimiento de

envío en Front Office y lo

autoriza Back Office.

MM.MONEY.MARKET,

CALLAPLAZO.CEDIDO


A Plazo Cedido


envío en Front Office y lo

autoriza Back Office.

MM.MONEY.MARKET,

CALLALAVISTA.TORNADO


A la Vista Tomado


recepción envío en Front Office

y lo autoriza Back Office.

MM.MONEY.MARKET,

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:

82


@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:


@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

SALIENTE P-T

MX.DOMICILIACION,RET.FONDOS.SPEI Registrar un SPEI Saliente

para Captación.

CAPTACION

SALIENTE P-T

MX.DOMICILIACION,RET.FONDOS.SPEI.O

NLINE

Registrar un SPEI Saliente

para Captación (En línea)

Colocación (Devoluciones)

COLOCACION MX.DOMICILIACION,DEVOL.SPEI Registrar una Devolución para

83

SALIENTE P-T Colocación y esperar la

autorización para generar el

mensaje SPEI.

COLOCACION

SALIENTE P-T

MX.DOMICILIACION,DEVOL.AUT.SPEI Al autorizar el registro realizar

el envío del mensaje a

Enlace-SPEI

Manejo de respuesta enlace SPEI

COLOCACION

Y CAPTACION

MX.DOMICILIACION,RESPUESTA.SPEI Actualizar el estatus del envío

FT para confirmarlo o

rechazarlo.

COLOCACION

Y CAPTACION

MX.DOMICILIACION,AUDIT Datos de auditoría para

registros en

MX.DOMICILIACION.

Tesorería

TESORERIA

SALIENTE P-P

MM.MONEY.MARKET,CALLALAVISTA.CE

DIDO.COMP.SPEI

Al autorizar el registro

generado por Front Office

generar el envío del mensaje

a Enlace SPEI.

TESORERIA

SALIENTE P-P

MM.MONEY.MARKET,CALLAPLAZO.CEDI

DO.COMP.SPEI

Al autorizar el registro

generado por Front Office

generar el envió del mensaje

a Enlace SPEI.

TESORERIA

SALIENTE P-P

MM.MONEY.MARKET,AUTORIZA.SPEI Confirmar el SPEI enviado.

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 Registrar un SPEI Entrante

84

ENTRANTE P-P RNADO.COMP para Participante-Participante.

TESORERIA

ENTRANTE P-P

MM.MONEY.MARKET,CALLAPLAZO.TORN

ADO.COMP

Registrar un SPEI Entrante

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 Descripción Funciones o características

VW.SPEI.CALLJ.IXPAN Rutina de entrada para la

versión de Captación en

línea o en proceso de T24.

• Aplicar FT para tomar los

recursos de la cuenta T24 del

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

la cuenta que obtiene los

datos necesarios para el

envío a SPEI.

• Validar que exista la cuenta, que

sea una categoría valida y tipo

de pago DIRECTO.

• Extraer datos de banco y cuenta

destino de la cuenta T24.

• Extraer datos del cliente

VW.SPEI.CALLJ.IXPAN.

DEVOL

Rutina de

AUTHORISATION para la

versión de Colocación.



• Aplicar FT para tomar los


85


cliente.

VW.POP.DOMI.PAG Rutina de Validación para

el Contrato CRM que

obtiene los datos

necesarios para el envío a

SPEI.

• Validar que exista el contrato y

obtiene la cuenta eje.

• Validar que exista la cuenta y

que acepte pago DIRECTO.

• Obtener datos de banco y

cuenta destino del cliente.

• Extraer datos del cliente.

VW.SPEI.CALLJ.IXPAN.

PP

Rutina de entrada para

registro de mensajes

Participante-Participante.



• Enviar mensaje de error para

indicar falla en el registro de la

petición.

VW.SPEI.CALLJ.SALIEN

TES

Rutina de entrada para las

versiones de los tipos de

SPEI: T-T, T-P y P-T.

• Aplica FT para tomar los


cliente.



• Aplicar FT para deshacer

movimiento si ocurre un error en

el registro de la petición

VW.POP.DOMI.SPEI.SA

L

Rutina de Validación para

las versiones de los tipos

de SPEI: T-T, T-P y P-T.

• Validar la cuenta del Tercero y

su categoría para T-T y T-P.

• Extraer datos del cliente para T-

T y T-P

• Extraer datos del banco para P-T

• Validar la cuenta CLABE para T-

T 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

ESTA

Rutina de entrada para

recibir la respuesta de

SPEI de un mensaje

• Actualizar los campos de

DOMI.STATUS y DEV.STATUS

para marcar como liquidado o

86


enviado. rechazado.

VW.SPEI.CALLJ.ENTRA

NTES

Rutina de entrada para las

versiones de SPEI

Entrantes

• Registrar en

MX.DOMICILIACION el mensaje

entrante.

VW.V.DOMI.AMT Rutina de Validación para

revisar que la cuenta tenga

saldo para aplicar.

• Validar el monto contra el saldo

(WORKING.BALANCE) de la

cuenta.

VPM.2BR.VALNUEVO.D

OMI

Rutina de ID para evitar

que se modifique un

registro ya existente.

• Verificar si existe el ID y evitar

que sea modificado con la

versión.

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 en INAU para

autorización desde Devolución para

Colocación.

%MX.DOMICILIACION$NAU,RECEPCION.SPEI Consultar mensajes en INAU para

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.

87


@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

RECEPCION/ENVIO

A/50 SI

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

RECEPCION/ENVIO

A/50 SI

RFC.BANXICO RFC BANXICO PARA

RECEPCION/ENVIO

A/20 SI

88

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

89

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.

90

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.

91

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.

92

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.

93

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.

94

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

características para hospedar la aplicación25.

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

R

SUSE Linux Enterprise Server (SLES) 10 y SP1 R

SUSE Linux Enterprise Desktop (SLED) 10 y SP1 C

SUSE Linux OSS 10.1 o 10.2 C

Ubuntu

Ubuntu 6.06 LTS y Ubuntu 6.10 C

Ubuntu 7.04 C

25 http://www-01.ibm.com/support/docview.wss?rs=2327&uid=swg27006536

95

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) C

5.2.2 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.

96

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 Propósito bnk.run/Interfaces/java/spei/class Clases de java principales para la interface de

SPEI bnk.run/Interfaces/java/spei/class2 Clases de ayuda bnk.run/Interfaces/java/spei/lib Librerías requeridas bnk.run/Interfaces/java/spei/log Contendrá los logs (registros) generados por

la interface

97

bnk.run/Interfaces/java/spei/properties Contendrá el archive de configuración de la interface

5.3 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 Sub directorio Archivos 1 bnk.run/Interfaces/java/spei/class ClientWSPraxisSpei.java

ClientWSPraxisSpei.class ClientWSPraxisSpeiHelper.java ClientWSPraxisSpeiHelper.class SpeiHostEndPointService.java SpeiHostEndPointService.class SpeiHostEndPointServiceLocator.java SpeiHostEndPointServiceLocator.class

2 bnk.run/Interfaces/java/spei/class2 ConnectivityT24.java ConnectivityT24.class ConnectivityHelper.java ConnectivityHelper.class ConnectivityT24Client.java ConnectivityT24Client.class

3 bnk.run/Interfaces/java/spei/properties 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:

98

• # 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 Meses Consultor T24 Consultor J2EE Líder de proyecto Total

Análisis y diseño 1 $ 30,000.00 $ 50,000.00 $ 35,000.00 Desarrollo 2 $ 30,000.00 $ 50,000.00 $ 35,000.00 Desarrollo 3 $ 30,000.00 $ 35,000.00 Implementación 4 $ 35,000.00 Pruebas 5 $ 35,000.00 $ 90,000.00 $ 100,000.00 $ 175,000.00 $ 365,000.00

5.4.2 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.

99

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.

100

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

101

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.

102

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.

103

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,

104

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.

105

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, http://es.wikipedia.org/wiki/Plataforma_Java, Consulta Marzo-2009

� Java Runtime Environment, 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 Marzo-

2009

� 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

106

� 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

107

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.

108

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.

109

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.

110

Anexo 1

PROCESO DESEADO CAPTACION Y COLOCACION (SPEI)

Proceso Deseado SPEI

T24

Carga Archivo de

Collection

System en T24

Enlace SPEI

Visualiza los

registros

“liberados”

Enlace

SPEI

Autoriza

registros

“enviados”

Enlace SPEI

TEBO verifica que

finalice el proceso

en “liquidadas”

BANXICO

Collection

System

Captación

Alemania

México

T24

Application Server

Canal de Comunicación

SAP T24

Operaciones Entrantes

T24

Cuentas de los clientes

DISEÑO DE IMPLEMENTACIÓN DEL SISTEMA SPEI PARA …

Documents

Transcript of DISEÑO DE IMPLEMENTACIÓN DEL SISTEMA SPEI PARA …