Historia de Cambios. Fecha Versión Descripción Autor <06/Agosto/2007> <1.0> <Creación y revisión del Documento>

Transcripción

1 ICETEX SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS DOCUMENTO DE ARQUITECTURA DEL NUEVO SISTEMA DE CRÉDITO Y CARTERA DEL ICETEX

2 Historia de Cambios Fecha Versión Descripción Autor <06/Agosto/2007> <1.0> <Creación y revisión del Documento> <Roberto Pardo, William Ciendua, Olga Alejandra Pantoja R. > Confidencial ICETEX, 2007 Pág. 2

3 TABLA DE CONTENIDO 1. INTRODUCCION QUÉ ES ARQUITECTURA DE SOFTWARE LO TRADICIONAL VS. NUESTRA VISION ARQUITECTURA DE NEGOCIO LA CLAVE DE LA ARQUITECTURA DE NEGOCIO DIAGRAMA GLOSARIO CONVENCIONES UTILIZADAS EN EL DIAGRAMA OBJETOS DEL SISTEMA LISTA DE ESTADOS POR OBJETO CAUSALES DE ANULACION DE LA SOLICITUD DE ADJUDICACION CAUSALES DE NO APROBACION DE LA SOLICITUD DE ADJUDICACION CAUSALES DE ELEGIBLE DE LA SOLICITUD DE ADJUDICACION CAUSALES DE APLAZAMIENTO EN LA RENOVACION CAUSALES DE BLOQUEO EN LA RENOVACION CAUSALES PARA EL PASO DEL CREDITO A ETAPA FINAL DE AMORTIZACION DIAGRAMA GENERAL DE ESTADOS TRANSICIÓN DE ESTADOS DE LA SOLICITUD TRANSICIÓN DE ESTADOS DE LA RESOLUCIÓN TRANSICIÓN DE ESTADOS DEL GIRO DEL BENEFICIARIO TRANSICIÓN DE ESTADOS DE LA OPERACIÓN DE CRÉDITO TRANSICIÓN DE ESTADOS DE LA RENOVACIÓN TRANSICIÓN DE OPERACIÓN CARTERA SUBESTADOS DE CARTERA DIAGRAMA DE ESTADOS PARA FONDOS CERRADOS (P.E. COOPERATIVAS) TRANSICIÓN DE ESTADOS DE LA SOLICITUD RESUMEN DE REQUERIMIENTOS TECNICOS Confidencial ICETEX, 2007 Pág. 3

4 3. ARQUITECTURA LOGICA SOA Y NIVELES/CAPAS REQUERIMIENTOS TECNICOS BPM REQUERIMIENTOS TECNICOS INTERFASE DE USUARIO (IU) Y FORMULARIOS REQUERIMIENTOS TECNICOS SERVICIOS SERVICIOS DE CALCULOS SERVICIOS DE INTEGRACION SERVICIOS UTILITARIOS DE NEGOCIO SERVICIOS UTILITARIOS DE SISTEMAS OPTIMIZACION CACHE APLICATIVOS REQUERIMIENTOS TECNICOS BASES DE DATOS Y PERSISTENCIA SEGURIDAD Y AUDITORÍA PATRONES GENERALES ARQUITECTURA FISICA PLATAFORMAS Confidencial ICETEX, 2007 Pág. 4

5 1. INTRODUCCION EL objetivo de este documento es presentar los lineamiento de la Arquitectura del nuevo Sistema de Software de Crédito y Cartera del ICETEX (para abreviar lo llamaremos el SCC, pero se espera que más adelante tenga un nombre más interesante). Esta es la primera versión de la misma y debe ser detallada y afinada a lo largo de la construcción del sistema, tal como lo indican las buenas prácticas iterativas e incrementales de la metodología RUP. Sin embargo la esencia fundamental de la arquitectura está delineada en este documento y es la base de los requerimientos técnicos de arquitectura en los términos de referencia para la construcción y/o adaptación final del sistema. Para realizar este documento se analizaron los requerimientos expresados en los Casos de Uso de Sistemas del nuevo Sistema de Crédito y Cartera. Igualmente se han tenido en cuenta las políticas de Informáticas definidas en el ICETEX en cuanto a uso de hardware, software de infraestructura, políticas de seguridad, y realización de otros proyectos de sistemas de información definidos en el Plan de Informática QUÉ ES ARQUITECTURA DE SOFTWARE Arquitectura de Software es, a grandes rasgos, una vista de un sistema que define los principales componentes, el comportamiento de éstos, y las formas en que los componentes interactúan y se coordinan para alcanzar el objetivo del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión y suprimiendo detalles que no cambian las abstracciones. Esta es una definición tal vez demasiado amplia. Un autor establece que la arquitectura de software de un sistema constituye un puente entre el requerimiento y el código, ocupando el lugar que en los gráficos antiguos se reservaba para el diseño. La definición más oficial de Arquitectura tal vez es la que se encuentra en el documento de IEEE1471: La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución. Confidencial ICETEX, 2007 Pág. 5

6 Aunque existen muchas definiciones de Arquitectura de un Sistema de Software, la esencia de todas es que Arquitectura es la descripción de la estructura fundamental de un sistema. La Arquitectura permite pensar sobre la estructura global sin caer en los detalles de algoritmos y estructuras de datos. La Arquitectura permite visualizar y analizar cómo interactúan las partes que componen un sistema. Se pretende identificar los mecanismos de comunicación y sincronización entre sus partes, cuáles partes manejan las grandes divisiones funcionales de un sistema que interesan a los usuarios, y cómo deben ser las partes que manejan las funciones clásicas del software en cuanto a presentación al usuario, a reglas de negocio y a datos persistentes. Mediante la Arquitectura se puede analizar un sistema a un nivel alto de abstracción mostrando las principales decisiones de diseño. Es importante que la Arquitectura sea de alto nivel pues un sistema de software se compone de miles de detalles que muchas veces obscurecen las decisiones de fondo, las que a su vez determinan las principales propiedades técnicas de un sistema como rendimiento, escalabilidad, flexibilidad, reutilización, entre otros. En la metodología RUP, la definición de una Arquitectura de un Sistema es una actividad fundamental en la fase de Elaboración, por cuanto determina la estructura global del sistema, y así permite definir más claramente el esfuerzo que se hará durante la fase de Construcción. Sólo cuando se ha definido la Arquitectura se puede definir realmente el presupuesto de construcción de un sistema. Cualquier estimativo anterior puede estar muy desfasado de la realidad. Es importante aclarar que arquitectura no es diseño. En Arquitectura se toman las decisiones de fondo mientras que en el diseño se detallan las decisiones de fondo sin programar aún. En este documento se describe así la Arquitectura del SCC, sin entrar en los detalles de diseño pero sí identificando la forma como se debe estructurar el sistema y definiendo los principios de diseño del mismo LO TRADICIONAL VS. NUESTRA VISION Tradicionalmente la Arquitectura de software de un sistema se ha trabajado como un tema muy técnico y muy orientado al ámbito de software. Nuestra visión es diferente. Creemos que lo técnico es muy importante, pero más importante es la estructura que se le de a la solución desde el punto de vista de negocio. Creemos después de haber construido varios sistemas grandes que una Arquitectura de Software refleja íntimamente una Arquitectura de Negocio y por lo tanto si la Arquitectura (léase la estructura de la solución ) de Negocio está mal concebida, así mismo la Arquitectura de Software reflejará una mala Arquitectura de Negocio, aunque técnicamente puede ser muy sólida. Creemos que la escritura como tal Confidencial ICETEX, 2007 Pág. 6

7 de Casos de Uso de Sistema refleja una concepción de Negocio y muchas veces la misma arquitectura de negocio, que más tarde condiciona la Arquitectura Técnica de Software. Para efectos de este trabajo Arquitectura es equivalente a estructura de la solución. Así, Arquitectura de Negocio (o Arquitectura Conceptual) es la estructura de la solución de negocio, que no necesariamente tiene que ver con tecnología o software. La Arquitectura de Software o de Sistema (o Arquitectura Lógica) es la estructura de la solución de software, que refleja la Arquitectura de Negocio, debe estar alineada con éste, y no está necesariamente atada a una plataforma de software o hardware. Finalmente la Arquitectura de Implantación (o Arquitectura Física) es la estructura de la solución en términos de plataforma de software y hardware. Cada tipo de Arquitectura es como una forma de ver (una vista ) del sistema. Las vistas son complementarias pues se requieren todas para entender la estructura completa del sistema, pero como se indicó anteriormente, la Vista Conceptual es la más importante por cuanto define la estructura del negocio como tal. Resumiendo, para efectos de este trabajo se han agrupado varias Vistas en lo que llamamos tres tipos de Arquitectura: la Conceptual, la Lógica y la Física. Arquitectura Conceptual = Arquitectura de Negocio Describe la estructura básica de la solución, basada en los Requerimientos y Casos de Uso de Negocio. En esta vista se toman decisiones CONCEPTUALES importantes que definen la estructura de la solución de software. Por ejemplo en el SCC se define que todas las líneas de crédito del ICETEX son similares en cuanto a su estructura y lo que las diferencia son parámetros expresados en forma de reglas de negocio y condiciones. Aún más importante, la arquitectura conceptual del SCC define los objetos de negocio clave (solicitud, cartera, deudor, etc.) y hace un modelo de estados por los que pasan estos objetos durante la vida de un crédito en el sistema. Arquitectura Lógica = Arquitectura Técnica del Sistema = Arquitectura de Software. Describe los componentes lógicos del sistema, su estructura interna básica, y sus relaciones. Incluye los componentes lógicos tanto de negocio (funcionales) como técnicos (no funcionales). Normalmente es independiente de la Plataforma tecnológica en la que se implementará el sistema. Incluye la llamada Vista Lógica. A veces incluye la Vista de Datos cuando se describe la persistencia de ciertas entidades de negocios. En el SCC la Arquitectura Lógica define una estructura basada en capas y servicios. Identifica los servicios tanto funcionales como técnicos. Arquitectura Física = Arquitectura de Implantación. Confidencial ICETEX, 2007 Pág. 7

8 Describe las tecnologías que se deben usar de la Plataforma escogida y decisiones básicas sobre asociación de componentes lógicos y físicos. Describe decisiones sobre la Plataforma (frameworks, librerías, patrones), las decisiones sobre Arquitectura de Hardware (tipos de servidores, tipos de clientes) y guías de diseño en la plataforma escogida. En el SCC la Arquitectura Física define la Plataforma JEE5, algunos patrones y librerías, y algunas configuraciones de hardware. En este documento explicamos cada una de estas vistas en cierto detalle. Dado que el sistema se va a construir externamente, el enfoque de estas vistas es detallar lo necesario para definir unos requerimientos técnicos, tratando de no restringir a los posibles proveedores y dejando libertad al contratista para decidir aspectos del diseño del sistema. 2. ARQUITECTURA DE NEGOCIO En esta sección presentamos la arquitectura de negocio del SCC LA CLAVE DE LA ARQUITECTURA DE NEGOCIO Existen tres principios fundamentales sobre los cuales está basada esta arquitectura, a saber: 1. Todos los productos de crédito se deben poder representar en el mismo aplicativo. Esto evita los problemas de generar aplicaciones separadas dependiendo de las especificidades de los productos de crédito. Un solo ejecutable que maneja todo. 2. El software debe modelarse fundamentalmente como un sistema basado en estados, donde un crédito (llamado así desde el punto de vista de un usuario) viaja por una multitud de estados (solicitud radicada, solicitud aprobada, resolución generada, giro en firme, operación de cartera al día, etc.). Existen condiciones y acciones que hacen pasar a un crédito de un estado a otro. Cada producto define sus propios caminos y condiciones dentro del sistema de estados. Confidencial ICETEX, 2007 Pág. 8

9 3. El sistema es altamente parametrizado, es decir, muchos valores, tablas, fórmulas y algoritmos se deben poder cambiar fácilmente sin necesidad de recompilar o generar nuevos ejecutables DIAGRAMA Gráficamente, la arquitectura conceptual puede dibujarse así: En esta sección presentamos la estructura del sistema usando estados, y mostramos la relación de éstos con los casos de uso. Confidencial ICETEX, 2007 Pág. 9

10 GLOSARIO Acción Creación de un objeto destino como consecuencia de un cambio de estado de un objeto origen. Diagrama de Estados Es un grafo que muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación, junto con los cambios que permiten pasar de un estado a otro. Los Diagramas de Estado representan autómatas de estados finitos, desde el punto de vista de los estados y las transiciones. Son útiles sólo para los objetos con un comportamiento significativo. Cada objeto está en un estado en cierto instante. El estado está caracterizado parcialmente por los valores de los atributos del objeto. El estado en el que se encuentra un objeto determina su comportamiento. Cada objeto sigue el comportamiento descrito en el Diagrama de Estados asociado a su clase. Los Diagramas de Estados y escenarios son complementarios, los Diagramas de Estados son autómatas jerárquicos que permiten expresar concurrencia, sincronización y jerarquías de objetos, son grafos dirigidos y deterministas. La transición entre estados es instantánea y se debe a la ocurrencia de un evento. Estado Es la identificación durante un periodo de tiempo del objeto (no instantáneo) en el cual el objeto está esperando alguna operación, tiene cierto estado característico o puede recibir cierto tipo de estímulos. Confidencial ICETEX, 2007 Pág. 10

11 Evento Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Esta ocurrencia puede corresponder a una: o Condición que toma el valor de verdadero o falso o Recepción de una señal de otro objeto en el modelo o Recepción de un mensaje o Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y fecha particular Objeto Es una entidad lógica dentro de la aplicación que tiene sentido para el usuario del sistema, es una unidad atómica que encapsula estado y comportamiento. Se define a un objeto como "una entidad tangible que muestra alguna conducta bien definida". Un objeto "es cualquier cosa, real o abstracta, acerca de la cual almacenamos datos y los métodos que controlan dichos datos". SubEstado Un estado puede descomponerse en subestados, con transiciones entre ellos y conexiones al nivel superior. Las conexiones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel inmediatamente superior. Transición Es una relación entre dos estados que indica que un objeto en el primer estado puede pasar al segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son satisfechas. También hace referencia al cambio de un estado de un objeto destino como consecuencia del cambio de estado de un objeto origen. Confidencial ICETEX, 2007 Pág. 11

12 CONVENCIONES UTILIZADAS EN EL DIAGRAMA CONVENCION DESCRIPCION Inicio o Creación del objeto. Estado no final de un objeto.... Estado Final de un objeto. Transición o Acción. Perímetro de los estados de un objeto. Confidencial ICETEX, 2007 Pág. 12

13 2.2. OBJETOS DEL SISTEMA Transacción Solicitud Adjudicación Resolución Obligación Cartera Giro por Beneficiario Crédito Renovación Confidencial ICETEX, 2007 Pág. 13

14 OBJETO Solicitud de Adjudicación Resolución Giro Crédito Obligación Cartera Renovación DESCRIPCIÓN Entidad que contiene la información registrada por el solicitante y que hace parte de los datos del otorgamiento del crédito.. Entidad que representa el documento soporte a un desembolso de dinero, bien sea en la adjudicación del crédito como en la renovación del mismo Entidad que representa los datos del desembolso Entidad que se crea en el momento del primer desembolso y que constituye posteriormente una obligación Entidad que contiene la información de los saldos de la deuda de crédito del beneficiario y su comportamiento de pago Entidad que determina la ejecución o no de un desembolso. Transacción Entidad que registra la ejecución de la disponibilidad presupuestal, operaciones sobre el presupuesto y la tesorería, giros, pagos y novedades de cartera Confidencial ICETEX, 2007 Pág. 14

15 2.3. LISTA DE ESTADOS POR OBJETO OBJETO ESTADO DESCRIPCION Solicitud de Adjudicación Radicada Parcial No hay completitud en los datos que se registran en la solicitud de adjudicación. Se constituye en el primer estado de la solicitud de crédito Radicada En Estudio No Aprobada (*) Elegible Anulada (*) Se han ingresado la totalidad de los datos. La solicitud se encuentra en proceso de evaluación por parte del comité de crédito Después del proceso de evolución acorde con las políticas del ICETEX la solicitud presenta causales de no aprobación La solicitud cumple con todos los requisitos para que sea aprobada la solicitud pero no existe disponibilidad presupuestal. Esta solicitud queda pendiente de aprobación o no aprobación en los próximos comités. Es el no otorgamiento del crédito por las causales de anulación. Confidencial ICETEX, 2007 Pág. 15

16 OBJETO ESTADO DESCRIPCION Aprobada Desistida (*) Legalizada Visada Generada en resolución Aprobada en resolución Enviada en resolución La solicitud cumple con todos los requisitos y esta lista para continuar con la legalización. Es cuando el beneficiario informa de su renuncia al proceso para obtener el crédito. Confirmación del cumplimiento de los requisitos exigidos por el ICETEX de los documentos de carta de compromiso y pagare. Es la aprobación por parte del ICETEX consecuencia de la revisión final de toda la documentación e información ingresada de la solicitud. Es cuando la solicitud hace parte de una resolución de giro pero la resolución aún no ha sido autorizada para desembolso Es cuando la solicitud hace parte de una resolución de giro y dicha resolución tiene la autorización para el desembolso Es cuando la solicitud es parte de la resolución de giro en estado enviada. Confidencial ICETEX, 2007 Pág. 16

17 OBJETO ESTADO DESCRIPCION Girada (*) El sistema financiero le informa al sistema de crédito y cartera que números de cuenta pudieron ser giradas, cuentas que están relacionadas con una solicitud de crédito; en ese caso la solicitud queda en estado girada. No Girada (*) El sistema financiero le informa al sistema de crédito y cartera que números de cuenta no pudieron ser giradas, cuentas que están relacionadas con una solicitud de crédito; en ese caso la solicitud queda en estado no girada. Estas solicitudes quedan disponibles en el sistema para ser reprocesadas. Confidencial ICETEX, 2007 Pág. 17

18 OBJETO ESTADO DESCRIPCION Resolución Generada Se establecen los parámetros de la resolución como documento de soporte al desembolso de un conjunto de solicitudes de adjudicación o renovación visadas. Aprobada Anulada Enviada Notificada Es la aprobación de desembolso. Es la no aprobación de la resolución Es el envío de la resolución aprobada al sistema financiero. Es la respuesta del sistema financiero de la resolución enviada. Confidencial ICETEX, 2007 Pág. 18

19 OBJETO ESTADO DESCRIPCION Giro por Beneficiario En Proceso Hace referencia al desembolso del beneficiario se encuentra en la resolución generada, aprobada o enviada. En firme Es la realización del desembolso al beneficiario consecuencia de la respuesta enviada del sistema financiero. Anulada Rechazado El giro se anuló a causa de la anulación de la resolución que lo contenga El giro no fue exitoso. Confidencial ICETEX, 2007 Pág. 19

20 OBJETO ESTADO DESCRIPCION Crédito Activo sin bloqueo El crédito tiene desembolsos pendientes y cumple con la condiciones para la renovación del crédito Activo con bloqueo Activo Aplazado Activo sin desembolsos pendientes Finalizado El crédito tiene desembolsos pendientes y está inhabilitado para realizar la renovación del crédito El crédito tiene desembolsos pendientes y esta sin ninguna restricción para ejecutar la renovación de desembolso. El crédito NO tiene desembolsos pendientes. El crédito ya fue cancelado. Confidencial ICETEX, 2007 Pág. 20

21 OBJETO ESTADO DESCRIPCION Obligación Cartera CEE al día El crédito se encuentra en época de estudio al día. CEE atrasado en cuota CPG al día CPG atrasado en cuota CEA al día CEA Mora El crédito se encuentra en época de estudios y atrasado en cuota de cultura de pago El crédito se encuentra en periodo de gracia al día. El crédito se encuentra en periodo de gracias y atrasado en cuotas El crédito se encuentra en Etapa final de amortización al día. El crédito se encuentra en Etapa final de amortización en mora. Confidencial ICETEX, 2007 Pág. 21

22 OBJETO ESTADO DESCRIPCION Subestados de Mora del objeto Obligación Cartera (Estos subastados pueden ser parametrizables a partir de la mora en cuotas o por la calificación de la cartera) Cobro preventivo El crédito se encuentra entre 1 y 30 días de mora. Cobro correctivo Cobro pre-jurídico El crédito se encuentra entre 31 y 60 días de mora. El crédito se encuentra con más 60 días de mora. Cobro Jurídico El crédito se encuentra con más de 180 días de mora. Confidencial ICETEX, 2007 Pág. 22

23 OBJETO ESTADO DESCRIPCION Subestados del objeto Obligación Cartera Normal Castigada Se tiene confianza en el pago de la obligación. Se entiende por cartera vencida aquella respecto de la cual el plazo ordinario de pago se ha cumplido, encontrándose el deudor en mora en el pago de las obligaciones. A su turno, por cartera castigada se debe entender aquella cartera vencida respecto de la cual se han agotado los procedimientos de cobro sin ningún resultado lo que hace temer que el derecho de crédito no sea recuperable. Confidencial ICETEX, 2007 Pág. 23

24 OBJETO ESTADO DESCRIPCION Subestados del objeto Obligación Cartera No reestructurado No hay cambios de condiciones originales que obedezcan a un deterioro en la capacidad de pago por parte del deudor. Reestructurado Se considerará un crédito como reestructurado siempre que un cambio en los términos y condiciones originalmente pactadas sean motivadas por un deterioro en la capacidad de pago de los créditos por parte del deudor Confidencial ICETEX, 2007 Pág. 24

25 OBJETO ESTADO DESCRIPCION Renovación Bloqueada Se presentó una causal de bloqueo para que la renovación de desembolso no pueda realizar. Aplazada Desistida Aprobada Se presentó una causal de aplazamiento para que la renovación de desembolso no pueda ser realizada. Se presentó una causal de desistimiento para que la renovación de desembolso no pueda ser realizada. Se cumplieron con todos los requisitos para renovar la solicitud de desembolso CAUSALES DE ANULACION DE LA SOLICITUD DE ADJUDICACION Por vencimiento de términos. Por solicitud del Beneficiario del crédito Por inconsistencias en los datos (falsedad en información cuando se realiza validación de datos) en especial cuando son datos evaluables. Confidencial ICETEX, 2007 Pág. 25

26 CAUSALES DE NO APROBACION DE LA SOLICITUD DE ADJUDICACION Por mérito académico, Decisión de no aprobar la solicitud elegible Por no cumplir con alguno de los requisitos evaluables definidos en la parametrización de cada modalidad de crédito y/o fondo CAUSALES DE ELEGIBLE DE LA SOLICITUD DE ADJUDICACION Por la no disponibilidad presupuestal de una solicitud que cumple con todos los requisitos para ser aprobada CAUSALES DE APLAZAMIENTO EN LA RENOVACION 1. Retiro temporal del programa académico por calamidad doméstica, incapacidad certificada, fuerza mayor o caso fortuito entre otros, debidamente justificados por el beneficiario. 2. Obtención de beca u otra forma de cubrimiento de los costos académicos, otorgada por la Institución de Educación Superior u otra entidad, sin límite de períodos académicos. 3. Cierre temporal del centro docente y/o programa académico. 4. Por expresa voluntad del beneficiario 5. Por enfermedad, fuerza mayor y caso fortuito. 6. Prestación del servicio Militar 7. Por secuestro del beneficiario, debidamente certificado por la enditad competente, por el término que dure la retención y un término de adaptación igual hasta un año, a solicitud del beneficiario. Existen algunas causales de aplazamiento no cuentan para la configuración de la política del ICETEX en cuanto a las condiciones de la renovación. Confidencial ICETEX, 2007 Pág. 26

27 CAUSALES DE BLOQUEO EN LA RENOVACION 1. Suspensión del estudiante por parte de la Institución de Educación Superior y/o Escuela Normal Superior. 2. Repetición de un período académico ya financiado. 3. Cambio de centro docente o de programa de estudios que implique nivelación hasta por dos períodos académicos. 4. No estar al día en el cumplimiento de las obligaciones con el ICETEX. 5. Información inconsistente del núcleo familiar 6. Información inconsistente de la información académica. 7. Información inconsistente de la información de referencias personales. 8. Información inconsistente del Deudor Solidario 9. Información inconsistente de la Garantía 10. No actualización de la identificación del Beneficiario: (Tarjeta de identidad vencida). 11. Supero número de aplazamientos permitidos en el sistema. 12. Inconsistencia en el estrato reportado. 13. Convenio suspendido CAUSALES PARA EL PASO DEL CREDITO A ETAPA FINAL DE AMORTIZACION 1. Finalización del programa de estudios para el cual se concedió el crédito educativo. (No necesariamente se cumple el número de giros pactados) 2. Realización del último giro, según el número de períodos a financiar establecidos al momento del otorgamiento del crédito. 3. Expresa voluntad del beneficiario, cuando desea continuar sus estudios, pero no requiere más desembolsos. 4. Reincidencia en la suspensión por parte de la Institución Educativa Superior o Escuela Normal Superior. 5. Abandono injustificado del programa de estudios. 6. Adulteración de documentos o presentación de información falsa en cualquier momento de la vida del crédito. 7. Comprobación por parte del ICETEX, a través de las Instituciones de Educación Superior IES o cualquier medio, sobre falsedad en la información suministrada, especialmente en lo referente al estrato socioeconómico y al registro en el SISBEN. 8. Utilización del crédito para fines distintos de aquellos para los cuales fue concedido. 9. Cambio de centro docente o de programa de estudios sin previa autorización por parte del ICETEX. Confidencial ICETEX, 2007 Pág. 27

28 10. No informar al ICETEX de ingresos adicionales por becas, comisión de estudios u otra clase de apoyo económico para financiar los estudios que reciba el beneficiario durante el tiempo en que disfrute del crédito educativo. 11. No presentar durante más de dos períodos académicos información sobre desempeño académico, la no actualización de la información personal y la del(los) deudor(es) solidario(s). 12. No tramitar la renovación del servicio según lo establecido en el presente Reglamento por más de dos períodos académicos. 13. Incurrir por tercera vez en la suspensión temporal de desembolsos. 14. La reincidencia en la repetición de un período académico. 15. Muerte o invalidez del beneficiario. 16. Suspensión definitiva de los estudios. 17. Incumplimiento por parte del estudiante de cualquiera de las obligaciones contractuales y reglamentarias expedidas por el ICETEX. Confidencial ICETEX, 2007 Pág. 28

29 2.4. DIAGRAMA GENERAL DE ESTADOS. Confidencial ICETEX, 2007 Pág. 29

30 ICETEX

31 Confidencial ICETEX, 2007 Pág. 31

32 Confidencial ICETEX, 2007 Pág. 32

33 Confidencial ICETEX, 2007 Pág. 33

34 Confidencial ICETEX, 2007 Pág. 34

35 ICETEX El diagrama general presenta todos los estados de los objetos que participan en el sistema de crédito y cartera: En el diagrama se describe la secuencia de estados empezando por la solicitud de adjudicación y cuando esta inicia a formar parte de una resolución de giro que a su vez genera la creación de un giro cuando la resolución es aprobada. Si el giro es exitoso este genera la creación de la operación de cartera en un estado inicial de CEE al día y la creación de operación de crédito con un estado inicial de activo sin bloqueo. Una vez la operación de crédito se ha creado en el sistema se presentan las renovaciones que dependiendo de su realización modifican el estado de la operación de crédito que puede ser bloqueada, aplazada o continua activo sin bloqueo o queda activo sin desembolsos pendientes si corresponde a la última renovación. Cuando el crédito se ha creado también se controla el saldo y el comportamiento de pago con los estados del objeto de operación de cartera. Los objetos operación crédito y operación cartera también cambian de estados por la ejecución de novedades que hacen que se cambie uno de esos estados.

36 A continuación se describe las transiciones de estados por la ejecución de los casos de uso: TRANSICIÓN DE ESTADOS DE LA SOLICITUD. Transición de Estados Radicada Parcial De Radicada Parcial a Casos de Uso OTO-SIS- 001 Registrar Solicitud de crédito de un Solicitante OTO-SIS- 008 Modificar la solicitud cuando falta información en la etapa de diligenciamiento de la solicitud de crédito Radicada De Radicada Parcial a NOV-SYS-005 Anular créditos aprobados que no fueron legalizados NOV-SIS-006- Anular créditos Anulada De Radicada a Desistida De Radicada OTO-SIS- 013 Validar la información del formulario de solicitud A En Estudio En Estudio A No Aprobada OTO-SIS- 014 Generar las evaluaciones de las solicitudes OTO-SYS- 016 Actualizar el estado de las solicitudes de crédito en el comité En estudio a desistida Confidencial ICETEX, 2007 Pág. 36

37 En Estudio A Elegible En Estudio A Anulada En Estudio A Aprobada Elegible a Aprobada OTO-SIS- 014 Generar las evaluaciones de las solicitudes OTO-SYS- 016 Actualizar el estado de las solicitudes de crédito en el comité OTO-SIS- 014 Generar las evaluaciones de las solicitudes OTO-SYS- 016 Actualizar el estado de las solicitudes de crédito en el comité OTO-SIS- 014 Generar las evaluaciones de las solicitudes OTO-SYS- 016 Actualizar el estado de las solicitudes de crédito en el comité OTO-SIS- 014 Generar las evaluaciones de las solicitudes OTO-SYS- 016 Actualizar el estado de las solicitudes de crédito en el comité Elegible a No Aprobada OTO-SIS- 014 Generar las evaluaciones de las solicitudes OTO-SYS- 016 Actualizar el estado de las solicitudes de crédito en el comité Elegible a Desistida Confidencial ICETEX, 2007 Pág. 37

38 Aprobada a Legalizada OTO-SYS- 010 Autorizar créditos aprobados en el comité para legalización OTO-SYS- 017 Verificar la información de las solicitudes aprobadas OTO-SIS-020 Revisar la garantía del crédito: carta de instrucciones y pagare y confirmación de valores OTO-SIS-019 Legalizar créditos aprobados Legalizada a Aprobada Legalizada a Visada Visada a Generada en resolución Generada a aprobada en resolución Aprobada en Resolución a Girada Aprobada en Resolución a No Girada NOV-SIS-009 Reversar la legalización OTO-SIS-021 Hacer visado del crédito por parte del ICETEX GIR-SIS-002 Generar Resolución relación de Giro GIR-SIS-005 Generar Resoluciones de Giro Complementario GIR-SIS-003 Aprobar resolución relación de giro GIR-SIS-006 Cargar número de referencia del giro GIR-SIS-006 Cargar número de referencia del giro Confidencial ICETEX, 2007 Pág. 38

39 TRANSICIÓN DE ESTADOS DE LA RESOLUCIÓN. Transición de Estados A Generada Casos de Uso GIR-SIS-002 Generar Resolución relación de Giro GIR-SIS-005 Generar Resoluciones de Giro Complementario Generara a Aprobada Generada a Anulada Aprobada a Enviada Enviada a notificada GIR-SIS-003 Aprobar resolución relación de giro GIR-SIS-003 Aprobar resolución relación de giro GIR-SIS-004 Cargar información de la resolución GIR-SIS-006 Cargar número de referencia del giro TRANSICIÓN DE ESTADOS DEL GIRO DEL BENEFICIARIO Transición de Estados A En proceso Proceso a en firme Casos de Uso GIR-SIS-003 Aprobar resolución relación de giro GIR -SIS-007 Confirmar giros exitosos Proceso a Rechazado GIR-SIS-007 Confirmar giros exitosos Confidencial ICETEX, 2007 Pág. 39

40 TRANSICIÓN DE ESTADOS DE LA OPERACIÓN DE CRÉDITO Transición de Estados A activo sin bloqueo Activo sin bloqueo a activo con bloqueo Activo sin bloqueo a aplazado Activo sin bloqueo a sin desembolsos pendientes. Activo con bloqueo Aplazado a sin desembolsos pendientes. Activo con bloqueo a sin reembolsos pendientes. Sin desembolsos pendientes a finalizado. A finalizado Casos de Uso GIR-SIS-007 Confirmar giros exitosos NOV-SIS-011 Bloquear créditos CDI-SIS-001 Ejecutar Cierre Diario: CDI-SIS-002 Actualizar estados de los créditos CDI-SIS-001 Ejecutar Cierre Diario: CDI-SIS-002 Actualizar estados de los créditos CDI-SIS-001 Ejecutar Cierre Diario: CDI-SIS-002 Actualizar estados de los créditos CDI-SIS-001 Ejecutar Cierre Diario: CDI-SIS-002 Actualizar estados de los créditos NOV-SIS-012 Terminación del crédito NCA-SIS-005 Aplicar Condonación Total NCA-SIS-013 Eliminar saldos mayores a favor del Beneficiario NCA-SIS-013 Eliminar Saldos menores Confidencial ICETEX, 2007 Pág. 40

41 TRANSICIÓN DE ESTADOS DE LA RENOVACIÓN Transición de Estados Casos de Uso A Bloqueada REN-SIS-001 Realizar la actualización de datos e impresión del soporte de la renovación REN-SIS-002 Realizar la renovación (gestor del crédito) A Aplazada REN-SIS-001 Realizar la actualización de datos e impresión del soporte de la renovación REN-SIS-002 Realizar la renovación (gestor del crédito) A Desistida REN-SIS-001 Realizar la actualización de datos e impresión del soporte de la renovación REN-SIS-002 Realizar la renovación (gestor del crédito) A Aprobada REN-SIS-001 Realizar la actualización de datos e impresión del soporte de la renovación REN-SIS-002 Realizar la renovación (gestor del crédito) Confidencial ICETEX, 2007 Pág. 41

42 TRANSICIÓN DE OPERACIÓN CARTERA CEE crédito época de estudios CPG crédito periodo de gracia CEA crédito etapa final de amortización Transición de Estados CEE al día A CEA al día Casos de Uso GIR-SIS-007 Confirmar giros exitosos CEA -SIS-001 Pasar Crédito a etapa final de amortización De CEE Al día o CPG Al día o CEE atrasado en cuota o CPG atrasado en cuota. CEE Al día a CEE atrasado en cuota. CEE-SIS-001-Aplicar Giros de Adjudicación y Renovación. CPG Al día a CPG atrasado en cuota CEE atrasado en cuota. CEE-SIS-004 Aplicar Recaudos Época de Estúdio Confidencial ICETEX, 2007 Pág. 42

43 A CEE Al día CEE atrasado en cuota CEE Al día CEE atrasado en cuota. NCA-SIS-007 Reversar Giro A CEE Al día CEE atrasado en cuota CEE Al día CEE en mora a CEE al día. Ver las transacciones que se muestran en el diagrama de estados y casos de uso. Ver caso de uso de cierre de periodo académico. A CEA al día CEA-SIS-004 Aplicar Recaudos etapa final de amortización. CDI-SIS-001 Ejecutar Cierre Diario: CDI-SIS-002 Actualizar estados de los créditos CPA-SIS-001 Ejecutar Cierre Periodo Académico NCA-SIS-001 Pasar Crédito a etapa final de amortización. De CEE Al día o CPG Al día o CEE atrasado en cuota o CPG atrasado en cuota. A CEE al día NCA-SIS-001 Pasar Crédito a época de estudio. Confidencial ICETEX, 2007 Pág. 43

44 O A CEE atrasado en cuota. De: CEA al día o CEA en mora. CEE al día NCA-SIS-002 Reversar Pago A CEE atrasado en cuota. CPG al día A CPG atrasado en cuota. CEA al día A CEA en mora. CEE atrasado en cuota. NCA-SIS-004 Aplicar Pago A CEE al día CPG atrasado en cuota A CPG al día. CEA en mora a CEA al día Confidencial ICETEX, 2007 Pág. 44

45 A finalizado NCA-SIS-005 Aplicar Condonación Total CEA en mora NCA-SIS-006 Aplicar Condonación Parcial a CEA al día CEE al día NCA-SIS-009 Aplicar Giro A CEE atrasado en cuota. CEE mora NCA-SIS-010 Refinanciar Crédito. A CEE al día. A finalizado A finalizado NCA-SIS-013 Eliminar saldos mayores a favor del Beneficiario NCA-SIS-013 Eliminar Saldos menores Confidencial ICETEX, 2007 Pág. 45

46 2.5. SUBESTADOS DE CARTERA Transición de Estados A Reestructurada. A Cobro preventivo A Cobro correctivo Casos de Uso Se cambia de estado por las novedades que cambien las condiciones del crédito y estas estén parametrizadas como novedades de reestructuración. Se cambian de estados por la temporalidad días de mora o se puede cambiar de estado de manera manual. A Cobro Jurídico A Cobro Prejurídico A Castigada Se cambia a este estado por la decisión de la entidad. Este se realiza de manera manual. Confidencial ICETEX, 2007 Pág. 46

47 2.6. DIAGRAMA DE ESTADOS PARA FONDOS CERRADOS (P.E. COOPERATIVAS) Confidencial ICETEX, 2007 Pág. 47

48 Confidencial ICETEX, 2007 Pág. 48