INSTALACIÓN Y PUESTA EN MARCHA DE SOLUCIÓN INTEGRAL DE SOFTWARE ADMS PARA EL ÁREA DE DISTRIBUCIÓN DE JASEC

Los interesados en cotizar deberán cumplir con los siguientes requisitos, los cuales se consideran indispensables para la aceptación de la oferta y su evaluación:

 

1. El oferente deberá presentar como anexo, la ficha técnica con las especificaciones técnicas, la marca, y/o el modelo de los ítems cotizados en la Tabla1 y deberán presentarse en idioma español.

 

1. Indicar la dirección de la página web donde se puede verificar la información indicada en la ficha técnica. Las ofertas en donde la información técnica de la ficha como la descrita en la página web, no sean coincidentes, a oferta no será tomada en cuenta como elegibles y será descartada del estudio.

 

1. Todos los ítems deberán se cotizados con precios unitarios y totales por artículo y por partida. La adjudicación se realizará por partida completa y en caso de adjudicación no se aceptan entregas parciales.

 

1. Experiencia específica en sistemas OMS

El oferente deberá acreditar experiencia específica en la implementación de sistemas de Gestión de Interrupciones (OMS), no siendo admisible experiencia limitada únicamente a sistemas GIS o sistemas de análisis fuera de línea.

Para tal efecto, el oferente deberá presentar mínimo tres (3) notas de clientes donde el sistema OMS se encuentre actualmente en operación productiva, con fecha de puesta en marcha dentro de los últimos cinco (5) años y que estas integraciones hayan sido en el Continente americano, en las cuales se indique de manera expresa:

• Alcance funcional del OMS implementado,
• Año de entrada en operación,
• Valor facturado del proyecto en dólares estadounidenses
• Información de contacto del responsable técnico u operativo del cliente, quien podrá ser contactado por la entidad contratante para verificación de la información suministrada.

La experiencia requerida podrá ser acreditada directamente por el oferente o, en caso de que este no sea el fabricante del sistema OMS ofertado, podrá ser acreditada por el fabricante. En este último caso, el fabricante deberá emitir una carta formal de respaldo al oferente, en la cual autorice expresamente el uso de su experiencia para efectos de esta oferta y manifieste su compromiso de soporte técnico y acompañamiento durante la ejecución del proyecto.

La falta de presentación de estas certificaciones o la imposibilidad de verificación de estas será causal de rechazo técnico de la oferta.

1. Experiencia y disponibilidad del personal clave

El oferente deberá presentar el equipo técnico que participará directamente en la ejecución del proyecto, incluyendo como mínimo el especialista en OMS y el especialista en integraciones con sistemas corporativos.

Para cada uno de los perfiles se deberá presentar hoja de vida detallada y certificaciones del fabricante en los respectivos sistemas.

1. Experiencia conjunta de fabricante e integrador

El oferente deberá demostrar experiencia como integrador del fabricante en la implementación de sistemas ADMS en empresas de distribución eléctrica, mediante notas de al menos tres (3) proyectos ejecutados en operación productiva, en las cuales se indique de manera expresa:

• Alcance funcional del ADMS implementado
• Año de entrada en operación
• Valor facturado del proyecto en dólares estadounidenses
• Información de contacto del responsable técnico u operativo del cliente, quien podrá ser contactado por la entidad contratante para verificación de la información suministrada.

Se deberá acreditar experiencia en proyectos donde el integrador haya implementado soluciones del fabricante ofertado.

Los bienes y servicios ofertados por cada oferente deberán cumplir con las siguientes características:

El componente OMS requerido para atender la solución del sistema avanzado de gestión de la distribución (ADMS) debe contener una plataforma OMS diseñada para maximizar el rendimiento de los operadores y despachadores trabajando con una única base de datos ADMS y una interfaz gráfica de usuario.

7.1.        Arquitectura del sistema.

• El oferente deberá proporcionar un diagrama de arquitectura de alto nivel del Sistema de Sistema de Gestión de Interrupciones (OMS). A partir de este diagrama, el oferente deberá describir detalladamente cómo cada componente interactúa para garantizar la correcta gestión del ciclo de vida de las órdenes, incluyendo:

 

• Flujo de información entre módulos funcionales.
• Integración con sistemas externos
• Mecanismos de seguridad y control de acceso.
• Escalabilidad y alta disponibilidad de la solución.
• Cumplimiento con estándares internacionales aplicables.

 

• El diagrama deberá ser claro, legible y reflejar la arquitectura modular del sistema, indicando las capas de presentación, lógica de negocio, integración y almacenamiento de datos.

 

• El Sistema de Gestión de Interrupciones (OMS) deberá estar integrado con los servidores SCADA y DMS de la plataforma en uso de JASEC, garantizando la interoperabilidad y el intercambio de información en tiempo real para la operación eficiente de la red eléctrica.

 

• El sistema de Gestión de Interrupciones (OMS) deberá poder comunicarse con las aplicaciones e interfaces necesarias, incluyendo SCADA marca Survalent, DMS marca Survalent, CIS, GIS marca Intergraph y Supermap, AMI (por contratar), AVL, IVR/TCS y servicios de mensajería de texto, garantizando la interoperabilidad y el flujo seguro de información.

 

• El sistema deberá garantizar la implementación de redundancia, soportando hasta cuatro niveles de redundancia para asegurar la continuidad del servicio y la disponibilidad del sistema ante fallas. El tipo de redundancia aplicada deberá incluir redundancia de hardware, redundancia de software, redundancia de comunicaciones y redundancia de base de datos.

 

• Para cualquier servidor orientado al cliente, el sistema deberá implementar mecanismos de seguridad que garanticen que el público no tenga acceso directo a los servidores SCADA/OMS. Estos mecanismos deberán incluir segmentación de redes, firewalls, autenticación robusta y cifrado de datos. Estos elementos deberán ser visible en el diagrama solicitado.

 

• El sistema deberá definir y documentar los flujos de datos entre los servidores públicos y el OMS, asegurando que la transferencia se realice mediante canales seguros y controlados, evitando cualquier exposición de información crítica.

 

Lineamientos Funcionales para el desarrollo del sistema OMS.

 

7.2.        Requisitos del GIS

 

• El sistema de Gestión de Interrupciones (OMS) deberá poder importar datos provenientes del sistema GIS de Intergraph y Supermap, actual proveedor de JASEC, garantizando la compatibilidad y actualización correcta de la información geoespacial en la plataforma.

 

• El sistema de Gestión de Interrupciones (OMS) deberá proporcionar un método para importar activos de las redes de distribución desde el GIS, incluyendo el modelo de conectividad, transformadores, medidores en media y baja tensión, ubicaciones de servicios, luminarias y generadores. Para la red de baja tensión, el sistema deberá mostrar la ubicación de los transformadores de distribución y las ubicaciones de servicio mediante una conexión en línea recta entre el transformador y el medidor.

 

• Antes de importar la información del GIS al OMS, el sistema deberá verificar la integridad y consistencia de los datos y generar un informe detallado con los elementos que requieran corrección. Este informe deberá incluir los campos obligatorios faltantes para la importación (por ejemplo, el valor nominal en kVA para transformadores), conductores con longitud cero, conductores superpuestos, conexiones ambiguas, valores de fase incoherentes, bucles (loops) presentes en la red, conexiones faltantes y cualquier inconsistencia en las fases. El informe deberá permitir a JASEC realizar las correcciones en el GIS y ejecutar nuevamente la validación antes de proceder con la importación.

 

• El proveedor deberá garantizar que el sistema permita asignar los campos utilizados en el GIS a los campos requeridos por el OMS, sin que JASEC deba modificar los nombres de campo en su GIS. Además, la herramienta de exportación del GIS deberá permitir a los usuarios dar a los datos el formato requerido por el ADMS, incluyendo la creación de reglas que definan cómo deberán exportarse los datos.

 

• El sistema deberá ofrecer una opción para importar la información GIS de forma incremental, es decir, únicamente los cambios realizados desde la última importación, o bien permitir la importación por distrito, garantizando flexibilidad y eficiencia en la actualización de datos.

 

• El sistema deberá disponer de tareas separadas para la exportación de datos desde el GIS y la importación de transformadores, medidores y ubicaciones de servicio al OMS/ADMS. Todas las tareas deberán poder programarse para ejecutarse en una hora preestablecida, excepto la importación del modelo de conectividad. Además, el sistema deberá contar con una ventana de importación GIS que permita a los usuarios supervisar el estado de las importaciones en tiempo real.

 

• El sistema deberá permitir a JASEC importar datos del GIS que no formen parte de la red de producción (por ejemplo, futuros, propuestos, abandonados, etc.). Estas secciones de línea deberán visualizarse en el OMS con un esquema de colores diferenciado que identifique claramente que no pertenecen al entorno de producción.

 

• El sistema deberá permitir que los datos del GIS se importen inicialmente en un entorno fuera de línea para su verificación completa. Una vez validada la información, el sistema deberá ofrecer la opción de publicar los datos en el entorno de producción en tiempo real, garantizando la integridad y consistencia de la información antes de su uso operativo.

 

• Cuando exista una etiqueta en un punto o un dispositivo temporal en una sección de línea, el sistema no deberá modificar dicha sección durante la importación (es decir, no deberá borrarla, moverla ni cambiar su fase). El usuario deberá resolver el conflicto antes de continuar con la importación. Cualquier importación que no implique modificaciones en estas secciones deberá proceder con normalidad.

 

• El proceso de importación de datos desde el GIS y la validación de la información no deberá afectar el rendimiento ni la disponibilidad del sistema OMS, garantizando que las operaciones críticas continúen funcionando sin interrupciones durante dichas tareas.

 

7.3.        Requisitos CIS

 

• El sistema deberá permitir la importación de información proveniente del CIS del proveedor designado por JASEC hacia el OMS, garantizando la compatibilidad y la correcta integración de los datos para la gestión de interrupciones.

 

• El sistema deberá permitir a JASEC programar la importación de datos del CIS hacia el OMS de forma diaria o bajo demanda (ad hoc), garantizando flexibilidad en la actualización de la información.

 

• El sistema deberá permitir que el OMS lea el nivel de prioridad del cliente directamente desde el CIS, asegurando que esta información se utilice para la gestión y priorización de interrupciones.

 

• El sistema deberá permitir que el OMS lea desde el CIS si un cliente ha sido desconectado (por ejemplo, por morosidad), garantizando que esta información se utilice para la correcta gestión de interrupciones y comunicaciones con el cliente.

 

• El sistema deberá ser capaz de importar desde el CIS los requisitos especiales asociados a un lugar de servicio (por ejemplo, presencia de equipos médicos), asegurando que esta información se utilice para la correcta priorización y gestión de interrupciones.

 

 

7.4.        Integración AMI/AMR/MDM

 

• El sistema deberá ser capaz de integrarse con los sistemas AMI / AMR / MDM y cumplir, como mínimo, con las siguientes funciones:

• Recibir y procesar notificaciones de interrupción del servicio (mensajes de último suspiro).
• Recibir y procesar notificaciones de restauración.
• Recibir y procesar notificaciones de alarma (por ejemplo, manipulación de medidores detectada).
• Realizar pings a medidores, bajo demanda o automáticamente, para verificar el restablecimiento del servicio.
• Ejecutar lecturas de medidores a petición.
• Enviar mensajes de conexión y desconexión a los medidores.

 

• El sistema deberá tener la capacidad de realizar pings a los medidores de forma individual, por transformador o a todos los medidores aguas abajo de una sección de línea, garantizando la verificación eficiente del estado del servicio.

7.5.        Integración de la localización automática de vehículos (AVL)

 

• El sistema deberá tener la capacidad de interconectarse con un sistema AVL para futuras necesidades de JASEC.

 

7.6.          Interfaz gráfica de usuario (GUI) de la sala de control GUI/Navegación

 

El sistema deberá proporcionar a los operadores y despachadores una plataforma capaz de integrar SCADA, OMS y DMS. La interfaz gráfica de usuario deberá estar compuesta por el mapa GIS importado y cualquier otra visualización creada, incluyendo diagramas unifilares y visualizaciones tabulares.

 

• El sistema deberá permitir abrir varias ventanas o pestañas para visualizar diferentes mapas o vistas, garantizando que los operadores y despachadores puedan gestionar simultáneamente múltiples perspectivas de la red.

 

• El sistema deberá permitir utilizar OpenStreetMap como capa base para la visualización geográfica en la interfaz del OMS.

 

• El sistema deberá superponer la red de distribución sobre el mapa y mostrar la red primaria, los interruptores (como fusibles, disyuntores, seccionalizadores), transformadores, la red de baja tensión (medidores de energía), lámparas de alumbrado público y generadores (por ejemplo, paneles solares). Además, el sistema deberá eliminar automáticamente objetos del mapa en función del nivel de zoom configurado por el administrador.

 

• El sistema deberá ofrecer una opción para que, en el caso de los medidores secundarios, se incluya la información del transformador de distribución al que están asociados y permita agruparlos por distancia o por fase para mejorar la visualización.

 

• El sistema deberá disponer de un panel OMS en la interfaz gráfica de usuario que contenga una visualización tabular independiente para:

 

 

• Llamadas entrantes
• Llamadas de interrupción
• Llamadas de servicio
• Llamadas de emergencia
• Casos de interrupción
• Tiquetes de servicio
• Tiquetes de emergencia
• Operaciones
• Cuadrillas
• Trabajos
• Programación de cuadrillas
• Informes de daños
• Visitas de inspección
• Eventos mayores
• Suspensiones programadas

 

 

 

• El sistema deberá permitir que cualquier vista de cualquier visualización tabular pueda guardarse como archivo en formato PDF o CSV, garantizando la exportación de información para análisis y reportes.

 

• El sistema deberá permitir que, al hacer clic en un elemento de cualquiera de las visualizaciones tabulares, el OMS navegue automáticamente hasta dicho elemento en el mapa, garantizando una interacción rápida y eficiente entre las vistas tabulares y geográficas.

 

 

• El sistema deberá permitir que el panel OMS pueda anclarse o desanclarse en la pantalla. Cuando el panel esté desacoplado y el usuario seleccione un elemento en una visualización tabular, el sistema deberá ofrecer la opción de elegir en cuál mapa navegará hasta dicho elemento, en caso de que haya varias ventanas abiertas.

 

• El sistema deberá permitir que, en cada visualización tabular, el usuario pueda filtrar la lista en función de consultas como intervalo de tiempo, cliente, alimentador o zonas afectadas. Además, la visualización tabular deberá poder ordenarse por cualquiera de las columnas.

 

• El sistema deberá permitir que el usuario ajuste el tamaño y el orden de las columnas, así como definir qué columnas se muestran en cada lista tabular. Además, las preferencias de visualización deberán poder guardarse por usuario en cada estación de trabajo.

 

• El sistema deberá permitir que los usuarios muestren u oculten en el mapa los casos de interrupción activos, restaurados y programados. Las interrupciones momentáneas de las últimas 24 horas deberán incluirse junto con las interrupciones restauradas. Además, el sistema deberá permitir definir un color distinto para la zona de interrupción que identifique:

• Interrupciones no verificadas
• Interrupciones verificadas no planeadas
• Interrupciones planeadas y verificadas
• Interrupciones programadas
• Interrupciones restablecidas.

 

• El sistema deberá disponer, en cada área de interrupción, de un icono marcador (tipo pushpin) que muestre información sobre el caso de interrupción y ofrezca la opción de ver más detalles. El sistema deberá permitir especificar una imagen tipo pin diferente para cada uno de los tipos de área de interrupción definidos. Además, junto a la imagen tipo pin deberá visualizarse el número de clientes sin suministro en ese caso de interrupción.

 

• El sistema deberá colocar un icono junto a cualquier dispositivo de interrupción asociado a un caso de interrupción en el mapa, garantizando una identificación visual clara para los operadores.

 

• El sistema deberá mostrar en el mapa todas las llamadas activas por cortes, llamadas de servicio y llamadas de emergencia, garantizando visibilidad en tiempo real para los operadores y despachadores.

 

• El sistema deberá permitir que los usuarios muestren u oculten todos los trabajos en el mapa. Además, deberá ofrecer la posibilidad de utilizar un icono diferente para los distintos estados y tipos de trabajo. El sistema también deberá permitir filtrar para mostrar únicamente determinados estados o tipos de trabajo en el mapa.

 

• El sistema deberá permitir que los usuarios muestren u oculten todos los informes de daños en el mapa, garantizando una visualización flexible y adaptada a las necesidades operativas.

 

• El sistema deberá permitir que, desde el mapa, los usuarios puedan hacer ping a cualquier medidor, a todos los medidores asociados a un transformador o a todos los medidores aguas abajo de una sección de línea, garantizando la verificación eficiente del estado del servicio.

 

• El sistema deberá permitir que, desde cualquier medidor o transformador mostrado en el mapa, los usuarios puedan visualizar una lista de todos los casos de interrupción que hayan afectado a dicho elemento.

 

• El sistema deberá permitir que, desde cualquier medidor mostrado en el mapa, los usuarios puedan visualizar una lista completa del historial de llamadas asociadas a ese cliente.

 

• El sistema deberá permitir que, desde cualquier medidor mostrado en el mapa, los usuarios puedan crear un nuevo registro de llamada con la información del cliente ya diligenciada, garantizando rapidez y precisión en la gestión de llamadas.

 

• El sistema deberá permitir que, desde cualquier interruptor (por ejemplo, fusible, disyuntor, etc.) mostrado en el mapa, el usuario pueda visualizar una lista de todos los casos de interrupción en los que dicho dispositivo haya sido el dispositivo de interrupción.

 

• El sistema deberá permitir que, desde cualquier medidor o lámpara de alumbrado público mostrados en el mapa, los usuarios puedan visualizar una lista de todos los tiquetes de servicio o emergencia asociados a dicho dispositivo.

 

• El sistema deberá permitir que, desde cualquier transformador o dispositivo mostrado en el mapa, los usuarios puedan visualizar una lista completa del historial de visitas de inspección asociadas a dicho dispositivo.

 

• El sistema deberá permitir a los usuarios trazar secciones de líneas energizadas. Estas trazas deberán poder realizarse en forma bidireccional, ascendente o descendente, y pueden ser trazas del alimentador completo o hasta el siguiente dispositivo de protección.

 

• El sistema deberá permitir mantener activas hasta cinco trazas simultáneamente. Además, deberá ofrecer la funcionalidad para realizar trazados en secciones de línea sin tensión.

 

• El sistema deberá permitir que, en cada sección de línea, los usuarios puedan visualizar el recuento de todos los clientes aguas abajo y su información asociada. Además, el administrador deberá tener la opción de incluir el recuento de clientes junto a la sección de línea correspondiente en el mapa.

 

• El sistema deberá permitir que la coloración de la red primaria se cambie dinámicamente, utilizando un esquema de colores fijo (por ejemplo, por nivel de tensión) o dinámico (por ejemplo, por alimentador), garantizando una visualización clara y adaptable a las necesidades operativas.

 

7.7.         Gestión de llamadas

 

7.7.1.    El sistema deberá gestionar los dos tipos de llamadas: llamadas de interrupción y llamadas de incidencia (o no interrupción). Una llamada de interrupción se define como cualquier llamada relacionada con la ausencia de suministro eléctrico al cliente, mientras que una llamada de incidencia corresponde a cualquier comunicación en la que el cliente informe una situación relevante para la compañía eléctrica (por ejemplo, árboles cerca de líneas eléctricas o incendio en un poste). Las llamadas de incidencia deberán poder clasificarse en llamadas de servicio y llamadas de emergencia (que requieren atención inmediata). El sistema deberá utilizar únicamente las llamadas de interrupción para el análisis del alcance de la interrupción.

 

7.7.2.    El sistema deberá permitir la entrada de llamadas de interrupción de suministro a través de múltiples canales, incluyendo: un representante de atención al cliente (CSR), un operador de sala de control/despachador, un servicio de mensajes de texto y un portal de cortes de suministro orientado al cliente.

 

7.7.3.    El sistema deberá permitir que las llamadas sean atendidas tanto por despachadores como por representantes de atención al cliente (CSR). Cada uno deberá disponer de su propia pantalla de entrada de llamadas. La vista para el CSR deberá ser simplificada, con funciones y acciones del OMS limitadas, pero deberá permitir registrar llamadas de clientes y visualizar todas las interrupciones activas.

 

7.7.4.    El sistema deberá permitir que el módulo OMS de recepción de llamadas busque una cuenta introduciendo cualquiera de los siguientes datos: número de teléfono de la persona que llama, número de cuenta (NISE), número de cedula, nombre, dirección, número de medidor.

 

7.7.5.    El sistema deberá permitir que el módulo OMS de recepción de llamadas recupere registros de llamadas anteriores utilizando como criterio de búsqueda el número de referencia, el nombre de la persona que llama o el número telefónico del llamante.

 

7.7.6.    El sistema deberá permitir que el módulo de recepción de llamadas del OMS asocie automáticamente cada registro de llamada a cualquier caso de interrupción activo del que forme parte la persona que llama.

 

7.7.7.    El sistema deberá permitir que el módulo de recepción de llamadas del OMS ofrezca al operador la posibilidad de anular la asignación automática y asignar manualmente las llamadas a los casos de interrupción existentes.

 

7.7.8.    El sistema deberá ser capaz de soportar dos tipos principales de llamadas: llamadas de interrupción y llamadas de incidentes (o no interrupción). Las llamadas de incidentes deberán poder desglosarse en llamadas de servicio y llamadas de emergencia. Una llamada puede pertenecer a más de un tipo (por ejemplo, interrupción y llamada de servicio, o interrupción y llamada de emergencia), y el sistema deberá asignar automáticamente el tipo o los tipos en función de la información introducida por el usuario.

 

7.7.9.    El sistema deberá permitir que, para las llamadas de incidentes, el operador seleccione uno o más problemas comunes desde una lista definida por JASEC. Las incidencias pueden tener asociada una bandera de emergencia o peligro. El sistema deberá convertir automáticamente en llamada de emergencia, cualquier registro que incluya una incidencia con indicador de emergencia. Además, los usuarios deberán poder activar manualmente el indicador de emergencia para convertir un registro de llamada en una llamada de emergencia.

 

7.7.10. El sistema deberá permitir que, para una llamada de incidente, la ubicación pueda establecerse a partir de una ubicación seleccionada en el mapa o número de poste, en lugar de utilizar la ubicación del servicio o el medidor del cliente que realiza la llamada.

 

7.7.11. El sistema deberá añadir automáticamente un prefijo a cualquier comentario incorporado en un registro de llamada, indicando si el comentario ha sido realizado por personal de la sala de control o por un representante de atención al cliente (CSR).

 

7.7.12. El sistema deberá disponer de listas separadas para llamadas de interrupción, llamadas de servicio y llamadas de emergencia. Además, el despachador deberá poder filtrar y ordenar estas listas según sus preferencias.

 

7.7.13. El sistema deberá garantizar que las listas de llamadas de interrupción, servicio y emergencia proporcionen una indicación visual para notificar la existencia de llamadas activas (es decir, casos o tiquetes asociados aún no completados) en la pestaña, sin que el usuario tenga que abrirla. Además, la lista de llamadas de emergencia deberá incluir un indicador visual distintivo (por ejemplo, cambio en el símbolo de la pestaña) para alertar al operador sobre llamadas de emergencia pendientes de despacho y llamadas de emergencia activas.

 

7.7.14. El sistema deberá activar una alarma que notifique al usuario cuando una llamada de emergencia no haya sido asignada a un tiquete dentro de un intervalo de tiempo determinado.

 

7.7.15. El sistema deberá generar una alarma para notificar a los operadores cuando llegue una nueva llamada o evento al OMS que sea externo a la sala de control.

 

7.8.        Gestión de casos

 

7.8.1.    El sistema deberá garantizar que cualquier operación SCADA (evento telemedido o control del operador, ya sea telemedido o manual) cree un caso de interrupción verificado cuando algún cliente resulte afectado, estableciendo el dispositivo operado como la fuente del dispositivo de interrupción. Cualquier operación posterior relacionada con la interrupción, independientemente de si afecta o no a clientes, deberá asociarse automáticamente al caso de interrupción.

• Para cada operación, el sistema deberá registrar el número de clientes perdidos o restablecidos.
• Si una operación afecta a varios casos (por ejemplo, en una situación de interrupción anidada), la operación deberá asociarse a todos los casos involucrados.

7.8.2.    El sistema deberá permitir que, para un caso de interrupción no verificado (normalmente creado por el análisis de llamadas o eventos del OMS), el operador tenga la opción de verificar el caso una vez confirmada la ubicación del dispositivo de interrupción, o establecer el caso como resuelto. Cuando un caso se establece como resuelto, esto deberá indicar que no hubo interrupción desde el lado de JASEC, pero deberá permitir mantener un registro de las acciones realizadas durante la investigación. Los casos resueltos deberán poder archivarse o eliminarse.

 

7.8.3.     El sistema deberá permitir que cada caso de interrupción realice un seguimiento de todos los clientes que hayan llamado en relación con el caso, incluyendo cualquier evento de notificación de interrupción asociado (por ejemplo, notificaciones de último suspiro provenientes de AMI). Las notificaciones de último suspiro solo deberán registrarse en la lista de llamadas cuando hayan sido utilizadas para predecir la ubicación de la interrupción; una vez verificado el caso, las nuevas notificaciones no deberán incluirse en dicha lista. Además, el sistema deberá mantener la capacidad de rastrear el estado AMI de cada medidor y generar una advertencia si un usuario intenta restaurar un caso sin que todos los medidores hayan enviado su mensaje de restauración de energía.

 

7.8.4.    El sistema deberá diferenciar entre interrupciones planificadas y no planificadas, permitiendo al usuario definir un color distinto para la zona de interrupción correspondiente a cada tipo en el mapa.

 

7.8.5.    El sistema deberá permitir que, para las interrupciones planificadas, el despachador incluya una orden de conmutación y una orden de restablecimiento asociadas al caso de interrupción. Si se proporciona una hora de ejecución programada para cada paso de dichas órdenes, el OMS deberá calcular automáticamente los clientes afectados y sus tiempos de interrupción previstos.

 

7.8.6.    El sistema deberá permitir que, si una interrupción planificada se encuentra dentro del tiempo de verificación especificado (definible por el usuario), cualquier operación realizada en el dispositivo de interrupción del caso convierta automáticamente la interrupción planificada en un caso de interrupción verificada activo.

 

7.8.7.    El sistema deberá permitir programar varias interrupciones planificadas para el mismo día, siempre que cada una tenga una hora de inicio única.

 

7.8.8.    El sistema deberá permitir que los usuarios consoliden múltiples casos de interrupción en un único caso consolidado cuando exista la misma causa para todas las interrupciones (por ejemplo, pérdida de suministro). Una vez creado el caso consolidado, el sistema deberá permitir añadir o eliminar casos individuales. En la visualización tabular para operadores, solo deberá mostrarse el caso consolidado, mientras que los casos contribuyentes deberán ser accesibles desde el registro del caso. Para los informes (resumen de interrupción, actas diarias, estadísticas de rendimiento e informes detallados), el sistema deberá ofrecer la opción de mostrar el caso consolidado o los casos contribuyentes.

 

7.8.9.    El sistema deberá realizar un seguimiento del número inicial de clientes sin suministro y de la pérdida inicial de kVA, así como del número actual de clientes sin suministro y de la pérdida actual de kVA. El caso de interrupción deberá incluir a todos los clientes del lado primario y secundario, incluyendo los medidores.

 

7.8.10. El sistema deberá permitir que el usuario establezca un caso en estado de restauración verificada una vez que el número de clientes sin suministro y la pérdida de kVA sean cero. Una vez que el caso se encuentre en restauración verificada, cualquier nueva llamada en el área deberá tratarse como un nuevo corte potencial. Alternativamente, el sistema deberá permitir que el administrador configure que, si el número de clientes sin suministro y la pérdida de kVA se mantienen en cero durante un período predefinido, el caso pase automáticamente a restauración verificada.

 

7.8.11. El sistema deberá registrar el número total de minutos de inactividad del cliente, así como calcular los indicadores DPIR y FPI correspondientes a cada caso de interrupción.

 

7.8.12. El sistema deberá permitir que cada caso de interrupción realice un seguimiento de la duración de la interrupción para cada transformador y cliente afectado. Si un cliente o transformador experimenta varias operaciones de apertura dentro del mismo caso, el sistema deberá mantener un registro independiente para cada operación de apertura.

 

7.8.13. El sistema deberá calcular la gravedad de cada caso de interrupción como una función definida por el usuario, considerando el número de clientes fuera de servicio, el cliente de mayor prioridad implicado, los kVA perdidos y la duración de la interrupción.

 

7.8.14. El sistema deberá establecer la prioridad del caso de interrupción en función del cliente de mayor prioridad implicado en dicho caso. Además, el sistema deberá permitir que el despachador sobrescriba manualmente la prioridad asignada.

 

7.8.15. El sistema deberá permitir que el tiempo de interrupción y el tiempo de restablecimiento de un caso, dispositivo o transformador puedan ser sobrescritos manualmente por un despachador.

 

7.8.16. El sistema deberá permitir asociar a cada caso de interrupción una causa, definida en función de una clasificación predeterminada por el ente regulador, el fallo de un dispositivo y las condiciones meteorológicas. JASEC deberá tener la opción de especificar los parámetros posibles para cada tipo. Además, el sistema deberá permitir que JASEC configure que, para determinados códigos de causa, sea obligatorio especificar el fallo del dispositivo.

 

7.8.17. El sistema deberá ofrecer una opción para impedir que los casos de interrupción se cierren hasta que se haya especificado la causa de la interrupción.

 

7.8.18. El sistema deberá ofrecer una opción para que el usuario incluya un motivo cuando se cancele un caso de interrupción.

 

7.8.19. El sistema deberá ofrecer a JASEC la opción de impedir el cierre de un caso de interrupción hasta que se hayan completado todas las devoluciones de llamada asociadas al caso.

 

7.8.20. El sistema deberá permitir crear y programar trabajos asociados a un caso de interrupción, garantizando la planificación y ejecución eficiente de las actividades necesarias para su resolución.

 

7.8.21. El sistema deberá permitir enviar solicitudes al WMS o MCC para obtener los recursos necesarios para completar un trabajo asociado a un caso de interrupción.

 

7.8.22. El sistema deberá permitir hacer un seguimiento de los materiales utilizados en cada caso de interrupción, garantizando la trazabilidad y control de recursos empleados en la resolución del evento.

 

7.8.23. El sistema deberá generar una lista de medidores que el sistema AMI aún considere fuera de servicio cuando una interrupción se haya restablecido desde el punto de vista de la topología y no todos los medidores hayan enviado un mensaje de restablecimiento. El sistema deberá advertir al despachador antes de permitir marcar el caso como restauración verificada y ofrecer la opción de hacer ping a todos o a un subconjunto de los medidores para comprobar su estado antes del cierre. Además, el sistema deberá permitir realizar un análisis de llamadas/eventos en los medidores que sigan reportando, para identificar la ubicación de una posible interrupción anidada.

 

7.8.24. El sistema deberá proporcionar una función para establecer el Tiempo Estimado de Restauración (ETOR), calculado automáticamente en función de la última hora estimada de finalización de todos los trabajos necesarios para el caso de interrupción. Además, el sistema deberá ofrecer una opción para excluir determinados trabajos de este cálculo.

 

7.8.25. El sistema deberá permitir que los cálculos del Tiempo Estimado de Restauración (ETOR) puedan ser sobrescritos manualmente por el despachador.

 

7.8.26. El sistema deberá permitir que, cuando los despachadores introduzcan el Tiempo Estimado de Restauración (ETOR), exista la opción de redondearlo al intervalo más próximo de 15 minutos, 30 minutos o 1 hora. Alternativamente, el sistema deberá permitir fijar la ETOR en los 15 minutos, 30 minutos o 1 hora siguientes (por ejemplo, si el despachador fija la ETOR en 2:03 y selecciona redondeo a los 15 minutos siguientes, la ETOR se establecerá en 2:15).

 

7.8.27. El sistema deberá permitir mostrar un intervalo de Tiempo Estimado de Restauración (ETOR) a los usuarios en la interfaz gráfica de la sala de control, en las notificaciones internas por correo electrónico y en el Portal Web para clientes, en lugar de una hora exacta (por ejemplo, 2:00 - 3:30 en lugar de 2:45). El administrador deberá poder especificar el intervalo a utilizar y definir valores diferentes para interrupciones planificadas y no planificadas.

 

7.8.28. El sistema deberá permitir que los despachadores puedan modificar rápidamente el Tiempo Estimado de Restauración (ETOR) mediante incrementos definidos por el administrador (por ejemplo, añadir o restar 15 minutos de la hora ETOR actual).

 

7.8.29. El sistema deberá permitir configurar una alarma que notifique a los usuarios cuando el Tiempo Estimado de Restauración (ETOR) se aproxima o se ha superado para un caso de interrupción activo.

 

7.8.30. Adicional al tiempo antes detallado, el sistema deberá proporcionar un espacio, en cada reporte, de inclusión del tiempo requerido para:

• Tiempo de organización
• Tiempo de desplazamiento
• Tiempo de localización de falla
• Tiempo de reparación

 

7.8.31. El sistema deberá soportar la gestión de cortes anidados, permitiendo que los clientes afectados puedan ser extraídos de un corte activo cuando el corte principal haya sido restablecido.

 

7.8.32. El sistema deberá convertir un caso de interrupción en una interrupción momentánea cuando el dispositivo de interrupción se abra (es decir, se dispare) y permanezca cerrado nuevamente dentro de un plazo de tiempo definido por el usuario.

 

7.8.33. El sistema deberá registrar, para cada operación asociada a un caso de interrupción, la hora registrada (momento en que el OMS registró el cambio de estado), la hora SCADA (marca de tiempo recibida desde la RTU) y la hora efectiva, la cual deberá poder ser ajustada manualmente por el operador o despachador. La hora efectiva deberá propagarse a todos los clientes afectados por la operación y utilizarse en todos los cálculos estadísticos y de fiabilidad.

 

7.8.34. El sistema deberá permitir que los despachadores utilicen texto predefinido en cualquiera de los campos aplicables, según lo definido por el administrador del sistema.

 

7.8.35. El sistema deberá permitir que los despachadores publiquen fotos relacionadas con el caso de interrupción, las cuales se compartirán en el Portal Web de Interrupciones.

 

7.8.36. El sistema deberá permitir que los despachadores excluyan los casos de interrupción del servicio de los cálculos de los índices de continuidad y calidad del servicio.

 

7.8.37. El sistema deberá garantizar que los clientes desconectados en la zona de interrupción no afecten el recuento de clientes para los cálculos de continuidad y calidad del servicio, pero sigan apareciendo en la lista de clientes del caso de interrupción, marcados como desconectados.

 

7.8.38. El sistema deberá permitir hacer un seguimiento del tiempo de respuesta de cada caso de interrupción, calculado como el tiempo transcurrido entre el momento en que se produjo la interrupción y el momento en que la primera cuadrilla llegó al lugar. Si no se crearon trabajos para el caso, el despachador deberá tener la opción de establecer manualmente el tiempo de respuesta.
Además, si se define un umbral de tiempo de respuesta aceptable, el sistema deberá calcular el porcentaje de casos que cumplieron dicho umbral para el mes en curso y el mes anterior.

 

7.8.39. El sistema deberá permitir que el despachador proporcione la ubicación del problema en un caso de interrupción (por ejemplo, el lugar donde un árbol cayó sobre una línea y provocó el disparo del disyuntor). El sistema deberá ofrecer la opción de ingresar una descripción, seleccionar una ubicación en el mapa o elegir un dispositivo. Además, deberá existir la opción de configurar este campo como obligatorio para los casos de interrupción.

 

7.8.40. El sistema deberá permitir que, en el registro del caso, el despachador visualice cualquier informe de daños o tiquete de servicio/emergencia asociada al mismo.

 

7.8.41. El sistema deberá permitir que cada caso de interrupción muestre la(s) zona(s) afectada(s), basadas en las subdivisiones y distritos definidos a partir de la información importada desde el GIS.

 

7.8.42. El sistema deberá permitir que cada caso de interrupción muestre el municipio o municipios incluidos, basados en el campo ‘ciudad’ definido a partir de la importación GIS. Además, el campo municipio deberá poder utilizarse como filtro en varios informes del OMS.

 

7.8.43. El sistema no deberá asociar automáticamente un registro de llamada a un caso de interrupción previsto o verificado si el registro de llamada tiene una antigüedad superior a un límite especificado por el usuario.

 

7.8.44. El sistema deberá permitir que el caso de interrupción rastree la orientación (subterránea, aérea o indefinida) de la ubicación del problema cuando se haya especificado un dispositivo para ello. En caso contrario, el sistema deberá utilizar la orientación del dispositivo de interrupción.

 

7.9.        Gestión de Tiquetes

7.9.1.    El sistema deberá permitir crear un tiquete de servicio o emergencia a partir de una llamada de servicio/emergencia, así como crear tiquetes independientes. Además, el sistema deberá permitir especificar si un tiquete de servicio es no planificado o programado.

 

7.9.2.    El sistema deberá permitir que, una vez creado un tiquete de servicio o emergencia, un operario pueda asignar cuadrillas al tiquete para completar el trabajo requerido o enviarlo al MCC.

 

7.9.3.    El sistema deberá permitir hacer un seguimiento de todas las llamadas relacionadas con un tiquete de servicio y de aquellas que requieran una devolución de llamada.”

 

7.9.4.    El sistema deberá permitir que, cuando se cree un tiquete a partir de una llamada, esta se asocie automáticamente al tiquete y que el tiquete herede todas las incidencias y comentarios registrados en la llamada.

 

7.9.5.    El sistema deberá permitir que el operador disponga de una lista de incidencias definidas por el usuario y pueda asociar una o varias incidencias a un tiquete. Cada incidencia deberá contar con dos banderas configurables: peligro y emergencia.

 

7.9.6.    El sistema deberá permitir que un tiquete tenga asociadas hasta doce (12) incidencias.

 

7.9.7.    El sistema deberá permitir que los tiquetes puedan asignarse a casos de interrupción. Si un tiquete está asociado a un caso de interrupción, el sistema deberá ofrecer la opción de requerir que el tiquete se complete antes de iniciar trabajos en el caso de interrupción, especialmente cuando exista un riesgo o peligro potencial que deba ser mitigado previamente.

 

7.9.8.    El sistema deberá permitir hacer un seguimiento del tiempo de respuesta de cada tiquete, calculado como el tiempo transcurrido entre el momento en que se creó el tiquete y el momento en que la primera cuadrilla llegó al lugar (denominado tiempo de organización). Si no se crearon trabajos para el tiquete, el despachador deberá tener la opción de establecer manualmente el tiempo de respuesta.
Además, si se define un umbral de tiempo de respuesta aceptable, el sistema deberá calcular el porcentaje de solicitudes que cumplieron dicho umbral para el mes en curso y el mes anterior. El sistema deberá permitir configurar umbrales distintos para solicitudes de servicio no planificadas, solicitudes programadas y solicitudes de emergencia.

 

7.9.9.    El sistema deberá permitir hacer un seguimiento del material utilizado para completar cada tiquete, garantizando la trazabilidad y control de recursos empleados en la ejecución del trabajo.

 

7.9.10. El sistema deberá permitir que cada tiquete contenga una lista completa de todos los informes de daños asociados al mismo.

 

7.9.11. El sistema deberá permitir que el registro del tiquete rastree si alguna de las personas relacionadas con el tiquete ha solicitado una devolución de llamada una vez que el tiquete ha sido completado.

 

7.9.12. El sistema deberá permitir que una incidencia pueda marcarse como tiquete de seguimiento. Cuando se marque como tiquete de seguimiento, el despachador deberá tener la opción de notificar hasta dos destinatarios por correo electrónico (un destinatario puede ser un buzón de departamento o todo el departamento), indicando quiénes se consideran responsables del tiquete, su prioridad y la fecha de vencimiento. Los destinatarios deberán tener la opción de revisar estos tiquetes y, potencialmente, reasignarlos desde la interfaz gráfica de la sala de control o la aplicación Dashboard.

 

7.9.13. El sistema deberá permitir que, al configurar la prioridad de un tiquete de seguimiento, el administrador especifique el número de días en los que deberá completarse dicho tiquete, utilizando este valor para establecer la fecha de vencimiento. Por defecto, la fecha de vencimiento deberá fijarse según la prioridad, pero el usuario deberá tener la opción de sobrescribirla manualmente.

 

7.9.14. El sistema deberá permitir que el administrador configure el contenido del correo electrónico de notificación que recibirá un destinatario cuando se le asigne un tiquete. Esta configuración deberá incluir la posibilidad de especificar un archivo de plantilla para definir el formato del correo electrónico y determinar qué información se incluirá en el encabezado del asunto y en el cuerpo del mensaje (por ejemplo: número de tiquete, número de caso de interrupción, descripción del tiquete, ubicación, fecha de vencimiento, problemas e incluir comentarios únicamente en el cuerpo del correo electrónico).

 

7.9.15. El sistema deberá permitir que el administrador configure el departamento y el personal perteneciente a cada departamento, incluyendo la posibilidad de especificar el jefe del departamento, un correo electrónico individual para cada miembro y un buzón departamental.

 

7.9.16. El sistema deberá enviar un correo electrónico de escalamiento a los destinatarios originales y al jefe o jefes de departamento cuando un tiquete de seguimiento no se haya completado en la fecha de vencimiento especificada.

 

7.9.17. El sistema deberá permitir establecer una prioridad por defecto para los tiquetes de seguimiento.

 

 

7.10.     Informes de daños y visitas de inspección

7.10.1. El sistema deberá permitir la creación de informes de daños desde la aplicación cliente para manejo de cuadrillas, desde una aplicación móvil o desde la interfaz gráfica de la sala de control, con el fin de identificar cualquier zona problemática en campo.

 

7.10.2. El sistema deberá permitir que, en un informe de daños, el informador incluya:

• Una descripción de los daños.
• La ubicación del daño seleccionada en el mapa.
• Todas las observaciones realizadas sobre los daños, con la opción de elegir observaciones desde una lista predefinida.
• Comentarios adicionales.
• Archivos adjuntos para compartir, como imágenes, videos o documentos (por ejemplo, Word).

 

7.10.3. El sistema deberá permitir que los informes de daños puedan vincularse a un caso de interrupción o a un tiquete de emergencia o servicio.

 

7.10.4. El sistema deberá permitir que, desde la sala de control, un evaluador de daños pueda crear un tiquete directamente a partir de un informe de daños cuando sea necesario realizar trabajos de seguimiento.

 

7.10.5. El sistema deberá permitir que, si es necesario realizar una investigación más detallada, el evaluador de daños pueda crear un recorrido de inspección para que el equipo de campo investigue otras zonas.

 

7.10.6. El sistema deberá permitir que una visita de inspección se cree como un elemento independiente cuando existan inspecciones sobre el terreno que el personal de campo deba realizar (por ejemplo, gestión de activos, mantenimiento rutinario, etc.).

 

7.10.7. El sistema deberá permitir que el evaluador de daños añada sus valoraciones al informe de daños sobre el siguiente curso de acción. Además, el evaluador deberá poder crear un elemento de trabajo detallando las tareas de seguimiento necesarias, para que un despachador cree el trabajo y lo envíe a una cuadrilla, o bien que el propio evaluador de daños pueda crear el trabajo directamente.

 

7.10.8. El sistema deberá permitir que, desde el informe de daños, se visualice un resumen de todos los trabajos asignados al tiquete o caso asociado.

 

7.10.9. El sistema deberá permitir que el informe de daños incluya un campo específico para que el evaluador de daños añada sus comentarios.

 

7.10.10.  El sistema deberá permitir que el evaluador de daños marque en el informe de daños cuando haya finalizado su evaluación.

 

7.10.11.  El sistema deberá permitir que el evaluador de daños marque en el informe de daños si existe dificultad de acceso al lugar, si hay un problema de seguridad o si es necesario controlar el tráfico.

 

7.10.12.  El sistema deberá permitir que, para una visita de inspección, el usuario pueda:

 

• Especificar el nombre de la visita de inspección.
• Definir el objetivo de la visita (seleccionable desde una lista predefinida).
• Asignar una cuadrilla y su vehículo asociado.
• Notificar el trabajo a la cuadrilla.
• Ingresar la descripción de la visita.
• Añadir comentarios adicionales.
• Proporcionar una lista de puntos de chequeo que deberán incluirse en la visita.

Cada punto de chequeo deberá poder corresponder a un elemento de la red de distribución (por ejemplo, conductor, transformador, interruptor) o a un lugar específico para investigar (seleccionado en el mapa con registro de coordenadas GPS).

7.10.13.  El sistema deberá permitir que, para cada ubicación de punto de chequeo en una visita de inspección, se proporcione una lista de instrucciones sobre las acciones a realizar en el lugar (por ejemplo, tomar una fotografía o grabar un video).

 

7.11.     Gestión de eventos Mayores

7.11.1. El sistema deberá permitir que los usuarios pongan todo el sistema en modo ‘Evento Mayor’ o solo una región específica. Cada región deberá admitir un máximo de un evento mayor activo a la vez. El sistema deberá permitir que el usuario establezca la fecha y hora de inicio y finalización del evento mayor; si la hora de finalización queda en blanco, el evento mayor deberá permanecer activo indefinidamente hasta que se defina una.

 

7.11.2. El sistema deberá desactivar todas las tareas de importación programadas cuando se coloque en modo ‘Evento Mayor’.

 

7.11.3. El sistema deberá garantizar que, cuando el OMS se coloque en modo ‘Evento Mayor’, todos los casos de interrupción, tiquetes, informes de daños y cualquier trabajo o material asociado se agreguen automáticamente al registro del evento mayor. Además, cualquier caso de interrupción asociado al evento deberá marcarse automáticamente con el indicador ‘día de suceso grave’ para efectos de notificación.

 

7.11.4. El sistema deberá permitir que el usuario asocie o desasocie manualmente un caso, tiquete o informe de daños a un registro de evento mayor. Si la hora de inicio del evento se especifica después de que este haya comenzado, el sistema deberá ofrecer la opción de reclamar automáticamente todos los casos nuevos ocurridos en ese periodo. Además, deberá existir una opción para anular la reclamación de todos los casos asociados a un evento mayor.

 

7.11.5. El sistema deberá permitir que, para un registro de evento mayor, los despachadores puedan especificar:

• El nombre del acontecimiento principal.
• Una descripción del evento.
• El tipo de incidente, seleccionable desde una lista definida por el usuario.
• La categoría del evento.
• La región afectada por el acontecimiento grave.
• El responsable de la gestión del incidente (incluyendo nombre, número de teléfono y correo electrónico).
• Comentarios adicionales introducidos por el usuario.

7.11.6. El sistema deberá calcular, para cada registro de evento (mayor o menor), al menos los siguientes indicadores:

• Número de transformadores y clientes afectados.
• DPIR y FPI.
• Cantidad de interrupciones sostenidas y momentáneas.
• Número de llamadas de emergencia.
• Número de tiquetes generados.
• Total, de horas/hombre empleadas.
• Costo del material utilizado.
• Número de trabajos realizados.
• Número de cuadrillas utilizadas (propias y externas).
• Alimentadores afectados.
• Cliente de mayor prioridad afectado.
• Incluir listado de indicadores de ARESEP

7.12.     Gestión de cuadrillas

7.12.1. El sistema deberá tener la capacidad de enviar cuadrillas para asignarlas a interrupciones (incluyendo el tipo de cuadrilla e información sobre el equipo), incidentes (tiquetes de servicio/emergencia), informes de daños y visitas de inspección.

 

7.12.2. El sistema deberá permitir que el despachador cree nuevas cuadrillas utilizando las herramientas administrativas y el personal disponible, asegurando que las cuadrillas creadas estén disponibles inmediatamente en el sistema. Al crear una nueva cuadrilla, el usuario deberá poder especificar el tipo de cuadrilla que se está creando.

 

7.12.3. El sistema deberá permitir añadir personal a una cuadrilla, incluyendo su nombre e información de contacto.

 

7.12.4. El sistema deberá permitir asociar un vehículo a cada cuadrilla.

 

7.12.5. El sistema deberá permitir que en una solicitud de trabajo se incluyan documentos justificativos, tales como órdenes de trabajo, órdenes de cambio y autorizaciones.

 

7.12.6. El sistema deberá permitir notificar a una cuadrilla cuando se le ha asignado un nuevo trabajo mediante el envío de un mensaje SMS y/o correo.

 

7.12.7. El sistema deberá ofrecer al usuario la posibilidad de asignar uno o más equipos de forma simultánea y/o secuencial a un caso de interrupción, a un tiquete o a un informe de daños.

 

7.12.8. El sistema deberá permitir que el registro de trabajo haga seguimiento de la progresión del trabajo, registrando marcas de tiempo cuando el personal de campo marque cualquiera de los siguientes estados como completado, o permitiendo que la marca de tiempo se establezca manualmente:

 

• Asignación del trabajo a la cuadrilla.
• Acuse de recibo por parte de la cuadrilla.
• Inicio del desplazamiento hacia el lugar del incidente.
• Llegada al lugar del incidente.
• Finalización de las actividades.
• Cierre del trabajo.
• Cancelación del trabajo (opcional).

 

7.12.9. El sistema deberá ofrecer la opción de exigir que la cuadrilla confirme que ha dejado el lugar de trabajo en condiciones seguras antes de cerrar el trabajo. Además, el sistema deberá permitir registrar qué equipo de campo estaba presente en el lugar cuando se realizó esta confirmación.

 

7.12.10.  El sistema deberá permitir que el registro de trabajo haga un seguimiento de todos los miembros de la cuadrilla que participaron en las actividades, de manera que los usuarios puedan identificar qué miembros estuvieron presentes en la ejecución del trabajo.

 

7.12.11.  El sistema deberá permitir que las cuadrillas solo puedan asignarse a un trabajo cuando estén disponibles. El sistema deberá ofrecer la opción de asociar un horario a la cuadrilla para especificar su disponibilidad, o permitir que esta se establezca manualmente.

 

7.12.12.  El sistema deberá permitir que la ubicación del trabajo se establezca en el mapa.

 

7.12.13.  El sistema deberá permitir que el usuario especifique la hora prevista de inicio y finalización del trabajo asignado a una cuadrilla. Una vez fijada la hora de inicio, la hora prevista de finalización deberá calcularse automáticamente en función de la duración estimada asociada al tipo de trabajo. Además, el sistema deberá permitir que el despachador incluya en la duración total del trabajo el tiempo de viaje, el tiempo de preparación, el tiempo de espera y el tiempo de pausa.

 

7.12.14.  El sistema deberá permitir definir hasta tres duraciones estimadas diferentes por tipo de trabajo: diurno, nocturno o bajo circunstancias atenuantes.

 

7.12.15.  El sistema deberá permitir que las duraciones estimadas de los tipos de trabajo se calculen a partir de los datos históricos de trabajos realizados. Las duraciones estimadas deberán poder establecerse como el mínimo, el máximo o la media de los datos históricos. El sistema deberá ofrecer una opción para excluir trabajos de estos cálculos. Las duraciones actualizadas se convertirán en las duraciones por defecto para los nuevos trabajos.

 

7.12.16.  El sistema deberá generar una alarma si el trabajo no se ha completado en el plazo previsto. Además, deberá permitir configurar una tolerancia adicional al tiempo de finalización previsto antes de activar la alarma.

 

7.12.17.  El sistema deberá permitir que se añadan archivos adjuntos a un trabajo tanto desde la sala de control como por el personal de campo.

 

7.12.18.  El sistema deberá permitir que, si un trabajo es urgente, esta condición se indique claramente en la descripción del trabajo.

 

7.12.19.  El sistema deberá permitir que el despachador visualice todos los trabajos asociados a un caso de interrupción, tiquete, informe de daños, recorrido de inspección o por cuadrilla dentro del registro respectivo. Además, el sistema deberá disponer de una lista global de trabajos en el panel OMS para mostrar todos los trabajos actualmente registrados en el sistema.

 

7.12.20.  El sistema deberá disponer de un cronograma tipo Gantt para identificar rápidamente la programación de las cuadrillas. Los despachadores deberán poder visualizar el progreso actual de los trabajos y ajustarlos directamente desde el calendario (acortar o alargar la duración del trabajo, mover el trabajo a una hora distinta o asignarlo a otra cuadrilla). El cronograma deberá permitir aplicar filtros según las necesidades del usuario, incluyendo: tipo de trabajo, estado del trabajo, tipo de cuadrilla, tipo de vehículo, y la opción de incluir o excluir trabajos no asignados o trabajos sin horas programadas.

 

7.12.21.  El sistema deberá permitir que cada trabajo incluya un campo de comentarios separado para los despachadores y otro para el personal de campo.

 

7.12.22.  El sistema deberá permitir que, para cada trabajo, el despachador pueda visualizar la distancia de la cuadrilla asignada al trabajo cuando la funcionalidad AVL esté disponible.

 

7.12.23.  El sistema deberá permitir que los puestos de trabajo puedan modelarse a partir del último puesto creado.

 

7.13.     Operaciones

7.13.1. El sistema deberá proporcionar a operadores y despachadores una lista tabular global de todas las operaciones asociadas a casos de interrupción. Esta lista deberá mostrar, como mínimo, la siguiente información:

• Datos del dispositivo.
• Fecha y hora en que se produjo la operación.
• Usuario que realizó la operación.
• Número de clientes afectados por la operación.
• Caso de interrupción asociado.
• Comentarios relacionados con la operación.

 

7.13.2. El sistema deberá permitir que los usuarios filtren la lista tabular global de operaciones por tiempo o por caso de interrupción, y que puedan ordenar la lista por cualquiera de las columnas disponibles.

 

7.13.3. El sistema deberá proporcionar a operadores y despachadores una lista tabular global de todas las operaciones asociadas a casos de interrupción.

 

7.13.4. El sistema deberá permitir que los usuarios actualicen los comentarios de una o varias operaciones directamente desde la lista tabular global de operaciones.

 

 

 

 

7.14.     Sistema

 

7.14.1. El sistema deberá permitir que el dispositivo de interrupción de un caso pueda ser cualquier dispositivo de la red de distribución primaria, desde el transformador de subtransmisión hasta un transformador de distribución, incluyendo dispositivos temporales. Asimismo, el sistema deberá admitir casos de interrupción asociados a uno o varios medidores en la red secundaria.

 

7.14.2. El sistema deberá permitir que, para un transformador de distribución bifásico o trifásico, el usuario especifique qué fases se pierden (fase coincidente, ninguna fase o todas las fases) cuando se produzca una pérdida parcial de fase, en función de la configuración del transformador (por ejemplo, Y-Y, D-Y, etc.).

 

7.14.3. El sistema deberá crear automáticamente un caso de interrupción momentánea cuando los dispositivos de interrupción se disparen y se cierren (permaneciendo cerrados) dentro del intervalo definido por el usuario para este tipo de interrupción. Esta funcionalidad deberá aplicarse únicamente a eventos telemedidos. La diferencia entre interrupciones sostenidas y momentáneas será utilizada para fines informativos (por ejemplo, cálculo de FPI frente a FIM). Además, el sistema deberá permitir que el caso de interrupción realice un seguimiento del recuento de parpadeos, es decir, el número de veces que el dispositivo de interrupción se abrió y cerró durante el transcurso del caso.

 

7.14.4. El sistema deberá permitir realizar un seguimiento de los clientes afectados por una interrupción, tanto aquellos conectados a la red de distribución en el lado primario (media tensión) como en el lado secundario (baja tensión).

 

7.14.5. El sistema deberá registrar en el registro de auditoría todos los eventos importantes de un caso de interrupción, incluyendo: creación del caso, verificación del caso, restauración verificada, cierre del caso, archivado, cancelación y eliminación.

 

7.14.6. El sistema deberá permitir que el administrador importe una lista de medidores programados para estar fuera de servicio (por ejemplo, por mantenimiento o reparaciones planificadas). Si el OMS recibe una notificación de último suspiro de un medidor que está en esta lista, la notificación deberá ser ignorada y no tratarse como una llamada de interrupción.

 

7.15.     Archivo

7.15.1. El sistema deberá permitir que el operador archive los casos de interrupción cerrados. Al archivar un caso, el sistema deberá archivar también todos los datos asociados relacionados con el caso, incluyendo el registro de operaciones, transformadores/clientes afectados, llamadas, trabajos, tiquetes y demás información vinculada.

 

7.15.2. El sistema deberá implementar dos niveles de archivo:

 

·   Archivo a corto plazo, almacenado en la base de datos en línea durante un período aproximado de dos años.

·   Archivo a largo plazo, almacenado indefinidamente en una base de datos SQL Server.

·   El sistema deberá permitir que los usuarios especifiquen qué nivel de archivo desean utilizar para mostrar la información en la lista tabular del OMS en la interfaz gráfica de la sala de control (por ejemplo, casos de interrupción).

 

7.15.3. El sistema deberá permitir que, para un caso archivado, los usuarios puedan modificar la causa, la causa del fallo del dispositivo, la causa meteorológica, la exclusión de las estadísticas y el indicador de día de evento mayor. Estas modificaciones solo deberán realizarse en casos archivados a corto plazo, pero cualquier cambio efectuado deberá propagarse automáticamente al archivo a largo plazo.

 

7.15.4. El sistema deberá permitir que el operador archive las solicitudes cerradas. Al archivar un tiquete, el sistema deberá archivar también todos los datos asociados relacionados con el caso, incluyendo trabajos, materiales, llamadas, cuadrillas asignadas y demás información vinculada.

 

7.15.5. El sistema deberá impedir que se archiven casos o tiquetes de interrupción abiertos; primero deberán cerrarse. Además, el sistema deberá permitir que el usuario seleccione varios casos de interrupción para archivarlos de manera simultánea.

 

7.15.6. El sistema deberá garantizar que los casos y tiquetes archivados sean fácilmente accesibles. Los usuarios deberán poder buscar casos o tiquetes en función de su estado (activos, archivados o ambos) y abrirlos para visualizar todos sus datos.

 

7.16.     Registro de auditoría

 

7.16.1. El sistema deberá permitir realizar un seguimiento de todas las ediciones y acciones efectuadas en el OMS, registrándolas en una base de datos SQL, independientemente de si fueron realizadas por un usuario desde la sala de control, a través de una aplicación web del OMS o mediante una aplicación externa como un sistema de gestión de personal.

 

7.16.2. El sistema deberá permitir que, para cada registro modificado, el registro de auditoría realice un seguimiento en la base de datos de: la hora en que se realizó la modificación, el usuario que la ejecutó (incluyendo nombre y función), la acción realizada (añadir, modificar o eliminar), los objetos del OMS afectados (llamada, caso, tiquete, trabajo, material, cuadrilla, informe de daños o evento mayor) y el detalle de lo que se modificó.

 

 

7.17.     Análisis de llamadas y eventos

 

7.17.1. El sistema deberá permitir que la función de análisis de llamadas/eventos agrupe automáticamente las llamadas (CSR, AMI, web, IVR, TCS y texto) en un punto común utilizando un modelo dinámico de conectividad eléctrica, empleando las fases del modelo para la predicción de fases y la localización de las llamadas. El análisis deberá predecir el dispositivo de interrupción para casos no verificados, y el despachador o el personal de campo deberán confirmar que se trata del dispositivo correcto.

 

7.17.2. El sistema deberá permitir que el usuario especifique el número mínimo de dispositivos aguas abajo que deberán considerarse como dispositivos de interrupción antes de que las interrupciones se agrupen en un caso mayor, utilizando el dispositivo de línea aguas arriba como origen de la interrupción.

 

7.17.3. El sistema deberá permitir que la función de análisis de llamadas/eventos tenga un límite definible por el usuario para la antigüedad máxima de una llamada o evento que se utilizará en el análisis.

 

7.17.4. El sistema deberá garantizar que la función de análisis de llamadas/eventos se base en todos los cambios del modelo, incluyendo cortes y puentes (por fase), así como la apertura o cierre de dispositivos (por fase).

 

7.17.5. El sistema deberá permitir que la función de análisis de llamadas/eventos ofrezca al operador la opción de desplazar la predicción aguas arriba respecto a la predicción actual, o establecer manualmente el dispositivo que considere como origen de la interrupción. Una vez que el despachador o el personal de campo confirmen la ubicación del dispositivo de interrupción, el sistema deberá permitir verificar la interrupción.

 

7.17.6. El sistema no deberá requerir la función de análisis de llamadas/eventos para un evento SCADA/DMS, ya que el caso de interrupción deberá verificarse automáticamente y todos los registros de llamadas afectados por este caso deberán asociarse automáticamente a él.

 

7.17.7. El sistema deberá garantizar que el motor de análisis de llamadas/eventos no considere ningún dispositivo telemedido como origen de una interrupción, a menos que la telemetría haya fallado o que el punto haya sido establecido manualmente por el operador.

 

7.17.8. El sistema deberá permitir que la función de análisis de llamadas/eventos tenga la opción de predecir únicamente dispositivos de protección como origen de una interrupción. Los dispositivos de protección deberán poder definirse durante la importación del GIS.

 

7.17.9. El sistema deberá permitir que la función de análisis de llamadas/eventos se ejecute bajo demanda o automáticamente cuando se alcance un umbral de llamadas definido por el usuario. El umbral deberá especificar el número de llamadas o eventos de interrupción de servicio recibidos que no estén vinculados a un caso existente antes de activar la predicción de interrupción. Una vez alcanzado el umbral, la predicción deberá activarse con cada nueva llamada/evento, pero ejecutarse como máximo una vez cada cinco (5) minutos.

 

7.17.10.  El sistema deberá garantizar que el análisis automatizado de llamadas/eventos active una alarma en el sistema SCADA para informar al operador sobre la ubicación propuesta de una interrupción en cuanto se actualice o se cree un caso previsto de interrupción.

 

7.17.11.  El sistema deberá soportar el análisis automático de ping después de que se produzca un evento de interrupción (por ejemplo, registro de llamada, AMI, entrada en el portal de interrupciones). medidores definidos, determinar el alcance de la interrupción creando primero una lista de todos los dispositivos protegidos en el alimentador donde se originó el evento y realizando un ping aleatorio a un número de medidores definido por el usuario por debajo de cada dispositivo protegido. Si un medidor no responde al ping, el sistema deberá generar un nuevo evento para dicho medidor.

·         El sistema deberá permitir ampliar esta funcionalidad para proponer casos de interrupción del servicio una vez que se cumpla un número predefinido de eventos no asignados.

·         El sistema deberá permitir ampliar esta funcionalidad para que los casos propuestos se verifiquen automáticamente y, una vez verificados, se envíen al portal de interrupciones sin intervención del operador.

 

7.17.12.  El sistema deberá ofrecer una opción para no predecir interrupciones a nivel de transformador cuando el único tipo de llamadas provenga de AMI.

 

7.17.13.  El sistema deberá ofrecer una opción para que, si un caso previsto es más antiguo que un límite especificado por el usuario, las nuevas llamadas en esa zona de interrupción no se asocien automáticamente a dicho caso.

 

7.17.14.  El sistema deberá permitir que los usuarios tengan la opción de ‘congelar’ los casos de interrupción previstos. Cuando un caso esté congelado, las llamadas asociadas a dicho caso no deberán utilizarse para ningún análisis futuro hasta que el caso se ‘descongele’. Además, el sistema deberá permitir que el administrador configure que, una vez asignado un trabajo a un caso de interrupción previsto, este se congele automáticamente.

 

7.17.15.  El sistema deberá ofrecer la capacidad de realizar un análisis de los medidores que continúan reportando energía apagada una vez que se ha restablecido por completo un caso de interrupción. Basándose en estos medidores, el sistema deberá poder predecir el dispositivo de interrupción de una posible interrupción anidada. El operador o el personal de campo deberán confirmar que se trata efectivamente de una interrupción anidada.

 

7.18.     Operaciones

7.18.1. El sistema deberá permitir aplicar condiciones temporales en la red, tales como puentes, puestas a tierra, cortes, fuentes o interruptores. Además, deberá mantener una lista separada de estos cambios temporales, accesible fácilmente por el operador.

 

7.18.2. El sistema deberá permitir aplicar etiquetas a los dispositivos. Estas etiquetas pueden ser informativas o restrictivas, de manera que impidan que el dispositivo siga funcionando hasta que la etiqueta sea retirada.

 

7.18.3. El sistema deberá soportar la gestión de autorizaciones o permisos de trabajo, asegurando que estas puedan ser creadas, asociadas y controladas dentro del flujo operativo del OMS.

 

7.18.4. El sistema deberá admitir órdenes de conmutación, entendidas como una secuencia de acciones que incluye tanto operaciones de conmutación como aplicación de etiquetas. Cada orden de conmutación deberá poder contener al menos 200 pasos. El sistema deberá permitir añadir una orden de conmutación y una orden de restablecimiento a un caso de interrupción programada, y deberá analizar las operaciones para determinar los clientes y KVA´s que se verían afectados.

 

7.18.5. El sistema deberá permitir la aplicación de notas que puedan vincularse a un interruptor, transformador, medidor o colocarse como un icono en el mapa. Si existe una nota en un dispositivo, el sistema deberá generar algún tipo de notificación para alertar al operador.

 

7.18.6. El sistema deberá permitir realizar un seguimiento de todas las acciones del usuario con una marca de tiempo en un registro resumido del operador. Este registro deberá poder filtrarse para mostrar únicamente la información necesaria.

 

7.18.7. El sistema deberá permitir aplicar un filtro ‘antiruidos’ a cualquier punto del sistema que presente cambios excesivos en periodos muy cortos. Si un punto cambia de estado más de X veces en Y minutos (valores definidos por el usuario), el OMS no deberá registrar estas operaciones como parte de las operaciones del caso de interrupción.

 

7.19.     Indicadores clave de rendimiento (KPI) e informes de OMS

 

7.19.1.  Indicadores clave de rendimiento

El sistema deberá ofrecer la opción de almacenar los siguientes KPI en un punto, permitiendo que estos se muestren en la interfaz gráfica del operador (como valor, gráfico, etc.), se almacenen en conjuntos de datos históricos y se utilicen en informes. Los KPI que el sistema deberá soportar incluyen:

1. Número total de clientes.
2. Número total de clientes fuera de servicio, desglosado por cortes planificados y no planificados.
3. Número total de clientes restablecidos.
4. Número de clientes prioritarios fuera de servicio.
5. Número total de medidores inteligentes, medidores inteligentes que informan interrupción y medidores inteligentes en línea.
6. Número de alimentadores con interrupción.
7. Número de transformadores con interrupción.
8. Total, de kVA perdidos.
9. Número de interrupciones activas.
10. Número total de interrupciones sostenidas (hoy, ayer, este mes, mes pasado, este año, año pasado).
11. Número total de interrupciones momentáneas (hoy, ayer, este mes, mes pasado, este año, año pasado).
12. Número total de llamadas de interrupción (por hora, día, mes, año).
13. Número total de llamadas de incidentes/servicio (por hora, día, mes, año).
14. Número total de llamadas de emergencia (por hora, día, mes, año).
15. Número total de tiquetes de servicio (hoy, ayer, mes, año).
16. Número total de tiquetes de emergencia (hoy, ayer, mes, año).
17. Número total de accesos al portal web de interrupciones (por hora, día, mes, año).
18. Número total de llamadas de urgencia no atendidas.
19. Número total de llamadas de emergencia enviadas.
20. Número total de llamadas de interrupción en los últimos 60 minutos, desglosadas por fuente (sala de control, IVR, TCS, web, CSR).
21. Número de cuadrillas asignadas.
22. Porcentaje de casos de interrupción que cumplieron el umbral de tiempo de respuesta (este mes y mes pasado).
23. Porcentaje de tiquetes de emergencia que cumplieron el umbral de tiempo de respuesta (este mes y mes pasado).
24. Resultados DPIR (ayer, mes, año).
25. Resultados FPI (ayer, mes, año).
26. Resultados FMIK (ayer, mes, año).
27. Resultados TTIK (ayer, mes, año).
28. Resultados FIM (ayer, mes, año).
29. Resultados FIP (ayer, mes, año).
30. Resultados FIT (ayer, mes, año).
31. Resultados DAI (ayer, mes, año).
32. Resultados FI (ayer, mes, año).

Los KPI están disponibles para todo el sistema o para cada región.

Los operadores y despachadores dispondrán de una visualización tabular de los KPI en su interfaz gráfica de usuario. Tendrán la opción de ver los KPI por sistema, región o municipio.

 

 

7.19.2.  Informes

7.19.2.1. El sistema deberá disponer de diez informes principales:

• Informe de caso de interrupción.
• Resumen de interrupciones.
• Índices de calidad y continuidad establecidos por la normativa regulatoria.
• Cliente por alimentador (resumido o detallado).
• Informe de tiquetes.
• Detalles de eventos de interrupción.
• Estadísticas de rendimiento de interrupciones.
• Minutos de cliente de interrupción diaria.
• Informes de tiempo de respuesta.
• Informe personalizado solicitado por la administración

 

Estos informes deberán poder personalizarse mediante filtros de selección, criterios de visualización y filtros de resaltado aplicados. Además, el sistema deberá permitir guardar la configuración personalizada de un informe para su reutilización en ejecuciones posteriores.

 

• El sistema deberá permitir que los usuarios guarden los informes en formato PDF o CSV.
• El sistema deberá ofrecer una opción para mostrar los minutos del cliente, así como los indicadores FPI, en minutos u horas según la preferencia del usuario.

 

• El sistema deberá permitir que los informes puedan programarse para su ejecución automática o ejecutarse bajo demanda (ad hoc), según las necesidades del usuario.

 

• El sistema deberá permitir que los informes predefinidos se visualicen desde la interfaz gráfica de la sala de control y, opcionalmente, en la aplicación Cuadro de Mandos. En esta última, los informes que los usuarios pueden visualizar dependerán de sus derechos de usuario. Además, el sistema deberá permitir configurar si los informes visibles en el Cuadro de Mandos pueden ser accesibles para todos los usuarios o únicamente para aquellos con privilegios.

 

7.20.     Índices de calidad y continuidad de servicio

• El sistema deberá proporcionar informes de índices de continuidad y calidad de servicio que incluyan los indicadores del sistema. Además, en los informes de calidad de servicio, el sistema deberá permitir añadir la métrica ASAI (Índice de Disponibilidad Media del Servicio) y clasificarla en rangos configurables por el usuario para identificar áreas problemáticas, por ejemplo:

• Bueno: ASAI > X
• Regular: X > ASAI > Y
• Malo: ASAI < Z.”**
  • El sistema deberá generar informes de índice de calidad y continuidad estándar basados en la norma regulación nacional para los periodos de tiempo definidos por el usuario y en tiempo real. Estos informes deberán poder ejecutarse para todo el sistema o por alimentador, con periodicidad anual o mensual, e incluir como mínimo los siguientes indicadores: DPIR, FPI, FMIK, TTIK, FIM, FIP, FIT, DAI y FI

 

• El sistema deberá garantizar que los informes estándar del OMS calculen los índices de fiabilidad tanto incluyendo como excluyendo los cortes por pérdida de suministro.

 

• El sistema deberá ofrecer una opción para excluir de los cálculos de los índices de fiabilidad las ubicaciones de servicio que no tengan un número de medidor definido o que tengan un medidor sin un cliente asociado.

 

7.21.     Informes de casos y resúmenes de incidencias

• El sistema deberá proporcionar informes de caso de interrupción y de resumen de interrupción que incluyan todos los casos según los filtros de selección, criterios de visualización y filtros de resaltado aplicados. El informe de resumen deberá mostrar una descripción en una sola línea del caso, mientras que el informe detallado deberá ofrecer información completa del caso de interrupción.

 

 

7.22.     Informes de clientes por alimentador (resumidos o detallados)

• El sistema deberá proporcionar un informe detallado de clientes por alimentador que incluya información completa de todos los clientes en los alimentadores seleccionados, como mínimo: nombre, número de medidor, número de cuenta, número de teléfono, dirección, fase, transformador y nivel de prioridad.

 

• El sistema deberá proporcionar informes de resumen de clientes por alimentador que incluyan el recuento de clientes (desglosado por fase y clientes críticos), el número de transformadores y el total de kVA de los alimentadores seleccionados. Además, los informes deberán permitir filtrarse por región, estación y/o subestación.

 

• El sistema deberá ofrecer una opción para generar informes tanto para la red construida como para la red en funcionamiento.

 

 

7.23.     Informe detallado de incidencias

 

• El sistema deberá proporcionar un informe detallado de incidentes de interrupción que incluya un desglose de todas las operaciones que causaron pérdida de suministro eléctrico y sus correspondientes operaciones de restablecimiento, para una zona y un periodo de tiempo determinados. Cada fila del informe deberá contener:

 

· Hora de inicio del caso de interrupción.

· Marca de tiempo de la operación.

· Nombre del dispositivo.

· Número de clientes perdidos o restablecidos.

· Duración de la interrupción.

· Minutos (u horas) de los clientes afectados por el paso.

· Causa del evento.

· Fallo del dispositivo.

· Alimentador y Zona Geográfica.

 

Si se requieren múltiples pasos para restaurar todos los clientes afectados por una operación, esta deberá aparecer en varias filas mostrando todos los pasos de restablecimiento asociados.

 

• El sistema deberá permitir especificar un intervalo de tiempo para la generación del informe, pudiendo ser absoluto (fechas exactas) o relativo (por ejemplo, últimas 24 horas, última semana, último mes).

 

7.24.     Informe diario de minutos de interrupción

• El sistema deberá proporcionar un informe de minutos de cliente de cortes diarios que muestre un resumen de los cortes para el área y el periodo de tiempo especificados. Para cada día, el informe deberá incluir:

• El número de cortes sostenidos activos ese día.
• El número total de clientes afectados por todos los cortes activos de ese día.
• El número total de minutos (u horas) de clientes afectados por todos los cortes sostenidos de ese día.

 

• El sistema deberá permitir que los informes puedan filtrarse por región o Zona Geográfica.

 

• El sistema deberá permitir especificar un intervalo de tiempo para la generación del informe, pudiendo ser absoluto (fechas exactas) o relativo (por ejemplo, últimas 24 horas, última semana, último mes).

 

• El sistema deberá permitir especificar un intervalo de tiempo para la generación del informe, pudiendo ser definido en términos absolutos (fechas concretas) o relativos (por ejemplo, últimos 7 días, último mes)

 

7.25.     Informe estadístico sobre el rendimiento de las interrupciones

• El sistema deberá generar un informe de estadísticas de rendimiento de paradas que muestre el tiempo de respuesta para los casos y/o tiquetes de interrupciones. Para cada evento, el informe deberá permitir visualizar la hora de inicio del evento, el momento en que se envió el trabajo y cuándo llegó la cuadrilla al lugar. Además, deberá indicar el rendimiento de cada incidencia: si la cuadrilla llegó dentro del tiempo de respuesta aceptable o si hubo retraso. Si la cuadrilla aún no ha llegado, el informe deberá actualizarse según el estado actual (en ruta, asignada o no asignada). El informe deberá incluir datos adicionales como número de trabajo, tiempo de respuesta, tiempo de viaje, información de la cuadrilla (nombre y miembros), causa o problema del incidente (si aplica), ETOR (si aplica), región y Zona Geográfica.

 

• El sistema deberá permitir filtrar el informe para mostrar cualquier combinación de casos de interrupción, tiquetes de servicio y tiquetes de emergencia.

 

• El sistema deberá permitir especificar un intervalo de tiempo para el informe, pudiendo ser definido en términos absolutos (fechas concretas) o relativos (por ejemplo, últimos 7 días, último mes).

 

7.26.     Informe de Tiquetes

• El sistema deberá generar un informe que incluya todos los tiquetes según los filtros de selección, criterios de visualización y filtros de resaltado aplicados.

 

 

7.27.     Informe sobre el tiempo de respuesta

• El sistema deberá generar el informe ‘Minutos diarios de cliente por interrupción’, mostrando un resumen de los tiempos de respuesta de las fallas y tiquetes de emergencia según los criterios de búsqueda definidos. El informe deberá permitir visualizar el estado del caso o tiquete de emergencia, el tiempo de respuesta, el número de llamadas relacionadas con el evento, el estado de la respuesta y el número de veces que se ha modificado la ETOR (Tiempo estimado de restablecimiento).

7.28.     Calculadora de índices de fiabilidad

• El sistema deberá disponer de una calculadora de índices de continuidad y calidad ad hoc que permita a los operadores y despachadores calcular rápidamente los índices de continuidad y calidad sobre la marcha.

 

• El sistema deberá poner la calculadora a disposición de los operadores y despachadores como parte de la interfaz gráfica de usuario del OMS.

 

• El sistema deberá permitir al usuario personalizar la calculadora, incluyendo las siguientes opciones:

• Intervalo de tiempo.
• Incluir/excluir días de grandes acontecimientos o calcular solo esos días.
• Incluir/excluir la pérdida de suministro o calcular únicamente la pérdida de suministro.
• Cálculo para todos los circuitos, un circuito o desglose de circuitos.
• Cálculo para todo el sistema (con opción de desglose por alimentador), un alimentador o transformador específico.
• Calcular para todas las causas (con opción de desglose por causa) o una causa específica, incluyendo la opción de incluir/excluir causas relacionadas con la pérdida de suministro o calcular solo en base a dichas causas.
  • El sistema deberá permitir incluir en el informe los siguientes índices y estadísticas de continuidad y calidad:
• DPIR, FPI, FMIK, TTIK, FIM, FIP, FIT, DAI y FI
• Minutos del cliente
• Clientes por fuera de servicio
• Alimentador
• Interrupciones
• Clientes Totales
• Clientes momentáneos
• Interrupciones momentáneas.
  • El sistema deberá permitir que los resultados de la Calculadora de Índices de continuidad y calidad se guarden en un archivo CSV.

 

7.29.     Notificaciones

• El sistema deberá ser capaz de notificar a los clientes el estado de las interrupciones planificadas mediante mensajes o correo electrónico.

 

• El sistema deberá permitir la creación de un archivo CSV para cada caso de interrupción planificada, que incluya los clientes afectados, sus datos de contacto y los tiempos de salida y restablecimiento. Este archivo deberá poder remitirse al departamento de comunicación para las notificaciones a los clientes.

 

• El sistema deberá proporcionar métodos para contactar electrónicamente a los clientes con actualizaciones sobre el estado de la interrupción (creación del caso, restablecimiento del caso o actualización del ETOR) mediante IVR, correo electrónico o mensaje. Además, el sistema deberá permitir que los clientes envíen reportes de cortes a través de IVR o mensajería.

 

• El sistema deberá permitir a los usuarios proporcionar mensajes personalizados para cada interrupción en el Portal de Incidencias del cliente, mediante un campo denominado “Mensaje para el público”.

 

• El sistema deberá generar una alarma cada vez que se cree un registro de llamada externa (proveniente de CSR Web Client, IVR/TCS, AMI o portal de cortes) para notificar al operador.

 

7.30.     Devoluciones de llamada

• El sistema deberá permitir especificar en el registro de llamadas si la persona que llama ha solicitado una devolución de llamada. Además, deberá poder importar la preferencia de devolución de llamada del cliente desde el CIS.

 

• El sistema deberá disponer de un módulo de devolución de llamada para gestionar las solicitudes de clientes que han sido restablecidos. Este módulo deberá contener una lista dinámica de los clientes restablecidos que solicitaron devolución de llamada. Además, el operador o el CSR deberán poder completar la devolución de llamada y marcarla como completada en el registro de llamadas.

 

 

7.31.     Notificaciones internas por correo electrónico

• El sistema deberá disponer de una aplicación de notificación por correo electrónico que permita informar a todas las partes interesadas, tanto internas como externas a la empresa, sobre cualquier cambio significativo en un caso de interrupción en el que dichas partes estén involucradas.

 

• El sistema deberá permitir desactivar temporalmente las notificaciones por correo electrónico en todo el sistema.

 

• El sistema deberá permitir la creación de grupos de destinatarios para notificaciones por correo electrónico, de manera que todos los usuarios asociados a un grupo reciban las mismas notificaciones. Para cada grupo, el administrador del sistema deberá poder:

Especificar el número mínimo de clientes afectados por un caso de interrupción para que el grupo reciba la notificación. Configurar los eventos que dispararán el envío de correos electrónicos, incluyendo:

• Creación de un caso de interrupción previsto o cambio en el dispositivo de interrupción.
• Verificación de un caso de interrupción imprevista.
• Verificación de un caso de interrupción planificada.
• Actualización del ETOR.
• Actualización del código de la causa.
• Actualización del estado de los trabajos.
• Verificación del restablecimiento del caso de interrupción.
• Cancelación de un caso de interrupción.
• Corte momentáneo.
  • El sistema deberá permitir añadir un formato de archivo para los correos electrónicos, de manera que cada grupo de destinatarios cumpla con las políticas de formato de correo electrónico establecidas por JASEC.

 

• El sistema deberá permitir que el administrador incluya en el asunto del correo electrónico información relevante, la cual puede variar según se trate de interrupciones planificadas o no planificadas. El contenido configurable deberá incluir:

• Tipo de interrupción.
• Zona(s) afectada(s).
•  
• Número inicial de clientes afectados.
• Clientes que permanecen sin servicio.
• Hora de inicio de la interrupción.
• Clientes críticos afectados
• Estado del caso
• Estado de los trabajos
• Código de causa interna
• Texto de la causa de cara al público
• Dispositivo de interrupción
• Tiempo estimado de restauración (ETOR)
• Tiempo real de restauración
• Enlace al caso de interrupción en el Portal Web de Interrupciones
• Notas del despachador
• Mensaje al público
• Lista de calles principales

 

• El sistema deberá permitir que, para un individuo dentro de un grupo de destinatarios, el administrador anule las condiciones bajo las cuales recibe un correo electrónico, basándose en:

 

• El número de clientes afectados en un caso de interrupción.
• El número de calles principales afectadas.

 

7.32.     Notificaciones a los clientes

• El sistema deberá permitir la integración con un servicio de mensajería para informar a los clientes sobre los cortes de servicio.

 

• El sistema deberá ofrecer la opción de enviar notificaciones a todos los clientes o, alternativamente, establecer la preferencia de notificación a partir de la información importada desde el SIA.

 

• El sistema deberá permitir que las notificaciones se envíen automáticamente a los clientes o, alternativamente, que el despachador confirme manualmente el envío cuando exista una notificación pendiente.

 

• El sistema deberá permitir especificar un retardo en el envío de notificaciones a los clientes, pudiendo configurar diferentes retardos para las notificaciones de cortes activos y para las notificaciones de cortes previstos.

 

• El sistema deberá permitir que el administrador especifique los eventos que pueden desencadenar una notificación al cliente, incluyendo:

 

• Creación de un caso de interrupción previsto o cambio en el dispositivo de interrupción.
• Verificación de un caso de interrupción imprevista.
• Verificación de un caso de interrupción planificada.
• Actualización del ETOR.
• Actualización del código de la causa.
• Actualización del estado de los trabajos.
• Verificación del restablecimiento del caso de interrupción.
• Cancelación de un caso de interrupción.
• Corte momentáneo.
  • El sistema deberá permitir que el administrador incluya en la mensajería información relevante, la cual puede variar según se trate de interrupciones planificadas o no planificadas. El contenido configurable deberá incluir:

 

• Tipo de interrupción.
• Zona(s) afectada(s).
• Número inicial de clientes afectados.
• Clientes que siguen fuera de servicio.
• Hora de inicio de la interrupción.
• Estado del caso.
• Estado de los trabajos.
• Código de causa público (con opción de valor por defecto si no se especifica la causa).
• Tiempo estimado de restauración (ETOR).
• Tiempo real de restauración.
• Enlace al caso de interrupción en el Portal Web de Interrupciones.
• Mensaje al público.
• Dirección del lugar de servicio.

 

• El sistema deberá permitir que el administrador especifique el formato del contenido de los mensajes, asegurando que se ajuste a las políticas y requerimientos definidos por la organización.

 

• El sistema deberá permitir que los operadores notifiquen a los clientes sobre los cortes previstos en su zona.

 

7.33.     Aplicaciones web del OMS.

 

• El sistema deberá proporcionar aplicaciones web para las partes interesadas externas a la sala de control (tanto internas como externas), que les permitan visualizar e interactuar con los datos del OMS según sus necesidades.

 

• El sistema deberá garantizar que todas las aplicaciones web del OMS no interactúen directamente con el OMS. En su lugar, el OMS deberá replicar de forma segura los datos necesarios en una base de datos SQL, desde la cual las aplicaciones web podrán leer y escribir la información correspondiente. Para atender este tema el contratista deberá suministrar el licenciamiento y equipo requerido.

 

• El sistema deberá admitir una aplicación web basada en navegador para los representantes de atención al cliente (CSR), diseñada para facilitar la recepción de llamadas y la visualización de los cortes actuales, sin requerir que los CSR se entrenen en todo el paquete de software OMS.

 

• Para permitir el acceso a la aplicación el método de autenticación deberá ser: usuario y contraseña con validación en el Active Directory y con doble factor de autenticación (Google authenticator, Microsoft authenticator y/o outhpoint).

 

• Según los derechos asociados a la cuenta del usuario, el sistema deberá permitir:

• Ejecutar comandos de Ping a medidores.
• Borrar registros de llamadas creados desde el cliente web del CSR.
• Ver los usuarios conectados.

 

• El sistema deberá garantizar que el cliente web del CSR admita conexiones seguras mediante el protocolo HTTPS.

 

• El sistema deberá garantizar que el Cliente Web CSR soporte la misma funcionalidad que las características definidas en el Módulo de Gestión de Llamadas Internas

 

• El sistema deberá permitir que el CSR visualice, dentro del registro de llamadas, si el servicio de la persona que llama está desconectado y cuál es el estado actual del medidor AMI en la ubicación de servicio del cliente.

 

• El sistema deberá permitir que, en función de los derechos de usuario, el CSR pueda ejecutar un comando de ping a un medidor para verificar el estado actual del cliente, siempre que la funcionalidad dependa de la integración con AMI.

 

• El sistema deberá permitir que el CSR Web Client ofrezca la opción de elegir la tecnología cartográfica de fondo entre Google, Bing u OpenStreetMap. En este mapa se deberán superponer las zonas de interrupción y la ubicación de todas las personas que llaman, para que los CSR puedan visualizar fácilmente dónde se encuentran las interrupciones actuales y si la persona que llama está afectada. Además, el administrador deberá poder decidir qué tecnología de mapa de fondo se utilizará.

 

• El sistema deberá permitir que, en el mapa del CSR Web Client, los usuarios tengan la opción de visualizar:

• Cortes activos o programados.
•  
•  
• Tiquetes de servicio.
• Tiquetes de emergencia.
• Vehículos.
• Red de distribución (incluyendo tramos de línea de la red primaria, transformadores y medidores).
  • El sistema deberá permitir que, para la red primaria, el usuario especifique colores que identifiquen cuándo las secciones de línea están energizadas o desenergizadas.

 

• El sistema deberá permitir que, para los medidores y transformadores, el usuario especifique colores y símbolos que identifiquen la fase de los transformadores y medidores, así como su estado (energizado o desenergizado).

 

• El sistema deberá permitir que el contorno del área de servicio de JASEC se visualice en el mapa del CSR Web Client.

 

• El sistema deberá ofrecer una opción global para que los cortes momentáneos permanezcan visibles en el mapa durante un número de minutos definido por el usuario después de producirse, con el fin de que los CSR estén al tanto de estos eventos.

 

• El sistema deberá permitir que todas las llamadas de la lista actual del CSR se muestren opcionalmente en el mapa, para que el CSR pueda visualizar el patrón actual de llamadas.

 

• El sistema deberá permitir que los CSR visualicen una lista de todas las llamadas actuales relacionadas con cortes y no cortes en el sistema (excluyendo los informes de apagado del sistema AMI). Las llamadas archivadas no deberán mostrarse en esta lista. Además, el CSR deberá poder filtrar la lista por:

 

• Nombre del cliente.
• Intervalo de tiempo.
• Caso de interrupción.
•  
• Origen de la llamada.
• Solicitud de devolución de llamada por parte del cliente.

 

• El sistema deberá permitir que, al seleccionar un registro de llamada en la lista, el mapa navegue automáticamente hasta la ubicación de la persona que llama.

 

• El sistema deberá permitir que, dentro del registro de llamadas de un cliente, el CSR consulte tanto el historial de llamadas como el historial de cortes asociados al cliente.

 

• El sistema deberá permitir que, para una llamada que no esté relacionada con una interrupción, el CSR especifique la ubicación de la llamada como:
• La ubicación de servicio de un cliente.
• Una luminaria
• Cualquier ubicación en el mapa (registrando automáticamente las coordenadas GPS).
• El sistema deberá garantizar que, una vez registrada, una llamada de interrupción se asocie automáticamente a un caso de interrupción activo o previsto al que esté conectada, según la conectividad de la red.

 

• El sistema deberá garantizar que las zonas de interrupción trazadas en el mapa se marquen con un símbolo tipo pin visible en todos los niveles de zoom. Al hacer clic en el pin, el CSR deberá poder visualizar la siguiente información del caso de interrupción:

 

• Número de asunto.
• Tipo de caso.
• Hora de inicio del caso de interrupción.
• Descripción del caso de interrupción.
• Número de clientes afectados y número de clientes que permanecen sin servicio.
• Código de causa de la interrupción.
• Estado del caso.
• Estado de los trabajos.
• Tiempo estimado de restauración.
• Notas del despachador.
• Mensaje para el público.
• Lista de todos los trabajos actuales asociados al caso y su estado, con opción para ver la ubicación de estos trabajos en el mapa.
• Hora de la última actualización del caso.
  • El sistema deberá permitir que, al hacer clic en un tiquete de servicio o emergencia en el mapa, se muestre la siguiente información:

 

• Número de tiquete.
• Estado del tiquete.
• Problemas relacionados con el tiquete.
• Lista de todos los trabajos actuales asociados al caso y su estado, con opción para ver la ubicación de estos trabajos en el mapa.
• Hora de la última actualización del tiquete.

 

7.34.     Portal web de interrupciones

• El sistema deberá proporcionar un portal cartográfico orientado al cliente final que muestre geográficamente todos los cortes de suministro conocidos. Cada interrupción deberá visualizarse en el mapa resaltando su zona afectada.

 

• El sistema deberá permitir que el Portal Web de Interrupciones se configure para utilizar como tecnología cartográfica subyacente Google Maps, Bing Maps u OpenStreetMap.

 

• El sistema deberá garantizar que el Portal Web de Interrupciones ofrezca opciones estándar de navegación por el mapa, incluyendo panorámica, zoom y búsqueda por dirección. Además, el administrador deberá poder establecer el nivel mínimo de zoom permitido.

 

• El sistema deberá permitir que el formato de fecha y hora utilizado en el Portal Web de Interrupciones sea definido por JASEC, asegurando la personalización según sus políticas y estándares.

 

• El sistema deberá garantizar que el Portal Web de Interrupciones soporte conexiones seguras mediante el protocolo HTTPS.

 

• El sistema deberá permitir que el Portal Web de Interrupciones soporte alta disponibilidad mediante la implementación de un equilibrador de carga de red.

 

• El sistema deberá permitir que las zonas de servicio de JASEC se delineen en el mapa y que el área de servicio pueda sombrearse para facilitar su identificación visual.

 

• El sistema deberá permitir que las áreas de servicio admitan definiciones opcionales de Región (provincia, cantón o distrito). Según el tipo de área seleccionada por el usuario, el cliente deberá poder filtrar los datos del Portal de Incidencias para mostrar únicamente los de su área. Al seleccionar un área, el Portal de Incidencias deberá:

• Navegar hasta los límites definidos del área seleccionada.
• Actualizar las listas para mostrar solo las interrupciones de la zona especificada.
• Actualizar las estadísticas resumidas para reflejar los recuentos del área seleccionada.
  • El sistema deberá permitir que JASEC especifique el número mínimo de clientes afectados por un caso de interrupción para que este se muestre en el mapa. El valor predeterminado deberá ser uno.

 

• El sistema deberá permitir que el Portal Web de Interrupciones que muestre los medidores afectados por una interrupción. En estos casos, únicamente se deberá mostrar un símbolo tipo pin con la ubicación aproximada de la interrupción.

 

• El sistema deberá permitir que el Portal Web de Interrupciones ofrezca la opción de seleccionar colores para las áreas de interrupción según el estado del caso, incluyendo:

 

• No verificada.
• Planificada verificada.
• No planificada verificada.
•  

 

• El sistema deberá permitir que JASEC seleccione los casos de interrupción no verificados en el Portal Web de Interrupciones.

 

• El sistema deberá permitir que JASEC personalice el banner ubicado en la parte superior del Portal Web de Interrupciones.

 

• El sistema deberá permitir que el Portal Web de Interrupciones proporcione información básica sobre el estado de las interrupciones, incluyendo:

 

• Número de caso.
• Tipo de interrupción.
• Hora de inicio de la interrupción.
• Número de clientes afectados.
• Hora prevista de restablecimiento.
•  
• Estado de los trabajos.
• Mensaje para el público.

 

Estos datos deberán estar disponibles al hacer clic en la imagen tipo pin asociada al caso de interrupción. Además, el usuario deberá tener la opción de ocultar cualquiera de estos campos y especificar la etiqueta que se utilizará para cada uno.

• El sistema deberá permitir que el usuario especifique el texto alternativo que se mostrará cuando no haya información disponible para los campos de causa, hora estimada de restablecimiento y mensaje para el público. Para el mensaje al público, el sistema deberá permitir definir mensajes predeterminados independientes según el estado del caso (activo o restaurado), si es planificado o no planificado, o si se trata de una interrupción momentánea.

 

• El sistema deberá permitir incluir fotos para cada caso de interrupción en el Portal Web de Interrupciones. Las fotos deberán estar disponibles al hacer clic en la imagen tipo pin asociada a la interrupción.

 

• El sistema deberá permitir que el campo de causa admita una asignación pública, de manera que, si se define, se utilice en lugar del código de causa interno.

 

• El sistema deberá permitir que los usuarios especifiquen un intervalo ETOR opcional para su publicación en el Portal de Incidencias.

 

• El sistema deberá permitir definir un conjunto alternativo de imágenes tipo pin para representar cuándo la cuadrilla está in situ en el Portal Web de Interrupciones.

 

• El sistema deberá permitir configurar un límite de zoom en el Portal de Incidencias para controlar el nivel de detalle visible en el área de interrupciones cuando se utilice Google Maps.

 

• El sistema deberá permitir que la información sobre los cortes de suministro se muestre en el Portal de Incidencias tanto en un mapa geográfico como en formato tabular. La visualización tabular deberá contener la misma información que la imagen tipo pin asociada a la interrupción. Además, al seleccionar una incidencia en la vista tabular, el usuario deberá poder navegar automáticamente hasta el caso correspondiente en el mapa.

 

• El sistema deberá garantizar que el Portal Web de Interrupciones se actualice dinámicamente en función de las incidencias nuevas, actualizadas o restauradas, con una frecuencia mínima de una vez por minuto. Además, el usuario deberá poder definir la frecuencia de actualización según sus necesidades.

 

• El sistema deberá enviar automáticamente los cortes de suministro al Portal Web de Interrupciones en un intervalo especificado por el usuario, sin necesidad de intervención del operador. Además, el sistema deberá ofrecer al operador/despachador la opción de no publicar un caso de interrupción en el portal. Si el caso ya está publicado, deberá eliminarse en la siguiente actualización.

 

• El sistema deberá ofrecer una opción para que los cortes restaurados permanezcan visibles en el mapa durante un intervalo definido por el usuario. Además, deberá permitir especificar intervalos diferentes para interrupciones planificadas y no planificadas.

 

• El sistema deberá permitir que el Portal Web de Interrupciones ofrezca a los clientes la opción de enviar informes de incidencias a través del portal. Estos envíos deberán ser tratados por el OMS como una llamada de interrupción y utilizados para el análisis de llamadas y eventos.

 

JASEC podrá personalizar una declaración de privacidad que se incluirá en la página de notificación de interrupciones.

 

• El sistema deberá permitir que el Portal Web de Interrupciones incluya una página opcional que muestre todas las interrupciones planificadas para el futuro.

 

• El sistema deberá permitir que el Portal Web de Interrupciones incluya una página opcional que muestre todas las incidencias ocurridas en las últimas 24 horas, incluyendo casos activos, momentáneos y restaurados.

 

• El sistema deberá permitir que, para cada página de cortes (Actual, Programado y Últimas 24 horas), se muestre opcionalmente un bloque de estadísticas que incluya:

 

 

• Número total de cortes.
• Número de clientes afectados.
• Número de clientes afectados que permanecen sin suministro eléctrico.

 

• El sistema deberá permitir que el Portal Web de Interrupciones incluya una página opcional de preguntas frecuentes (FAQ). Esta página deberá poder vincularse a una URL proporcionada por el administrador o personalizarse mediante el editor del Portal Web de Interrupciones.

 

• El sistema deberá garantizar que el Portal Web de Interrupciones, como servidor orientado al cliente, no interactúe directamente con el servidor OMS. En su lugar, deberá implementar un mecanismo seguro para interactuar con el servidor ADMS, utilizando protocolos cifrados y autenticación robusta para proteger la integridad y confidencialidad de los datos.

 

• El sistema deberá notificar al usuario cuando se pierda la comunicación con el Portal Web de Interrupciones. Además, cuando el portal restablezca la conexión con el OMS, deberá sincronizar automáticamente los datos perdidos para garantizar la actualización completa de la información.

 

7.35.     Cuadro de mandos (Dashboard)

• El sistema deberá ofrecer dos tipos de cuadros de mando según el público objetivo:

 

·         Un cuadro de mando en modo vestíbulo (Lobby) para proporcionar una visión general de alto nivel sobre la situación de las interrupciones.

·         Un cuadro de mando para móvil/escritorio, que permita a los usuarios mayor flexibilidad para decidir qué información mostrar.

 

• Modo vestíbulo (Lobby)
  • El sistema deberá proporcionar un cuadro de mando en modo vestíbulo (Lobby) de solo visualización, que ofrezca una perspectiva general de alto nivel sobre la información de interrupciones. Esta visualización deberá incluir:

 

·     Un mapa de cortes de suministro de gran tamaño.

·     Una sección configurable con indicadores clave de rendimiento (KPI).

·     Gráficos, cuadros y tablas relacionados.

 

El modo vestíbulo deberá funcionar como una vista pasiva de los datos del OMS y no requerir ninguna interacción por parte del usuario.

 

• El sistema deberá permitir que el mapa del cuadro de mando en modo vestíbulo utilice la tecnología cartográfica base seleccionada por el usuario (Google Maps, Bing Maps u OpenStreetMap). Además, los usuarios deberán tener la opción de visualizar en el mapa:

·  Cortes activos.

·   Cortes programados.

·   Cortes restaurados.

·   Trabajos.

·    Vehículos.

 

• El sistema deberá permitir que el usuario defina los colores que se utilizarán para las áreas de interrupción según el estado del caso, incluyendo:

 

·    Interrupción no verificada.

·    Interrupción no planificada verificada.

·    Interrupción planificada verificada.

·    Interrupción programada.

·    Interrupción restaurada.

 

Además, el portal deberá mostrar una leyenda que indique el significado de cada color para los diferentes tipos de interrupciones.

• El sistema deberá permitir que el área de servicio de JASEC se incluya y se visualice en el mapa.

 

• El sistema deberá ofrecer una opción para que el mapa rote automáticamente entre todas las interrupciones activas en un intervalo definido por el usuario. Cuando el cuadro de mando se desplace a un caso de interrupción, deberá abrirse automáticamente el cuadro de diálogo del pin de interrupción mostrando:

·    Número de caso.

·    Tipo de caso.

·    Hora de inicio del caso.

·    Número de clientes afectados y clientes que siguen sin suministro.

·    Causa.

·    Estado.

·    Hora estimada de restablecimiento.

·    Mensaje para el público.

Además, el sistema deberá permitir que el usuario detenga la rotación automática en cualquier momento para interactuar con el cuadro de mando y realizar su propia navegación en el mapa.

• El sistema deberá permitir que el usuario ordene y active o desactive los indicadores clave de rendimiento (KPI) que se mostrarán en el cuadro de mandos, incluyendo

 

·    Número total de clientes fuera de servicio (incluyendo cuántos clientes de alta prioridad y no planificados están fuera de servicio) y restablecidos.

·    Estado actual del AMI (medidores totales, clientes fuera, clientes dentro).

·    Número de alimentadores y transformadores averiados y total de KVA perdidos.

·    Número de llamadas hoy, ayer, esta hora y la última hora.

·    Número de llamadas de emergencia no atendidas y despachadas.

·    Número total de interrupciones hoy, ayer, este mes y el mes pasado.

·    Porcentaje de respuesta a tiempo para casos de interrupción y tiquetes de emergencia (este mes y el mes pasado).

·    Número de accesos al Portal Web de Interrupciones esta hora, la última hora, hoy y ayer.

 

• Los gráficos de barras mostrarán el número de clientes que se han quedado sin servicio y se han restablecido, así como el número de llamadas por cortes de suministro en las últimas 24 horas (desglosadas en intervalos de una hora).

 

• El sistema deberá permitir que los gráficos de barras muestren:

 

· El número de clientes que se han quedado sin servicio y los que han sido restablecidos.

· El número de llamadas por cortes de suministro en las últimas 24 horas, desglosadas en intervalos de una hora.

 

• El sistema deberá proporcionar una tabla que muestre los índices de calidad y continuidad solicitados por ARESEP para los siguientes períodos:

 

·  Ayer.

·Este mes.

·El mes pasado.

·Este año.

·  Años registrados en el sistema

 

• El sistema deberá permitir que la cabecera del cuadro de mando en modo vestíbulo (Lobby) sea personalizable, incluyendo la posibilidad de agregar el logotipo de JASEC (respetando el libro de marcas de JASEC) y texto personalizado.

 

• Modo de visualización

 

7.35.3.1.     Sistema deberá permitir que la aplicación de cuadros de mando de OMS en modo móvil o de escritorio se personalice para mostrar información relevante sobre OMS a las partes interesadas internas de JASEC, accesible desde ordenadores de escritorio, portátiles, tabletas o dispositivos móviles.

7.35.3.2.   El sistema deberá requerir autenticación y autorización del usuario para acceder al cuadro de mandos móvil/escritorio de OMS. La autenticación deberá ser por usuario y contraseña con validación en el Active Directory y con doble factor de autenticación (Google authenticator, Microsoft authenticator y/o outhpoint). Según los derechos asociados a la cuenta del usuario, el sistema deberá permitir:

· Fijar el tiempo estimado de restablecimiento de un caso de interrupción.

· Actualizar el mensaje para el campo público de un caso de interrupción.

· Ver los informes no privilegiados configurados para el cuadro de mando.

· Ver todos los informes configurados (privilegiados y no privilegiados).

· Acceder a la calculadora de fiabilidad.

· Acceder a los datos de los clientes en caso de interrupción.

· Ver todos los tiquetes.

· Editar todos los tiquetes.

· Editar tiquetes asignados al usuario.

· Editar tiquetes asignados al departamento del usuario.

· Acceder a los datos de una región o de todas las regiones, si la regionalización está activada.

 

7.35.3.3.     El sistema deberá garantizar que el cuadro de mandos móvil/escritorio de OMS admita conexiones seguras mediante el protocolo HTTPS.

7.35.3.4.     El sistema deberá proporcionar páginas separadas dentro del cuadro de mandos móvil/escritorio para:

• El mapa de cortes.
• Los indicadores clave de rendimiento (KPI).
• Los gráficos.
• Una tabla con los casos de cortes.

 

7.35.3.5.     El sistema deberá permitir que el administrador configure la tecnología de mapas base utilizada en el cuadro de mando del vestíbulo, pudiendo elegir entre Google Maps, Bing Maps u OpenStreetMap. Además, los usuarios deberán tener la opción de visualizar en el mapa:

• Cortes activos.
• Cortes programados.
• Cortes restablecidos.
• Puestos de trabajo.
• Vehículos.
• Red de distribución (incluyendo tramos de línea de la red primaria, transformadores y medidores).

 

7.35.3.6.     El sistema deberá permitir que, para la red primaria, el usuario especifique colores que identifiquen cuándo las secciones de línea están:

•  
•  
• Parcialmente energizadas.

7.35.3.7.     El sistema deberá permitir que, para los medidores y transformadores, el usuario especifique colores y símbolos que identifiquen la fase de los transformadores y medidores, así como su estado (energizado o desenergizado).

7.35.3.8.     El sistema deberá permitir que los clientes de alta prioridad dentro de casos de interrupción activos se visualicen en el mapa. Además, el administrador deberá poder especificar la prioridad mínima para que un cliente sea considerado de alta prioridad.

7.35.3.9.     El sistema deberá permitir que, en la página de indicadores clave de rendimiento del cuadro de mandos, el usuario pueda ordenar y activar o desactivar los siguientes KPI:

• Número total de clientes y número total de clientes fuera (incluyendo cuántos clientes de alta prioridad y no planificados/previstos están fuera) y restaurados.
• Estado actual del AMI (medidores totales, clientes fuera de servicio, clientes con servicio).
• Número de alimentadores y transformadores averiados y total de KVA perdidos.
• Número de llamadas hoy, ayer, esta hora y la última hora.
• Número de llamadas de emergencia hoy, ayer, esta hora y la última hora.
• Número de llamadas de emergencia no atendidas y despachadas.
• Número total de interrupciones hoy, ayer, este mes y el mes pasado.
• Porcentaje de respuesta a tiempo para casos de interrupción y tiquetes de emergencia (este mes y el mes pasado).
• Número de accesos al Portal Web de Interrupciones (esta hora, última hora, hoy y ayer).
• Número de casos de interrupción momentánea creados (hoy, ayer, este mes y el mes pasado).
• Número de representantes de atención al cliente (RAC) y personal de campo de guardia.

 

7.35.3.10.   El sistema deberá permitir que, en la página de gráficos del cuadro de mandos, los usuarios puedan visualizar:

• Gráficos de barras que muestren el número de clientes que se quedaron sin servicio y los que fueron restablecidos, así como el número de llamadas por cortes en las últimas 24 horas, desglosadas en intervalos de una hora.
• Un gráfico circular que desglosa todas las llamadas de interrupción de servicio de la última hora por tipo.
• Una tabla que muestre los índices de fiabilidad definidos por ARESEP para los períodos: ayer, este mes, el mes pasado, este año y años registrados en el sistema.

 

7.35.3.11.   El sistema deberá permitir que, en la página de casos de interrupción del cuadro de mandos, el usuario visualice una lista de todos los casos de interrupción, con listas separadas para casos activos, no verificados, programados y restaurados. Para cada caso, se deberá mostrar como mínimo la siguiente información:

• Número de clientes afectados y que permanecen fuera.
• Dispositivo de interrupción del caso.
• Hora de inicio del caso.
• Estado de los trabajos.
• Tiempo estimado de restauración.
• Tipo de interrupción.
• Prioridad del caso.
• Descripción del caso.
•  
• Alimentador afectado.
• Mensaje para el público.
• Notas relacionadas con el caso.
• Tiempo de respuesta del caso.
• Indicadores solicitados por ARESEP.
• Información de contacto de todos los clientes afectados.
• Detalles sobre todos los trabajos asociados al caso.

 

7.35.3.12.   El sistema deberá permitir que, en función de los derechos de usuario, los usuarios puedan actualizar la hora estimada de restablecimiento (ETOR) o el mensaje para el público asociado a un caso de interrupción.

7.35.3.13.   El sistema deberá permitir que los usuarios realicen búsquedas en el mapa utilizando los siguientes criterios:

• Localización del servicio, mediante los campos: nombre, dirección, número de teléfono, número de abonado o número de medidor del cliente.
• Transformador, utilizando el campo nombre.

 

7.35.3.14.   El sistema deberá permitir que, sujeto a los derechos de usuario, el personal de con derechos de visualización utilice el panel de control para ver y gestionar los tiquetes de seguimiento. Además, el sistema deberá ofrecer la opción de filtrar la lista de tiquetes por:

• Estado del tiquete (seguimiento, servicio o emergencia).
• Tipo de tiquete (abierto, cerrado, cancelado, todos).
• Causa del caso de interrupción asociado al tiquete (si aplica).
• Solicitudes asignadas al tiquete de seguimiento.
• Por cantón o distrito.

 

7.35.3.15.   El sistema deberá permitir que, en función de los derechos de usuario, los usuarios puedan actualizar el estado del tiquete, agregar comentarios, asignar nuevas cuadrillas para reenviar el tiquete o modificar la fecha de vencimiento.

7.35.3.16.   El sistema deberá permitir que los usuarios visualicen la pantalla del vestíbulo (Lobby) dentro del modo móvil/escritorio del cuadro de mandos, ofreciendo la misma funcionalidad de vista general de alto nivel que en el modo vestíbulo.

7.35.3.17.   El sistema deberá permitir que los usuarios visualicen todos los informes preconstruidos que estén disponibles para ellos, en función de los derechos de usuario asignados.

7.35.3.18.   El sistema deberá permitir que los usuarios ejecuten los informes preconstruidos tal como están configurados o, alternativamente, modificar parámetros del informe, incluyendo:

• El intervalo de tiempo del período del informe (en términos absolutos o relativos).
• El área del informe (distritos o cantones, subestación, alimentador y circuito).
• La opción de generar el informe sobre la red tal como está construida o tal como está operativa.

 

7.35.3.19.   El sistema deberá permitir que los usuarios, en función de sus derechos, creen sus propias consultas para la Calculadora de Índices de calidad y continuidad solicitados por ARESEP directamente desde la aplicación del cuadro de mandos.

 

7.36.     Cliente móvil de la cuadrilla (MCC)

• El sistema deberá extender la funcionalidad del OMS a dispositivos móviles, como ordenadores portátiles y tabletas, para permitir su uso por parte del personal de campo.

 

• El sistema deberá requerir autenticación y autorización del usuario para acceder a cualquier dato en el MCC. La autenticación deberá ser por usuario y contraseña con validación en el Active Directory y con doble factor de autenticación (Google authenticator, Microsoft authenticator y/o outhpoint). Según los derechos de usuario asociados a su cuenta, el sistema deberá permitir:

• Editar casos de interrupción, incluyendo el desplazamiento de la ubicación de la interrupción aguas arriba.
• Verificar casos de interrupción previstos.
• Confirmar el restablecimiento de la interrupción.
• Fijar el tiempo estimado de restablecimiento (ETOR).
• Añadir trabajos.
• Editar trabajos.
• Ejecutar comandos de ping a medidores.
• Ajustar manualmente para abrir dispositivos no telemedidos.
• Ajustar manualmente para cerrar dispositivos no telemedidos.
• Añadir/editar informes de daños.
• Vincular informes de daños.
• Añadir/editar tiquetes.
  • El sistema deberá garantizar que el MCC admita conexiones seguras mediante el protocolo HTTPS.

 

• El sistema deberá permitir que el administrador elija la tecnología de mapa base utilizada en el MCC entre Bing, Google u OpenStreetMap. Además, los usuarios deberán tener la opción de visualizar en el mapa:

 

 

· Cortes activos.

· Cortes programados.

· Cortes restaurados.

· Trabajos.

· Vehículos.

· Red de distribución (incluyendo secciones de línea de la red primaria, dispositivos de conmutación telemedidos y no telemedidos, transformadores y medidores).

 

El administrador deberá poder configurar estas capas para que aparezcan o desaparezcan automáticamente según el nivel de zoom. Para los interruptores, el usuario deberá tener la opción de activar o desactivar toda la capa o hacerlo por subtipos.

 

• El sistema deberá garantizar que todas las comunicaciones entre el MCC y el OMS estén cifradas, asegurando la confidencialidad e integridad de los datos transmitidos.

 

• El sistema deberá garantizar que el MCC reciba actualizaciones casi en tiempo real desde el OMS a través de un canal de comunicación seguro, para asegurar que el personal de campo pueda visualizar el estado actual de la red.

 

 

• El sistema deberá permitir que, dentro del MCC, se muestre una lista tabular separada para casos de interrupción, trabajos, tiquetes de servicio, tiquetes de emergencia e informes de daños. Además, al hacer clic en cualquier elemento de la tabla, el sistema deberá navegar automáticamente hasta la ubicación correspondiente en el mapa.

 

• El sistema deberá permitir que el MCC indique al usuario cuando el número de tiquetes de emergencia haya aumentado, sin que el usuario tenga que acceder manualmente a la lista de tiquetes de emergencia.

 

• El sistema deberá permitir que cada pestaña del MCC pueda filtrarse por los siguientes campos:

 

• Casos de interrupción: Causas, personal asignado y estado del caso.
• Tiquetes: Cuadrilla asignada y estado del trabajo.
• Trabajos: Cuadrilla asignada y estado del trabajo.

 

• El sistema deberá permitir que la cuadrilla de campo ordene su lista de trabajos por los siguientes criterios:

 

• Hora de inicio programada.
• Número de registro de trabajo.
• Tipo de trabajo.
• Si el trabajo está asociado a un caso o tiquete.
• Cuadrilla asignada al trabajo.

 

La clasificación deberá poder realizarse en orden ascendente o descendente.

 

• El sistema deberá permitir que el personal de campo busque en el mapa las siguientes entidades:

 

• Ubicaciones de servicios.
•  
•  
•  

 

• El sistema deberá permitir que las cuadrillas visualicen los trabajos que se les asignen, mostrando como mínimo los siguientes detalles:

• Ubicación del elemento de trabajo.
• Descripción del elemento de trabajo.
• Comentarios del despachador o de la cuadrilla de campo.
• Cuadrilla asignada.
• Hora programada de inicio y parada.
• Estado actual del trabajo.
• Número de orden de trabajo.

 

• El sistema deberá permitir que las cuadrillas, dentro del MCC y en función de sus derechos de usuario, actualicen el trabajo y el caso de interrupción en el que están trabajando. Como mínimo, deberán poder:

 

• Actualizar la hora estimada de restauración (ETOR).
• Actualizar el estado actual del trabajo.
• Proporcionar comentarios visibles para el resto del equipo.

 

• El sistema deberá permitir que, a partir de un caso de interrupción, el personal de campo pueda localizar la ubicación del dispositivo de interrupción y del siguiente dispositivo en línea ascendente.

 

• El sistema deberá permitir que las cuadrillas añadan archivos adjuntos a los trabajos existentes, incluyendo documentos, imágenes u otros tipos de archivos relevantes.

 

• El sistema deberá permitir que las cuadrillas, en función de sus derechos de usuario, verifiquen el dispositivo de interrupción propuesto para un caso de interrupción y confirmen cuándo se ha completado el restablecimiento de una interrupción verificada.

 

• El sistema deberá permitir que las cuadrillas, en función de sus derechos de usuario, añadan o modifiquen tiquetes de servicio o emergencia desde el MCC.

 

• El sistema deberá permitir que el MCC admita los siguientes estados de trabajo para cada tarea:
  
  

1. Asignado a la cuadrilla.
2. Reconocido por la cuadrilla.
3. (Opcional) Llegada al almacén o bodega.
4. Llegada al lugar.
5. Trabajo terminado.
6. (Opcional) Requisito de dejar el lugar en condiciones seguras.
7. Trabajo finalizado.
8. (Opcional) Trabajo cancelado. Revisar con los tiempos dados por MC

 

• El sistema deberá garantizar que, cada vez que se actualice el estado actual de un trabajo, se registre automáticamente una marca de tiempo indicando cuándo se realizó el cambio. Además, el sistema deberá permitir que un usuario ajuste manualmente la marca de tiempo para reflejar con mayor precisión las actividades realizadas en el campo.

 

• El sistema deberá permitir que el MCC ofrezca a las cuadrillas la capacidad de crear nuevos trabajos y asignárselos a sí mismas.

 

• El sistema deberá permitir que el MCC superponga en el mapa el modelo de conectividad de la red, incluyendo capas separadas para:

 

• Secciones de línea.
• Interruptores (con una capa separada para cada subtipo).
• Dispositivos de generación distribuida.
• Luminarias de alumbrado público.
•  
•  

 

El usuario deberá poder activar y desactivar manualmente las capas. Además, a partir del símbolo, el usuario deberá poder conocer el estado del dispositivo (por ejemplo, abierto o cerrado) y si un tramo de línea está energizado, parcialmente energizado o desenergizado.

• El sistema deberá permitir que el MCC incluya una capa separada para los distintos tipos de datos OMS, incluyendo:

• Cortes activos.
• Cortes programados.
• Cortes restaurados.
• Informes de daños.
• Tiquetes de servicio.
• Tiquetes de emergencia.
•  

 

• El sistema deberá permitir que el MCC muestre la ubicación de todos los vehículos en el territorio de servicio, siempre que se haya integrado la funcionalidad AVL (Automatic Vehicle Location).

 

• El sistema deberá permitir que el MCC admita la ejecución de pings a medidores, siempre que exista una interfaz AMI disponible que soporte solicitudes de ping.
• El sistema deberá permitir que los usuarios actualicen el estado de los dispositivos no telemedidos en el MCC para reflejar su estado real en el campo, en función de sus derechos de usuario.

 

• El sistema deberá permitir que el MCC muestre las etiquetas establecidas en el ADMS, diferenciando su tipo según su propósito:

 

· Informativas.

· De inhibición del control.

· De inhibición parcial (por ejemplo, mantener abierto o mantener cerrado).

 

• El sistema deberá permitir que el MCC funcione en modo sin conexión cuando no haya conectividad. Para ello, deberá mantener localmente en la tableta o dispositivo de la cuadrilla una versión en caché de:

 

• Los datos de OMS (casos, tiquetes, trabajos e informes de daños).
• Los datos cartográficos (incluyendo mosaicos, el modelo de red y los datos de OMS).
  • El sistema deberá garantizar que, cuando el MCC esté en modo fuera de línea, se muestre claramente una indicación al personal de campo de que el dispositivo se encuentra en este estado.

 

• El sistema deberá permitir que, cuando el MCC esté en modo fuera de línea, se muestren los datos almacenados en caché de todos los registros OMS. La cuadrilla deberá poder visualizar y modificar estos datos. Si la cuadrilla guarda cambios, el sistema deberá notificar que los cambios se han guardado localmente y que se sincronizarán con el OMS cuando se restablezca la conexión. Además, deberá existir una indicación en los registros que tengan cambios locales, la cual se eliminará una vez que los datos se sincronicen con el OMS.

 

• El sistema deberá permitir que, cuando el MCC esté en modo fuera de línea, la cuadrilla pueda crear nuevos tiquetes, trabajos o informes de daños, asegurando que estos se almacenen localmente y se sincronicen con el OMS cuando se restablezca la conexión.

 

7.37.     Servicio de entrenamiento.

 

• El sistema deberá permitir la instalación del OMS en un servidor de entrenamiento fuera de línea, para que los operadores puedan probar cómo maneja el OMS distintos escenarios sin afectar el entorno de producción.

 

• El sistema deberá permitir tomar una copia instantánea de la base de datos OMS de producción y transferirla al servidor de entrenamiento para usarla como base de datos de pruebas. El servidor de entrenamiento deberá poder almacenar una biblioteca de estas copias instantáneas y permitir al usuario elegir cuál cargar para un escenario específico. Alternativamente, el servidor de producción deberá poder reenviar cambios puntuales al servidor de entrenamiento para mantener la sincronización. Cuando el usuario inicie una sesión de entrenamiento, deberá poder desactivar temporalmente esta capacidad de reenvío para evitar interferencias con sus acciones.

 

• El sistema deberá garantizar que, cuando un usuario de OMS se conecte al servidor de entrenamiento, se muestre una indicación clara en la interfaz gráfica notificando que está conectado al servidor de entrenamiento y no al entorno de producción.

 

• El sistema deberá permitir que el servidor de entrenamiento sin conexión del OMS simule llamadas telefónicas de clientes para que los usuarios en formación puedan utilizarlas en sus escenarios de prueba, incluyendo simulaciones para condiciones de alta carga.

 

• El sistema deberá permitir que el servidor de entrenamiento sin conexión del OMS simule eventos AMI, llamadas IVR, llamadas web y mensajería para que los usuarios en formación puedan utilizarlos en sus escenarios de prueba, incluyendo simulaciones para condiciones de alta demanda.

 

7.38.     Rendimiento.

 

Capacidades mínimas de Rendimiento

• El sistema deberá demostrar el cumplimiento de los requisitos mínimos de rendimiento definidos por JASEC, entendiendo la “capacidad de gestión” como la habilidad para soportar todos los eventos especificados sin que el sistema se bloquee, procesarlos en un tiempo razonable y continuar funcionando de manera normal.

 

• El sistema deberá tener la capacidad de gestionar hasta 100 alarmas SCADA por segundo durante un período mínimo de 1 hora, sin afectar la estabilidad ni el rendimiento del sistema.

 

• El sistema deberá tener la capacidad de gestionar hasta 20 cortes generados por SCADA por minuto, sin afectar la estabilidad ni el rendimiento del sistema.

 

• El sistema deberá tener la capacidad de atender hasta 1.000 llamadas por hora durante un período mínimo de 6 horas, sin afectar la estabilidad ni el rendimiento del sistema.

 

• El sistema deberá tener la capacidad de gestionar una ráfaga de hasta 1.000 notificaciones de cortes provenientes de AMI por minuto, procesando un mínimo de 50.000 medidores, sin afectar la estabilidad ni el rendimiento del sistema.

 

 

7.39.     Seguridad del sistema.

 

7.39.1. GUI de la sala de control.

• El sistema deberá soportar autenticación y autorización de usuarios mediante usuario y contraseña con validación en el Active Directory y con doble factor de autenticación (Google authenticator, Microsoft authenticator y/o outhpoint).
• El sistema deberá permitir la asignación de diferentes derechos de cuenta para distintos usuarios, garantizando que cada usuario tenga acceso únicamente a las funciones y datos autorizados según su rol.

 

• El sistema deberá permitir establecer un período de inactividad para cada cuenta. Si una cuenta no se utiliza durante un intervalo definido por el usuario, el sistema deberá desconectar automáticamente la sesión de dicha cuenta.

 

• El sistema deberá permitir que JASEC especifique el número mínimo de caracteres requeridos para una contraseña y definir si esta deberá incluir caracteres especiales, números o una combinación de ambos.

 

• El sistema deberá permitir establecer una fecha de caducidad para cualquier contraseña creada, garantizando que los usuarios deban actualizarla una vez alcanzada la fecha definida.

 

• El sistema deberá admitir el uso de contraseñas secundarias que sean requeridas cuando se emita algún control, proporcionando una capa adicional de seguridad para operaciones críticas.

 

7.40.     Aplicaciones web OMS (cliente web CSR, Cuadros de Mandos de OMS móvil/de escritorio, Manejo de Cuadrillas)

• El sistema deberá soportar autenticación y autorización de usuarios mediante usuario y contraseña con validación en el Active Directory y con doble factor de autenticación (Google authenticator, Microsoft authenticator y/o outhpoint).

 

• El sistema deberá permitir que las aplicaciones web de OMS asignen diferentes derechos de cuenta a distintos usuarios, garantizando que cada usuario acceda únicamente a las funciones y datos autorizados según su rol.

 

• El sistema deberá garantizar que las aplicaciones web de OMS soporten conexiones seguras mediante el protocolo HTTPS.

 

• Se debe cumplir con lo indicado en el libro de marcas de JASEC.

 

7.41.     Integración de SCADA y DMS

 

Requisitos de integración

• El sistema deberá integrarse de manera completa y fluida con la base de datos, la interfaz gráfica de usuario y el modelo de red de los sistemas SCADA y DMS existente, garantizando interoperabilidad y consistencia en la información.

 

 

• El sistema deberá garantizar que la integración con SCADA permita recibir todos los eventos en tiempo real, sin pérdida de ningún evento, asegurando la continuidad y confiabilidad de la información.

 

• El sistema deberá permitir que la integración con DMS actualice automáticamente un caso de interrupción en OMS basado en una acción realizada en DMS. Por ejemplo, si FLISR restablece parcial o totalmente el servicio a una sección de clientes, esta actualización deberá reflejarse en OMS.

 

• El sistema deberá garantizar que, en caso de recibir un evento SCADA (por ejemplo, el bloqueo de un interruptor), el OMS cree automáticamente una interrupción verificada, reflejando el estado real de la red en tiempo real.

 

• El sistema deberá proporcionar al operador una única interfaz gráfica desde la cual pueda gestionar todas las operaciones SCADA, OMS y DMS, incluyendo:

 

• Emisión de controles a dispositivos telemedidos.
• Visualización de datos recogidos de dispositivos telemétricos.
• Visualización de la red en vista geográfica y esquemática.
• Emisión y retirada de etiquetas y autorizaciones.
• Gestión de órdenes de conmutación.
• Gestión de casos de interrupción del servicio.
• Visualización y control de las funciones DMS.

 

7.42.     Servicios del Proveedor.

Requisitos de servicios del proveedor

• El proveedor del OMS deberá ser capaz de ofrecer una solución “llave en mano” y prestar los siguientes servicios:

 

· Gestión del proyecto durante la ejecución.

· Configuración de la base de datos del sistema e implantación de gráficos.

· Servicios GIS, incluyendo la importación del modelo de conectividad con detección de errores y validación de datos.

· Importación de datos al OMS desde sistemas externos como GIS, CIS y AMI.

· Integración con sistemas externos como AVL.

· Implantación completa del paquete OMS, incluyendo el cliente web CSR y el portal de incidencias.

· Pruebas remotas y validación de interfaces (GIS, CIS y AMI).

· Configuración de escenarios de prueba.

· Puesta en servicio in situ.

· Formación in situ y/o a distancia.

 

7.43.     Modelo de licenciamiento.

 

• El sistema OMS deberá ser suministrado bajo un modelo de licenciamiento perpetuo para todas las funcionalidades incluidas en el alcance de esta licitación. No se aceptarán modelos de licenciamiento por suscripción para los módulos de OMS.

Adicionalmente, el oferente deberá cotizar, con carácter informativo y no vinculante para la adjudicación, el costo estimado de soporte y mantenimiento por un periodo de cinco (5) años, indicando el porcentaje anual aplicado, los servicios incluidos y el esquema de escalamiento de soporte.

 

7.44.     Integración con SCADA y plataforma de integración corporativa.

 

• La integración del OMS con el sistema SCADA deberá ser nativa con el sistema SCADA Survalent, o en su defecto deberá realizarse de forma bidireccional mediante la plataforma MultiSpeak en las versiones 4.1 y 5.0, conforme al estándar corporativo de integración definido por la entidad.

No se aceptarán integraciones basadas exclusivamente en protocolos de comunicación industrial tales como DNP3, IEC 60870-5-104, OPC u otros protocolos de telemetría punto a punto.

 

7.45.     Demostración técnica.

 

• Como parte del proceso de evaluación técnica y a criterio de JASEC, el oferente deberá realizar una demostración funcional del sistema ofertado en un ambiente operativo, en la cual se evidencie la integración con SCADA, GIS, OMS y WFM, así como el manejo de eventos de interrupción, análisis de afectación de clientes, despacho de cuadrillas y restauración del servicio.

En dicha demostración deberá evidenciarse la funcionalidad del componente móvil en modo fuera de línea.

La no demostración satisfactoria de cualquiera de las funcionalidades descritas será considerada como incumplimiento de requisitos técnicos mínimos y será causal de rechazo de la oferta.

 

7.46.     HARDWARE

7.46.1. Plataforma de Hardware.

 

• La plataforma de hardware comprende todos los dispositivos físicos requeridos para la correcta operación del software OMS, incluyendo servidores host, estaciones de trabajo para operadores, estaciones de ingeniería para desarrollo y configuración, y terminales móviles o de campo para las cuadrillas.
• El sistema deberá implementarse utilizando dispositivos e interfaces de uso general, estándares en la industria. Los equipos de hardware propuestos deberán estar disponibles comercialmente en al menos dos marcas reconocidas en el mercado.
• Todos los materiales y equipos suministrados para instalación permanente deberán cumplir con las especificaciones técnicas vigentes, ser nuevos, sin uso previo y encontrarse en perfecto estado de funcionamiento.

 

7.47.     Servidores OMS Distribución

 

• El contratista del sistema deberá dimensionar, definir la cantidad y proporcionar los servidores necesarios para poder ejecutar de manera total y correcta el sistema OMS ofertado, así como los periféricos del servidor de la estación maestra. Estos construidos por un fabricante líder de la industria informática. Los servidores serán diseñados, fabricados, garantizados y ensamblados íntegramente por el fabricante de los computadores. No se aceptarán marcos de computadores de componentes compuestos ensamblados con tarjetas de diversos proveedores por fabricantes de segunda fuente.
• Los servidores deben contar con procesador de última tecnología, con capacidad de ejecutar el sistema en capacidad plena. Esto procesadores deberán ser de fabricantes reconocidos en el mercado (ejemplo: Intel o AMD)
• Los servidores deben contar con un arreglo RAID de discos duros de estado solidos con capacidad de almacenamiento suficiente para soporte el sistema OMS y al menos 1 año de históricos.
• La memoria RAM del equipo deberá ser dimensionada por el oferente en función de los requerimientos del software ofertado y su correcto desempeño en ambiente de producción. El oferente deberá garantizar que la capacidad instalada sea suficiente para soportar la carga operativa, procesamiento de datos, concurrencia de usuarios y servicios asociados, asegurando un funcionamiento estable y sin degradación del rendimiento.
• Los servidores host deben contar el último sistema operativo (SO) Microsoft Windows Server de 64 bits debidamente licenciado. No se considerará otro sistema operativo como UNIX, Linux, OS2 y VMS.
• El contratista deberá proporcionar la gestión patches SO de acuerdo con los estándares NERC CIP. Todos los patches del sistema operativo serán evaluados por el proveedor y los resultados se proporcionarán al usuario final dentro de los 30 días posteriores al lanzamiento del patch.
• Los servidores host deberán contar con un mínimo de dos tarjetas de interfaz de red Gigabit Ethernet (NIC).
• Los servidores host y el equipo de comunicación asociados se entregarán montados en bastidores en gabinetes de 48U con paredes perforadas para facilitar la ventilación.
• Cada gabinete debe proporcionarse con una UPS que respalde los servidores y cualquier elemento activo necesario para dar continuidad de servicio en caso de falla de la alimentación eléctrica por un periodo de 1 hora

 

7.48.     Consolas de la terminal de Trabajo

 

• El contratista del sistema deberá proporcionar el hardware y los periféricos de la consola de la estación de trabajo construidos por un fabricante líder de la industria informática.
• Las terminales de trabajo ejecutarán la última versión del sistema operativo Microsoft Windows de 64 bits debidamente licenciado.
• Las consolas de la estación de trabajo deberán tener dos tarjetas de interfaz de red Gigabit Ethernet (NIC).
• El sistema podrá soportar cualquier número de consolas de estación de trabajo sin necesidad de actualizar el hardware y el software del sistema.
• Las consolas de trabajo deberán contar con tarjetas de video con al menos 4 con puerto HDMI o DVI.
• Se deberán suministrar 2 monitores de tecnología LED de 27” por cada consola de trabajo. Compatibles con las tarjetas de video.
• Deben poseer una memoria RAM mínima de 16GB
• Deberán contar con un disco duro de estado sólido de al menos 512 GB.

 

7.49.     Estaciones de Ingeniería móvil

 

• El contratista del sistema deberá proporcionar el hardware y los periféricos de la consola de la estación de ingeniería construidos por un fabricante líder de la industria informática.
• Las estaciones de ingeniería deberán contar con procesador similar o superior al Core i7 de última tecnología.
• Deben poseer una memoria RAM mínima de 16GB
• Deberán contar con un disco duro de estado sólido de al menos 1 TB.
• Las terminales de Ingeniería ejecutarán la última versión del sistema operativo Microsoft Windows de 64 bits debidamente licenciado.
• Las consolas de ingeniería serán de tipo portátil Plus 2 en 1.
• Los equipos deberán tener pantalla tipo táctil de al menos 16 “.
• Los equipos deberán tener un chasis metálico en aluminio.
• Los equipos deberán traer su estuche de transporte tipo mochila.

 

7.50.     Pantalla Led mural de la menos 65 “

 

• Se requiere el suministro e instalación de una pantalla LED mural de al menos 65 pulgadas, destinada a la visualización permanente de información operativa en el Centro de Despacho de Energía. El equipo deberá ser de tecnología LED, con un tamaño mínimo de 65 pulgadas en diagonal y resolución 4K UHD (3840 x 2160 píxeles) como mínimo, garantizando alta definición y nitidez para la correcta visualización de diagramas unifilares, cartografía GIS, estados de red, eventos, alarmas y tableros operativos del Despacho de Energía.
• La pantalla deberá contar con un nivel de brillo adecuado para operación en salas de control, no menor a 400 nits, así como un ángulo de visión mínimo de 178 grados tanto horizontal como vertical, permitiendo la correcta visualización desde distintos puntos del recinto. El equipo deberá estar diseñado para operación continua 24 horas al día, 7 días a la semana (24/7), asegurando confiabilidad y estabilidad en ambientes de misión crítica.
• En cuanto a conectividad, la pantalla deberá disponer de múltiples entradas de video, incluyendo al menos dos puertos HDMI y un puerto DisplayPort o equivalente, que permitan la integración con estaciones de operación, servidores de visualización o controladores gráficos.
• La solución deberá incluir el sistema de montaje mural fijo o estructura para su correcta instalación, garantizando seguridad y estabilidad.

 

7.51.     Tabletas Rugerizadas para Cuadrillas de Campo

 

• 47.6.1 El sistema deberá contemplar el uso de tabletas rugerizadas de grado industrial, destinadas a las cuadrillas de campo para la consulta, registro y actualización de información operativa asociada al sistema OMS.
• Las tabletas deberán ser equipos diseñados para operación en ambientes exigentes, con protección contra polvo, humedad, vibraciones y golpes, adecuados para uso en campo por personal técnico.
• Los equipos deberán contar con certificaciones de resistencia de estándar industrial, tales como IP65 o superior para protección ambiental y MIL-STD-810H o equivalente para resistencia a condiciones operativas adversas.
• Las tabletas deberán contar con pantalla táctil de aproximadamente 10 pulgadas, optimizada para uso en exteriores y con capacidad de operación con guantes o lápiz digital.
• Los equipos deberán disponer de capacidad de procesamiento, memoria RAM y almacenamiento suficientes para ejecutar de manera eficiente las aplicaciones móviles del sistema OMS y cualquier software complementario requerido para la operación de campo.
• Las tabletas deberán contar con conectividad inalámbrica integrada, incluyendo como mínimo Wi-Fi, Bluetooth y conectividad celular (LTE o superior), que permita la comunicación con los sistemas centrales y el intercambio de información en tiempo real o diferido.
• Los equipos deberán incluir sistemas de posicionamiento satelital (GPS o equivalente) para permitir la georreferenciación de eventos, activos y actividades realizadas por las cuadrillas.
• Las tabletas deberán contar con batería de larga duración adecuada para cubrir la jornada de trabajo en campo, así como la posibilidad de reemplazo o carga mediante accesorios diseñados para operación móvil.
• Como referencia de equipo que cumple con las características descritas, se considera la tablet rugged Dell Latitude 7030 Rugged Extreme Tablet (Pro Rugged 10) o equivalente, sin limitar la posibilidad de que los oferentes propongan equipos de características iguales o superiores.
• Los oferentes deberán especificar claramente el modelo propuesto, sus características técnicas y los accesorios incluidos para su operación en campo (bases vehiculares, cargadores, lápiz digital, correas de sujeción u otros).

Esta sección establece las condiciones generales aplicables al procedimiento de licitación tramitado por la Junta Administrativa del Servicio Eléctrico de Cartago, en adelante denominada JASEC.

Para una correcta interpretación de estas condiciones generales, se deberá considerar en conjunto lo dispuesto en:

• La Sección II, que detalla las Condiciones Específicas de la contratación, incluidas las especificaciones técnicas. En caso de contradicción entre las condiciones generales y las especificaciones técnicas contenidas en la Sección II, prevalecerá lo dispuesto en estas últimas.

El régimen jurídico aplicable a este procedimiento de contratación se encuentra establecido en los siguientes instrumentos normativos:

• El artículo 5 de la Ley General de Contratación Pública N.º 9986, publicada en el Alcance N.º 109 a La Gaceta N.º 103 del lunes 31 de mayo de 2021.
• El Reglamento a la Ley General de Contratación Pública, contenido en el Decreto Ejecutivo N.º 43808-H, publicado en el Alcance N.º 258 a La Gaceta N.º 229 del miércoles 30 de noviembre de 2022.

Este pliego de condiciones se estructura en dos secciones principales, que deben ser leídas e interpretadas de forma integral para garantizar el cumplimiento de los requisitos del procedimiento.

1. SECCIÓN PRIMERA: CONDICIONES GENERALES DEL PLIEGO DE CONDICIONES PARA TODO TIPO DE LICITACIONES REDUCIDAS, MENORES Y MAYORES.

CAPÍTULO I

1.- GENERALIDADES

Podrán participar en esta licitación las personas físicas o jurídicas que presenten su oferta, ya sea actuando directamente, por medio de su representante legal, o a través de un representante de casas extranjeras debidamente autorizado.

Por el solo hecho de presentar su oferta, el oferente declara y acepta lo siguiente:

 

a)    Que conoce íntegramente los documentos referentes a esta Licitación y sus modificaciones y que acepta todos los términos y condiciones contenidos en ellos.

 

1. Que se somete a las leyes y Tribunales de Costa Rica en todo lo concerniente a los trámites del presente proceso licitatorio y a la ejecución del contrato. En el caso de oferentes extranjeros, se declara expresamente la renuncia a cualquier intervención o reclamación diplomática en su favor.
2. Que acepta la jurisdicción nacional para resolver cualquier controversia directa o indirectamente relacionada con el contrato, con renuncia expresa a cualquier otra jurisdicción.
3. Que cumple estrictamente con las obligaciones laborales y de seguridad social respecto de sus trabajadores.
4. Que se encuentra inscrito y al día en la plataforma SICOP. Se aclara que JASEC no realiza pagos a través de dicha plataforma, por lo que, en caso de resultar adjudicatario, el oferente deberá inscribirse en el Registro de Proveedores de JASEC.
5. Que, en el caso de oferentes extranjeros, estos podrán participar directamente o mediante un representante de casas extranjeras debidamente autorizado por el principal. Dicho representante también podrá presentar la oferta a nombre de un tercero, siempre que se acredite la existencia de un contrato de representación válido.
6. OFERTAS ELECTRÓNICAS
   • REQUISITOS DE LAS OFERTAS

Toda oferta deberá ser elaborada y presentada en el Sistema Unificado de Compras Públicas, a más tardar a la hora y fecha señalada en el pliego de condiciones, como cierre de recepción de ofertas.

 

Las ofertas deberán cumplir los siguientes aspectos:

• La redacción en idioma español. La información técnica o complementaria y los manuales de uso expedidos por el fabricante deberán presentarse en idioma español, salvo que en el pliego de condiciones se permitan otros idiomas con la traducción debidamente consularizada o se acepte una traducción libre de su texto.
• Debe ser firmada por persona con capacidad legal.
• El Oferente está obligado a cotizar todo el objeto, salvo que se trate de partidas independientes entre sí, en cuyo caso podrá cotizar en las de su interés, sin que sea necesario que el pliego de condiciones lo autorice. No se permite la cotización parcial de una línea.
• Todas las unidades de medidas que se utilicen en la oferta deben estar dadas en el Sistema Internacional (S.I.) de Pesos y Medidas.
• En el pliego de condiciones se indicará cuando se aceptan ofertas alternativas. Se entenderá por oferta alternativa una propuesta distinta a la definida en el pliego de condiciones, respetando el núcleo del objeto y la necesidad a satisfacer, que puede ser conveniente y oportuna para la entidad. La Institución en la sección correspondiente indicará la cantidad máxima de ofertas base y alternativas que se permitirán. Para efectos de presentar varias ofertas, el Oferente deberá registrarlas de forma separada en el Sistema Unificado de Compras Públicas.
• Aportar manuales o documentación técnica como un archivo en PDF o GIF.
• Para las muestras del producto a ofertar, deberá señalarse el lugar de entrega, custodia, análisis y el plazo para la devolución.
• Aportar los tributos que afectan los precios, cuando se omitan se presumen incluidos en el precio cotizado.
• El ofertante nacional o extranjero deberá aportar en la oferta, Declaración Jurada que no le afecta el régimen de prohibiciones establecido en los numerales N°28 y N°29  Ley General de Contratación Pública Nº9986.  Además, deberá confirmar si no hay conflicto de intereses con algún funcionario que tramite o realice estudios o criterios en el concurso y la aceptación de la cláusula COMPROMISO ANTICORRUPCIÓN establecida en la sección segunda.

 

• CRITERIOS COMPARATIVOS PARA EVALUAR Y ADJUDICAR

 

En la ponderación de las ofertas, se considerarán los factores que se definen en la sección de especificaciones técnicas.

• Tratándose de contrataciones de objeto múltiple, la evaluación se hará para cada una de las líneas o grupos de líneas definidos en el requerimiento, según se haya establecido en este pliego de condiciones por lo que JASEC podrá acordar la adjudicación parcialmente entre uno o más oferentes según convenga a sus intereses.

 

• En caso de recibir propuestas en distintas monedas, y únicamente para efectos del estudio comparativo de precios de las ofertas, el Sistema Unificado de Compras Públicas las convertirá a una misma moneda aplicando el tipo de cambio de referencia para la venta, calculado por el Banco Central de Costa Rica, vigente al momento de la apertura de ofertas.

 

• Cuando se trate de la adquisición de bienes, el oferente, deberá indicar las normas bajo las cuales se fabricarán y para los repuestos genuinos o la fabricación de piezas que por su aplicación dentro del proyecto pueda tener el carácter de "especial”.

 

• La Administración se reservará el derecho de adjudicar el concurso a uno o más oferentes en forma total o parcial, por partidas según lo indicado en el pliego de condiciones.

 

• En caso de que al concurso no se presenten ofertas o las que lo hicieren no se ajusten a los requerimientos sustanciales, la Administración declarará infructuoso el concurso. Cuando, existiendo ofertas elegibles, pero por razones de interés público no se recomiende adjudicar, la Administración mediante acto motivado declarará desierto el concurso.

 

• La Administración se reservará el derecho de adjudicar al segundo mejor oferente en caso de declarar insubsistente el concurso.

 

 

 

 

 

• PLAZO PARA ADJUDICACIÓN

El Acto Final será comunicado a través del Sistema Integrado de Compras Públicas (SICOP).

Este acto se emitirá dentro del plazo máximo establecido en la Sección Segunda de este pliego de condiciones, contado a partir del día hábil siguiente a la recepción de las ofertas.

JASEC se reserva la facultad discrecional de adjudicar parcialmente o de declarar desierta la presente contratación, según lo estime conveniente a sus intereses institucionales.

En caso de que se ofrezcan bienes sujetos a desgravación arancelaria, y para efectos de comparación de ofertas, JASEC adicionará a aquellas propuestas cotizadas en moneda extranjera —que no incluyan productos desgravados— el valor correspondiente a los impuestos y derechos de importación, en la proporción que corresponda.

 

• GARANTÍAS DE CUMPLIMIENTO

Las garantías de cumplimiento deberán ser depositadas a través del Sistema Integrado de Compras Públicas (SICOP), conforme a los términos y cuentas bancarias de JASEC indicados en dicha plataforma.

En caso de que JASEC se vea en la necesidad de ejecutar la garantía antes del vencimiento del contrato, el adjudicatario estará obligado a presentar una nueva garantía, de forma que el contrato permanezca debidamente respaldado hasta su total ejecución.

Es responsabilidad del contratista mantener vigente la garantía de cumplimiento mientras no se haya recibido formalmente el objeto contractual. Si, un día hábil antes del vencimiento de la garantía, el contratista no ha gestionado su prórroga, la Administración podrá hacerla efectiva de manera preventiva y mantener los fondos en una cuenta bajo custodia. Dichos fondos servirán como medio de resarcimiento en caso de incumplimiento. En este supuesto, el contratista podrá presentar una nueva garantía que sustituya el monto retenido.

La garantía otorgada por los fabricantes sobre materiales y equipos no podrá ser inferior a doce (12) meses contados a partir de la entrada en operación de los equipos o del uso de los materiales, o veinticuatro (24) meses posteriores a su aceptación por parte de JASEC, lo que ocurra primero.

Cuando el oferente de los materiales o equipos sea un exportador, este asumirá responsabilidad solidaria con el fabricante respecto al cumplimiento de las garantías estipuladas en el presente procedimiento de contratación.

 

 

1. FORMA DE PAGO

La forma habitual de pago en JASEC es mediante transferencia bancaria, a crédito, con un plazo de treinta (30) días naturales, contado a partir de la verificación satisfactoria del cumplimiento de las obligaciones contractuales.

En caso de requerirse una modalidad de pago distinta, esta deberá ser coordinada previamente con los Departamentos de Tesorería y Proveeduría. JASEC podrá aplicar, según corresponda, las siguientes modalidades de pago:

• Pago por resultados
• Pago por precio-volumen
• Pago en función del uso

Cuando se trate de pagos a empresas extranjeras por servicios prestados dentro del territorio nacional, se generará la obligación de practicar la retención correspondiente, conforme a lo dispuesto en el artículo 59 de la Ley del Impuesto sobre la Renta. La tarifa aplicable dependerá del concepto específico del pago a remesar, según lo establecido en dicha normativa

Toda oferta que proponga una forma de pago distinta a la establecida será declarada inadmisible.

La factura deberá detallar, por cada línea adjudicada, el porcentaje correspondiente del Impuesto al Valor Agregado (IVA) aplicable al monto total.

JASEC se reserva el derecho de retener hasta un 5% de las sumas por pagar al adjudicatario en caso de incumplimientos contractuales. Esta retención podrá aplicarse de forma directa o, en su defecto, mediante la ejecución parcial de la garantía de cumplimiento, según lo que resulte más conveniente para la Administración según el artículo 115 Decreto 43808-H.

En el caso de pagos a empresas extranjeras por servicios prestados dentro del territorio nacional, se generará la obligación de practicar la retención correspondiente, conforme al artículo 59 de la Ley del Impuesto sobre la Renta. La tarifa aplicable dependerá del concepto específico del pago a remesar.

Todo pago a cargo de la Administración se realizará una vez efectuada la recepción definitiva de los bienes o servicios contratados. Esta recepción no exime al contratista de su responsabilidad por vicios ocultos, conforme a lo dispuesto en los artículos 284 y 285 del Reglamento a la Ley General de Contratación Pública (Decreto Ejecutivo N.º 43808-H)

• TRÁMITES DE EXONERACIÓN

JASEC no cuenta con exoneración tributaria ante el Ministerio de Hacienda. Por tanto, en el caso de productos importados cuya empresa oferente esté domiciliada fuera del territorio nacional, los precios deberán cotizarse bajo el término Incoterms 2020: DDP (Delivered Duty Paid) – Bodegas JASEC.

Cualquier oferta que indique un lugar de entrega distinto al señalado será considerada inelegible.

Todo el trámite de nacionalización será de entera responsabilidad del contratista, quien deberá asumir todos los costos asociados, incluyendo, pero no limitándose a:

• Contratación de una agencia aduanal.
• Pago de bodegaje en el almacén fiscal.
• Transporte desde el almacén fiscal hasta el sitio de entrega.
• Descarga del material en el lugar de destino.
• Cualquier otro costo directo o indirecto derivado del proceso de importación y entrega.

JASEC no asumirá, en ninguna circunstancia, el pago de bodegaje, impuestos, tributos ni ningún otro gasto relacionado con la nacionalización de la mercadería.

La entrega se considerará completada únicamente cuando la mercadería haya sido descargada (puesta en el suelo) en el sitio de entrega designado. Solo a partir de ese momento, el contratista quedará liberado de responsabilidad sobre el bien entregado.

• DESGRAVACIÓN ARANCELARIA

Los proveedores que ofrezcan bienes sujetos a beneficios de desgravación arancelaria establecidos en instrumentos bilaterales o multilaterales de comercio suscritos y ratificados por la República de Costa Rica deberán cumplir con los siguientes requisitos:

• Indicar en su oferta la partida, subpartida o fracción arancelaria correspondiente a los bienes ofertados.
• Declarar bajo juramento que los bienes estarán acompañados de los certificados de origen que respalden la información arancelaria proporcionada en la oferta.

El incumplimiento de estos requisitos podrá dar lugar a la descalificación de la oferta o a la aplicación de las sanciones correspondientes, conforme a la normativa vigente.

 

• TIEMPO Y FORMA DE ENTREGA

En caso de que la oferta incluya materiales o equipos a importar, deberá indicarse expresamente el tiempo estimado para el embarque, conforme a lo establecido en la legislación tributaria costarricense.

El plazo de entrega se contará a partir del día hábil siguiente a la notificación de la Orden de Compra. Dicho plazo deberá ser indicado en la oferta en días naturales o hábiles, según corresponda.

El adjudicatario deberá acompañar cada bulto enviado a JASEC con la documentación correspondiente, la cual deberá detallar de forma precisa:

• Contenido de cada bulto
• Precio unitario
• Lista de empaque
• Precio total de los materiales y equipos

En la parte exterior de cada bulto deberá indicarse claramente el número de pedido y la orden de compra. Asimismo, todos los bultos deberán estar debidamente identificados al momento del embarque. No se permitirá la mezcla de materiales correspondientes a diferentes pedidos en un mismo bulto durante el proceso de empaque y embalaje.

Los materiales o equipos que, al momento de la entrega, presenten defectos evidentes e inaceptables a juicio de JASEC, serán rechazados de inmediato y no se considerarán como recibidos. El adjudicatario deberá suministrar los catálogos técnicos que describan los equipos y accesorios entregados.

Para contrataciones en plaza, la oferta deberá indicar el tiempo y lugar de entrega de los materiales y equipos. En caso de adjudicación, el plazo de entrega se contará a partir de la notificación por fax de la Orden de Compra. La mercadería deberá ser entregada en el Almacén de JASEC ubicado en Barrio Fátima o en el Almacén Birrís, según se indique.

• RECLAMOS DE MERCADERÍA

 

En caso de que el adjudicatario envíe un artículo que no corresponde a lo adjudicado, o que sea defectuoso, JASEC procederá a su devolución siempre y cuando el adjudicatario cancele los gastos de nacionalización. La firma de la solicitud de exoneración de los bienes sustitutos quedará condicionada a la demostración de la cancelación de los gastos de nacionalización de los bienes originalmente exonerados. En caso de que el contratista no desee nacionalizar los bienes defectuosos o diferentes a lo adjudicado, JASEC podrá autorizar la reexportación de dichos bienes en el entendido de que todos los gastos y trámites asociados correrán por cuenta del contratista.

Solo cuando la totalidad de lo adjudicado se halla entregado a satisfacción, en la Bodega de JASEC, el contratista adquirirá el derecho al pago.

En caso de sobrantes de materiales, estos pasarán a ser propiedad de JASEC.

En el caso de compras de importación, los costos asociados a reclamos por faltantes o errores en la entrega de la mercadería se gestionarán de la siguiente manera:

1. Faltantes de mercadería:
   Durante la revisión en el Almacén de JASEC, se detecta un faltante de productos que sí fueron incluidos en la factura, el adjudicatario será responsable de cubrir todos los costos relacionados con el envío del faltante, incluyendo:

• Impuestos de nacionalización
• Gastos de desalmacenaje
• Costos de entrega en las bodegas de JASEC

 

1. Errores o defectos en la entrega:
   El adjudicatario entrega un artículo que no corresponde a lo adjudicado o que presenta defectos, JASEC procederá a su devolución, el adjudicatario asume los gastos de nacionalización de dichos bienes.

En caso de que el contratista no desee nacionalizar los bienes defectuosos o incorrectos, JASEC podrá autorizar su reexportación, bajo el entendido de que todos los gastos y trámites asociados correrán por cuenta del contratista.

 

1. Condición para el pago:
   El contratista adquirirá el derecho al pago únicamente cuando la totalidad de los bienes adjudicados haya sido entregada a satisfacción en la bodega de JASEC.

 

1. Sobrantes de materiales:
   Cualquier sobrante de materiales entregado pasará a ser propiedad de JASEC, sin que ello implique un ajuste en el monto a pagar.

 

 

• OBLIGATORIEDAD DE LA FICHA TÉCNICA Y DE ALMACENAMIENTO

 

• FICHA TÉCNICA

Con el objetivo de revisar el flujo de proceso que ha seguido la adquisición de productos, los oferentes que participen en los distintos procedimientos ordinarios de contratación pública deben presentar en sus ofertas, como requisito indispensable, la Ficha Técnica de cada producto. Este documento se utilizará para determinar el cumplimiento de las características del objeto(s) exigidas en el pliego de condiciones, en fase de elegibilidad.

Cuando exista discrepancia con el pliego de condiciones se rechaza la mercadería hasta ajustarse el objeto contractual requerido por la administración.

• FICHA DE ALMACENAMIENTO.

Adicionalmente es requisito indispensable, ya sea en la oferta o bien en el momento de la entrega del objeto, actuando como contratista, presentar Ficha de Almacenamiento a efecto de manipular y conservar de forma correcta los artículos correspondientes a los materiales cotizados o adjudicados.

 El Departamento Almacén como área responsable de la conservación y custodia del inventario, ha definido los grupos de artículos para los cuales el contratista deberá suministrar la respectiva Ficha de Almacenamiento:

• Transformadores de Distribución Transformadores de Corriente y Transformadores de Potencia.
• Fibra Óptica.
• Equipo Electrónico.
• Contadores y Colectores de Energía.
• Postes Tubulares y de Concreto
• Recloser y controles.
• Productos químicos y conexos como: combustibles, lubricantes, diluyentes, abonos, fertilizantes, insecticida, fungicidas y similares
• Productos tóxicos.
• Equipo especializado para Subestaciones.
• Equipo especializado para Plantas Hidroeléctricas.
• Cable de Potencia Concéntrico.

 

Si en la oferta no se presentó la Ficha de Almacenamiento, esta deberá entregarse en el Almacén de JASEC designado en la Orden de Compra, junto con la factura comercial. La omisión de su entrega ocasionará que la recepción del objeto contractual se dé en forma provisional bajo protesta, en los términos del artículo N°284 del Reglamento a la Ley General de Contratación Pública DE Nº43808-H, de forma que quedará en suspenso la Recepción Definitiva y por consiguiente el inicio del plazo para efectuar el pago hasta que se subsane este aspecto por parte del contratista.

La Ficha de Almacenaje deberá contener al menos la siguiente información:

Manipulación: Especificar las precauciones necesarias para garantizar un traslado y manipulación sin peligro, tales como el tipo del equipo de manutención a emplear. Incluir recomendaciones sobre medidas de orden técnico y cualquier otra exigencia o norma específica relativa al bien.

Condiciones de Almacenaje: Especificar las condiciones necesarias para el almacenamiento, por ejemplo: si se requiere un lugar fresco o ventilado, si puede estar expuesto a la intemperie, si debe aislarse del suelo para evitar filtraciones de humedad.

Formas de Almacenamiento: Definir el Patrón de Paletizado, la unidad de carga paletizada a utilizar (dimensiones y peso de la carga y/o características de la paleta que se debe utilizar), cantidades máximas de niveles a estibar; dependiendo del material si se requieren durmientes, así como las normas de uso para bobinas de cable.

Condiciones Especiales de Conservación: Cualquier recomendación e información adicional suministrada por el fabricante o por el distribuidor del material, que permita asegurar la conservación del artículo.

En caso de tratarse de equipos y materiales especializados no incluidos en la categorización indicada anteriormente, JASEC se reserva el derecho de solicitar al Contratista posterior a la recepción provisional de los artículos; la respectiva Ficha de Almacenamiento.

 

 

1. PENALIZACIÓN

 

El adjudicatario se obliga a cumplir estrictamente con lo dispuesto en la Ley General de Contratación Pública N.º 9986, así como con todas las condiciones establecidas en el pliego de condiciones y los términos de su oferta.

El incumplimiento de cualquiera de las cláusulas contenidas en dichos documentos facultará a la Administración para proceder con la resolución del contrato y la ejecución de la garantía de cumplimiento, previa audiencia otorgada al contratista, sin perjuicio de las acciones legales que correspondan para el resarcimiento de daños y perjuicios en la vía jurisdiccional.

De esta manera, JASEC podrá rescindir la relación contractual derivada del presente procedimiento cuando así lo amerite, siempre que la decisión esté debidamente razonada y fundamentada, conforme a lo establecido en el artículo 288 y siguientes del Reglamento a la Ley General de Contratación Pública (Decreto Ejecutivo N.º 43808-H).

En caso de que se incluyan sanciones pecuniarias fijas y predeterminadas en el pliego de condiciones, estas deberán estar debidamente justificadas. Es decir, deberá demostrarse el riesgo o afectación potencial a la Administración, tanto en lo relativo a:

• La cláusula penal por incumplimiento del plazo de ejecución pactado ya sea por ejecución anticipada o tardía.
• Las multas por ejecución defectuosa del objeto contractual.

Estas sanciones deberán incorporarse en la Sección II del pliego, correspondiente a las especificaciones técnicas.

Es importante señalar que la suma de las sanciones aplicables por estos conceptos no podrá exceder el 25% del monto total del contrato, conforme a los límites establecidos por la normativa vigente.

JASEC se reserva el derecho de valorar, además, el cobro de daños y perjuicios derivados de estos incumplimientos. Asimismo, la entrega morosa o el incumplimiento contractual serán considerados en la evaluación del desempeño del proveedor.

En caso de que se determine la existencia de un daño o perjuicio, se procederá a la apertura de un procedimiento administrativo para la eventual imposición de sanciones, conforme a lo dispuesto en la Ley General de Contratación Pública N.º 9986.

 

1. REAJUSTE Y DESGLOSE DE PRECIOS

 

Con el fin de asegurar y mantener el equilibrio económico del contrato, JASEC reconocerá ajustes de precios, conforme a lo dispuesto en el Artículo 43 de la Ley General de Contratación Pública. La dependencia técnica correspondiente deberá verificar la fórmula de reajuste o revisión de precios en los casos que así lo ameriten.

 

Los oferentes deberán incluir en su propuesta de oferta una estructura de precios completa y un presupuesto detallado, que identifique y cuantifique todos los elementos que componen el precio ofertado.

Los reajustes se calcularán únicamente sobre los elementos de costo, utilizando índices de precios oficiales. En ningún caso se reajustarán los rubros correspondientes a utilidad ni imprevistos.

 

En caso de solicitar un ajuste especial en dólares, el contratista deberá presentar un estudio económico-financiero acompañado de toda la evidencia documental necesaria que respalde el desequilibrio contractual.

 

La solicitud de reajuste o revisión de precios será admitida únicamente cuando se cumpla con la totalidad de la información y requisitos establecidos en el artículo 61 del Reglamento para el Reajuste de Precios en los Contratos de Obra Pública y la Revisión de Precios en los Contratos de Bienes y Servicios.

 

En caso de que la documentación presentada sea incompleta o insuficiente, la Administración podrá prevenir al contratista para que aporte la información adicional requerida, dentro del plazo que se le indique, conforme a lo dispuesto en dicho artículo.

 

Las fórmulas aplicables para el cálculo de los reajustes serán las siguientes:

 

Para contratos de obra pública: se aplicará la fórmula matemática establecida en el Artículo 26 del Reglamento para el Reajuste de Precios en los Contratos de Obra Pública y la Revisión de Precios en los Contratos de Bienes y Servicios.

 

**Los cálculos se realizarán sobre las estimaciones periódicas de avance aprobadas por la Administración. Para ello, deberá existir un programa de trabajo vigente.

Para los contratos de Bienes y Servicios: se utilizará la fórmula definida en el Artículo 51 Reglamento Reajuste Precios en los Contratos de Obra Pública y la Revisión de Precios en los Contratos de Bienes y Servicios.

**En estos casos, el cálculo se basará en la valoración de los pagos por entregas, conforme al cronograma de tiempos vigente.

El derecho a solicitar reajustes o revisiones de precios concluye con el finiquito del contrato.

 

5.2 DESGLOSE DEL PRECIO

En cumplimiento de lo dispuesto en el artículo 42 de la Ley General de Contratación Pública y los artículos 102 y 103 del reglamento citado, el oferente deberá presentar, como parte de su oferta, la estructura del precio en valores absolutos y porcentuales. En caso de discrepancia entre ambos, prevalecerán los valores absolutos, los cuales deberán coincidir con la moneda o monedas en que se presenta la oferta.

A continuación, se presenta un cuadro de ejemplo que ilustra cómo debe estructurarse el presupuesto detallado, el cual constituye la memoria de cálculo que respalda el precio cotizado. Esta información debe reflejarse fielmente en la estructura del precio incluida en la oferta:

El presupuesto detallado debe desglosar los componentes de cada actividad, unidad de obra, bien o servicio, según corresponda, e incluir obligatoriamente al menos los siguientes elementos:

• Costos directos: Son aquellos gastos que, aunque no están directamente vinculados con la producción, resultan esenciales para el funcionamiento operativo de la empresa, que deben contemplar:
  • Recursos de materiales
  • Mano de obra (con el detalle de cargas sociales)
  • Equipos y maquinaria
  • Subcontratos debidamente identificados
• Costos indirectos: Son aquellos gastos que, aunque no están directamente vinculados con la producción de bienes o la prestación de servicios, son esenciales para el funcionamiento general de la empresa. Entre ellos se incluyen el alquiler, los servicios públicos, los seguros y otros costos administrativos
• Utilidad:  Es la ganancia que obtiene la empresa
• Imprevistos: Son provisiones para cubrir gastos inesperados.

Este desglose es fundamental para la aplicación de la fórmula de reajuste o revisión de precios, conforme a lo establecido en los artículos 107, 108 y 109 del Decreto 43808-H.

 

5.3 PRESUPUESTO DETALLADO.

El contratista que resulte adjudicado debe presentar dentro del plazo de ocho días hábiles siguientes a la firmeza de la adjudicación, el presupuesto detallado correspondiente a la memoria de cálculo efectuada y que sustenta el precio cotizado.

 

1. ARBITRAJE

Las partes únicamente podrán recurrir al arbitraje cuando exista una autorización previa, expresa y por escrito emitida por la Junta Directiva o por la instancia competente de la institución. Dicha autorización deberá otorgarse conforme a los lineamientos y procedimientos establecidos por la autoridad correspondiente, y deberá constar en el expediente contractual como requisito indispensable para la validez del sometimiento a arbitraje.

 

1. COMPRAS ESTRATEGICAS

 

La Proveeduría Institucional será responsable de verificar que los pliegos de condiciones incluyan criterios estratégicos, los cuales podrán establecerse como requisitos de admisibilidad o como criterios de evaluación, según su pertinencia y necesidad en cada procedimiento de contratación.

Estos criterios deberán estar alineados con los objetivos de las políticas públicas en los ámbitos social, ambiental y económico, tanto a nivel local como regional, así como con el fomento de la innovación, conforme a lo dispuesto en el Artículo 20 de la Ley General de Contratación Pública. Esta norma establece que las contrataciones públicas deben contribuir al desarrollo social equitativo, la promoción económica de sectores vulnerables, la protección ambiental y la innovación, reconociendo su carácter instrumental para el progreso económico y el bienestar general.

En este sentido, es obligación del gestor de compras incorporar en los pliegos de condiciones criterios estratégicos de corto, mediano y largo plazo, considerando el ciclo de vida del bien o servicio, con el fin de garantizar una contratación pública sostenible, alineada con los principios de eficiencia, eficacia y responsabilidad social.

 

1. CUMPLIMIENTO DE LO PACTADO

El adjudicatario se compromete a cumplir estrictamente con lo dispuesto en la Ley General de Contratación Pública N.º 9986, así como con todas las disposiciones establecidas en el pliego de condiciones y los términos de su oferta.

El incumplimiento de cualquiera de las cláusulas contenidas en dichos documentos facultará a la Administración para proceder con la resolución del contrato y la ejecución de la garantía de cumplimiento, previa audiencia otorgada al contratista, sin perjuicio de ejercer las acciones correspondientes en la vía jurisdiccional para el resarcimiento de daños y perjuicios.

Igualmente, JASEC podrá rescindir la relación contractual derivada del presente procedimiento cuando así lo amerite, siempre que la decisión esté debidamente razonada, fundamentada y justificada, conforme a lo establecido en los artículos 90 y siguientes del Reglamento a la Ley General de Contratación Pública (Decreto Ejecutivo N.º 43808-H).

 

1. EJECUCIÓN CONTRACTUAL

En contratos cuya ejecución se extienda a lo largo de varios periodos económicos, el fiscalizador o administrador del contrato no está autorizado para solicitar servicios ni comprometer recursos adicionales que excedan la estimación económica adjudicada, independientemente de la variación en el tipo de cambio. La conversión de moneda debe cubrir exclusivamente el monto comprometido, y los saldos a favor generados por diferenciales cambiarios no constituyen recursos disponibles para ampliar el alcance contractual, salvo que exista una modificación contractual debidamente formalizada.

Cuando el fiscalizador o administrador del contrato gestione la apropiación de recursos en la reserva presupuestaria y en la orden de compra, deberá asegurarse de que dicha gestión se enmarque en la planificación presupuestaria plurianual. Además, está obligado a contar con un mecanismo de control documentado que respalde los pagos realizados y permita verificar el uso adecuado de los fondos públicos, conforme a lo establecido en los artículos 38 de la Ley General de Contratación Pública N.º 9986 y 87 del Decreto Ejecutivo N.º 43808-H.

Por su parte, el contratista no podrá alegar desconocimiento de la normativa aplicable, según lo dispuesto en el artículo 119 de la Ley General de Contratación Pública N.º 9986.

 

1. FINIQUITO

 

Las partes contratantes están facultadas para acordar la suscripción del finiquito del contrato, el cual podrá formalizarse a través del Sistema Digital Unificado de Compras.

 

La suscripción del finiquito por parte de quien ostente la capacidad legal correspondiente tendrá efectos liberatorios, impidiendo la formulación de reclamos posteriores, salvo aquellos relacionados con vicios ocultos, cuya responsabilidad subsiste conforme a la normativa aplicable.