SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA … · objeto es “realizar el levantamiento de los...

360
ICETEX SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS 22 - 09 DOCUMENTO DE CASOS DE USO DE SISTEMAS Versión <1.4>

Transcript of SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA … · objeto es “realizar el levantamiento de los...

ICETEX

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS 22 - 09 DOCUMENTO DE CASOS DE USO DE SISTEMAS Versión <1.4>

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

2

Historia de Cambios

Fecha Versión Descripción Autor

<12/Mayo/2007> <1.0> <Creación y revisión del Documento>

<Alex Fernando Buitrago – Olga Alejandra Pantoja R.>

<16/Junio/2007> <1.1> <Modificación del Documento> <Alex Fernando Buitrago – William Ciendua - Olga Alejandra Pantoja R.>

<25/Junio/2007> <1.2> <Modificación del Documento> <Alex Fernando Buitrago – William Ciendua - Olga Alejandra Pantoja R.>

<30/Junio/2007> <1.3> <Modificación del Documento> <Alex Fernando Buitrago – William Ciendua - Olga Alejandra Pantoja R.>

<30/Julio/2007> <1.4> <Modificación del Documento> <Alex Fernando Buitrago – William Ciendua - Olga Alejandra Pantoja R.>

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

3

TABLA DE CONTENIDO

INTRODUCCIÓN ................................................................................................................................. 8

MARCO TEÓRICO ............................................................................................................................ 11

1. PARAMETRIZACIÓN DE LAS TABLAS BÁSICAS ................................................................... 14

1.1 Parametrizar Tipo de Crédito definido por la Superintendencia Financiera ...................... 14

1.2 Parametrizar Tipo de Recurso .......................................................................................... 15

1.3 Parametrizar Tipo de Cobertura ....................................................................................... 16

1.4 Parametrizar Tipo de Estudio a Financiar......................................................................... 17

1.5 Parametrizar el Tipo de Rubro a Financiar ....................................................................... 18

1.6 Parametrizar los tipos de condición del crédito para constituir cartera ............................. 19

1.7 Parametrizar el Listado de Países .................................................................................... 20

1.8 Parametrizar el Tipo de Moneda ...................................................................................... 21

1.9 Parametrizar el sistema de Amortización ......................................................................... 22

1.10 Parametrizar el Tipo de Deudor ........................................................................................ 23

1.11 Parametrizar el tipo de Personería ................................................................................... 24

1.12 Parametrizar Lista de Departamentos .............................................................................. 25

1.13 Parametrizar Lista de Ciudades y/o Municipios ................................................................ 26

1.14 Parametrizar de Direcciones Territoriales del ICETEX ..................................................... 27

1.15 Crear Instituciones de Educación Superior ...................................................................... 28

1.16 Crear Entidades contratistas del ICETEX ......................................................................... 30

1.17 Crear Constituyente del Fondo ......................................................................................... 32

1.18 Crear Línea de Crédito ..................................................................................................... 34

1.19 Definir modalidad de crédito y/o fondo. ............................................................................ 35

1.20 Definir Alianza Estratégica. .............................................................................................. 37

2. PARAMETRIZACIÓN DE LAS CONDICIONES DEL CRÉDITO ............................................... 40

2.1 Crear campos del Formulario de la Solicitud .................................................................... 40

2.2 Crear sección del Formulario............................................................................................ 41

2.3 Asociar Secciones al Formulario ...................................................................................... 42

2.4 Crear Formulario de registro. ............................................................................................ 43

2.5 Establecer las etapas de la Solicitud del Crédito .............................................................. 45

2.6 Definir Calendarios ........................................................................................................... 47

2.7 Parametrizar el modelo de evaluación de crédito ............................................................. 48

2.8 Parametrizar el modelo de clasificación de cartera y cálculo de las provisiones .............. 51

2.9 Definir las condiciones de la legalización en la IES o Constituyente del Fondo ............... 53

2.10 Establecer los datos para validar en el formulario ............................................................ 56

2.11 Definir las condiciones del Giro ........................................................................................ 58

2.12 Definir el formulario para la constitución de la garantía .................................................... 60

2.13 Definir plantillas de generación de reportes oficiales ........................................................ 62

2.14 Definir Criterios de Suspensión del Crédito. ..................................................................... 64

2.15 Definir porcentaje de financiación de un rubro. ................................................................ 65

2.16 Definir condiciones de subsidio y/o Condonación. ........................................................... 67

3. PARAMETRIZACIÓN DE LA LIQUIDACIÓN DE CARTERA .................................................... 69

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

4

3.1 Definir algoritmo de generación de cuotas ....................................................................... 69

4. OTORGAMIENTO DE CRÉDITO .............................................................................................. 70

4.1 Registrar Solicitud de crédito de un solicitante ................................................................. 70

4.2 Cargar beneficiarios de fondos en el sistema de crédito y cartera .................................. 75

4.3 Crear pin de seguridad ..................................................................................................... 77

4.4 Cambiar pin de seguridad ................................................................................................ 79

4.5 Consultar estado de la Solicitud por número de identificación ........................................ 83

4.6 Registrar sección datos básicos ....................................................................................... 86

4.7 Registrar demás secciones de la solicitud de crédito ....................................................... 89

4.8 Modificar solicitud cuando falta información en la etapa de diligenciamiento de la solicitud de crédito ....................................................................................................................................... 92

4.9 Registrar la solicitud de estudio del Deudor Solidario ...................................................... 95

4.10 Evaluar el deudor solidario ............................................................................................... 98

4.11 Consultar estado del estudio del deudor solidario .......................................................... 101

4.12 Imprimir Formulario del Deudor Solidario aprobado para la legalización del crédito ...... 104

4.13 Validar la información del formulario de solicitud ............................................................ 107

4.14 Realizar la matrícula de cuentas .................................................................................... 110

4.15 Generar las evaluaciones de las solicitudes ................................................................... 113

4.16 Actualizar el estado de las solicitudes de crédito en el comité ....................................... 117

4.17 Verificar la información de las solicitudes aprobadas ..................................................... 120

4.18 Publicación y consulta de los resultados del comité ....................................................... 122

4.19 Legalizar créditos aprobados.......................................................................................... 124

4.20 Revisar la garantía del crédito: carta y pagare y confirmación de valores: ..................... 128

4.21 Hacer visado del crédito por parte del ICETEX .............................................................. 131

5. RENOVACIÓN DEL CRÉDITO ............................................................................................... 133

5.1 Realizar la actualización de datos e impresión del soporte de la renovación ................. 133

5.2 Realizar la renovación en las IES o Fondos ................................................................... 137

6. GIROS..................................................................................................................................... 140

6.1 Pago a proveedores cargados a gastos al fondo ........................................................... 140

6.2 Generar resoluciones de giro ......................................................................................... 143

6.3 Aprobar resolución relación de giro ................................................................................ 148

6.4 Generar Resoluciones de Giro Complementario ............................................................ 151

6.5 Confirmar giros exitosos ................................................................................................. 155

6.6 Visar tarjeta ................................................................................................................... 158

6.7 Aplicar Gastos al Fondo ................................................................................................. 161

7. NOVEDADES DEL CRÉDITO ................................................................................................. 163

7.1 Modificar los datos de ubicación del beneficiario y/o del deudor de una solicitud aprobada que no ha sido legalizada ............................................................................................................ 163

7.2 Modificar los datos de ubicación del beneficiario de un crédito después de la legalización 166

7.3 Actualizar datos de los gestores ..................................................................................... 169

7.4 Cambio de Deudor Solidario .......................................................................................... 171

7.5 Anular créditos aprobados que no fueron legalizados .................................................... 174

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

5

7.6 Anular créditos cuando el beneficiario desiste en la confirmación de datos ................... 176

7.7 Aplazar la legalización del crédito .................................................................................. 179

7.8 Realizar legalización del crédito fuera de los tiempos estipulados por el ICETEX ......... 181

7.9 Reversar la legalización ................................................................................................. 184

7.10 Cambio de IES y/o programa académico solicitado por el estudiante ............................ 186

7.11 Bloquear créditos ............................................................................................................ 189

7.12 Terminación del crédito .................................................................................................. 193

8. CARTERA EN EPOCA DE ESTUDIO ..................................................................................... 195

8.1 Aplicar Giros de Adjudicación y Renovación .................................................................. 195

8.2 Constituir Cartera ........................................................................................................... 198

8.3 Generar Plan de cuotas durante la época de estudios ................................................... 200

8.4 Aplicar Recaudos Época de Estudio. ............................................................................. 203

8.5 Registrar información de la transacción realizada .......................................................... 206

8.6 Consultar Crédito ............................................................................................................ 208

9. CARTERA EN ETAPA FINAL DE AMORTIZACIÓN ............................................................... 211

9.1 Pasar crédito a etapa final de amortización. ................................................................... 211

9.2 Generar Plan de cuotas para etapa de final de amortización. ...................................... 214

9.3 Liquidar crédito en etapa final de amortización .............................................................. 217

9.4 Aplicar Recaudos etapa final de amortización. ............................................................... 219

9.5 Registrar distribución de capital e Interés que conforma el capital inicial por fuente de Financiación en etapa final de amortización para el control de la contabilización del interés diferido ....................................................................................................................................... 221

9.6 Afectar interés diferido que conformó el capital inicial por fuente de Financiación en etapa final de Amortización por recaudo. .............................................................................................. 223

9.7 Aplicar calificación Manual ............................................................................................. 225

10. CARTERA EN ETAPA DE ESTUDIO Y AMORTIZACIÓN ................................................. 227

10.1 Generar información para extractos y recibos de pago. ................................................. 227

10.2 Generar Extractos y Recibos de Pago. ......................................................................... 230

11. CIERRE DIARIO ................................................................................................................. 232

11.1 Ejecutar Cierre Diario ..................................................................................................... 232

11.2 Actualizar estado de los créditos .................................................................................... 235

11.3 Causación Diaria ............................................................................................................ 239

11.4 Generar Interfaz Contable en el aplicativo de Cartera ................................................... 242

11.5 Enviar Interfaz Contable Consolidada a Contabilidad .................................................. 245

11.6 Realizar el registro de transacciones de causación de interés teniendo en cuenta la conformación del capital inicial de la obligación en la etapa final de amortización. .................... 248

12. CIERRE MENSUAL ............................................................................................................ 250

12.1 Ejecutar Cierre Mensual ................................................................................................. 250

12.2 Calificar Cartera .............................................................................................................. 253

12.3 Alinear Calificaciones ................................................................................................... 255

12.4 Actualizar provisiones ..................................................................................................... 257

12.5 Generar Provisión General de Cartera ........................................................................... 260

12.6 Ejecutar Reclasificación Contable .................................................................................. 262

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

6

13. CIERRE PERIODO ACADÉMICO ...................................................................................... 265

13.1 Ejecutar cierre periodo académico ................................................................................. 265

14. NOVEDADES DE CARTERA ............................................................................................. 271

14.1 Pasar crédito a etapa final de amortización. ................................................................... 271

14.2 Pasar crédito a época de estudio. .................................................................................. 276

14.3 Reversar Pago................................................................................................................ 279

14.4 Aplicar Pago ................................................................................................................... 282

14.5 Aplicar Condonación Total ............................................................................................. 284

14.6 Aplicar condonación parcial ............................................................................................ 287

14.7 Reversar Giro ................................................................................................................. 290

14.8 Aplicar Giro ..................................................................................................................... 293

14.9 Ampliar Número de Cuotas ............................................................................................ 295

14.10 Refinanciar Crédito .................................................................................................... 297

14.11 Modificar valor de cuota ............................................................................................. 299

14.12 Prorrogar Crédito ....................................................................................................... 302

14.13 Eliminar saldos mayores a favor del Beneficiario ....................................................... 305

14.14 Eliminar saldos menores ............................................................................................ 307

14.15 Registrar Retención Salarial ....................................................................................... 309

14.16 Modificar Tasa de Interés ........................................................................................... 311

14.17 Recalcular saldos de la operación desde la fecha de la novedad .............................. 313

14.18 Buscar Operación para aplicar novedades. ............................................................... 316

14.19 Registrar datos de la novedad ................................................................................... 318

14.20 Anular Novedad ......................................................................................................... 320

14.21 Consultar Novedad .................................................................................................... 322

14.22 Autorizar Ejecución de la novedad ............................................................................. 324

15. INTERFACES ..................................................................................................................... 326

15.1 Reporte a Centrales de Riesgo ...................................................................................... 327

15.2 Consulta a Centrales de Riesgo ..................................................................................... 328

15.3 Consulta con el DNP ...................................................................................................... 329

15.4 Consulta con el SNIES ................................................................................................... 329

15.5 Consulta con el ICFES ................................................................................................... 330

15.6 Reporte a UIAF(Unidad Administrativa Especial de Información y Análisis Financiero) . 331

15.7 ACH ................................................................................................................................ 332

15.8 Superintendencia financiera ........................................................................................... 332

15.9 Superintendencia financiera: .......................................................................................... 333

15.10 DANE ......................................................................................................................... 334

15.11 Registraduría Nacional de Estado Civil. ..................................................................... 334

15.12 Sistema Financiero - Presupuesto ............................................................................. 335

15.13 Sistema Financiero – Actualización Presupuestal ..................................................... 335

15.14 Sistema Financiero – Tesorería ................................................................................ 336

15.15 Sistema Financiero – Contabilidad ............................................................................ 336

15.16 Sistema Financiero – Contabilidad ............................................................................ 337

15.17 Oficina de Riesgo - Actualización del modelo de Riesgo ........................................... 337

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

7

15.18 Operaciones y Tecnología - Seguimiento al crédito – Extractos ................................ 338

15.19 Operaciones y Tecnología - Seguimiento al crédito – Créditos a Verificar ................. 338

15.20 Operaciones y Tecnología - Gestión Documental - Envío de datos de la custodia .... 339

15.21 Operaciones y Tecnología - Gestión Documental - Consulta de datos de la custodia 339

15.22 Operaciones y Tecnología - Gestión de la Cobranza - Envío de Información ............ 340

15.23 Operaciones y Tecnología - Gestión de la Cobranza – Actualización de los estados de crédito. 340

16. Gestión de consultas y Reportes ........................................................................................ 342

16.1 Introducción .................................................................................................................... 342

16.2 Generador de reportes ................................................................................................... 342

16.2.1 Características Generales ..................................................................................... 342

16.2.2 Características Específicas reportes gerenciales .................................................. 343

16.3 Listado de consultas y reportes ...................................................................................... 344

16.4 Características de las Consultas por Internet ................................................................. 358

17. ANEXOS ............................................................................................................................. 359

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

8

INTRODUCCIÓN

En el marco de desarrollo del contrato establecido entre el ICETEX y Softmanagement S.A. cuyo objeto es “realizar el levantamiento de los requerimientos y especificaciones funcionales y técnicas para contratar el Sistema de Información para la Gestión del Crédito, Cartera y Fondos en administración del ICETEX” se ha definido el proyecto entres fases: La fase de inicio, la fase intermedia y la fase de contratación. En la primera fase se desarrollo un modelo preliminar del negocio. La fase de elaboración se divide en tres iteraciones. Hasta este momento se ha realizado la iteración inicial donde se presento el documento de casos de uso de negocios en el que se muestran los siguientes macroprocesos:

Administración de parámetros: Corresponde al conjunto de casos de uso que hacen posible la flexibilización del Sistema de Información a través de los parámetros. Los casos de uso de parametrización permiten que el aplicativo cuente con las condiciones de flexibilidad requeridas durante la adjudicación, renovación y ejecución de los créditos.

Los grandes elementos que hacen parte la parametrización se relacionan a continuación:

o Tablas básicas. Establecen los datos que harán parte de las diferentes listas de valores que harán parte del aplicativo. Ejemplos de tablas básicas son: Lista de Departamentos, ciudades y municipios, tipos de identificación, Líneas de crédito y tipos de sistemas de amortización:

o Condiciones del crédito. Constituyen los parámetros que afectan los procesos de otorgamiento, renovación, legalización y desembolso del crédito. Las condiciones son propias para cada modalidad del crédito. Ejemplos de la condiciones son; Modelo de puntaje social para la evaluación del crédito, campos que contiene el formulario, condiciones de aprobación y ranking, condiciones de legalización en la IES y los datos por verificar en los procesos de seguimiento y adjudicación del crédito

o Condiciones de la cartera. Incluye los diferentes algoritmos de cálculo para las liquidaciones del crédito de acuerdo a la modalidad de otorgamiento o reestructuración y a los sistemas de amortización vigentes; además permite la parametrización de los modelos de calificación y de provisiones de la cartera.

o Integración con otros aplicativos. Permite la parametrización de los elementos de ejecución de las interfases. Ejemplos de dicha tipificación son: Definición de la dinámica de cuentas para las interfaces con el sistema de gestión financiera, parametrización de la forma en que se deben hacer los reportes de centrales de información y el establecimiento de los reportes a la superintendencia financiera

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

9

Gestión del crédito: Incluye las etapas de otorgamiento y desembolso (Giros) del crédito antes de la constitución de la cartera y la actualización de los gastos a los fondos. Adicionalmente integra la cartera en periodo de época de estudios de los créditos a través del proceso de renovaciones. En este proceso se desarrollaron los siguientes casos de uso:

o Otorgamiento del crédito, donde se realiza el proceso de selección y evaluación de

solicitudes de créditos y subsidios que cumplen con los requisitos de la modalidad y/o fondo respectivo con el fin de conceder créditos para realizar estudios de educación Básica y Media, Formación para el trabajo y la desarrollo humano y Educación Superior (técnica, tecnológica, universitaria, postgrado y postdoctorado).

o Renovación del crédito: Sirve para realizar la actualización de datos y visado por parte de los

terceros (Instituciones de Educación Superior –IES y fondos) y del ICETEX para la generación de la resolución.

o Novedades del crédito: Presenta el listado de las posibles novedades del crédito que se

pueden presentar durante el otorgamiento y renovación del crédito.

o Giros, que presenta las acciones realizadas para el proceso de desembolso en época de estudio para créditos condonables, reembolsables, subsidiables y mixtos.

Gestión de la cartera: Establece la especificación funcional de los diferentes estados de la cartera, sus condiciones de liquidación, las transiciones entre los estados y las excepciones que se pueden presentar. En este macroproceso se encuentran los siguientes casos de uso de negocio: o Cartera en época de estudio, donde se describen los procesos de cartera que se generan

cuando el crédito está en época de estudio. o Cartera en época de amortización: Presenta los procesos de cartera que se realizan en los

créditos cuando están en época de amortización.

o Novedades de cartera: Presenta el listado de las posibles novedades del crédito que se pueden presentar durante la gestión de la cartera.

o Cierres, donde se realiza la consolidación de información de cada crédito. Aquí se hace

referencia a los cierres diarios, los mensuales y por periodo académico.

Los cierres diarios hacen la actualización de saldos de cada crédito discriminado por los giros y recaudos con sus respectivas variables (capital, intereses y primas de seguros). Los cierres mensuales realizan la calificación de la cartera de acuerdo a su comportamiento. Adicionalmente se debe realizar las provisiones y reportes de control solicitados por los

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

10

usuarios y entidades externas. Por último se encuentran los cierres por periodo académico donde se definen los estados del crédito una vez evaluado el comportamiento del crédito durante el periodo académico. Los posibles estados que se pueden presentar son: Renovación, Aplazamiento, Bloqueos (por: Cambio de número de identificación, no actualización de datos, inconsistencia de datos), crédito en época de gracia y crédito en época de amortización (Paso al cobro).

Interfases

Describe las interfaces que rigen el intercambio de información entre el Sistema de Crédito y cartera y los Sistemas de Información de las entidades externas e internas el ICETEX. En este documento se incluyen las diferentes especificaciones necesarias para construir los componentes necesarios para consultar y enviar información a las entidades externas e internas. Por tanto, este documento concreta y unifica los siguientes aspectos relacionados con las interfaces:

Tipo: o Entrada : se obtiene información de la entidad o Sálida: se genera información para la entidad

Forma Envío/Recepción : o Archivo con transmisión electrónica o Archivo entrega física(Cd,Dvd) o Servicio Web

Frecuencia Envío /Recepción: o Diario o Mensual o Por demanda : Cada vez que se necesite la información

Procesos que afecta

Seguridad: o Certificados Digitales o Autenticación

Reportes En este documento se desarrolla la fase intermedia donde se presentan los casos de uso de sistemas que hacen referencia a la especificación detallada de las actividades funcionales de los casos de uso de negocio procesos de crédito y cartera del ICETEX.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

11

MARCO TEÓRICO

A continuación se presenta el formato utilizado para el desarrollo de los casos de uso de es5te documento y la explicación de cada una de las variables que lo compone:

Código*:

Nombre (del caso de uso):

Elaborado por: Aprobado por:

Fecha de elaboración:

Fecha de aprobación:

Objetivo

Es la finalidad que debe cumplir el sistema frente al caso de uso

Descripción

Presenta una definición más detallada del objetivo. La definición de los actores de los casos de uso está sujeto a cambios en las políticas del ICETEX.

Actores Principales

Son aquellos que ejecutan y modifican el caso de uso. Los actores definidos en estas variables en el futuro pueden cambiar. La definición de los actores de los casos de uso está sujeto a cambios en las políticas del ICETEX.

Actores secundarios

Son los que aportan información para desarrollar el caso de uso y los que utilizan las posibles salidas de información. Los actores definidos en estas variables en el futuro pueden cambiar.

Precondiciones:

Son los requerimientos previos al caso de uso que se necesitan para desarrollar el objetivo de este.

Poscondiciones

Presenta los estados en los que debe quedar el sistema después de la ejecución de cada uno de los casos de Uso

Secuencia normal de acciones:

En este punto se presenta el flujo básico que se desarrolla al interior del caso de uso sin que se presente alguna falla o no se cumpla con

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

12

alguna regla determinada en el sistema.

Secuencias alternas

1. Previniendo que el sistema pueda fallar ó que en algún momento

los registros que se introducen en el sistema no cumplen con alguna regla de negocio preestablecida dentro del mismo, se presenta un flujo alternativo que deberá realizar el sistema con el fin de superar las fallas presentadas dentro del flujo básico del caso de uso. Estas secuencias alternativas indican el punto del flujo básico en donde se genero el problema y van acompañadas por una letra (a, b, c) que representa los pasos alternativos que debe seguir el sistema. Esta letra acompañara cada uno de los procesos que necesiten ser modificados con el fin de suplir la falla del sistema o la inconsistencia de información registrada por los usuarios del mismo

Requerimientos no funcionales:

Son aquellos que describen los servicios o funciones que satisfacen los objetivos de los usuarios. Se entiende por Requerimientos No Funcionales las propiedades técnicas o restricciones que debe satisfacer el sistema. Los requerimientos no funcionales que se van a aplicar en este proyecto son:

Desempeño ( Rendimiento) Hace referencia a los tiempos de respuesta del sistema, a la frecuencia de ocurrencia y a aquellas actividades que debe controlar el sistema.

Disponibilidad Representa la ubicación y las personas que deben tener acceso a la información generada en los casos de uso de sistemas.

Seguridad Representa el nivel de autenticación de los usuarios que intervienen en el desarrollo de las actividades

Gestionabilidad - Control de procesos Hace referencia a los cambios de estado del proceso. En este se debe referenciar el estado inicial y el estado final. Sin embargo hay

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

13

casos de uso en que no se afecta el estado del proceso.

Auditoria Representa el nivel de control y seguimiento de las operaciones realizadas, lo cual se ve reflejado en el historial de los procesos (actividades realizadas, fecha en que se realizo, actor que realizo la actividad).

Notas y comentarios

Tiene la función de aclarar el significado de algunas operaciones del caso de uso.

*Los casos de uso de tienen la siguiente denominación:

Parametrización de las tablas básicas. PTB

Parametrización de las condiciones del crédito. PCR

Parametrización de la liquidación de cartera. PCA

Otorgamiento de Crédito: OTO

Renovación de Crédito: REN

Novedades de crédito: NCR

Giros GIR

Cartera en época de estudio: CEE

Cartera en época de amortización: CEA

Cierre Diario CDI

Cierre mensual CME

Cerre Por Periodo Académico CPA

Novedades de cartera: NCA

Interfaces INT

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

14

1. PARAMETRIZACIÓN DE LAS TABLAS BÁSICAS

1.1 Parametrizar Tipo de Crédito definido por la Superintendencia Financiera

Código: PTB-SIS-001

Nombre: Parametrizar Tipo de Crédito definido por la Superintendencia Financiera

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Dejar a disposición de los casos de uso de parametrización la clasificación del crédito

Descripción Permitir a través de este campo reportar de forma adecuada la información a la superintendencia financiera. Además determina cual debe ser el modelo de referencia para la calificación de cartera y las provisiones

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Se crea el parámetro de tipo de crédito definido para la superintendencia financiera.

Secuencia normal de acciones:

1. El usuario selecciona el la opción de clasificación del crédito para la Superintendencia Financiera

2. El sistema de solicita los siguientes datos: 2.1 Código 2.2 Descripción

3. El usuario registra la información y la guarda 4. El sistema le presenta la confirmación del almacenamiento.

Secuencias alternas 4.1 El sistema muestra el mensaje: Código de la clasificación del crédito ya existe.

4.2 Ir al paso 4 nuevamente

Notas y comentarios Los tipos de crédito que maneja el ICETEX, corresponden a Créditos de consumo y comerciales únicamente; el crédito educativo se ubica en este momento como crédito de consumo, adicionalmente las estrategias de mercadeo encaminadas a las Instituciones de Educación Superior se considerarían créditos comerciales.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

15

1.2 Parametrizar Tipo de Recurso

Código: PTB-SIS-002

Nombre: Parametrizar Tipo de Recurso

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Dejar a disposición de los casos de uso de parametrización los tipos de recursos con los que cuenta el ICETEX para el otorgamiento del préstamo

Descripción Permitir el registro de los tipos de recursos de financiación que harán parte de la configuración de la modalidad.

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Se crea el parámetro de tipo de recurso.

Secuencia normal de acciones:

1. El usuario selecciona el la opción de adicionar un nuevo recurso de financiación

2. El sistema de solicita los siguientes datos: 2.1 Código 2.2 Descripción

3. El usuario registra la información y la guarda 4. El sistema le presenta la confirmación del almacenamiento .

Secuencias alternas 4.1 El sistema muestra el mensaje: Código del recurso de financiación ya existe.

4.2 Ir al paso 4 nuevamente

Notas y comentarios Los tipos recursos con los que cuenta el ICETEX actualmente son: Recursos Propios, Recursos Privados, Recursos Mixtos o de Alianza Estratégica.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

16

1.3 Parametrizar Tipo de Cobertura

Código: PTB-SIS-003

Nombre: Parametrizar Tipo de Cobertura

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Dejar a disposición de los casos de uso de parametrización los tipos cobertura o convocatoria con los que cuenta el ICETEX

Descripción Permitir el registro de los tipos de cobertura que harán parte de la configuración de la modalidad y que modifican los calendarios y la operación de adjudicación de los créditos.

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Se crea el parámetro de tipo de Cobertura

Secuencia normal de acciones:

1. El usuario selecciona el la opción de adicionar un nuevo tipo de cobertura

2. El sistema de solicita los siguientes datos: 2.1 Código 2.2 Descripción

3. El usuario registra la información y la guarda 4. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas 4.1 El sistema muestra el mensaje: Código del tipo de cobertura ya existe.

4.2 Ir al paso 4 nuevamente

Notas y comentarios Los tipos de cobertura establecidos en el ICETEX corresponden a: Convocatoria abierta y Convocatoria Cerrada.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

17

1.4 Parametrizar Tipo de Estudio a Financiar

Código: PTB-SIS-004

Nombre: Parametrizar Tipo de Estudio a Financiar

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Dejar a disposición de los casos de uso de parametrización los tipos de estudio a financiar por parte de ICETEX

Descripción Permitir el registro de los tipos de estudio que harán parte de la configuración de la modalidad y condicionan su denominación.

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Se crea el parámetro de tipo de estudio a financiar

Secuencia normal de acciones:

1. El usuario selecciona el la opción de adicionar un nuevo tipo de estudio a financiar

2. El sistema de solicita los siguientes datos: 2.1 Código 2.2 Descripción

3. El usuario registra la información y la guarda 4. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas 4.1 El sistema muestra el mensaje: Código del tipo de estudio a financiar ya existe.

4.2 Ir al paso 4 nuevamente

Notas y comentarios Los tipos de estudio a financiar establecidos en el ICETEX corresponden a: Pregrado país, Postgrado país, Estudios en el exterior y Subsidios para bachillerato (Para algunos de los fondos de convocatoria cerrada)

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

18

1.5 Parametrizar el Tipo de Rubro a Financiar

Código: PTB-SIS-005

Nombre: Parametrizar el Tipo de Rubro a Financiar

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Dejar a disposición de los casos de uso de parametrización los tipos de rubro a financiar por parte de ICETEX

Descripción Permitir el registro de los tipos de rubro que harán parte de la configuración de la modalidad y la tipifican

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Se crea el parámetro de tipo de rubro a financiar

Secuencia normal de acciones:

1. El usuario selecciona el la opción de adicionar un nuevo rubro a financiar

2. El sistema de solicita los siguientes datos: 2.1 Código 2.2 Descripción

3. El usuario registra la información y la guarda 4. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas 4.1 El sistema muestra el mensaje: Código del rubro a financiar ya existe.

4.2 Ir al paso 4 nuevamente

Notas y comentarios Los rubros a financiar establecidos en el ICETEX corresponden a: Matricula, Sostenimiento, computadores, textos y pasajes

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

19

1.6 Parametrizar los tipos de condición del crédito para constituir cartera

Código: PTB-SIS-006

Nombre: Parametrizar los tipos de condición del crédito para constituir cartera

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Dejar a disposición de los casos de uso de parametrización los tipos de condición que permiten la constitución de la cartera

Descripción El parámetro establece si una modalidad del crédito constituye o no cartera, de acuerdo a la parametrización de las etapas de la solicitud

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Se crea el parámetro del tipo de condición para la constitución de la cartera

Secuencia normal de acciones:

1. El usuario selecciona la opción de adicionar un nuevo tipo de condición para la constitución de la cartera

2. El sistema de solicita los siguientes datos: 2.1 Código 2.2 Descripción

3. El usuario registra la información y la guarda 4. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas 4.1 El sistema muestra el mensaje: El Código ya existe. 4.2 Ir al paso 4 nuevamente

Notas y comentarios Los rubros a financiar establecidos en el ICETEX corresponden a: Condonable, mixto, reembolsable y Subsidiado

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

20

1.7 Parametrizar el Listado de Países

Código: PTB-SIS-007

Nombre: Parametrizar el Listado de Países

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Dejar a disposición de los casos de uso de parametrización el listado de países.

Descripción El parámetro es utilizado para el establecer el tipo de moneda y la ubicación de la ciudad del programa académico

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Lista de países creado

Secuencia normal de acciones:

1. El usuario selecciona la opción de adicionar un nuevo país 2. El sistema de solicita los siguientes datos:

2.1 Código 2.2 Nombre del País

3. El usuario registra la información y la guarda 4. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas 4.1 El sistema muestra el mensaje: El Código ya existe. 4.2 Ir al paso cuatro (4) nuevamente

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

21

1.8 Parametrizar el Tipo de Moneda

Código: PTB-SIS-008

Nombre: Parametrizar el Tipo de Moneda

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Dejar a disposición de los casos de uso de parametrización el listado monedas en las cuales se puede realizar el giro.

Descripción El parámetro es utilizado para el establecer el tipo de moneda en la que se harán los giros

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Tipo de Moneda Creado.

Secuencia normal de acciones:

1. El usuario selecciona la opción de adicionar un nuevo tipo de moneda

2. El sistema de solicita los siguientes datos: 2.1 Código 2.2 Moneda 2.3 País Origen de la Moneda

3. El usuario registra la información y la guarda 4. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas 4.1 El sistema muestra el mensaje: El Código ya existe. 4.2 Ir al paso 4 nuevamente

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

22

1.9 Parametrizar el sistema de Amortización

Código: PTB-SIS-009

Nombre: Parametrizar el sistema de Amortización

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Dejar a disposición de los casos de uso de parametrización de la liquidación de los créditos los tipos de sistemas de amortización establecidos por la Superintendencia Financiera y adoptados por el ICETEX.

Descripción El parámetro es utilizado para el establecer el sistema de amortización en la que se harán los giros

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Sistema de amortización creado

Secuencia normal de acciones:

1. El usuario selecciona la opción de adicionar un nuevo sistema de amortización

2. El sistema de solicita los siguientes datos: 2.1 Código 2.2 Nombre del Sistema de Amortización 2.3 Tipo de Crédito (Consumo o Comercial)

3. El usuario registra la información y la guarda 4. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas 4.1 El sistema muestra el mensaje: El Código ya existe. 4.2 Ir al paso 4 nuevamente

Notas y comentarios Los sistemas de amortización se encuentran ligados al tipo de crédito y establecen la forma en que se deben liquidar dichos créditos previo a la generación de los recibos de pago; los sistemas de amortización que se tienen actualmente son: Amortización Fija, Cuota Fija y Cuota Variable.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

23

1.10 Parametrizar el Tipo de Deudor

Código: PTB-SIS-010

Nombre: Parametrizar el Tipo de Deudor

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Dejar a disposición del registro del formulario de solicitud el role del deudor en la solicitud de crédito.

Descripción El parámetro es utilizado en los casos de uso del registro de clientes en la solicitud de crédito

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Tipo de Deudor Creado

Secuencia normal de acciones:

1. El usuario selecciona la opción de adicionar un nuevo tipo de Deudor

2. El sistema de solicita los siguientes datos: 2.1 Código 2.2 Tipo de Deudor

3. El usuario registra la información y la guarda 4. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas 4.1 El sistema muestra el mensaje: El Código ya existe. 4.2 Ir al paso 4 nuevamente

Notas y comentarios Existen dos tipos de deudor: El principal o beneficiario del crédito y el deudor solidario como garantía del crédito para algunas modalidades del crédito el beneficiario del crédito es también el deudor solidario.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

24

1.11 Parametrizar el tipo de Personería

Código: PTB-SIS-011

Nombre: Parametrizar el Tipo de Personería

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Dejar a disposición del registro del formulario de solicitud el tipo de personería que tiene el deudor del crédito.

Descripción El parámetro es utilizado en los casos de uso del registro de clientes en la solicitud de crédito

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Tipo de Deudor Creado

Secuencia normal de acciones:

1. El usuario selecciona la opción de adicionar un nuevo tipo de personería

2. El sistema de solicita los siguientes datos: 2.1 Código 2.2 Tipo de Personería

3. El usuario registra la información y la guarda 4. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas 4.1 El sistema muestra el mensaje: El Código ya existe. 4.2 Ir al paso 4 nuevamente

Notas y comentarios Existe dos tipos de personería: Natural o Jurídica.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

25

1.12 Parametrizar Lista de Departamentos

Código: PTB-SIS-012

Nombre: Parametrizar Lista de Departamentos

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Dejar a disposición del caso de uso de parametrización de las ciudades.

Descripción El parámetro es utilizado en los casos de uso del registro de nuevas ciudades o en la actualización de las mismas

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Departamento Creado

Secuencia normal de acciones:

1. El usuario selecciona la opción de adicionar un nuevo departamento

2. El sistema de solicita los siguientes datos: 2.1 Código 2.2 Departamento 2.3 País

3. El usuario registra la información y la guarda 4. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas 4.1 El sistema muestra el mensaje: El Código ya existe. 4.2 Ir al paso 4 nuevamente

Notas y comentarios Este caso de uso aplica para los departamentos o provincias que se encuentren referenciadas en el extranjero. La codificación para el país proviene de un archivo que suministra el DANE (Departamento Nacional de Estadística).

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

26

1.13 Parametrizar Lista de Ciudades y/o Municipios

Código: PTB-SIS-013

Nombre: Parametrizar Lista de Ciudades y/o Municipios

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Dejar a disposición del caso de uso la parametrización de las ubicaciones de las instituciones, lugares de nacimiento y residencia.

Descripción El parámetro es utilizado en los casos de uso del registro de nuevas ciudades o en la actualización de las mismas

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Ciudad o Municipio Creado

Secuencia normal de acciones:

1. El usuario selecciona la opción de adicionar nueva ciudad o Municipio

2. El sistema de solicita los siguientes datos: 2.1 Código 2.2 Nombre Ciudad / Municipio 2.3 Departamento

3. El usuario registra la información y la guarda 4. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas 4.1 El sistema muestra el mensaje: El Código ya existe. 4.2 Ir al paso 4 nuevamente

Notas y comentarios Este caso de uso aplica para las ciudades que se encuentren referenciadas en el extranjero. La codificación para el país proviene de un archivo que suministra el DANE (Departamento Nacional de Estadística).

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

27

1.14 Parametrizar de Direcciones Territoriales del ICETEX

Código: PTB-SIS-014

Nombre: Parametrizar de Direcciones Territoriales del ICETEX

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Permitir el registro de las regionales con las que cuenta el ICETEX.

Descripción

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Dirección Territorial Creada

Secuencia normal de acciones:

1. El usuario selecciona la opción de adicionar nueva Dirección Territorial

2. El sistema de solicita los siguientes datos: 2.1 Código 2.2 Nombre Regional 2.3 Lugar de Ubicación (Departamento / Municipio) 2.4 Dirección 2.5 Teléfono 2.6 Director

3. El usuario registra la información y la guarda 4. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas 4.1 El sistema muestra el mensaje: El Código ya existe. 4.2 Ir al paso 4 nuevamente

Notas y comentarios Determina el origen del crédito a partir de la ciudad a la que se presenten los documentos de soporte.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

28

1.15 Crear Instituciones de Educación Superior

Código: PTB-SIS-015

Nombre: Mantener Registro de IES

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Permitir el registro de la Instituciones de Educación Superior (IES)

Descripción Las IES se encargan del proceso de legalización de los crédito en la adjudicación y en la renovación.

Actores Principales Caso uso de sistemas de la interfase con SNIES

Actores secundarios No existe actor secundario

Precondiciones: Se encuentra definida y disponible la interfase con el SNIES.

Poscondiciones IES creadas o modificadas

Programas académicos actualizados

Secuencia normal de acciones:

En el momento de la ejecución de la interfase se desarrollan las siguientes operaciones para cada IES. 1. El sistema verifica la no existencia de la IES a partir del

código SNIES para la IES. 2. El sistema registra la siguiente información:

2.1 Código SNIES 2.2 Nit 2.3 Nombre 2.4 Lugar de Ubicación (Departamento / Municipio) 2.5 Dirección 2.6 Teléfono 2.7 Página Web 2.8 Correo Electrónico 2.9 Contacto 2.10 Teléfono Contacto 2.11 Correo Electrónico Contacto 2.12 Estado de la actividad de la IES (Autorizada)

3. El sistema registra la información de los programas académicos autorizados para la IES, la información registrada es la siguiente:

Código SNIES del programa académico

Descripción del programa académico

Número de periodos académicos

Número de créditos académicos

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

29

Rango de fecha de vigencia para el programa académico 4. El sistema actualiza los reportes de auditoria para la

interfase SNIES 5. Fin del proceso.

Secuencias alternas Actualización de Datos de la IES

Notas y comentarios Datos adicionales a la IES que se asocian después de su creación son:

1. Datos del convenio 2. Calendario académico 3. Convenio con el CERES 4. Programas en Alianza Estratégica 5. Usuarios de la Legalización y Consulta

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

30

1.16 Crear Entidades contratistas del ICETEX

Código: PTB-SIS-016

Nombre: Crear Entidades contratistas del ICETEX

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Permitir el registro de los terceros o contratistas del ICETEX

Descripción Las entidades que hacen parte del aplicativo de crédito y cartera son:

1. Entidades de Cobranza 2. Entidades de Seguimiento al Crédito 3. Entidades de Gestión Documental 4. Entidades de Atención al Usuario

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Entidad de Cobranza Creado

Secuencia normal de acciones:

1. El usuario selecciona la opción de adicionar nueva Entidad o Contratista

2. El sistema de solicita los siguientes datos: 2.1 NIT Entidad 2.2 Nombre o Razón Social 2.3 Lugar de Ubicación (Departamento / Municipio) 2.4 Dirección 2.5 Teléfono 2.6 Página Web 2.7 Correo Electrónico 2.8 Contacto 2.9 Teléfono Contacto 2.10 Correo Electrónico Contacto

3. El usuario registra la información y la guarda 4. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas 4.1 El sistema muestra el mensaje: El Código ya existe. 4.2 Ir al paso 4 nuevamente

Notas y comentarios Datos adicionales a la creación de la Entidad que se asocian después de su creación son:

Interfase de datos para el envío de la información

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

31

(Resultado de la Gestión)

Interfase de datos para la recepción de información (Envío de los créditos a Gestionar)

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

32

1.17 Crear Constituyente del Fondo

Código: PTB-SIS-017

Nombre: Crear Constituyente del Fondo

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Permitir el registro de los constituyentes del fondo

Descripción Registro de los datos básicos de las entidades que entregan fondos en administración al ICETEX, para prestamos y/o subsidios educativos

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Entidad constituyente del fondo Creada

Secuencia normal de acciones:

1. El usuario selecciona la opción de adicionar nueva Entidad con Fondos en Administración

2. El sistema de solicita los siguientes datos: 2.1 NIT Entidad 2.2 Nombre o Razón Social 2.3 Lugar de Ubicación (Departamento / Municipio) 2.4 Dirección 2.5 Teléfono 2.6 Página Web 2.7 Correo Electrónico 2.8 Contacto 2.9 Teléfono Contacto 2.10 Correo Electrónico Contacto

3. El usuario registra la información y la guarda 4. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas 4.1 El sistema muestra el mensaje: El Código ya existe. 4.2 Ir al paso 4 nuevamente

Notas y comentarios Datos adicionales en la constitución del fondo se relacionan a continuación:

Posibles destinos del crédito

Tipo de Crédito a Otorgar (Préstamo condonable, subsidio)

Datos del Contrato: o Porcentaje de Gastos de Administración

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

33

o Porcentaje de Intereses de Recuperación de Cartera

Tipo de Cobertura (Abierta o Cerrada)

Calendario Académico

Condiciones de Aprobación del Crédito

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

34

1.18 Crear Línea de Crédito

Código: PTB-SIS-018

Nombre: Crear Línea de Crédito

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Registrar la información en el sistema de la línea de crédito.

Descripción El sistema le permite al administrador registrar la información del código de la línea, Nombre de la línea y el tipo de crédito (consumo, financiero).

Actores Principales Administrador del sistema.

Actores secundarios

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Se crea una línea de crédito en el sistema.

Secuencia normal de acciones:

1. El usuario selecciona crear línea de crédito. 2. El sistema solicita información para la creación de la línea. 3. El usuario ingresa el código, nombre y tipo de crédito

(consumo, comercial) 4. El sistema retorna un mensaje de línea creada.

Secuencias alternas 4.1 El sistema muestra el mensaje: Código de línea de crédito ya existe.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

35

1.19 Definir modalidad de crédito y/o fondo.

Código: PTB-SIS-019

Nombre: Definir modalidad de crédito y/o fondo.

Elaborado por: Diego A. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Crear una modalidad de crédito

Descripción

Actores Principales Administrador del sistema.

Actores secundarios Funcionario de la Vicepresidencia de Crédito y Cobranza

Precondiciones: Existe la línea de crédito a la cual se va a asociar la modalidad de crédito.

El usuario es valido en el sistema y tiene los privilegios necesarios.

Poscondiciones Modalidad de crédito

Secuencia normal de acciones:

1. El usuario selecciona crear modalidad de crédito y/o fondo. 2. El sistema solicita información para la parametrización de la

modalidad 3. El usuario ingresa la línea a la que pertenecerá la modalidad

(Pregrado país, Postgrado país, IES, Estudios en el exterior, fondos) y las IES con las cuales tiene convenio.

4. El sistema asigna el código de identificación de la modalidad. 5. El usuario ingresa el tipo de recurso que manejara la

modalidad (público, privado, mixto) (única o múltiple) e ingresa el tipo de cobertura (Convocatoria) que se manejara (Convocatoria Abierta o Cerrada).

6. El usuario ingresa los niveles de estudios a financiar (pregrado, postgrado, educación básica media, maestrías, doctorados, Educación para el trabajo y desarrollo humano).

7. El usuario ingresa los rubros que se van a financiar (Matricula, Sostenimiento, computadores, textos, pasajes) se define número de salarios mínimos vigentes y máximo a cubrir por periodo, define el tipo de crédito que se va a manejar por cada fuente (condonable, mixto, reembolsable, Subsidiado), el destino del giro (IES, beneficiario, tercero) y la moneda en que se realizará el giro.

8. El usuario ingresa el porcentaje de la tasa de interés, la tasa de mora y el plazo máximo de reembolso del crédito.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

36

9. El usuario ingresa el porcentaje de la deuda a pagar en ejecución y amortización.

10. El usuario establece si el crédito es de giro es único o renovable

11. El usuario indica si la modalidad maneja periodo de gracia. 12. El usuario ingresa la duración en días del periodo de gracia. 13. El usuario asocia los sistemas de amortización disponibles

para la modalidad (Cuota fija, variable…). 14. El usuario ingresa los componentes de las cuotas en

estudio, gracia y amortización (Prima de seguro, interés, capital) y sus porcentajes.

15. El usuario ingresa el orden de los componentes de los recaudos en estudio, gracia y amortización (Prima de seguro, interés, capital) y sus porcentajes.

16. El usuario indica si la modalidad de crédito necesita deudor solidario

17. El usuario ingresa el tipo de deudor solidario (Natural y/o jurídico), define el número de deudores solidarios necesarios para el otorgamiento y el modelo de riesgo utilizado para la evaluación.

18. El usuario ingresa la lista de documentos requeridos y condiciones para la legalización.

19. El usuario ingresa el formato de la carta de instrucciones y pagare.

20. El usuario carga el archivo con la descripción de la modalidad.

21. El sistema de crédito visualiza la plantilla creada. 22. El usuario asigna el estado de la modalidad(Definitiva,

provisional) 23. El sistema graba la modalidad.

Secuencias alternas El usuario ingresa el porcentaje de comisión para el fondo 10.1 El usuario indica que no hay periodo de gracia y sigue al

paso 9. 14.1. El sistema controla que la suma de los porcentajes sea el

100% 141.1. El sistema solicita valores correctos y va al paso 14.

15.1. El usuario indica que no necesita deudor solidario y sigue al paso 17

Notas y comentarios Renovaciones del crédito.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

37

1.20 Definir Alianza Estratégica.

Código: PTB-SIS-020

Nombre: Definir Alianza Estratégica.

Elaborado por: Diego A. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Establecer los criterios o parámetros que hacen parte de la alianza estratégica

Descripción

Actores Principales Administrador del sistema.

Actores secundarios Funcionario de la Vicepresidencia de Crédito y Cobranza

Precondiciones: La modalidad de crédito sobre la cual actúa la alianza estratégica se encuentra configurada en el sistema (Ver caso de uso PTB-SIS-019)

Los gestores que hacen parte de la alianza se encuentran creados (Ver caso de uso PTB-SIS-017)

Poscondiciones Alianza estratégica creada y disponible para su uso en el otorgamiento de crédito.

Secuencia normal de acciones:

1. El usuario selecciona la modalidad de crédito sobre la cual se establece la alianza estratégica.

2. El sistema le presenta los datos de la modalidad junto con la opción de alianza estratégica

3. El usuario selecciona la opción de alianza estratégica. 4. El sistema le presenta un formulario con los siguientes

apartes: a. Constituyentes de la alianza estratégica (Ver

Nota 1). b. Condiciones en la evaluación del crédito (Ver

Nota 2) c. IES a las cuales pueden acceder los

beneficiarios y Programas académicos d. Condiciones del otorgamiento de subsidios

(Ver Nota 3) e. Condiciones para la condonación (Ver Nota

3). f. Condiciones de distribución de los recursos

en el momento del giro. (Ver Nota 4)

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

38

g. Condiciones de reembolso en el recaudo a cada una de la fuentes de aplicación (Ver Nota 5)

5. El usuario registra la información y la almacena 6. El sistema almacena la información y la deja disponible para

la autorización del funcionario de crédito y cobranza 7. El funcionario de crédito y cobranza selecciona de una lista

de tareas la función de autorización de alianza estratégica. 8. El funcionario revisa los datos de la alianza estratégica y la

deja disponible para su utilización 9. Fin del Proceso

Secuencias alternas La información disponible para la alianza estratégica no esta correcta: 8.a El funcionario de crédito y cobranza revisa los datos y encuentra inconsistencias. La tarea es devuelta al administrador de la aplicación y el flujo de actividades retorna al paso 5.

Notas y comentarios Nota 1. Constituyentes de la alianza estratégica Conjunto de gestores que pueden ser IES (Instituciones de Educación Superior), fondos privados, fondos mixtos o fondos públicos (Entidades del orden nacional, Departamentos o Municipios) que desean establecer condiciones específicas de cobertura de crédito para una población objetivo. Nota 2. Condiciones de Evaluación de crédito. Las condiciones de evaluación al crédito modifican algunos de los parámetros de evaluación de la modalidad con el objeto de darle mayor cobertura al población a la cual quiere favorecer la alianza estratégica. Entre las condiciones de evaluación se encuentran: o Lugar de nacimiento del Beneficiario del Crédito o Grupo étnico al que pertenece o Condiciones especiales de desplazamiento, desmovilización

entre otros. o Méritos académicos o Programas académicos o Estrato y/o niveles del SISBEN La lista que se presenta en esta nota es a manera de ejemplo por lo tanto puede cambiar de acuerdo a las condiciones expuestas por el constituyente y que se encuentren en el marco de la política del ICETEX. Nota 3. Condiciones para los subsidios y las condonaciones. En las alianzas que aplique se deben establecer las condiciones

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

39

de los subsidios y de las condonaciones de acuerdo a los siguientes parámetros posibles: o Cumplimiento del programa académico o Promedio de notas en el periodo académico o Promedio de notas en la carrera o Cumplimiento de condiciones especiales que pueden estar

asociadas con la movilidad del estudiante o presentación de servicios a la comunidad objeto.

Nota 4. Condiciones en el Giro Consiste en el establecimiento de los porcentajes de los aportes de cada una de las fuentes que hacen parte de la alianza estratégica en el momento del desembolso del crédito. Las condiciones del giro definen la dinámica de cuentas en el sistema financiero del ICETEX. Nota 5. Condiciones en el Recaudo. Personalización de la distribución de los recursos en el momento en que se haga el recaudo a cada una de las fuentes de financiación del crédito. A continuación se presentan las posibles configuraciones de reembolso de recursos: o Por porcentajes de aplicación. El caso mas común es aplicar

los mismos porcentajes de aplicación en el momento del desembolso.

o Prelación de recursos. Durante un periodo de tiempo rembolsar el dinero a uno de los fondos y posteriormente a los demás.

o Combinación de los anteriores

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

40

2. PARAMETRIZACIÓN DE LAS CONDICIONES DEL CRÉDITO

2.1 Crear campos del Formulario de la Solicitud

Código: PCR-SIS-001

Nombre: Crear campos del Formulario de la Solicitud

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Permite el registro de los campos que harán parte del formulario

Descripción Los campos que hacen parte del formulario pueden estar asociados a varios formularios.

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Campo de Formulario Creado

Secuencia normal de acciones:

1. El usuario selecciona la opción de adicionar nuevo Campo de Formulario

2. El sistema de solicita los siguientes datos: 2.1 Identificación del Campo 2.2 Nombre del Campo 2.3 Tipo de Campo (Básico, Enumerado, Lista y

Tabla) 2.4 Tipo de Dato (Carácter, Flotante, Entero,

Decimal, SI/NO) 3. El usuario registra la información y la guarda 4. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas 4.1 El sistema muestra el mensaje: El Código ya existe. 4.2 Ir al paso 4 nuevamente

Notas y comentarios El tipo de Campo establece el comportamiento del mismo como se detalla a continuación:

El tipo de campo básico solicita inmediatamente el Tipo de Dato.

El tipo de campo Enumerado pide la lista de valores.

El tipo de campo Lista pide además de la lista de valores los tipos de datos que contendrá la lista

El tipo de Dato Tabla solicita el código de la consulta de base de datos

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

41

2.2 Crear sección del Formulario

Código: PCR-SIS-002

Nombre: Crear sección del Formulario

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Permite la creación de las posibles secciones que puede llegar a tener el formulario

Descripción Las secciones del formulario en la mayor parte de los casos son iguales sin embargo este caso de uso permite que existan cambios de fondo para modalidades que no se encuentren definidas al momento del diseño del aplicativo

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Sección del Formulario Creada

Secuencia normal de acciones:

1. El usuario selecciona la opción de adicionar nueva sección del Formulario

2. El sistema de solicita los siguientes datos: 2.1 Identificación de la sección 2.2 Nombre de la sección

3. El usuario registra la información y la guarda 4. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas 4.1 El sistema muestra el mensaje: El Código ya existe. 4.2 Ir al paso 4 nuevamente

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

42

2.3 Asociar Secciones al Formulario

Código: PCR-SYS-003

Nombre: Asociar Secciones al Formulario

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Asociar las secciones al formulario y definir cuales son la que generan el número de solicitud

Descripción Las secciones del formulario en la mayor parte de los casos son iguales sin embargo este caso de uso permite que existan cambios de fondo para modalidades que no se encuentren definidas al momento del diseño del aplicativo

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Formulario con secciones asociadas

Secuencia normal de acciones:

1. El usuario selecciona la opción de asociar secciones al Formulario

2. El sistema de solicita lista la secciones disponibles 3. El usuario asocia la sección y la guarda el formulario 4. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas

Notas y comentarios Este caso de uso hace parte de las modificaciones al formulario

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

43

2.4 Crear Formulario de registro.

Código: PCR-SIS-004

Nombre: Crear Formulario de registro.

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Crear formulario de registro de la modalidad.

Descripción De un catalogo de datos selecciona la información que debe contener el formulario.

Actores Principales Administrador del sistema.

Actores secundarios

Precondiciones: El cliente es admitido y conocido para el sistema.

La modalidad no tiene parametrizado el formulario de registro

Debe existir un catalogo de datos (Ver Nota1)

Poscondiciones Se crea un formulario de registro asociado a la modalidad.

Secuencia normal de acciones:

1. El usuario selecciona definir formulario de registro. 2. El sistema muestra una lista de las modalidades. 3. El usuario selecciona una modalidad para la parametrización

del formulario y define el tiempo máximo de permanencia de las solicitudes diligenciadas parcialmente.

4. El sistema solicita información por sección (datos básicos, núcleo familiar, Información laboral del núcleo familiar, datos del crédito, referencias).

5. El usuario selecciona la sección que desea parametrizar. 6. El usuario muestra el catalogo disponible para la sección

seleccionada. 7. El usuario selecciona el campo del catalogo e indica si el

campo seleccionado es obligatorio. 8. El usuario indica que no desea agregar más campos y

selecciona guardar. 9. El sistema graba el formulario

Secuencias alternas 8.1. El usuario decide agregar más campos y repite la acción 5a. 8.2. El usuario define en que formato desea guardar la plantilla (Convocatoria Cerrada)

Notas y comentarios

1. Un catalogo de datos es un conjunto de datos ya

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

44

parametrizados que me permiten elegir que información debe contener el formulario.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

45

2.5 Establecer las etapas de la Solicitud del Crédito

Código: PCR-SIS-005

Nombre: Establecer las etapas de la Solicitud del Crédito

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Crear las etapas que debe seguir un crédito

Descripción Las etapas que se contemplan en el crédito son: a. Otorgamiento del Crédito b. Renovación del Crédito c. Legalización del Crédito d. Desembolso e. Época de estudios de la Cartera f. Época de Amortización de la Cartera

Actores Principales Administrador del sistema.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Poscondiciones Proceso de crédito Creado

Secuencia normal de acciones:

1. El usuario selecciona la modalidad para la creación de las etapas del proceso

2. El sistema le presenta las siguientes operaciones: 2.1 Etapas 2.2 Participantes en el proceso 2.3 Campos de Datos 2.4 Listado de Participantes

3. El usuario selecciona la opción de etapas 4. El sistema le solicita la siguiente información:

4.1 Código de la Etapa 4.2 Descripción de la etapa

5. El usuario almacena la información 6. El sistema le solicita la siguiente información al usuario:

6.1 Lista de actividades 6.2 Lista de transiciones 6.3 Lista de Condiciones para pasar de una actividad a otra

7. El usuario registra la información y la almacena 8. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas

Requisitos No Funcionales

Usabilidad: Se requiere que la creación de etapas del proceso sea gráfica y

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

46

que cuente con paletas de objetos que permitan arrastrar y crear las etapas, actividades, transiciones y condiciones del proceso.

Seguridad Se requiere que cada uno de las actividades tenga los siguientes roles:

Responsable o participante Supervisor del Proceso Administrador del Proceso.

Control del Proceso. Se requiere que la creación de procesos cumpla con el estándar internacional para la administración de procesos de negocio contemplado en el sitio Internet http://www.wfmc.org/

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

47

2.6 Definir Calendarios

Código: PCR-SIS-006

Nombre: Definir Calendarios

Elaborado por: Diego Arteaga. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Asignar calendarios de adjudicación y renovación.

Descripción El usuario selecciona la modalidad de crédito para asociarle unas fechas donde el estudiante puede solicitar renovaciones y adjudicaciones.

Actores Principales Administrador del sistema

Actores secundarios

Precondiciones: El cliente es valido y tiene los privilegios necesarios.

El sistema ya selecciona la modalidad de crédito a la cual se le va a asignar un calendario.

Las fechas de inicio y fin de un periodo de adjudicación ò renovación no pueden ser menor a la fecha actual.

Para una modalidad y un mismo tipo (Adjudicación y renovación) la fecha final de un calendario no puede ser mayor que la fecha inicial de otro calendario.

Poscondiciones Se asigna a la modalidad de crédito unas fechas para adjudicación y renovación.

Secuencia normal de acciones:

1. El usuario selecciona definir calendarios y el tipo (Adjudicación ò renovación).

2. El sistema muestra los calendarios definidos para la modalidad.

3. El usuario ingresa una fecha inicial y una fecha final y selecciona guardar.

4. El sistema informa al usuario que la información se guardo exitosamente.

5. El usuario indica que no desea agregar más calendarios. 6. El sistema finaliza.

Secuencias alternas 5.1 El usuario indica que desea agregar más calendario y vuele al paso 3.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

48

2.7 Parametrizar el modelo de evaluación de crédito

Código: PCR-SIS-007

Nombre: Parametrizar el modelo de evaluación de crédito

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Asociar un nuevo modelo de evaluación del crédito

Descripción Se debe permitir la captura o modificación de las variables que harán parte del modelo de puntaje en el otorgamiento del crédito para cada modalidad

Actores Principales Funcionario de la oficina de riesgo.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Existe una modalidad de crédito sobre la cual se hará la convocatoria

Se cuenta con el modelo definido por la oficina de riesgo del ICETEX

El usuario se encuentra ubicado en el registro de la modalidad

Poscondiciones Modelo de evaluación actualizado

Secuencia normal de acciones:

1. El usuario selecciona la opción de modelos. 2. El sistema le presenta dos opciones de creación o

actualización de los modelos:

Modelo de evaluación del crédito

Modelo de calificación de cartera y provisiones 3. El usuario selecciona la opción de evaluación del crédito 4. El sistema le presenta la lista de variables con los puntajes

con las siguientes opciones:

Modificar Variable

Adicionar Variable

Eliminar Variable 5. El usuario selecciona la variable para la modificación o

eliminación de la información 6. El sistema le presenta los datos de la variable:

Código de la variable

Descripción de la variable

Tipo de Variable (Básica, Lista, Rango)

Valor del puntaje 7. El usuario solamente puede modificar el valor del puntaje

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

49

8. El usuario almacena la información 9. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas Adicionar una nueva variable:

6.a El usuario selecciona la opción de adicionar una nueva variable

7.b. El sistema le solicita los siguientes datos:

Origen de la variable (Ver Nota 1)

Nombre de la variable

Valor del Puntaje

8.b. El usuario registra los datos solicitados 9. El usuario almacena la información 9.a. El sistema asigna un código consecutivo a la variable 10. El sistema le presenta la confirmación del almacenamiento Eliminar una variable 7.c El usuario opera la opción de eliminar

Notas y Comentarios 1. Los posibles orígenes de las variables se relacionan a continuación:

Formulario de la Solicitud

Sisben

Puntajes de ICFES y/o ECAES. Mérito académico

Condiciones especiales de cuotas partes por municipio y/o apartamento

Centrales de Información.

Requisitos No Funcionales

Usabilidad Se requiere que el sistema valide el puntaje máximo exigido para la variables para evitar equivocaciones posteriores en el cálculo

Gestión del Proceso. Los modelos deben tener estados de actividad y solamente puede estar un activo para la modalidad que se este adicionando o modificando.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

50

Auditoria Debe almacenarse la siguiente información: o Fecha de la publicación del modelo o Modalidad de crédito o Variables modificadas. o Versión anterior del modelo o Nueva versión del modelo o Usuario que hizo la modificación

Disponibilidad Se requiere que para que el modelo este disponible cuente con una aprobación de la oficina de riesgo y la fecha de aplicación genera su actividad para las operaciones de evaluación del crédito.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

51

2.8 Parametrizar el modelo de clasificación de cartera y cálculo de las provisiones

Código: PCR-SIS-008

Nombre: Parametrizar el modelo de clasificación de cartera y cálculo de las provisiones

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Asociar un nuevo modelo de clasificación de la cartera y el cálculo de las provisiones

Descripción Se debe permitir la captura o modificación de las variables que harán parte del modelo de calificación de cartera y cálculo de provisiones para cada modalidad

Actores Principales Funcionario de la oficina de riesgo.

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Existe una modalidad de crédito sobre la cual se hará la convocatoria

Se cuenta con el modelo aprobado por la oficina de riesgo del ICETEX

El usuario se encuentra ubicado en el registro de la modalidad

Poscondiciones modelo de clasificación de cartera y cálculo de las publicado

Secuencia normal de acciones:

1. El usuario selecciona la opción de modelos. 2. El sistema le presenta dos opciones de creación o

actualización de los modelos:

Modelo de evaluación del crédito

Modelo de calificación de cartera y cálculo de provisiones 3. El usuario selecciona la opción de modelo de calificación

de cartera y de cálculo de provisiones 4. El sistema le presenta la matriz de variables que en su

defecto son:

Edad de la Cartera

Perfil de crédito (Rango de Puntajes)

Calificación (Escala)

Porcentaje de aplicación de la provisión 5. El usuario modifica los datos de la matriz 6. El usuario almacena la información 7. El sistema le presenta la confirmación del

almacenamiento

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

52

Secuencias alternas

Notas y Comentarios El sistema debe permitir mas de un modelo de provisión a la vez, sin embargo debe manejar los siguientes estados de aplicación:

Vigente-Autorizado. El sistema debe calcular el resultado del modelo para cada crédito y enviarlo a contabilidad para los procesos del sistema financiero

Vigente-No autorizado. El sistema debe calcular el resultado del modelo para cada crédito y enviarlo a contabilidad con la condición de la generación de un balance de prueba

No Vigente. No aplica cálculo. El sistema debe permitir versiones de modelo, sin embargo solamente una estará vigente por modalidad y por estado del modelo

Requisitos No Funcionales

Usabilidad Se requiere que el sistema permita adicionar nuevas variables a la matriz que provienen del resultado de la labor de la oficina de riesgo

Gestión del Proceso. Los modelos deben tener estados de actividad y solamente puede estar un activo para la modalidad y estado que se este adicionando o modificando.

Auditoria Debe almacenarse la siguiente información: o Fecha de la publicación del modelo o Modalidad de crédito o Modelo modificado o Estado anterior del modelo o Nuevo estado del modelo o Versión anterior del modelo o Nueva versión del modelo o Usuario que hizo la modificación

Disponibilidad Se requiere que para que el modelo este disponible cuente con una aprobación de la oficina de riesgo y la fecha de aplicación genera su actividad para las operaciones de cartera.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

53

2.9 Definir las condiciones de la legalización en la IES o Constituyente del Fondo

Código: PCR-SIS-009

Nombre: Definir las condiciones de la legalización en la IES o Constituyente del Fondo

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Establecer los pasos para la legalización del crédito por parte de la IES y/o constituyente del Fondo

Descripción Se debe permitir la captura o modificación de las variables que se deben tener en cuenta para la validación de datos y condiciones de la legalización en cada uno de los pasos que hacen parte del proceso de legalización

Actores Principales Administrador del Sistema

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Existe una modalidad de crédito sobre la cual se hará la convocatoria

Se tienen los códigos SNIES de las Instituciones de Educación Superior

Se tienen almacenados los constituyentes del fondo

El usuario se encuentra ubicado en el registro de la modalidad

Poscondiciones Condiciones de la legalización creadas

Secuencia normal de acciones:

1. El usuario selecciona la opción de condiciones para el proceso de legalización.

2. El sistema le presenta una lista de pasos para definir las variables a verificar en cada paso, con las siguientes opciones:

Adicionar Paso

Modificar Paso 3. El usuario selecciona la opción de modificar paso 4. El sistema le presenta la lista de variables que deben ser

verificadas y registradas:

Adicionar Variable

Eliminar Variable 5. El usuario selecciona la opción adicionar variable 6. El sistema le presenta los datos de la variable:

Código de la variable

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

54

Descripción de la variable

Tipo de Variable (Verificación, Registro)

Tipo de Dato a almacenar (Carácter, Entero, SI/NO, Lista, Enumerado y Flotante)

7. El usuario registra los datos solicitados y almacena la información

8. El sistema le presenta la confirmación del almacenamiento

Secuencias alternas Eliminar Paso 4.a El usuario opera la opción de eliminar 8.a. El usuario almacena la información Adicionar un Paso 4.b El usuario opera la opción de adicionar 4.c. El sistema solicita los siguiente datos para la creación del paso:

Nombre del paso

Ubicación en el proceso Eliminar una variable 6.a El usuario opera la opción de eliminar 8.a. El usuario almacena la información

Notas y Comentarios Las variables que contiene la lista de verificación deben tener un estado de actividad al igual que los pasos del proceso

Requisitos No Funcionales

Gestión del Proceso. Las variables deben tener estados de actividad y la construcción de las etapas del proceso de legalización deben tener en cuenta los estándares internacionales sobre la implementación de BPM’s y WF.

Auditoria Debe almacenarse la siguiente información para el caso de la modificación de la variable en un paso: o Fecha de Adición o Modificación de la variable o Modalidad de crédito o Usuario que hizo la modificación

Debe almacenarse la siguiente información para el caso de modificación, adición o eliminación de un paso:

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

55

Fecha de la operación

Tipo de Operación

Modalidad de crédito

Usuario que hizo la modificación

Disponibilidad Se requiere que para que los formatos de legalización queden disponibles deben contar con una aprobación por parte de la vicepresidencia de crédito y cartera.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

56

2.10 Establecer los datos para validar en el formulario

Código: PCR-SIS-010

Nombre: Establecer los datos para validar en el formulario

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Establecer los datos a verificar por parte del tercero de seguimiento al crédito

Descripción Debe permitir la selección de las variables del formulario que deben ser verificadas en la consulta telefónica

Actores Principales Administrador del Sistema

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Existe una modalidad de crédito sobre la cual se hará la convocatoria

El usuario se encuentra ubicado en el registro de la modalidad

Poscondiciones Datos para la validación del formulario establecidos

Secuencia normal de acciones:

1. El usuario selecciona la opción de datos para verificar en el formulario.

2. El sistema le presenta la lista de campos que se están validando con las siguientes opciones:

Adicionar campo

Eliminar Campo 3. El usuario selecciona adicionar campo 4. El sistema le presenta la lista de campos del formulario

que no se encuentran en la lista de validación 5. El usuario selecciona uno o mas campos y la posición en

el formato de validación 6. El usuario almacena la información 7. El sistema le presenta la confirmación del

almacenamiento

Secuencias alternas Eliminar una variable 4.a El usuario opera la opción de eliminar 6a. El usuario almacena la información

7a. El sistema le presenta la confirmación del almacenamiento

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

57

Notas y Comentarios Los campos que contiene la lista de verificación deben tener un estado de actividad

Requisitos No Funcionales

Gestión del Proceso. Los campos del formato de validación deben tener estados de actividad

Auditoria Debe almacenarse la siguiente información: o Fecha de Adición o Modificación del formato o Modalidad de crédito o Usuario que hizo la modificación

Disponibilidad Se requiere que para que el nuevo formato quede disponible cuente con una aprobación por parte de la vicepresidencia de crédito y cartera.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

58

2.11 Definir las condiciones del Giro

Código: PCR-SYS-011

Nombre: Definir las condiciones del Giro

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Establecer las condiciones que debe cumplir el giro

Descripción Operar las condiciones del giro tanto es su constitución como en el paso en firme

Actores Principales Administrador del Sistema

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Existe una modalidad de crédito sobre la cual se hará la convocatoria

El usuario se encuentra ubicado en el registro de la modalidad

Poscondiciones Condiciones del giro creadas

Secuencia normal de acciones:

1. El usuario selecciona la opción condiciones del giro. 2. El sistema le presenta la lista de campos asociados con el

proceso de giros. 3. El usuario selecciona el campo 4. El sistema le presenta la lista de condiciones del giro para los

campos que contienen los valores de aprobación, subsidio y desembolso de los créditos; además que las condiciones de facturación de los cursos avalados por los constituyentes del fondo para las personas naturales, y presenta las siguientes opciones:

Adicionar Condición

Eliminar Condición

Modificar Condición 5. El usuario selecciona adicionar condición 6. El usuario adiciona una nueva condición con los siguientes

datos.

Nombre condición

Operador (Superior, Inferior e Igual)

Comportamiento de la condición (Evitar finalizar el proceso, notificar)

7. El usuario almacena la información 8. El sistema le presenta la confirmación del almacenamiento

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

59

Secuencias alternas Modificar una condición 5.a. El usuario selecciona modificar condición sobre el campo seleccionado 6.a. El sistema le presenta los siguiente datos que pueden ser modificados:

Nombre condición

Operador (Superior, Inferior e Igual)

Comportamiento de la condición (Evitar finalizar el proceso, notificar)

Eliminar una variable 5.b El usuario opera la opción de eliminar 7a. El usuario almacena la información

Notas y Comentarios

Requisitos No Funcionales

Gestión del Proceso. Las condiciones influyen sobre los cambios de las etapas del proceso de giros

Auditoria Debe almacenarse la siguiente información: o Fecha de Adición o Modificación del proceso de giros o Modalidad de crédito o Usuario que hizo la modificación

Disponibilidad Se requiere que para que el nuevo proceso quede disponible cuente con una aprobación por parte de la vicepresidencia de crédito y cartera.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

60

2.12 Definir el formulario para la constitución de la garantía

Código: PCR-SIS-012

Nombre: Definir el formulario para la constitución de la garantía

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Establecer las condiciones para la constitución de la garantía para la modalidad de crédito

Descripción Establecer el formulario de captura de la garantía, la constitución de la garantía se encuentra inmersa en las condiciones del legalización del crédito

Actores Principales Administrador del Sistema

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Existe una modalidad de crédito sobre la cual se hará la convocatoria

El usuario se encuentra ubicado en el registro de la modalidad

Poscondiciones Formulario de constitución de Garantía Creado

Secuencia normal de acciones:

1. El usuario selecciona la opción de formulario de la constitución de la garantía

2. El sistema le presenta la siguiente lista de operaciones sobre el formulario:

Adicionar campos

Eliminar Campos 3. El usuario utiliza la opción de adicionar campos 4. El sistema le presenta el catálogo de campos disponibles 5. El usuario selecciona el campo del catalogo e indica si el

campo seleccionado es obligatorio. 6. El usuario indica que no desea agregar más campos y

selecciona guardar. 7. El sistema graba el formulario

Secuencias alternas Eliminar Campo 3.a. El usuario utiliza la opción de eliminar campos 4.a. El sistema le presenta el catálogo de campos disponibles en el formulario actual

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

61

5.a. El usuario selecciona el campo a eliminar 5.b. El sistema va al paso 6.

Notas y Comentarios

Requisitos No Funcionales

Gestión del Proceso. La constitución de la garantía es una etapa de la legalización del crédito y se constituye como una condición antes del giro

Auditoria Debe almacenarse la siguiente información: o Fecha de modificación del formulario o Campo modificado o Tipo de Operación (Adición, Eliminación) o Usuario que hizo la modificación

Disponibilidad Se requiere que para que el nuevo proceso quede disponible cuente con una aprobación por parte de la vicepresidencia de crédito y cartera.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

62

2.13 Definir plantillas de generación de reportes oficiales

Código: PCR-SIS-013

Nombre: Definir plantillas de generación de reportes oficiales

Elaborado por: William Ciendúa C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Definir las plantillas para los reportes oficiales por cada uno de los créditos y agrupados por las modalidades

Descripción Las plantillas que deben ser generadas inicialmente son:

Resolución de giro

Carta de instrucciones

Pagaré

Actores Principales Administrador del Sistema

Actores secundarios No existe actor secundario

Precondiciones: El cliente es admitido y conocido para el sistema.

Existe una modalidad de crédito sobre la cual se hará la convocatoria

El usuario se encuentra ubicado en el registro de la modalidad

Poscondiciones Plantilla oficial creada

Secuencia normal de acciones:

1. El usuario selecciona la opción de plantillas para la generación de reportes oficiales

2. El sistema le presenta la siguiente lista de posibilidades de registro para la plantilla:

Resolución de Giro

Carta de Instrucciones

Pagaré 3. El usuario selecciona cualquiera de las opciones anteriores. 4. El sistema le presenta la siguiente lista de operaciones:

Adicionar campo

Eliminar Campo 5. El usuario utiliza la opción de adicionar campos 6. El sistema le presenta el catálogo de campos disponibles 7. El usuario selecciona el campo del catalogo e indica si el

campo seleccionado es modificado en tiempo de generación del reporte (P.e. Ordenador del Gasto y Prepuesto en la Resolución).

8. El usuario indica que no desea agregar más campos y selecciona guardar.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

63

9. El sistema graba la plantilla

Secuencias alternas Eliminar Campo 5.a. El usuario utiliza la opción de eliminar campos 6.a. El sistema le presenta el catálogo de campos disponibles en el plantilla 7.a. El usuario selecciona el campo a eliminar 7.b. El sistema va al paso 9.

Notas y Comentarios

Requisitos No Funcionales

Gestión del Proceso. No existe cambio en el proceso por la modificación de las plantillas

Auditoria Debe almacenarse la siguiente información: o Fecha de modificación de la plantilla o Campo modificado o Tipo de Operación (Adición, Eliminación) o Usuario que hizo la modificación

Disponibilidad Se requiere que para que la nueva plantilla quede disponible cuente con una aprobación por parte de la vicepresidencia de crédito y cartera.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

64

2.14 Definir Criterios de Suspensión del Crédito.

Código: PCR-SIS-014

Nombre: Definir Criterios de Suspensión del Crédito.

Elaborado por: William C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Definir criterios de suspensión del crédito.

Descripción Definir una lista con los criterios por los cuales un crédito es suspendido.

Actores Principales Administrador del sistema.

Actores secundarios

Precondiciones: El cliente es valido y tiene los privilegios necesarios.

El sistema ya tiene cargada la información de la modalidad de crédito.

Poscondiciones Se crea una lista con criterios de suspensión y es asociada a una modalidad de crédito

Secuencia normal de acciones:

1. El usuario selecciona definir criterios de suspensión. 2. El sistema muestra los criterios establecidos. 3. El usuario ingresa la descripción del criterio. 4. El usuario indica que no desea agregar más criterios. 5. El sistema guarda la información.

Secuencias alternas 4.1 El usuario indica que desea agregar más campos y va al paso

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

65

2.15 Definir porcentaje de financiación de un rubro.

Código: PCR-SIS-015

Nombre: Definir porcentaje de financiación de un rubro.

Elaborado por: Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Definir criterios que se deben verificar para establecer la financiación de un rubro.

Descripción Con la información que nos suministra el formulario de registro se establece las condiciones de financiación de un rubro.

Actores Principales Administrador del sistema.

Actores secundarios

Precondiciones: El cliente es valido y tiene los privilegios necesarios.

El sistema ya conoce la modalidad que se va ha condicionar.

El sistema ya tiene cargada la información de la modalidad de crédito.

Poscondiciones Se crea n criterios de financiación y se asocian a una modalidad de crédito.

Secuencia normal de acciones:

1. El usuario selecciona definir criterios de financiación. 2. El sistema carga los rubros que la modalidad financia

(matricula, sostenimiento, textos, pasajes, transporte). 3. El usuario selecciona un rubro. 4. El sistema muestra los campos asociados al formulario de

registro de la modalidad agrupados por sección (datos básicos, núcleo familiar, Información laboral del núcleo familiar, datos del crédito, referencias).

5. El usuario selecciona un campo. 6. El sistema muestra los posibles valores del campo. 7. El usuario selecciona el valor o el rango de valores posibles

para el campo. 8. El usuario indica que no desea agregar más campos e

ingresa el porcentaje de financiación. 9. El usuario decide guardar la información. 10. El sistema guarda la información.

Secuencias alternas 8.1 El usuario ingresa más campos y va al paso 5.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

66

8.2 El usuario indica establecer criterios para un nuevo rubro y va la paso 3.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

67

2.16 Definir condiciones de subsidio y/o Condonación.

Código: PCR-SIS-016

Nombre: Definir condiciones de subsidio y/o Condonación.

Elaborado por: William C. Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Definir condiciones de subsidio y/o Condonación.

Descripción Con la información que nos suministra el formulario de registro se establecen las condiciones para los subsidios y/o condonación.

Actores Principales Administrador del sistema.

Actores secundarios No cuenta con actores secundarios

Precondiciones: El cliente es valido y tiene los privilegios necesarios.

El sistema ya conoce la modalidad que se va ha condicionar

La modalidad tiene parametrizado el formulario de registro.

No se pueden agregar campos repetidos para el condicionamiento.

El tipo de financiación del crédito es subsidio, condonación o mixto.

Poscondiciones Se crea las condiciones necesarias para la condonación o subsidio del crédito.

Secuencia normal de acciones:

1. El usuario selecciona definir condiciones de subsidios y/o condonación.

2. El sistema carga los rubros financiados (matricula, sostenimiento, textos, pasajes) y el tipo de financiación (subsidio y/o condonable).

3. El usuario selecciona el rubro y el tipo de financiación. 4. El sistema muestra los campos asociados al formulario de

registro de la modalidad agrupados por sección (datos básicos, núcleo familiar, Información laboral del núcleo familiar, datos del crédito, referencias).

5. El usuario selecciona un campo. 6. El sistema muestra los posibles valores del campo. 7. El usuario selecciona el valor o el rango de valores posibles

para el campo. 8. El usuario indica que no desea agregar más campos e

ingresa el porcentaje de financiación. 9. El usuario decide guardar la información. 10. El sistema guarda la información.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

68

Secuencias alternas 8.1 El usuario ingresa más campos y va al paso 5. 8.2 El usuario indica establecer criterios para un nuevo rubro y va la paso 3.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

69

3. PARAMETRIZACIÓN DE LA LIQUIDACIÓN DE CARTERA

3.1 Definir algoritmo de generación de cuotas

Código: PCA-SIS-001

Nombre: Definir algoritmo de generación de cuotas

Elaborado por: Aprobado por:

Fecha de elaboración:

2007-06-16 Fecha de aprobación:

Objetivo Definir los algoritmos para cada uno de los sistemas de amortización aprobados por la superintendencia financiera

Descripción Actualmente se cuenta con la siguiente clasificación de sistemas de amortización para la generación de las cuotas:

Cuota Fija

Amortización Fija

Cuota variable

Actores Principales Administrador del sistema.

Actores secundarios No cuenta con actores secundarios

Precondiciones: El cliente es valido y tiene los privilegios necesarios

El sistema de amortización ha sido creado.

Poscondiciones Algoritmo de liquidación creado.

Secuencia normal de acciones:

1. El usuario selecciona a partir del sistema de amortización las siguientes opciones:

2. El usuario selecciona la opción adicionar y/o modificar el algoritmo de cálculo de las cuotas

3. El sistema le presenta las formulas actuales del algoritmo de cálculo de cuotas

4. El usuario modifica las formulas 5. El sistema le presenta las siguientes opciones:

Probar formula

Almacenar Formula 6. El usuario decide guardar la información. 7. El sistema guarda la información confirmando la opción al

usuario

Secuencias alternas No existe algoritmo de liquidación de cuotas

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

70

4. OTORGAMIENTO DE CRÉDITO

4.1 Registrar Solicitud de crédito de un solicitante

Código: OTO-SIS- 001

Nombre: Registrar Solicitud de crédito de un Solicitante

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-06-01 Fecha de aprobación:

Objetivo Registrar los datos del solicitante para acceder al crédito

Descripción El sistema le permite al solicitante realizar el ingreso de información parcial o definitiva de la solicitud, la matricula de la cuenta bancaria, obtener el número de registro cuando la solicitud esta diligenciada totalmente y el solicitante autoriza su evaluación y conocer el estado de la Solicitud de Crédito (parcial, total o modificada) (Ver nota 1). * El sistema debe estar en la capacidad de bloquear a las personas que se hayan inscrito en el mismo periodo en otra modalidad de crédito y/o fondo. **Los formularios pueden quedar incompletos por un periodo de un (1) mes luego serán anuladas y deberán ingresar de nuevo toda la información. ***Una vez diligencien los criterios mínimos de aceptación el sistema debe evaluarlos para saber si el solicitante es susceptible a evaluación.

Actores Principales Solicitante del Crédito

Es el encargado de ingresar la información del formulario.

Actores secundarios ACH.

Esta base de datos del sistema financiero es utilizada en el proceso de matricula de cuentas. La utilización del servicio se hace por un procesamiento por lotes

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

71

Interfase con la Registraduría

Sirve para confirmar el estado del número de identificación del solicitante (Válido e inválido). El proceso se hace en línea a través de un servicio web.

Precondiciones: Modalidad de crédito parametrizada (Ver Caso de Uso - NEG-PAR-001) y publicada en la pagina Web.

El calendario debe estar vigente para la inscripción de solicitudes En las modalidades de crédito y fondos abiertos(Ver Nota 2)

El solicitante que tenga otro crédito en el ICETEX debe haber cancelado por lo menos el cincuenta por ciento (50%) de este para poder solicitar otro crédito. (Actúa como una regla de negocio que puede cambiar con las políticas establecidas para el ICETEX, por ejemplo las condiciones del préstamo para los computadores).

Poscondiciones Solicitud completa (Ver nota 3)

Solicitud Parcial (Ver Nota 4)

Solicitud Modificada (Ver Nota 5)

Número de registro cuando la solicitud esta completamente diligenciada.

Secuencia normal de acciones:

1. El solicitante selecciona la modalidad de Crédito y/o Fondo e ingresa el número de identificación.

2. El sistema valida si el número de identificación del solicitante existe, ver caso de uso caso de uso de consulta de la solicitud (Ver caso de uso OTO-SIS-004) (Ver nota 6)

3. El sistema le solicita que cree un Pin de seguridad (ver caso de uso OTO-SIS-003)

4. El sistema valida el Pin de seguridad 5. El sistema presenta el formato a diligenciar ver caso de uso

registrar sección Datos Básicos (Ver caso de uso OTO-SIS-006) y demás datos de la solicitud (Ver caso de uso OTO-SIS-007)

6. El solicitante autoriza la evaluación de la solicitud 7. El sistema valida que la información del formulario este

completa y le asigna el número de registro 8. El sistema conduce al solicitante al registro del deudor

solidario 9. El solicitante imprime el reporte de solicitud de crédito con el

número de registro asignado (solo se da cuando la solicitud esta completa) (Ver nota 7)

10. Fin del Proceso.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

72

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación debe guardar el registro de solicitud en un tiempo máximo de cinco (5) segundos. El sistema debe controlar el tiempo de duración de las solicitudes diligenciadas parcialmente. En el caso que se haya vencido el plazo (un mes) deben ser anuladas y se le debe informar al solicitante.

Disponibilidad La solicitud debe estar disponible para realizar cambios cuando este diligenciada parcialmente, siempre y cuando el calendario de la solicitud se encuentre activo. Cuando este completamente diligenciada la solicitud debe estar disponible para consulta de los solicitantes, para el(los) analista(s) de créditos que realicen el proceso de evaluación de las solicitudes. La solicitudes diligenciadas parcialmente deben estar disponibles por un tiempo máximo de un (1) mes y para modificaciones estarán disponibles de acuerdo al periodo establecido por cada modalidad de crédito y/o fondo. La información debe quedar disponible para atención al usuario con el fin de que pueda realizar consultas.

Seguridad El sistema debe pedir un código de autenticación (pin de seguridad) para que el solicitante entre a modificar una solicitud parcial o a consultar el estado de la solicitud

Gestionabilidad - Control de procesos En el caso de que la solicitud sea diligenciada totalmente y el solicitante autoriza su evaluación el proceso queda en un estado de radicado. En el caso de solicitudes parciales no existe cambio en el estado del proceso.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

73

En el caso de las solicitudes que están diligenciadas parcialmente y llevan un periodo superior a un mes quedan en un estado de anulado.

Auditoria Debe existir un control de los cambios realizados en las solicitudes parciales donde se presente: o Fecha o Ubicación o Cambio realizado o Actor que lo realizo (solicitante)

Notas y comentarios 1. Los formularios pueden quedar diligenciados parcialmente de acuerdo a lo establecido en el reglamento de cada modalidad y/o fondo (Ver Formulario General del crédito).

2. La convocatoria abierta hace referencia a los créditos donde

los solicitantes se pueden inscribir a nivel nacional. 3. Solicitud Completa: Es cuando el solicitante ha diligenciado el

formulario en su totalidad y autoriza para que esta entre a evaluación.

4. Solicitud Parcial: Hace referencia a las solicitudes que tienen

información incompleta en las diferentes secciones del formulario de inscripción. En este punto el sistema debe estar en la capacidad de controlar los cambios (fecha, observación y quien lo realizó) que se realizan en los formularios y el estado de la misma (solicitud parcial, solicitud modificada y solicitud total).

5. Solicitud Modificada: Hace referencia a aquellas solicitudes

que han sido diligenciadas en su totalidad pero no han sido marcadas para evaluación o aquellas solicitudes parciales que son susceptibles a cambios en la información o diligenciar los campos faltantes El sistema debe llevar un histórico de cambios, donde se muestre la fecha y la observación de los cambios realizados.

6. El calendario es estipulado por el comité de crédito. En este

se fija la fecha de inicio de la convocatoria, la fecha de finalización, el tiempo para legalización y visado del crédito y

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

74

el tiempo para modificación de solicitudes. En el caso de los Fondos se rige por lo estipulado en la Junta Administradora para el ingreso de información en la solicitud de crédito.

7. La opción de impresión del reporte de solicitud de crédito debe quedar disponible hasta la legalización del crédito

* En el caso de fondos y modalidades donde se debe hacer una preinscipción, el sistema debe estar en la capacidad de validar que el numero de identificación este en la base de datos de las modalidades y/o fondos específica.

**El sistema debe permitir que el solicitante conozca los datos

necesarios en las demás secciones y la información requerida para la evaluación del deudor solidario.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

75

4.2 Cargar beneficiarios de fondos en el sistema de crédito y cartera

Código: OTO-SIS- 002

Nombre: Cargar beneficiarios de fondos en el sistema de crédito y cartera

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-07-11 Fecha de aprobación:

Objetivo Realizar el cargue de la información de los beneficiarios de fondos en el sistema de crédito y cartera.

Descripción El sistema debe subir la información de los beneficiarios de fondos que fue cargada por los gestores. En este caso el gestor debe cargar la información en una planilla y el sistema debería contar con una utilidad para el cargue de esta información en el sistema de cr4édito y cartera.

Actores Principales Gestor del fondo Es el encargado de ingresar la información de los beneficiarios de los fondos.

Sistema de crédito y cartera

Esta aplicación es la encargada de cargar la información de los beneficiarios de los fondos

Analista de fondos Se encarga de correr el proceso de cargue de información

Actores secundarios

Precondiciones: El gestor debe haber cargado la información de los beneficiarios en el sistema

El fondo debe estar en el periodo para inscripción de solicitudes.

Poscondiciones Beneficiario registrado

Secuencia normal de acciones:

1. El funcionario de fondos entra al sisema y escoge la opción “cargar información de beneficiarios de los fondos”

2. El sistema le presenta los archivos recibidos de los gestores 3. El funcionario escoge el fondo del cual quiere cargar los

beneficiarios 4. El sistema carga la información 5. Fin del proceso

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

76

Secuencias alternas 4a.El sistema no carga la información Porque hay incompatibilidad de los tipos de campo (p.e. que en la columna del número de identificación colocan una letra en vez de número) el sistema enva un mensaje de no aplicación con la respectiva observación y el analista de fondos le informa a el gestor del fondo para su modificación.

Requerimientos no funcionales

Desempeño ( Rendimiento) o El sistema debe cargara la información en un tiempo

máximo de dos (2) segundos una vez que el analista de fondos o escoge.

o El sistema debe generar un mensaje de acepcatción o rechazo de cargue de la información.

Disponibilidad La información generada en este caso de uso debe estar disponible en el repositorio del sistema de crédito y cartera para su consulta y generación de las actividades siguientes.

Seguridad o El sistema debe pedir un código de autenticación al

analista de fondos para que pueda relaizar este proceso.

Gestionabilidad - Control de procesos Este caso de uso se genera el estado de “radicado” .

Auditoria Debe existir un repositorio donde se presntela siguiente información:

o Fondo que se modifico o Beneficiarios que se cagaron o Fecha de cargue o Actor que lo realizo

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

77

4.3 Crear pin de seguridad

Código: OTO-SIS- 003

Nombre: Crear pin de seguridad

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-06-13 Fecha de aprobación:

Objetivo Contar con una clave de acceso para el diligenciamiento del formulario y para los demás procesos de consulta o modificación que se deban realizar en la duración del crédito

Descripción El sistema le permite al solicitante crear una clave de acceso para realizar los procesos de consulta y modificación en las etapas del crédito.

Actores Principales Solicitante del Crédito

Es el encargado de ingresar la información para la creación del pin de seguridad.

Actores secundarios Sistema de pines de seguridad

Esta aplicación es la encargada de solicitarle la información al usuario para la creación del pin de seguridad.

Precondiciones: El solicitante debe ser un usuario nuevo

La modalidad de crédito y/o fondo debe estar en el periodo para inscripción de solicitudes.

Poscondiciones Asignación del Pin de seguridad

Secuencia normal de acciones:

1. El solicitante ingresa el número de identificación al sistema 2. El sistema le informa que debe crear una clave de acceso y le

presenta el texto jurídico 3. El solicitante acepta las condiciones para crear la clave de

acceso 4. El sistema le solicita al usuario dos preguntas con sus

respectivas respuestas para la creación de la clave de acceso 5. El solicitante graba la información requerida 6. El sistema le envía un mensaje de aceptación de clave al

correo electrónico y le solicita el cambio de la clave la primera vez que ingresa.

7. Fin del proceso

Secuencias alternas 3a. El solicitante no acepta las condiciones para crear la clave de acceso

Fin del proceso

Requerimientos no

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

78

funcionales Desempeño ( Rendimiento) o La aplicación debe guardar la información dada por el

solicitante en un tiempo máximo de dos (2) segundos. o El sistema debe generar una respuesta de aceptación

o rechazo del pin.

Disponibilidad La creación de clave de acceso debe estar disponible cuando la convocatoria de la modalidad de crédito y/o fondos esta en proceso de inscripción de solicitudes (el tiempo depende de lo estipulado en cada una de estas).

Seguridad El sistema debe pedir el número de identificación y debe validar que este no exista en la base de datos del sistema de crédito y cartera. El solicitante al finalizar el proceso debe contar con una clave única y conocida sólo por él.

Gestionabilidad - Control de procesos Este caso de uso debe presentar el estado “aceptado” para la creación del pin de seguridad y finaliza con un estado de pin de seguridad “activo”.

Auditoria Debe existir un control de la generación del pin de seguridad donde se presente:

o Fecha de creación o Preguntas y respuestas creadas por el solicitante. o Número de identificación del actor que creó el pin de

seguridad

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

79

4.4 Cambiar pin de seguridad

Código: OTO-SIS- 004

Nombre: Cambiar pin de seguridad

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-06-13 Fecha de aprobación:

Objetivo Cambiar la clave de acceso cuando el usuario la ha olvidado o cuando el usuario lo desee y cuando lo exija el sistema.

Descripción El sistema le permite al solicitante realizar el cambio de la clave de acceso. En el caso de olvido de clave el usuario debe responder las preguntas dadas al sistema en el momento de la creación del pin de seguridad. Cuando es cambio de clave debe entrar con su pin de seguridad actual a la opción de cambio de contraseña. El usuario tiene tres intentos para responder las preguntas. Si no acierta la cuenta es bloqueada y se debe comunicar con el contact center donde se valida la información básica. Una vez confirmada se resetea la clave actual y se habilita la opción de cambiar clave. En el caso de que la información sea inconsistente el usuario debe acercarse a la oficina de atención al usuario para realizar este proceso.

Actores Principales Solicitante del Crédito

Es el encargado de ingresar la información para el cambio del pin de seguridad.

Actores secundarios Sistema de pines de seguridad

Es el encargado de procesar la información y validar el cambio de clave

Contact center Es el encargado de resetear la clave actual y habilitar la opción en el sistema de cambio de clave en el caso de que la sesión ha sido bloqueada porque el usuario olvido su clave y no respondió correctamente las preguntas de seguridad. Este proceso se puede a llevar a cabo cuando la información básica solicitada por los funcionarios de esta área es validada con la del sistema.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

80

Atención al usuario Es el encargado de resetear la clave actual y habilitar la opción en el sistema de cambio de clave en el caso de que la sesión ha sido bloqueada porque los datos solicitados por el contact center son inconsistentes. Este proceso se puede hacer cuando el solicitante se acaezca personalmente a las oficinas de esta área.

Precondiciones: El solicitante debe tener un pin de seguridad creado

La sesión del solicitante debe estar activa

Poscondiciones Cambio de pin de seguridad

Secuencia normal de acciones:

1. El solicitante ingresa el pin de seguridad actual 2. El sistema valida el pin de seguridad 3. El sistema presenta la información de la sesión 4. El solicitante escoge la opción “cambio de claves” 5. El sistema le solicita la clave actual y la nueva clave 6. El solicitante ingresa la información requerida y graba 7. El sistema actualiza la clave de acceso y guarda los cambios

en el histórico. 8. Fin del proceso

Secuencias alternas 2a. El sistema no valida el pin de seguridad Cuando el solicitante ingresa un pin incorrecto el sistema le hace las preguntas de seguridad y él tiene tres intentos para contestarlas.

Si las contesta correctamente antes de los tres intentos retoma el flujo normal en el paso tres (3).

Si contesta mal en los tres intentos que tiene el usuario debe comunicarse con el contact center, el cual le solicita información básica y la valida. o El sistema presenta tres campos aleatoriamente

para que el contact center haga las respectivas preguntas Si la información solicitada por el contact center es validada resetea la clave actual y habilita la opción de cambio de clave.

o En el caso de que la información sea inconsistente el solicitante se debe acercar a las oficinas de atención al usuario con una carta solicitando el cambio de clave y el documento de identificación. En esta oficina se verifican los datos básicos del solicitante (p.e. nombre, número de identificación) 1. Si la información es valida se resetea la clave

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

81

actual y habilita la opción de cambio de clave. 2. Si el documento de identificación es

incorrecto se le indica al solicitante para realizar los correctivos pertinentes (p.e. actualización de datos)

Requerimientos no funcionales

Desempeño ( Rendimiento) o La aplicación debe guardar la información dada por el

solicitante en un tiempo máximo de 2 segundos. o El sistema debe generar una respuesta de aceptación

o rechazo del cambio de clave

Disponibilidad El cambio de clave debe estar disponible en los siguientes casos:

o Cuando el usuario quiere cambiar de pin de seguridad

o Cuando el usuario olvido su clave actual pero las respuestas de las preguntas de seguridad son acertadas y fueron dadas antes de los tres intentos que tiene para contestarlas.

o Cuando el contact center habilita la opción de cambio de clave.

o Cuando atención al usuario habilita la opción de cambio de clave.

Seguridad El sistema debe pedir el pin de seguridad validarlo. El contact center debe validar la información básica del solicitante en el caso de que la sesión este bloqueada. Atención al usuario debe validar los datos básicos del solicitante cuando el contact center no habilito la opción de cambio de clave por inconsistencia de datos. El solicitante al finalizar el proceso debe contar con una clave única y conocida sólo por él.

Gestionabilidad - Control de procesos Este caso de uso se puede iniciar en el estado de “pin bloqueado” o “pin activo” y finaliza con un estado de pin de seguridad “modificado”.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

82

Auditoria Debe existir un control en el vcambio de pin de seguridad donde se presente:

o Fecha de cambio. o Motivo del cambio (Pin bloqueado o por solicitud del

solicitante). o Número de identificación del actor que cambio el pin

de seguridad. o Medio por el que se realizo el cambio:

­ Sesión del usuario ­ Contact center ­ Atención al usuario

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

83

4.5 Consultar estado de la Solicitud por número de identificación

Código: OTO-SIS- 005

Nombre: Consultar estado de la Solicitud por número de identificación

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-04-18 Fecha de aprobación:

Objetivo Conocer el estado de las solicitud(es) crédito(s) por medio del número de identificación.

Descripción El software valida si el número de identificación del solicitante ya existe en la base de datos de solicitudes de crédito en cualquiera de sus modalidades o fondo y muestra el resultado de la consulta. *En este proceso se puede revisar si el usuario tenía solicitudes de créditos aprobados en las diferentes modalidades de crédito y/o fondo.

Actores Principales Sistema de información de solicitudes de crédito

Es el encargado de validar la existencia del número de identificación en las bases de datos de crédito y cartera.

Solicitante Realiza la consulta del estado de la solicitud

Actores secundarios

Precondiciones: Modalidad de crédito parametrizada (Ver Caso de Uso - NEG-PAR-001) y publicada en la Web

Poscondiciones Obtener la confirmación de la existencia del número de identificación del solicitante.

Secuencia normal de acciones:

1. El beneficiario ingresa el pin de seguridad y el numero de identificación

2. el sistema valida la información 3. El sistema presenta el resultado de la consulta y regresa al

paso 4 del caso de uso OTO-SIS-001 (Ver Nota 1) 4. Fin del Proceso

Secuencias alternas 1a. Si el número de identificación existe y el formulario se encuentra diligenciado (parcialmente)

El sistema pide al solicitante el pin de seguridad

El sistema valida que el pin de seguridad corresponda al número de identificación ingresado (ver nota 2)

El sistema trae la información del formulario para su

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

84

modificación o para completar información faltante ver caso de uso de modificación del formulario (ver caso de uso OTO-SIS-005)

1b. Si el número de identificación existe y el formulario se encuentra bloqueado por encontrarse en evaluación comité de crédito

El sistema pide al solicitante el pin de seguridad

El sistema valida que el pin de seguridad corresponda al número de identificación ingresado

El sistema presenta el reporte con la información ingresada por el solicitante. En este caso no se pueden realizar modificaciones en los datos.

1c. Si el número de identificación no existe

Se notifica que no existe información para el número de identificación consultado

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación debe presentar el estado de la solicitud en un tiempo de máximo de 2 segundos una vez que el solicitante digite su pin de seguridad y el número de identificación.

Disponibilidad La solicitud debe estar disponible para que sea consultada por el usuario hasta que entra a comité de evaluación. y debe presentar el estado en que se encuentra.(solicitud parcial, modificada , total o en comité de evaluación).

Seguridad El sistema debe pedir un código de autenticación (pin de seguridad) para que el solicitante pueda consultar el estado de la solicitud.

Gestionabilidad – Control del proceso Este caso de uso puede iniciar en cualquiera de los siguientes estados: Solicitud parcial, solicitud modificada o solicitud total). En la consulta de solicitudes no hay cambio de estado.

Auditoria Debe existir un histórico que presente las consultas realizadas con fecha y quien la realizó Es posible establecer una política estándar para cada uno de los procesos

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

85

(Inserción, modificación, Borrado y Consulta).

Notas y comentarios 1. Los estados de las solicitudes son:

1. Solicitud parcial: Aquellas solicitudes que no han

dligenciado totalmente la información o aquellas que son susceptibles de modificación de datos antes de ser autorizada para evaluación.

2. Solicitud completa: Es cuando el solicitante ha

diligenciado el formulario en su totalidad y autoriza para que esta entre a evaluación. En este caso el proceso queda en un estado de radicado

3. Anuladas:

o Por vencimiento de términos. o Por solicitud del Beneficiario del crédito En el caso de anulación de solicitudes el proceso se da por finalizado

4. En comité de evaluación

2. En el caso de que el solicitante olvide el pin de seguridad el sistema le hace las preguntas que el usuario grabo en el momento de la creación de la clave de acceso y tiene tres intentos para responderlas. Si en estas tres oportunidades no contesta correctamente la sesión se bloquea y debe comunicarse con el contact center para resetear la clave actual y para la creación de otra.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

86

4.6 Registrar sección datos básicos

Código: OTO-SIS- 006

Nombre: Registrar Sección de Datos Básicos

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-04-18 Fecha de aprobación:

Objetivo Realizar el ingreso de los datos básicos del solicitante

Descripción El sistema presenta la sección de datos básicos requeridos (ver nota 1), el solicitante ingresa la información requerida en esta sección, el sistema valida que los campos obligatorios se encuentren diligenciados y graba la información. *El sistema debe controlar que el solicitante diligencie el formulario de acuerdo a lo establecido en la parametrización de cada modalidad de crédito y/o fondo.(p.e. las convenciones utilizadas en las direcciones).

Actores Principales Solicitante del Crédito

Es el encargado de ingresar los datos básicos en el formulario

Actores secundarios

Precondiciones: El solicitante debe contar con una clave de acceso en la modalidad de crédito y/o fondo a inscribirse.

Poscondiciones Activación de las siguientes secciones del formulario de solicitud de crédito

Solicitud parcial.

Secuencia normal de acciones:

1. El sistema presenta la información de los datos básicos del solicitante a diligenciar

2. El solicitante ingresa la información solicitada y graba la sección.

3. El sistema valida que los campos obligatorios se encuentren completamente diligenciados

4. El sistema guarda la información 5. El sistema habilita las demás secciones de la solicitud de

crédito para que sean diligenciadas ver caso de uso OTO-SIS-004

6. Fin del Proceso

Secuencias alternas 5a. El sistema no valida los campos obligatorios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

87

El sistema muestra el mensaje que todos los campos obligatorios no están diligenciados y lo regresa al paso dos (2) del flujo normal

Requerimientos no funcionales

Desempeño ( Rendimiento) El sistema debe almacenar la información en un tiempo máximo de dos (2) segundos El sistema debe generar una respuesta de aceptación o rechazo de la información guardada por el solicitante.

Disponibilidad La solicitud debe estar disponible para que sea diligenciada cuando el solicitante tenga código de autenticación (pin de seguridad). Esta información debe quedar guardada en un repositorio del sistema de crédito y cartera con el fin de generar reportes o para consulta de los funcionarios del ICETEX.

Seguridad El sistema debe pedir un código de autenticación (pin de seguridad) para que el solicitante entre a diligenciar los datos básicos de la solicitud.

Gestionabilidad - Control del proceso En este casos de uso no existen cambios de estado en el proceso.

Auditoria Debe existir un histórico que presente los siguientes datos: 1. Fecha 2. Información diligenciada 3. Actor que lo realizo

Notas y comentarios 1. Los datos básicos a diligenciar son:

Nombre completo

Tipo de identificación (tarjeta de identidad, cédula de ciudadanía)

Numero de identificación

Departamento y ciudad de nacimiento

Fecha de nacimiento

Género

Estado civil

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

88

Departamento y municipio de residencia

Dirección residencia

Teléfono residencia

Correo electrónico Sin embargo la información solicitada en esta sección puede variar dependiendo de las necesidades de la modalidad de crédito o fondo.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

89

4.7 Registrar demás secciones de la solicitud de crédito

Código: OTO-SIS- 007

Nombre: Registrar demás secciones de la solicitud de crédito

Elaborado por: Aprobado por:

Fecha de elaboración:

2007-04-18 Fecha de aprobación:

Objetivo Registrar la información requerida en las diferentes secciones de la solicitud de crédito diferentes a la sección de los datos básicos.

Descripción El solicitante ingresa la información requerida en las secciones de: Núcleo Familiar, Datos laborales del núcleo Familiar, Datos del crédito, Historial académico, Referencia Familiares e Información Bancaria en la solicitud de crédito para que pueda obtener el reporte de inscripción. (Las secciones que se presentan son las que tiene el ICETEX, pero pueden cambiar en el transcurso del tiempo). *No es necesario realizar el registro total de una sección para pasar a la otra. **El sistema debe ser flexible para que el solicitante conozca los datos necesarios en cada sección y así poder conseguir toda la información.

Actores Principales Solicitante del Crédito

Es el encargado de diligenciar la información del formulario de solicitud de crédito

Actores secundarios

Precondiciones: El solicitante debe haber diligenciado la sección de datos básicos

El solicitante debe contar con una clave de acceso para adicionar o modificar los datos que hacen parte de las secciones del formulario

La solicitud debe estar vigente y dentro de las fechas estipuladas por cada modalidad de crédito y/o fondo para diligenciamiento de solicitudes

Poscondiciones Solicitud completa

Obtener el reporte de la inscripción cuando la solicitud quede completa

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

90

Tener el histórico de los cambios o del diligenciamiento realizado en el formulario

Secuencia normal de acciones:

1. El solicitante ingresa la información a cada una de las secciones de la solicitud de crédito (Ver Nota 1)

2. El sistema valida que los campos obligatorios de cada sección se encuentren diligenciados

3. El sistema guarda la información 4. El sistema presenta el reporte de la inscripción y genera el

histórico de cambios. 5. El solicitante imprime el reporte de la solicitud de crédito 6. Fin del Proceso

Secuencias alternas 5a. El sistema no valida los campos obligatorios

El sistema muestra el mensaje que todos los campos obligatorios no están diligenciados y lo regresa al paso uno (1) del flujo normal

Requerimientos no funcionales

Desempeño ( Rendimiento) El sistema debe almacenar la información en un tiempo máximo de dos (2) segundos por sección. Cuando el solicitante grabe la información, el sistema debe indicarle los datos que le faltaron en cada sección. El sistema debe generar una respuesta de aceptación o rechazo de la información guardada por el solicitante.

Disponibilidad La sección debe estar disponible para que sea diligenciada cuando el solicitante tenga código de autenticación (pin de seguridad). La información debe quedar guardada en un repositorio del sistema de crédito y cartera con el fin de generar reportes o para consulta de los funcionarios del ICETEX.

Seguridad El sistema debe permitir el diligenciamiento de las secciones de las solicitudes siempre y cuando la sección de datos básicos se encuentre diligenciada con los datos obligatorios. El sistema debe pedir un código de autenticación (pin de seguridad) para que el solicitante entre a diligenciar las

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

91

secciones diferentes a la de datos básicos de la solicitud.

Gestionabilidad - Control del proceso El aplicativo debe presentar el estado en que se encuentra la solicitud con su respectiva explicación. Después de diligenciar las secciones no existe cambio, pero en el momento que las secciones se diligencien en su totalidad puede establecerse un estado para el proceso de modificado

Auditoria Debe existir un histórico que presente los siguientes datos:

o Fecha o Información diligenciada o Actor que lo realizo

Notas y comentarios 1. La información de las demás secciones de la solicitud de crédito puede variar dependiendo de las necesidades de la modalidad de crédito o fondo (Ver anexo Formulario general de crédito donde se muestra los campos mínimos con que debe contar esta sección). Para el caso de la información bancaria solo es requerida si el beneficiario solicita financiación de sostenimiento, textos, transporte, derechos de grado.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

92

4.8 Modificar solicitud cuando falta información en la etapa de diligenciamiento de la

solicitud de crédito

Código: OTO-SIS- 008

Nombre: Modificar la solicitud cuando falta información en la etapa de diligenciamiento de la solicitud de crédito

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-04-18 Fecha de aprobación:

Objetivo Permitir que el solicitante pueda ingresar información faltante a la solicitud de crédito o realizar modificaciones a la información ya ingresada siempre y cuando no este siendo evaluada.

Descripción El sistema presenta la información grabada por el solicitante para que este pueda realizar modificaciones a la solicitud o ingresar información faltante en el formulario, el solicitante completa la información requerida e imprime el soporte de la inscripción.

Actores Principales Sistema de información de solicitudes de crédito

Presenta las solicitudes disponibles en la base de datos del ICETEX y susceptibles a cambios

Solicitante del crédito

Es el encargado de ingresar la información faltante en la solicitud o de modificar aquella que esta incorrecta.

Actores secundarios

Precondiciones: El solicitante debe contar con pin de seguridad para poder modificar la solicitud.

El formulario debe encontrarse vigente según la política de la modalidad de crédito y/o fondo.

Poscondiciones Obtener la actualización de la información solicitada en el formulario de inscripción

Obtener el soporte de la inscripción

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

93

Secuencia normal de acciones:

1. El solicitante ingresa el pin de seguridad y el número de identificación

2. El sistema valida la información 3. El solicitante escoge la opción de modificar datos del

formulario. 4. El sistema presenta el formulario con los datos diligenciados 5. El solicitante selecciona los datos a modificar e ingresa la

información faltante o corrige la información existente 6. El sistema valida que los campos obligatorios de la sección

se encuentre completamente diligenciados 7. El sistema actualiza la base de datos y alimenta el histórico

de cambios (Ver nota 1) 8. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) El sistema debe almacenar la información en un tiempo máximo de dos (2) segundos por sección. El sistema debe generar una respuesta de aceptación o rechazo de la información modificada por el solicitante.

Disponibilidad La solicitud debe estar disponible para modificación cuando este diligenciada parcialmente o cuando no ha sido autorizada por el solicitante para evaluación. Cuando la solicitud ha sido evaluada y hubo inconsistencias en los datos la solicitud queda como aplazada para que el solicitante modifique la información. La información debe quedar guardada en un repositorio del sistema de crédito y cartera con el fin de controlar los cambios realizados en la solicitud.

Seguridad El sistema debe pedir un código de autenticación (pin de seguridad) para que el solicitante entre a diligenciar las secciones diferentes a la de datos básicos de la solicitud.

Gestionabilidad (Transabilidad). El aplicativo debe presentar el estado de solicitud parcial o solicitud total y al finalizar el proceso debería quedar un

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

94

estado de modificación en la solicitud con sus respectivas observaciones.

Auditoria Debe existir un histórico que presente las modificaciones realizadas donde se presente la siguiente información:

o Fecha o Cambio realizado o Actor que lo realizo (solicitante, atención al usuario,

seguimiento al crédito).

Notas y comentarios 1. En el caso de que el solicitante diligencie todo el formulario y autoriza la evaluación de éste, el sistema debe verificar que los datos estén completos y así poder asignarle el número de registro.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

95

4.9 Registrar la solicitud de estudio del Deudor Solidario

Código: OTO-SIS- 009

Nombre: Registrar la solicitud de estudio del Deudor Solidario

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-04-18 Fecha de aprobación:

Objetivo Registrar los datos del deudor solidario para que pueda ser evaluado por la central de información

Descripción El solicitante ingresa a la opción de solicitar estudio del deudor solidario e ingresa la información solicitada en el formulario. Graba la información y genera el recibo para pagar el estudio del deudor *Si el solicitante muestra que tiene suficiencia económica puede ser el deudor. ** Este caso de uso esta sujeto a cambios en el futuro.

Actores Principales Solicitante del Crédito

Es el encargado de diligenciar la información del deudor solidario

Actores secundarios

Precondiciones: El deudor Solidario no puede ser codeudor de más de dos (2) créditos.

Poscondiciones Solicitud del deudor solidario diligenciada

Recibo para pagar el estudio del deudor solidario

Secuencia normal de acciones:

1. El sistema solicita el tipo de identificación y número de identificación del deudor solidario (Ver Nota 1)

2. El sistema muestra los datos requeridos del deudor solidario (Ver anexo formulario del deudor solidario) (Ver Nota 2).

3. El solicitante ingresa la información requerida 4. El sistema valida que los datos obligatorios hayan sido

diligenciados en su totalidad 5. El sistema genera el recibo para pago del estudio del deudor

solidario (Ver anexo recibo de caja estudio deudor solidario) 6. El sistema envía a la central de información las solicitudes de

estudio de codeudor pendientes de evaluación con las variables requeridas por la central de información y las marca como enviadas

7. Fin del Proceso

Secuencias alternas 3a. El solicitante no diligencia los datos obligatorios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

96

requeridos

Si no se han diligenciado los campos obligatorios el sistema genera un mensaje informando que debe diligenciar los campos obligatorios y lo regresa al paso dos (2) del flujo normal

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación debe guardar el registro de solicitud del deudor solidario en un tiempo máximo de cinco (5) segundos.

Disponibilidad Cuando este completamente diligenciada la solicitud debe estar disponible para consulta del solicitante y para el(los) analista(s) de créditos que realicen el proceso de evaluación de las solicitudes. La solicitud debe estar vigente por un plazo máximo de tres (3) meses para su evaluación. Si en este periodo el solicitante no paga el estudio del deudor esta solicitud es anulada.

Seguridad El sistema debe pedir un código de autenticación (pin de seguridad) para que el solicitante entre a diligenciar la información solicitada para la evaluación del deudor solidario. El(los) analista(s) de crédito debe tener una clave personal para consultar los deudores solidarios registrados.

Gestionabilidad - Control de procesos Cuando la solicitud de evaluación del deudor solidario es diligenciada en su totalidad queda en un estado de evaluación.

Auditoria Debe existir un repositorio donde se presente la siguiente información:

o Fecha de inscripción o Nombre del (los) deudor(es) solidario(s). o Número de identificación del (los) deudor(es)

solidario(s). o Nombre del solicitante al que se le relaciona el(los)

deudor(es) solidario(s). o Actor que realizo el registro de la solicitud.

Notas y comentarios 1. El solicitante podrá ingresar varios deudores solidarios para

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

97

estudio por parte de la Central de Información. La modalidad de crédito debe tener definido cuantos deudores solidarios necesita cada solicitud.

2. El deudor solidario puede ser persona natural o jurídica.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

98

4.10 Evaluar el deudor solidario

Código: OTO-SIS- 010

Nombre: Evaluar el deudor solidario

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-04-18 Fecha de aprobación:

Objetivo Realizar la calificación del deudor solidario con base en el scoring requerido por la modalidad de crédito o Fondo

Descripción La Central de Información realiza la evaluación de las solicitudes de estudio del deudor solidario pendientes de evaluar y que ya realizaron el pago ante el banco teniendo en cuenta el scoring para la evaluación según la modalidad de crédito o fondo

Actores Principales Central de Información

Es la encargada de realizar la evaluación del deudor solidario. Una vez la realiza debe ser enviada al ICETEX con los respectivos resultados y sus observaciones.

Actores secundarios Sistema de solicitudes de crédito

Utiliza los resultados generados por la central de Información para realizar la evaluación de las solicitudes de crédito

Precondiciones: El solicitante debe haber pagado en el banco la solicitud de estudio del deudor solidario

La Central de Información debe tener actualizada en línea la información de los deudores solidarios que se encuentren pendientes de evaluación.

Poscondiciones Deudor aprobado (ver nota 1)

Deudor rechazado (ver nota 2)

Actualizar el resultado en la base de datos de solicitudes de crédito del ICETEX

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

99

Secuencia normal de acciones:

1. La Central de Información valida los solicitantes pendientes de evaluación y que tienen confirmado el pago del estudio de deudor solidario. (Ver Nota 3)

2. La Central de información realiza la evaluación del deudor solidario teniendo en cuenta el scoring de la modalidad de crédito o fondo donde se encuentra inscrito el solicitante.

3. La Central de información actualiza el estado de cada deudor solidario en la base de datos

4. La Central de Información envía el resultado del estudio del deudor con las variables requeridas por el ICETEX.

5. El sistema valida que el deudor solidario no cumpla este rol en más de un crédito.

6. El sistema carga el resultado de la evaluación de la solicitud en cada formulario y envía un correo electrónico a cada solicitante con el resultado del estudio de deudor solidario

7. Fin del proceso. 6.

Secuencias alternas 6a. El sistema de solicitudes de crédito no envía correo electrónico a cada solicitante sobre el resultado del estudio de deudor solidario Cuando el correo electrónico esta mal escrito la oficina de seguimiento al crédito contacta al solicitante y le informa el resultado de la evaluación del deudor solidario.

Requerimientos no funcionales

Desempeño ( Rendimiento) El sistema debe controlar que las solicitudes de evaluación de deudor solidario registradas sean canceladas en un tiempo máximo de tres (3) meses. Si se pasan de este tiempo debe ser anuladas El sistema debe cargar los resultados de las solicitudes evaluadas por la central de información diariamente.

Disponibilidad La evaluación del deudor solidario debe quedar disponible en la sesión del usuario hasta el momento de los resultados del comité de evaluación. Adicionalmente debe quedar en el repositorio de deudores solidarios del sistema de crédito y cartera. Si la solicitud de evaluación de deudor solidario pasa de tres (3) meses y el solicitante no ha cancelado la evaluación de ésta se debe anular.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

100

Seguridad El(los) analista(s) de crédito encargados de cargar la información de los deudores solidarios en el repositorio debe(n) tener una clave personal.

Gestionabilidad - Control de procesos El estado inicial de este caso de uso es “en evaluación” y puede quedar en alguno de los siguientes estados: Aprobado o rechazado.

Auditoria Debe existir un repositorio donde se presente la siguiente información:

o Fecha de inscripción o Nombre del (los) deudor(es) solidario(s). o Número de identificación del (los) deudor(es)

solidario(s). o Nombre del solicitante al que se le relaciona el(los)

deudor(es) solidario(s). o Resultado de la evaluación

Notas y comentarios 1. Deudor Solidario Aprobado: Hace referencia a aquel resultado donde la información ingresada por el solicitante cumple con el scoring requerido por la modalidad de crédito o fondo.

2. Deudor Solidario No Aprobado: Hace referencia a aquel

resultado donde la información ingresada por el solicitante no cumple con el scoring requerido por la modalidad de crédito o fondo.

3. El sistema deja pendiente de validación por un máximo de

tres (3) meses aquellas solicitudes que no tienen registrado el pago en el banco, luego de este tiempo son anuladas

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

101

4.11 Consultar estado del estudio del deudor solidario

Código: OTO-SIS- 011

Nombre: Consultar estado del estudio del deudor solidario

Elaborado por: Aprobado por:

Fecha de elaboración:

2007-04-18 Fecha de aprobación:

Objetivo Realizar la consulta sobre el resultado del estudio del deudor solidario por la Central de Información

Descripción El solicitante ingresa al sistema y consulta el resultado del estudio del deudor solidario y el motivo del rechazo si fuera el caso

Actores Principales Solicitante

Realiza la consulta del estado de la solicitud

Actores secundarios Sistema de información de solicitudes de crédito Seguimiento al crédito

Se encarga de cargar los resultados de la evaluación en las bases de datos de crédito y cartera e informar al solicitante de éstos

Precondiciones: Debe existir la solicitud de evaluación del deudor solidario

Poscondiciones Consulta del estado del estudio del deudor solidario

Secuencia normal de acciones:

1. El sistema solicita el ingreso del número de identificación y del pin de seguridad

2. El solicitante ingresa la información. 3. El sistema valida el pin de seguridad. 4. El solicitante escoge la opción “consulta de evaluación del

deudor solidario”. 5. El sistema presenta el resultado de estudio de los deudores

solidarios con las respectivas observaciones(Ver Nota 1) 5. Fin del proceso

Secuencias alternas 3a. El sistema no valida el pin de seguridad. Cuando el solicitante ingresa un pin incorrecto el sistema le hace

las preguntas de seguridad y él tiene tres intentos para contestarlas.

Si las contesta correctamente antes de los tres intentos retoma el flujo normal en el paso cuatro (4).

Si no contesta mal en los tres intentos que tiene el usuario debe comunicarse con el contact center, el cual le solicita información básica y la valida.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

102

o Si la información solicitada por el contact center es validada resetea la clave actual y habilita la opción de cambio de clave.

o En el caso de que la información sea inconsistente el solicitante se debe acercar a las oficinas de atención al usuario con una carta solicitando el cambio de clave y el documento de identificación. En esta oficina se verifican los datos básicos del solicitante (p.e. nombre, número de identificación) ­ Si la información es valida se resetea la clave

actual y habilita la opción de cambio de clave.

­ Si el documento de identificación es incorrecto se le indica al solicitante para realizar los correctivos pertinentes (p.e. actualización de datos)

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación debe presentar el estado de la solicitud de evaluación del deudor solidario en un tiempo de máximo de 2 segundos una vez que el solicitante escoja la opción “consultar estado de solicitud de evaluación del deudor solidario”

Disponibilidad La consulta del estado de la solicitud debe estar disponible para que sea consultada por el usuario hasta que entre al comité de evaluación. y debe presentar el estado en que se encuentra.(aprobado, rechazado, en evaluación).

Seguridad El sistema debe pedir un código de autenticación (pin de seguridad) para que el solicitante pueda realizar esta consulta. El analista de crédito debe contar con una clave personal para poder cargar el resultado de la consulta en la base de datos del sistema de crédito y cartera.

Gestionabilidad – Control del proceso En la consulta de solicitudes no hay cambio de estado.

Auditoria

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

103

Debe existir un histórico que presente las consultas realizadas con fecha y quien la realizó.

Notas y comentarios 1. El solicitante puede ingresar la información para estudio de varios deudores solidarios y obtener el resultado de aquellos a los cuales les realizo el pago ante el banco.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

104

4.12 Imprimir Formulario del Deudor Solidario aprobado para la legalización del crédito

Código: OTO-SIS- 012

Nombre: Imprimir formulario del deudor solidario

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-04-18 Fecha de aprobación:

Objetivo Imprimir el formulario del deudor solidario siempre y cuando este se encuentre aprobado para el proceso de legalización

Descripción El solicitante ingresa el número de identificación y el número de registro e imprime el formulario del deudor solidario aprobado para la legalización del crédito.

Actores Principales Solicitante del crédito

Es el encargado de imprimir el formulario

Actores secundarios Sistema de información de solicitudes de crédito

Presenta la información del formulario del deudor solidario. Además debe tener un control de este proceso.

Precondiciones: El resultado del estudio del deudor solidario debe encontrarse en estado aprobado

Poscondiciones Obtener el formulario del deudor solidario impreso

Secuencia normal de acciones:

1. El sistema solicita el número de identificación y el pin de seguridad.

2. El solicitante ingresa la información requerida 3. El sistema valida la información 4. El solicitante escoge la opción de impresión de formulario del

deudor solidario aceptado 5. El sistema presenta el reporte del formulario del deudor

solidario 6. El solicitante imprime el formulario del deudor solidario

aprobado. 7. Fin del proceso

Secuencias alternas 1a. El sistema no valida el pin de seguridad Cuando el solicitante ingresa un pin incorrecto el sistema le hace

las preguntas de seguridad y él tiene tres intentos para contestarlas.

Si las contesta correctamente antes de los tres intentos retoma el flujo normal en el paso cuatro (4).

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

105

Si no contesta mal en los tres intentos que tiene el usuario debe comunicarse con el contact center, el cual le solicita información básica y la valida. o Si la información solicitada por el contact center

es validada resetea la clave actual y habilita la opción de cambio de clave.

o En el caso de que la información sea inconsistente el solicitante se debe acercar a las oficinas de atención al usuario con una carta solicitando el cambio de clave y el documento de identificación. En esta oficina se verifican los datos básicos del solicitante (p.e. nombre, número de identificación) ­ Si la información es valida se resetea la clave

actual y habilita la opción de cambio de clave.

­ Si el documento de identificación es incorrecto se le indica al solicitante para realizar los correctivos pertinentes (p.e. actualización de datos)

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación debe presentar el reporte del formulario del deudor solidario en un tiempo de máximo de 2 segundos una vez que el solicitante escoja la opción “consultar estado de solicitud de evaluación del deudor solidario”

Disponibilidad La opción de impresión del formulario de la solicitud del deudor solidario debe estar disponible cuando el resultado haya sido aprobado y hasta la legalización del crédito.

Seguridad El sistema debe pedir un código de autenticación (pin de seguridad) para que el solicitante pueda imprimir el formulario.

Gestionabilidad – Control del proceso En la impresión del formulario no hay cambio de estado.

Auditoria Debe existir un histórico que presente la siguiente

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

106

información: o Fecha de impresión o Actor que realizo la impresión

.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

107

4.13 Validar la información del formulario de solicitud

Código: OTO-SIS- 013

Nombre: Validar la información del formulario de solicitud

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-04-18 Fecha de aprobación:

Objetivo Verificar la información de los formularios de solicitud de crédito con las entidades externas.

Descripción El analista de crédito y/o el analista de fondos realiza el proceso de verificación de la información diligenciada en los formularios de solicitud con las entidades externas. Este proceso de revisión se realiza través de las interfaces y se debería ejecutar diariamente.

Actores Principales Analista de crédito Es el encargado de revisarla información de las solicitudes de crédito con la información de las entidades externas en las modalidades de crédito.

Analista de fondos Es el encargado de revisarla información de las solicitudes de crédito con la información de las entidades externas en los fondos.

Interfaz con el DNP

Sirve para validar el estrato de SISBEN en las modalidades de crédito y/o fondos donde es evaluable.

Interfaz con el ICFES

Se encarga de verificar la información de la solicitud relacionada con el puntaje del examen de estado y el puesto ocupado en este.

Interfaz con las centrales de información

Es la encargada de dar el resultado de la evaluación del deudor solidario.

Interfaz con el DANE

Sirve para confirmar información de la división política administrativa de Colombia en las modalidades de crédito y/o fondos donde esta sea un criterio de evaluación.

Ministerio del Interior

Brinda información evaluable en los fondos de afrocolombianos e indígenas

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

108

Ministerio de Protección Social

Brinda información relacionada con la base de datos de hospitales y los puntajes de calificación del criterio del rural por ciudades).

ACH

Actores secundarios

Precondiciones: La solicitud de crédito debe estar completamente diligenciada y autorizada para ser evaluada.

Poscondiciones Definir cuales son las solicitudes susceptibles de evaluación en el comité de crédito.

Solicitar modificación de información en las solicitudes que se encontraron inconsistentes.

Secuencia normal de acciones:

1. El analista entra al sistema y escoge la opción de “validar la información de las solicitudes de crédito.

2. El sistema presenta la opción de seleccionar la modalidad de crédito o fondo (ver nota 1)

3. El analista de crédito y/o el analista de fondos escoge la modalidad de crédito y/o fondo en la que desea verificar la información de la solicitud de crédito.

4. El sistema valida la información ingresada por el solicitante con las entidades externas.

5. El sistema genera el listado de solicitudes susceptibles a evaluación del comité de crédito.

6. Fin del proceso.

Secuencias alternas 5a. El sistema no genera el listado de solicitudes susceptibles a evaluación del comité de crédito

Cuando hay inconsistencia en la información el sistema envia un mensaje a la sesión del usuario para que realice las modificaciones pertinentes (la solicitud queda en un estado de “aplazado”. Una vez se realicen estas modificaciones empieza el flujo normal.

Cuando la información no se encuentra, el sistema envía un mensaje a la sesión del solicitante para que realice su modificación.

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación debe correr el proceso diariamente. Cuando existan inconsistencias en la información el sistema debe generar automáticamente un mensaje para la sesión del usuario donde se solicite la corrección de estos datos.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

109

Disponibilidad La validación de información debe estar disponible para los analistas de crédito y/o analista de fondos encargados de realizar este proceso. Se debe tener acceso a este hast antes de iniciar el proceso de realizar el comité de evaluación.

Seguridad El sistema debe pedir un código de autenticación a los analistas de crédito y/o analista de fondos encargados de la validación de la información. Este código debe ser unico y sólo lo debe conocer el usuario autorizado.

Gestionabilidad – Control del proceso Este proceso inicia cuando la solicitud esta totalmente diligenciada y al finalizar el proceso puede quedar en alguno de los siguientes estados: Solicitud aplazada (ver nota 2) o solicitud en comité de crédito.

Auditoria Debe existir un histórico que presente la siguiente información: o Fecha de validación de la información. o Resultado de la validación de la información o Actor que realizo el proceso.

Notas y comentarios 1. El sistema debe presentarle a cada analista únicamente el listado de modalidades de crédito y/o fondos a los cuales tiene acceso para la evaluación.

2. Aplazadas: Son aquellas solicitudes que cuentan con información inconsistente o que no tienen la información completa (p.e. el resultado de la evaluación del deudor solidario no ha salido o no fue aprobada).

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

110

4.14 Realizar la matrícula de cuentas

Código: OTO-SIS- 014

Nombre: Realizar la matrícula de cuentas

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-06-01 Fecha de aprobación:

Objetivo Verificar la información de las cuentas bancarias a donde se debe realizar el desembolso.

Descripción El sistema debe validar la información de la cuenta bancaria a través de la interfaz con ACH Este proceso se debe realizar diariamente y se hace por lotes.

Actores Principales Solicitante del Crédito

Es el encargado de ingresar la información de la cuenta bancaria al sistema de información

ACH.

Es el encargado de validar que el número de cuenta exista, que coincida con el nombre del beneficiario y que este activa.

Sistema de crédito Es la encargada de cargar la información de cuentas bancarias al sistema financiero para su validación

Sistema financiero Es el encargado de enviar la información para que sea validada

Actores secundarios

Precondiciones: Solicitud de crédito aprobada.

Poscondiciones Cuenta aprobada (ver nota 1)

Cuenta rechazada (ver nota 2)

Cuenta por verificar (ver nota 3)

Secuencia normal de acciones:

1. El sistema trae la información bancaria del formulario de solicitud de crédito.

2. El sistema de crédito envía la información al sistema financiero del ICETEX. Pendiente de confirmación con HEINSOHN

3. El área de tesorería crea un archivo por entidad bancaria para su validación

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

111

4. El banco valida la información y envía el resultado de la consulta al sistema financiero del ICETEX (aprobado o rechazado).

5. El funcionario de tesorería carga la información y se la envía al sistema de crédito

6. El funcionario de crédito carga estos resultados en su base de datos.

7. Fin del Proceso.

Secuencias alternas 5a. La cuenta fue rechazada Atención al usuario contacta al beneficiario y le informa los motivos del rechazo y empieza el flujo normal.

Requerimientos no funcionales

Desempeño ( Rendimiento) El sistema de crédito debe enviar la información de cuentas bancarias a consultar diariamente. La aplicación debe guardar el resultado de la consulta automáticamente es enviado por el sistema financiero.

Disponibilidad La actividad de diligenciamiento de información bancaria debe quedar abierta para realizar en cualquier momento del crédito.

El resultado del proceso de matricula de cuentas debe estar disponible en la base de datos del sistema de crédito para su consulta

Seguridad El sistema debe solicitarle el código de autenticación al beneficiario para diligenciar la información bancaria. Debe ser único y sólo lo debe conocer él.

El sistema debe solicitarle al funcionario de crédito un código de autenticación para subir la información.

Gestionabilidad - Control de procesos El proceso de matricula de cuentas puede quedar e alguno de los siguientes estados: Cuenta aprobada o cuenta rechazada

Auditoria Debe existir un control del diligenciamiento de la información y de los cambios realizados en el historial bancario donde se presente:

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

112

Fecha de diligenciamiento

Actor que lo realizo

Resultado de la consulta en ACH

Cambio realizado

Fecha en que se realizo el cambio

Actor que realizo el cambio.

Notas y comentarios 1. Una cuenta aprobada hace referencia a aquella validación de datos que fue consistente en toda la información.

2. Una cuenta no aprobada se puede dar porque:

Esta inactiva

El número de cuenta no coincide con el titular

El número de cuenta no existe 3. Una cuenta por es la que no ha tenido el resultado de la

validación de información por parte del ACH.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

113

4.15 Generar las evaluaciones de las solicitudes

Código: OTO-SIS- 015

Nombre: Generar las evaluaciones de las solicitudes

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-06-14 Fecha de aprobación:

Objetivo Realizar la evaluación de las solicitudes susceptibles de aprobación.

Descripción El analista de crédito y/o el analista de fondos verifica que la modalidad de crédito o fondo tenga actualizado los criterios de calificación y su respectiva puntuación, el sistema evalúa los criterios de calificación de acuerdo a los puntajes establecidos y a la disponibilidad presupuestal y genera los resultados del comité.

Actores Principales Analista de crédito Se encarga de realizar la calificación de las solicitudes autorizadas para evaluación

Analista de fondos Se encarga de realizar la calificación de las solicitudes autorizadas para evaluación

Actores secundarios Interfaz con el modelo financiero

Es la encargada de brindar información con respecto al certificado de disponibilidad presupuestal (CDP) de las modalidades de crédito y/o fondos.

Precondiciones: Los criterios de evaluación de la modalidad de crédito y/o fondo a evaluar deben estar parametrizados y actualizados.

La solicitud debe ser susceptible a aprobación.

Debe existir certificado de disponibilidad presupuestal en la modalidad de crédito y/o fondo donde se va a realizar la evaluación de solicitudes.

Poscondiciones Solicitud evaluada

Secuencia normal de acciones:

1. El analista de crédito o el analista de fondos entra al sistema y escoge la opción de evaluar solicitudes de crédito.

2. El sistema presenta la opción de seleccionar la modalidad de crédito o fondo (ver nota 3)

3. El analista de crédito o el analista de fondos selecciona la modalidad de crédito y/o fondo

4. El sistema presenta los rangos de fechas de las solicitudes de

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

114

crédito a evaluar 5. El analista de crédito o el analista de fondos escoge el rango

de fechas en que se va a evaluar. 6. El analista de crédito o el analista de fondos solicita la

información de disponibilidad presupuestal.(ver nota 4) 7. El sistema financiero del ICETEX envia la información

presupuestal de la modalidad de crédito y/o fondo consultado (número de CDP y su saldo).

8. El analista de crédito o el analista de fondos cruza la información consultada en el sistema financiero y realiza una distribución preliminar de recursos.

9. El sistema califica cada solicitud con base en los criterios de evaluación y la disponibilidad presupuestal y les pre-asigna a cada solicitud un estado (A las aprobadas les asigna un número de estudio de crédito) (Ver Nota 5)

10. El sistema genera un reporte que se presentará al comité de crédito.

11. Fin del proceso

Secuencias alternas 6a. El sistema no valida la información ingresada por el solicitante con la central de información.

Si el deudor solidario no se encuentra aprobado o no hay respuesta por parte de las centrales de riesgo la solicitud queda aplazada y se le debe enviar un mensaje a la sesión del usuario del estado de la solicitud.

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación debe correr este proceso con la periodicidad establecida por cada modalidad de crédito y /o fondo para la evaluación de solicitudes (en este momento se realiza semanalmente). Una vez se tiene los resultados del comité de crédito, el software debe cargar automáticamente la información en la sesión de cada usuario y en el repositorio de solicitudes evaluadas.

Disponibilidad El proceso de evaluación debe estar habilitado en las fechas establecidas por cada modalidad de crédito y/o fondo para la evaluación de solicitudes La aplicación debe generar el informe de resultados del comité de crédito una vez se tenga los resultados de la evaluación.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

115

Seguridad

El sistema debe pedir un código de autenticación a los analistas de crédito y/o analista de fondos encargados de la evaluación de las solicitudes. Este código debe ser único y sólo lo debe conocer el usuario autorizado.

Gestionabilidad – Control del proceso Este proceso inicia cuando la solicitud esta totalmente diligenciada y al finalizar el proceso que da en estado de “evaluada para ser presentada en comité. En esta caso la solicitud puede ser: aprobada, no aprobada, elegible o anulada.

Auditoria Debe existir un histórico que presente la siguiente información: o Fecha de evaluación de la solicitud de crédito. o Resultado de la evaluación. o Actor que realizo el proceso.

Notas y comentarios 1. Criterios de calificación: Son los requisitos establecidos y parametrizados en cada modalidad de crédito o fondo para la evaluación de la solicitud (pe.. Tipo de universidad, Estrato socioeconómico, Nivel de SISBEN).

2. El deudor solidario no es requerido en todas las modalidades

de crédito y/o fondos para la evaluación de la solicitud (pe. Fondo Secretaria de Educación del Distrito). En los fondos cerrados los gestores de los fondos realizan este proceso.

3. El sistema debe presentarle a cada analista únicamente el

listado de modalidades de crédito y/o fondos a los cuales tiene acceso para la evaluación.

4. El sistema de crédito y cartera solicita al sistema financiero el

número de CDP de la modalidad de crédito y/o fondo a afectar en la evaluación de solicitudes y el valor disponible. En el casos de fondos enviamos al sistema financiero el NIT del constituyente y el código del fondo y este nos debe devolver el saldo que tiene el fondo para poder saber con qué se cuenta para realizar elestudio de crédito (no hay

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

116

constitución de CDP).

5. Los estados que se pueden presentar son:

1. Aprobadas. En este caso el crédito pasa a ser legalizado 2. No aprobadas:

Por mérito académico,

Por disponibilidad presupuestal: en este caso se puede presentar la posibilidad de anular la solicitud o aplazarla.

Por no cumplir con alguno de los requisitos evaluables definidos en la parametrización de cada modalidad de crédito y/o fondo.

En este caso el proceso se da también por finalizado.

3. Elegible: Hace referencia a aquellas personas que cumplen con los requisitos evaluables pero por disponibilidad presupuestal no se les puede dar crédito. Por lo tanto quedan como opcionadas en el caso de que los aprobados no legalicen los créditos o desistan de ellos. Se puede dar para modalidades de crédito y/o fondos.

Las solicitudes aplazadas se diferencian de las elegibles en que las primeras tienen información inconsistente o no llego el resultado de la evaluación del deudor solidario. En el caso de las elegibles son aquellas solicitudes completas que cumplen con los requisitos pero por disponibilidad presupuestal no pudieron ser aprobadas).

4. Anuladas:

o Por vencimiento de términos. o Por solicitud del Beneficiario del crédito o Por inconsistencias en los datos (falsedad en

información cuando se realiza validación de datos) en especial cuando son datos evaluables.

En el caso de anulación de solicitudes el proceso se da por finalizado

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

117

4.16 Actualizar el estado de las solicitudes de crédito en el comité

Código: OTO-SYS- 016

Nombre: Actualizar el estado de las solicitudes de crédito en el comité

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-07-11 Fecha de aprobación:

Objetivo Realizar la marcación de los créditos aprobados, no aprobados, elegibles y anulados en el comité de crédito.

Descripción El comité de crédito define la evaluación definitiva de las solicitudes de crédito y actualiza el estado de éstas en el sistema. Adicionalmente se genera un acta de comité donde se presenta el listado de las solicitudes evaluadas con sus respectivas observaciones.

Actores Principales Comité de crédito Se encarga de cargar los resultados definitivos de las solicitudes evaluadas en el sistema de crédito y cartera.

Actores secundarios Beneficiario Consulta el estado de la solicitud.

Seguimiento al crédito Realiza la validación de la información del formulario para que la solicitud siga con el proceso de legalización.

Atención al usuario Brinda información al beneficiario sobre el estado de la solicitud

IES Consulta el listado de créditos adjudicados susceptibles a legalización.

Precondiciones: La solicitud debe encontrase evaluada

Poscondiciones Solicitud aprobada Solicitud no aprobada Solicitud elegible

Solicitud anulada

Secuencia normal de acciones:

1. El comité de crédito revisa el reporte generado de las evaluaciones de las solicitudes de crédito, revisa la disponibilidad presupuestal de la modalidad de crédito

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

118

evaluada y aprueba definitivamente los resultados generados de la evaluación.

2. El funcionario del comité de crédito encargado del cargue de los resultados del comité de crédito entra al sistema de crédito y cartera

3. El sistema le solicita el pin de seguridad 4. El funcionario diligencia la información solicitada 5. El sistema valida la información 6. El funcionario escoge la opción “cargue de resultados de

comité de crédito” 7. El sistema le presenta las modalidades de crédito en las que

puede realizar este cargue 8. El funcionario escoge la modalidad 9. El sistema presenta el listado de solicitudes evaluadas 10. El funcionario actualiza el estado de las solicitudes evaluadas

(Ver Nota 1) 11. El sistema carga la información. 12. Fin del proceso

Secuencias alternas 1a. Definir solicitudes de crédito a aprobar cuando existe un empate en el último puesto.

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación debe generar un mensaje de confirmación del cargue de los resultados definitivos del comité.

Disponibilidad Los resultados definitivos deben quedar en el repositorio del sistema de crédito y cartera.

Seguridad El sistema debe pedir un código de autenticación al funcionario del comité de crédito encargado del cargue de la información. Este código debe ser único y sólo lo debe conocer el usuario autorizado.

Gestionabilidad – Control del proceso Entra en un estado de “evaluada” y puede finalizar en alguno de los siguientes estados: aprobado, no aprobado, elegible o anulada

Auditoria Debe existir un histórico que presente la siguiente información:

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

119

o Fecha del comité o Acta de comité. o Resultados del comité (listado de solicitudes con su

respectivo estado) o Actor que realizo el cargue de los estados

Notas y comentarios 1. En el caso de los fondos cerrados los gestores realizan la calificación y aprobación de las solicitudes.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

120

4.17 Verificar la información de las solicitudes aprobadas

Código: OTO-SYS- 017

Nombre: Verificar la información de las solicitudes aprobadas

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-07- 11 Fecha de aprobación:

Objetivo Realizar la validación de la información de las solicitudes de crédito aprobadas en el comité de crédito.

Descripción Seguimiento al crédito realiza la verificación de la información registrada por el solicitante en el formulario con el fin de confirmar la veracidad de ésta. En el caso de los gestores de fondos estos realizan el seguimiento a los créditos para la legalización

Actores Principales Seguimiento al crédito

Se encarga de contactar al beneficiario, al deudor y a las referencias para confirmar los datos diligenciados en la solicitud de crédito.

Actores secundarios

Precondiciones: El crédito debe encontrarse aprobado por el comité.

Poscondiciones Información del solicitante confirmada y lista para la legalización.

Crédito anulado

Crédito desistido

Secuencia normal de acciones:

1. El funcionario de seguimiento al crédito ingresa a la opción de consulta de formularios

2. El sistema presenta las solicitudes aprobadas pendientes de verificación de información.

3. El funcionario de seguimiento al crédito escoge el crédito al cual le va a hacer la verificación de datos.

4. El sistema presenta una pantalla con la información del solicitante, deudores solidarios y referencias y una opción para verificar la información del formulario.

5. El funcionario de seguimiento contacta al beneficiario, al deudor y a las referencias para verificar la información

6. El funcionario de seguimiento al crédito le informa al solicitante los pasos a seguir para la legalización.

7. Fin del proceso

Secuencias alternas 5a. Los datos del formulario verificados son inconsistentes

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

121

Si no afectan los criterios de evaluación de la solicitud el funcionario de seguimiento al crédito realiza las correcciones pertinentes y continúa en el paso seis (6) del flujo normal.

Si modifica los criterios de evaluación se registra estado de anulado y se termina el proceso.

5b. El solicitante desiste del crédito

Fin del proceso

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación debe generar un informe con los créditos aprobados a los que se les realizo la verificación de datos. El sistema una vez se haya verificado la información de los créditos aprobados debe enviar un mensaje a la sesión de los beneficiaros con los pasos a seguir para la legalización.

Disponibilidad La información verificada debe quedar en el repositorio del sistema de crédito y cartera.

Seguridad El sistema debe pedir un código de autenticación al funcionario de seguimiento al crédito para poder realizar la verificación de información. Este código debe ser único y sólo lo debe conocer el usuario autorizado.

Gestionabilidad – Control del proceso En este proceso no hay cambio de estado

Auditoria Debe existir un histórico que presente la siguiente información: o Fecha de verificación de información o Observaciones realizadas en la verificación de datos. o Actor que realizo el proceso. o Estado en el que quedo el crédito.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

122

4.18 Publicación y consulta de los resultados del comité

Código: OTO-SIS-018

Nombre: Publicación y consulta de los resultados del comité

Elaborado por: Olga Alejandra Pantoja R

Aprobado por:

Fecha de elaboración:

2007-04-18 Fecha de aprobación:

Objetivo Publicar los resultados de la evaluación de las solicitudes de crédito.

Descripción El profesional del área de tecnología encargado habilita el sistema para que el solicitante pueda consultar el resultado de la solicitud de crédito.

Actores Principales Profesional del área de tecnología

Es el encargado de subir la información del comité en la página web y en la sesión de cada usuario. Además habilita la opción de consulta en la sesión de cada usuario.

Actores secundarios

Precondiciones: La Solicitud debe tener el resultado del comité de crédito (estados con su respectivo comentario).

Poscondiciones El solicitante obtiene información acerca del resultado de la solicitud.

Secuencia normal de acciones:

1. El profesional del área de tecnología activa la consulta de resultados de estudio del crédito (Ver Nota1).

2. El sistema solicita el de PIN de seguridad y el numero de identificación del solicitante.

3. El solicitante ingresa la información. 4. El sistema presenta el resultado del estudio de la solicitud 5. El sistema presenta el instructivo para la legalización de (Ver

Nota 2) 6. El solicitante imprime la información 7. Fin del proceso

Secuencias alternas 4a. Cuando el crédito no es aprobado

El sistema no debe mostrar información para legalización del crédito

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación debe presentar el resultado del comité de

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

123

crédito en máximo dos segundos después de que el usuario entra a la opción de consulta de resultados.

Disponibilidad Esta información debe estar disponible en un repositorio donde se guarden las consultas realizadas.

Seguridad El sistema debe pedir un código de autenticación a los analistas de crédito y/o analista de fondos y al solicitante para la publicación y consulta de resultados del comité de crédito. Este código debe ser único y sólo lo debe conocer el usuario autorizado.

Gestionabilidad – Control del proceso En este proceso no hay cambio de estado

Auditoria Debe existir un histórico que presente la siguiente información: o Fecha de publicación de resultados o Actor que realizo el proceso. o Fecha de consulta de resultados o Actor que realizo la consulta.

Notas y comentarios 1. En el caso de los fondos cerrados los gestores informan a los beneficiaros el resultado del estudio del crédito e informan a los beneficiarios acerca de los pasos a seguir para la legalización del crédito.

2. Los documentos requeridos para legalizar pueden variar según la modalidad de crédito o fondo.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

124

4.19 Legalizar créditos aprobados

Código: OTO-SIS-019

Nombre: Legalizar créditos aprobados

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-04-18 Fecha de aprobación:

Objetivo Recibir de los beneficiarios la documentación solicitada por la modalidad de crédito o fondo, para que los terceros puedan legalizar el crédito

Descripción El solicitante entrega los documentos solicitados por la modalidad de crédito o fondo a la IES y/o a los terceros para que este revise la documentación entregada y legalice el crédito del solicitante. Para esto la IES tendrá un Check List de los documentos a verificar. *En el caso de los créditos del exterior la legalización es realizada por el ICETEX.

Actores Principales Solicitante aprobado

Es el encargado de entregar los documentos soporte en la IES y/o en el fondo para la revisión y legitimación del crédito

Terceros

Es el encargado de revisar los documentos soporte de las solicitudes aprobadas en las diferentes modalidades de crédito y validarla para la generación de la resolución de giro. Puede ser la IES, el ICETEX o el gestor del fondo.

Actores secundarios Sistema de Información

Registra la legalización de los créditos aprobados en el aplicativo de crédito para su giro

Precondiciones: La solicitud debe encontrarse aprobada por el comité de crédito.

El crédito debe contar con un número de crédito

El crédito debe tener el número del certificado de disponibilidad presupuestal (CDP).

Poscondiciones Crédito legalizado y listo para el desembolso por parte del

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

125

ICETEX

Secuencia normal de acciones:

1. El tercero ingresa al sistema y escoge la opción de “legalizar créditos”

2. El sistema presenta las opciones de filtro para realizar la consulta de solicitudes pendientes de legalización

3. El tercero ingresa la información del filtro seleccionado 4. El sistema presenta el listado de créditos pendientes de

legalizar según el filtro escogido 5. El tercero escoge el crédito a legalizar 6. El sistema presenta el check list de los documentos

solicitados, el número de crédito y el número de certificado de disponibilidad presupuestal. (Ver Nota 1)

7. El tercero imprime el pagare y carta de instrucciones y se las entrega al solicitante para su diligenciamiento (Ver Nota 2)

8. El solicitante aprobado diligencia el pagare y carta de instrucciones y lo entrega a la IES y/o al tercero.

9. El tercero verifica y marca en el listado los documentos entregados por el solicitante aprobado.

10. El tercero visa la entrega del pagare y carta de instrucciones e ingresa el valor real de la matricula y el valore solicitado del solicitante aprobado. (Ver Nota 3)

11. El sistema de legalización envía la información solicitada para el soporte presupuestal y para el registro presupuestal al sistema financiero del ICETEX (Ver nota 4)

12. El sistema guarda el Log de Auditoria del usuario que realizo la legalización del crédito

13. Fin del Proceso.

Secuencias alternas 10a. LA IES no visa el Pagaré y la Carta de Instrucciones porque están mal diligenciados

La IES imprime nuevamente el pagare y carta de instrucciones para que el solicitante realice de nuevo su diligenciamiento. El sistema guarda en log de auditoria el usuario que realizo la segunda impresión.

10b. La IES no legaliza el crédito porque el solicitante no entrega la documentación completa

Si el solicitante no entrega la documentación completa la IES puede marcar los documentos entregados y dejar sin marcar los que se encuentren pendientes y genera soporte de los documentos entregados y pendientes de entregar. Una vez este marcado los documentos obligatorios podrá continuar

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

126

con el proceso de legalización.

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación debe guardar la información de la legalización máximo en 2 segundos después de que la IES y/o el tercero da la opción de legalizar el crédito.

Disponibilidad Esta información debe estar disponible para los funcionarios del ICETEX que realizan el proceso de visado, para las IES y en la sesiones de los beneficiarios. Además esta información debe estar en un repositorio para próximas consultas.

Seguridad El sistema debe pedir un código de autenticación a las IES y/o terceros para la legalización del crédito. Este código debe ser único y sólo lo debe conocer el usuario autorizado.

Gestionabilidad – Control del proceso En este proceso las solicitudes entran en un estado de aprobado y al finalizar pueden quedar en los siguientes estados: legalizado pendiente de legalizar o no legalizado.

Auditoria Debe existir un histórico que presente la siguiente información: o Fecha de legalización del crédito o Listado de documentos entregados por el ICETEX o Número del crédito o Estado del crédito (legalizado, pendiente de legalización,

no legalizado) o Actor que realizo el proceso.

Notas y comentarios 1. El check list de documento a entregar puede variar según la modalidad de crédito o fondo. La información básica que se verifica con los documentos soporte es:

Número de identificación del beneficiario

Nombre del beneficiario

Ciudad

Dirección

Teléfono

E-mail

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

127

Universidad

Modalidad de crédito o fondo

Valor Matricula

Periodo o Semestre a cursar

Total de periodos o semestres

Código SNP

Periodicidad

Destino del Giro (Matricula, Sostenimiento, Derechos de Grado, Textos, Transportes, Computadores, Capacitación, Tesis, entre otros)

2. El pagare y la carta de instrucciones son formatos estándar

que aplican de acuerdo al reglamento operativo de las modalidades de crédito o fondo pero que pueden variar su contenido según cambien las políticas de crédito en la Institución, por lo tanto deben ser parametrizables. Estos deben identificar a que modalidad de crédito o fondo pertenece para diferenciarlos. Se puede imprimir varias veces. No necesariamente se imprime después de que el estudiante entrega documentos

3. El ingreso del valor de la matricula por la IES debe estar

controlada en el sistema según los topes aprobados por cada modalidad de crédito o fondo.

4. La información que debe entregar el sistema de crédito es el

NIT de la Universidad, la modalidad de crédito y/o fondo, el número de CDP, el valor total de las matriculas y el valor de la garantías (debe ser consolidado por IES). Cuando se realiza el envío de esta información el sistema financiero debe enviar un mensaje de confirmación.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

128

4.20 Revisar la garantía del crédito: carta y pagare y confirmación de valores:

Código: OTO-SIS-020

Nombre: Revisar la garantía del crédito: carta de instrucciones y pagare y confirmación de valores

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-06-08 Fecha de aprobación:

Objetivo Revisar la validez jurídica del pagaré y la carta de instrucciones de los créditos.

Descripción Gestión documental debe revisar la autenticidad y el correcto diligenciamiento de las garantías de los créditos una vez que son enviadas por las IES o terceros para la constitución del historial del crédito. Adicionalmente debe digitalizar la garantía para que quede en el repositorio para consulta de los beneficiarios de crédito y cartera. El tiempo que se puede tomar gestión documental para el visado puede ser máximo quince (15) días

Actores Principales Gestión documental Es la encargada de revisar y validar la información de la carta de instrucciones y del pagaré.

Actores secundarios

Precondiciones: La solicitud de crédito debe estar legalizada.

La IES y/o el tercero debe haber entregado la carta de instrucciones y el pagaré al beneficiario

Poscondiciones Constitución de garantías

Crédito listo para la generación de la resolución.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

129

Secuencia normal de acciones:

1. Gestión documental entra al sistema al a opción de constituir garantías

2. El sistema presenta las modalidades y/o fondos susceptibles a constitución de garantías.

3. Gestión documental escoge la modalidad de crédito y/o fondo en la que se va a constituir garantías.

4. El sistema despliega los créditos pendientes de constitución de garantías.

5. Gestión documental escoge el crédito. 6. El sistema despliega la información del crédito 7. Gestión documental revisa la información y valida la

constitución de garantías 8. El sistema graba la información y carga el pagaré y la carta

de instrucciones en el historial del crédito y en la base de datos del sistema de crédito y cartera (acá se realiza la digitalización de la garantía).

9. Gestión documental coloca el check de la revisión de la garantía

10. Fin del Proceso.

Secuencias alternas 7a. Gestión documental no valida la constitución de garantías

Si el valor de algún rubro o las firmas son inconsistentes gestión documental no constituye la garantía y le informa al área de seguimiento al crédito para que realice la verificación correspondiente.

Requerimientos no funcionales

Desempeño ( Rendimiento) El sistema debe cargar diariamente el archivo de constitución de garantías en la base de datos del sistema de crédito y cartera y en el historial de cada crédito. Una vez cargada esta información debe enviar un mensaje de confirmación a la sesión de los beneficiarios y de los terceros

Disponibilidad La garantía debe quedar disponible de forma digital en el historial de crédito y en un repositorio para los funcionarios de crédito y cartera.

Seguridad El sistema debe solicitar un código de autenticación para que los funcionarios de crédito y cartera la carguen.

Gestionabilidad – Control del proceso En esta parte el proceso finaliza con un estado de “garantía

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

130

revisada y aprobada” o “garantía revisada pero no aprobada”

Auditoria Debe existir un repositorio que cuente con la siguiente información:

o Fecha de constitución de garantías o Actor que realizo la constitución de garantías o Valor de la garantía o Nombre del beneficiario y numero de identificación

Notas y comentarios 1.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

131

4.21 Hacer visado del crédito por parte del ICETEX

Código: OTO-SIS-021

Nombre: Hacer visado del crédito por parte del ICETEX

Elaborado por: Aprobado por:

Fecha de elaboración:

2007-04-18 Fecha de aprobación:

Objetivo Registrar la autorización de giro para los diferentes rubros según la solicitud realizada.

Descripción Se revisan pagare y carta de instrucciones con los requisitos establecidos La oficina de operaciones ingresa los valores correspondientes a giros por sostenimiento y demás rubros si El solicitante los ha solicitado y se han aprobado. La oficina de seguimiento al crédito verifica los valores registrados por terceros y oficina de operaciones y verifica si los valores cumplen con los topes máximos autorizados por la modalidad de crédito o fondo.

Actores Principales Funcionarios de operaciones Revisar y validar la información de la legalización

Seguimiento de crédito Verificar la información del pagaré y de la carta de instrucciones

Actores secundarios

Precondiciones: La solicitud de crédito debe encontrarse legalizada en su totalidad por la IES.

Poscondiciones Crédito visado y listo para que se realice el visado dual

Secuencia normal de acciones:

1. El funcionario de operaciones ingresa a la opción de visar créditos legalizados

2. El sistema presenta en la pantalla la lista de beneficiarios legalizados y pendientes de visar

3. El funcionario de operaciones verifica la información ingresada en la legalización y visa* el crédito (ver Nota 1)

4. Fin del Proceso. *Se puede visar masivamente o individualmente.

Secuencias alternas 3a. Valores incorrectos

Si el valor de algún rubro no corresponde marca como no visado para que la oficina de operaciones realice las correcciones correspondientes y vuelva a quedar pendiente de visar.

Requerimientos no Desempeño ( Rendimiento)

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

132

funcionales El sistema debe cargar diariamente el visado de créditos en la base de datos del sistema de crédito y cartera y en el historial de cada crédito. Una vez cargada esta información debe enviar un mensaje de confirmación.

Disponibilidad Esta información debe estar disponible para los funcionarios del ICETEX que realizan el proceso de generación de resoluciones de giro, para las IES y en la sesiones de los beneficiarios. Además esta información debe estar en un repositorio para próximas consultas.

Seguridad El sistema debe solicitar un código de autenticación para que los funcionarios de operaciones realicen el visado.

Gestionabilidad – Control del proceso En esta parte el proceso entra en un estado de “legalizado” y finaliza con un estado de “visado”.

Auditoria Debe existir un repositorio que cuente con la siguiente información:

o Fecha de visado. o Actor que realizo el visado

Notas y comentarios 1. Para el caso de los fondos cerrados los gestores del fondo visan los créditos y los envían al ICETEX para la realización del giro

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

133

5. RENOVACIÓN DEL CRÉDITO

5.1 Realizar la actualización de datos e impresión del soporte de la renovación

Código: REN-SIS-001

Nombre: Realizar la actualización de datos e impresión del soporte de la renovación

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-04-08 Fecha de aprobación:

Objetivo Realizar la actualización de datos básicos del beneficiario para que el gestor pueda autorizar la renovación del crédito y así poder realizar el desembolso.

Descripción El beneficiario actualiza los datos básicos tanto de él como del deudor(es) solidario(s) e imprime el soporte de la actualización para presentarla al gestor para que estos autoricen la renovación. En este proceso el gestor del fondo debe enviar con anterioridad el listado de beneficiarios susceptibles a renovación. *Aquel crédito que esta en mora de treinta (30) días es susceptible a renovación. **En el momento en que el estudiante actualice datos y grabe esta información el sistema debe estar en la capacidad de decir el estado en que esta el crédito con su respectiva observación (p.e. bloqueo por mora en obligaciones, listo para renovación )

Actores Principales Beneficiario del crédito

Es el encargado de actualizar la información

Gestor del fondo Es el encargado de enviar la información de los beneficiarios a renovar

Analista de fondo Realiza la actualización de datos una vez llega la información de los gestores del fondo

Actores secundarios Sistema de información de renovación

Utiliza esta información para generar las resoluciones de giro.

Precondiciones: El formulario debe encontrarse activo para la actualización de

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

134

datos y dentro del rango de fechas del calendario.

El beneficiario se debe encontrar en época de estudios

El crédito no debe estar bloqueado por ningún motivo.

Resultados Datos actualizados por parte del beneficiario

Crédito listo para que la IES y/o fondo pueda autorizar un nuevo desembolso.

Secuencia normal de acciones:

1. El sistema solicita pin de seguridad y número de identificación (ver nota 1)

2. El sistema valida pin de seguridad 3. El sistema carga la información existente 4. El beneficiario realiza las modificaciones pertinentes y guarda 5. El sistema verifica que toda la información obligatoria haya

sido subida y la carga. 6. El sistema presenta las posibles operaciones que puede

realizar el beneficiario una vez que se actualizo el crédito.(ver nota 2).

7. El beneficiario escoge la opción de renovación del crédito 8. El sistema carga la renovación del crédito 9. El beneficiario imprime el soporte de la renovación 10. Fin del Proceso

Secuencias alternas 2a. El sistema no valida el pin de seguridad

Cuando el solicitante ingresa un pin incorrecto el sistema le hace las preguntas de seguridad y él tiene tres intentos para contestarlas.

Si las contesta correctamente antes de los tres intentos retoma el flujo normal en el paso tres (3).

Si no contesta mal en los tres intentos que tiene el usuario debe comunicarse con el contact center, el cual le solicita información básica y la valida.

Si la información solicitada por el contact center es validada resetea la clave actual y habilita la opción de cambio de clave.

En el caso de que la información sea inconsistente el solicitante se debe acercar a las oficinas de atención al usuario con una carta solicitando el cambio de clave y el documento de identificación. En esta oficina se verifican los datos básicos del solicitante (p.e. nombre, número de identificación)

Si la información es valida se resetea la clave actual y habilita la opción de cambio de clave.

Si el documento de identificación es incorrecto se le indica al

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

135

solicitante para realizar los correctivos pertinentes (p.e. actualización de datos).

5a. El beneficiario no puede verificar la información

El sistema presenta el mensaje que los campos obligatorios deben ser cargados en su totalidad y lo regresa al paso cuatro (4) del flujo normal.

Requerimientos no funcionales

Desempeño ( Rendimiento) El aplicativo debe guardar los cambios realizados en los datos y en la solicitud de renovación por el beneficiario máximo en dos (2) segundos. El sistema debe controlar que la información diligenciada por el beneficiario cuente con los caracteres definidos en la parametrización de la modalidad del crédito y del fondo (p.e. el número de identificación si es tarjeta de identidad debe contar con 11 digitos)

Disponibilidad La actualización de datos debe estar disponible y abierta en la sesión de cada beneficiario durante el tiempo de duración del crédito. Además debe reposar en un repositorio de datos de los créditos donde se guarde el historial de cambios realizados.

Seguridad El sistema de solicitar un código de autenticación (pin de seguridad) para que el beneficiario y/o analisata de fondos pueda realizar la actualización de datos y la solicitud de renovación.

Gestionabilidad – Control del proceso Una vez realizado el proceso, los créditos quedaran actualizados los datos para la renovación del crédito.

Auditoria Debe existir un repositorio donde se presente la siguiente información: o Fecha de actualización de datos o Datos actualizados o Opción escogida (Aplazamiento, renovación. Solicitud de

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

136

condonación) o Actor que realizo el cambio.

Notas y comentarios 1 Este caso de uso no aplica para los fondos cerrados pues ellos realizan este proceso directamente en el fondo.

2 Las posibles opciones que se pueden presentar una vez se

actualicen los datos son: o Aplazamiento o Renovación. o Solicitud de condonación.

* El estudiante debería poder realizar actualización de datos en cualquier momento del crédito con el fin de conocer los datos de ubicación.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

137

5.2 Realizar la renovación en las IES o Fondos

Código: REN-SIS-002

Nombre: Realizar la renovación (gestor del crédito)

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-04-08 Fecha de aprobación:

Objetivo Reportar la renovación del crédito para el siguiente periodo académico.

Descripción Una vez el beneficiario ha actualizado datos y ha seleccionado la opción de renovar el crédito, el gestor (IES, fondo o ICETEX) debe verificar la información, diligenciar los datos académicos y confirmar la información bancaria para la posterior renovación. *El ICETEX en todos los casos debe realizar la confirmación del número de cuenta y su estado (activo o inactivo) antes de la generación de la resolución relación de giro.

Actores Principales IES Revisar la información de académica del beneficiario para autorizar le renovación del crédito

Gestor del fondo Revisar la información de académica del beneficiario para autorizar le renovación del crédito.

Funcionario del ICETEX encargado de renovar créditos

Revisar, verificar y autorizar el giro para aquellos créditos cuyo destino es diferente a matrícula y para aquellos que no son renovados por las IES y/o fondos.

Actores secundarios Funcionarios de crédito y cartera

Utiliza la información de renovación para generar la resolución de giros.

Precondiciones: El beneficiario debe encontrarse en época de estudios

El beneficiario debe haber solicitado la renovación del credito.

El fondo cerrado debe haber enviado la información de los beneficiarios que renovaron el crédito.

El crédito no debe estar bloqueado

Poscondiciones Obtener la autorización por parte de la IES y del fondo

Secuencia normal de acciones:

1. El sistema presenta la lista de los beneficiarios que ya realizaron la actualización de datos

2. El gestor (IES, fondo)selecciona el beneficiario a renovar

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

138

3. El sistema presenta los datos del beneficiario y los campos para que sean verificados y diligenciados por el gestor (IES, fondo).

4. El gestor (IES, fondo) ingresa la información solicitada (p.e. Semestre a cursar, valor de la matricula) (Ver Nota1)

5. El sistema valida que se haya ingresado la información 6. El sistema guarda el log de auditoria de quien realizo la

verificación y guarda la información 7. El gestor avala los créditos a renovar 8. Fin del Proceso

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) El sistema debe guardar la aprobación de la IES y/o fondo máximo en dos (2) segundos y debe generar un reporte de aceptación o rechazo de la renovación. El sistema debe controlar que la información del valor registrada por el gestor (IES, fondos) no se pase de los topes máximos estipulados por la modalidad.

Disponibilidad La renovación por parte de la IES y7o fondo debe quedar disponible en el sistema de crédito para poder generar la generación de la resolución de giro.

Seguridad El sistema debe solicitar un código de autenticación para que los funcionarios de la IES y/o fondo realicen la verificación y diligenciamiento de información.

Gestionabilidad – Control del proceso En esta parte el proceso finaliza con un estado de “renovado por parte de la IES y/o fondo.

Auditoria Debe existir un repositorio que cuente con la siguiente información:

o Fecha de renovación del crédito o Cambios realizados en la información. o Actor que realizó la renovación.

Notas y comentarios 1 La información que la IES debe ingresar puede variar según la modalidad de crédito o fondo (pe. El fondo de la secretaria

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

139

de educación del distrito solicita saber si el beneficiario perdió materias para la aprobación de la renovación). Así mismo el valor de la matricula ingresada para una misma carrera puede variar según los topes estipulados en cada modalidad de crédito o fondo.

*La renovación puede no ser visada cuando:

El beneficiario aplaza el semestre, para este caso el gestor marca el crédito como aplazado.

El beneficiario se retira de la universidad.

El beneficiario termino los estudios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

140

6. GIROS

6.1 Pago a proveedores cargados a gastos al fondo

Código: GIR-SIS-001

Nombre: Pago a proveedores cargados a gastos al fondo

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-06-20 Fecha de aprobación:

Objetivo Crear la resolución relación de desembolsos a efectuar a los proveedores para ser pasada a aprobación teniendo descuentos los descuentos tributarios correspondientes.

Descripción El sistema de crédito y cartera debe crear la resolución relación de giro donde se presentan los datos básicos que se necesiten para realizar el giro: los datos del beneficiario, datos del tercero y descuentos tributarios. (ver nota 1).

Actores Principales Analista de fondos

Es el encargado de generar la resolución de giro una vez que esta tiene la liquidación tributaria.

Sistema de crédito y cartera

Se encarga de generar las resoluciones de giro y cargar la información en el sistema financiero.

Proveedor de bienes o servicios

Es el encargado de entregar la factura para la generación de la resolución de giro

Actores secundarios Sistema financiero

Utiliza la información para efectuar el giro

Precondiciones: El crédito debe estar legalizado.

La cuenta debe estar previamente aprobada por el proceso de matricula de cuentas

Se debe tener el número de disponibilidad presupuestal

Se debe tener la factura debidamente diligenciada según el tipo de tercero.

La fecha de la factura debe ser del mes vigente

Resultados Creación de resolución relación de giro para terceros

Secuencia normal de acciones:

1. El analista de fondos entra al sistema y escoge la opción de generar resolución para terceros

2. El sistema presenta los filtros por lo que se puede conocer que resoluciones de giro están pendientes de generación (por modalidad de crédito y/o fondo, IES: en este caso le presenta )

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

141

3. El analista de fondos selecciona el filtro 4. El sistema muestra una vista previa de la resolución (ver nota 2) 5. El analista de fondos diligencia una breve descripción de la

factura a girar, verifica la información de la resolución de giro y selecciona la opción de procesar resolución

6. El sistema carga la información de la resolución, genera el número de resolución y la envía al sistema financiero ver caso de uso GRC-SIS-003) (en este caso el sistema financiero debe enviar confirmación del envío)(ver nota 3)

7. El analista de crédito y/o fondos imprime la resolución de giro. 8. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación debe procesar la resolución en máximo cinco (5) segundos después de que el analista de fondos escoja el filtro. El sistema debe cargar la información de la resolución en el sistema en un tiempo máximo de dos (2) segundos. Una vez cargada debe enviársela automáticamente al sistema financiero. El sistema debe generar un mensaje de confirmación.

Disponibilidad

La opción de facturación de cursos de terceros debe estar disponible para los analistas de fondos que deben realizar este proceso. Una vez que haya sido procesada, las resoluciones deben quedar disponibles en el sistema financiero y en un repositorio para la consulta de los funcionarios del ICETEX.

Seguridad o El sistema debe pedir un código de autenticación (pin de

seguridad) para que el analista de fondos pueda generar la resolución de giro.

Gestionabilidad - Control de procesos La resolución queda en un estado de generada para firmas.

Auditoria Debe existir un histórico donde se presente la siguiente

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

142

información: o Fecha de generación de la resolución o Número de la resolución o Número de CDP o Información de la resolución o Información de impuestos liquidados o Estado en el que se encuentra la resolución de giro o Actor que creo la resolución

Notas y comentarios 1. Los datos que se necesitan del tercero son:

NIT

Nombre del tercero

Datos bancarios (número de cuenta, tipo de cuenta, nombre del titular).

Tipo de tercero (Régimen común, régimen simplificado, gran contribuyente, persona natural, persona jurídica, autoretenedor)

Dirección

Teléfono 2. El sistema presenta la siguiente información

o NIT o Nombre del tercero o Valor antes de impuestos o Impuestos liquidados (retención en la fuente, ICA,

RETEIVA, RETEICA, IVA) o Valor neto

3. Se debe manejar un consecutivo único de resoluciones para las modalidades de crédito y fondos.

Una vez se generan las resoluciones, se debe alimentar automáticamente las bases de datos de presupuestos, tesorería, de tal manera que se pueda saber el estado de las resoluciones: resoluciones presupuestadas, giradas o si fueron rechazadas en cualquiera de las etapas anteriores.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

143

6.2 Generar resoluciones de giro

Código: GIR-SIS-002

Nombre: Generar Resolución relación de Giro

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-05 – 03 Fecha de aprobación:

Objetivo Crear la resolución relación de desembolsos a efectuar para ser pasada a aprobación.

Descripción El sistema de crédito y cartera debe crear la resolución relación de giro donde se presentan los datos básicos que se necesiten para realizar el giro Número de identificación de la IES), los datos del beneficiario y del crédito (Ver nota 1) y enviar la información al sistema financiero. *El sistema debe generar un indicador diciendo si se debe constituir o no cartera por cada resolución relación de giro.

Actores Principales Analista de crédito

Es el encargado de validar la información de la resolución relación de giro.

Analista de fondos

Es el encargado de validar la información de la resolución relación de giro.

Sistema de crédito y cartera

Se encarga de generar las resoluciones de giro y cargar la información en el sistema financiero.

Actores secundarios Sistema financiero

Utiliza la información para efectuar el giro

Precondiciones: El crédito debe estar legalizado o renovado.

El crédito debe estar en época de estudio

El crédito debe estar al día en las obligaciones (ver nota 2)

La cuenta debe estar previamente aprobada por el proceso de matricula de cuentas

Se debe tener el número de disponibilidad presupuestal

Resultados Creación de resolución relación de giro

Secuencia normal de acciones:

1. El analista de crédito y/o fondos entra al sistema y escoge la opción de generar resolución.

2. El sistema presenta los filtros por lo que se puede conocer que resoluciones de giro están pendientes de generación (por modalidad de crédito y/o fondo, IES: en este caso le presenta )

3. El analista de crédito y/o fondos selecciona el filtro 4. El sistema muestra una vista previa de la resolución

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

144

5. El analista de crédito y/o fondos verifica la información de la resolución de giro y selecciona la opción de procesar resolución

6. El sistema carga la información de la resolución, genera el número de resolución y la envía al sistema financiero(ver caso de uso GRC-SIS-004) (en este caso el sistema financiero debe enviar confirmación del envío)(ver nota 3)

7. El analista de crédito y/o fondos imprime la resolución de giro. 8. Fin del proceso.

Secuencias alternas 5a. El analista de crédito y/o fondos no verifica la información de la resolución por inconsistencia en los datos.

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación debe procesar la resolución en máximo cinco (5) segundos después de que el analista de crédito y/o fondos escoja el filtro. El sistema debe cargar la información de la resolución en el sistema en un tiempo máximo de dos (2) segundos. Una vez cargada debe enviársela automáticamente al sistema financiero.

Disponibilidad La opción de generación de resoluciones debe estar disponible para los analistas de crédito y/o fondos que deben realizar este proceso. Una vez que haya sido procesada, las resoluciones deben quedar disponibles en el sistema financiero y en un repositorio para la consulta de los funcionarios del ICETEX.

Seguridad o El sistema debe pedir un código de autenticación (pin de

seguridad) para que el analista de crédito y/o fondos pueda generar la resolución de giro.

Gestionabilidad - Control de procesos La resolución queda en un estado de generada para firmas.

Auditoria Debe existir un histórico donde se presente la siguiente información: o Fecha de generación de la resolución o Número de la resolución o Número de CDP o Información de la resolución

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

145

o Estado en el que se encuentra la resolución de giro o Actor que creo la resolución o Fuentes de recursos

Notas y comentarios 1. Los datos que se necesitan de la IES son:

NIT

Nombre de la Universidad

Datos bancarios (número de cuenta, tipo de cuenta, nombre del titular).

Los datos del beneficiario son:

Número de identificación

Nombre

Programa académico

Los datos del crédito son:

Modalidad de crédito y/o fondos

Valor matricula

Valor de giro

Número de CDP

Valor de la garantía 2. Si el ICETEX se demora en realizar el giro el beneficiario no

necesita pagar las cuotas que se generan de esta, por ejemplo el beneficiario solicita renovación el primero (1) de julio y el ICETEX le gira el primero (1) de agosto entonces no es necesario que pague las cuotas de julio y agosto para que le desembolsen).

3. La información que se debe cargar en el momento de generar

resoluciones de giro es:

Fecha de creación de la resolución

Destino de giro: proveedor, IES, beneficiario

Rubro de la resolución (matrícula, sostenimiento, transporte, computadores, entre otros. ver nota 4)

Número de identificación del beneficiario (puede ser cédula de ciudadanía o tarjeta de identidad para personas naturales y NIT para personas jurídicas) (ver nota 5)

Código del crédito

Valor bruto, el valor de la garantía y el valor neto a desembolsar.

Nombre de la entidad financiera del Beneficiario donde se

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

146

debe hacer el desembolso

Número de cuenta bancaria a donde se debe consignar

Tipo de cuenta del beneficiario (ahorro ó corriente)

Número de certificado de disponibilidad presupuestal (CDP).

Fuentes de financiación (ICETEX, IES, Fondos, Alianza Estratégica).

Presentar que tipo de proceso es: Créditos Adjudicados o renovados.

Valor del gasto en administración porcentaje de la comisión que se le paga al ICETEX

Centro de costos

Se debe manejar un consecutivo único de resoluciones para las modalidades de crédito y fondos.

Una vez se generan las resoluciones, se debe alimentar automáticamente las bases de datos de presupuestos, tesorería, de tal manera que se pueda saber el estado de las resoluciones: resoluciones presupuestadas, giradas o si fueron rechazadas en cualquiera de las etapas anteriores.

4. Los giros a universidades se hacen por concepto de matricula. Los giros a estudiante se hacen por concepto de sostenimiento o cuando el estudiante ya ha efectuado el pago de matricula a la IES (siempre y cuando tenga certificado este pago). En fondos se tienen otros rubros como son textos, transporte, tesis, derechos de grado, uniformes, pensión los cuales son girados al estudiante.

El consecutivo de numeración de la resolución debería ser único

para todas las modalidades de crédito y fondos. Cuando el giro se realiza a una entidad educativa, se deben generar resoluciones independientes para cada una. Las resoluciones con destino de giro al estudiante se generan por modalidad de crédito y/o fondo.

Una resolución solo debe tener un destino del crédito.

5. En el caso de que una resolución para IES contenga varios beneficiarios esta debe incluir el numero de identificación y el nombre completo de cada uno de los beneficiarios, el programa académico, el número de crédito, el semestre a financiar , el valor bruto, el valor de la garantía, liquidación del crédito: que es

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

147

subsidiado y que es crédito y el valor neto).

En el caso de los fondos cuya financiación va por gastos al fondo en la resolución no existe la liquidación del crédito.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

148

6.3 Aprobar resolución relación de giro

Código: GIR-SIS-003

Nombre: Aprobar resolución relación de giro

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-05 – 03 Fecha de aprobación:

Objetivo Aprobar la resolución de giro para realizar el desembolso

Descripción Una vez que se genera la resolución de giro esta debe ser avalada por el(los) ordenador(es) del gasto y por el área presupuestal (registro presupuestal, interfase con el modulo financiero). Cuando esta avalada, el analista de crédito y/o fondos debe cambiar el estado de la resolución en el sistema (anulada o aprobada). * Se debe dejar abierta la posibilidad de que la firma sea digital o en forma física.

Actores Principales Vicepresidencia de crédito y cobranza:

Es el encargado de avalar las resoluciones relaciones de giro de las modalidades de crédito

Vicepresidencia de Fondos

Es el encargado de avalar las resoluciones relaciones de giro de los fondos junto al gestor del fondo

Presupuesto

Se encarga de revisar que el soporte y el registro presupuestal existan y coincidan.

Analista de crédito

Es el encargado de cambiar el estado de la resolución una vez este avalada por los ordenadores del gasto y por presupuesto

Analista de fondos

Es el encargado de cambiar el estado de la resolución una vez este avalada por los ordenadores del gasto y por presupuesto

Actores secundarios Tesorería Se encarga de realizar los desembolsos una vez que las resoluciones relaciones de giro son aprobadas.

Precondiciones: Debe haber una resolución relación de giro creada

Resultados Resolución relación de giro avalada

Secuencia normal de acciones:

1. El (los) ordenadores del gasto revisan la información de la resolución, la avalan. y la envían al área de presupuesto.

2. El jefe de presupuesto verifica la información presupuestal de la resolución y la envía al área de crédito y/o fondos

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

149

3. El analista de crédito y/o fondos actualiza el estado de la resolución en el sistema (aprobado o rechazado)

4. Fin del proceso.

Secuencias alternas

1a. El(los) ordenadores del gasto no avala la resolución por inconsistencias en la información y se anula

Cuando existen inconsistencias en la información la resolución es anulada. En el momento en que se anula la resolución relación de giro el sistema debe dar la posibilidad de volver a girar para el mismo periodo pero debe dejar el histórico de que se anulo

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación debe guardar el cambio de estado de la solicitud en máximo dos (2) segundos después de que el analista lo haya subido.

Disponibilidad El estado de aprobación resolución relación de giro debe quedar disponible para tesorería con el fin de que puedan realizar el proceso de desembolso. De igual forma debe quedar disponible en un repositorio como información de seguimiento a los créditos.

Seguridad o El sistema debe solicitar un código de autenticación (pin de

seguridad) para que el analista de crédito y/o fondos actualice el estado de las resoluciones de giro.

Gestionabilidad - Control de procesos El proceso esta en un estado de generada para firmas y puede quedar en dos posible estados: aprobada o anulada

Auditoria Debe existir un repositorio donde se presente: o Fecha de aprobación o Numero de resolución o Estado de la resolución o Actores que aprobaron la resolución o Actor que cargo la información al sistema

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

150

Notas y comentarios La aprobación de las resoluciones relaciones de giro debe presentar quienes son los ordenadores de acuerdo a las fuentes de recursos. en el caso de recursos propios el ordenador del gasto es el vicepresidente de crédito y cobranzay en el caso de las alianzas es el vicepresidente de fondos. En el formulario deben existir campos especiales para saber si aplica a subsidio o crédito en alianzas y de esta manera se deben generar las distintas dinámicas de cuentas. Cuando hay subsidio el solicitante no debe saberlo sino hasta el momento en que se haga la liquidación de obligaciones.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

151

6.4 Generar Resoluciones de Giro Complementario

Código: GIR-SIS-004

Nombre: Generar Resoluciones de Giro Complementario

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-05 – 03 Fecha de aprobación:

Objetivo Crear la relación de desembolsos adicionales a efectuar

Descripción El sistema debe crear resoluciones de giro adicionales cuando la IES y/o el gestor han solicitado un valor menor de giro y se debe realizar un desembolso adicional. En este proceso la IES y/o el fondo debe solicitarlo mediante una carta donde explique el motivo de la solicitud y el monto adicional a girar. Una vez se realiza la verificación de datos por parte del ICETEX, se procede a efectuar la resolución de giro adicional, para complementar el giro Inicial (ver nota 1). Cuando es consolidado podría ser con un archivo para el cargue masivo de giros complementarios….se podría generar aplicativo para este cargue masivo en la IES y que el ICETEX lo valida *En el momento de generar la resolución de giro el sistema debe traer el valor de giro inicial y el valor total del giro para sacar la diferencia (valor complementario) que se debe girar y debe controlar que no se pase los topes máximos * El giro complementario también se puede dar cuando hubo un error en el cargue de la información ** En los giros complementarios el sistema debe estar en la capacidad de presentar contra que fuente se esta cruzando (por ejemplo Existe una modalidad en que los beneficiario de estrato 1 al 2 tienen una parte de crédito y otra de beneficio y los de estrato tres en adelante tiene solo crédito. Entonces si se tiene un beneficiario que es de estrato uno y se le giro pensando que era de estrato 3, se le debe creara el giro complementario por lo correspondiente a subsidio. ***Los subsidios nunca se cancelan con recursos propios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

152

Actores Principales Analista de crédito Es el encargado de validar la información de la resolución relación de giro.

Analista de fondos Es el encargado de validar la información de la resolución relación de giro.

Sistema de crédito y cartera Se encarga de generar las resoluciones de giro y cargar la información en el sistema financiero.

Gestor del fondo Autoriza la generación de giros complementarios en fondos

Vicepresidencia de crédito y cobranza

Autoriza la generación de giros complementarios en las modalidades de crédito

Actores secundarios Sistema financiero Utiliza la información para efectuar el giro

Precondiciones: El crédito debe estar en época de estudio

El crédito debe tener un giro inicial por menor valor.

El crédito debe tener autorizada la generación del giro complementario.

Resultados Resolución de giro complementario.

Secuencia normal de acciones:

1. El analista de crédito y/o fondos entra al sistema y escoge la opción de generar resolución complementaria

2. El sistema presenta el listado de créditos pendientes de generación de resoluciones de giro complementario.

3. El analista de crédito y/o fondos selecciona la resolución a generar.

4. El sistema muestra una vista previa de la resolución 5. El analista de crédito y/o fondos verifica la información de la

resolución de giro y selecciona la opción de procesar resolución complementaria

6. El sistema carga la información de la resolución, genera el número de resolución y la envía al sistema financiero(ver caso de uso GRC-SIS-002) (en este caso el sistema financiero debe enviar confirmación del envío)(ver nota 3)

7. El analista de crédito y/o fondos imprime la resolución de giro complementaria.

8. Fin del proceso.

Secuencias alternas

Requerimientos no Desempeño ( Rendimiento)

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

153

funcionales La aplicación debe procesar la resolución en máximo cinco (5) segundos después de que el analista de crédito y/o fondos escoja el filtro. El sistema debe cargar la información de la resolución en el sistema en un tiempo máximo de dos (2) segundos. Una vez cargada debe enviársela automáticamente al sistema financiero.

Disponibilidad La opción de generación de resoluciones debe estar disponible para los analistas de crédito y/o fondos que deben realizar este proceso. Una vez que haya sido procesada, las resoluciones deben quedar disponibles en el sistema financiero y en un repositorio para la consulta de los funcionarios del ICETEX.

Seguridad o El sistema debe pedir un código de autenticación (pin de

seguridad) para que el analista de crédito y/o fondos pueda generar la resolución de giro.

Gestionabilidad - Control de procesos La resolución queda en un estado de generada para firmas.

Auditoria Debe existir un histórico donde se presente la siguiente información: o Fecha de generación de la resolución o Número de la resolución o Número de CDP o Motivo del giro complementario. o Información de la resolución o Estado en el que se encuentra la resolución de giro

(pendiente para firmas) o Actor que creo la resolución

Notas y comentarios 1. Los datos que se necesitan de la IES son:

NIT

Nombre de la Universidad

Datos bancarios (número de cuenta, tipo de cuenta, nombre del titular).

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

154

Los datos del beneficiario son:

Número de identificación

Nombre

Programa académico

Los datos del crédito son:

Modalidad de crédito y/o fondos

Valor matricula

Valor de giro

Número de CDP

Valor de la garantía

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

155

6.5 Confirmar giros exitosos

Código: GIR-SIS-005

Nombre: Confirmar giros exitosos

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-06-14 Fecha de aprobación:

Objetivo Realizar la confirmación de los giros en el sistema de crédito para la constitución de cartera (créditos adjudicados) o aplicación de giros (créditos renovados).

Descripción El analista crédito y/o fondos debe actualizar el estado del giro (exitoso o rechazado) una vez que el sistema financiero informe de la confirmación bancaria. *El banco se demora máximo tres (3) días hábiles en confirmar los giros.

Actores Principales Sistema financiero

Se encarga de enviar el archivo con la confirmación de giros y sus respectivas observaciones

Analista de crédito

Se encarga de actualizar el estado del giro (en firma o rechazado) en las modalidades de crédito.

Analista de fondos

Se encarga de actualizar el estado del giro (en firma o rechazado) en los fondos.

Actores secundarios Analista de cartera

Utiliza la información para constituir cartera o aplicar lo giros.

Precondiciones: El sistema financiero debe enviar el listado de la confirmación de giros.

El sistema de crédito y cartera debe tener cargado el archivo con la información del banco (número de referencia y valor girado).

Resultados Giro exitoso

Giro rechazado

Secuencia normal de acciones:

1. El sistema financiero envía al sistema de crédito y cartera el archivo de confirmación de giros.

2. El analista de crédito y/o fondos cruza la información con las bases de datos del sistema de crédito y cartera a partir del número de referencia.

3. El sistema carga los giros y guarda la información (ver nota 1). 4. El sistema solicita la aplicación de los giros 5. Fin del proceso

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

156

Secuencias alternas 3a. El sistema no carga los giros. Aquellos giros que no fueron exitosos son enviados al àrea de tesorería para que realicen las respectivas modificaciones. Si la información no puede ser modificada (p.e. el valor a girar no es el estipulado en la resolución relación de giro) se anula el giro y se debe iniciar el proceso desde la generación de la resolución relación de giro.

4a. El sistema constituye cartera

En el caso de créditos adjudicados y que son reembolsables el sistema de cartera debe crear el histórico de cartera afectando cuentas del activo (cuentas por cobrar y bancos). En el caso de los créditos mixtos la parte reembolsable constituye cartera afectando cuentas del activo (cuentas por cobrar y bancos) y la parte condonable afecta el activo los gastos.

4b. El sistema aplica giros a cartera En el caso de créditos renovados y que son reembolsables el sistema aplica el giro afectando las cuentas del activo (cuentas por cobrar y bancos). En el caso de los créditos mixtos la parte reembolsables se aplica afectando las cuentas del activo y la parte reembolsable afecta el activo y los gastos.

4c. El sistema aplica gastos al fondo En el caso de los créditos condonables de los fondos la aplicación de los giros afectan el activo y los gastos

Requerimientos no funcionales

Desempeño ( Rendimiento) El sistema debe controlar que no se supere el tope de giro por día, para una cuenta y por beneficiario. El sistema debe revisar que el giro no supere el año de vigencia en que fue emitida. El sistema debe cargar diariamente los giros e firme y automáticamente debe solicitar la constitución de cartera o la aplicación de los giros. El sistema debe llevar un control de los giros devueltos y saber la ubicación de estos (devuelto a tesorería para modificaciones,

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

157

anulado, generación de una nueva resolución relación de giro, generada para firmas giro en proceso).

Disponibilidad La confirmación debe estar disponible en la base de datos del sistema de crédito y cartera, en el historial de cada crédito y en la sesión de cada beneficiario para su consulta. Adicionalmente debe estar disponible para el sistema financiero para generar la causación pertinente.

Seguridad El(los) analista(s) de crédito debe(n) tener una clave personal para traer la información del sistema financiero y para cargarla en el sistema de crédito y cartera. El sistema debe pedir un código de autenticación (pin de seguridad) para que pueda ser consultada. .

8. Gestionabilidad - Control de procesos El proceso entra en un estado de giro en proceso y puede finalizar en alguno de los siguientes estados: Exitoso o rechazado.

Auditoria Debe existir un repositorio donde se presente: 1. Fecha de cargue del estado del giro en el sistema 2. Información del crédito (número de referencia, valor girado,

fecha en que fue girado, tipo de crédito – reembolsable, condonable o mixto).

3. Siguiente proceso a realizar (Constitución de cartera, aplicación de giros a cartera, aplicación de gastos al fondo).

4. Actor que realizo el cargue.

Notas y comentarios 1. El sistema debe generar un indicador de gestión que mida el número de giros exitosos frente al número total de giros a efectuar.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

158

6.6 Visar tarjeta

Código: GIR-SIS-006

Nombre: Visar tarjeta

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-07-12 Fecha de aprobación:

Objetivo Confirmar que la tarjeta entregada a los beneficiarios de los fondos este activa para realizar el desembolso

Descripción El analista de fondos debe realizar la verificación de la activación y entrega de la tarjeta a los beneficiarios nuevos a donde se les va a girar lo financiado. *En este caso no se gira a ningún tercero ni se realiza la confirmación bancaria.

Actores Principales Beneficiario Recibe la tarjeta a donde se le va a hacer los desembolsos y colabora con la verificación de datos.

Analista de fondos

Se encarga de entregar y revisar que la tarjeta entregada este activa y tenga los datos

Actores secundarios Sistema de crédito y cartera

Utiliza la información para constituir cartera o aplicar lo giros.

Precondiciones: El fondo debe tener reglamentada la entrega de tarjetas

El crédito debe ser nuevo (para el otorgamiento de tarjeta)

Resultados Tarjeta entregada y visada por el ICETEX

Secuencia normal de acciones:

6. El analista de fondos contacta al beneficiario para informarle que su tarjeta ya esta

7. El beneficiario se acerca al ICETEX para recibir la tarjeta 8. El analista de fondos le solicita el documento de identificación y 9. El analista del fondo ingresa al sistema para validar la

información del beneficiario y de la tarjeta 10. El sistema le presenta la información a revisar 11. El analista de fondos valida la información y visa la entrega de

la tarjeta. 12. El sistema guarda la información y le informa al sistema

financiero del ICETEX el estado de la tarjeta para que realice el desembolso.

13. Fin del proceso.

Secuencias alternas 6a. El analista no valida la información por inconsistencias en

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

159

la información, le solicita que se acerque a las oficinas de seguimiento al crédito para la modificación de los datos.

Requerimientos no funcionales

Desempeño ( Rendimiento) El sistema debe presentar la información del beneficiario y de la tarjeta en máximo dos (2) segundos. El sistema debe enviar un mensaje a la sesión del beneficiario donde se confirme la entrega de la tarjeta. El sistema debe cargar diariamente las tarjetas visadas en el repositorio de éste. El sistema debe entregar un mensaje de confirmación de entrega de la información de las tarjetas visadas al sistema financiero del ICETEX

Disponibilidad El resultado del visado de la tarjeta debe estar disponible en la base de datos del sistema de crédito y cartera, en el historial de cada crédito y en la sesión de cada beneficiario. Adicionalmente debe estar disponible para el sistema financiero del ICETEX para que realicen los respectivos desembolsos..

Seguridad El analista de fondos debe tener una clave personal para revisar la información del beneficiario y de la tarjeta y para el visado de la misma. Este debe ser único

9. Gestionabilidad - Control de procesos El proceso finaliza en un estado de “tarjeta visada y entregada”..

Auditoria Debe existir un repositorio donde se presente: 5. Fecha de visado de la tarjeta 6. Persona a quien se le entrego 7. Fondo al que pertenece el beneficiario 8. Actor que realizo el visado

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

160

Notas y comentarios 1. En el momento de la entrega de la tarjeta el beneficairo debe firmar el listado de entrega de tarjetas con el fin de llevar un control de éstas

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

161

6.7 Aplicar Gastos al Fondo

Código: CEE-SIS-007

Nombre: Aplicar Gastos al Fondo

Elaborado por: William C. Aprobado por:

Fecha de elaboración:

2007-05-07 Fecha de aprobación:

Objetivo Actualizar el saldo de los fondos por la aplicación de giros a sus beneficiarios.

Descripción El sistema de cartera cada vez que aplica un giro o se constituye cartera (primer giro) de un fondo debe disminuir el valor del giro al saldo disponible que posee el fondo.

Actores Principales Analista de Fondos Carga información en el sistema de crédito

Sistema de crédito y cartera

Actualizar información de los créditos

Actores secundarios Sistema financiero Realiza la causación contable

Precondiciones: Existencia de giros en firme

Poscondiciones Actualización del saldo del fondo.

Secuencia normal de acciones:

1. El sistema disminuye el saldo del fondo por el valor del giro. 2. El sistema retorna un mensaje exitoso de la actualización del

saldo del fondo. 3. Fin del proceso.

Secuencias alternas 2a. El sistema no disminuye el saldo del fondo porque no existe recursos para cubrir el valor total del giro..

El sistema registra un mensaje de no hay saldo disponible para el valor del giro.

Requerimientos no funcionales

Desempeño ( Rendimiento) El sistema debe aplicar diariamente los giros en firme y automáticamente debe enviar u mensaje de confirmación o rechazo.

Disponibilidad La confirmación debe estar disponible en la base de datos del sistema de crédito y cartera, en el historial de cada crédito y en la sesión de cada beneficiario para su consulta.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

162

Adicionalmente debe estar disponible para el sistema financiero para generar la causación pertinente.

Seguridad El(los) analista(s) de crédito debe(n) tener una clave personal para traer la información del sistema financiero y para cargarla en el sistema de crédito y cartera. El sistema debe pedir un código de autenticación (pin de seguridad) para que pueda ser consultada. .

Gestionabilidad - Control de procesos El proceso entra en un estado de giro exitoso

Auditoria Debe existir un repositorio donde se presente: o Fecha de cargue del estado del giro en el sistema o Información del crédito (número de referencia, valor

girado, fecha en que fue girado, tipo de crédito – reembolsable, condonable o mixto).

o Siguiente proceso a realizar (Constitución de cartera, aplicación de giros a cartera, aplicación de gastos al fondo).

o Actor que realizo el cargue.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

163

7. NOVEDADES DEL CRÉDITO

7.1 Modificar los datos de ubicación del beneficiario y/o del deudor de una solicitud aprobada que no ha sido legalizada

Código: NCR-SIS-001

Nombre: Modificar los datos del estudiante y/o del deudor solidario de una solicitud aprobada que no ha sido legalizada

Elaborado por: Olga Alejandra Pantoja R:

Aprobado por:

Fecha de elaboración:

2007-05-04 Fecha de aprobación:

Objetivo Verificar y actualizar los datos de ubicación de los solicitantes (ver notas 1) teniendo en cuenta que esto no afecte los criterios de evaluación de la solicitud.

Descripción Seguimiento al crédito verifica y actualiza los datos de del beneficiario y/o del deudor siempre y cuando no afecten los criterios de evaluación del crédito.

Actores Principales Beneficiario Es el encargado de avisar el cambio de datos de ubicación

Gestor Del fondo Es el encargado de avisar el cambio de datos de ubicación del beneficiario

Seguimiento al crédito

Recibe la solicitud de cambio de información del crédito. Revisa que esta no afecte los criterios de evaluación de la solicitud.

Actores secundarios Sistema de crédito y cartera

Utiliza la información para actualizar los datos de los créditos aprobados

Precondiciones: El beneficiario debe encontrarse aprobado por el comité de crédito en cualquiera de las modalidades de crédito o fondo y no debe haber legalizado.

Poscondiciones Actualización de datos básicos del beneficiario antes de la legalización

Secuencia normal de acciones:

1. El beneficiario solicita la modificación de datos a la oficina de seguimiento de crédito.

2. Seguimiento al crédito le realiza dos preguntas para confirmar que es el beneficiario real.

3. El sistema valida las respuestas 4. Seguimiento al crédito ingresa al sistema, valida que el

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

164

beneficiario se encuentre aprobado por comité 5. El sistema presenta la información del beneficiario 6. Seguimiento al crédito modifica los datos que hayan

cambiado y verifica que no afecten los criterios de evaluación de la solicitud..

7. El sistema guarda la información y actualiza la base de datos de crédito.

8. Fin del proceso.

Secuencias alternas 3a. El sistema no valida las respuestas porque son incorrectas

El funcionario de seguimiento al crédito le dice al beneficiario que debe acercarse a las oficinas de atención al usuario con los documentos soporte para solicitar la modificación de datos básicos.

6a. El sistema no guarda la información debido a que la modificación de los datos afectan los criterios de evaluación de la solicitud.

Seguimiento al crédito le informa al beneficiario y el crédito es susceptible a anulación.

Requerimientos no funcionales

Desempeño ( Rendimiento) El sistema debe controlar que los datos a cambiar no afectan los criterios de evaluación del crédito. Una vez se diligencie la información el sistema debe generar un mensaje de aceptación o rechazo del cambio de los datos. El sistema debe validar las respuestas de las preguntas de autenticación del beneficiario en máximo dos (2) segundos. El sistema debe presentar la información del crédito máximo en dos (2) segundos una vez que el funcionario de seguimiento al crédito lo haya solicitado. El sistema debe guardar los cambios aceptados en máximo dos (2) segundos y debe reportar su aceptación.

Disponibilidad La modificación de los datos deben estar disponibles en la base de datos del sistema de crédito y cartera y en el historial de cada crédito. En este debe presentar un histórico de los cambios realizados.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

165

Seguridad El sistema debe pedir un código de autenticación (pin de seguridad) al funcionario de seguimiento al crédito para realizar la consulta y modificación de datos básicos del crédito.

Gestionabilidad - Control de procesos El proceso o cambia de estado.

Auditoria Debe existir un repositorio donde se presente (adicionalmente debe quedar en el historial del crédito): o Fecha de modificación de datos. o Información de los datos modificados. o Actor que realizo el cambio.

Notas y comentarios 1. Los datos que se pueden verificar son:

Dirección,

Teléfono,

Ciudad,

Número de celular,

Correo electrónico,

Adicionalmente se pueden modificar los siguientes datos siempre y cuando no afecten en la evaluación del crédito.

Estrato

SISBEN.

Referencias familiares

Referencia personales

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

166

7.2 Modificar los datos de ubicación del beneficiario de un crédito después de la

legalización

Código: NCR-SIS-002

Nombre: Modificar los datos de ubicación del beneficiario después de la legalización

Elaborado por: Olga Alejandra Pantoja R:

Aprobado por:

Fecha de elaboración:

2007-07-11 Fecha de aprobación:

Objetivo Verificar y actualizar los datos de ubicación de los solicitantes

Descripción Cuando el beneficiario se encuentra en época de estudios, seguimiento al crédito realiza la actualización de los datos básicos del beneficiario dado el caso que estos hayan cambiado. Cuando el crédito esta en época de estudios puede modificar el estrato (asi este haya sido criterio de evaluación).

Actores Principales Beneficiario Es el encargado de avisar el cambio de datos de ubicación

Gestor del crédito Es el encargado de avisar el cambio de datos de ubicación del beneficiario

Seguimiento al crédito

Realiza el cambio de datos

Actores secundarios Sistema de crédito y cartera

Utiliza la información para actualizar los datos de los créditos aprobados

Precondiciones: El gestor del crédito debe estar activo

Poscondiciones 1. Actualización de datos del gestor del crédito

Secuencia normal de acciones:

1. El beneficiario solicita la modificación de datos a la oficina de seguimiento de crédito.

2. Seguimiento al crédito le realiza dos preguntas para confirmar que es el beneficiario real.

3. El sistema valida las respuestas 4. El sistema presenta la información del beneficiario 5. Seguimiento al crédito modifica los datos que hayan

cambiado. 6. El sistema guarda la información y actualiza la base de datos

de crédito. 7. Fin del proceso.

Secuencias alternas 3a. El sistema no valida las respuestas porque son

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

167

incorrectas El funcionario de seguimiento al crédito le dice al beneficiario que debe acercarse a las oficinas de atención al usuario con los documentos soporte para solicitar la modificación de datos básicos.

Requerimientos no funcionales

Desempeño ( Rendimiento) Una vez se diligencie la información el sistema debe generar un mensaje de aceptación o rechazo del cambio de los datos. El sistema debe validar las respuestas de las preguntas de autenticación del beneficiario en máximo dos (2) segundos. El sistema debe presentar la información del crédito máximo en dos (2) segundos una vez que el funcionario de seguimiento al crédito lo haya solicitado. El sistema debe guardar los cambios aceptados en máximo dos (2) segundos y debe reportar su aceptación.

Disponibilidad La modificación de los datos debe estar disponible en la base de datos del sistema de crédito y cartera y en el historial de cada crédito. En este debe presentar un histórico de los cambios realizados.

Seguridad El sistema debe pedir un código de autenticación (pin de seguridad) al funcionario de seguimiento al crédito para realizar la consulta y modificación de datos básicos del crédito.

Gestionabilidad - Control de procesos El proceso o cambia de estado.

Auditoria Debe existir un repositorio donde se presente (adicionalmente debe quedar en el historial del crédito): o Fecha de modificación de datos. o Información de los datos modificados. o Actor que realizo el cambio.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

168

Notas y comentarios *Los datos de ubicación del beneficiario pueden ser modificados en:

Época de inscripción mientras el formulario se encuentre activo para ello En este caso la modificación la realiza el solicitante).

Época de renovación cuando el beneficiario actualiza sus datos básicos.

En el momento en que hayan cambios en la información básica del deudor.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

169

7.3 Actualizar datos de los gestores

Código: NCR-SIS-003

Nombre: Actualizar datos de los gestores

Elaborado por: Olga Alejandra Pantoja R:

Aprobado por:

Fecha de elaboración:

2007-07-11 Fecha de aprobación:

Objetivo Verificar y actualizar los datos de los gestores del crédito

Descripción El sistema permite la ctualización de datos de los gestores.

Actores Principales Gestor del crédito Es el encargado de avisar el cambio de datos

Seguimiento al crédito

Realiza el cambio de datos

Actores secundarios Sistema de crédito y cartera

Utiliza la información para actualizar los datos de los créditos aprobados

Precondiciones: El crédito debe estar vigente

Poscondiciones Actualización de datos básicos del crédito

Secuencia normal de acciones:

1. El gestor entra al sistema 2. El sistema le solicita su pin de seguridad 3. El gestor ingresa la información solicitada 4. El sistema la valida 5. El gestor selecciona la opción “actualizar datos” 6. El sistema le presenta los datos actuales 7. El gestor modifica los datos 8. El sistema guarda la información y actualiza la base de datos

de crédito. 9. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) Una vez se diligencie la información el sistema debe generar un mensaje de aceptación o rechazo del cambio de los datos. El sistema debe validar las respuestas de las preguntas de autenticación del beneficiario en máximo dos (2) segundos. El sistema debe presentar la información del crédito máximo en dos (2) segundos una vez que el funcionario de

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

170

seguimiento al crédito lo haya solicitado. El sistema debe guardar los cambios aceptados en máximo dos (2) segundos y debe reportar su aceptación.

Disponibilidad La modificación de los datos debe estar disponible en la base de datos del sistema de crédito y cartera y en el historial del gestor. En este debe presentar un histórico de los cambios realizados.

Seguridad El sistema debe pedir un código de autenticación (pin de seguridad) al funcionario de seguimiento al crédito para realizar la consulta y modificación de datos básicos del crédito.

Gestionabilidad - Control de procesos El proceso o cambia de estado.

Auditoria Debe existir un repositorio donde se presente (adicionalmente debe quedar en el historial del crédito): o Fecha de modificación de datos. o Información de los datos modificados. o Actor que realizo el cambio.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

171

7.4 Cambio de Deudor Solidario

Código: NCR-SIS-004

Nombre: Cambio de Deudor Solidario

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-05-07 Fecha de aprobación:

Objetivo Obtener un nuevo deudor solidario aprobado y realizar la garantía del nuevo deudor solidario (pagaré y carta de instrucciones).

Descripción El analista de crédito y/o fondos realiza el cambio del deudor solidario durante la época de legalización, de estudio y de amortización del crédito teniendo en cuenta la solicitud del beneficiario y la aprobación en el comité (Ver Nota 1). * Mientras tenga un codeudor aprobado no me puede validar otro, sin embargo me debe quedar un historial del deudor aprobado y del deudor anterior con la observación pertinente

Actores Principales Beneficiario Solicita el cambio de deudor

Seguimiento al crédito

Es el encargado de verificar la información de deudor solidario y avisar cuando se debe hacer cambio del mismo.

Gestor Imprime la nueva garantía y la valida una vez es entregada por el beneficiario

ICETEX Visa la garantía

Gestión documental Constituye la nueva garantía

Actores secundarios Sistema de crédito y cartera

Utiliza la información para actualizar los datos del deudor solidario en su base de datos y en el historial de cada crédito.

Precondiciones: El crédito debe estar vigente

El cambio del deudor solidario debe encontrarse aprobado por el ICETEX.

El deudor solidario que reemplazará al anterior debe encontrarse evaluado y aprobado por la central de información (ver caso de uso OTO-SIS-010)

El beneficiario debe estar al día en las obligaciones.

Poscondiciones Tener la información del nuevo deudor solidario y la garantía del crédito diligenciada y radicada.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

172

Secuencia normal de acciones:

1. El analista de crédito y/o fondos ingresa el código de autenticación.

2. El sistema lo valida 3. El analista escoge la opción de cambio de deudor solidario e

ingresa los nuevos datos y le notifica al beneficiario la aceptación de cambio de deudor solidario

4. El sistema debe generar el nuevo pagare y carta de instrucciones

5. El gestor imprime la garantía 6. El beneficiario diligencia el pagaré y la carta de instrucciones

y lo radia en el gestor 7. El gestor lo valida y lo envia a gestión docuimental 8. Gestión documental valida la garantía. 9. Gestión documental envía archivo de nuevas garantías

constituidas (digitalización). 10. El ICETEX visa la garantía. 11. Fin del proceso.

Secuencias alternas 7a.El gestor no valida la garantía. Cuando el pagaré o la carta de instrucciones esta manchado, roto o la información es inconsistente se lo devuelve al beneficiario e imprime uno nuevo. Cuando este diligenciado continua en el paso siete(7) del flujo normal.

Requerimientos no funcionales

Desempeño ( Rendimiento) El analista de crédito y/o el analista de fondos debe cargar el listado de cambio de deudores diariamente y debe tener como llave el número de crédito. Una vez se carga esta información el sistema debe generar un mensaje de aceptación del cambio de deudor en la sesiones de cada usuario cambiado. El sistema debe generar un mensaje donde confirme la creación del nuevo deudor. El sistema debe llevar un historial con el cambio de deudores de cada crédito

Disponibilidad La nueva garantía debe quedar disponible de forma digital en el historial de crédito y en un repositorio para los funcionarios de crédito y cartera (se deben realizar las respectivas observaciones del cambio de deudor solidario).

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

173

Seguridad El sistema debe solicitar un código de autenticación para que los funcionarios de crédito y cartera carguen la información y para el gestor en el momento de la impresión de la garantía.

Gestionabilidad – Control del proceso En esta parte el proceso finaliza con un estado de “cambio de garantía.

Auditoria Debe existir un repositorio que cuente con la siguiente información:

o Fecha de constitución de garantías nuevas o Actor que realizo la constitución de garantías o Observación del cambio de deudor solidario o Ubicación de la garantía o Valor de la garantía o Nombre del beneficiario y número de identificación o Gestor que realizo la validación de la garantía

Notas y comentarios 1. CAUSALES DE CAMBIO DE DEUDOR SOLIDARIO:

El deudor solidario desiste.

Por muerte del deudor solidario.

El deudor solidario se declara en quiebra.

Deudor con pena privativa de libertad.

Secuestro.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

174

7.5 Anular créditos aprobados que no fueron legalizados

Código: NCR-SIS-005

Nombre: Anular créditos aprobados que no fueron legalizados

Elaborado por: Aprobado por:

Fecha de elaboración:

2007-05-07 Fecha de aprobación:

Objetivo Realizar la anulación de aquellos créditos que fueron aprobados en el comité y que el beneficiario no legalizo ante el gestor durante el plazo previsto en cada modalidad de crédito.(el plazo es parametrizable)

Descripción El sistema controla el tiempo que lleva la solicitud de crédito pendiente de legalizar si se pasa del tiempo anula estos créditos y le informa al beneficiario.

Actores Principales Sistema de crédito y cartera

Valida el tiempo que lleva la solicitud aprobada sin legalizar

Actores secundarios

Precondiciones: El beneficiario debe encontrarse aprobado por el comité de crédito en cualquiera de las modalidades de crédito o fondo.

El crédito no debe pasarse de los días estipulados para la legalización (definida en la parametrización)

Poscondiciones Anular aquellas solicitudes aprobadas y que no fueron legalizadas.

Secuencia normal de acciones:

1. El sistema revisa el tiempo que lleva la solicitud aprobada sin legalizar

2. El sistema anula las solicitudes que llevan más del tiempo estipulado por la modalidad de crédito

3. El sistema genera un mensaje para la sesión de los beneficiarios don de les informa la anulación del crédito

4. El sistema actualiza el repositorio 5. Fin del Proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) El sistema debe controlar los días que han pasado del tiempo de legalización. Si después del tiempo establecido por la modalidad de crédito no ha sido legalizado el sistema debe anulara el crédito y le debe avisar al beneficiario. Una vez cargada la información el sistema debe generar un

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

175

mensaje de confirmación de la anulación.

Disponibilidad La anulación de créditos aprobados pero no legalizados debe quedar en la base de datos del sistema de crédito para la consulta de los funcionarios del ICETEX. De igual manera debe quedar disponible en la sesión de cada beneficiario.

Seguridad El sistema debe tener parametrizado el tiempo para la legalización por modalidad de crédito y debe estar en la capacidad de anular las solicitudes que se pasen de este.

Gestionabilidad – Control del proceso En esta parte el proceso inicia en el estado de “crédito aprobado” y finaliza con un estado de “anulación de crédito aprobado”.

Auditoria Debe existir un repositorio que cuente con la siguiente información:

o Fecha de anulación del crédito. o Número del crédito o Observación de la anulación.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

176

7.6 Anular créditos cuando el beneficiario desiste en la confirmación de datos

Código: NCR-SIS-006

Nombre: Anular créditos

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-05-07 Fecha de aprobación:

Objetivo Realizar la anulación de aquellos créditos cuando no concuerdan los datos (ver nota 1), no se consigue el beneficiario para la verificación de datos o cuando el beneficiario desiste.

Descripción El funcionario de seguimiento al crédito durante de la etapa de otorgamiento verifica la información con el beneficiario y si existen inconsistencias en los datos que no pueden ser corregidos se anula el crédito. En el caso en que el beneficiario desiste del crédito en el momento de la confirmación de datos la solicitud también es anulada. El funcionario de seguimiento al crédito durante de la etapa de otorgamiento verifica la información ingresada por el beneficiario en el formulario de inscripción si al contactar al beneficiario encuentra inconsistencia en los datos registrados anula la solicitud.

Actores Principales Beneficiario Solicita la anulación del crédito aprobado

Seguimiento al crédito

Solicita la anulación de un crédito aprobado cuando el beneficiario expresa su deseo de desistir del crédito.

Actores secundarios Sistema de crédito y cartera Utiliza esta información para la actualización del historial del crédito. Solicita la anulación de un crédito aprobado cuando la información es inconsistente

Precondiciones: El beneficiario debe encontrarse aprobado por el comité de crédito en cualquiera de las modalidades de crédito .

Poscondiciones Crédito anulado

Secuencia normal de 1. El funcionario de seguimiento al crédito contacta al

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

177

acciones: beneficiario y verifica la información 2. El funcionario marca el crédito como anulado 3. Fin del proceso

Secuencias alternas 1a. El funcionario no contacta al beneficiario El crédito se anula y se termina el proceso.

1b. El beneficiario desiste del crédito Fin del proceso

1c. El funcionario no valida la información por inconsistencias en la información no subsanables y anula el crédito

Requerimientos no funcionales

Desempeño ( Rendimiento) El sistema debe subir la anulación del crédito máximo dos (2) segundos después de que el funcionario de seguimiento al crédito maraca el estado de desistido. Una vez cargada la información el sistema debe generar un mensaje de confirmación de la anulación.

Disponibilidad La anulación de créditos desistidos debe quedar en la base de datos del sistema de crédito para la consulta de los funcionarios del ICETEX. De igual manera debe quedar disponible en la sesión de cada beneficiario.

Seguridad El sistema debe solicitar un código de autenticación para que los funcionarios de crédito y cartera carguen las anulaciones. El sistema debe solicitar un código de autenticación para que el beneficiario entre a consultar el estado del crédito en su sesión.

Gestionabilidad – Control del proceso En esta parte el proceso inicia en el estado de “crédito aprobado” y finaliza en cualquiera de los siguientes estados: “anulación de crédito por solicitud del beneficiario”, “anulación de crédito por falsedad en información”. “anulación del crédito porque el beneficiario desistió”.

Auditoria

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

178

Debe existir un repositorio que cuente con la siguiente información:

o Fecha de anulación del crédito. o Número del crédito o Observación de la anulación. o Actor que realizo la anulación.

Notas y comentarios 1. La solicitud de crédito se anula porque:

Los datos de ubicación del beneficiario son falsos

Los datos del codeudor son falsos

Los datos de las referencias familiares son falsos.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

179

7.7 Aplazar la legalización del crédito

Código: NCR-SIS-007

Nombre: Aplazar la legalización del crédito

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-05-07 Fecha de aprobación:

Objetivo Registrar la legalización del crédito como aplazado. Servicio militar

Descripción El beneficiario envía carta al comité de crédito solicitando el aplazamiento de la legalización, el comité evalúa la solicitud y envía a la oficina de operaciones para que realice la marcación de aplazamiento

Actores Principales Beneficiario Solicita el aplazamiento de la legalización

Comité de crédito Evalúa la solicitud de aplazamiento de la legalización.

Vicepresidencia de fondos

alúa la solicitud de aplazamiento de la legalización

Oficina de operaciones

Marca e aplazamiento de la legalización en el sistema de crédito y cartera.

Actores secundarios Sistema de crédito y cartera

Utiliza esta información para la actualización del historial del crédito.

Precondiciones: El beneficiario debe encontrarse aprobado

El crédito no debe estar legalizado ante la IES

Poscondiciones Legalización aplazada por el tiempo estipulado por el comité de crédito y/o la vicepresidencia de fondos.

Secuencia normal de acciones:

1. El beneficiario envía carta al comité de crédito o vicepresidencia de fondos solicitando el aplazamiento de la legalización del crédito (Ver Nota 1)

2. El comité de crédito aprueba el aplazamiento y envía a la oficina de operaciones.

3. La persona asignada de operaciones ingresa al sistema y registra la marcación de aplazamiento y fecha de terminación del aplazamiento.

4. El sistema valida la información y actualiza el estado del crédito

5. Fin del Proceso.

Secuencias alternas

Requerimientos no Desempeño ( Rendimiento)

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

180

funcionales El sistema debe cargar las legalizaciones aplazadas máximo en dos (2) segundos por crédito. Una vez se carga esta información el sistema debe generar un mensaje de confirmación del aplazamiento de la legalización..

Disponibilidad El aplazamiento de la legalización debe quedar en la base de datos del sistema de crédito para la consulta de los funcionarios del ICETEX. De igual manera debe quedar disponible en la sesión de cada beneficiario.

Seguridad El sistema debe solicitar un código de autenticación para que los funcionarios del área de operaciones cargue el aplazamiento de la legalización. El sistema debe solicitar un código de autenticación para que el beneficiario entre a consultar el estado del crédito en su sesión.

Gestionabilidad – Control del proceso En esta parte el proceso finaliza con un estado de “aplazamiento de la legalización”.

Auditoria Debe existir un repositorio que cuente con la siguiente información:

o Fecha de aplazamiento de la legalización. o Actor que solicito el aplazamiento o Actor que autorizo el aplazamiento o Actor que realizo el cambio en el sistema

Notas y comentarios 1. El beneficiario puede aplazar la legalización del crédito por:

No tener la documentación completa.

No encontrarse el deudor para el diligenciamiento del pagare y carta de instrucciones.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

181

7.8 Realizar legalización del crédito fuera de los tiempos estipulados por el ICETEX

Código: NCR-SIS-008

Nombre: Realizar legalización del crédito fuera de los tiempos estipulados por el ICETEX

Elaborado por: Aprobado por:

Fecha de elaboración:

2007-05-07 Fecha de aprobación:

Objetivo Registrar la legalización de créditos que no fueron legalizados por el gestor dentro del calendario estipulado

Descripción El gestor envía una solicitud al ICETEX para legalizar créditos que no fueron legalizados dentro de las fechas estipuladas para ello. ICETEX realiza el estudio de la solicitud y aprueba la legalización extemporánea. Una vez se tiene la aprobación el funcionario designado entra al repositorio de créditos anulados lo saca de ahí y habilita la sesión del gestor para la legalización del crédito (puede ser individual o consolidada

Actores Principales Gestor

Solicita la legalización extemporánea de los créditos que no se legitimaron durante el periodo establecido.

Comité de crédito y cartera Evalúa la solicitud de legalización extemporánea

Vicepresidencia de Fondos Evalúa la solicitud de legalización extemporánea

Analista de crédito Carga la información de créditos legalizados extemporáneamente en el sistema de crédito y cartera

Analista de fondos Carga la información de créditos legalizados extemporáneamente en el sistema de crédito y cartera

Actores secundarios Sistema de crédito y cartera Utiliza esta información para la actualización del historial del crédito.

Precondiciones: El beneficiario debe encontrarse aprobado

El crédito no debe estar legalizado

Debe existir la solicitud de renovación extemporánea.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

182

Poscondiciones Legalización extemporánea del crédito.

Secuencia normal de acciones:

1. El gestor envía la solicitud al ICETEX solicitando la legalización del crédito

2. ICETEX estudia la solicitud y la aprueba 3. El funcionario de operaciones ingresa al sistema y va al

módulo donde esta los créditos anulados lo desmarca le coloca la respectiva observación y le coloca el nuevo tiempo para la legalización.

4. El sistema automáticamente lo saca del listado de anulados y habilita la opción de legalización extemporánea en la sesión de los gestores de los créditos.

5. El sistema le envía un mensaje al gestor del crédito donde le confirma que esta habilitado para realizar la legalización extemporánea

6. Fin del Proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) El Funcionario de operaciones debe cargar el listado de créditos con legalización extemporánea el mismo día que fue aprobado por el comité de crédito. El sistema debe controlar los créditos a los que se les hace a demarcación de anulados y los que tiene aprobado la legalización extemporánea. El sistema debe guardar el tiempo para la legalización extemporánea en cada crédito. Una vez cargada la demarcación de los créditos anulados en el sistema debe generar un mensaje de confirmación. Cuando se habilita la opción de legalización extemporánea el sistema debe informarlo en la sesión del gestor del crédito.

Disponibilidad La legalización extemporánea debe quedar en la base de datos del sistema de crédito para la consulta de los funcionarios del ICETEX. De igual manera debe quedar disponible en la sesión de cada beneficiario.

Seguridad

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

183

El sistema debe solicitar un código de autenticación para que los analistas de crédito y/o fondos carguen la legalización extemporánea.

Gestionabilidad – Control del proceso En esta parte el proceso inicia con un estado de bloqueo por no legalización y termina en un estado “legalización extemporánea”.

Auditoria Debe existir un repositorio que cuente con la siguiente información (también debe quedar en el historial de cada crédito):

o Fecha de demarcación del crédito anulado o observación de la demarcación. o Fecha de habilitación de la legalización

extemporánea. o Tiempo definido para la legalización extemporánea o Número del crédito o Actores que aprobaron la legalización

extemporánea o Motivos de la legalización extemporánea.

(documentos soporte y su ubicación) o Actor que realizo la legalización extemporánea en el

sistema

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

184

7.9 Reversar la legalización

Código: NCR-SIS-009

Nombre: Reversar la legalización

Elaborado por: Aprobado por:

Fecha de elaboración:

2007-05-07 Fecha de aprobación:

Objetivo Realizar la demarcación de la legalización del crédito cuando el gestor del crédito (IES o tercero) se equivoca.

Descripción El analista de crédito y/o fondos realiza la reversión de la legalización cuando lo solicita el beneficiario, la IES o existen inconsistencias en el proceso. Cuando la IES se equivoca y gestión documental no visa

Actores Principales Gestor Solicita la reversión de la legalización

Beneficiario Solicita la reversión de la legalización

Seguimiento al crédito

Solicita la reversión de la legalización por inconsistencia en la información

Analista de crédito Carga la información de la reversión de la legalización en el sistema de crédito y cartera.

Analista de fondos Carga la información de la reversión de la legalización en el sistema de crédito y cartera.

Actores secundarios Sistema de crédito y cartera

Utiliza esta información para la actualización del historial del crédito.

Precondiciones: El crédito debe estar legalizado

Debe existir la solicitud de reversión de la legalización.

Poscondiciones Legalización reversada y pendiente de legalizar.

Secuencia normal de acciones:

1. El gestor del crédito informa a la oficina de seguimiento al crédito (con soporte; carta, correo electrónico) la reversión de la legalización (Ver Nota 1)

2. El analista de crédito y/o fondos ingresa a la opción de reversión de la legalización

3. El sistema presenta la lista de beneficiarios legalizados 4. El analista de crédito y/o fondos selecciona el beneficiario 5. El sistema presenta los datos del beneficiario y una opción

para confirmar la reversión de la legalización 6. El analista de crédito y/o fondos confirma la reversión de la

legalización y graba

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

185

7. Fin del Proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) El analista de crédito y/o el analista de fondos debe cargar el listado de reversiones de legalización diariamente y debe tener como llave el número de crédito. Una vez se carga esta información el sistema debe generar un mensaje de confirmación de la reversión.

Disponibilidad La reversión de la legalización debe quedar en la base de datos del sistema de crédito para la consulta de los funcionarios del ICETEX. De igual manera debe quedar disponible en la sesión de cada beneficiario.

Seguridad El sistema debe solicitar un código de autenticación para que los funcionarios de crédito y cartera carguen la reversión de la legalización. El sistema debe solicitar un código de autenticación para que el beneficiario entre a consultar el estado del crédito en su sesión.

Gestionabilidad – Control del proceso En esta parte el proceso finaliza con un estado de “reversión de la legalización”

Auditoria Debe existir un repositorio que cuente con la siguiente información:

o Fecha de reversión de la legalización. o Motivo de la reversión de la legalización o Actor que solicito la reversión. o Actor que realizo la reversión.

Notas y comentarios 1. La legalización se puede reversar por:

Marcación incorrecta de los documentos entregados por el beneficiario

Valor de la matricula errónea

Documentos inconsistentes

Solicitud del beneficiario.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

186

7.10 Cambio de IES y/o programa académico solicitado por el estudiante

Código: NCR-SIS-010

Nombre: Cambio de IES y/o programa académico solicitado por el estudiante

Elaborado por: Aprobado por:

Fecha de elaboración:

2007-05-07 Fecha de aprobación:

Objetivo Realizar la actualización de la IES y/o programa académico.

Descripción El beneficiario envía carta al comité de crédito y/o a la vicepresidencia de fondos solicitando el cambio de la IES, el ICETEX evalúa la solicitud y envía a la oficina de operaciones para que realice el cambio de IES *Para poder realizar el cambio la IES y/o programa académico debe estar acreditado por el SNIES y debe cumplir con las políticas fijadas por el ICETEX para este caso.

Actores Principales Beneficiario Solicita cambio de IES y/o programa académico

Comité de crédito Evalúa el cambio de IES y/o programa académico

Vicepresidencia de fondos

Evalúa el cambio de IES y/o programa académico

Analista de crédito Carga el cambio de IES y/o programa académico en el historial del crédito y en el sistema de crédito y cartera.

Analista de fondos Carga el cambio de IES y/o programa académico en el historial del crédito y en el sistema de crédito y cartera.

Actores secundarios Sistema de crédito y cartera

Utiliza esta información para la actualización del historial del crédito.

Precondiciones: El beneficiario debe encontrarse aprobado

El crédito no debe estar legalizado ante la IES

Poscondiciones IES actualizada para legalización

Secuencia normal de acciones:

1. El beneficiario envía carta al ICETEX la solicitud de cambio de IES.

2. El ICETEX aprueba el cambio y envía a la oficina de operaciones.

3. La persona asignada de operaciones ingresa a la opción de cambio de información académica

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

187

4. El sistema presenta en pantalla la información de la universidad y carrera

5. La Persona asignada de operaciones realiza el cambio de IES, confirma la carrera y graba.

6. El sistema valida la información y guarda los datos actualizados

7. Fin del Proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) El analista de crédito y/o el analista de fondos debe cargar el listado de cambio de IES y/o programa académico en el historial del crédito y en el sistema de crédito y cartera diariamente. El sistema debe demorarse máximo dos (2) segundos en el cargue de esta información en cada crédito. Una vez se carga esta información el sistema debe generar un mensaje de confirmación del cambio.

Disponibilidad El cambio de IES y/o programa académico debe quedar en la base de datos del sistema de crédito para la consulta de los funcionarios del ICETEX. De igual manera debe quedar disponible en la sesión de cada beneficiario.

Seguridad El sistema debe solicitar un código de autenticación para que los funcionarios de crédito y cartera el cambio de IES y/o programa académico El sistema debe solicitar un código de autenticación para que el beneficiario entre a consultar el estado del crédito en su sesión.

Gestionabilidad – Control del proceso En esta parte el proceso finaliza con un estado de “cambio de IES y/o programa académico”.

Auditoria Debe existir un repositorio que cuente con la siguiente información:

o Fecha de cambio de IES y/o programa académico o Actor que solicito el cambio o Motivo del cambio

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

188

o Actor que autorizo el cambio o Actor que realizo el cambio en el sistema

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

189

7.11 Bloquear créditos

Código: NCR-SIS-011

Nombre: Bloquear créditos

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-07-12 Fecha de aprobación:

Objetivo Bloquear los créditos cuando cumple alguna de las causales

Descripción El sistema con la generación de los cierres presenta los créditos que son susceptibles de bloqueo. Los créditos se pueden bloquear cuando:

Suspensión del estudiante por parte de la Institución de Educación Superior y/o Escuela Normal Superior.

Repetición de un período académico ya financiado.

Cambio de centro docente o de programa de estudios que implique nivelación hasta por dos períodos académicos.

No estar al día en el cumplimiento de las obligaciones con el ICETEX.

Información inconsistente del núcleo familiar

Información inconsistente de la información académica.

Información inconsistente de la información de referencias personales.

Información inconsistente del Deudor Solidario

Información inconsistente de la Garantía

No actualización de la identificación del Beneficiario: (Tarjeta de identidad vencida).

Supero número de aplazamientos permitidos en el sistema.

Inconsistencia en el estrato reportado.

Convenio suspendido.

Actores Principales Cierre diario Informa que beneficiarios tienen el documento de identificación vencido

Cierre mensual Presenta el listado de créditos en mora de sus obligaciones

Cierre por periodo académico

Presenta el listado de beneficiarios que no realizaron actualización de datos durante el periodo académico

Registraduría Nacional del Estado

Colabora en el proceso de validación de números de identificación.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

190

Civil (RNEC)

Sistema de crédito y cartera

. Marca automáticamente los créditos bloqueados

Actores secundarios .

Precondiciones: El crédito debe estar activo

Poscondiciones Crédito bloqueado por:

Suspensión del estudiante por parte de la Institución de Educación Superior y/o Escuela Normal Superior.

Repetición de un período académico ya financiado.

Cambio de centro docente o de programa de estudios que implique nivelación hasta por dos períodos académicos.

No estar al día en el cumplimiento de las obligaciones con el ICETEX.

Información inconsistente del núcleo familiar

Información inconsistente de la información académica.

Información inconsistente de la información de referencias personales.

Información inconsistente del Deudor Solidario

Información inconsistente de la Garantía

No actualización de la identificación del Beneficiario: (Tarjeta de identidad vencida).

Supero número de aplazamientos permitidos en el sistema.

Inconsistencia en el estrato reportado.

Convenio suspendido.

Secuencia normal de acciones:

1. El sistema genera los respectivos cierres 2. El sistema genera el listado de créditos bloqueados con su

respectiva causa. 3. El listado marca los créditos como bloqueados. 4. Fin del proceso

Secuencias alternas 2a. Cuando hay créditos bloqueados inconsistencias en el documento de identificación:

1. El sistema envía los datos a la Registraduría Nacional del Estado Civil para que sean verificados

2. La Registraduría Nacional Del Estado civil cruza la información enviada y envía al ICETEX información acerca del estado de los documentos

3. La oficina de operaciones actualiza la información y

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

191

bloquea los documentos no coincidentes (Ver Nota 1) 4. El sistema marca y guarda la información 5. El funcionario del área de operaciones envía la

información a seguimiento al crédito para que contacte al solicitante y verifique el número de documento.

6. Fin del Proceso.

Requerimientos no funcionales

Desempeño ( Rendimiento) El sistema en la generación de cada cierre debe avisar que créditos están bloqueados al área de operaciones y en las sesiones de los beneficiarios y de los gestores del crédito..

Disponibilidad Los bloqueos de créditos deben quedar en la base de datos del sistema de crédito para la consulta de los funcionarios del ICETEX. De igual manera debe quedar disponible en la sesión de cada beneficiario.

Seguridad

Gestionabilidad – Control del proceso En esta parte el proceso finaliza con alguno de los siguientes estados de bloqueo: o Suspensión del estudiante por parte de la Institución de

Educación Superior y/o Escuela Normal Superior. o Repetición de un período académico ya financiado. o Cambio de centro docente o de programa de estudios que

implique nivelación hasta por dos períodos académicos. o No estar al día en el cumplimiento de las obligaciones con

el ICETEX. o Información inconsistente del núcleo familiar o Información inconsistente de la información académica. o Información inconsistente de la información de referencias

personales. o Información inconsistente del Deudor Solidario o Información inconsistente de la Garantía o No actualización de la identificación del Beneficiario:

(Tarjeta de identidad vencida). o Supero número de aplazamientos permitidos en el

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

192

sistema. o Inconsistencia en el estrato reportado. o Convenio suspendido.

Auditoria Debe existir un repositorio que cuente con la siguiente información:

o Fecha de bloqueo. o Motivo de bloqueo o Cierre en el que se generó el bloqueo.

Notas y comentarios 1. Para el caso de los fondos cerrados la oficina de operaciones envía la lista de beneficiarios no coincidentes para que sean validados por ellos y reenviados nuevamente al ICETEX para su validación ante la Registraduría nacional del estado civil y así poder quitar la marca de bloqueo.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

193

7.12 Terminación del crédito

Código: NCR-SIS-012

Nombre: Terminación del crédito

Elaborado por: Olga Alejandra Pantoja R.

Aprobado por:

Fecha de elaboración:

2007-05-10 Fecha de aprobación:

Objetivo Realizar la marcación de crédito terminado

Descripción La persona asignada de operaciones marca el crédito como terminado cuando el crédito cumple algunas de las causales de terminación (ver nota 1). *En el cierre académico también se definen los créditos susceptibles a terminación.

Actores Principales Oficina de operaciones:

Es la encargada de marcar el crédito como terminado.

Cierre mensual Presenta el listado de créditos terminados

Cierre por periodo académico

Genera el listado de créditos susceptibles de terminación.

Actores secundarios Sistema de crédito y cartera

Utiliza esta información para la actualización del historial del crédito.

Precondiciones: El beneficiario debe cumplir alguna de las causales de terminación del crédito

Poscondiciones Crédito terminado

Secuencia normal de acciones:

1. El sistema presenta la lista de los beneficiarios identificados por modalidad de crédito

2. El funcionario de operaciones selecciona el beneficiario 3. El sistema presenta los datos de cartera y el saldo a la fecha 4. El funcionario de operaciones marca el crédito como

terminado y justificación de la marcación. 5. El sistema valida y guarda la información 6. Fin del Proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) El sistema debe cargar el listado de créditos susceptibles a terminación en el cierre de periodo académico. Una vez se carga esta información el sistema debe generar un mensaje de confirmación de la información.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

194

Disponibilidad La terminación del crédito debe quedar en la base de datos del sistema de crédito para la consulta de los funcionarios del ICETEX. Adicionalmente esta información debe quedar en el sistema de cartera para la liquidación del crédito y la generación del plan de pagos (periodo de gracia y época de amortización).De igual manera debe quedar disponible en la sesión de cada beneficiario.

Seguridad El sistema debe solicitar un código de autenticación para que los funcionarios de operaciones realicen la terminación del crédito. El sistema debe solicitar un código de autenticación para que el beneficiario entre a consultar el estado del crédito en su sesión.

Gestionabilidad – Control del proceso En esta parte el proceso puede entrar de alguno de los siguientes estados: Aplazamiento, bloqueo, crédito en época de estudio y finaliza con un estado de “crédito terminado”.

Auditoria Debe existir un repositorio que cuente con la siguiente información:

o Fecha de terminación del crédito o Motivo de la terminación. o Actor que solicito la terminación. o Actor que realizo la terminación.

Notas y comentarios 1. Los motivos de terminación del crédito son por :

Crédito en ceros

Muerte del beneficiario

Por solicitud del estudiante

Supera numero de aplazamientos

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

195

8. CARTERA EN EPOCA DE ESTUDIO

8.1 Aplicar Giros de Adjudicación y Renovación

Código: CEE-SIS-001

Nombre: Aplicar Giros de Adjudicación y Renovación.

Elaborado por: William Gerardo C Aprobado por:

Fecha de elaboración:

2007-04-24 Fecha de aprobación:

Objetivo Actualizar el saldo de los créditos que corresponden a giros de renovación y crear el crédito para los giros de adjudicación. La aplicación del giro se hará solo si el crédito tiene habilitada la opción de permitir aplicación automática de giro.

Descripción El modulo de crédito informará de los giros en firmes pendientes de aplicar en cartera y el sistema los aplicará en cartera.

Actores Principales Caso de uso de Crédito-.

Ejecutará este caso de uso.

Actores secundarios

Precondiciones: El crédito debe estar en época de estudio si el giro corresponde a una solicitud de renovación.

Para giros de renovación debe existir la constitución de cartera.

Poscondiciones Actualización de los saldos de los créditos para los giros que correspondan a una renovación.

Creación del plan de cuotas(para los giros de adjudicación y renovación). Este plan de cuotas corresponde a las cuotas que debe cancelar el beneficiario por el giro otorgado.

Creación del crédito para los giros de adjudicación.

Respuesta a Crédito de la aplicación del giro : 1. Exitosa 2. No exitosa y la causa.

Secuencia normal de acciones:

Por cada giro pendiente de aplicar que se recibe de crédito : 1. El sistema determina si el giro a aplicar corresponde a una

adjudicación (primer giro) y le constituye la cartera (ver caso de uso constituir cartera: CEE-SYS-002).

2. El sistema crea el plan de cuotas para el giro aplicado ya sea de adjudicación o renovación. (Ver caso de uso Generar plan de de cuotas para el giro aplicado).

3. El sistema aplica el giro incrementando el saldo de capital

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

196

del crédito por el valor del giro. 4. El sistema registra la transacción del giro aplicado. (ver caso

de uso registrar información de la transacción: CEE-SYS-005).

5. El sistema retorna una respuesta a crédito indicando de la aplicación del giro o de la no aplicación del giro y su causa.

6. Fin del proceso.

Secuencias alternas 2a. El sistema no aplica el giro por inconsistencias ( p.e inconsistencias de codificación):

Vicepresidencia de Operaciones y Tecnología genera informe de los giros en firme rechazados con la causa de la no constitución que quedó registrado en el sistema financiero del ICETEX.

Vicepresidencia de crédito y cobranzas o fondos revisa, corrige y aplica de forma manual el giro por medio de la novedad aplicar giro.

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la transacción fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

Seguridad

El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución de la transacción. El sistema debe solo habilitar esta opción sobre los créditos que puede gestionar el usuario. El sistema debe validar que el usuario que esta realizando la transacción tenga autorización para ejecutarla en ese horario.

Gestionabilidad (Control del Proceso) No genera cambio de estado.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

197

Auditoria Debe quedar registrado en el sistema el usuario, la fecha, hora, origen que originó la transacción y número de resolución.

Notas y comentarios 1. Los giros que se realizaron en dólares se registran y se manejan en pesos (moneda local). La conversión a pesos del giro se realiza con la TRM del día con que el banco le consignó a la cuenta del beneficiario. Cuando cartera lee el giro en el modulo financiero del sistema apoteosys lee el valor en pesos para su aplicación.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

198

8.2 Constituir Cartera

Código: CEE-SIS-002

Nombre: Constituir Cartera

Elaborado por: William Gerardo C Aprobado por:

Fecha de elaboración:

2007-05-07 Fecha de aprobación:

Objetivo Obtener el número que va a identificar la obligación en cartera y generar el plan de cuotas del giro a cancelar durante la época de estudio.

Descripción La constitución de cartera hace referencia al nacimiento de la obligación en cartera. Es decir cuando se carga (se aplica) en cartera el primer giro.

Actores Principales Caso de uso aplicar Giro Ejecuta este caso de uso

Actores secundarios

Precondiciones: El giro de estar en firme y debe ser de adjudicación.

Poscondiciones Obtener el número de Crédito

Generación del plan de cuotas.

Crear el histórico y consolidado del crédito.

Secuencia normal de acciones:

1. El sistema recibe el giro de adjudicación para constituir la cartera.

2. El sistema genera el número de crédito.(ver nota 1) 3. El sistema crea el saldo de capital del crédito. 4. El sistema registra el número de resolución para determinar

que giro generó el crédito. 5. El sistema genera y registra el plan de cuotas. (ver caso de

uso plan de cuotas). 6. El sistema incorpora y registra la operación en cartera. 7. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

199

cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la transacción fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución de la transacción. El sistema debe solo habilitar esta opción sobre los créditos que puede gestionar el usuario. El sistema debe validar que el usuario que esta realizando la transacción tenga autorización para ejecutarla en ese horario.

Gestionabilidad (Control del Proceso) No se modifica el estado pero si el caso de uso que utiliza este caso.

Auditoria Debe quedar registrado en el sistema el usuario, la fecha, hora y origen que originó la transacción.

Notas y comentarios 1. El número de crédito será un consecutivo asignado por el sistema desde el primer desembolso (nacimiento de la cartera) sin restricción de longitud.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

200

8.3 Generar Plan de cuotas durante la época de estudios

Código: CEE-SIS-003

Nombre: Generar Plan de cuotas durante la época de estudios

Elaborado por: William Gerardo C Aprobado por:

Fecha de elaboración:

2007-04-24 Fecha de aprobación:

Objetivo Hacer la liquidación de las cuotas del giro aplicado que el beneficiario debe pagar durante la época de estudios.

Descripción El sistema debe realizar la liquidación de cuotas de pago que deben ser canceladas en la época de estudios detallando sus componentes (valor, tasa de interés y fecha de pago) y los rubros a cobrar asociados al plan en aquellas modalidades y fondos que tienen establecido el recaudo de dinero durante la época de ejecución del crédito.

Actores Principales Caso de uso Constituir Cartera Ejecuta este caso de uso

Actores secundarios

Precondiciones: La modalidad de crédito y/o fondo debe tener establecido las condiciones de liquidación de cuotas en época de estudio.

El crédito debe estar en época de estudio y poseer un saldo mayor a cero.

El crédito debe tener constituida la cartera y la aplicación de giros.

Poscondiciones Plan de cuotas.

Secuencia normal de acciones:

1. El sistema lee las condiciones que aplican para el crédito ( ver nota 1).

2. El sistema controla la periodicidad para generar el plan de cuotas. (depende de la parametrización del la línea del giro que se realice.)

3. El sistema genera el plan de cuotas del giro. (ver nota 2). 4. El sistema registra el plan de cuotas del crédito. 5. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para transacciones de corta duración.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

201

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la transacción fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución de la transacción. El sistema debe solo habilitar esta opción sobre los créditos que puede gestionar el usuario. El sistema debe validar que el usuario que esta realizando la transacción tenga autorización para ejecutarla en ese horario.

Gestionabilidad (Control del Proceso) No modifica el estado del crédito.

Auditoria Debe quedar registrado en el sistema el usuario, la fecha, hora y origen que originó la transacción.

Notas y comentarios 1. Condiciones del crédito:

Fecha de Inicio

Valor del Crédito

Tasa de Interés: Toma la tasa menor entre la tasa definida y la tasa de interés de usura definida.

Modalidad de pago

Día de Corte

Número de Cuotas

Nivel de formación

Estrato

Factor de cuota

Formulación asociada para la liquidación de cuotas. 2. El plan de cuotas registra la siguiente información :

Número de Cuota.

Fecha de pago.

Valor cuota.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

202

Altura

Valor Intereses Corrientes.

Valor Abono a capital.

Valor saldo de capital.

Prima de seguro.

Época.

El plan será recalculado por novedades que impliquen este cambio. Los componentes de las cuotas y datos de la obligación van a depender de la formulación y de los rubros asociados al plan. El sistema debe almacenar internamente la distribución de los componentes de capital, interés corriente y mora por fuente de financiación. Pero esta información no se le informará al beneficiario, es únicamente para el manejo interno del crédito.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

203

8.4 Aplicar Recaudos Época de Estudio.

Código: CEE-SIS-004

Nombre: Aplicar Recaudos Época de Estudio

Elaborado por: William Gerardo C Aprobado por:

Fecha de elaboración:

2007-04-24 Fecha de aprobación:

Objetivo Actualizar el saldo de los créditos y generar el registro del movimiento de los recaudos aplicados.

Descripción El sistema aplica los recaudos pendientes de aplicar que se encuentren disponibles en el sistema.

Actores Principales Funcionario de de vicepresidencia de operaciones y tecnología.

Habilita o deshabilita el servicio Publicación/Suscripción.

Servicio de Cartera: Consulta el repositorio del modulo financiero del sistema financiero del ICETEX la existencia de giros en firme pendientes de aplicar para su respectivo cargue. Marca en el sistema financiero del ICETEX la aplicación y no aplicación de estos giros.

Actores secundarios

Precondiciones: El sistema (de tesorería) debe enviar una notificación de que hay recaudos pendientes de aplicar a Cartera.

Poscondiciones Recaudo aplicado.

Recaudo no aplicado.

Secuencia normal de acciones:

El sistema de cartera recibe notificación del sistema financiero de la existencia de recaudos pendientes de aplicar. Y por cada recaudo realiza lo siguiente: 1. El sistema aplica el valor del recaudo a los diferentes

componentes en el orden establecido por fuente de financiación. (ver nota 1).

2. El sistema registra la transacción del recaudo aplicado. 3. El sistema informa al sistema financiero de la aplicación del

recaudo o el rechazo del recaudo y su causa por medio de

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

204

un servicio. 4. El sistema registra en un repositorio los resultados de la

aplicación del recaudo exitosa o no exitosa con el fin de que se pueda consultar e imprimir.

5. Fin del proceso.

Secuencias alternas 1 .Orden de aplicación de los componentes del crédito: Se referencia siempre desde la cuota más antigua y por cada una se cancela en el siguiente orden: Otros conceptos según modalidad, prima de seguro, interés mora, interés corriente y finalmente se amortiza a capital. 2. Para el caso de que el valor aplicado del recaudo supere el valor esperado: se aplicara a capital, siempre y cuando este definido como aplicación por defecto o ese excedente se aplicará como lo solicite el beneficiario (por ejemplo abono a cuota futura).

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la transacción fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución de la transacción. El sistema debe solo habilitar esta opción sobre los créditos que puede gestionar el usuario. El sistema debe validar que el usuario que esta realizando la transacción tenga autorización para ejecutarla en ese horario.

Gestionabilidad (Control del Proceso) Debe registrarse el posible cambio de estado de etapa de estudio atrasado en pago de cuota moderadora a etapa de estudio al día.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

205

Auditoria Debe quedar registrado en el sistema El usuario, la fecha, hora y origen que originó la transacción.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

206

8.5 Registrar información de la transacción realizada

Código: CEE-SIS-005

Nombre: Registrar información de la transacción realizada.

Elaborado por: William Gerardo C Aprobado por:

Fecha de elaboración:

2007-04-24 Fecha de aprobación:

Objetivo Registrar toda la información relacionada con la transacción realizada.

Descripción El sistema registra la información relacionada con la transacción. Este registro queda disponible para los procesos de contabilidad que requieren de esta información para la generación de los movimientos contables. Pero se requiere que se almacene toda la información necesaria para poder realizar la contabilización y auditoria de la transacción.

Actores Principales Todos los casos de uso que generen transacción en el sistema.

Ejecutan este caso de uso.

Actores secundarios

Precondiciones:

Poscondiciones Transacción registrada.

Secuencia normal de acciones:

1. El Caso de uso que genera la transacción. 2. El sistema registra la transacción con información necesaria

para contabilidad y auditoria. (Ver nota 1).

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no debe superar los 0.1 segundos.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres.

Seguridad El sistema debe con mecanismos de autenticación para autorizar la ejecución del proceso.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

207

Gestionabilidad (Control de Procesos) Deben quedar registrados en el sistema todos los eventos que se presentaron en la ejecución del proceso.

Notas y comentarios 1. Información que debe quedar registrada del movimiento en el sistema :

Secuencial del movimiento

Secuencial del movimiento consolidado

Tipo de movimiento (Si genera o no genera contabilidad).

Concepto del movimiento (Concepto que indica el perfil contable asociado al movimiento, necesario para contabilizar a las cuentas definidas en el perfil).

Calificación del crédito (A,B,C,D,E)

Calificación de alineación.

Estado del Movimiento: Sin generación interfaz contable Interfaz contable generada Error Generación Interfaz Contable Consolidado Interfaz Contable Enviado a Contabilidad Rechazado de Contabilidad.

Fecha del movimiento

Fecha de aplicación

Valor del movimiento

Usuario del movimiento

Origen del movimiento (Lugar donde se realizó el movimiento).

Fuente de recurso: Fondos, ICETEX, Alianzas.

Destino del giro

Numero de resolución

Cuenta destino del giro

Identificación del beneficiario del pago

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

208

8.6 Consultar Crédito

Código: CEE-SIS-006

Nombre: Consultar Crédito

Elaborado por: William Gerardo C Aprobado por:

Fecha de elaboración:

2007-04-24 Fecha de aprobación:

Objetivo Consultar las operaciones de crédito bajo distintos parámetros.

Descripción El usuario podrá consultar la información del crédito.

Actores Principales Funcionario de Cartera

Atención al usuario.

Seguimiento al crédito

Consulta los créditos relacionados a su línea que administre o gestione y sobre los cuales tenga acceso.

Actores secundarios

Precondiciones: Privilegio de Consulta.

Poscondiciones Información detallada del crédito.

Secuencia normal de acciones:

1. El usuario selecciona la opción de consulta del crédito. 2. El sistema presenta distintos filtros para realizar la búsqueda de

los créditos. (ver nota 1). 3. El usuario ingresa datos en los filtros para realizar la búsqueda. 4. El sistema muestra los créditos que cumplen con los datos

ingresados en los filtros. 5. El usuario selecciona el crédito del que desea el detalle del

crédito. 6. El sistema muestra la información básica del crédito y diferentes

opciones para consultar los diferentes ítems del crédito. (ver nota 2).

7. fin del proceso

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la transacción fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

209

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución de la transacción.

Gestionabilidad (Control del Proceso) No cambia estado del crédito.

Notas y comentarios 1. Filtros para consultar el crédito :

número del crédito.

número de identificación.

apellidos

nombres

Gestores: por IES, alianzas, entre otros

número de identificación

número de operación migrada 2. Ítems del Crédito:

Datos Generales

Condiciones

Rubros

Deudores

Garantías

Consulta de Tasas

Estado Actual o Estado del Crédito (ver documento de estados). o Estado en Cartera (ver documento de estados). o Días de Mora o Historial de Estados de las solicitudes asociadas al

crédito con los datos siguientes. Número de Solicitud Tipo Solicitud: Adjudicación o Renovación. Rubro: Matricula, Sostenimiento. Estado Solicitud (ver documento de

estados). Fecha de asignación del estado. Número de Periodo Académico Año Número en la Frecuencia académica

definida para el año.

Para semestres serian 1 y 2.

Para trimestres serían 1,2,3 y 4.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

210

Condiciones de Pago

Giros

Abonos

Garantías

Novedades realizadas al crédito.

3. Todas las consultas tendrán la opción de ser impresas.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

211

9. CARTERA EN ETAPA FINAL DE AMORTIZACIÓN

9.1 Pasar crédito a etapa final de amortización.

Código: CEA -SIS-001

Nombre: Pasar Crédito a etapa final de amortización.

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-16 Fecha de aprobación:

Objetivo Realizar el paso de los créditos que se encuentran en época de estudio o en periodo de gracia a etapa final de amortización.

Descripción El sistema realiza el paso de los créditos que se encuentren en época de estudio o en periodo de gracia a etapa final de amortización. Este paso consiste en determinar el saldo total del crédito que se encuentra con causal de terminación en etapa de estudio o periodo de gracia y trasladarlo a etapa final de amortización para generar el plan de cuotas respectivo. El saldo que se traslada corresponde a la sumatoria de los componentes: capital, intereses, prima de seguro y demás conceptos adeudados.

Actores Principales Caso de Uso Cierre Diario

Ejecuta al paso de los créditos a época de amortización.

Actores secundarios

Precondiciones: Estado de terminación del crédito en época de estudio.

Vencimiento del periodo de gracia.

Solicitud expresa del beneficiario.

Poscondiciones 1. Cerrar saldo crédito en época de estudios. 2. Saldo inicial para etapa final de amortización. 3. Generación plan de pagos. 4. Cambio de estado del crédito a etapa final de amortización. 5. Alimentar el repositorio de créditos trasladados a amortización

este.

Secuencia normal de acciones:

El caso de uso de cierre diario dispara la ejecución del paso de los créditos a etapa final de amortización para aquellos que sufrieron este cambio. Por cada crédito realiza lo siguiente:

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

212

1. El sistema valida que tenga una causal de terminación o que

se encuentre en periodo de gracia. 2. El sistema calcula el saldo insoluto a la fecha del crédito que

pasará a la etapa final de amortización. 3. El sistema aplica las condiciones de tasa de interés, tipo de

amortización, plazo, valor de cuota definidas en la modalidad de crédito del beneficiario.

4. El sistema cambia el estado del crédito a etapa final de amortización.

5. El sistema genera el plan de pagos de acuerdo a las opciones confirmadas.

6. El sistema presenta mensaje de paso a amortización realizado con éxito.

7. El sistema genera carta al beneficiario y al deudor solidario ratificando condiciones de amortización del crédito. El texto de la carta debe poseer una funcionalidad para su administración dinámica.

8. El sistema genera plan de cuotas para ser entregado al beneficiario. (Se tendrá la opción de impresión para entrega al beneficiario).

9. El sistema registra en el repositorio de créditos trasladados a amortización la información del traslado (indicando que el origen corresponde a paso automático en el cierre).

10. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la transacción fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución de la transacción. El sistema debe solo habilitar esta opción sobre los créditos

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

213

que puede gestionar el usuario. El sistema debe validar que el usuario que esta realizando la transacción tenga autorización para ejecutarla en ese horario.

Gestionabilidad (Control del Proceso) Debe registrarse el cambio de estado de etapa de estudio o periodo de gracia a etapa final de amortización

Auditoria Debe quedar registrado en el sistema el usuario, la fecha, hora y origen que originó la transacción.

Notas y comentarios 1. La información registrada en el repositorio debe contener las condiciones e información básica:

Nombre beneficiario

Número de crédito

Modalidad de crédito

Saldo total a amortizar

Número de cuotas

Valor de cuota

Fecha de vencimiento 2. El ingreso de la causal de terminación se generara extraordinariamente por parte de los contratistas o funcionarios

3. Causales de terminación: (ver documentos de estados).

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

214

9.2 Generar Plan de cuotas para etapa de final de amortización.

Código: CEA-SIS-002

Nombre: Generar Plan de cuotas para etapa final de amortización.

Elaborado por: William Gerardo C Aprobado por:

Fecha de elaboración:

2007-04-24 Fecha de aprobación:

Objetivo Generar el plan de cuotas sobre el saldo total consolidado en el momento que el crédito pasa a etapa final de amortización.

Descripción El sistema debe generar las cuotas que debe pagar el beneficiario en función del tipo de plan de amortización, plazo, saldo, tasa de interés, fechas de vencimiento y los rubros definidos para el plan de etapa final de amortización según la modalidad.

Actores Principales Caso de uso Pasar crédito de época de estudio a época de amortización. Que es invocado desde el Cierre Diario o desde la novedad.

Ejecuta este caso de uso.

Actores secundarios

Precondiciones: Ejecución del caso de uso cambiar estados que se ejecuta en el cierre diario.

Consolidación del saldo en época de estudio que va a constituir el saldo de capital inicial en época de amortización.

Poscondiciones Plan de cuotas del crédito.

Publicación del plan de cuotas en la web.

Secuencia normal de acciones:

El sistema consulta los créditos en etapa final de amortización que no se les ha generado el plan de cuotas. Y por cada crédito realiza lo siguiente: 1. El sistema lee las condiciones del crédito para la generación

de las cuotas. (ver nota 1). 2. El sistema genera el plan de cuotas (ver nota 2).

Discriminando los componentes de Capital, Interés Corriente e Interés de Mora por fuente de financiación. Aclarando que el plan de cuotas que se presenta al beneficiario se mostrarán los componentes de Capital, Interés Corriente e Interés de

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

215

Mora de manera totalizada ( No discriminada por fuente de financiación).

3. El sistema registra el plan de cuotas de etapa final de amortización con estado vigente.

4. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la transacción fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución de la transacción. El sistema debe solo habilitar esta opción sobre los créditos que puede gestionar el usuario. El sistema debe validar que el usuario que esta realizando la transacción tenga autorización para ejecutarla en ese horario.

Gestionabilidad (Control del Proceso) Debe registrarse el posible cambio de estado de etapa de estudio atrasado en pago de cuota moderadora a etapa de estudio al día.

Auditoria Debe quedar registrado en el sistema El usuario, la fecha, hora y origen que originó la transacción.

Notas y comentarios 1. Condiciones del crédito: a. fecha de inicio b. valor del crédito c. tasa de interés d. Sistema de amortización e. Modalidad de pago

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

216

f. día de corte g. Número de periodos académicos financiados h. Rubros asociados al plan de amortización de la

modalidad. i. número de cuotas

2. El plan de cuotas registra la siguiente información

a. Saldo inicial al periodo b. número de cuotas. c. fecha de pago. d. valor cuota. e. Prima de Seguro. f. Valor rubro : Estos valores se crearán por cada

rubro asociado al plan. g. valor intereses corrientes. h. valor abono a capital. i. valor saldo de capital. j. Tasa de interés (nominal y efectiva): El sistema

asignará la menor tasa entre la tasa de interés corriente definida y la tasa máxima de usura definida.

k. Tasa de interés de mora: El sistema asignará la menor tasa entre la tasa de interés mora definida y la tasa máxima de usura definida.

l. Condiciones del plan.

3. Manejo de redondeo a centenas en el valor de la cuota

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

217

9.3 Liquidar crédito en etapa final de amortización

Código: CEA-SIS-003

Nombre: Liquidar Crédito en etapa final de amortización

Elaborado por: William Gerardo C Aprobado por:

Fecha de elaboración:

2007-04-24 Fecha de aprobación:

Objetivo Actualizar diariamente los saldos del crédito en amortización una vez han sido aplicados todos los pagos, novedades, causaciones y otros conceptos como honorarios, gastos judiciales, etc.

Descripción El sistema actualizara y almacenara en un histórico los saldos y estados de los créditos al cierre, una vez incorporada todas las transacciones que afecten los saldos de los créditos. Se puede presentar el caso de que un crédito se suspenda por que el beneficiario ha reportado una inconformidad sobre la liquidación del crédito. Si el crédito se suspende el sistema no debe realizarle ninguna liquidación. El sistema proveerá las consultas y reportes para obtener los créditos suspendidos a la fecha.

Actores Principales Caso de Uso Cierre Diario Ejecuta este caso de uso

Actores secundarios

Precondiciones: El crédito debe estar en época de amortización.

El sistema debe tener aplicados todos los procesos de recaudos, novedades y causaciones que se ejecutan antes y durante el cierre.

Poscondiciones Almacenamiento en el histórico los saldos del crédito.

Secuencia normal de acciones:

El sistema selecciona los créditos en etapa final de amortización y por cada crédito realiza lo siguiente: 1. El sistema recalcula los saldos de prima de seguro, interés

de mora, interés corriente y capital por fuente de financiación. (ver nota 1).

2. El sistema debe almacenar en el histórico de saldos el: Estado, Nuevos saldos de los componentes del crédito. Debe registrarse el saldo total del crédito por cada uno de los rubros y el saldo por cada una de las cuotas que registre

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

218

vencidas y vigentes. 3. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no debe superar los 0.1 segundos.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres.

Seguridad El sistema debe con mecanismos de autenticación para autorizar la ejecución del proceso.

Gestionabilidad (Control de Procesos) Deben quedar registrados en el sistema todos los eventos que se presentaron en la ejecución del proceso.

Auditoria Debe quedar registrado de quien y cuando se ejecutaron los eventos de modificación, eliminación o adición de información.

Notas y comentarios 1. El cálculo de saldos consiste en totalizar el valor de los saldos total del crédito y los saldos totales de cada uno de los componentes que integran las cuotas vencidas y vigentes.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

219

9.4 Aplicar Recaudos etapa final de amortización.

Código: CEA-SIS-004

Nombre: Aplicar Recaudos etapa final de amortización.

Elaborado por: William Gerardo C Aprobado por:

Fecha de elaboración:

2007-04-24 Fecha de aprobación:

Objetivo Actualizar el saldo de los créditos y generar el registro de las transacciones de los recaudos aplicados.

Descripción El sistema aplica los recaudos pendientes de aplicar que son notificados por el sistema financiero del ICETEX.

Actores Principales Funcionario de de vicepresidencia de operaciones y tecnología.

Habilita o deshabilita el servicio para aplicar los recaudos notificados de manera automática.

Servicio de Cartera: Aplica los recaudos notificados de manera automática. Marca en el sistema financiero del ICETEX la aplicación y no aplicación de estos giros.

Actores secundarios

Precondiciones: El sistema financiero del ICETEX (tesorería) debe enviar notificar la existencia recaudos pendientes de aplicar a Cartera.

Poscondiciones Registro de la transacción del recaudo aplicado.

Secuencia normal de acciones:

El sistema de cartera recibe notificación de la existencia de recaudos pendientes de aplicar del sistema financiero del ICETEX. El sistema lee del repositorio los recaudos pendientes de aplicar que corresponden a créditos en época de amortización. Y Por cada recaudo realiza lo siguiente : 1. El sistema incrementa el saldo del fondo si el recaudo

pertenece a un fondo ( si no se realiza en crédito). 2. El sistema aplica el valor del recaudo a los diferentes

componentes en el orden establecido. (ver nota 1). 3. El sistema registra la transacción del recaudo aplicado. 4. El sistema realiza la afectación del interés diferido que

conformó el capital inicial en etapa final de amortización. (ver

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

220

caso de uso: Afectar interés diferido por recaudo en etapa final de amortización).

5. El sistema de cartera notifica por un servicio al sistema financiero la aplicación o no aplicación del recaudo indicando la causa.

6. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación debe realizar la lectura y aplicación de cada recaudo en 0.5 segundos.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres.

Seguridad El sistema debe con mecanismos de autenticación para que Cartera pueda establecer llamadas y recepciones del sistema financiero del ICETEX.

Gestionabilidad (Control de Procesos) Debe quedar registrado en el sistema todos los eventos que se presentaron en la comunicación de Cartera y el modulo financiero de Apoteosis en la aplicación de recaudos informando las inconsistencias generadas para ser tenidas en cuenta en las novedades.

Auditoria Debe quedar registrado la información de quien y cuando se inicio y se canceló el servicio de aplicación automática de recaudos.

Notas y comentarios 1. Orden de aplicación del valor del recaudo a los componentes de las cuotas del crédito: Se referencia siempre desde la cuota más antigua y por cada una se aplicar el valor del recaudo en el siguiente orden: otros conceptos, prima de seguro, interés mora, interés corriente y finalmente se amortiza a capital.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

221

9.5 Registrar distribución de capital e Interés que conforma el capital inicial por fuente de Financiación en etapa final de amortización para el control de la contabilización del interés diferido

Código: CEA-SIS-005

Nombre: Registrar la distribución de Interés y capital de época de estudio que conforma el capital inicial por fuente de financiación en etapa final de amortización para el control de la contabilización del interés diferido

Elaborado por: William Gerardo C Aprobado por:

Fecha de elaboración:

2007-04-24 Fecha de aprobación:

Objetivo Registrar la distribución de capital e interés que conforma el capital inicial del crédito en etapa final de amortización.

Descripción EL sistema registra las distribuciones de capital e interés por fuente de financiación de época de estudio que conformarán el capital inicial de la obligación en la etapa final de amortización.

Actores Principales Caso de uso paso a etapa final de amortización. (Del cierre diario o por novedad).

Ejecuta este caso de Uso.

Actores secundarios

Precondiciones: Las que aplique al caso de uso paso de época de estudio a etapa final de amortización.

Poscondiciones Registro de la distribución de capital e interés que conforma el capital inicial de la obligación en la etapa final de amortización

Secuencia normal de acciones:

1. El sistema en el paso de la obligación de época de estudio a etapa final de amortización almacena la distribución de capital e interés de época de estudio que conforma el capital inicial de la etapa final de amortización registrando los siguientes datos:

a. Fecha del traslado b. Valor Total del capital: ( conformado por el total de

interés y capital en época de estudio). c. Por cada fuente de financiación debe almacenarse

: i. Valor de capital ii. Valor de Interés iii. Porcentaje que representa el valor del

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

222

interés de la fuente de financiación respecto al valor total del capital inicial para etapa final de amortización.

2. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Aplica los requerimientos NO funcionales del caso de uso que ejecuta este caso de uso.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

223

9.6 Afectar interés diferido que conformó el capital inicial por fuente de Financiación en etapa final de Amortización por recaudo.

Código: CEA-SIS-006

Nombre: Afectar interés diferido que conformó el capital inicial por fuente de Financiación en etapa final de Amortización.

Elaborado por: William Gerardo C Aprobado por:

Fecha de elaboración:

2007-04-24 Fecha de aprobación:

Objetivo Realizar la afectación del interés diferido por fuente de financiación que conformó el capital inicial de la obligación en etapa final de amortización por recaudo.

Descripción EL sistema debe realizar la afectación de interés diferido que conformó el capital inicial de la obligación en etapa final de amortización. Teniendo en cuenta que parte del recaudo esta afectando el interés diferido.

Actores Principales Caso de uso de aplicar pago: por aplicación masiva o por novedad.

Ejecuta este caso de Uso.

Actores secundarios

Precondiciones: Las que aplique al caso de uso paso de época de estudio a etapa final de amortización.

Poscondiciones Registro de la distribución de capital e interés que conforma el capital inicial de la obligación en la etapa final de amortización

Secuencia normal de acciones:

1. El sistema lee la distribución de interés por fuente de financiación del capital inicial de la obligación en etapa final de amortización.

2. El sistema determina del valor recaudado: el valor de interés que corresponde a cada interés diferido por fuente de financiación de la distribución del interés. El valor de afectación de diferido lo obtiene multiplicando el porcentaje de interés diferido por el valor del recaudo.

3. Actualiza el valor de interés diferido pendiente de contabilizar: Esta actualización se hace restándole al valor actual que se tenga el valor obtenido en el paso anterior. Esta actualización se realiza en la distribución de conformación de capital inicial en etapa final de amortización.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

224

4. El sistema registra la transacción por el interés diferido para la

generación de su movimiento contable (lo realiza por cada fuente de financiación).

5. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Aplica los requerimientos NO funcionales del caso de uso que ejecuta este caso de uso.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

225

9.7 Aplicar calificación Manual

Código: CEA-SIS-007

Nombre: Aplicar Calificación Manual.

Elaborado por: William Gerardo C Aprobado por:

Fecha de elaboración:

2007-04-24 Fecha de aprobación:

Objetivo Realizar la aplicación manual de la calificación a una obligación de cartera.

Descripción EL sistema tendrá la opción para que se realice la aplicación manual de la calificación de usuario al crédito.

Actores Principales Funcionario de Cartera. Asigna la calificación de usuario al crédito.

Actores secundarios

Precondiciones: El crédito debe encontrarse en etapa final de amortización y activo.

Poscondiciones Asignación o modificación de la calificación de usuario.

Secuencia normal de acciones:

1. El usuario selecciona la opción de calificaciones del crédito 2. El sistema presenta filtros para buscar el crédito. 3. El usuario ingresa la información en los filtros para que el

sistema realice la búsqueda. 4. El usuario presiona la opción buscar. 5. El sistema presenta en un listado los créditos que cumplieron

con los filtros ingresados. El sistema presenta los siguientes datos de cada uno de los créditos :

a. Número de Crédito b. Saldo de Capital c. Capital Congelado d. Capital Contingente e. Interés corriente f. Interés congelado g. Interés contingente h. Interés de Mora i. Interés de mora congelado j. Interés de mora contingente

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

226

k. Calificación aplicada l. Calificación de usuario m. Calificación de alineación. n. Calificación de temporalidad o. Calificación Modelo 1. p. Calificación Modelo 2. q. Calificación Modelo .. n.

6. El usuario selecciona el crédito que desea aplicar la calificación manual

7. El sistema presenta la información del crédito mencionada en el numeral 6 con la opción de ingresar y modificar el valor de la calificación de usuario del crédito.

8. El usuario modifica o ingresa la calificación de usuario y selecciona la opción de guardar.

9. El sistema registra la calificación y guarda en el histórico el cambio de calificación.

10. El sistema presenta mensaje de registro de calificación de usuario realizado con éxito.

Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

227

10. CARTERA EN ETAPA DE ESTUDIO Y AMORTIZACIÓN

10.1 Generar información para extractos y recibos de pago.

Código: CAE-SIS-001

Nombre: Generar Información para extractos.

Elaborado por: William Gerardo C Aprobado por:

Fecha de elaboración:

2007-04-24 Fecha de aprobación:

Objetivo Generar la información para los extractos y/o recibos de pago de créditos en época de estudio y amortización.

Descripción El sistema debe generar la información para los extractos y/o recibos de pago de cada crédito para ser impresos u obtenidos por Internet. Esta información quedara disponible en un repositorio para que se pueda obtener y aplicar el formato de presentación que se defina para ser impreso u obtenido por el beneficiario por Internet.

Actores Principales Funcionario de Vicepresidencia de operaciones y tecnología.

Ejecuta la opción de generar información de extractos. Ejecuta la opción de generar información de recibos de pago.

Cierre Diario Ejecuta la opción de generar información de extractos. Ejecuta la opción de generar información de recibos de pago.

Cierre Mensual Ejecuta la opción de generar información de extractos. Ejecuta la opción de generar información de recibos de pago.

Actores secundarios

Precondiciones: Definición de ciclos de generación de extractos.

Poscondiciones Generación de información de extractos y recibos de pago que quedaran disponibles en un repositorio.

Secuencia normal de El sistema selecciona los créditos que dentro del periodo no se

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

228

acciones: les ha generado el extracto. Por cada crédito realiza lo siguiente : 1. El sistema extrae los datos necesarios para el extracto y

recibos de pago. (datos básicos del estudiante (nombre, dirección, ciudad.) y del crédito (número de crédito, saldos iniciales, saldos al corte, valores a pagar), fechas de vencimiento).

2. El sistema valida las fechas de cobro para que estas correspondan a un día hábil. En el caso de que la fecha de cobro sea una fecha no hábil el sistema tomará la siguiente fecha hábil. El sistema validará con el calendario definido y asociado a este proceso.

3. El sistema almacena la información en un archivo. (no se

asocia a ningún formato de impresión). 4. El sistema registra una marca al crédito para saber que la

información del recibo de pago ya fue generado para el crédito.

5. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación no debe superar 1 segundo por generación de información (de extracto y/o recibo de pago).

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres.

Seguridad El sistema debe con establecer mecanismos de autenticación para que el usuario de cierres o de vicepresidencia y tecnología pueda generar la información de extractos y recibos de pago.

Auditoria Debe quedar registrado la información de quien y cuando se ejecutó la generación de información de extractos.

Notas y comentarios 1. Para extractos: Se debe proyectar los saldos de intereses moratorios unos días (valor parametrizable) para la generación

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

229

del extracto. Es necesario porque se presenta una diferencia entre la fecha de corte de generación del extracto y la fecha en que realiza el pago el beneficiario. 2. Para extractos: No a todos los créditos se les genera extractos. Es decir se tendrá la posibilidad de registrar una marca al crédito, de manera que el sistema pueda establecer si se le genera la información del extracto. 3. Para extractos o recibos de pago: El sistema valida si ya se generó información para el extracto y/o recibo de pago para no volverla a generar. 4. Datos que deben quedar en el repositorio para recibos de

pago:

Código de Referencia

Nombres del Beneficiario

Apellido del Beneficiario

Ciudad

Dirección

Teléfono

Fecha Corte

Saldo Deuda

Lista de las cuentas donde puede realizar el pago. Esta lista debe contener el nombre de la entidad financiera, número de cuenta, código de barras de la entidad donde pueden consignar el valor del pago.

Observación o recomendación que debe salir en el formato impreso.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

230

10.2 Generar Extractos y Recibos de Pago.

Código: CAE-SYS-002

Nombre: Generar Extractos y Recibos de Pago.

Elaborado por: William Gerardo C Aprobado por:

Fecha de elaboración:

2007-04-24 Fecha de aprobación:

Objetivo Publicar, imprimir, enviar: extractos y recibos de pago.

Descripción El sistema dispondrá de diferentes opciones para que el beneficiario obtenga su extracto y recibo de pago. El beneficiario lo podrá obtener:

o Vía Internet. o Por correo (impresión física) envío del ICETEX.

Actores principales Funcionario de División de informática.

Informa ubicación del repositorio al Outsourcing. Establece y valida los permisos sobre el repositorio.

Outsourcing Imprime extractos. Envía extractos al beneficiario o a las IES.

Actores secundarios IES Envía extractos y/o recibos de pago al Beneficiario.

Beneficiario Obtiene e imprime extracto o recibo de pago vía Internet.

Precondiciones: La información del extracto deberá estar actualizada y disponible en el repositorio creado para almacenar la información de extractos.

Poscondiciones Impresión recibo de pago y/o extracto con su gestión de envío.

Obtención e Impresión de los recibos de pago y/o extracto del beneficiario por Internet.

Secuencia normal de acciones:

1. Outsourcing ejecuta la opción de impresión de extractos y recibos de pago.

2. El sistema consulta los créditos que tienen recibos y/o extractos pendientes de imprimir y que están disponibles en el repositorio.

3. El usuario de recibos de pago y/o extractos selecciona los

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

231

créditos a los que desea imprimir el extracto y/o recibo de pago.

4. El usuario confirma impresión de extractos y/o recibos de pago.

5. El sistema imprime el extracto y/o recibo de pago en el formato de presentación definido para el extracto.(El sistema deberá estar en capacidad de aplicar cualquier formato de presentación sin que se tenga que afectar la impresión).

6. El sistema marca los créditos que se les imprimió el extracto. (Esta marca consiste en registrar la siguiente información: fecha de impresión e incrementa número de impresiones realizadas). Esta información también se registra para el recibo de pago.

7. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible 7x24 todos los días.

Seguridad El sistema debe establecer mecanismos de autenticación para que El usuario de outsourcing tenga acceso al repositorio de información generada para extractos.

Gestionabilidad (Control del Proceso) No hay cambio de estados, pero si se deja un registro de la impresión del extracto para el crédito u obtención por internet.

Auditoria Debe quedar registrado la información de quien y cuando se ejecutó la impresión de extractos o la obtención vía Internet.

Notas y comentarios 1. El extracto podrá ser obtenido e impreso por el beneficiario vía Internet. Este evento será registrado en el sistema indicando que fue impreso por Internet.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

232

11. CIERRE DIARIO

11.1 Ejecutar Cierre Diario

Código: CDI-SIS-001

Nombre: Ejecutar Cierre Diario

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Realizar el cierre diario de las operaciones de créditos y cartera y la realización de la contabilización de las operaciones.

Descripción Se ejecutan todos los procesos para cerrar las operaciones diarias del crédito.

Actores Principales Funcionario de vicepresidencia de operaciones y tecnología

Ejecuta la opción del cierre diario.

Actores secundarios

Precondiciones: Realización del cierre del día de fecha anterior a la fecha del día que se está cerrando.

Bloqueo del sistema para que no se permita el ingreso de transacciones con fecha inferior o igual a la fecha del día que se está cerrando.

Confirmación de que han sido ingresadas todas las operaciones del día, para proceder a realizar el cierre.

Debe estar actualizada la tasa de interés de usura permitida

Poscondiciones Cierre diario de todas las operaciones de créditos y cartera.

Actualización de los saldos de los créditos.

Actualización de estados de las obligaciones

Generación de la interfaz contable en el modulo de Cartera

Contabilización de las operaciones (Envío de la interfaz contable consolidada en el modulo de cartera al modulo de Contabilidad del sistema financiero del ICETEX).

Debe haberse generado la contabilidad de todas las transacciones del día anterior

Secuencia normal de acciones:

1. El usuario ejecuta la opción de cierre diario. 2. El sistema realiza una copia de seguridad de la información

(Base de datos que se afectan por los procesos del cierre) y lo deja en un repositorio definido para este fin.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

233

3. El sistema actualiza el estado de los créditos (ver caso de uso Actualización de estados: CDI-SIS-002).

4. El sistema genera el paso de los créditos a etapa final de amortización de los créditos que presentaron este cambio de estado. (Ver caso de uso paso a época de amortización).

5. El sistema ejecuta la causación diaria (ver caso de uso de causación diaria: CDI-SIS-003).

6. El sistema generar interfaz contable en el aplicativo de cartera (ver caso de uso Generar interfaz contable en el modulo de Cartera: CDI-SIS-004).

7. El sistema pasa la interfaz contable consolidada en el modulo de Cartera al modulo de Contabilidad del sistema financiero del ICETEX. (ver caso de uso Enviar interfaz contable consolidada al modulo de Contabilidad CDI-SIS-005).

8. El sistema pasa los saldos de cada uno de los créditos al histórico de saldos.

9. Registrar información del cierre en el repositorio para la generación de reportes para centrales de información.

10. El sistema realiza una copia de seguridad de la información (Base de datos que se afectan por los procesos del cierre) y lo deja en un repositorio definido para este fin.

11. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para los casos de uso que integran el cierre diario.

Disponibilidad El sistema debe estar disponible de 7pm a 10pm de lunes a viernes para los casos de uso que integran el cierre diario.

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución de la transacción de cierre. El sistema debe validar que el usuario que esta realizando la transacción tenga autorización para ejecutarla en ese horario.

Gestionabilidad (Control del Proceso) No modifica el estado pero si uno de los caso de uso que

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

234

utiliza este caso.

Auditoria Debe quedar registrado en el sistema el usuario, la fecha, hora y origen de cada ejecución de cada caso de uso que integra el cierre diario.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

235

11.2 Actualizar estado de los créditos

Código: CDI-SIS-002

Nombre: Actualizar estados de los créditos

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Actualizar los estados de los créditos.

Descripción El sistema consulta el estado actual del los créditos y de acuerdo a las condiciones que posean los créditos a la fecha de ejecución del cierre establece el nuevo estado para el crédito.

Actores Principales Caso de uso Cierre Diario. Ejecuta este caso de uso.

Actores secundarios

Precondiciones: Ver precondiciones del Caso de uso Cierre Diario debido a que este dispara la ejecución.

Poscondiciones Actualización del estado del crédito en caso que cambie

Registro en el histórico de estados del crédito si hubo cambio de estado.

Secuencia normal de acciones:

El sistema selecciona los créditos vigentes para establecer su nuevo estado. Por cada crédito el sistema realiza lo siguiente : 1. El sistema lee el estado actual del crédito. 2. El sistema de acuerdo al estado leído del crédito analiza las

condiciones para determinar si hay cambio de estado. (ver nota 1).

3. El sistema registra el cambio de estado si se presentó. (Número de Crédito, Fecha de cambio, Estado anterior, Nuevo Estado).

4. El sistema actualiza el estado actual del crédito. 5. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para los casos de uso que integran el cierre diario.

Disponibilidad

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

236

El sistema debe estar disponible de 7pm a 10pm de lunes a viernes para los casos de uso que integran el cierre diario.

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución de la transacción de cierre. El sistema debe validar que el usuario que esta realizando la transacción tenga autorización para ejecutarla en ese horario.

Gestionabilidad (Control del Proceso) Debe registrarse los cambios de estados que se presentan y la causa que lo generaron.

Auditoria Debe quedar registrado la información de quien y cuando se ejecuto el proceso. Debe registrarse la fecha, hora de inicio y hora final de la ejecución del proceso.

Notas y comentarios 1. Definición de estados y condiciones que generan el nuevo Estado:

a. De época de estudio a Periodo de Gracia i. Condiciones :

1. Se llegó al periodo final de estudio.

b. De época de estudio a Bloqueado i. Condiciones :

1. Marca de no actualización de datos del beneficiario.

2. Presenta 1 día de mora o el número de días definido en la parametrización.

c. De época de estudio a Aplazado i. Condiciones :

1. Marca de aplazamiento. d. De Bloqueado a Amortización al día.

i. Condiciones : 1. Se cumplió el número de días

definido en la parametrización para permanecer el crédito en estado bloqueado.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

237

e. De Aplazado a Amortización al día i. Condiciones :

1. Se cumplió el número de periodos (más de 2) definido en la parametrización para permanecer el crédito aplazado.

f. De periodo de gracia a amortización i. Condiciones:

1. Finalizó tiempo de gracia. g. De Amortización al día a Mora

i. Condiciones : 1. El crédito se encuentra con 1 día de

mora o los días que se defina en la parametrización.

h. De Amortización al día a Cobro Preventivo

i. Condiciones : 1. El crédito se encuentra ente 1 día y

30 días de mora (este rango estará definido en la parametrización).

i. De Cobro Preventivo a Cobro Correctivo i. Condiciones:

1. El crédito se encuentra ente 31 día y 60 días de mora (este rango estará definido en la parametrización).

j. Cobro Prejuridico

i. Condiciones : 1. El crédito se encuentra con más de

60 días de mora o los días que se defina en la parametrización.

k. De Cobro Prejuridico a cobro Jurídico al dia

i. Condiciones : 1. El crédito se encuentra con más de

180 días de mora o los días que se defina en la parametrización.

l. De Amortización al día a Finalizado

i. Condiciones : 1. El crédito posee saldo cero o menor

a cero (es decir el beneficiario tiene un saldo a favor).

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

238

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

239

11.3 Causación Diaria

Código: CDI-SIS-003

Nombre: Causación Diaria

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Realizar la actualización del saldo de interés de los créditos por la causación diaria generada en época de estudio y en etapa final de amortización. Registrar información de la transacción de causación de interés en este registro quedara registrada la época.

Descripción Calcula la causación diaria que se genera por cada uno de los créditos. Para este caso se refiere al interés que se genera sobre el saldo a la fecha.

Actores Principales Caso de uso cierre diario. Ejecuta este caso de uso.

Actores secundarios

Precondiciones: Se deben haber aplicado los movimientos que afecten el saldo de los créditos:

o Giros. o Recaudos. o Novedades que aumentan saldo. ( nota debito) o Novedades que disminuyen saldo. (nota crédito)

Manejo del diferido (Saldo que pasa de época de estudio a época de amortización).

Poscondiciones Actualización saldo de interés corriente y mora del crédito.

Actualización de saldos diferidos.

Registro del movimiento de causación de interés

Secuencia normal de acciones:

El sistema lee los créditos pendientes de causación diaria y por cada uno de los créditos realiza lo siguiente : 1. El sistema liquida el valor de interés corriente, El sistema

para la liquidación del interés toma la menor tasa entre la tasa de interés corriente asociada al crédito y la tasa máxima de usura permitida.

2. El sistema liquida el valor de interés de mora (si el crédito está en mora porque no están cubiertos los pagos a la fecha del cierre) según la etapa que se encuentre la obligación de crédito (Época de estudio o etapa final de amortización). El

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

240

sistema para la liquidación del interés toma la menor tasa entre la tasa de interés mora asociada al crédito y la tasa máxima de usura permitida.

3. El sistema actualiza los valores de interés corriente, y de mora del crédito.

4. El sistema actualiza el plan de cuotas los valores de intereses corrientes y de mora teniendo en cuenta la distribución de la conformación del capital inicial de la obligación en etapa final de amortización.

5. El sistema registra las causaciones de interés teniendo en cuenta la distribución del interés y capital de época de estudio que conformó el capital inicial de la obligación en la etapa final de amortización. (ver caso de uso: Realizar el registro de transacciones de causación de interés teniendo en cuenta la conformación del capital inicial de la obligación en la etapa final de amortización).

6. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para los casos de uso que integran el cierre diario.

Disponibilidad El sistema debe estar disponible de 7pm a 10pm de lunes a viernes para los casos de uso que integran el cierre diario.

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución de la transacción de cierre. El sistema debe validar que el usuario que esta realizando la transacción tenga autorización para ejecutarla en ese horario.

Gestionabilidad (Control del Proceso) No genera cambio de estado.

Auditoria Debe quedar registrado la información de quien y cuando se ejecuto el proceso. Debe registrarse la fecha, hora de inicio y hora final de la ejecución del proceso.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

241

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

242

11.4 Generar Interfaz Contable en el aplicativo de Cartera

Código: CDI-SIS-004

Nombre: Generar Interfaz Contable en el aplicativo de Cartera

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Realizar la generación contable de las transacciones diarias de cartera pendientes de generar movimiento contable.

Descripción El sistema lee las transacciones pendientes de generar movimiento contable a la fecha y genera la afectación contable de cada una. El sistema genera un consolidado diario de movimientos y lo almacena en el modulo de cartera. (Disponible para ser enviado a Contabilidad).

Actores Principales Caso de uso cierre diario Ejecuta este caso de uso.

Caso de uso cierre Mensual Ejecuta este caso de uso.

Actores secundarios

Precondiciones: Ejecución de la causación diaria.

Se debe haber realizado los cambios de estado del crédito.

Se debe haber realizado la aplicación de los movimientos que afecten el saldo de los créditos:

o Giros. o Recaudos. o Novedades que aumentan saldo. ( nota debito) o Novedades que disminuyen saldo. (nota crédito) o Manejo de diferidos.

Poscondiciones 1. Marcar los movimientos que generaron movimiento contable.

Secuencia normal de acciones:

El sistema lee las transacciones pendientes de generación de movimiento contable para la fecha dada. (se invoca desde del cierre diario). Por cada uno de los movimientos se realiza lo siguiente : 1. El sistema consulta el perfil contable asociada a la

transacción seleccionada para contabilizar. (ver nota 1).

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

243

2. El sistema genera el movimiento contable por el valor de la transacción a las cuentas definidas del perfil contable asociado en el modulo de cartera.

3. El sistema marca la transacción si se genero el movimiento contable o si no fue posible su generación y su causa. Esta marca es importante con el objetivo de poder volver a reejecutar este caso de uso para la generación del movimiento contable de las transacciones que no pudieron ser contabilizadas (por error en la ejecución anterior o por una falla del sistema).

4. El sistema genera consolidado en cartera de los movimientos contables que se han generado por modalidad de crédito (acces, mediano plazo, largo plazo), transacción (giros, pagos, reversos, causaciones), cuenta contable según calificación y clasificación.

5. El sistema marca las transacciones y movimientos contables que conformaron el consolidado de movimientos contables disponibles para enviar a contabilidad.

6. Fin del proceso.

Secuencias alternas El sistema no puede generar el movimiento contable de la transacción contable:

El sistema registra en un repositorio las transacciones que no pudieron ser contabilizadas con las causa de su no generación.

El sistema provee una consulta con opción de impresión para visualizar la información anterior.

El usuario realizara los ajustes que ocasione la causa.

EL proceso que represente este caso de uso podrá volverse a ejecutar cuantas veces sea necesario con el objetivo de poder generar el movimiento contable de la transacción corregida.

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para los casos de uso que integran el cierre diario.

Disponibilidad El sistema debe estar disponible de 7pm a 10pm de lunes a viernes para los casos de uso que integran el cierre diario.

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

244

de la transacción de cierre. El sistema debe validar que el usuario que esta realizando la transacción tenga autorización para ejecutarla en ese horario.

Gestionabilidad (Control del Proceso) No genera cambio de estado.

Auditoria Debe quedar registrado la información de quien y cuando se ejecuto el proceso. Debe registrarse la fecha, hora de inicio y hora final de la ejecución del proceso.

Notas y comentarios 1. Perfil contable: definición de las cuentas que deben afectarse. En esta definición se indica la naturaleza debito o crédito, la calificación (A,B,C,D,E,), y clasificación (comercial, consumo), y estado de las obligaciones (vigente o vencido).

2. En el registro del movimiento se guarda un concepto,

concepto que nos sirve para determinar el perfil contable.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

245

11.5 Enviar Interfaz Contable Consolidada a Contabilidad

Código: CDI-SIS-005

Nombre: Enviar Interfaz Contable Consolidada a Contabilidad

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Enviar los movimientos contables consolidados pendientes de enviar de crédito y cartera al modulo de Contabilidad. Marcar los movimientos contables consolidados enviados a contabilidad.

Descripción El sistema lee los movimientos contables consolidados en el modulo de cartera que no han sido enviados a contabilidad y los envía a Contabilidad. Si el envío fue exitoso marca el movimiento como enviado, si no pudo enviarse marca el movimiento como error al enviar y registra la causa del porque no se pudo enviar. Información del tercero en el movimiento consolidado se pueden presentar 2 casos :

Movimiento consolidado sin información del tercero: en este caso el valor enviado será nulo.

Movimiento consolidado con información del tercero: en este caso el valor enviado será el que se defina para este tipo de movimiento. Dependiendo de esta definición se afectara la forma de consolidar los movimientos.

Actores Principales Caso de uso cierre diario Ejecuta este caso de uso.

Caso de uso cierre Mensual Ejecuta este caso de uso.

Actores secundarios

Precondiciones: Deben existir movimientos contables consolidados pendientes de enviar.

Poscondiciones Movimientos contables consolidados enviados a contabilidad

Marcación de los movimientos contables consolidados que se enviaron a contabilidad.

Secuencia normal de acciones:

El sistema lee los movimientos contables consolidados pendientes de enviar a contabilidad y por cada movimiento 1. El sistema envía el movimiento a contabilidad. 2. El sistema marca el movimiento consolidado como enviado a

Contabilidad.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

246

3. El sistema marca los movimientos del movimiento consolidado de contabilidad como enviados a contabilidad.

4. 5. Fin del proceso.

Secuencias alternas 2a. El movimiento no fue aceptado por contabilidad

El sistema registra en un repositorio los movimientos que no pudieron ser aceptados por contabilidad.

El sistema provee una consulta con opción de impresión para visualizar la información anterior.

El usuario realizara los ajustes que ocasione la causa.

EL proceso que represente este caso de uso podrá volverse a ejecutar cuantas veces sea necesario con el objetivo de poder enviar los movimientos a contabilidad.

En caso de no comunicación con el sistema financiero el sistema debe proveer mecanismos para proveer esta información a consolidada al sistema Financiero.

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para los casos de uso que integran el cierre diario.

Disponibilidad El sistema debe estar disponible de 7pm a 10pm de lunes a viernes para los casos de uso que integran el cierre diario. Debe poderse reejecutar este caso de uso.

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución del caso de uso y la transmisión a sistema financiero del ICETEX. El sistema debe validar que el usuario que esta realizando la transacción tenga autorización para ejecutarla en ese horario.

Gestionabilidad (Control del Proceso) No genera cambio de estado. Pero registra la marcación de los movimientos de enviado a contabilidad o rechazado de contabilidad con la causa de esta no aceptación.

Auditoria Debe quedar registrado la información de quien y cuando se

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

247

ejecuto el proceso. Debe registrarse la fecha, hora de inicio y hora final de la ejecución del proceso. Debe quedar registrado cada reproceso.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

248

11.6 Realizar el registro de transacciones de causación de interés teniendo en cuenta la conformación del capital inicial de la obligación en la etapa final de amortización.

Código: CDI-SIS-006

Nombre: Realizar el registro de transacciones de causación de interés teniendo en cuenta la conformación del capital inicial de la obligación en la etapa final de amortización.

Elaborado por: William Gerardo C Aprobado por:

Fecha de elaboración:

2007-04-24 Fecha de aprobación:

Objetivo Realizar los registros contables necesarios para realizar la afectación contable del interés causado por fuente de financiación

Descripción EL sistema consulta la distribución de capital e interés por fuente de financiación de época de estudio que conformó el capital inicial de la obligación en la etapa final de amortización y realiza el registro de la transacción del interés diferido por fuente de financiación para ser contabilizada..

Actores Principales Caso de uso Causación de Interés.

Ejecuta este caso de Uso.

Actores secundarios

Precondiciones: Debe estar registrada la distribución de la conformación del capital e interés que conformó el capital inicial en etapa final de amortización.

Poscondiciones Registrar transacción de causación de interés por fuente de financiación

Secuencia normal de acciones:

1. El sistema lee la distribución del capital e interés que conformó el capital inicial de la obligación en la etapa final de amortización

2. El sistema realiza una transacción de causación de interés por el valor del porcentaje ( del valor total causaso de interés) definido en la distribución de cada fuente de financiación que conformó el capital inicial. Estas transacciones queda listas para que se pueda generar su correspondiente movimiento contable.

Secuencias alternas

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

249

Requerimientos no funcionales

Aplica los requerimientos NO funcionales del caso de uso que ejecuta este caso de uso.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

250

12. CIERRE MENSUAL

12.1 Ejecutar Cierre Mensual

.

Código: CME-SIS-001

Nombre: Ejecutar Cierre Mensual

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Ejecutar el cierre mensual de todas las operaciones de los créditos.

Descripción Se ejecutan todos los procesos necesarios para el cierre mensual de los créditos. Consolidar datos para generación de reportes a entes externos.

Actores Principales Funcionario de Vicepresidencia de Operaciones y Tecnología

Ejecuta la opción del cierre diario.

Actores secundarios

Precondiciones: Bloqueo del sistema para no permitir el ingreso de transacciones con fecha menor o igual a la fecha de cierre.

La fecha de cierre debe ser una fecha de fin de mes válida.

Se deben haber ejecutado los cierres diarios.

Poscondiciones Actualización de la calificación de los créditos.

Homologación (alineamiento) de los créditos

Provisión de capital e interés de los créditos.

Reclasificación de la cartera.

Registro contable de los movimientos generados.

Secuencia normal de acciones:

1. El usuario selecciona la opción de cierre Mensual. 2. El sistema realiza copia de seguridad de las bases de datos. 3. El sistema ejecuta la calificación de cartera teniendo en

cuenta la clasificación de la cartera (Consumo y Comercial). (ver caso de uso de calificar cartera: CME-SIS-002).

4. El sistema ejecuta la homologación de cartera. (ver caso de uso homologación cartera : CME-SIS-003).

5. El sistema ejecuta la reclasificación contable (ver caso de uso de reclasificación contable: CME-SIS-004).

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

251

6. El sistema ejecuta la provisión de cartera (ver caso de uso de provisión de cartera : CME-SIS-005).

7. Marcar el cierre mensual en los créditos. 8. El sistema realiza la consolidación del endeudamiento del

beneficiario. (Ver nota 1). 9. El sistema ejecuta la generación de la interfaz contable en el

modulo de cartera (ver caso de uso generar Interfaz Contable en el aplicativo de Cartera: CME-SIS-004).

10. El sistema pasa la interfaz contable consolidada generada en cartera al modulo de contabilidad (ver caso de uso enviar Interfaz Contable Consolidada a Contabilidad: CME-SIS-005).

11. El sistema realiza copia de seguridad de las bases de datos. 12. El sistema ejecuta la generación de la información para los

extractos (ver casos de uso generación de información de extractos).

13. El sistema ejecuta la generación de la información para entes internos y Externos en un repositorio definido para este fin.

14. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para los casos de uso que integran el cierre mensual.

Disponibilidad El sistema debe estar disponible de en el tiempo asignado para el cierre mensual.

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución del cierre. El sistema debe validar que el usuario que esta realizando la transacción tenga autorización para ejecutarla en ese horario.

Gestionabilidad (Control del Proceso) No modifica estados.

Auditoria Debe quedar registrado en el sistema El usuario, la fecha,

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

252

hora y origen de cada ejecución de cada caso de uso que integra el cierre.

Notas y comentarios 1. El sistema alimenta un repositorio de endeudamiento el total de las obligaciones por beneficiario. Registrando la información de:

i. Código del Beneficiario. ii. Total Capital adeudado. iii. Total interés corriente adeudado. iv. Total de interés de mora adeudado. v. Total de prima de seguro adeudado vi. Total de otros cargos adeudados.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

253

12.2 Calificar Cartera

Código: CME-SIS-002

Nombre: Calificar Cartera

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Establecer y actualizar la calificación de los créditos.

Descripción Establecer los meses en mora para determinarla calificación que se le asignará al crédito.

Actores Principales Caso de uso Cierre Mensual Ejecuta este caso de uso

Actores secundarios

Precondiciones: La fecha de corte debe corresponder a una fecha de cierre de mes válida.

El crédito debe estar en época de ejecución o amortización.

El crédito debe tener un estado vigente de cartera.

Poscondiciones

Nueva Calificación del Crédito

Registro del movimiento de cambio de calificación si se presentó.

Secuencia normal de acciones:

El sistema determina los diferentes modelos vigentes que aplicaría para determinar las calificaciones a asignar al crédito. El sistema asignaria la calificación a cada crédito por cada uno de los modelos vigentes de calificación: 1. El sistema selecciona el modelo a aplicar de calificación. 2. El sistema obtiene los datos necesarios para el modelo de

calificación. Por ejemplo determina los meses de mora para el modelo de calificación de temporalidad (ver nota1).

3. El sistema establece la calificación del modelo utilizado. Por ejemplo para el modelo de temporalidad califica de acuerdo a los meses de mora calculados y según la parametrización de clasificación (Comercial, Consumo) y calificación (A,B,C,D,E) registrada en el sistema.

4. El sistema actualiza la calificación del crédito indicando el modelo que se utilizó para asignar la calificación. (Es decir se tendrá por cada modelo de calificación que se utilitze un campo para guardar su calificación). Estas actualizaciones quedarán registradas para que puedan ser consultadas e impresas ya sea por crédito o de forma masiva.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

254

5. El sistema registra movimiento del cambio de calificación si se presentó por modelo utilizado.

6. Fin del Proceso

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para los casos de uso que integran el cierre mensual.

Disponibilidad El sistema debe estar disponible en el tiempo asignado para el cierre mensual.

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución del caso de uso en el cierre. El sistema debe validar que el usuario que esta realizando la transacción tenga autorización para ejecutarla en ese horario.

Gestionabilidad (Control del Proceso) No modifica estados. Asigna la nueva calificación. Debe validar si ya se ha ejecutado los casos de uso previos obligatorios para la ejecución de este caso de uso.

Auditoria Debe quedar registrado en el sistema El usuario, la fecha, hora y origen de cada ejecución de cada caso de uso que integra el cierre.

Notas y comentarios 1. Meses en mora: Corresponden a los meses existentes entre la fecha de cubrimiento del saldo incumplido y la fecha de corte.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

255

12.3 Alinear Calificaciones

Código: CME-SIS-003

Nombre: Alinear Calificaciones.

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Obtener la calificación más acida de los créditos vigentes del beneficiario, en caso de que este posea más de un crédito vigente. Y aplicar esta calificación a cada uno de los créditos.

Descripción Se refiere al caso de que el beneficiario posea más de una obligación y estas tengan calificaciones diferentes. El sistema deber seleccionar la calificación mas acida de loas calificaciones asignadas a cada uno de los créditos del beneficiario y asignar le esta calificación a cada uno de los créditos, en el campo que se tenga designado para almacenar la calificación de alineación. La calificación que se utilizará para alinear será la que se defina en el sistema. Por ejemplo en el sistema se determina que la calificación de alineación debe ser la calificación del modelo de temporalidad.

Actores Principales Caso de uso cierre mensual Ejecuta este caso de uso

Actores secundarios

Precondiciones: Ejecución del caso de uso Calificar Cartera.

Poscondiciones Asignación de la calificación homologada a los créditos.

Secuencia normal de acciones:

El sistema selecciona los beneficiarios de créditos vigentes que posean más de un crédito vigente. Y por cada Beneficiario el sistema realiza lo siguiente: Por cada beneficiario : 1. El sistema obtiene las diferentes calificaciones asignadas

créditos del beneficiario. 2. El sistema obtiene la calificación mas acida de los créditos

del beneficiario. 3. El sistema asigna la calificación mas acida obtenida a los

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

256

créditos del beneficiario. (lo asigna en el campo que se tenga para guardar la calificación alineada).

4. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para los casos de uso que integran el cierre mensual.

Disponibilidad El sistema debe estar disponible en el tiempo asignado para el cierre mensual.

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución del caso de uso en el cierre. El sistema debe validar que el usuario que esta realizando la transacción tenga autorización para ejecutarla en ese horario.

Gestionabilidad (Control del Proceso) No modifica estados. Asigna la calificación de alineación (Homologación). Debe validar si ya se ha ejecutado los casos de uso previos obligatorios para la ejecución de este caso de uso.

Auditoria Debe quedar registrado en el sistema el funcionario, el usuario, la fecha, hora y origen de cada ejecución de cada caso de uso que integra el cierre.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

257

12.4 Actualizar provisiones

Código: CME-SIS-004

Nombre: Actualizar Provisiones

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Calcular y actualizar el valor de provisión de los créditos.

Descripción Calcula y actualiza los valores de provisión de capital e interés de los créditos con base en los saldos y distribuciones de los intereses (Congelado y Contingente).

Actores Principales Caso de Uso Cierre Mensual Ejecuta este caso de uso.

Actores secundarios

Precondiciones: La fecha de cierre debe corresponder a una fecha de cierre de mes.

Ejecución del caso de uso Calificar Cartera.

Ejecución del caso de uso Homologar Cartera.

Poscondiciones Nuevo saldo de provisión de capital del crédito.

Nuevo saldo de la provisión de Interés del crédito.

Registro del movimiento de provisión.

Secuencia normal de acciones:

Por cada crédito se realiza lo siguiente teniendo en cuenta los modelos vigentes de provisión p definidos para aplicar. 1. El sistema lee la calificación alineamiento del crédito. 2. El sistema lee el modelo de provisión que debe aplicar.

(pueden ser uno o más modelos). 3. El sistema determina la provisión anterior. Solo si el crédito ya

se le había aplicado alguna provisión. 4. El sistema evalúa los saldos de capital, interés o otros cargos

con el objetivo de determinar si hay una recuperación o un reintegro de provisión.

5. El sistema registra una transacción de recuperación de provisión si esta se presentó para capital, interés y otros conceptos. (Ver nota 1).

6. El sistema registra una transacción de reintegro de provisión si esta se presentó para capital, interés y otros conceptos.

7. El sistema obtiene los datos necesarios para el modelo para proceder a realizar la provisión de capital, interés y otros

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

258

conceptos por cada modelo que debe aplicar (ver nota 2).. 8. El sistema aplica formula para generar la provisión de capital,

provisión de interés y provisión de otros conceptos del modelo utilizado.

9. El sistema aplica formula para generar la provisión otros conceptos.

10. El sistema actualiza el saldo de provisión de interés , de capital del crédito y otros conceptos (Estos saldos se actualizan por modelo).

11. El sistema registra en cartera el movimiento de provisión de interés, capital y otros conceptos. (En este registro queda registrado el modelo que se utilizó).

12. El sistema genera reporte de variación de provisiones de crédito por crédito.

13. Fin del Proceso

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para los casos de uso que integran el cierre mensual.

Disponibilidad El sistema debe estar disponible en el tiempo asignado para el cierre mensual.

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución del caso de uso en el cierre. El sistema debe validar que el usuario que esta realizando la transacción tenga autorización para ejecutarla en ese horario.

Gestionabilidad (Control del Proceso) No modifica estados. Debe validar si ya se ha ejecutado los casos de uso previos obligatorios para la ejecución de este caso de uso.

Auditoria Debe quedar registrado en el sistema el funcionario, el usuario, la fecha, hora y origen de cada ejecución de cada caso de uso que integra el cierre.

Notas y comentarios 1. Definición de los conceptos recuperación y reintegro

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

259

Recuperación: Es el valor que se disminuye de provisión que corresponde a la provisión de periodos contables anteriores al actual.

Reintegro: Es el valor de provisión que se disminuye que corresponde a la provisión del periodo contable actual.

2. Datos para realizar el calculo de provisiones :

% provisión capital

% provisión interés

% otros conceptos

Valor garantía

% otros conceptos

Saldo de capital

Saldos de interés corriente

Saldos de interés de mora

Saldos de otros conceptos

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

260

12.5 Generar Provisión General de Cartera

Código: CME-SIS-005

Nombre: Generar Provisión General de Cartera

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Totalizar la provisión de los créditos para enviar a contabilidad.

Descripción El sistema totaliza las provisiones por concepto de capital, interés y otros conceptos , para su posterior envió a contabilidad

Actores Principales Caso de Uso Cierre Mensual Ejecuta este caso de uso.

Actores secundarios

Precondiciones: La fecha de cierre debe corresponder a una fecha de cierre de mes.

Ejecución del caso de uso Calificar Cartera.

Ejecución del caso de uso Alinear Cartera.

Ejecución del caso de uso de provisión de cartera.

Poscondiciones Registro de las provisiones de capital, interés y otros conceptos por cada crédito.

Secuencia normal de acciones:

1. El sistema obtiene el total de provisión de capital, interés y

otros conceptos de los créditos de acuerdo a los criterios que se establezcan para obtener los totales. (ver nota 1).

2. El sistema registra la transacción de provisión de interés, capital y otros conceptos. Los registros de interés, capital y otros conceptos pueden ser uno o más por cada uno, dependiendo de los criterios establecidos para obtener los totales de provisión.

3. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para los casos de uso que integran el cierre mensual.

Disponibilidad El sistema debe estar disponible en el tiempo asignado para el cierre mensual.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

261

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución del caso de uso en el cierre. El sistema debe validar que el usuario que esta realizando la transacción tenga autorización para ejecutarla en ese horario.

Gestionabilidad (Control del Proceso) No modifica estados. Debe validar si ya se ha ejecutado los casos de uso previos obligatorios para la ejecución de este caso de uso.

Auditoria Debe quedar registrado en el sistema El usuario, la fecha, hora y origen de cada ejecución de cada caso de uso que integra el cierre.

Notas y comentarios 1. Criterios para consolidar y obtener los totales de provisión :

Clasificación: Consumo, Comercial.

Calificación

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

262

12.6 Ejecutar Reclasificación Contable

Código: CME-SIS-006

Nombre: Ejecutar Reclasificación Contable

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Trasladar los saldos de las cuentas contables de la calificación anterior a las cuentas de la nueva calificación del crédito.

Descripción Se realiza un traslado de los saldos de las cuentas contables de los créditos cuya calificación ha sido alineada y para aquellos cuya calificación ha sufrido modificación de un mes a otro.

Actores Principales Caso de Uso Cierre Mensual Ejecuta este caso de uso.

Actores secundarios

Precondiciones: Ejecución del caso de uso Calificar Cartera.

Ejecución del caso de uso Alinear Cartera.

Poscondiciones Traslado de saldos de cuentas contables de la calificación anterior a la nueva calificación.

Secuencia normal de acciones:

El sistema selecciona los créditos que cambiaron de calificación de un mes a otro y por cada crédito realiza lo siguiente : 1. El sistema determina los saldos de las cuentas contables que

debe trasladar de la calificación anterior a la nueva calificación.

2. El sistema evalúa si el cambio de calificación implica una afectación de cuentas congeladas (cuentas del activo) o cuentas contingentes. Y de acuerdo a esta afectación guarda el valor de saldo de las cuentas contables. (ver nota 1 y 2 ).

3. El sistema registra las transacciones de de reclasificación: de Capital, interés y otros conceptos. (ver nota 3).

4. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La ejecución no deberá superar el tiempo establecido para los casos de uso que integran el cierre mensual.

Disponibilidad

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

263

El sistema debe estar disponible en el tiempo asignado para el cierre mensual.

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución del caso de uso en el cierre. El sistema debe validar que el usuario que esta realizando la transacción tenga autorización para ejecutarla en ese horario.

Gestionabilidad (Control del Proceso) No modifica estados. Debe validar si ya se ha ejecutado los casos de uso previos obligatorios para la ejecución de este caso de uso.

Auditoria Debe quedar registrado en el sistema el usuario, la fecha, hora y origen de cada ejecución de cada caso de uso que integra el cierre.

Notas y comentarios 1. Significado de Congelado y Contingente :

a. Congelado: Hace referencia al saldo que presentaron las cuentas de activo mientras el crédito se encontraba en las calificaciones de 0 a 60 días antes de iniciar la afectación de las cuentas contingentes. Esta cuentas dejan de afectarse una vez se empiezan afectar las cuentas contingentes.

b. Contingente: Es la asignación que se le da a las cuentas que empiezan a afectarse cuando el crédito se encuentra en calificación que correspondan a mas de 60 días de mora.

2. En el sistema debe estar definido la calificación de

congelación, es decir la que corresponda a la que inicia cuando de presenta los 60 días de mora. De esta manera el sistema evalúa si el crédito llega a esta calificación para iniciar el manejo de cuentas congeladas y cuentas contingentes.

3. El registro de la transacción de reclasificación debe contener

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

264

los siguientes ítems :

Fecha de reclasificación: corresponde a la fecha de cierre.

Calificación Anterior

Calificación nueva

Concepto: Es el que establece el perfil que debe utilizar para afectar las cuentas del traslado de capital, iteres u otros conceptos.

Valor de traslado.

Estado ( Contabilizado, No Contabilizado)

Fecha de Contabilización. Cada transacción de reclasificación que se contabiliza, tiene una afectación para la cuenta contable de la calificación anterior y para la cuenta contable de la nueva calificación.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

265

13. CIERRE PERIODO ACADÉMICO

13.1 Ejecutar cierre periodo académico

Código: CPA-SIS-001

Nombre: Ejecutar Cierre Periodo Académico

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Actualizar los estados de los créditos y generar alertas por los cambios que se generan por la finalización del calendario académico de acuerdo con las actividades desarrolladas por los beneficiarios del crédito.

Descripción El sistema realizará los cambios de estado en los créditos generados por la finalización de los periodos académicos definidos en el sistema según el calendario asociado al programa académico. Los estados que cambian hacen referencia al crédito y a la obligación de cartera. A continuación se mencionan los posibles estados de cada uno de ellos. Los estados de crédito que se pueden dar son:

Activo

Bloqueado: impide que se realicen giros y solo se presenta en época de estudio.

Aplazado: Implica que se aplazo el giro, donde se pude presentar 2 situaciones :

o Que el beneficiario esta cursando el semestre: porque esta utilizando una beca para el pago del periodo académico.

o Que el beneficiario no esta cursando el semestre porque la razón del aplazamiento corresponden a causas como la prestación del servicio militar.

Finalizado: El crédito se saldó.

Anulado: Se encontraron inconsistencias que determinaron su anulación.

Los estados de la obligación de Cartera son :

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

266

Crédito en época de estudio al día

Crédito en época de estudio atrasado en pago de cuota

Crédito en periodo de gracia al día

Crédito en periodo de gracia atrasado en pago de cuota

Crédito en etapa final de amortización al día.

Crédito en etapa final de amortización en cobro preventivo.

Crédito en etapa final de amortización en cobro correctivo.

Crédito en etapa final de amortización en cobro prejuridico.

Crédito en etapa final de amortización en cobro jurídico.

Crédito en etapa final de amortización finalizado.

Los nuevos estados establecidos para los créditos incidirán para:

Trasladar el crédito a etapa final de amortización.

Bloquear la solicitud de giro.

Aplazar la solicitud de giro.

Anular la solicitud de giro.

Finalizar el crédito: Por causa de condonación del 100%.

Traslado a periodo de Gracia. En la finalización del periodo académico se tiene en cuenta las siguientes variables para proceder a cambiar el estado:

Fecha final del periodo académico : o Para seleccionar los créditos que se deben evaluar

para el cambio de estado.

Número de periodos académicos del programa, Número de periodos académicos finalizados por el beneficiario, Número de Giros realizados al beneficiario, Número de aplazamientos por Beca y Número de aplazamientos por servicio militar prestado:

o Para determinar el traslado de época de estudio a periodo de gracia o a etapa final de amortización. Se tienen en cuenta los aplazamientos que hagan parte para este traslado.

Número de giros realizados al beneficiario y el número de periodos de programa académico del beneficiario:

o Para determinar el traslado de época de estudio a periodo de gracia o a etapa final de amortización. Se tienen en cuenta los aplazamientos que hagan parte para este traslado.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

267

Novedades aplicadas en el periodo académico que incidan en el cambio de estado del crédito o de la obligación en cartera.

Actores Principales Caso de uso cambio de estados que es llamado por el caso de uso de cierre diario.

Ejecuta este caso de uso.

Actores secundarios

Precondiciones: La fecha de ejecución debe corresponder a los ciclos de calendario establecido para las modalidades de crédito.

Definición de los calendarios de los programas académicos.

El crédito debe estar en época de estudio o periodo de gracia. (Es decir aplica para los créditos que no se encuentren en etapa final de amortización).

Poscondiciones Actualización del estado del crédito.

Registro del cambio de estado: fecha, estado anterior, nuevo estado y causa del cambio de estado, número de periodo académico. Este registro es por periodo académico.

Registro de los cambios de estado presentados en el día a día al crédito. Teniendo en cuenta que estos cambios de estado puede implicar un cambio de estado en el registro de cambio de estado por periodo académico.

Secuencia normal de acciones:

El sistema selecciona los créditos de los beneficiarios donde la fecha de finalización del periodo del programa académico asociado al crédito corresponda con la fecha del día. El sistema por cada crédito realiza lo siguiente: 1. El sistema lee la siguiente información de cada crédito:

a. Número de periodos del programa académico. b. Número de periodos académicos a financiar

definidos en el otorgamiento del crédito. c. Número de periodos financiados del programa

académico (o su equivalente en número de créditos académicos: (ver nota 1)) por el beneficiario.

d. Número de aplazamientos aplicados al

beneficiario: Obtenido del historial de estados e. Vigencia del programa académico. f. Fecha de Estado actual de la cartera del crédito

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

268

g. Fecha de inicio del periodo de gracia

2. El sistema evalúa la información anterior para determinar los cambios de estado a aplicar al crédito.

3. El sistema actualiza el estado del crédito (solicitud, obligación del crédito) de acuerdo a las diferentes causas que ocasionen el cambio de estado. (ver nota 2).

4. El sistema registra en un repositorio los cambios de estado de los créditos que se presentaron en el cierre de periodo académico. Esta información debe poderse consultar imprimir y enviarse a los beneficiarios e IES.

5. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Disponibilidad Debe quedar toda la información relacionada con el cierre del período académico referente a:

a. Cambio de estado: Estado anterior y nuevo estado.

b. Fecha del cambio c. Causa del cambio de estado. d. Usuario que cambio el estado. e. Número del periodo académico.

Gestionabilidad (Control del Proceso) Debe registrar los cambios de estado que se generan el cierre académico. Debe validar si ya se ha ejecutado los casos de uso previos obligatorios para la ejecución de este caso de uso.

Auditoria Debe quedar registrado en el sistema la ejecución del cierre del periodo académico (Usuario, Fecha, Hora inicial, Hora Final, Estado de Ejecución) y el detalle de cambio de estado de cada crédito:

a. Fecha de cambio estado b. Estado anterior c. Estado Nuevo d. Causa del cambio de estado e. Número de periodo académico.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

269

Notas y comentarios 1. Sistema de Créditos:

El crédito es una unidad de medida del trabajo académico del estudiante. Permite calcular el número de horas semanales en promedio por período académico dedicado por el estudiante a una actividad académica, lo cual constituye un referente común que facilita hacer equiparables las intensidades de la formación académica entre programas de diferentes instituciones, la transferencia y movilidad estudiantil dentro del sistema de Educación Superior, la homologación de estudios y la convalidación de títulos obtenidos en el exterior, y el ejercicio de las funciones de Inspección y Vigilancia en la verificación del cumplimiento de los estándares mínimos de calidad de los distintos programas académicos, en lo relacionado con la intensidad del trabajo académico de los estudiantes. Se aclara que esta unidad de medida es reportada por las IES al Ministerio de Educación Nacional, y en ningún momento es establecido por el ICETEX.

2. Cambios de estados de la obligación del crédito y de la

solicitud y las causas que generan el cambio en el cierre del periodo académico:

A Época de Gracia Al día o Atrasado en cuota : Por :

Finalización del programa de estudios: cumplió el número de periodos académicos finalizados y la modalidad cuenta con periodo de gracia.

Realización del último giro según el número de períodos académicos a financiar establecidos en el momento del otorgamiento y la modalidad cuenta con periodo de gracia.

A Etapa final de amortización al día: Por:

Finalización del programa de estudios y no tiene periodo de gracia.

Realización del último giro: según el número de períodos académicos a financiar establecidos en el momento del otorgamiento.

Paso del límite del número de periodos aplazados.

Reincidencia en la repetición del periodo académico.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

270

A Finalizado Por:

El crédito reúne las condiciones de condonación del 100%. Cambios de Estado de la solicitud a:

Aplazada

Bloqueada

Suspendida

Anulada Ver causas del cambio a los estados de la solicitud en el documento de Cambios de estado.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

271

14. NOVEDADES DE CARTERA

Consideraciones Generales sobre las novedades de Cartera

1. En el sistema se tendrá definido si la novedad ocasiona o no ocasiona una reestructuración del sistema.

2. En el sistema se tendrá definido si la novedad requiere o no autorización para renovar.

14.1 Pasar crédito a etapa final de amortización.

Código: NCA-SIS-001

Nombre: Pasar Crédito a etapa final de amortización.

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-16 Fecha de aprobación:

Objetivo Realizar el paso del crédito que se encuentra en época de estudio o en periodo de gracia a etapa final de Amortización.

Descripción El sistema realiza el paso del crédito que se encuentre en época de estudio o en periodo de gracia a etapa final de amortización. Este paso consiste en determinar el saldo total del crédito que se encuentra con causal de terminación (ver nota 1) en etapa de estudio o periodo de gracia y trasladarlo a etapa final de amortización generando el plan de cuotas respectivo. El saldo que se traslada corresponde a la sumatoria de los componentes del crédito: capital, intereses, prima de seguro y demás conceptos adeudados (ver nota 2). El interés que se traslada y que conforma el saldo inicial del crédito tendrá un manejo especial para su contabilización (ver nota 3).

Actores Principales Funcionarios de vicepresidencia de operaciones y tecnología

Ejecuta la novedad en el sistema.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

272

Actores secundarios Beneficiario Solicita que su crédito sea trasladado a etapa final de amortización.

Contratistas del ICETEX (atención al usuario)

Informan al beneficiario el paso del crédito a etapa final de amortización.

Seguimiento al crédito

Informan al Beneficiario el paso del crédito a etapa final de amortización.

IES Informan de créditos que deben ser pasados a etapa final de amortización.

Precondiciones: El crédito debe estar en época de estudio o en periodo de gracia.

Estado de terminación del crédito en época de estudio.

Vencimiento del periodo de gracia.

Solicitud expresa del beneficiario.

Poscondiciones Cambio de estado del crédito a etapa final de amortización.

Cerrar saldo crédito en época de estudios: Dejar un registro del capital, interés, prima de seguro y otros conceptos que conformaran el saldo inicial del crédito en etapa final de amortización y la marcación de que ya se cerró esta etapa del crédito.

Saldo inicial para etapa final de amortización.

Plan de Cuotas Generado

Alimentar el repositorio de créditos trasladados a amortización este.

Secuencia normal de acciones:

1. El usuario o contratista de cartera selecciona la opción de paso de crédito a amortización.

2. El usuario selecciona la operación que desea aplicarle la novedad (ver caso de uso buscar operación: NCA-SIS-017) y registra la causal

3. El sistema presenta los datos del crédito y válida que tenga una causal de terminación.

4. El sistema presenta los saldos del crédito a la fecha, y las nuevas condiciones del crédito ( tasa de interés, sistema de amortización, plazo, valor de cuota)

5. El usuario de cartera selecciona la opción de pasar el crédito a etapa final de amortización y confirma el paso al cobro

6. El sistema cambia el estado del crédito a etapa final de amortización.

7. El sistema genera el plan de cuotas de acuerdo a las opciones confirmadas (ver caso de uso generación plan de cuotas).

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

273

8. El sistema presenta mensaje de paso a amortización realizado con éxito.

9. El sistema genera carta al beneficiario ratificando condiciones de amortización del crédito.

10. El sistema genera plan de pagos para ser entregado al beneficiario. (Se tendrá la opción de impresión para entrega al beneficiario).

11. El sistema registra en el repositorio de créditos trasladados a amortización la información del traslado. (ver nota 4).

12. Fin del proceso.

Secuencias alternas 8a Se podrá modificar por solicitud del beneficiario el plazo del crédito para lo cual el sistema debe contar con la opción de recalculo de cuotas en función del plazo. 8b. Se podrá modificar el tipo de plan de amortización por solicitud del beneficiario para lo cual el sistema debe contar con la opción de recalculo de cuotas en función del plan de amortización.

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución de la novedad. El sistema debe solo habilitar esta opción sobre los créditos que puede gestionar el usuario. El sistema debe validar que el usuario que esta realizando la novedad tenga autorización para ejecutarla en ese horario. Se requiere de un control dual para que la novedad sea ejecutada (ver caso de uso Autorizar Ejecución de la novedad).

Gestionabilidad (Control del Proceso)

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

274

El crédito debe estar marcado como paso a etapa final de amortización junto con las causales de terminación. Después de la aplicación de este caso de uso el estado del crédito es etapa final de amortización.

Auditoria Deben quedar registrados en el sistema todos los eventos que se presentaron en la aplicación de la novedad. Especialmente las autorizaciones de cambio de plazo y cambio del sistema de amortización

Notas y comentarios 1. Causales de terminación :

Superar número de aplazamientos en época de estudios.

Finalización del periodo de gracia o de estudio ( crédito tradicional)

Retiro de la universidad – Informado por la universidad

Retiro de la universidad – Informado por el Estudiante

Retiro de la universidad – Verificación de seguimiento al crédito

Cambio de programa académico sin aprobación del ICETEX.

No renovación por más de dos periodos académicos por parte del estudiante.

Documentación falsa

2. Conceptos adeudados adicionales al crédito: Corresponden a

los cobros que se parametrizen para ser cobrados al deudor. Estos cobros adicionales no serán adicionados al capital si no que se manejaran de manera independiente. Pero se asociarán a la cuota inicial.

3. El sistema determina el porcentaje que representa el interés

que se traslado de la etapa de estudio a la etapa final de amortización sobre el saldo inicial que se determinó para el inicio de la etapa final de amortización. Este porcentaje lo tiene cuenta para realizar las afectaciones contables cada vez que se registre un recaudo sobre el crédito en etapa final de amortización. La afectación contable la realiza de la siguiente manera cada vez que se registre un recaudo:

a. Determina el valor que esta amortizando a capital del

valor total del recaudo.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

275

b. Sobre el valor anterior obtiene un nuevo valor que corresponde al porcentaje que representó el interés sobre el saldo inicial.

c. Y con el valor anterior genera un movimiento a contabilizar por concepto del interés trasladado a la etapa final de amortización.

4. La información registrada en el repositorio debe contener las

condiciones e información básica:

nombre beneficiario

número de crédito

modalidad de crédito

Saldo total a amortizar.

Sistema de Amortización

número de cuotas

valor de cuota

fecha de vencimiento

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

276

14.2 Pasar crédito a época de estudio.

Código: NCA-SIS-002

Nombre: Pasar Crédito a época de estudio.

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-16 Fecha de aprobación:

Objetivo Realizar el paso del crédito que se encuentra en etapa final de amortización a época de estudio.

Descripción El sistema realiza el paso del crédito que se encuentre en etapa final de amortización a época de estudio.

Actores Principales Funcionarios de vicepresidencia de operaciones y tecnología

Ejecuta la novedad en el sistema.

Actores secundarios

Precondiciones: El crédito debe estar en etapa final de amortización.

Soporte del paso a época de estudio..

Poscondiciones Cambio de estado del crédito a CEE al día o CEE atrasado en cuota. ( CEE: crédito en época de estudio).

Reverso de las transacciones realizadas posterior a la fecha de época de estudio que se está reversando.

Actualizar saldos del crédito a la fecha. ( Recalculo de Saldos)

Actualizar el estado del plan de cuotas de etapa final de amortización a estado no vigente.

Alimentar el repositorio de créditos devueltos de etapa final de amortización a época de estudio.

Secuencia normal de acciones:

1. El usuario o contratista de cartera selecciona la opción de paso de crédito de etapa final de amortización a época de estudio.

2. El usuario selecciona el crédito que desea aplicarle la novedad (ver caso de uso buscar crédito: NCA-SIS-017). Estos créditos deben estar en etapa final de amortización.

3. El sistema solicita los datos para realizar el paso del crédito a

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

277

época de estudio: a. Fecha del crédito en época de estudio b. Causa de la devolución del crédito de etapa final de

amortización a época de estudio. 4. El usuario ingresa los datos solicitados por el sistema. 5. El sistema valida que el dato de fecha sea consistente para

pasar el crédito a época de estudio. 6. El usuario de cartera confirma el paso del crédito a época de

estudio. 7. El sistema cambia el estado del crédito a CEE al día o CEE

atrasado en cuota. 8. El sistema deja como no vigente el plan de cuotas de etapa

final de amortización. 9. El sistema deja como no vigente el plan de cuotas época de

estudio y genera un nuevo plan de cuotas vigente de época de estudio.

10. El sistema aplica la novedad de ejecutando el caso de uso recalcular saldos de la operación desde la fecha de la novedad.

11. El sistema presenta mensaje de crédito trasladado a época de estudio con éxito.

12. El sistema registra en el repositorio de créditos trasladados de etapa final de amortización a la época de estudio.

13. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

Seguridad El sistema debe contar con mecanismos de autenticación para que valide el usuario y le habilite la opción de ejecución de la novedad. El sistema debe solo habilitar esta opción sobre los créditos que puede gestionar el usuario. El sistema debe validar que el usuario que esta realizando la

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

278

novedad tenga autorización para ejecutarla en ese horario. Se requiere de un control dual para que la novedad sea ejecutada (ver caso de uso Autorizar Ejecución de la novedad).

Gestionabilidad (Control del Proceso) El crédito debe estar marcado como paso a etapa final de amortización junto con las causales de terminación. Después de la aplicación de este caso de uso el estado del crédito es etapa final de amortización.

Auditoria Deben quedar registrados en el sistema todos los eventos que se presentaron en la aplicación de la novedad. Especialmente las autorizaciones de cambio de plazo y cambio del sistema de amortización

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

279

14.3 Reversar Pago

Código: NCA-SIS-003

Nombre: Reversar Pago

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Reversar un pago que se aplicó a un crédito.

Descripción El usuario de cartera debe realizar la reversión de un pago por causas como:

Pago aplicado a otro crédito

Cheque devuelto

Pago aplicado dos veces. La reversión de pagos se puede dar en época de estudios, periodo de gracia y en etapa final de amortización. En la duración del crédito se puede presentar varias reversiones. La reversión puede provenir adicionalmente de la aplicación del archivos de inconsistencia que provee el modulo financiero y que corresponde al reporte bancario.

Actores Principales Funcionario de Cartera Ejecuta la novedad.

Actores secundarios Beneficiario Informa que el pago no ha sido aplicado al crédito.

Atención al usuario Gestiona y corrobora aplicación del pago. Elabora el soporte de reversión del pago.

Precondiciones: Soporte de Consignación no aplicada al crédito del beneficiario indicando que se le aplicó al beneficiario incorrecto (solo aplica para el caso de pago aplicado a otro crédito).

Soporte de devolución de cheque.

Pago doble aplicado por error del banco o error interno del ICETEX (Novedad mal aplicada).

Poscondiciones Nuevo saldo de capital.

Nuevo saldo de interés.

Marcación del pago como reverso total.

Registro del movimiento de reverso total.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

280

Secuencia normal de acciones:

1. El usuario selecciona la opción Reversión de pago 2. El usuario selecciona el crédito que desea aplicar la novedad

(ver caso de uso buscar operación: NCA-SIS-017). 3. El sistema presenta los pagos aplicados al crédito. 4. El usuario selecciona el pago a reversar. 5. El sistema reversa el pago ejecutando el caso de uso

recalcular saldos de la operación desde la fecha de la novedad (ver caso de uso Recalcular saldos de la operación desde la fecha de la novedad: NCA-SIS-016).

6. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

Seguridad El sistema debe contar con mecanismos de autenticación y autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario. El sistema debe contar con la posibilidad de solicitar autorizaciones en línea otros funcionarios o leer estas autorizaciones si ya habían sido ingresadas para poder ejecutar la novedad. Se requiere de un control dual para que la novedad sea ejecutada (ver caso de uso Autorizar Ejecución de la novedad).

Gestionabilidad (Control del proceso) Puede presentarse cambio de estado dependiendo de los días de mora que pueda generar esta reversión. Este cambio debe evaluarse para establecer su nuevo estado en la clasificación de cartera (Ver caso de uso clasificar cartera:).

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

281

Auditoria Debe quedar registrada la información de quien y cuando se ejecutó la novedad. Deben quedar registradas todas las autorizaciones de los funcionarios que aprobaron la ejecución de la novedad. Debe quedar registrada toda la información relacionada con la autorización de la novedad: Número de Soporte de la novedad.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

282

14.4 Aplicar Pago

Código: NCA-SIS-004

Nombre: Aplicar Pago

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Realizar la aplicación de un pago no aplicado en el proceso masivo.

Descripción El usuario de cartera debe realizar la aplicación de pagos que no fueron subidos por inconsistencias en la información.

Actores Principales Funcionario de Cartera Ejecuta la aplicación del pago total.

Actores secundarios Atención al Usuario Atiende y gestiona la solicitud de la no aplicación del pago.

Beneficiario Informa que no le ha sido aplicado el pago a su crédito.

Precondiciones: Soporte de Consignación de pago no aplicada al crédito del beneficiario.

Poscondiciones Novedad de pago por autorizar.

Pago Aplicado.

Secuencia normal de acciones:

1. El usuario selecciona la opción Aplicar pago 2. El usuario selecciona el crédito al que desea aplicar la

novedad (ver caso de uso buscar crédito: NCA-SIS-017). 3. El sistema presenta los campos de fecha de pago y valor del

pago para ingresar. 4. El usuario ingresa la información solicitada del pago. 5. El sistema valida si la novedad que se va a realizar requiere

autorización. ( ver caso de uso Solicitar Autorización). 6. El sistema aplica el pago ejecutando el caso de uso recalcular

saldos de la operación desde la fecha de la novedad. 7. El sistema presenta mensaje de aplicación de pago. 8. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

283

establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

Seguridad El sistema debe contar con mecanismos de autenticación y autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario. El sistema debe contar con la posibilidad de solicitar autorizaciones en línea a otros funcionarios o leer estas autorizaciones si ya habían sido ingresadas para poder ejecutar la novedad. Se requiere de un control dual para que la novedad sea ejecutada (ver caso de uso Autorizar Ejecución de la novedad).

Gestionabilidad (Control del proceso) Puede presentarse cambio de estado para los créditos que no estén al día; debido a la eventual disminución en días de mora que podría generar esta aplicación de pago. Este cambio debe evaluarse para establecer su nuevo estado en la clasificación de cartera (Ver caso de uso clasificar cartera:).

Auditoria Debe quedar registrada la información de quien y cuando se ejecutó la novedad. Deben quedar registradas todas las autorizaciones de los funcionarios que aprobaron la ejecución de la novedad. Debe quedar registrada toda la información relacionada con la autorización de la novedad: Número de Soporte de la novedad.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

284

14.5 Aplicar Condonación Total

Código: NCA-SIS-005

Nombre: Aplicar Condonación Total

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-08 Fecha de aprobación:

Objetivo Realizar la cancelación de un crédito que cumple con los requisitos de condonación.

Descripción La oficina de cartera debe cancelar el crédito por condonación cuando se presentan las siguientes condiciones:

Muerte del beneficiario.

Invalidez del beneficiario (cuando el beneficiario hubiese perdido el 50% o más de su capacidad laboral).

Por prestación de servicios o reembolso en especie

Culminación de estudios en el caso que la modalidad de crédito o fondo lo tenga establecido.

Actores Principales Funcionario de Cartera Ejecuta la novedad en el sistema.

Actores secundarios

Beneficiario, Codeudores o Apoderados

Solicita la condonación total informando la causa.

Atención al Usuario. Gestiona la solicitud de condonación y la dirige al comité de cartera y cobranzas.

Comité de cartera y cobranzas. Aprueba o no aprueba la condonación.

Precondiciones: Deben estar parametrizadas las condiciones de la modalidad del crédito para aplicar la condonación total del crédito.

Soportes para aplicar la condonación para el comité.

Acta de comité de aprobación de condonaciones.

Poscondiciones

Actualización del estado del Crédito: Finalizado por condonación Total del Crédito.

Recalculo de saldos dependiendo de la fecha de la novedad

Actualización de los saldos del crédito.

Registro de la transacción de Condonación Total.

Secuencia normal de acciones:

1. El Beneficiario, codeudores o apoderados solicita la condonación del crédito.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

285

2. Atención al Usuario recibe solicitud(es) de Condonación. 3. Atención al Usuario válida si es posible aplicar la(s) condonación(es). 4. Atención al Usuario prepara y clasifica las solicitudes de condonación

de los créditos. 5. El comité de cartera evalúa la solicitud de condonación. 6. El comité de cartera aprueba la(s) condonación(es) del crédito por

medio de un acto administrativo. 7. El usuario de cartera selecciona la opción de aplicar la Condonación. 8. El sistema presenta la lista de causales disponibles para aplicar la

condonación. 9. El usuario selecciona la causal de condonación; causal que será

asociada de manera automática a los créditos que se seleccionen. (pero se podrá modificar la causal para un crédito en particular).

10. El usuario selecciona la(s) operación(es) que desea aplicar la novedad (ver caso de uso buscar de operación: NCA-SIS-017). (El sistema proveerá la funcionalidad de ver la información de detalle de cada una de las operaciones seleccionadas).

11. El usuario marca o desmarca los créditos que desea aplicarle la novedad.

12. El usuario ingresa los datos de la condonación: a. Número de resolución que aprobó la condonación. b. Porcentaje de la condonación : 100 %. c. Fecha desde la cual aplica la condonación. d. El sistema con los datos anteriores presenta el valor de

condonación. (El valor sobre el cual aplica el porcentaje de condonación se obtendrá del histórico de saldos diarios).

13. El usuario confirma la aplicación de la condonación de los créditos marcados.

14. El sistema aplica la novedad de condonacion ejecutando el caso de uso recalcular saldos de la operación desde la fecha de la novedad.

15. El sistema salda el crédito de los créditos marcados. 16. El sistema cambia el estado de los créditos a finalizado por

Condonación Total. 17. El sistema registra la transacción de condonación total de los créditos

que se seleccionaron para aplicarle la novedad. 18. Fin del proceso.

Secuencias alternas 6a. El comité de cartera no aprueba la condonación del crédito por que hay inconsistencias en la información.

Se le solicita al outsourcing de seguimiento al crédito que se contacte con el beneficiario o el deudor y confirma la información. Una vez se hacen las modificaciones pertinentes se retoma desde el paso cinco (5) del flujo normal.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

286

6b. El comité de cartera no aprueba la condonación del crédito por que no cumple con los requisitos exigidos para la condonación del crédito.

Requerimientos no funcionales

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

Seguridad El sistema debe contar con mecanismos de autenticación y autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario. El sistema debe contar con la posibilidad de solicitar autorizaciones en línea a otros funcionarios o leer estas autorizaciones si ya habían sido ingresadas para poder ejecutar la novedad. Se requiere de un control dual para que la novedad sea ejecutada (ver caso de uso Autorizar Ejecución de la novedad).

Gestionabilidad (Control del proceso) Se presenta un cambio de estado a finalizado por condonación total.

Auditoria Debe quedar registrada la información de quien y cuando se ejecutó la novedad. Deben quedar registradas todas las autorizaciones de los funcionarios que aprobaron la ejecución de la novedad. Debe quedar registrada toda la información relacionada con la autorización de la novedad: Número de Soporte de la novedad.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

287

14.6 Aplicar condonación parcial

Código: NCA-SIS-006

Nombre: Aplicar Condonación Parcial

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-16 Fecha de aprobación:

Objetivo Disminuir el saldo del crédito por el valor parcial condonado y generar el nuevo plan de pagos.

Descripción La oficina de cartera debe liquidar un crédito cuando se presentan las siguientes condiciones:

Muerte del beneficiario,

invalidez (cuando el beneficiario hubiese perdido el 50% o más de su capacidad laboral)

Por prestación de servicios o reembolso en especie

Culminación de estudios en el caso que la modalidad de crédito o fondo lo tenga establecido.

Actores Principales Funcionario de Cartera Ejecuta la novedad en el sistema.

Actores secundarios Beneficiario Solicita la condonación total informando la causa.

Atención al Usuario. Gestiona la solicitud de condonación y la dirige al comité de Cartera.

Comité de cartera Aprueba o no aprueba la condonación.

Precondiciones: La modalidad de crédito o fondo debe tener establecidos los requisitos para la condonación parcial o total del crédito.

Poscondiciones Registro de la transacción de condonación parcial del crédito.

Recalculo de saldos dependiendo de la fecha de la novedad

Actualización de los saldos del crédito.

Actualización del estado del crédito.

Secuencia normal de acciones:

1. El Beneficiario solicita la condonación parcial del crédito. 2. Atención al Usuario recibe solicitud de Condonación. 3. Atención al Usuario válida si es posible aplicar la condonación

parcial.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

288

4. Atención al Usuario genera solicitud de Condonación parcial del crédito.

5. El comité de cartera evalúa la solicitud de condonación parcial.

6. El comité de cartera aprueba la condonación parcial del crédito por medio de un acto administrativo.

7. El usuario de cartera selecciona la opción de aplicar la Condonación parcial.

8. El usuario selecciona la operación que desea aplicar la novedad (ver caso de uso buscar de operación: NCA-SIS-017).

9. El sistema presenta el mensaje de que al crédito se le puede aplicar la condonación parcial.

10. El sistema presenta las posibles causas de condonación para que el usuario seleccione la causa.

11. El usuario selecciona la causa de condonación. 12. El usuario ingresa los datos de la condonación:

a. Número de resolución que aprobó la condonación.

b. Porcentaje de la condonación. c. Fecha desde la cual aplica la condonación. d. El sistema con los datos anteriores presenta el

valor de condonación. (El valor sobre el cual aplica el porcentaje de condonación se obtendrá del histórico de saldos diarios).

13. El sistema aplica la novedad de condonacion ejecutando el

caso de uso recalcular saldos de la operación desde la fecha de la novedad.

14. El sistema presenta el mensaje de confirmación de la aplicación de la condonación.

15. El usuario confirma la aplicación de la condonación parcial. 16. El sistema presenta los nuevos saldos del crédito. 17. El sistema registra la transacción del la novedad de

condonación parcial. 18. Fin del proceso.

Secuencias alternas 6a. El comité de cartera no aprueba la condonación del crédito por que hay inconsistencias en la información.

Se le solicita al outsourcing de seguimiento al crédito que se contacte con el beneficiario o el deudor y confirma la información. Una vez se hacen las modificaciones pertinentes se retoma desde el paso cinco (5) del flujo

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

289

normal.

6b. El comité de cartera no aprueba la condonación del crédito por que no cumple con los requisitos exigidos para la condonación del crédito.

Requerimientos no funcionales

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado

Seguridad El sistema debe contar con mecanismos de autenticación y autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario. El sistema debe contar con la posibilidad de solicitar autorizaciones en línea a otros funcionarios o leer estas autorizaciones si ya habían sido ingresadas para poder ejecutar la novedad.

Gestionabilidad (Control del proceso) Se debe registrar el cambio de estado si la aplicación de la condonación parcial lo generó.

Auditoria Debe quedar registrada la información de quien y cuando se ejecutó la novedad. Deben quedar registradas todas las autorizaciones de los funcionarios que aprobaron la ejecución de la novedad. Debe quedar registrada toda la información relacionada con la autorización de la novedad: Número de Soporte de la novedad.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

290

14.7 Reversar Giro

Código: NCA-SIS-007

Nombre: Reversar Giro Total

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-08 Fecha de aprobación:

Objetivo Reversar el total del giro aplicado incorrectamente al beneficiario.

Descripción El área de cartera debe realizar la reversión de un giro que no fue utilizado o fue aplicado a otro crédito. La reversión de giros se puede dar en época de estudios, periodo de gracia y en etapa final de amortización. En la duración del crédito se puede presentar varias reversiones.

Actores Principales Funcionario de Cartera Ejecuta el reverso del giro.

Actores secundarios Beneficiario Informa que aparece un giro que no le corresponde.

Atención al Usuario Atiende y gestiona la solicitud de la reversión del giro.

Precondiciones: Soporte de Giro aplicado incorrectamente.

Poscondiciones

Nuevos saldos del crédito.

Marcación del giro como reverso total.

Registro del movimiento de reverso total.

Secuencia normal de acciones:

1. El Beneficiario informa que existe un giro aplicado al crédito

que no se ha efectuado. 2. Atención al Usuario recibe la solicitud de reversión de giro 3. Atención al Usuario válida que el giro ha sido aplicado al

crédito pero que no ha sido utilizado. 4. Atención al Usuario genera solicitud reversión de giro. 5. El usuario de cartera selecciona la opción de reversión de

giro. 6. El usuario selecciona la operación que desea aplicar la

novedad (ver caso de uso buscar de operación: NCA-SIS-017).

7. El sistema presenta los giros del crédito.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

291

8. El usuario selecciona el giro reversar. 9. El sistema aplica la novedad ejecutando el caso de uso

recalcular saldos de la operación desde la fecha de la novedad.

10. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado

Seguridad El sistema debe contar con mecanismos de autenticación y autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario. El sistema debe contar con la posibilidad de solicitar autorizaciones en línea a otros funcionarios o leer estas autorizaciones si ya habían sido ingresadas para poder ejecutar la novedad. Se requiere de un control dual para que la novedad sea ejecutada (ver caso de uso Autorizar Ejecución de la novedad).

Gestionabilidad (Control del proceso) Puede presentarse cambio de estado para los créditos que no estén al día; debido a la eventual disminución en días de mora que podría generar esta aplicación de giro. Este cambio debe evaluarse para establecer su nuevo estado en la clasificación de cartera (Ver caso de uso clasificar cartera:).

Auditoria Debe quedar registrada la información de quien y cuando se ejecutó la novedad. Deben quedar registradas todas las autorizaciones de los

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

292

funcionarios que aprobaron la ejecución de la novedad. Debe quedar registrada toda la información relacionada con la autorización de la novedad: Número de Soporte de la novedad.

Notas y comentarios 1. Las variables para filtrar pueden ser: Número de identificación el beneficiario, nombre del beneficiario o código del crédito.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

293

14.8 Aplicar Giro

Código: NCA-SIS-008

Nombre: Aplicar Giro

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-08 Fecha de aprobación:

Objetivo Realizar la aplicación de un giro que no fue registrado o aplicado en el proceso masivo.

Descripción El usuario de cartera debe realizar la aplicación de giros que no fueron aplicados al crédito.

Actores Principales Funcionario de Cartera Ejecuta la aplicación del giro.

Actores secundarios Beneficiario Informa que no le ha sido aplicado el giro.

Atención al Usuario Atiende y gestiona la solicitud de la no aplicación del giro.

Precondiciones:

Soporte de Giro no aplicada al crédito

Poscondiciones Giro. Aplicado

Secuencia normal de acciones:

1. El usuario selecciona la opción de aplicación de giro 2. El usuario selecciona la operación que desea aplicar la

novedad (ver caso de uso buscar de operación: NCA-SIS-017).

3. El sistema presenta los campos para ingresar la fecha del giro y el valor del giro.

4. El usuario ingresa la información de valor y fecha del giro. 5. El usuario confirma la aplicación del giro. 6. El sistema aplica el giro ejecutando el caso de uso recalcular

saldos de la operación desde la fecha de la novedad. 7. El sistema presenta mensaje de aplicación de giro 8. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo establecido para transacciones de corta duración.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

294

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado

Seguridad El sistema debe contar con mecanismos de autenticación y autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario. El sistema debe contar con la posibilidad de solicitar autorizaciones en línea a otros funcionarios o leer estas autorizaciones si ya habían sido ingresadas para poder ejecutar la novedad. Se requiere de un control dual para que la novedad sea ejecutada (ver caso de uso Autorizar Ejecución de la novedad).

Gestionabilidad (Control del proceso) Puede presentarse cambio de estado para los créditos debido al eventual aumento en días de mora que podría generar esta aplicación de giro. Este cambio debe evaluarse para establecer su nuevo estado en la clasificación de cartera (Ver caso de uso clasificar cartera:).

Auditoria Debe quedar registrada la información de quien y cuando se ejecutó la novedad. Deben quedar registradas todas las autorizaciones de los funcionarios que aprobaron la ejecución de la novedad. Debe quedar registrada toda la información relacionada con la autorización de la novedad: Número de Soporte de la novedad.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

295

14.9 Ampliar Número de Cuotas

Código: NCA-SIS-009

Nombre: Ampliar Número de Cuotas.

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-08 Fecha de aprobación:

Objetivo Realizar la ampliación en número de cuotas para la amortización de la deuda del crédito.

Descripción El usuario de cartera realiza la ampliación de tiempo que se tiene para cancelar la deuda del crédito

Actores Principales Funcionario de novedades de Cartera.

Ejecuta este caso de uso.

Actores secundarios Beneficiario Solicita aumentar el número de cuotas.

Atención al Usuario Atiende y Gestiona Solicitud

Comité de Cartera Aprueba Solicitud.

Precondiciones: Crédito en etapa final de amortización.

La obligación debe estar al día en los pagos (Cuando esta en mora se conoce como refinanciación).

Poscondiciones Ampliación del número de cuotas (Solo se puede ampliar hasta la mitad del tiempo inicial pactado (sujeto a Parametrización).

Reliquidación de los componentes de las cuotas y Generación de una nueva tabla de amortización.

Secuencia normal de acciones:

1. El usuario selecciona la opción de aplicar ampliación. 2. El usuario selecciona la operación que desea aplicar la

novedad (ver caso de uso buscar de operación: NCA-SIS-017).

3. El sistema solicita el nuevo número de cuotas. 4. El sistema Aplica la ampliación. 5. El sistema realiza las afectaciones correspondientes de los

componentes del crédito generando una nueva tabla de amortización.

6. El usuario imprime la información del nuevo plan de cuotas. 7. Fin del proceso.

Secuencias alternas

Requerimientos no

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

296

funcionales Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado

Seguridad El sistema debe contar con mecanismos de autenticación y autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario. El sistema debe contar con la posibilidad de solicitar autorizaciones en línea a otros funcionarios o leer estas autorizaciones si ya habían sido ingresadas para poder ejecutar la novedad. Se requiere de un control dual para que la novedad sea ejecutada (ver caso de uso Autorizar Ejecución de la novedad).

Gestionabilidad (Control del proceso) No se presentan cambio de estado del crédito porque este debe estar al día para aplicar esta novedad.

Auditoria Debe quedar registrada la información de quien y cuando se ejecutó la novedad. Deben quedar registradas todas las autorizaciones de los funcionarios que aprobaron la ejecución de la novedad. Debe quedar registrada toda la información relacionada con la autorización de la novedad: Número de Soporte de la novedad.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

297

14.10 Refinanciar Crédito

Código: NCA-SIS-010

Nombre: Refinanciar Crédito.

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-08 Fecha de aprobación:

Objetivo Realizar la ampliación en número de cuotas para la amortización de la deuda del crédito.

Descripción El usuario de cartera realiza la ampliación de tiempo que se tiene para cancelar la deuda del crédito

Actores Principales Funcionario de novedades de Cartera.

Ejecuta este caso de uso.

Actores secundarios Beneficiario Solicita refinanciación.

Atención al Usuario Atiende y Gestiona Solicitud

Comité de Cartera Aprueba Solicitud.

Precondiciones: Crédito en etapa final de amortización.

La obligación debe estar en mora

El valor de la cuota deber ser superior a medio salario mínimo, siempre y cuando no supere el numero de cuotas autorizadas (hoy esta hasta 96). (sujeto a Parametrización).

Poscondiciones Ampliación del número de cuotas. Solo se puede ampliar hasta la mitad del tiempo inicial pactado (sujeto a parametrización).

Reliquidación de los componentes de las cuotas y Generación de una nueva tabla de amortización.

Secuencia normal de acciones:

1. El usuario selecciona la opción de aplicar ampliación. 2. El usuario selecciona la operación que desea aplicar la

novedad (ver caso de uso buscar de operación: NCA-SIS-017).

3. El sistema solicita el nuevo número de cuotas. 4. El sistema aplica la ampliación. 5. El sistema realiza las afectaciones correspondientes de los

componentes del crédito generando una nueva tabla de amortización.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

298

6. El usuario imprime la información del nuevo plan de cuotas. 7. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

Seguridad El sistema debe contar con mecanismos de autenticación y autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario. El sistema debe contar con la posibilidad de solicitar autorizaciones en línea a otros funcionarios o leer estas autorizaciones si ya habían sido ingresadas para poder ejecutar la novedad. Se requiere de un control dual para que la novedad sea ejecutada (ver caso de uso Autorizar Ejecución de la novedad).

Gestionabilidad (Control del proceso) Debe registrarse el cambio de estado de los estados no al día (En Mora, Cobro Prejuridico, Cobro Jurídico) a estado al día.

Auditoria Debe quedar registrada la información de quien y cuando se ejecutó la novedad. Deben quedar registradas todas las autorizaciones de los funcionarios que aprobaron la ejecución de la novedad. Debe quedar registrada toda la información relacionada con la autorización de la novedad: Número de Soporte de la novedad.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

299

14.11 Modificar valor de cuota

Código: NCA-SIS-011

Nombre: Modificar valor de cuota

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-08 Fecha de aprobación:

Objetivo Modificar Valor de la cuota.

Descripción El usuario de cartera realiza la modificación del valor de la cuota por las siguientes causas:

Abono extraordinario de Capital a solicitud del Beneficiario.

Paso incorrecto a etapa final de amortización ( p.e numero de cuotas asignadas no corresponden).

Solicitud del beneficiario para :

Disminuir valor de cuota lo que ocasiona un aumento en el número de cuotas.

Disminuir el número de cuotas lo que ocasiona un incremento en el valor de la cuota.

Actores Principales Funcionario de Cartera Aplica modificación.

Actores secundarios Atención al usuario Gestiona solicitud

Beneficiario Solicita modificación valor de la cuota

Precondiciones: Crédito en etapa final de amortización.

La obligación debe estar al día.

Poscondiciones Ampliación o disminución del número de cuotas

Reliquidación de los componentes de las cuotas y Generación de una nueva tabla de amortización.

Secuencia normal de acciones:

1. El usuario selecciona la opción de modificar valor de cuota. 2. El usuario selecciona la operación que desea aplicar la

novedad (ver caso de uso buscar de operación: NCA-SIS-017).

3. El sistema presenta las opciones disponibles de disminución de valor de cuota, modificación del número de cuotas o abono a capital del valor que no se ha utilizado del beneficiario.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

300

4. El usuario elige una opción de las mencionadas anteriormente.

5. El sistema solicita datos de acuerdo a la opción seleccionada. 6. El usuario ingresa los datos según la opción. 7. El sistema realiza las afectaciones correspondientes de los

componentes del crédito generando una nueva tabla de amortización.

8. El usuario imprime la información del nuevo plan de cuotas. 9. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

Seguridad El sistema debe contar con mecanismos de autenticación y autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario. El sistema debe contar con la posibilidad de solicitar autorizaciones en línea a otros funcionarios o leer estas autorizaciones si ya habían sido ingresadas para poder ejecutar la novedad. Se requiere de un control dual para que la novedad sea ejecutada (ver caso de uso Autorizar Ejecución de la novedad).

Gestionabilidad (Control del proceso) No se registra cambio de estado, debido a que la aplicación de esta novedad exige estar al día.

Auditoria

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

301

Debe quedar registrada la información de quien y cuando se ejecutó la novedad. Deben quedar registradas todas las autorizaciones de los funcionarios que aprobaron la ejecución de la novedad. Debe quedar registrada toda la información relacionada con la autorización de la novedad: Número de Soporte de la novedad.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

302

14.12 Prorrogar Crédito

Código: NCA-SIS-012

Nombre: Prorrogar Crédito.

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-08 Fecha de aprobación:

Objetivo Realizar la suspensión de pagos en un tiempo determinado.

Descripción El sistema registra la suspensión de pagos hasta una fecha dada, lo que ocasiona que se modifiquen las fechas limites de pago de cuotas que están entre la fecha de hoy y la fecha de la prorroga. Las fechas límites de pago de estas cuotas se modifican por la fecha de la prorroga. Al terminarse el periodo de prorroga el sistema debe distribuir los intereses generados durante el tiempo de prorroga entre las cuotas restantes por cancelar, es decir el valor de las cuotas pendientes aumentaran debido a la distribución del interés corriente generado durante la prorroga. Los intereses generados durante la prorroga solo se suman a los intereses corrientes de las cuotas y no se capitalizan.

Actores Principales Funcionario de Cartera Ejecuta la novedad en el sistema.

Actores secundarios Beneficiario Solicita la prorroga para el pago de sus obligaciones.

Atención al Usuario. Gestiona la solicitud de prorroga.

Comité de cartera Aprueba o no aprueba la tercera prorroga.

Precondiciones: El crédito debe estar en etapa final de amortización.

El crédito debe estar al día en el pago de obligaciones hasta la fecha de solicitud de prórroga.

Poscondiciones

Cambio de las fechas de pago de las cuotas afectadas por la

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

303

prorroga.

Registro del movimiento de la prorroga.

Secuencia normal de acciones:

1. El beneficiario solicita la prórroga 2. Atención al usuario recibe la solicitud 3. Atención al usuario genera solicitud de prorroga 4. Comité de cartera evalúa y aprueba la solicitud solo si

corresponde a una prorroga adicional a la que tiene derecho el beneficiario por reglamento.

5. El usuario selecciona la opción de prorrogar el crédito. 6. El usuario selecciona la operación que desea aplicar la

novedad (ver caso de uso buscar de operación: NCA-SIS-017).

7. El usuario selecciona la operación a prorrogar 8. El sistema presenta los tiempos disponibles para prorrogar

según la línea de crédito. 9. El usuario elige el tiempo de prorroga. 10. El sistema presenta la fecha de prorroga (hasta que fecha hay

suspensión de pagos). 11. El sistema presenta las cuotas que estarían sujetas a la

suspensión de pagos. 12. El sistema solicita confirmación de aplicar la prorroga. 13. El usuario confirma la aplicación de prorroga. 14. El sistema actualiza el estado del crédito en prorroga. 15. El sistema registro del número de prorrogas aplicadas al

crédito. 16. El sistema modifica la fecha límite de pago de las cuotas

afectadas por la prorroga. 17. Fin del proceso.

Secuencias alternas 5a. El Comité de cartera no aprueba la solicitud de prórroga porque no cumple con los requisitos exigidos para dicha ampliación

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

304

requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

Seguridad El sistema debe contar con mecanismos de autenticación y autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario. El sistema debe contar con la posibilidad de solicitar autorizaciones en línea a otros funcionarios o leer estas autorizaciones si ya habían sido ingresadas para poder ejecutar la novedad.

Gestionabilidad (Control del proceso) No se registra cambio de estado, debido a que la aplicación de esta novedad exige estar al día.

Auditoria Debe quedar registrada la información de quien y cuando se ejecutó la novedad. Deben quedar registradas todas las autorizaciones de los funcionarios que aprobaron la ejecución de la novedad. Debe quedar registrada toda la información relacionada con la autorización de la novedad: Número de Soporte de la novedad.

Notas y comentarios 1. La prorroga puede hacerse hasta 12 meses en 2 periodos de 6 meses. (Definición sujeta a parametrización).

2. Solo se pueden hacer 2 solicitudes de prorroga. (Definición sujeta a parametrización)

3. Es posible realizar una tercera prorroga pero debe contar con la aprobación en el comité de cartera y solo podrá realizarla un funcionario autorizado.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

305

14.13 Eliminar saldos mayores a favor del Beneficiario

Código: NCA-SIS-013

Nombre: Eliminar saldos mayores a favor del Beneficiario

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-16 Fecha de aprobación:

Objetivo Actualizar el saldo del crédito a cero , actualizar el estado del crédito a finalizado y generar transacción para contabilizar por el valor del saldo mayor eliminado.

Descripción El sistema salda los créditos que posean un saldo mayor a favor del beneficiario. Se considera saldo mayor a favor del beneficiario a un valor mayor al valor definido en la parametrización para considerar los saldos menores. La definición de este valor en parametrización estará definido por salarios diarios mínimos vigentes.

Actores Principales Funcionario de Vicepresidencia de Operaciones y Tecnología

Ejecuta este caso de uso.

Actores secundarios

Precondiciones:

Poscondiciones Actualizar a cero el saldo de capital.

Actualización del estado del crédito a finalizado.

Registro de la transacción de saldar crédito por saldo mayor a favor del beneficiario

Creación de un giro para realizar la devolución de este saldo a favor del beneficiario.

Secuencia normal de acciones:

El sistema selecciona los créditos que posean saldo mayor a favor del beneficiario. Por cada crédito realiza lo siguiente:

1. El sistema pasa a cero los saldos del crédito. 2. El sistema genera transacción de saldar crédito

por concepto de saldo mayor a favor del beneficiario. Este concepto determinará las

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

306

cuentas que debe afectarse en el momento de generar el movimiento contable de la transacción.

3. El sistema actualiza el estado del crédito a finalizado.

4. El sistema registra giro a favor del beneficiario por el valor eliminado del saldo mayor.

5. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo establecido para transacciones de corta duración en lote.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

Seguridad El sistema debe contar con mecanismos de autenticación y autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario. El sistema debe contar con la posibilidad de solicitar autorizaciones en línea a otros funcionarios o leer estas autorizaciones si ya habían sido ingresadas para poder ejecutar la novedad.

Gestionabilidad (Control del proceso) Se registra cambio de estado del crédito al día a finalizado.

Auditoria Debe quedar registrada la información de quien y cuando se ejecutó la novedad. Deben quedar registradas todas las autorizaciones de los funcionarios que aprobaron la ejecución de la novedad. Debe quedar registrada toda la información relacionada con la autorización de la novedad: Número de Soporte de la novedad.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

307

14.14 Eliminar saldos menores

Código: NCA-SIS-014

Nombre: Eliminar Saldos menores

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-16 Fecha de aprobación:

Objetivo Actualizar su saldo cero y generar transacción para contabilizar por la eliminación del saldo menor de capital.

Descripción El sistema salda lo créditos que posean un saldo menor. Se considera saldo menor a un valor menor o igual al valor definido en la parametrización para considerar los saldos menores. La definición de este valor en parametrización estará definido por salarios diarios mínimos vigentes. Estos saldos se dividen en dos grupos y dependiendo de este grupo se registra una transacción que tendrá su respectivo movimiento contable. Los grupos son saldo menor a favor del beneficiario y saldo menor en contra del beneficiario.

Actores Principales Funcionario de Vicepresidencia de Operaciones y Tecnología

Ejecuta el saneamiento de saldos.

Actores secundarios

Precondiciones:

Poscondiciones Actualizar a cero el saldo de capital.

Actualización del estado del crédito a finalizado.

Registro de la transacción de saldar crédito ya sea por: o Saldo menor a favor del Beneficiario. o Ó Saldo menor en contra del beneficiario.

Secuencia normal de acciones:

El sistema selecciona los créditos que posean saldo menor. Por cada crédito realiza lo siguiente:

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

308

1. El sistema pasa a cero los saldos del crédito. 2. El sistema genera transacción de saldar crédito

por concepto de saldo menor a favor del beneficiario o saldo menor en contra del beneficiario.

3. El sistema actualiza el estado del crédito a finalizado.

4. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo establecido para transacciones de corta duración en lote.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

Seguridad El sistema debe contar con mecanismos de autenticación y autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario. El sistema debe contar con la posibilidad de solicitar autorizaciones en línea a otros funcionarios o leer estas autorizaciones si ya habían sido ingresadas para poder ejecutar la novedad.

Gestionabilidad (Control del proceso) Se registra cambio de estado del crédito al día a finalizado.

Auditoria Debe quedar registrada la información de quien y cuando se ejecutó la novedad. Deben quedar registradas todas las autorizaciones de los funcionarios que aprobaron la ejecución de la novedad. Debe quedar registrada toda la información relacionada con la autorización de la novedad: Número de Soporte de la novedad.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

309

14.15 Registrar Retención Salarial

Código: NCA-SIS-015

Nombre: Registrar Retención Salarial.

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-18 Fecha de aprobación:

Objetivo Registrar la retención salarial por orden de un juzgado.

Descripción

Actores Principales Funcionario de Cartera Aplica retención al crédito

Actores secundarios Seguimiento al crédito Gestiona retención y valida orden del juzgado.

Precondiciones: Orden del juzgado para registrar la retención salarial.

Poscondiciones

Crédito marcado con retención salarial.

Registro del movimiento de retención salarial

Secuencia normal de acciones:

1. El usuario de cartera selecciona la opción de retención

salarial. 2. El sistema solicita el código del beneficiario al que desea

realizarle la retención salarial. 3. El usuario ingresa el código del beneficiario. 4. El sistema presenta los datos del beneficiario y los datos de

los créditos que este posee vigentes. 5. El sistema presenta el beneficiario y los codeudores

asociados a este que el sistema le puede aplicar la retención salarial.

6. El usuario selecciona el ente al cual le aplicará la retención salarial.

7. El sistema presenta los datos del ente seleccionado i. Información del beneficiario. ii. Información del Empleador del ente

seleccionado. 8. El sistema solicita los datos de retención específicos:

i. % retención salarial y/o valor a retener. ii. Número orden de Juzgado iii. Razón de la retención iv. Fecha inicial de la retención

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

310

v. Fecha final de la retención. 9. El usuario ingresa los datos solicitados. 10. El usuario ejecuta aplicación de la retención. 11. El sistema marca los créditos asociados al beneficiario con

retención salarial. 12. El sistema registra la información de la retención. 13. Fin de proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado

Seguridad El sistema debe contar con mecanismos de autenticación y autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario. El sistema debe contar con la posibilidad de solicitar autorizaciones en línea a otros funcionarios o leer estas autorizaciones si ya habían sido ingresadas para poder ejecutar la novedad.

Gestionabilidad (Control del proceso) No se registra cambio de estado.

Auditoria Debe quedar registrada la información de quien y cuando se ejecutó la novedad. Deben quedar registradas todas las autorizaciones de los funcionarios que aprobaron la ejecución de la novedad. Debe quedar registrada toda la información relacionada con la autorización de la novedad: Número de Soporte de la novedad.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

311

14.16 Modificar Tasa de Interés

Código: NCA-SIS-016

Nombre: Modificar tasa de interés.

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-08 Fecha de aprobación:

Objetivo Modificar tasas de interés para los créditos que se seleccionen.

Descripción El sistema almacena para cada crédito la nueva tasa de interés que aplicará.

Actores Principales Funcionario de Cartera Registra la nueva tasa de interés.

Actores secundarios Comité de Crédito Aprueba la nueva tasa de interés y a los créditos que aplican.

Precondiciones: Crédito en etapa final de amortización.

Poscondiciones Reliquidación de los componentes de las cuotas y Generación de una nueva tabla de amortización.

Secuencia normal de acciones:

1. El usuario selecciona la opción de modificación de tasa de

interés. 2. El usuario selecciona los créditos que le aplicará la

modificación de la tasa de interés. 3. El sistema solicita la nueva tasa de interés que aplicará y su

observación. 4. El usuario ingresa la nueva tasa de interés y su observación. 5. El usuario confirma la aplicación de la nueva tasa de interés. 6. El sistema registra para cada crédito la nueva tasa de interés

y deja la anterior tasa de interés como no vigente. 7. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

312

El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado

Seguridad El sistema debe contar con mecanismos de autenticación y autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario. El sistema debe contar con la posibilidad de solicitar autorizaciones en línea a otros funcionarios o leer estas autorizaciones si ya habían sido ingresadas para poder ejecutar la novedad.

Gestionabilidad (Control del proceso) No se registra cambio de estado.

Auditoria Debe quedar registrada la información de quien y cuando se ejecutó la novedad. Deben quedar registradas todas las autorizaciones de los funcionarios que aprobaron la ejecución de la novedad. Debe quedar registrada toda la información relacionada con la autorización de la novedad: Número de Soporte de la novedad.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

313

14.17 Recalcular saldos de la operación desde la fecha de la novedad

Código: NCA-SIS-017

Nombre: Recalcular saldos de la operación desde la fecha de la novedad.

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-08 Fecha de aprobación:

Objetivo Recalculo y registro de los movimientos del crédito desde una fecha dada hasta la fecha actual por ingreso de novedades.

Descripción El sistema debe permitir recalcular y registrar todos los movimientos posteriores al ingreso de una novedad de tal forma que se actualice a la fecha. Los movimientos aplicados dentro de estas fechas deben ser reversados y re-aplicados.

Actores Principales Casos de uso de novedades. Ejecutan este caso de uso.

Actores secundarios

Precondiciones: Soporte que sustente la aplicación de la novedad.

Poscondiciones Recalculo del saldo de capital, intereses y seguros del crédito

Regeneración de los movimientos para contabilizar.

Alimentar repositorio de novedades de crédito.

Secuencia normal de acciones:

1. El sistema marca todas las transacciones realizadas desde la fecha de la novedad a la fecha de hoy como reversados. (ver nota 1).

2. El sistema consulta el saldo del crédito a la fecha anterior de la fecha de la novedad consultándolo del histórico de saldos.

3. El sistema aplica la novedad y registra la transacción de la novedad.

4. El sistema registra en el repositorio de novedades la transacción de novedad aplicada.

5. El sistema obtiene los el nuevo saldo del crédito a la fecha aplicando cada transacción que se marco como reversada desde la fecha de la novedad a la fecha de hoy.

6. El sistema actualiza el plan de cuotas por las transacciones aplicadas. (ver nota 2).

7. El sistema compara el nuevo saldo del crédito con el saldo actual y por este valor de diferencia genera una transacción de ajuste por la novedad aplicada para que sea posteriormente contabilizado.

8. El sistema actualiza el saldo actual del crédito por el nuevo

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

314

saldo obtenido de aplicar todas las transacciones desde la fecha de la novedad a la fecha de hoy. ( ver nota 3).

9. El sistema almacena los datos de la novedad (ver caso de uso registrar datos de la novedad: NCA-SIS-018).

10. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad que hace uso de este caso, fuera del tiempo reglamentario establecido el usuario debe estar autorizado

Seguridad El sistema debe contar con mecanismos de autenticación y autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario. El sistema debe contar con la posibilidad de solicitar autorizaciones en línea a otros funcionarios o leer estas autorizaciones si ya habían sido ingresadas para poder ejecutar la novedad.

Gestionabilidad (Control del Proceso) Deben quedar registrado en el sistema todos los eventos que se presentaron en la aplicación de la novedad. Este caso de uso no modifica el estado del crédito pero si prepara los datos para que los casos que hagan uso de el si lo hagan

Auditoria Debe quedar registrado la información de quien y cuando se ejecutó la novedad. Las autorizaciones que requieren para este recalculo se deberán realizar en las novedades que utilicen este caso de uso.

Notas y comentarios 1. Consideraciones para la aplicación de la novedad en los siguientes casos:

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

315

a. Cuando afectan una transacción realizada (p.e reversiones):

i. Se debe marcar la transacción realizada como reversada y generar un nueva transacción para contabilizar este reverso, siempre y cuando la transacción marcada como reversada haya sido contabilizada.

b. Cuando es una novedad con fecha actual: i. Se registra la transacción de la novedad y se

afecta el saldo del crédito por esta novedad. ii. El sistema no debe recalcular saldos.

c. Cuando es realizada en una fecha anterior: i. El sistema si debe recalcular saldos. ii. El sistema si debe aplicar las transacciones

desde la fecha de la novedad para obtener el nuevo saldo a la fecha.

iii. El sistema debe registrar una transacción de ajuste por la diferencia de los saldos actuales de la fecha antes y de la fecha después de aplicar la novedad.

2. El sistema debe considerar en que etapa se encuentra el

crédito dado que de encontrarse en amortización o con un sistema de cuotas definido tendría que efectuar el recalculo del plan de cuotas.

3. No se puede modificar el histórico de saldos. solo se actualiza

a la fecha de hoy.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

316

14.18 Buscar Operación para aplicar novedades.

Código: NCA-SIS-018

Nombre: Buscar Operación para aplicar novedades

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Buscar operación bajo diferentes criterios de consulta.

Descripción El sistema presentara una forma con diferentes opciones para que se puedan consultar los créditos a los que se les aplicará la novedad. Dependiendo de la novedad que utiliize esta búsqueda se presentaran las opciones para la realización de la consulta.

Actores Principales Casos de uso de novedades Ejecuta este caso de uso.

Actores secundarios

Precondiciones:

Poscondiciones Obligaciones que cumplan con las opciones seleccionadas por el usuario.

Secuencia normal de acciones:

1. El sistema presenta funcionalidad con diferentes opciones para obtener el crédito que le desea aplicar la novedad (Ver nota 1)

2. El usuario ingresa los datos de las opciones que va a definir para buscar la operación de crédito.

3. El usuario aplica la opción de búsqueda. 4. El sistema presenta los créditos que cumplen con las

opciones seleccionadas por el usuario. 5. El sistema retorna a la novedad desde la cual fue llamada. 6. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo establecido para transacciones de corta duración en lote. Este tiempo esta sujeto a los filtros que defina el usuario.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

317

Seguridad El sistema debe contar con mecanismos de autenticación y autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario.

Gestionabilidad (Control del proceso) No se registra cambio de estado.

Auditoria Para la consulta no se registra información. Además cada novedad realizará el registro.

Notas y comentarios 1. Opciones de búsqueda:

Numero de identificación

Apellidos

Nombres

Numero de Obligación

Numero de Resolución

Estas opciones son de ingreso opcional, es decir en el evento que no se ingrese nada en la opción, el sistema no lo tendrá en cuenta para realizar la búsqueda.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

318

14.19 Registrar datos de la novedad

Código: NCA-SIS-019

Nombre: Registrar datos de la novedad.

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Registrar datos de la novedad.

Descripción El sistema almacenara la información relacionada con las novedades presentadas en un repositorio definido para registrar esta información.

Actores Principales Casos de uso de novedades. Ejecutan este caso de uso.

Actores secundarios

Precondiciones:

Poscondiciones Obligaciones que cumplan con las opciones seleccionadas por el usuario.

Secuencia normal de acciones:

1. El sistema almacenará en un repositorio los datos de la

novedad (ver nota 1). 2. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad que utiliza este caso de uso fuera del tiempo reglamentario establecido, el usuario debe estar autorizado

Seguridad El sistema debe contar con mecanismos de autenticación y autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

319

Gestionabilidad (Control del proceso) No se registra cambio de estado.

Auditoria No se registra información.

Notas y comentarios 1. Datos que se deben registrar de la novedad :

a. Número de Crédito b. Tipo de novedad:

i. De datos básicos. ii. De afectación de saldos (prorrogas,

ampliaciones, pagos, giros, etc.). c. Valor de la novedad d. Fecha de la novedad e. Fecha del movimiento: fecha del día f. Razón de la novedad: Observación sobre la novedad. g. Número de resolución: Para las novedades que

aplique. h. Usuario que realizó la novedad i. Usuario que autorizó la novedad: Solo se registra

para las novedades que la requieran. j. Fecha de la solicitud de autorización de la novedad. k. Fecha de autorización de la novedad. l. Lugar de realización de la novedad. m. Saldo de Capital antes de la ejecución de la novedad. n. Saldo de interés corriente antes de la ejecución de la

novedad. o. Saldo de interés de mora antes de la ejecución de la

novedad. p. Saldo de Capital después de la ejecución de la

novedad. q. Saldo de interés corriente después de la ejecución

de la novedad. r. Saldo de interés de mora después de la ejecución de

la novedad.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

320

14.20 Anular Novedad

Código: NCA-SIS-020

Nombre: Anular Novedad

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Anular una novedad que se aplico incorrectamente.

Descripción El usuario de cartera debe anular la novedad que se aplico incorrectamente a un crédito. Dentro de las novedades se encuentran :

Aplicación de un giro.

Aplicación de un pago.

Reversión de un giro total

Reversión de un pago total.

Reversión de un giro parcial

Reversión de un pago parcial

Paso de un crédito de época de estudio a etapa final de amortización.

La anulación de la novedad se puede dar en época de estudios, periodo de gracia y en etapa final de amortización. En la duración del crédito se puede presentar varias anulaciones de novedades.

Actores Principales Funcionario de Cartera

Ejecutan la reversión de la novedad.

Actores secundarios

Precondiciones: Soporte de Novedad aplicada incorrectamente.

Poscondiciones Nuevo saldo de capital.

Nuevo saldo de interés.

Marcación anulación de la novedad.

Registro del movimiento de anulación de la novedad.

Secuencia normal de acciones:

1. El usuario selecciona la opción anulación de la novedad 2. El usuario selecciona la operación que desea aplicar la

anulación de la novedad (ver caso de uso buscar operación: NCA-SIS-017).

3. El sistema presenta las novedades asociadas al crédito. 4. El usuario selecciona la novedad a anular. 5. El sistema anula la novedad ejecutando el caso de uso

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

321

recalcular saldos de la operación desde la fecha de la novedad.

6. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

Seguridad El sistema debe contar con mecanismos de autenticación y autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario. El sistema debe contar con la posibilidad de solicitar autorizaciones en línea otros funcionarios o leer estas autorizaciones si ya habían sido ingresadas para poder ejecutar la novedad.

Gestionabilidad (Control del proceso) Puede presentarse cambio de estado dependiendo de los días de mora que pueda generar esta reversión. Este cambio debe evaluarse para establecer su nuevo estado en la clasificación de cartera (Ver caso de uso clasificar cartera:).

Auditoria Debe quedar registrada la información de quien y cuando se ejecutó la novedad. Deben quedar registradas todas las autorizaciones de los funcionarios que aprobaron la ejecución de la novedad. Debe quedar registrada toda la información relacionada con la autorización de la novedad: Número de Soporte de la novedad.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

322

14.21 Consultar Novedad

Código: NCA-SIS-021

Nombre: Consultar Novedad

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Consultar las novedades de un crédito

Descripción El sistema presenta las novedades asociadas a un crédito y su detalle.

Actores Principales Funcionario de Cartera Consultar la información de las novedades asociadas a un crédito del cual posea privilegios de consulta.

Actores secundarios

Precondiciones:

Poscondiciones Novedades asociadas al crédito.

Secuencia normal de acciones:

1. El usuario selecciona la opción consulta de novedades. 2. El usuario selecciona la operación que desea consultarle la

novedad (ver caso de uso buscar operación: NCA-SIS-017). 3. El sistema presenta las novedades asociadas al crédito. 4. El usuario selecciona la novedad a consultar. 5. El sistema presenta los datos de la novedad. 6. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Desempeño ( Rendimiento) La aplicación de la novedad no deberá superar el tiempo establecido para transacciones de corta duración.

Disponibilidad El sistema debe estar disponible de 6am a 6pm siempre y cuando no se interfiera con los procesos de cierres. Si se requiere la ejecución de la novedad fuera del tiempo reglamentario establecido el usuario debe estar autorizado.

Seguridad El sistema debe contar con mecanismos de autenticación y

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

323

autorización para que valide el usuario y habilite la opción de ejecución de la novedad en el horario permitido para el usuario.

Gestionabilidad (Control del proceso) No se presentan cambios de estado.

Auditoria No registra información.

Notas y comentarios

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

324

14.22 Autorizar Ejecución de la novedad

Código: NCA-SIS-022

Nombre: Autorizar Ejecución de la novedad

Elaborado por: William Gerardo C. Aprobado por:

Fecha de elaboración:

2007-05-02 Fecha de aprobación:

Objetivo Permitir que el sistema provea un mecanismo para ejecutar las novedades que requieran de una autorización.

Descripción El sistema provee una funcionalidad que permitirá que en el momento de ejecutar la transacción, el usuario que esta registrando la novedad permita solicitar la autorización y esta pueda ser ejecutada en el sistema.

Actores Principales Casos de uso de novedades Ejecutan este caso de uso.

Actores secundarios

Precondiciones:

Poscondiciones Solicitud de autorización de ejecución.

Aprobación de Ejecución de la novedad.

Secuencia normal de acciones:

En el momento de que el usuario seleccione la opción de aplicar la novedad el sistema realiza lo siguiente: 1. El sistema consulta si la novedad a ejecutar requiere

autorización. 2. El sistema presenta los usuarios que pueden realizar la

autorización de la novedad. 3. El usuario selecciona el funcionario al que desea enviarle la

solicitud. 4. El sistema alerta y estará alertando al funcionario de esta

solicitud, cuando este se encuentre conectado al sistema. También enviará un correo al funcionario informándole de la solicitud de autorización. El sistema debe contar con una opción de consulta de autorizaciones pendientes para el que la solicito y para el usuario que tiene que realizarla.

5. El funcionario responde la solicitud. Esta respuesta puede ser:

a. Autorizada: para que el sistema ejecute la novedad.

b. No autorizada: En esta respuesta el funcionario ingresará la razón de la no autorización. De manera que esta novedad pueda ser ajustada por

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

325

el funcionario que la ingresó para volver a solicitar la autorización de ejecución.

c. Anulada: En esta respuesta se anula la novedad y se ingresa el motivo de esta anulación. De manera que no se podrá modificar para ejecutar la novedad.

6. El sistema detecta que la autorización ha sido realizada y ejecuta la novedad de manera automática. Esta ejecución se realiza siempre y cuando la autorización se haya realizado. En el caso de que la autorización no se haya realizado la novedad quedará en espera de esta autorización. Es decir el sistema seguirá alertando de esta autorización pendiente.

7. Fin del proceso.

Secuencias alternas

Requerimientos no funcionales

Auditoria El sistema registra y actualiza el repositorio de autorizaciones. Los datos que se deben almacenar son:

Nombre del Solicitante

Nombre del Autorizador

Fecha de Solicitud

Fecha de Respuesta de la Autorización

Número de Crédito

Secuencial de la autorización.

Concepto de la transacción de Novedad

Estado: Pendiente, Ejecutada.

Respuesta del Autorizante: i. Autorizada ii. No autorizada iii. Anulada

Observación de la autorización.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

326

15. INTERFACES

A continuación se presenta un diagrama con las entidades que se presenta interfaz:

ACH

SNIES

RNEC

ICFES

OPERACIONES Y TECNOLOGIA ( SEGUIMIENTO AL CREDITO, GESTIÓN DOCUMENTAL, GESTION DE COBRANZA).

SISTEMA FINANCIERO (PRESUPUESTO, TESORERIA, CONTABILIDAD)

SUPERFINANCIERA

UIAF DNP

ICETEX: CREDITO Y CARTERA

INTERFACES DEL ICETEX CON ENTIDADES EXTERNAS E INTERNAS

CENTRALES DE RIESGO

DANE

OFICINA DE

RIESGO

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

327

15.1 Reporte a Centrales de Riesgo

Código : INT-SIS-01

Nombre: Reporte a Centrales de Riesgo

Tipo: De Salida.

Forma Envío /Recepción

Archivo

Frecuencia Envío /Recepción:

Mensual

Procesos que afecta: Ninguno.

Seguridad: Certificados Digitales

Observaciones: 1. Es conveniente analizar que la información que se almacena del deudor solidario en la base

datos de CIFIN quede en el ICETEX. Lo que implica realizar un desarrollo de formularios y preparación de la infraestructura para almacenar esta información en el ICETEX y el envío de la información capturada a CIFIN. La importancia de este almacenamiento es que el ICETEX cuente con la información necesaria para que en un futuro pueda realizar la calificación del riesgo del crédito y no dependa de la central de la información.

2. Es necesario evaluar los servicios ofrecidos por otras centrales de información y decidir que implicaciones se tienen para el desarrollo de la interfaz.

Anexos:

1. Ver documentación detalle del archivo que debe enviar el ICETEX a DATACREDITO en la carpeta \1.CENTRALES DE RIESGO\DataCredito\:

a. Ver el archivo ManualEntregaInformacionMaestroCartera.pdf donde se especifica el archivo de información de cartera que debe enviarse a DataCredito.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

328

15.2 Consulta a Centrales de Riesgo

Código : INT-SIS-02

Nombre: Consulta a Centrales de Riesgo

Tipo: De Entrada.

Forma Envío /Recepción

Archivo Servicio web con la entidad DATACREDITO.

Frecuencia Envío /Recepción:

Mensual o diario (

Procesos que afecta: Proceso de estudio de crédito.

Seguridad: Certificados Digitales Autenticación (Servicio Web).

Anexos:

1. Ver documentación detalle del servicio web de DATACREDITO en la carpeta \1.CENTRALES DE RIESGO\DataCredito\:

b. Ver el archivo DHWS Junio07.doc donde se especifica el web service (WS) de la historia de crédito que es un producto que permite obtener la información suministrada por DataCredito a través del protocolo SOAP.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

329

15.3 Consulta con el DNP

Código : INT-SIS-03

Nombre: Consulta con el DNP.

Tipo: De Entrada.

Forma Envío /Recepción

Archivos en medio magnético (DVD).

Frecuencia Envío /Recepción:

Trimestral

Procesos que afecta: Proceso de estudio de crédito.

Seguridad: Autenticación.

Anexos:

1. Ver variables que se maneja en la interfaz enviada por el DNP. Ver documento Variables.doc de la carpeta /3.DNP.

15.4 Consulta con el SNIES

Código : INT-SIS-04

Nombre: Consulta con el SNIES.

Tipo: De Entrada.

Forma Envío /Recepción

Servicio Web

Frecuencia Envío /Recepción:

Por Demanda.

Procesos que afecta: Proceso de Solicitud de Crédito.

Seguridad: Certificados Digitales

Anexos:

1. Ver documentación detalle de los web services en la carpeta .\4.MINISTERIO DE EDUCACION (SNIES)\Webservice\.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

330

15.5 Consulta con el ICFES

Código : INT-SIS-05

Nombre: Consulta con el ICFES

Tipo: De Entrada.

Forma Envío /Recepción

Servicio Web

Frecuencia Envío /Recepción:

Por Demanda.

Procesos que afecta: Proceso de Solicitud de Crédito.

Seguridad: Autenticación.

Observaciones :

La información requerida por el ICETEX del ICFES hace referencia a la información de los exámenes de ICFES y ECAES.

No se tiene acordado un convenio para la interfaz entre el ICETEX y el ICFES.

En reunión realizada el 22 de junio del 2007 se plantearon varias soluciones: 1. El ICFES da acceso por tiempos limitados al día para acceder a su base de datos y se

extrae la información que requiere el ICETEX. De esta solución surge las siguientes observaciones:

i. Quien construye el servicio de extracción de información. ii. Quien realiza el mantenimiento del servicio si la base de datos es modificada y

afecta el servicio. 2. La construcción de un servicio web para obtener la información requerida. 3. Pasar la información del ICFES al ICETEX con cierta periodicidad, de tal manera que el

sistema consulte primero la información en la base de datos del ICETEX y en caso de no encontrarla hacer uso del servicio web para consultar la Base de datos el ICFES.

Se Identificaron 3 etapas donde la información requerida del ICFES cambia: 1. Información anterior al 2002: No se tiene definido puesto. 2. Información entre el 2002 y 2004: Se tiene un puntaje promedio y el puesto. 3. Información después del 2004: No se tiene un puntaje promedio porque el reporte

genera 9 puntajes y puesto por área.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

331

15.6 Reporte a UIAF(Unidad Administrativa Especial de Información y Análisis Financiero)

Código : INT-SIS-06

Nombre: Reporte a UIAF(Unidad Administrativa Especial de Información y Análisis Financiero )

Tipo: De Salida.

Forma Envío /Recepción

Archivo sin utilizar el software ROS(Reporte de Operaciones sospechosas). Archivo utilizando el software ROS.

Frecuencia Envío /Recepción:

Mensual - Ultimo día de cada mes es la fecha de corte y la fecha de reporte los 10 primeros días del mes

Procesos que afecta: Afecta estado del crédito que determina cuales están en investigación.

Seguridad: Certificado Digital.

Anexos:

1. Para archivos sin utilizar el software ROS: Ver documentación de detalle en la carpeta \6.UIAF:

a. Para el envío del archivo de transacciones en efectivo: Ver los documentos Superfinanciera circular 022 cap 11 anexo doc técnico transacciones en efectivo.doc y Superfinanciera circ 022 cap 11 anexo formato transacciones en efectivo.xls.

b. Para el envío del archivo de clientes exonerados: ver los documentos:

Superfinanciera circular 022 cap 11 anexo instructivo clientes exonerados.doc y

Superfinanciera circ 022 cap 11 anexo formato clientes exonerados.xls. 2. Para archivos usando el software ROS: Ver documentación de detalle en la carpeta

\6.UIAF\ROS. Ver los documentos: a. ROS GM 2.0 Y 3.0 (Reporte de Operaciones Sospechosas).doc. b. Manual de Instalacion.pdf c. SUPERFINANCIERA circular 022 Cáp. 11 anexo instructivo ROS.doc d. SUPERFINANCIERA circular 022 Cáp. 11 anexo instructivo ROS.doc e. Recomendación para la gestión de documentos GEL-XML (Recomendación del

Gobierno para la creación de documentos XML).

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

332

15.7 ACH

Código : INT-SIS-07

Nombre: ACH

Tipo: De Entrada.

Forma Envío /Recepción

Archivos vía Web a cada una de las entidades financieras.

Frecuencia Envío /Recepción:

Por Demanda.

Procesos que afecta: Proceso de Matricula de Cuentas.

Seguridad: Autenticación.

Anexos:

1. Para el proceso de matricula de cuentas ver el documento ACH_Matricula_de_Cuentas.doc que se encuentra en la carpeta /7.ACH. Este documento contiene información referente a la interfaz actual entre el ICETEX y el Banco Popular para el proceso de matricula de cuentas.

15.8 Superintendencia financiera

NO SE ENVIA INFORMACION (VER SIGUIENTE INTERFACE).

Código : INT-SIS-08

Nombre: Superintendencia financiera

Tipo: De Salida.

Forma Envío /Recepción

Archivo (información de Crédito).

Frecuencia Envío /Recepción:

Procesos que afecta:

Seguridad:

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

333

15.9 Superintendencia financiera:

Código : INT-SIS-09

Nombre: Superintendencia financiera

Tipo: De Salida.

Forma Envío /Recepción

Archivo (Información de Cartera).

Frecuencia Envío /Recepción:

Mensual.

Procesos que afecta: Ninguno.

Seguridad: Certificados Digitales.

Anexos:

1. Ver documentación detalle de los archivos a enviar en la carpeta: \ 8-9.SUPER INTENDENCIA FINANCIERA. Específicamente los documentos: a. FormatosCartera.xls: internamente este archivo contiene los links a los archivos

detalle de cada uno de los formatos. i. Los archivos que deben enviarse hacen referencia a la siguiente

información: ii. Informe de Reestructuración de Operaciones Activas de Crédito. iii. Liquidación de Créditos Comerciales y de Consumo. Informe Individual por Deudor - Operaciones Activas de Crédito. Reporte Individual - Venta y/o Compra de Operaciones Activas de Crédito

y/o Cartera Castigada. Informe Consolidado - Venta y/o Compra de Operaciones Activas de Crédito

y/o Cartera Castigada. Informe Consolidado de Operaciones Activas de Crédito. Novedades de Créditos, Cuentas por Cobrar y Bienes Dados Leasing que

se encuentren en incumplimiento.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

334

15.10 DANE

Código : INT-SIS-10

Nombre: DANE

Tipo: De Entrada.

Forma Envío /Recepción

Archivo en medio magnético.

Frecuencia Envío /Recepción:

Por Cambio de información en el DANE.

Procesos que afecta: Proceso de Solicitud de Crédito.

Seguridad: Certificados Digitales.

Anexos:

4. Ver documentación detalle de los archivos que se reciben del DANE y que tienen que ser cargados en el sistema. ( Ver la carpeta \10.DANE\.)

15.11 Registraduría Nacional de Estado Civil.

Código : INT-SIS-11

Nombre: Registraduría Nacional del Estado Civil

Tipo: De Entrada.

Forma Envío /Recepción

Servicios web Archivos

Frecuencia Envío /Recepción:

Por Demanda (Servicios web) Por solicitud (Archivos en medio magnético).

Procesos que afecta: Proceso de Solicitud de Crédito.

Seguridad: Autenticación.

Anexos:

1. Ver documentación de los documentos de identificación que la RNEC administra. (Ver documento Tipos de Documentos.doc de la carpeta /11.RNEC).

2. Ver documentación de la información suministrada en reunión del 6 de junio del 2007 con un funcionario de la RNEC. (Ver documento RNEC_Interfaces Actuales y Futuras.doc /11.RNEC).

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

335

15.12 Sistema Financiero - Presupuesto

Código : INT-SIS-12

Nombre: Área financiera presupuesto

Tipo: De Entrada.

Forma Envío /Recepción

Servicio de Consulta (Valor del Presupuesto)

Frecuencia Envío /Recepción:

Por Demanda (Por cada solicitud de estudio).

Procesos que afecta: Proceso de Solicitud.

Seguridad: Autenticación.

Anexos:

1. Ver en la capeta \12-16.SISTEMA FINANCIERO el documento Interfaces(Servicios) con Sistema Financiero.doc el servicio Consulta de CDPs.

15.13 Sistema Financiero – Actualización Presupuestal

Código : INT-SIS-13

Nombre: Área financiera – Actualización Presupuestal

Tipo: De Salida.

Forma Envío /Recepción

Servicio de Consulta (Valor del Presupuesto)

Frecuencia Envío /Recepción:

Por demanda (Por Aprobación y desembolso).

Procesos que afecta: Proceso de Legalización

Proceso de Giros en firme

Seguridad: Autenticación.

Anexos:

1. Ver en la capeta \12-16.SISTEMA FINANCIERO el documento Interfaces(Servicios) con Sistema Finaciero.doc los servicios

Legalización del crédito que afecta el valor del presupuesto (de legalización).

Generación de la resolución de desembolso.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

336

15.14 Sistema Financiero – Tesorería

Código : INT-SIS-14

Nombre: Área financiera – Tesorería

Tipo: De Entrada.

Forma Envío /Recepción

Servicio

Frecuencia Envío /Recepción:

Cada que se reporten giros o recaudos.

Procesos que afecta: Proceso de aplicación de giros.

Proceso de aplicación de recaudos

Seguridad: Autenticación.

Anexos:

1. Ver en la capeta \12-16.SISTEMA FINANCIERO el documento Interfaces(Servicios) con Sistema Finaciero.doc los servicios

Confirmación del desembolso.

Consulta del recaudo.

Reporte de inconsistencias.

15.15 Sistema Financiero – Contabilidad

Código : INT-SIS-15

Nombre: Área financiera – Contabilidad (crédito)

Tipo: De Salida.

Forma Envío /Recepción

Servicio

Frecuencia Envío /Recepción:

Diaria y Mensual de los procesos de cierre.

Procesos que afecta: Saldos de las Cuentas Contables.

Seguridad: Autenticación.

Anexos:

a. Ver en la capeta \12-16.SISTEMA FINANCIERO el documento Interfaces(Servicios) con Sistema Finaciero.doc ver el servicio:

Paso de la información contable de Crédito y Cartera al sistema financiero.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

337

15.16 Sistema Financiero – Contabilidad

Código : INT-SIS-16

Nombre: Área financiera – Contabilidad (cartera)

Tipo: De Salida.

Forma Envío /Recepción

Servicio

Frecuencia Envío /Recepción:

Diaria y Mensual de los procesos de cierre.

Procesos que afecta: Saldos de las Cuentas Contables.

Seguridad: Autenticación.

Anexos:

1. Ver en la capeta \12-16.SISTEMA FINANCIERO el documento Interfaces(Servicios) con Sistema Finaciero.doc ver el servicio:

Paso de la información contable de Crédito y Cartera al sistema financiero.

15.17 Oficina de Riesgo - Actualización del modelo de Riesgo

Código : INT-SIS-17

Nombre: Oficina de Riesgo - Actualización del modelo de Riesgo

Tipo: De Entrada.

Forma Envío /Recepción

Servicio

Frecuencia Envío /Recepción:

Por Demanda (El ICETEX define su frecuencia).

Procesos que afecta: Modelo de Provisiones

Modelo de Riesgo Interno futuro.

Seguridad: Autenticación.

Anexos 1. Para ver los servicios que se requieren para alimentar los modelos de riegos ver documento

OFICINA_DE_RIESGO_Modelos.doc ubicado en la carpeta /17.OFICINA_DE_RIESGO.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

338

15.18 Operaciones y Tecnología - Seguimiento al crédito – Extractos

Código : INT-SIS-18

Nombre: Operaciones y Tecnología - Seguimiento al crédito – Extractos

Tipo: De Salida.

Forma Envío /Recepción

Base de datos Xml con información de extractos.

Frecuencia Envío /Recepción:

Diario, Mensual.

Procesos que afecta: Ninguno.

Seguridad: Autenticación.

Anexos:

1. Ver en la capeta \ 18-23.OPERACIONES Y TECNOLOGIA el documento Base de Datos XML Extractos.doc la información que debe guardarse en la base de datos.

15.19 Operaciones y Tecnología - Seguimiento al crédito – Créditos a Verificar

Código : INT-SIS-19

Nombre: Operaciones y Tecnología - Seguimiento al crédito – Créditos a Verificar

Tipo: De Salida.

Forma Envío /Recepción

Base de datos Xml con información de créditos y estados.

Frecuencia Envío /Recepción:

Diario, Mensual.

Procesos que afecta: Ninguno.

Seguridad: Autenticación.

Anexos:

1. Ver en la capeta \ 18-23.OPERACIONES Y TECNOLOGIA el documento Base de Datos XML Verificación.doc Créditos la información que debe guardarse en la base de datos.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

339

15.20 Operaciones y Tecnología - Gestión Documental - Envío de datos de la custodia

Código : INT-SIS-20

Nombre: Operaciones y Tecnología - Gestión Documental - Envío de datos de la custodia

Tipo: De Salida.

Forma Envío /Recepción

Base de datos Xml con datos de la garantía y los documentos digitalizados.

Frecuencia Envío /Recepción:

Por Demanda (Por cada legalización de un Crédito).

Procesos que afecta: Ninguno.

Seguridad: Autenticación.

Anexos:

1. Ver en la capeta \ 18-23.OPERACIONES Y TECNOLOGIA el documento Base de Datos XML Garantías.doc la información que debe guardarse en la base de datos.

15.21 Operaciones y Tecnología - Gestión Documental - Consulta de datos de la custodia

Código : INT-SIS-21

Nombre: Operaciones y Tecnología - Gestión Documental - Consulta de datos de la custodia

Tipo: De Entrada.

Forma Envío /Recepción

Servicio

Frecuencia Envío /Recepción:

Por Demanda (Por cada legalización de un Crédito).

Procesos que afecta: Ninguno.

Seguridad: Autenticación.

Servicio suministrado por Gestión Documental para la consulta de la información de la garantía. Entada: Número de Crédito Salida: Si existe retorna la siguiente información:

Número de Crédito

Referencia del Pagaré

Valor del Pagaré

Fecha inicial de vigencia

Fecha final de vigencia

Imagen del Pagaré

Imagen Carta de instrucciones

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

340

15.22 Operaciones y Tecnología - Gestión de la Cobranza - Envío de Información

Código : INT-SIS-22

Nombre: Operaciones y Tecnología - Gestión de la Cobranza - Envío de Información

Tipo: De Salida.

Forma Envío /Recepción

Base de datos xml con información de los créditos que impliquen ir a cobranzas.

Frecuencia Envío /Recepción:

Mensual (en el cierre).

Procesos que afecta: Ninguno.

Seguridad: Autenticación.

Anexos:

1. Ver en la capeta \18-23.OPERACIONES Y TECNOLOGIA el documento Base de Datos XML Cobranzas.doc la información que debe guardarse en la base de datos.

15.23 Operaciones y Tecnología - Gestión de la Cobranza – Actualización de los estados de crédito.

Código : INT-SIS-23

Nombre: Operaciones y Tecnología - Gestión de la Cobranza – Actualización de los estados de crédito.

Tipo: De Entrada.

Forma Envío /Recepción

Archivo con los datos de cobranzas.

Frecuencia Envío /Recepción:

Mensual (en cada corte).

Procesos que afecta: Ninguno.

Seguridad: Autenticación.

Servicio suministrado por Crédito y Cartera para registrar la información de cobranza que tenga incidencia en el crédito. Este servicio consiste en un acceso al sistema para reflejar esta información que consistirá en una pantalla para registrar esta información en el crédito.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

341

Entadas: Archivo con los datos de cobranzas actualizados.

Secuencial del registro

Número de crédito

Evento de la cobranza

Estado anterior al evento

Estado posterior al evento

Observaciones del evento

Salida: Archivo con los siguientes datos:

Secuencial del registro

Número de crédito

Resultado de la Carga (Exitoso o no exitoso)

Razón de la no carga (nulo, si no fue posible su carga).

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

342

16. Gestión de consultas y Reportes

16.1 Introducción

La gestión de consulta y reportes incluyen las diversas salidas de información que debe contener la aplicación de crédito, cartera y fondos en administración, las salidas propuestas se enumeran a continuación:

1. Generador de Reportes. Herramienta que permite la construcción y publicación de los informes requeridos por la aplicación

2. Consultas por Internet. Desarrollo de un portal del acceso a la información pública del

sistema: contenido del ICETEX, consultas de los ciudadanos, consultas específicas sobre los pasos y requisitos de la solicitud de crédito y sobre el estado del crédito, y consultas sobre los clientes.

3. Integración con Office y Exchange. Manejo de notificaciones1, reportes, alarmas usando las

facilidades nativas de Office y Exchange.

16.2 Generador de reportes

16.2.1 Características Generales

Se requiere que exista una herramienta en el sistema de crédito, cartera y fondos en administración que abarque todas las fases del proceso de los informes: acceso a datos, diseño del informe, administración y distribución, e integración de los informes con portales y aplicaciones. Cada una de las características se describe a continuación:

1. Acceso a datos Debe permitir un acceso personalizado a la base de datos y mantener un control sobre la conectividad, respetando los niveles de seguridad propuestos para el sistema de crédito, cartera y fondos en administración

1 Las notificaciones pueden ser internas o externas, por medio de correos electrónicos u otros medios afines con la plataforma propuesta en este documento

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

343

2. Diseño de Informe Debe permitir el diseño de reporte interactivos, es decir que el usuario este en capacidad de crear sus propios reportes con herramientas como el diseñador visual de reportes y las peticiones dinámicas. Los reportes pueden ser o no almacenados en un repositorio propio de datos; si son almacenados dichos reportes pueden llegar a ser publicados o distribuidos.

3. Administración y Distribución Debe permitir además de la creación de los reportes la modificación de los mismos y la eliminación de acuerdo con perfiles de seguridad. Además, se debe contar con una herramienta de publicación o distribución bien sea un portal y/o por correos electrónicos.

4. Integración

Debe permitir la publicación de los reportes en portales de Internet e Intranet, además de de la exportación de los datos a los siguientes formatos: Excel Word PDF XML TEXTO ACCES

16.2.2 Características Específicas reportes gerenciales

Las características deseables de los reportes gerenciales son la de una herramienta de inteligencia de negocios que contenga las siguientes fases de construcción por parte de un usuario final: Acceder a un fuente de datos Crear informes Transformar los informes en tableros de control de negocios Compartirlos con facilidad y de manera segura a través de Microsoft Office y de la Web

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

344

16.3 Listado de consultas y reportes

Se requiere que además del dinamismo que deben tener las consultas y reportes, se establezcan la siguiente lista como reportes iniciales de la futura aplicación:

TIPO DE CASOS DE

USO CÓDIGO DESCRIPCIÓN ENTRADA SALIDA PARTICIPANTES

CRÉDITO

REP_SYS_001 CONSULTA DEL FORMULARIO DE INSCRIPCIÓN

Datos Identificadores del Beneficiario (Identificación,

Nombres, Apellidos),

Datos identificadores

del crédito (Número del

Crédito, Línea y Modalidad del Crédito)

Datos del Formulario

(Datos básicos, Datos

académicos y demás

secciones de la modalidad)

En Internet para el Beneficiario del Crédito, Atención

al usuario y Seguimiento al

crédito

REP_SYS_002 CONSULTA DE LOS DATOS DEL DEUDOR SOLIDARIO

Datos Identificadores del Beneficiario (Identificación,

Nombres, Apellidos),

Datos identificadores

del crédito (Número del

Crédito, Línea y Modalidad del Crédito)

Datos del Formulario

para el deudor

solidario ( datos

básicos, Datos

académicos y demás

secciones de la modalidad)

En Internet para el Beneficiario del Crédito, Atención

al usuario y Seguimiento al

crédito

REP_SYS_003 CONSULTA DE LAS OBLIGACIONES DEL CLIENTE

Datos Identificadores del Beneficiario (Identificación,

Nombres, Apellidos)

Listado de las

obligaciones y estado de las mismas (Cartera)

En Internet para el Beneficiario del Crédito, Atención

al usuario y Seguimiento al

crédito

REP_SYS_004 ESTADO DE UN CRÉDITO EN PROCESO DE ADJUDICACIÓN/RENOVACIÓN

Datos Identificadores del Beneficiario (Identificación,

Nombres, Apellidos),

Datos identificadores

del crédito

Historial de estados y causales

durante los procesos de adjudicación

y/o renovación

En Internet para el Beneficiario del Crédito, Atención

al usuario y Seguimiento al

crédito

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

345

TIPO DE CASOS DE

USO CÓDIGO DESCRIPCIÓN ENTRADA SALIDA PARTICIPANTES

(Número del Crédito, Línea y Modalidad del Crédito)

REP_SYS_005 LISTADO DE CRÉDITOS POR ESTADO (EN TRAMITE)

Rango de Fechas por etapas (Radicación, Evaluación, Legalización, Giros) y estados (P.E. Evaluación tiene : Aprobados, Rechazados, Elegibles)

Listado de créditos que cumplen con las condiciones y la sumatoria de los valores del solicitud y aprobación

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

REP_SYS_006 LISTADO DE DESEMBOLSOS

Rango de Fechas, listado de Líneas y modalidades de crédito, Origen del crédito, universidad y/o programa académico, nivel de formación académica, nivel de sisben, estrato

Listado de créditos que cumplen con las condiciones y la sumatoria de los valores del solicitud, aprobación y desembolso

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

REP_SYS_007 LISTADO DE SOLICITUDES ANULADAS

Rango de Fechas, listado de Líneas y modalidades de crédito, Origen del crédito, universidad y/o programa académico

Listado de créditos que cumplen con las condiciones y la sumatoria de los valores del solicitud

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

REP_SYS_008 CONDICIONES FINALES DE APROBACIÓN DE UN CRÉDITO

Datos Identificadores del Beneficiario (Identificación, Nombres, Apellidos),

Condiciones del Crédito: Línea de crédito, modalidad, tasa, valor

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

346

TIPO DE CASOS DE

USO CÓDIGO DESCRIPCIÓN ENTRADA SALIDA PARTICIPANTES

Datos identificadores del crédito (Número del Crédito, Línea y Modalidad del Crédito), nivel de sisben, ciudad, departamento, estrato

aprobado, valor de la matrícula, numero de periodos a financiar, cuota de cultura de pago y cuota estimada del periodo de amortización)

vicepresidencia de operaciones y tecnología

CARTERA

REP_SYS_009

CONSULTA DEL SALDO DE CRÉDITO A FECHA DE CORTE, O A UNA FECHA PROYECTADA.

Datos Identificadores del Beneficiario (Identificación, Nombres, Apellidos), Datos identificadores del crédito (Número del Crédito, Línea y Modalidad del Crédito)

Datos del Crédito, fecha de Corte, Valor a pagar, saldos de la obligación por componentes diferenciando si es vencido , vigente.

En Internet para el Beneficiario del Crédito, Atención al usuario y Seguimiento al crédito

REP_SYS_010 CONSULTA DEL ESTADO DE CUENTA DEL CRÉDITO

Datos Identificadores del Beneficiario (Identificación, Nombres, Apellidos), Datos identificadores del crédito (Número del Crédito, Línea y Modalidad del Crédito)

Consulta del Formato de Estados de cuenta

En Internet para el Beneficiario del Crédito, Atención al usuario y Seguimiento al crédito

REP_SYS_011 CONSULTA DE MOVIMIENTOS EN RANGO DE FECHA

Datos Identificadores del Beneficiario (Identificación, Nombres, Apellidos), Datos identificadores del crédito (Número del

Datos del Crédito, listado de Movimientos y Saldo Final

En Internet para el Beneficiario del Crédito, Atención al usuario y Seguimiento al crédito

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

347

TIPO DE CASOS DE

USO CÓDIGO DESCRIPCIÓN ENTRADA SALIDA PARTICIPANTES

Crédito, Línea y Modalidad del Crédito)

REP_SYS_012 CONSULTA DEL RECIBO DE PAGO A FECHA DE CORTE

Datos Identificadores del Beneficiario (Identificación, Nombres, Apellidos), Datos identificadores del crédito (Número del Crédito, Línea y Modalidad del Crédito)

Consulta del Formato de Recibos de Pago

En Internet para el Beneficiario del Crédito, Atención al usuario y Seguimiento al crédito

REP_SYS_013 CONSULTA DEL PLAN DE CUOTAS INICIAL Y VIGENTES

Datos Identificadores del Beneficiario (Identificación, Nombres, Apellidos), Datos ,identificadores del crédito (Número del Crédito, Línea y Modalidad del Crédito)

Consulta del Formato de Plan de Pagos a la Fecha del otorgamiento del crédito

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

REP_SYS_014 CONSULTA DEL PLAN DE PAGOS VIGENTE

Datos Identificadores del Beneficiario (Identificación, Nombres, Apellidos), Datos identificadores del crédito (Número del Crédito, Línea y Modalidad del Crédito)

Consulta del Formato de Plan de Pagos Vigente

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

348

TIPO DE CASOS DE

USO CÓDIGO DESCRIPCIÓN ENTRADA SALIDA PARTICIPANTES

REP_SYS_015 CONSULTA DE LA CONDICIONES ACTUALES DE CARTERA

Datos Identificadores del Beneficiario (Identificación, Nombres, Apellidos), Datos identificadores del crédito (Número del Crédito, Línea y Modalidad del Crédito)

ü Datos del Básicos del Solicitante ü Valor de la Aprobación ü Valor Consolidado de los desembolsos ü Valor Consolidado de los Pagos ü Tasa inicial del crédito ü Tasa Vigente del crédito ü Sistema de Amortización Inicial ü Sistema de Amortización Vigente ü Número de Cuotas Pactadas ü Número de Cuotas Pagadas ü Número de Cuotas Faltantes ü Saldo de la Obligación al día

En Internet para el Beneficiario del Crédito, Atención al usuario y Seguimiento al crédito.

REP_SYS_016

LISTADO DE DEUDORES AL DIA, CON MORA SUPERIOR A 30/60/90 Y 12O DÍAS O MAS A LA FECHA DE CORTE

Fecha de Corte ,Listado de Líneas y modalidades de crédito, Origen del crédito, universidad y/o programa académico

Listado de deudores que cumplen la condición

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

REP_SYS_017 LISTADO DE CLIENTES PARA LAS DIFERENTES CALIFICACIONES DE

Fecha de Corte ,Listado de Líneas y

Listado de deudores que cumplen la

Consulta interna para los funcionarios de la

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

349

TIPO DE CASOS DE

USO CÓDIGO DESCRIPCIÓN ENTRADA SALIDA PARTICIPANTES

CARTERA modalidades de crédito, Origen del crédito, universidad y/o programa académico

condición vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

REP_SYS_018 LISTADO DE CLIENTES CON n NÚMERO DE CRÉDITOS VIGENTES

Fecha de Corte, Origen del crédito

Listado de deudores que cumplen la condición

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

REP_SYS_019

LISTADO DE CLIENTES CON UN CRÉDITO VIGENTE Y CUYO PAGO DE LA OBLIGACIÓN SEA SUPERIOR A XX PORCENTAJE

Fecha de Corte, Origen del crédito

Listado de deudores que cumplen la condición

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

REP_SYS_020 LISTADO DE OBLIGACIONES CON REFINANCIACIÓN

Fecha de Corte, Origen del crédito

Listado de deudores que cumplen la condición

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

REP_SYS_021 LISTADO DE OBLIGACIONES EN COBRANZA

Fecha de Corte, Origen del crédito

Listado de deudores que cumplen la condición

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

REP_SYS_022 LISTADO DE OBLIGACIONES CON RECLASIFICACIÓN DE CARTERA

Fecha de Corte, Origen del crédito

Listado de deudores que cumplen la condición

Consulta interna para los funcionarios de la vicepresidencia de crédito y

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

350

TIPO DE CASOS DE

USO CÓDIGO DESCRIPCIÓN ENTRADA SALIDA PARTICIPANTES

cartera y la vicepresidencia de operaciones y tecnología

REP_SYS_023 LISTADO DE CLIENTES CON OBLIGACIONES AL DÍA

Fecha de Corte, Origen del crédito

Listado de deudores que cumplen la condición

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

REP_SYS_024 LISTADO DE CLIENTES SIN ACTUALIZACIÓN DE DATOS EN LOS N ÚLTIMOS MESES

Fecha de Corte, Origen del crédito, EDAD DE CARTERA

Listado de deudores que cumplen la condición

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

REP_SYS_025 LISTADO DE CLIENTES EN ÉPOCA DE ESTUDIOS

Fecha de Corte ,Listado de Líneas y modalidades de crédito, Origen del crédito, universidad y/o programa académico

Listado de deudores que cumplen la condición

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

REP_SYS_026 LISTADO DE CLIENTES EN ÉPOCA FINAL DE AMORTIZACIÓN

Fecha de Corte ,Listado de Líneas y modalidades de crédito, Origen del crédito, universidad y/o programa académico

Listado de deudores que cumplen la condición

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

INDICADORES DE GESTIÓN

REP_SYS_027 DEMANDA POTENCIAL ATENDIDA

Rango de Fechas, Genero, Origen y en General los campos del

Lista de solicitudes radicadas

Oficina de Planeación y Presidencia

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

351

TIPO DE CASOS DE

USO CÓDIGO DESCRIPCIÓN ENTRADA SALIDA PARTICIPANTES

formulario o identificación del crédito

REP_SYS_028 COBERTURA DEL CRÉDITO ICETEX

Rango de Fechas, Genero, Origen y en General los campos del formulario o identificación del crédito

Lista de solicitudes radicadas

Oficina de Planeación y Presidencia

REP_SYS_029 CRÉDITOS GIRADOS ESTUDIANTES DE ESTRATOS 1,2 Y 3

Rango de Fechas, Genero, Origen y en General los campos del formulario o identificación del crédito

Lista de solicitudes radicadas

Oficina de Planeación y Presidencia

REP_SYS_030 VALOR EN CRÉDITOS GIRADOS A ESTUDIANTES DE ESTRATOS 1,2 Y 3 U OTROS

Rango de Fechas, Genero, Origen y en General los campos del formulario o identificación del crédito

Lista de solicitudes radicadas

Oficina de Planeación y Presidencia

REP_SYS_031 NUMERO DE BENEFICIARIOS DE CRÉDITO CON SUBSIDIO

Rango de Fechas, Genero, Origen y en General los campos del formulario o identificación del crédito

Lista de solicitudes radicadas

Oficina de Planeación y Presidencia

REP_SYS_032 TIEMPO PROMEDIO DE DESEMBOLSO

Rango de Fechas, Genero, Origen y en General los campos del formulario o identificación del crédito

Lista de solicitudes radicadas

Oficina de Planeación y Presidencia

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

352

TIPO DE CASOS DE

USO CÓDIGO DESCRIPCIÓN ENTRADA SALIDA PARTICIPANTES

REP_SYS_033

PORCENTAJE DE PARTICIPACIÓN EN LAS COLOCACIONES DE NUEVOS PRODUCTOS

Rango de Fechas, Genero, Origen y en General los campos del formulario o identificación del crédito

Lista de solicitudes radicadas

Oficina de Planeación y Presidencia

REP_SYS_034 NUMERO DE PERSONAS QUE RECIBEN EL DESEMBOLSO

Rango de Fechas, Genero, Origen y en General los campos del formulario o identificación del crédito

Lista de solicitudes radicadas

Oficina de Planeación y Presidencia

REP_SYS_035 NUMERO DE BENEFICIARIOS DE ALIANZAS ESTRATÉGICAS

Rango de Fechas, Genero, Origen y en General los campos del formulario o identificación del crédito

Lista de solicitudes radicadas

Oficina de Planeación y Presidencia

REP_SYS_036 VALOR DE LOS DESEMBOLSOS CON IES Y ALIANZAS ESTRATÉGICAS

Rango de Fechas, Genero, Origen y en General los campos del formulario o identificación del crédito

Lista de solicitudes radicadas

Oficina de Planeación y Presidencia

REP_SYS_037 VALOR DE LA CARTERA DEL ICETEX

Rango de Fechas, Genero, Origen y en General los campos del formulario o identificación del crédito

Lista de solicitudes radicadas

Oficina de Planeación y Presidencia

REP_SYS_038 CALIDAD DE LA CARTERA Rango de Fechas, Genero,

Lista de solicitudes radicadas

Oficina de Planeación y Presidencia

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

353

TIPO DE CASOS DE

USO CÓDIGO DESCRIPCIÓN ENTRADA SALIDA PARTICIPANTES

Origen y en General los campos del formulario o identificación del crédito

REP_SYS_039 INFORME GAP

Rango de Fechas, Genero, Origen y en General los campos del formulario o identificación del crédito

Lista de solicitudes radicadas

Oficina de Planeación y Presidencia

REP_SYS_040 CUMPLIMIENTO RECAUDO DE LA CARTERA

Rango de Fechas, Genero, Origen y en General los campos del formulario o identificación del crédito

Lista de solicitudes radicadas

Oficina de Planeación y Presidencia

REP_SYS_041 VALOR REAL DE LA CARTERA

Rango de Fechas, Genero, Origen y en General los campos del formulario o identificación del crédito

Lista de solicitudes radicadas

Oficina de Planeación y Presidencia

REP_SYS_042 VALOR ESPERADO DE LA CARTERA

Rango de Fechas, Genero, Origen y en General los campos del formulario o identificación del crédito

Lista de solicitudes radicadas

Oficina de Planeación y Presidencia

RES_SYS_043 VALOR DE LOS INTERESES CAUSADOS MENSUALMENTE

Rango de Fechas, Genero, Origen y en General los campos del

Lista de solicitudes radicadas

Oficina de Planeación y Presidencia

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

354

TIPO DE CASOS DE

USO CÓDIGO DESCRIPCIÓN ENTRADA SALIDA PARTICIPANTES

formulario o identificación del crédito

TIPO DE CASOS DE

USO CÓDIGO DESCRIPCIÓN ENTRADA SALIDA PARTICIPANTES

RES_SYS_044 LISTADO DE RECAUDOS Rango de Fechas Modalidad

Número de Recaudo, Valor, fecha

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

RES_SYS_045

LISTADO DE CLIENTES QUE RELIZARON EL PAGO CON EL RECIBO ELECTRÓNICO.

Rango de Fechas Modalidad

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

RES_SYS_046 LISTADO DE PROVISIONES Rango de Fechas Modalidad

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

RES_SYS_047 LISTADO DE DESPLAZAMIENTO DE CARTERA

Rango de Fechas Modalidad

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

355

TIPO DE CASOS DE

USO CÓDIGO DESCRIPCIÓN ENTRADA SALIDA PARTICIPANTES

RES_SYS_048

LISTADO DE PROYECCION DE GIROS PARA LOS CREDITOS EN EPOCA DE ESTUDIOS

Rango de Fechas Modalidad

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

RES_SYS_049

LISTADO DE CREDTIDOS DE PROYECCION DE ESTADOS. ES DECIR LOS CREDITOS QUE ESTAN PROXIMOS A PASAR AL COBRO, A FINALIZAR, A CONDONAR, DE PASO A COBREO PREVENTIVO, AL COBRO JURIDICO.

Rango de Fechas Modalidad

Datos del crédito, Datos Del Beneficiario, Datos de los codeudores.

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

RES_SYS_050 LISTADO DE LOS CREDITOS CON RETENCIÓN SALARIAL.

Rango de Fechas Modalidad

Datos del crédito

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

RES_SYS_051 LISTADO DE GARANTIAS DE LOS CREDITOS.

Modalidad Estado, Fecha, Monto.

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

RES_SYS_052 LISTADO DE NOVEDADES DE CREDITO.

Rango de Fechas Modalidad

Datos del crédito. Datos de la novedad

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

356

TIPO DE CASOS DE

USO CÓDIGO DESCRIPCIÓN ENTRADA SALIDA PARTICIPANTES

RES_SYS_053 LISTADO DE NOVEDADES DE CARTERA.

Rango de Fechas Modalidad

Datos del crédito. Datos de la novedad

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

RES_SYS_054

LISTADO DE LOS MONTOS A RECIBIR POR RECAUDOS A UNA FECHA DADA.

Rango de Fechas Modalidad

Datos del crédito. Valor de Recaudo, Fecha del Recaudo.

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

RES_SYS_055 LISTADO DE LOS CREDITOS CON SALDOS MAYORES

Rango de Fechas Modalidad

Datos del crédito, Valor del saldo.

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

RES_SYS_056 LISTADO DE LOS CREDITOS CON SALDOS MENORES

Rango de Fechas Modalidad

Datos del crédito, Valor del saldo.

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

RES_SYS_057

LISTADO DE LOS CREDITOS FINALIZADOS POR SALDO MINIMO MAYOR A CERO O SALDO MENOR A CERO.

Rango de Fechas Modalidad

Datos del crédito, Valor Saldado, Fecha de la finalización.

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

357

TIPO DE CASOS DE

USO CÓDIGO DESCRIPCIÓN ENTRADA SALIDA PARTICIPANTES

RES_SYS_058 LISTADO DE OBLIGACIONES REESTRUCTURADAS

Rango de Fechas Modalidad

Datos del crédito, Datos de la novedad de Reestructuración, Fecha de la reestructuración.

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

RES_SYS_059

LISTADO DE CUENTAS CONTABLES CONSOLIDADAS A UNA FECHA DADA.

Fecha Modalidad

Datos de consolidación cuenta, Número de cuenta, Valor.

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

RES_SYS_060 LISTADO DE CAUSACIONES DIARIAS.

Rango de Fechas Modalidad

Fecha, Tipo (capital, interés, otros cargos), Nro de crédito Valor.

Consulta interna para los funcionarios de la vicepresidencia de crédito y cartera y la vicepresidencia de operaciones y tecnología

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

358

16.4 Características de las Consultas por Internet

La especificación de las consultas por Internet debe incluir un administrador de contenidos que permita además de la publicación de consultas personalizar los estilos de las páginas que serán llamadas desde el portal principal del ICETEX. El administrador de contenidos debe usar el concepto de “módulos” que permiten adaptarlo a varias necesidades, se sugiere por lo menos la siguiente lista

Noticias Propagandas Seguridad Lista de personas Foros para discusión Calendarios de eventos FAQs Formas de retroalimentación Galería de imágenes Procesador de palabra Links Facilidad de búsqueda Directorio de proveedores Consultas SQL Integración con el motor de Reportes

Se recomienda que administrador se conecte de manea sencilla respetando los principios de seguridad del ICETEX a la base de datos y adicionalmente permita la construcción de nuevos módulos de acuerdo a las nuevas necesidades.

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

359

17. ANEXOS

Modelo evaluación de crédito – Proceso de otorgamiento

Sistemas de amortización

Anexo modelo de referencia ance042_06

Modelo ref comercial cap02anexo3

Matriz formato de solicitud

Archivo DHWS Junio07.doc

Archivo ManualEntregaInformacionMaestroCartera.pdf donde se especifica el archivo de información de cartera que debe enviarse a DataCredito.

Documento Variables.doc de la carpeta /3.DNP.

Documentación detalle de los web services en la carpeta .\4.MINISTERIO DE EDUCACION (SNIES)\Webservice\.

Documento SUPERFINANCIERA circular 022 cap 11 anexo doc técnico transacciones en efectivo.doc

Documento SUPERFINANCIERA circ 022 cap 11 anexo formato transacciones en efectivo.xls.

Documento SUPERFINANCIERA circular 022 cap 11 anexo instructivo clientes exonerados.doc

Documento SUPERFINANCIERA circ 022 cap 11 anexo formato clientes exonerados.xls.

Documento ACH_Matricula_de_Cuentas.doc

Documento FormatosCartera.xls

Tipos de Documentos.doc

RNEC_Interfaces Actuales y Futuras.doc

Documento Interfaces (Servicios) con Sistema Financiero.doc

SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.4>

22-09 DOCUMENTO DE CASOS DE USO DE SISTEMAS

Fecha: <30/Julio/2007>

Confidencial

ICETEX, 2007 Pág.

360

OFICINA_DE_RIESGO_Modelos.doc

Documento Base de Datos XML Extractos.doc la información que debe guardarse en la base de datos.

documento Base de Datos XML Verificación.doc Créditos la información que debe guardarse en la base de datos.

Documento Base de Datos XML Garantías.doc la información que debe guardarse en la base de datos.

Documento Base de Datos XML Cobranzas.doc la información que debe guardarse en la base de datos.

Documento Técnico SB-DS-007. subsistema cartera v 4.0