Situation Handling

O Situation Handling roda ao lado das aplicações de negócio, e não dentro da lógica delas:

1. A SAP entrega situation templates (modelos de situação) para casos de uso como contratos prestes a vencer ou faturas com desconto financeiro em risco. Um key user copia um modelo em um situation type (tipo de situação).
2. A detecção começa a partir de uma execução em batch agendada ou de eventos de negócio, como criado, alterado ou excluído. Situações baseadas em mensagens reagem a erros e avisos de execuções do sistema.
3. O framework verifica os dados do objeto disparador e, no framework estendido, também do objeto âncora, em relação às condições configuradas.
4. Se as condições forem atendidas, uma situation instance (instância de situação) é criada, e o Responsibility Management determina quem é responsável.
5. Os usuários são alertados por notificações do launchpad, e-mail, My Home ou uma mensagem dentro do app de negócio, e podem abrir uma página da situação com contexto e ações.

O Situation Handling, portanto, informa as pessoas sobre exceções; resolvê-las continua sendo uma decisão humana.

A comparação segue a documentação da SAP para o SAP S/4HANA Cloud Public Edition; a documentação on-premise confirma situações customizadas, modelos baseados em mensagem e transporte para o framework estendido, então verifique os detalhes de agendamento e de ações para a sua release. A Reference Library lista os apps estendidos a partir do SAP S/4HANA 2021. Os dois frameworks podem rodar em paralelo, e o estendido é a escolha quando situações customizadas ou transportes são importantes.

Pontos fortes

• Nenhuma alteração na lógica da aplicação: o framework é fracamente acoplado, então adotar um modelo não modifica o processo de negócio.
• Casos de uso entregues: muitos modelos em finanças, compras, vendas e outras áreas funcionam após a configuração.
• Monitoramento: o Monitor Situations (F3264) mostra o ciclo de vida das situações e ajuda a identificar as recorrentes.

Onde ele para

• Não é em tempo real. Execuções em batch e o processamento de eventos podem atrasar a detecção em relação à transação.
• Escala humana. A SAP limita os volumes de detecção ao que as pessoas conseguem processar e desaconselha o uso do Situation Handling como ferramenta principal para casos críticos em tempo, críticos para a vida ou relevantes para a segurança.
• Informa, não roteia. Não há função de encaminhamento nem fluxo de aprovação; os workflows tratam etapas sequenciadas.

O Situation Handling cobre exceções de processo dentro do SAP S/4HANA, não o processo de ponta a ponta ao redor delas.

A própria orientação da SAP aponta primeiro para o Responsibility Management:

1. Destinatários. Verifique a seção Recipients do situation type. Seja com equipes ou com regras de responsabilidade, o usuário precisa ser membro com a função e os valores de responsabilidade corretos.
2. Tipo habilitado. O situation type precisa estar ativo, e as condições precisam corresponder a dados reais; filtros restritos demais nunca disparam.
3. Detecção executada. Para tipos baseados em batch, confirme que o job de batch rodou; para tipos baseados em eventos, confirme que o evento é disparado.
4. Canal de exibição. Mensagens dentro do app aparecem apenas em apps que incluem o Situation Handling; as preferências de notificação e as configurações de e-mail decidem os demais canais. On-premise e no Private Edition, as notificações do launchpad também exigem o canal de notificação do SAP Fiori e as configurações de Customizing relacionadas.

Um erro frequente é construir o situation type antes de as equipes existirem. Notificações de situação ausentes costumam ser problemas de dados de responsabilidade, não defeitos do framework.