Upload
vuanh
View
219
Download
0
Embed Size (px)
Citation preview
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
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN 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