Aplicacion para la gestion de cuotas partes pensionales de la …red.uao.edu.co/bitstream/10614/405/3/TIS00566.pdf · 2019. 9. 17. · 9.4.4 xajax 43 9.4.5 adodb 44 9.5 PRUEBAS 44

APLICACIÓN PARA LA GESTION DE CUOTAS PARTES PENSION ALES DE LA ALCALDIA DE SANTIAGO DE CALI.

JORGE ANDRES CULTID MEJIA

UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERIA INFORMATICA SANTIAGO DE CALI

2009


JORGE ANDRES CULTID MEJIA

2051175

PROYECTO DE GRADO PARA OPTAR EL TITULO DE

INGENIERO INFORMÁTICO

DIRECTOR DIEGO FERNANDO MARIN INGENIERO DE SISTEMAS

UNIVERSIDAD AUTONOMA DE OCCIDENTE FACULTAD DE INGENIERIA

PROGRAMA DE INGENIERIA INFORMATICA SANTIAGO DE CALI

2009

CONTENIDO Pág. INTRODUCCION 1 1. TITULO 2 2. PARTICIPANTES 3 3. PLANTEAMIENTO DEL PROBLEMA 4 4. JUSTIFICACION 5 5. ANTECEDENTES 6 6. MARCO TEORICO 7

6.1 DECRETO No 411.200040 DE 2007 12 6.2 DECRETO 2921 DE 1948 12 6.3 LEY 71 DE 1988 13 6.4 DECRETO 2709 DE 1994 13

7. OBJETIVOS 14

7.1 OBJETIVO GENRAL 14 7.2 OBJETIVO ESPECIFICO 14

8. METODOLOGIA 15

8.1 FASE DE INICIO 15 8.2 FASE ELABORACION 16

8.3 FASE CONSTRUCCION 16 8.4 PRUEBAS 17 8.5 DESPLIGUE 17

9. DESARROLLO DEL PROYECTO 19

9.1 MODELADO DEL NEGOCIO 19

9.2 ESPECIFICACION REQUERIMIENTOS 27 9.3 ANALISIS Y DISEÑO 31

9.3.1 Modelado del software 32 9.3.2 Arquitectura del software 39 9.3.3 Modelado de base de datos 40

9.4 IMPLEMENTACION 43

9.4.1 Base de datos MySQL 43

9.4.2 html 43

9.4.3 php 43

9.4.4 xajax 43

9.4.5 adodb 44

9.5 PRUEBAS 44

10. CONCLUSIONES 49 11. RECOMENDACIONES 51 BIBLIOGRAFIA 52 GLOSARIO 53

LISTA DE ANEXOS

Pág.

Anexo A 52 Anexo B 68 Anexo C 70 Anexo D 73 Anexo E 76 Anexo F 108

1

INTRODUCCIÓN

Un pensionado es aquel trabajador que ha salido de la fuerza laboral por causa de una pensión de vejez, jubilación, invalidez por origen común o profesional. La Alcaldía de Santiago de Cali, como organización que es, está obligada a pagar pensiones, según las normas vigentes, a los jubilados de esta organización. La Alcaldía de Santiago de Cali maneja aproximadamente 1600 pensionados. Existe la posibilidad que el pensionado haya trabajado en otras empresas del estado diferentes a la Alcaldía, y por esta razón a la Alcaldía no le corresponde hacerse cargo de la totalidad de la pensión. Las personas que hayan trabajado en otras empresas del estado, no cobran la totalidad de la pensión a la Alcaldía, la pensión es cobrada según el tiempo trabajado en cada una de las empresas del estado. Por ejemplo, un pensionado trabajo en la gobernación, la cámara de comercio y se pensiona en la Alcaldía. Entonces, la Alcaldía se encargara de pagar su pensión total al pensionado, pero la Alcaldía cobrara la parte correspondiente según el tiempo trabajado a las otras entidades del gobierno en las cuales esta persona trabajo. Por esta razón la alcaldía del municipio ha creado un área de pago y cobro para pensionados llamada, cuotas partes pensiónales, ubicada en el piso 15 del Centro Administrativo Municipal (CAM), que se encarga de hacer estas liquidaciones (Liquidación de capital y liquidación DTF) con respecto a la ley a cada uno de los pensionados para luego realizar los cobros pertinentes. Esta área de la Alcaldía genera sus operaciones manualmente ayudados con la herramienta Microsoft office Excel, teniendo en cuenta que esta área debe resolver estos procedimientos mensualmente a 1600 pensionados aproximadamente, consideramos que es una tarea ardua y difícil, por eso el propósito de este proyecto, crear una aplicación en PHP y BD MySQL, para automatizar estos procesos y mejorar el desempeño de esa tarea.

2

1. TITULO


FASE DE LIQUIDACION.

3

2. PARTICIPANTES

2.1 ESTUDIANTE NOMBRE: Jorge Andrés Cultid Mejía CODIGO: 2051175 PROGRAMA: Ingeniería informática MODALIDAD: Pasantía E-MAIL: [email protected] 2.2 DIRECTOR ACADEMICO DEL PROYECTO NOMBRE: Diego Fernando Marín Lozano CARGO PROFESIONAL: Ingeniero en sistemas - Docente hora cátedra 2.3 ASESOR EMPRESARIAL NOMBRE: Leónidas Andrade Otálora CARGO PROFESINAL: Ingeniero en sistemas – Profesional universitario

4

3. PLANTEAMIENTO DEL PROBLEMA

El área de cuotas partes pensiónales se encarga del cobro y del pago de cuota partistas de más de 1600 pensionados, basados en dos diferentes liquidaciones, liquidación de capital y liquidación DTF. Este proceso debe realizarse mensualmente por cada uno de los pensionados de la alcaldía, lo cual es una tarea difícil y demorada considerando la cantidad de información a manejar y la cantidad de pensionados. Si a esto sumamos que no existe una herramienta automatizada que le ayude a los funcionarios a hacer su trabajo, el trabajo es mucho más largo y difícil. Además que en el proceso no está libre de errores debido a que la información es manipulada manualmente. Un problema aun mayor, es que los funcionarios no cumplieron con los cronogramas de pagos y de cobros, basados en las liquidaciones, debido a la cantidad de pensionados y los pocos funcionarios. Como la alcaldía no cumplió con el cronograma, a la fecha del 29 de julio de 2009, está sujeta a sanciones diarias por ese incumplimiento.

5

4. JUSTIFICACION

En un área donde el manejo de información es muy alto considerando el número de pensionados, esto sumado a las herramientas con las que ellos trabajan hace de su labor una tarea lenta, difícil y propensa a errores. El área de cuotas partes debió liquidar y cuadrar las deudas de las empresas con la alcaldía de las cuentas de los 1600 pensionados que actualmente tiene la alcaldía. Este ajuste debió realizarse antes del 29 de julio de 2009, según decretos de ley. Como no se hizo a tiempo la alcaldía incurrió a faltas con la ley y los pensionados. Esto repercutió en sanciones económicas para la alcaldía a favor de las entidades adeudadas y con los pensionados, los cual le cuestan mucho dinero a la alcaldía. Con el propósito de brindar una herramienta confiable y segura al área de cuotas partes pensiónales, que sea capaz de realizar las mismas tareas que ellos realizan, se debe implementar una aplicación ya que si no se implementa esta herramienta a tiempo el área de cuotas partes pensiónales no podrá alcanzar las metas. La razón de la implementación de realizar esta aplicación radica en que el área no tiene el personal suficiente para las tareas del área, y dado que la aplicación hará mucho más rápido cada liquidación, el personal será suficiente para realizar las liquidaciones, considerando que la alcaldía no cumplió la meta de liquidar los pensionados antes del 29 de julio del 2009 y que la alcaldía está siendo sancionada diariamente, es de suma importancia y urgencia implementar la aplicación de las liquidaciones de los cuotapartistas para hacer mas ágil y confiable la liquidación para así ponerse al día con las liquidaciones para que la alcaldía no siga cayendo en sanciones por el incumplimiento en las cuentas de cobro.

6

5. ANTECEDENTES

El procedimiento que realiza el área de cuotas partes, debe ser realizado por todas las entidades públicas y del estado. En el proceso de investigación sobre los antecedentes del sistema el área de cuotas partes pensionales de la alcaldía de Santiago de Cali consulto otras entidades públicas como la alcaldía de Jamundí, alcaldía de Yumbo, Cajanal, alcaldía de Medellín entre otras. Todas estas empresas deben hacer el mismo procedimiento relacionado a la liquidación de las cuotas partes pensionales, pero las empresas del estado consultadas no tienen o desconoces la utilización de una herramienta de software para la liquidación de las cuotas partes pensionales. Al mismo tiempo la investigación hecha por el área de informática de la alcaldía y el pasante, dio como resultado que se desconoce totalmente la implementación de una herramienta de software relacionada al tema de las liquidaciones de las cuotas partes pensionales. A comienzos del año 2008 el Banco de la República asesoró al personal de cada entidad pública del área de cuotas partes pensiónales con el manejo eficiente de este procedimiento y facilito para el personal una plantilla hecha en Microsoft Office Excel, que permite automatizar las liquidaciones y reducir un poco la carga de trabajo, pero la liquidación debe realizarse por cada uno de los pensionados y también debe manejarse mucha información. Otro problema es que la plantilla solo maneja los cálculos, y el personal debe encargarse del manejo de los oficios.

7

6. MARCO TEORICO

En este punto haremos referencia acerca de las definiciones de los distintos conceptos que se manejaran a lo largo del proyecto, pertinente al área de cuotas partes pensiónales y que incidirán en los objetivos del proyecto en los que nos veremos involucrados directamente. Además se dará una introducción a las tecnologías que haremos uso en este proyecto. Pensionados: Un pensionado es aquel trabajador que ha salido de la fuerza laboral por causa de una pensión de vejez, jubilación, invalidez por origen común o profesional, además, quien recibe una sustitución pensional por la muerte del trabajador. Cuota parte pensional: Es un elemento determinante en la financiación de las prestaciones económicas derivadas de la invalidez, vejez y muerte que se reconozcan ya sea por parte del Instituto de Seguros Sociales o por entidades de derecho público del orden nacional o territorial, descentralizadas territorialmente o por servicios y su proporción se determina a prorrata del tiempo cotizado o laborado en las respectivas entidades. Si un pensionado laboró en entidades del Estado antes del primero de abril de 1994, se debe anexar la certificación del tiempo de servicio, al momento de radicar su solicitud de pensión a efectos de ser tenidos en cuenta para su prestación. Cuando se analiza la viabilidad de reconocer una prestación económica, es la entidad que va a reconocer, la encargada de consultar las cuotas partes correspondientes y a su vez las entidades consultadas deberán pronunciarse sobre dicha consulta aceptando u objetando la cuota. La entidad que reconoce la prestación, paga la totalidad de la misma y posteriormente repite contra la (s) entidad (es) concurrente (s) en un proceso tendiente a obtener el pago de dichas cuotas, procedimiento que no involucra al pensionado.1 Es decir, el proceso de cuotas partes es de carácter inter-administrativo, que no le corresponde al asegurado tramitar, toda vez que se efectúa por la entidad que reconoce la pensión para financiar la misma.

1 Decreto 1513 de 1998. Bogotá D.C. Agosto, 1998, Diario Oficial No. 43.357

8

Liquidación de capital: La liquidación de capital es una operación que se realiza para calcular el valor de las pensiones con su respectivo ajuste en salud año por año, a partir de la fecha de aceptación de la jubilación del pensionado, en base a unos cálculos aritméticos que relacionan el valor de la pensión, los aumentos dictados por la ley y los ajustes en salud. Esta liquidación debe ser realizada a cada uno de los pensionados de la alcaldía. Se debe realizar partir de la fecha de aceptación de la pensión hasta la fecha actual. Liquidación DTF 2: La liquidación DTF es una operación muy parecida a la liquidación de capital, solo que la liquidación DTF se realiza discriminado cada mes de cada año teniendo en cuenta las dos mesadas adicionales en junio y diciembre denominadas primas. También tiene en cuenta el valor de la pensión y el valor de los ajustes en salud, además que tiene en cuanta unos intereses mensuales dictados por el banco de la republica. La liquidación de DTF se debe realizar a partir de julio del 2006 hasta la fecha. Diseño Web: El diseño Web es el proceso de conceptualización, planificación, modelado y ejecución de páginas Web. El objetivo principal de este diseño es la creación de una página Web en la intranet de la alcaldía. A principios del Desarrollo Web, el diseño Web representaba la creación de páginas HTML (lenguaje de marcas de hipertexto) estáticas con texto y gráficos enlazados. El entorno de hoy en día incluye la creación de sitios Web dinámicos que utilicen otros lenguajes de programación (php, javascript3, .NET4) para interactuar con las bases de datos y los navegadores, junto las páginas HTML, los gráficos y el CSS5 (Hojas de estilo en cascada).

2 Son las iniciales de depósitos a término fijo. La DTF es una tasa o porcentaje muy utilizada, principalmente en el sistema financiero. Se calcula como el promedio ponderado de las diferentes tasas de interés de captación utilizadas por los bancos, corporaciones financieras, corporaciones de ahorro y vivienda y compañías de financiamiento comercial para calcular los intereses. 3 Es un lenguaje de scripting basado en Objetos, utilizado para acceder a objetos en aplicaciones. Es utilizado, principalmente, integrado en un navegador web permitiendo el desarrollo de interfaces de usuario mejoradas y páginas web dinámicas. 4 Es un proyecto de Microsoft para crear una nueva plataforma de desarrollo de software con énfasis en transparencia de redes, con independencia de plataforma de hardware y que permita un rápido desarrollo de aplicaciones. 5 Es un lenguaje de hojas de estilo usado para describir la semántica de la presentación (es decir, el aspecto y el formato) de un documento escrito en un lenguaje de marcas. Its most common application is to style web pages written in HTML and XHTML, but the language can be applied to any kind of XML document, including SVG and XUL. Su aplicación más común es que las páginas web de estilo escrito en HTML y XHTML, pero el lenguaje se puede aplicar a cualquier tipo de documento XML, incluyendo SVG y XUL.

9

La idea de seguir un diseño web es para mantener un plan de acción sobre cómo realizar el proyecto. Así se sabrá exactamente lo que se debe hacer y las metas a cumplir para cubrir el objetivo final de una forma clara y precisa y mantener un orden para posteriores revisiones o mantenimiento de la aplicación. Al ser un proceso conceptual, es algo que puede ser modificado y manipulado a nuestra medida, no son reglas que se deben seguir al pie de la letra o que estén escritas en algún libro, es algo abstracto que nos sirve para planear y seguir un mapa para realizar nuestra aplicación según nuestra necesidad. Servidor WEB [3]: Un servidor web es un programa que implementa el protocolo HTTP6. Este protocolo pertenece a la capa de aplicación del modelo OSI7 y está diseñado para transferir lo que llamamos hipertextos, páginas web o páginas HTML, textos complejos con enlaces, figuras, formularios, botones y objetos incrustados como animaciones o reproductores de música. Sirve contenido estático a un navegador. Carga un archivo y lo sirve a través de la red al navegador de un usuario. Es un programa que se ejecuta continuamente en un ordenador, manteniéndose a la espera de peticiones por parte de un cliente y que responde a estas peticiones adecuadamente, mediante una página web que se exhibirá en el navegador o mostrando el respectivo mensaje si se detectó algún error. Un servidor web se mantiene a la espera de peticiones HTTP por parte de un cliente HTTP que solemos conocer como navegador. El cliente realiza una petición al servidor y éste le responde con el contenido que el cliente solicita.

Base de datos MySQL [4]: es un sistema de gestión de base de datos relacional, multihilo y multiusuario. En esta base de datos estarán los datos pertenecientes a un mismo contexto y almacenados para que puedan hacer usados posteriormente para hacer las liquidaciones.

6 HyperText Transfer Protocol es el protocolo usado en cada transacción de la Web (WWW). HTTP fue desarrollado por el consorcio W3C y la IETF 7 El modelo de referencia de Interconexión de Sistemas Abiertos (OSI, Open System Interconnection) fue el modelo de red descriptivo creado por la Organización Internacional para la Estandarización lanzado en 1984. Es decir, fue un marco de referencia para la definición de arquitecturas de interconexión de sistemas de comunicaciones.

10

Los datos almacenados son los datos estrictamente necesarios para realizar las liquidaciones y estructurados según un determinado modelo de información que refleja no solo los datos en si mismos, sino también las relaciones que existen entre ellos. La base de datos se diseño con un propósito específico y se organizo con una logia coherente. MySQL se ofrece bajo la GNU GPL8 para cualquier uso compatible con esta licencia, pero para aquellas empresas que quieran incorporarlo en productos privativos deben comprar a la empresa una licencia específica que les permita este uso. MySQL es una base de datos muy rápida en la lectura cuando utiliza el motor no transaccional MyISAM9, pero puede provocar problemas de integridad en entornos de alta concurrencia en la modificación. En aplicaciones web hay baja concurrencia en la modificación de datos y en cambio el entorno es intensivo en lectura de datos, lo que hace a MySQL ideal para este tipo de aplicaciones. Por estas rezones MySQL es la base de datos elegida ya que se ajusta a las necesidades de la aplicación. PHP [6]: PHP es el acrónimo de Hipertext Preprocesor. Es un lenguaje de programación del lado del servidor gratuito e independiente de plataforma, rápido, con una gran librería de funciones y mucha documentación. PHP se escribe dentro del código HTML, lo que lo hace realmente fácil de utilizar, al igual que ocurre con el popular ASP de Microsoft, pero con algunas ventajas como su gratuidad, independencia de plataforma, rapidez y seguridad Es un lenguaje que es interpretado del lado del servidor, tomando el código en PHP como su entrada y creando páginas web como salida.

8 La Licencia Pública General de GNU o más conocida por su nombre en inglés GNU General Publical License o simplemente su acrónimo del inglés GNU GPL, es una licencia creada por la Free Software Foundation en 1989 (la primera versión), y está orientada principalmente a proteger la libre distribución, modificación y uso de software. 9 MyISAM es la tecnología de almacenamiento de datos usada por defecto por el sistema administrador de bases de datos relacionales MySQL. Este tipo de tablas están basadas en el formato ISAM pero con nuevas extensiones.

11

Puede ser desplegado en la mayoría de los servidores web y en casi todos los sistemas operativos y plataformas sin costo alguno Cuando el cliente hace una petición al servidor para que le envíe una página web, el servidor ejecuta el intérprete de PHP. Éste procesa el script solicitado que generará el contenido de manera dinámica (por ejemplo obteniendo información de una base de datos). El resultado es enviado por el intérprete al servidor, quien a su vez se lo envía al cliente. HTML: Siglas de HyperText Markup Language (Lenguaje de Marcas de Hipertexto), es el lenguaje de marcado predominante para la construcción de páginas web. Es usado para describir la estructura y el contenido en forma de texto, así como para complementar el texto con objetos tales como imágenes. HTML se escribe en forma de "etiquetas", rodeadas por corchetes angulares (<,>). HTML también puede describir, hasta un cierto punto, la apariencia de un documento HTML es el lenguaje con el que se definen las páginas web. Básicamente se trata de un conjunto de etiquetas que sirven para definir el texto y otros elementos que compondrán una página web. HTML es un lenguaje de marcación de elementos para la creación de documentos hipertexto, muy fácil de aprender, lo que permite que cualquier persona, aunque no haya programado en la vida, pueda enfrentarse a la tarea de crear una web. El diseño en HTML aparte de cumplir con las especificaciones propias del lenguaje debe respetar unos criterios de accesibilidad web, siguiendo unas pautas, o las normativas y leyes vigentes en los países donde se regule dicho concepto. ADODB [5]: es un conjunto de bibliotecas de bases de datos para PHP y Python10. Esta permite a los programadores desarrollar aplicaciones web de una manera portable, rápida y fácil. La ventaja reside en que la base de datos puede cambiar sin necesidad de reescribir cada llamada a la base de datos realizada por la aplicación.

10 Python es un lenguaje de programación interpretado creado por Guido van Rossum en el año 1991. En la actualidad Python se desarrolla como un proyecto de código abierto, administrado por la Python Software Foundation. Python se utiliza como lenguaje de programación interpretado, lo que ahorra un tiempo considerable en el desarrollo del programa, pues no es necesario compilar ni enlazar.

12

Cabe notar que ADOdb usa SQL. Teniendo en cuenta que cada base de datos implementa SQL de una manera levemente diferente, es trabajo del desarrollador prestar cuidadosa atención a las características y funciones específicas de la base de datos para mantener la portabilidad del código. Actualmente ADODB maneja MySQL, Oracle, Microsoft SQL Server, Sybase, Sybase SQL Anywhere, Informix, PostgreSQL, FrontBase, SQLite, Interbase (versiones de Firebird y Borland), Foxpro, Access, ADO, DB2, SAP DB and ODBC. Es una librería compatible con PHP.

AJAX: Xajax es una biblioteca código abierto de PHP capaz de generar aplicaciones Web con tecnología AJAX.

Xajax es una biblioteca de código abierto para PHP que permite crear de manera fácil y simple aplicaciones Web basadas en AJAX usando además HTML, CSS, y Javascript. Las aplicaciones desarrolladas con Xajax pueden comunicarse asíncronamente con funciones que se encuentran del lado del servidor y así actualizar el contenido de una página sin tener que recargarla nuevamente. Marco normativo (Hacemos énfasis a los artículos le gales referentes al aplicativo) Decreto No 411.20.0040 de 2007 (Anexo A) [1] Descripción y recomendaciones de los procedimientos del área de cuotas partes. Este decreto describe la forma correcta de operación del área de cuotas partes y de cómo debemos realizar el aplicativo sin salirnos del marco legal que lo rige. Decreto 2921 de 1.948 (Anexo B) 11 Decreto que explica el procedimiento de aceptación de los cuota partistas involucrados en la pensión de un jubilado y su proceder.

11Decreto 2921 de 1948. Bogota D.C. Agosto, 1948, Diario Oficial No 26.811Decreto 1513 de 1998.

13

Ley 71 de 1.988 12 (Anexo C) Ley que nos indica los beneficiarios de esta pensión, en caso de que el pensionado no pueda hacerse responsable de la misma y determina también el momento de liquidación de la cuenta del pensionado por parte del aplicativo. Decreto 2709 de 1994 13 (Anexo D) Decreto que contiene la legalidad del proceso de cuotas partes y el artículo que involucra el tiempo de trabajo del jubilado.

12 Ley 71 de 1988, Bogota D.C. Diciembre, 1988, Diario Oficial No. 38.624 13Decreto 2709 de 1994, Bogota D.C. Diciembre, 1994, Diario Oficial No. 41.635

14

7. OBJETIVOS

7.1 OBJETIVO GENERAL

Construir un software que permita efectuar la liquidación de las cuotas partes de manera regular y conforme a la exigencias de la normatividad vigente (Reglamento interno de cartera decreto No 411.20.0040 de febrero 8 de 2007)

7.2 OBJETIVOS ESPECIFICOS

• Identificar las necesidades del área de cuotas partes basándonos en la problemática.

• Analizar los procesos del departamento de cuotas partes.

• Estudiar y comprender todo el proceso de gestión documental dentro del área de cuotas partes.

• Diseñar un software que de solución eficaz y eficiente al problema actual del departamento de cuotas partes.

• Realizar la documentación necesaria para la comprensión y el desarrollo de la aplicación.

• Desarrollar el aplicativo basándose en la documentación y cumpliendo con los requerimientos solicitados.

• Implantar la aplicación en el departamento de cuotas partes con la debida capacitación para un optimo uso.

• Realizar las pruebas necesarias para garantizar la calidad del aplicativo.

15

8. METODOLOGIA

En el desarrollo de este proyecto la metodología a emplear es de tipo empírico analítica con un impacto social reflejada en los usuarios de cuotas partes pensiónales. La siguiente metodología, fue ajustada al proyecto en base a la metodología propuesta en el libro “Ingeniería de software” [7] de Ian Sommerville.

FASE DE INICIO

Modelado del negocio En esta fase el equipo se familiarizará más al funcionamiento de la empresa, sobre conocer sus procesos.

• Reunión con las directivas del departamento de cuotas partes pensiónales.

• Entender la estructura y la dinámica de la organización para la cual el sistema va ser desarrollado.

• Entender el problema actual.

• Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común de la organización objetivo.

Requisitos En esta línea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que especifiquemos.

• Reunión con las directivas para definir requerimientos.

• Levantamiento de requerimientos.

• Restablecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema podría hacer.

16

• Proveer a los desarrolladores un mejor entendimiento de los requisitos del

sistema.

FASE DE ELABORACIÓN

En la fase de elaboración, abarcan más los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), análisis. Análisis y Diseño En esta actividad se especifican los requerimientos y se describen sobre como se van a implementar en el sistemas.

• Transformar los requisitos al diseño del sistema al lenguaje entendido por nosotros.

• Descripción de los procesos.

• Desarrollar una arquitectura para el sistema.

• Adaptar el diseño para que sea consistente con el entorno de implementación.

• Clasificar los requerimientos según su importancia.

• Realizar los diferentes diagramas para entendimiento y desarrollo del software. (Anexo E )

FASE DE CONSTRUCCIÓN

Implementación Se implementan los ficheros fuente, binarios, ejecutables y demás. El resultado final es un sistema ejecutable.

17

• Planificar qué subsistemas que deben ser implementados y en qué orden

deben ser integrados.

• El desarrollador decide en qué orden implementa los elementos del subsistema.

• El desarrollador implementará el código necesario para desarrollar cada modulo.

• Si encuentra errores de diseño, los corrige.

PRUEBAS

Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando.

• Encontrar y documentar defectos en la calidad del software.

• Verificar las funciones del producto de software según lo diseñado (Anexo F).

• Verificar que los requisitos tengan su apropiada implementación.

• Verificar la funcionalidad comparando con los requerimientos y los

objetivos.

DESPLIEGUE

Esta actividad tiene como objetivo producir con éxito distribuciones del producto y distribuirlo a los usuarios.

• Probar el producto en su entorno de ejecución final.

• Empaquetar el software para su distribución.

• Distribuir el software.

18

• Instalar el software.

• Proveer asistencia y ayuda a los usuarios.

• Formar a los usuarios y al cuerpo de ventas.

19

9. DESARROLLO DEL PROYECTO

9.1 MODELADO DEL NEGOCIO Comprensión del problema ENUNCIADO: Reunión con el personal del área de cuotas partes pensiónales para que explicaran el procedimiento de las liquidaciones que corresponden al área de cuotas partes pensiónales. PORBLEMA: La no automatización de las liquidaciones de los pensionados con respecto a los cuota artistas. Proceso

Análisis del problema

Tabla 1. Definición de variables de salida.

Nombre Descripción Liquidación DTF La liquidación DTF sale mensualmente

del resultado de hacer las diferentes operaciones, con los intereses de DTF mensuales dictados por el banco de la república, regidas por la ley para este procedimiento.

Liquidación Capital La liquidación de capital sale como resultado de las operaciones realizadas anualmente con los aumentos autorizados por la ley que regirá todo ese

20

año liquidado. Tabla 2. Definición de variables de entrada.

Nombre Descripción Datos del pensionado

Datos básicos y necesarios para la realización de las diferentes liquidaciones: Cedula , Nombre , apellido , Fecha nacimiento . * Fecha ingreso, Valor pensión , No Resolución de jubilación , No Resolución de reliquidación, Fecha jubilación , Fecha aceptación , Fecha reajuste en salud, Resolución de ajuste, Fecha última consulta, Fecha último pago de pensión. * No resolución sustituto, Fecha fallecimiento pensionado, Cedula sustituto, Nombre del sustituto, Apellido sustituto.

Datos de la entidad Datos básicos de la entidad también necesarios para las liquidaciones: Nit, Nombre de la entidad, Dirección, Teléfono, Contacto .

• Los datos en negrilla son obligatorios para la liquidación.

Proceso

Para las dos liquidaciones (capital y DTF) se realiza el mismo procedimiento inicial. Se debe revisar la resolución donde se aprueba el pago de la pensión para el jubilado. Esta resolución trae todos los datos del pensionado y de las diferentes entidades en las que trabajó. Las liquidadoras empiezan a llenar un plantilla en Excel con los datos importantes para la liquidación. A partir de la fecha de jubilación, la cuota parte correspondiente a la liquidación, la pensión del jubilado , se empieza a realizar la liquidación de capital. Las dos liquidaciones tienen en cuenta los aumentos anuales autorizados por ley según el salario del pensionado. Partir de esos datos y los que ya se saben

21

del pensionado se empieza a calcular, con las formulas, los nuevos datos correspondientes a la pensión y a la parte correspondiente de la entidad. Formulas (Pág. 22) y ejemplos (Pág. 20 y 21).

22

Figura1. Liquidación de capital.

23

Figura 2. Liquidación DTF

24

FORMULAS

Figura 3. Formulas liquidación de capital

M = Valor de la cuota parte / Valor de la pensión A = Valor pensión mes * M B = A * 1.07 * Se calcula partir del periodo 1996

C = (B * X) + (A * W): Si periodo < 1976 entonces W =12 y X = 0; Si 1976 < = periodo < 1994 entonce s W = 13 y X = 0; Si periodo > = 1994 entonces W = 2 y X = 12.

D = Valor de la pensión mensual del año anterior * aumento del año actual + aumento adicional del año actual

E = D * M; F = E * 1.07 * Se calcula partir del periodo 1996; L = Sumatoria de valor cuota anual en todos los periodos

25

Figura 4. Formulas liquidación DTF

El primer dato del valor pensión anual es obtenido de la liquidación por capital correspondiente al año 2006.

T = Valor cuota parte / Valor pensión mes A = Valor pensión mensual * T; B = A * 7%; C = A + B D = C * (1 + TASA MES)

F = Valor de la pensión mensual del año anterior * aumento del año actual + aumento adicional del año actual E = D – C G= (D + C)*(1 + TASA MES) H = G – C – D I = F * T J = I * 7% K = I + J L = ∑ cuota mensual con reajuste M = ∑ Cuota mensual acumulada N = ∑ Valor intereses

26

Tabla 3. Definición de variables de Proceso.

Nombre Descripción Aumento Aunque el aumento es una constante q el

gobierno da cada año, a veces por algunos decretos debe ser modificada durante el proceso de algunas liquidaciones.

Aumento adicional Al igual q el aumento el aumento adicional es una constante también puede ser modificable durante el proceso de liquidación. Esto dictado por algún decreto.

Porcentaje del cuota partista

Esta variable es calculada durante el proceso, al insertar la cuota parte y el valor de la pensión del pensionado. Es usada para calcular el valor mensual del cuota partista.

Valor pensión mes Este valor se va incrementado según los aumentos determinados por el gobierno, así q cada año el valor de la pensión será diferente.

Valor cuota mensual Es la parte a pagar correspondiente a la entidad que se va incrementando cada año, según los aumentos determinados por la ley

Reajuste en salud A partir del año 1996 el gobierno autoriza el pago de un auxilio de salud, este se va incrementando según se incremente el valor de la pensión anualmente.

Valor cuota anual Es el valor correspondiente a pagar con el valor de la pensión y el reajuste en salud según los determinados año.

Tasa mes Es el interés mensual que será utilizado en la liquidación DTF

Cuota mensual acumulada

Es el valor cuota mensual con reajuste multiplicado por el interés para saber su valor mensual

Valor intereses Es el valor total que se debe pagar mensualmente teniendo en cuenta el interés.

27

9.2 ESPECIFICACION DE REQUERIMIENTOS

Acta de Reunión para Requerimientos

Fecha Versión Descripción Autor 1.0 Primera versión Jorge Cultid

Responsables: Doctora Nelcy Lara, Angélica Chaux, Jorge Andrés Cultid Mejía Participantes: Jorge Andrés Cultid – pasante, Leonidas Andrade – Asesor

empresarial, Doctora Nelcy Lara, Angelica Chaux - liquidadora Temas tratados:

� Alcance inicial

� Requerimientos relevantes

Alcance inicial: Se discutieron aspectos referentes al alcance del sistema, como ser la estimación y tamaño. Se acordó a su vez la validación del alcance por parte del cliente, siendo esta de carácter formal. El alcance quedo definido hasta donde el sistemas pueda generar las dos liquidaciones (capital y DTF), insertando los datos mencionados en la resolución antes mencionados. El sistema también deberá permitir la consulta de estas liquidaciones.

28

Requerimientos relevantes:

• El aplicativo debe guardar los datos de la resolución (datos relacionados al pensionado y la entidad)

• Que el aplicativo realice la liquidación de las cuotas partes pensionales por cobrar.

• Que se pueda ingresar los nuevos pensionados y dar de baja a los que definitivamente ya cesaron.

• Que discrimine el capital y los intereses DTF causados mensualmente.

• Que se puedan consultar las diferentes liquidaciones realizadas por el sistema.

• Que se pueda ingresar las nuevas entidades y dar de baja y/o modificar las que ya no existen.

• Que se pueda ingresar los aumentos y los intereses DTF autorizados por el gobierno nacional.

Resumen de Usuarios

Nombre Descripción ADMINISTRADOR Usuario global del sistema. Responsable de

definir los perfiles de usuario. Se hace cargo de las modificaciones y de la inactivación de funciones.

LIQUIDADORA Encargadas de realizar las inserciones y realizar las liquidaciones y las consultas.

Entorno de usuario Los usuarios entrarán al sistema identificándose sobre un ordenador con un sistema operativo Windows XP y tras este paso entrarán a la parte de aplicación según su perfil. Este sistema es similar a cualquier aplicación WEB y por tanto los usuarios estarán familiarizados con su entorno.

29

Perfiles de Usuario

Administrador

Representante Abogada Nelcy Lara Descripción Jefe del área de cuotas partes pensiónales Tipo Administrador Responsabilidades Responsable del área de cuotas partes

pensiónales, quien define las funciones de las liquidadoras en el área y el sistema.

Liquidadora

Representante Liquidadoras Descripción Profesionales encargadas de las

liquidaciones de los pensionados Tipo Usuario Responsabilidades Responsable de las liquidaciones y de las

consultas del sistema.

30

Listado de requerimientos encontrados por el progra mador

1. Iniciar sesión.

2. Insertar usuario. 3. Modificar usuario. 4. Inactivar usuario. 5. Insertar pensionado. 6. Modificar datos pensionado. 7. Inactivar Pensionado.

8. Insertar sustituto. 9. Modificar Sustituto. 10. Inactivar sustituto.

11. Insertar Entidad. 12. Inactivar Entidad. 13. Modificar Entidad.

14. Insertar Aumento. 15. Modificar Aumento. 16. Eliminar Aumento. 17. Consultar Aumento.

18. Insertar interés DTF. 19. Eliminar tasa DTF. 20. Modificar interés DTF. 21. Consultar tasa DTF.

22. Liquidar cuota parte por capital. 23. Liquidar cuota parte por DTF. 24. Consultar liquidación de capital. 25. Consultar liquidación DTF

31

9.3 ANALISIS Y DISEÑO La estructura de módulos es una estructura que nos permite modelar y tener una visión global del sistema. Descomponiendo el sistema en subsistemas o en subtareas de menor complejidad. Así al dar solución a cada modulo daremos solución a cada tarea y al terminar cada uno de los módulos se dará solución a todo el problema en general. La metodología de programación solicitada por el cliente era que fuera de una forma estructural pero que no fuera orientado a objetos. Por eso la forma elegida para modelar e identificar en forma global el sistema era con la estructura de módulos que igual daría una visión global del sistema e identificaríamos sub problemas para identificar. Para el diseño e interpretación del software, dado que es programación estructurada, se deicidio por diseña diagramas de contexto hasta el 3 nivel, donde se puede identificar, describir e interpretar cada uno de los procesos del sistema. Para el diseño más detallado y el diseño de cada uno de los modulo, se decidió hacer Diagramas de flujo de datos (DFD) que nos muestra la interacción y el funcionamiento abstracto de cada uno de los subsistemas.

32

9.3.1 Modelado del Software Figura 5. Estructura de módulos

33

DISEÑO

Figura 6. Diagrama de Contexto - Nivel 0

34

Figura 7. Diagrama de contexto – Nivel 1

35

Figura 8. Diagrama de contexto – Nivel 2 - Liquidac iones

36

Figura 9. Diagrama de contexto nivel 3 Liquidación de capital

Figura 10. Diagrama de contexto nivel 3 Liquidación DTF

37

Diagramas de Flujo de Datos (DFD) del sistema Figura 11. Generar Liquidación de Capital - 1.6.4. 1.1

38

Figura 12. Generar Liquidación DTF - 1.6.4.2.1

39

9.3.2 ARQUITECTURA DEL SOFTWARE La arquitectura en la que está basada la aplicación es una arquitectura cliente - servidor. La arquitectura cliente servidor es un modelo para desarrollar sistemas de información en el que las operaciones se dividen en procesos independientes que cooperan entre sí para intercambiar información, servicios o recursos. En este modelo las aplicaciones se dividen de forma que el servidor contiene la parte que debe ser compartida por varios usuarios, y en el cliente permanece sólo lo particular de cada usuario. En la arquitectura cliente – servidor, los procesos se reparten ente los clientes de la aplicación y el servidor donde se encuentra la aplicación. En algunos casos el cliente y el servidor pueden ser la misma máquina. Como ha sido el proceso de desarrollo de esta aplicación. En la puesta en marcha de la aplicación las liquidadoras accederán al sistema por medio de la intranet donde encontraran la interfaz de usuarios. Allí el código HTML y JAVASCRIPT serán ejecutados en la máquina de las liquidadoras, pero el proceso de guardar, consultar y generar liquidaciones entre otras será hecho por la lógica del negocio que lo realiza la aplicación en el servidor. Se eligió esta arquitectura porque es el modo de desarrollo que maneja el área de informática de la alcaldía, debido a que todas las aplicaciones anteriormente desarrolladas fueron desarrolladas en esta misma arquitectura, y es deseo del área de informática unificar todas las aplicaciones en un sistema mayor de trámites en la alcaldía, y para eso se debía realizar todas las aplicaciones con la misma arquitectura.

40

Figura 13. Arquitectura del software

9.3.3 Modelo de base de datos La base de datos escogida para el desarrollo de la aplicación es un tipo de base de datos relacional. La base de datos relacional es un tipo de BD que ofrecen muchos tipos de procesos de datos. Tiene como característica la simplicidad, la generalidad, facilidad de uso para el usuario final, períodos cortos de aprendizaje y las consultas de información se especifican de forma sencilla. La forma de de representación y almacenamiento de los datos se hace en tablas. Esta forma de almacenamiento es compacta y es posible acceder a la información contenida en dos o más tablas.

41

En general las bases de datos relacionales están constituidas por una o más tablas, incluso los resultados de cualquier consulta son otra tabla, que contienen la información ordenada de una forma organizada, que están relacionadas entre sí por algún campo de la tabla. La base de datos relacionales tiene dos secciones, el esquema o los datos. El esquema es la estructura de la base de datos, como nombre de la tabla, nombre del campo, tipo de dato. Y los datos son lo que se almacenará en estas tablas.

• Las tablas están compuestas por filas y columnas.

• Cada tabla tiene una clave primaria , un identificador único, compuesto por una o más columnas.

• La mayoría de las claves primarias están formadas por una única columna, pero pueden ser varias columnas o datos, ser llave primaria.

• Para establecer una relación entre dos tablas es necesario incluir, en forma de columna, en una de ellas la clave primaria de la otra. A esta columna se le llama clave secundaria.

La planificar el tipo de información que se iba a almacenar, se tuvo en cuenta la información disponible y la información necesaria, para garantizar un óptimo funcionamiento de la base de datos y la aplicación. Dado la necesidad de sencillez, seguridad, integridad y robustez que se necesitaba para el almacenamiento de datos, se decidió por la base de datos relacional que suplía todas las necesidades anteriormente nombradas. Comparando con otro tipo de bases de datos, como la analítica o jerárquico. El analítico es una base de datos orientada a proyecciones al futuro que solo permite lectura y el modelo jerárquico no representa eficientemente la redundancia de datos. Así, el modelo jerárquico puede representar dos tipos de relaciones entre los datos: relaciones de uno a uno y relaciones de uno a muchos. Estos modelos no satisfacen los requerimientos del software, por ese se decidió por el tipo de base de datos relacionales, que nos permitía los procesos necesario sobre los datos y nos permitía el manejo eficiente de la redundancia de datos.

42

Para el moldeamiento de esta base de datos se decidió por el Modelo Entidad – Relación (MER), una herramienta de modelado para representar las entidades, propiedades y relaciones. El MER es el modelo más utilizado para el diseño conceptual de bases de datos. Muestra una versión simplificada de la base de datos y representa los datos mediante una serie de entidades que disponen de atributos. Una entidad es una clase de objetos o conceptos claramente identificable en el mundo real y establecen interrelaciones con otras entidades por medio de las llaves primarias y foráneas. El diagrama resultante del MER, es un diagrama que nos permite ver con claridad el modelado de datos. Nos muestra las entidades y sus atributos. Por esa misma razón es fácil interpretar también los módulos (subprogramas) necesarios para la aplicación. Figura 14. Modelo entidad relacion – Liquidacion de cuotas partes pensionales.

43

9.4 IMPLEMENTACION

9.4.1 Base de datos mysql: La base de datos utilizada para la implementación del proyecto es MySQL. Esta base de datos es un sistema de gestión de datos relacional, perfecta para el desarrollo de nuestra base de datos que como dijimos con anterioridad seria una base de datos relacional, además es uno de los RDBMS más completos destacándose por su soporte de transacciones, estabilidad, escalabilidad y soporte multiplataforma. Además es la base de datos que la alcaldía tiene licencia y en la cual están montadas todas las bases de datos de sus aplicaciones de trámites de la alcaldía. 9.4.2. html Debido a que será un aplicación web se decidió por realizar la interfaz en HTML, que es un lenguaje predominante en el mercado y que ayuda a la realización de una interfaz simple, fácil de realizar y amena al usuario. Además por deseo del área de informática y telemática, se debía realizar en HTML para la integración con los otros sistemas de trámites que se hará en el futuro. 9.4.3 php PHP es un lenguaje de programación interpretado, que sirve para la creación de páginas web dinámicas y transaccionales. Es usado usualmente en interpretación del lado del servidor, en la arquitectura cliente – servidor. Además es un código que puede ser embebido en HTML. También fue seleccionado este lenguaje para el desarrollo porque es un lenguaje desplegado por casi todos los tipos de servidores y en casi todos los sistemas operativos. Además las demás aplicaciones de la alcaldía son realizadas en PHP, por lo cual para su futura integración, fue solicitud de la alcaldía que la aplicación fuera desarrollada en PHP. 9.4.4 xajax XAJAX es una librería de código abierto en PHP, capaz de generar aplicaciones web con tecnología AJAX, usada para realizar peticiones de contenido o

44

computación de servidor sin tener que recargar la página en la que está el usuario. Gracias a que no es necesario recargar la pagina para mostrar las peticiones, se escogió esta tecnología para mostrar las diferentes operaciones sin necesidad de recargar la interfaz del usuario y disminuir la capacidad de red. Además hace más presentable la interfaz para el usuario. 9.4.5 adodb Es un conjunto de librerías de bases de datos para PHP y Phyton. Esta permite a los programadores desarrollar aplicaciones web de una manera portable, rápida y fácil. La ventaja reside en que la base de datos puede cambiar sin necesidad de reescribir cada llamada a la base de datos realizada por la aplicación, esto lo hace portable, además es un librería que ha sido utilizada en anteriores aplicaciones en la alcaldía, entonces la aplicación podría usar la misma librería ADODB que usan las otras aplicaciones de trámites y reducir la cantidad de archivos en el servidor. 9.5 PRUEBAS Las pruebas hechas a la aplicación son pruebas funcionales, que tienen por objetivo probar que los sistemas desarrollados, cumplan con las funciones específicas para los cuales han sido creados. Estas pruebas se realizaron con el usuario final. A este tipo de pruebas se les denomina también pruebas de comportamiento o pruebas de caja negra, ya que los analistas de pruebas, no enfocan su atención a como se generan las respuestas del sistema, básicamente el enfoque de este tipo de prueba se basa en el análisis de los datos de entrada y en los de salida y si da conformidad a los requerimientos hechos por el cliente. Esta etapa fue la última del proceso de desarrollo del proyecto. Al dar conformidad a este proceso, se podrá proceder a la fase de producción.

45

PROYECTO: LIQUIDACION CUOTAS PARTES PENSIONALES

PRUEBA FUNCIONAL

MODULO: GENERAR LIQUIDACION DE CAPITAL

Fecha:

Responsables: Jorge Andrés Cultid Mejía

Identificador: 1.6.4.1.1

Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos, en el menú, la opción de generar una liquidación de capital.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. Deben existir aumentos. Debe existir el pensionado a liquidar. Debe existir la entidad con la cual se va a liquidar.

Entrada - Introducimos el usuario.

- Introducimos contraseña.

- Iniciamos sesión.

- Nos aparece la interfaz del menú del sistema.

- Seleccionamos en Liquidaciones la opción de liquidación pensionado- capital.

- Completamos todos los campos relacionados a la liquidación.

- Pulsamos el botón Aceptar .

- El sistema genera la liquidación.

- El usuario hace las modificaciones que considere necesarias en los aumentos.

- Si el usuario quiere guarda la liquidación. En este caso se guarda la liquidación.

- El sistema inserta en la base de datos los datos de la liquidación.

Resultado Esperado - El sistema guardo satisfactoriamente los datos de la liquidación y mostro el respectivo mensaje exitoso.

Resultado Obtenido Prueba Exitosa SI(X) NO( )

Comentarios Las pruebas se hicieron con el usuario ADMINISTRADOR.

46


PRUEBA FUNCIONAL

MODULO: CONSULTAR LIQUIDACION DE CAPITAL

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos, en el menú, la opción de consultar la liquidación del pensionado.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. Debe existir ya la liquidación para el pensionado.





- Seleccionamos en LIQUIDACIONES la opción de consultar liquidación.

- Completamos los datos del pensionado y la entidad.

- Pulsamos el botón CONSULTAR.

- El sistema nos mostro la liquidación del pensionado.

Resultado Esperado - El sistema mostro la liquidación del respectivo pensionado.



47


PRUEBA FUNCIONAL

MODULO: GENERAR LIQUIDACION DTF

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos, en el menú, la opción de generar una liquidación DTF.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. Deben existir aumentos. Debe existir el pensionado a liquidar. Debe existir la entidad con la cual se va a liquidar. Deben existir intereses DTF para liquidar.





- Seleccionamos en Liquidaciones la opción de liquidación pensionado- DTF.



- El sistema genera la liquidación DTF.


- Si el usuario quiere guarda la liquidación DTF. En este caso se guarda la liquidación.

- El sistema inserta en la base de datos los datos de la liquidación DTF.




48


PRUEBA FUNCIONAL

MODULO: CONSULTAR LIQUIDACION DTF

Fecha:




Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. Debe existir ya la liquidación DTF para el pensionado.





- Seleccionamos en LIQUIDACIONES la opción de consultar liquidación DTF.


- Pulsamos el botón ACEPTAR.

- El sistema nos mostro la liquidación DTF del pensionado.




49

10. CONCLUSIONES

En el desarrollo de este proyecto se dio cumplimiento a los objetivos planteados inicialmente por el quipo de trabajo. Para el analista y desarrollador quedo un conocimiento que ayudo a la generación de ideas para la conceptualización y posterior materialización de la aplicación. El proceso de investigación empezó de forma general sobre el análisis y diseño de la programación estructurada, que luego fue enfocada hacia el análisis y el diseño de la aplicación de liquidación de cuotas partes. Al realizar una buena identificación y un buen análisis de las necesidades se pudo clarificar el alcance y los objetivos a cumplir, mostrando la importancia del análisis a esos objetivos y necesidades. Las experiencias con el cliente permitieron conocer las expectativas que ellos tenían del proyecto y le permitieron al analista conocer y experimentar las exigencias del mismo cliente, así se pudo comprender la importancia de un buen análisis por encima de ser un buen programador. La calidad en el análisis del problema, en el desarrollo y la implementación de la aplicación se va mejorando según la experiencia. Es muy importante tener el alcance del proyecto muy bien definido. Pues el cliente estará cambiando los requerimientos del proyecto lo cual hará que se prolongue el tiempo de análisis y desarrollo si no se ha definido un alcance previamente. Se evidencio la importancia de una metodología, sobretodo en la parte de diseño. Porque así se pudo abordar directamente cada modulo, de un amanera más fácil y concreta. Durante el proceso de desarrollo de todo el proyecto se usaron conceptos y herramientas adquiridos a lo largo de la carrera de ingeniería de sistemas, por ejemplo la metodología del proyecto, la cual sirvió para establecer un camino lógico para la realización de las actividades del proyecto, además de la

50

experiencia obtenida en el manejo de lenguajes de programación y técnicas de programación. Al finalizar el proyecto se logro el diseño e implementación de la aplicación de liquidación de cuotas partes, que cumple funcionalmente con los requisitos planteados al principio del proyecto, con las expectativas personales del analista y desarrollador y con las del usuario, objetivo que se evidenciaron en las pruebas funcionales realizadas antes de la culminación de este proyecto. El desarrollo de este proyecto permite al desarrollador tener más experiencia sobre su carrera en el ámbito laboral y comercial que comparado con el ámbito educativo presenta algunas diferencias. Para el desarrollador del proyecto, la satisfacción del cliente al interactuar con la aplicación de liquidación de cuotas partes es el principal logro y es la evaluación del alcance del proyecto.

51

11. RECOMENDACIONES

Los diagramas de diseño, son DFD, así que la interpretación de estos diagramas es abstracta. No deben seguirse al pie de la letra pero es recomendable hacerlo para tener una idea del modulo a desarrollar y para seguir un orden en el desarrollo. Se le debe dar la mayor prioridad y la mayor atención al análisis del problema, un desarrollador antes de ser un buen programador debe ser ante todo un muy buen analista, para así comprender de una mejor manera el problema. Se debe tener muy claro, por parte del cliente y el desarrollador, el alcance del proyecto. Normalmente se define en un documento firmado por ambas partes. Para dejar claro hasta donde debe desarrollar el programador. La documentación del código, a medida q avanza el desarrollo es muy importante, evitara enredos y pérdida de tiempo dado en el caso que se deba corregir algo, q es lo mas seguro. Se debe analizar de una manera global todo el problema, para dar una solución general. Nunca se debe analizar por partes y dar solución por partes, asi mas adelante puede presentarse problemas en el momento de avanzar en soluciones. Si se ve de forma global el problema, lo más seguro es que no habrá inconvenientes en el futuro. Es de suma importancia el análisis del modelado de la BD, al hacer un buen modelado de la Base de datos, se estará garantizando, en un gran porcentaje, una excelente aplicación.

52

12. BIBLIOGRAFIA [1] SICALI [en linea]: Santiago de Cali, Colombia, Alcaldía del municipio de Santiago de Cali, Junio de 2006 [Consultado el 10 de Octubre de 2009]. Disponible en internet: http://www.sicali.com/info_general/relatoria/Normas/decretos/DECRETO%20MUNICIPAL%20No.%200040%20de%202007.pdf

[2] ASLESON, Ryan. Pro AJAX and Java Frameworks. 1 ed. USA: Editorial Apress, 2006, 336 p [3] HAWKINS, Scott. Apache Web Server Administration & e-commerce Handbook. 1 ed. Madrid: Prentice Hall PTR. 2001, 384 p. [4] HORTH, Henry F. SILBERCHATZ, Abraham. Fundamentos de las bases de datos. 5 ed Madrid: McGraw Hill, 1998, 944 p. [5] Libreria ADOdb para PHP: Manual oficial, librería DODB [En linea]: USA, John Lim, Agosto del 2006 [Consultado el 18 de Septiembre de 2008]. Disponible en internet: http://www.lacorona.com.mx/fortiz/adodb/docs-adodb- es.htm#features [6] RISHPATER, Ray. Wireless Web Development with PHP and WAP. 3 ed. USA: Editorial Apress, 2001, 510 p. [7] SOMMERVILLE, Ian. Ingeniería de software. 7 ed. Madrid: Editorial Pearson, 2005, 712 p.

53

GLOSARIO CUOTA PARTE PENSIONAL: es un elemento determinante en la financiación de las prestaciones económicas derivadas de la invalidez, vejez y muerte que se reconozcan ya sea por parte del Instituto de Seguros Sociales o por entidades de derecho público del orden nacional o territorial, descentralizadas territorialmente o por servicios y su proporción se determina a prorrata del tiempo cotizado o laborado en las respectivas entidades. DTF: tasa de Captación a través de Depósitos a Término Fijo. La tasa DTF es el resultado de promediar la tasa de captación a 90 días a través de Certificados de Depósito a Término (CDT´s) de todos los intermediarios financieros, ponderado por el monto captado. A partir de la información que todos los intermediarios financieros envían diariamente a la Superintendencia Bancaria sobre sus captaciones, el Banco de la República realiza el cálculo con las captaciones a 90 días e informa el valor de la DTF al mercado. HTML: HyperText Markup Language. es el lenguaje preferido para el diseño y desarrollo de páginas web. Es usado para describir la estructura y el contenido en forma de texto, así como para complementar el texto con objetos tales como imágenes. HTML se escribe en forma de "etiquetas". MYSQL: es un sistema de gestión de bases de datos relacional. Se considera uno de los sistemas de gestión de base de datos más completos por su soporte, estabilidad, escalabilidad y multiplataforma PENSIONADO: un pensionado es aquel trabajador que ha salido de la fuerza laboral por causa de una pensión de vejez, jubilación, invalidez por origen común o profesional, además, quien recibe una sustitución pensional por la muerte del trabajador. PHP: Hypertext Pre-processor. es un lenguaje interpretado de propósito general ampliamente usado y que está diseñado especialmente para desarrollo web y puede ser incrustado dentro de código HTML. Generalmente se ejecuta en un servidor web, tomando el código en PHP como su entrada y creando páginas web como salida. Puede ser desplegado en la mayoría de los servidores web y en casi todos los sistemas operativos y plataformas sin costo alguno.

54

ANEXO A

ALCALDÍA DE SANTIAGO DE CALI

Decreto No. 411.20.0040 de 2007 ( Febrero 08 )

“POR MEDIO DEL CUAL SE ESTABLECE EL REGLAMENTO INTE RNO DEL RECAUDO DE CARTERA DEL MUNICIPIO DE SANTIAGO DE CAL I”

“Por una Cali Segura, Productiva y Social. Tú tiene s mucho que ver” 1 El Alcalde de Santiago de Cali, en uso de sus facultades legales y en especial las que le confiere el Artículo 2º de la Ley 1066 de julio veintinueve (29) de 2006 reglamentado por el Decreto 4473 de diciembre quince (15) de 2006 y

CONSIDERANDO

Que el artículo segundo de la Ley 1066 de julio 29 de 2006 consagra la obligación para las entidades territoriales de establecer un reglamento interno de recaudo de cartera que determine las particulares condiciones a que se sujetará el cobro persuasivo y coactivo, para la recuperación de obligaciones en mora a su favor. Que el mismo artículo consagra la obligación de fijar en el reglamento interno de recaudo de cartera las condiciones específicas para el otorgamiento de facilidades de pago, con la exigencia de garantías idóneas que avalen la satisfacción de las obligaciones a favor del fisco municipal. Que el parágrafo tercero del artículo segundo de la Ley 1066 de julio 29 de 2006 dispone que el reglamento interno de recaudo de cartera deberá expedirse dentro de los dos meses siguientes a la reglamentación que de ese artículo realice el Gobierno Nacional. Que el Artículo segundo de la Ley 1066 de 2006 fue reglamentado mediante el Decreto 4473 de diciembre 15 de 2006. Que se requiere definir las políticas, criterios y procedimientos para adelantar el cobro persuasivo, coactivo y para la suscripción de facilidades para el pago de las obligaciones en mora, asi como el oportuno y estricto cumplimiento de las obligaciones derivadas de los mismos.

55

Que se hace necesario expedir el reglamento interno de recaudo de cartera del Municipio de Santiago de Cali, en cumplimiento de la obligación legal enunciada. Que por lo anteriormente expuesto

DECRETA

Capítulo I

Normas generales

ARTÍCULO 1: Establecer el reglamento interno de recaudo de cartera del Municipio de Santiago de Cali, el que se sujetará a las reglas contenidas en el presente Decreto. ARTÍCULO 2: Competencia. Corresponde al Tesorero General del Municipio de Santiago de Cali, en ejercicio de las facultades conferidas por los artículos 95 del Decreto 0203 de Marzo de 2001 y 29 del Decreto 376 de junio de 2001, complementado por el Decreto 411.20.0166 de marzo 15 de 2006, adelantar las acciones relacionadas con el cobro persuasivo y coactivo en el Municipio de Santiago de Cali y particularmente las relacionadas con el presente reglamento interno de recaudo de cartera. Para el cobro persuasivo de obligaciones en mora diferentes a impuestos, el Tesorero contará con el apoyo de los funcionarios responsables de la administración de cada obligación, quienes realizarán las actividades descritas en el artículo 23 del presente reglamento. ARTICULO 3: Definiciones. Cartera: Para los efectos del presente reglamento, se define como cartera, toda obligación a favor del Municipio de Santiago de Cali, cuyo plazo para el pago se encuentre vencido. Facilidad de Pago: Es una modalidad de pago cuya finalidad principal es la de permitir al Municipio llegar a un acuerdo con el deudor moroso para cancelar sus obligaciones antes de iniciar el cobro por vía de la Jurisdicción coactiva, la jurisdicción dispuesta en normas especiales según corresponda o para suspender el proceso ejecutivo ya iniciado. Beneficiario de la facilidad de pago: Serán beneficiarios las personas naturales, jurídicas y las entidades públicas que tengan calidad de deudores del Municipio de Santiago de Cali; serán también beneficiarios los representantes legales de entidades, los

56

terceros que soliciten la facilidad a nombre del deudor como apoderado constituido mediante documento privado reconocido por notario, ó como responsable solidario, liquidadores, administradores, poseedores, adjudicatarios, quienes tengan derechos herenciales, curadores, albaceas, secuestres, entre otros, cuando se cumplan los requisitos estipulados en el presente decreto. Tabla de amortización: Es una herramienta financiera automatizada que calcula el valor de las cuotas mensuales que permiten al deudor pagar su deuda dentro del plazo que el Municipio le conceda. La liquidación de las cuotas a pagar en el cumplimiento de un acuerdo de pago, se resumira para conocimiento previo del interesado en la tabla de amortización. Las partidas que componen dicha tabla son las siguientes, previo el pago de la cuota inicial convenida al firmar el acuerdo de pago: Saldo de la deuda total al momento de celebrar la negociación discriminada en tres partidas: Capital adeudado, intereses moratorios e intereses de financiación, cuotas mensuales equivalentes al total del capital adeudado, intereses de mora e intereses de financiación dividido por el número de cuotas pactadas. No se liquidarán intereses moratorios sobre el saldo mensual de intereses causados no cancelados. Interes de financiación : Es aquel aplicable a la deuda objeto del plazo durante el tiempo que se autorice la facilidad para el pago. Interes de mora : Es aquel aplicable a toda obligación vencida. Codeudor: Es aquella persona natural o jurídica que se compromete solidariamente por el pago de las obligaciones objeto de la facilidad. Para los efectos del presente reglamento, solamente podrán ser codeudores quienes acrediten capacidad económica, bien sea, por tener un vínculo laboral vigente, ser propietario de bienes muebles sujetos a registro o inmuebles no afectados con limitaciones o gravámenes a la propiedad, o quienes otorguen a favor del Municipio, alguno de los tipos de garantías dispuestas en el presente reglamento. Cobro persuasivo: Son las actuaciones que pretenden el acercamiento con el deudor con el fin de procurar la cancelación de su obligación de manera voluntaria o por lo menos celebrar un acuerdo de pago, antes de iniciar un proceso de cobro. Cobro coactivo: Es la aplicación de los procedimientos formales previstos en el Estatuto Tributario Nacional con el objeto de lograr la satisfacción de la obligación hasta con el remate de bienes del deudor. Aquellas obligaciones no sujetas al procedimiento

57

administrativo coactivo deberán cobrarse a través de la jurisdicción establecida en normas especiales. Garantía: Las garantías son fuente alternativa de pago y consisten en ofrecer un respaldo jurídicamente eficaz al pago de la obligación garantizada, al otorgar al acreedor una preferencia o mejor derecho para obtener el pago de la obligación. ARTÍCULO 4: De las garantías. Se podrán aceptar como respaldo de la deuda que se difiere garantías personales, bancarias o de instituciones financieras, contratos fiduciarios, reales, libranzas y las pólizas de cumplimiento, pignoración de rentas de la nación, entidades territoriales, entidades descentralizadas y la denuncia de bienes. Dichas garantías se deben constituir a favor del Municipio de Santiago de Cali y cubrirán el monto de la obligación más los intereses causados a la fecha de suscripción de la facilidad de pago. PARÁGRAFO: No se aceptaran como garantías prenda sobre activo circulante, acciones, aportes de interés social, cheques personales, establecimientos de comercio, cartera de créditos, facturas y en general las que no cumplan las condiciones de ofrecer un respaldo jurídicamente eficaz al pago de las obligaciones. ARTÍCULO 5: Exigencia de las garantías. El Tesorero General, el Director o Secretario, según corresponda, exigirá la presentación de garantías idóneas que respalden el cumplimiento de las obligaciones contenidas en las facilidades de pago de conformidad con lo dispuesto en los artículos 6 y 7 del presente Reglamento de Recaudo. ARTÍCULO 6: Cuantía de las garantías. Salvo el caso de las garantías personales, el valor de las garantías deberá cubrir el monto total de la obligación principal, los intereses causados y actualización, más los intereses calculados para el plazo total que se va a conceder. Sin embargo cuando se otorguen garantías bancarias o de compañías de seguros, el monto de la misma debe cubrir la obligación y un treinta por ciento (30%) adicional del valor de ella como respaldo de los intereses calculados para el plazo. La garantía de compañía de seguro deberá cubrir el término de la facilidad y por lo menos seis meses más y estar sujeta a las condiciones que establece la Ley 80 de 1993 y sus decretos reglamentarios. En todos los eventos las garantías deberán estar debidamente perfeccionadas de conformidad con la norma y disposiciones legales, antes de la expedición del acto administrativo que concede la facilidad.

58

El total de los gastos que se generen en el otorgamiento de garantías para la suscripción de facilidades de pago serán a cargo beneficiario de la facilidad de pago. Cuando existan circunstancias excepcionales de lo cual deberá quedar constancia en el expediente únicamente el funcionario competente, podrá autorizar el cambio de la garantía ofrecida para el otorgamiento de la facilidad para el pago siempre y cuando la nueva garantía sea de igual o superior realización, es decir, que permita en el evento de incumplimiento obtener el recaudo oportuno y efectivo de las obligaciones garantizadas. Por lo tanto, deberá seguir los lineamientos y parámetros establecidos en el presente reglamento para las garantías admisibles, teniendo en cuenta que es de su absoluta responsabilidad, la defensa de los intereses del Municipio. ARTICULO 7: Aprobación e inadmisión de las garantía s. Corresponde al Tesorero, Director o Secretario según corresponda, la aprobación de la constitución y el perfeccionamiento de las garantías establecidas en este Reglamento, su inadmisión y la inspección a los bienes ofrecidos para garantizar la obligación sujeta a facilidades. Corresponde al Tesorero General la custodia y guarda de las garantías, títulos valores y especies venales.

Capitulo II Facilidades de Pago ARTÍCULO 8: Competencia para otorgar facilidades de pago. Corresponde al Tesorero General, previa delegación del Director del Departamento Administrativo de Hacienda y a los funcionarios competentes en las demás dependencias, conceder mediante resolución motivada a los deudores morosos de obligaciones a favor del Municipio de Santiago de Cali facilidades para el pago de las mismas, las que se sujetarán a las reglas contenidas en los artículos siguientes. PARÁGRAFO: No habrá lugar al otorgamiento de facilidades de pago por los impuestos de Delineación urbana, Espectáculos Públicos Municipales, Publicidad Exterior Visual, Juegos Permitidos y Estampilla Pro-cultura y en general no podrán concederse facilidades para el pago de obligaciones relacionadas con dineros no consignados por concepto de retención en la fuente.

59

ARTÍCULO 9: Procedimiento para la facilidad de pago . El deudor o un tercero a su nombre podrá solicitar se le conceda facilidad para el pago de las obligaciones vencidas a favor del Municipio de Santiago de Cali, mediante escrito dirigido al Tesorero General, al Director o Secretario competente. El escrito de solicitud, deberá radicarse ante el Despacho del Director o Secretario competente, personalmente o por interpuesta persona, con exhibición del documento de identidad del signatario y en el caso de apoderado especial, de la correspondiente tarjeta profesional. a. Contenido de la solicitud El escrito mediante el cual se eleva la solicitud de facilidad para el pago de obligaciones, deberá contener como mínimo: _ Ciudad y fecha _ Nombre o razón social del deudor _ Calidad en la que actúa. _ Concepto de la obligación y períodos que se adeuden. _ Plazo solicitado. _ Especificación de la garantía ofrecida. _ Indicación de si se le adelanta proceso de cobro persuasivo y/o coactivo en otra dependencia del Municipio de Santiago de Cali. _ Si el solicitante es un tercero a nombre del deudor, deberá manifestar expresamente que se compromete solidariamente al pago total de la deuda objeto de la facilidad incluyendo los intereses y actualización que se generen. _ Manifestación de los motivos que justifiquen la solicitud del plazo. _ Dirección y teléfono del solicitante. _ Dirección de correo electrónico. _ Firma y cédula del solicitante. b. Documentos que deben anexarse a la solicitud _ Certificado expedido por la entidad competente, con una vigencia no superior a tres (3) meses, en donde se compruebe la propiedad de los bienes cuando el dominio de los mismos esté sometido a la solemnidad del registro. _ Documento que pruebe fehacientemente la propiedad de los bienes en el evento en que el dominio de los mismos no esté sometido a la solemnidad de registro. _ Fotocopia de la cédula de ciudadanía. _ Certificado de existencia y representación legal expedido por la entidad competente, cuando se trate de personas jurídicas.

60

_ Acta del órgano competente mediante el cuál se autoriza al Representante legal para celebrar este tipo de actos, cuando en los Estatutos no tenga la facultad para hacerlo o esté limitado por la cuantía. _ El avalúo del bien ofrecido en garantía:

• Tratándose de bienes inmuebles será admisible el avalúo catastral siempre y cuando el valor sea superior al monto total de la obligación objeto de facilidad.

• Tratándose de vehículos podrá aceptarse como avalúo de los mismos el valor establecido en las tablas de avalúos para vehículos que expide el Ministerio de Trasporte o de la Secretaria de Transito del Municipio, siempre y cuando se efectúe inspección para verificar su estado.

_ Poder debidamente presentado ante notario público cuando se actué en representación de otra persona c. Trámite de la solicitud El funcionario que tenga a cargo el expediente dentro de los diez (10) días siguientes a la presentación de la solicitud, deberáefectuar el análisis de la misma, verificando: _ Que se cumplan puntualmente todos los requisitos establecidos en el presente reglamento para su otorgamiento. _ Si se encuentran cumplidos los requisitos, realizar la evaluación financiera, cuando a ello hubiera lugar y perfeccionadas las garantías se proyectará la Resolución que la concede, para la firma del funcionario competente. d. Evaluación financiera: Teniendo en cuenta la naturaleza y la cuantía de la obligación deberá establecerse la situación económica del deudor dentro del sector a que pertenece, como la capacidad de pago real que le permita cumplir con las cuotas determinadas en la facilidad, para lo cual es necesario solicitar: _ Estados Financieros

• Balance de los 2 últimos cierres contables • Proyección de Estado de Perdidas y Ganancias por el término de la facilidad,

incluyendo las cuotas de la misma. • Flujo de Caja proyectado por el término de la facilidad incluyendo las cuotas de la

misma.

61

Con los documentos anteriores, el funcionario asignado para ello, realizará una evaluación financiera, es decir, analizará la capacidad de pago que le permita concluir que el deudor se encuentra en condiciones de dar oportuno y estricto cumplimiento al pago de la facilidad solicitada. El funcionario responsable de efectuar la evaluación, deberá dejar soporte mediante el cual indique cómo se realizó dicha evaluación y las razones por las cuales propone, se acepte o se rechace la solicitud. d. Solicitud sin el lleno de los requisitos Analizada la solicitud, los documentos y garantías ofrecidas, si el funcionario considera que de acuerdo a las disposiciones legales y los requisitos establecidos en el presente reglamento no es viable conceder la facilidad, la rechazará, decisión que deberá comunicarse al solicitante a través de oficio dentro de los cinco (5) días siguientes al plazo para el estudio de la solicitud. ARTÍCULO 10: Solicitud con el lleno de los requisit os: Cumplidos la totalidad de los requisitos establecidos en las disposiciones legales y en el presente reglamento, dentro de los cinco (5) días siguientes el funcionario proyectará la resolución que otorga la facilidad, la cual deberá contener como mínimo: - La tasa de interés, que será la vigente al momento de otorgarla. - La identificación plena del deudor (nombre o razón social) - Solicitante: especificando la persona que hace la solicitud de la facilidad, indicando nombre o razón social, Nit y la calidad en que actúa. - Discriminación de las obligaciones y cuantía. - Monto total de la facilidad - Descripción de las garantías, las cuales deben encontrarse perfeccionadas, excepto cuando se trate de relación de bienes. - Plazo concedido - Modalidad o tipo de las cuotas - Fecha de pago de las cuotas, discriminando las obligaciones que se pagan en cada una - Indicar las causales de incumplimiento. - Aceptación de la garantía - Orden de suspender el proceso de cobro coactivo, si este se hubiere iniciado - Orden de notificar al deudor y/o al tercero que la haya solicitado a. Cuotas para el pago de la facilidad La resolución que otorgue la facilidad para el pago, deberá indicar el plazo concedido de acuerdo al monto de la deuda, el valor, número y tipo de las cuotas, fecha en que debe

62

realizarse el pago de cada una, obligaciones que se cancelan a través de ella y la imputación, dándole aplicación al artículo 6 de la Ley 1066 de 2006. b. Determinación del tipo de cuota: Para la cancelación de las obligaciones objeto de la facilidad, el municipio determinará de acuerdo a la naturaleza de la obligación el tipo de cuota, así: - Cuotas fijas y periodos fijos; - Cuotas fijas y periodos variables; - Cuotas variables y períodos fijos; o - Cuotas variables y periodos variables c. Fecha para el pago de las cuotas En la facilidad se determinarán las fechas en que deben cancelarse cada una de las cuotas y su vencimiento será la última hora hábil del día, teniendo en cuenta los horarios de los establecimientos bancarios y entidades financieras autorizadas para recaudar. d. Determinación de los saldos insolutos Para el cálculo de los intereses causados o moratorios, deberá determinarse en meses, el lapso comprendido entre la fecha de vencimiento y la fecha de corte y aplicar la tasa vigente del DTF al valor de la cuota parte pensional, y en el caso de otra obligación vencida objeto de este reglamento se causaran los intereses especiales previstos en el ordenamiento Nacional. Así mismo deberán calcularse los valores por actualización cuando a ello hubiere lugar, de conformidad con el artículo 867-1 del Estatuto Tributario Nacional. Si existen pagos parciales y/o actos administrativos ejecutoriados de compensación se efectuará la correspondiente liquidación, dándole aplicación a la Ley 1066 de 2006. e. Liquidación de la facilidad de pago Para la liquidación de las facilidades, a través de la cual se determinará el valor de las cuotas y su imputación se tendrán en cuenta las formulas aplicables al tipo de la cuota y a la naturaleza de la obligación.

63

ARTÍCULO 11: Determinación del plazo, de la cuota i nicial y de las garantías exigidas: Las condiciones generales de plazo, cuota inicial y garantías exigidas para el otorgamiento de facilidades de pago según el tipo de obligación, serán fijadas por el Departamento o Secretaria competente de manera concertada con el Departamento Administrativo de Hacienda Municipal. ARTICULO 12: Modificación de la facilidad. Durante la vigencia de la facilidad de pago y cuando a ello hubiere lugar, podrán surgir modificaciones a la misma en los eventos relacionados a continuación: a. Ajuste de la tasa de interés b. Abonos extraordinarios c. Actualización del valor de las obligaciones d. Compensaciones ARTICULO 13: Ampliación del plazo. Cuando existan circunstancias excepcionales en donde se demuestre plenamente la imposibilidad de continuar cancelando las cuotas en las fechas determinadas en la facilidad, podrá autorizarse la ampliación del plazo de la facilidad concedida, sin exceder del término que las normas legales establecen, contados desde la fecha en que se concedió inicialmente. En este evento deberá reposar en el expediente el documento suscrito por el funcionario competente para autorizar la ampliación, en el cuál se indiquen claramente las circunstancias de hecho y de derecho que se tuvieron en cuenta para tomar dicha decisión, acompañado de los soportes presentados por el beneficiario de la facilidad. Será condición para autorizar la ampliación, que la facilidad se esté cumpliendo tanto en lo referente al pago de las cuotas establecidas, como de las obligaciones posteriores, de lo contrario se iniciará el procedimiento para declararla sin vigencia y hacer efectivas las garantías. La tasa de interés será la misma que rige la facilidad otorgada, siempre y cuando se encuentre cumplida, de lo contrario se deberá declarar sin vigencia. La ampliación se hará treinta (30) días antes del vencimiento de la cuota más próxima, de lo contrario quedará para la cuota siguiente. En este evento es necesario verificar si la garantía es suficiente, de lo contrario deberá completarse hasta cubrir el monto total de la obligación como lo establece lo consignado en el valor de las garantías. ARTICULO 14: Control de la facilidad. Otorgada la facilidad de pago, se deberá realizar un seguimiento permanente para controlar el cumplimiento tanto de las cuotas

64

determinadas en ella como de las obligaciones surgidas con posterioridad a la notificación de la misma. El funcionario competente para adelantar el control requerirá al deudor o al tercero por cualquier medio disponible, referente al incumplimiento en el pago de las cuotas, indicándole el término (no mayor a quince días) dentro del cuál deberá informar los datos que permitan verificar el pago correspondiente. Al efectuar el control y verificación de los recibos de pago, identificación, imputación, concepto, periodo, deberá constatar: que la fecha de pago, identificación, imputación, concepto, período, correspondan a los señalados en la respectiva resolución. ARTICULO 15: Cláusula aceleratoria e incumplimiento de la facilidad de pago. El incumplimiento de dos (2) cuotas consecutivas será causal de terminación unilateral de la facilidad pago y hará exigible el cobro de la totalidad de obligación, de acuerdo con su naturaleza, procediéndose con el cobro administrativo coactivo, liquidándose los intereses de mora desde la fecha de suscripción de la facilidad de pago. Igual procedimiento se realizará cuando el deudor incurra en alguna de las causales especiales dispuestas en la resolución que concede la facilidad, como causal de terminación. El funcionario responsable del control de las facilidades proyectará la resolución que la dejará sin efecto, declarando sin vigencia el plazo concedido, ordenando hacer efectiva la garantía hasta la concurrencia del saldo de la deuda garantizada, y la enviará para la firma del funcionario competente. La resolución que declara sin vigencia el plazo concedido, deberá contener como mínimo: - La indicación de las cuotas dejadas de cancelar a pesar del requerimiento formulado. - La indicación de las demás causales de incumplimiento - El saldo insoluto. - La orden de hacer efectivas las garantías. - La orden de notificación de la providencia al deudor y al garante cuando fuere del caso, indicándoles el recurso que legalmente procede, dentro de qué término y ante que funcionario debe interponerse. Ejecutoriada la resolución que declara sin vigencia la facilidad concedida, deberá iniciarse en forma inmediata el procedimiento de cobro Administrativo coactivo para hacerse efectivas las garantías ofrecidas para el cumplimiento de las obligaciones.

65

Se deja expresamente establecido, que no se concederán nuevas facilidades para obligaciones objeto de la facilidad declarada sin vigencia, si se tiene en cuenta que las garantías exigidas por las normas legales tienen por finalidad hacerlas efectivas en caso de incumplimiento, para la cancelación de las obligaciones respaldadas por dicha garantía. ARTICULO 16: Pago extemporáneo de las cuotas. Cuando el pago de las cuotas se efectúe con posterioridad a las fechas fijadas en la resolución que concedió la facilidad, y aún no se hubiere declarado sin vigencia, deberán liquidarse intereses moratorios, por cada mes o fracción de mes de retardo, sobre la parte del capital involucrado en la cuota respectiva, a la tasa que esté rigiendo la facilidad. ARTICULO 17: Notificaciones. Los actos administrativos que conceden facilidades se notificaran personalmente y los que las modifican o declaran sin vigencia el plazo, se notificaran en forma personal o por correo, incluyendo el correo electrónico. ARTICULO 18: Recursos. Contra la resolución que declara sin vigencia el plazo concedido procede el recurso de reposición ante el mismo funcionario que la profirió, dentro de los cinco (5) días a su notificación, el cual deberá resolverlo dentro del mes siguiente a su interposición en debida forma. ARTICULO 19: Disposiciones aplicables . En virtud del acuerdo de pago suscrito, se aplicarán las siguientes disposiciones: - Las cuotas mensuales cubrirán en igualdad de proporción los intereses causados y el capital adeudado. - En caso de cancelar el total de la deuda antes del plazo convenido, el valor a pagar será el que indique el estado de cuenta expedido por el Municipio de Santiago de Cali al momento del pago. - El aceptar el pago de las obligaciones correspondientes a las cuotas partes pensionales, u otra obligación mediante un acuerdo de pago no impide que el deudor pueda solicitar al municipio la revisión del estado de su cuenta en cualquier momento, como tampoco impide que el Municipio de oficio la efectué. - El pago de las cuotas mensuales se hará en las entidades financieras autorizadas por el Municipio. - Para todas y cada una de estas modalidades de pago, se podrán realizar pagos extraordinarios con miras a disminuir el plazo inicialmente establecido. - El pago de las cuotas establecidas en los acuerdos de pago se hará en la fecha que se indique en la resolucion que establece la facilidad. - Los deudores que hayan incumplido un (1) convenio de pago celebrado con el Municipio de Santiago de Cali, no tendrán derecho a pactar un nuevo convenio de pago sobre las vigencias incumplidas aún en en la etapa del cobro coactivo. - La entidad pública deudora deberá contar con el respectivo certificado de disponibilidad presupuestal y con la autorización de vigencias futuras, si es del caso, de conformidad

66

con el Estatuto Orgánico de Presupuesto, para la realización de acuerdos de pago con otras entidades del sector público. - El municipio de Santiago de Cali, se abstendra de celebrar acuerdos de pago con los deudores que aparezcan reportados en el boletìn de deudores morosos por el incumplimiento de acuerdos de pago, salvo que se subsane el incumplimiento y la Contaduría General de la Nación expida la correspondiente certificación. - Para efectos de lo dispuesto en la Resolución 04 de Enero 12 de 1999 o de los demás actos que establezcan el procedimiento para los descuentos voluntarios a los servidores públicos, jubilados y pensionados, para la cancelación de obligaciones a través de descuentos por nómina, las facilidades de pago enunciadas se sujetarán íntegramente a lo dispuesto en el presente reglamento. - Podrán realizarse pagos parciales del monto de cada una de las cuotas establecidas en la facilidad de pago, de acuerdo con la naturaleza de la obligación. - No se expedirá paz y salvo por cumplimiento de las cuotas establecidas ni por cumplimiento parcial de la facilidad de pago. ARTICULO 20: Otras actuaciones con ocasión del otor gamiento de la facilidad. a. Cobro de Garantía. Ejecutoriada y en firme la resolución que ordena hacer efectiva la garantía otorgada, para respaldar el pago de las obligaciones, si el garante no consigna el saldo insoluto dentro de los diez (10) días siguientes a la ejecutoria, el funcionario competente librará mandamiento de pago contra el garante y decretará el embargo, secuestro y avalúo de los bienes del mismo, para su posterior remate. El cobro contra el garante, se adelantará por el procedimiento administrativo coactivo, haciendo especial claridad que contra el mandamiento de pago, el garante en ningún caso podrá alegar excepción alguna diferente a la de “pago efectivo”. El título ejecutivo para estos eventos, estará conformado por la garantía y la resolución que la ordene hacer efectiva, debidamente ejecutoriada y en firme. b. Suspensión del procedimiento. Cuando en cualquier etapa del procedimiento coactivo, se otorgue facilidad para el pago, deberá suspenderse el proceso. Sin perjuicio de la exigibilidad de garantías, cuando se declare el incumplimiento de la facilidad de pago deberá reanudarse el procedimiento, si aquellas no son suficientes para garantizar la totalidad de la deuda garantizada. c. Reanudación del procedimiento. Cuando se declare sin vigencia la facilidad, si las garantías otorgadas no fueren suficientes para el cobro de las obligaciones objeto de la misma, deberá iniciarse o continuarse el procedimiento administrativo de cobro decretando el embargo de las cuentas corrientes, de ahorro o de cualquier otro titulo en bancos o entidades financieras y de los bienes identificados como de propiedad del deudor.

67

d. Reporte al boletín de Deudores morosos del Estad o. Se deberá reportar a la Contaduría General de la Nación, en las mismas condiciones establecidas en la Ley 901 de 2004, los deudores que hayan incumplido los acuerdos de pago suscritos con el Municipio de Santiago de Cali.

Capitulo III

Cobro de obligaciones

ARTÍCULO 21: Etapas del cobro. La gestión de cobro está a cargo de la Tesorería General y contiene dos etapas, una denominada del cobro persuasivo y otra del cobro coactivo. Para el cobro persuasivo de obligaciones en mora diferentes a impuestos, el Tesorero contará con el apoyo de los funcionarios responsables de la administración de cada obligación quienes realizarán las actividades descritas en el artículo 23 del presente reglamento. ARTÍCULO 22: Del cobro persuasivo. El Tesorero General con el apoyo de los funcionarios responsables de la administración de cada obligación, realizarán las labores de cobro persuasivo dentro de los seis (6) meses siguientes a la fecha en que se incumpla con el pago de las obligaciones sujetas a este reglamento. ARTÍCULO 23: Procedimiento de cobro persuasivo. Recibida por el Tesorero General o por los funcionarios responsables de la administración de cada obligación, la relación de deudores del fisco municipal se agotará el siguiente procedimiento: 1. Clasificación de la cartera. La cartera por cobrar será dividida por tipo de obligación. Una vez hecha la clasificación anterior, la cartera obtenida se dividirá en tres grupos de acuerdo con su cuantía. El primer grupo estará integrado por las obligaciones en mora en cuantía igual o superior a veinticinco (25) salarios mínimos legales mensuales vigentes; el segundo grupo se conformará con las obligaciones en mora por valor igual a diez (10) salarios mínimos legales mensuales vigentes y hasta veinticinco (25) salarios legales mensuales vigentes

68

menos un peso, y; un tercer grupo de cartera conformado por las obligaciones en mora inferiores a diez (10) salarios mínimos legales mensuales vigentes. Se realizará gestión de cobro persuasivo en el mismo orden de conformación de los grupos. 2. Gestión a realizarse. a. Cartera igual o superior a veinticinco (25) sala rios mínimos legales mensuales vigentes. Al deudor se le hará un máximo de cinco (5) llamadas persuasivas en un tiempo de dos (2) meses. Concluido este lapso de tiempo sin que se obtenga la satisfacción total de la obligación o sin que resulte posible ubicarlo, se conformará una relación con los deudores renuentes al pago y se dará inicio al procedimiento administrativo de cobro. El funcionario responsable podrá implementar la realización de visitas a los deudores. En caso de que ninguno de los mecanismos empleados de lugar a la satisfacción de la totalidad de la obligación en mora, podrá remitirse oficio persuasivo a través de servicio de correo el que deberá contener como mínimo los siguientes datos: _ El nombre y apellido completo _ La dirección. _ Número de identificación predial en caso de tratarse de este impuesto. _ NIT o cédula _ El concepto de la obligación (tipo de renta, impuesto, sanción, multa, etc.) _ El valor del capital de la obligación y sus respectivos intereses hasta una fecha de corte y de acuerdo con la tasa de interés vigente que corresponda de conformidad con las normas especiales. _ Número telefónico donde el deudor se puede comunicar con el grupo que realiza el cobro persuasivo para conocer el monto de la liquidación a la fecha de pago _ Lugar y datos donde debe realizar el pago Certificada la entrega por la empresa de mensajería, se dará un plazo de diez (10) días hábiles al deudor para que realice el pago. Concluido este lapso de tiempo sin que se obtenga la satisfacción total de la obligación o sin que resulte posible ubicar al deudor se conformará una relación con los deudores renuentes al pago y se dará inicio al procedimiento administrativo de cobro. b. Cartera igual a diez salarios mínimos legales me nsuales vigentes y hasta veinticinco salarios mínimos legales mensuales vige ntes menos un peso. Al deudor se le hará un máximo de tres (3) llamadas persuasivas en un tiempo de dos (2) meses. Concluido este lapso de tiempo sin que se obtenga la satisfacción total de la obligación o sin que resulte posible ubicar al deudor se conformará una relación con los deudores renuentes al pago y se dará inicio al procedimiento administrativo de cobro.

69

En caso de que trascurra el término enunciado sin que se obtenga la satisfacción total de la obligación, se podrá remitir un oficio persuasivo a través de servicio de correo el que deberá contener como mínimo los datos relacionados en el literal a. del presente artículo: c. Cartera inferior a diez salarios mínimos legales mensuales vigentes. Al deudor se le hará un máximo de tres (3) llamadas persuasivas en un tiempo de dos (2) meses. Concluido este lapso de tiempo sin que se obtenga la satisfacción total de la obligación o sin que resulte posible ubicar al deudor se conformará una relación con los deudores renuentes al pago y se dará inicio al procedimiento Administrativo de cobro. En caso de que trascurra el término enunciado sin que se obtenga la satisfacción total de la obligación, podrá remitirse un oficio persuasivo a través de servicio de correo el que deberá contener como mínimo los datos relacionados en el literal a. del presente artículo: d. Otros mecanismo de gestión de cartera Para ubicar a aquellos deudores que se encuentren en mora por obligaciones cuya cuantía se encuadre en lo dispuesto en el literal c. del presente artículo podrá efectuarse una búsqueda en las bases de datos con que cuente la administración o en el directorio telefónico. Para ubicar a aquellos deudores que se encuentren en mora por obligaciones cuyas cuantías se encuadren en lo dispuesto en los literales a. y b. podrá efectuarse una búsqueda en las bases de datos con que cuente la administración o en el directorio telefónico. La administración podrá optar por realizar búsquedas adicionales en el Registro de instrumentos públicos u otros registros públicos de otros bienes, Cámara de comercio, Superintendencia de salud y otros medios que permitan la ubicación del deudor. De la búsqueda realizada se dejará constancia en el expediente. El procedimiento dispuesto en este artículo deberá realizarse en un término máximo de seis (6) meses, concluidos los cuales se dará inicio al proceso de cobro administrativo coactivo. ARTÍCULO 24: Cobro coactivo. El procedimiento para el cobro coactivo de obligaciones en mora a favor del municipio de Santiago de Cali se sujetará a las disposiciones

70

contenidas en el Estatuto Tributario Municipal, el Estatuto Tributario Nacional y por las normas que los modifiquen o complementen. ARTÍCULO 25: Criterios de clasificación de cartera para el cobro coactivo. Cuantía: Para la organización y realización de programas de cobro, la cartera por cobrar podrá ser dividida en tres grupos en la misma forma como lo dispone el numeral 1 del Artículo 23 del presente reglamento. Antigüedad: Para la organización y realización de programas de cobro, la cartera por cobrar podrá ser dividida en tres grupos, el primero conformado por aquellas obligaciones con una antigüedad igual o inferior a un año; un segundo grupo conformado por aquellas obligaciones con una antigüedad de entre un año un día y hasta cuatro años, y; un tercer grupo conformado por obligaciones con una antigüedad superior a cuatro años. Naturaleza: Deberán cobrarse todas las obligaciones en mora a favor del Municipio de Santiago de Cali, contenidas en documentos que presten mérito ejecutivo. Para el caso de las obligaciones en mora por concepto de retenciones practicadas y no consignadas, la Tesorería General, pondrá en conocimiento de las autoridades penales correspondientes la iniciación del proceso de cobro, dando además aplicación al régimen sancionatorio contenido en el Estatuto Tributario Municipal y el Estatuto Tributario Nacional. Deudor: Dentro del procedimiento de cobro no habrá lugar a tratamientos especiales por la calidad del deudor salvo lo dispuesto en normas especiales.

Capitulo IV

Disposiciones finales ARTÍCULO 26: Imputación de pagos. Los pagos que por cualquier concepto hagan los deudores, deberán imputarse al período que estos indiquen, en las mismas proporciones con que participan las sanciones actualizadas, intereses, anticipos, impuestos y retenciones, dentro de la obligación total al momento del pago. ARTÍCULO 27: Para todos los efectos legales, quien mediante escrito separado o suscripción directa manifieste actuar en calidad de co-deudor será responsable del pago de las cuotas, la obligación principal y sus accesorios, y en caso de incumplimiento será sujeto del proceso de cobro administrativo coactivo.

71

ARTICULO 28: Inscripción en el sistema único de inf ormación de tramites SUIT. Se deberá adelantar el trámite previsto en la Ley 962 de Julio 8 de 2005, Artículo 1 Numerales 2 y siguientes. ARTICULO 29 : En lo no previsto en el presente reglamento, se aplicarán las disposiciones de la Ley 1066 de 2006, el Decreto Reglamentario 4473 de 2006, y las demás normas concordantes. ARTÍCULO 30: Vigencia y derogatorias. El presente Decreto rige a partir de su publicación en el boletín oficial y deroga todas las disposiciones que le sean contrarias.

PUBLÍQUESE Y CÚMPLASE

Dado en Santiago de Cali a los ocho (8) días del mes de Febrero de dos mil siete (2007) (ORIGINAL FIRMADO) _______________________________ APOLINAR SALCEDO CAICEDO Alcalde de Santiago de Cali Proyectó y Revisó: Dirección Jurídica Alcaldía Departamento Admitivo. Hacienda

72

ANEXO B

DECRETO 2921 DE 1948

(Agosto 21)

Por el cual es reglamenta el artículo 21 de la Ley 72 de 1947.

El Presidente de la República de Colombia,

en uso de sus atribuciones legales,

DECRETA:

Artículo 1. Los empleados nacionales, departamentales o municipales que tengan derecho a solicitar el reconocimiento y pago de la pensión de jubilación elevarán la solicitud a la Caja o institución de Previsión Social, a la cual estén afiliados al tiempo de cumplir su servicio o a la que hayan estado afiliados en el momento de retirarse del servicio oficial, si es el caso. PARAGRAFO. Cuando la entidad respectiva no tenga establecida su Caja o institución de previsión social, la solicitud deberá ser dirigida a dicha entidad, para la tramitación correspondiente Artículo 2 La Caja de previsión social que reciba una solicitud de pago de una pensión de jubilación que sea de su cargo o de varias entidades, la pondrá en conocimiento de éstas, y les remitirá copia del proyecto de resolución que elabore y de los documentos que sean necesarios para que cada una de tales entidades pueda establecer si son correctos, si está obligada a la cuota que se le asigna y si se ajusta a las disposiciones legales que la rigen. PARAGRAFO. La entidad que reciba las copias a que se refiere este artículo, y que considere necesario el examen de los documentos presentados, podrá solicitarlo, y la Caja en cuyo poder se encuentren los desglosará y se los remitirá, pero dejando copia autenticada de ellos. Artículo 3. Dentro de los quince días hábiles siguientes la Caja o la entidad en cuyo conocimiento es puesta la solicitud deberá manifestar si la acepta o si la objeta con fundamento legal. En caso de que guardare silencio, la Caja a que inicialmente recibió la

73

solicitud de reconocimiento de la pensión le exigirá la devolución de los documentos originales que le hubiere emitido si es el caso, y dictará la providencia que decida sobre la solicitud del empleado. Artículo 4. Conocido el concepto de las demás entidades y devuelto por éstas el proyecto de resolución, ésta será elaborada de acuerdo con lo que ellas hubieren manifestado. Si ocurriere el caso de que guardaren silencio, se procederá de acuerdo con lo dispuesto en el artículo anterior, PARAGRAFO. De esta providencia se pasará copia autenticada a las demás entidades obligadas, a fin de que cada una expida la providencia que reconozca, y ordene el pago de la cuota que le corresponda. Artículo 5. El beneficiario podrá ejercer los recursos y las acciones legales, dentro del término señalado para ello, contra la resolución de la caja a la cual solicitó el reconocimiento de la pensión en cuanto se refiere a la obligación a cargo de ella, o en cuanto se aparta de lo que las demás entidades hayan aceptado como cuota o parte de la pensión que éstas deban pagar Artículo 6. El beneficiario podrá igualmente intentar los recursos y ejercer las acciones legales contra las resoluciones que dicten las entidades obligadas al pago de una parte de la pensión, si no se conforma con la decisión tomada en ellas. Artículo 7. Mientras se tramitan los recursos o se adelantan las acciones contra cualquiera de las providencias mencionadas, en el curso de que esto suceda el beneficiario tendrá derecho a recibir el pago de las cuotas reconocidas en aquellas consentidas por él. La caja pagadora, al ser resuelto el recurso o cuando se decida la acción contra la providencia impugnada, cubrirá las cuotas de conformidad con el fallo definitivo. Artículo 8. No solamente deberán entenderse por caja de previsión social, para los efectos legales y en especial para los del articulo 21 de la ley que reglamenta y los del presente decreto, las que en la actualidad llevan dicha denominación, sino también todas aquellas instituciones de previsión social ya establecidas o que sean creadas, y además las entidades que vienen atendiendo el pago de prestaciones sociales a trabajadores oficiales, y las que por la ley deben hacerlo, como los departamentos, municipios, intendencias, comisarías, etc. Artículo 9. La caja a la cual corresponda el pago de una pensión formada por cuotas de diversas entidades, repetirá contra las demás dichas cuentas de la comprobación de haber efectuado los pagos, las que deberán ser canceladas a su presentación.

74

Artículo 10. Este decreto rige desde la fecha de su expedición. Dado en Bogotá a veintiuno de agosto de mil novecientos cuarenta y ocho. NOTA: Modificado por el Artículo 75 del decreto 1848 de 1969, numerales 2º y 3º.

75

ANEXO C

LEY 71 DE 1988

(diciembre 19)

por la cual se expiden normas sobre pensiones y se dictan otras disposiciones Reglamentado por el Decreto Nacional 1073 de 2002

El Congreso de Colombia

DECRETA:

Ver Fallo del Consejo de Estado 2615 de 2001 Artículo 1. Las pensiones a que se refiere el artículo 1o. de la ley 4a. de 1976, las de incapacidad permanente parcial y las compartidas, serán reajustadas de oficio cada vez y con el mismo porcentaje en que sea incrementado por el Gobierno el salario mínimo legal mensual. Parágrafo. Este reajuste tendrá vigencia simultánea a la que se fija para el salario mínimo. Ver Parágrafo artículo 1o., artículo 11 del Decreto Nacional 1160 de 1989, Ver el Decreto 2108 de 1992 Artículo 2. Ninguna pensión podrá ser inferior al salario mínimo legal mensual, ni exceder de quince (15) veces dicho salario; salvo lo previsto en convenciones colectivas, pactos colectivos y laudos arbitrales. Parágrafo. El límite máximo de las pensiones, sólo será aplicable a las que se causen a partir de la vigencia de la presente ley. Artículo 3. Extiéndese las previsiones sobre sustitución pensional de la Ley 33 de 1973, de la Ley 12 de 1975, de la Ley 44 de 1980 y de la Ley 113 de 1985 en forma vitalicia, al cónyuge supérstite compañero o compañera permanente, a los hijos menores o inválidos y a los padres o hermanos inválidos que dependan económicamente del pensionado, en las condiciones que a continuación se establecen: 1. El cónyuge sobreviviente o compañero o compañera permanente, tendrán derecho a recibir en concurrencia con los hijos menores o inválidos por mitades la sustitución de la respectiva pensión con derecho a acrecer cuando uno de los dos órdenes tengan extinguido su derecho. De igual manera respecto de los hijos entre sí.

76

2. Si no hubiere cónyuge o compañero o compañera permanente, la sustitución de la pensión corresponderá íntegramente a los hijos menores o inválidos por partes iguales. 3. Si no hubiere cónyuge supérstite o compañero o compañera permanente, ni hijos menores o inválidos, la sustitución de la pensión corresponderá a los padres. 4. Si no hubiere cónyuge supérstite, compañero o compañera permanente, ni hijos menores o inválidos, ni padres, la sustitución de la pensión corresponderá a los hermanos inválidos que dependan económicamente del causante. Artículo 4. A falta de los beneficiarios consagrados en el artículo 1o. de la Ley 126 de 1985, tendrán derecho a tal prestación los padres o los hermanos inválidos del empleado fallecido que dependieren económicamente de él, desde la aplicación de la ley a que se refiere este artículo. Artículo 5. Las empresas, entidades o patronos que satisfacen pensiones, a solicitud escrita de la respectiva Asociación de Pensionados, deberán hacer los descuentos de las cuotas o totalidad de los créditos o deudas que contraen los pensionados organizados gremialmente en favor de su organización gremial. Igual prerrogativa tienen las Cajas de Compensación Familiar para hacer los descuentos establecidos en el artículo 6o. de esta ley. Artículo 6 .- Las Cajas de Compensación Familiar deberán prestar a los pensionados, mediante previa solicitud, los servicios a que tienen derecho los trabajadores activos. Para estos efectos los pensionados cotizarán de acuerdo con los reglamentos que expida el Gobierno Nacional, sin que en ningún caso la cuantía de la cotización sea superior al dos por ciento (2%) de la correspondiente mesada. Los pensionados que se acojan a este beneficio no recibirán subsidio en dinero. Artículo 7. A partir de la vigencia de la presente ley, los empleados oficiales y trabajadores que acrediten veinte (20) años de aportes sufragados en cualquier tiempo y acumulados en una o varias de las entidades de previsión social que hagan sus veces, del orden nacional, departamental, municipal, intendencial, comisarial o distrital y en el Instituto de los Seguros Sociales, tendrán derecho a una pensión de jubilación siempre que cumplan sesenta (60) años de edad o más si es varón y cincuenta y cinco (55) años o más si es mujer. El Gobierno Nacional reglamentará los términos y condiciones para el reconocimiento y pago de esta prestación y determinará las cuotas partes que correspondan a las entidades involucradas. Parágrafo. INEXEQUIBLE . Para el reconocimiento de la pensión de que trata este artículo, a las personas que a la fecha de vigencia de la presente ley, tengan diez (10)

77

años o más de afiliación en una o varias de las entidades y cincuenta (50) años o más de edad si es varón o cuarenta y cinco (45) años o más si es mujer, continuarán aplicándose las normas de los regímenes actuales vigentes. Artículo 8. Las pensiones de jubilación, invalidez y vejez una vez reconocidos, se hacen efectivas y deben pagarse mensualmente al pensionado desde la fecha en que se haya retirado definitivamente del servicio, en caso de que este requisito sea necesario para gozar de la pensión. Para tal fin la entidad de previsión social o el I.S.S., comunicarán al organismo donde labora el empleado, la fecha a partir de la cual va a ser incluido en la nómina de pensionados, para efecto de su retiro del servicio. Para cobrar su primera mesada el pensionado deberá acreditar su retiro, mediante copia auténtica del acto administrativo que así lo dispuso o constancia expedida por el Jefe de Personal de la entidad donde venía laborando, o de quien haga sus veces. Artículo 9. Las personas pensionadas o con derecho a la pensión del sector público en todos sus niveles que no se hayan retirado del servicio de la entidad, tendrán derecho a la reliquidación de la pensión, tomando como base el promedio del último año de salarios y sobre los cuales haya aportado al ente de previsión social. Parágrafo. La reliquidación de la pensión de que habla el inciso anterior, no tendrá efectos retroactivos sobre las mesadas anteriores al retiro del trabajador o empleado del sector público en todos sus niveles. Artículo 10. Al cónyuge sobreviviente, al compañero o compañera permanente, a los hijos menores o inválidos, a los padres y a los hermanos inválidos con derecho a la sustitución pensional, se les harán los reajustes pensionales y demás beneficios y obligaciones contenidas en las leyes, convenciones colectivas, o demás disposiciones consagradas a favor de los pensionados. Artículo 11. Esta ley y las Leyes 33 de 1973, 12 de 1975, 4a. de 1976, 44 de 1980, 33 de 1985, 113 de 1985 y sus decretos reglamentarios, contienen los derechos mínimos en materia de pensiones y sustituciones pensionales y se aplicarán en favor de los afiliados de cualquier naturaleza de las entidades de previsión social, del sector público en todos sus niveles y de las normas aplicables a las entidades de Previsión Social del Sector privado, lo mismo que a las personas naturales y jurídicas, que reconozcan y paguen pensiones de jubilación, vejez e invalidez. Artículo 12. El Gobierno Nacional hará los traslados presupuestales y abrirá los créditos necesarios para la ejecución de esta ley.

78

Artículo 13. La presente ley rige a partir de su sanción y deroga todas las disposiciones que le sean contrarias.

República de Colombia - Gobierno Nacional Publíquese y ejecútese

Dada en Bogotá, D.E., a 19 de diciembre de 1988. El Presidente de la República, VIRGILIO BARCO. El Ministro de Hacienda y Crédito

Público, LUIS FERNANDO ALARCON MANTILLA. El Ministro de Trabajo y Seguridad Social, JUAN MARTIN CAICEDO FERRER.

79

ANEXO D

DECRETO 2709 DE 1994

(diciembre 13)

por el cual se reglamenta el artículo 7 de la Ley 7 1 de 1988.

EL PRESIDENTE DE LA REPÚBLICA DE COLOMBIA, en uso de sus facultades constitucionales, en espec ial de las conferidas en el

numeral 11 del artículo 189 de la Constitución Polí tica,

DECRETA:

Artículo 1. Pensión de jubilación por aportes. La pensión a que se refiere el artículo 7 de la Ley 71 de 1988, se denomina pensión de jubilación por aportes. Tendrán derecho a la pensión de jubilación por aportes quienes al cumplir 60 años o más de edad si es varón, o 55 años o más si se es mujer, acrediten en cualquier tiempo, 20 años o más de cotizaciones o aportes continuos o discontinuos en el Instituto de Seguros Sociales y en una o varias de las entidades de previsión social del sector público. Artículo 2. Efectividad y pago de la pensión de jubilación por aportes. La pensión de jubilación por aportes, para los servidores públicos se hará efectiva una vez se retiren del servicio. Para los demás trabajadores, se requiere la desafiliación de los seguros de invalidez, vejez o muerte y accidente de trabajo y enfermedad profesional, salvo las excepciones previstas en la ley. Artículo 3. Incompatibilidad de la pensión de jubilación por aportes. La pensión de jubilación por aportes es incompatible con las pensiones de jubilación, invalidez, vejez y retiro por vejez. El empleado o trabajador podrá optar por la más favorable cuando haya concurrencia entre ellas. Artículo 4. Entidad de previsión. Para efectos de la pensión de jubilación por aportes, se tendrá como entidad de previsión social a cualquiera de las cajas de previsión social, fondos de previsión, o las que hagan sus veces del orden nacional, departamental, intendencial, comisarial, municipal o distrital y al Instituto de los Seguros Sociales.

80

Artículo 5. Tiempo de servicios no computables. No se computará como tiempo para adquirir el derecho a la pensión de jubilación por aportes, el laborado en empresas privadas no afiliadas al Instituto de Seguros Sociales para los riesgos de invalidez, vejez y muerte, ni el laborado en entidades oficiales de todos los órdenes cuyos empleados no aporten al sistema de seguridad social que los protege. Artículo 6. Salario base para la liquidación de la pensión de jubilación por aportes. Derogado por el art. 24, Decreto Nacional 1474 de 1997. El salario base para la liquidación de esta pensión, será el salario promedio que sirvió de base para los aportes durante el último año de servicios, salvo las excepciones contenidas en la ley. Si la entidad de previsión es el ISS se tendrá en cuenta el promedio del salario base sobre el cual se efectuaron los aportes durante el último año y dicho instituto deberá certificar lo pagado por los citados conceptos durante el período correspondiente. Artículo 7°. Certificaciones y tramitación. La entidad empleadora al retiro del empleado, o cuando éste lo solicite, certificará por escrito el tiempo trabajado, la entidad de previsión a la cual fueron hechos los aportes y el valor pagado por cada uno de los factores salariales durante el último año de servicios. Si el período de trabajo fuere inferior a un año deberá certificar lo pagado por los citados conceptos, durante dicho período. La dependencia de personal de la última entidad empleadora tendrá la obligación de recibir, revisar y con la colaboración del interesado, completar los documentos pertinentes para demostrar el derecho a la pensión de jubilación por aportes. Artículo 8°. Monto de la pensión de jubilación por aportes. El monto de la pensión de jubilación por aportes será equivalente al 75% del salario base de liquidación. El valor de la pensión de jubilación por aportes, no podrá ser inferior al salario mínimo legal mensual vigente ni superior a quince (15) veces dicho salario, salvo lo previsto en la ley. Artículo 9°. Derechos de los beneficiarios de la pensión de jubilación por aportes. Los beneficiarios de la pensión de jubilación por aportes tienen las mismas obligaciones y derechos accesorios establecidos en las disposiciones legales y reglamentarias que rijan en la entidad de previsión pagadora. Artículo 10. Entidad de previsión pagadora. La pensión de jubilación por aportes será reconocida y pagada por la última entidad de previsión a la que se efectuaron aportes, siempre y cuando el tiempo de aportación continuo o discontinuo en ellas haya sido mínimo de seis (6) años. En caso contrario, la pensión de jubilación por aportes será reconocida y pagada por la entidad de previsión a la cual se haya efectuado el mayor tiempo de aportes.

81

Parágrafo. Si la entidad de previsión obligada al reconocimiento de la pensión de jubilación por aportes es la Caja Nacional de Previsión Social, el pago de dicha prestación lo asumirá el Fondo de Pensiones Públicas del nivel nacional a partir de 1995. Si las entidades de previsión obligadas al reconocimiento de la pensión de jubilación por aportes son del orden territorial, dicha prestación, en el evento de liquidación de las mismas, estará a cargo de la entidad que las sustituya en el pago. Artículo 11. Cuotas partes. Todas las entidades de previsión social a las que un empleado haya efectuado aportes para obtener esta pensión, tienen la obligación de contribuirle a la entidad de previsión pagadora de la pensión con la cuota parte correspondiente. Para el efecto de las cuotas partes a cargo de las demás entidades de previsión, la entidad pagadora notificará el proyecto de liquidación de la pensión a los organismos concurrentes en el pago de la pensión, quienes dispondrán del término de quince (15) días hábiles para aceptarla u objetarla, vencido el cual, si no se ha recibido respuesta, se entenderá aceptada y se procederá a expedir la resolución definitiva de reconocimiento de la pensión. La cuota parte a cargo de cada entidad de previsión será el valor de la pensión por el tiempo aportado a esta entidad, dividido por el tiempo total de aportación. Artículo 12. Vigencia. El presente Decreto rige a partir de la fecha de su publicación y deroga los artículos 19, 20, 21, 23, 24, 26, 27, 28 y 29 del Decreto 1160 de 1989.

Publíquese y cúmplase.

Dado en Santafé de Bogotá, D.C., a 13 de diciembre de 1994 ERNESTO SAMPER PIZANO

La Ministra de Trabajo y Seguridad Social, María Sol Navia Velasco.

82

ANEXO E

Figura 15. Diagrama de contexto - Nivel 0

83

Figura 16. Diagrama de Contexto – Nivel 1

84

Diagrama de contexto - Nivel 2

Figura 17. Diagrama de contexto nivel 2 - Pensionad o

Figura 18. Diagrama de contexto nivel 2 - Entidad

85

Figura 19. Diagrama de contexto nivel 2 - Sustituto

Figura 20. Diagrama de contexto nivel 2 - Aumentos

86

Figura 21. Diagrama de contexto nivel 2 - Intereses

Figura 22. Diagrama de contexto nivel 2 - Liquidaci ones

87

Figura 23. Diagrama de contexto nivel 2 - Usuario

Figura 24. Diagrama de contexto nivel 3 Liquidación de - capital

88

Figura 25. Diagrama de contexto nivel 3 - Liquidaci ón DTF

89

Diagramas de Flujo de Datos (DFD) del sistema

Figura 26. Modificar pensionado - 1.1.1

90

Figura 27. Inactivar pensionado 1.1.2

91

Figura 28. Insertar pensionado - 1.1.3

92

Figura 29. Modificar Entidad - 1.2.1

93

Figura 30. Inactivar Entidad - 1.2.2

94

Figura 31. Insertar Entidad - 1.2.3

95

Figura 32. Modificar Sustituto - 1.3.1

96

Figura 33. Inactivar Sustituto - 1.3.2

97

Figura 34. Insertar Sustituto - 1.3.3

98

Figura 35. Modificar Aumento - 1.4.1

99

Figura 36. Inactivar Aumento - 1.4.2

100

Figura 37. Insertar Aumento - 1.4.3

101

Figura 38. Consultar Aumento - 1.4.4

102

Figura 39. Modificar Interés - 1.5.1

103

Figura 40. Inactivar Interés - 1.5.2

104

Figura 41. Insertar Interés - 1.5.3

105

Figura 42. Consultar Interés - 1.5.4

106

Figura 43. Generar Liquidación de Capital - 1.6.4.1 .1

107

Figura 44. Consultar Liquidación de Capital - 1.6.4 .1.2

108

Figura 45. Generar Liquidación DTF - 1.6.4.2.1

109

Figura 46. Consultar Liquidación DTF - 1.6.4.2.2

110

Figura 47. Modificar usuario - 1.7.1

111

Figura 48. Inactivar usuario - 1.7.2

112

Figura 49. Insertar usuario - 1.7.3

113

Figura 50. Iniciar sesión - 1.7.4

114

ANEXO F

PROYECTO: LIQUIDACION CUOTAS PARTES PENSIONALES PRUEBA FUNCIONAL

MODULO: MODIFICAR PENSIONADO

Fecha:


Identificador: 1.1.1

Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos la modificación del pensionado, donde el sistemas nos traerá los datos del pensionado que luego modificaremos y guardaremos en la base de datos.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. También debe existir ya un pensionado en la base de datos para modificar sus datos.





- Seleccionamos en PENSIONADO la opción de modificar pensionado.

- Completamos el campo Cedula con una cedula existente en la base de datos.

- Pulsamos el botón validar.

- El sistema nos trae los datos del pensionado a las casillas de texto.

- El usuario modifica los datos correspondientes.

- Pulsamos el botón MODIFICAR.

- El sistema modifica los datos correspondientes del pensionado y nos muestra un mensaje de éxito en la modificación.

Resultado Esperado - El sistema trajo los datos del pensionado.

- El sistema actualizo correctamente todos los datos en la base de datos que fueron modificados por el administrador


Comentarios Los datos traídos por el sistema cuando completamos la cedula son presentados en dos pestañas para hacer la interfaz más agradable para el

usuario.

Las pruebas se hicieron con el usuario ADMINISTRADOR.

115


PRUEBA FUNCIONAL

MODULO: INACTIVAR PENSIONADO Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos la inactivación del pensionado donde el sistemas inactivara los datos del pensionado para no ser tenido en cuenta por el sistema.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. También debe existir ya un pensionado en la base de datos para inactivar sus datos.





- Seleccionamos en PENSIONADO la opción de Inactivar pensionado.

- Completamos el campo Cedula con una cedula existente en la base de datos.

- Pulsamos el botón validar.

- El sistema nos trae y muestra los datos del pensionado para que el usuario este seguro del pensionado a inactivar.

- Pulsamos el botón Inactivar .

- El sistema inactiva los datos del pensionado y nos muestra un mensaje de éxito en la inactivación.

Resultado Esperado - El sistema trajo los datos del pensionado.

- El sistema Inactivo correctamente todos los datos en la base de .



116


PRUEBA FUNCIONAL

MODULO: INSERTAR PENSIONADO

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos, en el menú, la opción de insertar un pensionado, donde el sistemas guardara los datos del pensionado para posteriores funciones con respecto al pensionado.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. El pensionado a insertar no debe existir en la base de datos.





- Seleccionamos en PENSIONADO la opción de insertar pensionado.

- Completamos todos los campos relacionados al pensionado, por lo menos los obligatorios, y si también tiene un sustituto ese pensionado también pueden ser completados sus datos.

- Pulsamos el botón Insertar .

- El sistema inserta en la base de datos los datos relacionados al pensionado y del sustituto.

Resultado Esperado - El sistema guardo satisfactoriamente los datos del pensionado y del sustituto y mostro el respectivo mensaje exitoso.


Comentarios El formulario para insertar los datos del usuario es presentado en varias pestañas para una mejor experiencia.

Las pruebas se hicieron con el usuario ADMINISTRADOR.

117


PRUEBA FUNCIONAL

MODULO: MODIFICAR ENTIDAD

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos la modificación de la entidad, donde el sistemas nos traerá los datos respectivos de la entidad que luego modificaremos y actualizaremos en la base de datos.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. También debe existir ya una entidad en la base de datos para modificar sus datos.





- Seleccionamos en ENTIDAD la opción de modificar entidad.

- Seleccionamos del menú desplegable la entidad que modificaremos.

- Pulsamos el botón valida.

- El sistema nos trae los datos de la entidad a las casillas de texto.

- El usuario modifica los datos necesarios.


- El sistema modifica los datos correspondientes de la entidad y nos muestra un mensaje de éxito en la modificación.

Resultado Esperado - El sistema trajo los datos de la entidad.



Comentarios Las pruebas se hicieron con el usuario ADMINISTRADOR

118


PRUEBA FUNCIONAL

MODULO: INACTIVAR ENTIDAD

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos la inactivación de la entidad donde el sistemas inactivara los datos de la entidad para no ser tenido en cuenta por el sistema.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. También debe existir ya la entidad en la base de datos para inactivar sus datos.





- Seleccionamos en ENTIDAD la opción de Inactivar Entidad.

- Seleccionamos del menú desplegable la entidad a inactivar


- El sistema inactiva los datos de la entidad y nos muestra un mensaje de éxito en la inactivación.

Resultado Esperado - El sistema Inactivo correctamente todos los datos en la base de datos.



119


PRUEBA FUNCIONAL

MODULO: INSERTAR ENTIDAD

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos, en el menú, la opción de insertar una nueva entidad, donde el sistemas guardara los datos de la entidad para posteriores funciones con respecto a esa entidad.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. La entidad a insertar no debe existir en la base de datos.





- Seleccionamos en ENTIDAD la opción de insertar entidad.

- Completamos todos los campos relacionados a la entidad.


- El sistema inserta en la base de datos los datos relacionados a la entidad.

Resultado Esperado - El sistema guardo satisfactoriamente los datos de la entidad y mostro el respectivo mensaje exitoso.



120


PRUEBA FUNCIONAL

MODULO: MODIFICAR SUSTITUTO

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos la modificación del sustituto, donde el sistema nos traerá los datos respectivos del sustituto que luego modificaremos y actualizaremos en la base de datos.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. También debe existir ya un sustituto en la base de datos para modificar sus datos.





- Seleccionamos en SUSTITUTO la opción de modificar sustituto.

- Completamos la cedula del sustituto.


- El sistema nos trae los datos del sustituto a las casillas de texto.

- El usuario modifica los datos del sustituto.


- El sistema modifica los datos correspondientes del sustituto y nos muestra un mensaje de éxito en la modificación.

Resultado Esperado - El sistema trajo los datos del sustituto.




121


PRUEBA FUNCIONAL

MODULO: INACTIVAR SUSTITUTO

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos la inactivación del sustituto donde el sistemas inactivara los datos sustituto para no ser tenido en cuenta por el sistema.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. También debe existir ya un sustituto en la base de datos para inactivar sus datos.





- Seleccionamos en SUSTITUTO la opción de Inactivar sustituto.

- Completamos la cedula del sustituto a inactivar.

- El sistema nos muestra los datos del sustituto para estar seguros del sustituto a inactivar.


- El sistema inactiva los datos del usuario y nos muestra un mensaje de éxito en la inactivación.




122


PRUEBA FUNCIONAL

MODULO: INSERTAR SUSTITUTO

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos, en el menú, la opción de insertar un sustituto, donde el sistemas guardara los datos del sustituto relacionándolo a un pensionado para posteriores funciones..

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. El sustituto a insertar no debe existir en la base de datos. Debe tener un pensionado relacionado ya insertado en la base de datos.





- Seleccionamos en SUSTITUTO la opción de insertar sustituto.

- Completamos la cedula del pensionado al cual se le relacionado el sustituto.

- Pulsamos el botón valida .

- El sistema verifica que el pensionado exista.

- Completamos todos los campos relacionados al sustituto.


- El sistema inserta en la base de datos los datos del sustituto y lo relaciona con un pensionado.

Resultado Esperado - El sistema guardo satisfactoriamente los datos del sustituto y mostro el respectivo mensaje exitoso.


Comentari os Las pruebas se hicieron con el usuario ADMINISTRADOR.

123


PRUEBA FUNCIONAL

MODULO: MODIFICAR AUMENTO

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos la modificación del aumento, donde el sistema nos traerá los datos respectivos del aumento con base al año que luego modificaremos y actualizaremos en la base de datos.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. También debe existir ya aumento para el respectivo año en la base de datos para modificar sus datos.





- Seleccionamos en AUMENTO la opción de modificar aumento.

- Completamos el año del aumento a modificar.


- El sistema nos trae los datos del aumento a las casillas de texto.

- El usuario modifica los datos del aumento.


- El sistema modifica los datos correspondientes del aumento.

Resultado Esperado - El sistema trajo los datos del sustituto.




124


PRUEBA FUNCIONAL

MODULO: INACTIVAR AUMENTO

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos la inactivación del aumento donde el sistema inactivara el aumento en el respectivo año para no ser tenido en cuenta por el sistema.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. También debe existir ya el aumento para el respectivo periodo en la base de datos para inactivar sus datos.





- Seleccionamos en AUMENTO la opción de Inactivar aumento.

- Completamos el periodo a inactivar.


- El sistema nos muestra los datos del aumento para estar seguros del sustituto a inactivar.


- El sistema inactiva los datos del aumento y nos muestra un mensaje de éxito en la inactivación.




125


PRUEBA FUNCIONAL

MODULO: INSERTAR AUMENTO

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos, en el menú, la opción de insertar un nuevo aumento, donde el sistema guardara los datos del aumento

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. El aumento a insertar no debe existir en la base de datos.





- Seleccionamos en AUMENTO la opción de insertar aumento.

- Completamos todos los campos relacionados al aumento.


- El sistema inserta en la base de datos los datos del aumento.

Resultado Esperado - El sistema guardo satisfactoriamente los datos del aumento y mostro el respectivo mensaje exitoso.



126


PRUEBA FUNCIONAL

MODULO: CONSULTAR AUMENTO

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos, en el menú, la opción de consultar los aumentos de todos los años.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. Deben existir aumentos para mostrar.





- Seleccionamos en AUMENTO la opción de consultar aumentos.

- El sistema nos mostrara la tabla de los aumentos con sus respectivos periodos.

Resultado Esperado - El sistema mostros los aumentos con sus periodos tal cual están en la base de datos..



127


PRUEBA FUNCIONAL

MODULO: MODIFICAR INTERES

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos la modificación de un respectivo interés, donde el sistema actualizara la base de datos.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. También debe existir ya el interés para ser modificado.





- Seleccionamos en DTF la opción de modificar DTF.

- Completamos los datos del interés.


- El sistema modifica los datos correspondientes al interés.

Resultado Esperado - El sistema actualizo correctamente todos los datos en la base de datos que fueron modificados por el administrador



128


PRUEBA FUNCIONAL

MODULO: INACTIVAR INTERES

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos la inactivación del interés donde el sistema inactivara el aumento en el respectivo año y mes del interés.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. También debe existir ya el interés a ser inactivado.





- Seleccionamos en DTF la opción de Inactivar tasa.

- Completamos el año y seleccionamos el mes a inactivar.


- El sistema inactiva los datos del interés con su respectivo año y mes, nos muestra un mensaje de éxito en la inactivación.




129


PRUEBA FUNCIONAL

MODULO: INSERTAR INTERES

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos, en el menú, la opción de insertar un nuevo interés DTF, donde el sistema guardara los datos del aumento

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. El interes a insertar no debe existir en la base de datos.





- Seleccionamos en DTF la opción de insertar DTF.

- Completamos todos los campos relacionados al Interés DTF.


- El sistema inserta en la base de datos los datos del interés DTF.

Resultado Esperado - El sistema guardo satisfactoriamente los datos del interés y mostro el respectivo mensaje exitoso.



130


PRUEBA FUNCIONAL

MODULO: CONSULTAR INTERES

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos, en el menú, la opción de consultar los aumentos de todos los años.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. Deben existir aumentos para mostrar.





- Seleccionamos en DTF la opción de consulta DTF.

- Completamos los datos para el filtro.

- El sistema nos mostrara la tabla de los intereses con su respectivo año y mes.

Resultado Esperado - El sistema mostro el interés del periodo que insertamos.



131


PRUEBA FUNCIONAL

MODULO: GENERAR LIQUIDACION DE CAPITAL

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos, en el menú, la opción de generar una liquidación de capital.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. Deben existir aumentos. Debe existir el pensionado a liquidar. Debe existir la entidad con la cual se va a liquidar.





- Seleccionamos en Liquidaciones la opción de liquidación pensionado- capital.



- El sistema genera la liquidación.


- Si el usuario quiere guarda la liquidación. En este caso se guarda la liquidación.

- El sistema inserta en la base de datos los datos de la liquidación.




132


PRUEBA FUNCIONAL

MODULO: CONSULTAR LIQUIDACION DE CAPITAL

Fecha:




Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. Debe existir ya la liquidación para el pensionado.





- Seleccionamos en LIQUIDACIONES la opción de consultar liquidación.


- Pulsamos el botón CONSULTAR.

- El sistema nos mostro la liquidación del pensionado.




133


PRUEBA FUNCIONAL

MODULO: GENERAR LIQUIDACION DTF

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos, en el menú, la opción de generar una liquidación DTF.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. Deben existir aumentos. Debe existir el pensionado a liquidar. Debe existir la entidad con la cual se va a liquidar. Deben existir intereses DTF para liquidar.





- Seleccionamos en Liquidaciones la opción de liquidación pensionado- DTF.



- El sistema genera la liquidación DTF.


- Si el usuario quiere guarda la liquidación DTF. En este caso se guarda la liquidación.

- El sistema inserta en la base de datos los datos de la liquidación DTF.




134


PRUEBA FUNCIONAL

MODULO: CONSULTAR LIQUIDACION DTF

Fecha:




Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. Debe existir ya la liquidación DTF para el pensionado.





- Seleccionamos en LIQUIDACIONES la opción de consultar liquidación DTF.


- Pulsamos el botón ACEPTAR.

- El sistema nos mostro la liquidación DTF del pensionado.




135


PRUEBA FUNCIONAL

MODULO: MODIFICAR USUARIO

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos la modificación de un usuario, donde el sistema actualizara la base de datos. Acá se podrá modificar los permisos que tiene el usuario sobre el sistema.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. También debe existir ya un usuario en la base de datos para ser modificado





- Seleccionamos en USUARIO la opción de modificar usuario.

- Completamos el LOGIN del usuario.

- Pulsamos el link traer datos del usuario.

- El sistema muestra los permisos que tiene el usuario y se agregaron mas permisos al usuario.

- El sistema modifica los datos correspondientes al usuario agregándole nuevos permisos.

Resultado Esperado - El sistema actualizo correctamente todos los datos en la base de datos que fueron modificados por el administrador



136


PRUEBA FUNCIONAL

MODULO: INACTIVAR USUARIO

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos la inactivación usuario para que no pueda entrar al sistema.

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. También debe existir ya un usuario en la base de datos.





- Seleccionamos en USUARIO la opción de Inactivar usuario.

- Completamos el campo del LOGIN.


- El sistema inactiva al usuario, nos muestra un mensaje de éxito en la inactivación.




137


PRUEBA FUNCIONAL

MODULO: INSERTAR USUARIO

Fecha:



Descripción Nos introducimos al sistema como usuario administrador. Accediendo a su funcionalidad y solicitamos, en el menú, la opción de insertar un nuevo usuario para que pueda tener acceso al sistema

Condición de ejecución El administrador debe haber iniciado su sesión para poder acceder al sistema. El usuario a insertar no debe existir en la base de datos.





- Seleccionamos en USUARIO la opción de nuevo usuario.

- Completamos todos los campos relacionados al usuario y sus permisos para el sistema.


- El sistema inserta en la base de datos los datos al nuevo usuario.

Resultado Esperado - El sistema guardo satisfactoriamente los datos del usuario y mostro el respectivo mensaje exitoso.



138


PRUEBA FUNCIONAL

MODULO: INICIAR SESION Fecha:



Descripción Para introducirnos al sistema, debemos primero haber iniciado sesión para acceder así al menú según los permisos del usuario.

Condición de ejecución Debe existir un usuario con acceso al sistema.




- Nos aparece la interfaz del menú del sistema según los permisos del usuario.

Resultado Esperado - El sistema nos permitió entrar al sistema y nos mostro el menú con la opciones de acceso de su perfil.



Documents

Aplicacion para la gestion de cuotas partes pensionales de la …red.uao.edu.co/bitstream/10614/405/3/TIS00566.pdf · 2019. 9. 17. · 9.4.4 xajax 43 9.4.5 adodb 44 9.5 PRUEBAS 44