El Suministro deberá incluir todos aquellos ítems que no hubiesen sido expresamente indicados en la presente sección, pero que pueda inferirse razonablemente que son necesarios para satisfacer el requisito de suministro indicado, por lo tanto, dichos bienes y servicios serán suministrados por el Proveedor como si hubiesen sido expresamente mencionados, salvo disposición contraria en el Contrato.
Los bienes y servicios suministrados deberán ajustarse a las especificaciones técnicas y las normas estipuladas en este apartado. En caso de que no se haga referencia a una norma aplicable, la norma será aquella que resulte equivalente o superior a las normas oficiales de la República del Paraguay. Cualquier cambio de dichos códigos o normas durante la ejecución del contrato se aplicará solamente con la aprobación de la contratante y dicho cambio se regirá de conformidad a la cláusula de adendas y cambios.
El Proveedor tendrá derecho a rehusar responsabilidad por cualquier diseño, dato, plano, especificación u otro documento, o por cualquier modificación proporcionada o diseñada por o en nombre de la Contratante, mediante notificación a la misma de dicho rechazo.
Los productos y/o servicios a ser requeridos cuentan con las siguientes especificaciones técnicas:
ACTUALIZACIÓNDEL SISTEMA DE CONTROL DE ACTIVO FIJO (SICAF) DELMINISTERIO DE JUSTICIA
Sistema de Patrimonio de Control de Activo Fijo (SICAF)
Provisión de nuevas versiones programadas. Este ítem se refiere a cambios y agregado de funcionalidades realizadas por el proveedor en el software, sin que ello sea expresamente solicitado por los usuarios.
1. 2 Las actualizaciones en esta modalidad se refieren a:
1.2.1 Cambios de funcionalidades
1.2.2 Agregado de reportes
1.2.3.Agregado de funcionalidades
1.2.4 Mejoras y optimizaciones de funcionalidades
1.2.5 Optimizaciones de consultas SQL, Procedimientos almacenados, índices, tablas, vistas y otros elementos de la base de datos.
1.2.6Optimizaciones de rendimiento general del sistema.
1.2.7 Actualización de plataforma de desarrollo
1.2.8 Actualización de librerías (dll para 32bits y 64bits)
1.2.9 Actualización de motor de base de datos
1.2.10Corrección de bugs desconocidos hasta las versiones previas.
2. Provisión de nuevas funcionalidades requeridas por el usuario. Este ítem se refiere a nuevas necesidades de los usuarios y comprende:
2.1 Cambio en reportes disponibles en el sistema.
2.2 Creación de nuevos formatos de reportes.
2.3 Agregado de nuevos campos a formularios actuales.
2.4 Agregado de teclas rápidas a funcionalidades existentes.
2.5 Agregado de nuevos formularios que extiendan las funcionalidades de los formularios en producción.
2.6 Agregado de nuevas opciones y funcionalidades que extiendan las opciones, formularios, reportes y funcionalidades en producción.
2.7 Análisis de requisitos y especificación funcional. Para aquellas actividades del mantenimiento que supongan nuevas funcionalidades, el oferente deberá elaborar la especificación de requisitos de software. Esta especificación de requisitos de software debe contener una descripción completa del comportamiento del sistema que se va a desarrollar. Incluirá (si así se considera) un conjunto de casos de uso que describan todas las interacciones que tendrán los usuarios con el software. Además de los casos de uso, la Especificación de Requerimiento de Software, también contendrá requisitos no funcionales (o complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación (como por ejemplo restricciones en el diseño o estándares de calidad).
2.8 El proveedor deberá elaborar la documentación necesaria para permitir la correcta instalación del software en los diferentes entornos utilizados en la institución. (Ej. Distintas versiones de sistema operativos).
2.9El proveedor deberá elaborar los manuales, presentaciones y demás soportes necesarios para garantizar una correcta transferencia de tecnología.
2.10Toda la documentación entregada deberá seguir un formato digital, utilizando un sistema de control de versiones.
2.11 La institución verificará el contenido de las documentaciones entregadas a fin de garantizar que el contenido se ajuste a los requerimientos solicitados.
3 Soporte a la puesta en producción
3.1 El proveedor deberá participar en el paso a producción, a requerimiento de la institución cuando lo estime conveniente, al menos de las siguientes tareas:
3.2 Revisión del entorno de producción previamente al inicio de las tareas de instalación.
3.3 Elaboración de los procedimientos necesarios de marcha atrás.
3.4 Acompañamiento en la coordinación, aportando proactivamente la información necesaria para asegurar el resultado de la instalación del sistema en producción.
3.5 Realizar el paso a producción de una forma activa si la institución así lo requiere.
3.6 Capacitación en el uso de las nuevas funcionalidades.
MANTENIMIENTO
4.1 Mantenimiento Evolutivo: son los nuevos desarrollos, las modificaciones y eliminaciones necesarias en un producto software para cubrir la expansión o cambio en las necesidades del usuario.
4.2 Mantenimiento Perfectivo: son las acciones llevadas a cabo para mejorar la calidad interna del sistema en cualquiera de sus aspectos: reestructuración del código, definición más clara del sistema y optimización del rendimiento y eficiencia.
4.3 Mantenimiento Adaptativo: son las modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios de configuración del hardware, software de base, gestores de base de datos, comunicaciones, etc.
4.4 Mantenimiento Correctivo: son aquellos cambios precisos para corregir errores del producto software a los problemas que no puedan ser solucionados por el personal de la institución, en cuyo caso la institución generará los pedidos de soporte técnico para cada evento en particular. Sistemas de consultas mediante dispositivos móviles.
4.5 Realizar diagnóstico y solución de los problemas que afecten a los productos y en el caso que lo requieran se asistirá a la institución en la apertura de casos de soporte con el fabricante de bases de datos y herramientas utilizadas en los sistemas.
4.6 Revisión de bitácoras del sistema operativo, bases de datos y aplicativos para detectar situaciones anómalas que podrían ocasionar caídas en el sistema: La revisión de los componentes de software deberá realizarse considerando las mejores prácticas y configuraciones inherentes a las aplicaciones adquiridas.
4.7 En caso de que la revisión de los componentes de software detecte alguna situación que deba corregirse, se deberá proceder al afinamiento (Tunning) de los parámetros del sistema operativo, bases de datos y programas de la Solución para mejorar el desempeño.
4.8 Ejecución de procesos preventivos de actualización de las bases de datos y detección de inconsistencias.
4.9 Desarrollo y mantenimiento de rutinas y herramientas.
5. Todas las opciones mencionadas más arribas serán probadas o testeadas, por el proveedor en sus propias infraestructuras y no serán requeridas infraestructuras de pruebas en la institución, se coordinarán fechas de actualización con funcionarios de los departamentos involucrados. Una vez puestas en funcionamiento las actualizaciones o cambios mediante manteniendo, se procederá a emitir una hoja de soporte en el cual se consignará los datos de la versión de las actualizaciones realizadas.
6. Capacitación de las actualizaciones o up grades. Se requerirá la provisión de capacitación sobre las nuevas funcionalidades, reportes, agregados y opciones disponibles en cada revisión.
7. Manuales en formato PDF. Se requerirá la provisión de una actualización de los manuales de ambos sistemas. Esta revisión podrá contener una reseña sobre las nuevas opciones, reportes y funcionalidades de cada revisión
SOPORTE TECNICO
8.1 Modificaciones del código fuente de la aplicación que aseguren la continuidad del funcionamiento del sistema, según los requerimientos establecidos por la institución.
8.2 Mejoras en la aplicación con el fin de mantener el nivel de competencia y calidad.
8.3Solución de problemas e implementación de la misma, para todos los módulos que ya se encuentren o sean instalados durante el período de vigencia del presente contrato.
8.4 Asistencia al personal de la institución Configuración de los sistemas abarcando la optimización de las configuraciones y el correspondiente entrenamiento al personal de institución.
8.5 Adiestramiento y optimización de las configuraciones en general de los sistemas de acuerdo con las necesidades de institución.
8.6 Atención de emergencias incluyendo la configuración y/o reconfiguración de equipos informáticos. Asistencia para la optimización de los recursos de hardware.
8.7 Eliminación de fallas mediante servicio de mantenimiento preventivo y correctivo. Instrucción del personal de la institución respecto al impacto y solución de los mismos.
8.8 Soporte y capacitación según requerimiento de la institución para la administración, operación y configuración del sistema, sus tablas, sus relacionamientos y sus contenidos.
8.9 Cooperación para la instalación de la aplicación en nuevos equipos que sean adquiridos por la compañía (por ej. instalación en equipos con S.O. Windows 7 y superiores, software generador de reportes)
8.10 Cooperación para la instalación de una herramienta de control de versiones que permita el óptimo seguimiento y control de las tareas de mantenimiento de programas.
8.11 Confección y generación de nuevos informes. Mantenimiento de los reportes existentes
8.12 Asistencia para la organización y sincronización de procesos y procedimientos vinculados con la utilización de los sistemas.
8.13 Brindar información a la institución sobre el estado de implementación del sistema, su nivel de utilización y productividad potencial aún no utilizada.
8.14 Implementación según requerimientos de la institución de ampliaciones de los niveles de seguridad y auditoria del Sistema, que involucren modificaciones del código fuente de la aplicación, configuraciones de los Sistemas Operativos y las Bases de Datos.
8.15 Las tareas mencionadas en los puntos anteriores deberán realizarse en dependencias de la institución, siempre que no sean tareas que por su naturaleza deban realizarse en otro local y en horarios adecuados a las labores habituales, de tal forma que el personal de la institución tenga la posibilidad de involucrarse y sea partícipe de todos ellos, con el fin de beneficiarse de la transferencia de conocimientos y pueda obtener un mayor aprovechamiento de los mismos.
8.16 El software y los entregables generados durante la fase de mantenimiento, así como los procesos asociados a la generación de éstos, deberá ser conforme a las normativas vigentes en la institución.
8.17 Entrenamiento, para nuevos funcionarios, en la utilización del sistema actual.
8.18 Fortalecimiento del conocimiento de los funcionarios de las bondades de las actuales funcionalidades del sistema.
8.19 Instalación del sistema en nuevos equipos a ser utilizadas en el los departamentos involucrados.
8.20 Soporte para la reinstalación del sistema en equipos formateados, cuyos sistemas operativos han sido reinstalados por indicaciones del Departamento de Informática.
8.21 Soporte para la realización de copias de seguridad de equipos a ser formateados.
9. Forma de prestación del servicio
9.1 La institución será responsable de realizar los pedidos de servicio cuando considere que existe un fallo o malfuncionamiento correspondiente a cualquier módulo de los sistemas mencionados más arriba. El servicio de soporte técnico será prestado a solicitud de funcionarios del Departamento de Patrimonio, Gerencia de Informática o fiscal del contrato.
9.2 Soporte preventivo de 08:00 a 15:00 horas de lunes a Viernes.
9.3 Sitios donde podrán realizarse los soportes presencial on-site:
9.3.1 Gerencia de Tecnología de Información y Comunicación.
9.3.2 Departamento de Patrimonio.
9.4 Todas las tareas realizadas en forma presencial deberán efectuarse en forma conjunta con el personal designado por el fiscal del contrato de manera a asegurar la adecuada transferencia de conocimientos hacia el personal de la institución.
9.5 Soporte correctivo de 08:00 a 15:00 horas de Lunes a Viernes con técnicos locales del proveedor; y/o soporte remoto en caso de urgencia o necesidad, según nivel de criticidad 1 (uno) o 2 (Dos). El soporte remoto podrá efectuarse vía fax, email, o internet, en este último caso una vez finalizada el servicio se desconectará o cerrará la sesión de acceso a internet. Igualmente podrá utilizar otro tipo de comunicación de modo a solucionar el problema existente, siempre y cuando no trasgreda lo estipulado en la Política de Seguridad de la institución.
9.6 Se podrán efectuar por medio escrito, por fax, o por correo electrónico (considerándose todas estas formas igualmente validas), a las direcciones acordadas entre la institución y el Proveedor al inicio del contrato.
9.7 La institución notificará las anomalías que se presenten incluyendo la siguiente información:
9.7-1 Fecha y hora.
9.7.2 Descripción del problema.
9.7.3 Usuarios y procesos afectados.
9.7.4 Nivel de criticidad de la falla.
9.8 El proveedor deberá mantener un registro de los mismos, utilizando un sistema de seguimiento de errores, que asignará automáticamente un número de incidencia y a su vez deberá estar integrada al sistema de control de versiones, que permita conocer la revisión en la cual se ha solucionado el incidente.
9.9 El tiempo que transcurra entre el momento de reportar un incidente de soporte técnico y el momento de atención del proveedor para brindar la solución al problema o para acordar con la institución un nuevo plazo para la atención, no deberá exceder las 24 horas.
9.10 Las resoluciones a los problemas que pudiesen surgir deberán ajustarse a lo establecido en la Tabla Plazos de Resolución de Incidentes. Para el caso que la resolución del problema sea imposible de resolver en los plazos estipulados, el proveedor, deberá acordar con la institución un nuevo plazo, teniendo la institución la decisión única y exclusiva sobre el nuevo plazo de resolución.
|
Nivel |
Tiempo de resolución máximo |
Impacto |
Detalle del impacto |
|
1 |
24 horas |
Alto |
Software detenido, fallas del Sistema o indisponibilidad o falla de máxima funcionalidad de componentes vitales. |
|
2 |
48 horas |
Medio |
Software no detenido, falla en componentes vitales solucionable en forma transitoria y no definitiva. |
|
3 |
72 horas |
Bajo |
Software no detenido, falla de componentes no vitales que requieren solución no inmediata. |
|
4 |
15 días |
Muy Bajo |
Problemas en nuevos componentes o funciones no utilizables aún en el ambiente de producción. |
9.11 Ante cada incidente como mínimo el proveedor deberá actualizar el registro en su sistema de control de incidencias con la siguiente información:
9.11.1 Descripción detallada del problema, su causa y solución propuesta.
9.11.2 Problemas que se presentaron durante la resolución.
9.11.3 Documentación adjunta de los cambios hechos.
9.11.4 Recomendaciones.
9.11.5 Fecha y hora de resolución.
9.12 El proveedor deberá acompañar a los técnicos de la institución, en la continua implementación de tareas, aportando la experiencia de implementaciones anteriores. La variedad de tareas y ambientes a automatizar requieren de conocimiento previo para realizarlas en forma efectiva.
9.13 El proveedor deberá proporcionar capacitación al personal técnico de la institución bajo la modalidad entrenamiento en el trabajo (Training on the Job).
9. 14 A la finalización de cada servicio de soporte técnico el proveedor emitirá una hoja de soporte, la cual será firmada y aceptada por el funcionario responsable del departamento, en la misma también podrá ser incluida observaciones que se consideren necesarias.
9.15 A petición de la institución mediante el fiscal de contrato designado, se emitirá un informe de los servicios técnicos prestados, consignando en el mismo las fechas de realización del soporte, tareas realizadas y funcionario firmante.
10. Requerimientos logísticos requeridos
10.1 Para el adecuado desarrollo del proyecto, la institución se encargará de los trámites administrativos para garantizar a los técnicos, el acceso a sus instalaciones en los horarios que sean definidos, la identificación de los mismos como contratistas temporales, dispondrá de espacio para la ubicación de los puestos de trabajo, facilitará los puntos de conexión a la red corporativa y utilización de líneas telefónicas (para comunicaciones internas) asignadas al proyecto.
10.2 El software y hardware, necesarios para la codificación y pruebas de las Especificaciones de Requerimientos de Sistemas deberá ser suministrada por el proveedor.
10.3 Actividades administrativas del oferente. La institución requiere que el proveedor efectúe las siguientes actividades administrativas durante la ejecución del proyecto:
10.3.1 Mantener de manera eficiente y adecuada las comunicaciones del servicio por medio del fiscal designado por la institución.
10.3.2 Asegurar la disponibilidad de sus técnicos de tal manera que brinde la asistencia requerida por la institución.
10.3.3 Trabajar conjuntamente con el fiscal designado por la institución para resolver las desviaciones que se presenten en el plan del servicio.
11 Servicios vinculados a proveer
Soporte por 12 (doce) meses.
Actualización del Sistema Integrado de Recursos Humanos (SIRH) del Ministerio de Justicia
Especificaciones Técnicas
A continuación, se listan unos objetivos deseados a lograr con la implementación de este proyecto.
1.1 Generar una base de datos Única de Recursos Humanos de la institución.
1.2 Minimizar los trabajos realizados en islas independientes entre los distintos departamentos involucrados en la gestión de los Recursos Humanos, y permitir trabajar sobre un único sistema y una única fuente de datos.
1.3 Ayudar a cumplimentar la normativa existente.
1.4 Permitir una fácil accesibilidad y aprovechamiento de la información.
1.5 Reducción de costes y tiempo, reduciendo la cantidad de recursos presupuestarios destinados a horas extraordinarias y adicionales utilizadas actualmente para registrar los legajos, expedientes, y diversos procesos de la Dirección de Recursos Humanos.
1.6 Optimización de los recursos, permitiendo seleccionar a los Recursos Humanos de la institución para ocupar cargos y asumir responsabilidades de acuerdo a su perfil, evitando la subutilización de los mismos.
1.7 Reducción del traslado de los funcionarios para la realización de trámites administrativos relativos a su legajo personal.
1.8 Facilitar el registro, la actualización y la consulta del legajo del personal mediante la implementación de diversos mecanismos de acceso a una base de datos integrada, ya sea mediante una aplicación institucional, portal de empleados o aplicaciones móviles.
1.9 Optimizar los procesos Administrativos actuales.
2. Normativa
2.1 La plataforma de software deberá estar adecuada a la Legislación Paraguaya, para el modelado de las reglas de negocios y procedimientos administrativos. La implementación de este sistema debe considerar el conjunto de normativas vigentes que rigen a las entidades y organismos del Estado, igualmente debe posibilitar la adecuada migración de la información contenida en los actuales sistemas de información que posee la Institución.
2.2 Las normativas vigentes que deberá soportar el sistema son las siguientes (son enunciativas, pero no limitativas).
2.2.1 Ley Nº 1535/99 De Administración Financiera del Estado
2.2.2 Ley 1626 De la Función Pública
2.2.3 Decreto N° 8127/2000 Por el cual se establecen las disposiciones legales y administrativas que reglamentan la implementación de la ley Nº 1535/1999, De Administración Financiera del Estado, y el funcionamiento del sistema integrado de administración financiera-SIAF
2.2.4 Decreto N° 10.143/2012. Por el cual se aprueba el Código de Ética del Poder Ejecutivo que establece la vigencia de un sistema de gestión ética en base a valores y normas que deben regir y orientar la conducta de las autoridades y servidores públicos
2.2.5 SET RG Nº 82/2016 Por la cual se disponen medidas administrativas relacionadas al Impuesto a la Renta del Servicio de Carácter Personal IRP.
2.2.6 Resolución SFP Nº 1317/2015. Que dispone que el registro de asistencia de los servidores públicos permanentes, contratados y comisionados para sus tramitaciones a ser realizadas ante la Secretaría de la Función Pública sean a través de registros de control tecnológicos
3. Características técnicas
3.1 Multiusuario. Con la posibilidad de creación de perfiles y usuarios para la asignación de las distintas opciones, funciones, procedimientos, reportes y formularios disponibles en el sistema.
3.1.1 Deberá permitir el acceso controlado a cada menú del sistema. En caso que estos menús impliquen operaciones deberá permitir el acceso de solo Lectura o lecto escritura.
3.1.2 Deberá permitir el acceso a controles que permitan borrados o modificaciones, de manera tal a permitir establecer acceso por usuario.
3.1.3 El sistema deberá poder conectarse a servidores LDAP/Active Director y en producción para la validación de usuarios.
3.2Auditable, debe poseer una bitácora de auditoria de todas las operaciones realizadas por los usuarios con las fechas y horas correspondientes.
3.3 La bitácora de auditoria deberá estar implementada a nivel de base de datos utilizando trigger o disparadores para dicho efecto. No se aceptarán auditoria implementada mediante aplicaciones.
3.4 Base de datos relacional, el sistema deberá almacenar las transacciones en un motor de base de datos relacional con soporte ACID y compatible con el estándar ANSI SQL 2008. En ningún caso se aceptarán sistemas con base de datos basados en ficheros.
3.4.1 Deberá cumplir otras capacidades adicionales tales como:
3.4.1.1 Lenguaje procedimental y de funciones.
3.4.1.2 Funciones escalares
3.4.1.3 Funciones con valores de tablas
3.4.1.4 Funciones de agregado
3.4.1.5 Funciones de sistemas
3.4.2 Esquemas
3.43 Trigger o disparador el cual deberá ser empleado en el mecanismo de auditoría del sistema.
3.4.4 Desencadenadores de bases de datos
3.4.5 Estadísticas del uso de la base de datos para obtener mejoras conforme al uso del mismo.
3.4.6 Mecanismo para visualizar el resultado de consulta que pueden ejecutarse mediante petición de los usuarios o almacenarse como si fuera una tabla. Debe disponer de mecanismo de seguridad que permita definir los roles o acceso de los usuarios a estas consultas.
3.4.7 Tipos de datos de sistemas
3.4.8 Tipos de datos definidos por el usuario
3.4.9 Tipos de tablas definidos por el usuario
3.4.10 Tipos definidos por el usuario
3.4.11 Soporte para ensamblados para .Net Framework
3.4.12 Reglas
3.4.13 Guías de plan de ejecución
3.4.14 Secuencias
3.4.15 Funciones de partición
3.4.16 Se deberá poder definir objetos como índices y elementos de requerimiento de acceso rápido para colocarlo en un fichero independiente en discos del tipo SSD.
3.4.17 Auditoria
3.4.17.1 Debe disponer de auditoría integrada propia del motor de base de datos
3.4.17.2 Debe disponer de auditoría creada para uso del sistema basada en triggers. Debe funcionar para las sentencias Insert, Update, y Delete.
3.4.18 Seguridad y nivel de acceso.
3.4.18.1 Usuarios
3.4.18.2 Roles
3.4.18.3 Claves simétricas
3.4.18.4 Certificados
3.4.19 Alta disponibilidad. Al ser una operación crítica la producción de documentos se deberá dotar de un sistema con alta disponibilidad el cual consistirá como mínimo en disponer una base de datos que soporte una copia síncrona de la base de datos en producción, al cual se podrá recurrir en falla del primero en forma automática, sin que esto represente una pausa a la producción de documentos.
3.4.20 Copias de seguridad y respaldo. El sistema deberá disponer de un sistema automático de copias de respaldo debidamente configurado para realizar las mismas al menos una vez al finalizar las operaciones del día.
3.5 Los reportes y formularios emitidos podrán exportarse a otros sistemas de ofimática como Microsoft Excel y Microsoft Word como mínimo.
3.6 Documentado, debe proveerse el manual de usuario en forma impresa y en formato PDF.
3.6.1 Se deberá incluir enlaces de videos tutoriales (que pueden ser hospedados en el servidor institucional o en servidores públicos tipo Youtube).
3.6.2 Estos videos deberán permitir a los usuarios recordar procedimientos o realizar paso a paso, algunas funcionalidades del sistema.
3.7 Ambiente Web. El sistema deberá ser del tipo Web Enabled, permitiendo escalabilidad y fácil despliegue de la aplicación. La aplicación deberá generar respuestas HTML/HTML5 puras y no requerirá la instalación de aplicaciones adicionales para el funcionamiento como plugins tipo ActiveX o Applet de Java.
3.7.1 Ambiente web, compatibilidad, clientes. Mozilla Firefox en su última versión o superior, Google Chrome en su última versión o superior, Internet Explorer en su última versión o superior y Safari en su última versión o superior.
3.8 La visualización de reportes deberá realizarse en el navegador sin necesidad de descarga de ficheros PDF o similares, para tal efecto deberá implementarse un servidor de reportes. La aplicación deberá operar en forma integrada con el servidor de reportes.
3.9 El despliegue podrá realizarse utilizando Aplicación tipo StandAlone, y Servicios de Windows. Adicionalmente deberá proveerse módulo para servidores IIS y Apache en su última versión, de tal manera a obtener rendimiento, escalabilidad y balanceo de carga.
3.10.1Los despliegues de aplicaciones, deberán permitir ser escalables, proveyendo para ello una aplicación que permita desplegar múltiples instancias de la misma aplicación, para sectorizar a la instalación, por ejemplo una instancia para los usuarios del departamento de Legajos, otra instancia para los usuarios del departamento de Salarios, de manera tal que en caso que sea necesario realizar cambios en un departamento y se requiera apagar momentáneamente el sistema, no afecte a la totalidad sino solo al área afectada.
3.10.2 Estas aplicaciones deberán permitir interconectarse entre instancias para formar nodos y gestionar automáticamente las sesiones, instanciando nodos a medida que sean requeridas mas sesiones, y purgando a las sesiones que ya no sean utilizadas.
3.10.3 Despliegue remoto. Esta característica deberá permitir subir los nuevos ejecutables mediante una interfaz gráfica, y a medida que se purguen las sesiones, reemplazar por las nuevas versiones.
3.11 Identificación de sistemas y sus componentes. Todos los componentes de los sistemas deberán ser identificados con el nombre del mismo y adicionalmente con Número de Versión + Número de Revisión + Número de Build (Ejemplo 2.15.24, para permitir a los usuarios realizar consultas sobre funcionalidades de cada versión a los administradores de sistemas de manera univoca).
3.12 Para aplicaciones del tipo Servicio, o servidores, serán construidos y publicados para funcionar en forma nativa para 64 bits, aprovechando con esto toda la capacidad de recursos de hardware disponible en los servidores.
3.13 Para aplicaciones tipo standalone, escritorio y utilidades diversas serán publicadas en forma nativa para 32 bits, permitiendo una homogeneidad entre todas las aplicaciones disponibles en la institución, considerando que existen equipos con sistema operativo de 32 y 64 bits deberán coexistir. Estas aplicaciones deberán generarse en formato ejecutable y ser automáticamente empacable en formato .cab y publicados al servidor de actualizaciones para su distribución.
3.14 En todos los casos, todas las aplicaciones y componentes, deberán ser en formato binario, evitando utilizar lenguajes interpretados, capas intermedias de abstracción u otros elementos similares que impacten negativamente en el rendimiento de las aplicaciones.
4. Características de administración y autogestión
Estas funcionalidades están destinadas a los administradores de sistemas para simplificar las tareas de administración y gestión de los mismos.
4.1 Registro de Usuario. Deberá disponer del registro y sus correspondientes permisos y niveles de acceso.
4.1.1 Impresión de formularios para registro de usuarios. Este formulario podrá ser impreso y llenado por el usuario como solicitud de creación de usuarios.
4.1.2 Notificación de creación y bienvenida al sistema mediante correo electrónico. Una vez creado el usuario, el sistema deberá enviar un correo electrónico de bienvenida. Este mensaje de bienvenida deberá permitir ser personalizado con HTML, para incluir imágenes y link a manuales del sistema.
4.1.3 La autenticación de usuarios deberá ser única para todas las plataformas de servicios (Aplicaciones Web, Aplicaciones auxiliares de escritorio, Aplicaciones para teléfonos móviles).
4.1.4 Deberá disponer de una funcionalidad para generar una contraseña aleatoria.
4.2 Autogestión. El sistema deberá disponer de un link en la pantalla de inicio para Recuperar contraseña. En caso que sea olvidado el sistema deberá enviarlo por correo electrónico.
4.2.1 En caso que las solicitudes se realicen desde la web deberá incluir un Captcha, para prevenir que sistemas automáticos maliciosos intenten recuperar contraseñas.
4.2.2 En los casos de autoservicios para el usuario final deberán aplicar el mismo proceso, pero en vez de Nombre de Usuario, se deberá utilizar como identificador el Número de Documento y como contraseña un PIN de cuatro dígitos.
4.2.3 En caso de las aplicaciones para teléfonos móviles, se deberá incluir una opción para recordar el usuario y contraseña, que simplifiquen el acceso desde el teléfono.
4.2.4 Este procedimiento deberá ser un proceso autónomo sin intervención de usuario, totalmente automático en cualquier horario del día, permitiendo que los usuarios que se encuentran distribuidos a lo largo de la geografía nacional, puedan restaurar en caso de olvido.
4.2.4.1 El procedimiento requerido consistirá en lo siguiente:
4.2.4.1.1 El usuario seleccionará en su dispositivo móvil / aplicación de escritorio / o aplicación web un enlace disponible en la pantalla de inicio de sesión que indica Olvide mi Contraseña, y se iniciaría el pedido de tres elementos.
4.2.4.1.2 Número de Documento o Nombre de Usuario.
4.2.5 Si existiesen coincidencias entre los parámetros, previo proceso por los servidores de aplicaciones, se generará una nueva Contraseña, caso contrario se emitirá una alerta.
4.2.6 Todas las validaciones deberán ser realizados en el servidor de aplicaciones, los dispositivos deberán enviar los datos, y elementos gráficos sin procesamiento o pre procesamiento alguno.
4.2.7 Deberá disponer de una pantalla de Ayuda, indicado claramente con el (?) signo de interrogación, que deberá desplegar al menos datos de contactos del personal de soporte técnico o número de teléfono donde llamar en caso de soporte, link a manuales, y link a video tutoriales.
4.2.8 Inicio por primera vez, en caso que el usuario inicie por primera vez sesión el sistema, deberá emitirse un mensaje de Bienvenida, solicitando de manera obligatoria el cambio de contraseña.
4.3 Monitoreo de Sistemas. El sistema deberá disponer de forma integrada, una aplicación de monitoreo de todos los servicios asociados al sistema. Esta pantalla de recursos permite a los administradores monitorear el funcionamiento del sistema.
4.3.1 Las funciones de monitoreo, control, administración de usuarios es provisto en una aplicación general de administración del sistema.
4.3.2 Adicionalmente deberá permitir reiniciar los servicios, e inclusive el servidor. Esta herramienta deberá permitir acceder a los sistemas vía web, en caso que el administrador no encuentre otra manera de acceder al servidor.
4.4 Actualización automática de aplicaciones
4.4.1 Si bien se solicita que el Core Principal solicitado deberá ser provisto con característica Web Enabled, también deberán ser provistas algunas aplicaciones auxiliares que requieran actualización local (aplicaciones de escritorio), tales como la aplicación de gestión de relojes biométricos.
4.4.2 Se deberá proveer de un servidor de aplicaciones que mantenga actualizado las aplicaciones de escritorio, verificando que la versión sea la misma disponible en el servidor y en caso que se trate de una versión previa descargar y reemplazar por la versión más actualizada.
4.4.3 El mismo mecanismo deberá ser utilizado para descargar archivos y librerías adicionales, drivers de acceso a datos y drivers de relojes biométricos, deberán ser descargados y actualizados.
4.4.4 Deberá establecer parámetros de configuración regional en caso que no se encuentre los parámetros Paraguay / Español requerido.
5 Plataforma Utilizada actualmente
5.1 El sistema está desarrollado con las siguientes características técnicas.
5.2 Base de datos: SQL Server 2017 (14.0), Multiplataforma Open Sources y Propietarios: Red Hat Enterprise Linux 64 bits (Open Source) o superior, CentOS Linux Server 64 bits (Open Source) o superior, Windows Server 64 bits.
5.3 Considerando que el proyecto abarca Aplicaciones para Servidores 64 Bits, Aplicaciones para escritorio para Windows de 32 Bits y dispositivos móviles en IOS y Android, para mantener una única rama de codificación: RAD Studio (Lenguaje Object Pascal / IDE Delphi).
5.4 Para las aplicaciones Web, deberán ser del tipo RIA (rich Internet application), Una aplicación web que tiene la mayoría de las características de las aplicaciones de escritorio tradicionales, que permitan a los usuarios utilizar de manera fácil toda la plataforma solicitada, para dicho efecto deberá utilizarse AJAX con la librería Ext JS versión 6.5 o superior.
6 Funcionalidades globales de las aplicaciones
6.1 En los ficheros que contengan grillas con datos, deberá agregarse un encabezado que contenga un filtro, que, dependiendo de los valores de los campos, sean del tipo texto, numérico, lista de valores, fechas, actuará como un filtro de una hoja de cálculo. Este comportamiento deberá permitir al usuario un proceso rápido al estar familiarizado con las hojas de cálculo.
6.2 Indicaciones visuales en las grillas, con colores rojos como alerta en la línea. (podrán ser otros colores para otras alertas).
6.3 Deberá disponer de una modalidad de capacitación, en la cual los cambios realizados en la base de datos no tengan impacto sobre los datos, y sea utilizado solamente para fines de entrenamiento.
6.3.1 Deberá mostrar claramente en la pantalla un gráfico o logotipo indicando que es de capacitación, para evitar confusiones al usuario.
7 Módulos y funcionalidades requeridas
Se han divido en módulos, las funcionalidades requeridas por la institución, y como mínimo deberán ser las siguientes.
7.1Legajos del funcionario Modulo a ser Actualizado
7.1.1Datos del funcionario. El Sistema Integrado de Recursos Humanos, deberá permitir registrar la información del funcionario tales como Nombres, Apellidos, Dirección, Teléfonos, Fotografía (tipo carnet), Documentos, como CI, Pasaporte, Licencia de conducir y los archivos escaneados de los mismos a fin de contar con un legajo en archivo digital.
7.1.1.1En caso de teléfonos deberá permitir registrar varios, (más de un celular, teléfonos fijos adicionales).
7.1.1.2En caso de direcciones deberá disponer de una base de datos estandarizada de Geolocalizaciones del Paraguay (como mínimo deberá incluir Departamento, Distrito, Localidad).
7.1.1.3Deberá disponer de campos de Geolocalización de direcciones y desplegar con Google Maps integrado en la misma pantalla de operación
7.1.1.4.1En caso que la fotografía tenga una foto de cuerpo entero o área mayor, deberá realizar un recorte automático del rostro y adjuntarlo al módulo de legajos.
7.1.1.4.2Opcionalmente deberá disponer para su utilización de la funcionalidad de Chroma Key o Telon verde, permitiendo de esta manera limpiar el fondo de las fotos tomadas con un telón o cartulina verde utilizada en el proceso de captura de actualización de fotografías.
7.1.2Datos del grupo familiar del funcionario.
7.1.2.1El sistema deberá contar con un registro del grupo familiar del funcionario, como mínimo datos de: Nombres y CI de hijos, padres, hermanos y otros parentescos definibles.
7.1.3Estudios y formación académica del funcionario
7.1.4El legajo digital de funcionario deberá contar con un registro de estudios realizados por el funcionario, el nivel de la instrucción (primario, secundario, universitario, cursos técnicos) la Institución donde realizó dichos estudios, y los idiomas que habla, lee y escribe el funcionario.
7.1.5Historial laboral de los funcionarios previos a su contrato o nombramiento dentro de la institución.
7.1.6Historial de categorías, bonificaciones y autorizaciones de descuentos, así como también la definición de cargo y línea presupuestaria.
7.1.7Datos de profesión
7.1.8Buscadores, deberá incluirse un buscador que permita localizar legajos ya sea por Código, Número de Documento, Nombres y Apellidos, Números de legajos.
7.1.8.1Las búsquedas por el campo de Nombres y Apellidos deberán poder realizarse como búsquedas parciales y en cualquier orden.
7.2Historial de función dentro de la institución. El funcionario podrá disponer de una carrera administrativa, por ejemplo, iniciar como Contratado, y luego el mismo vínculo cambiar a Permanente y en cada instancia, podrá realizar funciones en un departamento y cambiar a otro.
7.3Deberá tener al menos el historial de la carrera administrativa del funcionario desde su nombramiento hasta su jubilación, además de otros registros como amonestaciones, multas, sumarios y sanciones, traslados internos y externos con trasferencia de línea presupuestaria inclusive, condicionamientos internos y a otras instituciones.
7.3.1Deberá registrar además el Área, Departamento, Dirección, Programa donde se encuentre prestando servicios, así como también un historial de la evaluación de desempeño.
7.4El sistema deberá registrar datos como Antecedentes Físicos, Limitaciones Físicas, Grupo Sanguíneo, en Caso de emergencia a que número acudir, para una base de datos de uniformes para el funcionariado, talles de camisa, zapato y pantalón,
7.5El sistema deberá identificar a los funcionarios permanentes, contratados, comisionados, matriciados y acuerdo a eso aplicar distintos reportes.
7.6Reportes a emitir en base a datos de legajos
7.6.1Reporte del Perfil de funcionario
7.6.2Reporte de Ficha del funcionario
7.7Documentos de legajos. Deberá permitir adjuntar Documentos de Legajos relacionados al personal, tales como Copias de Cedula de Identidad, Copias de Títulos, Certificados, etc).
7.8Documentos de la carrera administrativa, tales como Resoluciones, Decretos, estos documentos podrán ser únicos o múltiples y deberá poder describirse, tanto la Procedencia, Periodo, Identificadores de Número y año.
7.8.1Deberá permitir capturar los datos del contenido del documento, indizarlos y permitir búsquedas, por ejemplo (Decreto Nº 24/2018, Nombramiento, Cargo Director, o Resolución Nº 30/2018 Designación de Jefe de Departamento).
7.8.2En todos los casos los documentos podrán ser adjuntados en formato PDF, para su posterior consulta, desde cualquiera de las plataformas Web, Escritorio o Móvil.
7.9Reportes de legajos
7.9.1Reportes de personal por organigrama (todos o solo alguna seleccionada)
7.9.1.1Ordenados por Número de Documento, Apellidos.
7.9.1.2Filtrado por Tipo de Vínculo (Ejemplo Permanente, Contratado).
7.9.1.3Filtrado por Objeto de Gasto (Ejemplo 141, 142, 143).
7.9.2Reportes de personal con fotografía
7.9.2Reporte de alertas de datos de legajos
7.9.3.1Se deberá incluir un reporte que permita alertas de los datos faltantes, con el fin de actualizar el legajo, por ejemplo:
7.9.3.1.1Personal sin datos de Horarios establecidos
7.9.3.1.2Personal sin datos de teléfono o dirección
7.9.3.1.3Personal sin Huella capturada
7.9.1.1.4Personal sin Carga Horaria definida
7.9.3.1.5Personal sin Fotografía capturada
7.9.4Se deberá incluir la posibilidad de impresión de un formulario para la actualización de legajos.
7.9.5Deberá incluir consultas y generación de reportes, con diversos filtros tales como
7.9.5.1 Tipos de vínculos
7.9.5.1 Estado
7.9.5.2 Cargo / Función
7.9.5.4Categoría
7.9.5.5Ubicación / Organigrama
7.10 Emisión de documentos
7.10.1Impresión y emisión de credenciales. El sistema deberá poder imprimir credenciales utilizando impresoras de PVC en formato CR80, utilizando los datos y fotografías previamente cargados.
7.10.1.1Al emitir la credencial, adicionalmente deberá desplegar datos de credenciales o carnet previamente impresos a modo de consultas.
7.10.1.2Deberá emitir un comprobante de dos partes (talón y acuse de recibo) para el funcionario, que se utilizará como comprobante de entrega al funcionario de dicha credencial.
7.10.2.Constancia laboral.
7.10.2.1El sistema deberá poder emitir un comprobante estandarizado de ser funcionario de la institución y permitir la consulta de las constancias previamente impresas.
7.10.2.2La constancia de trabajo deberá incluir datos de la antigüedad, situación, tipo de vínculo, y demás datos personales.
7.10.3Certificado de trabajo.
7.10.3.1 El sistema deberá permitir la emisión de certificados de trabajo de personal, y la consulta de los certificados previamente emitidos.
7.10.3.2El certificado de trabajo emitido deberá incluir como mínimo datos de la antigüedad, tipo de vínculo, datos personales, datos de salario, fotografía.
7.10.3.3Se deberá incluir un formato estandarizado sugerido por la Secretaría de la Función Pública.
7.10.4Contratos del personal
7.10.4.1El sistema deberá permitir la generación e impresión de contratos de trabajo, emitidos con los datos del personal.
7.10.4.2Los contratos podrán imprimirse de manera individual o por lotes.
7.10.4.2.1En los casos de lotes podrán ser utilizados para generar un Lote de una dependencia, por ejemplo, Lote 123 Contratos de la Dirección de Administración y Finanzas, de manera que permita la distribución de los contratos y recolección posterior a la firma por parte de los funcionarios.
7.10.5Recepción física de contratos. Deberá agregarse una funcionalidad que permita mediante captura mecanizada utilizando Códigos de Barras 2D o 3D, marcar la recepción de los mismos.
7.10.6Los formatos de Credenciales, Certificados, Constancias podrán ser modificado y adecuado por el administrador del sistema utilizando una aplicación para diseño cuyas características se detallan más adelante.
7.11Carga masiva de datos
7.11.1El sistema deberá disponer de mecanismo para carga masiva de datos, utilizados para actualizar los datos o como relevamientos de datos del personal.
7.11.2Se deberá agregar una funcionalidad para la actualización masiva de datos del personal, cuya fuente de información sea provista en una planilla de Excel, esta planilla deberá ser validada al importar al sistema, entre las validaciones deberá incluirse, la validación de existencias de datos de contactos, validaciones de Localidad / Distrito / Departamento (en base a los requerimientos estandarizados provistos por la administración tributaria.
7.11.3Una vez importado y validado deberá actualizar el legajo del personal, y emitir un informe correspondiente a dicha tarea.
7.11.4Actualización masiva de fotografías. Al igual que la carga o actualización individual de la fotografía de legajos, esto permite la actualización masiva, permitiendo la subida de una carpeta completa de archivos fotográficos, disminuyendo sustancialmente el tiempo de actualización de datos.
7.11.4.1Para las fotografías deberá permitir capturar de una vez archivos del formato JPG nombrados con el número de CI (por ejemplo 1542114.jpg).
7.11.4.2Solicitudes de contratos
8 Definiciones y ficheros
8.1 Programas y tipos de Programas
8.2 Tipos de documentos del personal
8.3 Tipos de documentos de Legajos
8.4 Nacionalidad
8.5 Establecimiento (Lugares de emisión de títulos académicos)
8.6 Profesión
8.7 Especialidad
8.8 Cargos y Grupos de cargos
8.9 Categorías
8.10 Organigrama
8.10.1 El sistema deberá disponer de un editor de organigrama visual que genere los organigramas a partir de la estructura de dependencias disponible en el sistema.
8.10.2Esta funcionalidad deberá permitir disponer siempre de un organigrama actualizado.
8.10.3El organigrama deberá poder imprimirse y exportarse a programas ofimáticos.
8.10.4El organigrama deberá poder visualizarse tanto de modo vertical y horizontal, deberá poder realizarse zoom sobre el mismo.
8.10.5Deberá permitir disponer de nodos al menos en (Elipse, Rectángulo, rectángulo redondeado, o rombo).
8.10.6Cada nodo representará a un superior, subordinado o asistente y el mismo deberá tener como mínimo los siguientes datos: (Nombres y Apellidos, Número de CI, Cargo, Fotografía, todos estos datos deberán mantenerse actualizado a partir de los datos del legajo).
9 Asistencias de funcionarios- Módulo a ser Actualizado
9.1 Captura de huellas
Para las asistencias el sistema deberá registrar marcaciones realizadas por medio de tarjetas de proximidad o tarjetas con código de barras, datos de huellas dactilares o datos georreferénciales a través de un aplicativo para móvile
9.1.1 Las capturas de huellas podrán realizarse mediante la aplicación auxiliar de escritorio, utilizando un escáner de huella dactilar, o mediante el propio reloj biométrico administra por el sistema.
9.1.2 En caso de capturas mediante escáneres de huella, adicional a la parilla especifica del algoritmo.
9.1.3 El sistema deberá disponer de un mecanismo para instalar de manera automática drivers de los relojes y escáner utilizando el sistemas de actualización de aplicación.
9.1.4 Se deberá proveer al menos compatibilidad con un algoritmo de huella dactilar
9.1.5 En caso que se requiera algún algoritmo adicional la Institución proveerá el SDK requerido
9.1.6 Durante el proceso de la captura de huellas se deberá incluir alertas.
9.1.6.1 Indicador de color verde oscuro para huellas a sincronizar, pudiendo el administrador seleccionar los dedos que serán enviados a los relojes.
9.1.6.2 Color rojo para indicar problemas en la extracción de las características de huella
9.1.6.3 Color naranja para posibles huellas repetidas, ya sean reales o falsos positivos. Se deberá agregar un valor en porcentaje de similitud con otra huella indicada.
9.1.6.4 Se deberá agregar una opción para seleccionar el nivel de acceso que tendrá el usuario, ya sea este un usuario regular o un administrador.
9.1.6.5 Se deberá contar con una opción para seleccionar los dedos predefinidos, marcar o seleccionar todas las huellas o desmarcar todas las huellas, para minimizar el tiempo en seleccionar los dedos.
9.1.6.5.1 Deberá disponer de una funcionalidad para cambiar los mismos parámetros por un organigrama o dependencia.
9.1.6.6 Deberá disponer de un reporte con las indicaciones de los dedos, las opciones de registro y fotografía del personal, que podrá ser utilizado para diversos trámites como las excepciones de marcación por huella.
9.2 Registro mediante tarjetas.
9.2.1 Deberá disponer de una opción que permita definir la marcación mediante tarjetas RFID.
9.3 Datos y parámetros para marcación de asistencias (datos de usuarios, huellas y fotografías)
9.3.1 Se deberá proveer una funcionalidad para descargar dichos datos a los relojes biométricos. Por defecto será utilizada la red, pero opcionalmente deberá estar disponible pendrive, en caso que la red no esté disponible.
9.3.2 Se deberá permitir descargar mediante pendrive (el sistema deberá generar el contenido de los mismos en un pendrive).
9.3.3 Deberá disponer de una funcionalidad para descargar o sincronizar dichos datos mediante red utilizando protocolo TCP.
9.3.4 Los datos de usuarios deberán incluir los parámetros de marcación ya sea por huella, tarjeta o PIN, y si el usuario es usuario normal o administrador de reloj.
9.3.5Deberá permitir la descarga o sincronización de datos de
9.3.5.1 Un solo funcionario
9.3.5.2 Un organigrama o una dependencia
9.3.5.3 Una planilla personalizada
9.4 Registro de marcación
9.4.1 El sistema deberá permitir la importación de registros de marcación de entrada y salidas de funcionarios en formato texto descargado de los relojes mediante pendrive.
9.4.1.1 Deberá disponer de una opción para cargar o importar las fotografías de las marcaciones, en caso que los relojes dispongan de cámara fotográfica.
9.4.2 Deberá permitir la descarga de marcaciones mediante el uso de red.
9.4.2.1 En caso de las descargas vía red podrán ser Diferenciales o Completas.
9.4.2.2 Deberá permitir la descarga de fotografías de marcaciones y asociarlas al registro de asistencias, para los relojes que tengan cámara fotográfica.
9.5Deberá disponer de un servicio que permita recolectar de forma automática en horario predefinido los registros de asistencias de aquellos relojes marcadores conectados en red. Opcionalmente podrá sincronizar los datos del personal con estos dispositivos.
9.5.1 Servicio es una aplicación ejecutable de larga duración, que no dispone de interfaz gráfica, que se ejecutan en su propia sesión sin necesitar de inicio de sesión por parte de los usuarios.
9.5.2 Para un correcto despliegue y configuración del servicio la institución proveerá de los discos de instalación y SDK de estos dispositivos.
9.5.3 Comúnmente el SDK está compuesto de ficheros de librerías DLL que contiene instrucciones para la administración y operación de los dispositivos, estas instrucciones disponen parámetros de entradas y emite respuestas.
9.5.4 Los parámetros de entradas deberán ser enviadas por el servicio basado en las preferencias y configuraciones definidas en el Legajo del Personal.
9.5.5 Las respuestas generadas por los dispositivos basados en las funciones ejecutadas deberán ser recolectadas en forma automáticas y almacenarlas en el sistema.
9.5.6 Deberá disponer de un registro y/o log del funcionamiento del servicio.
9.5.7 El resultado esperado es que los usuarios dispongan desde su front office todos los reportes de asistencias.
9.6 Integración a relojes biométricos. Deberá disponer de un fichero de registro de relojes biométricos, que permita la captura de parámetros del mismo, para usos durante la sincronización de datos.
9.6.1 Deberá permitir captura de parámetros del Reloj como IP, Puerto, y datos adicionales como Marcas, Modelos, Ubicación, Número de Serie, etiqueta de Identificación.
9.7 Reportes de asistencias. El sistema deberá permitir generar reportes con los siguientes parámetros.
9.7.1 Rango de fechas (Inicio y Fin de la consulta de asistencias).
9.7.2 De un solo personal.
9.7.3 De un organigrama (opcionalmente puede incluir dependencias).
9.7.4 De un Reloj en específico.
9.7.5 De un grupo de Reloj en específico.
9.7.6 De una planilla que no siga ninguno de los anteriores criterios.
9.7.6.1 Este registro personalizado podrá ser una o varias listas personalizadas.
9.7.6.2 Cada lista personalizada podrá ser modificada o actualizada de manera registro a registro o mediante importación desde una planilla de Excel.
9.7.7 Deberá permitir la impresión de reportes de asistencias en diversos formatos y como mínimo los siguientes:
9.7.7.1 Planilla sin procesar, debiendo ser un espejo de las marcaciones obtenidas de los relojes.
9.7.7.1.1 Identificación de varios intentos de marcaciones.
9.7.7.2 Planilla estándar, aplicando reglas de horarios y licencias
9.7.7.3 Planilla estándar simplificada, para ser entregada a los funcionarios en caso que estos consulten sus asistencias.
9.7.7.3.1 Debe contener al menos una columna de Fecha / Horario de Entrada / Horario de Salida / Eventos (Llegadas tardías, Días feriados, Salidas tempranas) y Licencias (Ausencias y eventos justificados).
9.7.7.4 Planilla extendida, que contenga datos adicionales para uso interno del departamento.
9.7.7.4.1 Adicionalmente a la columna de Fecha / Horario de Entrada / Horario de Salida / Eventos (Llegadas tardías, Días feriados, Salidas tempranas) y Licencias (Ausencias y eventos justificados), deberá incluir horarios de referencias, una columna para totalizar Ausencias, Llegadas tardías, salidas tempranas, Horas Extras, Horas Adicionales, Tiempo asistido a la institución.
9.7.7.5 Planilla de Resumen de asistencias, que será un resumen de las anteriores planillas.
9.7.7.5.1 Deberá contener columnas para totalizar los eventos, por ejemplo, Ausencias, Llegadas tardías, Salidas Tempranas, y Multas por cada evento.
9.8 Turnos y horarios de trabajo. Deberá permitir la definición de múltiples turnos y horarios de trabajos.
9.8.1 Los horarios predefinidos podrán ser asignados a cada vínculo del personal.
9.8.2 Opcionalmente cada funcionario podrá disponer de un horario no estandarizado.
9.8.3 Deberá permitir diversos tipos de horarios, permitiendo al usuario definir horarios:
9.8.3.1 Fijos Un horario de entrada y salida fija, con días fijos. Ejemplo lunes a viernes de 8:00 a 15:00 Hs.
9.8.3.2 Rotativos Horarios rotativos, por ejemplo, para personal de guardia, seguridad, por ejemplo, cada 3 días turnos de 12 horas.
9.8.3.3 Calendarizados. Deberá permitir horarios que no sigan ninguno de los tipos anteriores, sino una fecha fija definida en base a un calendario.
9.8.3.4 Intercalados Horarios que puedan intercalar los horarios, por ejemplo, martes y jueves de 7:00 a 12:00 Hs, y la siguiente Semana Lunes, miércoles y viernes de 8:00 a 13:00 Hs., intercalando semana tras semana.
9.8.3.5 Todos los horarios deberán tener una vigencia de inicio y fin, permitiendo de esta manera disponer de múltiples horarios en el trascurso del tiempo y esto ser aplicado a los diversos reportes, en el periodo de fecha dado.
9.8.3.6 Se deberá poder establecer tolerancias a horarios, tolerancia de entradas y salidas, por ejemplo 15 minutos de tolerancia de entrada.
9.8.3.7 Horarios especiales. Deberá permitir establecer horarios flexibles, que sumaricen solo las cantidades de horas trabajas, y no indiquen llegadas tardías o salidas tempranas, aplicable al personal superior.
9.8.4 Para asignar los horarios, se deberá disponer de un fichero en el legajo o un asistente para asignar los mismos. Al finalizar el procedimiento deberá emitir un comprobante para uso interno.
9.9 Multas. El sistema deberá emitir informes de multas en base a los registros de asistencias y las licencias cargadas. Las multas podrán ser por los siguientes motivos:
9.9.1 Ausencias
9.9.2 No marcó salida
9.9.3 Salida antes de hora
9.9.4 Llegadas tardías y muy tardías
9.9.5 El sistema también deberá contemplar una funcionalidad excepción de multa para funcionarios de mayor jerarquía, fuero sindical o funcionarios exonerados por alguna disposición o permiso vigente.
9.10 Excepción en el horario de trabajo. El sistema deberá permitir crear una excepción en el horario de trabajo (Salida antes de hora temporalmente por exámenes, tratamientos médicos, o similar).
9.11 El sistema deberá permitir la gestión de días festivos o feriados. Los mismos deben estar indicados en los reportes de asistencias, evitando marcar esa fecha como Ausencia.
9.12 El sistema deberá permitir la gestión de asuetos. Los asuetos deberán cargarse en el sistema desde una hora determinada. Los mismos deben estar indicados en los reportes de asistencias, evitando marcar esa fecha como Salida antes de hora.
9.13 El sistema deberá permitir la carga de días lluviosos. Los días lluviosos deberán permitir una tolerancia de llegada tardía a ser definida por el usuario, para evitar que los reportes de asistencias emitan informes con Llegadas tardías cuando existan estas excepciones.
9.14 El sistema deberá permitir la impresión de planillas proformas de asistencias manuales, ya sea para uso individual o múltiple a ser utilizado en caso de falla de relojes marcadores.
9.15 Administraciones de Permisos y licencias. El sistema deberá permitir la carga de Permisos y Licencias y los mismos deben indicarse en los reportes de asistencias de funcionarios.
9.15.1 Ausente con Justificativo
9.15.2 Ausente con Reposo Médico
9.15.3 Comisionado
9.15.4 Vacaciones
9.15.5 Cursos y Seminarios
9.15.6 Cursos y Seminarios, y seminarios pagados por la institución.
9.15.7Llegadas muy Tardía con Justificativo
9.15.8 Duelos y/o fallecimiento de familiar
9.15.9 Permiso por Maternidad
9.15.10 Licencia por Lactancia
9.15.10.1 Podrán definirse llegadas más tardías o salidas más tempranas de acuerdo a la solicitud del personal.
9.15.11 Llegada Tardía con Justificativo
9.15.12 No marcó Entrada con Justificativo
9.15.13 No marcó entrada/salida con Justificativo
9.15.14 Salida antes de Hora con Permiso
9.15.15 Permisos remunerados
9.15.16 Permisos con goce de sueldo
9.15.17 Permiso sin goce de sueldo
9.15.18 Permisos por Traslados o tareas fuera de institución.
9.16 El sistema deberá poder establecer límites a cada tipo de permiso solicitado. Por ejemplo (máximo 10 permisos por exámenes anuales).
9.17 Se deberán poder establecer las modalidades sobre las licencias, por ejemplo, si serán contados como días hábiles o corridos, Ejemplo vacaciones 12 días hábiles.
9.18 El sistema deberá permitir la impresión de formatos preconfigurados de Órdenes de Trabajo, Solicitudes de Licencia y Justificativos, dichos formularios podrán ser utilizados como estándares en la institución.
9.19 Reportes de licencias y permisos
9.19.1 Deberá incluir reportes de licencias y permisos, ya sea por un personal o por una dependencia.
9.19.2 Reporte de licencias cruzadas. En caso que el funcionario realice alguna marcación dentro de los plazos de una licencia. Por ejemplo durante sus vacaciones asignadas, concurra a su lugar de trabajo y realice la marcación.
9.20 Reportes de multas. Las multas deberán poder imprimirse con el detalle de asistencias, mostrando claramente el cálculo de los mismos por un periodo determinado.
9.21 Marcación georreferencial a través de aplicativo para móviles.
8.21.1. Se debe proveer de un aplicativo que permita la marcación de asistencia a través de celulares.
8.21.2. El ingreso al aplicativo debe darse a través de una contraseña personal habilitada para cada funcionario.
8.21.3. Las informaciones a transmitir al Sistema Principal son:
8.21.2.1. Posición georreferencial del usuario.
8.21.2.2. Hora de transmisión de la posición
8.21.2.3. Número del celular utilizado para la transmisión.
10 Liquidación de Salarios Módulo a ser Actualizado
10.1 El sistema deberá generar los cálculos de los distintos conceptos mencionados más abajo tanto de las Percepciones y Descuentos. La generación podrá realizarse en forma individual por funcionario o en un proceso en lotes para todos los funcionarios.
10.1.1Deberá permitir conocer el saldo presupuestario por cada unidad jerárquica.
10.1.2 Con esta información deberá permitir controlar la cantidad de cargos ocupados y vacantes.
10.2 El sistema deberá generar los cálculos de los distintos conceptos mencionados más abajo tanto de las Percepciones y Descuentos. Deberá tener opción para generar la Liquidación del Salario en forma individual o de la totalidad de los funcionarios.
10.3 Los conceptos que podrán ser liquidados serán los siguientes:
10.3.1Sueldos (OG 111)
10.3.2 Dietas
10.3.3 Gastos de representación (OG 113)
10.3.4 Aguinaldo (OG 114)
10.3.5 Gastos de residencia
10.3.6 Remuneración extraordinaria (OG 123)
10.3.7 Remuneración adicional (OG 125)
10.3.8 Subsidio familiar
10.3.9 Bonificaciones por grado académico
10.3.10 Bonificaciones por antigüedad en la función
10.3.11 Bonificaciones por responsabilidad en el cargo
10.3.12 Bonificaciones por gestión administrativa
10.3.13 Labores insalubres
10.3.14 Labores riesgosas y servicios en lugares inhóspitos
10.3.15 Otras bonificaciones y gratificaciones
10.3.16 Gratificaciones
10.3.17 Bonificación por exposición al peligro
10.3.18 Gratificaciones por servicios especiales
10.3.19 Bonificación por gestión presupuestaria
10.3.20 Unidad Básica Alimentaria - UBA
10.3.21 Escalafón diplomático y administrativo
10.3.21 Contratación de personal técnico (OG 141)
10.3.23 Contratación de personal de salud (OG 142)
10.3.24 Jornales (OG 144)
10.3.25 Honorarios (OG 145)
10.3.26 Otros gastos del personal (OG 199)
10.3.27 Subsidio para la salud
10.3.28 Estos conceptos deben ser configurables y permitir cambiar o agregar nuevos ítems de acuerdo al Presupuesto General de Gastos aprobado anualmente.
10.3. 29 La aplicación de estos ítems podrán ser aplicables para el Cálculo de Aporte Jubilatorio. Cada ítem deberá ser configurado por el usuario para la aplicación de la jubilación.
10.3.30 En caso los quienes no tengan aportes jubilatorios y en su reemplazo emitan facturas como el caso de OG 145 Honorarios, deberá realizar el cálculo correspondiente al Impuesto de Valor Agregado, el cual podrá inclusive ser configurado para tener retenciones, cuando el funcionario tenga IDAP (Identificador de Acreedor Presupuestario).
10.3.31 Estos parámetros deberán ser indicados en el vínculo de funcionario, durante la emisión del contrato correspondiente.
10.4 El sistema deberá contemplar una funcionalidad para descuentos de Asociaciones, Cooperativas y Sindicatos y mantener un fichero del mismo, así como la liquidación y descuento automático en la planilla de salario.
10.5 Los descuentos podrán cargarse de las siguientes maneras:
10.5.1 Manualmente en un fichero de descuentos.
10.5.2 Importación desde un fichero de Excel emitido por Asociaciones, Cooperativas y Sindicatos. El sistema deberá poseer una funcionalidad para interpretar los ficheros en formato electrónico Excel (xls) preestablecido e importarlos a su base de datos.
10.6 El sistema deberá gestionar descuentos judiciales que podrán ser:
10.6.1 Cobros guaraníes
10.6.2 Prestación alimentaria
10.6.3 El sistema deberá permitir guardar los datos del demandante, Juzgado, monto de juicio y cuenta corriente judicial.
10.6.4 El sistema deberá realizar los descuentos en el proceso de liquidación de salarios.
10.6.5 El sistema deberá poder emitir un Estado de Cuenta Judicial a petición del funcionario.
10.6.6 Como mínimo el estado de cuenta judicial podrá contener datos
10.6.6.1 Demandante
10.6.6.2 Juzgado / Actuario / Juez
10.6.6.3 Caratula / Oficio
10.6.6.4 Monto del Juicio / Gastos de Justicia / Intereses / Honorarios
10.6.7 Este estado de cuenta judicial deberá mantenerse actualizado conforme se vayan descontando de los salarios.
10.7 Liquidación de salarios. El sistema deberá permitir agregar los conceptos en los legajos del funcionario que podrán ser en porcentaje sobre el salario o valores fijos, los mismos podrán ser:
10.7.1 Gastos de representación
10.7.2 Descuentos de los beneficios tales como
10.7.3 Bonificación por Grado Académico
10.7.4 Bonificación por Antigüedad
10.7.5 Ayuda escolar
10.7.7 Bonificación por Responsabilidad en el Cargo
10.7.7 Bonificación por Responsabilidad en la Gestión Presupuestaria
10.7.8 Gratificaciones por Servicios Especiales
10.7.9 Cajeros y Verificadores
10.7.10 Labores Insalubres
10.7.11 Ordenadores de Gastos
10.7.12 Habilitados Pagadores o Tesorero
10.7.13 Reportes a partir de información de salarios
10.7.14 Reportes de disponibilidad de cargos y vacancias
10.7.15 Reporte de liquidación de Bonificaciones por:
10.715.1 Grado académico
10.7.15.2 Antigüedad
10.7.15.3 Bonificación por Gastos de representación
10.7.15.4 Ayuda Escolar
10.7.15.5 Responsabilidad en el cargo
10.7.15.6 Ordenadores de gastos y habilitados pagadores o tesorero
10.7.15.7 Cajero y verificadores
10.7.15.8 Bonificación por responsabilidad en la gestión presupuestaria
10.7.15.9 Labores insalubres
10.7.15.10 Gratificaciones por Servicios Especiales
10.7.15.11 Bonificación Familiar
10.7.16 Reporte de Gratificaciones por funcionario
10.7.17 Reporte de Remuneración Adicional y Remuneración extraordinaria
10.7.18 Planilla de liquidación de sueldos
10.7.19 Planilla Anual de pagos
10.7.20 Reporte de liquidación de Aguinaldos
10.7.21 Deberá permitir la personalización por parte de los usuarios de los modelos de impresión de comprobantes de pagos de salarios, utilizando un editor de modelos de impresión con características WYSIWYG.
10.8 Parámetros y validaciones para liquidación
10.9 El sistema deberá disponer de redondeo y este redondeo podrá ser opcional para cada concepto ya sea para salario, beneficios y/o descuentos, de tal forma a evitar números decimales y/o fraccionarios.
10.10 Validaciones para liquidación. Deberá disponer de unas validaciones que permitan disminuir los posibles errores durante el proceso de elaboración de las planillas de liquidaciones. Algunas de ellas son:
10.10.1 Función o cargo duplicado
10.10.2 Personal sin categoría actual
10.10.3 Personal sin función actual o con pendencia de regularización de traslado.
10.10.4 Con asignación 0, o la categoría no tiene un valor monetario definido asociado.
10.10.5 Personal contratado con contrato actual vencido.
10.10.6 Personal contratado con contrato sin fecha de vencimiento.
10.10.7 Personal que no registra asistencia en el periodo a liquidar.
10.10.8 Control de categorías (disponible, ocupado, vacante).
10.11 Pagos parciales en medida de cantidad de días, con captura de observaciones, motivos del pago parcial.
10.12 Pagos retroactivos, cuyo procesamiento podrá realizarse por monto, cantidad de días por periodo, en base a la fecha de posesión de cargo, agregándose captura de observaciones y motivos de pago retroactivo.
10.13 Funcionalidad de cambios masivos, ya sea un contrato en específico o una selección realizada. Estos cambios masivos pueden darse por errores en la carga, o cambios de vigencias.
10.14 Funcionalidad de importar solicitudes de contratos mediante ficheros de Excel, en un formato estandarizado.
10.15 Funcionalidad de actualización de datos de contratos desde ficheros de Excel, se podrán proveer ficheros en formatos estandarizados Excel que podrán sobre escribir datos del contrato, por ejemplo, actualización de horarios, o datos personales u otros campos mandatorios en contratos.
10.16 Renovación masiva de contratos, provista en archivos de Excel.
10.17 Adicionalmente a las reglas estandarizadas de pagos, y alertas asociadas con los mismos, el usuario deberá disponer de una opción para autorizar o desautorizar pagos sobrepasando todas las reglas establecidas. Este proceso deberá tener una indicación del motivo por el cual se ha realizado la operación.
10.18 Informes de inconsistencias o alertas.
10.19 Este informe de control, deberá contener alerta tales como
10.19.1 Salario de pago mayor al salario establecido en el contrato
10.19.2 Pagos en meses anteriores, y cese de pagos en el periodo actual
10.20 Realización de proceso de bajas individuales o masivas.
10.21Filtros comparativos entre distintos periodos, emitiendo alertas, por ejemplo, de Vínculos inactivos, que permitan minimizar el olvido de inclusión en las planillas de pagos.
10.22.Deberá incluirse alertas adicionales, como vencimientos de contratos, contratos distintos a montos.
10.23 Excepciones de pagos por un periodo determinado, en caso de permisos sin goce de sueldo.
10.24 Reportes adicionales de traslados temporales, bajas y movimientos de un periodo determinado.
10.25 Consultas auxiliares de salarios. Por ejemplo, Detalle de los descuentos aplicados y formularios, y valores utilizados para dicho efecto.
11. Plan financiero Módulo a ser incorporado
11.1 Una vez generada la Nómina de Salarios y Liquidaciones, podrán ejecutarse dependiendo del plan financiero asignado a la institución.
11.2 Para esta tarea el sistema deberá disponer un registro del plan financiero, con las cuantías asignadas a cada Objeto de Gasto, Fuente de Financiamiento, Programas, y Subprogramas estos ficheros podrán ser modificados en el transcurso del tiempo, por ejemplo, en caso de reprogramación presupuestaria.
11.3 Fichero del plan financiero. El fichero deberá ser anual.
11.3.1 Deberá disponer buscadores, por programas, subprogramas
11.3.2 Deberá permitir actualizar o cargar en forma masiva inclusive desde un archivo en formato Excel.
11.4 La nómina generada deberá ser correlacionada con el Plan Financiero del mes correspondiente para emitir las planillas de solicitudes de fondos.
11.4.1 Deberá permitir realizar ajustes en las diversas planillas permitiendo mover o transferir una línea a otra solicitud de fondos.
11.4.2 En todo momento deberá permitir al usuario visualizar los fondos disponibles en cada plan financiero.
11.4.3 Deberá permitir la impresión de solicitudes de fondos en los formatos correspondientes
11.4.3.1 Para personal permanente
11.4.3.1Personal contratado
11.4.3.3 Judiciales
11.4.3.4 Descuentos para entidades
11.4.4 Deberá permitir la generación de las solicitudes de fondos en formato CSV, con todos sus detalles para la ejecución la red bancaria.
11.5 Durante la ejecución de la operación del plan financiero deberá indicarlo con alertas a los usuarios sobre planillas ya ejecutadas, las pendientes, desfinanciadas, inclusive aquellas ya que dispongan de la STR.
11.6 Cheques y Chequeras
11.6.1 En casos puntuales donde no sea posible pagar mediante la red bancaria, el sistema deberá poder imprimir cheques y mantener un control de las chequeras de pagos de salarios.
11.7 Reporte de ejecución presupuestaria de salario
11.7.1 deberá disponer de un reporte que permita visualizar la ejecución de salarios, bonificaciones y otros pagos al personal de la institución, así como el saldo presupuestario que permita realizar modificaciones al presupuesto con suficiente antelación.
12 Bienestar del personal Módulo a ser Actualizado
12.1 En base a los datos del Legajo deberá disponer de informe de:
12.1.1 Carrera académica del personal (tanto para el personal administrativo en general, como para el personal técnico misional de la institución).
12.1.2 Esta información académica deberá ayudar en la elaboración de las capacitaciones a realizarse.
12.1.3Al finalizar las capacitaciones deberá disponer de un reporte sobre las asistencias a capacitaciones realizadas, que permita ayudar al personal capacitado actualizar su legajo.
12.1.4 Al mismo tiempo esta información deberá permitir a la institución realizar promociones internas o externas del personal o realizar búsquedas de candidatos a ocupar cargos con requerimientos de formación específica.
12.2 Evaluación del personal
12.2.1 Deberá permitir la generación de un formulario de evaluación del personal.
12.2.2 La generación del formulario vacío de evaluación de desempeño se deberá permitir realizar tanto en forma individual por cada personal, así como por una dependencia especificada.
12.2.3.Las dependencias podrán ser un solo elemento del organigrama o un rango.
12.2.4 Se deberá permitir la excepción de realización de evaluaciones por vínculo.
12.2.5 Se deberá permitir la recepción de formularios de evaluación por lotes.
12.2.6 Reporte de evaluaciones deficientes (en ambas etapas anuales, tienen nota menor o igual a calificación dos).
12.2.7 Anulación de formularios de evaluación, ya sea en formulario individual o por lotes.
12.2.8 Prorrogas de carga de formulario, ya sea individual o por lotes.
12.3 Capacitación del personal.
12.3.1 Deberá permitir crear solicitudes de capacitación del personal y realizar trámites de los mismos.
12.3.2 Estas solicitudes podrán ser de forma individual o grupal (para cursos y capacitaciones grupales).
12.3.3 Se deberá permitir definir diversos tipos de capacitaciones Ej. Curso, Seminario, Charlas, Capacitaciones Técnicas, etc.
12.3.4 Las solicitudes de capacitaciones podrán diversos tipos de requisitos y estos requisitos a su vez tener condiciones por ejemplo (Cumple, No Cumple, No Aplica), en criterios como candidatos a cumplir ciertas capacitaciones previas, áreas específicas, disponibilidad presupuestaria, etc.
12.3.5 Las solicitudes podrán tener material adjunto por ejemplo folletería de los cursos, plan de programas, etc
12.3.6 Las solicitudes deberán contener información de los cursos, organizador de evento, fecha de inicio, fecha de fin, duración, lugar, horarios, fechas de inscripción limite, entre otros.
12.3.7 Las solicitudes deberán disponer de información financiera, por ejemplo, Proveedor y condiciones de pagos, así como los respectivos montos de Inversión de capacitación, comisiones, etc.
12.3.8 Los datos de información de las capaciones, sus objetivos y si estos están en el Plan de capacitación institucional.
12.3.9 La información de los proveedores deberá generada en un fichero de proveedores, y estos ficheros inclusive podrán ser obtenidos mediante un servicio REST provisto por la DNCP, mediante los servicios provistos por su conjunto de datos abiertos.
12.3.10 Deberá soportar el estándar de autenticación oauth mediante token establecidos en https://www.contrataciones.gov.py/datos/api/v2/
12.4.1 Selección de personal
12.4.1 Este módulo deberá permitir gestionar los llamados a concursos de ya sea interno o externo.
12.4.2 En todos los casos deberá permitir capturar datos establecidos en el portal Paraguay Concursa
12.4.3 Deberá disponer de un fichero del Cargo vacante y las cantidades, asi como la información financiera de los mismos, y los requisitos solicitados
12.4.4 Deberá disponer de un fichero de candidatos, donde serán cargados todos los datos de los mismos.
12.4.5 Se deberá permitir mediante un asistente cargar un candidato a un cargo, y el sistema deberá permitir las comparativas entre distintos niveles de cumplimiento.
12.4.6 Por ejemplo, en una visualización Kanban los datos de cumplimiento documental, cumplimento de experiencia, cumplimiento de entrevistas, etc.
12.4.7 Cada tipo de cumplimiento será una etapa y esta podrá ser definida en el propio sistema.
12.4.8 Deberá permitir la visualización de informes de comparación de candidatos, para la toma de decisión y posterior carga en el portal Paraguay Concursa.
13. Aplicaciones móviles Módulo a ser Incorporado
Se deberá incluir dos aplicaciones móviles, una destinada al personal del Área de Recursos Humanos que permita realizar consultas al sistema de cualquier funcionario y otra destinado al personal de la institución. Esta última aplicación deberá permitir al propio funcionario consultar sus salarios, asistencias y legajos, sin necesidad de concurrir hasta la Dirección de Recursos Humanos para realizar la gestión.
13.1 Para ambas aplicaciones se deberá tener en cuenta las siguientes características.
13.1.1 Deberán estar disponibles para las plataformas IOS 11.x 12.x y Android 8.x Oreo, 9.x Pie. Estas aplicaciones deberán ser creadas en forma nativa para estas plataformas a fin de garantizar el rendimiento adecuado durante su uso diario, evitando demoras posibles. No serán aceptados aquellos que requieran capas intermedias para su ejecución tipo PhoneGap.
13.1.2 Los costos y procesos asociados por la publicación de las mismas en las tiendas de Aplicaciones correrán a cargo del oferente. Deberá realizar el proceso para al menos una tienda.
13.1.3 Para permitir la conexión entre la aplicación móvil y servidor de aplicaciones se deberá proveer un web service con tecnología REST. Por motivos de seguridad y rendimiento, no deberá ser una conexión directa a la base de datos.
13.1.4 El servidor de aplicaciones que proveerá del webservice deberá disponer de autenticación de las aplicaciones móviles identificando el usuario registrado.
13.1.5 Los datos enviados y recibidos entre la aplicación móvil y servidor de aplicación deberá ser encriptado y comprimido para garantizar confiabilidad y un menor uso de recursos de ancho de banda.
13.1.6 El servidor que responderá las consultas de las aplicaciones móviles deberá desplegarse mediante servicios, no requiriendo de esta manera iniciar manualmente la aplicación. Deberá disponer de un log o registro del servicio.
13.2 Funcionalidades comunes.
13.2.1 Deberán tener una opción para recuperar Contraseña o PIN mediante correo electrónico.
13.3 Aplicación de teléfonos inteligentes para el funcionario de la institución.
13.3.1 Deberá permitir la consulta de la Ultima Liquidación
13.3.2 Deberá disponer de consulta de liquidaciones de periodos anteriores
13.3.3 Deberá permitir la consulta de legajo del funcionario
13.3.4 Deberá permitir la consulta de marcaciones de relojes biométricos
13.4 Aplicación de teléfonos inteligentes para el usuario del área de Recursos Humanos, tales como Jefes y Directores. Esta App deberá ayudar a estos funcionarios en la toma decisiones de los Recursos Humanos en base a consultas aun cuando no se encuentren en sus oficinas, y solo tengan acceso a sus teléfonos móviles.
13.4.1 Esta aplicación deberá contener consultas de datos del personal, fotografía del legajo, teléfono, dirección y datos de contacto, y vínculos disponibles, así como el detalle del vínculo, como lugar de trabajo, con su detalle de horario, asignación del salario, rubro, objeto de gastos entre otros.
13.4.2 Deberá disponer el detalle del legajo, movimiento e historial laboral de personal, así como la descarga de documentos de legajos en formato PDF, esto deberá permitir a los usuarios de esta aplicación utilizarlo como una extensión de la plataforma cuando se encuentre alejado del ordenador.
13.4.3 Deberá permitir la consulta de asistencias de un personal.
13.4.4 Deberá permitir la capturar una fotografía, y asociarlo a un legajo, actualizando el mismo en la plataforma de Recursos Humanos.
13.4.4.1 El sistema deberá validar la existencia de una fotografía valida al momento de subir la misma mediante la aplicación, utilizando algún algoritmo de reconocimiento facial.
13.4.4.2 En caso que la fotografía tenga una foto de cuerpo entero o área mayor, deberá realizar un recorte automático del rostro y adjuntarlo al módulo de legajos del sistema de Recursos Humanos.
13.4.4.3 Opcionalmente deberá disponer para su utilización de la funcionalidad de Chroma Key o Telón verde, partiendo de esta manera limpiar el fondo de las fotos tomadas con un telón o cartulina verde utilizada en el proceso de captura de actualización de fotografías.
14. Aplicación para terminal de autoservicio Módulo a ser Incorporado
14.1 Se deberá proveer de una aplicación de escritorio autónomo para ser instalado en terminales de consultas, cuya función será de la de consultas de salarios, e impresión de comprobantes de liquidación, destinado a aquellos funcionarios que no dispongan de teléfonos inteligentes, o no tengan impresoras para efecto.
14.2 Las terminales de auto consulta podrán ubicarse en las oficinas Regionales u oficinas administrativas, para permitir a aquellos funcionarios que no tienen acceso a teléfonos de alta gama la impresión de sus comprobantes de liquidación de salario.
14.3 Tanto para el uso de la aplicación de autoservicio, como sus homólogos Web y Terminal podrán ser utilizados con el Número de Documento del Personal y un PIN.
14.4 El sistema de Legajos deberá disponer una función de Impresión de recibo de entrega de PIN.
14.5 Se deberá proveer una aplicación para terminales de auto consulta para Windows de 32 y 64 bits.
14.6 Estas terminales podrán tener pantalla touch, por ende la pantalla y botones de la misma deberán ser ajustadas automáticamente a la resolución máxima de la misma y deberán bloquear otras operaciones del sistema operativo.
14.7 Deberá permitir imprimir el comprobante mediante la impresora conectada a la terminal. Las impresoras podrán ser estándares de oficina, o de tickets tipo matricial o térmica.
14.8 Deberá permitir limitar la cantidad de impresión de comprobantes, por ejemplo (los 2 últimos meses de liquidación de salarios), evitando el malgasto de papeles y tintas. (En caso que el funcionario desee imprimir copias adicionales o meses anteriores podrá hacerlo mediante la web, en su impresora personal o cualquier otro sitio de impresión para el público).
14.9 Para permitir la conexión entre la aplicación de la terminal de consulta y servidor de aplicaciones se deberá proveer un web service con tecnología REST. Por motivos de seguridad y rendimiento, no deberá ser una conexión directa a la base de datos.
14.10 Los datos enviados y recibidos entre la aplicación de terminal de autoservicio y servidor de aplicación deberán ser encriptado y comprimido para garantizar confiabilidad y un menor uso de recursos de ancho de banda.
14.11 Adicionalmente deberá disponer de un mecanismo de actualización automática en caso que existan nuevas versiones, sin requerir la asistencia de personal técnico para dicho efecto, o minimizar este requerimiento.
15 Aplicación web de autoservicio Módulo a ser Incorporado
Se deberá proporcionar una aplicación para el funcionario, este deberá proporcionar servicios a los funcionarios minimizando la necesidad de concurrir a la Dirección de Recursos Humanos para realizar consultas o tramites.
15.1 Deberá permitir realizar:
15.1.1 Consulta de la Última Liquidación. El detalle deberá contener el Objeto de Gastos del Ingreso asociado, así como los descuentos de los mismos. Por Ejemplo 111- Salario de Permanente, Descuentos de Aportes Jubilatorios, Descuentos de asociaciones, cooperativas y descuentos judiciales.
15.1.2 Consulta de liquidaciones de periodos anteriores, imprimir o descargar en formato PDF del histórico de salarios de meses anteriores, esto deberá minimizar la necesidad de concurrir los funcionarios a la institución para generar estos comprobantes. Por ejemplo, Impresión del histórico de los últimos 12 meses que podrían ser utilizados para la presentación de las declaraciones del Impuesto a la Renta Personal.
15.1.3 Imprimir o descargar en formato PDF del extracto de Descuentos Judiciales en casos que los tuviere.
15.1.4 Consulta de legajo del funcionario
15.1.4.1 Deberá permitir la descarga de los archivos adjuntos en PDF.
15.2 Deberá disponer de la funcionalidad de recuperación de PIN, en caso de olvido del mismo, enviando un nuevo PIN vía correo electrónico.
15.2.1 Al solicitar el nuevo PIN deberá solicitar un captcha.
15.3 Cambiar el PIN a uno personalizado por el usuario.
16 Portal de trámites del personal Módulo a ser Incorporado
16.1 Esta aplicación está desplegada en modo servicio que permite realizar trámites, o pre-procesar trámites relacionados al personal.
16.2 Esta aplicación deberá tener limitación de acceso a datos solo a dicha dependencia y sólo a algunas tareas específicas, respecto al sistema principal de Recursos Humanos. Por ejemplo, un usuario de esta aplicación con Perfil de acceso a datos de la Dirección de Administración y Finanzas, no podrá realizar trámites o consultar datos de funcionarios de la Secretaria General, y viceversa de la misma manera.
16.3 Las tareas y opciones se limitarán al usuario, al rol de la dependencia. El rol de la dependencia corresponderá al Organigrama de la institución. Estas funcionalidades deberán minimizar la necesidad de concurrir los funcionarios afectados a la oficina central de la institución, permitiendo realizar los trámites frecuentes y estandarizados en las oficinas administrativas de sus lugares de trabajo.
16.4 Se podrán generar los siguientes tramites:
16.4.1 Consulta (sólo lectura) del perfil del legajo
16.4.2 Consulta (sólo lectura) de documentos del legajo
16.4.3 Actualización de datos personales limitados a campos adicionales que no tengan directa relación con pagos.
16.4.4 Actualización de dirección particular
16.4.5 Actualización de teléfonos (fijos y celulares)
16.5 En todos los casos se deberá generar un histórico en el sistema principal de Recursos Humanos para su consulta.
16.5.1 Cambio de horario
16.5.2 Preimpreso de planillas de asistencias estandarizada
16.5.3 Impresión de formularios de evaluación del personal
16.5.4 Solicitud de corrección de antigüedad, permitiendo este último adjuntar comprobantes escaneados (ejemplo Decreto de Nombramiento), para los casos de carga errónea del legajo.
16.5.5 Constancia de evaluación del personal, para el uso del mismo en concursos públicos.
16.5.6 Impresión de copias de certificados de trabajo estandarizado
16.5.7 Actualización de fotografía. El sistema deberá validar la existencia de una fotografía valida al momento de subir la misma mediante el portal, utilizando algún mecanismo de reconocimiento facial.
16.5.7.1 En caso que la fotografía tenga una foto de cuerpo entero o área mayor, deberá realizar un recorte automático del rostro y adjuntarlo al módulo de legajos del sistema de Recursos Humanos.
16.5.7.2 Opcionalmente deberá disponer para su utilización de la funcionalidad de Chroma Key o Telon verde, pudiendo de esta manera limpiar el fondo de las fotos tomadas con un telón o cartulina verde utilizada en el proceso de captura de actualización de fotografías.
16.6 Deberá disponer de una sección para la publicación de formularios estándares o planillas utilizadas en la institución, o emitidas por otras instituciones para su llenado.
16.7 Deberá disponer de una sección para la publicación de normativas y regulaciones asociadas a la tarea de Recursos Humanos.
16.7.1 Por ejemplo, publicación de normativa (en formato PDF) para pagos de horas extras.
16.8 Deberá permitir la consulta de solicitudes realizadas y el estado de la misma. Por ejemplo, solicitud de corrección o actualización de antigüedad, fecha de proceso, motivo de aprobación o rechazo del mismo.
16.69 Deberá permitir cambiar la contraseña a una personalizada por el usuario e imprimir un perfil del usuario para conocer los permisos concedidos.
16.10 Deberá disponer de un formulario estándar para el registro de nuevos usuarios en la plataforma.
16.11 Al realizar un registro del usuario, el sistema deberá enviar al usuario un correo eléctrico de bienvenida en forma automática.
16.12 Esta aplicación web deberá ser del tipo Responsive, se entiende por este último que tratará de redimensionar y colocar los elementos del sistema web de tal forma que se adapten a cada dispositivo permitiendo una correcta visualización, considerando que las distintas oficinas Regionales, oficinas administrativas tienen en su conjunto pantallas y resoluciones de las mismas muy heterogéneas.
17 Firma digital Módulo a ser Incorporado
El creciente uso de las firmas digitales en los distintos procesos del gobierno paraguayo (implementación de políticas de cero papel), y las entidades privadas (simplificación y rapidez en procesos), obliga también a la institución a adecuar y facilitar los sistemas informáticos para dicha tarea.
17.1 El sistema deberá permitir agregar dicha funcionalidad para la emisión de reportes, y en un proceso final de manera opcional permitir al usuario firmar digitalmente.
17.2 El componente de clave pública podrá ser almacenada en los servidores y podrá ser utilizado para mostrar los datos del firmante de los documentos.
17.3 El componente de la clave privada no deberá ser almacenada en el servidor, y el mismo solo lo tendrá acceso el propietario de la firma, que podrá mantenerlo almacenado en la forma más conveniente que decida.
17.4 Se deberá disponer de algunos reportes o formularios seleccionados que podrán ser firmados digitalmente o emitidos como reporte común, por ejemplo.
17.5 Reporte de contratos, el usuario podrá seleccionar firmar digitalmente, con lo cual se generará un archivo en PDF y se les solicitará a los usuarios los parámetros de clave privada cuyo conocimiento solo deberá tenerlo el mismo.
17.6 Parámetros tales como certificador o plantillas predefinidas para la firma digital podrán ser almacenadas y desplegadas durante este proceso.
17.7 Al ser un proceso nuevo se deberá disponer de especial cuidado en el diseño de la interfaz de usuario, agregando alertas, e indicadores para los usuarios, todo esto considerando que de acuerdo la legislación local tiene validez
17.8 Ley Nº 4017 / De validez jurídica de la Firma Electrónica, la Firma Digital, los mensajes de datos y el Expediente Electrónico
17.9 Ley N°4610 "Que modifica y amplía la Ley N° 4017/10 "De validez jurídica de la firma electrónica, la firma digital, los mensajes de datos y el Expediente Electrónico"
17.10 Decreto N°7369 "Por el cual se aprueba el Reglamento General de la ley n°4017 "De validez Jurídica de la Firma electrónica, la Firma digital, Los mensajes de datos y el Expediente Electrónico.
17.11 Resolución N°1430/2013 Por la cual se aprueba y pone en vigencia la Política de Certificación de la Infraestructura de Clave Pública del Paraguay. Se deja sin efecto Resoluciones N° 165/2013 y N°771/2013.
17.12 Resolución N°501/16 Por la cual se aprueba y pone en vigencia la Guía de Estándares Tecnológico y Lineamientos de Seguridad para la Habilitación y Auditoria a Prestadores de Servicios de Certificación.
17.13 Resolución Nº 1562 Por la cual se modifica parcialmente la resolución Nº 1400/2016 de fecha 09 de noviembre de 2016, Que aprueba y pone en vigencia las directivas obligatorias para la formulación y elaboración de la Política de Certificación y Declaración de Prácticas de Certificación de los Prestadores de Servicios de Certificación habilitados en la República del Paraguay.
17.14 Otras resoluciones que reglamenten el funcionamiento de la ley vigente
17.15 Documentos cargados al sistema, que contenga anotaciones o metadatos que puedan ser leídos mediante estándares de firma digital, cuya visualización será mostrada en el sistema con un elemento o icono distintito de firma digital.
18 Servicios vinculados a proveer
18.1 Soporte técnico por 12 (doce) meses.
18.2 Capacitación.
18.3 Migración de datos de fuentes externas.
18.4 Actualización de Manuales
19 Entrega de la Actualización
19.1 La actualización del Sistema debe ser entregado en un dispositivo óptico en un plazo no mayor a 7 días posterior a la firma del contrato y/o recepción de la Orden de Compra, y se realizará la recepción del sistema acta mediante.
19.2 Una vez recibido el sistema en el dispositivo óptico se procederá a instalar el mismo tanto en el servidor y en las estaciones de trabajo de la Institución según corresponda con la coordinación de la Dirección de Recursos Humanos.
En cuanto al los patrimonios activos fijos cumple con la función de realizar un inventario permanente y actualizado de los bienes de uso, permite consultar y generar reportes de la situación actual de los bienes y sus correspondientes movimientos y en cuanto a la actualización del sistema integrado de RRHH del ministerio de justicia nos permitir optimizar el sistema ingresado de RRHH con que cuenta la Institución, obteniendo mejoras de los modelos ya existentes y la incorporación de nuevos módulos que nos permita un mayor y mejor control de los RRHH de la institución y facilitar de la DGRH permitiendo la selección de los recurso humanos de la institución par ocupar cargos y ausmír responsabilidades de acuerdo a su perfil, evitando la subutilización de los mismo.
estre llamado es de caracter periódico
REMITIDAD POR EL DEPARTAMENTO DE PATRIMONIO Y DIRECCION GENERAL DE TALENTO HUMANO
La entrega de los bienes se realizará de acuerdo al plan de entrega y cronograma de cumplimiento, indicado en el presente apartado. Así mismo, de los documentos de embarque y otros que deberá suministrar el proveedor indicado a continuación:
| LOTE | DESCRIPCION DEL BIEN - SERVICIO | PLAZO DE ENTREGA | LUGAR DE ENTREGA |
| 1 | SERVICIOS DE ACTUALIZACION DEL SISTEMA INTEGRADO DE RECURSOS HUMANOS (SIRH) |
La actualización del sistema bebe ser entregado en un dispositivo óptico en plazo de no mayor a 7 (Siete) días posterior a la firma del contrato y/o recepción de la orden de compra, y se realizara la recepción del sistema acta mediante. Una vez recibida el sistema en el dispositivo óptico se procederá a instalar el mismo tanto en el servidor y en la estaciones de trabajo de la institución según corresponda con la coordinación de la Dirección de Recursos Humanos |
Dirección General de Talento Humano Calle Rodríguez de Francia esq. Estados Unidos- Asunción, Primer Piso, Dirección General de Talento Humano - de Lunes a Viernes de 08:00 a 15:00hs. |
| 2 | SERVICIOS DE ACTUALIZACION DEL SISTEMA INTEGRADO ACTIVO FIJO (SICAF) | 15 (siete) días a partir de la recepción de la Orden de Compra se deberá entregar en medio óptico. | Departamento de Patrimonio Calle Estados Unidos entre Rodríguez de Francia y República de Colombia Asunción de lunes a viernes en en horario de 08:00 a 15:00 hs. |
(NO APLICA)
Para la presente contratación se pone a disposición los siguientes planos o diseños:
No aplica
El embalaje, la identificación y la documentación dentro y fuera de los paquetes serán como se indican a continuación:
No aplica
Las inspecciones y pruebas serán como se indica a continuación:
No aplica
El documento requerido para acreditar el cumplimiento contractual, será:
Planificación de indicadores de cumplimiento:
|
INDICADOR |
TIPO |
FECHA DE PRESENTACIÓN PREVISTA (se indica la fecha que debe presentar según el PBC) |
|
Nota de Remisión / Acta de recepción 1 |
Nota de Remisión / Acta de recepción |
DICIEMBRE 2022 |
De manera a establecer indicadores de cumplimiento, a través del sistema de seguimiento de contratos, la convocante deberá determinar el tipo de documento que acredite el efectivo cumplimiento de la ejecución del contrato, así como planificar la cantidad de indicadores que deberán ser presentados durante la ejecución. Por lo tanto, la convocante en este apartado y de acuerdo al tipo de contratación de que se trate, deberá indicar el documento a ser comunicado a través del módulo de Seguimiento de Contratos y la cantidad de los mismos.
La convocante adjudicará el contrato al oferente cuya oferta haya sido evaluada como la más baja y cumpla sustancialmente con los requisitos de las bases y condiciones, siempre y cuando la convocante determine que el oferente está calificado para ejecutar el contrato satisfactoriamente.
1. La adjudicación en los procesos de contratación en los cuales se aplique la modalidad de contrato abierto, se efectuará por las cantidades o montos máximos solicitados en el llamado, sin que ello implique obligación de la convocante de requerir la provisión de esa cantidad o monto durante de la vigencia del contrato, obligándose sí respecto de las cantidades o montos mínimos establecidos.
2. En caso de que la convocante no haya adquirido la cantidad o monto mínimo establecido, deberá consultar al proveedor si desea ampliarlo para el siguiente ejercicio fiscal, hasta cumplir el mínimo.
3. Al momento de adjudicar el contrato, la convocante se reserva el derecho a disminuir la cantidad de Bienes requeridos, por razones de disponibilidad presupuestaria u otras razones debidamente justificadas. Estas variaciones no podrán alterar los precios unitarios u otros términos y condiciones de la oferta y de los documentos de la licitación.
En aquellos llamados en los cuales se aplique la modalidad de contrato abierto, cuando la Convocante deba disminuir cantidades o montos a ser adjudicados, no podrá modificar el monto o las cantidades mínimas establecidas en las bases de la contratación.
La comunicación de la adjudicación a los oferentes será como sigue:
1. Dentro de los cinco (5) días corridos de haberse resuelto la adjudicación, la convocante comunicará a través del Sistema de Información de Contrataciones Públicas, copia del informe de evaluación y del acto administrativo de adjudicación, los cuales serán puestos a disposición pública en el referido sistema. Adicionalmente el sistema generará una notificación a los oferentes por los medios remotos de comunicación electrónica pertinentes, la cual será reglamentada por la DNCP.
2. En sustitución de la notificación a través del Sistema de Información de Contrataciones Públicas, las convocantes podrán dar a conocer la adjudicación por cédula de notificación a cada uno de los oferentes, acompañados de la copia íntegra del acto administrativo y del informe de evaluación. La no entrega del informe en ocasión de la notificación, suspende el plazo para formular protestas hasta tanto la convocante haga entrega de dicha copia al oferente solicitante.
3. En caso de la convocante opte por la notificación física a los oferentes participantes, deberá realizarse únicamente con el acuse de recibo y en el mismo con expresa mención de haber recibido el informe de evaluación y la resolución de adjudicación.
4. Las cancelaciones o declaraciones desiertas deberán ser notificadas a todos los oferentes, según el procedimiento indicado precedentemente.
5. Las notificaciones realizadas en virtud al contrato, deberán ser por escrito y dirigirse a la dirección indicada en el contrato.
Una vez notificado el resultado del proceso, el oferente tendrá la facultad de solicitar una audiencia a fin de que la convocante explique los fundamentos que motivan su decisión.
La solicitud de audiencia informativa no suspenderá ni interrumpirá el plazo para la interposición de protestas.
La misma deberá ser solicitada dentro de los dos (2) días hábiles siguientes en que el oferente haya tomado conocimiento de los términos del Informe de Evaluación de Ofertas.
La convocante deberá dar respuesta a dicha solicitud dentro de los dos (2) días hábiles de haberla recibido y realizar la audiencia en un plazo que no exceda de dos (2) días hábiles siguientes a la fecha de respuesta al oferente.
Luego de la notificación de adjudicación, el proveedor deberá presentar en el plazo establecido en las reglamentaciones vigentes, los documentos indicados en el presente apartado.
|
|
|
|
|
|
|
|
2. Documentos. Consorcios |
|
|
|
|