Aplicación de acceso remoto a la información en función de la gestión financiera de la Empresa

Aplicación de acceso remoto a la información en función de la gestión financiera de la Empresa Remot Access System to information for the financial managment of Enterprise Autora: Lic. Dialys Nerely Pérez de Armas Institución: Fintur S.A Sucursal Villa Clara Dirección: Cólon #619 e/ Barcelona y Alejandro Oms, Santa Clara, Villa Clara Teléfonos: 208288, 273417(particular) Correo electrónico: dialys@fintstc.fintur.tur.cu

RESUMEN: FINTUR es la institución financiera no bancaria que pertenece al Ministerio del Turismo y cuenta con 20 sucursales a lo largo de todo el país. Cada sucursal funciona como un banco de las entidades turísticas del territorio. Cada entidad que pertenece a Fintur se denomina cliente y posee una o más cuentas bancarias en diferentes monedas. La problemática que nos planteamos resolver tiene en cuenta tanto las necesidades de los clientes de Fintur como las de la Gerencia de la sucursal. Los clientes tienen la necesidad de mantenerse actualizados sobre los saldos de sus cuentas bancarias y de sus estados de cuenta. En el caso de la Gerencia, la necesidad radica en mantener informado al gerente sobre los movimientos de las cuentas de los clientes con vistas a conformar el flujo de caja y ver su variación a través del tiempo. Ante esta situación, proponemos una aplicación para el acceso remoto que brinde determinados servicios en línea a los clientes: obtener los saldos de sus cuentas bancarias, obtener estados de cuenta y flujos de caja. Este sistema también brinda la posibilidad de que la gerencia acceda a él y pueda consultar los datos financieros de los clientes desde diferentes pespectivas. Para ello se construyó un datawarehouse o almacén de datos en SQL Server 2000 que se actualiza mediante paquetes de transformación de datos que traen la información del SABIC, el sistema operacional que se utiliza en Fintur. Se construyó un sistema de cubos OLAP para mostrar la información multidimensionalmente y de esta forma, el Gerente cuenta con una poderosa herramienta de análisis. Para hacer uso del almacén, se diseñó una Aplicación cliente de usuario final basada en la tecnología WEB y que usa ASP para acceder a la Base de Datos del almacén. Tiene 3 módulos a los cuales se accede en dependencia del usuario que se conecte: cliente, gerente o administrador. Se establecen dos tipos de conexión: remota para los clientes de Fintur y a través de la red local para el gerente de la sucursal y el administrador del sistema. El trabajo reporta los siguientes beneficios: Mayor eficiencia en el manejo de la información por parte de los clientes de Fintur. Mayor agilidad en los análisis de la Gerencia. Ahorro de recursos materiales y humanos. Mejora de la imagen corporativa de Fintur. PALABRAS CLAVES: Sistema fuente, Almacén de datos, Datawarehouse, Modelo dimensional, esquema estrella, aplicación Web, OLAP 2

INTRODUCCIÓN A fines de 1994 se creó FINTUR, una institución financiera no bancaria que pertenece al Ministerio del Turismo y cuenta con 20 sucursales a lo largo de todo el país. FINTUR centraliza las cuentas bancarias en divisas de casi todas las entidades del sector turístico, sus instalaciones y dependencias y opera con sus saldos disponibles. Un papel importante y estratégico que esta institución desempeña es su actuación como agente recaudador del Estado, en relación con el aporte de determinados compromisos de las entidades turísticas con este; concentra y maneja los recursos financieros temporalmente libres, que genera el turismo, en vías de garantizar el funcionamiento y contribuir así al desarrollo de este sector. Cada sucursal funciona como un banco de las entidades turísticas del territorio. Cada entidad que pertenece a Fintur se denomina cliente y posee una o más cuentas bancarias en diferentes monedas. FINTUR S.A Sucursal Villa Clara, forma parte de la red de sucursales que mantiene la casa matriz para la ejecución de su objeto social. Esta sucursal cuenta con 36 clientes hasta el momento, los que ejecutan sus operaciones mercantiles y financieras partiendo de los saldos disponibles en sus cuentas bancarias. Los clientes tienen la necesidad de mantenerse constantemente actualizados sobre los saldos de sus cuentas bancarias y de sus estados de cuenta, lo cual ellos realizan actualmente mediante visitas frecuentes a la sucursal o llamadas continuas por teléfono. Esto trae como consecuencia pérdida de tiempo y demora en la ejecución de operaciones financieras. Por otra parte, la necesidad inmediata de la Gerencia radica en mantenerse informada sobre los movimientos de las cuentas de los clientes con vistas a conformar el flujo de caja consolidado de las instalaciones, hacerlo de forma dinámica y ver su variación en el tiempo. Esto es importante para la gerencia pues a partir de esta información se confeccionan las evaluaciones para la línea de crédito revolvente para compras mayoristas y los informes estadísticos a las instancias superiores. En Fintur hay un sistema implantado desde el año 1998, denominado SABIC (Sistema Automatizado para la Banca Internacional de Comercio) que se utiliza para registrar las operaciones de los clientes. Este sistema tiene como plataforma FoxPRO sobre DOS corriendo en un servidor NOVELL 3.12 por lo que no está preparado para dar respuesta a la problemática que se plantea pues no permite conexiones remotas. Por otra parte, para los requerimientos de la Gerencia, el SABIC no cuenta con reportes de salida dinámicos y no es posible crearlos por la plataforma donde corre. El sistema SABIC tiene la información que nos hace falta para dar solución a nuestro problema. Pero esto no basta, pues el sistema no esta preparado para dar acceso remoto a los usuarios, además de que no es conveniente por problemas de seguridad 3

del sistema. Por otro lado no es compatible con Windows que es el sistema operativo que tienen instalado todos nuestros clientes. Por otra parte, la Gerencia necesita consultar los datos de una forma analítica teniendo en cuenta el comportamiento de años anteriores y esta posibilidad no la da el Sabic pues como sistema operacional (OLTP) organiza sus bases de datos encaminadas al procesamiento transaccional y no al analítico. Generalmente, los sistemas transaccionales o OLTP usan estructuras normalizadas, en las cuales se optimizan las inserciones y actualizaciones de artículos e incluso algunas selecciones, pero es menos probable que el sistema se organice de forma tal que produzca reportes eficientes para datos resumidos con cierta jerarquía. Ante esta situación, proponemos como objetivo del trabajo la creación de un sistema que brinde las facilidades para el acceso remoto de los clientes de Fintur y determinados servicios en línea como son: obtención de los saldos de sus cuentas bancarias, emisión de estados de cuenta y flujo de caja y además que brinde la posibilidad a la Gerencia de consultar analíticamente la información financiera de sus clientes. DESARROLLO Para dar solución al objetivo planteado, concebimos un sistema que consta de tres componentes y se muestra en el Anexo # 1. Las componentes son: El sistema fuente SABIC Un Almacén de datos o Datawarehouse : que se actualiza con los datos del SABIC y se utiliza para la recuperación de la información. Una aplicación de usuario final : que permita a los clientes y al gerente conectarse ya sea de forma remota o local y consultar los datos del Datawarehouse. Estos componentes se explican a continuación. Sistema Fuente SABIC Actualmente, toda la información que se registra en Fintur de las cuentas de los clientes se procesa en el sistema contable financiero SABIC. Este sistema está implantado en Fintur desde octubre del año 1998. Está programado en FOXPROX 5.2 para DOS y corre sobre un servidor dedicado con la versión de Novell Netware 3.12. Cada especialista trabaja en red y accede de forma compartida al SABIC. A pesar de ser un sistema ya antiguo que no es compatible con Windows, cumple con los requerimientos de Fintur como Casa Financiera, permite ejecutar las operaciones 4

financieras de las entidades turísticas, hacer los cierres diarios y llevar toda la contabilidad de la sucursal. Como vemos este Sistema es muy amplio pero solo nos interesa abordar en este trabajo las operaciones que involucran las cuentas bancarias de los clientes. Las cuentas de los clientes están compuestas por 14 dígitos. El esquema que tiene la cuenta es el siguiente: Por ejemplo : USD 3210 1 1518 60 Moneda Cuenta Subcuenta Desglose de la cuenta Código de Contraparte Tipo de Contraparte Moneda : Esta compuesta por tres letras que especifica el tipo de moneda. Por ejemplo : USD ( Dólar estadounidense), CUC ( Peso convertible), CUP (Peso Cubano), etc. Cuenta Subcuenta : La conforman 4 dígitos. Especifica el tipo de cuenta de que se trata, en particular, las cuentas de clientes comienzan siempre por 32 y se clasifican como : 3210 cuenta de operaciones (la más usada) 3220 cuenta de fondos colaterales 3230 cuenta de inversiones 3240 cuenta de fondo de mantenimiento 3250 cuenta especial de financiamiento interno Tipo de contraparte : Es un dígito que refleja qué tipo de cuenta es : 1- Cliente 2- Banco 3- Concepto Ingreso/Gasto 4- Medio Básico 5- Suministrador Para las cuentas que estamos tratando siempre es 1 porque corresponde a cuentas de clientes. Código de Contraparte : Está formado por 4 dígitos que reflejan el código del cliente, del banco, del suministrador u otros conceptos en dependencia del dígito anterior (tipo de contraparte). Estos códigos tienen sus descripciones en ficheros clasificadores: C_Client, C_Sumini, C_Bancos, C_Otrcon y C_Concept. Desglose de la cuenta : Está formado por dos dígitos que se utilizan para diferenciar varias cuentas de un mismo cliente. Las transacciones en el Sabic están formadas por dos o más asientos contables, donde la suma de los débitos y los créditos es igual a cero. Cada asiento tiene una referencia corriente que lo identifica unívocamente. La referencia corriente tiene 8 caracteres. El primer carácter es una letra que representa el tipo de transacción, el segundo caracter 5

representa el último dígito del año y el resto de los 6 caracteres que le siguen conforman un número consecutivo que lo da el sistema. El Sabic tiene 3 ficheros básicos : M_Histor : registra la historia de todos los asientos contables que se van procesando. M_Diario : registra aquellos asientos que quedaron pendientes en cartera para ser utilizados en un futuro, cuando se cumpla su fecha de vencimiento M_Mayor : registra de cada cuenta el saldo confirmado y el saldo contable actual. Entiéndase por saldo confirmado la suma de todas las transacciones asociadas a esa cuenta con fecha valor menor o igual al día actual. El saldo contable es igual al saldo confirmado más los asientos pendientes en el fichero M_Diario con fecha valor futura Al cierre del día se guardan los saldos de todas las cuentas que están en el fichero Mayor y ese fichero tiene un número consecutivo que es identificado por el sistema. Por lo que es posible recuperar el saldo que tuvo una cuenta determinada un día específico. El Almacén de Datos Por los requerimientos de nuestro problema, nos dimos a la tarea de crear un Almacén de datos o Datawarehouse (DWH). Para aquellos que desarrollan y mantienen los sistemas de datos haciéndolos disponibles para los directivos de las empresas, el término DataWareHouse ofrece la solución como ubicación central para que se pueda acceder a la información de forma analítica y ver y comparar su variación en el tiempo. El Almacén de Datos usa los datos relevantes de las fuentes existentes y los combina en una estructura que es óptima para realizar selecciones. El DWH tiene cuatro características primarias. Es una colección de datos orientada a un tema, integrada, variable en el tiempo y no volátil, útil para la toma de decisiones. Es orientada a un tema porque tiene en cuenta los procesos de negocio de una empresa que se deseen priorizar. Es integrado porque agrupa a todos los sistemas operacionales en un sistema de información que se generan en el proceso de negocio proveyéndolos de formatos y códigos consistentes. Es variante en el tiempo porque los datos se organizan y almacenan en jerarquías en el tiempo, lo que permiten análisis comparativos de estados actuales y de períodos anteriores. Es no volátil porque se usa principalmente para operaciones de carga y recuperación de información y no para actualizaciones. 6

El Almacén de Datos hace consultable la información que se tiene de una empresa tanto de meses como de años anteriores. Permite obtener una mayor velocidad de respuesta al procesamiento de análisis. Con la creación de un Almacén de Datos se persigue un sistema de fácil comprensión y de rápida ejecución, información consistente y datos de alta calidad, con diseño que permita los cambios y además, una salvaguarda segura para proteger nuestra información. El diseño de un Almacén de Datos se hace basado en el modelo dimensional que divide el mundo de los datos en dos grandes tipos: las medidas y las descripciones del entorno de estas medidas. Las medidas, que generalmente son numéricas, se almacenan en las tablas de hechos y las descripciones de los entornos que son textuales se almacenan en las tablas de dimensiones. Las tablas de hechos son las tablas primarias en el modelo dimensional y contiene los valores del negocio. Las tablas de dimensiones son las compañeras de las tablas de hechos. Cada dimensión se define por su llave primaria que sirve para mantener la integridad referencial en la tabla de hechos a la que se acopla. Los atributos de estas tablas sirven de base a las solicitudes que se hacen al almacén de datos. Diseñamos nuestro almacén partiendo del modelo dimensional basado en el esquema de estrella, el cual se muestra en el Anexo # 2. Para conformar la tabla de hechos tuvimos en cuenta el hecho principal de nuestro problema que es: una operación financiera, la cual se mide por el importe de la operación. En la operación intervienen además la cuenta del cliente que hizo la operación, el indicador financiero por el que se hizo y la fecha. Estos datos y algunos más los podemos captar de la tabla M_Histor del sistema SABIC. La cuenta del cliente nos dice la siguiente información : la moneda, el tipo de cuenta, el desglose y el cliente que hizo la operación y basado en esto conformamos las tablas de dimensiones, las cuales en algunos casos partieron de los clasificadores del SABIC. El software que utilizamos para crear nuestro almacén de datos fue el SQL Server 2000 por la seguridad que brinda como servidor de presentación de los datos y por la posibilidad de dar permisos a los usuarios sobre las bases de datos. Fue necesario crear una conexión ODBC para acceder a las bases de datos del SABIC y poner en función un grupo de servicios de transformación de datos (DTS), encargados de extraer la información del SABIC, depurarla y transformar esos datos para actualizar las tablas de hechos y de dimensiones. Estos servicios fueron agrupados en 4 grandes grupos que a su vez hacen uso de otros DTS. Ellos son: Clasificadores : es el servicio encargado de alimentar las tablas de dimensiones. 7

Instalador : se utiliza para la carga inicial del almacén de datos. Incluye otros DTS. Cierre del día : se ejecuta con una frecuencia diaria a una hora determinada después del cierre del día que se efectúa en el sistema SABIC. Contempla varios servicios de transformación de datos para completar el proceso de actualización diaria de las tablas del almacén. Obtención de los saldos del día: se ejecuta cada una hora para obtener los saldos actualizados de las cuentas de los clientes. Para publicar los datos del almacén con los requerimientos que exigía la Gerencia, fue necesario usar una herramienta superior de análisis. Estas herramientas son conocidas como cubos OLAP Procesamiento Analítico en línea y están disponibles en el Analizador como parte del paquete de SQL SERVER 2000. Los cubos OLAP permiten ver la información de forma multidimensional. Esto permite variar y alternar las dimensiones como se desee. Es de mucha utilidad para la Gerencia pues de aquí puede sacar un consolidado de toda la información de los clientes, pues esta tabla permite hacer no solo el análisis de los datos a través del tiempo ya sea enmarcada en años, trimestres, meses o días, sino además analizar los datos desde diferentes perspectivas, como pueden ser clientes, cadenas turísticas, etc. Para los clientes también resulta de utilidad pues pueden acceder a su información específicamente y comparar con períodos anteriores. Esta facilidad se consigue a través de funciones parametrizadas que extraen solo la información del cubo perteneciente al cliente conectado. Para acceder al Almacén de datos y poder consultar la información se implementan las herramientas de acceso de datos del usuario final. Estas herramientas constituyen el cliente del Almacén de Datos que mantiene una interacción con el servidor enviando a éste solicitudes SQL y éste devuelve los resultados ya sea en pantalla, un reporte, un gráfico o en alguna otra forma superior de análisis para el usuario. Estas herramientas pueden ser tan simples como las consultas ad-hoc o tan complejas como la minería de datos. En general, los usuarios prefieren usar las aplicaciones. Aplicación de usuario final Como tercer componente del sistema se implementó una aplicación Web la cual permite a los clientes conectarse al sistema y solicitar los servicios programados. La tecnología usada para desarrollar esta aplicación es HTML dinámico, facilitando de esta forma que el usuario externo a Fintur se conecte sin tener que instalar ningún software previamente. Para el acceso a la base de datos se usa ADO usando llamadas a procedimientos almacenados en el servidor. Esto se programó en ASP con VBScript partiendo de una conexión OLE DB al almacén de datos. La conexión a la aplicación puede ser de dos formas: remota o local. 8

Conexión remota : para los clientes de Fintur, accediendo vía MODEM a una dirección IP. Conexión a través de la red local : para el gerente de la sucursal y el administrador del sistema, a través de la red local de Fintur. La página inicial de la aplicación tiene en la parte superior un banner que agrupa los logos de las entidades más representativas del Ministerio del Turismo. Los banners se muestran de modo rotativo y en el medio dos entradas para poner clave de usuario y contraseña. La aplicación tiene 3 tipos de usuarios posibles: los clientes de Fintur el Gerente de la sucursal el administrador del sistema Para cada tipo de usuario se diseñó un módulo con los servicios que este puede solicitar. Para los clientes de Fintur las opciones del sistema son: Obtención de los saldos de sus cuentas bancarias Emisión de los estados de cuenta Emisión del flujo de caja Cambio de clave de usuario Para el Gerente de la sucursal, el sistema ofrece lo siguiente: Consolidado de los flujos de caja de los clientes Consolidado de los saldos de los clientes Emisión de estados de cuenta de clientes Cambio de clave de usuario El administrador del sistema tiene las siguientes facilidades: Añadir un nuevo usuario Eliminar un usuario Mostrar todos los usuarios Insertar un código de cliente Eliminar un código de cliente Cambio de clave CONCLUSIONES 1. La propuesta de nuestro trabajo consiste en la creación de un sistema que tiene como componentes: un Sistema fuente que es el Sabic, un Almacén de Datos que funciona como Servidor permitiendo hacer consultable la información de Fintur que está registrada en el Sabic y una aplicación cliente que consulta el almacén y facilita el acceso remoto a los usuarios para conocer sus saldos en cuenta y el estado financiero de las mismas. 9

2. Las ventajas que tiene el sistema propuesto para la Gerencia radican en que ya cuenta con una poderosa herramienta de análisis de la información de forma multidimensional con el objetivo de hacer análisis eficientes y ver su variación en el tiempo. 3. Para los clientes de Fintur este sistema representa un grupo de beneficios tales como: ahorro de tiempo y recursos materiales y rapidez en la ejecución de operaciones financieras. 4. Este sistema garantiza una mejora de la imagen corporativa de Fintur ante sus clientes. REFERENCIAS BIBLIOGRÁFICAS [1] Kimball R., Laura Reeves, Margy Ross & Warren Thornthwaite, The Data Warehouse Life Cycle Toolkit, New York : John Wiley & Sons, 1998. [2] Servicios de Información Tecnológica de la Universidad de Indiana : http://www.indiana.edu/~dss/services/datawarehouse, 2001. [3] Kimball R., Build your DataWarehouse one piece at a time, Datawarehouse Designer, Octubre 2002. Extraido el 4 de marzo del 2003 de http://www.iemagazine.com/021030 [4] Haisten M., The Real-Time Data Warehouse: The Next Stage in Data Warehouse Evolution, 2003. Extraido el 12 de septiembre de 2003 de http://www.damanconsulting.com/company/articles [5] Architectural Evolution in Data Warehousing, White Paper No. 11, Julio 1998. Extraido el 14 de diciembre de 2003 de www.dkms.com/white_papers.htm. [6] Eden T. & Hartman P., Active Server Pages in Plain English, Foster City, CA: IDG Books Worldwide, 2001. [7] Sáez Concepción, Y. y Carrasco Fuentes, Hailem D., Trabajo de Diploma Quipus Shop: Aplicación de gestión de ventas de productos y servicios usando tecnologías de redes, 2002. 10

Anexo 1. Sistema propuesto Cliente n... Foxpro sobre Novell Servidor SQL- Server HTML y ASP con VBScript Cliente 2 Cliente 1 Manejo SQL SABIC DTS Extraer Poblar ALMACÉN DE DATOS Publicación datos Aplicación Usuario Final Gerente Sucursal DTS Administrador sistema Servicios de datos Herramienta Análisis OLAP Conexión por red local Conexión remota 11

ANEXO # 2 ALMACEN DE DATOS ESQUEMA DE ESTRELLA MODELO DIMENSIONAL Dimensión CUENTA - id_cuenta - nombre cuenta Dimensión CLIENTE -id_cliente -nombre cliente -cadena que pertenece Tabla Hechos - OPERACION -id_moneda -id_cuenta -id_cliente -id_desglose -id_asiento -id_fecha -Importe operación ($) Dimensión MONEDA - id_moneda - nombre moneda Dimensión TIEMPO -id_fecha - día - mes -trimestre -año Dimensión DESGLOSE Dimensión INDICADOR -id desglose -nombre desglose -id_asiento -nombre asiento (indicador) 12