SM30 : maintenir une table de paramétrage SAP sans développeur (et quand passer par SM31 ou SE11)

Un consultant me transfère une copie d’écran : « Michael, le client veut ajouter trois lignes dans une table de paramétrage, et l’équipe technique annonce deux jours de développement. C’est normal ? » Non, ce n’est pas normal. Dans neuf cas sur dix, ce genre de mise à jour se fait en quelques minutes avec SM30, sans toucher une ligne d’ABAP et sans mobiliser un développeur. Le réflexe « il faut un dev » coûte du temps et de l’argent pour rien, simplement parce que personne n’a pris dix minutes pour expliquer ce que fait vraiment la transaction SM30, là où elle s’arrête, et à partir de quand il faut effectivement appeler quelqu’un.

Cet article remet ces gestes dans le bon ordre. Vous allez voir comment maintenir une table de paramétrage avec SM30, comment savoir si SM30 suffit ou s’il faut basculer sur SM31, SE11 ou SE16N, et surtout comment ne rien casser : le bon mandant, la demande de transport, les autorisations. C’est le quotidien d’un key-user qui sait travailler proprement.

SM30, c’est quoi ? (Call View Maintenance en clair)

SM30 est la transaction de Call View Maintenance : elle ouvre le dialogue de maintenance d’une table ou d’une vue SAP pour en afficher et modifier les données. Concrètement, vous saisissez le nom d’une table dans l’écran de SM30, et SAP vous présente une grille où vous pouvez ajouter, modifier ou supprimer des entrées, comme dans un tableur encadré.

Le mot important, c’est « encadré ». SM30 n’ouvre pas la table en accès brut : elle passe par un dialogue de maintenance généré, c’est-à-dire un petit programme et un écran que SAP a créés spécifiquement pour cette table. Ce générateur s’appelle le Table Maintenance Generator (générateur de maintenance de table, ou TMG). C’est lui qui décide quels champs sont visibles, lesquels sont modifiables, et quels contrôles s’appliquent à la saisie.

Conséquence directe, et c’est la première chose à retenir : une table n’est maintenable en SM30 que si elle possède un générateur de maintenance. Si la table n’en a pas, SM30 vous renverra un message du type « la maintenance n’est pas autorisée » ou « pas de générateur de maintenance pour cette table ». Ce n’est pas une erreur de votre part, c’est simplement que personne n’a généré le dialogue côté Dictionnaire ABAP (on y revient avec SE11).

Dernier point de vocabulaire, parce qu’il évite beaucoup de confusions : SM30 sert surtout aux données de paramétrage (customizing) : les tables qui pilotent le comportement du système, pas les données métier transactionnelles comme une commande ou une livraison. Maintenir une table de customizing et créer une commande client, ce sont deux gestes de natures très différentes, même si l’écran ressemble à une grille dans les deux cas.

Maintenir une table avec SM30, étape par étape

Voici le déroulé standard pour ajouter ou modifier une entrée. Rien de sorcier, mais chaque étape a son rôle.

1. 1
   Vérifiez d’abord votre mandant

   Vous êtes connecté à un mandant précis (le client SAP). Une table de customizing modifiée dans un mandant ne se propage pas magiquement aux autres : c’est le transport qui s’en charge. Avant toute saisie, assurez-vous d’être dans le bon environnement (en général un mandant de personnalisation, pas la production directe).

2. 2
   Lancez la transaction SM30

   Saisissez /nSM30 dans la zone de commande, ou passez par le menu.

3. 3
   Saisissez le nom de la table ou de la vue

   Renseignez le champ prévu, puis choisissez le mode : Afficher pour consulter sans risque, Gérer (Maintenir) pour modifier.

4. 4
   Travaillez dans la grille

   Vous pouvez ajouter une ligne (« Nouvelles entrées »), modifier une valeur existante, ou supprimer une ligne. Les contrôles définis dans le générateur s’appliquent au fur et à mesure (champs obligatoires, valeurs autorisées).

5. 5
   Sauvegardez

   C’est là que se joue une étape clé pour une table de customizing : selon le paramétrage du mandant, SAP vous demande de rattacher la modification à une demande de customizing / demande de transport (ce n’est pas systématique). Le cas échéant, vous en créez une nouvelle ou vous en sélectionnez une existante. Cette demande permettra plus tard de rejouer la modification dans les autres systèmes (qualité, production), sachant que c’est en général l’équipe technique, pas le key-user, qui réalise le transport lui-même.

Tant que vous restez en mode Afficher, vous ne risquez rien : c’est une excellente façon de découvrir une table avant d’y toucher. Le geste qui engage, c’est la sauvegarde en mode Gérer.

Un mot sur la frontière avec la consultation pure. Si votre besoin est seulement de regarder le contenu d’une table (vérifier une valeur, comprendre comment une donnée est paramétrée), vous n’avez même pas besoin de SM30. SE16 et sa version plus moderne SE16N affichent le contenu d’une table en lecture seule, sans passer par un générateur de maintenance. C’est l’outil de l’inspecteur, pas du modificateur. Beaucoup de key-users gagneraient à dégainer SE16N en premier réflexe pour explorer, et à ne sortir SM30 que quand il faut réellement écrire.

SM30 vs SM31 : laquelle utiliser ?

La question revient sans cesse, et la réponse est plus simple qu’elle n’en a l’air. SM31 est l’ancienne transaction de maintenance de table. Historiquement, c’est elle qu’on utilisait, mais elle offrait une fonctionnalité réduite par rapport à ce que SAP voulait proposer ensuite.

Depuis la release 4.6, SM31 a été redirigée : appeler SM31 vous renvoie en pratique vers la maintenance étendue, c’est-à-dire le moteur de SM30 (« Call View Maintenance Like SM30 »). La recommandation officielle de SAP, documentée de longue date dans la note SAP 28504 sur la maintenance de table, est claire : utilisez SM30 (la extended table maintenance) pour vos travaux courants. La documentation ABAP officielle de SAP sur les vues de maintenance confirme d’ailleurs que ce sont bien les transactions SM30 et SM31 qui éditent les tables d’une vue de maintenance via la maintenance étendue.

Retenez-le comme une règle d’hygiène, pas comme un débat technique : SM30 aujourd’hui, SM31 c’est l’histoire.

Quand faut-il passer par SE11 (et là, on appelle un développeur) ?

C’est ici que se trouve la vraie frontière entre le geste key-user et le geste développeur, et c’est exactement le point que mon consultant du début n’avait pas su trancher.

SM30 maintient les DONNÉES d’une table. Vous remplissez, vous corrigez, vous supprimez des lignes dans une structure qui existe déjà. C’est un travail fonctionnel, à votre portée.

SE11 (le Dictionnaire ABAP, ABAP Dictionary) DÉFINIT la table. C’est dans SE11 qu’on décrit la structure : les champs, leurs types, les clés. Et c’est aussi dans SE11 (via le menu Utilitaires) qu’on génère le générateur de maintenance qui rendra ensuite la table modifiable en SM30, en y rattachant un groupe de fonctions, des écrans de maintenance et un groupe d’autorisation. Ce travail-là touche au modèle de données : c’est du périmètre développeur, pas du périmètre key-user.

La règle de partage est donc nette :

• La table existe déjà et possède un générateur de maintenance → SM30, vous gérez, sans développeur.
• La table existe mais n’a pas de générateur de maintenance (SM30 refuse la maintenance) → il faut générer le TMG dans SE11 → vous appelez un développeur (ou un consultant technique).
• La table n’existe pas encore, ou il faut lui ajouter un champ → définition / modification de structure dans SE11 → périmètre développeur, sans discussion.

Cette logique « je modifie une donnée vs je modifie une structure » est exactement la même que celle qui sépare un key-user d’un développeur sur d’autres terrains de personnalisation. C’est d’ailleurs la même philosophie que je détaille dans le guide sur personnaliser les écrans SAP sans ABAP avec SHD0 : adapter le comportement de SAP avec les outils fonctionnels prévus pour ça, et ne basculer côté technique que lorsque le besoin touche réellement le code ou la structure. SM30 pour les données de paramétrage, SHD0 pour l’apparence des écrans : deux portes d’entrée du « SAP sans développeur », deux gestes que tout key-user gagne à maîtriser.

SM30, SM31, SE11, SE16N : le tableau de décision

Pour trancher en trois secondes la prochaine fois qu’on vous demande de « toucher une table », gardez ce tableau sous la main.

La ligne de partage est toujours la même : données → fonctionnel (SM30 / SE16N), structure → technique (SE11). Si vous gardez ce repère, vous saurez instantanément si la demande qui arrive sur votre bureau est pour vous ou pour le dev.

Autorisations et garde-fous : ne pas casser la prod

SM30 est puissante, et c’est précisément pour ça qu’elle est encadrée par des autorisations. On ne laisse pas n’importe qui modifier n’importe quelle table de paramétrage : une mauvaise valeur dans une table de customizing peut changer le comportement du système pour tout le monde.

Trois objets d’autorisation contrôlent l’accès aux tables :

• S_TABU_DIS : l’accès par groupe d’autorisation de table. Chaque table appartient à un groupe ; cet objet dit à quels groupes vous avez droit, et en affichage ou en maintenance.
• S_TABU_NAM : l’accès par nom de table. Plus fin que le précédent, il permet d’autoriser une table précise sans ouvrir tout son groupe.
• S_TABU_CLI : l’autorisation pour les tables indépendantes du mandant (cross-client). Ces tables-là sont particulièrement sensibles, car une modification touche tous les mandants du système d’un coup, sans transport.

Si SM30 vous refuse l’accès à une table alors que la transaction s’ouvre bien, le problème est presque toujours là : il vous manque l’autorisation sur le bon groupe ou le bon nom de table. Ce n’est pas à forcer ; c’est une demande à faire passer à votre équipe sécurité, en justifiant le besoin.

Pour un key-user qui veut justement comprendre cette logique de paramétrage de bout en bout (mandant, customizing, transport) au lieu d’apprendre les gestes un par un dans la douleur, c’est précisément le genre de fondamentaux qu’on remet dans le bon ordre dans le SAP Starter : de quoi prendre SM30 (et ses voisins) en main proprement plutôt qu’à tâtons.

Les erreurs fréquentes avec SM30 (et comment les éviter)

Au fil des missions, ce sont toujours les mêmes pièges qui reviennent. Les connaître à l’avance vous fait gagner un temps considérable.

Confondre données de customizing et données applicatives

SM30 sert au paramétrage, pas à la saisie de données métier transactionnelles. Si vous vous retrouvez à vouloir « ajouter une commande » via une table, vous êtes au mauvais endroit : il existe presque toujours une transaction métier dédiée. SM30 touche au comportement du système, pas aux flux du quotidien.

Oublier le mandant

Modifier dans le mauvais mandant est l’erreur classique. Vous saisissez proprement, vous sauvegardez, et la modification n’apparaît pas là où on l’attend, parce qu’elle a été faite dans un autre mandant. Vérifiez systématiquement votre point d’entrée avant d’écrire.

Sauvegarder sans demande de transport

Sur une table de customizing, refuser ou « zapper » la demande de transport, c’est se condamner à un changement qui restera coincé dans un seul système. Prenez l’habitude de toujours rattacher la modification à une demande, et de noter son numéro.

Forcer une table qui n’a pas de générateur de maintenance

Si SM30 annonce qu’il n’y a pas de maintenance possible, ce n’est pas un bug à contourner. C’est le signal qu’il faut un générateur de maintenance (à créer dans SE11) ou que cette table n’est tout simplement pas censée être éditée à la main. Remontez le besoin plutôt que de chercher une porte dérobée.

Ignorer les autorisations

Un refus d’accès n’est pas un échec personnel : c’est le système de sécurité qui fait son travail. La bonne réaction est de formuler une demande d’autorisation justifiée (S_TABU_DIS / S_TABU_NAM selon le cas), pas de chercher à contourner.

FAQ SM30

Conclusion

La prochaine fois qu’on vous annonce « il faut un développeur » pour ajouter trois lignes dans une table de paramétrage, posez la seule question qui compte : s’agit-il de modifier des données, ou de modifier une structure ? Si ce sont des données et que la table a son générateur de maintenance, SM30 est votre outil, en quelques minutes et sans code. Si c’est la structure ou le générateur lui-même qui manque, alors oui, SE11 et un développeur entrent en jeu. Entre les deux, SM31 n’est qu’un raccourci historique vers SM30, et SE16N reste votre meilleur réflexe pour regarder sans toucher.

Le geste suivant est simple : ouvrez SM30 dans votre environnement de test, tapez le nom d’une table de paramétrage que vous connaissez, et restez en mode Afficher pour explorer sa grille. Vous verrez immédiatement de quoi on parle, et vous aurez fait le premier pas pour ne plus jamais sous-traiter ce qui vous revient.

À lire ensuite

01

Tutos SAP

IDoc SAP : lire un IDoc, analyser une erreur (WE02 / WE19 / BD87) et savoir quand l’utiliser

Un IDoc SAP en erreur, c'est souvent le premier vrai test d'autonomie d'un consultant junior. Le métier vous signale qu'une commande n'est pas arrivée dans

Michael A. 19 min de lecture

02

Tutos SAP

Output management SAP : comment SAP décide quel document imprimer ou envoyer (NACE)

Si tu es key-user ou consultant junior SD, tu vas tôt ou tard tomber sur la question : "pourquoi ce document est sorti, et pourquoi celui-là ne part pas ?"

Michael A. 17 min de lecture

03

Tutos SAP

Variante de sélection SAP : sauvegarder, réutiliser et planifier l’exécution d’un rapport

Chaque lundi matin, c'est le même rituel : vous ouvrez votre rapport, vous re-tapez la même société, le même magasin, la même plage de dates, les trois zon

Michael A. 19 min de lecture

04

Tutos SAP

Déterminer le prix dans SAP SD : la mécanique de la condition technique

Comment SAP détermine le prix d'une ligne de commande SD : schéma de calcul, types de condition, séquence d'accès et enregistrements de condition, expliqués pas à pas pour un consultant...

Michael A. 16 min de lecture