Esta sección constituye el detalle de los bienes y/o servicios con sus respectivas especificaciones técnicas - EETT, de manera clara y precisa para que el oferente elabore su oferta. Salvo aquellas EETT de productos ya determinados por plantillas aprobadas por la DNCP.
El Suministro deberá incluir todos aquellos ítems que no hubiesen sido expresamente indicados en la presente sección, pero que pueda inferirse razonablemente que son necesarios para satisfacer el requisito de suministro indicado, por lo tanto, dichos bienes y servicios serán suministrados por el Proveedor como si hubiesen sido expresamente mencionados, salvo disposición contraria en el Contrato.
Los bienes y servicios suministrados deberán ajustarse a las especificaciones técnicas y las normas estipuladas en este apartado. En caso de que no se haga referencia a una norma aplicable, la norma será aquella que resulte equivalente o superior a las normas oficiales de la República del Paraguay. Cualquier cambio de dichos códigos o normas durante la ejecución del contrato se aplicará solamente con la aprobación de la contratante y dicho cambio se regirá de conformidad a la cláusula de adendas y convenios modificatorios.
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.
En este apartado la convocante deberá indicar los siguientes datos:
Unidad o Área requirente:
Dependencias:
Dirección de Informática y Dirección de Administración y Finanzas
Responsables y cargos:
José Ramírez, Director Interino de Informática.
Clara González, Directora de Administración y Finanzas.
Justificación de la necesidad que se pretende satisfacer mediante la contratación a ser realizada:
Desde la creación de la Dirección Nacional de Propiedad Intelectual (DINAPI) como institución de organismo autónomo y autárquico entre los años 2013/2014, los procesos administrativos financieros, referentes a contabilidad, presupuesto y tesorería se han desarrollado utilizando herramientas de ofimática básicas, principalmente planillas de formato tipo Excel.
Esta situación ha generado una alta dependencia del trabajo manual, con limitadas capacidades de control y trazabilidad, lo que constituye una restricción significativa para alcanzar niveles óptimos de eficiencia institucional.
Actualmente, la ausencia de un sistema integral de gestión tecnológica en las áreas administrativas y de soporte trae consigo las siguientes limitaciones:
Altos riesgos operativos: La dependencia del trabajo manual incrementa la probabilidad de errores humanos en el registro y procesamiento de datos.
Baja trazabilidad: Las planillas ofimáticas dificultan el seguimiento histórico de la información y la generación de reportes confiables y de forma rápida.
Falta de integración: Los procesos de administración, referentes a contabilidad, presupuesto y tesorería funcionan de manera aislada, sin interoperabilidad ni comunicación entre áreas.
Retrasos en la gestión: La ausencia de automatización ralentiza la tramitación de expedientes, contrataciones y registros financieros.
Débil control interno: No se cuenta con mecanismos automatizados de validación, auditoría y seguridad de la información.
Estos factores impactan directamente en la eficiencia, transparencia y capacidad de respuesta institucional.
Resulta imprescindible la adquisición e implementación de un software de gestión administrativa y financiera, que permita la automatización, integración y estandarización de procesos claves de la institución, contribuyendo a mejorar el control interno, la seguridad de la información y la eficiencia operativa.
La implementación del software propuesto aportará los siguientes beneficios:
Automatización de procesos administrativos y financieros, minimizando riesgos de error y aumentando la seguridad de la información.
Mayor transparencia en contrataciones y llamados, gracias a la estandarización de procedimientos y generación de reportes auditables.
Aumento de la productividad institucional, mediante la reducción de tiempos de respuesta y la mejora en la organización de la información.
Interoperabilidad con otras plataformas gubernamentales, en concordancia con los lineamientos del MITIC y la estrategia nacional de gobierno digital. La integración con el SIARE es requisito ineludible y un pilar estratégico para la correcta operación y validación de cualquier sistema de gestión administrativa en el ámbito público de Paraguay.
La adquisición de esta solución tecnológica se encuentra alineada en la Transformación Digital de la DINAPI, que busca fortalecer la gestión institucional y consolidar a la institución como referente en innovación tecnológica. Las iniciativas nacionales de modernización impulsadas por el MITIC, orientadas a la integración y digitalización de procesos públicos. El trabajo conjunto con organismos internacionales, como la OMPI, que ya ha provisto soluciones tecnológicas en otras áreas de la institución, lo que evidencia el compromiso institucional con la digitalización y su disposición a adoptar herramientas que favorezcan la interoperabilidad, la eficiencia y la transparencia en los procesos de gestión pública.
En virtud de lo expuesto, se considera técnica y estratégicamente justificada la adquisición de un software de gestión administrativa y financiera para la DINAPI, dado que su implementación permitirá superar las limitaciones actuales, optimizar procesos, fortalecer la transparencia institucional y contribuir a la modernización del Estado paraguayo.
Justificación de la planificación:
Corresponde a un llamado temporal.
Justificación de las especificaciones técnicas establecidas:
Se concluye que las especificaciones técnicas y las condiciones particulares, se encuentran estipuladas con criterios suficientemente claros, objetivos e imparciales y son en base a los requisitos técnicamente indispensables, en cumplimiento del Decreto N° 2264/2024 reglamentario de la Ley 7021/2022 De Suministro y Contrataciones Públicas.
Los productos y/o servicios a ser requeridos cuentan con las siguientes especificaciones técnicas:
El propósito de la Especificaciones Técnicas (EETT), es el de definir las características técnicas de los bienes que la convocante requiere. La convocante preparará las EETT detalladas teniendo en cuenta que:
- Las EETT sirven de referencia para verificar el cumplimiento técnico de las ofertas y posteriormente evaluarlas. Por lo tanto, unas EETT bien definidas facilitarán a los oferentes la preparación de ofertas que se ajusten a los documentos de licitación, y a la convocante el examen, evaluación y comparación de las ofertas.
- En las EETT se deberá estipular que todos los bienes o materiales que se incorporen en los bienes deberán ser nuevos, sin uso y del modelo más reciente o actual, y que contendrán todos los perfeccionamientos recientes en materia de diseño y materiales, a menos que en el contrato se disponga otra cosa.
- En las EETT se utilizarán las mejores prácticas. Ejemplos de especificaciones de adquisiciones similares satisfactorias en el mismo sector podrán proporcionar bases concretas para redactar las EETT.
- Las EETT deberán ser lo suficientemente amplias para evitar restricciones relativas a manufactura, materiales, y equipo generalmente utilizados en la fabricación de bienes similares.
- Las normas de calidad del equipo, materiales y manufactura especificadas en los Documentos de Licitación no deberán ser restrictivas. Se deberán evitar referencias a marcas, números de catálogos u otros detalles que limiten los materiales o artículos a un fabricante en particular. Cuando sean inevitables dichas descripciones, siempre deberá estar seguida de expresiones tales como “o sustancialmente equivalente” u “o por lo menos equivalente”, remitiendo la aclaración respectiva. Cuando en las ET se haga referencia a otras normas o códigos de práctica particulares, éstos solo serán aceptables si a continuación de los mismos se agrega un enunciado indicando otras normas emitidas por autoridades reconocidas que aseguren que la calidad sea por lo menos sustancialmente igual.
- Asimismo, respecto de los tipos conocidos de materiales, artefactos o equipos, cuando únicamente puedan ser caracterizados total o parcialmente mediante nomenclatura, simbología, signos distintivos no universales o marcas, únicamente se hará a manera de referencia, procurando que la alusión se adecue a estándares internacionales comúnmente aceptados.
- Las EETT deberán describir detalladamente los siguientes requisitos con respecto a por lo menos lo siguiente:
(a) Normas de calidad de los materiales y manufactura para la producción y fabricación de los bienes.
(b) Lista detallada de las pruebas requeridas (tipo y número).
(c) Otro trabajo adicional y/o servicios requeridos para lograr la entrega o el cumplimiento total.
(d) Actividades detalladas que deberá cumplir el proveedor, y consiguiente participación de la convocante.
(e) Lista detallada de avales de funcionamiento cubiertas por la garantía, y las especificaciones de las multas aplicables en caso de que dichos avales no se cumplan.
- Las EETT deberán especificar todas las características y requisitos técnicos esenciales y de funcionamiento, incluyendo los valores máximos o mínimos aceptables o garantizados, según corresponda. Cuando sea necesario, la convocante deberá incluir un formulario específico adicional de oferta (como un Anexo a la de Oferta), donde el oferente proporcionará la información detallada de dichas características técnicas o de funcionamiento con relación a los valores aceptables o garantizados.
Cuando la convocante requiera que el oferente proporcione en su oferta datos sobre una parte de o todas las Especificaciones Técnicas, cronogramas técnicos, u otra información técnica, la convocante deberá detallar la información requerida y la forma en que deberá ser presentada por el oferente en su oferta.
Si se debe proporcionar un resumen de las EETT, la convocante deberá insertar la información en la tabla siguiente. El oferente preparará un cuadro similar para documentar el cumplimiento con los requerimientos.
Los bienes y/o servicios deberán cumplir con las siguientes especificaciones técnicas y normas:
ESPECIFICACIONES TÉCNICAS
SISTEMA DE GESTIÓN Y ADMINISTRACIÓN DE RECURSOS DEL ESTADO.
INTRODUCCIÓN
La Dirección Nacional de Propiedad Intelectual (DINAPI) requiere la adquisición de un Sistema Integrado de Gestión de que integra los módulos de Presupuesto, Contabilidad y Tesorería, incluyendo: la provisión y adaptación del Sistema, el desarrollo de las funciones explicitadas en este documento y la capacitación de los recursos humanos.
OBJETIVO GENERAL
El objetivo es adquirir un Software de Gestión Institucional que permita estandarizar los procesos de las áreas Financiera, Presupuesto y Contabilidad, garantizando eficiencia, seguridad y escalabilidad.
OBJETIVOS ESPECÍFICOS
DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS.
A continuación, se presentan definiciones, acrónimos y abreviaturas que facilitarán la comprensión de los términos utilizados en las especificaciones técnicas del presente pliego.
MARCO LEGAL.
Entre las principales normativas que dan vigencia al Sistema de Información de Contrataciones Públicas se citan:
BENEFICIARIOS
La digitalización de los procesos administrativos contribuirá con un mejor desarrollo de los trabajos no solo a los funcionarios de las áreas involucradas en el uso del software, sino que impactará directamente en el mejor desempeño de la Institución, e indirectamente en todos los actores del sistema de compras públicas.
La cantidad aproximada de usuarios del sistema es de diez funcionarios.
INFRAESTRUCTURA PARA EL SOFTWARE
Tecnologías
La DINAPI cuenta con centros de datos a cargo de la Dirección de Informática, en los cuales las aplicaciones serán alojadas.
Para aprovechar la infraestructura actual, las licencias y suscripciones de soporte con las que cuenta actualmente, se debe considerar que las aplicaciones deberán:
Se requiere licencia de uso perpetua sin límite de cantidad de usuarios y el código fuente del software objeto de esta contratación a favor de la entidad.
Los códigos fuentes serán alojados en el servidor de Versionado de Código de la entidad.
Cumplir los lineamientos de ciberseguridad exigidos por el ente regulador nacional MITIC/CERT-PY hasta la fecha el fin del convenio de garantía.
ALCANCE DEL PROYECTO:
La DINAPI requiere la adquisición de un Software especializado, previamente desarrollado e implementado en otras instituciones o empresas, en este caso un Software de Gestión de Procesos Administrativos, que, no obstante, requiere de forma adicional a las funcionalidades de origen trabajos de adaptación y configuración por parte del oferente, para un uso específico y posterior implementación dentro de la Institución.
El Oferente deberá detallar en su oferta los requerimientos mínimos a nivel de infraestructura de hardware que el software exige para su funcionamiento óptimo.
RESULTADOS ESPERADOS
DETALLE DE LOS PROCESOS DEL SISTEMA REQUERIDO
En el presente documento se describen 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.
Conforme el Decreto N° 3248/2025 que reglamenta la Ley 7408/2024 que aprueba la Ley de Presupuesto para el 2025, establece lo siguiente en su artículo 396: Para los procedimientos de contratación correspondientes a la adquisición de Sistemas Informáticos de Planeamiento de Recursos de Gobierno (GRP) o sus componentes de gestión financiera interna y similares, deberá incluirse como requisito en el PBC que el sistema a ser adquirido permitirá la interfaz para su conexión física con el Sistema Integrado de Administración de los Recursos del Estado (SIARE) y que no interferirá con el uso y finalidad del sistema integrado establecido para la administración financiera del Estado. Se requiere que la empresa adjudicada desarrolle la interfaz requerida.
El sistema deberá tener la capacidad de interoperabilidad con los sistemas existentes en la DINAPI a través de APIs (Interfaces de Programación de Aplicaciones).
Listado de sistemas que forman parte del presente documento de especificaciones de procesos:
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:
- Registro de datos de CDPs.
- Reservas por reprogramaciones
- Otras reservas de carácter interno.
- Control de reprogramaciones en curso, aprobación y aplicación de cambios.
- Migración de saldos mensuales
- Carga de compromisos directos, por órdenes, facturas u otros documentos que respalden un gasto.
- Registración de metas.
- Registración de la ejecución de metas.
- Generación de reportes relacionados a las metas.
- Validaciones en formulario de carga de compromisos.
- Formulario de carga de cumplimiento de metas independientes a compromisos.
Así mismo genera todos los reportes y documentos necesarios como ser:
- Ejecución mensual del plan financiero.
- Listado de reprogramaciones.
- Listado de gasto con filtros por estructura, rubro, fecha etc.
- Formatos de notas y/o comprobantes por cada proceso.
El sistema cuenta con una herramienta de control mensual de equidad entre la ejecución reflejada en el sistema contra la información almacenada en el SIAF.
Todas las secciones del sistema contemplan la posibilidad de adjuntar archivos digitalizados de los documentos oficiales de cada uno de los procesos.
El sistema genera reportes gráficos y listados con resúmenes que se reflejan en un panel principal, dando al usuario un panorama general de la ejecución del plan financiero.
INFORMACIONES REQUERIDAS EN LA PANTALLA INICIAL
- Acceso a secciones más utilizadas del sistema. Ej.: Plan financiero, Reservas y CDPs, Compromisos, Reprogramaciones y Migraciones.
- Acceso a la vista del plan financiero en modo desplegable.
- Gráfico de área de evolución mensual de reservas y compromisos: Comportamiento de la ejecución del plan financiero con cortes mensuales
- Gráfico de barras de ejecución por rubro de objeto del gasto: Se debe mostrar en columnas distintas por cada rubro de objeto del gasto su valor total, reservado (reservas + compromisos directos), comprometido.
- Gráfico de torta para distribución del plan financiero por rubro: Muestra la distribución del plan financiero vigente por rubro.
- Listado con acceso directo a últimas reservas y/o compromisos realizados: El mismo servirá para acceder de manera fácil a visualizar/editar datos recientes.
- Porcentaje de reservas realizadas con el plan financiero.
- Porcentaje de compromisos realizados con el plan financiero.
- Porcentaje de ejecución del nivel 100.
- Porcentaje de ejecución de los niveles 200 al 900.
- Acceso a visualizar y configurar la presentación en modo transición.
Presentación en modo transición
La presentación en modo transición consiste en la generación de un mecanismo donde se puedan seleccionar uno o varios datos/gráficos que figuran en el panel principal y estos puedan ser expuestos de manera dinámica en el monitor del usuario. Estará enfocado principalmente para ser visualizado en pantallas de gran tamaño (32 pulgadas superiores) dispuestos en puntos claves para demostrar el proceso de 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
Información requerida: 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.
Información requerida: 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.
Información requerida: 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
Información requerida: 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
Información requerida: Periodo, Tipo de presupuesto, Programa, Subprograma, 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, Subprograma, 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 datos 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.
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 de 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 tenga 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
Información requerida: 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 tenga 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, Subprograma, 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 específica 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.
Información requerida: Estructura (Periodo, Tipo de presupuesto, Programa, Subprograma, 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).
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
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 CDPs 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 menores 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:
- Ejecución de CDPs: Ejecución de un CDP específico mostrando solo los totales de los compromisos realizados
- Ejecución detallada de CDPs: Ejecución detallada de los compromisos de un CDP específico.
- Reservas por línea presupuestaria: Listado de reservas realizadas en una línea presupuestaria especificada.
Observación: Todos los reportes deberán poder ser filtrados por tipo y rango de fecha.
Compromisos
Informaciones requeridas:
Funcionalidad/es:
- Se llevará el control de todos los gastos realizados contra el plan financiero.
- Los datos cargados en la cabecera serán utilizados como un filtro para determinar que todos los registros del detalle llevarán la misma información, por lo tanto, en la cabecera solo son datos obligatorios Nro., Periodo, Fecha, Número de Expediente, Valor total, Estado. De tal manera los datos que no son especificados en la cabecera podrán ser variables en el detalle.
Validación/es:
- La imputación de los gastos se hará únicamente contra estructuras afectadas que cuenten con saldo en el plan financiero.
- Todas las imputaciones se deberán realizar a un objeto de gasto a la unidad, se deberá verificar que su correspondencia en la decena posea saldo suficiente para poder realizar la imputación.
Documento/s emitido/s: Emite comprobante de compromiso realizado indicando la línea presupuestaria afectada.
Reporte/s: Se podrá generar listados de los gastos filtrando por todos los campos del detalle del compromiso.
Reprogramaciones y migraciones
Informaciones requeridas:
Funcionalidad/es: Llevar el control de los procesos de reprogramación del plan financiero, así como automatizar la modificación en el proceso de migración de saldos del plan financiero mensual.
Validación/es:
- Solamente las reprogramaciones del tipo OFICIAL podrán ser AUMENTO o DISMINUCIÓN, las demás únicamente MIGRACIÓN.
- Los valores a disminuir afectarán al saldo actual del plan financiero, inclusive si la reprogramación no se encontrase aprobada.
- Los valores a aumentar solo afectarán al plan financiero una vez que la reprogramación sea aprobada.
- Las reprogramaciones del tipo INTERNO reciben aprobación de manera automática.
- Los montos a disminuir deberán ser validados contra los compromisos y/o reservas realizados en la línea correspondiente.
Alertas y Notificaciones: El sistema deberá alertar sobre la existencia de 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 cargados 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
Los ítems se deberán desplegar teniendo en cuenta el siguiente orden:
Entidad > Tipo de presupuesto > Programa > Subprograma > Proyecto > Distribución > Sub-Distribución > Objeto del gasto > Fuente de financiamiento/Organismo financiador/Departamento > CDPs o Reservas > Compromisos
Otros materiales y accesos útiles
- Acceso directo al sistema al SIPP.
- Acceso directo al clasificador presupuestario vigente. Acceso al archivo PDF. Búsqueda de objeto de gasto por descripción.
DESCRIPCIÓN GENERAL
El sistema de Tesorería se encarga de llevar el control de la ejecución del plan financiero asignado a la entidad.
El sistema debe contemplar todas las exigencias a nivel de proceso que se requieren para llevar este control. Además debe ser capaz de integrarse con otros sistemas.
El módulo de tesorería debe conectarse por medio de APIs con el Sistema de Caja de la institución.
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:
- Actualizaciones de base de datos y resguardo de datos
- Herramientas generales para el manejo de datos
Sección de pagos pendientes
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 número 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 configurada por grupo de objeto del gasto.
ESPECIFICACIONES DE LA PLATAFORMA DEL SISTEMA
El sistema deberá estar desarrollado acorde a las últimas tendencias de desarrollo de software para ambiente web. Debe utilizar lenguajes y plataformas que posean una gran cantidad de soporte en línea. La base de datos a ser utilizada 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 auditoría puede ser incremental y el backup de datos una copia o en espejo.
El sistema deberá adecuarse 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 deberá 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 MÉTODOS DE PROGRAMACIÓN
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.
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.
El sistema utiliza una base de datos del tipo Open Source, la base de datos seleccionada posee las siguientes características:
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.
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).
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.
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.
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 ú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 auditoría de datos.
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 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.
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 aliviará el tamaño de la base de datos operativa y hará más fácil el backup de datos. Tanto de los datos de auditoría como los datos del sistema. Con esta estructura de base de datos permitimos que los backups de auditoría sean por el mecanismo incremental.
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í el resguardo de los archivos en diferentes directorios y periodicidades distintas según el tipo de backup.
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.
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.
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:
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 cuál es el formato requerido para la importación de datos.
Los formatos habilitados para la importación de datos serán:
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.
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.
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:
La presentación de los listados de datos de secciones deberá tener en cuenta los siguientes puntos:
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:
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:
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.
Sistema de aplicación de firma digital con la utilización de TOKEN y Firma no cualificada del servidor público: El sistema deberá contar con un sistema para la utilización de firma digital. Permitiendo a los usuarios firmar documentos en pdf generados en el sistema, estos documentos se deberán guardar en el servidor con la posibilidad de descarga. Cada uno de estos documentos podrá poseer una o varias firmas digitales. Todas estas firmas deberán ser realizadas por el usuario sin la necesidad de descargar el archivo para firmarlo en Acrobat Reader u otro software similar, el proceso de la firma se deberá realizar principalmente para el usuario dentro del ambiente web del sistema. Deberá existir una sección especial del sistema donde se encuentre el listado de todos los pdfs que fueron firmados a través del sistema. Este listado deberá emitir informes y deberá poder ser filtrados según parámetros como: rango de fecha, firmantes, tipo de documentos etc.
Sistema de impresión directa desde el sistema en impresoras conectadas al equipo de usuario
Consiste en un mecanismo donde el usuario pueda configurar dentro del entorno web del sistema en que impresora conectada a su equipo desea imprimir que reporte. El objetivo final del mismo es facilitar el proceso de impresión directa con teclas como P o combinaciones de teclas. 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.
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.
Aplicación para upload directo de fotos y pdfs
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
El sistema deberá poseer 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
ENTREGABLES:
A todo software se le atribuyen unas características y prestaciones determinadas en función del tipo de software de que se trate; así como de aquellas características especiales que se hayan incluido en el contrato. Además, se entiende que el software estará siempre listo para funcionar correctamente según los requerimientos funcionales y no funcionales especificados por el OEE, cuando el usuario decida ejecutarlo correctamente. De lo contrario, estaremos ante una incidencia debido a un fallo de funcionamiento o bien el software presentará un defecto.
El funcionamiento adecuado del software en las condiciones en que se encuentre al momento de su recepción final, con todos los requerimientos funcionales y no funcionales especificados por el OEE, deberá estar garantizado por el oferente adjudicado por un periodo mínimo de 8 años a partir de la terminación del contrato, periodo en el que deberá responder respecto de todo vicio oculto, falla o defecto que afecte a su funcionamiento, siempre y cuando éstos vicios ocultos, fallas o defectos tengan origen en el código fuente y/o código objeto del software. El software deberá funcionar en las mismas condiciones y con las mismas funcionalidades alcanzadas al momento de su recepción final, con hardware de características equivalentes o conforme lo establezcan las especificaciones técnicas, de forma perpetua; debiendo el oferente adjudicado responder por un periodo mínimo mencionado en los términos señalados.
En particular, la garantía de buen funcionamiento en virtud de la cual el proveedor debe asegurar al OEE y a los usuarios que esta designe, que el software funcionará correctamente durante el plazo de vigencia del contrato, al menos, durante un tiempo determinado, de modo que en caso de que el software presente algún fallo, prestará la asistencia oportuna al usuario para remediarlo.
En el caso de consorcios, el oferente debe indicar cuál será la empresa encargada de la sección Garantía. En caso de no especificar se atribuye a la empresa líder del consorcio.
Obligación de defensa, indemnización y continuidad. El Desarrollador asume la responsabilidad total para el caso en que alguna o todas las Creaciones infrinjan derechos de propiedad intelectual o derechos de propiedad industrial o cualquier otro derecho de terceros, y se obliga a indemnizar al Cliente y sus empleados íntegramente respecto de cualquier reclamo, demanda, querella o acción de cualquier clase que se genere por dicho concepto, incluyendo montos por indemnización, por suspensión de operaciones y gastos generados por concepto de reclamos o demandas que pudieren interponerse en contra del Cliente.
En virtud de lo anterior, el Desarrollador defenderá, a su cargo y costo, cualquier acción entablada en contra del Cliente y/o alguno de sus empleados que argumente que alguna o todas las Creaciones infringe algún derecho de propiedad intelectual, propiedad industrial o cualquier otra clase de propiedad o derechos, si el Cliente notifica por escrito al Desarrollador de cualquier reclamo, demanda, querella o acción de cualquier clase recibida, dentro de los 5 días hábiles de ocurrido. Si el Cliente elige defender cualquier acción entablada o no notifica al Desarrollador dentro del plazo señalado, el Desarrollador quedará libre de pagar los costos del juicio, pero no de indemnizar al Cliente, si el fallo declarase la infracción de cualquiera propiedad intelectual, propiedad industrial o cualquier otra clase de propiedad o derechos sobre todas o alguna de las Creaciones.
El Desarrollador deberá pagar los montos que sean necesarios para transigir los mencionados reclamos, demandas, querellas o acciones.
Durante el tiempo que dure algún conflicto sucedido de acuerdo a esta sección, si el Cliente fuere privada de utilizar una o más de las Creaciones, el Desarrollador deberá proveer con alternativas efectivas al Cliente para seguir operando, y todas estas alternativas deberán ser costeadas por el Desarrollador.
El soporte técnico será por un plazo de 2 (dos) años contados a partir de la fecha de vigencia del contrato. El soporte será realizado preferentemente de manera remota para los casos que así lo permita. Caso contrario un técnico de la empresa deberá presentarse en un plazo no mayor a 3 días hábiles.
Se podrá disponer hasta 2 (dos) presencias inmediatas por mes. Se entiende por presencia inmediata la condición de presentarse en el mismo día del requerimiento; y para los casos que la solicitud haya sido en horarios posterior al medio día, el proveedor podrá presentarse hasta el mediodía del día hábil siguiente.
MANUALES Y TUTORIALES
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.
Indicadores de Cumplimiento de Contrato
Los documentos requeridos para acreditar el cumplimiento contractual serán:
Observación: para la migración de datos en las diferentes fases, los plazos de entrega podrán ampliarse cuando la contratante no cumpla con la entrega de los mismos, así como cuando el personal designado para la implementación de los módulos no disponga de tiempo para seguir con los avances de implementación. Dicha información quedará redactada en constancias de tareas realizadas por técnicos designados por el proveedor adjudicado.
La institución contratante se compromete a emitir una resolución en la cual el sistema informático será de uso obligatorio para los procesos de gestión interna en las áreas de cada módulo implementado.
Los administradores del contrato designados son:
Posterior a la recepción definitiva de cada módulo del sistema, se procederá al periodo de garantía del producto, donde se podrán seguir solicitando actualizaciones a funcionalidades contempladas dentro del PBC durante el periodo de garantía.
Conforme lo dispuesto en las EETT.
FASE A
FASE B
FASE C
Restricciones específicas
Sistemas Informáticos de Planeamiento de Recursos de Gobierno
El artículo 2 de la Ley N° 1535/99 De administración Financiera del Estado indica lo siguiente: establécese el Sistema Integrado de Administración Financiera - en adelante denominado SIAF, que será obligatorio para todos los organismos y entidades del Estado, en el mismo artículo, se indica que:
El SIAF estará conformado por sistemas de:
Por su parte, el Decreto N° 3248/2025 que reglamenta la Ley 7408/2024 que aprueba la Ley de Presupuesto para el 2025, establece lo siguiente en su artículo 396:
En procedimientos de Menor Cuantía, la aplicación de la preferencia reservada a las MIPYMES prevista en el artículo 34 inc b) de la Ley N° 7021/22 ‘’De Suministro y Contrataciones Públicas" será de conformidad con las disposiciones que se emitan para el efecto. Son consideradas Mipymes las unidades económicas que, según la dimensión en que organicen el trabajo y el capital, se encuentren dentro de las categorías establecidas en el Artículo 4° de la Ley N° 7444/25 QUE MODIFICA LA LEY Nº 4457/2012 ‘’PARA LAS MICRO, PEQUEÑAS Y MEDIANAS EMPRESAS’’, y se ocupen del trabajo artesanal, industrial, agroindustrial, agropecuario, forestal, comercial o de servicio.
La entrega de los bienes se realizará de acuerdo al plan de entrega, indicado en el presente apartado. El proveedor se encuentra facultado a documentarse sobre cada entrega. Así mismo, de los documentos de embarque y otros que deberá suministrar el proveedor indicado a continuación:
|
Ítem |
Descripción del bien/servicio |
Cantidad |
Unidad de medida |
Lugar |
Plazo de entrega
|
|
1 |
Sistema de gestión para las oficinas administrativas |
1 (uno) |
Unidad |
Dirección de Informática DINAPI, sito en España N.° 323 c/ Estados Unidos, Asunción. |
Dentro de los 60 (sesenta) días, contados a partir de la recepción por parte del proveedor de la orden de compra/servicio. |
La prestación de los servicios se realizará de acuerdo al plan de prestación, indicados en el presente apartado. El proveedor se encuentra facultado a documentarse sobre cada prestación.
Conforme lo dispuesto en las EETT.
FASE A
FASE B
FASE C
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