Lors d’un projet d’implémentation S4H, nous avons mis en place la solution Contrat de Négoce de SAP.
Cette solution est intéressante fonctionnellement car elle permet de gérer à un seul endroit la partie vente et la partie achat.
Mais ce n’est pas de cela que je vais vous parler mais plutôt du workflow qui l’accompagne.
Il s’agit de mon premier workflow sur les contrats de négoce et j’ai voulu partager mon expérience .
Avant tout sachez qu’il existe aujourd’hui peu de documentation sur ce sujet.
Le workflow est basé sur des statuts et avec une BADI de contrôle .
Il y a pour ce workflow une grosse partie de paramétrage.
Le menu pour accéder au paramétrage est WB2B_CUS
l faut commencer par activer les composants pour que le workflow soit pris en compte.
L’un des gros soucis des statuts dans cette application est qu’il ne correspondent en rien a ce que l’on connait dans SD ou PS par exemple.
Il existe des Statuts Applications, Statut Système et Statut Utilisateur.
En tant que client nous nous attendons a une gestion de ces statuts dans la JEST il n’en est rien.
Les seuls statuts que nous pouvons créer sont les statuts Application.
Il existe des incompatibilités entre ces différents statuts mais elles ne sont pas documentées, il faut donc tâtonner.
Première chose, il faut créer un groupe de statut, on y regroupe les statuts applicatifs.
L’événement workflow TOBERELEASED doit être assigné (ici pur A Valider).
Ce que j’ai pu remarquer c’est que si il y a une modification après validation, et que l’on souhaite relancer un workflow alors l’événement indiqué ici n’est d’aucune utilité (cela ne fonctionnait ni sur le statut applicatif K ou sur le L).
Les statuts standards doivent tous être assignés sinon il y aura une erreur.
Ce contrôle, vous permettra d’éviter des tests sans succès, dès que vous faites un changement dans les statuts, lancez le contrôle.
Vous la trouverez dans le menu de paramétrage, servez vous de l’aide fournie sur le point de paramétrage pour mieux comprendre comment elle fonctionne.
A noter, que juste au dessus les points de paramétrage servent pour l’application FIORI, au moment ou j’écris ces lignes l’application FIORI n’est utilisable que dans ECC, nous faisions une implémentation S4H et l’application n’existe pas.
Nous avons donc créé un workflow basé sur une tâche de décision avec un lien WEB Gui sur l’objet BUS2124 joint a la tâche.
Dans cette BADI je vous invite également a vous servir de la classe
cl_wb2_wf_approval_control qui est une classe utilitaire qui vous permettra de mieux contrôler le lancement du workflow (avec la méthode
send_approve_event) .
Il existe plusieurs workflows sur l’objet BUS2124
WS03100022 pour la release du contrat
WS03100024 pour modifier le contrat
WS03100027 pour afficher le contrat
Aucun de ces workflows ne m’a donné satisfaction pour l’approbation des contrats.
J’ai donc opté pour faire le mien.
Avec la transaction SWDM, j’ai trouvé deux tâches inintéressantes
Ces deux tâches après une tâche de décisions sont celles qui me sont nécessaires pour une simple validation.
Seul problème la méthode ApprovalWithSuccess est une méthode d’arrière plan mais la tâche ne l’est pas.
Il faut donc créer votre propre tâche qui elle acceptera les traitements en arrière-plan, ne modifiez pas le standard.
Une simple copie de cette tâche suffira.
Le besoin client était plutôt simple, une seule validation donc le workflow est très simple.
La dernière étape pour mettre ce workflow en place… Transaction SWE2.
Et voilà votre workflow d’approbation sur les contrats de négoce est prêt à être lancé.