Sistema OPCISAP, OPCIPRES SA de CV SOFOM ENR.

(1)

Q U E P A R A O B T E N E R E L T Í T U L O D E LICENCIADO EN CIENCIAS DE LA INFORMÁTICA

P R E S E N T A OMAR ALBERTO CERVANTES GARCÍA

MÉXICO D. F. 2010

INSTITUTO POLITÉCNICO NACIONAL

UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y CIENCIAS SOCIALES

Y ADMINISTRATIVAS

”SISTEMA OPCISAP,

OPCIPRES S. A. DE C. V. SOFOM ENR”

INFORME DE MEMORIA DE EXPERIENCIA PROFESIONAL

(2)

ÍNDICE

RESUMEN ... i

INTRODUCCIÓN ... ii

CAPÍTULO I ANTECEDENTES DE OPCIPRES SA DE CV SOFOM ENR ... 1

1.1 MISIÓN ... 1

1.2 VISIÓN ... 1

1.3 VALORES ... 2

1.4 ORGANIGRAMA... 3

1.5 ORGANIGRAMA DEL AREA DE SISTEMAS ... 4

1.5.1 Funciones de los niveles tácticos. ... 4

CAPÍTULO I I CAPACITACIÓN ... 5

2.1 ARQUITECTURA CLIENTE SERVIDOR ... 5

CAPÍTULO I I I RESPALDO AUTOMÁTICO DE BASE DE DATOS... 6

3.1 GENERACION DE RESPALDO ... 6

3.1.1 Requerimiento ... 6

3.1.2 Análisis ... 6

3.1.3 Diseño ... 6

3.1.4 Implementación ... 7

3.1.5 Pruebas ... 7

3.1.6 Liberación ... 7

3.2 REPORTADOR POR ESTATUS ... 8

3.2.2 Análisis ... 8

3.2.3 Diseño ... 8

3.3 PROCESO DE DISPERSIÓN ... 10

3.3.2 Análisis ... 10

3.3.3 Diseño ... 11

3.4 PROCESO DE ACTIVACIÓN ... 13

(3)

3.4.2 Análisis ... 13

3.4.3 Diseño ... 14

CAPÍTULO I V INTERFAZ CONTABLE ... 18

4.1 GENERACION DE MOVIMIENTOS CONTABLES ... 18

4.1.2 Análisis ... 19

4.1.3 Diseño ... 19

4.2 PROCESO DE ACTUALIZACIÓN DE VENCIMIENTOS ... 27

4.2.2 Análisis ... 27

4.2.3 Diseño ... 27

4.3 EXPORTACIÓN AUTOMÁTICA A ASPEL COI ... 29

4.3.2 Análisis ... 29

4.3.3 Diseño ... 30

CAPÍTULO V ADMINISTRACIÓN DE LIDERES DE ASESORES FINANCIEROS ... 34

5.1 LIDERES DE ASESORES ... 34

5.1.2 Análisis ... 34

5.1.3 Diseño ... 35

5.2 ADMINISTRACIÓN DE RESGUARDO DE EXPEDIENTES ... 38

5.2.2 Análisis ... 39

(4)

5.2.3 Diseño ... 40

5.3 GENERACIÓN EN LOTE DE ESTADOS DE CUENTA ... 47

5.3.2 Análisis ... 48

5.3.3 Diseño ... 49

5.4 PAGINA WEB DE LA EMPRESA ... 53

5.4.2 Análisis ... 53

5.4.3 Diseño ... 53

CAPÍTULO VI ACTUALIZACIÓN DEL WORKFLOW DE LOS CRÉDITOS... 57

6.1 WORKFLOW ... 57

6.1.2 Análisis ... 57

6.1.3 Flujo normal... 58

6.1.4 Folios en transito ... 58

6.1.5 Diseño ... 59

CONCLUSIONES ... 71

ANEXOS ... 72

(5)

i RESUMEN

El objetivo del presente escrito es compartir lo más relevante de mi experiencia profesional en el sector financiero enfocado al manejo de la información y procesamiento eficiente de datos.

Lo anterior basado en el desarrollo de un sistema complejo para administrar las operaciones del día a día de una empresa del sector financiero enfocada a otorgar créditos a los trabajadores de la SNTE (Sindicato Nacional de Trabajadores de la Educación). La mejora de procesos; las técnicas de la programación orientada a objetos que utilice, el lenguaje de programación pascal y las herramientas de desarrollo rápido empleadas así como las necesidades operativas y de minería de datos solicitadas en cada etapa por las distintas áreas de la empresa en sectores de alta jerarquía y de operación además del sistema manejador de bases de datos de IBM Informix con el Lenguaje Estructurado de consultas.

La principal metodología empleada para la entrega de cada subsistema al área correspondiente fue la teoría del ciclo de vida de los sistemas. Donde los resultados obtenidos fueron estables y mejoraron las actividades de cada uno de los usuarios superando las expectativas de cada requerimiento.

De esta forma he elaborado en conjunto con mis compañeros de área un Sistema de Administración de Prestamos para el sector financiero enfocado a las necesidades operativas de OPCIPRES S.A. DE C.V. SOFOM E.N.R.

(6)

ii INTRODUCCIÓN

En el presente comentaré de forma simple y concreta las actividades más sobresalientes y de mayor peso productivo en la empresa donde actualmente me sigo desempeñando profesionalmente. He decidido dar el primer paso para la elaboración de estas memorias, considerando el nivel de la audiencia para el que estoy escribiendo. Teniendo así un amplio criterio para determinar cuáles términos o procedimientos necesitan definición o descripción y cuáles no.

En todo momento, pensaré en el lector y orientaré mis pensamientos y palabras a una audiencia de “especialistas moderados” en el área de la informática de forma general y de forma específica en el desarrollo de sistemas, proyectos y programación orientada a objetos.

Los principales subsistemas desarrollados se enfocan la captura de solicitantes de créditos, administración de créditos, asesores financieros, cálculo de capacidad de pago, diversos tipos de reportes, generación en lote de estados de cuenta, calificación de cartera, cálculo de la comisión a asesores financieros, exportación automática de la contabilidad generada por la activación y dispersión de créditos a ASPEL COI, módulo para la administración de resguardo de expedientes, entre otros.

El equipo de desarrollo de sistemas en la empresa y de soporte técnico estaba inicialmente compuesto de dos personas; el Gerente de Sistemas y Procesos y un Ingeniero de Desarrollo, este último perfil es el que yo desempeño. De la misma forma en que todas las áreas de la empresa fueron creciendo, sistemas también lo fue haciendo.

(7)

1 CAPÍTULO I ANTECEDENTES DE OPCIPRES SA DE CV SOFOM ENR Se fundó a finales del 2005 por empresarios con amplia experiencia en la administración y otorgamientos de créditos. Con un giro Financiero de Sociedad Financiera de Objeto Múltiple. OPCIPRES, S.A. DE C.V. SOFOM E.N.R.

(OPCIPRES), tiene por objeto otorgar créditos promover y vender productos financieros y otorgar servicios de asesoría financiera a personas físicas o morales.

1.1 MISIÓN

La misión de OPCIPRES es satisfacer las necesidades financieras de trabajadores que enfrentan barreras para acceder a servicios financieros tradicionales y que por sus condiciones laborales califican para el otorgamiento del crédito.

Garantizando un servicio de excelencia a través de resolver sus necesidades de manera rápida, bajo condiciones competitivas, logrando una adecuada utilidad a los accionistas mediante una operación eficiente.

1.2 VISIÓN

Ser una empresa que:

• Retribuya y desarrolle integralmente a su personal: Aprovechar la capacidad y el talento de su recurso humano, brindando una retribución justa al desempeño de sus labores.

• Contribuya al desarrollo regional: Procurar el beneficio de las comunidades, a través de financiamientos viables y seguros.

• Ofrezca un servicio de excelencia: Garantizar la satisfacción del cliente, excediendo sus expectativas y anticipando sus necesidades.

• Opere con rentabilidad y eficiencia: Operar con criterios de rentabilidad, optimizando el uso de los recursos disponibles.

• Sea líder en su ramo: Que se distinga por tener una operación segura y eficiente sustentada en personal calificado, sistemas, herramientas y tecnología de punta.

• Tenga vocación de innovación y aprendizaje: Búsqueda continúa de innovación y desarrollo de nuevos productos, así como la ampliación de las líneas de negocio.

• Trabajo en equipo: Fomentar que haya compañerismo en la organización, porque el trabajo en equipo da muy buenos resultados; ya que normalmente estimula el entusiasmo para que salgan bien las tareas encomendadas. Las empresas que fomentan entre los trabajadores un ambiente de armonía obtienen resultados beneficiosos. La empresa en efectividad y los trabajadores en sus relaciones sociales. El compañerismo se logra cuando hay trabajo y amistad con las relaciones interpersonales y laborales.

(8)

2 1.3 VALORES

• Pasión por el servicio: Ofrecer el mejor servicio a nuestros clientes (internos y externos), en términos de rapidez, eficiencia y amabilidad. Las interacciones entre las áreas se rigen por el único deseo de lograr la satisfacción del cliente.

• Innovación: No nos conformamos con el estado actual del negocio y buscamos siempre nuevas opciones que nos permitan ser más eficientes. Mantenemos el compromiso por mejorar y por ser líderes.

• Creatividad: La denominamos también inventiva, pensamiento original, imaginación constructiva, pensamiento divergente o pensamiento creativo, es la capacidad de generación de nuevas ideas o conceptos operativos, o de nuevas asociaciones entre ideas y conceptos conocidos de cada una de las áreas de la empresa, para que habitualmente se produzcan soluciones originales.

• Desarrollo del personal: Desarrollamos nuestra organización desde adentro, promoviendo a la gente sin otra distinción que la de su desempeño. Actuamos bajo la convicción de que las personas que laboran en OPCIPRES son nuestro principal activo.

• Apoyo: Tener la iniciativa y voluntad para orientar a nuestros compañeros a resolver sus dudas en ciertas etapas de su desarrollo laboral así como mantener una buena relación de confianza a fin de solucionar todas las inquietudes o problemáticas durante las actividades diarias.

• Lealtad: Somos francos con cada uno de nosotros. Operamos siempre dentro de las Leyes. Tenemos presentes los valores de OPCIPRES en cada una de nuestras acciones y decisiones. Fundamentamos nuestras propuestas con honestidad, incluyendo el reconocimiento de los riesgos involucrados.

• Honestidad: Tener una cualidad de calidad humana que consiste en comportarse y expresarse con coherencia y sinceridad, y de acuerdo con los valores de verdad y justicia de cada integrante de la empresa. Para trata de vivir el día a día de acuerdo a como se piensa y se siente. En el sentido más evidente, la honestidad debe entenderse como el simple respeto a la verdad en relación con los compañeros, los hechos y las demás personas.

• Integridad: Que cada uno de los integrantes de la empresa que no se quede en una sola actividad, sino que se mueva por las distintas áreas del conocimiento. La integridad fue característica en el hombre.

• Amistad: Se da en distintas etapas de la vida y en diferentes grados de importancia y trascendencia. La amistad nace cuando las personas encuentran inquietudes comunes. Hay amistades que nacen a los pocos minutos de relacionarse y otras que tardan años en hacerlo.

(9)

3 1.4 ORGANIGRAMA

(10)

4 1.5 ORGANIGRAMA DEL AREA DE SISTEMAS

Objetivo Estratégico de la Gerencia. Coordinar el desarrollo e implantación de sistemas informáticos y su aplicación, así como investigar, desarrollar y fomentar la evolución tecnológica de la empresa; planificando, organizando, dirigiendo, coordinando y supervisando el adecuado uso de las tecnologías de información y de conectividad; de manera que se asegure el respaldo y reguardo de la información de la empresa.

1.5.1 Funciones de los niveles tácticos.

Ingeniero de desarrollo: Analizar, diseñar, desarrollar, evaluar e implantar Sistemas de Información haciendo uso de las herramientas y metodologías computacionales adecuadas, analizando necesidades, a fin de satisfacer los requerimientos de la Institución.

Ingeniero de desarrollo web: Analizar, diseñar, desarrollar, evaluar e implantar la plataforma web, haciendo uso de las herramientas y metodologías computacionales adecuadas, analizando necesidades, a fin de satisfacer los requerimientos de la Institución.

Ingeniero de soporte técnico: Administrar y configurar los sistemas de bases de datos a nivel físico y lógico, a fin de asegurar la integridad, disponibilidad y confidencialidad de la información almacenada, así mismo supervisar y coordinar la asistencia técnica en las áreas de hardware, software y comunicaciones, garantizando calidad y oportunidad en la prestación del servicio a los distintos usuarios de la organización; Investigando, analizando y coordinando la evolución tecnológica de las áreas de hardware y software de la organización.

Ingeniero de procesos: Definir, formular y elaborar los documentos de los sistemas informáticos necesarios para mejorar la operación del área de sistemas y de la empresa detallando las funcionalidades para la mejora de los procesos.

(11)

5 CAPÍTULO I I CAPACITACIÓN

Al ingresar a laborar a OPCIPRES en el 2006 obtuve el conocimiento de la estructura funcional de la empresa en aquél entonces, estructura que ha ido creciendo en todos sus niveles al paso del tiempo. Recibí información sobre la historia de la empresa y el significado de su nombre: OPCIPRES (Opción de préstamo). El Gerente de Sistemas, mi jefe inmediato, me indicó la función que debía seguir el área de sistemas, el tipo de información que se manejaba, la base de datos era administrada en un servidor SUN con un SMDB Informix, la herramienta de desarrollo rápido para el sistema central de la empresa ha sido Delphi 7 de Borland con el lenguaje de programación orientado a objetos de Pascal. La arquitectura bajo la cual estaba implementado el sistema de la empresa era Arquitectura Cliente- Servidor, el sistema tenía un nombre inicial de Prestacción el cual después fue renombrado por la Subdirección de Operaciones a OpciSAP (Sistema de Administración de Préstamos de OPCIPRES) en el cual se centraron la mayoría de mis actividades profesionales en proyectos y subsistemas que apoyarían directamente a la producción y a las funciones darías de las aéreas de la empresa. Al momento de mi incorporación el sistema inicial Prestacción ya contaba con módulos simples de captura de préstamos, solicitantes, varios catálogos y algunos tipos básicos de reportes de información. En este momento muchas de las operaciones que ya se han automatizado hasta la fecha se realizaban de forma manual con herramientas de Office como Excel por ejemplo.

2.1 ARQUITECTURA CLIENTE SERVIDOR

Esta arquitectura bajo la cual esta implementado el sistema de información que he desarrollado el cual es objeto de este documento consiste básicamente en un cliente OpciSAP que realiza peticiones a otro programa llamado servidor de aplicaciones MidasOpciSAP que le da la respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras, por esto mismo se eligió esta arquitectura de sistemas. En esta arquitectura la capacidad de proceso está repartida entre los clientes cuya función depende del tipo de usuario correspondiente a una área jerárquica de la empresa y el servidor de datos y de aplicaciones, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema en módulos independientes como los que comentaré en los siguientes capítulos. La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor se ejecuta necesariamente sobre una sola máquina y en este caso es necesariamente un sólo programa de tipo COM Object el cual publica distintos servicios para que el OpciSAP distribuido en todas las computadoras del corporativo puedan llamar. Los tipos específicos de servidores con que cuenta la empresa son:

servidor web, de archivos y de correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma utilizada hasta ese momento.

(12)

6 CAPÍTULO I I I RESPALDO AUTOMÁTICO DE BASE DE DATOS

La primera actividad que se encomendó después de recibir la capacitación de los servidores de la empresa y el ambiente de desarrollo de Borland Delphi Versión 7. Se me indico levantar el requerimiento con la Subdirección de Operaciones para desarrollar un servicio de Windows para realizar respaldos automáticos de la base de datos relacional de la empresa llamada opcipres_prod contenida en Informix.

3.1 GENERACION DE RESPALDO

3.1.1 Requerimiento

En una sesión de levantamiento de requerimiento sostenida entre la Subdirección de Operaciones, la Gerencia de Sistemas y yo como Ingeniero de Sistemas, se detecto la necesidad de respaldar automáticamente toda la información del servidor SUN almacenada en la base de datos de Informix, dicha necesidad de respaldo surgió porque algunas semanas atrás se dañó un servidor y se perdió una parte de la información de las operaciones diarias de la empresa.

3.1.2 Análisis

La Subdirección de Operaciones únicamente me pidió una solución al problema planteado y me apegue el desarrollo de una aplicación en Delphi para que fungiera como servicio de Windows para que realizara el respaldo de la base de datos solicitada. Se contaba con una base de datos en El SMBD de IMB Informix 9.x el Gerente de Sistemas me asigno un nombre de usuario y una contraseña para poder conectarme.

3.1.3 Diseño

Una ventana simple con dos secciones. Una para la configuración de los parámetros iníciales de conexión como lo es Dirección IP del Servidor de datos, Nombre de la base de datos, Nombre de usuario y password. Un reloj para poder seleccionar la hora de ejecución del proceso automatizado y una lista de opciones para indicarle al sistema los días de la semana en los que se va a realizar el respaldo.

Fig. 1. Pantalla del servicio de Respaldo automático de base de datos.

(13)

7 3.1.4 Implementación

Inicié un nuevo proyecto en Delphi donde hice la creación de la ventana tomando en cuenta los parámetros de entrada necesarios. Así mismo hice una sección de Log donde se indicaría la hora en la que ocurre cada acción del servicio.

Hice una clase principal que hereda de TWinService la cual cuenta entre otras cosas con un método de ejecución llamado Run funcionó bajo es siguiente algoritmo:

• Dentro de la clase principal llamada TFrmBkpMain incluir un TTimer que hace herencia de TThread para que cuando la hora de ejecución configurada sea igual a la hora actual del TTimer, conectar un componente de sesión Telnet del tipo TidTelnet cuyos datos de sesión ya serian configurados a continuación.

• En el evento IdTelnetDataAvailable de dicho componente ir enviando el siguiente comando de ejecución al servidor Linux de Informix para llevar a cabo el respaldo de la base de datos.

• Cuando la petición del buffer sea ‘PLEASE LOGIN’ enviar el texto contenido en la caja de texto del usuario.

• Cuando en el buffer aparecía ‘PASSWORD:’ se enviaría el texto encriptado de la caja de texto de password.

• Si el buffer de la consola devolvía: 'FTP SERVICE’ y la sesión ya estaba activa con el siguiente comando se realizaba la creación de la carpeta contenedora del respaldo ‘mkdir OpciPres_DDMMYYYY’

• Con la instrucción anterior se crearía una carpeta en el servidor.

• Después enviaría otro comando para posicionarse dentro de la nueva carpeta: ‘cd OpciPres_DDMMYYYY’

• Enviar la instrucción para hacer el respaldo físico de la base de datos escrita en la caja de texto de base de datos. 'dbexport –c opcipres_prod'

• Finalmente un comando ‘ls’ para revisar que el respaldo se haya generado correctamente.

• En caso contrario se notificaría el error en la consola.

3.1.5 Pruebas

Una vez terminada la nueva herramienta para realizar respaldo automáticos de la base de datos. Se realizaron las pruebas pertinentes en bases de datos del servidor de pruebas.

3.1.6 Liberación

Lleve a cabo la instalación del nuevo servicio desarrollado para que apareciera en la lista de servicios de Windows, le cambie las propiedades de inicio a inicio automático y una vez iniciado se configuro a las 10pm de lunes a viernes;

(14)

8 finalmente inicio su proceso normalmente. Durante la programación de este nuevo módulo aprendí a realizar conexiones vía Telnet con servidores de datos remotos utilizando un componente externo en pascal para poder enviar comando de ejecución al servidor de datos Informix.

3.2 REPORTADOR POR ESTATUS

Una vez cubierta la necesidad de respaldo automático de la información operativa del día a día de la empresa la Dirección General y la Subdirección de Operaciones se dieron a la tarea de solicitar un módulo de impresión del estatus actual de cada uno de los créditos en un periodo parametrizable.

3.2.2 Análisis

El área de Normatividad y Mesa de Control me indico que la vida de un crédito hasta ese momento pasaba por una serie de estatus: En Trámite, Autorizado, Dispersado, Activado, Pagado, Rechazado o Cancelado; los cuales describo a continuación:

A. En Trámite: Estatus inicial que indica que la documentación de un cliente está siendo analizada para su autorización o rechazo.

B. Autorizado: Cuando el analista central valida toda la documentación y capacidad de pago de un solicitante.

C. Dispersado: Cuando Tesorería pone a disposición del solicitante el monto del crédito.

D. Activado: Cuando el solicitante toma el dinero objeto de su préstamo.

E. Pagado: El solicitante ha cubierto todos sus pagos.

F. Rechazado: La documentación requerida está incompleta o el solicitante no cubre la capacidad de pago requerida para el monto que desea.

G. Cancelado: Es imposible que el solicitante pueda continuar efectuando sus pagos por alguna causa de fuerza mayor.

3.2.3 Diseño

En la base de datos en la tabla de préstamos se guardaba cada una de las fechas por las que pasaba cada uno de los estatus descritos anteriormente ftramdt, fautdt, fdispdt, factdt, fpaiddt, frchzdt y fcxl respectivamente.

El módulo de mantenimiento de préstamos se encargaba de actualizar cada uno de estos campos de tipo Integer con este formato YYYYMMDD según la operación que cada usuario realizara.

De esta forma en el sistema ya renombrado a OpciSAP (Sistema de Administración de Préstamos de OPCIPRES) en la pantalla inicial en la sección del menú de Reportes agregue un nuevo elemento con la etiqueta: ‘Listado por estatus’

el cual en su evento onClick instanciaba a la nueva clase que implementaría, la cual

(15)

9 entre otras cosas de forma visual contendría: TComboBox para Fondeador, Entidad y Convenio, otro para el tipo de estatus, dos TDateTimePicker para elegir el periodo de fechas a buscar y dos botones: Uno para realizar la impresión de los créditos encontrados y otro para exportar la información a un archivo de Excel delimitado por comas (csv). Quedando de forma física la siguiente pantalla, al igual que las demás diseñadas con una interfaz amigable y muy intuitiva para cada uno de los usuarios.

Fig. 2. Pantalla del Sistema OpciSAP para reportes por estatus de crédito.

3.2.4 Implementación

La nueva clase que desarrolle; la nombre ‘Frm_ListadoStatus’ la cual heredaba de la súper clase ‘TForm’ de Delphi al ser instanciada cargaba los catálogos de Fondeador, entidad y convenios de sus tablas respectivas en la base de datos. Al ser llenados todos los criterios de búsqueda de dicha ventana y dar clic en el botón de búsqueda se ejecutaba remotamente un método del servidor de aplicaciones que devolvía toda la información de los créditos que cumplieran con dichas condiciones enviadas desde el cliente donde este la presentaba en forma de reporte. Cabe mencionar que todos los reportes que implemente fueron hechos con la herramienta de FastReports Inc. Donde simplemente genere una plantilla de diseño la cual sería alimentada por un DataSet que el servidor de aplicaciones devolvía con la petición su método público.

El Query que el servidor que solicitaba a la base de datos fue el siguiente:

(16)

10 3.2.5 Liberación

Para que finalmente el cliente, en este caso la clase Frm_ListadoStatus, la agregara a una propiedad de la plantilla de FastReports y se presentara el siguiente reporte en pantalla:

Fig. 3. Reportes de créditos dispersados.

En este ejemplo se presentan todos los créditos del Fondeador OPCIPRES SA DE CV de la Entidad de Chiapas del Convenio Sección 40 que fueron dispersados entre el día 1 y 30 de Noviembre del 2008.

3.3 PROCESO DE DISPERSIÓN

A mediados del año 2006 se detecto la necesidad de administrar la forma en la que la Gerencia de Tesorería ponía en las cuentas de los solicitantes el dinero que pedían en el préstamo. En este entonces se venía utilizando un programa de un banco externo llamado Cash Windows el cual se ha encargado hasta este momento de hacer las peticiones de transferencias electrónicas de la misma cuenta o del tipo SPEI. Sin embargo el usuario antes mencionado llevaba el registro de cuantos créditos fueron dispersados en una hoja de cálculo en Excel y pidieron al área de sistemas un módulo especial en el OpciSAP para esta tarea.

3.3.2 Análisis

En la tabla de préstamos ha existido un campo el cual indica el tipo del estatus en el que estaba siempre el crédito, fcvestatus. En este nuevo módulo simplemente se requería un listado de todos aquellos registros de préstamo que ya hayan sido autorizados para poder dispersarse. Que el usuario pudiera seleccionar cuales

(17)

11 dispersaría, indicar una comisión por disposición del efectivo y en una lista desplegable para seleccionar el Fondeador del préstamo. Para que la Asistente de Tesorería así como la misma Gerente de Tesorería no tuvieran problema alguno para elegir la información a dispersar.

3.3.3 Diseño

Así pues en OpciSAP en el menú de Préstamos agregue un nuevo elemento llamado: ‘Por dispersar’ el cual llamaría a la nueva clase ‘TFrmPorDispersar’ con los elementos visuales descritos en la sección anterior.

En la pantalla habría un TComboBox para seleccionar la entidad y otro para el convenio. Al dar clic en el botón de ‘Obtener’ se enviaría al servidor de aplicaciones un Query para obtener los siguientes campos fcvepresta, ffolio, fsolicamt, fautdt, fdie, fcvefondo, fcvecliente, fcvedispone, fcvebanco, fcuenta, fclabe, fsucursal, fcvevendor, fcvesolic, fcvestatus, fcveedo, fcvedestino y fcomision de la tabla de préstamo de los créditos que pertenezcan a la entidad y al convenio seleccionado donde su campo de clave de estatus fuera ‘Autorizado’.

Cada campo representaba la siguiente información para el usuario final:

fcvepresta: Llave única de la tabla de préstamo, de tipo UNIQUE CONSTRAINT en la definición SQL. ffolio: Numero de folio de la solicitud del préstamo. fsolicamt: Monto del préstamo. fcvestatus: Llave foránea a la tabla de catálogo de estatus. fautdt:

Fecha de autorización de la solicitud. fdie: Clave de dispersión electrónica, para que el cliente pueda cobrar su préstamo en la ventanilla bancaria en caso de que ese sea su método de disposición. fcvefondo: Llave foránea a la tabla de fondeadores, representaría a la institución que financia el préstamo. fcvecliente: Llave al catálogo de convenios o dependencias a donde pertenece el solicitante del préstamo.

fcvedispone: Llave foránea a la tabla del método de disposición por ejemplo. Puede ser Dispersión en ventanilla o Transferencia SPEI. Representa la forma en la que el solicitante cobrara su dinero. fcvebanco: Llave al catálogo de bancos donde se depositara. fcuenta: Numero de cuenta bancaria. fclabe: Clave Bancaria Estandarizada para transferencias SPEI. fsucursal: Numero de sucursal bancaria.

fcvevendor: Llave foránea al catálogo de vendedores para saber que Asesor Financiero finalmente vendió el producto. fcvesolic: Llave a la tabla que contiene la información referente al solicitante del préstamo. fcvestatus: Llave a foránea a la tabla del catálogo de estatus. Al momento de realizar la dispersión esta clave debe hacer referencia al estatus de AUTORIZADO, ya que por una regla de negocio solo los créditos con ese estatus pueden ser dispersados. fcveedo: Llave foránea a la entidad federativa donde se vendió el préstamo. fcvedestino: Tipo de destino que el cliente indico en su solicitud para usar su crédito. Una vez pintada toda la información del DataSet enviado por el AppServer en una tabla visual. Habilite un menú contextual con las siguientes opciones:

(18)

12 Marcar dispersión: Esta opción lanzaba la información bancaria del solicitante del préstamo a la cual se efectuaría la dispersión y al dar clic en un botón de ‘Aceptar’ el préstamo se marcaria para poder ser dispersado.

Marcar todos: Aquí se presentaba una opción para escribir el Fondeador del préstamo y una caja monetaria para escribir la cantidad de comisión a cobrar, al ingresar estos parámetros de entrada el módulo recorría todos los registros del DataSet, modificaba esta información y los marcaba todos para poder ser dispersados en ese momento.

Desmarcar dispersión: Le quitaba la marca de ‘Poder dispersar’ al registro seleccionado del DataSet en la tabla.

Desmarcar todos: Desmarcaría todos los registros .

Verificar con archivo de salida: Corroboraba todos los RFC’s y los Montos a dispersar marcados con un archivo de texto plano que generaba el sistema bancario de Cash Windows; en caso de que la información fuera la misma se habilitaba la siguiente opción.

Dispersar marcados: Recorría uno a uno los registros del DataSet en un ciclo y si estaba marcado para activación hacia la petición al servidor de aplicaciones de un Stored Procedure para cambiar el estatus del préstamo a ‘DISPERSADO’, también actualizaría su fecha de dispersión y la comisión cobrada. El Stored Procedure fue nombrado ‘upd_dispersa2’; lo programe en Informix código SQL.

Quedo como resultado la siguiente ventana.

Fig. 4. Nuevo módulo de créditos por dispersar.

(19)

13 3.3.5 Liberación

Cuando había terminado el desarrollo del nuevo módulo de dispersión de préstamos autorizados, realice muchos tipos de pruebas en un ambiente local conectándome a una base de datos de desarrollo que se actualizada con un día de atraso copiando toda la información de producción de esta manera; le di una capacitación a la Gerente de Tesorería indicándole que con algunos pasos muy sencillos resumidos en muy pocos clics podría llevar a cabo la administración de sus dispersiones de créditos día a día.

En este proyecto aprendí a tener mucho cuidado con el manejo de montos en mi código Pascal. Que es más conveniente crear los campos de tipo MONEY que NUMERIC en la base de datos para su correcta manipulación. También tome como experiencia que al usuario final no le importa ver tantos campos con información que no es relevante para su operación, simplemente le basta con lo esencial para poder decidir, en este caso, si el crédito debe dispersarse o no.

Los demás campos que yo necesite como programador para que el proceso funcione los podía mantener en memoria para hacer mis operaciones sin necesidad de pintarlos en pantalla para consumir menos recursos y darle más agilidad al proceso para que el usuario trabaje más rápido. Ya que esta es la finalidad de cada módulo, facilitarle el trabajo al usuario y garantizar la integridad de los datos.

3.4 PROCESO DE ACTIVACIÓN

Este proceso me fue solicitado inmediatamente después de terminar el proceso anterior de Dispersión. Básicamente consiste en cambiar el estatus de los créditos que ya fueron cobrados por los solicitantes a ‘ACTIVO’.

Cabe mencionar que un crédito para la empresa está activo desde el momento que el solicitante cobra su dinero en el banco a donde se le deposito el monto requerido y hasta que recibimos el último paga el cual salde la deuda; este último pago puede ser un descuento quincenal o un depósito bancario con anticipo a capital.

3.4.2 Análisis

La problemática en ese entonces consistía en que la Gerente de Tesorería debía esperar muchos días hasta que se recibía el primer pago del solicitante para saber que su crédito ya estaba activo. De esta forma desde el módulo principal de administración de préstamos (ya existente) buscaba folio por folio y así, uno por uno, cambiaba su estatus de ‘DISPERSADO’ a ‘ACTIVO’ en caso de que el dinero dispersado haya sido cobrado dentro de un periodo de menor a 7 días en caso contrario, es decir, si el dinero no fue cobrado en esos 7 días el estatus pasaría de

(20)

14

‘DISPERSADO’ a ‘CANCELADO’. Todo lo anterior causaba mucho tiempo de trabajo para el usuario y llevaba su control externo en archivos de Excel lo cual no era correcto para las exigencias de la Subdirección de Administración y Finanzas en su forma de operar día a día para cada usuario, para que posteriormente dentro de la atapa del diseño físico de la ventana incluyera todos los elementos necesarios para que los usuarios de Tesorería pudieran realizar las operaciones correspondientes.

3.4.3 Diseño

Entonces propuse, solicitar un archivo de texto al banco con un LAY-OUT predefinido en el cual se especificaría cuales créditos dispersados ya fueron cobrados por los solicitantes para poder saber cuales se podrán activar en este nuevo módulo del OpciSAP. Dentro del menú de Prestamos en el OpciSAP coloque un nuevo elemento con la etiqueta: ‘Por activar’ el cual crearía una instancia de la clase ‘TFrmPorActivar’ con objetos para seleccionar la Entidad, el Convenio y un botón para cargar la información; así como una tabla para pintar toda la información relevante a la Activación. Así como dos casillas de verificación para indicar con que prestamos se querían trabajar si con los DISPERSADOS o con los CADUCADOS.

Fig. 5. Nuevo módulo de créditos por activar.

(21)

15 3.4.4 Implementación

En el evento onClick del botón se ejecutaría una consulta la cual se envía al AppServer que regresaría al cliente todos los créditos con estatus de

‘DISPERSADO’ hasta la fecha actual. La consulta se efectuaba sobre la tabla de préstamos y obtenía los siguientes campos:

fcvepresta: Llave única de la tabla de préstamo, de tipo UNIQUE CONSTRAINT. fdispcxl: Fecha de cancelación de la dispersión. fdispamt: Monto dispersado, monto solicitado menos la comisión por apertura. ffolio: Numero de folio de la solicitud del préstamo. fsolicamt: Fecha de la solicitud del préstamo. fcvestatus:

Llave foránea a la tabla de catálogo de estatus. fdispdt: Fecha de dispersión del préstamo. fdie: Clave de dispersión electrónica, para que el cliente pueda cobrar su préstamo en la ventanilla bancaria en caso de que ese sea su método de disposición.

fcvecliente: Llave al catálogo de convenios o dependencias a donde pertenece el solicitante del préstamo. fcvesolic: Llave a la tabla que contiene toda la información referente al solicitante. fdispref: Referencia de dispersión. fqnaamt: Monto total que se le descontara quincenalmente al solicitante. ftotcapital: Total de capital. ftotinteres:

Total de intereses durante la vida del crédito. fqnaini: Número de la quincena inicial de descuento vía nomina. fqnafin: Número de la quincena final de descuento. fplazo:

Número de meses para cubrir el total de los pagos del préstamo. fcvestatus: Estatus actual de préstamo, en este caso seria ‘DISPERSADO’. fcvefondo: Llave foránea a la tabla de fondeadores, representaría a la institución que financia el préstamo.

Al dar un clic en la casilla de verificación de DISPERSADOS habilitaba la propiedad Filter del DataSet principal para únicamente mostrar aquellos prestamos que efectivamente tenían estatus de dispersado. El filtro fue el siguiente:

memActiva.Filter := 'fcaducado = 0';

En caso de dar clic en los caducados el filtro seria:

memActiva.Filter := 'fcaducado = 1;

El campo de fcaducado se creó como campo calculado dentro del DataSet principal el cual indicaba con un numero 1 si el campo fdispcxl fuese menor a la fecha actual, es decir que ya han pasado los 7 días después de la dispersión y el cliente no ha cobrado su dinero en ventanilla. Una vez pintada toda la información del DataSet enviado por el AppServer en una tabla visual heredada de TcxGrid. Le inyecte la dependencia de un PopUp Menú con las siguientes opciones:

Marcar Activación: Esta opción ejecutaba el siguiente proceso. Al dar clic derecho sobre un registro de la tabla de préstamos por activar, se validaba que el préstamo no haya caducado. En ese caso solo se cambiaba los siguientes campos en memoria:

FieldByName('factdt' ).AsDateTime:= [Fecha de Activacion];

FieldByName('fupddt' ).AsDateTime:= [Fecha actual];

(22)

16 FieldByName('factivado').AsBoolean := True ;

FieldByName('fCaducado').AsInteger := 0 ; FieldByName('fCadAct').AsBoolean:=False;

Y así al terminar de marcar los préstamos que se activaran se ejecutarían otros procesos que serian los que finalmente darían paso a la ejecución de un procedimiento almacenado en la base de datos de producción para hacer el cambio de estatus a nivel lógico de los créditos.

Desmarcar Activación: Esta opción inicializaba los campos del DataSet del registro seleccionado para que el usuario pudiera indicar que ya no se desea activar.

Recuperar movimientos del día: Esta opción cargaría en memoria el archivo que enviaba el banco a donde se hacían las dispersiones en este caso BBVA BANCOMER. Se tomaban los siguientes campos de las siguientes posiciones por cada línea de archivo cargada:

sDIE := De la posición 10 se copiaban 15 caracteres;

sMonto:= De la posición 88 se copiaban 16 caracteres;

sFOper:= De la posición 104 se copiaban 8 caracteres;

Si se encontraba la llave de la DIE recorrida en el ciclo actual dentro del DataSet este se ponía en modo edición y por cada DIE del archivo encontrada en el DataSet se actualizaba de forma masiva los mismos campos para marcar la activación, solo que con los valores leídos de cada línea del archivo.

Imprimir: Esta opción enviaba a la impresora seleccionada la información de registros por activar en pantalla.

Activar Marcados: Este método de la clase se posicionaba en el primer registro del DataSet con su método First () después se ejecutaría un ciclo while para recorrer todos los registros si se detectaba que dicho registro estaba marcado para activar con el campo 'factivado= True' entonces se mandaría a ejecutar un SP haciendo un llamado a un método del AppServer para cambiar el estatus de

‘DISPERSADO’ a ‘ACTIVO’. El Método público seria setSaveStatus e internamente ejecutaba esta sección de código dentro del Stored Procedure.

UPDATE prestamo SET fcvestatus = 4,

factdt = [Fecha de Activación],

fupdusr = [Usuario que realice el cambio], fupddt = [Fecha actual]

WHERE fcvepresta=[Llave del préstamo];

Finalizado este nuevo módulo de Activación de Préstamos dispersados, se efectuaron pruebas en mi ambiente local direccionándome a mi base de datos de

(23)

17 desarrollo para finalmente capacitar a la Gerente de Tesorería de la misma forma que en el proyecto anterior de Dispersión. La forma de utilizar esta nueva interfaz fue muy sencilla y amigable para los usuarios responsables del modulo. En conclusión, para ellos, bastaba únicamente con obtener los prestamos que tenían estatus de Dispersado, después de verificar montos cobrados por parte de los solicitantes, marcarlos de uno a uno o en su defecto corroborar con un archivo que les proporcionaba el banco para que se marcaran en automático para dar clic en una opción de ‘Activar Marcados’. Adicionalmente cuando cada uno de los créditos se marcaba como activo, el sistema OpciSAP generaba internamente un correo electrónico para ser enviado a las personas responsables de este proceso para tener una notificación inmediata de los créditos que han sido cambiados de estatus.

Fig. 6. Notificación de Activación en correo electrónico.

(24)

18 CAPÍTULO I V INTERFAZ CONTABLE

Hasta este momento las actividades que desarrolle además de la colocación de impresoras y el manejo de un pequeño inventario del equipo de computo del corporativo; eran, como lo he descrito en los capítulos anteriores, actividades un tanto sencillas donde debía implementar un módulo nuevo en el sistema principal OpciSAP que le presentaría al usuario correspondiente la información grafica de los prestamos con algún estatus en especial para que se pudiera indicar, al mismo sistema, que era necesario cambiarlos a un nuevo estatus para poder continuar así con la vida del crédito.

4.1 GENERACION DE MOVIMIENTOS CONTABLES

Para este entonces ya dominaba más la interacción con el usuario final y el liderar un proyecto completamente desde el levantamiento de requerimiento hasta el mantenimiento de la solución una vez implantada. Y en el aspecto técnico ya había aprendido a utilizar las bases de datos en Informix de IBM, las variantes en las consultas SQL en relación a Oracle y SQL Server que ya dominaba con anterioridad así como la estructura de un Stored Procedure y los Triggers.

En relación al lenguaje de programación orientado a objetos que ocupaba para el sistema central, Pascal en Borland Delphi 7, aprendí a interactuar con unos componentes de terceros del tipo VCL (Visual Component Libraries) llamados Developer Express Inc, para mostrar la información de la base de datos en pantalla al usuario final de una forma muy profesional y con bastante funcionalidad incluida lo que ahorraría la escritura de mucho pseudocódigo con funcionalidad que dichos componentes ya tenían implícita.

En la siguiente sección me enfocare a comentar los proyectos que me costaron un poco mas de trabajo por la complejidad que representaba su impacto en la operación del día a día; así como la interacción en varias áreas estratégicas de la empresa a la vez. Utilizaré lenguaje un poco más técnico para poder describir la mayoría de los pasos que lleve a cado para implementar las diferentes soluciones.

Cabe mencionar que al igual que en los proyectos anteriores el lenguaje de programación Pascal estará íntimamente vinculado con el Lenguaje Estructurado de Consultas SQL para la interacción entre el AppServer y la Base de Datos de producción para regresar al cliente, en este caso el OpciSAP, la nueva información necesaria para cubrir las necesidades de los nuevos módulos.

La Subdirección de Operaciones y la Gerencia de Contabilidad se dieron a la tarea de solicitar a la Gerencia de Sistemas que todos los procesos que representaran un flujo de efectivo dentro de las operaciones diarias del OpciSAP quedaran registrados dentro de nuestra base de datos para poder explotar dicha

(25)

19 información posteriormente generando cargos y abonos en algunas cuentas contables que la Gerencia de Contabilidad nos proporcionaría. Para ser más preciso el interés se enfocaba en la generación de movimientos contables en la Dispersión y en la Activación de créditos, ya que dichos procesos representaban la salida de dinero del fondo monetario de la empresa que en esencia este es el dinero que se entrega físicamente a los solicitantes.

4.1.2 Análisis

Cuando comencé con el diseño del modelo Entidad-Relación para desarrollar esta nueva funcionalidad en el Sistema principal la base de datos contaba principalmente, además de varios catálogos, con una tabla de préstamos en la cual se reflejaba completamente el paso de los estatus de TRAMITE, AUTORIZACION.

DISPERSION y ACTIVACION así como sus respectivas fechas.

Y como el requerimiento principal finalmente se centraba en la generación de movimientos contables con sus respectivos cargos y abonos a algunas cuentas contables la implementación se haría en su mayoría en la Base de Datos de Informix para que al momento de Dispersar o Activar se generaran en automático los movimientos contables.

4.1.3 Diseño

De acuerdo a los requerimientos establecidos para la creación de la Interfaz contable establecí la creación de las siguientes tablas:

Nombre Tabla

Calendario

Descripción Almacenará las fechas en que se entregarán archivos a cómputo, se recibirán los productos por concepto de descuento y se aplicarán los vencimientos de pagos de cada quincena.

Campo Tipo Descripción

fcvecalendar Entero Campo único identificador de las fechas.

fcveedo Entero Entidad a la que está asociada la fecha.

fcvecliente Entero Clave del convenio al que está asociada la fecha.

fqnaproc Entero Quincena de proceso a reportar.

finidt Entero Fecha de la recepción de archivos en cómputo.

ffindt Entero Fecha en que termina la recepción de archivos de cómputo.

fpagodt Entero Fecha en que OPCIPRES recibe de la dependencia el pago por concepto de descuentos.

fcomputo Varchar(1) Bandera que indica si el archivo de descuentos ya fue enviado a cómputo.

(26)

20 fvtodt Entero Fecha en que se aplicará el proceso de

vencimientos de pagos.

faplicavto Varchar(1) Bandera que indica si el proceso de vencimientos ya fue aplicado o sigue sin aplicarse.

faplicadt Entero Fecha en que se aplicó el proceso de vencimientos de pagos.

fcomms Varchar(100) Comentarios.

Nombre Tabla

producto

Descripción Almacenará los productos financieros que ofrece la empresa.

fcveprod Entero Campo único identificador de los productos.

fproducto Varchar(35) Nombre con el cual se reconocerá el producto.

Nombre Tabla

cpto_contable

Descripción Almacenará los conceptos contables definidos por el usuario.

fcvecpto Entero Campo único identificador de los conceptos.

fcveprod Entero Clave del producto al que está asociado el concepto.

fcpto Varchar(10) Nombre del concepto.

fcptocxl Entero Clave del concepto que cancela el movimiento.

fctacargo Varchar(20) Nombre de cuenta que refleja el cargo del concepto.

fctaabono Varchar(20) Nombre de cuenta que refleja el abono del concepto.

fdescrip Varchar(50) Descripción del concepto contable.

fcvestatus Entero Clave del estatus del movimiento contable.

Nombre Tabla

mov_contable

Descripción Almacenará los movimientos contables de los créditos.

(27)

21 fcvemcc Entero Campo único identificador de los movimientos

contables, llave primaria de la tabla.

fcvecpto Entero Concepto al que está asociado el movimiento contable.

fcvepresta Entero Clave del crédito que género el movimiento contable.

fmonto Money Monto aplicado en el movimiento contable.

fmccdt Entero Fecha en que se realizó el movimiento contable.

fmccflujo Varchar(1) Indica si el movimiento contable implica flujo de efectivo.

factivo Varchar(1) Indica si al movimiento ya se le aplica su cancelación.

fcomms Varchar(100) Comentarios sobre el movimiento contable.

faddusr Varchar(25) Usuario que agrega el movimiento contable.

fadddt Entero Fecha en que se agregó el movimiento contable.

Nombre Tabla

Vencimiento

Descripción Almacenará los datos de vencimientos de pagos de cada crédito que al menos haya sido dispersado.

fcvevto Entero Campo único identificador de los vencimientos, será la llave primaria de esta entidad.

fcvepresta Entero Clave del crédito al cual está asociado el vencimiento.

fdispdt Entero Fecha en que se dispersó el crédito.

fdispamt Money Monto cobrado por la comisión de dispersión.

fdispiva Money IVA cobrado por concepto de la comisión por dispersión.

fpaiddt Entero Fecha en que se dispuso el crédito (Activación).

fcompqna Varchar(1) Quincena en que se envió el archivo a cómputo.

ffirtsqna Entero Quincena en que se recibió el primer descuento del crédito.

fqnaini Entero Quincena en que deben iniciar los descuentos.

fqnafin Entero Quincena en que deben terminar los descuentos.

(28)

22 fcvestatus Entero Estatus actual del crédito.

fcapqna Money Capital a recuperar quincenalmente.

fintqna Money Interés a recuperar quincenalmente.

fivaqna Money IVA a recuperar quincenalmente.

fcaptotal Money Capital total a recuperar.

finttotal Money Interés total a recuperar.

fivatotal Money IVA total a recuperar.

fqnavdas Entero Total de quincenas vencidas.

fqnapgdas Entero Número de quincenas vencidas pagadas.

fqnanopgdas Entero Número de quincenas vencidas no pagadas.

fnextqnavto Entero Siguiente quincena de vencimiento.

fnextdtvto Entero Siguiente fecha de vencimiento.

fcapvdo Money Capital vencido hasta última quincena registrada.

fintvdo Money Interés vencido hasta la última quincena.

fivavdo Money IVA vencido hasta la última quincena registrada.

flastdtpago Money Fecha de último pago recibido.

flastqnapago Money Quincena de último pago recibido.

fcappgdo Money Capital total pagado hasta última quincena registrada.

fintpgdo Money Interés total pagado hasta última quincena.

fivapgdo Money IVA total pagado hasta la última quincena registrada.

fcapsaldo Money Saldo de capital hasta la última quincena registrada.

fintsaldo Money Saldo de interés hasta la última quincena.

fivasaldo Money Saldo de iba hasta la última quincena registrada.

faddusr Varchar(25) Usuario que agregó el registro.

fadddt Entero Fecha en que se agregó el registro.

fupdusr Varchar(25) Último usuario que modificó el registro.

fupddt Entero Fecha en que se hizo la última modificación al registro.

Nombre Tabla

Amortiza

(29)

23 Descripción Almacenará el calendario de amortizaciones de cada crédito.

fcveamortiza Entero Campo único identificador de las diferentes amortizaciones, en este caso es la llave primaria.

fcvepresta Entero Clave del crédito al que pertenece la amortización.

fnumamortiza Entero Número de amortización del crédito.

fcaprecup Money Monto de capital por recuperar en la amortización.

fintrecup Money Monto de interés por recuperar en la amortización.

fivarecup Money Monto de IVA por recuperar en la amortización.

ftotalrecup Money Monto total por recuperar en la amortización.

fcappgdo Money Monto de capital pagado en la amortización.

fintpgdo Money Monto de interés pagado en la amortización.

fivapgdo Money Monto de IVA pagado en la amortización.

ftotalpgdo Money Monto total pagado de la amortización.

fpagado Varchar(1) Indica si la amortización ya fue pagada.

fqnapgo Entero Quincena en que se termino de pagar la cantidad total de la amortización.

fpgodt Entero Fecha en que se termino de pagar la cantidad total de la amortización.

faddusr Varchar(25) Usuario que creó la amortización.

fadddt Entero Fecha en que se creó la amortización.

fupdusr Varchar(25) Usuario que modificó la amortización

Para llevar a cabo el registro, control y reporte de los movimientos contables fue necesaria la creación de los siguientes Stored Procedure’s dentro de la Base de Datos.

setmovcontable: SP que registrará y validará los movimientos contables generados por los registros de Dispersión y Activación.

a) Parámetros a recibir:

- aTipo. 0=Alta 1=Cancelación.

- aCpto. Concepto a dar de alta o a cancelar.

- aCvePresta. Clave del préstamo que genera la operación.

- aMonto. Monto del movimiento contable.

(30)

24 - aNow. Fecha de movimiento YYYYMMDD.

- aHora. Hora en que se genera el movimiento.

- aFlujo. Indica si genera flujo de efectivo, 0=Falso 1=Verdadero.

- aComms. Comentarios al movimiento.

- aAddUsr. Usuario que se agrega el registro.

- aAddDt. Fecha en que se agrega el registro.

b) Se tomaría el concepto recibido en el parámetro y determinando si existe en el catálogo de conceptos contables (tabla cpto_contable). En caso de no encontrarse el concepto en el catálogo se notificaría un error al usuario.

En caso de encontrar el concepto se buscaría la clave única del concepto (campo fcvecpto) así como la clave única del concepto que lo cancela (campo fcptocxl).

c) Se busco a partir de la tabla mov_contable la nueva clave única que se asignará al movimiento contable por registrar de la tabla mov_contable todos los movimientos contables registrados al concepto solicitado y asociado al crédito definido por el parámetro recibido.

d) En caso de haber encontrado registros asociados al crédito por el mismo concepto, para el caso negativo se debía evaluar si se está solicitando una alta del concepto la cual dará como resultado la inserción del nuevo registro en la tabla mov_contable con la siguiente asignación de datos:

- fcvemcc: Nueva clave única definida.

- fcvecpto: Clave única del concepto.

- fcvepresta: Parámetro aCvePresta.

- fmonto: Parámetro aMonto.

- fmccdt: Parámetro aNow.

- fmcchr: Parámetro aHora.

- fmccflujo: Parámetro aFlujo.

- fmccactivo: ‘T’.

- fcomms: ‘’.

- faddusr: Parámetro aAddUsr.

- fadddt: Parámetro aAddDt.

e) Para el caso de solicitar una baja también se realiza la inserción del movimiento contable con las siguientes consideraciones:

- fcvecpto: Clave única del concepto de cancelación.

- fmccactivo: ‘F’.

- fcomms: ‘NO EXISTE EL MOVIMIENTO PREVIO A LA CANCELACION’

- faddusr: Parámetro aAddUsr - fadddt: Parámetro aAddDt

f) En caso de haber encontrado registros asociados al crédito y por el mismo concepto contable solicitado, sería necesario recorrerlos para verificar que todos se encuentren inactivos. Dentro del barrido de registros se debe definir el total de registros encontrados, total de registros con estatus inactivo (campo fMccActivo=T) y

(31)

25 la clave del primer registro activo (si es que lo hubiese). Si el resultado del “barrido”

indica que todos los registros encontrados están inactivos se aplicarán las siguientes consideraciones:

En caso de haber solicitado un alta:

- fcomms: ‘’.

Si se solicitó una baja de movimiento contable:

- fcomms: ‘NO EXISTE CONCEPTO ACTIVO A CANCELAR’.

g) En caso de encontrar al menos un concepto activo se aplicarán las siguientes consideraciones:

Si se solicitado dar de alta un nuevo movimiento contable, se insertaría un registro con la siguiente asignación de datos:

- fcomms: ‘EXISTE AL MENOS UN REGISTRO ACTIVO DEL CONCEPTO’.

Para una baja evaluar si se tiene más de un registro activo, es caso afirmativo se inserta el movimiento contable de la cancelación con la siguiente asignación de datos:

(32)

26 - fcvepresta: Parámetro aCvePresta.

- fcomms: ‘EXISTE MAS DE UN CONCEPTO ACTIVO A CANCELAR’.

Posteriormente se toma la clave única del primer movimiento contable activo encontrado y se cambia su bandera a inactivo (fMccActivo=’F’) indicando que todos los movimientos de alta ya tienen su contraparte de baja.

Para el caso de encontrar un solo movimiento activo se inserta el movimiento contable correspondiente a la baja, tomando en cuenta la siguiente asignación de datos informativos:

- fcomms: ‘’.

Por último se marca como inactivo el movimiento contable que haya sido detectado como activo (fMccActivo=’F’). Una vez puesto a punto este nuevo SP adicionalmente se modificaron también los SP’s de upd_dispersa2 y setSaveStatus.

En los SP’s antes mencionados se agrego el llamado al nuevo SP de setmovcontable para dar de alta los nuevos movimientos solicitados en el requerimiento:

upd_dispersa2. Después de cambiar es estatus a ‘DISPERSADO’ en la tabla de préstamo se ejecuto el siguiente código SQL:

--'250' REGISTRO DE LA DISPERSION

setmovcontable(0,'250',acve,aSolicAmt,adate,aHR,'0','DISPERSION',ausr,adt);

setSaveStatus. En la sección donde se pregunta si el nuevo estatus a cambiar se trata de ‘ACTIVO’ se agrego:

--'251' CANCELACION DE LA DISPERSION

setmovcontable(0,'251',acve,aSolicAmt,achgdt,HR,'1','ACTIVACION',ausr,adt);

--'254' Movimiento contable de la comisión por disposición

(33)

27 setmovcontable(0,'254',acve,aComision,achgdt,HR,'1','ACTIVACION',ausr,adt);

--'258' Movimiento contable de IVA de la comisión por disposición

setmovcontable(0,'258',acve,aIVA ,achgdt,HR,'1','ACTIVACION',ausr,adt);

--'252' Movimiento contable de Intereses por cobrar

setmovcontable(0,'252',acve,aInteres,achgdt,HR,'1','ACTIVACION',ausr,adt);

4.2 PROCESO DE ACTUALIZACIÓN DE VENCIMIENTOS

Como apoyo a la creación de movimientos contables fue necesaria la implementación del nuevo servicio de actualización de vencimientos solicitado por la Subdirección de Operaciones apoyada de la Direccion General para ser instalado en un servidor de Aplicaciones independiente.

Para que ningún otro proceso afectara su inicialización diaria y este pudiera llevarse a cabo sin ningún tipo de problema.

4.2.2 Análisis

Finalmente se necesitaría una nueva herramienta. Es decir, un programa de Pascal que también funcionaria como un servicio de Windows que diariamente verificaría si se ha cumplido la fecha de vencimiento quincenal de cada uno de los créditos activos, en caso afirmativo generará los movimientos contables correspondientes a los vencimientos de pagos de los créditos

4.2.3 Diseño

La herramienta quedó finalmente de la siguiente forma:

Fig. 7. Módulo para ejecutar los movimientos contables de los vencimientos.

Me di a la tarea de programar una nueva aplicación que debía ejecutarse como un servicio y sería ejecutado de manera automática al iniciar el sistema operativo, tal cual fue solicitado en el requerimiento por la Subdirección de operaciones. Con cajas de texto con mascara predefinida permitiría la configuración

(34)

28 de la hora en que se ejecutara el proceso de vencimientos y se seguiría el siguiente algoritmo dentro del sistema. Dentro de la clase principal llamada TFrmUpdVto incluir un TTimer heredando a la súper clase TThread. Cuando la hora de ejecución configurada sea igual a la hora actual del TTimer, la aplicación definirá la fecha del día en el formato YYYYMMDD, se conectaría a la base de datos opcipres_prod y de la tabla calendario cargaría todos aquellos registros cuya fecha de vencimiento (campo fvtodt) sea igual a la previamente definida y que no haya sido previamente procesado (campo fAplicaVto=’F’). Los campos a recuperar con la consulta serian:

fcveedo, fcvecliente y fqnaproc (Clave de entidad, Clave de convenio y Quincena de proceso), en caso de encontrarse registros que cumplan la condición, la nueva aplicación tomaría las claves de los convenios. de la tabla prestamo obtendría todos los créditos que tengan la misma clave de convenio y que se encuentren en estatus Activo (fcvestatus=4). Los campos a recuperar con la consulta fueron: fcvepresta, fqnacapital y fqnainteres (clave del crédito, monto de capital quincenal y monto de interés quincenal). Los registros de créditos que se obtuvieron serían recorridos uno a uno y con la información obtenida se aplicarán los siguientes movimientos contables mediante la ejecución del procedimiento almacenado setMovContable, explicado en el proyecto de la interfaz contable:

•Cancelación parcial del concepto 251 (cobro de capital vigente, concepto 284) con la siguiente asignación de parámetros: aTipo=1 (baja), aCpto=251, aCvePresta=Clave de crédito que esté siendo procesado, aMonto=monto de capital quincenal a descontar (obtenido previamente), aNow=Fecha del proceso, aHora=Hora del proceso, aFlujo=0 (Falso), aComms=’’, aAddUsr=Usuario que realiza el proceso, aAddDt= Fecha en que se aplica el proceso.

•Registro de amortizaciones vencidas exigibles (concepto 375), los datos a registrar son: aTipo=0 (alta), aCpto=375, aCvePresta=Clave de crédito que esté siendo procesado, aMonto=monto de capital quincenal a descontar (obtenido previamente), aNow=Fecha del proceso, aHora=Hora del proceso, aFlujo=0 (Falso), aComms=’’, aAddUsr=Usuario que realiza el proceso, aAddDt= Fecha en que se aplica el proceso.

•Cancelación parcial del concepto 252 (cancelación de los intereses por cobrar, concepto 253) con la siguiente asignación de parámetros: aTipo=1 (baja), aCpto=252, aCvePresta=Clave de crédito que esté siendo procesado, aMonto=monto de interés quincenal a descontar (obtenido previamente), aNow=Fecha del proceso, aHora=Hora del proceso, aFlujo=0 (Falso), aComms=’’, aAddUsr=Usuario que realiza el proceso, aAddDt= Fecha en que se aplica el proceso.

•Provisión de intereses devengados (concepto 265), los datos a registrar son:

aTipo=0 (alta), aCpto=265, aCvePresta=Clave de crédito que esté siendo procesado, aMonto=monto de interés quincenal a descontar (obtenido previamente), aNow=Fecha del proceso, aHora=Hora del proceso, aFlujo=0 (Falso), aComms=’’, aAddUsr=Usuario que realiza el proceso, aAddDt= Fecha en que se aplica el proceso.

Cuando los movimientos contables de cada vencimiento fueron aplicados, registre en un log el total de movimientos aplicados por cada uno de los convenios en