El Suministro deberá incluir todos aquellos ítems que no hubiesen sido expresamente indicados en la presente sección, pero que pueda inferirse razonablemente que son necesarios para satisfacer el requisito de suministro indicado, por lo tanto, dichos bienes y servicios serán suministrados por el Proveedor como si hubiesen sido expresamente mencionados, salvo disposición contraria en el Contrato.

Los bienes y servicios suministrados deberán ajustarse a las especificaciones técnicas y las normas estipuladas en este apartado. En caso de que no se haga referencia a una norma aplicable, la norma será aquella que resulte equivalente o superior a las normas oficiales de la República del Paraguay. Cualquier cambio de dichos códigos o normas durante la ejecución del contrato se aplicará solamente con la aprobación de la contratante y dicho cambio se regirá de conformidad a la cláusula de adendas y cambios.

El Proveedor tendrá derecho a rehusar responsabilidad por cualquier diseño, dato, plano, especificación u otro documento, o por cualquier modificación proporcionada o diseñada por o en nombre de la Contratante, mediante notificación a la misma de dicho rechazo.

ESPECIFICACIONES TÉCNICAS

 

Descripción General:

El sistema está 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ógica 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 la copia de seguridad 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 Tablet 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.

Las políticas de acceso a usuarios deben permitir un acceso por roles que podrá ser configurable según las exigencias de la Entidad.

Los usuarios y todos los datos de este, serán los provistos por el Servidor LDAP con el que cuente el Instituto.

 

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 institución. Los códigos podrán ser modificados para el uso dentro de la misma institución, y no podrán ser donados ni comercializados a otras entidades.

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

Diseño web adaptativo WEB RESPONSIVE:

Diseño web adaptable (o adaptativo), RWD, con el 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, PC’s, 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. La visualización del sistema debe tener un único diseño web con una visualización adecuada en cualquier dispositivo.

Base de datos tipo Open Source:

El sistema utiliza una base de datos del tipo Open Source, la base de datos seleccionada posee 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 Windows 32/64bit.

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 triggers 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 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, desconfirmar 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.

Las creaciones de roles y asignaciones de estos deberán ser registrados en la tabla de auditoría de datos.

Políticas de Clave de Acceso:

El sistema deberá corroborar su clave de acceso contra el servidor LDP, con 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.

 

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:

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.

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 la copia de seguridad 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 auditoría.
• 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.

Vulnerabilidades Detectadas:

En caso de detección de vulnerabilidades en cualquier etapa del proyecto, el mismo debe ser corregido en un plazo no mayor a 30 días, sin que esto implique gastos adicionales por parte del Instituto.

 

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 o 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 ratón.

 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 text área.

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, como:

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 debería poder 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 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.

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 clic se seleccionará el dato indicado.

•             Si no existe el campo vinculado, deberá aparecer una opción para agregar nuevo registro en la tabla vinculada, luego de agregar el registro 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.

Conexión con otros Sistemas:

El sistema debe tener la posibilidad de poder conectarse a otros sistemas de control interno como el ERP-ODOO, con el objetivo de facilitar los controles y seguimientos de los procesos realizados permitiendo una funcionalidad entre ambos sistemas, innovando y obteniendo toda la información centralizada mediante este mecanismo.

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:

El sistema deberá poseer de una aplicación que facilite el mecanismo para adjuntar imágenes y pdf al sistema. 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.

Funcionalidad General:

La aplicación debe 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).

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:

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

•             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 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 deberá poseer 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 terminales.

 

DATACENTER E INFRAESTRUCTURA

 

El sistema deberá poseer una conexión al software mediante servicios de internet por medio de un navegador web, se puede utilizar Mozilla Firefox o Chrome como navegadores. Se requieren únicamente de conexión a internet, navegador web y sus credenciales de acceso para la utilización del software.

 

GARANTIA, SOPORTE E IMPLEMENTACION

Garantía:

El sistema debe contar con garantía de 2 (dos) años sobre las funcionalidades establecidas dentro del pliego de base y condiciones. El plazo de garantía se dará por iniciado con la conformidad de las áreas involucradas y el área TI, en los trabajos asignados o módulos implementados.

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, pero en caso de urgencias, se deberá contar con un técnico de la empresa de forma presencia inmediata, pudiendo disponer de hasta 4 (cuatro) presencias inmediatas por mes. Se entiende por presencia inmediata la condición de presentarse en el mismo día del requerimiento.

Implementación:

El soporte técnico será por un plazo de 2 (dos) años contados a partir de la fecha de vigencia del contrato. El esta etapa, se requerirá de la presencia de al menos 2 (dos) Técnicos por modulo para la implementación y migración de datos, de lunes a viernes de 7 a 15 Hrs, a excepción de feriados y asuetos.

El oferente deberá presentar un cronograma propuesto de actividades de todas las etapas desde el inicio hasta la implementación y posterior capacitación al área técnica.

 

MANUALES, TUTORIALES Y CAPACITACIONES

 

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.

Video Tutoriales:

Todas las secciones indicadas en el manual de usuarios deberán contar con un video tutorial explicativo que formará parte de cada sección de manual usuarios para su versión accesible desde el sistema.

Capacitaciones:

Posterior a la implementación y ajustes, se deberá realizar capacitaciones a los operarios de forma general y especifica de los módulos a ser llevado a producción, tantas veces sean necesario.

Se requerirá también la retroalimentación de al menos 2 (dos) veces por año por modulo, durante la vigencia del contrato.

Se requerirá la capacitación y retroalimentación para el área Administrativa y TI.

 

MODULOS REQUERIDOS

 

A continuación, se describe las funcionalidades específicas de los sistemas requeridos. No obstante, estos no deberán ser 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 citadas dentro de las siguientes especificaciones.

 

Gestión Documental y Seguimiento de Expediente

Tiene como principal objetivo el de organizar y documentar el proceso de todos los expedientes y/o documentaciones dentro de la institución. Del mismo modo también debe brindar a los usuarios y directores información gerencial sobre la situación de los trámites por dependencia y a nivel general, teniendo en cuenta tipo de trámites, plazos asignados, prioridades etc.

El sistema deberá contemplar todos los datos generales del documento, lleva un control del flujo y funcionarios que tuvieron intervención en sus trámites, realiza actualizaciones como:

•             Reordenar ítems del menú y generar un entorno propio

•             El módulo si bien debe ser parte integral del sistema SIRA, deberá ser reorganizado para presentarse en un entorno específico a sus funciones, esto a fin de facilitar el acceso y el entendimiento sobre las funciones específicas por parte de los usuarios.

•             Panel principal específico del módulo con datos gerenciales.

Informaciones requeridas:

•             Acceso a secciones más utilizadas del sistema. Ej.: Recepción de expedientes, Salida de Expedientes, Expedientes en mi dependencia.

•             Acceso a búsqueda de expedientes.

•             Gráfico de torta de tipos de expedientes que ingresan a la dependencia.

•             Informes estadísticos:

•             Tiempo promedio de expedientes en la dependencia.

•             Expedientes fuera del rango de tiempo.

•             Expedientes en bandeja de entrada/salida.

•             Listado de últimos expedientes recibidos y enviados.

•             Porcentaje de expedientes en tiempo.

•             Porcentaje de expedientes recibidos en la semana.

•             Presentación en modo transición.

La presentación en modo transición consiste en la generación de un mecanismo donde se puedan seleccionar uno o varios datos/gráficos que figuran en el panel principal y estos puedan ser expuestos de manera dinámica en el monitor del usuario. Estará enfocado principalmente para ser visualizado en pantallas de gran tamaño (32 pulg. o superiores) dispuestos en puntos claves para demostrar el proceso de la gestión.

Generación de recorridos por tipo de expedientes:

•             El sistema permite establecer flujos/recorridos predeterminados por tipos de expedientes. Los tipos de recorridos se vincularán a tipos de expedientes, pudiendo un mismo tipo de recorrido estar vinculados a varios tipos de expedientes y así mismo un tipo de expediente estar vinculado a varios tipos de recorridos.

•             El sistema utiliza este recorrido para poder generar informes estadísticos sobre el avance porcentual del expediente. Así mismo brindará un mayor entendimiento del flujo completo de las actividades de la institución.

•             El expediente utilizará como guía el recorrido vinculado, se podrá configurar que los expedientes puedan respetar o no este flujo de actividades. La propiedad de respetar o no el flujo del proceso podrá ser configurado tanto en la configuración del tipo de recorrido como en el expediente en cuestión.

 Configuración de tiempos máximos por tipo de expedientes y dependencias:

Se podrán configurar tiempos máximos de espera por cada tipo de expediente para cada dependencia. Se configurarán dos lapsos de tiempo por tipo de expediente:

•             Plazo atrasado.

•             Plazo muy atrasado.

Esta propiedad será utilizada para generar informes y alertas sobre la situación de expedientes.

Configuración de alertas y notificaciones:

El sistema emite alertas y notificaciones vinculadas a los expedientes. Las alertas y notificaciones que emite el sistema son:

•             Expediente atrasado.

•             Expediente muy atrasado.

•             Semanalmente la cantidad total de expedientes atrasados.

•             Semanalmente la cantidad total de expedientes muy atrasados.

Implementación de sistema de impresión rápida y automática:

El sistema puede imprimir comprobantes de movimientos de manera automática. La impresión automática consiste en el mecanismo de que el propio sistema envíe la petición de impresión a la impresora sin la necesidad de ir al menú>archivo>imprimir>aceptar o ctr+p>aceptar. Este mecanismo debe ayudar a agilizar el proceso de recepción de expedientes en todas las dependencias.

Mecanismo de acción de la aplicación:

•             Recepción del expediente.

•             Ingreso a la APP

•             Escaneo del código de barra

•             Mensaje de confirmación de recepción

•             Impresión automática en impresora vinculada al usuario.

La impresión deberá salir de manera automática sin indicar que desea imprimir. Esta solicitud de impresión será lanzada automáticamente desde un equipo conectado a la red (equipo del usuario o servidor del sistema).

Mecanismo de recepción rápida a través de smartphones:

Se requerirá de la creación de una APP (ANDROID) para la recepción rápida con impresión automática de comprobante de recepción.

Mecanismo de acción de la aplicación:

- Recepción del expediente.

- Ingreso a la APP

- Escaneo del código de barra

- Mensaje de confirmación de recepción

- Impresión automática en impresora vinculada al usuario.

La impresión deberá salir de manera automática sin indicar que desea imprimir. Esta solicitud de impresión será lanzada automáticamente desde un equipo conectado a la red (equipo del usuario o servidor del sistema).

Optimización de búsqueda de expedientes:

Se podrá buscar expedientes por todos los tipos de datos establecidos en la cabecera del expediente, inclusive si estos datos fuesen propios del tipo de expediente.

Aparte se podrá buscar por:

•             Rango de fecha de creación y de movimiento.

•             Dependencia generadora del expediente

•             Dependencia por donde ha pasado el expediente

•             Usuario que ha realizado el movimiento

Los campos donde se introducirán los valores de búsqueda deberán ser independientes para cada tipo de dato.

Optimización de reportes:

•             Optimización de filtros de reportes actuales y reordenamiento de los datos por columnas.

•             Implementación de consulta por código QR.

•             Implementación de código QR vinculado al expediente. Las nuevas carátulas generadas a través del sistema tendrán un código QR que enviará a una dirección donde se podrá ver toda la información del expediente y sus movimientos a través del tiempo.

•             Implementación de sistema de ingreso/egreso por código de barra

•             Se podrán registrar los movimientos de los expedientes utilizando un lector de código de barras. El mecanismo deberá agilizar el proceso de carga de datos.

•             Se podrá configurar para que la impresión del comprobante de recepción sea emitida de manera automática.

•             Rediseño del comprobante de recepción de expedientes.

•             Se planteará un rediseño del comprobante de recepción de expedientes a fin de optimizar la utilización de los recursos de la institución.

Vinculación de los expedientes con los demás módulos del sistema:

El sistema vinculará los procesos registrados en otros módulos vinculando este proceso al expediente. Esta vinculación deberá permitir tener acceso a informes y/o procesos financieros registrados en el sistema que conciernan al expediente en cuestión.

Informes estadísticos:

El sistema emite informes estadísticos sobre la situación general de los expedientes, teniendo en cuenta los plazos máximos determinados.

El informe podrá ser filtrado por:

•             Dependencia (campo obligatorio)

•             Dependencias internas (SI/NO)

•             Tipo de expediente (Dejando en blanco hace referencia a todos los tipos)

•             Rango de fecha

•             Recorridos independientes de un mismo expediente

•             Generación de recorridos independientes para un mismo expediente, indicando cada una de las disgregaciones con siglas que serán indicadas luego del nro. de expediente.

Aplicación de permisos exclusivos por tipo de expedientes:

Aplicación de permisos exclusivos para ciertos tipos de expedientes.

Secretaria General:

Abarcará los procesos requeridos para la generación y registración de resoluciones. Así como de documentaciones relacionadas a esta dependencia.

Acciones y procesos principales:

- Seguimiento de estado de resoluciones.

- Registración de resoluciones.

- Generación de resoluciones y otras notas según formato.

- Autoadministración de formatos a través de plantillas del tipo word.

- Recepción de pedidos de las dependencias.

- Registro y Generación de la Entrada.

- La Autoridad designa quien realizara el trabajo.

- Funcionario que realizara el trabajo debe tener posibilidad de contestar.

- Posibilidad de dejar un historial de Versiones y Correcciones del Expediente.

- Una vez terminado el proceso administrativo asentar número y fecha de Resolución, Nota o Decreto.

- Escanear y Adjuntar el Expediente.

- Remitir a la Dependencia de Destino.

- Registro y Recepción de Seguimiento, registración y generación de resoluciones y otras notas según formatos autoadministrables por los usuarios del sistema.

- Trazabilidad y Búsqueda General del Expediente.

- Aplicación de permisos exclusivos para ciertos tipos de expedientes.

- Aplicación de Tipos de Seguridad Informática: Marca de Agua, Control de Consultas de Expedientes y Descarga de Archivo.

- Desarrollo de reportes según necesidad conforme a los procesos demostrados.

- Trazabilidad y Búsqueda General del Expediente.

Procesos vinculados con gestión de archivos:

- Referente a todas las documentaciones firmadas por la máxima autoridad (Redacción y Estructuración de Proyectos de Notas, Resoluciones, Decretos, Leyes, Convenios).

- Escaneado con todos sus antecedentes: Documentos, Imágenes, Videos.

- Carga en el Sistema.

- Capacidad de carga de todo tipo de archivos.

- Trazabilidad y Búsqueda General del Expediente.

- Aplicación de permisos exclusivos para ciertos tipos de expedientes.

- Aplicación de Tipos de Seguridad Informática: Marca de Agua, Control de Consultas de Expedientes y Descarga de Archivo.

- Desarrollo de reportes según necesidad conforme a los procesos demostrados.

- Importación de Datos y Campos de Sistema Informático utilizado actualmente.

Principales reportes:

- Listado de resoluciones por funcionarios, fechas y tipos.

- Estado de resoluciones.

- Resumen de tipo de resoluciones.

- Generación de archivo comprimido zip o rar con pdf y planillas de resoluciones firmadas en un rango de fecha y/o funcionario.

- Informes requeridos para rendición y contabilidad.

- Desarrollo de reportes según necesidad conforme a los procesos establecidos dentro de la estructura de base de datos.

 

Adquisiciones

Tiene como principal objetivo el de llevar el control de todos los procesos de planificación, elaboración de documentaciones y evaluación que se requiere para poder adquirir bienes y servicios dentro de las normas de contrataciones públicas.

El sistema contempla todas las exigencias a nivel de proceso que se requieren para llevar este control.

 Los principales procesos contemplados son:

-              Carga del Pre-PAC.

-              Agrupación del Pre-PAC para generación del PAC.

-              Generación de formularios con formatos que agilizan la carga del PAC en el portal de contrataciones.

-              Control de CDP´s emitidos.

-              Generación y alerta de generación de llamados según planificación anual.

-              Organización de ítems y lotes de llamados.

-              Generación de nota de invitación a proveedores.

-              Asistente para generación del Pliego de Base y Condiciones. (Formatos pre- establecidos para cada modalidad).

-              Calendario con notificaciones sobre eventos vinculados a llamados.

-              Generación de Nota de Invitación a proveedores del rubro.

-              Carga de datos de oferentes.

 

 

-              Generación de acta de apertura de ofertas.

-              Carga de datos de ofertas.

-              Generación de cuadro de comparación de precios exportable a Excel.

-              Generación de reporte sobre lotes e ítems adjudicados a oferentes. Exportación del reporte a Excel a fin de ser utilizado dentro de la resolución de adjudicación.

-              Control de Adjudicaciones.

Así mismo genera todos los reportes y documentos necesarios como ser:

-              Listado de llamados por estados.

-              Listado de llamados por tipos.

-              Resumen de datos del llamado.

-              Borrador para esquema base del PBC.

-              Nota de Invitación a proveedores del rubro.

-              Acta de apertura.

-              Cuadro de comparación de precios.

-              Cuadro de montos adjudicados.

-              Informe sobre adjudicaciones.

-              Estadísticas generales.

-              Desarrollo de reportes según necesidad conforme a los procesos establecidos dentro de la estructura de base de datos.

El sistema cuenta con mecanismos que validan datos contra los datos cargados al portal de contrataciones.

Todas las secciones del sistema contemplan la posibilidad de adjuntar archivos digitalizados de los documentos oficiales de cada uno de los procesos.

El sistema genera reportes gráficos y listados con resúmenes que se reflejan en un panel principal, dando al usuario un panorama general de la ejecución de los procesos de adquisiciones.

Informaciones requeridas en la pantalla inicial:

-              Acceso a secciones más utilizadas del sistema.  Ej.: Pre-PAC, PAC, CDP´s, Llamados, Adjudicaciones, Eventos.

-              Gráfico de torta para distribución de llamados por tipo de llamado.

-              Listado de eventos más cercanos con opción de ir a agregar un evento.

-              Porcentaje de PAC’s que poseen llamados.

-              Porcentaje de llamados adjudicados.

-              Vista representativa de cantidades de llamados y sus estados actuales.

-              Acceso a la ventana de logueo del portal de contrataciones.

-              Acceso directo al PDF de la Ley 2051/03.

-              Acceso a visualizar y configurar la presentación en modo transición.

Presentación en modo transición:

La presentación en modo transición consiste en la generación de un mecanismo donde se puedan seleccionar uno o varios datos/gráficos que figuran en el panel principal y estos puedan ser expuestos de manera dinámica en el monitor del usuario. Estará enfocado principalmente para ser visualizado en pantallas de gran tamaño (32 pulg. o superiores) dispuestos en puntos claves para demostrar el proceso de la gestión.

Los datos a mostrar en la transición deberán poder ser configurables por cada usuario.

Especificaciones de datos y sus propiedades:

Datos primarios o básicos requeridos Categorías de llamados:

Informaciones requeridas: Número de categoría, Denominación.

Datos iniciales cargados: Las categorías vigentes según contrataciones públicas.

Funcionalidad/es: Catalogar y organizar los llamados por categorías a fin de posteriormente poder realizar informes por esta propiedad.

Validación/es: Ninguna descripción debe ser igual. Reporte/s: Listado de categorías de llamados.

Modalidades:

Informaciones requeridas: Abreviación tipo de modalidad, Nombre de modalidad. Datos iniciales cargados: Las modalidades vigentes según contrataciones públicas.

Funcionalidad/es: Catalogar y organizar los llamados por modalidades a fin de posteriormente poder realizar informes por esta propiedad.

Validación/es: Ningún nombre debe ser igual. Reporte/s: Listado de modalidades.

Marcas:

Informaciones requeridas: Marca.

Datos iniciales cargados: Marcas más populares existentes en el mercado. Funcionalidad/es: Catalogar productos por marcas, evitando así la mala transcripción de nombre.

Validación/es: Ningún nombre debe ser igual. Reporte/s: Listado de marcas registradas.

Unidades de medidas:

Informaciones requeridas: Abreviación, Nombre

Datos iniciales cargados: Unidades de medidas más utilizadas.

Funcionalidad/es: Determinar la unidad de medida de una manera estándar a fin de que el PBC sea más claro para los oferentes.

Validación/es: Ninguna abreviación ni nombre igual. Reporte/s: Listado de Unidades de Medidas.

Objetos del gasto:

Informaciones requeridas: Número de OG, Denominación, Concepto, Abreviación.

Datos iniciales cargados: Se encuentra cargado toda la información de los objetos del gasto obtenidas desde el clasificador presupuestario.

Funcionalidad/es: Se podrá realizar búsquedas de objetos del gasto tanto por número, denominación, concepto, abreviación a fin de ayudar al usuario final a determinar cuál es el objeto del gasto indicado para la registración de datos.

Validación/es: No se podrán agregar objetos del gasto que no posean un Objeto del gasto padre cargado. No se podrán eliminar objetos del gasto que posean algún tipo de dato vinculado al mismo. Reporte/s: Se podrá emitir un listado completo y/o filtrado de los objetos del gasto

registrados.

Fuente de financiamiento:

Informaciones requeridas: Número de fuente de financiamiento, Denominación.

Datos iniciales cargados: Se encuentra cargado toda la información de fuentes de financiamiento obtenidas desde el clasificador presupuestario.

Funcionalidad/es: Se podrá realizar búsqueda por número y denominación. Validación/es: Solo se podrán agregar valores divisibles entre 10 y menores a 100. Reporte/s: Se podrá emitir un listado completo y/o filtrado de los datos registrados.

Organismos financiadores:

Informaciones requeridas: Número de organismo financiador, Denominación.

Datos iniciales cargados: Se encuentra cargado toda la información de fuentes de financiamiento obtenidas desde el clasificador presupuestario que son utilizados dentro de la entidad.

Funcionalidad/es: Se podrá realizar búsqueda por número y denominación. Validación/es: Solo valores numéricos inferiores a 1000.

Reporte/s: Se podrá emitir un listado completo y/o filtrado de los datos registrados.

Feriados:

Informaciones requeridas: Fecha, Descripción.

Datos iniciales cargados: Deberá poseer registrado todas fechas correspondientes a feriados establecidos para los siguientes cinco años a partir del periodo de implementación del software.

Funcionalidad/es: Se podrá realizar búsqueda por fecha y descripción.

Validación/es: No se podrán registrar dos feriados con la misma fecha dentro del mismo año.

Reporte/s: Se podrá emitir un listado completo y/o filtrado de los feriados registrados.

Información institucional:

Estructura:

Informaciones requeridas: Periodo, Tipo de presupuesto, Programa, Sub-Programa, Proyecto, Distribución, Sub-Distribución, Denominación, Afectable.

Datos iniciales cargados: Ninguno. El sistema inicialmente no debe contar con ningún dato cargado en esta sección.

Migración de datos: Se deberán ver reflejada la estructura financiera del periodo vigente según el presupuesto aprobado.

Funcionalidad/es:

El sistema almacenará una estructura financiera distinta para cada periodo.

El sistema deberá contar con la posibilidad de generar una nueva estructura igual que la estructura utilizada en el periodo anterior.

El sistema debe permitir modificar esta nueva estructura creada.

Se determinarán estructuras del tipo afectable SI/NO, las afectables serán las únicas que podrán ser vinculadas a un plan financiero, las demás serán la resultante de la suma de sus distribuciones.

Si bien el SIAF cuenta con una distribución por Tipo de presupuesto, Programa, Sub-Programa, Proyecto, el sistema deberá permitir disgregar la estructura hasta en dos niveles más a fin de dar la posibilidad a la entidad de distribuir montos por una estructura más específica.

Validación/es:

No se podrán crear estructuras que no cuenten con un ítem superior que lo contengan a excepción de los tipos de presupuesto.

No se podrán generar distribuciones de estructuras dentro de una estructura del tipo afectable.

No se podrán eliminar estructuras que posean algún tipo de registro de dato vinculada a la misma.

Reporte/s: Se podrá emitir un listado completo y/o filtrado de la estructura seleccionado el periodo deseado y los tipos de distribuciones seleccionados.

Plan financiero

Informaciones requeridas: Estructura (Periodo, Tipo de presupuesto, Programa, Sub- Programa, Proyecto, Distribución, Sub-Distribución), Objeto del gasto, Fuente de financiamiento, Organismo financiador, Departamento, Mes, Valor.

Datos iniciales cargados: Ninguno. El sistema inicialmente no debe contar con ningún dato cargado en esta sección.

Migración de datos: Se deberá ver reflejado el plan financiero inicial de entidad según información emitida por el SIAF. La información a ser migrada será correspondiente al plan financiero mensual, los valores anuales serán los correspondientes a la suma de los valores mensuales.

Funcionalidad/es: Se podrá consultar la situación del plan financiero. Se podrá consultar filtrando por estructura y/o OG indiferentemente.

Validación/es: Los montos asignados no podrán ser menores que la suma de las reservas. La sumatoria de valores mensuales no podrá ser mayor que el presupuesto cargado. Solo se podrá asignar montos a estructuras del tipo afectable. Todos los montos deberán ser asignados a un mes específico.

Reporte/s:

Listado general: Acceso a un listado general de datos cargados con filtros por cada tipo de dato (Estructura, Objeto del gasto, Fuente de financiamiento, Organismo financiador, Departamento, Mes).

Reporte de distribución: Se podrá acceder a un reporte de distribución de las asignaciones del plan financiero.

Reporte de ejecución (Reservas): Se podrá visualizar la ejecución del plan financiero anual según los montos reservados.

Observación: Todos estos reportes permitirán según la lógica del reporte filtrar los datos por Estructura, Objeto del gasto, Fuente de financiamiento, Organismo financiador, Departamento, Mes.

Proveedores

Informaciones requeridas: RUC, Nombre, Teléfono, Dirección, Correo, Banco, Número de cuenta bancaria, País de origen.

Datos iniciales cargados: Ninguno. El sistema inicialmente no debe contar con ningún dato cargado en esta sección.

Migración de datos: Se deberá proceder a la carga de datos de todos los proveedores según listado que deberá ser proveído por la entidad contratante.

Funcionalidad/es: Se podrán consultar datos de funcionarios de la entidad.

Obtención dinámica de datos: El sistema contará con un sistema de obtención dinámica de datos del beneficiario introduciendo su número de RUC. El mecanismo obtendrá datos de algún servidor en las nubes que registre esta información. Requiere que el servidor posee conexión a internet.

Validación/es: El identificador del proveedor será su número de RUC o identificador único para proveedores que no poseen RUC.

Reporte/s: Se podrá emitir un listado completo los proveedores, el listado debe permitir filtrar por Parte del nombre, País de origen y Banco.

Estructura por usuarios

Informaciones requeridas: Usuario, Estructura financiera. Datos iniciales cargados: Ninguno.

Funcionalidad/es: Se asignarán estructuras habilitadas para los usuarios, esto con el fin de que los usuarios que entran a cargar su Pre-PAC tengan solamente acceso a ver la información correspondiente a su estructura.

Validación/es: El usuario debe estar vinculado a una estructura y esto habilita que pueda ver y editar todas las estructuras que se encuentran dentro de la seleccionada.

Reporte/s: Listado con filtro por Usuario y Estructura.

Administración del catálogo de productos:

Productos al 4to Nivel

Informaciones requeridas: Código al 4to nivel, Denominación.

Datos iniciales cargados: Según catálogo de contrataciones públicas.

Funcionalidad/es: Se utilizará para emitir reportes agrupando los productos del catálogo

al 4to nivel.

Validación/es: Solo se podrán ingresar códigos que correspondan al 4to nivel según

estructura del código para producto de contrataciones públicas. Reporte/s: Listado con filtro por niveles 1, 2 y 3.

Catálogo de productos

Informaciones requeridas: Código del producto, Nombre del producto, Categoría de llamado, Objeto del gasto, Unidad de medida, Valor referencial, Estado (Activo/Inactivo).

Datos iniciales cargados: Presentamos dos opciones. 1) Carga según catálogo de contrataciones públicas, 2) Según datos de productos adquiribles.

Funcionalidad/es: Poseer un catálogo de os producto que podrán ser adquiridos dentro de la entidad. Los productos se diferenciarán entre activos e inactivos, donde solo los activos podrán ser seleccionados para nuevos Pre-PACs, PAC, Llamados. Por otro lado, se requiere determinar qué tipo de producto es para cata categoría de llamado y objeto del gasto, esta información será utilizada para la generación del PAC. El sistema debe generar automática y correlativamente códigos al 6to nivel.

Validación/es: Solo se podrán ingresar códigos al 5to y 6to nivel, en el caso de ingresar al 5to nivel el sistema generará de manera automática un número correlativo siguiente para el 6to nivel.

Reporte/s: Listado de productos con filtros por Niveles (1, 2, 3, 4, 5), Categoría de llamado, Objeto del gasto, Unidad de medida, Estado (Activo/Inactivo).

Listado de productos que formaron parte de un llamado dentro de un rango de tiempo.

Procesos y/o gestiones operativas. Pre-PAC:

Informaciones requeridas: Estructura, Producto, Descripción, Valor Referencial, Cantidad, Tipo (INICIAL, COMPLEMENTO)

Datos iniciales cargados: Ninguno.

Funcionalidad/es: Sección destinada a la carga de los productos que se estiman comprara para el periodo. Cada administración debe cargar su propio Pre-PAC seleccionando únicamente los productos activos. El valor referencial se asignará poniendo el mismo valor referencial puesto en la definición del producto, se guarda este valor únicamente a los efectos de que, si el valor referencial del producto varía con el tiempo, el valor del Pre-PAC no varíe.

Debe existir una funcionalidad que agregue todos los productos a la lista y que usuario final solamente proceda a editar los valores requeridos.

Validación/es:

-              No se podrá agregar dos productos iguales dentro del Pre-PAC del tipo inicial, los productos ya seleccionados no deben aparecen entre las opciones de productos a seleccionar.

-              Solo se podrá agregar Pre-PAC dentro de las estructuras asignadas al usuario y sus estructuras dependientes.

-              Se podrán agregar productos con cantidad 0 cero, a fin de indicar de esta manera que no se requiere de la compra de este producto.

Reporte/s:

-              Listado general: Listado de registros cargados con filtros por estructura, objeto del gasto, categoría, Niveles.

-              Reporte de estructura: Listado de productos seleccionados dentro del Pre-PAC con corte de control tipificado por rubros de objetos del gasto o clasificación. Se debe poder filtrar seleccionando tipo (INICIAL, COMPLEMENTO, AMBOS).

PAC:

Informaciones requeridas:

Cabecera: Descripción, Fecha estimada de adjudicación, Modalidad, Objeto del llamado, Categoría de llamado, AD Referéndum (SI/NO), Subasta (SI/NO), desde periodo, hasta periodo, Nro. DNCP, Activo (SI/NO).

Detalle: Pre-PAC vinculado.

Detalle de montos plurianuales: Periodo Valor.

Datos iniciales cargados: Ninguno.

Funcionalidad/es: Generar agrupaciones de Pre-PAC por categorías de llamado. Preparar archivo a fin de agilizar la carga del PAC en el portal de contrataciones.

Deberá existir un mecanismo para agregar todos los registros del Pre-PAC que no tengan PAC y que correspondan a la categoría del llamado de una vez. Luego se podrá ir quitando los productos que no se deseen que formen parte del PAC.

Validación/es:

-              Un Pre-PAC solamente puede estar vinculado a un PAC.

-              Solo se pueden asignar Pre-PACs activos.

-              Solo se pueden agregar Pre-PAC que coincidan con la categoría de llamado indicada.

-              Solo se podrá editar la categoría del llamado si no se encuentra enlazado ningún Pre- PAC.

-              Los exigirán ser bloqueados para la generación de la solicitud de CDP.

Documento/s emitido/s:

-              Nota de Solicitud de CDP.

-              Reporte con datos para carga en el portal de contrataciones: Este reporte, archivo o mecanismo debe poseer el mismo orden y tipos de datos que requiere el portal de contrataciones a fin de que la carga se pueda hacer copiando y pegando datos.

Reporte/s:

-              Listado general: Listado de los datos generales del PAC con sumatoria de valores. Filtros por estructura, Categoría, Modalidad, Rango de Fecha.

-              Listado detallado: Listado detallado de los productos contenidos en los PACs. Filtros por estructura, Categoría, Modalidad, Objeto del Gasto, Rango de Fecha.

-              Listado de productos sin PAC: Listado de productos que aún no poseen PAC. Filtros por estructura, OG, Tipo.

CDPs:

Informaciones requeridas:

Cabecera: Nro., Periodo, Fecha, Detalle, Documento digitalizado, Liberado, Fecha liberación.

Detalle: Estructura, OG, FF, OF, Dpto., Valor, Valor liberado

Datos iniciales cargados: Ninguno. El sistema inicialmente no debe contar con ningún dato cargado en esta sección.

Migración de datos: Se debe ver reflejado todos los CDPs para llamados nuevos emitidos hasta la fecha de migración de datos, todos deben contar con su documento físico adjunto en el sistema.

Funcionalidad/es: Registrar las líneas presupuestarias afectadas a la certificación, a fin de tener como parámetro al momento de la preparación del llamado y adjudicación de los proveedores. Se deberá poder generar un CDP de manera automática con los datos del PAC, los valores de las líneas afectadas no podrán ser editados directamente.

Validación/es: Las reservas no podrán ser mayores que el saldo del plan financiero anual para esa línea presupuestaria. Las reservas se deberán realizar en el mismo OG que se encuentra especificado en el plan financiero.

Reporte/s:

-              Listado general de CDPs: Listado general de las cabeceras de los CDPs con los valores totales reservados.

-              Reservas por línea presupuestaria: Listado de reservas realizadas en una línea presupuestaria especificada.

Observación: Todos los reportes deberán poder ser filtrados por tipo y rango de fecha.

Llamados

Informaciones requeridas:

Datos principales: Número DNCP, Número de convocatoria, Descripción, Fecha de inicio de preparación, Fecha estimada de adjudicación, Modalidad, Objeto del llamado, Categoría de llamado, AD Referéndum (SI/NO), Subasta (SI/NO), Desde periodo, Hasta periodo, Formato de PBC, Activo (SI/NO).

Datos secundarios: Tipo de garantía de mantenimiento de oferta, plazo de entrega, lugar, número de acta de apertura, número de licitación.

Funcionalidad/es: Registración de datos generales del llamado.

Si procede con la carga de un número de DNCP que ya existen en el PAC, el sistema deberá:

-              Cargar toda la información que ya se encuentra especificada en esa sección

-              Crear un lote genérico

-              Cargar toda la información de los productos en los ítems del llamado.

-              Vincular con el CDP vinculado al PAC.

El sistema permitirá la creación de llamados sin la necesidad de la existencia de un PAC. Esta funcionalidad es permitida para los casos de carga de llamados que sus PAC ya fueron cargados y no se desea registrar en el sistema.

Validación/es: No puede existir variación entre los datos del PAC y datos del llamado. Reporte/s: Listado de llamados por Estados, Categorías, Modalidad, Rango de fecha.

Llamado > Secciones del PBC

Informaciones requeridas: Formato sección PBC, Orden en hasta 6 niveles de prioridad. Funcionalidad/es: Armar el índice del PBC con los formatos de secciones genéricos pre-

establecidos. Los datos se reemplazar en el formato por las etiquetas establecidas dentro del mecanismo de funcionamiento del asistente de generación de PBC’s.

Validación/es: Combinación de secciones abiertas.

Reporte/s: Listado tipo índice de las secciones seleccionadas. (No es necesario indicar la página correspondiente del archivo a generar).

Llamado > Usuarios vinculados

Informaciones requeridas: Usuario.

Funcionalidad/es: Vincular usuarios específicos a los procesos. Se vinculará a los usuarios a fin de poder realizar las notificaciones correspondientes a estos usuarios. Solo los usuarios de administración general y usuarios vinculados podrán realizar modificaciones a los registros del llamado.

Validación/es: Solo se podrán vincular usuarios activos.

Reporte/s: Listado de usuarios vinculados con filtro por usuario y llamado.

Llamado > Eventos

Informaciones requeridas: Fecha, Hora, Tipo, Descripción.

Funcionalidad/es: Registro de los eventos vinculados al llamado, como ser apertura de ofertas, cierre de plazo de consultas, reuniones aclaratorias etc. Estas actividades arrojarán notificaciones y serán visualizadas en el panel inicial del sistema.

Validación/es: No puede existir más de un evento vinculado a un llamado en la misma fecha y hora.

llamado.

Reporte/s: Listado de eventos a realizarse, se podrá filtrar por tipo, rango de fecha y

Llamado > Documentos

Informaciones requeridas: Titulo, Fecha, Descripción, Documento digitalizado (PDF).

Funcionalidad/es: Adjuntar todos los documentos que se utilizaron durante el proceso de elaboración del llamado hasta la adjudicación de los bienes. Esta sección deberá servir para consultar cualquier tipo de documento que pueda servir de apoyo. Memos, Notas, Resoluciones, Actas etc.

Validación/es: Debe exigir la vinculación con el documento PDF.

Reporte/s: Listado de documentos vinculados con filtro por llamado y rango de fecha.

Llamado > CDP’s

Informaciones requeridas: Número de CDP vinculado al llamado.

Funcionalidad/es: Registrar todos los CDP´s vinculados al llamado. Deberá permitir la vinculación de uno o más CDPs vinculados al llamado a fin ser utilizados como insumo para la generación de los ítems adjudicados dentro del periodo.

Validación/es: El sistema permitirá que un llamado no posea un CDP vinculado si el mismo es del tipo Ad Referéndum, en caso contrario será una exigencia la vinculación de al menos un CDP.

Reporte/s:

-              Listado de CDP’s vinculados.

-              Listado detallado con sus líneas presupuestarias afectadas mostrando el total reservado, valor con precio referencial y valor con precios ofertados para ofertas seleccionadas como a adjudicar.

Llamado > Estructuras permitidas

Informaciones requeridas: Estructura, OG, FF, OF, Dpto.

Funcionalidad/es: El sistema exigirá la vinculación con las estructuras que utilizarán los bienes. En el caso de poseer CDP´s vinculados este debe verse reflejados automáticamente en esta sección.

Reporte/s: Listado de líneas vinculadas al llamado.

Llamado > Lotes

Informaciones requeridas: Lote, Denominación, Tipo (ABIERTO, CERRADO), Tipo Adjudicación (LOTE, ITEM), Declarado desierto (SI/NO).

Funcionalidad/es: Registración y configuración de los lotes que poseerá el llamado.

Validación/es: No pueden existir lotes con la misma denominación. Para los lotes del tipo abierto la adjudicación será por LOTE.

Reporte/s:

-              Listado de lotes con sus totales y denominaciones.

-              Listado de los lotes con sus ítems y valores.

Llamado > Ítems

Informaciones requeridas: Lote, Ítem, Tipo (Producto/Titulo), Producto, Descripción, Valor unitario referencial, Declarado desierto (SI/NO).

Funcionalidad/es: Registración de la estructura de ítems que será utilizado dentro del llamado. El campo ítem deberá ser del tipo cadena, permitiendo así cargar ítems y sub-ítems de la siguiente manera:

1             Titulo o Grupo

1.1          Sub-Titulo o Sub-Grupo

1.2          Sub- Sub-Titulo o Sub- Sub-Grupo

1.2.1      Producto

1.2.2      Producto

1.3          Producto

Se determinará si el ítem es un producto o un título con el campo tipo, el valor referencial será cargado automáticamente del valor indicado en el Pre-PAC o en su defecto el Catálogo de productos, este precio deberá ser registrado a fin de no registrar variaciones si el precio referencial cambia a futuro.

Validación/es: Solo se podrá vincular con un producto si el ítem es el tipo producto, en el caso de declarar desierto, el cambio deberá ser aplicado de manera automática a todos sus sub-s ítems. Solo se podrán seleccionar productos que coincidan con la categoría de llamado y los objetos del gasto vinculados en las estructuras permitidas asignadas para el llamado.

Reporte/s: Listado de Lotes e ítems con filtro por lotes, se deberá poder mostrar la distribución asignada a cada producto.

Llamado > Distribuciones

Informaciones requeridas: Lote, Ítem, estructura, OG, FF, OF, Dpto., Cantidad o Valor. Funcionalidad/es: Asignación distribuida por estructura de los ítems a ser adquiridos. La

Distribución de las cantidades por estructura es opcional, en ningún caso puede ser obligatorio para continuar con el proceso. La asignación de distribuciones solo se da para planificar a donde afectarán administrativamente los bienes (la afectación administrativa debería coincidir con la existencia física del bien).

Validación/es: El valor referencial por la cantidad seleccionada no podrá superar el monto del CDP vinculado al llamado. En el caso de ser AD Referéndum esta regla no será aplicada.

Reporte/s: Listado de Lotes e ítems con filtro por lotes, se deberá poder mostrar la distribución asignada a cada producto.

Llamado > Invitados

Informaciones requeridas: Proveedor, Fecha comunicación por correo, Fecha comunicación por nota, Documento adjunto de recepción de invitación.

Funcionalidad/es: Registración de proveedores invitados. Esto generará la nota de invitación correspondiente, el sistema exigirá la cantidad de invitados mínimos para la aparición de la nota de invitación.

Validación/es: Validar cantidad mínima de invitados para aparición de nota de invitación. Documento/s emitido/s: Nota de invitación al llamado.

Reporte/s: listado de invitados con sus correspondientes fechas de notificaciones.

Llamado > Oferentes

Informaciones requeridas: Proveedor, Valor total, Observación, Evaluable (SI/NO).

Funcionalidad/es: Registración de los oferentes que se presentaron con sus correspondientes, ofertas. Esta sección generará el acta de apertura de oferta.

Documento/s emitido/s: Acta de apertura de ofertas.

Reporte/s: Listado de oferentes que se presentaron con su valor total y sus observaciones

realizadas.

Llamado > Ofertas

Informaciones requeridas: Oferente, Lote, Ítem, Marca, Modelo, Procedencia, Fabricante, Valor, Observación, Cantidad a adjudicar, Valor a adjudicar.

Funcionalidad/es: Carga de los datos de las ofertas presentadas

Validación/es: Solo se cargarán ofertas de oferentes seleccionados como Evaluable SI. El valor total de las ofertas cargadas no debe superar el valor cargado en valor total de la oferta en oferente. No se podrá adjudicar ningún valor si el total de ofertas cargado no coincide con el total ofertado. La cantidad a adjudicar no debe ser superior a la cantidad total solicitada por cada ítem.

Documento/s emitido/s:

-              Documento de comparación de precios con opciones de filtro por datos y exportación a formato Excel.

-              Documento de valores adjudicados con opciones de filtro por datos y exportación a formato Excel.

Reporte/s: Listado con datos de la oferta con filtros por oferentes, lotes, ítems.

Adjudicaciones

Informaciones requeridas: Llamado o Nro. DNCP, Oferente, Fecha de resolución, Número de resolución, Observaciones, Documento digitalizado.

Funcionalidad/es: Levar el registro de todas las adjudicaciones realizadas. Funcionalidad/es vinculada/s con otra/s sección/es:

-              Generación automática de datos de contrato con la resolución cargada (Vinculación con CONTRATOS).

Validación/es: El oferente debe ser un oferte del llamado y debe tener ítems con valores

adjudicados.

Reporte/s: Listado de adjudicaciones con filtro por rango de fecha, proveedor, llamado,

Número de resolución.

Eventos

Informaciones requeridas: Fecha, Hora, Tipo, Descripción.

Funcionalidad/es: Registro de los eventos vinculados al llamado y otros eventos independientes, como ser apertura de ofertas, cierre de plazo de consultas, reuniones aclaratorias, reunión de trabajo etc. Estas actividades arrojarán notificaciones y serán visualizadas en el panel inicial del sistema.

Validación/es: No puede existir más de un evento vinculado a un llamado en la misma fecha y hora.

Reporte/s: Listado de eventos a realizarse, se podrá filtrar por tipo, rango de fecha y llamado.

Otros materiales y accesos útiles:

-              Acceso directo a la ventana de acceso con usuarios del portal de contrataciones públicas.

-              Acceso directo al documento de la Ley 2051/03. Acceso al archivo PDF.

 

Contratos

Tiene como principal objetivo el de llevar el control de todos los procesos y etapas que conlleva un contrato, elaboración del contrato en sí y sus órdenes de compra y/o servicios.

El sistema contempla todas las exigencias a nivel de proceso que se requieren para llevar este control.

Los principales procesos contemplados son:

•             Carga de datos del contrato.

•             Generación de ítems del contrato importando de los datos del llamado.

•             Generación del contrato físico.

•             Control del saldo de los CC’s (Códigos de contratación).

•             Control del saldo de los CDP’s (Certificaciones de disponibilidades presupuestarias).

•             Registración e impresión de adendas, tanto de modificación de cantidades y/o cláusulas contractuales.

•             Generación de órdenes de compra y/o servicios.

•             Control de plazos de los trabajos que conllevan las ordenes emitidas.

•             Control y alertas sobre vigencias de pólizas.

•             Control y alertas sobre plazos contractuales.

•             Verificación de saldos en el periodo anterior a fin de solicitar los CDP de convalidación de saldo.

•             Solicitud de CDP de certificación de saldo.

•             Registración de CDP que afectan al contrato.

•             Calendario con notificaciones sobre eventos vinculados a contratos.

•             Base de datos con datos de contacto de proveedores.

•             Así mismo genera todos los reportes y documentos necesarios como ser:

•             Listado de contratos por proveedores, rango de fecha, estados etc.

•             Resumen de datos del contrato.

•             Impresión del contrato físico.

•             Impresión de adendas contractuales.

•             Nota de solicitud de CDP.

•             Nota sobre notificaciones vinculadas a retrasos.

•             Estadísticas generales.

•             Desarrollo de reportes según necesidad conforme a los procesos establecidos dentro de la estructura de base de datos.

Todas las secciones del sistema contemplan la posibilidad de adjuntar archivos digitalizados de

los documentos oficiales de cada uno de los procesos. El sistema genera reportes gráficos y listados con resúmenes que se reflejan en un panel principal, dando al usuario un panorama general de la ejecución de los procesos de adquisiciones.

Informaciones requeridas en la pantalla inicial:

Acceso a secciones más utilizadas del sistema. Ej.: Contratos, CDP´s, Ordenes, catálogo de productos, Códigos de contratación, Proveedores.

Información sobre: Cantidad de contratos vigentes, Valor total de contratos vigentes, Total pendiente de pago, Pendiente de pago en el presente periodo, pendiente de pago sin CDP emitido para el presente periodo.

Gráfico de torta para distribución de contratos por tipo de provisión.

Listado de últimos contratos y/o adendas cargadas.

Vista representativa de cantidades de contratos activos y sus estados actuales.

Acceso a la ventana de logueo del portal de contrataciones.

Acceso directo al pdf de la Ley 2051/03.

Acceso a visualizar y configurar la presentación en modo transición.

Presentación en modo transición

La presentación en modo transición consiste en la generación de un mecanismo donde se puedan seleccionar uno o varios datos/gráficos que figuran en el panel principal y estos puedan ser expuestos de

manera dinámica en el monitor del usuario. Estará enfocado principalmente para ser visualizado en pantallas de gran tamaño (32 pulg. o superiores) dispuestos en puntos claves para demostrar el proceso de la gestión.

Los datos a mostrar en la transición deberán poder ser configurables por cada usuario.

Especificaciones de datos y sus propiedades:

Datos primarios o básicos requeridos:

Categorías de llamados

Informaciones requeridas: Número de categoría, Denominación.

Datos iniciales cargados: Las categorías vigentes según contrataciones públicas.

Funcionalidad/es: Catalogar y organizar los llamados por categorías a fin de posteriormente poder realizar informes por esta propiedad.

Validación/es: Ninguna descripción debe ser igual.

Reporte/s: Listado de categorías de llamados.

Modalidades

Informaciones requeridas: Abreviación tipo de modalidad, Nombre de modalidad.

Datos iniciales cargados: Las modalidades vigentes según contrataciones públicas.

Funcionalidad/es: Catalogar y organizar los llamados por modalidades a fin de posteriormente poder realizar informes por esta propiedad.

Validación/es: Ningún nombre debe ser igual.

Reporte/s: Listado de modalidades.

Marcas:

Informaciones requeridas: Marca.

Datos iniciales cargados: Marcas más populares existentes en el mercado.

Funcionalidad/es: Catalogar productos por marcas, evitando así la mala transcripción de

Validación/es: Ningún nombre debe ser igual.

 Reporte/s: Listado de marcas registradas.

Unidades de medidas

Informaciones requeridas: Abreviación, Nombre

Datos iniciales cargados: Unidades de medidas más utilizadas.

Funcionalidad/es: Determinar la unidad de medida de una manera estándar a fin de que el PBC sea más claro para los oferentes.

Validación/es: Ninguna abreviación ni nombre igual.

 Reporte/s: Listado de Unidades de Medidas.

Objetos del gasto

Informaciones requeridas: Número de OG, Denominación, Concepto, Abreviación.

Datos iniciales cargados: Se encuentra cargado toda la información de los objetos del gasto obtenidas desde el clasificador presupuestario.

Funcionalidad/es: Se podrá realizar búsquedas de objetos del gasto tanto por número, denominación, concepto, abreviación a fin de ayudar al usuario final a determinar cuál es el objeto del gasto indicado para la registración de datos.

Validación/es: No se podrán agregar objetos del gasto que no posean un Objeto del gasto padre cargado. No se podrán eliminar objetos del gasto que posean algún tipo de dato vinculado al mismo.

Reporte/s: Se podrá emitir un listado completo y/o filtrado de los objetos del gasto

registrados.

Fuente de financiamiento

Informaciones requeridas: Número de fuente de financiamiento, Denominación.

Datos iniciales cargados: Se encuentra cargado toda la información de fuentes de financiamiento obtenidas desde el clasificador presupuestario.

Funcionalidad/es: Se podrá realizar búsqueda por número y denominación.

Validación/es: Solo se podrán agregar valores divisibles entre 10 y menores a 100.

 Reporte/s: Se podrá emitir un listado completo y/o filtrado de los datos registrados.

Organismos financiadores

Informaciones requeridas: Número de organismo financiador, Denominación.

Datos iniciales cargados: Se encuentra cargado toda la información de fuentes de financiamiento obtenidas desde el clasificador presupuestario que son utilizados dentro de la entidad.

Funcionalidad/es: Se podrá realizar búsqueda por número y denominación.

 Validación/es: Solo valores numéricos inferiores a 1000.

Reporte/s: Se podrá emitir un listado completo y/o filtrado de los datos registrados.

Feriados

Informaciones requeridas: Fecha, Descripción.

Datos iniciales cargados: Deberá poseer registrado todas fechas correspondientes a feriados establecidos para los siguientes cinco años a partir del periodo de implementación del software.

Funcionalidad/es: Se podrá realizar búsqueda por fecha y descripción.

Validación/es: No se podrán registrar dos feriados con la misma fecha dentro del mismo año.

Reporte/s: Se podrá emitir un listado completo y/o filtrado de los feriados registrados.

Información institucional

Estructura

Informaciones requeridas: Periodo, Tipo de presupuesto, Programa, Sub-Programa, Proyecto, Distribución, Sub-Distribución, Denominación, Afectable.

Datos iniciales cargados: Ninguno. El sistema inicialmente no debe contar con ningún dato cargado en esta sección.

Migración de datos: Se deberán ver reflejada la estructura financiera del periodo vigente según el presupuesto aprobado.

Funcionalidad/es:

El sistema almacenará una estructura financiera distinta para cada periodo.

El sistema deberá contar con la posibilidad de generar una nueva estructura igual que la estructura utilizada en el periodo anterior.

El sistema debe permitir modificar esta nueva estructura creada.

Se determinarán estructuras del tipo afectable SI/NO, las afectables serán las únicas que podrán ser vinculadas a un plan financiero, las demás serán la resultante de las sumas de sus distribuciones.

Si bien el SIAF cuenta con una distribución por Tipo de presupuesto, Programa, Sub-Programa, Proyecto, el sistema deberá permitir disgregar la estructura hasta en dos niveles más a fin de dar la posibilidad a la entidad de distribuir montos por una estructura más específica.

Validación/es:

No se podrán crear estructuras que no cuenten con un ítem superior que lo contengan a excepción de los tipos de presupuesto.

No se podrán generar distribuciones de estructuras dentro de una estructura del tipo afectable.

No se podrán eliminar estructuras que posean algún tipo de registro de dato vinculada a la misma.

Reporte/s: Se podrá emitir un listado completo y/o filtrado de la estructura seleccionado el periodo deseado y los tipos de distribuciones seleccionados.

Plan financiero

Informaciones requeridas: Estructura (Periodo, Tipo de presupuesto, Programa, Sub- Programa, Proyecto, Distribución, Sub-Distribución), Objeto del gasto, Fuente de financiamiento, Organismo financiador, Departamento, Mes, Valor.

Datos iniciales cargados: Ninguno. El sistema inicialmente no debe contar con ningún dato cargado en esta sección.

Migración de datos: Se deberá ver reflejado el plan financiero inicial de entidad según información emitida por el SIAF. La información a ser migrada será correspondiente al plan financiero mensual, los valores anuales serán los correspondientes a la suma de los valores mensuales.

Funcionalidad/es: Se podrá consultar la situación del plan financiero. Se podrá consultar filtrando por estructura y/o OG indiferentemente.

Validación/es: Los montos asignados no podrán ser menores que la suma de las reservas. La sumatoria de valores mensuales no podrá ser mayor que el presupuesto cargado. Solo se podrá asignar montos a estructuras del tipo afectable. Todos los montos deberán ser asignados a un mes específico.

Reporte/s:

Listado general: Acceso a un listado general de datos cargados con filtros por cada tipo de dato (Estructura, Objeto del gasto, Fuente de financiamiento, Organismo financiador, Departamento, Mes).

Reporte de distribución: Se podrá acceder a un reporte de distribución de las asignaciones del plan financiero.

Reporte de ejecución (Reservas): Se podrá visualizar la ejecución del plan financiero anual según los montos reservados.

Observación: Todos estos reportes permitirán según la lógica del reporte filtrar los datos por Estructura, Objeto del gasto, Fuente de financiamiento, Organismo financiador, Departamento, Mes.

Proveedores

Informaciones requeridas: RUC, Nombre, Teléfono, Dirección, Correo, Banco, Número de cuenta bancaria, País de origen.

Datos iniciales cargados: Ninguno. El sistema inicialmente no debe contar con ningún dato cargado en esta sección.

Migración de datos: Se deberá proceder a la carga de datos de todos los proveedores según listado que deberá ser proveído por la entidad contratante.

Funcionalidad/es: Se podrán consultar datos de funcionarios de la entidad.

Obtención dinámica de datos: El sistema contará con un sistema de obtención dinámica de datos del beneficiario introduciendo su número de RUC. El mecanismo obtendrá datos de algún servidor en las nubes que registre esta información. Requiere que el servidor posee conexión a internet.

Validación/es: El identificador del proveedor será su número de RUC o identificador único para proveedores que no poseen RUC.

Reporte/s: Se podrá emitir un listado completo los proveedores, el listado debe permitir filtrar por Parte del nombre, País de origen y Banco.

Administración del catálogo de productos:

Productos al 4to Nivel:

Informaciones requeridas: Código al 4to nivel, Denominación.

Datos iniciales cargados: Según catálogo de contrataciones públicas.

Funcionalidad/es: Se utilizará para emitir reportes agrupando los productos del catálogo

al 4to nivel.

Validación/es: Solo se podrán ingresar códigos que correspondan al 4to nivel según

estructura del código para producto de contrataciones públicas.

Reporte/s: Listado con filtro por niveles 1, 2 y 3.

Catálogo de productos

Informaciones requeridas: Código del producto, Nombre del producto, Categoría de llamado, Objeto del gasto, Unidad de medida, Valor referencial, Estado (Activo/Inactivo).

Datos iniciales cargados: Presentamos dos opciones. 1) Carga según catálogo de contrataciones públicas, 2) Según datos de productos adquiribles.

Funcionalidad/es: Poseer un catálogo de os producto que podrán ser adquiridos dentro de la entidad. Los productos se diferenciarán entre activos e inactivos, donde solo los activos podrán ser seleccionados para nuevos Contratos. Por otro lado, se requiere determinar qué tipo de producto es para cata categoría de llamado y objeto del gasto, esta información será utilizada para la generación del PAC. El sistema debe generar automática y correlativamente códigos al 6to nivel.

Validación/es: Solo se podrán ingresar códigos al 5to y 6to nivel, en el caso de ingresar al 5to nivel el sistema generará de manera automática un número correlativo siguiente para el 6to nivel.

Reporte/s: Listado de productos con filtros por Niveles (1, 2, 3, 4, 5), Categoría de llamado, Objeto del gasto, Unidad de medida, Estado (Activo/Inactivo).

Listado de productos que formaron parte de un llamado dentro de un rango de tiempo.

Procesos y/o gestiones operativas:

Contratos

Informaciones requeridas: Número y periodo de contrato, Denominación, Fecha de inicio y fin del contrato, Proveedor, Llamado vinculado, Modalidad, Objeto del llamado, Categoría de llamado, Valor inicial del contrato, Fecha de notificación, Formato de contrato, Documento digitalizado del contrato, Estado (PREPARACION, EJECUCION, EJECUTADO, RESCINDIDO), Activo (SI/NO).

Funcionalidad/es: Llevar la registración de los contratos con todos sus datos y procesos. La sección debe servir principalmente para generar los documentos que serán utilizados dentro del proceso de ejecución del contrato.

Validación/es: No se podrán seguir realizando cambios en el contrato si el mismo ya se encuentra con estado EJECUTADO o RESCINDIDO, Solo se podrán realizar cambios a contratos activos. Reporte/s: Listado de contratos con filtros por Fecha de inicio y fin del contrato, Proveedor,

Llamado vinculado, Modalidad, Objeto del llamado, Categoría de llamado, Estado., Deberá permitir ordenar por Número de contrato, Valor total, Fecha de vigencia o Estado.

Contrato > Usuarios vinculados

Informaciones requeridas: Usuario.

Funcionalidad/es: Vincular usuarios específicos a los procesos. Se vinculará a los usuarios a fin de poder realizar las notificaciones correspondientes a estos usuarios. Solo los usuarios de administración general y usuarios vinculados podrán realizar modificaciones a los registros del contrato.

Validación/es: Solo se podrán vincular usuarios activos.

Reporte/s: Listado de usuarios vinculados con filtro por usuario y contrato.

Contrato > Cláusulas

Informaciones requeridas: Orden (Hasta 3 niveles), Formato de cláusula.

Funcionalidad/es: Armar el índice de cláusulas con los formatos genéricos pre-

establecidos. Los datos se reemplazar en el formato por las etiquetas establecidas dentro del mecanismo de funcionamiento del asistente de generación de contratos.

Validación/es: Combinación de secciones abiertas.

Reporte/s: Listado tipo índice de las secciones seleccionadas. (No es necesario indicar la página correspondiente del archivo a generar).

Contrato > Eventos

Informaciones requeridas: Fecha, Hora, Tipo, Descripción.

Funcionalidad/es: Registro de los eventos vinculados al contrato, como ser finalización de vigencia del contrato, vigencia de póliza, vencimiento de plazos de etapas, reuniones etc. Estas actividades arrojarán notificaciones y serán visualizadas en el panel inicial del sistema.

Validación/es: No puede existir más de un evento vinculado a un contrato en la misma fecha y hora.

Reporte/s: Listado de eventos a realizarse, se podrá filtrar por tipo, rango de fecha y

Llamado.

Contrato > Estructuras permitidas

Informaciones requeridas: Estructura, OG, FF, OF, Dpto.

Funcionalidad/es: El sistema exigirá la vinculación con las estructuras que utilizarán los bienes. Esto a fin se ser utilizados en la distribución por estructura de los bienes dentro del contrato.

Reporte/s: Listado de líneas vinculadas al contrato.

Contrato > Códigos de contrataciones

Informaciones requeridas:

Cabecera: Número de CC, Número de adenda, Fecha de adenda, Observación adenda, valor, PDF de adenda, PDF de CC.

Detalle: Estructura, OG, FF, OF, Dpto., Valor.

Funcionalidad/es: Llevar el control de los CC’s vinculados al contrato, así también los sus saldos correspondientes.

Validación/es: Los montos ordenados no pueden superar los montos del CC. Los montos distribuidos asignados a este CC no pueden superar al monto asignado en su línea correspondiente.

Reporte/s:

Listado de CC’s vinculados al contrato con filtros por CC, Estructura, OG, FF, OF. Se debe visualizar su saldo correspondiente.

Ejecución del CC contra compromisos (Vinculación con PRESUPUESTO).

Contrato > Solicitudes de CDP

Informaciones requeridas:

Cabecera: Fecha, Descripción, Confirmación (SI/NO)

Detalle: Distribución vinculada.

Funcionalidad/es: Generar las solicitudes de CDP correspondientes a CDP´s de saldos de contratos y CDP’s sobre adendas a los contratos.

Validación/es: Debe existir saldo en el plan financiero.

Documento/s emitido/s: Nota de solicitud de CDP según estándar de notas de la entidad.

Reporte/s: Listado de Solicitudes de CDP emitidos.

Contrato > Certificaciones de disponibilidad presupuestaria

Informaciones requeridas: Identificador de solicitud, Número y periodo del CDP.

Funcionalidad/es: Llevar el control de los CDP´s vinculados al contrato y sus saldos correspondientes.

Reporte/s: Listado de CDP emitidos con sus valores de ejecución por órdenes emitidas.

Contrato > Lotes

Informaciones requeridas: Número, Denominación, Tipo (ABIERTO, CERRADO)

Funcionalidad/es: Carga de los lotes adjudicados al proveedor y declaración del comportamiento/modalidad del mismo.

Validación/es: No pueden existir dos lotes dentro del mismo contrato con el mismo nombre ni número.

Reporte/s:

-              Listado de lotes visualizando sus valores totales y ordenados.

-              Listado de lotes con sus ítems visualizando sus valores totales y ordenados.

Contrato > Ítems

Informaciones requeridas: Número de lote, Número de ítem, Tipo de ítem (PRODUCTO, TITULO), Producto, Descripción, Valor unitario, Marca, Modelo, Presentación, Procedencia, Fabricación, Observaciones.

Funcionalidad/es: Registración de la estructura de ítems que será utilizado dentro del lote. El campo ítem deberá ser del tipo cadena, permitiendo así cargar ítems y sub-ítems de la siguiente manera:

Titulo o Grupo

Sub-Titulo o Sub-Grupo

Sub- Sub-Titulo o Sub- Sub-Grupo

Producto

Producto

Producto

Se determinará si el ítem es un producto o un título con el campo tipo, el valor referencial será cargado automáticamente del valor indicado en el Pre-PAC o en su defecto el Catálogo de productos, este precio deberá ser registrado a fin de no registrar variaciones si el precio referencial cambia a futuro.

Validación/es: Solo se podrá vincular con un producto si el ítem es el tipo producto.

Solo se podrán seleccionar productos que coincidan con la categoría de llamado y los objetos del gasto vinculados en las estructuras permitidas asignadas para el contrato.

Reporte/s: Listado de Lotes e ítems con filtro por lotes, se deberá poder mostrar la distribución asignada a cada producto y su ejecución con relación a órdenes emitidas.

Contrato > Distribuciones

Informaciones requeridas: Número de CC, Número de lote, Número de ítem, Número de CDP, Estructura, OG, FF, OF, Dpto., Cantidad, Valor, Identificador de origen de migración.

Funcionalidad/es:

Asignación distribuida por estructura de los ítems contratados.

La Distribución de las cantidades por estructura es opcional, en ningún caso puede ser obligatorio para continuar con el proceso. La asignación de distribuciones solo se da para planificar a donde afectarán administrativamente los bienes (la afectación administrativa debería coincidir con la existencia física del bien).

Validación/es: La distribución asignada no podrá ser mayor que el monto establecido en el CC. La distribución no podrá ser menor al monto ya ordenado.

Reporte/s: Listado de Lotes e ítems con filtro por lotes, se deberá poder mostrar la distribución asignada a cada producto y su ejecución correspondiente con relación a las órdenes emitidas.

Contrato > Ordenes

Informaciones requeridas:

Cabecera: Tipo (OC, OS), Número, Periodo, Fecha, Número de contrato, Fecha tope de entrega, Lugar de entrega, Fecha de recepción de orden, Observaciones, Documento digitalizado, Activo (SI/NO), Confirmado (SI/NO).

Información de recepción y/o conformidad: Fecha de recepción, Lugar de recepción, Descripción, Documento digitalizado.

Detalle de productos: Lote, Ítem, Comentario.

Detalle de cantidades y su distribución: Distribución afectada, cantidad, Valor.

Funcionalidad/es:

Llevar el control de las órdenes emitidas y el saldo correspondiente del contrato.

Las órdenes emitidas contra la estructura de un periodo podrán ser alteradas y afectadas al periodo siguiente.

Solo se podrán seleccionar productos del contrato vinculado.

Entre las opciones de los productos solo serán visibles los productos que cuentan con saldo que aún no se han seleccionado para esta orden.

La carga de los productos debe ser de manera fácil y rápida.

Se debe crear funcionalidades que permitan agregar todos los ítems del contrato que aún tengan saldo.

Validación/es:

Validación de saldo de productos.

Solo afectarán al cálculo de saldos las órdenes activas.

No se podrá agregar dos veces el mismo producto a una orden.

Documento/s emitido/s: Documento de Orden de Compra y Servicio según los estándares de la entidad.

Reporte/s:

Listado de órdenes emitidas con filtro por proveedor, contrato, rango de fecha.

Listado detallado de órdenes emitidas con filtro por proveedor, contrato, rango de fecha, producto, CC, CDP.

Certificados de disponibilidades presupuestarias

Informaciones requeridas:

Cabecera: Nro., Periodo, Fecha, Detalle, Número de contrato, Documento digitalizado, Liberado, Fecha liberación.

Detalle: Estructura, OG, FF, OF, Dpto., Valor, Valor liberado

Funcionalidad/es: Registrar las líneas presupuestarias afectadas a la certificación, a fin de tener como parámetro al momento de la ejecución del contrato.

Validación/es: Las reservas no podrán ser mayores que el saldo del plan financiero anual para esa línea presupuestaria. Las reservas se deberán realizar en el mismo OG que se encuentra especificado en el plan financiero.

Reporte/s:

Listado general de CDPs: Listado general de las cabeceras de los CDPs con los valores totales reservados.

Reservas por línea presupuestaria: Listado de reservas realizadas en una línea presupuestaria especificada.

Observación: Todos los reportes deberán poder ser filtrados por tipo y rango de fecha.

Códigos de contratación

Informaciones requeridas: Número de contrato, Número de CC, Número de adenda, Fecha de adenda, Observación adenda, valor, PDF de adenda, PDF de CC.

Funcionalidad/es: Llevar un control general de los Códigos de Contratación de todos los

contratos.

Validación/es: Los Códigos deben estar vinculados a contratos y estos deben respetar las

reglas de asignaciones de saldos correspondientes.

Reporte/s:

Listado de CC´s con filtro por Contrato, Proveedor, estructura, OG, FF, OF, Dpto.

Listado de CC´s con su ejecución contra órdenes emitidas.

Listado de CC´s con su ejecución contra compromisos realizados. (Vinculación con PRESUPUESTO)

Ordenes

Informaciones requeridas: Tipo (OC, OS), Número, Periodo, Fecha, Número de contrato, Fecha tope de entrega, Lugar de entrega, Fecha de recepción de orden, Observaciones, Documento digitalizado, Activo (SI/NO), Confirmado (SI/NO), Fecha de recepción, Lugar de recepción, Descripción, Documento digitalizado, Valor total.

Funcionalidad/es: Levar un control general de todas las ordenes emitidas. Mecanismo de emisión rápido de orden de compra. A través de esta sección deben quedar claro los saldos actuales del contrato, ya que solo permitirá seleccionar productos y cantidades que posean saldo correspondiente para su emisión.

Validación/es: Validaciones de saldo. Solo las órdenes activas afectarán los cálculos de saldo de los contratos.

Reporte/s:

Listado de ordenes con filtros por Contrato, Proveedor, Rango de fecha.

Listado detallado con filtros por Contrato, Proveedor, Rango de fecha, Producto, CC, CDP.

Listado de órdenes por su estado. Recibido (SI/NO).

Eventos

Informaciones requeridas: Fecha, Hora, Tipo, Descripción.

Funcionalidad/es: Registro de los eventos vinculados al contrato y otros eventos independientes. Estas actividades arrojarán notificaciones y serán visualizadas en el panel inicial del sistema.

Validación/es: No puede existir más de un evento vinculado a un contrato en la misma fecha y hora.

Reporte/s: Listado de eventos a realizarse, se podrá filtrar por tipo, rango de fecha y contrato.

Otras herramientas:

Asistente para la generación de Contratos y Adendas:

Esta sección está dedicada a facilitar el proceso de generación de Contratos y Adendas. Se almacenarán formatos y secciones genéricas que podrán ser combinadas para crear el contrato o su modificación. Se deberá emplear dentro del formato etiquetas que serán reemplazados con datos.

Se establecerán algunos ejemplos que podrán utilizarse como base.

Formatos

Informaciones requeridas: Descripción, Formato.

 Datos iniciales cargados: Formatos genéricos.

Funcionalidad/es: Almacenan estructuras genéricas sobre la forma de presenta el Contrato o adenda.

Reporte/s: Cada formato debe generar una vista previa.

Cláusulas

Informaciones requeridas: Descripción, Formato.

 Datos iniciales cargados: Formatos genéricos.

Funcionalidad/es: Almacena estructuras genéricas sobre las cláusulas utilizadas en los contratos. Los formatos poseerán etiquetas que se reemplazarán por datos cargados en los contratos.

Reporte/s: Cada formato debe generar una vista previa.

Ejemplos

Informaciones requeridas:

Cabecera: Descripción, Formato.

Detalle: Orden (Hasta 6 niveles), Formato de cláusula.

Datos iniciales cargados: Ejemplos varios.

Funcionalidad/es:

Almacenar agrupaciones de cláusulas dentro de un formato seleccionado a fin de que estos pueden ser utilizados como base de formatos para los contratos.

Los contratos podrán seleccionar uno de los ejemplos como valor inicial para la preparación del contrato.

Un nuevo formato que se haya implementado dentro de un contrato podrá ser pasado como ejemplo seleccionando alguna acción dentro del sistema.

Reporte/s: Vista previa del formato seleccionado

Otros materiales y accesos útiles:

•             Acceso directo a la ventana de acceso con usuarios del portal de contrataciones públicas.

•             Acceso directo al documento de la Ley 2051/03. Acceso al archivo PDF.

 

Almacenes y Suministros

Tiene como principal objetivo de llevar el control de los productos almacenados en los depósitos de la Entidad. El sistema contempla todas las exigencias a nivel de proceso que se requieren para llevar este control.

Los principales procesos contemplados son:

-              Registración de productos.

-              Ingresos.

-              Movimientos internos y entre depósitos.

-              Generación de pedidos internos.

-              Control de recepción de envases.

-              Egresos.

-              Devoluciones.

-              Procesos de inventariado de depósitos y productos.

Así mismo genera todos los reportes y documentos necesarios como ser:

-              FC 02 - Hoja de inventario de bienes en existencia en depósitos.

-              FC 12 - Registro de bienes en existencia en depósitos por tipo de artículo.

-              FC 13 - Pedido interno o egreso vinculado.

-              FC 14 - Nota de recepción de elementos en depósito o almacenes.

-              Reporte con filtros de rango de fecha, proveedores, contratos y productos para Ingresos y Egresos.

El sistema debe estar preparado para trabajar con lectura de códigos de barra, pudiendo utilizar el mismo código de barra del bien como también generar un específico para cada producto.

Todas las secciones del sistema contemplan la posibilidad de adjuntar archivos digitalizados de los documentos oficiales de cada uno de los procesos.

El sistema genera reportes gráficos y listados con resúmenes que se reflejan en un panel principal, dando al usuario un panorama general de la situación de los depósitos de la Entidad.

Informaciones requeridas en la pantalla inicial:

-              Gráfico del          compartimiento              de          movimientos     de          los          últimos 30           días. (Ingresos/Egresos/Devoluciones/Inventarios)

-              Acceso a secciones más utilizadas del sistema. Ej.: Ingresos, Egresos.

-              Se deberá visualizar la cantidad de ingresos y egresos del día. Cantidad total de artículos.

-              Resumen del mes: Valor de artículos recibidos, Valor de artículos remitidos, Diferencia de valores.

 -             Resumen de situación de puntos críticos.

-              Listado de productos próximos a vencer.

-              Acceso directo a últimos movimientos registrados.

-              Acceso a visualizar y configurar la presentación en modo transición.

Presentación en modo transición:

La presentación en modo transición consiste en la generación de un mecanismo donde se puedan seleccionar uno o varios datos/gráficos que figuran en el panel principal y estos puedan ser expuestos de manera dinámica en el monitor del usuario. Estará enfocado principalmente para ser visualizado en pantallas de gran tamaño (32 pulg. o superiores) dispuestos en puntos claves para demostrar el proceso de la gestión.

Los datos a mostrar en la transición deberán poder ser configurables por cada usuario.

Especificaciones de datos y sus propiedades:

Datos primarios o básicos requeridos Objetos del gasto

Informaciones requeridas: Número de OG, Denominación, Concepto, Abreviación.

Datos iniciales cargados: Se encuentra cargado toda la información de los objetos del gasto obtenidas desde el clasificador presupuestario.

Funcionalidad/es: Se podrá realizar búsquedas de objetos del gasto tanto por número, denominación, concepto, abreviación a fin de ayudar al usuario final a determinar cuál es el objeto del gasto indicado para la registración de datos.

Validación/es: No se podrán agregar objetos del gasto que no posean un Objeto del gasto padre cargado. No se podrán eliminar objetos del gasto que posean algún tipo de dato vinculado al mismo. Reporte/s: Se podrá emitir un listado completo y/o filtrado de los objetos del gasto

registrados.

Categorías de llamados

Informaciones requeridas: Número de categoría, Denominación.

Datos iniciales cargados: Las categorías vigentes según contrataciones públicas.

Funcionalidad/es: Catalogar y organizar los llamados por categorías a fin de posteriormente poder realizar informes por esta propiedad.

Validación/es: Ninguna descripción debe ser igual. Reporte/s: Listado de categorías de llamados.

Cuentas patrimoniales

Informaciones requeridas: Cuenta, Sub-Cuenta, Analítico 1, Analítico 2, Denominación, Vida útil.

Datos iniciales cargados: Plan de cuentas planteadas en el manual de normas y procedimientos o cuentas proveídas por la entidad.

Funcionalidad/es: Clasificar los productos por sus cuentas patrimoniales correspondientes. Esta vinculación no será obligatoria, no obstante, ciertos reportes requerirán que los productos se encuentren vinculados a una cuenta patrimonial para que formen parte de estos reportes.

Validación/es: Se deberá validar que exista la cuenta padre. Reporte/s: Listado de cuentas patrimoniales con filtro por niveles.

Unidades de medidas

Informaciones requeridas: Abreviación, Nombre

Datos iniciales cargados: Unidades de medidas más utilizadas.

Funcionalidad/es: Determinar la unidad de medida de una manera estándar a fin de que el PBC sea más claro para los oferentes.

Validación/es: Ninguna abreviación ni nombre igual. Reporte/s: Listado de Unidades de Medidas.

Productos al 4to Nivel

Informaciones requeridas: Código al 4to nivel, Denominación.

Datos iniciales cargados: Según catálogo de contrataciones públicas.

Funcionalidad/es: Se utilizará para emitir reportes agrupando los productos del catálogo

al 4to nivel.

Validación/es: Solo se podrán ingresar códigos que correspondan al 4to nivel según

estructura del código para producto de contrataciones públicas. Reporte/s: Listado con filtro por niveles 1, 2 y 3.

Catálogo de productos

Informaciones requeridas: Código del producto, Nombre del producto, Categoría de llamado, Objeto del gasto, Unidad de medida, Valor referencial, Estado (Activo/Inactivo).

Datos iniciales cargados: Presentamos dos opciones. 1) Carga según catálogo de contrataciones públicas, 2) Según datos de productos adquiribles.

Funcionalidad/es: Poseer un catálogo de os producto que podrán ser adquiridos dentro de la entidad. Los productos se diferenciarán entre activos e inactivos, donde solo los activos podrán ser seleccionados para nuevos Pre-PACs, PAC, Llamados. Por otro lado, se requiere determinar qué tipo de producto es para cata categoría de llamado y objeto del gasto, esta información será utilizada para la generación del PAC. El sistema debe generar automática y correlativamente códigos al 6to nivel.

Validación/es: Solo se podrán ingresar códigos al 5to y 6to nivel, en el caso de ingresar al 5to nivel el sistema generará de manera automática un número correlativo siguiente para el 6to nivel.

Reporte/s: Listado de productos con filtros por Niveles (1, 2, 3, 4, 5), Categoría de llamado, Objeto del gasto, Unidad de medida, Estado (Activo/Inactivo).

Listado de productos que formaron parte de un llamado dentro de un rango de tiempo.

Feriados

Informaciones requeridas: Fecha, Descripción.

Datos iniciales cargados: Deberá poseer registrado todas fechas correspondientes a feriados establecidos para los siguientes cinco años a partir del periodo de implementación del software.

Funcionalidad/es: Se podrá realizar búsqueda por fecha y descripción.

Validación/es: No se podrán registrar dos feriados con la misma fecha dentro del mismo

año.

Reporte/s: Se podrá emitir un listado completo y/o filtrado de los feriados registrados.

Información institucional. Organigrama:

Informaciones requeridas: Id dependencia (Automático), Referencia a dependencia padre, Denominación, Abreviatura, e-mail, teléfono/interno, activo (SI/NO)

Datos iniciales cargados: Datos de la entidad, código 1.

Funcionalidad/es: Registro de la estructura orgánica institucional. Se podrá cargar todo el organigrama institucional. Cada ítem cargado deberá seleccionar su ítem padre, generando así una estructura en forma de árbol relacional, donde no exista un nivel máximo de profundidad.

Tener acceso a los datos de cada repartición de la entidad y poder consultar estos datos de manera fácil. Los funcionarios se deberán vincular a un ítem del organigrama, esto determinara en que repartición está ejerciendo labores el funcionario vinculado al ítem del organigrama.

Validación/es: No pueden existir dependencias con el mismo nombre dentro del mismo

padre directo.

Reporte/s: Listado de la estructura orgánica. Se deberá poder seleccionar el ítem padre y

la cantidad de niveles inferiores que se desea visualizar. El listado se deberá presentar de manera ordenada según la estructura del árbol. En el caso de no seleccionar la cantidad de niveles inferiores se deberá desplegar el listado hasta el último nivel registrado en cada ítem.

Funcionarios

Informaciones requeridas: CI, Nombre, Apellido, Imagen, Organigrama, Cargo Interno, Fecha de nacimiento, Sexo, Teléfono, Interno, Dirección, Correo, Banco, Número de cuenta, Activo.

Datos iniciales cargados: Ninguno. El sistema inicialmente no debe contar con ningún dato cargado en esta sección.

Migración de datos: Se deberá proceder a la carga de datos de todos los funcionarios según la última nómina de funcionarios, tanto nombrados como contratados.

Funcionalidad/es: Se podrán consultar datos de funcionarios por distintos campos. La búsqueda un funcionario por cédula, nombre, apellido, dependencia, cargo, teléfono, interno deberá ser de manera rápida desde el mismo listado principal. Se establecerá un campo activo SI/NO que determinará si el funcionario sigue o no formando parte de la entidad, este valor se deberá tener en cuenta al momento de generar gastos, el sistema no debe permitir generar gastos contra un funcionario inactivo.

Obtención dinámica de datos: El sistema contará con un sistema de obtención dinámica de datos de personas introduciendo su número de CI. El mecanismo obtendrá datos de algún servidor en las nubes que registre esta información. Requiere que el servidor posee conexión a internet.

Validación/es: No se podrán cargar datos de funcionarios sin su número de cédula. Los únicos campos obligatorios serán CI, Nombre y Apellido.

Reporte/s: Se podrá emitir un listado completo los funcionarios, el listado debe permitir filtrar por Organigrama, Cargo Interno, Fecha de nacimiento, Sexo, Banco, Activo.

Administración de depósitos:

Depósitos

Informaciones requeridas: Identificador de depósito, Denominación, Dependencia vinculada, funcionario responsable, Dirección, Teléfono.

Datos iniciales cargados: Depósitos donde se almacenarán los productos de la entidad. Funcionalidad/es: Registrar los datos de los depósitos y su correspondientes responsables.

Validación/es: No pueden existir depósitos con el mismo nombre.

Reporte/s: Listado depósitos existentes y el su valor total actual. Filtro opcional por depósito.

Sectores

Informaciones requeridas: Depósito, Identificador de sector, descripción.

Datos iniciales cargados: Sector de descarga de productos para cada depósito.

Funcionalidad/es: Ordenar cada depósito por sus sectores correspondientes. Los sectores de los depósitos serán considerados los espacios físicos donde se almacenarán o almacenan los bienes pudiendo se estos: estantes, pallets, secciones. En todos los depósitos se requerirá de la creación de una sección de descarga de artículos que hará referencia justamente al lugar inicial donde se depositan los artículos antes de ser organizados en sus estantes.

Validación/es: No se pueden repetir el nombre de un sector dentro de un mismo depósito. Reporte/s: Listado de sectores disponibles por depósitos, se mostrará las características

de este sector.

Usuarios autorizados

Informaciones requeridas: Usuario, Depósito.

Datos iniciales cargados: Asignación de los usuarios principales en sus depósitos correspondientes.

Funcionalidad/es: Asignar el o los depósitos que tendrá acceso cada usuario. Los usuarios púnicamente podrán visualizar información del depósito al cual esté vinculado.

Reporte/s: Listado de usuarios con filtro por depósito y usuario.

Proveedores

Informaciones requeridas: RUC, Nombre, Teléfono, Dirección, Correo, Banco, Número de cuenta bancaria, País de origen.

Datos iniciales cargados: Ninguno. El sistema inicialmente no debe contar con ningún dato cargado en esta sección.

Migración de datos: Se deberá proceder a la carga de datos de todos los proveedores según listado que deberá ser proveído por la entidad contratante.

Funcionalidad/es: Se podrán consultar datos de funcionarios de la entidad.

Obtención dinámica de datos: El sistema contará con un sistema de obtención dinámica de datos del beneficiario introduciendo su número de RUC. El mecanismo obtendrá datos de algún servidor en las nubes que registre esta información. Requiere que el servidor posee conexión a internet.

Validación/es: El identificador del proveedor será su número de RUC o identificador único para proveedores que no poseen RUC.

Reporte/s: Se podrá emitir un listado completo los proveedores, el listado debe permitir filtrar por Parte del nombre, País de origen y Banco.

Administración del catálogo de productos:

Catálogo

Informaciones requeridas: Referencia al producto general, Marca, Modelo, Presentación, Procedencia, Fabricante, Características, Peso Kg., Uso administrativo (SI/NO), Requiere envase (SI/NO), Imagen del producto, Código de barra, Activo (SI/NO).

Funcionalidad/es: Llevar el control de los productos que han pasado en algún momento por el depósito. Se deberá registrar la mayor cantidad de información referente al producto.

Validación/es: No pueden existir dos productos distintos con datos idénticos.

Reporte/s: Lisado de productos con filtros por todos sus campos de descripción. En esta vista se podrá visualizar la cantidad disponible del producto.

Distribución por sectores

Informaciones requeridas: Depósito, Sector, Producto, Referencia al ingreso, cantidad distribuida, Valor unitario, Vencimiento, Observación,

Funcionalidad/es: Organizar los productos dentro de cada depósito por sectores, gavetas, estantes, pallets etc.

Validación/es: El sector debe corresponder con el depósito correspondiente. Reporte/s: Listado de productos por sectores con filtro por sectores y productos.

Asignación por dependencias

Informaciones requeridas: Producto, Dependencia.

Funcionalidad/es: Asignación de productos por dependencias, será utilizado para restringir los tipos de productos que se pueden entregar a cada dependencia.

Validación/es: Verificar que no se pueda repetir la combinación del producto con la

dependencia.

Reporte/s: Listado de dependencias y producto con filtros por dependencia y producto.

Puntos críticos

Informaciones requeridas: Consumo (Máximo, Promedio, Mínimo), Tiempo de reposición (Máximo, Promedio, Mínimo), Stock de seguridad.

Funcionalidad/es: Llevar el control de los puntos críticos y generar alertas sobre los valores que representen reposición de productos.

Validación/es: Coherencia de datos entre Máximo, Promedio, Mínimo y Stock de

seguridad.

Reporte/s: Listado de productos con sus respectivos valores de puntos críticos y sus

valores actuales, Filtro por producto y productos que se encuentran fuera del rango requerido.

Procesos y/o gestiones operativas:

Ingresos

Informaciones requeridas:

Cabecera: Deposito, Número, Periodo, Fecha, Proveedor, Observación, Llamado, Contrato, Orden de compra, Número de nota de remisión, Número de factura, Número de comprobante de pago, Documento digitalizado (PDF).

Detalle: Producto, Observación, Valor unitario, Cantidad ingreso.

Funcionalidad/es: Registro de movimiento de ingresos de productos al depósito. Validación/es: Correlatividad de numeración y fecha de ingreso.

Documento/s emitido/s: FC-14 Nota de recepción de elementos en depósito o almacenes. Reporte/s:

-              Listado de ingresos con filtros por rango de fecha, proveedor, Contrato.

-              Listado detallado de ingresos con filtros por rango de fecha, proveedor, Contrato, Productos.

Movimientos entre depósitos y/o sectores

Informaciones requeridas:

Cabecera: Fecha, Descripción.

Detalle: Deposito origen, Sector origen, Deposito destino, Sector destino, Cantidad a distribuir.

Funcionalidad/es:

-              Registrar el movimiento de productos entre los depósitos.

-              Se deberá poder agregar productos al listado utilizando código de barras.

Validación/es: Verificación de saldos para valores a disminuir dentro del depósito de origen.

Documento/s emitido/s: Comprobante de movimiento de productos según normativas de la entidad.

Reporte/s: Listado de movimientos realizados con filtro por Deposito Origen/Destino, Sector Origen/Destino, Producto, Rango de fecha.

Pedidos internos

Informaciones requeridas:

Cabecera: Número, Periodo, Fecha, Dependencia, funcionario, Documento digitalizado (PDF), Confirmación de datos (SI/NO).

Detalle: Producto, Observación, Cantidad pedido.

Funcionalidad/es: Registrar los pedidos internos. Esta sección está preparada para que las propias dependencias realicen sus solicitudes correspondientes. Solo se visualizarán los productos vinculados a la dependencia y los productos marcados como administrativos.

Validación/es: No se podrá agregar productos que no figuren como administrativos ni estén vinculados a la dependencia solicitante.

Documento/s emitido/s: FC 13 Pedido Interno. Reporte/s:

-              Listado general de pedidos realizados con filtro por rango de fecha, dependencia.

-              Listado detallado de los productos solicitados con filtros por rango de fecha, dependencia y producto.

Recepción de envases

Informaciones requeridas: Deposito, Fecha de recepción, Dependencia, funcionario, Producto, Cantidad de envases, Observación, Documento digitalizado (PDF).

Funcionalidad/es: Llevar el control de los productos que requieren reposición de envases como ser: Bidones de agua, Garrafas de gas, Extintores etc.

Validación/es: Solo recibir productos que figuran como que utilizan envases dentro de la configuración de datos del catálogo de productos.

Documento/s emitido/s: Comprobante de entrega de envases.

Reporte/s: Listado de envases recibidos con filtro por rango de fecha, producto,

dependencia.

Egresos

Informaciones requeridas:

Cabecera: Deposito, Número, Periodo, Fecha, Pedido interno de referencia, Dependencia, Documento digitalizado (PDF), Movimiento confirmado (SI/NO).

Detalle: Referencia a distribución, Cantidad a egresar, requiere reposición de

envases (SI/NO).

Funcionalidad/es:

-              Registro de los movimientos de egresos de los depósitos con destino a las dependencias de la entidad.

-              La carga de ítems que componen el egreso deberá poder realizar de manera rápido con procesos que no requieran de la utilización del mouse.

-              El proceso de agregar productos no puede superar los tres clics.

-              Solo se podrán visualizar y seleccionar productos en existencia y que no figuren dentro del listado actual.

-              Se deberá poder dar egreso a los productos utilizando código de barra.

Validación/es:

-              Solo productos en existencia dentro del depósito.

-              Un mismo producto no puede figurar dos veces en un egreso.

Documento/s emitido/s: FC 13 Pedido Interno. Reporte/s:

-              Listado general de egresos con sus totales, debe contar con filtros de rango de fecha, dependencia destino.

-              Listado detallado de egresos, debe contar con filtros de rango de fecha, dependencia destino y producto.

Devoluciones

Informaciones requeridas:

Cabecera: Deposito, Número, Periodo, Fecha, Dependencia, Documento digitalizado (PDF), Movimiento confirmado (SI/NO).

Detalle: Referencia a distribución, Observación, Cantidad devolución.

Funcionalidad/es:

-              Registro de devolución de productos a fin de regularizar el saldo del producto.

-              Se deberá poder agregar productos al listado utilizando el código de barra del producto.

Documento/s emitido/s: Comprobante de devolución de productos.

Reporte/s: Listado detallado de productos devueltos con filtro por rango de fecha, dependencia y producto.

Inventarios

Informaciones requeridas:

Cabecera: Deposito, Número, Periodo, Fecha de inicio y fin, Observaciones, Documento digitalizado (PDF).

Detalle: Fecha inventariado, Referencia a distribución, Observaciones, cantidad inventariado, Cantidad de ajuste positivo o negativo (+ o -).

Funcionalidad/es:

-              Llevar el control de inventarios y realizarlos a través del sistema.

-              Deberá existir una aplicación o entorno que permita realizar el inventario directamente desde una Tablet o Smartphone.

-              El inventario se podrá realizar cargando los datos manualmente o a través de un código de barra.

-              Para el proceso de inventariado por producto el sistema no debe exigir más de dos clics.

-              Generar de manera automático los valores de ajuste tanto para faltantes como para sobrantes

Validación/es: No debe permitir inventariar dos veces el mismo producto en el mismo sector del depósito.

Documento/s emitido/s:

-              Comprobante detallado del inventario.

-              FC 02 Hoja de inventario de bienes en existencia en depósito.

Reporte/s: Listado detallado de productos inventariados con filtros por rango de fecha, usuario que realizo el inventario, deposito, sector, producto.

Informes con formatos establecidos por normativas externas:

FC-02

Descripción: Hoja de inventario de bienes en existencia en depósitos. Filtros: Selección de inventario realizado.

Objeto: Controlar el inventario de bienes almacenados mediante control cruzado de las existencias registradas en libros con los bienes físicos encontrados en la fecha de realización.

Normativa vinculada: Manual de normas y procedimientos del Ministerio de Hacienda.

FC-12

Descripción: Registro de bienes en existencia en depósitos por tipo de artículo. Filtros: Rango de fecha y producto.

Objeto: Llevar el registro permanente del inventario de existencias en almacenes, en cantidades y valores, por cada clase o tipo de artículo.

Normativa vinculada: Manual de normas y procedimientos del Ministerio de Hacienda.

FC-13

Descripción: Pedido interno.

Filtros: Pedido interno o egreso vinculado.

Objeto: Solicitud de las dependencias oficiales para la provisión por compra o fabricación de bienes; hoja de ruta y registro de las actuaciones administrativas consiguientes hasta la adjudicación y entrega. Si las cantidades entregadas son inferiores a las solicitadas, en caso de requerir la diferencia deberá formularse un nuevo pedido.

Normativa vinculada: Manual de normas y procedimientos del Ministerio de Hacienda.

FC-14

Descripción: Nota de recepción de elementos en depósito o almacenes. Filtros: Ingreso vinculado.

Objeto: Documento que registra el ingreso de elementos en almacenes, certifica su recepción y es constancia indispensable para el pago de cuentas a proveedores.

Normativa vinculada: Manual de normas y procedimientos del Ministerio de Hacienda.

Otras herramientas:

Sistema adaptado al uso y generación de códigos de barras

El sistema se debe adecuar al uso de códigos de barra.

El sistema tendrá la opción de utilizar el propio código de barra impreso en los paquetes o envases de los productos o generar uno desde el sistema.

El sistema deberá ser compatible con impresoras de etiquetas, no obstante, también deberá estar preparado para imprimir desde impresoras estándares en hojas pre-cortadas del tipo adhesiva.

Notificaciones sobre productos a vencer

El sistema generará notificaciones referentes a productos a vencer dentro de un plazo configurable.

Notificaciones sobre reposición de productos

El sistema generará notificaciones referentes a reposición de productos que se encuentren fuera del rango establecido en los puntos críticos.

Otros materiales y accesos útiles

-              Acceso directo al sistema de Patrimonio del Estado.

-              Acceso directo al documento de normas y procedimientos. Acceso al archivo PDF.

 

Tesorería y Contabilidad

Tiene como principal objetivo es de llevar el control de la ejecución del plan financiero asignado a la entidad. El sistema contempla todas las exigencias a nivel de proceso que se requieren para llevar este control.

Los principales procesos contemplados son:

-              Carga del plan financiero mensual.

-              Registro de datos de CDPs.

-              Reservas por reprogramaciones

-              Otras reservas de carácter interno.

-              Control de reprogramaciones en curso, aprobación y aplicación de cambios.

-              Migración de saldos mensuales

-              Carga de compromisos directos, por órdenes, facturas u otros documentos que respalde un gasto.

-              Registración de metas.

-              Registración de la ejecución de metas.

-              Generación de reportes relacionados a las metas.

-              Validaciones en formulario de carga de compromisos.

-              Formulario de carga de cumplimiento de metas independientes a compromisos.

Así mismo genera todos los reportes y documentos necesarios como ser:

-              Ejecución del plan financiero.

-              Ejecución mensual del plan financiero.

-              Listado de reprogramaciones.

-              Listado de gasto con filtros por estructura, rubro, fecha etc.

-              Formatos de notas y/o comprobantes por cada proceso.

El sistema cuenta con una herramienta de control mensual de equidad entre la ejecución reflejada en el sistema contra la información almacenada en el SIAF.

Todas las secciones del sistema contemplan la posibilidad de adjuntar archivos digitalizados de los documentos oficiales de cada uno de los procesos.

El sistema genera reportes gráficos y listados con resúmenes que se reflejan en un panel principal, dando al usuario un panorama general de la ejecución del plan financiero.

Informaciones requeridas en la pantalla inicial:

-              Acceso a secciones más utilizadas del sistema. Ej.: Plan financiero, Reservas y CDPs, Compromisos, Reprogramaciones y Migraciones.

-              Acceso a la vista del plan financiero en modo desplegable.

-              Gráfico de área de evolución mensual de reservas y compromisos: Comportamiento de la ejecución del plan financiero con cortes mensuales

-              Gráfico de barras de ejecución por rubro de objeto del gasto: Se debe mostrar en columnas distintas por cada rubro de objeto del gasto su valor total, reservado (reservas + compromisos directos), comprometido.

-              Gráfico de torta para distribución del plan financiero por rubro: Muestra la distribución del plan financiero vigente por rubro.

-              Listado con acceso directo a últimas reservas y/o compromisos realizados: El mismo servirá para acceder de manera fácil a visualizar/editar datos recientes.

-              Porcentaje de reservas realizadas con el plan financiero.

-              Porcentaje de compromisos realizados con el plan financiero.

-              Porcentaje de ejecución del nivel 100.

-              Porcentaje de ejecución de los niveles 200 al 900.

-              Acceso a visualizar y configurar la presentación en modo transición.

Presentación en modo transición:

La presentación en modo transición consiste en la generación de un mecanismo donde se puedan seleccionar uno o varios datos/gráficos que figuran en el panel principal y estos puedan ser expuestos de manera dinámica en el monitor del usuario. Estará enfocado principalmente para ser visualizado en pantallas de gran tamaño (32 pulg. o superiores) dispuestos en puntos claves para demostrar el proceso de la gestión.

Los datos a mostrar en la transición deberán poder ser configurables por cada usuario.

Especificaciones de datos y sus propiedades:

Datos primarios o básicos requeridos Objetos del gasto

Informaciones requeridas: Número de OG, Denominación, Concepto, Abreviación.

Datos iniciales cargados: Se encuentra cargado toda la información de los objetos del gasto obtenidas desde el clasificador presupuestario.

Funcionalidad/es: Se podrá realizar búsquedas de objetos del gasto tanto por número, denominación, concepto, abreviación a fin de ayudar al usuario final a determinar cuál es el objeto del gasto indicado para la registración de datos.

Validación/es: No se podrán agregar objetos del gasto que no posean un Objeto del gasto padre cargado. No se podrán eliminar objetos del gasto que posean algún tipo de dato vinculado al mismo. Reporte/s: Se podrá emitir un listado completo y/o filtrado de los objetos del gasto

registrados.

Fuente de financiamiento

Informaciones requeridas: Número de fuente de financiamiento, Denominación.

Datos iniciales cargados: Se encuentra cargado toda la información de fuentes de financiamiento obtenidas desde el clasificador presupuestario.

Funcionalidad/es: Se podrá realizar búsqueda por número y denominación. Validación/es: Solo se podrán agregar valores divisibles entre 10 y menores a 100. Reporte/s: Se podrá emitir un listado completo y/o filtrado de los datos registrados.

Organismos financiadores

Informaciones requeridas: Número de organismo financiador, Denominación.

Datos iniciales cargados: Se encuentra cargado toda la información de fuentes de financiamiento obtenidas desde el clasificador presupuestario que son utilizados dentro de la entidad.

Funcionalidad/es: Se podrá realizar búsqueda por número y denominación. Validación/es: Solo valores numéricos inferiores a 1000.

Reporte/s: Se podrá emitir un listado completo y/o filtrado de los datos registrados.

Feriados

Informaciones requeridas: Fecha, Descripción.

Datos iniciales cargados: Deberá poseer registrado todas fechas correspondientes a feriados establecidos para los siguientes cinco años a partir del periodo de implementación del software.

Funcionalidad/es: Se podrá realizar búsqueda por fecha y descripción.

Validación/es: No se podrán registrar dos feriados con la misma fecha dentro del mismo

año.

Reporte/s: Se podrá emitir un listado completo y/o filtrado de los feriados registrados.

Información institucional:

Estructura

Informaciones requeridas: Periodo, Tipo de presupuesto, Programa, Sub-Programa, Proyecto, Distribución, Sub-Distribución, Denominación, Afectable.

Datos iniciales cargados: Ninguno. El sistema inicialmente no debe contar con ningún dato cargado en esta sección.

Migración de datos: Se deberán ver reflejada la estructura financiera del periodo vigente según el presupuesto aprobado.

Funcionalidad/es:

El sistema almacenará una estructura financiera distinta para cada periodo.

El sistema deberá contar con la posibilidad de generar una nueva estructura igual que la estructura utilizada en el periodo anterior.

El sistema debe permitir modificar esta nueva estructura creada.

Se determinarán estructuras del tipo afectable SI/NO, las afectables serán las únicas que podrán ser vinculadas a un plan financiero, las demás serán la resultante de las sumas de sus distribuciones.

Si bien el SIAF cuenta con una distribución por Tipo de presupuesto, Programa, Sub-Programa, Proyecto, el sistema deberá permitir disgregar la estructura hasta en dos niveles más a fin de dar la posibilidad a la entidad de distribuir montos por una estructura más específicas.

Validación/es:

No se podrán crear estructuras que no cuenten con un ítem superior que lo contengan a excepción de los tipos de presupuesto.

No se podrán generar distribuciones de estructuras dentro de una estructura del tipo afectable.

No se podrán eliminar estructuras que posean algún tipo de registro de dato vinculada a la misma.

Reporte/s: Se podrá emitir un listado completo y/o filtrado de la estructura seleccionado el periodo deseado y los tipos de distribuciones seleccionados.

Funcionarios

Informaciones requeridas: CI, Nombre, Apellido, Imagen, Organigrama, Cargo Interno, Fecha de nacimiento, Sexo, Teléfono, Interno, Dirección, Correo, Banco, Número de cuenta, Activo.

Datos iniciales cargados: Ninguno. El sistema inicialmente no debe contar con ningún dato cargado en esta sección.

Migración de datos: Se deberá proceder a la carga de datos de todos los funcionarios según la última nómina de funcionarios, tanto nombrados como contratados.

Funcionalidad/es: Se podrán consultar datos de funcionarios por distintos campos. La búsqueda un funcionario por cédula, nombre, apellido, dependencia, cargo, teléfono, interno deberá ser de manera rápida desde el mismo listado principal. Se establecerá un campo activo SI/NO que determinará si el funcionario sigue o no formando parte de la entidad, este valor se deberá tener en cuenta al momento de generar gastos, el sistema no debe permitir generar gastos contra un funcionario inactivo.

Obtención dinámica de datos: El sistema contará con un sistema de obtención dinámica de datos de personas introduciendo su número de CI. El mecanismo obtendrá datos de algún servidor en las nubes que registre esta información. Requiere que el servidor posee conexión a internet.

Validación/es: No se podrán cargar datos de funcionarios sin su número de cédula. Los únicos campos obligatorios serán CI, Nombre y Apellido.

Reporte/s: Se podrá emitir un listado completo los funcionarios, el listado debe permitir filtrar por Organigrama, Cargo Interno, Fecha de nacimiento, Sexo, Banco, Activo.

Proveedores

Informaciones requeridas: RUC, Nombre, Teléfono, Dirección, Correo, Banco, Número de cuenta bancaria, País de origen.

Datos iniciales cargados: Ninguno. El sistema inicialmente no debe contar con ningún dato cargado en esta sección.

Migración de datos: Se deberá proceder a la carga de datos de todos los proveedores según listado que deberá ser proveído por la entidad contratante.

Funcionalidad/es: Se podrán consultar datos de funcionarios de la entidad.

Obtención dinámica de datos: El sistema contará con un sistema de obtención dinámica de datos del beneficiario introduciendo su número de RUC. El mecanismo obtendrá datos de algún servidor en las nubes que registre esta información. Requiere que el servidor posee conexión a internet.

Validación/es: El identificador del proveedor será su número de RUC o identificador único para proveedores que no poseen RUC.

Reporte/s: Se podrá emitir un listado completo los proveedores, el listado debe permitir filtrar por Parte del nombre, País de origen y Banco.

Administración de datos del presupuesto y plan financiero:

Presupuesto

Informaciones requeridas: Estructura (Periodo, Tipo de presupuesto, Programa, Sub- Programa, Proyecto, Distribución, Sub-Distribución), Objeto del gasto, Fuente de financiamiento, Organismo financiador, Departamento, Valor, Valor inicial.

Datos iniciales cargados: Ninguno. El sistema inicialmente no debe contar con ningún dato cargado en esta sección.

Migración de datos: Se deberá ver reflejado el presupuesto actual/vigente de la entidad, en el caso que la estructura posea una distribución más especifica que la dada en el SIAF, la entidad deberá proveer los valores de esta distribución en el Excel a fin de migrar los datos.

Funcionalidad/es: Se podrá consultar la distribución del presupuesto asignado a la entidad, así mismo se podrá consultar tanto sus valores iniciales como actuales.

Validación/es: Los montos asignados no podrán ser menores que el plan financiero asignado en la misma línea. Solo se podrá asignar montos a estructuras del tipo afectable.

Reporte/s: Se podrá emitir un listado completo y/o filtrado de la distribución del presupuesto seleccionando el presupuesto inicial y/o vigente.

Plan financiero

Informaciones requeridas: Estructura (Periodo, Tipo de presupuesto, Programa, Sub- Programa, Proyecto, Distribución, Sub-Distribución), Objeto del gasto, Fuente de financiamiento, Organismo financiador, Departamento, Mes, Valor.

Datos iniciales cargados: Ninguno. El sistema inicialmente no debe contar con ningún dato cargado en esta sección.

Migración de datos: Se deberá ver reflejado el plan financiero inicial de entidad según información emitida por el SIAF. La información a ser migrada será correspondiente al plan financiero mensual, los valores anuales serán los correspondientes a la suma de los valores mensuales.

Funcionalidad/es: Se podrá consultar la situación del plan financiero y su ejecución. Se podrá consultar filtrando por estructura y/o OG indiferentemente. El sistema contará con un mecanismo de importación y verificación de datos comparando el pdf emitido por el SIAF, con esto se agilizará la carga del plan financiero y se podrá realizar controles periódicos sobre la consistencia con los datos del sistema contra los del SIAF.

Validación/es: Los montos asignados no podrán ser menores que la suma de las reservas

+ compromisos directos. La sumatoria de valores mensuales no podrá ser mayor que el presupuesto cargado. Solo se podrá asignar montos a estructuras del tipo afectable. Todos los montos deberán ser asignados a un mes específico.

Reporte/s:

Listado general: Acceso a un listado general de datos cargados con filtros por cada tipo de dato (Estructura, Objeto del gasto, Fuente de financiamiento, Organismo financiador, Departamento, Mes).

Reporte de distribución: Se podrá acceder a un reporte de distribución de las asignaciones del plan financiero.

Reporte de distribución mensual: Se podrá acceder a un reporte de distribución de las asignaciones del plan financiero mes tras mes dentro del año.

Reporte de ejecución: Se podrá visualizar la ejecución del plan financiero anual según los montos comprometidos.

Reporte de ejecución (Reservas): Se podrá visualizar la ejecución del plan financiero anual según los montos reservados + compromisos directos.

Reporte de ejecución mensual: Se podrá visualizar la ejecución mensual mes tras mes durante el año en un mismo reporte.

Observación: Todos estos reportes permitirán según la lógica del reporte filtrar los datos por Estructura, Objeto del gasto, Fuente de financiamiento, Organismo financiador, Departamento, Mes.

Procesos y/o gestiones operativas:

Certificados de disponibilidades presupuestarias tanto de carácter interno como oficial

Informaciones requeridas:

Cabecera: Tipo (CDP, INTERNO, CAJA CHICA), Nro., Periodo, Fecha, Detalle, Documento digitalizado, Liberado, Fecha liberación.

Detalle: Estructura, OG, FF, OF, Dpto., Valor, Valor liberado

Datos iniciales cargados: Ninguno. El sistema inicialmente no debe contar con ningún dato cargado en esta sección.

Migración de datos: Se debe ver reflejado todos los CDPs emitidos hasta la fecha de migración de datos, todos deben contar con su documento físico adjunto en el sistema

Funcionalidad/es: Llevar el control y saldo de las certificaciones de disponibilidad presupuestaria tanto las oficiales como las internas o reservas para caja chica. Las reservas que se realicen en están certificaciones serán realizadas contra el plan financiero anual sin discriminación de saldo por meses del plan financiero mensual.

Funcionalidad/es vinculada/s con otra/s sección/es:

-   Generación automática de CDPS que se encuentren solicitados desde un PAC, se debe mostrar un listado de los CDP’s pendientes de emitir porque poseen un PAC sin CDP (Vinculación con ADQUISICIONES).

Alertas y Notificaciones: El sistema deberá alertar sobre la existencia de CDPs emitidos que se encuentran sin ejecución. Esta notificación se dará a fin de colaborar con el proceso de anulación de CDPs que no serán utilizados y la liberación de los que ya han sido utilizados en su totalidad. Quedará registrado tanto el valor inicial del CDP como el valor luego de ser liberado.

Validación/es: Las reservas realizadas no podrán ser menor que los compromisos existentes dentro de esta reserva. Las reservas no podrán ser mayores que el saldo del plan financiero anual para esa línea presupuestaria. Las reservas se deberán realizar en el mismo OG que se encuentra especificado en el plan financiero.

Documento/s emitido/s: Emite comprobante de reserva realizado según estándares de la institución.

Reporte/s:

-              Listado general de CDPs: Listado general de las cabeceras de los CDPs con los valores totales reservados.

-              Ejecución de CDPs: Ejecución de un CDP específico mostrando solo los totales de los compromisos realizados

-              Ejecución detallada de CDPs: Ejecución detallada de los compromisos de un CDP específico.

-              Reservas por línea presupuestaria: Listado de reservas realizadas en una línea presupuestaria especificada.

Observación: Todos los reportes deberán poder ser filtrados por tipo y rango de fecha.

Compromisos

Informaciones requeridas:

Cabecera: Nro., Periodo, Fecha, Nro. de Expediente, Comprobante (Tipo, Número, Fecha), CDP, Orden, Proveedor, funcionario, Estructura, OG, FF, OF, Dpto., Concepto, Valor total, Documento digitalizado, Estado

Detalle: Comprobante (Tipo, Número, Fecha), CDP, Orden, Proveedor, funcionario, Estructura, OG, FF, OF, Dpto., Mes, Concepto, Valor

Datos iniciales cargados: Ninguno. El sistema inicialmente no debe contar con ningún dato cargado en esta sección.

Migración de datos: Se deberán ver reflejados todos los datos de pagos realizados. Los datos serán migrados a partir de datos de obligaciones realizadas o Excel proveído por la entidad.

Funcionalidad/es:

-              Se llevará el control de todos los gastos realizados contra el plan financiero.

-              Los datos cargados en la cabecera serán utilizados como un filtro para determinar que todos los registros del detalle llevarán la misma información, por lo tanto, en la cabecera solo son datos obligatorios Nro., Periodo, Fecha, Número de Expediente, Valor total, Estado. De tal manera lo datos que no son especificados en la cabecera podrán ser variables en el detalle.

Validación/es:

-              La imputación de los gastos se hará únicamente contra estructuras afectables que cuenten con saldo en el plan financiero.

-              Todas las imputaciones se deberán realizar a un objeto de gasto a la unidad, se deberá verificar que su correspondencia en la decena posea saldo suficiente para poder realizar la imputación.

Documento/s emitido/s: Emite comprobante de compromiso realizado indicando la línea presupuestaria afectada.

Reporte/s: Se podrá generar listados de los gastos filtrando por todos los campos del detalle del compromiso.

Reprogramaciones y migraciones

Informaciones requeridas:

Cabecera: Fecha de inicio de planificación, descripción, tipo (OFICIAL, INTERNA, MIGRACION MENSUAL), Tipo de variación (MIGRACION, AUMENTO, DISMINUCION), Periodo, Filtros (estructura, OG, FF, OF, Dpto.),

Información de aprobación: Fecha, Tipo documento aprobación (resolución, decreto), nro. de documento de aprobación.

Detalle de líneas a aumentar: Línea presupuestaria, Valor a aumentar.

Detalle de líneas a disminuir: Línea presupuestaria, Valor a disminuir.

Datos iniciales cargados: Ninguno. El sistema inicialmente no debe contar con ningún dato cargado en esta sección.

Migración de datos: Se deberán reflejar todas las migraciones aprobadas y solicitadas realizadas durante el periodo vigente.

Funcionalidad/es: Llevar el control de los procesos de reprogramación del plan financiero, así como automatizar la modificación en el proceso de migración de saldos del plan financiero mensual.

Validación/es:

-              Solamente las reprogramaciones del tipo OFICIAL podrán ser AUMENTO o DISMINUCIÓN, las demás únicamente MIGRACIÓN.

-              Los valores a disminuir afectarán al saldo actual del plan financiero, inclusive si la reprogramación no se encontrase aprobada.

-              Los valores a aumentar solo afectarán al plan financiero una vez que la reprogramación sea aprobada.

-              Las reprogramaciones del tipo INTERNO reciben aprobación de manera automática.

-              Los montos a disminuir deberán ser validados contra los compromisos y/o reservas realizadas en la línea correspondiente.

Alertas y Notificaciones: El sistema deberá alertar sobre la existencia reprogramaciones cargadas que no han sido aprobadas luego de 60 días a fin de proceder con la aprobación o anular la reprogramación en el caso que corresponda.

Documento/s emitido/s: Emite comprobante de reprogramación con los datos cargada en el sistema, identificando los totales, detalle a aumentar y detalle a disminuir.

Reporte/s:

Listado general de reprogramaciones: Listado general de reprogramaciones realizadas con filtros por tipo y rango de fecha:

Listado detallado de reprogramaciones: Listado detallado de las líneas afectadas en las reprogramaciones.

Otras herramientas:

Plan financiero en modo desplegable:

Sistema de navegación por ítems desplegables a fin de proporcionar al usuario un método fácil de visualizar como se distribuye el actual plan financiero.

El mecanismo será con registros que se despliegan con los datos del detalle de su ejecución al hacer clic sobre cada registro.

Se podrá quitar un reporte en pdf de cada ítem seleccionado donde se podrá indicar hasta que nivel de detalle se desea que emita el reporte.

Los ítems se deberán desplegar teniendo en cuenta el siguiente orden:

Entidad > Tipo de presupuesto > Programa > Sub-Programa > Proyecto > Distribución > Sub-Distribución > Objeto del gasto > Fuente de financiamiento/Organismo financiador/Departamento > CDPs o Reservas > Compromisos

Otros materiales y accesos útiles

-              Acceso directo al sistema al SIPP.

-              Acceso directo al clasificador presupuestario vigente. Acceso al archivo PDF. Búsqueda de objeto de gasto por descripción.

Panel principal específico del módulo con datos gerenciales de tesorería:

Informaciones requeridas:

-              Acceso a secciones más utilizadas del sistema. Ej.: Pagos pendientes, Retenciones generadas, Cheques, Comprobantes de pago.

-              Acceso rápido a comprobante de pago por número o beneficiario.

-              Gráfico de área de evolución mensual de pagos: Comportamiento de la ejecución del plan financiero con cortes mensuales

-              Gráfico de barras de ejecución por rubro de objeto del gasto: Se debe mostrar en columnas distintas por cada rubro de objeto del gasto su valor total, reservado (reservas + compromisos directos), comprometido.

-              Gráfico de torta para distribución del plan financiero por rubro: Muestra la distribución del plan financiero vigente por rubro.

-              Listado con acceso directo a últimos pagos realizados: El mismo servirá para acceder de manera fácil a visualizar/editar datos recientes.

-              Porcentaje de pagos realizados con el plan financiero.

-              Porcentaje de ejecución del nivel 100.

-              Porcentaje de ejecución de los niveles 200 al 900.

-              Acceso a visualizar y configurar la presentación en modo transición.

Adecuación del entorno a las especificaciones generales actualizadas:

El módulo se deberá adecuar a las especificaciones generales establecidas en los puntos:

-              Actualización de la plataforma del sistema.

-              Actualizaciones de base de datos y resguardo de datos.

-              Herramientas generales para el manejo de datos.

Separar gráficamente las secciones indicadas en el menú pagos:

Actualmente se encuentra visualizado en una única sección varios estados del pago. Se requiere distribuir esta información en sectores independientes a fin de disponer la información de mejor manera.

Sección de pagos pendientes:

Se podrán realizar búsquedas con cada columna y generar informes correspondientes a este listado.

Sección de retenciones:

Se podrán realizar búsquedas con cada columna y generar informes correspondientes a este listado.

Comprobantes de pagos:

Se podrán realizar búsquedas con cada columna y generar informes correspondientes a este listado.

Configuración dinámica de coordenadas de impresión de cheque:

El sistema deberá permitir la configuración de las coordenadas XY para la impresión de los textos sobre el cheque. Esta funcionalidad estará disponible para usuarios autorizados. Cada cuenta podrá tener una configuración distinta.

Configuración de numero de cheque para talonario nuevo:

Los usuarios autorizados podrán asignar el número de cheque que deberá ser asignado a la cuenta. Esta funcionalidad se utilizará cuando se cambian los formularios, luego la asignación de número deberá continuar siendo correlativa.

Cada cuenta deberá poseer una configuración independiente.

Optimización de búsqueda de comprobantes:

Se deberá optimizar el mecanismo de búsqueda en registros de pagos, se podrán buscar datos por campos.

Se podrán emitir listado con los mismos filtros y distintos tipos de ordenamiento de datos.

Correlatividad numérica para comprobantes de pago:

La correlatividad de comprobantes de pago podrá ser configurado por grupo de objeto del gasto.

Conectividad con VUE e importación dinámica de ingresos:

Generación de mecanismos de conectividad con VUE e importación dinámica de ingresos, disparando procesos automáticos.

Modificación y generación de reportes con informaciones de VUE:

Modificación de reportes de ingresos incorporando todos los datos obtenidos correspondientes a ingresos registrados en el VUE.

 

Viáticos

Tiene como principal objetivo encargase de gestionar todo lo concerniente a viáticos, desde la solicitud hasta la rendición del mismo. Pasando por procesos como el cálculo de valores, validaciones por usuarios, asignación de resoluciones y otros.

Acciones y procesos principales:

-              Administración de destinos nacionales e internacionales y sus montos.

-              Carga de solicitud de viáticos, asignado destino/s y funcionario/s.

-              Cálculo de viático según tipo de funcionario, destino y pernote.

-              Posibilidad de Múltiples destinos/ciudades/departamento por solicitud.

-              Aplicación de resolución vinculada a la solicitud.

-              Redición de viáticos por funcionario.

-              Alarmas sobre rendiciones.

-              Asignación de varios niveles para autorización de los viáticos.

-              Incorporación en panel principal del perfil del funcionario de los datos y montos de viáticos.

-              Generación de documentaciones relacionadas al viatico como Orden de Trabajo y otros.

-              Generación de reportes consolidados de todos los tipos de remuneraciones percibidas incluyendo los viáticos.

Principales reportes:

-              Listado de viáticos por dependencias.

-              Listado de viáticos por funcionarios.

-              Ranking de destinos con más viáticos (cantidad y monto).

-              Ranking de funcionarios según viáticos asignados.

-              Rendiciones realizadas en rango de fecha.

-              Rendiciones pendientes de presentar.

-              Listado de viáticos con información de pago vinculantes (Obligación, Comprobante de pago).

 

Transporte

Tiene como principal objetivo la elaboración de las ordenes de trabajos, combinando datos de funcionarios, permisos y vehículos. Sistema de enlace con sistema de combustibles de Petropar a fin de realizar controles cruzados entre las órdenes y sus correspondientes cargas de combustibles.

Acciones y procesos principales:

-              Administración de destinos nacionales.

-              Carga e emisión de órdenes de trabajo.

-              Vinculación de carga de combustibles con las OT.

-              Redición de las ordenes de trabajos.

-              Generación de alarmas sobre OT no rendidas.

-              Responsables por vehículos.

-              Informe sobre el estado y la devolución de los vehículos.

-              Control de km de vehículos y alarmas de mantenimiento.

-              Sistema de solicitud digital de vehículo con chofer y acompañantes por parte de funcionario.

-              Autorización en hasta tres niveles.

Principales reportes:

-              Listado de ordenes por funcionarios, vehículos y rangos.

-              Estado de vehículos.

-              Resumen de tipo de vehículos y rango de utilización.

-              Utilización de combustible por vehículos, funcionarios, destinos y rango de fecha.

-              Rendiciones presentadas y pendientes.

-              Destinos y vehículos más utilizados.

 

RRHH - Gestión del Personal

Tiene como principal objetivo la gestión integral de los funcionarios dentro de la institución, sean estos nombrados, contratados, comisionados o pasantes. La gestión integral va desde la registración de los usuarios, pasando por el historial de todos sus pasos por dependencias, cargos, categorías etc. Esta herramienta es la encargada de realizar los cálculos de remuneraciones salariales según las normativas vigentes y teniendo como insumo las marcaciones del funcionario, sus permisos, sanciones, vacaciones, etc.

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 preselecció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 número 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:

o Una cabera con los datos del funcionario.

o Fecha de ingreso

o Antigüedad.

o Cantidad de vacaciones correspondientes

o Sumatoria de vacaciones tomadas

o Saldo de vacaciones pendientes

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

AUTOGESTION DE TRAMITES DEL FUNCIONARIO:

El sistema contará con la posibilidad de la autogestión de tramites como consultas de asistencias, emisión de certificados, gestión de legajos, solicitud de viatico, solicitudes de permisos o licencias y seguimiento de estos trámites, solicitudes de capacitaciones, consultas de evaluación de desempeño, históricos de liquidación, emisión de informes de actividades de HE, HA y otros relacionados al puesto o establecidas por normativas vigentes.

Estos contaran con niveles de aprobación según la estructura organizativa vigente, reglamentos y procedimientos establecidos por cada caso.

EVALUACION DE DESEMPEÑO:

El sistema deberá contar con un módulo de evaluación de desempeño, el cual se regirá de acuerdo con las normativas establecidas por el INTN. Estos deberán contar con aprobaciones y validaciones por nivel según estructura organizativa.

GESTION DE CONTRATACION:

El sistema deberá contar con un módulo de Gestión de Contratación, para todo el proceso estipulado en las normativas de la Función Publica y las normativas establecidas por el INTN. Estos deberán contar con aprobaciones y validaciones por nivel según estructura organizativa.

 

 

El área solicitante, la Dirección de Tecnologías de la Información, Comunicación y Gestión Estratégica del Instituto Nacional de Tecnología, Normalización y Metrología (INTN), a cargo del Lic. Cesar Lezcano y el Lic. Rogney Caballero, quienes realizaron el pedido a través del Memorando DINF N° 55/2022.

 

El área solicitante menciona que el pedido del proceso es realizado a fin de integrar y facilitar las tareas de control e información actualizada en línea, en especial para levantar observaciones de la auditoría interna institucional.

Ítem	Descripción del bien	Cantidad	Unidad de medida	Lugar de entrega de los bienes	Fecha(s) final(es) de entrega de los bienes
(Indicar el N°)	(Indicar la descripción de los bienes)	(Insertar la cantidad de bienes a proveer)	(Indicar la unidad de medida de los bienes	(Indicar el nombre del lugar)	(Indicar la(s) fecha(s) de entrega requerida(s)

Ítem	Descripción del bien	Cantidad	Unidad de medida	Lugar de entrega de los bienes	Fecha(s) final(es) de entrega de los bienes
1	ADQUISICIÓN DE SISTEMA INTEGRADO DE GESTIÓN Y ADMINISTRACIÓN	1	unidad	Avda. Gral. Artigas N° 3973 c/ Gral Roa	El mismo será disgregado por sub Ítems por cada uno de los módulos/sistemas solicitados, y se definirán dos fases. Fase 1 Implementación Inicial: Descripción de tareas: Instalación, migración de datos, capacitación inicial y puesta en marcha del sistema. Definición de porcentaje: 50% del monto del Sub Ítem adjudicado. Plazo: 30 días desde la recepción de la orden de servicio por parte del proveedor por cada sistema/modulo. Fase 2 Implementación Final: Descripción de tareas: Adecuaciones específicas de procesos, refuerzos de capacitaciones en el uso, generación de reportes o modificaciones solicitadas. Definición de porcentaje para el pago: 50% del monto del Sub Ítem adjudicado. Plazo: 90 días desde la recepción de la orden de compra por parte del proveedor por cada sistema/modulo.

No aplica

No aplica

No aplica

Planificación de indicadores de cumplimiento:

 

Documento requerido para acreditar el cumplimiento contractual será: Informes de Realización de los Servicios por Sistema/Módulos.
Indicador	Tipo	Fecha de Presentación Prevista
Informe de realización de los servicios del Ítem 1 FASE 1 Implementación Inicial.	Informe	30 días desde la recepción de la orden de servicio por parte del proveedor.
Informe de realización de los servicios del Ítem 1 FASE 2 Implementación Final.	Informe	90 días desde la recepción de la orden de servicio por parte del proveedor.

La convocante adjudicará el contrato al oferente cuya oferta haya sido evaluada como la más baja y cumpla sustancialmente con los requisitos de las bases y condiciones, siempre y cuando la convocante determine que el oferente está calificado para ejecutar el contrato satisfactoriamente.

La comunicación de la adjudicación a los oferentes será como sigue:

1. Dentro de los cinco (5) días corridos de haberse resuelto la adjudicación, la convocante comunicará a través del Sistema de Información de Contrataciones Públicas, copia del informe de evaluación y del acto administrativo de adjudicación, los cuales serán puestos a disposición pública en el referido sistema. Adicionalmente el sistema generará una notificación a los oferentes por los medios remotos de comunicación electrónica pertinentes, la cual será reglamentada por la DNCP.

2. En sustitución de la notificación a través del Sistema de Información de Contrataciones Públicas, las convocantes podrán dar a conocer la adjudicación por cédula de notificación a cada uno de los oferentes, acompañados de la copia íntegra del acto administrativo y del informe de evaluación. La no entrega del informe en ocasión de la notificación, suspende el plazo para formular protestas hasta tanto la convocante haga entrega de dicha copia al oferente solicitante.

3. En caso de la convocante opte por la notificación física a los oferentes participantes, deberá realizarse únicamente con el acuse de recibo y en el mismo con expresa mención de haber recibido el informe de evaluación y la resolución de adjudicación.

4. Las cancelaciones o declaraciones desiertas deberán ser notificadas a todos los oferentes, según el procedimiento indicado precedentemente.

5. Las notificaciones realizadas en virtud al contrato, deberán ser por escrito y dirigirse a la dirección indicada en el contrato.

 

Una vez notificado el resultado del proceso, el oferente tendrá la facultad de solicitar una audiencia a fin de que la convocante explique los fundamentos que motivan su decisión.

La solicitud de audiencia informativa no suspenderá ni interrumpirá el plazo para la interposición de protestas.

La misma deberá ser solicitada dentro de los dos (2) días hábiles siguientes en que el oferente haya tomado conocimiento de los términos del Informe de Evaluación de Ofertas.

La convocante deberá dar respuesta a dicha solicitud dentro de los dos (2) días hábiles de haberla recibido y realizar la audiencia en un plazo que no exceda de dos (2) días hábiles siguientes a la fecha de respuesta al oferente.

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.