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:
El sistema solicitado es una herramienta que permitirá gestionar y optimizar el Recurso Humano que posee la institución, requiriéndose las funcionalidades más abajo detalladas. La oferta técnica deberá recomendar los requisitos técnicos mínimos en cuanto a hardware, sistemas operativos, servidores y estaciones de trabajos requeridos para el funcionamiento del sistema, así como de la infraestructura técnica a utilizar.
A continuación, se listan unos objetivos deseados a lograr con la implementación de este proyecto.
2.2.1. 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
2.2.2. 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.3. 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.4. 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.5. Ley 1626 De la Función Pública.
2.2.6. Ley Nº 1535/99 De Administración Financiera del Estado.
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 Directory en producción para la validación de usuarios.
3.2. Auditable, 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.4.3. 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.
VER ANEXO - IMAGENES.
3.10. Escalabilidad y estabilidad
3.10.1. Los 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.4.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.
5. Plataforma Requerida
5.1. El sistema deberá estar desarrollado con algunas características técnicas solicitadas.
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.1. Legajos del funcionario
7.1.1. Datos 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.1. En caso de teléfonos deberá permitir registrar varios, (más de un celular, teléfonos fijos adicionales).
7.1.1.2. En 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.3. Deberá 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. Actualización de fotografía. El sistema deberá validar la existencia de una fotografía valida al momento de subir la misma mediante algunas de las aplicaciones, utilizando mecanismo de reconocimiento facial.
7.1.1.4.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.
7.1.1.4.2. Opcionalmente 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.2. Datos del grupo familiar del funcionario.
7.1.2.1. El 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.3. Estudios y formación académica del funcionario
7.1.4. El 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.5. Historial laboral de los funcionarios previos a su contrato o nombramiento dentro de la institución.
7.1.6. Historial de categorías, bonificaciones y autorizaciones de descuentos, así como también la definición de cargo y línea presupuestaria.
7.1.7. Datos de profesión
7.1.8. Buscadores, 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.1. Las búsquedas por el campo de Nombres y Apellidos deberán poder realizarse como búsquedas parciales y en cualquier orden.
7.2. Historial 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.3. Deberá 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.1. Deberá 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.4. El 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.5. El sistema deberá identificar a los funcionarios permanentes, contratados, comisionados, matriciados y acuerdo a eso aplicar distintos reportes.
7.6. Reportes a emitir en base a datos de legajos
7.6.1. Reporte del Perfil de funcionario
7.6.2. Reporte de Ficha del funcionario
7.7. Documentos 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.8. Documentos 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.1. Deberá 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.2. En 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.9. Reportes de legajos
7.9.1. Reportes de personal por organigrama (todos o solo alguna seleccionada)
7.9.1.1. Ordenados por Número de Documento, Apellidos.
7.9.1.2. Filtrado por Tipo de Vínculo (Ejemplo Permanente, Contratado).
7.9.1.3. Filtrado por Objeto de Gasto (Ejemplo 141, 142, 143).
7.9.2. Reportes de personal con fotografía
7.9.3. Reporte de alertas de datos de legajos
7.9.3.1. Se deberá incluir un reporte que permita alertas de los datos faltantes, con el fin de actualizar el legajo, por ejemplo:
7.9.3.1.1. Personal sin datos de Horarios establecidos
7.9.3.1.2. Personal sin datos de teléfono o dirección
7.9.3.1.3. Personal sin Huella capturada
7.9.3.1.4. Personal sin Carga Horaria definida
7.9.3.1.5. Personal sin Fotografía capturada
7.9.4. Se deberá incluir la posibilidad de impresión de un formulario para la actualización de legajos.
7.9.5. Deberá incluir consultas y generación de reportes, con diversos filtros tales como
7.9.5.1. Tipos de vínculos
7.9.5.2. Estado
7.9.5.3. Cargo / Función
7.9.5.4. Categoría
7.9.5.5. Ubicación / Organigrama.
7.10. Emisión de documentos
7.10.1. Impresió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.1. Al emitir la credencial, adicionalmente deberá desplegar datos de credenciales o carnet previamente impresos a modo de consultas.
7.10.2. Constancia laboral.
7.10.2.1. El 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.2. La constancia de trabajo deberá incluir datos de la antigüedad, situación, tipo de vínculo, y demás datos personales.
7.10.3. Certificado 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.2. El 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.3. Se deberá incluir un formato estandarizado sugerido por la Secretaría de la Función Pública.
7.10.4. Contratos del personal
7.10.4.1. El sistema deberá permitir la generación e impresión de contratos de trabajo, emitidos con los datos del personal.
7.10.4.2. Los contratos podrán imprimirse de manera individual o por lotes.
7.10.4.2.1. En 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.5. Recepció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.11. Carga masiva de datos
7.11.1. El sistema deberá disponer de mecanismo para carga masiva de datos, utilizados para actualizar los datos o como relevamientos de datos del personal.
7.11.2. Se 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.3. Una vez importado y validado deberá actualizar el legajo del personal, y emitir un informe correspondiente a dicha tarea.
7.11.4. Actualizació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.1. Para 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.2. Solicitudes 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.2. Esta funcionalidad deberá permitir disponer siempre de un organigrama actualizado.
8.10.3. El organigrama deberá poder imprimirse y exportarse a programas ofimáticos.
8.10.4. El organigrama deberá poder visualizarse tanto de modo vertical y horizontal, deberá poder realizarse zoom sobre el mismo.
8.10.5. Deberá permitir disponer de nodos al menos en (Elipse, Rectángulo, rectángulo redondeado, o rombo).
8.10.6. Cada 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
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óviles.
9.1. Captura de huellas.
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 administrado por el sistema.
9.1.2. En caso de capturas mediante escáneres de huella, el sistema deberá guardar el archivo original de huella, adicional a la plantilla específica 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 sistema de actualización de aplicaciones.
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 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.5. Deberá permitir la descarga o sincronización de datos de
9.5.5.1. Un solo funcionario
9.5.5.2. Un organigrama o una dependencia
9.5.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.5. Deberá 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.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.7. Llegadas 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
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.1. Con esta información deberá permitir controlar la cantidad de cargos ocupados y vacantes.
10.1.2. Deberá permitir conocer el saldo presupuestario por cada unidad jerárquica.
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.1. Sueldos (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.22. 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.3. Caratula / Oficio
10.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.6. 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.7.15.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.21. Filtros 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
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.2. Personal 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 TXT y/o 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
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.3. Al 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.1.5. Préstamos del Personal: módulo de Préstamos de Petropar al Personal, que contemple altas, bajas y modificaciones de préstamos ordinarios y extraordinarios o de otro tipo, listados, facturación y generación de libro IVA y emisión de informes correspondientes. El módulo de préstamos deberá contemplar el sistema de amortización francés.
12.1.6. Transporte del Personal: control de la marcación de entrada y salida de choferes en reloj biométrico de portería y emisión de informes correspondientes.
12.1.7. Servicio de Comedor: módulo de control de acceso de funcionarios al comedor, debiendo validar con su entrada registrada en el reloj biométrico de portería (para casos de vacaciones). Emisión de informes correspondientes.
12.1.8. Distribución de Leche al Personal: de acuerdo a los días trabajados según marcación en el reloj biométrico de portería. Emisión de informes correspondientes.
12.1.9. Distribución de Uniformes del Personal: registro de talle de todos los funcionarios clasificados según sus funciones en operativos y administrativos y por Gerencia/Dirección. Emisión de informes correspondientes.
12.1.10. Servicio de Odontología: registro de funcionarios que realizaron consultas y del trabajo realizado. Emisión de informes correspondientes.
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. 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
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 12.x y Android 10.x. 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.
14. Aplicación para terminal de autoservicio.
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
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
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.9. 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. 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 para el uso del sistema. (El costo incluye la implementación y capacitación por 12 Meses para lo cual se requiere la presencia de 2 capacitadores, conforme al cronograma presentado por el proveedor y aprobado por la Convocante. La Convocante podrá modificar este cronograma según lo requiera)
18.3. Migración de datos de fuentes externas.
18.3.1. La migración deberá constar la cantidad de registros en origen y al finalizar este proceso se deberá cuantificar la cantidad de registros migrados.
18.3.2. Durante el proceso de migración se podrá incluir procesos de validaciones de datos por ejemplo (enunciativo y no limitativo), fecha de nombramiento es anterior o posterior al cálculo de antigüedad en la institución
18.4. Servidor de manuales en línea
18.4.1. Se requerirá el desarrollo de una aplicación para proveer ayuda en línea.
18.4.2. Esta aplicación en modalidad de servicio se encargará de mantener una versión web de los manuales de los sistemas, estos manuales pueden ser consultados en línea, y el contenido de los mismos son del tipo Responsive, es decir se adapta al dispositivo desde cual se realiza la lectura, ya sean ordenadores de escritorio, celulares o tablets.
18.4.3. Debido a lo voluminoso de los manuales, estos son provistos en títulos y capítulos, orientados a cada módulo y sub-módulos correspondiente, este provee un buscador en línea de forma que el usuario encuentre la sección de la ayuda en forma simple, sin requerir desplazarse por todo el manual.
19. Entrega e instalación del sistema
19.1. El Sistema informático 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.
20. Interfaz con el sistema Integrado de Gestión Financiera SAP
20.1. Generación de pre asientos contables automáticos en el sistema SAP.
Inspecciones y Pruebas en la etapa de evaluación
La Convocante, a través de su Comité de Evaluación, solicitará una demostración del software ofertado a efectos de corroborar el cumplimiento cabal de las especificaciones técnicas solicitadas y en la plataforma de desarrollo requerida. Este requisito será de carácter sustancial y obligatorio.
Nombre: Lic. Pedro Fretes.
Cargo: Director
Dependencia: Dirección de Tecnología de la Información (DTI).
La actualización de los sistemas es fundamental, hoy no tener información precisa en el momento oportuno es un fracaso, en este proyecto prevemos un software que nos ayude a ejecutar la nomina del personal, expedir ticket de salarios, marcaciones, evaluaciones del personal, será un sistema integrado de Administración y Gestión de Recursos Humanos.
Está planificado de la siguiente forma:
a- Instalación, configuración del sistema e inicio de capacitación: 60 días posteriores a la recepción de la primera orden de Suministro por parte del proveedor (pago 30 días posterior al acta provisoria).
b- Entrega de manuales de usuario y carta de garantía: 30 días posterior a la recepción de la segunda orden de suministro por parte del proveedor, (pago 30 días posterior al acta provisoria).
c- Culminación de implementación y capacitación: 12 meses posteriores de la recepción de la primera Orden de Suministro por parte del proveedor (informe y acta de recepción).
Las especificaciones técnicas fueron elaboradas en función a las necesidades de PETROPAR, en lo que respecta a la gestión de los recursos humanos (liquidación de salarios, marcaciones, evaluación del personal, legajo del personal, entre otros.), todos estos procesos enmarcados a la ley 1626/2000.
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:
|
Ítem |
Descripción del bien |
Cantidad |
Unidad de medida |
Lugar de entrega de los bienes |
Fecha(s) final(es) de entrega de los bienes |
|
1 |
Sistema de gestión y optimización de recursos humanos |
1 |
Unidad |
Planta de PETROPAR en la ciudad de Villa Elisa ubicada en la Avda. Defensores del Chaco y Américo Picco |
Instalación, configuración del sistema e inicio de capacitación: 60 (sesenta) días posteriores a la recepción de la primera orden de suministro por parte del proveedor |
|
Ítem |
Descripción del servicio |
Cantidad |
Unidad de medida de los servicios |
Lugar donde los servicios serán prestados |
Fecha(s) final(es) de ejecución de los servicios |
|
1 |
Sistema de gestión y optimización de recursos humanos |
1 |
Undad |
Planta de PETROPAR en la ciudad de Villa Elisa ubicada en la Avda. Defensores del Chaco y Américo Picco |
|
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:
La Convocante, a través de su Comité de Evaluación, solicitará una demostración del software ofertado a efectos de corroborar el cumplimiento cabal de las especificaciones técnicas solicitadas y en la plataforma de desarrollo requerida.
1. El proveedor realizará todas las pruebas y/o inspecciones de los Bienes, por su cuenta y sin costo alguno para la contratante.
2. Las inspecciones y pruebas podrán realizarse en las instalaciones del Proveedor o de sus subcontratistas, en el lugar de entrega y/o en el lugar de destino final de entrega de los bienes, o en otro lugar en este apartado.
Cuando dichas inspecciones o pruebas sean realizadas en recintos del Proveedor o de sus subcontratistas se le proporcionarán a los inspectores todas las facilidades y asistencia razonables, incluso el acceso a los planos y datos sobre producción, sin cargo alguno para la Contratante.
3. La Contratante o su representante designado tendrá derecho a presenciar las pruebas y/o inspecciones mencionadas en la cláusula anterior, siempre y cuando éste asuma todos los costos y gastos que ocasione su participación, incluyendo gastos de viaje, alojamiento y alimentación.
4. Cuando el proveedor esté listo para realizar dichas pruebas e inspecciones, notificará oportunamente a la contratante indicándole el lugar y la hora. El proveedor obtendrá de una tercera parte, si corresponde, o del fabricante cualquier permiso o consentimiento necesario para permitir a la contratante o a su representante designado presenciar las pruebas o inspecciones.
5. La Contratante podrá requerirle al proveedor que realice algunas pruebas y/o inspecciones que no están requeridas en el contrato, pero que considere necesarias para verificar que las características y funcionamiento de los bienes cumplan con los códigos de las especificaciones técnicas y normas establecidas en el contrato. Los costos adicionales razonables que incurra el Proveedor por dichas pruebas e inspecciones serán sumados al precio del contrato, en cuyo caso la contratante deberá justificar a través de un dictamen fundado en el interés público comprometido. Asimismo, si dichas pruebas y/o inspecciones impidieran el avance de la fabricación y/o el desempeño de otras obligaciones del proveedor bajo el Contrato, deberán realizarse los ajustes correspondientes a las Fechas de Entrega y de Cumplimiento y de las otras obligaciones afectadas.
6. El proveedor presentará a la contratante un informe de los resultados de dichas pruebas y/o inspecciones.
7. La contratante podrá rechazar algunos de los bienes o componentes de ellos que no pasen las pruebas o inspecciones o que no se ajusten a las especificaciones. El proveedor tendrá que rectificar o reemplazar dichos bienes o componentes rechazados o hacer las modificaciones necesarias para cumplir con las especificaciones sin ningún costo para la contratante. Asimismo, tendrá que repetir las pruebas o inspecciones, sin ningún costo para la contratante, una vez que notifique a la contratante.
8. El proveedor acepta que ni la realización de pruebas o inspecciones de los bienes o de parte de ellos, ni la presencia de la contratante o de su representante, ni la emisión de informes, lo eximirán de las garantías u otras obligaciones en virtud del contrato.
El documento requerido para acreditar el cumplimiento contractual, será:
Planificación de indicadores de cumplimiento:
|
INDICADOR |
TIPO |
FECHA DE PRESENTACIÓN PREVISTA |
|
Acta de recepción provisoria 1 |
Acta de recepción provisoria 1 (Plan de trabajo - Hito, instalación y activación de licencias del Software de Gestión de RRHH - Informe) |
a los 60 (sesenta) días posteriores a la recepción de la primera orden de suministro emitida por el administrador del contrato. |
| Acta de recepción provisoria 2 / Informe. |
Acta de recepción provisoria 2 / Informe. |
a los 30 (treinta) días posteriores a la recepción de la segunda orden de suministro emitida por el administrador del contrato. |
|
Acta de recepción definitiva / Informe. |
Acta de recepción definitiva / Informe Final. |
a los 12 (doce) meses posteriores a la recepción de la segunda orden de suministro emitida por el administrador del contrato. |
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 |
|
|
|
|