pad-46 descripción de requerimientos versión 01 fecha 02...

Descripción de Requerimientos

Código PAD-46 ME-02-2014-SJTI-FO-04

Versión 01

Fecha 02/12/2014

Página 1 de 32

Formato : Físico/Digital La impresión de este documento será una copia controlada.

Clasificación : Confidencial

Ubicación : Sub Jefatura de TI Actualización: OCT - 2014

1. DATOS GENERALES

2. DESCRIPCION DEL REQUERIMIENTO

2.1 Alcance

Implementación de cambios y nuevas funcionalidades sobre el Sistema de Registro Nacional de Sanciones Destituciones y Despidos (RNSDD) en base a los lineamientos de la GDSRH y al marco legal definido por SERVIR.

2.2 Descripción

Implementar el registro y seguimiento de alertas del ciudadano. Implementar el registro y seguimiento de solicitudes del ciudadano para la emisión de

certificados por parte de la GDSRH. Implementar el nuevo módulo de consultas del ciudadano (Transparencia) Actualizar el aplicativo RNSDD, en base al nuevo marco legal de SERVIR y reglas del

negocio definidas por la GDSRH. Contar con las características mínimas, especificadas en los requerimientos técnicos y

funcionales. Garantizar el correcto funcionamiento del Sistema de manera integral. Aumentar la productividad la GDSRH al presentar la información de una forma

transparente, rápida y sencilla, que permita obtener reportes. Tener un alto rendimiento del aplicativo permitiendo alta concurrencia en horas pico. Garantizar la seguridad en las operaciones, para los aplicativos de interacción directa con

el ciudadano.

Proyecto : Implementación de Mejoras del Sistema de Registro Nacional de Sanciones, Destituciones y Despidos - RNSDD

Resumen : Definir los requerimientos funcionales para la implementación de las Mejoras al Sistema de RNSDD

Solicitado A :Ing. Eduardo Roncal Avalos Subjefafatura de Tecnologías de la Información.

Prioridad : Alta

Coordinador :Ing. Luis Delgado Alva Alfredo Ccasa Condori Fecha Solicitud

Solicitado Por :Magali Meza Mundaca Gerente de Desarrollo del Sistema de Recurso Humanos

Fecha Requerida :

Coordinador :Sharai Headdy Borjas Aldo Cataño Ita Fecha Recibida :

E-mail :[email protected]

Fecha Atención :

Teléfono/Anexo :206-3370 / 5515

Situación :



Versión 01

Fecha 02/12/2014

Página 2 de 32




Permitir la integración con otros servicios de SERVIR.

2.3 Antecedentes

El Registro Nacional de Sanciones de Destitución y Despido, en adelante el Registro, es una herramienta electrónica del sistema administrativo de gestión de recursos humanos donde las entidades obligatoriamente inscriben y actualizan las sanciones impuestas a sus servidores civiles, las mismas que se publicitan a través del módulo de consulta ciudadana de SERVIR.

El Registro tiene por finalidad que las entidades garanticen el cumplimiento de las sanciones inscribibles; y no permitan la prestación de servicios en el Estado a personas con suspensión o inhabilitación vigente; contribuyendo a la transparencia en la ·incorporación de los recursos humanos al Estado; así como constituir una garantía para los sancionados sobre la contabilización exacta del período que dura su sanción mandato de ley se deban inscribir, de acuerdo a la Directiva 001-2014-SERVIR/GDSRH Directiva que aprueba los lineamientos para la administración, funcionamiento, procedimiento de inscripción y consulta del Registro Nacional de Sanciones de Destitución y Despido – RNSDD, aprobada mediante Resolución de Presidencia Ejecutiva N°233-2014-SERVIR-PE.

2.4 Lineamientos

Como cuestión general, se tienen etiquetas en diversas opciones y formularios del aplicativo, las cuales deben ser modificadas por el proveedor previa revisión con el área usuaria y SJTI.

2.5 Requisitos Funcionales

CODIGO DETALLE REQUERIMIENTO FUNCIONAL

RF-001

Solicitud de Acceso al Módulo de Sanciones.

El sistema cuenta con la funcionalidad que permite el registro de las solicitudes de acceso para que las Entidades del Estado obtengan una(s) cuenta(s) de usuarios para ingresar al Sistema RNSDD.

Sobre el módulo de Registro de Solicitudes de Acceso se requieren los siguientes cambios e inclusión de nuevas funcionalidades: Modificación los mensajes de alerta en el registro de la solicitud. En la actualidad el módulo de solicitud de acceso está conformado por dos

(2) grupos de datos, el de “Datos del Usuario” e información de “Documento que autoriza”, ambos se registran en dos (2) formularios diferentes. Se debe modificar el sistema para que ambos grupos de datos se muestren en un solo formulario, sin afectar las validaciones existentes de los datos y el desarrollo de los cambios que afectan las funcionalidades según como se indica en este documento.

Agregar el campo RUC como criterio de búsqueda durante el registro de una solicitud de acceso en la selección de la Entidad. El sistema realiza la búsqueda de las Entidades en la base de datos del RNSDD. Se considera mostrar resultados de búsqueda cuando el registro de Entidad está en estado “Activa”.

Para los casos en que la Entidad no existe, Se debe implementar una nueva opción de: “Solicitud de Creación de Entidad”



Versión 01

Fecha 02/12/2014

Página 3 de 32




El sistema deberá permitir la generación de una solicitud de creación de nueva Entidad considerando el ingreso de RUC y Descripción. Todos los registros de nuevas Entidades generados a través de este formulario se consideran como solicitudes de creación de Entidad en el sistema y siguen un flujo de aprobación que lo efectúa el usuario con perfil Administrador.

Los datos ingresados para el registro de una nueva Entidad serán validados por el sistema según:

a. Verificará que no exista la Entidad previamente registrada en la base de datos del RNSDD de acuerdo al RUC y/o Nombre de la Entidad en cualquiera de sus Estados (Activa, Desactivada o Pendiente de Solicitud). Si el usuario está intentando solicitar la creación de una Entidad que se encuentra en estado “Pendiente de aprobación”, alertará al usuario. El sistema no debe permitir por ningún motivo enviar una solicitud de creación de una Entidad que ya se encuentra en estado “Pendiente de Solicitud”.

b. El sistema realizará la búsqueda de la Entidad mediante el RUC utilizando el servicio web de SUNAT. Considerar lo siguiente:

i. Solo se obtendrán datos cuando se trate de una Entidad del Estado (Entidad Pública), en caso la consulta se refiera a una Entidad no pública el sistema mostrará una alerta al usuario indicando la restricción. El sistema no debe permitir por ningún motivo registrar a una Entidad Privada.

ii. Los datos que se obtendrán del servicio web de SUNAT son: Nombre/ Razón social de la Entidad, Dirección y otros que se consideren necesarios y que formarán parte del registro de la Entidad como se indicará posteriormente en este documento.

Durante el registro de la solicitud de acceso, al seleccionar el perfil se deberá mostrar una breve descripción pre-configurada en forma de nota informativa al pie del campo del perfil tal como se indica en el siguiente cuadro:

Perfil DescripciónUsuario de inscripción

Registra y consulta sanciones

Usuario de lectura Solamente consulta sanciones

CGR / TSRA Usuario Contraloría General de la Republica

La nota informativa será configurada desde el módulo de administración de

perfiles, para ello se debe crear un campo adicional para ingresar la breve descripción.

Agregar al formulario de solicitud de acceso los siguientes campos: a. “Área”, campo obligatorio del formulario que debe ser una lista

desplegable cuyas opciones de selección serán administradas a través del módulo de mantenimiento de tablas auxiliares.

b. “Nivel de ofimática”, campo obligatorio del formulario que se presentará como lista desplegable cuyas opciones de selección serán administradas a través del módulo de mantenimiento de tablas auxiliares.



Versión 01

Fecha 02/12/2014

Página 4 de 32




Durante el registro de solicitud de acceso, se obtendrán datos adicionales de la persona como sexo, fecha de nacimiento, estado civil, dirección, grado de instrucción y restricción. La obtención de estos datos se realizará a través de la consulta al servicio de web de RENIEC y se almacenarán como datos de la persona en la base de datos del RNSDD (no es necesario que se muestren en el formulario). La tabla de grados de instrucción será una tabla auxiliar y el sistema deberá permitir el mantenimiento de esta tabla a través del módulo de mantenimiento de tablas auxiliares.

El sistema debe validar la duplicidad en registro de datos, como por ejemplo no es permitido el registro de una solicitud de un usuario que ya se encuentra registrado en la base de datos del RNSDD y cuyo estado es: activo, bloqueado, observado o solicitado. El sistema mostrará la alerta correspondiente indicando al usuario sobre la restricción. Esta validación para mostrar la alerta se hará luego del ingreso del número de documento de identidad en el formulario. El texto que se determine para la alerta será indicado por el área usuaria durante el servicio.

El sistema debe registrar y mostrar mensajes de alertas según sea el caso y debe ser activada al realizar la validación con RENIEC, ejemplo fallecimiento, usurpación de identidad y otros que cancelen la identidad de la persona. El texto que se determine para las alertas será aprobado por el área usuaria durante el servicio.

El Sistema actualmente valida si el registro de un usuario solicitante afecta el registro de un usuario existente, solo para los casos en los que el usuario solicite un usuario con perfil de inscripción en una Entidad que ya tiene registrado un usuario en estado activo con ese perfil. De darse el caso de una solicitud de acceso para reemplazo el sistema deberá mostrar una alerta al usuario solicitante que incluirá la información de la Entidad, el nombre del Usuario que ya se encuentra registrado con ese perfil. Esta validación no restringe el envío de la solicitud de acceso.

El campo para el registro del “Número de Resolución” deberá aceptar caracteres especiales.

RF- 002

Pantalla de Inicio de Sesión.

Modificación de la máscara y etiquetas de los campos en la pantalla de Inicio de sesión, que sea configurable y pueda darse mantenimiento al contenido desde la interfaz gráfica, la pantalla debe ser aprobada por el área Usuaria.

El sistema debe tener una opción para dar mantenimiento a las preguntas frecuentes mostradas en el sistema.

Modificación el texto de los mensajes de alerta en el módulo de inicio de sesión, el texto serán en coordinación con el Área Usuaria.

Modificar para que el sistema pueda bloquear la cuenta del usuario al exceder la cantidad máxima de intentos fallidos, y automáticamente debe enviarle un correo electrónico al usuario utilizando la plantilla de correo configurada en el sistema para estos casos

El Sistema debe mostrar mediante una alerta visible el procedimiento para activar su cuenta de usuario.

Modificar la modalidad de seguridad del inicio de sesión para el acceso del

usuario por un captcha basado en imagen que permita renovar la imagen



Versión 01

Fecha 02/12/2014

Página 5 de 32




y su lectura en altavoz , lo que facilitará la accesibilidad a para personas con discapacidad.

Modificar el sistema para que en cada intento fallido de inicio de sesión debe emitir mensajes de alerta del número de intentos restante, y debe refrescar el código captcha del formulario.

RF- 003

Alertas de Inicio de Sesión. (Nueva funcionalidad)

Se requiere la implementación de las siguientes alertas: Para todos los usuarios, se solicitará mediante una alerta la actualización de

los datos de su registro de usuario mientras se encuentre incompleto. Se considera incompleto cuando el registro no tiene registrada el área, nivel de ofimática y grado de instrucción que son campos nuevos en el registro del usuario. Al usuario se le mostrará los siguientes datos y se indica las acciones que podrá realizar:

Campo Acciones

Tipo de Documento de Identidad No modificable.

Número de Documento de Identidad

No modificable.

Nombres No modificable.

Apellido Paterno No modificable.

Apellido Materno No modificable.

Teléfono Modificable.

Email No modificable.

Denominación de Cargo No modificable.

Área Modificable.

Nivel de Ofimática Modificable.

Número de Resolución No modificable.

Resolución No modificable.

El sistema automáticamente debe consultar al web service de RENIEC, solo

cuando el usuario contenga número de documento de identidad como DNI, para obtener datos adicionales del usuario como:

o Grado de Instrucción o Dirección o Fecha de Nacimiento o Restricción

Los datos serán actualizados en el registro del usuario.

El sistema debe mostrar el link para acceder al módulo de actualización de datos de Entidad Para los usuarios con Perfil de inscripción y con derechos sobre el módulo de actualización de datos de Entidad, considerando las siguientes casuísticas. El sistema debe validar la vigencia del registro de Entidad, que consiste en calcular la última fecha de actualización de los datos



Versión 01

Fecha 02/12/2014

Página 6 de 32




versus el parámetro configurado en el sistema que define la vigencia máxima para solicitarle al usuario la actualización.

Consideraciones mínimas sobre la alerta: a) El texto de la alerta será definido con el área usuaria. b) La alerta se mostrará cuatro (4) días antes del cumplimiento

del plazo y mientras el usuario no actualice los datos. c) La ubicación de la alerta será a la mitad de la pantalla, con

tipo, tamaño de letra y colores que indiquen advertencia para el usuario.

d) Tendrá una duración máxima de cuatro (4) segundos o hasta que el usuario cierre la ventana.

e) Contiene un enlace para redireccionar al formulario de actualización de datos de Entidad.

f) Para los casos en los que se trate de una Entidad nueva recientemente aprobada por el administrador y cuyo registro esté incompleto, la ventana de alerta deberá mostrarse cada vez que ingrese al sistema, la ventana debe permitir cerrarse.

Para los usuarios de inscripción y administradores, el sistema mostrará en una ventana emergente el listado paginado de los registros de apelaciones. Consideraciones mínimas sobre la alerta:

a) El texto de la alerta será definido con el área usuaria. b) La ventana emergente deberá aparecer cada vez que el

usuario ingrese al sistema. c) Se mostrará por cuatro (4) segundos o hasta que el usuario

cierre la ventana. d) Contiene un enlace para redireccionar a la sección del sistema

que contiene los registros de apelaciones del Tribunal del Servicio Civil.

RF- 004

Entidades - Datos de la Entidad. (Modificación)

El sistema cuenta con un módulo a través del cual se le permite al usuario con perfil de Administrador de Entidad/Usuario de Inscripción actualizar los datos de su Entidad. Sobre este módulo se requieren los siguientes cambios funcionales:

o Modificación de etiquetas de los campos del formulario. o Modificación del texto de los mensajes de alertas de validación del

formulario. o Para los usuarios con el perfil de Administrador de Entidad/ usuario de

inscripción cuyo registro de Entidad se encuentre incompleto, es decir, solo contenga RUC y descripción, y que haya sido aprobado previamente por el Administrador Servir, el sistema deberá permitir actualizar todos los campos del formulario de actualización de datos de Entidad por única vez a excepción del RUC y descripción. El sistema no deberá permitir



Versión 01

Fecha 02/12/2014

Página 7 de 32




que el usuario ejecute otras acciones en el sistema sin haber actualizado su registro de Entidad.

o Para los usuarios cuyo registro de Entidad se encuentre incompleto, el sistema deberá permitir la actualización de los datos de acuerdo al cuadro mostrado en el [anexo 02], mediante un poopup, al ingresar al sistema, esta opción debe ser configurada para determinados perfiles., considerar que del anexo 02 los campos con (*) son obligatorios. Durante la actualización de los datos de una Entidad el sistema deberá validar los formatos de correo considerando que estos pueden contener “.” antes del “@”.

RF- 005

Entidades – Administrar Entidades (Modificación)

Módulo a través del cual los usuarios con perfil de administrador servir gestionan los registros de entidades, su modificación y desactivación. Se requiere la implementación de los siguientes cambios y nuevas funcionalidades sobre el módulo:

Modificación de etiquetas de los campos del formulario. Modificación del texto de los mensajes de alertas de validación del

formulario. El sistema deberá permitir manejar los registros de Entidades de acuerdo

a cuatro (4) tipos de Estados: Activa, Desactivada, Pendiente de aprobación, Rechazada.

El sistema no permitirá desactivar Entidades que contengan usuarios en estado “Activo”.

El estado “Pendiente de aprobación” le corresponderá a los registros de Entidades que han sido creados a través del módulo de Solicitud de Acceso.

Desde la administración de Entidades el sistema permitirá que el Administrador apruebe o rechace una solicitud de registro de Entidad que ha sido registrada desde el módulo de solicitud de acceso. La aprobación de una solicitud de registro de Entidad le cambia el estado a “activa”.

El sistema debe permitir realizar búsqueda de entidades mediante el número de RUC, Tipo de Entidad, Estado (Activa, Desactivada, Pendiente de Aprobación, Rechazada).

Los campos que formarán parte del registro de la Entidad son:

A. Datos Generales de la Entidad

etalle

Entidad:(*) Campo existente Abreviatura: Campo existente RUC:(*) Campo existente Descriptores(*): Campo existente Nivel de Gobierno (*) Campo existente Organización del Estado (*) Campo existente Sector:(*) Campo existente Tipo de Organismo (*) Campo existente Ley Creación: Campo existente Tipo de Entidad (*) Campo no existente. Crear. Estado (*) Campo existente.



Versión 01

Fecha 02/12/2014

Página 8 de 32




B. Ubicación Detalle Tipo de Vía (*) Campo existente Descripción de Vía (*) Campo existente Tipo de Zona Campo existente Descripción de Zona Campo existente Departamento: (*) Campo existente Provincia: (*) Campo existente Distrito: (*) Campo existente C. Otros Datos: Teléfono Institucional(*) Deberá modificarse la

etiqueta a “Teléfono”. Campo existente.

Correo Institucional: Campo existente. URL (Dirección Web): Campo existente D. Autoridades Titular Entidad(*) Campo existente Cargo / Puesto (*) Campo existente Correo del Titular Entidad Campo existente Titular de RRHH (*) Deberá modificarse la

etiqueta a “Titular de RRHH / o quien haga sus veces”. Campo existente

Cargo / Puesto (*) Campo existente Correo del Titular de RRHH Campo existente Teléfono del Titular de RRHH

Campo no existente. Crear. Modificable.

Titular de OGA Campo existente Cargo / Puesto OGA Campo existente Correo del Titular de OGA Campo existente Titular de Transparencia Campo existente Cargo / Puesto Campo existente Email del Titular de Transparencia

Campo existente

D. Misión de la Entidad (Máximo 500 Caracteres)

Campo existente

Los campos con (*) son obligatorios.

Durante el registro o actualización de los datos de una Entidad el sistema

deberá validar los formatos de correo considerando que estos pueden contener “.” antes del “@”.

Deberá garantizarse que el sistema almacene la fecha de creación del registro así como la fecha de la última actualización del registro de la Entidad, los datos serán mostrados en el formulario cuando se consulte el registro de una Entidad.

La creación de Entidades, modificación, actualización de datos, cambios de estado deberán convertirse en eventos que el sistema mostrará en el dashboard.

RF- 006

Últimos Eventos (Pantalla de Inicio/Dashboard).

El sistema posee un dashboard (página) donde se muestran los eventos asociados a los registros de sanciones, entidades, solicitudes de acceso y



Versión 01

Fecha 02/12/2014

Página 9 de 32




los accesos de usuarios. Los cambios solicitados sobre el funcionamiento del dashboard son:

o Modificación de etiquetas de los campos en la página del dashboard.o El acceso a este dashboard se da actualmente para usuarios con

perfil (a) y (c), se requiere en adelante que los siguientes perfiles tengan acceso al dashboard:

Administrador Servir Administrador de Entidad/ Usuario de Inscripción. Administrador de Sistemas

o La información que se mostrará dependerá del perfil del usuario en el sistema, a continuación se muestra el cuadro que define, como mínimo, cuáles serán los eventos por cada perfil: [Ver Anexo 01]

Los eventos por categoría se mostrarán en forma de listas paginadas de cinco (5) registros, ordenados desde el último ingreso. La estructura de los listados se coordinará con el área usuaria.

Cada encabezado de las listas deberá permitir el ordenamiento de los datos mostrados tal y cual sucede actualmente con otras listas que se muestran en el aplicativo.

Los eventos que se muestran para el Usuario de Inscripción/Administrador de Entidad siempre estarán visibles, no será posible borrar el evento del dashboard. El sistema siempre mostrará los últimos diez (10) eventos ordenados por fecha, hora y se actualizará la lista automáticamente.

RF- 007

Seguridad - Administración de Perfiles y Accesos (Modificación)

El sistema permite actualmente la administración de cinco (5) perfiles de usuarios: Administrador de Sistemas, Administrador Servir, Administrador de Entidad, Usuario de Consulta, Usuario CGR/TSRA. Cada perfil de usuario tiene asignado un conjunto de accesos o privilegios a las funcionalidades y módulos del sistema. Estos privilegios son asignados desde el módulo de administración de perfiles y es el usuario o los usuarios con perfil de Administrador (Sistemas o Servir) quienes pueden: a) Crear nuevos perfiles de usuarios. b) Asignar derechos sobre los diferentes módulos, derechos que pueden ser

como se lista a continuación: o Registros de sanciones que puede visualizar a través del módulo de

consulta según el estado de la misma. o Acciones sobre los registros de sanciones (Editar, Anular, Eliminar,

Imprimir, Suspender). o Opciones del Menú a las que puede tener acceso (módulos del

sistema) y sus derechos sobre cada uno (todos o control total, lectura, modificación, inserción, eliminación). Sobre esta configuración se construye el menú en el sistema.

Se requiere la implementación de los siguientes cambios funcionales sobre el módulo: En adelante los perfiles iniciales que deberán ser configurados en el

sistema debe ser como sigue: Administrador Servir



Versión 01

Fecha 02/12/2014

Página 10 de 32




Administrador de Sistemas Administrar de Entidad o Usuario de Inscripción CGR/ TSRA Usuario de Consulta Sin perjuicio de que el sistema permita crear y configurar otros perfiles.

Se crearán campos adicionales en el registro del perfil para permitir: 1. Ingresar una definición del perfil o breve descripción. Esta

definición será usada como nota informativa y será mostrada en el módulo de registro de solicitud de acceso

2. Habilitar o deshabilitar el perfil para ser incluido en la lista de los perfiles que se pueden solicitar desde el módulo de registro de solicitud de acceso.

3. Asignar derechos al perfil para crear registros de sanciones para una Entidad. (El usuario registrará sanciones solo para la Entidad a la que se encuentra relacionado).

4. Configurar los derechos del perfil para acceder a acciones de impresión simple o impresión certificada de registro de sanciones.

5. Configurar los derechos del perfil para acceder al historial de eventos del registro de cada sanción.

6. Configurar los accesos a los usuarios especiales, para ello tomar como documento base el documento [anexo 03]

El sistema debe permitir configurar los derechos de acceso de un perfil a los módulos del sistema que incluirá a los nuevos módulos solicitados en este documento.

Se modificarán los nombres de los menús del Sistema en consenso con el área usuaria.

Se realizarán otras configuraciones de restricción por cada perfil administrado por el sistema según lo indique el área usuaria.

RF- 008

Seguridad - Administración de Usuarios y derechos

El sistema cuenta con un módulo que permite la administración de los registros de usuarios del Sistema. Se requieren los siguientes cambios e inclusión de funcionalidades sobre el módulo:


formulario. El sistema debe almacenar la fecha de la última actualización del registro de

un usuario. El sistema debe permitir buscar registros de usuarios por:

- Fecha y rango de fechas de aprobación de solicitudes de acceso. - Área a la que pertenece. - Nivel de Ofimática. - Grado de Instrucción. - Por tipo de Entidad. - Y otros filtros que el área usuaria considere necesarios y que forman

parte del registro del usuario. El sistema debe permitir asignar derechos especiales por usuario para la

consulta y registro de sanciones de acuerdo al régimen laboral, categoría y



Versión 01

Fecha 02/12/2014

Página 11 de 32




tipo de sanción. Para establecer los derechos especiales el sistema tomará como base los derechos asignados al perfil del usuario configurado en módulo de administración de perfiles, es decir, los derechos especiales se suman a los derechos ya asignados al perfil pero por ningún motivo podría restarse derechos.

El sistema deberá permitir la asignación de los derechos especiales por usuario y por grupo de usuarios. El sistema mostrará un enlace para acceder al formulario que permite establecer los derechos, el flujo para la asignación para el caso de un usuario será como sigue: 1. Asignación de derechos sobre las consultas de registros de sanciones

por estado de la sanción, así como los derechos sobre el registro de nuevas sanciones. Como ejemplo se muestra la maqueta de formulario (ver anexo N° 3) para la asignación de derechos especiales, sin perjuicio de que el proveedor proponga un prototipo que se ajuste a los requerimientos especificados en este documento y que deberá ser consensuado, revisado y aprobado por el área usuaria.

2. El sistema deberá permitir asignar un periodo de vigencia a los derechos especiales.

El sistema deberá permitir la asignación de derechos especiales para un grupo de usuarios. El administrador desde la administración de usuarios filtrará los registros de usuarios, considerar que uno de los filtros obligados es el perfil, dado que la asignación de derechos especiales toma como base los derechos asignados al perfil y solo aplicará para usuarios en estado activo. Se considerará como un proceso masivo de asignación de derechos especiales.

El sistema deberá almacenar como registros de auditoría todos los movimientos/acciones que se realizan con los registros de usuarios, incluye fecha y hora en que ocurre y datos del usuario que lo efectuó.

Los registros de auditoría de usuarios serán disponibles para consulta desde el módulo de administración de usuarios.

RF- 009

Aprobación de Solicitudes de Acceso (Modificación)

El sistema cuenta con la funcionalidad de aprobación de Solicitudes de Acceso para los usuarios con perfil Administrador Servir sobre la cual se requieren los siguientes cambios funcionales:


formulario. El sistema deberá grabar la fecha de aprobación de la solicitud de acceso. El sistema deberá validar si el usuario solicitante mantiene inhabilitaciones

vigentes registradas, de ser el caso, considerar lo siguiente: 1. En la ventana de aprobaciones se mostrará el listado de las

sanciones relacionadas al usuario en cuestión (Categoría, Tipo de Sanción, Estado y acciones para permitir ver (en una nueva ventana) e imprimir (impresión simple) el detalle de cada una de las sanciones.

2. El sistema no permitirá la aprobación de la solicitud de acceso de un usuario que registra sanciones en el sistema por lo que deshabilitará el botón de aprobación si ocurre el caso.



Versión 01

Fecha 02/12/2014

Página 12 de 32




El sistema deberá permitir que el administrador modifique cualquier dato del registro de solicitud de acceso.

RF- 010

Módulo de Registro de Sanciones.

Actualmente se tiene la opción: RNSDD - Registros Cambios funcionales sobre el módulo de registro de Sanciones:

Modificación en las etiquetas del formulario. Modificación en el texto de los mensajes de alerta durante el registro de los

datos en el formulario. Modificar el formulario para que al registrar los datos de identidad del

Sancionado, en adición a los datos que actualmente se obtienen de la consulta a través del servicio web de RENIEC, se requiere que el sistema obtenga además los siguientes:

o Género (Sexo) o Fecha de Nacimiento o Grado de Instrucción o Estado Civil. o Restricción. o Foto

Los datos extraídos no serán mostrados en el formulario de registro de Sanción pero serán almacenados como datos de identidad del sancionado.

El sistema debe permitir la carga de las listas de Régimen Laboral, Categoría de Sanción, Tipo de Sanción y causas todas relacionadas y de acuerdo a los derechos configurados previamente.

Los datos que corresponden a la “Autoridad que sanciona” y “Autoridad que notifica” ya no son necesarios para el registro de una sanción. Se requiere ocultar los campos en el formulario de registro de sanción y modificar las validaciones que realiza el formulario al grabar la información para que los datos ocultados no repercutan en la funcionalidad.

El sistema según el tipo de sanción y la configuración previa que contenga, en el formulario se visualizará el registro de un periodo de sanción.

Es obligatorio la carga de documentos durante el registro de una sanción. Se habilitará el botón para adjuntar documentos cuando al menos se haya ingresado los campos obligatorios del formulario de registro de sanción.

El sistema deberá validar paso a paso el ingreso de datos al formulario y activará las alertas correspondientes (campos obligatorios, validación del cálculo de periodo de sanción, número de caracteres permitidos en los campos y otros que el área usuaria indique) a medida que el usuario ingrese los datos en los campos obligatorios. Estas validaciones se ejecutarán sin perjuicio de la validación total de los datos que se realiza cuando se graban los datos.

Se creará un campo adicional en el grupo de datos de la sanción que permitirá que el usuario indique si es una sanción asociada a un “acto de corrupción”.

Para los casos en los que el registro de una sanción se asocie a un tipo de sanción que solicita el registro del periodo de sanción, al calcular el periodo de la sanción, el sistema deberá validar la fecha de inicio y fin de acuerdo a:



Versión 01

Fecha 02/12/2014

Página 13 de 32




La configuración del tipo de sanción. La fecha de notificación ingresada por el usuario en el formulario. Los parámetros del sistema “Fecha de corte” y “Periodo máximo de

apelación”.

Considerar: Para las Sanciones que se registren con una fecha de notificación anterior a

la “Fecha de corte”, el sistema deberá calcular el periodo de la sanción (cuando aplique según el tipo y su configuración) sin tomar en cuenta el “Periodo máximo de apelación”.

Para las Sanciones que se registren con una fecha de notificación posterior a la “Fecha de corte”, el sistema deberá calcular el periodo de la sanción (cuando aplique según el tipo y su configuración) tomando en cuenta el “Periodo máximo de apelación”.

RF- 011

Módulo de Suspensión de Registro de Sanciones.

El sistema cuenta con un módulo de registro de los datos de Inicio y Fin de Suspensión de Sanciones (opción Consulta - Suspensión), el mismo está asociado a un registro de Sanciones. El módulo presenta dos (2) grupos de datos, el de Datos de Inicio de Suspensión y el de Datos de Fin de Suspensión.

Sobre el módulo implementar los siguientes cambios:

Cambios de etiquetas en el formulario. Cambios de texto de las alertas de validación en el formulario. Si el registro de la sanción se encuentra en estado VIGENTE es posible que

se registre una suspensión de sanción que inicia con los datos de inicio de suspensión.

El ingreso al módulo de registro de suspensión debe darse de dos maneras: o Desde el mismo formulario de registro de sanción, cuando el usuario

se encuentra editando, el sistema mostrará un botón habilitado para ingresar al módulo.

o Desde la acción “Suspender Sanción” que se visualiza como acción en los registros consultados a través del módulo de consultas.

El formulario para registrar los datos de suspensión mostrará únicamente los campos que correspondan al inicio de la suspensión cuando el estado de la sanción es VIGENTE y si se tratara de una sanción en estado SUSPENDIDA el sistema mostrará en el formulario los campos que correspondan al fin de la suspensión inhabilitando la edición de los campos que forman parte del grupo de datos de inicio de suspensión.

El formulario de registro de suspensión, tanto en el grupo de datos de inicio y fin de suspensión deberá permitir la carga de un documento en formato (PDF, JPG) cuyo peso no exceda en 8Mb y debe ser considera como obligatorio.

El sistema debe realizar validaciones en el formulario a fin de verificar los datos antes de ser grabados, las cuales estarán relacionadas a los campos en los que se registran fechas en el grupo de datos de inicio y fin de suspensión, además de su comparación con otras fechas del registro de la sanción y fecha del sistema. a) En el grupo de datos de inicio de la suspensión:



Versión 01

Fecha 02/12/2014

Página 14 de 32




La fecha del documento que inicia la suspensión debe ser anterior a la fecha de la notificación de la sanción registrada en el formulario de registro de sanción.

La fecha de notificación de la suspensión no debe ser anterior a la fecha del documento de suspensión.

b) En el grupo de datos de fin de la suspensión: La fecha del documento que finaliza la suspensión debe ser posterior

o igual a la fecha del documento que inicia la suspensión. La fecha de notificación de la suspensión no debe ser anterior a la

fecha del documento de suspensión. El sistema debe realizar validaciones para el recalculo del periodo de sanción

cuando ocurre una finalización de una suspensión, es decir, vuelve a activarse la sanción cambiando a estado VIGENTE. Las restricciones para el proceso serán consensuadas con el área usuaria durante el servicio.

El sistema debe permitir que una sanción pueda tener más de un periodo de suspensión pero no al mismo tiempo. El historial de suspensiones del registro de sanción será visible desde el formulario de suspensión a modo de grilla cuya estructura será definida y consensuada con el área usuaria. El sistema permitirá ver el detalle de cada registro del historial de suspensión.

El sistema debe permitir configurar las Sanciones de acuerdo a algún motivo, los criterios que se consideren son por ejemplo: Una Sanción en estado Vigente puede pasar a estado “Vigente Permanente” (predeterminado) por el procedimiento automático. Las sanciones con este estado, podrán visualizarse en el módulo interno y solo para entidades que pertenezcan a un determinado sector.

RF- 012

Módulo de Anulación de Sanciones

El sistema cuenta con un módulo que permite anular los registros de sanciones (opción Consulta - Anular). Sobre el módulo se implementarán los siguientes cambios funcionales:

Cambios de etiquetas en el formulario. Cambios de texto de las alertas de validación en el formulario. Si el registro de la sanción se encuentra en estado VIGENTE, SUSPENDIDA

o NO VIGENTE y/o en otros estados, esto de acuerdo a configuración que puedan ser afectados, debe permitir se registre la anulación de una sanción.

El sistema deberá permitir el ingreso al módulo de registro de los datos de anulación de dos (2) maneras:

a) Desde el formulario de registro de sanción, cuando el usuario se encuentra editando, el sistema mostrará un botón habilitado para ingresar al módulo.

b) Desde la acción “Anular” que se visualiza como acción en los registros consultados a través del módulo de consultas.

En el formulario de registro de anulación de la sanción el sistema deberá permitir la carga de un documento en formato (PDF, JPG) cuyo peso no exceda en 8Mb.

La carga del documento es condición previa obligatoria para la grabación de los datos en el formulario.

Implementar validaciones en el formulario para la verificación de los datos antes de la grabación, las cuales estarán relacionadas a los campos en los



Versión 01

Fecha 02/12/2014

Página 15 de 32




que se registran fechas, además de su comparación con otras fechas del registro de la sanción, suspensión (de ser el caso) y fecha del sistema. Las restricciones para la validación de los datos serán consensuadas con el área usuaria durante el servicio.

RF- 013

Modulo Auditoría de Registros de Sanciones. (Modificación)

El sistema debe permitir poder visualizar la traza del registro de una sanción, por ningún motivo debe existir Borrados físicos, únicamente se debe realizar borrados lógicos.

El sistema debe permitir asegurar que se almacene todos los eventos asociados a un registro de sanción, desde la creación del registro, modificaciones y cambios de estado.

Los registros de auditoría de Sanciones mostrarán el historial de todos los eventos relacionados a los registro(s) de la(s) sanción(es). Se utilizará para realizar un seguimiento sobre los cambios que se realizan sobre un determinado registro de sanción. El sistema debe permitir acceder al historial desde el módulo de consulta de sanciones (aplica según configuración del perfil del usuario). Por cada registro consultado mostrará la acción “Historial”.

La acción “ver historial” generará una ventana emergente que mostrará en forma de lista los eventos. Cómo mínimo la estructura de la lista será:

a) Nombre del evento: se refiere a la acción que realizó el usuario (creación, edición, cambio de estado).

b) Descripción del evento: se refiere al detalle del evento. Se tendrán como mínimo los siguientes: registro de creación, modificación del registro de la sanción, la sanción cambió a estado (nombrar el nuevo estado”.

c) Usuario: el nombre del usuario que ejecutó la acción que generó el evento.

d) Entidad: Nombre de la Entidad a la que pertenece el usuario que ejecutó la acción que provoca la generación del evento. Para los casos en los que el evento lo genera el mismo Sistema, como por ejemplo cambios de estado automáticos, en esta columna se imprime “Sistema”.

e) Fecha, hora y segundo en que se produjo el evento. El sistema permitirá descargar adicionalmente el historial de modificaciones

de cada sanción en formato Excel. El archivo contiene el registro de la sanción con todos sus campos e incluye en su estructura la fecha de modificación, perfil y nombre del usuario que lo modificó. Esta información se almacena actualmente en una tabla del modelo de datos del Sistema.

RF- 014

Consultas sobre los registros de Sanciones

El sistema cuenta con un módulo que permite realizar consultas sobre los registros de sanciones, adicionalmente permite realizar consultas masivas a través de la carga de un archivo conteniendo los números de documentos de identidad de personas sobre las cuales se desea realizar consultas. Sobre el módulo se requieren los siguientes cambios funcionales:

Cambios en las etiquetas del formulario. Cambios en los textos de las alertas del formulario.



Versión 01

Fecha 02/12/2014

Página 16 de 32




Implementar las validaciones para que los resultados de las consultas (masiva y definida por usuario) sean discriminados de acuerdo al perfil y derechos especiales asignados al usuario.

Se debe considerar que las Sanciones con Estado Vigente permanente deben visualizarse por este módulo únicamente si el usuario consultante pertenece a un determinado perfil y/o entidad y/o sector en cuyas configuraciones fue declarada como visualización interna.

RF- 015

A. Consulta Masiva

Se deberá optimizar la consulta masiva para una respuesta más rápida que no supere los 500ms con soporte como mínimo de 5,000 registros por consulta.

Mientras se ejecute el proceso de consulta masiva el sistema mostrará una barra de avance de proceso visible al usuario.

El sistema debe de permitir cargar los datos a consultar en formatos XLS, conteniendo el tipo de documento y el número de documento de identidad.

El sistema debe garantizar la lectura de los datos del archivo con la lista de DNI, sin perjuicio del tipo de dato o formato del archivo, a fin de realizar la comparación con los datos almacenados en la base de datos. Como resultado de la consulta masiva el sistema deberá generar tres (3) archivos de acuerdo a lo siguiente:

a) El resultado consolidado en formato .XLS mostrando un icono referencial visible al pie del formulario para descarga del usuario.

b) Reporte en formato .PDF que contenga el reporte de sancionado de cada uno de los resultados de la consulta masiva, siempre y cuando estos resulten con estado VIGENTE y del tipo de sanción que inhabilite y/o no inhabilite.

c) Reporte en formato .PDF que contenga la ficha informativa de cada uno de los casos que no se encontró en la consulta masiva.

La estructura de cada reporte según el formato, serán definidas por el área usuaria durante la implementación del proyecto.

RF- 016

B. Consultas definidas por el usuario.

El Sistema debe permitir imprimir en formato .PDF cada uno de los registros de sanciones consultados en dos (2) tipos de formato (impresión simple y certificada), la acción es posible de acuerdo a la configuración del perfil del usuario.

Para los resultados de búsqueda que generen cero (0) registros encontrados el sistema generará un enlace para imprimir un reporte denominado “Reporte Negativo” en formato .PDF que contendrá la lista de criterios utilizados para la búsqueda y el resultado de la misma.

El diseño de los reportes de impresión simple, certificada y reporte negativo serán consensuados con el área usuaria. Incluirá codificación de reporte autogenerada por el sistema. Se utilizará los datos del registro del usuario para la construcción del código.



Versión 01

Fecha 02/12/2014

Página 17 de 32




El sistema deberá garantizar que se almacene el historial de las consultas efectuadas por los usuarios del sistema, incluirá el almacenamiento de los criterios de búsqueda seleccionados por el usuario, fecha, hora y minuto en que se efectuó la consulta.

Agregar un filtro de búsqueda al formulario que permita encontrar a las sanciones asociadas a un tipo de sanción cuya configuración indique que se trata de una sanción que inhabilita y no inhabilita.

Agregar un filtro de búsqueda al formulario que permita encontrar a las sanciones que están relacionadas a un acto de corrupción.

Sobre cada registro de sanción resultante de la búsqueda se generan acciones para:

Impresión Simple Impresión Certificada Ver Editar Eliminar Anular Suspender Historial

Cada una de estas acciones solo es visible de acuerdo a los derechos del usuario según su perfil y derechos especiales asignados.

Considerar las siguientes reglas para la visualización de las acciones sobre los registros de sanciones resultantes en la búsqueda: a) Se visualizarán de acuerdo al perfil y configuración de derechos

especiales del usuario autenticado en el sistema. b) Para el caso del usuario con un perfil al cual le corresponda visualizar la

acción de suspender, esta se mostrará de acuerdo a: Si la sanción se encuentra en estado VIGENTE o VIGENTE

PERMANENTE la acción suspender deberá llamarse/etiquetarse como “Suspender sanción”.

Si la sanción se encuentra en estado SUSPENDIDA la acción deberá llamarse/etiquetarse como “Activar sanción”.

RF- 017

Mantenimiento de tablas y Parámetros del Sistema

El sistema permite realizar el mantenimiento de las tablas auxiliares y los parámetros del sistema. Se requiere el desarrollo e implementación de cambios y nuevas funcionalidades que se definen por módulo como sigue:

A. Mantenimiento de Parámetros del Sistema.

El sistema cuenta con un módulo para la configuración de los parámetros del sistema. Sobre el módulo se requieren los siguientes cambios funcionales:

Agregar el parámetro que corresponderá a la “Vigencia de Registro Datos de Entidad” (medido en número de días). Este parámetro será utilizado para calcular la vigencia de los datos de la Entidad. Deberá compararse la fecha del sistema (fecha actual) con la fecha en la que se efectuó la última



Versión 01

Fecha 02/12/2014

Página 18 de 32




actualización de los datos de la Entidad verificando que no exceda el parámetro configurado.

Agregar el parámetro que correspondiente a “Periodo máximo de apelación” (medido en número de días). Este parámetro será utilizado para calcular el inicio del periodo de una sanción y dependerá del tipo de sanción seleccionada en el formulario de registro de sanciones. El área usuaria definirá el método de cálculo en el cual se hará uso de éste parámetro.

Agregar el parámetro “Fecha de corte”, para registrar fecha en formato DD/MM/YYYY que será utilizado en el cálculo del periodo de sanción en formulario de Registro de Sanciones.

El sistema debe permitir administrar cuentas de correo para las comunicaciones. Los parámetros mínimos para agregar una cuenta deben ser:

- Dirección/IP del servidor de correo de la cuenta. - Usuario /Nombre de cuenta - Clave - SMTP Puerto

El sistema debe permitir probar la conexión de cada una de las cuentas agregadas.

Agregar el campo que permitirá que se parametrice el peso máximo de cualquier archivo que será adjuntado/cargado a través de los distintos módulos del Sistema. La unidad de medida deberá ser MB.

RF- 018

Mantenimiento de la Tabla Maestras

Desarrollar e implementar el módulo que permita realizar el mantenimiento

de las tablas maestras (creación, edición y eliminación lógica de registros), de la tabla paramétrica Grados de Instrucción. Incluirá las validaciones para el proceso de creación, edición y eliminación de registros, como por ejemplo las tablas de grados de instrucción, Categoría de Sanciones, Causas de Sanciones.

El sistema debe permitir la habilitación o deshabilitación de la relación de Causas con el tipo de Sanción, que afectará la visualización de las opciones de selección de causas de Sanción en las listas desplegables ubicadas en el formulario de registro de Sanciones. El indicador únicamente afecta durante el registro de una nueva sanción mas no afecta la relación cuando se efectúa una edición o consulta de registros de sanciones registradas antes de la deshabilitación del registro.

El Sistema debe permitir realizar validaciones. Por ejemplo si se efectúa la deshabilitación de una categoría de Sanción automáticamente deberán también desactivarse los tipos de sanciones relacionados a ella.

MÓDULO DE CONFIGURACIÓN



Versión 01

Fecha 02/12/2014

Página 19 de 32




El sistema debe permitir la configuración y mantenimiento de los mismos parámetros de acuerdo a cuadro adjunto en el documento de referencia (Referencia anexo: cuadro de configuraciones 01, 02, 03). Algunas de las más importantes se detalla a continuación: Mantenimiento de la Tabla de relaciones de Régimen laboral vs. Tipos de Sanciones.

El sistema cuenta con un módulo que permite registrar las relaciones entre un determinado régimen laboral y los tipos de sanciones. Se requiere el desarrollo de los siguientes cambios y nuevas funcionalidades:

Modificar el texto de las etiquetas en el formulario. El sistema deberá almacenar la fecha de creación y última actualización del

registro de una relación de régimen laboral y tipo de sanción. La configuración del régimen laboral con el tipo de sanción sólo deberá

afectar la generación de las opciones de selección de régimen laboral y tipo de sanción en el formulario de registro de sanciones cuando se crea una nueva sanción.

Agregar el campo que permita indicar la habilitación o deshabilitación del registro de una relación que afecta la visualización de las opciones de selección de los regímenes laborales y tipos de sanciones en las listas desplegables ubicadas en el formulario de registro de sanciones mas no afecta la relación cuando se efectúa una edición o consulta de registros de sanciones creados antes de la deshabilitación del registro de relación.

Mantenimiento de Tabla Paramétrica de Categoría de Sanciones.

Desarrollo e implementación de un módulo que permita el mantenimiento de la tabla Categoría de Sanción (creación, edición, eliminación lógica de registros).

El sistema debe permitir la habilitación o deshabilitación de las categorías relacionadas con el tipo de sanción, que afectará las opciones de selección de categorías de Sanción en las listas desplegables ubicadas en el formulario de registro de Sanciones. Este indicador afecta la relación de la categoría y tipo de sanción durante el registro de una nueva sanción mas no afecta la relación cuando se efectúa una edición o consulta de registros de sanciones registradas antes de la deshabilitación de la categoría

RF- 019

B. Mantenimiento de Tabla de Tipos de Sanciones.

El sistema cuenta con un módulo que permite el mantenimiento de la Tabla de Tipos de Sanciones, la misma que repercute en el funcionamiento del registro de una sanción específicamente al despliegue de las tablas Régimen Laboral, categoría de sanción, tipo de sanción y causas. Se requiere los siguientes cambios funcionales en la administración de los tipos de sanciones:

El sistema debe contemplar un campo que defina que si el tipo de sanción genera un periodo automático.



Versión 01

Fecha 02/12/2014

Página 20 de 32




Agregar campo que permita indicar si el tipo de sanción solicitará al usuario indicar si la sanción se relaciona o no con una apelación. (La opción afirmativ-a en la configuración de un tipo de sanción genera un campo en el formulario de registro de sanción en el grupo de datos “Datos de la Sanción).

Agregar un campo que permita indicar si el tipo de sanción se relaciona o no con una apelación. La opción afirmativa en la configuración de un tipo de sanción genera un campo en el formulario de registro de sanción en el grupo de datos “Datos de la Sanción”.

Agregar campo que permita indicar si el tipo de sanción “Incluye o no un periodo de sanción”. Considerar el caso que si la opción es afirmativa, en la configuración del tipo de sanción se habilitarán los campos para el ingreso del periodo mínimo y máximo (en días, meses y años) en el formulario de creación de tipos de sanción.

a) El sistema debe realizar validaciones, como por ejemplo si el tipo de sanción incluye periodo de sanción. En el formulario de registro de una sanción se solicitará obligatoriamente el registro de la fecha de inicio y fin del periodo de sanción y se validará el periodo de sanción de acuerdo al periodo mínimo y máximo configurado en el tipo de sanción. Las consideraciones adicionales para el cálculo serán proporcionadas por el área usuaria durante el desarrollo del servicio.

Agregar campo que permita indicar si el tipo de sanción es o no “Visible en Módulo de Consulta Ciudadana”. Se define como una restricción para mostrar resultados de la consulta que se realiza a través del Módulo de Consulta Ciudadana.

C. Mantenimiento de Tabla de relaciones de Tipo de Sanción vs

Causas de Sanción

Desarrollo e implementación de un formulario que permita el mantenimiento de la tabla que relaciona Tipo de Sanción con los registros de la tabla de Causas de la Sanción.

El sistema deberá permitir mediante un formulario relacionar los tipos de sanción con una o más causas. La selección deberá hacerse mediante check’ (Referencia: ver imagen)

Ejemplo Propuesto

Agregar un campo que permita indicar la habilitación o deshabilitación del registro, que debe afectar a la visualización de las causas de Sanción en las listas desplegables del formulario de registro de Sanciones. Este indicador

Tipo de Sanción

Causa 1

Causa 3Causa 4

Causa 2



Versión 01

Fecha 02/12/2014

Página 21 de 32




afecta la relación del tipo de sanción y sus causas durante el registro de una nueva sanción mas no afecta la relación cuando se efectúa una edición o consulta de registros de sanciones registradas antes de la deshabilitación del registro.

Para todos los datos de la tabla paramétrica, el sistema debe permitir realizar eliminación lógica, por ningún motivo debe permitir realizar eliminación física a fin mantener la integridad de la base de datos.

Deberá garantizarse que la relación de las tablas Régimen Laboral, Categoría, Tipo de sanción y causas siga el siguiente esquema:

RF- 020

Módulo de Plantillas de Correos (Implementación)

Desarrollar e implementar el módulo que permitirá al usuario con perfil de administrador y derechos sobre el módulo, crear, editar, deshabilitar plantillas de correos destinadas para los mensajes a usuarios.

Las plantillas de correo para el usuario constarán de Asunto y Cuerpo del Mensaje.

El formulario debe presentar un editor de texto que permita darle detalles de forma al mensaje, como mínimo: tamaño de letra, tipo de letra, color de letra, negrita, cursiva, subrayado, color de fondo del mensaje, inserción de tablas, inserción de imágenes, inserción de url/enlaces, alineación de texto, lista numérica, lista de viñetas, aumento y reducción de sangría.

Debe permitir incorporar campos de la base de datos al asunto y cuerpo del Mensaje.

Las plantillas que se configurarán inicialmente son las relacionadas a los mensajes que el aplicativo envía al usuario cuando ocurran los siguientes eventos:

o Recuperación de clave. o Solicitud de acceso generada. o Solicitud de acceso Aprobada. o Solicitud de acceso Observada. o Solicitud de acceso Rechazada. o Bloqueo de Cuenta de Usuario. o Desbloqueo de Cuenta de Usuario. o Respuesta de Atención de Alertas/Denuncias. o Atención de solicitud de emisión de certificados negativos.

Régimen Laboral

Categoría de Sanción

Tipo de Sanción

Causas de Sanción



Versión 01

Fecha 02/12/2014

Página 22 de 32




Debe permitir asociar a la plantilla una cuenta de correo agregada en el módulo de parámetros del sistema.

Las plantillas deben estar asociadas a una determinado cuenta de correo para realizar el envió correspondiente.

Debe permitir enviar un email de prueba a un único correo destinatario denominado “destinatario de prueba” que será ingresado por el usuario administrador para probar cada una de las plantillas generadas en módulo.

RF- 021

Módulo de Reportes.

La solución debe plantear el diseño e implementación de un módulo de reportes dinámicos que le permitirá al usuario poder seleccionar los campos, la información que se muestre son relacionados con la información del registro de Sanción, la información de los usuarios del Sistema, información de Entidades e información sobre las consultas efectuadas a través del Módulo de Consulta Ciudadana, certificados negativos, alertas.

El módulo de reportes debe ser divido en dos partes y son: o Reportes definidos por usuario o Reportes Estáticos.

El sistema debe tener un diseño intuitivo, que debe ser planteado por el proveedor y aprobado por el área usuaria.

El acceso al módulo debe ser totalmente configurable mediante el módulo de administración de perfiles.

A. Reportes definidos por el usuario.

El sistema debe permitir mostrar los reportes de acuerdo a la necesidad del

usuario, la información requerida debe estar como mínimo relacionada a cualquiera de los siguientes grupos de Datos: o Sanciones. o Entidades. o Usuarios. o Alertas/denuncias. o Solicitudes de Certificados negativos. o Solicitudes de acceso. o Consultas Ciudadanas.

Las consultas debe contemplar criterios de búsqueda y como mínimo se

debe considerar los siguientes: a) Datos de Entidad: o Nivel de Gobierno

Podrá seleccionar más de uno o todas las opciones. o Sector

Podrá seleccionar más de uno o todas las opciones. o Organización del Estado

Podrá seleccionar más de uno o todas las opciones. o Tipo de Entidad

Podrá seleccionar más de uno o todas las opciones. o Entidad



Versión 01

Fecha 02/12/2014

Página 23 de 32




Podrá seleccionar más de una o todas las opciones resultantes. La lista de Entidades dependerá de los parámetros anteriormente seleccionados.

o Ubigeo de la Entidad - Departamento

Podrá seleccionar más de una o todas las opciones resultantes. - Provincia

Podrá seleccionar más de una o todas las opciones resultantes. Si se ha seleccionado más de un departamento la lista se mostrará estructurada por departamento.

- Distrito Podrá seleccionar más de una o todas las opciones resultantes. Si se ha seleccionado más de un departamento o provincia la lista se mostrará estructurada por departamento y provincia.

b) Sanción.

o Régimen Laboral

Podrá seleccionar más de uno o todas las opciones. o Categoría de Sanciones

Podrá seleccionar más de uno o todas las opciones. Las opciones que se listen dependerán de los parámetros anteriormente seleccionados.

o Tipo de Sanción Podrá seleccionar más de uno o todas las opciones. Las opciones que se listen dependerán de los parámetros anteriormente seleccionados.

o Causas Podrá seleccionar más de uno o todas las opciones. Las opciones que se listen dependerán de los parámetros anteriormente seleccionados (régimen, categoría, tipo de sanción).

o Por rango de fechas para: Sanción - Creación de registro. - Inicio de Sanción - Fin de Sanción - Notificación. Suspensión - Inicio de Suspensión - Fin de Suspensión Anulación/Eliminación - Rango de fechas para los registros de sanciones de sanciones

anuladas. o Estados de Sanción

Podrá seleccionar más de uno o todas las opciones.

c) Identidad de los Sancionados. o Por rango de Edades de los sancionados. o Por género.

Podrá seleccionar más de uno. Por defecto ambos parámetros se encontrarán pre – seleccionados.

o Por grado de instrucción.



Versión 01

Fecha 02/12/2014

Página 24 de 32




Podrá seleccionar más de uno o todas las opciones. o Por tipo de documento de identidad.

Podrá seleccionar más de uno o todas las opciones.

d) Usuarios.

o Perfil de los usuarios Podrá seleccionar más de uno o todas las opciones.

o Estado del Usuario Podrá seleccionar más de uno o todas las opciones.

o Área a la que pertenece Podrá seleccionar más de uno o todas las opciones.

o Rangos de Fecha de Registro del Usuario. o Rangos de Fecha de Aprobación de solicitudes.

e) Consultas Ciudadanas

o Criterio de Búsqueda

Podrá seleccionar más de uno o todas las opciones. o Fecha y Rango de Fechas en la que se efectuó la consulta.

f) Solicitudes de Certificados negativos.

o Datos de identidad del solicitante (género, edad) o Estado de la solicitud (permitirá seleccionar más de uno) o Rango de fechas del registro de la solicitud.

g) Alertas/Denuncias o Datos de identidad del denunciante. o Estado de la atención de la alerta. o Rango de fechas del registro de la alerta

Según la información que espera el usuario se habilitarán los parámetros:

Información esperada Parámetros permitidos Registros de Sanciones Entidad

Sanción Identidad del Sancionado Usuarios

Registros de Consultas Ciudadanas

Consultas Ciudadanas

Registros de Entidades Entidades Registros de Usuarios Usuarios Registros de Alertas/Denuncias

Entidad Alertas/Denuncias

Registros de Solicitudes de Certificados Negativos

Solicitud de Certificados Negativos

Los parámetros que se habilitarán permitirán filtrar la información para la generación del reporte.



Versión 01

Fecha 02/12/2014

Página 25 de 32




El usuario podrá elegir el modo de exportación de resultados que puede variar entre formato PDF, Excel.

La estructura de los reportes será definida con el área usuaria (Campos y detalles de forma) y dependerá del grupo de información y los tipos de formato de exportación requeridos.

El sistema deberá permitir grabar los criterios utilizados en la consulta como plantilla, que podrá ser utilizada para generar reportes posteriormente. La plantilla podrá nombrarse, se guardará su fecha de creación y usuario que la generó.

B. Reportes estáticos

Los reportes estáticos se presentarán como lista desplegable y responderán a tres (3) categorías:

a) Relacionado a los registros de Sancionados b) Relacionado a los registros de Usuarios c) Relacionado a las Consultas que se realizan a través del

Módulo de Consulta Ciudadana. Se diseñará e implementará como mínimo quince (15) reportes estáticos que

serán definidos por el área usuaria en coordinación con la SJTI. Los reportes estáticos presentarán información en forma agregada o nominal

y gráficos según la estructura que se diseñe. Todos los reportes deber permitir ser exportados en formato PDF y Excel. El proveedor debe presentar la propuesta de diseño de cada reporte que

serán aprobados por el área usuaria.

RF- 022

Módulo de Carga de Archivos.

Modificar de Carga de archivos, que permitirá al usuario con perfil de administrador y derechos sobre el módulo la carga de archivos en el sistema.

El formulario para la carga de archivos solicitará obligatoriamente por cada archivo que se quiera cargar los siguientes datos:

a) Descripción del Documento b) Fecha del Documento: que será registrada por el usuario. c) Versión del Documento. d) Estado (Activo, Inactivo) e) Fecha de la carga, se registra automáticamente.

El sistema debe permitir la carga de documentos en formato PDF, WORD, EXCEL, con un peso máximo de 5 Mb.

Posterior a la carga de documento el sistema generará un URL que será usado por el usuario de administrador para los fines que se crea conveniente (por ejemplo en las plantillas de correo).

RF- 023

Modulo Transparencia (Módulo externo). Desarrollar e implementar la página de Transparencia que estará conformada por tres (3) módulos:



Versión 01

Fecha 02/12/2014

Página 26 de 32




Los requerimientos al respecto son:

El acceso a la página y a sus módulos no requerirá inicio de sesión y será de acceso público. El enlace de acceso se encontrará como un icono en el módulo de inicio de sesión. (Ver Anexo N° 2).

La identidad gráfica estará alineada a los lineamientos de la Institución y la propuesta debe ser aprobada por el área usuaria en coordinación con la SJTI.

El proveedor deberá elaborar y presentan las maquetas propuestas de los módulos para ser revisadas y aprobadas previamente por el área usuaria y la Subjefatura de TI antes de la implementación. Como mínimo el proveedor deberá presentar dos (2) propuestas.

RF- 024

A. Módulo Consulta Ciudadana

Desarrollar e implementar el módulo de Consulta Ciudadana que permitirá realizar búsquedas sobre los registros de sanciones. El desarrollo del módulo se hará bajo los estándares sobre los cuales se ha solicitado el desarrollo de los cambios nombrados en este documento.

Los tipos de búsqueda de información a través del módulo se darán por dos (02) criterios:

Por datos personales (Nombre, apellido paterno, apellido materno). Por documento de identidad. Para la realización de las búsquedas se solicitará al usuario el ingreso de un

código de seguridad captcha basado en imagen que permita renovar la

imagen y su lectura en altavoz . Los resultados de las búsquedas se mostrarán en un listado cuya estructura

debe ser coordinada con el área usuaria. La estructura mínima considerará: N° ítem, datos del sancionado (nombres, apellido paterno, apellido materno), Entidad que sanciona, categoría de la sanción, tipo de sanción y estado de la sanción.

Los registros de sanciones que se podrán generar como resultado dependerán de la configuración del tipo de sanción al que se encuentren asociado.

B. Solicitud de Emisión de Certificados Negativos

C. Alerta Ciudadana

A. Consulta Ciudadana



Versión 01

Fecha 02/12/2014

Página 27 de 32




El sistema debe Registrar el historial de las consultas realizadas a través del módulo de consulta ciudadana. Como mínimo considerar el almacenamiento de los siguientes datos:

a) Fecha de la consulta b) Hora, minuto y segundo en el que se realizó la consulta. c) Tipo de criterio utilizado por el usuario para la búsqueda. d) Datos ingresados para la búsqueda. e) Dirección pública (IP) del punto desde donde se realizó la

consulta. Si la estructura de la tabla que almacenará el historial de consultas se llegará

a modificar respecto de la actual en el modelo de datos del RNSDD, el proveedor deberá garantizar que la información histórica almacenada hasta el momento de la implementación se ajuste a la estructura de la nueva tabla.

El módulo debe permitir la generación de una ficha en formato PDF que contendrá los datos que forman parte del detalle de cada registro encontrado. La ficha debe tener una marca de agua, logo, fecha y hora de generación del documento. La ficha debe mostrarse preliminarmente en una nueva página con la opción para imprimir o descargar el documento. El diseño de la ficha deberá ser en coordinación con el área usuaria para su aprobación aprobado.

Para las búsquedas cuyos resultados arrojen cero (0) registros, debe permitir la generación de una ficha en formato PDF en la que se listará los criterios utilizados en la búsqueda, un mensaje (el texto se definirá con el área usuaria), fecha y hora de la generación del documento. La ficha debe mostrarse preliminarmente en una nueva página con la opción de impresión o descarga del documento. El diseño de la ficha deberá ser coordinado con el área usuaria para darse como aprobado.

B. Módulo de Solicitud de Certificados Negativos.

Desarrollo e implementación de un módulo que permita que los usuarios públicos generen solicitudes de emisión de certificados negativos.

El formulario para el registro de la solicitud deberá contemplar como mínimo los siguientes campos: tipo y número de documento de identidad, nombres, apellidos, lugar de residencia (incluye ubigeo departamento, provincia y distrito), correo electrónico personal y alternativo, un campo tipo área de texto para que el usuario indique el motivo de la solicitud).

Para la validación de los datos de identidad de persona el formulario consumirá el servicio web de RENIEC para obtener los nombres, apellidos, género, fecha de nacimiento, dirección, restricción.

El sistema debe validar los campos para la grabación de los datos del formulario de acuerdo a lo siguiente: a) El sistema validará que el solicitante no mantenga sanciones vigentes y

que inhabiliten. Si se encuentra registros de sanciones asociadas al usuario entonces el sistema le mostrará una alerta indicando la restricción. Esta validación incorporará restricciones adicionales para mostrar la información al usuario solicitante, las reglas serán proporcionadas por el área usuaria. No se permitirá que un usuario que mantiene sanciones vigentes envíe una solicitud de emisión de Certificado Negativo.



Versión 01

Fecha 02/12/2014

Página 28 de 32




b) Si el usuario solicitante no registra sanciones en el RNSDD entonces los datos se procederán a guardar y la página de respuesta deberá señalar la recepción de la solicitud, mostrando: o Código de trámite que será autogenerado por el sistema para el pago

correspondiente de la tasa del TUPA, o Fecha de entrega (un día posterior a la fecha de registro de la solicitud, o Opción de imprimir el registro de la solicitud o descargarlo en formato

PDF. El sistema enviará automáticamente al correo electrónico registrado por el

usuario solicitante una copia del registro de la solicitud en formato PDF cuyo formato deberá ser aprobada por el área Usuaria.

La generación de una solicitud de emisión de certificado negativo se considera un evento que deberá ser mostrado inmediatamente después de ser grabado en el dashboard del administrador servir del RNSDD.

C. Módulo de Registro de Alertas en Línea.

Desarrollo e implementación de un módulo que permitirá que los usuarios públicos puedan registrar una denuncia sobre un hecho de su conocimiento relacionado al incumplimiento de la normatividad vigente sobre Sanciones, además permitirá que el usuario pueda consultar el estado de atención de la Alerta/Denuncia.

El formulario para el registro de la alerta/ denuncia estará conformado por dos (2) secciones.

a) En la sección N° 1, debe permitir la descarga del manual o guía que especifica los pasos y consideraciones para el manejo del módulo. Este documento será cargado a través del módulo de carga de archivos que es el que genera el enlace de descarga referenciado en este módulo.

b) En la sección N° 2, debe permitir el registro de la alerta a través de un formulario que considera el ingreso de datos de identidad del denunciante y datos propios de la denuncia.

Como datos personales se solicitará los siguientes: tipo y número de documento de identidad, fecha de caducidad del DNI, nombres, apellidos, ubigeo (departamento, provincia y distrito), teléfono (como mínimo dos) y correo electrónico.

Para la validación de los datos de identidad de persona el formulario consumirá el servicio web de RENIEC para obtener los nombres, apellidos, género, estado civil, fecha de nacimiento, dirección y restricción. Solo devolverá la información cuando la fecha de caducidad coincide con los datos devueltos por RENIEC, caso contrario no será posible que en el formulario se carguen los datos obtenidos en la consulta RENIEC.

Los siguientes campos no serán mostrados en el formulario pero si serán almacenados como parte del registro de la persona:

o Fecha de Nacimiento o Dirección o Estado civil o Restricción

Como datos de la alerta/denuncia el sistema solicitará la selección del tipo de alerta/denuncia que el usuario desea registrar y hay tres (3) tipos:



Versión 01

Fecha 02/12/2014

Página 29 de 32




a) Sanciones de despido o destitución, suspensión e inhabilitaciones del poder judicial que las entidades no han registrado en el RNSDD.

b) Conocimiento de personas inhabilitadas que se encuentran laborando en el Estado.

c) Entidades que solicitan dentro de un proceso de selección un certificado de no encontrarse inhabilitado.

Para las alertas del tipo a) se solicitará el ingreso de los siguientes datos para el registro:

o Nombre de la Entidad que viene incumpliendo, el sistema permitirá que el usuario busque y seleccione la Entidad.

o Nombre de las personas sancionadas no registradas en el RNSDD. Se solicitará el ingreso de número de documento de identidad (opcional), nombres y apellidos.

o Categoría de Sanción y Tipo de sanción, el sistema muestra una lista desplegable con los tipos de sanciones e incluirá una opción adicional excepcional que indique que “desconoce el tipo de sanción” (solo aplica en este formulario).

Adjuntar documento de sustento de alerta (opcional). Considerar peso máximo del documento según parámetro del sistema y los formatos permitidos de carga serán JPG, Word, PDF.

Para las alertas del tipo b) se solicitará el ingreso de los siguientes datos en el registro:


o Nombre de las personas sancionadas que es de su conocimiento que labora en el Estado. Se solicitará el ingreso de número de documento de identidad (opcional), nombres y apellidos.

o Descripción de los hechos (campo tipo texto que permitirá el ingreso de un máximo de 4,000 caracteres). El formulario deberá mostrar en todo momento la cantidad de caracteres restantes como dato de referencia al usuario.

o Adjuntar documento de sustento de alerta (opcional). Considerar peso máximo del documento según parámetro del sistema y los formatos permitidos de carga serán JPG, Word, PDF.

Para las alertas del tipo c) se solicitará el ingreso de los siguientes datos en el registro:


o Número de proceso de selección. o Descripción de los hechos (campo tipo texto que permitirá el

ingreso de un máximo de 4000 caracteres). El formulario deberá mostrar en todo momento la cantidad de caracteres restantes como dato de referencia al usuario.

o Adjuntar documento de sustento de alerta (opcional). Considerar peso máximo del documento según parámetro del sistema y los formatos permitidos de carga serán JPG, Word, PDF.



Versión 01

Fecha 02/12/2014

Página 30 de 32




El sistema debe permitir ingresar más de un registro por tipo de alerta. La generación de una alerta/denuncia se considera un evento que deberá

ser mostrado inmediatamente después de ser grabado en el dashboard del administrador servir del RNSDD.

El sistema asignará un código de trámite al registro de la alerta/denuncia. El sistema enviará automáticamente al correo del usuario, copia del registro

de alerta ingresada. Para la consulta de atención de la alerta/denuncia registrada el sistema

permitirá que los usuarios solicitantes realicen la búsqueda según el código de trámite para verificar el estado de la misma que se mostrará como una barra de estado. El resultado de la búsqueda contendrá como mínimo (Código de trámite, Fecha del registro, Estado).

RF- 025

Atención de Emisión de Certificados Negativos.

Desarrollar e implementar el módulo de atención de los registros de solicitudes de Emisión de Certificados Negativos.

El acceso al módulo deberá mostrarse como una opción más del menú y es permitido para los usuarios con perfil administrador y con derechos sobre el módulo según la configuración del perfil.

El sistema debe permitir realizar búsquedas sobre los registros de solicitudes, los filtros de búsqueda como mínimo serán:

o Número de documento de identidad del solicitante. o Nombres, apellido paterno y materno del solicitante. o Fecha y rango de fechas de creación del registro de

solicitud. o Por estado. o Código de Trámite.

El sistema generará los resultados de la búsqueda en forma de lista de paginada, la estructura del listado será definida con el área usuaria durante el servicio.

Por cada registro encontrado en la búsqueda el sistema mostrará acciones para el manejo del registro: atención, consulta y otros que indique el área usuaria.

El área usuaria definirá cuáles serán los estados de los registros de Solicitud de Emisión de Certificados Negativos.

El sistema permitirá que el administrador acceda al detalle del registro mostrando los datos en un formulario. No son modificables los campos que almacenan los datos ingresados por el solicitante.

El sistema deberá permitir que el administrador modifique el estado del registro desde el formulario.

El sistema deberá alertar al administrador cuando el solicitante mantenga registros de sanciones en estado VIGENTE y que inhabilitan.

Atención de Alertas/denuncias.

Desarrollar e implementar el módulo que permita gestionar los registros de

alertas/denuncias. El acceso al módulo deberá mostrarse como una opción más del menú y es

permitido para los usuarios con perfil administrador y con derechos sobre el módulo.



Versión 01

Fecha 02/12/2014

Página 31 de 32




El sistema deberá permitir registrar como un indicador la verificación de la veracidad del contenido de la alerta.

El sistema debe permitir realizar búsquedas sobre los registros de alertas/denuncias. Los filtros de búsqueda como mínimo deberán serán:

o Tipo de alerta/denuncia. o Número de documento de identidad del denunciante. o Nombres, apellido paterno y materno del denunciante. o Fecha y rango de fechas de creación del registro de

alerta/denuncia. o Por Entidad. o Por estado. o Y otros campos que indicará el área usuaria y que forman

parte del registro de la alerta/denuncia. El sistema generará los resultados de la búsqueda en forma de lista de

paginada, la estructura del listado será definida con el área usuaria durante el servicio.

Por cada registro encontrado en la búsqueda el sistema mostrará acciones para el manejo del registro: atención, consulta y otros que indique el área usuaria.

El sistema permitirá que el administrador ingrese en un área de texto la respuesta al ciudadano denunciante y habilitará un botón para efectuar el envío de la respuesta al correo registrado por el denunciante. El texto de la respuesta será parte del cuerpo del mensaje de la plantilla de correo creada para estos fines.

El sistema permitirá adjuntar documentos en forma opcional que se asociarán con el registro de la alerta/denuncia.

Los registros de alertas/denuncias se gestionarán por estados como: Recibido, en proceso, atendida, Notificada. El cambio de estado es automático. El flujo como mínimo deberá respetar lo siguiente:

a) Recibido: Es el primer estado del registro. b) En proceso: Segundo estado, el sistema deberá validar que el

registro haya sido verificado. c) Atendido: Tercer estado del registro, el sistema verificará que se hay

ingresado el texto que contiene la respuesta y que se haya efectuado el envío de la misma al correo electrónico del ciudadano denunciante.

d) Notificado: Cuarto estado del registro, el sistema verificará la confirmación de lectura del mensaje recibido por el destinatario guardando fecha y hora de efectuado el evento. El administrador podrá visualizar el dato como lectura si consulta el registro de la alerta.

El correo enviado como respuesta al ciudadano denunciante deberá contener el enlace a un formulario para responder una encuesta de dos (2) preguntas como mínimo, la primera para indicar el nivel de satisfacción y la segunda será la respuesta a una pregunta. Cuando el ciudadano haya grabado sus respuestas el registro de la alerta se indicará como ‘comentado’. El sistema deberá permitir realizar búsquedas para filtrar estos registros.

Actualización Automática del Estado de los Registros de Sanciones.



Versión 01

Fecha 02/12/2014

Página 32 de 32




Se requiere la implementación de cambios sobre el procedimiento almacenado (store procedure) que realiza la actualización automática del estado del registro de las sanciones. El proveedor deberá coordinar con el área usuaria para identificar y validar las reglas y validaciones que el proceso deberá incluir para efectuar el cambio de estado automático.

Módulo de Administración de los Registros de Apelaciones.

Desarrollo e implementación del módulo que permita a los usuarios con perfil administrador gestionar los registros de apelaciones.

El sistema permitirá realizar búsquedas sobre los registros de apelaciones a través de filtros relacionados con los atributos de una apelación. El resultado de las búsquedas deberá mostrarse en una lista paginada cuya estructura será definida con el área usuaria durante el servicio y además permitirá la descarga en formato Excel de los resultados de la búsqueda.

El sistema permitirá la creación, edición, eliminación lógica, desactivación de registros de apelaciones.

Los registros que se encuentren activos serán mostrados en la ventana de alerta disponible al usuario de inscripción.

2.6 Características del Usuario

No aplica

2.7 Niveles de Seguridad

No aplica

2.8 Consideraciones/ Observaciones

No aplica

3. SOLICITANTES

Magali Meza Mundaca Gerente de Desarrollo del Sistema de

Recurso Humanos

pad-46 descripción de requerimientos versión 01 fecha 02...

Documents