El Suministro deberá incluir todos aquellos ítems que no hubiesen sido expresamente indicados en la presente sección, pero que pueda inferirse razonablemente que son necesarios para satisfacer el requisito de suministro indicado, por lo tanto, dichos bienes serán suministrados por el Proveedor como si hubiesen sido expresamente mencionados, salvo disposición contraria en el Contrato.
Los bienes suministrados deberán ajustarse a las especificaciones técnicas y las normas estipuladas en este apartado. En caso de que no se haga referencia a una norma aplicable, la norma será aquella que resulte equivalente o superior a las normas oficiales de la República del Paraguay. Cualquier cambio de dichos códigos o normas durante la ejecución del contrato se aplicará solamente con la aprobación de la contratante y dicho cambio se regirá de conformidad a la cláusula de adendas y cambios.
El Proveedor tendrá derecho a rehusar responsabilidad por cualquier diseño, dato, plano, especificación u otro documento, o por cualquier modificación proporcionada o diseñada por o en nombre de la Contratante, mediante notificación a la misma de dicho rechazo.
Los productos a ser requeridos cuentan con las siguientes especificaciones técnicas:
Especificaciones Técnicas
1) ADQUISICION DE SOFTWARE DE SISTEMA DE GESTION ADMINISTRATIVA.
DETALLE DE LOS PROCESOS DEL SISTEMA REQUERIDO
En el presente documento se describe las funcionalidades específicas del sistema requerido. No obstante, los sistemas cotizados no son sistemas cerrados, se podrá seguir incorporando los reportes que sean necesarios para el cumplimiento de las necesidades de la dependencia y de la institución, siempre y cuando estos se encuentren dentro de los procesos y/o funcionalidades citados dentro de las siguientes especificaciones.
Listado de sistemas que forman parte del presente documento de especificaciones de procesos:
El sistema de Gestión de Adquisiciones se encarga 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:
Así mismo genera todos los reportes y documentos necesarios como ser:
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
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
nombres.
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 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 PrePAC
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:
Reporte/s:
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:
Documento/s emitido/s:
Reporte/s:
CDP´s
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, todo 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:
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á:
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:
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:
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:
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:
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.
fecha y hora.
Validación/es: No puede existir más de un evento vinculado a un llamado en la misma
Reporte/s: Listado de eventos a realizarse, se podrá filtrar por tipo, rango de fecha .
Otros materiales y accesos útiles
DESCRIPCIÓN GENERAL
El sistema de Gestión de Contratos se encarga 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:
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.
fecha y hora. contrato.
Validación/es: No puede existir más de un evento vinculado a un contrato en la misma
Reporte/s: Listado de eventos a realizarse, se podrá filtrar por tipo, rango de fecha y
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
DESCRIPCIÓN GENERAL
El sistema de Gestión Presupuestaria se encarga 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:
Así mismo genera todos los reportes y documentos necesarios como ser:
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
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í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.
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:
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:
Validación/es:
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:
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
El sistema de Gestión Presupuestaria se encarga 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. El detalle de las actualizaciones que se deberán realizar son (Todas las funcionalidades actuales deberán estar presentes en la actualización):
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:
Presentación en modo transición
Los datos a mostrar en la transición deberán poder ser configurables por cada usuario.
Adecuación del entorno a las especificaciones generales actualizadas
El módulo se deberá adecuar a las especificaciones generales establecidas en los puntos:
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.
DESCRIPCION GENERAL
El sistema de Viáticos es el encargado 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
PRINCIPALES REPORTES
El módulo de Recursos Humanos debe encargarse de la gestión completa de los funcionarios nombrados
y contratados dentro de la institución.
Las funciones generales que debe cumplir son:
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
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:
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:
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:
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:
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:
Informes y Reportes:
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:
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:
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:
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:
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:
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:
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:
Mecanismos aplicables:
Trabajos de configuración y desarrollo:
Validaciones:
Informes y Reportes:
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:
Procesos:
Informes y Reportes:
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:
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:
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:
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
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:
Informes y Reportes:
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:
Informes y Reportes:
RESOLUCIONES VINCULADAS A LA GESTIÓN DE RRHH
Carga de resoluciones vinculadas a procesos de Recurso Humano. Se debe poder visualizar una copia digitalizada de las resoluciones que afectan los procesos.
Datos específicos: Nro., Periodo, Descripción, Firmantes. Archivo adjunto: Archivo en formato pdf.
Búsqueda: Se debe buscar tanto por numero como por descripción, se debe listar todos los movimientos que hacen referencia a esta resolución.
Informes y Reportes:
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:
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:
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:
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:
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:
Informes y Reportes:
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:
Informes y Reportes:
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:
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:
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:
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
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:
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:
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:
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:
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:
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
Informes y Reportes:
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
Datos específicos: Funcionario, Mes, Rubro, Concepto, tipo de descuento, monto de descuento, estado, monto calculado, monto aplicado.
Informes y Reportes:
ESPECIFICACIONES DE LA PLATAFORMA DEL SISTEMA
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ógicas de negocio se debe realizar a través de triggers en base de datos.
La auditoría de registros se debe realizar a través de triggers en las tablas, registrando todos los cambios que se dieron y guardando todos los datos. El almacenamiento de estos datos debe ser en una base de datos distinta a fin de que el backup de auditoria puede ser incremental y el backup de datos una copia o en espejo.
El sistema se debe adecuar totalmente para el acceso a través de Tablets o Smartphone, la navegación debe ser sencilla y el sistema debe correr sin ningún inconveniente sobre los browsers más utilizados.
El sistema debe estar orientado al usuario operador, facilitando en todo momento el mecanismo de carga de datos.
Todos los informes deberán ser emitidos en formato pdf, los informes del tipo listados deberán ser exportables a Excel.
Todos los procesos citados dentro de las especificaciones técnicas deberán formar parte del sistema en general, no necesariamente dentro del módulo en el cual fue expuesta la funcionalidad. Esto a modo de no generar procesos duplicados y/o entornos distintos para la realización de una misma actividad.
Las políticas de acceso a usuarios deben permitir un acceso por roles que podrá ser configurable según las exigencias de la Entidad.
ESPECIFICACIONES SOBRE PLATAFORMAS Y METODOS DE PROGRAMACIÓN
Sistema en ambiente web WEB DEVELOPMENT
El sistema debe correr en ambiente web utilizando lenguajes con gran cantidad de soporte en línea.
Los códigos deberán ser entregados en su totalidad a la Entidad. Los códigos podrán ser modificados para el uso dentro de la misma entidad/administración, no podrán ser donados ni comercializados a otras entidades o administraciones.
Para los lenguajes compilados será exigido entregar los códigos fuentes correspondientes.
Diseño web adaptativo WEB RESPONSIVE
El diseño web adaptable (o adaptativo), conocido por las siglas RWD del inglés Responsive Web Design, es una filosofía de diseño y desarrollo cuyo objetivo es adaptar la apariencia de las páginas web al dispositivo que se esté utilizando para visualizarlas. Hoy día las páginas web se visualizan en multitud de dispositivos como tabletas, teléfonos inteligentes, libros electrónicos, portátiles, PCs, etcétera. Además, aún dentro de cada tipo, cada dispositivo tiene sus características concretas: tamaño de pantalla, resolución, potencia de CPU, sistema operativo o capacidad de memoria entre otras. Esta tecnología pretende que, con un único diseño web, se obtenga una visualización adecuada en cualquier dispositivo.
Base de datos tipo Open Source
El sistema utiliza una base de datos del tipo Open Source, la base de datos seleccionada posee las siguientes características:
Framework de desarrollo
El sistema está desarrollado sobre un "framework" (infraestructura, armazón, marco), en términos generales, un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar.
En el desarrollo de software, un framework o infraestructura digital, es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos concretos de software, que puede servir de base para la organización y desarrollo de software. Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes de un proyecto.
El framework utilizado deberá estar entre los más populares y debe contar con una gran cantidad de soporte en línea.
Programación en capas
Se requerirá de una programación por capas es decir una arquitectura cliente-servidor en el que el objetivo primordial es la separación de la lógica de negocios de la lógica de diseño; un ejemplo básico de esto consiste en separar la capa de datos de la capa de presentación al usuario.
La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algún cambio, solo se ataca al nivel requerido sin tener que revisar entre código mezclado.
Además, permite distribuir el trabajo de creación de una aplicación por niveles; de este modo, cada grupo de trabajo está totalmente abstraído del resto de niveles, de forma que basta con conocer la API que existe entre niveles.
En el diseño de sistemas informáticos actual se suelen usar las arquitecturas multinivel o Programación por capas. En dichas arquitecturas a cada nivel se le confía una misión simple, lo que permite el diseño de arquitecturas escalables (que pueden ampliarse con facilidad en caso de que las necesidades aumenten).
Mecanismo de validación de lógica de datos
La lógica de datos deberá estar aplicada en la base de datos a través de 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 a grandes rasgos el tipo de validación que se realiza.
Método de resguardo de datos
Todos los datos del sistema o de los sistemas que intervengan las especificaciones técnicas sobre las funcionalidades requeridas deberán almacenarse en una única base de datos. Esto hará posible que, si varios sectores del sistema utilizan una misma información, puedan nutrir un único lugar de carga de datos y así todas estas secciones trabajar de manera cooperativa para la generación y edición de datos.
CONTROL DE ACCESO
Políticas de acceso a las secciones del sistema
El acceso a las secciones del sistema será asignado por roles que englobaran permisos. El sistema tendrá un listado general de permisos sobre cada sección del sistema que permita:
Se podrán crear roles nuevos con la combinación de permisos que se desea.
Los usuarios no se podrán asignar directamente a permisos, se deberán vincularán únicamente a roles. Pudiéndose vincular a uno o más roles.
Los usuarios tendrán una propiedad de usuario activo (SI/NO), solo podrán acceder al sistema los usuarios activos SI.
Las creaciones de roles y asignaciones de los mismos deberán ser registrados en la tabla de auditoria de datos.
Políticas de clave de acceso
Políticas de claves de acceso configurables. Se podrá configurar en el sistema el nivel de seguridad exigido al usuario al momento de ingresar una nueva contraseña. Entre los tipos de configuración que se podrán seleccionar están:
El sistema permitirá configurar una periodicidad para el cambio de la clave de acceso, donde por ejemplo el valor 60 (sesenta) forzará a los usuarios a actualizar su clave cada 60 días y el valor 0 (cero) determinará que no se solicitará reasignar la clave en ningún momento.
En el caso de contar con servidor LDAP, el sistema podrá corroborar su clave de acceso contra el mismo.
MECANISMO DE AUDITORIA DE DATOS Y BACKUP
Mecanismo de auditoría
La auditoría de registros se hará en la base de datos a través de triggers del tipo after. El mecanismo de auditoría será realizado en paralelo de dos maneras:
El sistema debe poseer un mecanismo de validación de activación de todos los triggers de validación con cada conexión a la base de datos, evitando así problemas por desactivación intencional o involuntaria de los triggers de validación.
Almacenamiento de auditoría
Los registros de auditoría deberán ser almacenados de forma definitiva en una base de datos distinta a la base de datos del sistema en sí, esto por un lado alivianará el tamaño de la base de datos operativa y hará más fácil el backup de datos. Tanto de los datos de auditoria como los datos del sistema. Con esta estructura de base de datos permitimos que los backups de auditoria sean por el mecanismo incremental.
Políticas de Backup
El sistema tendrá un mecanismo propio de backup de base de datos y archivos fuentes. El sistema deberá tener una ventana de configuración, la ventana de configuración deberá permitir lo siguiente:
Se podrán agregar varias reglas permitiendo así en resguardo de los archivos en diferentes directorios y periodicidades distintas según el tipo de backup.
HERRAMIENTAS Y METODOS QUE DEBE CONTAR EL SISTEMA
Mecanismo de notificaciones
El sistema deberá contar con un mecanismo de notificaciones que trabaje con distintos tipos de eventos. Las notificaciones deberán aparecer al usuario dando la opción de:
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:
Mecanismo de importación de datos
Todas las tablas de base de datos que utilicen datos de gestión operativas deberán contar con la opción de importar datos directamente desde el sistema, se podrá importar adjunto un archivo o copiado y pegando la información en un textarea.
Cada tabla o sección de importación deberá indicar al usuario cual es el formato requerido para la importación de datos.
Los formatos habilitados para la importación de datos serán:
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:
Los reportes que serán enviados en una fecha distinta a la actual deberán reflejar los datos que posee el sistema al momento que se indica en la fecha de envío.
Se generará un listado de todos los envíos pendientes, el usuario que posea permiso para ver todos los envíos pendientes y cada usuario que generó el envío podrá visualizar, reconfigurar y eliminar los envíos de informes.
Se requerirá de la configuración del sistema a una cuenta de e-mail institucional de manera segura y respetando todas las políticas generales para no ser detectados como spam.
Formularios del tipo carga rápida
Todos los formularios de inserción de información al sistema deben tener la opción de carga rápida. Damos a entender por carga rápida un mecanismo por el cual:
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:
Mecanismo de selección de campos relacionados
Dentro de formularios de inserción y edición de datos poseemos ciertos datos que van vinculados con otros datos ya cargados en el sistema. Por lo tanto, en estos casos se debe seleccionar el valor al cual se hará referencia.
Para estos casos el sistema se deberá adecuar al siguiente mecanismo:
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:
El almacenamiento de los archivos deberá seguir las siguientes pautas de orden y seguridad:
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 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´s
El sistema deberá poseer de una aplicación que facilite el mecanismo para adjuntar imágenes y pdf al sistema.
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
o En el caso de requerir una imagen: Generar un archivo jpg y mostrar el archivo en la ventana donde se vincula los archivos.
o En el caso de requerir un pdf: Generar un archivo pdf y mostrar el archivo en la ventana donde se vincula los archivos.
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
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.
Infraestructura física:
GARANTIA Y SOPORTE
Garantía
El sistema debe contar con una garantía de 1 (un) año sobre las funcionalidades establecidas dentro del pliego de base y condiciones.
El plazo de garantía se dará por iniciado con la conformidad de los trabajos asignados.
Soporte
El soporte técnico será por un plazo de 1 (un) año contados a partir de la fecha de vigencia del contrato. El soporte será realizado preferente de manera remota para los casos que así lo permita. Caso contrario un técnico de la empresa se deberá presentarse en un plazo no mayor a 3 días hábiles.
Se podrá disponer hasta 2 (dos) presencias inmediatas por mes. Se entiende por presencia inmediata la condición de presentarse en el mismo día del requerimiento; y para los casos que la solicitud haya sido en horarios posterior al medio día, el proveedor podrá presentarse hasta el mediodía del día hábil siguiente.
MANUALES DE USUARIO
Manual de usuario administrador
El manual de usuarios administrador debe abarcar todas las funcionalidades requeridas para la creación de usuarios, administración de roles y configuraciones generales. 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 cuando el usuario posea asignado un rol de administración.
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.
Plazo de Entrega de Servicios.
Fase A. Primera etapa
Descripción de tareas: Instalación del sistema en el servidor e inicio de relevamiento de datos para migración.
Definición de porcentaje: 40% del monto del Ítem adjudicado.
Plazo: 30 días desde la recepción de la orden de compra por parte del proveedor.
Fase B. Segunda etapa
Descripción de tareas: Migración de datos, adecuaciones específicas de procesos, capacitaciones en el uso, generación de reportes solicitados.
Definición de porcentaje para el pago: 60% del monto del Ítem adjudicado.
Plazo: 90 días desde la recepción de la orden de compra por parte del proveedor.
Licenciada Marlene Rojas Soria, Directora de Finanzas, dependiente de la Direccion General de Administracion y Finanzas.
Con este llamado se pretende optimizar las gestiones y otras vinculadas, a fin de transparentar los procesos y así obtener los reportes al instante.
El mismo responde a una necesidad temporal.
Las especificaciones tecnicas fueron elaboradas conforme a las necesidades de la institucion, teniendo en cuenta todas las gestiones hechas por la Dinatran.
La entrega de los bienes se realizará de acuerdo al Plan de Entrega y Cronograma de Cumplimiento, indicado en el presente apartado. Así mismo, de los documentos de embarque y otros que deberá suministrar el Proveedor indicados a continuación:
SEDE CENTRAL DE LA DIRECCION NACIONAL DE TRANSPORTE - DINATRAN, sito en Ruta 2 Mcal. Estigarribia y Alberdi de la Ciudad de San Lorenzo. De Lunes a Viernes de 07:00 hs a 15:00 hs.
Fase A. Primera etapa
Descripción de tareas: Instalación del sistema en el servidor e inicio de relevamiento de datos para migración.
Definición de porcentaje: 40% del monto del Ítem adjudicado.
Plazo: 30 días desde la recepción de la orden de compra por parte del proveedor.
Fase B. Segunda etapa
Descripción de tareas: Migración de datos, adecuaciones específicas de procesos, capacitaciones en el uso, generación de reportes solicitados.
Definición de porcentaje para el pago: 60% del monto del Ítem adjudicado.
Plazo: 90 días desde la recepción de la orden de compra por parte del proveedor.
Para la presente contratación se pone a disposición los siguientes planos o diseños:
No aplica
El embalaje, la identificación y la documentación dentro y fuera de los paquetes serán como se indican a continuación:
No aplica
Las inspecciones y pruebas serán como se indica a continuación:
No aplica
El documento requerido para acreditar el cumplimiento contractual, será:
Planificación de indicadores de cumplimiento:
|
INDICADOR |
TIPO |
FECHA DE PRESENTACIÓN PREVISTA (se indica la fecha que debe presentar según el PBC) |
|
Nota de Remisión Fase A. Primera etapa |
Nota de Remisión |
30 días desde la recepción de la orden de compra |
|
Nota de Remisión Fase B. Segunda etapa |
Nota de Remisión |
90 días desde la recepción de la orden de compra |
De manera a establecer indicadores de cumplimiento, a través del sistema de seguimiento de contratos, la convocante deberá determinar el tipo de documento que acredite el efectivo cumplimiento de la ejecución del contrato, así como planificar la cantidad de indicadores que deberán ser presentados durante la ejecución. Por lo tanto, la convocante en este apartado y de acuerdo al tipo de contratación de que se trate, deberá indicar el documento a ser comunicado a través del módulo de Seguimiento de Contratos y la cantidad de los mismos.
La Convocante adjudicará el contrato al oferente cuya oferta haya sido evaluada como la más baja y cumpla sustancialmente con los requisitos de las bases y condiciones, siempre y cuando la convocante determine que el oferente está calificado para ejecutar el contrato satisfactoriamente.
1. La adjudicación en los procesos de contratación en los cuales se aplique la modalidad de contrato abierto, se efectuará por las cantidades o montos máximos solicitados en el llamado, sin que ello implique obligación de la convocante de requerir la provisión de esa cantidad o monto durante de la vigencia del contrato, obligándose sí respecto de las cantidades o montos mínimos establecidos.
2. En caso de que la convocante no haya adquirido la cantidad o monto mínimo establecido, deberá consultar al proveedor si desea ampliarlo para el siguiente ejercicio fiscal, hasta cumplir el mínimo.
3. Al momento de adjudicar el contrato, la convocante se reserva el derecho a disminuir la cantidad de bienes requeridos, por razones de disponibilidad presupuestaria u otras razones debidamente justificadas. Estas variaciones no podrán alterar los precios unitarios u otros términos y condiciones de la oferta y de los documentos de la licitación.
En aquellos llamados en los cuales se aplique la modalidad de contrato abierto, cuando la convocante deba disminuir cantidades o montos a ser adjudicados, no podrá modificar el monto o las cantidades mínimas establecidas en las bases de la contratación.
La comunicación de la adjudicación a los oferentes será como sigue:
1. Dentro de los cinco (5) días corridos de haberse resuelto la adjudicación, la convocante comunicará a través del Sistema de Información de Contrataciones Públicas, copia del informe de evaluación y del acto administrativo de adjudicación, los cuales serán puestos a disposición pública en el referido sistema. Adicionalmente el sistema generará una notificación a los oferentes por los medios remotos de comunicación electrónica pertinentes, la cual será reglamentada por la DNCP.
2. En sustitución de la notificación a través del Sistema de Información de Contrataciones Públicas, las convocantes podrán dar a conocer la adjudicación por cédula de notificación a cada uno de los oferentes, acompañados de la copia íntegra del acto administrativo y del informe de evaluación. La no entrega del informe en ocasión de la notificación, suspende el plazo para formular protestas hasta tanto la convocante haga entrega de dicha copia al oferente solicitante.
3. En caso de la convocante opte por la notificación física a los oferentes participantes, deberá realizarse únicamente con el acuse de recibo y en el mismo con expresa mención de haber recibido el informe de evaluación y la resolución de adjudicación.
4. Las cancelaciones o declaraciones desiertas deberán ser notificadas a todos los oferentes, según el procedimiento indicado precedentemente.
5. Las notificaciones realizadas en virtud al contrato, deberán ser por escrito y dirigirse a la dirección indicada en el contrato.
Una vez notificado el resultado del proceso, el oferente tendrá la facultad de solicitar una audiencia a fin de que la convocante explique los fundamentos que motivan su decisión.
La solicitud de audiencia informativa no suspenderá ni interrumpirá el plazo para la interposición de protestas.
La misma deberá ser solicitada dentro de los dos (2) días hábiles siguientes en que el oferente haya tomado conocimiento de los términos del Informe de Evaluación de Ofertas.
La convocante deberá dar respuesta a dicha solicitud dentro de los dos (2) días hábiles de haberla recibido y realizar la audiencia en un plazo que no exceda de dos (2) días hábiles siguientes a la fecha de respuesta al oferente.
Luego de la notificación de adjudicación, el proveedor deberá presentar en el plazo establecido en las reglamentaciones vigentes, los documentos indicados en el presente apartado.
|
|
|
|
|
|
|
|
2. Documentos. Consorcios |
|
|
|
|