1
DESARROLLO Y SOPORTE DE PRUEBAS DEL PROYECTO PAGO UNICO EN EL CANAL ELECTRÓNICO ATM MULTIFUNCIONALES, PARA
DESCONGESTIONAMIENTO DE LAS OFICINAS EN EL BANCO CAJA SOCIAL
DIANA PAOLA CASTAÑEDA TALERO
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS BOGOTÁ
2
DESARROLLO Y SOPORTE DE PRUEBAS DEL PROYECTO PAGO UNICO EN EL CANAL ELECTRÓNICO ATM MULTIFUNCIONALES, PARA
DESCONGESTIONAMIENTO DE LAS OFICINAS EN EL BANCO CAJA SOCIAL
DIANA PAOLA CASTAÑEDA TALERO 20061020008
TRABAJO DE GRADO PASANTIA SOPHOS BANKING SOLUTIONS S.A.S.
DIRECTOR INTERNO Lilian Astrid Bejarano Garzón Docente Facultad de Ingeniería
DIRECTOR EXTERNO Mohanraj Subramaniam
Development Director Sophos Banking Solutions S.A.S.
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS BOGOTÁ
3
CAPITULO I CONTEXTUALIZACION DEL PROYECTO REALIZADO ... 11
1. PLANTEAMIENTO DEL PROBLEMA ... 11
1.1. DESCRIPICIÓN DEL PROBLEMA ... 11
1.1.1. FORMULACIÓN DEL PROBLEMA ... 11
2. JUSTIFICACIÓN ... 12
3. OBJETIVOS ... 14
3.1. OBJETIVO GENERAL ... 14
3.2. OBJETIVOS ESPECÍFICOS... 14
CAPITULO II MARCO REFERENCIAL ... 16
4. MARCO REFERENCIAL SOPHOS BANKING SOLUTIONS S.A.S ... 16
4.1. BANCA ELECTRÓNICA ... 17
5. MARCO REFERENCIAL BANCO CAJA SOCIAL ... 19
6. MARCO CONCEPTUAL ... 20
7.1. ESQUEMA DE PROCESAMIENTO TRANSACCIONAL DE UN PAGO RED EFT ... 24
7.2. ARQUITECTURA ORIENTADA A SERVICIOS (SOA) ... 25
7.2.1. ¿QUE ES SOA? ... 25
4
8. MARCO HISTÓRICO ... 27
8.1. CONTEXTO HISTÓRICO DE LA BANCA ELECTRÓNICA ... 27
8.2. BANCA ELECTRÓNICA EN COLOMBIA ... 27
CAPITULO III MARCO METODOLOGÍCO ... 29
9. METODOLOGÍA USADA ... 29
CAPITULO IV DESARROLLO DEL PROYECTO ... 31
10. DESCRIPCIÓN FUNCIONAL ... 31
10.1. ¿QUÉ ES PAGO ÚNICO? ... 31
10.2. ARQUITECTURA ANTES Y DESPUÉS DE PAGO ÚNICO ... 31
10.3. PAGO ÚNICO EN MULTIFUNCIONALES ... 32
10.3.1. MERCADO OBJETIVO ... 32
10.3.2. ESPECIFICACIÓN DE LAS TRANSACCIONES IMPLEMENTADAS ... 33
10.3.2.1. Tipos de Pago ... 33
10.3.2.1.1. Pagos de Recaudos ... 33
10.3.2.1.2. Pago de Productos Propios (PPP) ... 33
10.3.2.1.3. Pago de Planilla Integrada de Liquidación de Aportes (PILA) ... 34
10.3.2.2. Tipos de Lectura ... 34
10.3.2.3. Medios de Pago ... 35
10.3.2.4. Transacciones ... 35
11. CONSTRUCCIÓN DE LA SOLUCIÓN ... 38
11.1. COMPONENTES DESARROLLADOS ... 39
11.1.1. COMPONENTE CONSUCONV ... 40
11.1.2. COMPONENTE ISOMULTIFUNCIONAL ... 40
11.1.3. COMPONENTE FSCOPACA ... 41
11.1.4. COMPONENTE ISOTRANV2 ... 41
11.2. PRUEBAS UNITARIAS ... 43
11.3. RESULTADOS ... 43
12. PRUEBAS DE INTEGRACIÓN ... 44
12.1. RESULTADOS ... 45
5
13.1. REVISIÓN INTERNA ... 46
13.2. ENTREGA ÁREA DE CERTIFICACIÓN... 46
13.3. RESULTADOS ... 47
14. SOPORTE PRUEBAS DE CERTIFICACIÓN ... 48
14.1. RESULTADOS ... 49
CAPITULO V CLAUSURA DEL PROYECTO ... 51
15. CONCLUSIONES ... 51
16. LÍNEAS DE TRABAJO FUTURAS. ... 53
17. BIBLIOGRAFÍA ... 54
CAPITULO VI ANEXOS ... 56
18. ANEXO A – DOCUMENTOS DE REQUERIMIENTOS FUNCIONALES ... 56
19. ANEXO B – DOCUMENTOS DE REQUERIMIENTOS TÉCNICOS ... 57
20. ANEXO C – DOCUMENTOS PRUEBAS UNITARIAS... 58
21. ANEXO D – LISTAS DE CHEQUEO REVISIÓN INTERNA ... 59
22. ANEXO E – FORMATO ACTA DE ENTREGA ... 60
6
LISTA DE FIGURAS
Figura 1. Metodología Fábrica de Software Sophos Banking Solutions S.A.S. ... 17
Figura 2. Servicios Ofrecidos en Medios Electrónicos Sophos Banking Solutions S.A.S. 18 Figura 3. Tipos de Cajeros Electrónicos Según Funcionalidad. Autora ... 21
Figura 4. Funcionalidades Comunes de una Terminal POS. Autora ... 21
Figura 5. La Adopción de una innovación basada en la Web. ... 22
Figura 6. Roles dentro del Procesamiento de un Pago con Tarjeta. ... 25
Figura 7. Comparación arquitecturas Antes y Despues de Pago Único. Autora ... 32
Figura 8. Ejemplo Código de Barras en Pago de Servicio Público. ... 35
Figura 9. Arquitectura Transacción Consulta Configuración del Convenio. Autora... 38
Figura 10. Arquitectura Transacción Consulta de Valor a Pagar. Autora ... 38
Figura 11. Arquitectura Transacción de Pago. Autora ... 39
Figura 12. Proceso Soporte Pruebas de Integración. Autora ... 44
7
LISTA DE TABLAS
Tabla 1. Participación Porcentual en Operaciones financieras por Canal en Colombia ... 28
Tabla 2. Indicadores en un código de Barras. Autora ... 34
Tabla 3. Condiciones de Lectura y Medio de Pago por Tipo de Pago. Autora ... 36
Tabla 4. Transacciones VS Tipo de Pago. Autora ... 37
Tabla 5. Servicios publicados en el componente consuconv. Autora ... 40
Tabla 6. Servicios publicados en el componente isomultifuncional. Autora ... 41
Tabla 7. Servicios publicados en el componente fscopaca. Autora ... 41
Tabla 8. Especificación Códigos de Proceso para las transacciones. Autora ... 42
Tabla 9. Especificación Porcentual de soporte pruebas de integración. Autora ... 45
Tabla 10. Especificación paquetes de entrega. Autora ... 47
8
GLOSARIO
Canal: es el medio que utilizan las entidades financieras para prestar sus servicios a los clientes y/o usuarios, tales como: oficinas, cajeros automáticos, Internet, datafonos, audio respuesta, corresponsales bancarios, telefonía móvil, entre otros. Datáfono (POS): es el dispositivo empleado en establecimientos de comercio para realizar pagos y efectuar otras operaciones, conocido como POS por su sigla en inglés (Point Of Sale).
ACH: es el sistema que permite realizar transferencias electrónicas de dinero entre entidades financieras, mediante una cámara establecida para liquidar y compensar este tipo de movimientos. ACH es el acrónimo en inglés de Automated Clearing House.
Multifuncional: Es un maquina transaccional que cumple con las mismas características de un cajero convencional, con el plus de poder recibir efectivo y cheques y de la misma manera dar vueltas al cliente.
CORE: Sistema centralizado de información.
Front End: Como lo indica su nombre, hace referencia a todos los canales que tiene un banco, es decir, con lo que el cliente interactúa directamente.
Back End: Hace referencia a la lógica del negocio y a la información en la Base de datos.
9
INTRODUCCION
Los medios electrónicos bancarios constituyen uno de los principales pilares del sistema bancario actual, tanto a nivel local como a nivel mundial (Flechas Villamil, 2012). Muchas de las nuevas tecnologías implementadas dentro de la "banca electrónica", son factor determinante para permitir el acceso de las personas a los servicios financieros, lo cual impacta de manera positiva al crecimiento y bienestar de la economía. El continuo desarrollo tecnológico, la cambiante demanda del mercado y la continua adaptación a las nuevas necesidades, han permitido la aparición de nuevos y mejores medios de pago.
Dentro del catálogo de los medios electrónicos bancarios, se pueden encontrar las tarjetas electrónicas (débito y crédito generalmente), que pueden ser utilizadas en los cajeros automáticos (ATM) y en las terminales de pago de puntos de venta (POS). Además de los anteriores, medios como Internet, la telefonía fija (canales de audio respuesta) y la telefonía móvil, también se incluyen dentro del grupo de los denominados medios electrónicos (Muñoz Leiva, 2008). El uso de la Internet como medio de pago se ha popularizado recientemente, pero aún son las tarjetas electrónicas, utilizadas en los canales ATM y POS, los que registran el mayor porcentaje de participación dentro del total de transacciones que se realizan en Colombia (Flechas Villamil, 2012). Esta tendencia no es muy diferente a nivel mundial.
Dada la importancia que tiene la banca electrónica para cualquier entidad financiera, los sistemas, componentes, y todo el software necesario para procesar la información deben de ser los más adecuados, en términos de rendimiento, estabilidad y escalabilidad, entre otros. De manera muy general, y en lo relacionado con la parte lógica del negocio, los sistemas bancarios que procesan la información transaccional realizada a partir de la utilización de un medio electrónico, se comunican a través del intercambio de una serie de mensajes, los cuales contienen toda la información relevante para la realización de la transacción.
10
11
CAPITULO I CONTEXTUALIZACION DEL PROYECTO REALIZADO
1. PLANTEAMIENTO DEL PROBLEMA
1.1. DESCRIPICIÓN DEL PROBLEMA
En la actualidad, las transacciones financieras originadas en canales de medios electrónicos, es decir, aquellas que se dan con la utilización de algún tipo de medio electrónico bancario (ATM, datafonos, Internet, etc.) y en las Oficinas, tienen uno de los mayores porcentajes de participación dentro del total de las transacciones realizadas en las entidades bancarias (Superintendencia Financiera de Colombia, 2014), siendo estas últimas la de mayor concurrencia por parte del cliente, por lo que es necesario generar estrategias que permiten prestar un servicio eficiente a las personas.
Los sistemas bancarios están en un continuo crecimiento y evolución, ya que existe la necesidad de responder a las demandas cambiantes del mercado, en cuanto a nuevos productos y funcionalidades para los clientes. En este sentido es importante aprovechar las herramientas que se tengan disponibles para brindar un servicio más eficiente y accesible para las personas.
1.1.1. FORMULACIÓN DEL PROBLEMA
12 2. JUSTIFICACIÓN
Social: Mediante el desarrollo del proyecto planteado, se busca satisfacer el requerimiento del Banco Caja Social de mejorar la calidad del servicio prestada a los clientes, a través de la optimización del canal electrónico ATM horario 7 x 24, en efectivo con vueltas en monedas y billetes y con tarjeta débito, brindando una opción diferente como lo son los cajeros multifuncionales y de esta manera complementar la oferta de valor hacia los clientes recaudadores y una opción transaccional adicional para los clientes de los convenios de recaudos (pagadores).
Sophos Banking Solutions como proveedor de soluciones tecnológicas del Banco
Caja Social, generó el proyecto SBFS00661 para atender los temas relacionados a
Multifuncionales.
Tecnológico: Las cambiantes necesidades de la banca electrónica, en cuanto al ofrecimiento de nuevos y mejores servicios para sus clientes, requiere de una ágil respuesta durante el desarrollo de nuevas aplicaciones tecnológicas que los soporten. En este momento el Banco Caja Social cuenta con 55 puntos Atm Multifuncionales (Banco Caja Social, s.f.), en los cuales solo se está utilizando el 60% de su potencial. En ese sentido es vital realizar las implementaciones necesarias para explotar este canal electrónico, aprovechando el 100% de su funcionalidad y así convertirlo en un activo para el Banco y sus clientes.
El proyecto, además de la finalidad social, económica y tecnológica que se ha expuesto hasta ahora, pretende contribuir con la ampliación de los conocimientos adquiridos durante la carrera profesional en áreas puntuales como la Ingeniería de software, bases de datos, gestión de proyectos, y modelamiento de software.
Las actividades a desarrollar durante la pasantía estarán supervisadas y apoyadas continuamente por el director externo y de manera intermitente por el director
13
14 3. OBJETIVOS
3.1. OBJETIVO GENERAL
Desarrollar una solución de software y dar soporte a pruebas del proyecto de Pago Único en el canal electrónico ATM Multifuncionales, para el mejoramiento de la calidad del servicio a los clientes del Banco Caja Social.
3.2. OBJETIVOS ESPECÍFICOS
Desarrollar un componente de Software encargado de procesar las
transacciones de Pagos de Productos Propios y Recaudos, generadas en los cajeros multifuncionales de la Entidad, de acuerdo al diseño definido por el Banco Caja Social.
Desarrollar un componente de software encargado de procesar las
transacciones de Pagos de PILA, generadas en los cajeros multifuncionales de la Entidad, de acuerdo al diseño definido por el Banco Caja Social.
Desarrollar un componente de software encargado de Consultar la
configuración del convenio, del cual se va a realizar el pago, de acuerdo al diseño definido por el Banco Caja Social.
Realizar la respectiva parametrización de los servicios en el componente
ambiente de desarrollo, mediante la solución de incidencias, para garantizar la correcta comunicación entre los sistemas.
Entregar la solución al área de Calidad Interna, para que se le realice la respectiva revisión por par y realizar los ajustes sugeridos por el evaluador interno, para garantizar una entrega de alta calidad.
Realizar la entrega oficial de la solución al área de Calidad del Banco, para
15
Brindar soporte durante el proceso de Pruebas y certificación, mediante la
16
CAPITULO II MARCO REFERENCIAL
4. MARCO REFERENCIAL SOPHOS BANKING SOLUTIONS S.A.S
“Sophos Banking Solutions, es una compañía colombiana creada con capital de la India. Especializada en desarrollo de software y servicios de consultoría en tecnología para los sectores financieros, en especial: sector Bancario y Bursátil” (Sophos Banking Solutions SAS, 2015).
Cuenta con una alta calidad de recursos, gracias a la mezcla de la experiencia de consultores de la India, con una importante experiencia en sistemas bancarios y consultores de Colombia, con una amplia experiencia en el contexto colombiano, teniendo en su historial excelentes proyectos con los clientes más importantes en Colombia.
17
Figura 1. Metodología Fábrica de Software Sophos Banking Solutions S.A.S. Tomado de http://www.sophosbanking.com/index.php/servicios/fabrica-de-software/102-servicios/fabrica-de-software/fabrica-software-metodologia/90-fabrica-de-software-metodologia.html
4.1. BANCA ELECTRÓNICA
18
Dentro del portafolio de servicios ofrecidos por la empresa, se encuentran proyectos de diseño, administración e implementación de medios electrónicos, en temas referentes a administración de transacciones, comunicaciones, mensajería y seguridad de la información, entre otros. En la Figura 2 se reflejan los servicios ofrecidos en esta área de Medios electrónicos.
19
5. MARCO REFERENCIAL BANCO CAJA SOCIAL
“Banco Caja Social es una empresa de la Fundación Social que mediante su actividad bancaria busca contribuir en la superación de las causas estructurales de la pobreza en Colombia para promover una sociedad justa, solidaria, productiva y en paz, razón de ser de toda la Organización” (Banco Caja Social, s.f.). Esta entidad tiene 4,8 millones de clientes totales y presencia en 63 ciudades con 263 oficinas, 4 extensiones y un centro de pagos, más de 600 cajeros automáticos propios y más de 3.000 Corresponsales Bancarios. Sus activos totales suman cerca de $10,2 billones2.
20 6. MARCO CONCEPTUAL
6.1. BANCA ELECTRÓNICA
Los medios electrónicos bancarios, también agrupados bajo el término "banca electrónica" (Muñoz Leiva, 2008), agrupan todas aquellas formas de realizar transacciones bancarias, generalmente relacionadas con transferencias de dinero de una cuenta a otra, mediante el uso de un medio electrónico. El término EFT componentes, sistemas y redes computacionales que permiten el procesamiento de estas transacciones (Sienkiewicz, 2002).
La importancia que tiene la banca electrónica para las instituciones financieras es superlativa, ya que, además de permitir el manejo de un gran volumen de transacciones, propias de cada entidad bancaria, también lleva a que tanto las personas que ya son clientes de algún banco, como aquellas que recién ingresan, puedan acceder más fácilmente a nuevos y mejores servicios bancarios, con la posibilidad de tener medios de pago diferentes al efectivo (Flechas Villamil, 2012). Además de lo anterior, la utilización de medios electrónicos de pago brinda algunos beneficios adicionales, como la reducción de costos, la simplificación de la contabilidad y cierto nivel de seguridad (Rouse, 2006).
6.1.1. CAJERO AUTOMÁTICO - ATM
21
Figura 3. Tipos de Cajeros Electrónicos Según Funcionalidad3. Autora
6.1.2. TERMINALES DE PAGO DE PUNTOS DE VENTA - POS
Conocidos en el sector financiero simplemente como POS, son los dispositivos que se utilizan en establecimientos comerciales, y que permiten la utilización de medios electrónicos (tarjetas débito y crédito) como forma de pago en la adquisición de algún bien o servicio, incluyendo la posibilidad de realizar otras transacciones básicas, como consultas de saldos y pago de facturas Más que ser un medio de pago, este es el instrumento electrónico que permite realizar transacciones a clientes que cuentan con una tarjeta débito (VISA Colombia, 2008). Al igual que un ATM, una terminal POS no es un medio electrónico de pago como tal, sino que es más una herramienta que permite el uso de las tarjetas débito y crédito por parte de un cliente.
Figura 4. Funcionalidades Comunes de una Terminal POS. Autora
22 años (Flechas Villamil, 2012). La banca electrónica por Internet se puede dividir en tres grupos básicos, de acuerdo al tipo de servicios que se ofrece. El primero hace relación a el servicio informativo puro que una entidad ofrece a sus cliente, el segundo se refiere al establecimiento de canales de comunicación entre la entidad y el cliente, y el tercero, los servicios transaccionales (Muñoz Leiva, 2008). Dentro de este último grupo de servicios transaccionales, también se realiza una catalogación, dependiendo de las partes involucradas en la transacción (Administración, negocio y consumidor); dentro de ese grupo, cabe destacar la importancia que están adquiriendo las transacciones negocio a consumidor ó B2C (Muñoz Leiva, 2008); sobre este tipo de transacciones se agrupan las que comúnmente son llevadas a cabo por un cliente al comprar productos o servicios desde un computador personal al cual tenga acceso. La catalogación que se realiza en cuanto a relación de las partes involucradas en el negocio, (Figura 5) puede ser igualmente aplicada para los demás tipos de canales electrónicos.
Figura 5. La Adopción de una innovación basada en la Web4.
23 6.1.4. AUDIO - IVR
Es el servicio prestado por muchas entidades bancarias, que permite la realización de determinado tipo de operaciones bancarias a través de un teléfono. Los sistemas de este tipo deben suministrar de manera interactiva, información relacionada con los productos bancarios de un cliente. También, dependiendo de la entidad, se pueden llegar a tener servicios como: activación de productos (tarjetas), consultas de saldos, consultas de las últimas transacciones realizadas, cambios de clave personal, entre otros.
6.1.5. BANCA MÓVIL
24 7. MARCO TEÓRICO
7.1. ESQUEMA DE PROCESAMIENTO TRANSACCIONAL DE UN PAGO RED EFT
Luego de conocer los diferentes tipos de medios electrónicos bancarios, es necesario entender la manera en que se procesa una transacción. Cada uno de los diferentes dispositivos electrónicos que ya se revisaron, no son más que el "Front-end" de un sistema transaccional, es decir, la parte responsable de obtener los datos de entrada necesarios para la realización de cualquier operación bancaria.
Toda la infraestructura tecnológica en cuanto a hardware, software y telecomunicaciones, que se dispone para permitir el procesamiento de una transacción se denomina un red EFT (Sienkiewicz, 2002).
Dentro de las redes y sistemas EFT se encuentran establecidos los siguientes encargado de la autorización de la transacción.
Card acceptor/Merchant (Negocio): representado por un Negocio o
Comercio particular, y en general, por los dispositivos o canales electrónicos con los que cuente, para permitir la realización de una transacción por parte de un tarjetahabiente. Es el responsable de tomar la información del cliente relacionada en un medio electrónico (tarjetas), y generar el mensaje base para el procesamiento del pago.
Cardacquirer (adquiriente): es la entidad financiera que, teniendo un
25
establecer a cual emisor (cardissuer), debe enviar la transacción para su autorización.
Processor / Card associations / Payment System Operator
(Asociaciones de tarjetas): las asociaciones de tarjetas son
organizaciones encargadas de proveer una red de procesamiento de transacciones EFT, que sirve de enlace entre las entidades emisoras y adquirientes.
Las relaciones posibles entre las anteriores partes de una red EFT se muestran a continuación.
Figura 6. Roles dentro del Procesamiento de un Pago con Tarjeta5.
En ocasiones, dependiendo del flujo o camino que debe seguir una transacción, puede darse el caso de que una misma entidad bancaria tenga el rol de emisor y adquiriente, por lo que la transacción no tiene que pasar por una red de procesamiento diferente a la de la propia entidad.
7.2. ARQUITECTURA ORIENTADA A SERVICIOS (SOA)
7.2.1. ¿QUE ES SOA?
Es un estilo arquitectónico de TI que mediante la exposición e invocación de servicios, busca facilitar la interacción entre diferentes sistemas propios o de
26
terceros, donde se expone la funcionalidad de un sistema en forma de servicios. Esos servicios pueden combinarse para realizar una tarea específica, para permitir que una empresa se adapte a condiciones y requisitos cambiantes (IBM, 2015).
7.2.2. BENEFICIOS SOA
SOA es una arquitectura que permite organizar mucho mejor los sistemas IT de una compañía. Esta organización aporta ventajas muy destacables como (Alba, 2008):
Escalabilidad.
Robustez.
Homogeneidad.
Facilidad en la adaptación de nuevos servicios.
Facilidad en la reestructuración de sistemas.
Permite sustituir componentes individuales sin que eso afecte a otros
27 8. MARCO HISTÓRICO
8.1. CONTEXTO HISTÓRICO DE LA BANCA ELECTRÓNICA
El desarrollo tecnológico en el área de la informática y los sistemas computacionales, que comenzó desde mediados del siglo XX, y que aún hoy en día se está dando, ha contribuido a las entidades financieras del mundo entero a dar respuestas a la demanda de nuevos y mejores servicios bancarios, manejando un alto grado de accesibilidad, flexibilidad y disponibilidad para el cliente, y trayendo beneficios adicionales a las organizaciones como la reducción de costos, incremento de la capacidad de negocio, mejora de imagen, entre otros (Egaña & Almandoz, 1998).
La aparición de los primeros cajeros automáticos a mediados de la década del 60, (Sienkiewicz, 2002), marcó el inicio de los canales electrónicos basados en una tarjeta electrónica (como por ejemplo las terminales POS), y con él, la creación de diversos productos bancarios a nivel mundial (Flechas Villamil, 2012).
Sobre la década del 90, el creciente auge de la Internet permitió la creación de otros canales y medios de pago electrónico, con la promesa de facilidad de acceso a servicios financieros desde cualquier lugar del mundo que tuviera acceso a la red. Desde sus inicios, el rol que jugó la Internet en la evolución de la banca electrónica fue fundamental, permitiendo en principio que los clientes conocieran fácilmente información referente a sus cuentas, para posteriormente abrir las puertas a la masificación de nuevos servicios, como la banca personal, el "e-commerce" o comercio electrónico, y el dinero electrónico, sólo por nombrar algunos.
Durante lo que ha transcurrido del siglo XXI, el canal que ha mostrado un mayor crecimiento ha sido Internet, y ya que se trata de aquel que representa el mayor potencial de crecimiento (Muñoz Leiva, 2008), se pronostica que continuara de la misma manera durante los siguientes años, convirtiéndose en una importante plataforma de innovación para la banca electrónica en los años que vienen.
8.2. BANCA ELECTRÓNICA EN COLOMBIA
28
conjunto, se han encargado de superar la cantidad de operaciones que se realizan de manera presencial en las oficinas de las entidades (Superintendencia Financiera de Colombia, 2014).
En Colombia, para finales del año 2012, del total de transacciones registradas en el sistema financiero colombiano (951'699.440 operaciones), los mayores porcentajes de participación se registraron en el canal de Internet (32.28%), y en las oficinas (23.37%), sin embargo, el total de operaciones realizadas por medio de los canales de ATM y POS, en conjunto, llegan a ser superiores a lo registrado por los otros dos canales (ATM: 21.46%; POS: 11.13%; total de los dos canales: 32.58%). En relación con lo que se registra a nivel mundial, las cifras muestran que el canal electrónico de mayor crecimiento es Internet, lo cual corresponde a la tendencia de otros países. De igual manera, es notoria la pérdida de participación de las oficinas, como medio en la realización de transacciones financieras.
Tabla 1. Participación Porcentual en Operaciones financieras por Canal en Colombia6
Según se observa, existe bastante interés por parte de la mayoría de entidades, en extender la cobertura de los servicios bancarios en el país, mediante la implementación de medios electrónicos de pago
29
CAPITULO III MARCO METODOLOGÍCO
9. METODOLOGÍA USADA
Actualmente, el Banco caja social cuenta con una metodología para la ejecución de proyectos, en lo competente a los proveedores, la cual se complementa con la metodología estándar de Sophos Banking (Ver Figura 1). De acuerdo a lo anterior se identifican las siguientes fases7:
1. Levantamiento de requerimientos. El objetivo de esta fase es definir de
manera detallada la funcionalidad o los servicios que se espera que la solución de software provea, como requerimientos funcionales, no funcionales, técnicos y de requerimientos de interfaz.
2. Análisis y Diseño. De acuerdo a la información recolectada en la fase de
Levantamiento de Requerimientos, se debe definir la arquitectura, así como los diferentes elementos y las decisiones de diseño que constituyen la solución para el proyecto.
3. Construcción. En esta fase como su nombre lo indica se debe construir el
desarrollo, donde el objetivo es verificar la correcta integración y funcionalidad de los distintos sistemas y subsistemas que hacen parte del proyecto.
5. Liberación. Esta fase consiste en realizar la entrega de los diferentes
compromisos pactados con el cliente, la cual debe estar soportada por un acta, documentos referentes a la solución y fuentes. De este mismo modo se debe entregar una guía de pasos y actividades que debe realizar el funcionario el cliente que desee instalar y ejecutar el código entregado.
30
6. Soporte Pruebas de Certificación. En esta fase el área de Pruebas y
certificación del BCS, procede a ejecutar su plan de prueba, y a partir de ellas registrar y gestionar cual incidencia ocasionada durante el proceso.
7. Implementación. El objetivo de esta fase es la implantación del sistema
31
CAPITULO IV DESARROLLO DEL PROYECTO
10. DESCRIPCIÓN FUNCIONAL
10.1. ¿QUÉ ES PAGO ÚNICO?
Concepto de operación en los canales, orientado a facilitar todo tipo de pagos sean estos:
Pagos de Productos Propios del Banco (PPP).
Pago de Recaudos.
Pago Único busca hacer simple y fácil la recepción de los recaudos en los diferentes canales del banco a través de un concepto unificado de los pagos de todos los productos que requieren recaudos en el Banco Caja Social, pero garantizando al cliente recaudador las condiciones técnicas y operativas negociadas en el convenio y asegurando las condiciones de lectura (Código de Barras o Manual), validación y operación correspondientes.
10.2. ARQUITECTURA ANTES Y DESPUÉS DE PAGO ÚNICO
32
Figura 7. Comparación arquitecturas Antes y Despues de Pago Único. Autora
10.3. PAGO ÚNICO EN MULTIFUNCIONALES
Actualmente los Multifuncionales no permiten transacciones de Pagos, pero el Banco Caja Social desea implementarlas, en pro de prestar un mejor servicio al cliente y descongestionar las oficinas.
Con el mejoramiento de la arquitectura de Pagos, es necesario que cuando se implementen este tipo de transacciones en un Front end, se haga bajo el nuevo modelo arquitectura. De acuerdo a la premisa anterior la solución desarrollada se realizó bajo el nuevo esquema.
10.3.1. MERCADO OBJETIVO
El proyecto busca de manera específica atacar dos factores de mercado:
33
Pagadores de los Convenios: Aquellos que requieran realizar pagos de
recaudos, pagos de productos propios y pagos de PILA.
10.3.2. ESPECIFICACIÓN DE LAS TRANSACCIONES IMPLEMENTADAS
10.3.2.1. Tipos de Pago Social cuenta con varios tipos de Recaudos, entre los que se encuentran:
Recaudos REC: Son aquellos en los cuales no se cuenta con una Base de
Datos de la información de Facturación en el sistema del Banco.
Recaudos BCS: Son aquellos en los cuales la facturación es manejada por
el Banco por lo tanto la información se encuentra disponible en la Base de Datos del sistema del Banco.
Recaudos Redeban (RBM): Son aquellos en los cuales la facturación va
contra la Base de Datos de Redeban Multicolor, en este sentido se hace referencia al Pago de Servicios Públicos.
10.3.2.1.2. Pago de Productos Propios (PPP)
34
10.3.2.1.3. Pago de Planilla Integrada de Liquidación de Aportes (PILA)
Los Convenios de Pago de PILA, son aquellos que se prestan al sector Empresarial, en el cual se ofrece una herramienta fácil, cómoda y organizada de realizar el recaudo de los aportes de seguridad social o parafiscales.
10.3.2.2. Tipos de Lectura
En la Máquina permite dos tipos de Lectura para obtener la información de lo que se quiere pagar, estos son:
Lectura Código de Barras: Cuando el cliente tiene la Factura. El
Multifuncional lee la información del código de Barras que se encuentra dividido en indicadores descritos en la siguiente tabla:
INDICADOR DESCRIPCIÓN
(415) Identifica a la empresa generadora de la factura y el servicio
que se va a recaudar. Conocido como código EAN8.
(8020)
Identifica la referencia de pago, ésta puede ser el NIT, la cédula, el número de teléfono, el número de factura, el número del carnet del alumno, el número de la tarjeta de crédito, etc,
(3900) Identifica el Valor a pagar en moneda nacional.
(96) Identifica la fecha máxima de pago.
Tabla 2. Indicadores en un código de Barras. Autora
Por ejemplo, para el siguiente caso de un pago de una empresa de servicios públicos se tendría (GHB Talento, 2012):
Número EAN: 7709999000451
Referencia de pago: 60326234
Valor a pagar:$98765
Fecha máxima de pago: 04 de Diciembre de 2003
35
Figura 8. Ejemplo Código de Barras en Pago de Servicio Público9.
Lectura Manual: Cuando el Cliente no tiene la Factura. El Multifuncional le
muestra una lista de convenios para que elija lo que desea pagar y de acuerdo a eso habilita los campos necesarios para que la persona ingrese la o las referencias de pago y en algunos casos le permita cambiar el valor a pagar.
10.3.2.3. Medios de Pago
Pago con debito a cuenta: El cliente debe insertar la Tarjeta Débito del BCS
en el lector del multifuncional y hacer uso de la Clave de Cajero Automático. El pago se aplica por el valor exacto leído en el código de Barras o ingresado manualmente y es el reportado al pagador en el soporte de la operación.
Pago en Efectivo: El cliente inserta su dinero en efectivo al Multifuncional, con
la opción de entregar vueltas del pago en billetes y monedas con ajuste a la centena a favor del cliente, donde la diferencia entre el valor exacto y el redondeado es asumido por el Banco. El pago se aplica por el valor exacto leído o ingresado y es el reportado al pagador en el recibo soporte de la operación.
10.3.2.4. Transacciones
Luego de conocer los tipos de Pago, los tipos de Lectura y los medios de pago en la tabla a continuación se encuentran las diferentes Tipos de pago del proyecto y su especificación frente a ellos.
36
Tabla 3. Condiciones de Lectura y Medio de Pago por Tipo de Pago. Autora
De acuerdo al resumen de la Tabla 3, el Banco definió las distintas transacciones a implementar, ya que aunque para el cliente es simplemente una transacción de Pago, esta tiene implícitamente varias transacciones que para el cliente van a ser transparentes, en este sentido se tiene:
1. Transacción de Consulta de Configuración del Convenio: Esta
transacción se encarga de consultar la información del recaudo a Pagar, para que le sea mostrada al cliente en pantalla, es decir, el Nombre del convenio, nombre de las referencias. Esta transacción solo se realiza cuando la lectura se hace de forma Manual.
2. Transacción de Consulta de Valor a Pagar: Una vez se tienen los datos
de lo que se desea pagar, se procede a consultar el valor a pagar de la factura para que sea mostrado en pantalla. Para los recaudos de tipo REC, esta transacción no se realiza, ya que no se cuenta con una base de datos sobre la cual consultar el valor a pagar.
3. Transacción de Pago del Recaudo: El cliente conoce el valor a pagar y
acepta realizar el pago del mismo. Esta transacción conlleva movimientos financieros (Débitos y créditos).
37 PAGO
TRANSACCION
RECAUDOS PRODUCTOS
PROPIOS PILA
REC BCS RBM
Consulta Configuración del
Convenio X X X X N/A
Consulta de Valor a Pagar N/A X X X X
Pago del Convenio X X X X X
38 11. CONSTRUCCIÓN DE LA SOLUCIÓN
De acuerdo a lo planteado por el nuevo esquema en la Figura 7 y haciendo un acercamiento a la parte relacionada a Multifuncionales, el área de Ingeniería de Software del Banco Caja Social, definió la siguiente arquitectura para la implementación de Pagos en multifuncionales. Cabe mencionar que el banco decidió no manejar las transacciones de PILA bajo el esquema de Pago único debido a que no se acomodaba a las condiciones del modelo.
Figura 9. Arquitectura Transacción Consulta Configuración del Convenio. Autora
39
Figura 11. Arquitectura Transacción de Pago. Autora
11.1. COMPONENTES DESARROLLADOS
De acuerdo a la arquitectura planteada por el BCS para cada una de las transacciones, se desarrollaron tres componentes10 y se realizó parametrización para uno:
consuconv.
isomultifuncional.
fscopaca.
isotranv2.
Ver ANEXO A – Documentos Requerimientos Funcionales11.
10 Los Manuales de Instalación de los componentes no se pudieron anexar al libro, por restricción del Banco Caja Social.
40
11.1.1. COMPONENTE CONSUCONV
El componente consuconv se creó con el objetivo de atender la transacción de Consulta de configuración del convenio, para esto se creó el siguiente servicio.
NOMBRE DEL Tabla 5. Servicios publicados en el componente consuconv. Autora
11.1.2. COMPONENTE ISOMULTIFUNCIONAL
41
Tabla 6. Servicios publicados en el componente isomultifuncional. Autora
11.1.3. COMPONENTE FSCOPACA
El componente fscopaca se creó con el objetivo de atender las transacciones relacionadas a temas de PILA, para esto se crearon los siguientes servicios.
NOMBRE DEL
Tabla 7. Servicios publicados en el componente fscopaca. Autora
11.1.4. COMPONENTE ISOTRANV2
42
El Banco definió distintos códigos de Proceso para las transacciones, en la siguiente tabla se especifican cada uno de ellos así como el respectivo servicio que lo atiende.
TRANSACCION CODIGO DE PROCESO
Consulta Configuración de Convenio con lectura de código de Barras
321000 – Efectivo
Consulta Valor a Pagar Recaudos 340000 – Efectivo 341000 – Cuenta de Ahorros 342000 – Cuenta Corriente
Consulta Valor a Pagar PPP 3B0000 – Efectivo 3B1000 – Cuenta ahorros 3B2000 – Cuenta corriente
43 11.2. PRUEBAS UNITARIAS
Una vez desarrollados cada uno de los servicios de cada componente, se procedió a realizar las respectivas pruebas unitarias, las cuales fueron ejecutadas bajo la herramienta JTUXCLIENT la cual es una aplicación del banco que dispara transacciones a un servicio indicado. Para ver los casos de pruebas ejecutados, ver ANEXO C – Documentos Pruebas Unitarias.
11.3. RESULTADOS
Como resultado de la construcción de la solución se tiene lo siguiente:
3 Documentos de Requerimientos técnicos.
2 Manuales de Instalación.
Creación de 3 componentes.
o Publicación de 11 servicios.
1 componente parametrizado.
44 12. PRUEBAS DE INTEGRACIÓN
Una vez terminados los desarrollos con sus respectivas pruebas unitarias, el siguiente paso realizado fueron las pruebas de integración, donde el objetivo es verificar la correcta integración y funcionalidad de los distintos sistemas y subsistemas que hacen parte del proyecto, es decir, validar la funcionalidad de la arquitectura.
Ambiente: Desarrollo.
Responsable de la ejecución: Funcionario tecnología BCS
Proceso: ver Figura 12.
45 12.1. RESULTADOS
Durante las pruebas de integración se distinguieron varios tipos de incidencias, de acuerdo a la gestión que se tuvo que realizar para solucionarla.
Tipo de Solución Porcentaje (%)
Ajuste de Código 40
Ajuste de Parametrización 25
Sin acciones 35
46 13. LIBERACIÓN DE LA SOLUCIÓN
Terminadas las pruebas de Integración, la solución está lista para ser entregada y así cumplir con los diferentes compromisos pactados con el cliente.
13.1. REVISIÓN INTERNA
Sophos Banking solutions, dentro del Banco se ha caracterizado por realizar unas entregas de alta calidad, esto gracias a la revisión que se realiza a las soluciones antes de ser liberadas al Área de Certificación de calidad del Banco. Este proyecto no fue la excepción, la revisión fue realizada por dos colaboradores de sophos, donde uno de ellos se encargó de la parte funcional y técnica y el otro se encargó de revisar el correcto manejo de los entregables.
Estas revisiones fueron realizadas por cada componente, excepto para el isotranv2 ya que no tenía lógica de negocio en la solución ver ANEXO D – Lista de Chequeo Revisión Interna.
13.2. ENTREGA ÁREA DE CERTIFICACIÓN
Una vez avalada la entrega por los revisores internos de Sophos, se procede a realizar la entrega al Banco, para que sea evaluada y certificada.
Se entregó lo siguiente, para cada componente
Documentos. (Requerimientos técnicos, funcionales, manual de instalación, Pruebas unitarias)
Fuentes.
Acta de entrega. (Ver ANEXO E – Formato Acta de Entrega) Por efectos de Privacidad, únicamente se va a mostrar el formato, pero no la información contenida en ella.
47 13.3. RESULTADOS
Como resultado de la Liberación de la solución se tiene lo siguiente:
4 Paquetes de entrega, donde cada uno contiene: documentos, fuentes, 1
acta de entrega y 1 formato de check in.
Componente Paquete de Entrega
Consuconv NBM0106_CC_7959_SCash_RecaudMultiF_ConfigConv
Isomultifuncional NBM0108_CC_7959_SCash_RecaudIsomultifunc
Fscopaca NMW0123_AC_FSCOPACA_CC_7959_RecaudMultifunc
Isotranv2 NBM0113_CC_7959_RecaudMultifunc_isotranv2
48 14. SOPORTE PRUEBAS DE CERTIFICACIÓN
Una vez el software se encuentra instalado en el ambiente de calidad, Esta área asigna una serie de colaboradores del Banco para que se encarguen de probar todos los escenarios posibles para garantizar el correcto funcionamiento de la solución en ambiente de producción. El BCS utiliza una herramienta MANTIS, como gestor de incidencias, para ver el esquema de uno de los casos mantis reportados, ver ANEXO F – Casos Mantis
Ambiente: Certificación y calidad. (Se trata de un ambiente lo más parecido posible a producción)
Responsable de la ejecución: Funcionarios área calidad BCS
49
Figura 13. Proceso Soporte Pruebas de Certificación. Autora
14.1. RESULTADOS
50
Tipo de Solución Tipo de Prioridad Porcentaje (%)
Ajuste en código A 16,7
B 16,7
Ajuste de Parametrización A 10
B 16,7
Sin acciones A 23,3
B 16,7
Tabla 11. Especificación Porcentual de soporte pruebas de certificación. Autora
51
CAPITULO V CLAUSURA DEL PROYECTO
15. CONCLUSIONES
En el entorno de canales electrónicos, es una buena práctica primero
identificar las transacciones involucradas y a partir de ahí definir servicios y no cargar un solo servicio a que atienda varios tipos de transacciones, ya que esto en la mayoría de los casos hace que el código sea difícil de leer para alguien que no lo haya desarrollado y además genera más impactos a la hora de realizar cambios funcionales. Para el proyecto fue bueno el diseño por parte del Banco ya que separaron las transacciones en distintos componentes lo que hace que se tenga un mayor orden.
El proyecto comenzó en la fase de Desarrollo, y en este aspecto se tuvo un
poco de dificultad, ya que funcionalmente no se conocía mucho del proyecto. En este sentido es mejor primero entender funcionalmente el proyecto antes de arrancar los desarrollos, ya que con este conocimiento se puede estructurar mejor la forma en que se va a desarrollar y tener un código más ordenado.
Muchas veces las pruebas unitarias se enfocan a satisfacer casos de
pruebas positivos y no se tiene en tanta consideración los casos negativos, es importante en este tipo de pruebas si el cronograma o permite, dedicar tiempo a realizarlas, pensando no tanto en los requerimientos del cliente sino pensando como un usuario potencial de la solución, esto lleva a encontrar casos de prueba fuera de lo convencional.
La calidad de la información es uno de los principales puntos de conflicto en
las pruebas unitarias, ya que son ejecutadas en un ambiente de desarrollo, donde muchas personas tiene acceso a la Base de datos y manipulan los datos para poder simular casos de prueba.
52
Las revisiones internas son un gran filtro de incidencias y hacen que se ahorre tiempo y desgaste en solucionar incidencias en las pruebas de certificación. Son una buena práctica para entregar una solución con un mínimo de errores y trae grandes beneficios, no solo para la persona que va a realizar la entrega, sino también para los revisores, ya que estos aprenden nuevos temas funcionales y en caso que el desarrollador no este, podrían brindarle soporte a la solución.
53 16. LÍNEAS DE TRABAJO FUTURAS.
A partir de lo mostrado en la Figura 7, se observa que el canal de Cajeros
Electrónicos actualmente no se encuentra funcionando bajo el esquema de Pago Único, por lo tanto se podría estudiar la viabilidad de que las transacciones de Pago en este canal sean implementadas bajo el modelo.
El Banco siempre se encuentra en búsqueda de nuevas oportunidades de
negocio, la existencia del modelo de Pago Único facilita la inclusión de nuevos canales como corresponsales Bancarios. Actualmente solo se tiene un convenio con Movilred, pero se planea ampliar esta línea con nuevas empresas como Carvajal y posiblemente tener unos corresponsales bancarios propios.
Dentro del proyecto realizado las únicas formas de pago permitidas por el
54 17. BIBLIOGRAFÍA
Alba, J. (Enero de 2008). ResarchGate. Obtenido de
http://www.researchgate.net/publication/28208202_SOA_Arquitectura_Orientada_ al_Servicio
Banco Caja Social. (s.f.). Banco Caja Social. Obtenido de https://www.bancocajasocial.com/nosotros
Banco Caja Social. (s.f.). Banco Caja Social. Obtenido de
https://www.bancocajasocial.com/listado-de-cajeros-multifuncional-amigo
Egaña, J., & Almandoz, A. (1998). educastur. Obtenido de
http://www.educastur.princast.es/fp/hola/hola_bus/cursos/curso2/documentos/1418 7195.pdf
Flechas Villamil, J. C. (07 de Julio de 2012). Portal Red ICI de Asociación Inteligencia Colectiva Iberoamericana. Obtenido de http://redici.org/podcast/136-edicion059
GHB Talento. (Noviembre de 2012). GHB Talento. Obtenido de
https://ghbtalento.files.wordpress.com/2012/11/ghb-codbar-300905.pdf
IBM. (2015). IBM. Obtenido de
https://www.ibm.com/developerworks/ssa/webservices/newto/
Muñoz Leiva, F. (2008). La adopción de una innovación basada en la Web. Editorial de la Universidad de Granada.
Radu, C. (2003). Implementing Electronic Card Payment Systems. Boston: Artech House.
Rouse, M. (2006). TechTarget. Obtenido de
http://searchwinit.techtarget.com/definition/Electronic-Funds-Transfer
Sienkiewicz, S. (2002). Philadelphiafed. Obtenido de
http://www.philadelphiafed.org/consumer-credit-and-payments/payment-cards-center/publications/discussion-papers/2002/EFTNetworks_042002.pdf
Sophos Banking Solutions SAS. (2015). Sophos Banking. Obtenido de http://www.sophosbanking.com/
Superintendencia Financiera de Colombia. (Agosto de 2014). Superintendencia Financiera de Colombia. Obtenido de
55
56
CAPITULO VI ANEXOS
57
58
59
60
