Prerrequisitos IS-U: qué activar antes de sincronizar AMI

Un rollout de medición avanzada en una distribuidora de América Latina suele avanzar por dos carriles que casi nunca se cruzan a tiempo. En el carril de campo, las cuadrillas instalan medidores y el proveedor levanta su sistema de cabecera. En el carril de sistemas, alguien asume que SAP IS-U “ya está listo” porque el módulo de gestión de dispositivos existe desde hace años. El choque llega el día en que se lanza la primera sincronización masiva y el sistema devuelve menos dispositivos de los esperados —o ninguno— sin que nadie sepa explicar por qué.

En la entrega anterior de esta serie describimos qué resuelve la capa de Meter Data Unification & Synchronization (MDUS) y por qué existe. Esta pieza baja un nivel: qué debe estar activado y replicado dentro de IS-U antes de que esa capa tenga con quién hablar. No es una lista de deseos de arquitectura; es un conjunto de prerrequisitos documentados que, si se omiten, no fallan con un error claro, sino con silencio.

Las funciones de negocio son el primer prerrequisito, y no tienen vuelta atrás

SAP es explícito en este punto. Para cargar datos de perfil desde un sistema externo —como el sistema MDUS— hacia el sistema IS-U, es necesario haber activado las funciones de negocio Advanced Metering Infrastructure 1, 2 y 3 (ISU_AMI_1, ISU_AMI_2 e ISU_AMI_3), haber replicado los datos maestros de dispositivo mediante la actividad masiva de sincronización AMI (EAMISYNC) para alinear las entradas de IS-U con las de los sistemas externos, y haber replicado las cabeceras de perfil con la transacción Profile Synchronization for AMI (EAMIPROFSYNC) (SAP Learning, 2026).

Cada una de esas funciones arrastra dependencias propias. ISU_AMI_1 exige tener activada previamente la función Utilities, General Enhancements (ISU_UTIL_1), y habilita el envío de órdenes de lectura al MDUS y la recepción de resultados desde el MDUS (SAP Help Portal, consultado 2026). ISU_AMI_2 es la que pone a disposición el monitor de comunicación AMI, con el que se visualizan los datos formateados del log de comunicación de servicios y se confirman las entradas erróneas (SAP Learning, 2026). Existen además funciones posteriores del mismo bloque: ISU_AMI_5, por ejemplo, entrega la Simplified Master Data Synchronization en el entorno AMI y exige tener activo el conjunto de funciones de negocio Utilities (SAP Help Portal, consultado 2026).

Aquí aparece el punto de gobierno que más se subestima: la activación no es un experimento. Por razones técnicas, activar una función de negocio escribe datos, ejecuta pasos de proceso y cambia interfaces, de modo que la gran mayoría no son reversibles; las pocas reversibles solo pueden desactivarse en sistemas de desarrollo o prueba, nunca en productivo (SAP Help Portal, consultado 2026). Y la activación en sí es una intervención planificada: se detienen los jobs batch, se cierra el sistema al resto de usuarios y el trabajo de fondo tarda del orden de 30 a 120 minutos, con actividades comparables a instalar un add-on de forma manual (SAP Help Portal, consultado 2026).

Para una distribuidora que factura por ciclos y opera con ventanas de mantenimiento estrechas, eso convierte la activación en un ítem de cronograma con dueño, no en una tarea Basis de última hora.

Replicar el maestro de dispositivos: qué hace realmente EAMISYNC

---
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([Actividad sobre el dispositivo en SAP for Utilities]) --> B{¿Es posible la sincronización automática?}
  B -->|Sí| C[Servicios empresariales replican, notifican y crean datos maestros]
  C --> D[Cada llamada queda registrada en una tabla dedicada]
  D --> E([Maestro de dispositivo replicado en el MDUS])
  B -->|No| F[EAMISYNC como actividad masiva y programable]
  F --> G[Corrida en simulación: cuántos dispositivos AMI entran]
  G --> H[Ejecución en firme vía BAdI ISU_AMI_DEVICE_MDE]
  H --> I([Entradas de IS-U alineadas con las de los sistemas externos])
  class A inicio
  class B decision
  class C,D,F,G,H proceso
  class E,I bueno
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

En una infraestructura de medición avanzada, el intercambio de datos maestros (MDE) queda habilitado automáticamente entre el back end de SAP y el sistema MDUS, y la información relacionada con ciertas actividades del dispositivo se transmite hacia ese sistema (SAP Learning, 2026). Servicios empresariales dedicados ejecutan la replicación, la notificación y la creación de los datos maestros del medidor avanzado; una sola acción puede disparar varios servicios, y cada llamada queda registrada en una tabla dedicada que permite verificar el éxito de la operación e identificar el origen de cualquier error (SAP Learning, 2026).

Cuando la sincronización automática no es posible —porque los datos ya existían, porque la conexión no estaba disponible o porque el dispositivo se dio de alta antes de que el MDUS existiera— entra EAMISYNC. Es una actividad masiva que permite sincronizar múltiples dispositivos entre IS-U y el MDUS, en simultáneo o en jobs de fondo separados, y admite programación. Internamente selecciona los dispositivos adecuados y utiliza el BAdI ISU_AMI_DEVICE_MDE para invocar el servicio de replicación; la casilla de ejecución en simulación permite ver cuántos dispositivos AMI entrarían antes de correr en firme (SAP Help Portal, consultado 2026).

Ese modo simulación es el control operativo que hay que institucionalizar. En un escenario multi-vendor —el escenario real de esta región, donde cada lote de medidores llega con su propio proveedor— el número de dispositivos que la simulación devuelve es el primer indicador honesto de si el maestro de IS-U y el inventario del proveedor están hablando del mismo parque.

Perfiles: el paso que se descubre tarde

La replicación de dispositivos no alcanza. Falta la capa de perfiles, y es donde más proyectos se detienen. La transacción Profile Synchronization for AMI (EAMIPROFSYNC) es una actividad masiva diseñada para replicar las asignaciones existentes entre perfiles y registros de los medidores avanzados en el sistema MDUS; las asignaciones pueden replicarse en función de atributos como perfil, dispositivo, sistema de medición avanzada y rol de perfil, y al ser actividad masiva soporta grandes volúmenes y permite fijar fecha y hora de ejecución (SAP Help Portal, consultado 2026).

Conviene detenerse en ese atributo: sistema de medición avanzada. Es, literalmente, la palanca que permite segmentar la sincronización por proveedor. Quien planifica la integración pensando en un solo sistema de cabecera rara vez lo usa; quien ya convive con dos rollouts distintos lo necesita desde el primer día.

Hay un matiz adicional que cambia el diseño: los valores de perfil no tienen que residir necesariamente en SAP para poder facturarse. Pueden gestionarse en el sistema MDUS como parte de la infraestructura de medición avanzada, y durante la facturación se determinan mediante una solicitud al MDUS (SAP Help Portal, consultado 2026). Eso desplaza la pregunta de arquitectura desde “¿dónde guardo los intervalos?” hacia “¿qué tan confiable es la ruta que los pide en el momento de facturar?”.

Por qué este orden pesa más en América Latina

La región dejó de ser un mercado de pilotos. La penetración de medidores eléctricos inteligentes en América Latina y el Caribe era de 7,7 % en 2024, con un parque instalado de 17,3 millones de unidades que se proyecta hacia 61,3 millones en 2030 —equivalentes a una penetración de 24,8 %— con una tasa de crecimiento anual compuesta de 23,5 % (Berg Insight, 2026). Las nuevas instalaciones estarán impulsadas sobre todo por Brasil y México, mientras que países como Argentina, Colombia, Ecuador y Perú aumentarán su participación en los envíos anuales de la región (Berg Insight, 2026).

Ese ritmo tiene una consecuencia directa: casi ninguna distribuidora terminará su despliegue con un solo proveedor. Los lotes se adjudican por licitación, en años distintos y con tecnologías distintas. Cuando la recaudación y el control de pérdidas no técnicas dependen de que el dato llegue completo, un maestro de dispositivos desalineado no se manifiesta como una falla de sistema: se manifiesta como facturación estimada, reclamos y ajustes manuales que nadie atribuye a una función de negocio sin activar.

Lista de verificación antes del pase a producción

• Confirmar que ISU_UTIL_1 y el conjunto de funciones Utilities están activos antes de planificar cualquier función AMI.
• Documentar qué funciones ISU_AMI se activarán, con qué dependencias y en qué ventana; tratarlas como cambio irreversible.
• Ejecutar EAMISYNC en modo simulación y contrastar el conteo contra el inventario del proveedor antes de la corrida en firme.
• Verificar el log de comunicación de servicios y confirmar las entradas erróneas con el monitor habilitado por ISU_AMI_2.
• Planificar EAMIPROFSYNC segmentado por sistema de medición avanzada, no en una única corrida global.
• Decidir explícitamente qué valores de perfil viven en SAP y cuáles se resolverán por solicitud al MDUS durante la facturación.

Con los prerrequisitos resueltos, IS-U ya tiene una identidad consistente de cada dispositivo y de cada perfil. La siguiente pregunta —y la siguiente entrega de esta serie— es cómo configurar la capa de integración para que acepte más de un sistema de cabecera sin duplicar esa identidad.

Fuentes

• SAP Learning — Configuring Device Management in SAP S/4HANA Utilities: Understanding Advanced Meter Infrastructure (2026). https://learning.sap.com/courses/configuring-device-management-in-sap-s-4hana-utilities/understanding-advanced-meter-infrastructure
• SAP Help Portal — Advanced Metering Infrastructure (business function ISU_AMI_1). https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/58ae574d7f4049a4a7e4f65901729f2a/eb75df7f40b741869203c56b5563b415.html
• SAP Help Portal — Utilities, Advanced Metering Infrastructure 5 (Simplified Master Data Synchronization). https://help.sap.com/docs/SAP_ERP/8885dc274cc4489aa3dd28ac0a9bfa10/164068550110f268e10000000a44147b.html
• SAP Help Portal — Deactivating Business Functions (documentación de SAP NetWeaver 7.1; el comportamiento descrito sigue vigente). https://help.sap.com/doc/saphelp_aii710/7.1/en-US/35/1b33b3e7764177a3218ae08f6637f0/content.htm
• SAP KBA 1641394 — SFW5: How-to activate Business Function (referencia vigente, release independent). https://userapps.support.sap.com/sap/support/knowledge/en/1641394
• SAP Help Portal — Switching on Business Functions. https://help.sap.com/docs/ABAP_PLATFORM_NEW/1d51ac4c098042528cadb1d5bcb1ab23/de899442047b0831e10000000a1550b0.html
• Berg Insight — Smart Metering in Latin America and the Caribbean, 3ª edición (enero 2026), autor Felix Linderum. https://media.berginsight.com/2026/01/20162133/bi-smla3-ps.pdf