Suministros y Especificaciones técnicas

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 serán suministrados por el Proveedor como si hubiesen sido expresamente mencionados, salvo disposición contraria en el Contrato.

Los bienes 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.

Detalle de los productos con las respectivas especificaciones técnicas

Los productos a ser requeridos cuentan con las siguientes especificaciones técnicas:

  1. Especificaciones Técnicas

 

DETALLE DE LOS PROCESOS DEL SISTEMA REQUERIDO

 

En el presente documento se describe las funcionalidades específicas del sistema requerido. No obstante, los sistemas cotizados no son sistemas cerrados, se podrá seguir incorporando los reportes que sean necesarios para el cumplimiento de las necesidades de la dependencia y de la institución, siempre y cuando estos se encuentren dentro de los procesos y/o funcionalidades citados dentro de las siguientes especificaciones.

Listado de sistemas que forman parte del presente documento de especificaciones de procesos:

    1. Gestión del personal

        DESCRIPCIÓN GENERAL

El módulo de Recursos Humanos debe encargarse de la gestión completa de los funcionarios nombrados

y contratados dentro de la institución.

Las funciones generales que debe cumplir son:

  • Carga del organigrama institucional en modo de árbol.
  • Datos generales de funcionarios
  • Asignación de línea presupuestaria según su anexo y el historial del mismo
  • Ubicación de trabajo actual dentro del Organigrama y su Historial de cargos y dependencias dentro de la institución.
  • Legajo académico clasificado por tipo de especializaciones y otras características que ayuden a una pre- selección en caso de concurso interno.
  • Administración de documentos personales digitalizados (CI, RUC, Pasaporte, Registro, Antecedentes etc.)
  • Administración de permisos
  • Marcación de entrada y salida de funcionarios
  • Administración de vacaciones
  • Generación de la nómina para el pago
  • Asignación de 3 niveles para autorización de permisos, con parametrización por tipo de permiso.
  • Incorporación de reglas de negocio para marcación de horario de almuerzo.
  • Registración de funcionarios que no corresponden a la institución y calculo especifico de multas a ser transferidas a la empresa proveedora según sea el caso.
  • Migración de datos de periodos anteriores.
  • Desarrollo de reportes según necesidad conforme a los procesos establecidos dentro de la estructura de base de datos.

Todas las secciones del sistema deben generar reportes que puedan ser filtrados por distintos campos, todos estos reportes deben ser generados en formato pdf, los listados deben contar con la posibilidad de exportarlos a planillas del tipo Excel.

 

El acceso a los datos para para la edición como para consultas debe administrado modularmente y todos los cambios realizados dentro del sistema deben quedar auditados.

LISTADO DE FUNCIONALIDADES Y/O ADMINISTRACIÓN DE DATOS QUE POSEE EL SISTEMA

    • Carga de cargos APN.
    • Cargos Internos.
    • Categorías de funcionarios.
    • Estructura Financiera.
    • Presupuesto del nivel 100 por periodo.
    • Tipo de conocimientos utilizados dentro de la entidad.
    • Administración de Feriados.
    • Tipo de documentos utilizados en la gestión de RRHH.
    • Posibilidad de administrar varias sedes.
    • Registro de relojes biométricos activos.
    • Códigos de funcionario para relojes.
    • Obtención automática de marcaciones del reloj.
    • Marcaciones de funcionarios.
    • Tipo de Permisos con sus reglas correspondientes.
    • Anexo del personal vigente por periodo.
    • Organigrama institucional ramificado en modo de árbol.
    • Carga de datos generales de funcionarios.
    • Resoluciones vinculadas a la gestión de RRHH.
    • Contratos vigentes y no vigentes vinculados a funcionarios.
    • Información académica de los funcionarios.
    • Información del anexo por funcionario.
    • Información de trayectoria por dependencia y cargo.
    • Administración de Remuneraciones Extraordinarias.
    • Administración de Remuneraciones Adicionales.
    • Procesos de generación de beneficios por Antigüedad.
    • Administración de reservas para Aguinaldo.
    • Otros Beneficios.
    • Descuentos.
    • Vacaciones.
    • Emisión de Certificado de Trabajo.
    • Apercibimientos.
    • Multas.
    • Notificaciones.
    • Generación de Nomina.

 

DETALLE DE FUNCIONALIDADES Y/O ADMINISTRACIÓN DE DATOS QUE DEBE POSEER EL SISTEMA

 

CARGA DE CARGOS APN

Cargo de datos de Cargos contemplados en el Anexo del Presupuesto Nacional a fin de vincularlo con anexo correspondiente al periodo.

Datos específicos: Denominación del cargo, Periodo Informes y Reportes:

  • Listado de Cargos por Periodo.
  • Listado de Funcionarios por Cargo.

 

CARGOS INTERNOS

 

Cargo de datos de Cargos internos ocupados dentro de la entidad a fin de vincularlos con el legajo del funcionario.

Datos específicos: Denominación del cargo, Descripción del trabajo. Informes y Reportes:

  • Listado de Cargos Internos por Periodo permitiendo mostrar o no a descripción del trabajo de cada cargo.
  • Listado de Funcionarios por Cargo Interno.

 

 

CATEGORÍAS DE FUNCIONARIOS

Cargo de datos de Categorías disponibles dentro del anexo del personal con todas sus especificaciones correspondientes.

Datos específicos: Código, Valor, Rango de fecha aplicable. Informes y Reportes:

  • Listado de Categorías de Funcionarios vigentes dentro de una fecha establecida.
  • Listado de Funcionarios por Categoría.

 

 

ESTRUCTURA FINANCIERA

Administración de la estructura financiera por Periodo, Tipo de Presupuesto, Programa, Sub-Programa, Proyecto, Producto a fin de vincular el presupuesto con su línea correspondiente.

Datos específicos: Periodo, Tipo de Presupuesto, Programa, Sub-Programa, Proyecto, Producto, Denominación, Afectable al presupuesto si o no.

Informes y Reportes:

  • Listado de estructura financiera por periodo.

 

 

PRESUPUESTO DEL NIVEL 100 POR PERIODO

Carga del presupuesto público asignado al nivel 100 y la de sus eventuales reprogramaciones dejando constancias del presupuesto inicial y actual.

Datos específicos: Periodo, Tipo de Presupuesto, Programa, Sub-Programa, Proyecto, Producto, Objeto del Gasto, Fuente de Financiamiento, Organismo Financiador, Departamento, Monto del presupuesto.

Validaciones específicas:

  • Solo se puede asignar presupuesto a ítems de la estructura que son imputables.
  • Validación de montos mínimos según generación de nóminas ya emitidas.

Informes y Reportes:

  • Listado del presupuesto filtrando por Periodo, TP, PG, SP, PY, PD, OG, FF, OF, DP.
  • Informe de ejecución del presupuesto (Presupuesto menos Nominas ya emitidas)

 

 

TIPO DE CONOCIMIENTOS UTILIZADOS DENTRO DE LA ENTIDAD

Definición de tipo de conocimientos utilizado para la posterior clasificación del legajo académico de los funcionarios. A través de esta clasificación se intenta facilitar la búsqueda de funcionarios de la institución con cierto perfil académico.

Datos específicos: Descripción, Detalle, Nivel Académico. Informes y Reportes:

  • Listado de tipos de conocimientos con cantidad de funcionarios activos dentro de cada grupo, se puede filtrar ítem padre del organigrama y la búsqueda se debe realizar dentro de todos los ítems del organigrama.

 

ADMINISTRACION DE FERIADOS

El sistema deberá poseer en sección de carga de fechas correspondientes a feriados a fin de poder realizar los cálculos de días hábiles cuando así sea necesario.

Datos específicos: Fecha, Motivo del feriado. Informes y Reportes:

  • Listado de feriados dentro de un rango de fecha.

 

 

TIPO DE DOCUMENTOS UTILIZADOS EN LA GESTIÓN DE RRHH

Definición de tipo de documentos utilizados para respaldar situaciones dentro de la gestión de Recursos Humanos, esto se utilizará para su posterior vinculación con los movimientos que requieran un aval documental para ciertos procesos.

Datos específicos: Descripción, Detalle. Informes y Reportes:

  • Listado de tipo de documentos y cantidad utilizada dentro del sistema dentro de sus múltiples tablas/procesos.

 

POSIBILIDAD DE ADMINISTRAR VARIAS SEDES

El sistema debe contar con la posibilidad de administrar varias sedes de la entidad. Todas las secciones del sistema deben actuar bajo el principio de múltiples sedes, pudiendo así generar procesos e informes por sedes.

Datos específicos: Denominación, Departamento, Ciudad, Dirección, Nro. de Teléfono. Informes y Reportes:

  • Listado de sedes de la entidad con sus informaciones correspondientes.
  • Todos los informes del sistema que utilicen datos que se vinculen a sedes deben por ser filtrados por estas sedes.

 

REGISTRO DE RELOJES BIOMÉTRICOS ACTIVOS

Descripción Registro de datos de relojes biométricos activos dentro de la entidad en sus distintas sedes. A través de esta sección se puede tener control total de los equipos a nivel hardware para la realización del control de marcaciones.

Datos específicos: Denominación, Sede, Código, IP, Clave, funcionario responsable, Estado. Informes y Reportes:

  • Listado de relojes con filtro por sede/estado.

 

 

CÓDIGOS DE FUNCIONARIO PARA RELOJES

Administración de códigos por funcionario para cada reloj biométrico. Cada reloj maneja un código único por funcionario, por lo tanto, a través de esta información podemos interpretar la información de los relojes dentro del sistema de RRHH.

Datos específicos: Reloj, funcionario, Estado, Código. Informes y Reportes:

  • Listado de funcionarios por reloj por estado.
  • Listado de funcionarios por reloj mostrando códigos.
  • Listado de relojes activos habilitados por funcionario.

 

 

OBTENCIÓN AUTOMÁTICA DE MARCACIONES DEL RELOJ

El sistema debe obtener de manera automática todos los datos del reloj biométrico. Datos específicos:

  • Reloj.
  • Código de funcionario.
  • Horario de marcación.
  • Horario de importación.

Mecanismos aplicables:

  • Importación de datos del reloj adjuntando el archivo plano generado por el reloj.
  • Importación automática del archivo a través de la red utilizando la IP del reloj.

Trabajos de configuración y desarrollo:

  • Configuración del servidor para la obtención automática de los datos del reloj.
  • Desarrollo de una interfaz de conexión entre el sistema y el reloj. Dicha interfaz podrá variar acorde al modelo del reloj disponible, los lenguajes que se podrán utilizar para el desarrollo de esta interfaz son JAVA o PYTHON.

Validaciones:

  • Se debe validar que no se inserte más de una vez el mismo registro de marcación.
  • Se debe validar la respuesta de los relojes a fin de comunicar la falta de importación de datos.
  • Se debe verificar la correlatividad de fecha y horario de registros de marcación a fin de no importar registros que sigan esta correlatividad.
  • El horario de importación debe ser mayor al de marcación.

Informes y Reportes:

  • Listado de procesos de importación de datos con cantidad de datos importados por proceso.
  • Listado de procesos por estado en proceso/en ejecución/abortados.

 

 

MARCACIONES DE FUNCIONARIOS

El sistema debe contar con una sección especial para la marcación de registros de entrada y salida de funcionarios. En esta sección se debe poder administrar todo lo concerniente a marcaciones tanto a través de los relojes biométricos como de manera manual/planilla.

Datos específicos:

  • Funcionario
  • Reloj
  • Horario de marcación
  • Horario de registro en sistema
  • Modo de registro

 Procesos:

  • Importación automática: Cuando la importación de los datos del reloj se realiza a través de un script automático configurado en el servidor, donde este script se conecta al reloj a través de la red y obtiene los datos de marcación.
  • Importación manual: Cuando el reloj biométrico no posee conexión a la red, por lo tanto se debe extraer el archivo plano del reloj de manera manual. Para este proceso de deberá adjuntar el archivo plano generado por el reloj y hacer correr un proceso a fin de insertar los registros.
  • Carga de planilla: El sistema deberá poseer una ventana de carga rápida de horarios según planilla, donde se exponga en pantalla las fechas de entrada y salida dentro de un rango de fecha para un funcionario, a modo que la carga de la planilla de marcación de un funcionario se pueda realizar de manera rápida y fácil.
  • Carga manual: Carga de registro de entrado o salida de manera manual, seleccionando el funcionario e indicando el horario de marcación, en este caso el sistema debe exigir la carga una documentación respiratoria y observación al respecto. (Se utiliza en caso de que el reloj no haya leído la marcación de algún funcionario u otro caso similar)

Informes y Reportes:

  • Listado de marcaciones de un funcionario dentro del mes.
  • Listado de marcaciones por reloj dentro de un rango de fecha y hora.
  • Listado de marcaciones por tipo.

 

 

TIPO DE PERMISOS CON SUS REGLAS CORRESPONDIENTES

Se deben cargar tipo de permisos permitidos a fin de categorizar los tipos de permisos existentes actualmente y otros que podrían llegar a surgir con el tiempo. Cada tipo de permisos debe cumplir sus reglamentaciones correspondientes indicadas en esta sección.

Datos específicos: Tipo de permisos, detalle de especificaciones genéricas.

Detalle de especificaciones genéricas: El detalle de especificaciones genéricas deberá ser ajustable a exigencias de la institución.

Informes y Reportes:

  • Listado de tipos de permisos.
  • Listado de tipos de permisos con cantidad de días/horas permitidas a través de este tipo de permiso.

 

ANEXO DEL PERSONAL VIGENTE POR PERIODO

Carga del anexo del personal a fin de vincular con cada funcionario nombrado su línea correspondiente al anexo y tener un informe de categorías disponibles.

Datos específicos: Periodo, Categoría, Cargo APN, Línea Presupuestaria, Vigente desde, Vigente hasta, Tipo de línea (Presupuestado, Comisionado, Contratado Jornalero, Contratado Técnico, Contratado Profesional), Estado (Activo/Inactivo), Información de baja de funcionario

Validación específica: Cada funcionario puede tener solo un registro activo. Informes y Reportes:

  • Listado correspondiente al anexo por periodo.
  • Listado de cargos vacantes.
  • Listado por categoría, cargo, línea presupuestaria.
  • Historia del legajo de registros correspondientes al anexo de un funcionario en particular.

 

 

ORGANIGRAMA INSTITUCIONAL RAMIFICADO EN MODO DE ÁRBOL

Carga del organigrama institucional por dependencias. El sistema debe manejar de manera independiente el organigrama institucional al organigrama o estructura financiera, ya que el institucional es el que denota las oficinas y procesos de los funcionarios.

El organigrama institucional no se maneja por periodo, es un organigrama eterno que si posee la posibilidad de decir que un ítem se encuentra activo o inactivo.

Las estructuras del organigrama deben ser en forma de árbol a fin de que el sistema no tenga un límite de niveles para la generación de dependencias relacionales.

Datos específicos: ID Ítem organigrama, Referencia al ítem padre, Nombre de la dependencia, dirección etc., Responsable y/o firmante.

Reglas:

  • Los ítems que no tienen padres van a la cabecera del organigrama.
  • No pueden existir dos ítems con el mismo nombre dentro del mismo padre.
  • No se pueden eliminar padres que poseen registros afectados.
  • No se puede desactivar ítems que poseen funcionarios activos asignados.

Forma de búsqueda:

La búsqueda de los registros se hará teniendo en cuenta el ítem y sus padres. Por lo tanto, si existen un organigrama (ejemplo a continuación):

Entidad (1)

Dirección Administrativa (2)

Informática (3)

Tesorería (4) Dirección de Apoyo (5)

Informática (6)

Comunicación Interna (7)

Donde se busca

  • La cadena: formatic se debe obtener como resultado el ítem 3 y 6.
  • La cadena: formatic direcc adm se debe obtener como resultado solo el ítem 3.

Forma de utilización en filtros de reportes: En todos los sectores del sistema que se hagan referencia a un filtro por dependencia, el sistema debe poseer un checkbox para indicar si:

  • Arrojar como resultado los registros correspondientes solo a ese ítem.
  • Arrojar como resultado los registros correspondientes a ese ítem y los correspondientes a los hijos del mismo ítem.

Informes y Reportes:

  • Mostrar organigrama activo.
  • Mostrar organigrama activo e inactivo.
  • Mostrar organigrama a partir de un ítem
  • Mostrar organigrama a partir de un ítem hasta un nivel de profundidad especificado.

 

 

CARGA DE DATOS GENERALES DE FUNCIONARIOS

El sistema deberá administrar los datos de los funcionarios de la institución.

Datos específicos: CI, Nombre, Apellido, Genero, Fecha de nacimiento, usuario de sistema vinculado a este funcionario, Cta. Cte., Discapacidad, Horario de entrada, Horario de salida.

Archivo adjunto: Foto del funcionario. Validaciones específicas:

  • Solo un funcionario por usuario puede estar vinculado. Relación 1 a 1.

Informes y Reportes:

  • Listado de funcionarios por rango de edad, genero.
  • Listado de funcionarios por tipo de horario de entrada y salida.

 

RESOLUCIONES VINCULADAS A LA GESTIÓN DE RRHH

Carga de resoluciones vinculadas a procesos de Recurso Humano. Se debe poder visualizar una copia digitalizada de las resoluciones que afectan los procesos.

Datos específicos: Nro, Periodo, Descripción, Firmantes. Archivo adjunto: Archivo en formato pdf.

Búsqueda: Se debe buscar tanto por numero como por descripción, se debe listar todos los movimientos que hacen referencia a esta resolución.

Informes y Reportes:

  • Listado de resoluciones por rango de fecha/periodo.
  • Visualización de una resolución.

 

CONTRATOS VIGENTES Y NO VIGENTES VINCULADOS A FUNCIONARIOS

Carga de contratos a fin de vincular con los funcionarios contratados, el sistema debe manejar un estándar de contrato (hasta 3 formatos).

Datos específicos: Nro, Periodo, Funcionario, Vigencia desde/hasta, Tipo de contrato, Resolución vinculada.

Informes y Reportes:

  • Listado de contratos correspondientes a una resolución.
  • Listado de contratos que afectan a un usuario.
  • Listado de contratos por sede.
  • Listado de contratos por dependencia.

 

 

INFORMACIÓN ACADÉMICA DE LOS FUNCIONARIOS

El sistema debe contar con una base de datos detallada de los cursos/capacitaciones/títulos de grado y post grados de sus funcionarios para de esta forma tener conocimiento de sus capacidades internas a fin de ubicar los funcionarios según sus mejores habilidades.

Datos específicos: Funcionario, Tipo de conocimiento, Descripción, Fecha de inicio del curso, Fecha de finalización del curso, Ciudad, País, Institución educadora.

Adjunto: Archivo en formato pdf a fin de adjuntar el titulo/diploma/certificado que avale el grado académico o conocimiento.

Búsqueda: La búsqueda se deberá poder realizar por distintos campos como ser: Tipo de conocimiento, edad, género, sede y otros.

Auto Gestión: La modalidad de auto gestión permite que los propios funcionarios interesados en que su legajo académico se encuentre actualizado puedan auto gestionar la actualización de sus datos a través de un usuario con el cual pueda tener acceso única y exclusivamente a sus datos. Los datos no serán publicados hasta que sea verificado por un usuario autorizado de recursos humanos.

Informes y Reportes:

  • Lisado de funcionarios según resultado de búsqueda.
  • Ranking de tipo de conocimientos de funcionarios.
  • Gráfico de grado académico según filtro seleccionado.

 

INFORMACIÓN ANEXO POR FUNCIONARIO

El sistema debe guardar el historial del funcionario en relación a su anexo de persona. Datos específicos: Los datos específicos son guardados a través del anexo del personal. Informes y Reportes:

  • Listado de la trayectoria y/o asignaciones según anexo del personal en los distintos periodos.

 

INFORMACIÓN DE TRAYECTORIA POR DEPENDENCIA Y CARGO

El sistema debe guardar el historial del funcionario en relación a las dependencias donde ha trabajado y que cargo ha ocupado.

Estos datos se deberán poder cargar desde dos modalidades: 1) A través de la ficha del funcionario. 2) a través del listado general de cargos y dependencias.

Datos específicos: Funcionario, dependencia, cargo interno. Informes y Reportes:

  • Listado de trayectoria en la institución.
  • Listado de funcionarios que han poseído cierto cargo.
  • Listado de funcionario que han pasado por una dependencia.
  • Listado de funcionarios actualmente en una dependencia.

 

ADMINISTRACIÓN DE REMUNERACIONES EXTRAORDINARIAS

El sistema debe generar las planillas correspondientes a Remuneraciones Extraordinarias teniendo en cuenta todos sus cálculos correspondientes.

Datos específicos: Funcionario, Entrada, Salida, Cant. Horas, Fecha, Monto RE generado. Funciones específicas:

  • Tomar los horarios correspondientes a entrada y salida del funcionario para realizar el cálculo.
  • Parametrización de porcentaje o fórmula de cálculo de pago de RE según la entidad.
  • Generar el cálculo de todos los funcionarios tengan o no el beneficio de RE.
  • Solamente generar nómina de los funcionarios que posean el beneficio de RE.
  • Presentar topes de RE al mes.
  • Analizar las horas correspondientes a RE según el horario laboral de cada funcionario.
  • Seguir las normas correspondientes. Ejemplo: Hasta 2 horas diarias, Hasta 8 horas semanales, Hasta 32 horas al mes.
  • Variación de topes mensuales según resolución.
  • Variación de montos a aplicar según disponibilidad presupuestaria.

Informes y Reportes:

  • Generación de planilla de resumen mensual por funcionario (Entrada, Salida, Cantidad de horas trabajas, Cant. Horas RE, Monto correspondiente por día, Sumatoria mensual).
  • Listado de funcionarios que poseen RE generado en el mes.
  • Listado de funcionarios que poseen RE generado en el mes y el beneficio correspondiente por resolución.
  • Generación de cuadro anual por meses de valores asignados a RE por nómina.

 

ADMINISTRACIÓN DE REMUNERACIONES ADICIONALES

El sistema debe generar las planillas correspondientes a Remuneraciones Adicionales teniendo en cuenta todos sus cálculos correspondientes para días hábiles como inhábiles.

Datos específicos: Funcionario, Entrada, Salida, Cant. Horas, Fecha, Monto RA generado, Monto RA día inhábil generado.

Funciones específicas:

  • Tomar los horarios correspondientes a entrada y salida del funcionario para realizar el cálculo.
  • Parametrización de porcentaje o fórmula de cálculo de pago de RA y RA-DI según la entidad.
  • Generar el cálculo de todos los funcionarios tengan o no el beneficio de RA.
  • Solamente generar nómina de los funcionarios que posean el beneficio de RA.
  • Presentar topes de RA al mes.
  • Analizar las horas correspondientes a RA según el horario laboral de cada funcionario.
  • Seguir las normas correspondientes. Ejemplo: El RA comienza a correr a partir de la finalización de la hora aplicable a RE, si el RE ya ha llegado a su tope se tomará como RA si la entidad posee ese criterio.
  • Variación de topes mensuales según resolución.
  • Variación de montos a aplicar según disponibilidad presupuestaria.

Informes y Reportes:

  • Generación de planilla de resumen mensual por funcionario (Entrada, Salida, Cantidad de horas trabajas, Cant. Horas RA, Cant. Horas RA-DI, Monto correspondiente por día para RA y RA-DI, Sumatoria mensual de RA y RA-DI).
  • Listado de funcionarios que poseen RA generado en el mes.
  • Listado de funcionarios que poseen RA generado en el mes y el beneficio correspondiente por resolución.
  • Generación de cuadro anual por meses de valores asignados a RA por nómina.

 

PROCESOS DE GENERACIÓN DE BENEFICIOS POR ANTIGÜEDAD

El sistema debe administrar los beneficios percibidos por Antigüedad según las normativas dictaminadas. Datos específicos: Funcionario, monto aplicable, fecha de inicio de aplicación.

Informes y Reportes:

  • Listado de funcionarios que poseen el beneficio.
  • Listado de funcionarios que deberían poseer el beneficio indicando una fecha específica.

 

ADMINISTRACIÓN DE RESERVAS PARA AGUINALDO

El sistema debe generar informes o alertas sobre la necesidad de fondos para cubrir lo correspondiente a pago de aguinaldo realizando una proyección de gastos a fin de prever con tiempo posibles reprogramaciones. Así también debe presentar una proyección de gastos teniendo en cuenta el último pago realizado a fin de estimar la ejecución ideal por mes y anual.

Datos específicos: Funcionario, periodo, monto. Informes y Reportes:

  • Informe de proyección de pagos de nivel 100 con estimación de ejecución ideal mensual y anual.

 

OTROS BENEFICIOS

El sistema debe permitir la administración de otros tipos de beneficios que puedan percibir los funcionarios.

El sistema debe manejar esta asignación de permisos de una manera parametrizable determinando por cada permiso los parámetros a tener en cuenta para el cálculo correcto de los importes.

Se debe poder cargar beneficios con bonificaciones fijas y porcentuales, indicando dentro de estos beneficios que funcionarios deben percibir este beneficio.

Alguno de los beneficios que se deben de tener en cuenta son: Responsabilidad en el cargo, por hijos, Grado académico, Premio por rendimiento etc.

Datos específicos: Tipo de concepto, descripción, desde, hasta, Obj. del Gasto, tipo (Fijo, Porcentaje, Horas máximas, Funcionarios vinculados, Documento de respaldo)

Informes y Reportes:

  • Listado de beneficios activos/inactivos dentro de rango de fecha.
  • Listado de funcionarios por beneficios dentro de rango de fecha.

 

DESCUENTOS

El sistema deberá poseer una sección de administración de descuentos a ser realizados a los funcionarios por motivos distinto a sanciones por falta en marcación de entrada/salida (Los descuentos que se encuentran dentro de los identificados por una mala marcación de su horario serán contemplados automáticamente dentro de la sección de marcaciones y generación de nómina).

Detalle de funcionalidades

  • Los descuentos se realizarán indicando el tipo de descuento, el monto.
  • Se determinará el listado de funcionarios que debe percibir este descuento.
  • Es sistema debe manejar una prioridad de descuento a ser realizado.
  • El sistema deberá manejar un tope mínimo que debe percibir el funcionario y realizar los descuentos solo hasta ese punto.
  • Los descuentos que no se puedan realizar quedarán pendiente para ser descontados en una siguiente generación de nómina.

Datos específicos: Denominación, Tipo, prioridad, Listado de funcionarios, fecha de inicio de descuento, Valor total a descontar, cantidad de aplicaciones, documento de respaldo.

Informes y Reportes:

  • Listado de descuentos realizados por funcionarios.
  • Listado de descuentos realizados dentro de un rango de fecha.

 

VACACIONES

El sistema deberá poseer calculadores que puedan identificar las vacaciones que le corresponden a cada funcionario.

El cálculo de vacaciones por funcionario se realizará teniendo en cuenta la cantidad de días permitidos según la antigüedad y la cantidad de periodos anteriores que pueden acumular vacaciones pendientes. Datos específicos: funcionario, cantidad total de vacaciones, días tomados.

Informes y Reportes:

  • Reporte individual del estado de vacaciones del funcionario: En este informe se debe indicar:
    • Una cabera con los datos del funcionario.
    • Fecha de ingreso
    • Antigüedad.
    • Cantidad de vacaciones correspondientes
    • Sumatoria de vacaciones tomadas
    • Saldo de vacaciones pendientes
    • Listado de fechas que se han tomado como vacaciones donde su sumatoria debe coincidir con la sumatoria de vacaciones tomadas.
  • Listado e vacaciones tomas: Generar un listado de funcionarios que tomaron vacaciones dentro de un rango de fecha correspondiente.
  • Listado general de vacaciones pendientes por funcionarios.

 

 

 

EMISIÓN DE CERTIFICADO DE TRABAJO

El sistema debe emitir el certificado de trabajo correspondiente con todos los datos del funcionario.

El formato del certificado laboral se debe coordinar con los responsables de RRHH.

Datos específicos mínimos: Nombre, antigüedad, cargo, lugar de trabajo, salario percibido, otros beneficios percibidos.

Informes y Reportes:

  • Generación del comprobante de trabajo en formato PDF.

 

APERCIBIMIENTOS

El sistema debe controlar el comportamiento de los funcionarios entorno a sus marcaciones, generando así la nota correspondiente para el apercibimiento de los funcionarios dentro del plazo establecido.

La nota de apercibimiento será realizada de forma conjunta con los encargados de RRHH. Informes y Reportes:

  • Listado de funcionarios que deben percibir apercibimientos.
  • Generación de nota de apercibimiento en formato pdf (En caso de que varios funcionarios deban recibir un apercibimiento el sistema podrá generan en un solo pdf varias notas de apercibimiento separando uno de otro por hoja)

MULTAS

El sistema debe realizar el control de apercibimientos de manera automática. No obstante estos apercibimientos solo se aplicarán una vez que sea aprobada a resolución correspondiente y sea cargada dentro del sistema.

Los apercibimientos generados serán a través de la nómina, descontando hasta un valor tope correspondiente a lo generado en el cálculo de marcaciones.

Datos específicos: funcionario, mes, tipo de apercibimiento, valor calculado, valor a descontar. Informes y Reportes:

  • Listado de funcionarios con apercibimiento por mes.
  • Listado de apercibimientos por funcionario.

 

NOTIFICACIONES

El sistema deberá manejar una sección correspondiente a notificaciones a funcionarios, donde dentro del sistema se puedan especificar las notificaciones emitidas y recibidas.

Detalle de funcionalidades

  • Se debe visualizar un panel con notificaciones emitidas y recibidas.
  • Las notificaciones se podrán buscar por palabras claves y/o nombre del funcionario.
  • Se podrán adjuntar archivos en formato pdf a fin de tener al archivo digital adjunto al sistema.

Informes y Reportes:

  • Listado de notificaciones recibidas.
  • Listado de notificaciones emitidas.
  • Listado de notificaciones por funcionario.
  • Listado de notificaciones por mes o rango de fecha.

 

GENERACIÓN DE NOMINA

El sistema contará con una sección de generación de nómina. La generación de dicha nómina generará un cierre dentro de los datos de los funcionarios, a fin de que a partir de generar la nómina no se puedan editar ningún registro con fecha menor a esa nómina que afecte a un funcionario involucrado dentro de dicha nómina.

Funcionalidades

  • Generación de planilla de nómina.
  • Generación de txt para transferencia a cuentas según formato exigido por entidades bancarias.
  • Descuento de retenciones de IVA, Renta, Jubilaciones, IPS.
  • Descuento por multas.
  • Debe impactar los descuentos establecidos dentro de la sección descuentos.

Datos específicos: Funcionario, Mes, Rubro, Concepto, tipo de descuento, monto de descuento, estado, monto calculado, monto aplicado.

Informes y Reportes:

  • Generación de nómina según exigencias y estándares teniendo en cuenta un corte de control por estructura presupuestaria.
  • Listado de funcionarios dentro de cada nómina.
  • Listado de nóminas generadas.

 

ESPECIFICACIONES DE LA PLATAFORMA DEL SISTEMA

 

DESCRIPCIÓN GENERAL

El sistema debe estar desarrollado acorde a las últimas tendencias de desarrollo de software para ambiente web. Debe utilizar lenguajes y plataformas que posean una gran cantidad de soporte en línea. La base de dato a ser utilizado debe ser del tipo Open Source y todas las validaciones de datos y lógicas de negocio se debe realizar a través de triggers en base de datos.

La auditoría de registros se debe realizar a través de triggers en las tablas, registrando todos los cambios que se dieron y guardando todos los datos. El almacenamiento de estos datos debe ser en una base de datos distinta a fin de que el backup de auditoria puede ser incremental y el backup de datos una copia o en espejo.

El sistema se debe adecuar totalmente para el acceso a través de Tablets o Smartphone, la navegación debe ser sencilla y el sistema debe correr sin ningún inconveniente sobre los browsers más utilizados.

El sistema debe estar orientado al usuario operador, facilitando en todo momento el mecanismo de carga de datos.

Todos los informes deberán ser emitidos en formato pdf, los informes del tipo listados deberán ser exportables a Excel.

Todos los procesos citados dentro de las especificaciones técnicas deberán formar parte del sistema en general, no necesariamente dentro del módulo en el cual fue expuesta la funcionalidad. Esto a modo de no generar procesos duplicados y/o entornos distintos para la realización de una misma actividad.

La política de acceso a usuarios debe permitir un acceso por roles que podrá ser configurable según las exigencias de la Entidad.

 

ESPECIFICACIONES SOBRE PLATAFORMAS Y METODOS DE PROGRAMACIÓN

Sistema en ambiente web WEB DEVELOPMENT

 

El sistema debe correr en ambiente web utilizando lenguajes con gran cantidad de soporte en línea.

Los códigos deberán ser entregados en su totalidad a la Entidad. Los códigos podrán ser modificados para el uso dentro de la misma entidad/administración, no podrán ser donados ni comercializados a otras entidades o administraciones.

Para los lenguajes compilados será exigido entregar los códigos fuentes correspondientes.

 

Diseño web adaptativo WEB RESPONSIVE

 

El diseño web adaptable (o adaptativo), conocido por las siglas RWD del inglés Responsive Web Design, es una filosofía de diseño y desarrollo cuyo objetivo es adaptar la apariencia de las páginas web al dispositivo que se esté utilizando para visualizarlas. Hoy día las páginas web se visualizan en multitud de dispositivos como tabletas, teléfonos inteligentes, libros electrónicos, portátiles, PCs, etcétera. Además, aún dentro de cada tipo, cada dispositivo tiene sus características concretas: tamaño de pantalla, resolución, potencia de CPU, sistema operativo o capacidad de memoria entre otras. Esta tecnología pretende que, con un único diseño web, se obtenga una visualización adecuada en cualquier dispositivo.

 

Base de datos tipo Open Source

 

El sistema deberá utilizar una base de datos del tipo Open Sorce, la base de datos seleccionada deberá poseer las siguientes características:

  • Una base de datos 100% ACID.
  • Soporta distintos tipos de datos: además del soporte para los tipos base, también soporta datos de tipo fecha, monetarios, elementos gráficos, datos sobre redes (MAC, IP ...), cadenas de bits, etc. También permite la creación de tipos propios.
  • Incluye herencia entre tablas, por lo que a este gestor de bases de datos se le incluye entre los gestores objeto-relacionales.
  • Copias de seguridad en caliente (Online/hot backups)
  • Unicode
  • Juegos de caracteres internacionales
  • Regionalización por columna
  • Multi-Version Concurrency Control (MVCC)
  • Múltiples métodos de autentificación
  • Acceso encriptado vía SSL
  • Completa documentación
  • Licencia BSD
  • Disponible para Linux y UNIX en todas sus variantes (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64) y Windows 32/64bit.

 

Framework de desarrollo

 

El sistema deberá estar desarrollado sobre un "framework" (infraestructura, armazón, marco), en términos generales, un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar.

 

En el desarrollo de software, un framework o infraestructura digital, es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos concretos de software, que puede servir de base para la organización y desarrollo de software. Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes de un proyecto.

El framework utilizado deberá estar entre los más populares y debe contar con una gran cantidad de soporte en línea.

 

Programación en capas

 

Se requerirá de una programación por capas es decir una arquitectura cliente-servidor en el que el objetivo primordial es la separación de la lógica de negocios de la lógica de diseño; un ejemplo básico de esto consiste en separar la capa de datos de la capa de presentación al usuario.

 

La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algún cambio, solo se ataca al nivel requerido sin tener que revisar entre código mezclado.

 

Además, permite distribuir el trabajo de creación de una aplicación por niveles; de este modo, cada grupo de trabajo está totalmente abstraído del resto de niveles, de forma que basta con conocer la API que existe entre niveles.

 

En el diseño de sistemas informáticos actual se suelen usar las arquitecturas multinivel o Programación por capas. En dichas arquitecturas a cada nivel se le confía una misión simple, lo que permite el diseño de arquitecturas escalables (que pueden ampliarse con facilidad en caso de que las necesidades aumenten).

 

Mecanismo de validación de lógica de datos

 

La lógica de datos deberá estar aplicada en la base de datos a través de trigger del tipo before. Todas las tablas del sistema verificarán la lógica de datos a través de triggers. De esta forma se protege los datos, aunque los mismos sean manipulados desde la propia base de datos o insertados desde otro sistema anexo.

 

El sistema deberá prever algún mecanismo que valide que los triggers de validación se encuentren activos. Inclusive si los triggers se desactivasen manualmente el mecanismo deberá activarlos antes de una inserción de datos desde el sistema.

Todas las validaciones realizadas deberán contar con un comentario en el código que explique a grandes rasgos el tipo de validación que se realiza.

 

Método de resguardo de datos

Todos los datos del sistema o de los sistemas que intervengan las especificaciones técnicas sobre las funcionalidades requeridas deberán almacenarse en una única base de datos. Esto hará posible que, si varios sectores del sistema utilizan una misma información, puedan nutrir un único lugar de carga de datos y así todas estas secciones trabajar de manera cooperativa para la generación y edición de datos.

 

CONTROL DE ACCESO

Políticas de acceso a las secciones del sistema

 

El acceso a las secciones del sistema será asignado por roles que englobaran permisos. El sistema tendrá un listado general de permisos sobre cada sección del sistema que permita:

  • Consultar datos
  • Consultar y editar datos
  • Consultar, editar y confirmar datos.
  • Consultar, des confirmar datos.

Se podrán crear roles nuevos con la combinación de permisos que se desea.

Los usuarios no se podrán asignar directamente a permisos, se deberán vincularán únicamente a roles. Pudiéndose vincular a uno o más roles.

Los usuarios tendrán una propiedad de usuario activo (SI/NO), solo podrán acceder al sistema los usuarios activos SI.

Las creaciones de roles y asignaciones de los mismos deberán ser registrados en la tabla de auditoria de datos.

 

Políticas de clave de acceso

 

Políticas de claves de acceso configurables. Se podrá configurar en el sistema el nivel de seguridad exigido al usuario al momento de ingresar una nueva contraseña. Entre los tipos de configuración que se podrán seleccionar están:

  • Nivel bajo: mayor o igual a cinco caracteres.
  • Nivel básico: mayor o igual a ocho caracteres.
  • Nivel medio: mayor o igual a doce caracteres con al menos una mayúscula y minúscula.
  • Nivel alto: mayor o igual a doce caracteres con al menos una mayúscula, minúscula y signo (¡@#$%^&*()_+=[]|\).

El sistema permitirá configurar una periodicidad para el cambio de la clave de acceso, donde por ejemplo el valor 60 (sesenta) forzará a los usuarios a actualizar su clave cada 60 días y el valor 0 (cero) determinará que no se solicitará reasignar la clave en ningún momento.

En el caso de contar con servidor LDAP, el sistema podrá corroborar su clave de acceso contra el mismo.

 

MECANISMO DE AUDITORIA DE DATOS Y BACKUP

 

Mecanismo de auditoría

 

La auditoría de registros se hará en la base de datos a través de triggers del tipo after. El mecanismo de auditoría será realizado en paralelo de dos maneras:

    1. Registro de los datos nuevos, modificados o viejos más usuario que realizo el cambio (usuario de base de datos y usuario del sistema), ip del cliente, aplicación (Sistema o Administrador de Base de Datos ej. PgAdmin), ID de transacción, Tipo de operación (INSERT, UPDATE, DELETE), fecha.
    2. Todas las tablas deberán contar con campos donde se deberán guardar el usuario y la fecha de creación y última modificación del registro.

El sistema debe poseer un mecanismo de validación de activación de todos los triggers de validación con cada conexión a la base de datos, evitando así problemas por desactivación intencional o involuntaria de los triggers de validación.

 

Almacenamiento de auditoría

Los registros de auditoría deberán ser almacenados de forma definitiva en una base de datos distinta a la base de datos del sistema en sí, esto por un lado alivianará el tamaño de la base de datos operativa y hará más fácil el backup de datos. Tanto de los datos de auditoria como los datos del sistema. Con esta estructura de base de datos permitimos que los backups de auditoria sean por el mecanismo incremental.

 

Políticas de Backup

 

El sistema tendrá un mecanismo propio de backup de base de datos y archivos fuentes. El sistema deberá tener una ventana de configuración, la ventana de configuración deberá permitir lo siguiente:

  • Periodicidad de tiempo para correr los procesos.
  • Destino de los archivos.
  • Tipo de backup:
    • Base de datos de datos operativos.
    • Base de datos de auditoria.
    • Archivos adjuntos.
    • Archivos fuentes de las secciones operativas.
    • Archivos fuentes de todo el sistema.
    • Completo.
  • Compresión de datos (SI/NO)

Se podrán agregar varias reglas permitiendo así en resguardo de los archivos en diferentes directorios y periodicidades distintas según el tipo de backup.

 

HERRAMIENTAS Y METODOS QUE DEBE CONTAR EL SISTEMA

Mecanismo de notificaciones

 

El sistema deberá contar con un mecanismo de notificaciones que trabaje con distintos tipos de eventos. Las notificaciones deberán aparecer al usuario dando la opción de:

  • Volver a notificar en 1 día.
  • Volver a notificar en 3 días.
  • Volver a notificar en 1 semana.
  • Volver a notificar en 15 días.
  • Volver a notificar en 1 mes.

Las notificaciones deberán aparecer sobre el entorno de trabajo en el que se encuentre el usuario. Las notificaciones y respuestas sobre las mismas serán registradas por usuarios.

 

Configuración de firmantes de reportes

 

Los firmantes de los reportes podrán ser configurables, se podrán determinar ciertos tipos de firmantes para ciertos tipos de reportes a ser definidos por la entidad.

 

Navegabilidad dentro del sistema

 

El sistema requerirá de una navegación fácil y rápida entre sus ventanas, otorgando al usuario operador facilidades al momento de la carga de datos.

Características principales:

  • Todo el sistema deberá poder ser navegable sin la utilización del mouse.
  • Se crearán combinaciones de teclas para un acceso directo a:
    • Ir al panel principal
    • Ir al menú principal
    • Ir a las opciones
    • Agregar un registro
    • Realizar una búsqueda
  • Los listados deberán ser navegables utilizando las fechas de arriba, abajo, derecha e izquierda.

Mecanismo de importación de datos

 

Todas las tablas de base de datos que utilicen datos de gestión operativas deberán contar con la opción de importar datos directamente desde el sistema, se podrá importar adjunto un archivo o copiado y pegando la información en un textarea.

Cada tabla o sección de importación deberá indicar al usuario cual es el formato requerido para la importación de datos.

Los formatos habilitados para la importación de datos serán:

  • Separado por tabulaciones.
  • Separado por ; (punto y coma).

 

Exportación de informes del tipo listado a formato Excel

 

Todos los reportes que generen como resultado principal un listado de datos deberá tener la opción de ser exportados a formato Excel.

Los archivos creados deberán tener la extensión xls o xlsx. Deberán abrirse en Excel sin ninguna advertencia por tipo de archivo o datos.

 

Envío en informes por e-mail directamente desde el servidor

 

Todos los reportes en PDF que genere el sistema deberán tener la opción de poder ser enviados por email, también se podrán configurar:

  • Momento de envío:
    • Envío inmediato.
    • Definir fecha de envió.
  • Destinatario
    • Mi usuario
    • Ingresar e-mail (se podrán ingresar varias cuentas de emails separados por ; punto y coma)

Los reportes que serán enviados en una fecha distinta a la actual deberán reflejar los datos que posee el sistema al momento que se indica en la fecha de envío.

 

Se generará un listado de todos los envíos pendientes, el usuario que posea permiso para ver todos los envíos pendientes y cada usuario que generó el envío podrá visualizar, reconfigurar y eliminar los envíos de informes.

 

Se requerirá de la configuración del sistema a una cuenta de e-mail institucional de manera segura y respetando todas las políticas generales para no ser detectados como spam.

 

Formularios del tipo carga rápida

 

Todos los formularios de inserción de información al sistema deben tener la opción de carga rápida. Damos a entender por carga rápida un mecanismo por el cual:

  • Solo sea necesario la utilización del teclado.
  • El orden de tabulaciones sea correlativo.
  • El sistema no debe volver al listado con cada registro cargado, solo deberá limpiar los campos y posicionar en cursor en el primer campo.
  • Se puedan seleccionar que datos serán idénticos durante la carga para que el sistema no borre esa información de los campos con cada inserción de registro.

 

Modo de presentación de listados y búsqueda de datos

La presentación de los listados de datos de secciones deberá tener en cuenta los siguientes puntos:

  • Mostrar el total de registros, en caso de datos filtrados se deberá mostrar el total de registros que coincidan con el filtro.
  • Poder ir al último registro con una acción.
  • Buscador por varias columnas de datos de manera independiente.

Mecanismo de selección de campos relacionados

Dentro de formularios de inserción y edición de datos poseemos ciertos datos que van vinculados con otros datos ya cargados en el sistema. Por lo tanto, en estos casos se debe seleccionar el valor al cual se hará referencia.

 

Para estos casos el sistema se deberá adecuar al siguiente mecanismo:

  • Lista desplegable de opciones a seleccionar mientras se va escribiendo la información.
  • Se podrá navegar entre las opciones a seleccionar con la fecha de arriba y abajo.
  • Con un click se seleccionará el dato indicado.
  • Si no existe el campo vinculado, deberá aparecer una opción para agregar un nuevo registro en la tabla vinculada, luego de agregar el registro se deberá regresar a la vista con todos los datos que ya se habían cargado más el nuevo registro creado. (Este mecanismo debe eliminar el problema de salir a agregar registros para continuar. Ejemplo del problema existente sin este mecanismo: Al agregar un registro y no existe el proveedor vinculado, debemos salir agregar el proveedor y volver a ingresar a la sección de carga).
  • Opción de ir a la vista del listado de la sección de referencia a seleccionar y buscar el registro según los parámetros de búsqueda especificados en el Modo de presentación de listados y búsqueda de datos.
  •  

Mecanismo de upload de archivos y fotos

El mecanismo de upload de fotos y archivos genera en gran medida problemas y retrasos al momento de carga de datos, por lo tanto, las características que debe cumplir el mecanismo son las siguientes:

  • Realizar el upload en segundo plano (Ejemplo: AJAX).
  • Se deberá poder seguir cargando datos al formulario durante la carga del archivo adjunto.
  • Se podrá adjuntar un archivo arrastrando desde una carpeta del sistema operativo del cliente hasta la opción de adjuntar.
  • Se deberá mostrar el progreso de subida de archivos en porcentaje.

El almacenamiento de los archivos deberá seguir las siguientes pautas de orden y seguridad:

  • Los archivos deberán ser guardados de manera ordenada en una carpeta dentro del servidor.
  • La carpeta que contendrá los archivos no debe encontrarse en un directorio visible o público.
  • El acceso al archivo será a través de un intérprete.
  • No se podrá acceder/descargar a los archivos sin estar logueados en el sistema.
  • La base de datos solo almacenará la ruta del archivo.

Vista previa de los pdf’s adjuntos

Los archivos adjuntos en formato pdf deberán tener la propiedad de poseer una vista previa en formato jpg de la primera página del pdf.

Firma digital

Sistema de aplicación de firma digital con la utilización de TOKEN: El sistema deberá contar con un sistema para la utilización de firma digital. Permitiendo a los usuarios firmar documentos en pdf generados en el sistema, estos documentos se deberán guardar en el servidor con la posibilidad de descarga. Cada uno de estos documentos podrá poseer una o varias firmas digitales. Todas estas firmas deberán ser realizadas por el usuario sin la necesidad de descargar el archivo para firmarlo en Acrobat Reader u otro software similar, el proceso de la firma se deberá realizar principalmente para el usuario dentro del ambiente web del sistema. Deberá existir una sección especial del sistema donde se encuentre el listado de todos los pdfs que fueron firmados a través del sistema. Este listado deberá emitir informes y deberá poder ser filtrados según parámetros como: rango de fecha, firmantes, tipo de documentos etc.

 

Sistema de impresión directa desde el sistema en impresoras conectadas al equipo de usuario Consiste en un mecanismo donde el usuario pueda configurar dentro del entorno web del sistema en que impresora conectada a su equipo desea imprimir que reporte. El objetivo final del mismo es facilitar el proceso de impresión directa con teclas como P o combinaciones de tecla. Generando así la funcionalidad de imprimir comprobantes de ingresos u otros documentos de manera directa sin la necesidad de recurrir a abrir el pdf e ir a las opciones de imprimir desde visualizador del pdf.

 

Generación dinámica de reportes de todos los listados del sistema

Todos los listados del sistema y tablas de base de datos deben generar una vista donde se puedan seleccionar que columnas mostrar o no, dentro del entorno del sistema (generación pdf y exportación a Excel), se deberá poder filtrar datos, agregar comentarios, firmantes. Configurar la impresión del reporte en formato horizontal o vertical. Se podrá modificar el orden de los datos del listado según distintas lógicas.

 

APLICACIONES QUE DEBEN CORRER CON EL SISTEMA

Aplicación para upload directo de fotos y pdf´s

 

El sistema requerirá de una aplicación que facilite el mecanismo para adjuntar imágenes y pdfs al sistema. Funcionalidad general

La aplicación deberá estar disponible para Android. Se encargará de facilitar el proceso de vincular las imágenes tomadas con el dispositivo y vincularlas con el registro correspondiente en el sistema.

 

Si el registro requiere de un archivo pdf, la aplicación deberá transformar la imagen o secuencias de imágenes en un archivo pdf con unas o varias páginas según la cantidad de imágenes tomadas en la secuencia.

 

Funcionalidades específicas

  • Aplicación disponible para sistemas operativos Android. (Desarrollado preferentemente con JAVA)
  • Requerirá de un control de acceso por usuario.
  • El control de acceso por usuarios utilizará el mismo usuario y clave del sistema, y se regirá por los privilegios de roles indicados en el sistema.
  • Se podrán procesar:
    • Fotos tomadas con la cámara.
    • Foto de la galería de imágenes.
    • Archivo pdf existente en el directorio del dispositivo.
  • El resultado final que deben generar los procesos de la aplicación y el sistema son:

o En el caso de requerir una imagen: Generar un archivo jpg y mostrar el archivo en la ventana donde se vincula los archivos.

o En el caso de requerir un pdf: Generar un archivo pdf y mostrar el archivo en la ventana donde se vincula los archivos.

  • El sistema debe poder generar un pdf de las imágenes tomadas.
  • El sistema deberá adjuntar primeramente un archivo pequeño y luego ejecutar en segundo plano el proceso para subir al servidor el archivo original. El proceso de carga dentro del sistema ya se podrá proseguir con el archivo pequeño adjunto en el servidor.
  • Se deberá mostrar o consultar los procesos de upload de datos al servidor que se encuentran pendientes y los últimos realizados.

 

Aplicación de calendario y notificaciones

 

El sistema requerirá de una aplicación donde los usuarios pueden visualizar el calendario de actividades en su Smartphone y recibir las mismas notificaciones que figuran en el sistema.

 

Funcionalidad general

La aplicación deberá estar disponible para Android. Tendrá como principal objetivo el de mantener al tanto a los funcionarios sobre las actividades vinculadas a su trabajo y principalmente procesos del sistema.

 

Funcionalidades específicas

  • Aplicación disponible para sistemas operativos Android. (Desarrollado preferentemente con JAVA)
  • Requerirá de un control de acceso por usuario.
  • El control de acceso por usuarios utilizará el mismo usuario y clave del sistema, y se regirá por los privilegios de roles indicados en el sistema.
  • Se mostrará la misma información de eventos que figura en el sistema con su usuario.
  • Deberá generar notificaciones en su Smartphone o Tablet cuando sea requerido según el plazo establecido en el sistema de notificaciones. Las repuestas realizadas en la aplicación tendrán el mismo valor que las respuestas realizadas en el sistema.

 

GARANTIA Y SOPORTE

 

Garantía

 

El sistema debe contar con una garantía de 2 (dos) años sobres las funcionalidades establecidas dentro del pliego de base y condiciones.

El plazo de garantía se dará por iniciado con la conformidad de los trabajos asignados.

 

Soporte

 

El soporte técnico será por un plazo de 2 (dos) años contados a partir de la fecha de vigencia del contrato. El soporte será realizado preferente de manera remota para los casos que así lo permita. Caso contrario un técnico de la empresa se deberá presentarse en un plazo no mayor a 3 días hábiles.

Se podrá disponer hasta 2 (dos) presencias inmediatas por mes. Se entiende por presencia inmediata la condición de presentarse en el mismo día del requerimiento; y para los casos que la solicitud haya sido en horarios posterior al medio día, el proveedor podrá presentarse hasta el mediodía del día hábil siguiente.

 

MANUALES Y TUTORIALES

 

Manual de usuario operador

 

El manual de usuarios operador debe abarcar todas las funcionalidades establecidas en las especificaciones del Pliego de Base y Condiciones. Deberá poseer un índice ordenado de los procesos que compone el manual. Se deberá entregar el manual en versión impresa y el sistema también debe contar con una versión digital que pueda ser accedido desde el mismo sistema.

  1. Especificaciones Técnicas

 

DETALLE DE LOS PROCESOS DEL SISTEMA REQUERIDO

 

En el presente documento se describe las funcionalidades específicas del sistema requerido. No obstante, los sistemas cotizados no son sistemas cerrados, se podrá seguir incorporando los reportes que sean necesarios para el cumplimiento de las necesidades de la dependencia y de la institución, siempre y cuando estos se encuentren dentro de los procesos y/o funcionalidades citados dentro de las siguientes especificaciones.

Listado de sistemas que forman parte del presente documento de especificaciones de procesos:

    1. Gestión del personal

        DESCRIPCIÓN GENERAL

El módulo de Recursos Humanos debe encargarse de la gestión completa de los funcionarios nombrados

y contratados dentro de la institución.

Las funciones generales que debe cumplir son:

  • Carga del organigrama institucional en modo de árbol.
  • Datos generales de funcionarios
  • Asignación de línea presupuestaria según su anexo y el historial del mismo
  • Ubicación de trabajo actual dentro del Organigrama y su Historial de cargos y dependencias dentro de la institución.
  • Legajo académico clasificado por tipo de especializaciones y otras características que ayuden a una pre- selección en caso de concurso interno.
  • Administración de documentos personales digitalizados (CI, RUC, Pasaporte, Registro, Antecedentes etc.)
  • Administración de permisos
  • Marcación de entrada y salida de funcionarios
  • Administración de vacaciones
  • Generación de la nómina para el pago
  • Asignación de 3 niveles para autorización de permisos, con parametrización por tipo de permiso.
  • Incorporación de reglas de negocio para marcación de horario de almuerzo.
  • Registración de funcionarios que no corresponden a la institución y calculo especifico de multas a ser transferidas a la empresa proveedora según sea el caso.
  • Migración de datos de periodos anteriores.
  • Desarrollo de reportes según necesidad conforme a los procesos establecidos dentro de la estructura de base de datos.

Todas las secciones del sistema deben generar reportes que puedan ser filtrados por distintos campos, todos estos reportes deben ser generados en formato pdf, los listados deben contar con la posibilidad de exportarlos a planillas del tipo Excel.

 

El acceso a los datos para para la edición como para consultas debe administrado modularmente y todos los cambios realizados dentro del sistema deben quedar auditados.

LISTADO DE FUNCIONALIDADES Y/O ADMINISTRACIÓN DE DATOS QUE POSEE EL SISTEMA

    • Carga de cargos APN.
    • Cargos Internos.
    • Categorías de funcionarios.
    • Estructura Financiera.
    • Presupuesto del nivel 100 por periodo.
    • Tipo de conocimientos utilizados dentro de la entidad.
    • Administración de Feriados.
    • Tipo de documentos utilizados en la gestión de RRHH.
    • Posibilidad de administrar varias sedes.
    • Registro de relojes biométricos activos.
    • Códigos de funcionario para relojes.
    • Obtención automática de marcaciones del reloj.
    • Marcaciones de funcionarios.
    • Tipo de Permisos con sus reglas correspondientes.
    • Anexo del personal vigente por periodo.
    • Organigrama institucional ramificado en modo de árbol.
    • Carga de datos generales de funcionarios.
    • Resoluciones vinculadas a la gestión de RRHH.
    • Contratos vigentes y no vigentes vinculados a funcionarios.
    • Información académica de los funcionarios.
    • Información del anexo por funcionario.
    • Información de trayectoria por dependencia y cargo.
    • Administración de Remuneraciones Extraordinarias.
    • Administración de Remuneraciones Adicionales.
    • Procesos de generación de beneficios por Antigüedad.
    • Administración de reservas para Aguinaldo.
    • Otros Beneficios.
    • Descuentos.
    • Vacaciones.
    • Emisión de Certificado de Trabajo.
    • Apercibimientos.
    • Multas.
    • Notificaciones.
    • Generación de Nomina.

 

DETALLE DE FUNCIONALIDADES Y/O ADMINISTRACIÓN DE DATOS QUE DEBE POSEER EL SISTEMA

 

CARGA DE CARGOS APN

Cargo de datos de Cargos contemplados en el Anexo del Presupuesto Nacional a fin de vincularlo con anexo correspondiente al periodo.

Datos específicos: Denominación del cargo, Periodo Informes y Reportes:

  • Listado de Cargos por Periodo.
  • Listado de Funcionarios por Cargo.

 

CARGOS INTERNOS

 

Cargo de datos de Cargos internos ocupados dentro de la entidad a fin de vincularlos con el legajo del funcionario.

Datos específicos: Denominación del cargo, Descripción del trabajo. Informes y Reportes:

  • Listado de Cargos Internos por Periodo permitiendo mostrar o no a descripción del trabajo de cada cargo.
  • Listado de Funcionarios por Cargo Interno.

 

 

CATEGORÍAS DE FUNCIONARIOS

Cargo de datos de Categorías disponibles dentro del anexo del personal con todas sus especificaciones correspondientes.

Datos específicos: Código, Valor, Rango de fecha aplicable. Informes y Reportes:

  • Listado de Categorías de Funcionarios vigentes dentro de una fecha establecida.
  • Listado de Funcionarios por Categoría.

 

 

ESTRUCTURA FINANCIERA

Administración de la estructura financiera por Periodo, Tipo de Presupuesto, Programa, Sub-Programa, Proyecto, Producto a fin de vincular el presupuesto con su línea correspondiente.

Datos específicos: Periodo, Tipo de Presupuesto, Programa, Sub-Programa, Proyecto, Producto, Denominación, Afectable al presupuesto si o no.

Informes y Reportes:

  • Listado de estructura financiera por periodo.

 

 

PRESUPUESTO DEL NIVEL 100 POR PERIODO

Carga del presupuesto público asignado al nivel 100 y la de sus eventuales reprogramaciones dejando constancias del presupuesto inicial y actual.

Datos específicos: Periodo, Tipo de Presupuesto, Programa, Sub-Programa, Proyecto, Producto, Objeto del Gasto, Fuente de Financiamiento, Organismo Financiador, Departamento, Monto del presupuesto.

Validaciones específicas:

  • Solo se puede asignar presupuesto a ítems de la estructura que son imputables.
  • Validación de montos mínimos según generación de nóminas ya emitidas.

Informes y Reportes:

  • Listado del presupuesto filtrando por Periodo, TP, PG, SP, PY, PD, OG, FF, OF, DP.
  • Informe de ejecución del presupuesto (Presupuesto menos Nominas ya emitidas)

 

 

TIPO DE CONOCIMIENTOS UTILIZADOS DENTRO DE LA ENTIDAD

Definición de tipo de conocimientos utilizado para la posterior clasificación del legajo académico de los funcionarios. A través de esta clasificación se intenta facilitar la búsqueda de funcionarios de la institución con cierto perfil académico.

Datos específicos: Descripción, Detalle, Nivel Académico. Informes y Reportes:

  • Listado de tipos de conocimientos con cantidad de funcionarios activos dentro de cada grupo, se puede filtrar ítem padre del organigrama y la búsqueda se debe realizar dentro de todos los ítems del organigrama.

 

ADMINISTRACION DE FERIADOS

El sistema deberá poseer en sección de carga de fechas correspondientes a feriados a fin de poder realizar los cálculos de días hábiles cuando así sea necesario.

Datos específicos: Fecha, Motivo del feriado. Informes y Reportes:

  • Listado de feriados dentro de un rango de fecha.

 

 

TIPO DE DOCUMENTOS UTILIZADOS EN LA GESTIÓN DE RRHH

Definición de tipo de documentos utilizados para respaldar situaciones dentro de la gestión de Recursos Humanos, esto se utilizará para su posterior vinculación con los movimientos que requieran un aval documental para ciertos procesos.

Datos específicos: Descripción, Detalle. Informes y Reportes:

  • Listado de tipo de documentos y cantidad utilizada dentro del sistema dentro de sus múltiples tablas/procesos.

 

POSIBILIDAD DE ADMINISTRAR VARIAS SEDES

El sistema debe contar con la posibilidad de administrar varias sedes de la entidad. Todas las secciones del sistema deben actuar bajo el principio de múltiples sedes, pudiendo así generar procesos e informes por sedes.

Datos específicos: Denominación, Departamento, Ciudad, Dirección, Nro. de Teléfono. Informes y Reportes:

  • Listado de sedes de la entidad con sus informaciones correspondientes.
  • Todos los informes del sistema que utilicen datos que se vinculen a sedes deben por ser filtrados por estas sedes.

 

REGISTRO DE RELOJES BIOMÉTRICOS ACTIVOS

Descripción Registro de datos de relojes biométricos activos dentro de la entidad en sus distintas sedes. A través de esta sección se puede tener control total de los equipos a nivel hardware para la realización del control de marcaciones.

Datos específicos: Denominación, Sede, Código, IP, Clave, funcionario responsable, Estado. Informes y Reportes:

  • Listado de relojes con filtro por sede/estado.

 

 

CÓDIGOS DE FUNCIONARIO PARA RELOJES

Administración de códigos por funcionario para cada reloj biométrico. Cada reloj maneja un código único por funcionario, por lo tanto, a través de esta información podemos interpretar la información de los relojes dentro del sistema de RRHH.

Datos específicos: Reloj, funcionario, Estado, Código. Informes y Reportes:

  • Listado de funcionarios por reloj por estado.
  • Listado de funcionarios por reloj mostrando códigos.
  • Listado de relojes activos habilitados por funcionario.

 

 

OBTENCIÓN AUTOMÁTICA DE MARCACIONES DEL RELOJ

El sistema debe obtener de manera automática todos los datos del reloj biométrico. Datos específicos:

  • Reloj.
  • Código de funcionario.
  • Horario de marcación.
  • Horario de importación.

Mecanismos aplicables:

  • Importación de datos del reloj adjuntando el archivo plano generado por el reloj.
  • Importación automática del archivo a través de la red utilizando la IP del reloj.

Trabajos de configuración y desarrollo:

  • Configuración del servidor para la obtención automática de los datos del reloj.
  • Desarrollo de una interfaz de conexión entre el sistema y el reloj. Dicha interfaz podrá variar acorde al modelo del reloj disponible, los lenguajes que se podrán utilizar para el desarrollo de esta interfaz son JAVA o PYTHON.

Validaciones:

  • Se debe validar que no se inserte más de una vez el mismo registro de marcación.
  • Se debe validar la respuesta de los relojes a fin de comunicar la falta de importación de datos.
  • Se debe verificar la correlatividad de fecha y horario de registros de marcación a fin de no importar registros que sigan esta correlatividad.
  • El horario de importación debe ser mayor al de marcación.

Informes y Reportes:

  • Listado de procesos de importación de datos con cantidad de datos importados por proceso.
  • Listado de procesos por estado en proceso/en ejecución/abortados.

 

 

MARCACIONES DE FUNCIONARIOS

El sistema debe contar con una sección especial para la marcación de registros de entrada y salida de funcionarios. En esta sección se debe poder administrar todo lo concerniente a marcaciones tanto a través de los relojes biométricos como de manera manual/planilla.

Datos específicos:

  • Funcionario
  • Reloj
  • Horario de marcación
  • Horario de registro en sistema
  • Modo de registro

 Procesos:

  • Importación automática: Cuando la importación de los datos del reloj se realiza a través de un script automático configurado en el servidor, donde este script se conecta al reloj a través de la red y obtiene los datos de marcación.
  • Importación manual: Cuando el reloj biométrico no posee conexión a la red, por lo tanto se debe extraer el archivo plano del reloj de manera manual. Para este proceso de deberá adjuntar el archivo plano generado por el reloj y hacer correr un proceso a fin de insertar los registros.
  • Carga de planilla: El sistema deberá poseer una ventana de carga rápida de horarios según planilla, donde se exponga en pantalla las fechas de entrada y salida dentro de un rango de fecha para un funcionario, a modo que la carga de la planilla de marcación de un funcionario se pueda realizar de manera rápida y fácil.
  • Carga manual: Carga de registro de entrado o salida de manera manual, seleccionando el funcionario e indicando el horario de marcación, en este caso el sistema debe exigir la carga una documentación respiratoria y observación al respecto. (Se utiliza en caso de que el reloj no haya leído la marcación de algún funcionario u otro caso similar)

Informes y Reportes:

  • Listado de marcaciones de un funcionario dentro del mes.
  • Listado de marcaciones por reloj dentro de un rango de fecha y hora.
  • Listado de marcaciones por tipo.

 

 

TIPO DE PERMISOS CON SUS REGLAS CORRESPONDIENTES

Se deben cargar tipo de permisos permitidos a fin de categorizar los tipos de permisos existentes actualmente y otros que podrían llegar a surgir con el tiempo. Cada tipo de permisos debe cumplir sus reglamentaciones correspondientes indicadas en esta sección.

Datos específicos: Tipo de permisos, detalle de especificaciones genéricas.

Detalle de especificaciones genéricas: El detalle de especificaciones genéricas deberá ser ajustable a exigencias de la institución.

Informes y Reportes:

  • Listado de tipos de permisos.
  • Listado de tipos de permisos con cantidad de días/horas permitidas a través de este tipo de permiso.

 

ANEXO DEL PERSONAL VIGENTE POR PERIODO

Carga del anexo del personal a fin de vincular con cada funcionario nombrado su línea correspondiente al anexo y tener un informe de categorías disponibles.

Datos específicos: Periodo, Categoría, Cargo APN, Línea Presupuestaria, Vigente desde, Vigente hasta, Tipo de línea (Presupuestado, Comisionado, Contratado Jornalero, Contratado Técnico, Contratado Profesional), Estado (Activo/Inactivo), Información de baja de funcionario

Validación específica: Cada funcionario puede tener solo un registro activo. Informes y Reportes:

  • Listado correspondiente al anexo por periodo.
  • Listado de cargos vacantes.
  • Listado por categoría, cargo, línea presupuestaria.
  • Historia del legajo de registros correspondientes al anexo de un funcionario en particular.

 

 

ORGANIGRAMA INSTITUCIONAL RAMIFICADO EN MODO DE ÁRBOL

Carga del organigrama institucional por dependencias. El sistema debe manejar de manera independiente el organigrama institucional al organigrama o estructura financiera, ya que el institucional es el que denota las oficinas y procesos de los funcionarios.

El organigrama institucional no se maneja por periodo, es un organigrama eterno que si posee la posibilidad de decir que un ítem se encuentra activo o inactivo.

Las estructuras del organigrama deben ser en forma de árbol a fin de que el sistema no tenga un límite de niveles para la generación de dependencias relacionales.

Datos específicos: ID Ítem organigrama, Referencia al ítem padre, Nombre de la dependencia, dirección etc., Responsable y/o firmante.

Reglas:

  • Los ítems que no tienen padres van a la cabecera del organigrama.
  • No pueden existir dos ítems con el mismo nombre dentro del mismo padre.
  • No se pueden eliminar padres que poseen registros afectados.
  • No se puede desactivar ítems que poseen funcionarios activos asignados.

Forma de búsqueda:

La búsqueda de los registros se hará teniendo en cuenta el ítem y sus padres. Por lo tanto, si existen un organigrama (ejemplo a continuación):

Entidad (1)

Dirección Administrativa (2)

Informática (3)

Tesorería (4) Dirección de Apoyo (5)

Informática (6)

Comunicación Interna (7)

Donde se busca

  • La cadena: formatic se debe obtener como resultado el ítem 3 y 6.
  • La cadena: formatic direcc adm se debe obtener como resultado solo el ítem 3.

Forma de utilización en filtros de reportes: En todos los sectores del sistema que se hagan referencia a un filtro por dependencia, el sistema debe poseer un checkbox para indicar si:

  • Arrojar como resultado los registros correspondientes solo a ese ítem.
  • Arrojar como resultado los registros correspondientes a ese ítem y los correspondientes a los hijos del mismo ítem.

Informes y Reportes:

  • Mostrar organigrama activo.
  • Mostrar organigrama activo e inactivo.
  • Mostrar organigrama a partir de un ítem
  • Mostrar organigrama a partir de un ítem hasta un nivel de profundidad especificado.

 

 

CARGA DE DATOS GENERALES DE FUNCIONARIOS

El sistema deberá administrar los datos de los funcionarios de la institución.

Datos específicos: CI, Nombre, Apellido, Genero, Fecha de nacimiento, usuario de sistema vinculado a este funcionario, Cta. Cte., Discapacidad, Horario de entrada, Horario de salida.

Archivo adjunto: Foto del funcionario. Validaciones específicas:

  • Solo un funcionario por usuario puede estar vinculado. Relación 1 a 1.

Informes y Reportes:

  • Listado de funcionarios por rango de edad, genero.
  • Listado de funcionarios por tipo de horario de entrada y salida.

 

RESOLUCIONES VINCULADAS A LA GESTIÓN DE RRHH

Carga de resoluciones vinculadas a procesos de Recurso Humano. Se debe poder visualizar una copia digitalizada de las resoluciones que afectan los procesos.

Datos específicos: Nro, Periodo, Descripción, Firmantes. Archivo adjunto: Archivo en formato pdf.

Búsqueda: Se debe buscar tanto por numero como por descripción, se debe listar todos los movimientos que hacen referencia a esta resolución.

Informes y Reportes:

  • Listado de resoluciones por rango de fecha/periodo.
  • Visualización de una resolución.

 

CONTRATOS VIGENTES Y NO VIGENTES VINCULADOS A FUNCIONARIOS

Carga de contratos a fin de vincular con los funcionarios contratados, el sistema debe manejar un estándar de contrato (hasta 3 formatos).

Datos específicos: Nro, Periodo, Funcionario, Vigencia desde/hasta, Tipo de contrato, Resolución vinculada.

Informes y Reportes:

  • Listado de contratos correspondientes a una resolución.
  • Listado de contratos que afectan a un usuario.
  • Listado de contratos por sede.
  • Listado de contratos por dependencia.

 

 

INFORMACIÓN ACADÉMICA DE LOS FUNCIONARIOS

El sistema debe contar con una base de datos detallada de los cursos/capacitaciones/títulos de grado y post grados de sus funcionarios para de esta forma tener conocimiento de sus capacidades internas a fin de ubicar los funcionarios según sus mejores habilidades.

Datos específicos: Funcionario, Tipo de conocimiento, Descripción, Fecha de inicio del curso, Fecha de finalización del curso, Ciudad, País, Institución educadora.

Adjunto: Archivo en formato pdf a fin de adjuntar el titulo/diploma/certificado que avale el grado académico o conocimiento.

Búsqueda: La búsqueda se deberá poder realizar por distintos campos como ser: Tipo de conocimiento, edad, género, sede y otros.

Auto Gestión: La modalidad de auto gestión permite que los propios funcionarios interesados en que su legajo académico se encuentre actualizado puedan auto gestionar la actualización de sus datos a través de un usuario con el cual pueda tener acceso única y exclusivamente a sus datos. Los datos no serán publicados hasta que sea verificado por un usuario autorizado de recursos humanos.

Informes y Reportes:

  • Lisado de funcionarios según resultado de búsqueda.
  • Ranking de tipo de conocimientos de funcionarios.
  • Gráfico de grado académico según filtro seleccionado.

 

INFORMACIÓN ANEXO POR FUNCIONARIO

El sistema debe guardar el historial del funcionario en relación a su anexo de persona. Datos específicos: Los datos específicos son guardados a través del anexo del personal. Informes y Reportes:

  • Listado de la trayectoria y/o asignaciones según anexo del personal en los distintos periodos.

 

INFORMACIÓN DE TRAYECTORIA POR DEPENDENCIA Y CARGO

El sistema debe guardar el historial del funcionario en relación a las dependencias donde ha trabajado y que cargo ha ocupado.

Estos datos se deberán poder cargar desde dos modalidades: 1) A través de la ficha del funcionario. 2) a través del listado general de cargos y dependencias.

Datos específicos: Funcionario, dependencia, cargo interno. Informes y Reportes:

  • Listado de trayectoria en la institución.
  • Listado de funcionarios que han poseído cierto cargo.
  • Listado de funcionario que han pasado por una dependencia.
  • Listado de funcionarios actualmente en una dependencia.

 

ADMINISTRACIÓN DE REMUNERACIONES EXTRAORDINARIAS

El sistema debe generar las planillas correspondientes a Remuneraciones Extraordinarias teniendo en cuenta todos sus cálculos correspondientes.

Datos específicos: Funcionario, Entrada, Salida, Cant. Horas, Fecha, Monto RE generado. Funciones específicas:

  • Tomar los horarios correspondientes a entrada y salida del funcionario para realizar el cálculo.
  • Parametrización de porcentaje o fórmula de cálculo de pago de RE según la entidad.
  • Generar el cálculo de todos los funcionarios tengan o no el beneficio de RE.
  • Solamente generar nómina de los funcionarios que posean el beneficio de RE.
  • Presentar topes de RE al mes.
  • Analizar las horas correspondientes a RE según el horario laboral de cada funcionario.
  • Seguir las normas correspondientes. Ejemplo: Hasta 2 horas diarias, Hasta 8 horas semanales, Hasta 32 horas al mes.
  • Variación de topes mensuales según resolución.
  • Variación de montos a aplicar según disponibilidad presupuestaria.

Informes y Reportes:

  • Generación de planilla de resumen mensual por funcionario (Entrada, Salida, Cantidad de horas trabajas, Cant. Horas RE, Monto correspondiente por día, Sumatoria mensual).
  • Listado de funcionarios que poseen RE generado en el mes.
  • Listado de funcionarios que poseen RE generado en el mes y el beneficio correspondiente por resolución.
  • Generación de cuadro anual por meses de valores asignados a RE por nómina.

 

ADMINISTRACIÓN DE REMUNERACIONES ADICIONALES

El sistema debe generar las planillas correspondientes a Remuneraciones Adicionales teniendo en cuenta todos sus cálculos correspondientes para días hábiles como inhábiles.

Datos específicos: Funcionario, Entrada, Salida, Cant. Horas, Fecha, Monto RA generado, Monto RA día inhábil generado.

Funciones específicas:

  • Tomar los horarios correspondientes a entrada y salida del funcionario para realizar el cálculo.
  • Parametrización de porcentaje o fórmula de cálculo de pago de RA y RA-DI según la entidad.
  • Generar el cálculo de todos los funcionarios tengan o no el beneficio de RA.
  • Solamente generar nómina de los funcionarios que posean el beneficio de RA.
  • Presentar topes de RA al mes.
  • Analizar las horas correspondientes a RA según el horario laboral de cada funcionario.
  • Seguir las normas correspondientes. Ejemplo: El RA comienza a correr a partir de la finalización de la hora aplicable a RE, si el RE ya ha llegado a su tope se tomará como RA si la entidad posee ese criterio.
  • Variación de topes mensuales según resolución.
  • Variación de montos a aplicar según disponibilidad presupuestaria.

Informes y Reportes:

  • Generación de planilla de resumen mensual por funcionario (Entrada, Salida, Cantidad de horas trabajas, Cant. Horas RA, Cant. Horas RA-DI, Monto correspondiente por día para RA y RA-DI, Sumatoria mensual de RA y RA-DI).
  • Listado de funcionarios que poseen RA generado en el mes.
  • Listado de funcionarios que poseen RA generado en el mes y el beneficio correspondiente por resolución.
  • Generación de cuadro anual por meses de valores asignados a RA por nómina.

 

PROCESOS DE GENERACIÓN DE BENEFICIOS POR ANTIGÜEDAD

El sistema debe administrar los beneficios percibidos por Antigüedad según las normativas dictaminadas. Datos específicos: Funcionario, monto aplicable, fecha de inicio de aplicación.

Informes y Reportes:

  • Listado de funcionarios que poseen el beneficio.
  • Listado de funcionarios que deberían poseer el beneficio indicando una fecha específica.

 

ADMINISTRACIÓN DE RESERVAS PARA AGUINALDO

El sistema debe generar informes o alertas sobre la necesidad de fondos para cubrir lo correspondiente a pago de aguinaldo realizando una proyección de gastos a fin de prever con tiempo posibles reprogramaciones. Así también debe presentar una proyección de gastos teniendo en cuenta el último pago realizado a fin de estimar la ejecución ideal por mes y anual.

Datos específicos: Funcionario, periodo, monto. Informes y Reportes:

  • Informe de proyección de pagos de nivel 100 con estimación de ejecución ideal mensual y anual.

 

OTROS BENEFICIOS

El sistema debe permitir la administración de otros tipos de beneficios que puedan percibir los funcionarios.

El sistema debe manejar esta asignación de permisos de una manera parametrizable determinando por cada permiso los parámetros a tener en cuenta para el cálculo correcto de los importes.

Se debe poder cargar beneficios con bonificaciones fijas y porcentuales, indicando dentro de estos beneficios que funcionarios deben percibir este beneficio.

Alguno de los beneficios que se deben de tener en cuenta son: Responsabilidad en el cargo, por hijos, Grado académico, Premio por rendimiento etc.

Datos específicos: Tipo de concepto, descripción, desde, hasta, Obj. del Gasto, tipo (Fijo, Porcentaje, Horas máximas, Funcionarios vinculados, Documento de respaldo)

Informes y Reportes:

  • Listado de beneficios activos/inactivos dentro de rango de fecha.
  • Listado de funcionarios por beneficios dentro de rango de fecha.

 

DESCUENTOS

El sistema deberá poseer una sección de administración de descuentos a ser realizados a los funcionarios por motivos distinto a sanciones por falta en marcación de entrada/salida (Los descuentos que se encuentran dentro de los identificados por una mala marcación de su horario serán contemplados automáticamente dentro de la sección de marcaciones y generación de nómina).

Detalle de funcionalidades

  • Los descuentos se realizarán indicando el tipo de descuento, el monto.
  • Se determinará el listado de funcionarios que debe percibir este descuento.
  • Es sistema debe manejar una prioridad de descuento a ser realizado.
  • El sistema deberá manejar un tope mínimo que debe percibir el funcionario y realizar los descuentos solo hasta ese punto.
  • Los descuentos que no se puedan realizar quedarán pendiente para ser descontados en una siguiente generación de nómina.

Datos específicos: Denominación, Tipo, prioridad, Listado de funcionarios, fecha de inicio de descuento, Valor total a descontar, cantidad de aplicaciones, documento de respaldo.

Informes y Reportes:

  • Listado de descuentos realizados por funcionarios.
  • Listado de descuentos realizados dentro de un rango de fecha.

 

VACACIONES

El sistema deberá poseer calculadores que puedan identificar las vacaciones que le corresponden a cada funcionario.

El cálculo de vacaciones por funcionario se realizará teniendo en cuenta la cantidad de días permitidos según la antigüedad y la cantidad de periodos anteriores que pueden acumular vacaciones pendientes. Datos específicos: funcionario, cantidad total de vacaciones, días tomados.

Informes y Reportes:

  • Reporte individual del estado de vacaciones del funcionario: En este informe se debe indicar:
    • Una cabera con los datos del funcionario.
    • Fecha de ingreso
    • Antigüedad.
    • Cantidad de vacaciones correspondientes
    • Sumatoria de vacaciones tomadas
    • Saldo de vacaciones pendientes
    • Listado de fechas que se han tomado como vacaciones donde su sumatoria debe coincidir con la sumatoria de vacaciones tomadas.
  • Listado e vacaciones tomas: Generar un listado de funcionarios que tomaron vacaciones dentro de un rango de fecha correspondiente.
  • Listado general de vacaciones pendientes por funcionarios.

 

 

 

EMISIÓN DE CERTIFICADO DE TRABAJO

El sistema debe emitir el certificado de trabajo correspondiente con todos los datos del funcionario.

El formato del certificado laboral se debe coordinar con los responsables de RRHH.

Datos específicos mínimos: Nombre, antigüedad, cargo, lugar de trabajo, salario percibido, otros beneficios percibidos.

Informes y Reportes:

  • Generación del comprobante de trabajo en formato PDF.

 

APERCIBIMIENTOS

El sistema debe controlar el comportamiento de los funcionarios entorno a sus marcaciones, generando así la nota correspondiente para el apercibimiento de los funcionarios dentro del plazo establecido.

La nota de apercibimiento será realizada de forma conjunta con los encargados de RRHH. Informes y Reportes:

  • Listado de funcionarios que deben percibir apercibimientos.
  • Generación de nota de apercibimiento en formato pdf (En caso de que varios funcionarios deban recibir un apercibimiento el sistema podrá generan en un solo pdf varias notas de apercibimiento separando uno de otro por hoja)

MULTAS

El sistema debe realizar el control de apercibimientos de manera automática. No obstante estos apercibimientos solo se aplicarán una vez que sea aprobada a resolución correspondiente y sea cargada dentro del sistema.

Los apercibimientos generados serán a través de la nómina, descontando hasta un valor tope correspondiente a lo generado en el cálculo de marcaciones.

Datos específicos: funcionario, mes, tipo de apercibimiento, valor calculado, valor a descontar. Informes y Reportes:

  • Listado de funcionarios con apercibimiento por mes.
  • Listado de apercibimientos por funcionario.

 

NOTIFICACIONES

El sistema deberá manejar una sección correspondiente a notificaciones a funcionarios, donde dentro del sistema se puedan especificar las notificaciones emitidas y recibidas.

Detalle de funcionalidades

  • Se debe visualizar un panel con notificaciones emitidas y recibidas.
  • Las notificaciones se podrán buscar por palabras claves y/o nombre del funcionario.
  • Se podrán adjuntar archivos en formato pdf a fin de tener al archivo digital adjunto al sistema.

Informes y Reportes:

  • Listado de notificaciones recibidas.
  • Listado de notificaciones emitidas.
  • Listado de notificaciones por funcionario.
  • Listado de notificaciones por mes o rango de fecha.

 

GENERACIÓN DE NOMINA

El sistema contará con una sección de generación de nómina. La generación de dicha nómina generará un cierre dentro de los datos de los funcionarios, a fin de que a partir de generar la nómina no se puedan editar ningún registro con fecha menor a esa nómina que afecte a un funcionario involucrado dentro de dicha nómina.

Funcionalidades

  • Generación de planilla de nómina.
  • Generación de txt para transferencia a cuentas según formato exigido por entidades bancarias.
  • Descuento de retenciones de IVA, Renta, Jubilaciones, IPS.
  • Descuento por multas.
  • Debe impactar los descuentos establecidos dentro de la sección descuentos.

Datos específicos: Funcionario, Mes, Rubro, Concepto, tipo de descuento, monto de descuento, estado, monto calculado, monto aplicado.

Informes y Reportes:

  • Generación de nómina según exigencias y estándares teniendo en cuenta un corte de control por estructura presupuestaria.
  • Listado de funcionarios dentro de cada nómina.
  • Listado de nóminas generadas.

 

ESPECIFICACIONES DE LA PLATAFORMA DEL SISTEMA

 

DESCRIPCIÓN GENERAL

El sistema debe estar desarrollado acorde a las últimas tendencias de desarrollo de software para ambiente web. Debe utilizar lenguajes y plataformas que posean una gran cantidad de soporte en línea. La base de dato a ser utilizado debe ser del tipo Open Source y todas las validaciones de datos y lógicas de negocio se debe realizar a través de triggers en base de datos.

La auditoría de registros se debe realizar a través de triggers en las tablas, registrando todos los cambios que se dieron y guardando todos los datos. El almacenamiento de estos datos debe ser en una base de datos distinta a fin de que el backup de auditoria puede ser incremental y el backup de datos una copia o en espejo.

El sistema se debe adecuar totalmente para el acceso a través de Tablets o Smartphone, la navegación debe ser sencilla y el sistema debe correr sin ningún inconveniente sobre los browsers más utilizados.

El sistema debe estar orientado al usuario operador, facilitando en todo momento el mecanismo de carga de datos.

Todos los informes deberán ser emitidos en formato pdf, los informes del tipo listados deberán ser exportables a Excel.

Todos los procesos citados dentro de las especificaciones técnicas deberán formar parte del sistema en general, no necesariamente dentro del módulo en el cual fue expuesta la funcionalidad. Esto a modo de no generar procesos duplicados y/o entornos distintos para la realización de una misma actividad.

La política de acceso a usuarios debe permitir un acceso por roles que podrá ser configurable según las exigencias de la Entidad.

 

ESPECIFICACIONES SOBRE PLATAFORMAS Y METODOS DE PROGRAMACIÓN

Sistema en ambiente web WEB DEVELOPMENT

 

El sistema debe correr en ambiente web utilizando lenguajes con gran cantidad de soporte en línea.

Los códigos deberán ser entregados en su totalidad a la Entidad. Los códigos podrán ser modificados para el uso dentro de la misma entidad/administración, no podrán ser donados ni comercializados a otras entidades o administraciones.

Para los lenguajes compilados será exigido entregar los códigos fuentes correspondientes.

 

Diseño web adaptativo WEB RESPONSIVE

 

El diseño web adaptable (o adaptativo), conocido por las siglas RWD del inglés Responsive Web Design, es una filosofía de diseño y desarrollo cuyo objetivo es adaptar la apariencia de las páginas web al dispositivo que se esté utilizando para visualizarlas. Hoy día las páginas web se visualizan en multitud de dispositivos como tabletas, teléfonos inteligentes, libros electrónicos, portátiles, PCs, etcétera. Además, aún dentro de cada tipo, cada dispositivo tiene sus características concretas: tamaño de pantalla, resolución, potencia de CPU, sistema operativo o capacidad de memoria entre otras. Esta tecnología pretende que, con un único diseño web, se obtenga una visualización adecuada en cualquier dispositivo.

 

Base de datos tipo Open Source

 

El sistema deberá utilizar una base de datos del tipo Open Sorce, la base de datos seleccionada deberá poseer las siguientes características:

  • Una base de datos 100% ACID.
  • Soporta distintos tipos de datos: además del soporte para los tipos base, también soporta datos de tipo fecha, monetarios, elementos gráficos, datos sobre redes (MAC, IP ...), cadenas de bits, etc. También permite la creación de tipos propios.
  • Incluye herencia entre tablas, por lo que a este gestor de bases de datos se le incluye entre los gestores objeto-relacionales.
  • Copias de seguridad en caliente (Online/hot backups)
  • Unicode
  • Juegos de caracteres internacionales
  • Regionalización por columna
  • Multi-Version Concurrency Control (MVCC)
  • Múltiples métodos de autentificación
  • Acceso encriptado vía SSL
  • Completa documentación
  • Licencia BSD
  • Disponible para Linux y UNIX en todas sus variantes (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64) y Windows 32/64bit.

 

Framework de desarrollo

 

El sistema deberá estar desarrollado sobre un "framework" (infraestructura, armazón, marco), en términos generales, un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar.

 

En el desarrollo de software, un framework o infraestructura digital, es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos concretos de software, que puede servir de base para la organización y desarrollo de software. Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes de un proyecto.

El framework utilizado deberá estar entre los más populares y debe contar con una gran cantidad de soporte en línea.

 

Programación en capas

 

Se requerirá de una programación por capas es decir una arquitectura cliente-servidor en el que el objetivo primordial es la separación de la lógica de negocios de la lógica de diseño; un ejemplo básico de esto consiste en separar la capa de datos de la capa de presentación al usuario.

 

La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algún cambio, solo se ataca al nivel requerido sin tener que revisar entre código mezclado.

 

Además, permite distribuir el trabajo de creación de una aplicación por niveles; de este modo, cada grupo de trabajo está totalmente abstraído del resto de niveles, de forma que basta con conocer la API que existe entre niveles.

 

En el diseño de sistemas informáticos actual se suelen usar las arquitecturas multinivel o Programación por capas. En dichas arquitecturas a cada nivel se le confía una misión simple, lo que permite el diseño de arquitecturas escalables (que pueden ampliarse con facilidad en caso de que las necesidades aumenten).

 

Mecanismo de validación de lógica de datos

 

La lógica de datos deberá estar aplicada en la base de datos a través de trigger del tipo before. Todas las tablas del sistema verificarán la lógica de datos a través de triggers. De esta forma se protege los datos, aunque los mismos sean manipulados desde la propia base de datos o insertados desde otro sistema anexo.

 

El sistema deberá prever algún mecanismo que valide que los triggers de validación se encuentren activos. Inclusive si los triggers se desactivasen manualmente el mecanismo deberá activarlos antes de una inserción de datos desde el sistema.

Todas las validaciones realizadas deberán contar con un comentario en el código que explique a grandes rasgos el tipo de validación que se realiza.

 

Método de resguardo de datos

Todos los datos del sistema o de los sistemas que intervengan las especificaciones técnicas sobre las funcionalidades requeridas deberán almacenarse en una única base de datos. Esto hará posible que, si varios sectores del sistema utilizan una misma información, puedan nutrir un único lugar de carga de datos y así todas estas secciones trabajar de manera cooperativa para la generación y edición de datos.

 

CONTROL DE ACCESO

Políticas de acceso a las secciones del sistema

 

El acceso a las secciones del sistema será asignado por roles que englobaran permisos. El sistema tendrá un listado general de permisos sobre cada sección del sistema que permita:

  • Consultar datos
  • Consultar y editar datos
  • Consultar, editar y confirmar datos.
  • Consultar, des confirmar datos.

Se podrán crear roles nuevos con la combinación de permisos que se desea.

Los usuarios no se podrán asignar directamente a permisos, se deberán vincularán únicamente a roles. Pudiéndose vincular a uno o más roles.

Los usuarios tendrán una propiedad de usuario activo (SI/NO), solo podrán acceder al sistema los usuarios activos SI.

Las creaciones de roles y asignaciones de los mismos deberán ser registrados en la tabla de auditoria de datos.

 

Políticas de clave de acceso

 

Políticas de claves de acceso configurables. Se podrá configurar en el sistema el nivel de seguridad exigido al usuario al momento de ingresar una nueva contraseña. Entre los tipos de configuración que se podrán seleccionar están:

  • Nivel bajo: mayor o igual a cinco caracteres.
  • Nivel básico: mayor o igual a ocho caracteres.
  • Nivel medio: mayor o igual a doce caracteres con al menos una mayúscula y minúscula.
  • Nivel alto: mayor o igual a doce caracteres con al menos una mayúscula, minúscula y signo (¡@#$%^&*()_+=[]|\).

El sistema permitirá configurar una periodicidad para el cambio de la clave de acceso, donde por ejemplo el valor 60 (sesenta) forzará a los usuarios a actualizar su clave cada 60 días y el valor 0 (cero) determinará que no se solicitará reasignar la clave en ningún momento.

En el caso de contar con servidor LDAP, el sistema podrá corroborar su clave de acceso contra el mismo.

 

MECANISMO DE AUDITORIA DE DATOS Y BACKUP

 

Mecanismo de auditoría

 

La auditoría de registros se hará en la base de datos a través de triggers del tipo after. El mecanismo de auditoría será realizado en paralelo de dos maneras:

    1. Registro de los datos nuevos, modificados o viejos más usuario que realizo el cambio (usuario de base de datos y usuario del sistema), ip del cliente, aplicación (Sistema o Administrador de Base de Datos ej. PgAdmin), ID de transacción, Tipo de operación (INSERT, UPDATE, DELETE), fecha.
    2. Todas las tablas deberán contar con campos donde se deberán guardar el usuario y la fecha de creación y última modificación del registro.

El sistema debe poseer un mecanismo de validación de activación de todos los triggers de validación con cada conexión a la base de datos, evitando así problemas por desactivación intencional o involuntaria de los triggers de validación.

 

Almacenamiento de auditoría

Los registros de auditoría deberán ser almacenados de forma definitiva en una base de datos distinta a la base de datos del sistema en sí, esto por un lado alivianará el tamaño de la base de datos operativa y hará más fácil el backup de datos. Tanto de los datos de auditoria como los datos del sistema. Con esta estructura de base de datos permitimos que los backups de auditoria sean por el mecanismo incremental.

 

Políticas de Backup

 

El sistema tendrá un mecanismo propio de backup de base de datos y archivos fuentes. El sistema deberá tener una ventana de configuración, la ventana de configuración deberá permitir lo siguiente:

  • Periodicidad de tiempo para correr los procesos.
  • Destino de los archivos.
  • Tipo de backup:
    • Base de datos de datos operativos.
    • Base de datos de auditoria.
    • Archivos adjuntos.
    • Archivos fuentes de las secciones operativas.
    • Archivos fuentes de todo el sistema.
    • Completo.
  • Compresión de datos (SI/NO)

Se podrán agregar varias reglas permitiendo así en resguardo de los archivos en diferentes directorios y periodicidades distintas según el tipo de backup.

 

HERRAMIENTAS Y METODOS QUE DEBE CONTAR EL SISTEMA

Mecanismo de notificaciones

 

El sistema deberá contar con un mecanismo de notificaciones que trabaje con distintos tipos de eventos. Las notificaciones deberán aparecer al usuario dando la opción de:

  • Volver a notificar en 1 día.
  • Volver a notificar en 3 días.
  • Volver a notificar en 1 semana.
  • Volver a notificar en 15 días.
  • Volver a notificar en 1 mes.

Las notificaciones deberán aparecer sobre el entorno de trabajo en el que se encuentre el usuario. Las notificaciones y respuestas sobre las mismas serán registradas por usuarios.

 

Configuración de firmantes de reportes

 

Los firmantes de los reportes podrán ser configurables, se podrán determinar ciertos tipos de firmantes para ciertos tipos de reportes a ser definidos por la entidad.

 

Navegabilidad dentro del sistema

 

El sistema requerirá de una navegación fácil y rápida entre sus ventanas, otorgando al usuario operador facilidades al momento de la carga de datos.

Características principales:

  • Todo el sistema deberá poder ser navegable sin la utilización del mouse.
  • Se crearán combinaciones de teclas para un acceso directo a:
    • Ir al panel principal
    • Ir al menú principal
    • Ir a las opciones
    • Agregar un registro
    • Realizar una búsqueda
  • Los listados deberán ser navegables utilizando las fechas de arriba, abajo, derecha e izquierda.

Mecanismo de importación de datos

 

Todas las tablas de base de datos que utilicen datos de gestión operativas deberán contar con la opción de importar datos directamente desde el sistema, se podrá importar adjunto un archivo o copiado y pegando la información en un textarea.

Cada tabla o sección de importación deberá indicar al usuario cual es el formato requerido para la importación de datos.

Los formatos habilitados para la importación de datos serán:

  • Separado por tabulaciones.
  • Separado por ; (punto y coma).

 

Exportación de informes del tipo listado a formato Excel

 

Todos los reportes que generen como resultado principal un listado de datos deberá tener la opción de ser exportados a formato Excel.

Los archivos creados deberán tener la extensión xls o xlsx. Deberán abrirse en Excel sin ninguna advertencia por tipo de archivo o datos.

 

Envío en informes por e-mail directamente desde el servidor

 

Todos los reportes en PDF que genere el sistema deberán tener la opción de poder ser enviados por email, también se podrán configurar:

  • Momento de envío:
    • Envío inmediato.
    • Definir fecha de envió.
  • Destinatario
    • Mi usuario
    • Ingresar e-mail (se podrán ingresar varias cuentas de emails separados por ; punto y coma)

Los reportes que serán enviados en una fecha distinta a la actual deberán reflejar los datos que posee el sistema al momento que se indica en la fecha de envío.

 

Se generará un listado de todos los envíos pendientes, el usuario que posea permiso para ver todos los envíos pendientes y cada usuario que generó el envío podrá visualizar, reconfigurar y eliminar los envíos de informes.

 

Se requerirá de la configuración del sistema a una cuenta de e-mail institucional de manera segura y respetando todas las políticas generales para no ser detectados como spam.

 

Formularios del tipo carga rápida

 

Todos los formularios de inserción de información al sistema deben tener la opción de carga rápida. Damos a entender por carga rápida un mecanismo por el cual:

  • Solo sea necesario la utilización del teclado.
  • El orden de tabulaciones sea correlativo.
  • El sistema no debe volver al listado con cada registro cargado, solo deberá limpiar los campos y posicionar en cursor en el primer campo.
  • Se puedan seleccionar que datos serán idénticos durante la carga para que el sistema no borre esa información de los campos con cada inserción de registro.

 

Modo de presentación de listados y búsqueda de datos

La presentación de los listados de datos de secciones deberá tener en cuenta los siguientes puntos:

  • Mostrar el total de registros, en caso de datos filtrados se deberá mostrar el total de registros que coincidan con el filtro.
  • Poder ir al último registro con una acción.
  • Buscador por varias columnas de datos de manera independiente.

Mecanismo de selección de campos relacionados

Dentro de formularios de inserción y edición de datos poseemos ciertos datos que van vinculados con otros datos ya cargados en el sistema. Por lo tanto, en estos casos se debe seleccionar el valor al cual se hará referencia.

 

Para estos casos el sistema se deberá adecuar al siguiente mecanismo:

  • Lista desplegable de opciones a seleccionar mientras se va escribiendo la información.
  • Se podrá navegar entre las opciones a seleccionar con la fecha de arriba y abajo.
  • Con un click se seleccionará el dato indicado.
  • Si no existe el campo vinculado, deberá aparecer una opción para agregar un nuevo registro en la tabla vinculada, luego de agregar el registro se deberá regresar a la vista con todos los datos que ya se habían cargado más el nuevo registro creado. (Este mecanismo debe eliminar el problema de salir a agregar registros para continuar. Ejemplo del problema existente sin este mecanismo: Al agregar un registro y no existe el proveedor vinculado, debemos salir agregar el proveedor y volver a ingresar a la sección de carga).
  • Opción de ir a la vista del listado de la sección de referencia a seleccionar y buscar el registro según los parámetros de búsqueda especificados en el Modo de presentación de listados y búsqueda de datos.
  •  

Mecanismo de upload de archivos y fotos

El mecanismo de upload de fotos y archivos genera en gran medida problemas y retrasos al momento de carga de datos, por lo tanto, las características que debe cumplir el mecanismo son las siguientes:

  • Realizar el upload en segundo plano (Ejemplo: AJAX).
  • Se deberá poder seguir cargando datos al formulario durante la carga del archivo adjunto.
  • Se podrá adjuntar un archivo arrastrando desde una carpeta del sistema operativo del cliente hasta la opción de adjuntar.
  • Se deberá mostrar el progreso de subida de archivos en porcentaje.

El almacenamiento de los archivos deberá seguir las siguientes pautas de orden y seguridad:

  • Los archivos deberán ser guardados de manera ordenada en una carpeta dentro del servidor.
  • La carpeta que contendrá los archivos no debe encontrarse en un directorio visible o público.
  • El acceso al archivo será a través de un intérprete.
  • No se podrá acceder/descargar a los archivos sin estar logueados en el sistema.
  • La base de datos solo almacenará la ruta del archivo.

Vista previa de los pdf’s adjuntos

Los archivos adjuntos en formato pdf deberán tener la propiedad de poseer una vista previa en formato jpg de la primera página del pdf.

Firma digital

Sistema de aplicación de firma digital con la utilización de TOKEN: El sistema deberá contar con un sistema para la utilización de firma digital. Permitiendo a los usuarios firmar documentos en pdf generados en el sistema, estos documentos se deberán guardar en el servidor con la posibilidad de descarga. Cada uno de estos documentos podrá poseer una o varias firmas digitales. Todas estas firmas deberán ser realizadas por el usuario sin la necesidad de descargar el archivo para firmarlo en Acrobat Reader u otro software similar, el proceso de la firma se deberá realizar principalmente para el usuario dentro del ambiente web del sistema. Deberá existir una sección especial del sistema donde se encuentre el listado de todos los pdfs que fueron firmados a través del sistema. Este listado deberá emitir informes y deberá poder ser filtrados según parámetros como: rango de fecha, firmantes, tipo de documentos etc.

 

Sistema de impresión directa desde el sistema en impresoras conectadas al equipo de usuario Consiste en un mecanismo donde el usuario pueda configurar dentro del entorno web del sistema en que impresora conectada a su equipo desea imprimir que reporte. El objetivo final del mismo es facilitar el proceso de impresión directa con teclas como P o combinaciones de tecla. Generando así la funcionalidad de imprimir comprobantes de ingresos u otros documentos de manera directa sin la necesidad de recurrir a abrir el pdf e ir a las opciones de imprimir desde visualizador del pdf.

 

Generación dinámica de reportes de todos los listados del sistema

Todos los listados del sistema y tablas de base de datos deben generar una vista donde se puedan seleccionar que columnas mostrar o no, dentro del entorno del sistema (generación pdf y exportación a Excel), se deberá poder filtrar datos, agregar comentarios, firmantes. Configurar la impresión del reporte en formato horizontal o vertical. Se podrá modificar el orden de los datos del listado según distintas lógicas.

 

APLICACIONES QUE DEBEN CORRER CON EL SISTEMA

Aplicación para upload directo de fotos y pdf´s

 

El sistema requerirá de una aplicación que facilite el mecanismo para adjuntar imágenes y pdfs al sistema. Funcionalidad general

La aplicación deberá estar disponible para Android. Se encargará de facilitar el proceso de vincular las imágenes tomadas con el dispositivo y vincularlas con el registro correspondiente en el sistema.

 

Si el registro requiere de un archivo pdf, la aplicación deberá transformar la imagen o secuencias de imágenes en un archivo pdf con unas o varias páginas según la cantidad de imágenes tomadas en la secuencia.

 

Funcionalidades específicas

  • Aplicación disponible para sistemas operativos Android. (Desarrollado preferentemente con JAVA)
  • Requerirá de un control de acceso por usuario.
  • El control de acceso por usuarios utilizará el mismo usuario y clave del sistema, y se regirá por los privilegios de roles indicados en el sistema.
  • Se podrán procesar:
    • Fotos tomadas con la cámara.
    • Foto de la galería de imágenes.
    • Archivo pdf existente en el directorio del dispositivo.
  • El resultado final que deben generar los procesos de la aplicación y el sistema son:

o En el caso de requerir una imagen: Generar un archivo jpg y mostrar el archivo en la ventana donde se vincula los archivos.

o En el caso de requerir un pdf: Generar un archivo pdf y mostrar el archivo en la ventana donde se vincula los archivos.

  • El sistema debe poder generar un pdf de las imágenes tomadas.
  • El sistema deberá adjuntar primeramente un archivo pequeño y luego ejecutar en segundo plano el proceso para subir al servidor el archivo original. El proceso de carga dentro del sistema ya se podrá proseguir con el archivo pequeño adjunto en el servidor.
  • Se deberá mostrar o consultar los procesos de upload de datos al servidor que se encuentran pendientes y los últimos realizados.

 

Aplicación de calendario y notificaciones

 

El sistema requerirá de una aplicación donde los usuarios pueden visualizar el calendario de actividades en su Smartphone y recibir las mismas notificaciones que figuran en el sistema.

 

Funcionalidad general

La aplicación deberá estar disponible para Android. Tendrá como principal objetivo el de mantener al tanto a los funcionarios sobre las actividades vinculadas a su trabajo y principalmente procesos del sistema.

 

Funcionalidades específicas

  • Aplicación disponible para sistemas operativos Android. (Desarrollado preferentemente con JAVA)
  • Requerirá de un control de acceso por usuario.
  • El control de acceso por usuarios utilizará el mismo usuario y clave del sistema, y se regirá por los privilegios de roles indicados en el sistema.
  • Se mostrará la misma información de eventos que figura en el sistema con su usuario.
  • Deberá generar notificaciones en su Smartphone o Tablet cuando sea requerido según el plazo establecido en el sistema de notificaciones. Las repuestas realizadas en la aplicación tendrán el mismo valor que las respuestas realizadas en el sistema.

 

GARANTIA Y SOPORTE

 

Garantía

 

El sistema debe contar con una garantía de 2 (dos) años sobres las funcionalidades establecidas dentro del pliego de base y condiciones.

El plazo de garantía se dará por iniciado con la conformidad de los trabajos asignados.

 

Soporte

 

El soporte técnico será por un plazo de 2 (dos) años contados a partir de la fecha de vigencia del contrato. El soporte será realizado preferente de manera remota para los casos que así lo permita. Caso contrario un técnico de la empresa se deberá presentarse en un plazo no mayor a 3 días hábiles.

Se podrá disponer hasta 2 (dos) presencias inmediatas por mes. Se entiende por presencia inmediata la condición de presentarse en el mismo día del requerimiento; y para los casos que la solicitud haya sido en horarios posterior al medio día, el proveedor podrá presentarse hasta el mediodía del día hábil siguiente.

 

MANUALES Y TUTORIALES

 

Manual de usuario operador

 

El manual de usuarios operador debe abarcar todas las funcionalidades establecidas en las especificaciones del Pliego de Base y Condiciones. Deberá poseer un índice ordenado de los procesos que compone el manual. Se deberá entregar el manual en versión impresa y el sistema también debe contar con una versión digital que pueda ser accedido desde el mismo sistema.

Identificación de la unidad solicitante y justificaciones

  • DIRECCION GENERAL DE GESTION Y DESARROLLO DE LAS PERSONAS DE LA GOBERNACION DEL DEPARTAMENTO CENTRAL
  • Contar con un sistema de Software con capacidad de facilitar y mejorar el trabajo de la Dirección General de Gestión y Desarrollo de las Personas  de  de la Gobernación del Departamento Central.
  • Se trata de un llamado que responde a una necesidad temporal.
  • Las especificaciones establecidas, se realizaron de acuerdo a la necesidad de la Institución.

Plan de entrega de los bienes

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 indicados a continuación: 

 

Item

 

Descripción del Bien

 

Cantidad

 

Unidad de medida

Lugar de entrega de los Bienes

Fecha(s) final(es) de Ejecución de los Bienes

 

1

ADQUISICION DE SOFTWARE PARA LA GOBERNACION DEL DEPARTAMENTO CENTRAL

1

UNIDAD

GOBERNACION DEL DEPARTAMENTO CENTRAL  RAMAL CAPIATA - AREGUA KM 4  

90 DIAS DESDE LA RECEPCION DE LA ORDEN DE COMPRA

 

 

 

 

 

 

 

 

 

 

 

 

Planos y diseños

Para la presente contratación se pone a disposición los siguientes planos o diseños:

No aplica

Embalajes y documentos

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

Inspecciones y pruebas

Las inspecciones y pruebas serán como se indica a continuación:

Las inspecciones y pruebas serán como se indica a continuación: La Dirección de Informática acompañado de la dependencia afectada a la implementación del módulo realizará un seguimiento diario a los procesos realizados por el proveedor en todo el periodo de implementación a los efectos de verificar el cumplimiento con las especificaciones técnicas.

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 al 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.

Indicadores de Cumplimiento

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)

Orden de Compra / Acta de recepción Orden de Compra / Acta de recepción

Informe de cumplimiento de Servicio

Criterios de Adjudicación

La Convocante adjudicará el contrato al oferente cuya oferta haya sido evaluada como la más baja y cumpla sustancialmente con los requisitos de la carta de invitación, 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  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.

Notificaciones

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.

 

Audiencia Informativa

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.

Documentación requerida para la firma del contrato

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.

 

  1. Personas Físicas / Jurídicas
  • Certificado de no encontrarse en quiebra o en convocatoria de acreedores expedido por la Dirección General de Registros Públicos;
  • Certificado de no hallarse en interdicción judicial expedido por la Dirección General de Registros Públicos;
  • Constancia de no adeudar aporte obrero patronal expedida por el Instituto de Previsión Social;
  • Certificado laboral vigente expedido por la Dirección de Obrero Patronal dependiente del Viceministerio de Trabajo, siempre que el sujeto esté obligado a contar con el mismo, de conformidad a la reglamentación pertinente - CPS;
  • En el caso que suscriba el contrato otra persona en su representación, acompañar poder suficiente del apoderado para asumir todas las obligaciones emergentes del contrato hasta su terminación;
  • Certificado de cumplimiento tributario vigente a la firma del contrato.

       2. Documentos. Consorcios

  • Cada integrante del consorcio que sea una persona física o jurídica deberá presentar los documentos requeridos para oferentes individuales especificados en los apartados precedentes.
  • Original o fotocopia del consorcio constituido.
  • Documentos que acrediten las facultades del firmante del contrato para comprometer solidariamente al consorcio.
  • En el caso que suscriba el contrato otra persona en su representación, acompañar poder suficiente del apoderado para asumir todas las obligaciones emergentes del contrato hasta su terminación.