Download Icon

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