Situation Handling

Situation Handling funciona junto a las aplicaciones de negocio, no dentro de su lógica:

1. SAP entrega plantillas de situación para casos de uso como contratos que vencen o facturas con descuento por pronto pago en riesgo. Un key user copia una plantilla en un tipo de situación.
2. La detección se inicia a partir de una ejecución batch planificada o de eventos de negocio como creado, modificado o eliminado. Las situaciones basadas en mensajes reaccionan a errores y advertencias de ejecuciones del sistema.
3. El framework comprueba los datos del objeto desencadenante, y en el framework ampliado también los del objeto ancla, frente a las condiciones configuradas.
4. Si se cumplen las condiciones, se crea una instancia de situación y Responsibility Management determina quién es responsable.
5. Los usuarios reciben avisos mediante notificaciones del launchpad, correo electrónico, My Home o un mensaje dentro de la aplicación de negocio, y pueden abrir una página de situación con contexto y acciones.

Por tanto, Situation Handling informa a las personas sobre las excepciones; resolverlas sigue siendo una decisión humana.

La comparación sigue la documentación de SAP para SAP S/4HANA Cloud Public Edition; la documentación on-premise confirma las situaciones personalizadas, las plantillas basadas en mensajes y el transporte para el framework ampliado, así que compruebe los detalles de planificación y de acciones para su release. La Reference Library registra las aplicaciones ampliadas a partir de SAP S/4HANA 2021. Ambos frameworks pueden funcionar en paralelo, y el ampliado es la opción adecuada cuando importan las situaciones personalizadas o los transportes.

Fortalezas

• Sin cambios en la lógica de la aplicación: el framework está débilmente acoplado, de modo que adoptar una plantilla no modifica el proceso de negocio.
• Casos de uso entregados: muchas plantillas de finanzas, compras, ventas y otras áreas funcionan tras su configuración.
• Supervisión: Monitor Situations (F3264) muestra el ciclo de vida de las situaciones y ayuda a detectar las recurrentes.

Dónde termina su alcance

• No es tiempo real. Las ejecuciones batch y el procesamiento de eventos pueden retrasar la detección respecto a la transacción.
• Escala humana. SAP limita los volúmenes de detección a lo que las personas pueden procesar y desaconseja usar Situation Handling como herramienta principal para casos críticos en tiempo, críticos para la vida o relevantes para la seguridad.
• Informa, no enruta. No hay función de reenvío ni flujo de aprobación; los workflows se encargan de los pasos secuenciados.

Situation Handling cubre las excepciones de proceso dentro de SAP S/4HANA, no el proceso de extremo a extremo que las rodea.

Las propias indicaciones de SAP apuntan primero a Responsibility Management:

1. Destinatarios. Revise la sección Recipients del tipo de situación. Tanto si usa equipos como reglas de responsabilidad, el usuario debe ser miembro con la función y los valores de responsabilidad correctos.
2. Tipo habilitado. El tipo de situación debe estar activo y las condiciones deben coincidir con datos reales; los filtros demasiado restrictivos nunca se disparan.
3. La detección se ejecutó. En los tipos basados en batch, confirme que el job batch se ejecutó; en los tipos basados en eventos, confirme que el evento se lanza.
4. Canal de visualización. Los mensajes dentro de la aplicación solo aparecen en las aplicaciones que incluyen Situation Handling; las preferencias de notificación y la configuración del correo electrónico deciden los demás canales. En on-premise y en Private Edition, las notificaciones del launchpad también necesitan el canal de notificaciones de SAP Fiori y los ajustes de Customizing correspondientes.

Un error frecuente es construir el tipo de situación antes de que existan los equipos. Las notificaciones de situaciones que faltan suelen ser problemas de datos de responsabilidad, no defectos del framework.