Situation Handling

Situation Handling s'exécute à côté des applications métier plutôt qu'au sein de leur logique :

1. SAP livre des modèles de situation pour des cas d'usage comme les contrats arrivant à expiration ou les factures dont l'escompte est menacé. Un key user copie un modèle dans un type de situation.
2. La détection démarre soit à partir d'une exécution batch planifiée, soit à partir d'événements métier comme la création, la modification ou la suppression. Les situations basées sur des messages réagissent aux erreurs et avertissements des exécutions système.
3. Le framework compare les données de l'objet déclencheur, et dans le framework étendu également celles de l'objet d'ancrage, aux conditions configurées.
4. Si les conditions sont remplies, une instance de situation est créée, et Responsibility Management détermine qui est responsable.
5. Les utilisateurs sont alertés par des notifications du launchpad, par e-mail, via My Home ou par un message dans l'application métier, et peuvent ouvrir une page de situation présentant le contexte et les actions.

Situation Handling informe donc les personnes des exceptions ; leur résolution reste une décision humaine.

La comparaison suit la documentation de SAP pour SAP S/4HANA Cloud Public Edition ; la documentation on-premise confirme les situations personnalisées, les modèles basés sur des messages et le transport pour le framework étendu ; vérifiez donc les détails de planification et d'actions pour votre release. La Reference Library référence les applications étendues à partir de SAP S/4HANA 2021. Les deux frameworks peuvent fonctionner en parallèle, et le framework étendu s'impose lorsque les situations personnalisées ou les transports comptent.

Atouts

• Aucune modification de la logique applicative : le framework est faiblement couplé, si bien qu'adopter un modèle ne modifie pas le processus métier.
• Cas d'usage livrés : de nombreux modèles en finance, achats, ventes et dans d'autres domaines fonctionnent après configuration.
• Supervision : Monitor Situations (F3264) affiche le cycle de vie des situations et aide à repérer celles qui se répètent.

Où il s'arrête

• Pas de temps réel. Les exécutions batch et le traitement des événements peuvent retarder la détection par rapport à la transaction.
• À l'échelle humaine. SAP plafonne les volumes de détection à ce que les personnes peuvent traiter et déconseille d'utiliser Situation Handling comme outil principal pour les cas critiques en termes de délai, de vie humaine ou de sécurité.
• Informe, sans acheminer. Il n'existe ni fonction de transfert ni circuit d'approbation ; les workflows gèrent les étapes séquencées.

Situation Handling couvre les exceptions de processus au sein de SAP S/4HANA, pas le processus de bout en bout qui les entoure.

Les recommandations de SAP renvoient d'abord à Responsibility Management :

1. Destinataires. Vérifiez la section Recipients du type de situation. Qu'elle utilise des équipes ou des règles de responsabilité, l'utilisateur doit être membre avec la bonne fonction et les bonnes valeurs de responsabilité.
2. Type activé. Le type de situation doit être actif, et les conditions doivent correspondre à des données réelles ; des filtres trop restrictifs ne se déclenchent jamais.
3. Détection exécutée. Pour les types basés sur un batch, confirmez que le job batch s'est exécuté ; pour les types basés sur des événements, confirmez que l'événement est déclenché.
4. Canal d'affichage. Les messages intégrés n'apparaissent que dans les applications qui intègrent Situation Handling ; les préférences de notification et les paramètres d'e-mail déterminent les autres canaux. En on-premise et en Private Edition, les notifications du launchpad nécessitent aussi le canal de notification SAP Fiori et les paramètres de Customizing associés.

Une erreur fréquente consiste à construire le type de situation avant que les équipes existent. L'absence de notifications de situation relève généralement de problèmes de données de responsabilité, pas de défauts du framework.