 |
|
 |
| Arquitectura | |
|
| Arquitectura Tecnológica | |
El Sistema Bantotal, como sus módulos complementarios
puede ejecutar en las siguientes arquitecturas:
El Sistema Bantotal, además, cuenta con versiones instaladas en modalidad:
|
Java
o .Net, utilizando una interfase gráfica bajo browser (Microsoft
Internet Explorer)| Arquitectura Aplicativa | ||||
| Bantotal es una aplicación estructurada lógicamente
en capas, orientada a componentes y explotando la re-usabilidad de los mismos. La construcción de un sub-sistema en particular se logra mediante la interacción de los componentes, mediante un procedimiento similar al armado de un “lego”. A continuación, se representa en forma gráfica la construcción de un Sistema de Préstamos.  Recursos Genéricos de la Aplicación Los recursos genéricos de la aplicación son módulos que son compartidos por todos los sub-sistemas. Entre ellos, podemos encontrar las funciones principales del Sistema tales como:
Estos recursos genéricos de la aplicación proveen tanto funciones para la registración de datos así como para su procesamiento. Por ejemplo, el Sistema Contable permite al usuario definir el Plan de Cuentas a utilizar así como los esquemas contables para cada una de las transacciones. Del mismo modo, provee el programa contabilizador (dado un asiento, imputa el mismo en las cuentas contables) y las salidas genéricas tales como balances, mayores e inventarios. Procesos Genéricos Los Procesos Genéricos son programas (consultas interactivas, reportes, programas batch) que proveen el tratamiento de datos para varios de los sub-sistemas que conforman Bantotal. Ejemplos:
En base a los principios de diseño de la aplicación, las mismas estructuras de datos son las utilizadas para almacenar la información de operaciones de diferente naturaleza. Por tanto, también se utilizan los mismos programas para recuperar la información de ellas. Es así que el programa de consulta de un contrato de Depósito a Plazo Fijo es el mismo que se utiliza para consultar los datos de un Préstamo. El mismo concepto aplica para programas que realizan funciones no relacionadas a un producto en particular. Así por ejemplo, el devengamiento de los intereses de una operación a plazo es uno sólo. El programa sólo debe saber reconocer que es una operación financiera y cual no lo es, sin tomar en consideración si es de naturaleza activa o pasiva. Procesos y Funciones Específicas Los Procesos y Funciones específicas son programas (consultas interactivas, reportes, programas batch) que proveen soporte para contratos u operaciones de determinada naturaleza concreta. Por ejemplo:
Estas funciones son notorias que están relacionadas solamente al Sistema de Préstamos. No son utilizadas por el Sistema de Depósitos a Plazo. Así también, la administración de chequeras es una función que solamente está relacionada al módulo de Cuentas Corrientes. El programa que renueva o procesa todo tipo de instrucción dada por el Cliente para su Depósito a Plazo (renovar, acreditar en cuenta, acreditar sólo intereses renovando capital) sólo aplica al Sistema de Depósitos a Plazo. Instancias del Meta-Modelo Transaccional A efectos de obtener el soporte funcional completo a determinada operativa bancaria, los eventos de un proceso de negocio pueden ser parametrizados como instancias (transacciones diferentes) del Meta-Modelo Transaccional brindado por el Sistema. Un Analista de Negocio, seleccionando los parámetros adecuados, puede definir las diferentes transacciones necesarias para administrar el producto o servicio bancario. Por ejemplo, en el Sistema de Préstamos, pueden definirse transacciones para:
Subir 
|
| Arquitectura Funcional | |||||
Todos los módulos comparten la misma estructura
de procesamiento, por lo que la cobertura funcional de los mismos (salvo por
las particularidades propias de cada Producto/Servicio) son las mismas. Atención al Cliente Cualquier módulo puede acceder a la Posición Integral de Cliente a efectos de conocer Productos/Servicios que utiliza, saldos, términos y condiciones (precios particulares), Límites (otorgados, utilizados, disponibles), Garantías, entre otros. Asimismo, para los productos financieros se incluyen facilidades de Simulación para operaciones nuevas como existentes. Se dispone a este nivel de la definición de los Productos o Paquetes de Productos (productos “combo”) que constituyen la oferta de Productos financieros de la Institución Financiera. Para un producto determinado, un conjunto de definiciones pueden estar preestablecidas (“preseteo”) tales como:
entre otros. Flujo de Trabajo El manejo de las operaciones, desde su solicitud hasta su liquidación se puede establecer en forma paramétrica mediante una herramienta de diseño de procesos integrada a Bantotal (GXflow  ). La misma trabaja básicamente
sobre “estados”. Los cambios de “estado” funcionan como
condiciones de salida de un proceso y la condición de “entrada”
de otro. Los roles que ejecutan pasos de un proceso, reciben sus tareas a través
de una “bandeja” (input basket), que filtra por estado, y a cual
se le asocian las transacciones posibles de ser ejecutadas (las que a su vez
implican cambios a nuevos estados).Transacción Un paso de un proceso puede tener asociado una o más transacciones para ser ejecutadas. Estas transacciones, invocarán al monitor transaccional bancario provisto con Bantotal a efectos que el mismo ejecute la definición subyacente de la transacción. En su ejecución, el sistema puede “trasladar” la información capturada a nivel del flujo y solicitar nuevos datos adicionales. La ejecución de una transacción monetaria conllevará la contabilidad en tiempo real de la misma (con control de cuadre del asiento contable o apunte en todas las monedas involucradas), y en caso de producirse una excepción, dispara el mecanismo de autorización de la misma (por ejemplo, autorizaciones por sobregiro, cambio en las condiciones de oferta estándar del Producto/Servicio, fecha valor, importes por encima de límites establecidos, etc.). La lógica de ejecución de las transacciones (y los programas subyacentes) es la misma (mismo código) tanto para su ejecución interactiva como batch. Documentación y Mensajería Las transacciones asimismo pueden ejecutar servicios de documentación y mensajería asociados a la misma tales como:
A estos efectos, el sistema provee de herramientas paramétricas que permiten diseñar el “overlay” de impresión (incluyendo textos fijos y atributos del Sistema), proveyendo asimismo rutinas de fechas e importes escritos tanto en español como en inglés. El editor de “overlays” para las intervenciones y tickets es propio, mientras que para los documentos de alta calidad se utiliza MS-Word, con todas las facilidades de edición del mismo (tipos de letra, recuadros, sombreados, bitmaps, etc.). Para todas las facilidades de impresión, se cuenta con soporte de re-impresión de las mismas. En relación a Mensajería, se cuenta con soporte a SWIFT, que incluye:
Contabilidad Toda la contabilidad es actualizada en tiempo real por las transacciones monetarias (o las no monetarias que lo requieran en cuentas extra-contables), realizando en forma automática todas las reclasificaciones de cuentas contables que sean necesarias según los requerimientos establecidos por los organismos reguladores y con transparencia al usuario final (sector, moneda, plazo, tipo de instrumento, residencia, tipo de institución financiera). Asimismo, la función contable implementa todos los procesos relacionados a los elementos transados subyacentes en cada operación tales como:
así como también los relaciones a los principios de contabildad generalmente aceptados tales como:
entre otros. La definición del Plan de Cuentas y esquemas contables asociados a cada transacción es paramétrica, y se permite manejar tablas de equivalencia entre el Plan de Cuentas local y el requerido por una Casa Matriz a efectos de la generación de reportes para esta, si fuese necesario. En este sentido, además, el sistema almacena los equivalentes de saldos según el tipo de cambio histórico (FASB52), por lo general, del dólar de los Estados Unidos de Norteamérica. La contabilidad provee de las salidas de información (por pantalla/impresas) típicas tales como: Balances (por empresa, sucursal, moneda, diferentes tipos de presentación; sobre los saldos on-line, a una fecha, al cierre de un mes), Inventarios, Mayores, Diarios, Listados de Vencimientos. Dada la arquitectura del Sistema (contabilidad integrada y embebida), no es necesario la utilización de cuentas “puente” o “transitorias” a efectos de integrar contablemente los sistemas, y por tanto, se elimina el control sobre ellas. Asimismo, y dado el control en el punto de entrada (transacción) del cumplimiento de la partida doble del asiento (entrada o apunte contable) no es factible encontrarse con problemas de contabilidad “no-balanceada”, a no ser que se encuentre un error de programa. Asimismo, y dado que la imputación del asiento contable es parte del ciclo de compromiso de una transacción, no es posible encontrar situaciones donde la cartera de un determinado producto presente un total diferente al que se expone en la contabilidad para el mismo. Información a Organismos Reguladores Como resultado de la contabilidad y de información provista de los productos, Bantotal automatiza la información a remitir a los Organismos de Supervisión de la actividad Bancaria en cada país donde se instale. Por tanto, todos los Productos/Servicios capturan y proveen la información suficiente y necesaria para cumplimentar con estos requisitos. Todas las facilidades explicadas anteriormente son paramétricas (productos, precios, procesos, transacciones, documentos, comunicaciones, contabilidad, informaciones) por lo que no se incluyen datos en el código fuente. Finalmente, y cómo lo muestra el gráfico incluido anteriormente, la lógica (y las herramientas que las implementan) es la misma para el conjunto de los módulos que componen la aplicación (de los cuales se detallan parte de ellos en dicho gráfico y a manera de ejemplo).  Subir
|
| Arquitectura de Integración Modular | ||
La concepción y diseño del Sistema,
establecen una integración total entre las diferentes funcionalidades
que lo componen. En este sentido:
Subir
|
| Arquitectura de Datos | |
Toda la información del Sistema es almacenada
en la base de datos relacional (desde la información de los productos,
clientes, procesos, requerimientos de impresión, comunicaciones, etc.).
Por las propias características de GeneXus y de diseño de la aplicación,
las tablas se normalizan a tercera forma normal, existiendo redundancias a efectos
de mejorar la performance de determinados procesos (por ejemplo, se genera un
archivo de apoyo para emitir las informaciones a los Organismos Reguladores,
recolectando información de los diferentes módulos que componen
el Sistema). Ante modificaciones de la base de datos, una de las virtudes de
GeneXus es construir automáticamente los programas de migración
de datos de las estructuras anteriores a las nuevas (incluso si fueron re-normalizadas),
facilitando el proceso de incrementalidad de la aplicación. Se asegura
además el manejo integro de los datos:
Utilizando las facilidades provistas por los gestores de base de datos, se mantienen los “journals” o “logs” de modificaciones realizadas sobre las entidades del Sistema, contándose con la imagen del registro previo a la modificación y posterior a la misma, e identificación de usuario, fecha y hora que realizó la misma. Subir
|
| Arquitectura de Ejecución |
| El Sistema puede operar en modalidad 7 x 24 y permite
la ejecución concurrente de funciones interactivas y batch. A través
de mecanismos de Commit y Rollback asegura la intregridad transaccional, manteniendo
un journal único provisto por la aplicación (a nivel de transacciones
monetarias), y por el gestor de base de datos a nivel de todas las tablas del
Sistema. La actualización de los datos es on-line y en tiempo real, incluso
para los datos contables. Por lo que los procesos que se ejecutan en forma batch,
son los que por su propia naturaleza, deben hacerlo de esa manera, tales como:
proceso de la cámara recibida, devengamiento de intereses, cálculo
de provisiones por incobrabilidad, pasaje de movimientos del día a archivos
históricos, a manera de ejemplo. Se permite el manejo de fecha valor
(a efectos de cálculo de intereses) como de fecha valor contable, encargándose
el sistema de reconstruir los saldos contables desde la fecha valor hasta el
día de proceso en forma automática (controlando las restricciones
de seguridad y de proceso que se pueden definir para el uso de esta técnica).
Se permiten realizar anulaciones o extornos de transacciones (que implican asimismo
un reverso del apunte o asiento contable), sobre movimientos del día
como de días anteriores. El sistema administra automáticamente
la contabilidad en este caso, realizando exactamente el asiento inverso al original. Desde el punto de vista batch, la ejecución es guiada por una tabla de control que permite definir la secuencia de ejecución de los procesos y su periodicidad (en términos de diario o mensual). Asimismo permite habilitar/deshabilitar procesos para el manejo de ejecuciones aperiódicas. Los procesos batch están diseñados para ser paralelizados (ejecución concomitante en varios procesadores) lo que permite reducir dramáticamente el camino crítico del mismo. Las posibilidades de paralelización de cada proceso difieren en función de la naturaleza del mismo (por grupo de sucursales, por módulo/transacción, etc.). Los procesos batch se ejecutan en forma totalmente automática requiriendo mínima intervención de operación. En caso de ejecución fallida, y en función de los códigos de retorno de los procesos, se puede establecer las políticas de interrupción del proceso. El total de la ejecución batch queda registrado en la tabla de control del sistema con indicación de hora de inicio y fin de cada proceso. Subir
|