SOA Manager: el puente que lleva la cuenta contractual al caso

Antes de firmar el go-live de una integración entre SAP S/4HANA Utilities y SAP Service Cloud Version 2 conviene hacer una prueba sencilla: modificar una cuenta contractual de prueba en el core y comprobar que el cambio llega a Service Cloud. Cuando no llega, la causa puede no estar en la pantalla del agente, sino un nivel más abajo: en un servicio consumidor de S/4HANA que nadie terminó de configurar en SOA Manager, o en una réplica delta que nunca se activó.

---
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: '#8B5CF6'
    secondaryColor: '#242428'
    tertiaryColor: '#1A1A1D'
    mainBkg: '#1A1A1D'
    secondBkg: '#242428'
    tertiaryBkg: '#2E2E33'
    lineColor: '#8B5CF6'
    textColor: '#F4F5F8'
    titleColor: '#F4F5F8'
    nodeBorder: '#8B5CF6'
    clusterBkg: '#1A1A1D'
    clusterBorder: '#2E2E33'
    edgeLabelBackground: '#242428'
    pie1: '#8B5CF6'
    pie2: '#f59e0b'
    pie3: '#22c55e'
    pie4: '#b495f9'
    pie5: '#f97316'
    pie6: '#ef4444'
    pieTitleTextColor: '#F4F5F8'
    pieSectionTextColor: '#F4F5F8'
    pieLegendTextColor: '#F4F5F8'
    pieStrokeColor: '#111113'
    pieOuterStrokeColor: '#111113'
---
flowchart TD
  A([Prueba antes del go-live]) --> B[Modificar una cuenta contractual de prueba en el core]
  B --> C{¿El cambio llega a Service Cloud?}
  C -->|Sí| D([Réplica delta activa])
  C -->|No| E[La causa puede estar un nivel más abajo]
  E --> F([Servicio consumidor sin terminar de configurar en SOA Manager])
  E --> G([Réplica delta que nunca se activó])
  class A inicio
  class C decision
  class B,E proceso
  class D bueno
  class F,G malo
classDef inicio fill:#30274d,stroke:#8B5CF6,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 malo fill:#462226,stroke:#ef4444,color:#ffffff

Esta pieza trata ese nivel. Qué hay que dejar listo en SOA Manager, quién suele hacerlo, qué más tiene que existir en S/4HANA antes de que la nube reciba un solo mensaje y cómo comprobar que todo quedó operativo.

SOA Manager, el eslabón que queda entre dos equipos

El servicio outbound en SOA Manager define el canal técnico por el que la cuenta contractual sale de S/4HANA hacia la capa de integración. En S/4HANA, un servicio consumidor necesita una configuración de runtime en SOA Manager para poder ejecutar sus llamadas (SAP Support, KBA 2033184). Sin esa configuración, el servicio existe en el sistema pero no tiene por dónde enviar nada.

Ese paso cae en una zona de frontera dentro del proyecto. La configuración del lado de S/4HANA suele quedar en manos del equipo de Basis o de integración del core, mientras que la de Service Cloud la trabaja el equipo de experiencia del cliente. Si el servicio outbound no está listo, el trabajo en la nube no tiene mensajes que procesar, y el retraso aparece en el frente equivocado. En las utilities de la región, donde ambos equipos suelen reportar a áreas distintas, conviene nombrar desde el inicio a un responsable de este eslabón.

Del lado técnico, un consultor que documentó la integración con Service Cloud Version 2 identifica el servicio web de cuenta contractual como CO_FKK_MDG_CONTRACT_ACCOUNT_BU. También advierte que la réplica de cuenta contractual cambió respecto de la versión anterior de la solución (SAP Community, 2024). El mismo autor señala como prerrequisito el componente de software IS-UT 808 (SAP Community, 2024).

Son referencias de campo, no una tabla oficial. Para confirmar nombres de servicios, integration flows y rutas, ese autor remite a la nota SAP 3253818, que reúne los detalles técnicos de la integración (SAP Community, 2024).

Tres bloques antes del primer mensaje

La preparación de S/4HANA para la réplica de cuentas contractuales puede leerse en tres bloques: la creación del servicio outbound en SOA Manager, la configuración del data replication framework para esa réplica y la configuración de la réplica delta. Cada bloque responde una pregunta distinta:

• Por dónde sale el mensaje. El servicio outbound configurado en SOA Manager, descrito en la sección anterior.
• Qué se envía y a quién. En el modelo de SAP, el data replication framework enlaza, mediante un modelo de réplica, las implementaciones outbound con los sistemas de negocio destino y define cómo se envían los objetos (SAP Learning, 2026).
• Cuándo se vuelve a enviar. La réplica delta es la que mantiene al día la cuenta contractual en Service Cloud después de la carga inicial, enviando los cambios posteriores que ocurren en el core.

El tercer bloque es el que más se subestima. Una carga inicial exitosa deja una foto de la cuenta contractual en el momento del go-live. Si la réplica delta no queda activa, los cambios posteriores en el core no llegan a Service Cloud. El agente vuelve entonces a trabajar con una cuenta contractual que ya no coincide con la que usa facturación, y la disputa se alarga. La prueba del inicio de esta pieza existe justamente para detectar ese caso antes de que lo detecte un cliente.

Un detalle de nomenclatura evita errores difíciles de diagnosticar. En la configuración del data replication framework para Service Cloud Version 2, el nombre del sistema de negocio debe coincidir exactamente con el ID de sistema de Service Cloud (SAP Learning, 2026). SAP lo documenta para la réplica de business partners y productos. Conviene aplicar la misma disciplina al configurar la cuenta contractual y validarla contra la guía de utilities.

Del core a Service Cloud: los tramos de la integración

El servicio outbound de cuenta contractual se configura dentro de S/4HANA, que actúa como emisor en la réplica de cuentas contractuales hacia SAP Service Cloud Version 2 (SAP Business Accelerator Hub, 2022). A partir de ahí, el recorrido documentado tiene tres tramos:

En SAP Cloud Integration, el integration flow de cuenta contractual tiene a S/4HANA como emisor y a Service Cloud Version 2 como receptor. En el receptor corresponde al escenario «Replicate Contract Account from SAP S/4HANA» (SAP Business Accelerator Hub, 2022). En Service Cloud Version 2, ese escenario se elige entre las configuraciones inbound relevantes para el alcance del proyecto (SAP Business Accelerator Hub, 2022). Esas instrucciones son de 2022: conviene contrastar los nombres de integration flows y escenarios con la edición vigente de la guía en SAP Help Portal antes de configurar.

Hay dos requisitos de la capa intermedia que conviene anticipar en el plan:

• Acceso a un tenant de SAP Cloud Integration. La guía lo lista entre los prerrequisitos (SAP Business Accelerator Hub, 2022). Para una utility que todavía no opera esa plataforma, el aprovisionamiento debe resolverse antes de la configuración, no durante.
• Gestión de certificados. El certificado de cliente descargado de S/4HANA o de Service Cloud Version 2 debe cargarse en el keystore del tenant de Cloud Integration (SAP Business Accelerator Hub, 2022). En muchas utilities de la región, los certificados pasan por un área de seguridad distinta a la del proyecto, así que este paso merece su propio responsable y su propia fecha.

Lista de verificación antes de firmar

Antes de dar por cerrada la habilitación, el equipo de proyecto puede recorrer una verificación corta:

• El servicio outbound de cuenta contractual existe en SOA Manager, con su puerto lógico configurado hacia el sistema correcto.
• El integration flow de réplica de cuenta contractual está desplegado. La guía indica que su estado debe verse en verde tras un despliegue exitoso (SAP Business Accelerator Hub, 2022).
• La configuración inbound «Replicate Contract Account from SAP S/4HANA» está seleccionada en Service Cloud Version 2.
• La réplica delta está activa: una modificación de prueba sobre una cuenta contractual del core aparece luego en Service Cloud.
• El equipo tiene a mano la nota SAP 3253818 como referencia de nombres de servicios e integration flows.

Esta pieza continúa la anterior de la serie, que distinguió qué datos del core se replican y cuáles se consultan en vivo; aquí el foco fue el paso de configuración que hace posible esa réplica. En la próxima veremos qué hace el agente con ese dato: cómo el historial de pagos a la vista permite resolver la disputa de factura en la primera llamada.

Fuentes

• SAP Help Portal (2026). SAP Service Cloud Version 2 Utilities Integration with SAP S/4HANA. https://help.sap.com/doc/5a8595a8165648f287464b1a7d63de3f/CSS_SHIP/en-US/dce87b149e2645a2ba7f8ba4efa4ad51.pdf
• SAP Business Accelerator Hub (2022). Set-Up Instructions: SAP Service Cloud Version 2 for Utilities Integration with SAP S/4HANA. https://api.sap.com/odata/1.0/catalog.svc/Files(‘02bae95d99784ab4865d761f7da33a37’)/$value
• SAP Community (2024). Blog Series- 1: SAP C4C Service cloud V2 integration with S4 Hana Utility (ISU). https://community.sap.com/t5/crm-and-cx-blog-posts-by-members/blog-series-1-sap-c4c-service-cloud-v2-integration-with-s4-hana-utility-isu/ba-p/13732254
• SAP Learning (consultado 2026). Preparing Technical Communication Settings in SAP S/4HANA. https://learning.sap.com/learning-journeys/integrating-sap-sales-cloud-and-sap-service-cloud-version-2-with-sap-s-4hana/preparing-technical-communication-settings-in-sap-s-4hana
• SAP Support (consultado 2026). KBA 2033184 - ESI - How to create a Logical Port manually for a Service Consumer in SOAMANAGER. https://userapps.support.sap.com/sap/support/knowledge/en/2033184