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.

Resumen de las Especificaciones Técnicas. Los bienes deberán cumplir con las siguientes Especificaciones Técnicas y Normas:

Detalle de las Especificaciones Técnicas y de las Normas

SISTEMA DE GESTIÓN DE COMPRAS

La Institución tiene como objetivo adquirir un software para gestionar las Compras institucionales que incluyen diversos procesos, desde el planeamiento del abastecimiento, es decir ayudar a identificar las necesidades de bienes y servicios, el seguimiento de los procesos y plazos, la recepción del bien o servicio y el posterior pago por dichos bienes o servicios.

1. Objetivos
   1. Minimizar los trabajos realizados en islas independientes entre los distintos departamentos involucrados en la gestión de las necesidades de bienes y servicios, y permitir trabajar sobre un único sistema y una única fuente de datos.
   2. Reducir la carga manual de datos en varios sistemas, formularios, procesos manuales, orientado a un proceso de una sola carga de datos para todo el circuito de contrataciones.
   3. Permitir monitorear el estado de todos los procesos de las contrataciones y su estado, en una matriz unificada con alertas visuales.
   4. Ayudar a complementar todas las normativas legales, y reglamentaciones institucionales que afectan a los procesos de contratación.
   5. Reducir los errores derivados de procesos manuales excesivos durante los procesos de definición, captura o procesamiento de las contrataciones institucionales.
   6. Características Técnicas
      1. Ambiente Web. El sistema deberá ser del tipo Web Enabled, permitiendo escalabilidad y fácil despliegue de la aplicación. La aplicación deberá generar respuestas HTML/HTML5 puras y no requerirá la instalación de aplicaciones adicionales para el funcionamiento como plugins tipo ActiveX o Applet de Java.
      2. Ambiente web, compatibilidad, clientes. Mozilla Firefox en su última versión o superior, Google Chrome en su última versión o superior, Internet Explorer en su última versión o superior y Safari en su última versión o superior.
      3. La visualización de reportes deberá realizarse en el navegador sin necesidad de descarga de ficheros PDF o similares, para tal efecto deberá implementarse un servidor de reportes. La aplicación deberá operar en forma integrada con el servidor de reportes.
      4. El sistema deberá poder conectarse a servidores Active Directory de Microsoft para la validación y acceso de usuarios.
      5. Base de datos relacional en su versión Microsoft SQL Server 2014 o superior.
      6. El software deberá abarcar aplicaciones para dispositivos móviles en IOS y Android. Especificamente para consultas y poder realizar ciertas operaciones básicas, lo cual se solicita como complemento. (enunciativo y no excluyente)
      7. El adjudicado debe proveer un manual de usuario en formato PDF.
      8. Escalabilidad y estabilidad
      9. Los despliegues de aplicaciones, deberán permitir ser escalables, proveyendo para ello una aplicación que permita desplegar múltiples instancias de la misma aplicación, para sectorizar a la instalación, por ejemplo Una instancia para los usuarios del departamento de Seguimiento de Contratos, otra instancia para los usuarios del área de UOC, de manera tal que en caso que sea necesario realizar cambios en un departamento y se requiera apagar momentáneamente el sistema, no afecte a la totalidad sino solo al área afectada. (enunciativo y no excluyente)
      10. Estas aplicaciones deberán permitir interconectarse entre instancias para formar nodos y gestionar automáticamente las sesiones, instanciando nodos a medida que sean requeridas más sesiones, y purgando a las sesiones que ya no sean utilizados. (enunciativo y no excluyente)
      11. Despliegue remoto. Esta característica deberá permitir subir los nuevos ejecutables mediante una interfaz gráfica, y a medida que se purguen las sesiones, reemplazar por las nuevas versiones. (enunciativo y no excluyente)
      12. Consideraciones generales:
          1. Licencia de uso a nombre de la AFD perpetua para usuarios ilimitados.
          2. El Oferente deberá entregar adjunto a la propuesta el listado de actividades a realizar y los requerimientos de información para realizar la parametrización de la solución ofertada, como así también los plazos para su implementación. EXIGIDO
          3. Deberá entregar cuando le sea solicitado un informe de los avances de la implementación al Encargado de Servicios Administrativos y al Encargado de Tecnología de la Información de la AFD.
          4. El Oferente deberá contar con un Líder de Proyecto que se encargará de realizar el seguimiento de las actividades del proyecto.
          5. El listado de requerimientos en el desarrollo realizado en cada uno de los módulos es enunciativo, pudiendo, en el desarrollo de estos incorporarse ítems que representen y generen mejoras en la funcionalidad de cada uno de ellos, en su conjunto e integrado a otros procesos de la estructura organizativa.
          6. Aspectos relacionados a la seguridad informática:
             1. En la codificación del software se debe utilizar estándares de buenas prácticas seguras de programación, la cual debe ser seleccionada e implementada de acuerdo con el lenguaje de programación y el entorno de desarrollo utilizado. El software deberá estar desarrollado de manera segura contemplando las recomendaciones del OWASP TOP 10 -2017.
             2. El sistema deberá tener las siguientes características:
                1. El sistema deberá permitir habilitar por cada rol o perfil de usuario permisos de lectura, modificación, grabación. Contar con esquemas de seguridad y accesos (creación de usuarios, roles, perfiles) e Integración con el Directorio Activo
                2. El sistema deberá poseer pistas de auditorías de las acciones críticas realizadas por los usuarios (edición de datos sensibles, eliminación de datos, logs de eventos; datos mínimos a ser registrados, fecha, hora, dirección IP, login, valor anterior, valor actual, nombre de la tabla) Así también log de los inicios/finalización de sesión de los usuarios (exitosos y fallidos), logs de las modificaciones de parámetros en el sistema, modificación de cuentas de usuarios, y perfiles.
                3. El software debe permitir la revocación de acceso de usuarios, mediante un estado desactivado o similar, así también deberá tener la opción de carga de fecha de expiración para las cuentas de usuarios.
                4. El software debe contemplar la expiración de sesiones de acuerdo con parámetros pueden ser fijos o configurables por la institución.
                5. El sistema deberá administrar el acceso a los reportes a través de roles o perfiles de acceso.
                6. Deberá permitir generar reportes de los logs de auditoría, listado de usuarios, listado de perfiles de usuarios y sus accesos en los sistemas en formato PDF, Excel, csv
                7. La comunicación y transmisión de datos entre el cliente (navegador web) y el sistema se realice mediante el protocolo seguro de transferencia HTTPS.
                8. Las contraseñas no deben almacenarse en texto claro, sino mediante la aplicación de funciones hash o funciones resumen.
                9. El Oferente deberá entregar a la AFD un informe técnico de las configuraciones realizadas una vez culminada la implementación.
                10. Capacitación: Los aspectos de capacitación resultan críticos para el éxito del software. El esfuerzo de capacitación requerido cubre dos facetas: la instrucción de los usuarios finales y la preparación técnica del personal que deberá sostener la operatividad del sistema, para lo cual presentará un Plan de Capacitación y estimará la cantidad de horas y recursos requeridos para la instrucción.

2. Funcionalidades:
   1. Fichero de catálogo de productos o servicios. Cuando un funcionario requiere un producto o servicio puede seleccionarlo directamente del catálogo que dispone, estos normalmente son commodities, ampliamente disponibles, como materiales de oficina, insumos varios, etc. También el usuario podrá definir productos que aún no estén disponibles en el catálogo, o productos que dispongan de complejidad en las especificaciones técnicas.
   2. Presupuestos, datos financieros, y objetos de gastos. Todas las compras institucionales deben tener definido un presupuesto, un monto referencial para la adquisición, y un objeto de gasto donde será imputado, y una fuente de financiamiento. Estos parámetros están definidos anualmente en el Presupuesto General de Gastos de la Nación.
   3. Participantes. Usuarios que han de participar en algún flujo de trabajo relacionado con el proceso de compras.
   4. El sistema deberá permitir la gestión del proceso de compras desde el inicio, hasta el proceso final.
   5. Para ayudar a comprender estos procesos a continuación se detalla en gráficos.
      1. En los ficheros que contengan grillas con datos, deberá agregarse un encabezado que contenga un filtro que, dependiendo de los valores de los campos, sean del tipo texto, numérico, lista de valores, fechas, actuará como un filtro de una hoja de cálculo. Este comportamiento deberá permitir al usuario un proceso rápido al estar familiarizado con las hojas de cálculo.
      2. Indicaciones visuales en las grillas, con colores como alerta en la línea. (ejemplo rojo u otros colores para otras alertas).
   6. El proceso de gestión de Compras de la institución se compone de dos etapas principales: la primera destinada a la preparación y proyección de esta, y la siguiente propiamente la ejecución de este.
   7. La etapa de proyecto y preparación se compone de las siguientes tareas.
      1. Los departamentos de las diferentes gerencias preparan sus requerimientos y necesidades de compras.
      2. Para capturar estas necesidades deberán disponer de una herramienta para completar y cargar los requerimientos,
      3. La lista de requerimientos deberá ser anual, es decir renovarse anualmente, y podrá ser utilizado los ficheros de catálogos predefinidos.
      4. Deberá disponer de datos y campos específicos por ejemplo para cargar Especificaciones técnicas.
      5. Cantidad y precios referenciales. Deberá disponer de campos para cargar el archivo de las cotizaciones remitidas por los potenciales proveedores que respaldan los precios referenciales utilizados.
      6. Justificaciones excepcionales.
   8. La información generada deberá permitir alertas de datos completados.
      1. Por ejemplo, se pudo haber iniciado cargando las especificaciones, pero faltan precios referenciales y/o archivos que respaldan los mismos, las alertas deberán permitir a la UOC listar aquellos requerimientos de compras incompletos para su seguimiento.
      2. A su vez a los usuarios deberá mostrar las alertas para completar los requerimientos de compras.
   9. En una fecha determinada, la UOC podrá iniciar el proceso de Cierre y consolidación, emitiendo una alerta de vencimiento, por ejemplo 10 días, para que todos los pedidos de compras sean completados y cerrados para ser utilizados como Anteproyecto.
   10. La información consolidada es enviada al área financiera para sus previsiones, por tanto, deberá generar informes consolidados. Estos informes como mínimo deberán tener filtros para poder seleccionar:
       1. Por área / gerencia / departamento
       2. Por periodo especifico
       3. Deberá disponer de una planilla detallada y también de un resumen final, es decir un reporte extendido que detalle todas las necesidades, especificaciones técnicas, objetivos, precios referenciales, y al final un reporte que solamente indique el título y los montos asignados, con una sumatoria final.
   11. Todas las compras institucionales se realizan atendiendo la Ley 2051, por ende, deberá completar los campos de datos definidos en esta ley, por ejemplo,
       1. Antes / Durante el proceso: Nombre de la Licitación / Tipo de Licitación / Tipo de procedimiento / Categoría / Etapas de licitación / Fecha de Entrega de ofertas, etc.
       2. Podrán existir campos opcionales y campos obligatorios que será definido con el usuario.
       3. Podrán también existir casos donde se requieran desglosar ítems, que son prácticas definidas por las reglamentaciones de contrataciones públicas del sector público, por ejemplo
          1. Costos de repuestos separados de costos de mano de obra
          2. Costos de mantenimiento de oficina (pintura por m2, mano de obra por m2)
          3. Es decir, los precios referenciales no solo serán un campo de valor, sino una lista de valores, con unidades de medidas correspondientes.
   12. Identificación de solicitudes de compras consolidadas
       1. Durante el proceso de solicitudes de compras, la dependencia o área solicitante podrá definir el destino de las solicitudes
       2. Algunos ejemplos:
          1. Área de Servicios generales: identifica una cantidad de mobiliario, pero podrá identificar que el destino de dichos mobiliarios será para distintas dependencias.
          2. Área de TI: solicita una cantidad de equipos informáticos, pero muchos de ellos serán destinados para diversas oficinas de la institución.
          3. Área de Marketing: solicita una gran cantidad de publicaciones, pero cuyos destinos son diversos proyectos institucionales.
       3. En todos estos casos, la dependencia que solicita dichos bienes o servicios podrá agregar como observador a la dependencia final de destino de dichas solicitudes de compras y podrán recibir las alertas, también consultar sobre el estado de este pedido en cual participa como observador.

1. 13. Revisión de solicitudes de compra
       1. Antes de iniciar el periodo fiscal siguiente, normalmente en los últimos meses del año, ej. Noviembre, se requiere confirmar todos los requerimientos de adquisición y compras, para verificar que no haya habido cambios en las especificaciones, o incluir aclaraciones definidas por los solicitantes. Estos cambios pudieron haberse determinado de forma posterior a la presentación inicial de los proyectos de adquisición.
       2. El sistema deberá emitir una alerta y recordatorio a todos los solicitantes para confirmar / agregar / modificar /cancelar la solicitud inicial.
       3. Una vez finalizado el plazo determinado por la UOC, se iniciará el proceso de Solicitudes de compras
       4. Estas solicitudes de compras deberán tener Estados para indicar su situación, esta situación deberá definirse en colores indicativos visualmente, como por ejemplo:
          1. Borrador (o anteproyecto)
          2. En revisión (que podrán ser Rechazados o Aprobados)
          3. Aprobados
          4. Rechazados
          5. Cancelados
          6. Finalizados o Cerrados
   14. Funcionalidad de consolidación:
       1. La funcionalidad de consolidación deberá permitir entre otras cosas:
          1. Agrupar las solicitudes por objetos de gastos u otros filtros definidos
          2. Unir varias solicitudes de compras similares, por ejemplo dos o más áreas realizan pedidos de compras de insumos similares, por ende, podrá ser unida para ser realizada una sola convocatoria o llamado de licitación para los ítems, para varias dependencias o áreas.
   15. Finalizado todos los procesos de recolección de datos, todas las Solicitudes de compras aprobadas serán enviadas a la DNCP, como Proyecto de compras finales.
   16. Estos datos de proyectos de compran generan un ID (que a partir de este punto deberán estar relacionados con todos los proyectos futuros, de manera automática, el sistema deberá indicar las Solicitudes de Compras, a que ID pertenecen y en qué estado se encuentra.
   17. En todo momento el usuario de la UOC deberá poder visualizar en una matriz la situación de las solicitudes de compras, y al hacer click sobre el ítem de la matriz, desplegar la información detallada.

1. 18. Como dato de detalle de las solicitudes y /o como parte de consultas deberán visualizarse información tales como:
       1. Llamados estándares o contratos abiertos, en estos últimos también será requerida información adicional:
          1. Saldo de contrato (para determinar si ya es necesario realizar nuevos llamados)
       2. Vencimiento de contratos anteriores que hagan referencias, por ejemplo, un llamado plurianual, cuyo contrato vence en el siguiente periodo y tenga que ser renovado., esto es especialmente para aquellos contratos que requieran continuidad, en las siguientes categorías
          1. Mantenimientos
          2. Seguros
          3. Soportes
   19. Se deberá disponer de una funcionalidad de Llamados urgentes, que permita indicar en la matriz un plazo menor para todo el proceso.
       1. Se iniciarán alertas de manera inmediata para todos los usuarios.
       2. Este llamado se posicionará en el primer nivel de atención de los usuarios.
   20. Deberá disponer de funcionalidades como:
       1. Cambio de fecha de apertura
       2. Alerta de vencimiento de tope de consulta
       3. Plazo para emitir el dictamen
       4. Plazos de presentación de especificaciones
   21. Precio referencial. En cada proceso de adquisición se deberá describir el método por el cual se ha establecido el precio referencial. Normalmente estos se construyen por algunos de los siguientes métodos.
       1. Contratos de otras instituciones obtenidos del portal de contrataciones.
       2. Publicaciones en revistas, internet
       3. Contrato anterior
       4. Presupuestos
       5. Campo de observación para describir si la obtención del precio referencial es por promedio o justificar el motivo por el cual es considerado cada precio unitario de cada ítem.

1. 22. La segunda etapa se compone del proceso de Ejecución y seguimiento de las compras.

1. 1. 1. Deberá permitir registrar los datos de la convocatoria, como Proveedor adjudicado, monto, Código de Contratación, Datos del contrato, estos datos podrán ser capturados inclusive desde el portal de contrataciones utilizando el API provisto por el mismo.
      2. El API indicado por Contrataciones públicas, así como las instrucciones de implementación se encuentran en el siguiente link https://www.contrataciones.gov.py/datos/api/v2/
      3. Se deberá disponer de un fichero de proveedores, el cual también podrá ser capturado desde el portal de la DNCP utilizando el API indicando el RUC o razón social; inclusive
      4. Gestión de contratos:
         1. Deberá permitir generar una proforma de contrato en formado DOCX para su posterior impresión, completando todos los datos de la licitación en cuestión.
         2. Deberá permitir disponer varias versiones de modelos de contratos, ya que estos generalmente pueden ir siendo modificados en el transcurso del tiempo.
         3. Responsable del contrato. Esta funcionalidad deberá permitir asignar a un funcionario responsable del seguimiento del contrato, por ejemplo, equipos de TI podrá ser asignado para su seguimiento al responsable del área y/o alguien designado por el mismo, por tanto, todas las notificaciones y eventos relacionados a estos le deberá ser notificado, es decir se emite una orden de compra relacionada a un contrato y esta es notificada al responsable para su conocimiento.
         4. Vencimientos de contratos. Debe de disponer de un reporte para consultar los vencimientos de los contratos y su estado, es decir, permitir visualizar los contratos, la vigencia de estos, si se han emitido las correspondientes órdenes de compras, alertas en caso de que no se disponga aun del código de contratación, para continuar los procesos.
         5. Documentos y obligaciones relacionadas a los contratos. Todos los contratos disponen de cierta documentación mandataria (Ej. Garantías de contratos, documentación suplementaria), se debe disponer de una lista de chequeo para permitir controlar que se haya recibido toda la documentación para posteriormente subirlo al portal de la DNCP.
         6. Esta lista de chequeo de documentaciones deberá ser establecida con base en las reglamentaciones según cada tipo de convocatoria, sin embargo la UOC podrá establecer componentes de lista de chequeo adicionales en caso de ser necesario, por ejemplo, un documento o correo electrónico interno que no es mandatorio subir al portal de la DNCP, pero que es importante para los procesos internos.

1. 1. 5. Órdenes de compras
         1. Deberá disponer de un fichero de órdenes de compras, que permita la emisión de este documento. Este proceso deberá apenas cargar la fecha de emisión, y datos propios del comprobante, todos los demás datos, como datos de la licitación, datos del contrato y la adjudicación deberá ser arrastrado de la base de datos previamente cargado durante los diversos procesos relacionados, desde el inicio de la solicitud de compra, minimizando de esta manera la doble o triple carga de datos.
         2. También deberá disponer de alertas y recordatorios de emisión de órdenes de compra, por ejemplo, al estar disponible el código de contratación, la firma de contratos y todos los requisitos legales, a emitir las órdenes de compras y el seguimiento del cumplimiento de los plazos.
         3. Deberá disponer de una matriz de seguimiento de cada etapa de las licitaciones posterior a la firma de los contratos. Esto deberá permitir a los usuarios de la UOC realizar un seguimiento de los bienes y/o servicios a ser recibidos, y los plazos de estos.

1. 1. 6. Actas de recepción
         1. Una vez finalizada la recepción de los bienes y/o servicios, se deberán emitir las Actas de recepción y/o conformidad, o eventualmente una anotación de no recepción, por lo que se deberá disponer por ende de formatos de proformas de Actas de recepción.
         2. Este componente podrá ser para emitir uno o varios informes realizados u otra evidencia de la operación.
         3. Generados y completados los comprobantes o evidencias, se enviarán las notificaciones a los usuarios correspondientes, y la UOC podrá emitir un informe para iniciar los procesos de pagos.

1. 1. 7. Procesos de pagos
         1. Estos procesos de pagos serán realizados en otros sistemas financieros institucionales, por ende, se utilizarán eventualmente la integración descrita en la sección de características técnicas.
         2. Deberá disponer de un área para registrar aquellos llamados cuyas órdenes de pagos han sido recibidos, completados y con proceso de pago iniciado.
         3. Opcionalmente deberá disponer de recordatorio mensual de pagos.
         4. Durante el proceso de pago, al momento de recibir la factura este podrá ser una o varias facturas asociadas a una orden de compra emitida, es decir deberá validar que no se haya presentado varias facturas por los mismos bienes o servicios recibidos.

1. 23. Informes y reportes
       1. El sistema deberá permitir generar diversos reportes requeridos por la UOC en particular, por los diversos usuarios de la plataforma en general, y para los directivos en la ayuda para la toma de decisiones.
       2. Listado de solicitudes de compras (filtros por fechas, por periodos, por dependencias o áreas, por estado).
       3. Listado de solicitudes de compras aprobadas y ser convertidas en Convocatorias.
       4. Listado de Convocatorias (por tipo de llamado, por estado, por rango de fechas.
       5. Listado de llamados adjudicados (filtros por rango de fechas, por área, por proveedor)
       6. Listados de contratos (filtros por rango de fecha, por proveedor, por convocatoria, por tipo).
       7. Listados de órdenes de compras y/o servicio emitidas (filtros de rango de fecha, por proveedor, por licitación relacionada).
       8. Listados de procedimientos impugnados (filtros de rango de fecha, por proveedor, por licitación relacionada).

3. Firma digital.

El creciente uso de las firmas digitales en los distintos procesos del gobierno paraguayo (implementación de políticas de cero papeles), y las entidades privadas (simplificación y rapidez en procesos), obliga también a la institución a adecuar y facilitar los sistemas informáticos para dicha tarea.

1. 1. El sistema deberá permitir agregar dicha funcionalidad para la emisión de reportes, y en un proceso final de manera opcional, permitir al usuario firmar digitalmente.
   2. El componente de clave pública podrá ser almacenada en los servidores y podrá ser utilizado para mostrar los datos del firmante de los documentos.
   3. El componente de la clave privada no deberá ser almacenada en el servidor, y el mismo solo tendrá acceso el propietario de la firma, que podrá mantenerlo almacenado en la forma más conveniente que decida.
      1. Se deberá disponer de algunos reportes o formularios seleccionados que podrán ser firmados digitalmente o emitidos como reporte común, por ejemplo.
      2. Actas o Evidencias de recepción / aprobación de servicios, el usuario podrá seleccionar firmar digitalmente, con lo cual se generará un archivo en PDF y se les solicitará a los usuarios los parámetros de clave privada cuyo conocimiento solo deberá tenerlo él mismo.
      3. Parámetros tales como certificadores o plantillas predefinidas para la firma digital podrán ser almacenadas y desplegadas durante este proceso.
      4. Podrá usarse una firma digital generada por el servidor mediante una generación de una clave RSA (para este caso se utilizará sólo a nivel interno), o utilizando un token o una firma digital emitida por un Prestador de Servicios de Certificación (PSC) habilitado dentro de la infraestructura de Clave Pública del Paraguay.
      5. En caso de utilizarse la opción de uso de Certificados digitales en módulos criptográficos como Tokens u validado por la Autoridad de Certificación Raíz del Paraguay, se deberá disponer de especial cuidado en el diseño de la interfaz de usuario, agregando alertas, e indicadores para los usuarios, todo esto considerado que de acuerdo la legislación local tiene validez
         1. Ley N.º 4017 De validez jurídica de la Firma Electrónica, la Firma Digital, los mensajes de datos y el Expediente Electrónico
         2. Ley N.º 4610 "Que modifica y amplía la Ley N° 4017/10 "De validez jurídica de la firma electrónica, la firma digital, los mensajes de datos y el Expediente Electrónico"
         3. Decreto N.º 7369 "Por el cual se aprueba el Reglamento General de la ley N.°4017 "De validez Jurídica de la Firma electrónica, la Firma digital, Los mensajes de datos y el Expediente Electrónico.
         4. Decreto N.º 2063 Por el cual se amplía el Decreto N.º 242/2018" que establece la nueva estructura orgánica y funcional del ministerio del interior" y el Decreto N.º 7369/2011 "por el cual se aprueba el reglamento general de la Ley N.º 4017/2010 "de validez jurídica de la firma electrónica, la firma digital, los mensajes de datos y expediente electrónico"
         5. Resolución N.º 164 Por la cual se reglamentan los artículos N°35 y N°42 de la Ley N.º 4017
         6. Resolución N.º 1430 Por la cual se aprueba y pone en vigencia la Política de Certificación de la Infraestructura de Clave Pública del Paraguay. Se deja sin efecto Resoluciones N° 165/2013 y N°771/2013.
         7. Resolución N.º 501 Por la cual se aprueba y pone en vigencia la Guía de Estándares Tecnológico y Lineamientos de Seguridad para la Habilitación y Auditoria a Prestadores de Servicios de Certificación.
         8. Resolución Nº 1562 Por la cual se modifica parcialmente la resolución Nº 1400/2016 de fecha 09 de noviembre de 2016, Que aprueba y pone en vigencia las directivas obligatorias para la formulación y elaboración de la Política de Certificación y Declaración de Prácticas de Certificación de los Prestadores de Servicios de Certificación habilitados en la República del Paraguay.
         9. Otras resoluciones que reglamenten el funcionamiento de las leyes y decretos vigentes
      6. Documentos cargados al sistema, que contenga anotaciones o metadatos que puedan ser leídos mediante estándares de firma digital, cuya visualización será mostrada en el sistema con un elemento o icono distintito de firma digital.

4. Tareas adicionales requeridas
   1. Migración de datos. Se requerirá migración de datos existentes en otras bases de datos, como fines históricos, o archivos de Excel. La base de datos actual se encuentra en SQL SERVER 2014.
      1. Estos datos deberán ser normalizados y ajustados a la estructura de la plataforma solicitada.
   2. Capacitación en el uso del sistema
   3. Soporte técnico, de 12 meses posteriores a la entrega del sistema y su puesta en funcionamiento operativo.

5. REQUERIMIENTOS Y EXPERIENCIA TÉCNICA

El Oferente deberá proporcionar evidencia documentada que demuestre su cumplimiento con los siguientes requisitos de experiencia:

1. Evidencia de contratos en la provisión a Instituciones Públicas y/o Privadas, dentro de los últimos 5 años (2016 al 2020, de Sistemas Administrativos de Compras o similares por el Oferente, como por ejemplo: 

1. Contratos de Seguimiento de Expedientes y Work Flow
2. Contratos   de Control de Activo Fijo
3. Contratos de Stock y Almacenes
4. Contratos de Recursos Humanos

2. Autorización del fabricante o Desarrollador del Sistema; o haber sido el desarrollador de los sistemas demostrable con el Certificado de Registro Nacional del Derecho de Autor, en caso de que el oferente no sea el autor de los sistemas, deberá acompañar el documento de cesión de derechos de los mismos, además de los Certificados del Registro Nacional del Derecho de Autor del cedente.

6. Plazos de entrega

Plazo de entrega: el oferente adjudicado dispondrá de un plazo máximo de ocho meses para la entrega del software en condiciones operativos, con todas las funcionalidades requeridas en las especificaciones técnicas, dicho plazo se computa desde la fecha de entrada en vigencia del contrato.

7. Lugar y condiciones de prestación y entrega del Software

Los trabajos de ajustes del software serán realizados básicamente en las oficinas de la Convocante y/o de Empresa Adjudicada, teniendo en cuenta los protocolos sanitarios actuales

8. Forma de pago

La forma de pago del producto será de la siguiente manera:

• 30 % a la entrega e instalación del Software.
• 70 % posterior a la instalación y puesta en funcionamiento total del Software.

Para realizar los pagos el oferente deberá entregar las documentaciones y evidencias necesarias que serán verificadas y aprobadas por los responsables del producto por parte de la AFD. 

9. Garantia del bien

Luego de la Aceptación Operacional (salida en Producción), las modificaciones en el software, derivadas de fallas de diseño, ingeniería o fabricación, deben realizarse sin cargo alguno para la AFD, por un período de garantía de un (1) año como mínimo.

• Nombre,  cargo  y dependencia de la Institución de quien solicita: Esperanza Ocampo, Encargada de Servicios Administrativos de la AFD
• Justificar la necesidad que se pretende satisfacer mediante la contratación a ser realizada: la Institución tiene como objetivo adquirir un software para gestionar las Compras institucionales, que incluyen diversos procesos desde el planeamiento del abastecimiento, es decir ayudar a identificar las necesidades de bienes y servicios; el seguimiento de los procesos y plazos, la recepción del bien o servicio y el posterior pago por dichas compras o servicios.
• Justificar la planificación: el llamado se encontraba previsto en el Programa Anual de Contrataciones de la AFD para el ejercicio fiscal 2020; posteriormente se había resuelto modificarlo a Ad Referéndum al ejercicio fiscal 2021, en el cual ha sido llevado a cabo pero fue cancelado por cuestiones relativas a las EETT. Finalmente, atendiendo a que la necesidad de la adquisición del software persiste a la fecha, y a los tiempos para la programación de la convocatoria y su evaluación, se modificó el PAC a fin de que pueda ser ejecutado en los ejercicios fiscales 2021 y 2022.

No aplica

No aplica

No aplica

Planificación de indicadores de cumplimiento:

La Convocante adjudicará el contrato al oferente cuya oferta haya sido evaluada como la más baja y cumpla sustancialmente con los requisitos de las bases y condiciones, siempre y cuando la convocante determine que el oferente está calificado para ejecutar el contrato satisfactoriamente.

La comunicación de la adjudicación a los oferentes será como sigue:

1. Dentro de los cinco (5) días corridos de haberse resuelto la adjudicación, la convocante comunicará a través del Sistema de Información de Contrataciones Públicas, copia del informe de evaluación y del acto administrativo de adjudicación, los cuales serán puestos a disposición pública en el referido sistema. Adicionalmente el sistema generará una notificación a los oferentes por los medios remotos de comunicación electrónica pertinentes, la cual será reglamentada por la DNCP.

2. En sustitución de la notificación a través del Sistema de Información de Contrataciones Públicas, las convocantes podrán dar a conocer la adjudicación por cédula de notificación a cada uno de los oferentes, acompañados de la copia íntegra del acto administrativo y del informe de evaluación. La no entrega del informe en ocasión de la notificación, suspende el plazo para formular protestas hasta tanto la convocante haga entrega de dicha copia al oferente solicitante.

3. En caso de la convocante opte por la notificación física a los oferentes participantes, deberá realizarse únicamente con el acuse de recibo y en el mismo con expresa mención de haber recibido el informe de evaluación y la resolución de adjudicación.

4. Las cancelaciones o declaraciones desiertas deberán ser notificadas a todos los oferentes, según el procedimiento indicado precedentemente.

5. Las notificaciones realizadas en virtud al contrato, deberán ser por escrito y dirigirse a la dirección indicada en el contrato.

Una vez notificado el resultado del proceso, el oferente tendrá la facultad de solicitar una audiencia a fin de que la convocante explique los fundamentos que motivan su decisión.

La solicitud de audiencia informativa no suspenderá ni interrumpirá el plazo para la interposición de protestas.

La misma deberá ser solicitada dentro de los dos (2) días hábiles siguientes en que el oferente haya tomado conocimiento de los términos del Informe de Evaluación de Ofertas.

La convocante deberá dar respuesta a dicha solicitud dentro de los dos (2) días hábiles de haberla recibido y realizar la audiencia en un plazo que no exceda de dos (2) días hábiles siguientes a la fecha de respuesta al oferente.