SHD0 (Transaction and Screen Variants) permet en SAP de personnaliser des transactions standard sans développement : masquer des champs, pré-remplir des valeurs, simplifier des écrans pour des profils utilisateurs spécifiques. Ce guide montre comment créer une variante de transaction étape par étape, avec un cas concret (masquer le champ « Movement allowed » dans MB21) et les pièges à éviter.
Sur 100 demandes business reçues par un consultant SAP, environ un tiers ne nécessite pas une ligne d’ABAP. Cacher un champ inutile. Préremplir un autre. Rendre un troisième obligatoire. Pour ces cas, SHD0 fait le travail. Et beaucoup de consultants ne savent pas que ça existe.
Cette transaction sert à créer des transaction variants et screen variants : des versions personnalisées d’une transaction SAP standard, sans développement spécifique. Le code SAP reste intact, l’écran s’adapte au métier. Cas concret ci-dessous, sur un projet industriel automobile, avec captures d’écran à chaque étape.
Pourquoi SHD0 plutôt qu’un développement ABAP custom ?
Beaucoup de projets démarrent avec une demande métier précise (par exemple, “on veut cacher cette case dans MB21“) et finissent par la grande porte du développement Z. Trois mois plus tard, le consultant ABAP livre une transaction ZMB21 qui fait pareil que la standard, plus une checkbox cachée. Coût : 8 jours de développement. SHD0 règle le besoin en 30 minutes, sans ligne de code, et survit aux mises à jour SAP.
SHD0 (transaction variant)
- 0 ligne d’ABAP
- 30 min de configuration
- Survit aux upgrades SAP
- Maintenable par n’importe quel consultant fonctionnel
- Coût moyen : 0,5 jour-homme
Développement Z (Z-transaction)
- 200 à 500 lignes d’ABAP
- 5 à 10 jours de dev + tests
- Risque de casse à chaque montée de version
- Maintenance par consultant ABAP uniquement
- Coût moyen : 8 à 15 jours-homme
Cas concret : MB21 sur projet automobile
Sur un projet S/4HANA chez un équipementier automobile, l’équipe maintenance utilisait la transaction MB21 pour réserver du matériel. La case “Movement Allowed” autorise les sorties de stock immédiates dès la réservation. Côté process, c’est risqué : un opérateur peut sortir le matériel avant validation par le contremaître, ce qui crée un écart de stock systémique. On l’a vu plusieurs fois en go-live.
La demande métier était précise : “Cacher cette checkbox aux opérateurs maintenance, la laisser visible uniquement au contremaître.” En standard SAP, impossible. Avec SHD0, 30 minutes de configuration et c’est réglé.
Configuration SHD0 pas-à-pas
Ouvrez la transaction SHD0. Le workflow tient en 5 étapes, avec les boutons SAP exacts à cliquer.
-
1Choisir la transaction à modifier
Saisissez le code transaction (
MB21dans notre cas) dans le champ “Transaction Code” en haut de l’écran SHD0. -
2Créer le Variant Group
Sous l’onglet “Standard Variants / Variant Groups”, saisissez un Group Name. SAP concatène avec le code transaction pour former le nom de la variante (par exemple
ZMB21_NO_MVT). Cliquez sur “Créer”. -
3Créer la Transaction Variant
Passez sous l’onglet “Transaction Variants”. Cliquez sur le bouton de création. SAP lance la transaction standard en mode “enregistrement”.
-
4Configurer le Screen Variant
Saisissez les valeurs par défaut souhaitées sur l’écran qui s’ouvre. Validez avec Entrée. SAP affiche un récapitulatif et demande de nommer le screen variant. Sur l’écran suivant, cochez “Hide” sur les champs à masquer (par exemple “Movement Allowed”).
-
5Sauvegarder dans une transport request
Cliquez sur “Exit and Save”. SAP affiche un récapitulatif final puis demande une transport request. Réutilisez la TR projet ou créez-en une nouvelle. La configuration est maintenant versionnée et prête pour le transport vers QA puis prod.
Assignation des screen variants aux utilisateurs
Le screen variant existe maintenant en système, mais il n’est pas encore appliqué automatiquement aux utilisateurs. SAP permet d’assigner un screen variant à des utilisateurs précis (nominaux ou via groupes). C’est la mécanique qui rend SHD0 plus fin qu’un système de rôles SAP.
Retournez dans “Standard Variants / Variant Groups”, sous l’onglet “User Assignment”. Saisissez le username SAP dans le champ “User”. Cliquez sur “Assign”. Cliquez ensuite sur “Set Proposal”. C’est l’étape critique : sans elle, le screen variant n’est pas appliqué automatiquement à la prochaine connexion de l’utilisateur.
Résultat attendu
L’utilisateur assigné lance MB21 normalement, par sa transaction code habituelle, sans procédure spéciale. La checkbox “Movement Allowed” est invisible. Pas de confusion possible. Le contremaître, lui, n’a pas le screen variant assigné. Il voit la checkbox standard et peut autoriser les sorties de stock validées.
En 8 ans de projets S/4HANA, je n’ai jamais vu une fonctionnalité standard SAP aussi sous-utilisée. SHD0 économise facilement 50 jours de développement Z par projet d’envergure.
Michael Antoine, fondateur Key User Training, consultant SAP EWM/Supply Chain
FAQ : SHD0 transactions et screen variants
SHD0 fonctionne-t-il sur S/4HANA ?
Oui, SHD0 est entièrement supporté sur S/4HANA (toutes versions, on-premise et Cloud Private Edition). La transaction n’a pas changé depuis ECC 6.0. C’est une compétence durable pour tout consultant SAP.
Peut-on rendre un champ obligatoire avec SHD0 ?
Oui. Au moment de la configuration des propriétés du screen variant (étape 4), cochez “Required” sur le champ concerné. SAP refusera la validation de la transaction tant que l’utilisateur n’aura pas saisi de valeur dans ce champ.
Que se passe-t-il si l’utilisateur lance la transaction sans son screen variant assigné ?
Si “Set Proposal” a bien été fait à l’assignation, le screen variant s’applique automatiquement à chaque lancement de la transaction. Sans “Set Proposal”, l’utilisateur voit la transaction standard et doit sélectionner manuellement le screen variant via le menu, ce qui défait l’intérêt de SHD0.
SHD0 vs SE93 ou SE51 : quelle différence ?
SE93 sert à créer une nouvelle transaction (avec un nouveau code Z*). SE51 est l’éditeur ABAP des écrans (dynpros) qui demande des compétences développement. SHD0 ne crée ni transaction ni écran. Il configure des variantes d’une transaction standard existante, sans toucher au code.
Les screen variants survivent-ils à une montée de version SAP ?
Oui dans la grande majorité des cas. Si SAP modifie un écran standard (ajout ou suppression de champ), le screen variant continue de fonctionner pour les champs encore présents. Les champs supprimés sont silencieusement ignorés. Une vérification post-upgrade reste recommandée sur les transactions critiques.
Comment supprimer ou modifier un screen variant existant ?
Retournez dans SHD0, saisissez la transaction code et le nom de la variante. La suppression et la modification se font via les boutons dédiés en haut de l’écran. Toute modification génère une transport request à propager vers les environnements supérieurs.
Pour aller plus loin avec SHD0
SHD0 est l’outil de pure customisation cosmétique en SAP : il ne touche ni au code applicatif, ni aux autorisations. Pour aller plus loin :
- Si tu as besoin de changer la logique métier (calcul, validation, défaut conditionnel), regarde du côté des variantes de transactions par BAdI, des field exits ou de la personnalisation par classification.
- Pour assigner une variante à un rôle utilisateur, le combo se fait via PFCG (voir notre guide sur les rôles et autorisations SAP) plus paramètres user (transaction
SU3ouOOSP). - SHD0 fonctionne aussi en S/4HANA Fiori, mais pour les apps Fiori transactionnelles, regarde plutôt les UI adaptations via le RTA (Run-Time Adaptation) Fiori.
SHD0 fait partie des transactions standards SAP qu’un consultant fonctionnel devrait maîtriser dès ses premiers projets. Pas besoin de passer par l’ABAP pour adapter une transaction au métier, et c’est exactement ce que cherchent les chefs de projet.
À lire ensuite
Job SAP : le guide key user pour SM36, SM37 et le cycle de vie
Comprendre les jobs SAP : cycle de vie en 6 statuts, création propre dans SM36 (start conditions, classes A/B/C), surveillance SM37 et lecture du job log.
Michael A.
ABAP debugger : le guide du consultant fonctionnel pour lire un programme SAP
Dump SAP, champ au mauvais montant, programme opaque : l'ABAP debugger en lecture. 4 accès, navigation F5 à F8, breakpoints et watchpoints, écran par écran.
Michael A.
Batch input SAP : guide de décision SM35, 7 pièges en prod et arbitrage avec LSMW, LTMC, BAPI et OData en 2026
Quand utiliser le batch input SAP en 2026 face à LSMW, Migration Cockpit LTMC, BAPI et OData. Comprendre SM35, SHDB, les 3 modes d'exécution et les 7 pièges qui font...
Michael A.
SHDB Transaction Recorder : guide 2026 Session Method vs Call Transaction, BDCDATA et 5 pièges en prod
Comment scripter une transaction SAP avec SHDB en 2026. Choisir entre Session Method (SM35) et Call Transaction, comprendre BDCDATA, les modes S/A/L et éviter les 5 pièges qui ruinent une...
Pierre B.