Sin dato duplicado: un repositorio único de medición en SAP IS-U
Cómo evitar la duplicación del dato de medición cuando conviven varios fabricantes AMI: repositorio único, identidad del punto de entrega e idempotencia.
· 13 min de lectura
Ningún pliego de licitación de medición avanzada trae una cláusula que diga quién tiene permiso de escritura sobre el dato. Se especifican protocolos, precisión metrológica, garantías de equipo, disponibilidad de comunicaciones. No se especifica cuál de los sistemas que van a existir después del despliegue guarda la versión que se factura, y cuál guarda apenas una copia de trabajo.
Esa omisión no se nota con un proveedor. Se cobra con el segundo. Cuando entra un fabricante nuevo y trae consigo su propio almacenamiento de lecturas, la organización descubre que nunca declaró un dueño: tiene varias copias del mismo consumo, todas plausibles, ninguna oficial. A partir de ahí la pregunta deja de ser de arquitectura y pasa a ser de custodia — quién responde por el número cuando dos sistemas discrepan, y con qué autoridad.
Quién escribe y quién solo lee
La decisión que resuelve esto es organizativa, no técnica. Cada fabricante que entra a la red debe recibir un rol explícito en el contrato: productor de dato crudo, con permiso de escritura hacia la capa de integración, y consumidor de solo lectura del repositorio oficial para sus funciones de diagnóstico. Sin esa asimetría escrita, el siguiente proveedor negociará la suya.
La regulación regional ya escribió esa asimetría para el mercado colombiano, y vale la pena leerla como plantilla de gobierno interno aunque otro país no la exija todavía. La Resolución CREG 101 001 de 2022 no reparte el dato en partes iguales: establece que, cuando los datos de energía eléctrica tienen la calidad de datos personales, el titular es el usuario y/o suscriptor; que el responsable por su tratamiento es el comercializador del servicio; y que el operador de red y el Gestor Independiente de Datos e Información (GIDI) actúan como encargados del tratamiento (CREG, 2022).
La misma resolución asigna al operador de red la responsabilidad por la obtención de los datos necesarios para facturar, por la veracidad de la información obtenida y por su entrega al GIDI en la forma que este último determine (CREG, 2022). Es decir: hay un productor, hay un custodio, y hay una cadena de responsabilidad nominal. Ninguno de los tres roles queda librado a lo que cada proveedor asuma por su cuenta.
El GIDI cierra el esquema como custodio: la figura fue creada con la función de recopilar, administrar, mantener, procesar, publicar y transferir los datos de energía obtenidos de los medidores avanzados (CREG, 2022). Es la formalización institucional de una idea que la arquitectura interna de cualquier utility debería adoptar por decisión propia: el dato de medición tiene un custodio único y neutral frente a los fabricantes.
La identidad del dato: manda el punto de entrega
Declarar un custodio no basta si el mismo consumo llega a su puerta con tres identidades distintas.
Aquí es donde muchos proyectos multi-vendor se rompen: el fabricante A identifica la lectura por número de serie del medidor, el B por identificador de nodo de red, y IS-U la espera por punto de entrega. La consecuencia es un duplicado que ningún sistema detecta, porque técnicamente son registros diferentes.
La regla de diseño es simple y no negociable: la clave de negocio es el punto de entrega más el intervalo temporal. El número de serie es un atributo del dispositivo, no la identidad del dato. Cuando se cambia un medidor, el punto de entrega sobrevive; el número de serie no.
El estándar sectorial acompaña esta lógica. IEC 61968-9 define la integración entre sistemas de medición, sistemas MDM y el resto de los sistemas empresariales, y cubre casos de uso como lectura, controles, eventos y sincronización de datos de cliente; su edición vigente es la 3.0 (IEC, 2024).
La regulación colombiana refuerza el mismo punto por la vía del contrato de suministro: la Resolución CREG 101 001 de 2022 responsabiliza al operador de red por la interoperabilidad de todos los equipos destinados a recopilar datos, exige como mínimo la suite uno y la función de no repudio del estándar DLMS/COSEM de la norma IEC 62056, y establece que en ningún caso se aceptan soluciones que transformen el esquema basado en protocolos abiertos a protocolos cerrados o propietarios (CREG, 2022). Un fabricante que solo entrega su identificador propietario no está entregando un dato interoperable, aunque el archivo llegue puntual.
El repositorio de medición vive en un solo lugar
Con los roles escritos y la identidad resuelta, queda nombrar el lugar. La salida no es elegir un fabricante: es elegir un sistema de registro —un único lugar donde el dato de medición es oficial— y degradar todo lo demás a caché operativa o a almacenamiento técnico de corto plazo.
En un paisaje SAP, ese lugar tiene nombre. Energy Data Management (EDM) es un componente plenamente integrado de SAP S/4HANA Utilities que permite gestionar los datos de energía importados de fuentes internas y externas —perfiles y curvas de carga, entre otros— para cada punto de entrega en una base de datos central, con validación previa al procesamiento y exportación hacia componentes como facturación (SAP Learning, s.f.). El repositorio EDM admite carga desde sistemas AMR mediante BAPIs y desde sistemas externos vía IDocs, SOA o servicios disponibles en BTP (SAP Learning, s.f.).
Los adaptadores de fabricante trabajan sobre la misma premisa. Landis+Gyr describe su MDUS como una solución donde los desafíos de duplicación de datos dejan de ser un problema porque toda la información de medición inteligente se almacena en un solo lugar, y afirma que su arquitectura sigue el estándar IEC 61968-9, lo que —según el fabricante— permite integrar cualquier head-end que use ese mismo estándar (Landis+Gyr, 2025).
Lo importante no es qué producto ocupa el rol, sino que el rol exista y esté escrito. Sin esa declaración formal, cada proveedor asume por defecto que su repositorio es el bueno.
Idempotencia: la defensa técnica contra el reenvío
Aun con custodio declarado, roles escritos e identidad correcta, queda un duplicado que se genera solo: el reenvío. Un head-end reintenta una entrega tras una caída de enlace; un job de recolección se relanza; un lote se reprocesa manualmente. El mismo intervalo entra dos veces.
SAP Integration Suite resuelve esto en la capa de integración. El paso Idempotent Process Call detecta si un identificador de mensaje ya fue procesado con éxito y almacena ese estado en el repositorio idempotente del tenant; ante una ejecución duplicada con el mismo identificador, el subproceso puede omitirse o el mensaje puede marcarse como duplicado para tratamiento específico (SAP Help Portal, s.f.). Es un detalle con impacto operativo: la documentación de SAP indica que las entradas del repositorio idempotente se eliminan por defecto a los 90 días (SAP Integration Suite — Configure the SFTP Sender Adapter, documentación oficial, s.f.; SAP KBA 3074618), de modo que reprocesos históricos más antiguos que esa ventana deben controlarse en el repositorio de negocio, no en el middleware.
---
config:
theme: base
fontFamily: 'Inter Variable, system-ui, sans-serif'
themeVariables:
darkMode: true
fontFamily: 'Inter Variable, system-ui, sans-serif'
fontSize: '15px'
background: '#111113'
primaryColor: '#1A1A1D'
primaryTextColor: '#F4F5F8'
primaryBorderColor: '#00C2FF'
secondaryColor: '#242428'
tertiaryColor: '#1A1A1D'
mainBkg: '#1A1A1D'
secondBkg: '#242428'
tertiaryBkg: '#2E2E33'
lineColor: '#00C2FF'
textColor: '#F4F5F8'
titleColor: '#F4F5F8'
nodeBorder: '#00C2FF'
clusterBkg: '#1A1A1D'
clusterBorder: '#2E2E33'
edgeLabelBackground: '#242428'
pie1: '#00C2FF'
pie2: '#f59e0b'
pie3: '#22c55e'
pie4: '#59d7ff'
pie5: '#f97316'
pie6: '#ef4444'
pieTitleTextColor: '#F4F5F8'
pieSectionTextColor: '#F4F5F8'
pieLegendTextColor: '#F4F5F8'
pieStrokeColor: '#111113'
pieOuterStrokeColor: '#111113'
---
flowchart TD
A([Reenvío del mismo intervalo]) --> B{¿Identificador ya procesado con éxito?}
B -->|No| F[Se procesa y se almacena el estado en el repositorio idempotente]
F --> G([Copia oficial en el repositorio EDM])
B -->|Sí| H{Tratamiento del duplicado}
H -->|Omitir| I([Subproceso omitido])
H -->|Marcar| J([Marcado como duplicado para tratamiento específico])
F --> C[Las entradas se eliminan por defecto a los 90 días]
C --> D[Reprocesos más antiguos — control en el repositorio de negocio]
D --> E([Fuera del alcance del middleware])
classDef inicio fill:#113d4f,stroke:#00C2FF,color:#ffffff
classDef decision fill:#473519,stroke:#f59e0b,color:#ffffff
classDef proceso fill:#33363c,stroke:#9aa0aa,color:#ffffff
classDef bueno fill:#193e2b,stroke:#22c55e,color:#ffffff
classDef neutro fill:#33363c,stroke:#9aa0aa,color:#ffffff
class A inicio
class B,H decision
class C,D,F proceso
class G,I,J bueno
class E neutro
Cómo se ve una custodia que nunca se declaró
Vale la pena reconocer el síntoma, porque rara vez llega etiquetado. La duplicación del dato de medición casi nunca se aprueba en un comité de arquitectura. Se acumula.
El head-end del fabricante A guarda la curva de carga porque la necesita para diagnosticar comunicaciones. El sistema de gestión del fabricante B la guarda otra vez porque su módulo de validación opera sobre datos propios. Y SAP IS-U la recibe una tercera vez porque sin ella no hay factura. Ninguna de esas tres copias es incorrecta por sí sola; el problema es que las tres son escribibles y ninguna fue declarada como la versión oficial.
Las consecuencias aparecen en el día a día operativo, no en el diagrama:
- Reclamos de facturación donde el analista debe comparar manualmente tres fuentes antes de responder al usuario.
- Reprocesos de validación y estimación que corrigen una copia y dejan las otras dos desalineadas.
- Auditorías regulatorias en las que la empresa no puede señalar con precisión de dónde salió el valor facturado.
- Sobrecostos silenciosos: almacenamiento, licencias y horas de conciliación que se repiten con cada nuevo rollout.
El cuarto punto es el que suele destrabar el presupuesto ante la gerencia, porque crece con cada fabricante que entra a la red.
Con el custodio nombrado, los roles escritos y los duplicados contenidos, queda una pregunta abierta: cómo se detecta que esta arquitectura empezó a degradarse. Eso exige instrumentación específica, y es el tema con el que cerramos esta guía en secuencia.
Fuentes
- Landis+Gyr — MDUS SAP for Utilities Adapter (2025): https://www.landisgyr.com/nam/en/home/software/mdus-sap
- SAP Learning — Understanding the Energy Data Management Components: https://learning.sap.com/courses/configuring-device-management-in-sap-s-4hana-utilities/understanding-the-energy-data-management-components
- SAP Help Portal — Idempotent Process Call Handles Duplicates: https://help.sap.com/docs/integration-suite/sap-integration-suite/idempotent-process-call-handles-duplicates-with-alternative-response
- IEC — IEC 61968-9, Interfaces for meter reading and control, edición 3.0 (2024)
- CREG — Resolución 101 001 de 2022 (artículos 9, 10, 19, 20, 36 y 37): https://gestornormativo.creg.gov.co/gestor/entorno/docs/resolucion_creg_101-1_2022.htm
¿Este análisis mapea un mercado donde ya operas o estás evaluando entrar?
Revisamos tu caso específico, mapeamos los riesgos que aplican, y te decimos honestamente si es oportunidad para ti —sin pitch comercial, solo discusión técnica y estratégica.
