El Suministro deberá incluir todos aquellos ítems que no hubiesen sido expresamente indicados en la presente sección, pero que pueda inferirse razonablemente que son necesarios para satisfacer el requisito de suministro indicado, por lo tanto, dichos bienes y servicios serán suministrados por el Proveedor como si hubiesen sido expresamente mencionados, salvo disposición contraria en el Contrato.
Los bienes y servicios suministrados deberán ajustarse a las especificaciones técnicas y las normas estipuladas en este apartado. En caso de que no se haga referencia a una norma aplicable, la norma será aquella que resulte equivalente o superior a las normas oficiales de la República del Paraguay. Cualquier cambio de dichos códigos o normas durante la ejecución del contrato se aplicará solamente con la aprobación de la contratante y dicho cambio se regirá de conformidad a la cláusula de adendas y cambios.
El Proveedor tendrá derecho a rehusar responsabilidad por cualquier diseño, dato, plano, especificación u otro documento, o por cualquier modificación proporcionada o diseñada por o en nombre de la Contratante, mediante notificación a la misma de dicho rechazo.
LIC. RUBEN FRANCO, DIRECTOR DE LA DIRECCION DE TECNOLOGIA DE LA INFORMACION Y COMUNICACION.
La necesidad que se pretende satisfacer mediante la presente Contratación de Servicio, obedece principalmente a la necesidad de mantener actualizados los softwares adquiridos anteriormente, de manera a seguir manteniendo la capacidad operativa de las distintas Dependencias del MAG. El citado Software es también de vital importancia debido a los resultados obtenidos de manera exitosa y positiva en estos años de implementación y, teniendo en cuenta que el 80% de los funcionarios del MAG a nivel País ya fueron capacitados y se encuentran actualmente utilizando dicho Sistema, así también implica un alto y mayor costo adquirir un Nuevo Sistema similar ofrecido por cualquier proveedor en plaza.
El llamado, objeto de la presente contratación, se trata de un llamado periódico necesario y de vital importancia para mantener en óptimas condiciones de operatividad a los software.
Las Especificaciones técnicas establecidas en el Pliego de Bases y Condiciones, conforme a los requerimientos realizados por la Dependencia solicitante.
Los productos y/o servicios a ser requeridos cuentan con las siguientes especificaciones técnicas:
| Ítem | Código de Catalogo | Especificaciones Técnicas | Unidad de Medida | Presentación | Cantidad |
| 1 | 43232202-002 | Sistema de Gestion de Trámite de Documentos. | Unidad | Unidad | 1 |
ACTUALIZACION SISTEMA DE GESTIÓN DEL EXPEDIENTES
El sistema de Seguimiento de Expedientes se encargará de llevar el control de los movimientos de los Expedientes de la Institución.
El sistema deberá contemplar todos los datos generales del documento, lleva un control del flujo y funcionarios que tuvieron intervención en sus trámites.
Los principales procesos contemplados son:
Así mismo deberá generar todos los reportes y documentos necesarios como ser:
El sistema deberá contar con herramientas para el control del movimiento de los expedientes, así mismo genera notificaciones en pantalla como por correo sobre plazos y movimientos de expedientes.
El sistema deberá generar de manera dinámica columnas de base de datos según las necesidades de los datos de cada tipo de expedientes. Este sistema será primordial para facilitar el futuro desarrollo de informes por parte de la contratante.
Todas los expedientes y movimientos de los mismos deberán contemplar la posibilidad de adjuntar archivos digitalizados de los documentos oficiales de cada uno.
El sistema deberá generar reportes gráficos y listados con resúmenes que se reflejan en un panel principal, dando al usuario un panorama general de la situación de los expedientes vinculados a la dependencia donde se encuentra activo el usuario.
Presentación en modo transición
La presentación en modo transición consiste en la generación de un mecanismo donde se puedan seleccionar uno o varios datos/gráficos que figuran en el panel principal y estos puedan ser expuestos de manera dinámica en el monitor del usuario. Estará enfocado principalmente para ser visualizado en pantallas de gran tamaño (32 pulg. o superiores) dispuestos en puntos claves para demostrar el proceso de la gestión.
Los datos a mostrar en la transición deberán poder ser configurables por cada usuario.
Datos primarios o básicos requeridos
Tipo de datos
Informaciones requeridas: Nombre del campo o columna de bd, Referencia, Tipo de dato, Valores permitidos, Descripción, Prioridad, Visible por defecto en listado.
Datos iniciales cargados: Todos tipos de campos requeridos por los expedientes migrados.
Funcionalidad/es: Generar de manera dinámica según cada tipo de datos un campo o fila en bd, a fin de almacenar en dicho campo del dato de cabecera del expediente y facilitar el futuro desarrollo de reportes por parte de la contratante.
Validación/es: No se podrán generar elementos con nombre de campos repetidos y/o reservados por la lógica del sistema.
Reporte/s: Cantidad y nombre de tipo de expedientes que utilizan el campo, cantidad de registros con valores no nulos que utilizan este campo.
Tipo de expedientes
Informaciones requeridas:
Cabecera: Identificador, denominación, prefijo, Tipo de origen permitido (Interno/Externo), Plazo general establecido.
Detalle:
Datos: Se registrarán los tipos de datos por cada tipo de expediente según las siguientes especificaciones: Vinculación con el tipo de dato, Instrucciones para el usuario sobre el dato a cargar, Orden de prioridad para la carga en formulario, Información exigida (si/no).
Pasos: Se determinará el flujo lógico de expediente de este tipo, determinando los pasos y plazos normales para el tipo de expediente, los valores mínimos requeridos para esta configuración serán los siguientes datos: Orden del paso, Descripción de la actividad o paso, Tipo de dependencia (Dependencia creadora del expediente, Dependencia específica, apara este caso determinar la dependencia).
Creación exclusiva: Determinación de las dependencias que pueden crear este tipo de expediente, en el caso de no determinar ninguna dependencia el sistema permitirá crear este tipo de expedientes a todas las dependencias.
Datos iniciales cargados: Según necesidad de datos migrados.
Funcionalidad/es: Determinar los datos del tipo de expediente, el comportamiento del tipo de expediente y plazos asociados.
Validación/es: Validaciones sobre lógica de recorrido de expedientes.
Reporte/s:
Entidades de tipo origen externo
Informaciones requeridas: Alias, denominación.
Datos iniciales cargados: Según necesidad de migración de datos.
Funcionalidad/es: Vinculación de movimiento de expedientes a ubicaciones y/o dependencias que no corresponden a la entidad.
Validación/es: Verificación de similitud de datos.
Reporte/s: Listado de entidades, cantidad de utilización de los campos.
Personas
Informaciones requeridas: Cédula/Ruc, Nombre, Apellido, Fecha de nacimiento, Teléfono, Dirección, Observación.
Datos iniciales cargados: Según necesidad de migración de datos.
Funcionalidad/es: Registrar personas físicas y/o jurídicas vinculadas a expedientes.
Validación/es: Verificación de similitud de datos.
Reporte/s: Listado de personas con cantidad de expedientes vinculados. Listado de personas con cantidad de expedientes vinculados no finiquitados.
Destino por dependencias
Informaciones requeridas: Dependencia origen, dependencia destino.
Datos iniciales cargados: Ninguno.
Funcionalidad/es:
Se determinará regla de envío de expedientes solo a ciertas dependencias, las dependencias que no posean asignaciones podrán enviar a todas las dependencias.
Reporte/s: Listado de dependencias con destinos permitidos y listado de dependencias con orígenes permitidos.
Organigrama
Carga del organigrama institucional por dependencias. El sistema debe manejar de manera independiente el organigrama institucional al organigrama o estructura financiera, ya que el institucional es el que denota las oficinas y procesos de los funcionarios.
El organigrama institucional no se maneja por periodo, es un organigrama eterno que si posee la posibilidad de decir que un ítem se encuentra activo o inactivo.
Las estructuras del organigrama deben ser en forma de árbol a fin de que el sistema no tenga un límite de niveles para la generación de dependencias relacionales.
Datos específicos: ID Ítem organigrama, Referencia al ítem padre, Nombre de la dependencia, dirección etc, Responsable y/o firmante.
Reglas:
Forma de búsqueda:
La búsqueda de los registros se hará teniendo en cuenta el ítem y sus padres.
Por lo tanto si existen un organigrama (ejemplo a continuación):
Entidad (1)
Dirección Administrativa (2)
Informática (3)
Tesorería (4)
Dirección de Apoyo (5)
Informática (6)
Comunicación Interna (7)
Donde se busca
Forma de utilización en filtros de reportes: En todos los sectores del sistema que se hagan referencia a un filtro por dependencia, el sistema debe poseer un checkbox para indicar si:
Informes y Reportes:
Dependencia por usuarios
Informaciones requeridas: Vinculación con usuario, dependencia, estado activo o inactivo.
Funcionalidad/es: Vinculación del usuario con la o las dependencias donde este podrá realizar movimientos y/o consultas.
Reporte/s: Listado de usuarios con dependencias vinculadas, Listado de dependencias con algún usuario vinculado.
Expedientes
Creación y almacenamiento de los datos de los expedientes.
Datos específicos:
Cabecera: Tipo de expediente, Origen externo (si/no), Título/Asunto, Recurrente, Información sobre el recurrente (email y celular), Cantidad inicial de fojas del expediente.
Detalle 1 - Movimientos: Ver sección especificaciones en sección de Movimientos.
Adjunto: Permite adjuntar la digitalización del expediente original.
Filtros de visualización de los listados: El listado de expedientes tendrá filtros predeterminados que serán de la siguiente manera:
Columnas de datos tipo resultados visibles en el listado: Días hábiles en trámite, días hábiles de atraso, estado actual, datos de último movimiento, días hábiles sin movimiento.
Auto gestión: Consulta de datos del expediente por el propietario y/o recurrente del expediente, pin especial de acceso.
Funciones vinculadas: Generación automática de número, teniendo en cuenta la aplicación de normas establecidas en el tipo de expediente.
Validaciones principales:
Informes y reportes:
Observaciones: La búsqueda de expedientes deberá ser de fácil entendimiento, permitiendo buscar expedientes por cualquier tipo de dato indicado en la cabecera del expediente según cada tipo. En el caso que distintos tipos de expedientes compartan datos como ser por ejemplo Proveedor, este campo deberá aparecer en la misma columna del listado independiente que sean de distintos tipos de expedientes.
Registro de los movimientos del expediente, incluyendo como movimiento el glose o desglose de expedientes.
Datos específicos:
Adjunto: Documentación correspondiente a la modificada y/o agregada en el movimiento en cuestión.
Filtros de visualización de los listados: El listado de los movimientos realizados deberá tener opciones de modo de visualización, las opciones deberán ser: Todos los movimientos, Movimientos realizados en esta dependencia, Movimientos de expedientes que se encuentran en esta dependencia.
Columnas de datos tipo resultados visibles en el listado: Se deberá visualizar y filtrar por el usuario que realizó el movimiento.
Funciones vinculadas:
Importar expediente a mi dependencia: Esta función permitirá ingresar a esta dependencia expedientes que no se encuentran salientes con destino a esta dependencia, en este caso el sistema agregará de manera automática el movimiento de salida e ingreso correspondiente, realizando así la edición y/o inserción de los movimientos que sean necesarios para cumplir el objetivo. Esta función solo estará disponible con la asignación de roles específicos.
Expedientes con glose: El sistema deberá generar de manera automática los registros correspondientes a los movimientos de los expedientes glosados al padre, solo se permitirá el movimiento de expediente padre.
Generación de código identificador para los movimientos múltiples, estos se generarán principalmente cuando exista una entrada y/o salida grupal.
Validaciones:
El sistema deberá brindar seguridad en la lógica de movimientos de expedientes, respetando lógica de dependencias, orígenes, destinos, fechas etc.
Solo se permitirá glosar y desglosar expedientes que se encuentran en la dependencia.
No se permitirá un expediente actualmente glosado.
Solo se harán movimientos en los expedientes padre.
Informes y reportes:
Comunicaciones
Sistema de administración de comunicaciones enviadas y recibidas. Las comunicaciones podrán ser remitidas directamente por email o físicamente.
Datos específicos: Vinculación con movimiento y expediente, dependencia vinculada, fecha de envío de email o recepción física de comunicación.
Archivos
Registro y almacenamiento físico de los expedientes finiquitados.
Datos específicos: Expediente vinculado, fecha, nro. de orden en estante, nro. de fojas, digitalización del expediente completo.
Adjunto: Posibilidad de adjuntar el documento final digitalizado.
Informes y reportes:
Código de barra asociado al expediente
El sistema deberá contar con un sistema que genere un código de barra único para cada expediente. Este código de barra deberá poder ser utilizado en otras herramientas del sistema como ser: Punto de consulta y movimiento rápido de expediente.
Código QR asociado al expediente
El sistema deberá contar con un sistema que genere un código QR único para cada expediente. Este código QR deberá aparecer en la carátula del expediente y deberá ser utilizado para visualizar los datos del expediente en su dispositivo móvil.
Comprobante de entrada de tamaño confortable
Se deberá diagramar un comprobante de entrada con toda la información necesaria según el tipo de entrada, el mismo debe ser de tamaño confortable, que permita su practico almacenamiento y la reducción de utilización de hojas de papel.
Comprobante de entrada en email con firma electrónica
El sistema deberá poder enviar de manera automática un comprobante de entrada a los usuarios que son parte de ese movimiento, del mismo modo también se deberá enviar un email de recepción a cuentas de email vinculadas a la dependencia de salida como de origen del expediente.
Sistema de seguimiento de plazos
El sistema de seguimiento de plazos deberá manejar los siguientes estados:
Sistema de alertas sobre plazos
El sistema deberá generar alertar y notificaciones a usuarios vinculados sobre situaciones de plazos fenecidos según las reglas establecidas en el sistema de seguimiento de plazos.
Sistema de notificaciones sobre movimientos
El sistema deberá generar notificaciones vía email a los usuarios y/o personas vinculadas al expediente, esta propiedad podrá ser configurada, habilitada o deshabilitada según cada usuario y recurrente.
Punto de consulta
Ambiente preparado para puntos de autogestión. Diseño orientado a dar sensación de click en botones, preparado exclusivamente para disponibilizar puntos de autogestión donde el recurrente puede obtener un reporte impreso que posea datos del expediente y su ubicación actual. No se deberá mostrar el histórico de movimientos.
El punto de consulta deberá funcionar con impresoras de ticket y/o impresoras estándares, el código de barra asociado el expediente podrá ser utilizado para realizar la consulta sin la necesidad de introducir datos por pantalla.
Consulta mobile/web
Mecanismo de consulta con pin único por expediente para consultar la ubicación y/o estado actual del expediente. Este mecanismo deberá ayudará a transparentar la gestión e incrementar y facilitar el control del recurrente sobre su expediente.
Movimientos rápidos
Sistema de movimientos rápidos ubicado en el panel principal del sistema, este deberá agilizar y facilitar el proceso de realización de movimientos, sean estos movimientos únicos o múltiples para los casos que se reciben o envían más de un expediente a la vez.
La cantidad máxima de clicks o selección de datos necesarios para cada caso deberá ser:
Código de barra asociado al movimiento múltiple de salida
El sistema deberá generar un código de barra de identificación de movimientos múltiples de salida a fin de agilizar la entrada múltiple posterior.
Búsqueda por contenido del PDF
Todos los archivos que sean adjuntados al sistema, deberán pasar por un proceso OCR transparente para el usuario, esto deberá permitir la búsqueda de expedientes por contenido del pdf digitalizado.
ESPECIFICACIONES GENERALES DE LA PLATAFORMA DEL SISTEMA
El sistema debe estar desarrollado acorde a las últimas tendencias de desarrollo de software para ambiente web. Debe utilizar lenguajes y plataformas que posean una gran cantidad de soporte en línea.
La base de 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 auditoria pueda ser incremental y el backup de datos una copia o en espejo.
El sistema se debe adecuar totalmente para el acceso a través de Tablets o Smartphones, la navegación debe ser sencilla y el sistema debe correr sin ningún inconveniente sobre los browser más utilizados.
El sistema debe estar orientado al usuario operador, facilitando en todo momento el mecanismo de carga de datos.
Todos los informes deberán ser emitidos en formato pdf, los informes del tipo listados deberán ser exportables a Excel.
Las políticas de acceso a usuarios debe permitir un acceso por roles que podrá ser configurable según las exigencias de la Entidad.
Sistema en ambiente web WEB DEVELOPMENT
El sistema debe correr en ambiente web utilizando lenguajes con gran cantidad de soporte en línea.
Los códigos deberán ser entregados en su totalidad a la Entidad. Los códigos podrán ser modificados para el uso dentro de la misma entidad/administración, no podrán ser donados ni comercializados a otras entidades o administraciones.
Para los lenguajes compilados será exigido entregar los códigos fuentes correspondientes.
Diseño web adaptativo WEB RESPONSIVE
El diseño web adaptable (o adaptativo), conocido por las siglas RWD del inglés Responsive Web Design, es una filosofía de diseño y desarrollo cuyo objetivo es adaptar la apariencia de las páginas web al dispositivo que se esté utilizando para visualizarlas. Hoy día las páginas web se visualizan en multitud de dispositivos como tabletas, teléfonos inteligentes, libros electrónicos, portátiles, PCs, etcétera. Además, aún dentro de cada tipo, cada dispositivo tiene sus características concretas: tamaño de pantalla, resolución, potencia de CPU, sistema operativo o capacidad de memoria entre otras. Esta tecnología pretende que con un único diseño web, se obtenga una visualización adecuada en cualquier dispositivo.
Base de datos tipo Open Source
El sistema deberá utilizar una base de datos del tipo Open Sorce, la base de datos seleccionada deberá poseer las siguientes características:
El sistema deberá estar desarrollado sobre un "framework" (infraestructura, armazón, marco), en términos generales, un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar.
En el desarrollo de software, un framework o infraestructura digital, es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos concretos de software, que puede servir de base para la organización y desarrollo de software. Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes de un proyecto.
El framework utilizado deberá estar entre los más populares y debe contar con una gran cantidad de soporte en línea.
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 trigger del tipo before. Todas las tablas del sistema verificarán la lógica de datos a través de triggers. De esta forma se protege los datos aunque los mismos sean manipulados desde la propia base de datos o insertados desde otro sistema anexo.
El sistema deberá prever algún mecanismo que valide que los triggers de validación se encuentren activos. Inclusive si los triggers se desactivasen manualmente el mecanismo deberá activarlos antes de una inserción de datos desde el sistema.
Todas las validaciones realizadas deberán contar con un comentario en el código que explique a grandes rasgos el tipo de validación que se realiza.
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 vincularan únicamente a roles. Pudiéndose vincular a uno o más roles.
Los usuarios tendrán una propiedad de usuario activo (SI/NO), solo podrán acceder al sistema los usuarios activos SI.
Las creaciones de roles y asignaciones de los mismos deberán ser registrados en la tabla de auditoria de datos.
Políticas de clave de acceso
Políticas de claves de acceso configurables. Se podrá configurar en el sistema el nivel de seguridad exigido al usuario al momento de ingresar una nueva contraseña. Entre los tipos de configuración que se podrán seleccionar están:
El sistema permitirá configurar una periodicidad para el cambio de la clave de acceso, donde por ejemplo el valor 60 (sesenta) forzará a los usuarios a actualizar su clave cada 60 días y el valor 0 (cero) determinará que no se solicitará reasignar la clave en ningún momento.
En el caso de contar con servidor LDAP, el sistema podrá corroborar su clave de acceso contra el mismo.
Mecanismo de 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á realizada en paralelo de dos maneras:
El sistema debe poseer un mecanismo de validación de activación de todos los triggers de validación con cada conexión a la base de datos, evitando así problemas por desactivación intencional o involuntaria de los triggers de validación.
Almacenamiento de auditoría
Los registros de auditoría deberán ser almacenados de forma definitiva en una base de datos distinta a la base de datos del sistema en sí, esto por un lado alivianará el tamaño de la base de datos operativa y hará más fácil el backup de datos. Tanto de los datos de auditoria como los datos del sistema. Con esta estructura de base de datos permitimos que los backups de auditoria sean por el mecanismo incremental.
Políticas de Backup
El sistema tendrá un mecanismo propio de backup de base de datos y archivos fuentes. El sistema deberá tener una ventana de configuración, la ventana de configuración deberá permitir lo siguiente:
Se podrán agregar varias reglas permitiendo así en resguardo de los archivos en diferentes directorios y periodicidades distintas según el tipo de backup.
Mecanismo de notificaciones
El sistema deberá contar con un mecanismo de notificaciones que trabaje con distintos tipos de eventos. Las notificaciones deberán aparecer al usuario dando la opción de:
Las notificaciones deberán aparecer sobre el entorno de trabajo en el que se encuentre el usuario.
Las notificaciones y respuestas sobre las mismas serán registradas por usuarios.
Configuración de firmantes de reportes
Los firmantes de los reportes podrán ser configurables, se podrán determinar ciertos tipos de firmantes para ciertos tipos de reportes a ser definidos por la entidad.
Navegabilidad dentro del sistema
El sistema requerirá de una navegación fácil y rápida entre sus ventanas, otorgando al usuario operador facilidades al momento de la carga de datos.
Características principales:
Mecanismo de importación de datos
Todas las tablas de base de datos que utilicen datos de gestión operativas deberán contar con la opción de importar datos directamente desde el sistema, se podrá importar adjunto un archivo o copiado y pegando la información en un textarea.
Cada tabla o sección de importación deberá indicar al usuario cual es el formato requerido para la importación de datos.
Los formatos habilitados para la importación de datos serán:
Exportación de informes del tipo listado a formato Excel
Todos los reportes que generen como resultado principal un listado de datos deberán tener la opción de ser exportados a formato Excel.
Los archivos creados deberán tener la extensión xls o xlsx. Deberán abrirse en Excel sin ninguna advertencia por tipo de archivo o datos.
Envío en informes por e-mail directamente desde el servidor
Todos los reportes en PDF que genere el sistema deberán tener la opción de poder ser enviados por email, también se podrán configurar:
Los reportes que serán enviados en una fecha distinta a la actual deberán reflejar los datos que posee el sistema al momento que se indica en la fecha de envío.
Se generará un listado de todos los envíos pendientes, el usuario que posea permiso para ver todos los envíos pendientes y cada usuario que generó el envío podrá visualizar, reconfigurar y eliminar los envíos de informes.
Se requerirá de la configuración del sistema a una cuenta de e-mail institucional de manera segura y respetando todas las políticas generales para no ser detectados como spam.
Formularios del tipo carga rápida
Todos los formularios de inserción de información al sistema deben tener la opción de carga rápida. Damos a entender por carga rápida un mecanismo por el cual:
Modo de presentación de listados y búsqueda de datos
La presentación de los listados de datos de secciones deberá tener en cuenta los siguientes puntos:
Mecanismo de selección de campos relacionados
Dentro de formularios de inserción y edición de datos poseemos ciertos datos que van vinculados con otros datos ya cargados en el sistema. Por lo tanto en estos casos se debe seleccionar el valor al cual se hará referencia.
Para estos casos el sistema se deberá adecuar al siguiente mecanismo:
Mecanismo de upload de archivos y fotos
El mecanismo de upload de fotos y archivos genera en gran medida problemas y retrasos al momento de carga de datos, por lo tanto las características que debe cumplir el mecanismo son las siguientes:
El almacenamiento de los archivos deberá seguir las siguientes pautas de orden y seguridad:
Vista previa de los pdf’s adjuntos
Los archivos adjuntos en formato pdf deberán tener la propiedad de poseer una vista previa en formato jpg de la primera página del pdf.
Aplicación para upload directo de fotos y pdf´s
El sistema requerirá de una aplicación que facilite el mecanismo para adjuntar imágenes y pdfs al sistema.
Funcionalidad general
La aplicación deberá estar disponible para Android. Se encargará de facilitar el proceso de vincular las imágenes tomadas con el dispositivo y vincularlas con el registro correspondiente en el sistema.
Si el registro requiere de un archivo pdf, la aplicación deberá transformar la imagen o secuencias de imágenes en un archivo pdf con unas o varias páginas según la cantidad de imágenes tomadas en la secuencia.
Funcionalidades específicas
Aplicación de calendario y notificaciones
El sistema requerirá de una aplicación donde los usuarios pueden visualizar el calendario de actividades en su Smartphone y recibir las mismas notificaciones que figuran en el sistema.
Funcionalidad general
La aplicación deberá estar disponible para Android. Tendrá como principal objetivo el de mantener al tanto a los funcionarios sobre las actividades vinculadas a su trabajo y principalmente procesos del sistema.
Funcionalidades específicas
Garantía
El sistema debe contar con una garantía de 2 (dos) años posterior a la correcta implementación documentada sobres las funcionalidades establecidas dentro del pliego de base y condiciones.
El plazo de garantía se dará por iniciado con la conformidad de la correcta impementación de los trabajos asignados.
Soporte
El soporte técnico será por un plazo de 2 (dos) años contados a partir de la fecha de vigencia del contrato.
El soporte será realizado preferente de manera remota para los casos que así lo permita. Caso contrario un técnico de la empresa se deberá presentarse en un plazo no mayor a 3 días hábiles.
Se podrá disponer hasta 2 (dos) presencias inmediatas por mes. Se entiende por presencia inmediata la condición de presentarse en el mismo día del requerimiento; y para los casos que la solicitud haya sido en horarios posterior al medio día, el proveedor podrá presentarse hasta el mediodía del día hábil siguiente.
TUTORIALES
Video tutoriales
Todas las secciones indicadas en el manual de usuarios deberán contar con un video tutorial explicativo que formará parte de cada sección de manual usuarios para su versión accesible desde el sistema.
PLAZO PARA ENTREGA FINAL E IMPLEMENTACION DEL SISTEMA
El sistema de Gestión de Expedientes deberá estar 100% implementado y en cumplimiento acorde a las especificaciones técnicas solicitadas en un plazo máximo de 45 (cuarenta y cinco) días.
Experiencia y Capacidad Técnica
El Oferente deberá proporcionar evidencia documentada que demuestre su cumplimiento con los siguientes requisitos de experiencia:
Deberá contar con una antigüedad mínima de 5 (cinco) años en el mercado, comprobado por medio de la Inscripción en el RUC.-
Presentar documentaciones que demuestren por lo menos 4 (cuatro) prestaciones de sistema de gestión de expedientes para recursos del estado. Los documentos podrán ser copias de contratos y/o facturaciones y/o certificados de uso de sistema de gestión de expediente en la entidad.
Las ofertas se aceptarán siempre que provengan de oferentes cuya ACTIVIDAD ECONÓMICA PRINCIPAL se encuentre vinculada al tipo de bienes (ramo informático), conforme Inscripción en la SET.
Se solicitarán demostraciones del sistema en la etapa de evaluación de la propuesta, la misma debe ser realizada el día señalado por la convocante. Esta demostración debe incluir una vista general del sistema y ABM (alta, baja, modificación) con los siguientes criterios a ser considerados:
Estructura de archivos, motor de base de datos y lenguaje utilizado acorde a EETT.
Una vez finalizada las pruebas, se labrará un acta en el cual será suscrito entre un representante del oferente y uno de la Convocante, con los resultados de cada uno de los criterios aquí mencionados, utilizando para ello el método cumple/no cumple teniendo en cuenta los criterios específicos mencionados en este listado y sus características específicas descriptas en el apartado de especificaciones técnicas dentro del presente PBC. Los gastos inherentes a estas inspecciones y pruebas quedarán por cuenta exclusiva del oferente.
| Ítem | Código de Catalogo | Especificaciones Técnicas | Unidad de Medida | Presentación | Cantidad |
| 2 | 43211711-9999 | Token para firma digital | Unidad | Unidad | 59 |
DISPOSITIVO CRIPTOGRAFICO TIPO TOKENS PARA FIRMA DIGITAL
Deberá contemplar la provisión de certificados para firma digital con validez jurídica, por lo que deben ser emitidos por un prestador de servicio de certificación habilitado en el marco de PKI PARAGUAY por la Dirección General de Firma Digital y Comercio Electrónico del Ministerio de Industria y Comercio.
Los certificados a ser adquiridos deben corresponder a la subordinada a la Autoridad Raíz de la infraestructura de Clave Pública de Paraguay.
Los CERTIFICADOS DIGITALES a adquirir deberán ser de 2 años.
Los certificados digitales a adquirir deberán ser emitidos utilizando dispositivos criptográficos de hardware seguros aprobados por el prestador de servicios de certificación, del tipo Tokens criptográfico.
Se deberán entregar los controladores de software para los dispositivos criptográficos y el middleware correspondiente para su utilización.
El proveedor de los CERTIFICADOS DIGITALES deberá brindar puntos de acceso para CRL y servicios de validación en línea del tipo OCSP para permitir comprobar el estado de los CERTIFICADOS DIGITALES que se adquieran.
En caso de bloqueo de los dispositivos, no deberá tener ningún costo el desbloqueo de los dispositivos.
Capacitación del uso de dispositivos.
ENTREGA DE LOS TOKENS CRIPTOGRAFICOS.
INCORPORACION DE LOS CERTIFICADOS DIGITALES A LOS DISPOSITIVOS.
La entrega de los bienes se realizará de acuerdo al plan de entrega y cronograma de cumplimiento, indicado en el presente apartado. Así mismo, de los documentos de embarque y otros que deberá suministrar el proveedor indicado a continuación:
|
Ítem |
Descripción del bien |
Cantidad |
Unidad de medida |
Lugar de entrega de los bienes |
Fecha(s) final(es) de entrega de los bienes |
|
(Indicar el N°) |
(Indicar la descripción de los bienes) |
(Insertar la cantidad de bienes a proveer) |
(Indicar la unidad de medida de los bienes |
(Indicar el nombre del lugar) |
(Indicar la(s) fecha(s) de entrega requerida(s) |
|
|
|
|
|
|
|
| Ítem | Código de Catalogo | Especificaciones Técnicas | Cantidad | Unidad de Medida | Lugar de entrega de los bienes | Fecha(s) final(es) de entrega de los bienes |
| 1 | 43232202-002 | Sistema de Gestion de Trámite de Documentos. | 1 | Unidad | Dirección de Tecnología de la Información y Comunicación, sito en Tte. Cnel. Irrazabal N° 668 e/ Azara y Herrera - Ciudad de Asunción | Hasta Diciembre/2021 |
| 2 | 43211711-9999 | Token para firma digital | 59 | Unidad |
Para la presente contratación se pone a disposición los siguientes planos o diseños:
No aplica
El embalaje, la identificación y la documentación dentro y fuera de los paquetes serán como se indican a continuación:
No aplica
Las inspecciones y pruebas serán como se indica a continuación:
No aplica
El documento requerido para acreditar el cumplimiento contractual, será:
Planificación de indicadores de cumplimiento:
|
INDICADOR |
TIPO |
FECHA DE PRESENTACIÓN PREVISTA |
|
Nota de Remisión / Informe 1 |
Nota de Remisión / Informe |
DICIEMBRE 2021. |
De manera a establecer indicadores de cumplimiento, a través del sistema de seguimiento de contratos, la convocante deberá determinar el tipo de documento que acredite el efectivo cumplimiento de la ejecución del contrato, así como planificar la cantidad de indicadores que deberán ser presentados durante la ejecución. Por lo tanto, la convocante en este apartado y de acuerdo al tipo de contratación de que se trate, deberá indicar el documento a ser comunicado a través del módulo de Seguimiento de Contratos y la cantidad de los mismos.
La convocante adjudicará el contrato al oferente cuya oferta haya sido evaluada como la más baja y cumpla sustancialmente con los requisitos de la carta de invitación, siempre y cuando la convocante determine que el oferente está calificado para ejecutar el contrato satisfactoriamente.
1. La adjudicación en los procesos de contratación en los cuales se aplique la modalidad de contrato abierto, se efectuará por las cantidades o montos máximos solicitados en el llamado, sin que ello implique obligación de la convocante de requerir la provisión de esa cantidad o monto durante de la vigencia del contrato, obligándose sí respecto de las cantidades o montos mínimos establecidos.
2. En caso de que la convocante no haya adquirido la cantidad o monto mínimo establecido, deberá consultar al proveedor si desea ampliarlo para el siguiente ejercicio fiscal, hasta cumplir el mínimo.
3. Al momento de adjudicar el contrato, la convocante se reserva el derecho a disminuir la cantidad de Bienes requeridos, por razones de disponibilidad presupuestaria u otras razones debidamente justificadas. Estas variaciones no podrán alterar los precios unitarios u otros términos y condiciones de la oferta y de los documentos de la licitación.
En aquellos llamados en los cuales se aplique la modalidad de contrato abierto, cuando la Convocante deba disminuir cantidades o montos a ser adjudicados, no podrá modificar el monto o las cantidades mínimas establecidas en las bases de la contratación.
La comunicación de la adjudicación a los oferentes será como sigue:
1. Dentro de los cinco (5) días corridos de haberse resuelto la adjudicación, la convocante comunicará a través del Sistema de Información de Contrataciones Públicas, copia del informe de evaluación y del acto administrativo de adjudicación, los cuales serán puestos a disposición pública en el referido sistema. Adicionalmente el sistema generará una notificación a los oferentes por los medios remotos de comunicación electrónica pertinentes, la cual será reglamentada por la DNCP.
2. En sustitución de la notificación a través del Sistema de Información de Contrataciones Públicas, las convocantes podrán dar a conocer la adjudicación por cédula de notificación a cada uno de los oferentes, acompañados de la copia íntegra del acto administrativo y del informe de evaluación. La no entrega del informe en ocasión de la notificación, suspende el plazo para formular protestas hasta tanto la convocante haga entrega de dicha copia al oferente solicitante.
3. En caso de la convocante opte por la notificación física a los oferentes participantes, deberá realizarse únicamente con el acuse de recibo y en el mismo con expresa mención de haber recibido el informe de evaluación y la resolución de adjudicación.
4. Las cancelaciones o declaraciones desiertas deberán ser notificadas a todos los oferentes, según el procedimiento indicado precedentemente.
5. Las notificaciones realizadas en virtud al contrato, deberán ser por escrito y dirigirse a la dirección indicada en el contrato.
Una vez notificado el resultado del proceso, el oferente tendrá la facultad de solicitar una audiencia a fin de que la convocante explique los fundamentos que motivan su decisión.
La solicitud de audiencia informativa no suspenderá ni interrumpirá el plazo para la interposición de protestas.
La misma deberá ser solicitada dentro de los dos (2) días hábiles siguientes en que el oferente haya tomado conocimiento de los términos del Informe de Evaluación de Ofertas.
La convocante deberá dar respuesta a dicha solicitud dentro de los dos (2) días hábiles de haberla recibido y realizar la audiencia en un plazo que no exceda de dos (2) días hábiles siguientes a la fecha de respuesta al oferente.
Luego de la notificación de adjudicación, el proveedor deberá presentar en el plazo establecido en las reglamentaciones vigentes, los documentos indicados en el presente apartado.
|
|
|
|
|
|
|
|
2. Documentos. Consorcios |
|
|
|
|