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 le système voisin, l’équipe technique répond « regarde tes IDocs », et là, silence. Vous savez que ça circule quelque part entre deux systèmes, mais vous ne savez pas par où ouvrir le capot. J’ai vu beaucoup de juniors rester bloqués à ce moment précis, non pas parce que le sujet est difficile, mais parce que personne ne leur a montré les trois ou quatre transactions qui suffisent à diagnostiquer la grande majorité des cas.
Bonne nouvelle : lire un IDoc et comprendre pourquoi il est tombé en erreur ne demande pas une ligne d’ABAP. C’est un travail de lecture, de méthode et de bon vocabulaire. Ce guide reprend le sujet dans le bon ordre, côté fonctionnel : ce qu’est réellement un IDoc, comment l’ouvrir avec WE02, comment lire son statut, comment analyser une erreur, puis comment le rejouer avec WE19 ou le retraiter en masse avec BD87. L’objectif n’est pas de faire de vous un développeur d’interfaces, mais de vous rendre capable de dire précisément ce qui bloque, et où.
- Lire : ouvrez l’IDoc avec WE02 (ou WE05) et lisez-le dans l’ordre, en-tête de contrôle, statut, puis segments de données.
- Statuts : en entrée, 51 = erreur (document non créé), 53 = succès. Identifiez toujours le sens avant d’interpréter le code.
- Diagnostiquer : sens et type de message, puis message de statut, puis segment fautif, puis corriger la cause.
- Agir : rejouez un cas avec WE19, retraitez le lot en masse avec BD87. Le tout sans une ligne d’ABAP.
Qu’est-ce qu’un IDoc, en langage fonctionnel ?
Un IDoc (Intermediate Document) est un conteneur de données structuré que SAP utilise pour échanger une information métier avec un autre système. Concrètement, c’est l’enveloppe normalisée dans laquelle SAP range une commande, une facture, une fiche article ou un mouvement de stock pour l’envoyer ailleurs, ou pour le recevoir.
Trois notions suffisent pour s’y retrouver, et aucune n’est technique au sens développeur du terme.
Le sens : entrant ou sortant (inbound / outbound). Un IDoc sortant part de votre système SAP vers l’extérieur. Un IDoc entrant arrive d’un système tiers vers votre SAP. C’est la toute première question à se poser face à une erreur, parce qu’elle oriente déjà la moitié du diagnostic : un problème en sortie et un problème en entrée ne se traitent pas au même endroit.
Le type de message (message type). Il décrit la nature métier de l’échange. Un type de message porte un nom parlant : par exemple ORDERS pour une commande d’achat ou de vente, INVOIC pour une facture, MATMAS pour une fiche article. Quand vous savez lire le type de message, vous savez de quel flux métier on parle avant même d’ouvrir le contenu.
Le type de base (basic type) et les segments. Le type de base est la structure technique de l’IDoc, le « moule » qui définit quels champs il transporte et dans quel ordre. À l’intérieur, les données sont rangées dans des segments : des blocs logiques (un segment en-tête, un segment poste, un segment partenaire…) qui regroupent les champs par thème. Lire un IDoc, c’est en grande partie savoir dans quel segment se trouve l’information que vous cherchez.
Retenez l’image : le type de message dit de quoi on parle, le type de base dit comment c’est rangé, les segments sont les tiroirs. Avec ces trois mots, vous pouvez déjà tenir une conversation crédible avec un développeur d’interfaces.
Quand utilise-t-on un IDoc (et quand non) ?
On utilise un IDoc dès qu’il faut faire communiquer SAP avec un autre système de façon structurée, traçable et rejouable. C’est le mode d’échange historique et toujours central pour l’EDI (échanges avec des partenaires externes : clients, fournisseurs, transporteurs) et pour les flux inter-systèmes, par exemple la synchronisation entre un ERP central et un système d’entrepôt.
Cette logique d’échange par messages structurés est exactement celle que l’on retrouve dans la synchronisation des données entre SAP ERP et EWM, où l’IDoc fait partie des mécanismes qui font circuler articles, commandes et confirmations entre les deux systèmes. Si vous diagnostiquez des flux dans ce contexte, comprendre l’IDoc est un prérequis direct.
Pourquoi l’IDoc plutôt qu’autre chose ? Parce qu’il est asynchrone et persistant. L’information est déposée dans un IDoc, stockée, envoyée, et reste consultable même des semaines plus tard. Si l’échange échoue, l’IDoc ne disparaît pas : il reste en erreur, consultable et rejouable. C’est précisément ce qui en fait un excellent point de diagnostic pour un fonctionnel : la trace reste.
Quand l’IDoc n’est-il pas le bon outil ? Quand vous voulez injecter en masse des données à l’intérieur d’un même système SAP, comme une reprise initiale ou un chargement de masse. Là, on parle plutôt de chargement par transaction enregistrée (le batch input), ou d’API et de services dédiés. L’IDoc, lui, sert avant tout à l’échange entre systèmes et à l’EDI. Garder cette frontière en tête évite de chercher un problème d’interface là où il s’agit en réalité d’un problème de chargement.
Lire un IDoc avec WE02 (et WE05) pas à pas
Pour afficher et lister les IDocs, la transaction de référence est WE02 ; WE05 propose une vue liste très proche. Commencez toujours par WE02 : c’est votre poste de lecture.
Au lancement, WE02 vous propose un écran de sélection. Les critères les plus utiles au quotidien sont la période (date de création), le sens (entrant / sortant), le statut, le type de message et le numéro d’IDoc si vous l’avez déjà. Un réflexe sain : restreindre par date et par type de message pour ne pas noyer l’écran sous des milliers d’IDocs sans rapport.
Une fois la liste affichée, ouvrez un IDoc. L’écran de détail s’organise toujours de la même manière, et c’est ce qui rend la lecture reproductible :
- L’en-tête de contrôle (control record) : les métadonnées de l’IDoc. Vous y lisez le sens, le type de message, le type de base, le partenaire émetteur et récepteur, et le port. C’est la carte d’identité de l’échange.
- Les enregistrements de statut (status records) : l’historique de vie de l’IDoc, étape par étape, avec le code statut et un message à chaque étape. C’est ici que se lit le « pourquoi » d’une erreur.
- Les données (data records) : le contenu métier, rangé dans les segments. C’est ici que vous vérifiez la valeur fautive (un code client inconnu, un article inexistant, une unité non reconnue…).
La bonne habitude de lecture est de descendre dans cet ordre : sens et type d’abord (en-tête), puis statut (que s’est-il passé ?), puis segment fautif (sur quelle donnée ?). Trois étages, toujours les mêmes.
Comprendre les statuts d’un IDoc
Le statut d’un IDoc est un code numérique qui dit où en est l’échange et s’il a réussi. C’est le cœur du diagnostic : avant de plonger dans les segments, lisez le statut, il vous dit déjà beaucoup. Premier réflexe à acquérir : les statuts entrants et sortants n’utilisent pas la même plage de codes, donc identifiez le sens avant d’interpréter le chiffre.
Voici les statuts que vous rencontrerez le plus souvent. Tenez-vous-en à ceux-ci tant que vous n’avez pas vérifié les autres dans votre système : la documentation SAP en liste davantage, et certains codes ont des nuances selon le contexte.
| Statut | Sens | Signification |
|---|---|---|
| 51 | Entrant | Erreur : le document applicatif n’a pas pu être créé. C’est l’erreur entrante la plus classique (donnée invalide, contrôle métier qui bloque). |
| 53 | Entrant | OK : le document applicatif a bien été créé dans SAP. C’est le statut de succès en entrée. |
| 64 | Entrant | IDoc prêt à être transmis à l’application (reçu, en attente de traitement). |
| 30 | Sortant | IDoc prêt pour l’envoi, mais pas encore transmis (en attente de dispatch). |
| 03 | Sortant | Données transmises au port (l’IDoc a quitté SAP côté technique). |
| 12 | Sortant | Dispatch OK : l’IDoc a bien été envoyé. |
| 29 | Sortant | Erreur dans le service ALE : l’IDoc sortant n’a pas pu partir, en général à cause d’un profil partenaire (WE20) mal configuré côté sortie. On le retraite avec le programme RBDAGAIN. |
Le couple à mémoriser en priorité est 51 contre 53 en entrée : 51 = erreur, le document n’existe pas ; 53 = succès, le document est créé. Dès que vous voyez 51, vous savez que le travail de diagnostic commence, et qu’il se jouera dans le message de statut et le segment de données. Pour les statuts que vous croisez moins souvent, le plus sûr reste de cliquer sur le code dans WE02 : SAP affiche son libellé, ce qui évite de mémoriser une table entière de tête.
Analyser une erreur : la méthode en quatre étapes
Face à un IDoc en statut 51, la pire approche est de regarder les données au hasard. La bonne approche est une lecture ordonnée, toujours la même, qui isole la cause avant de la corriger.
-
1Identifier le sens et le type de message
Ouvrez l’IDoc dans WE02 et lisez l’en-tête de contrôle. Entrant ou sortant ? Quel flux métier (ORDERS, INVOIC, MATMAS…) ? Cette étape recadre tout le reste : vous savez désormais quel document SAP aurait dû être créé ou envoyé.
-
2Lire le message de statut
Descendez dans les enregistrements de statut et lisez le message associé au statut 51. SAP y écrit en clair ce qui a bloqué : « client inconnu », « article inexistant dans cette division », « unité de mesure non convertible »… Neuf fois sur dix, le message vous donne déjà la nature du problème.
-
3Localiser le segment et la donnée fautive
Allez dans les données (data records) et trouvez le segment concerné par le message. Vous confrontez ainsi la valeur transmise à ce que SAP attend. C’est l’étape qui transforme un message générique en cause précise : tel champ porte telle valeur, et cette valeur n’existe pas dans le référentiel cible.
-
4Décider de l’action
Soit la donnée source est fausse et il faut la corriger à la source puis renvoyer l’IDoc, soit le référentiel cible est incomplet (un client, un article, un poste de chargement manquant) et il faut le compléter avant de retraiter. Le bon réflexe fonctionnel est de corriger la cause, pas seulement de relancer en espérant que ça passe.
Quand le message de statut ne suffit pas et que vous avez besoin de comprendre quel contrôle a rejeté l’IDoc, le pas suivant est de travailler avec un développeur, ou de poser un point d’analyse côté traitement applicatif. Mais dans la grande majorité des cas, ces quatre étapes suffisent à nommer la cause avec précision, et c’est déjà ce qu’on attend d’un fonctionnel autonome.
Rejouer ou tester un IDoc avec WE19 (sans casser la prod)
WE19 est l’outil de test de l’interface IDoc : il sert à rejouer ou simuler le traitement d’un IDoc, idéalement à partir d’un IDoc existant pris comme modèle. C’est l’instrument de vérification du fonctionnel prudent.
Le scénario typique : vous avez un IDoc entrant en erreur 51, vous avez corrigé le référentiel cible (créé le client manquant, par exemple), et vous voulez vérifier que le traitement passe désormais. WE19 permet de repartir de cet IDoc, éventuellement d’ajuster une donnée dans un segment, puis de relancer le traitement entrant pour observer le résultat.
L’intérêt majeur, c’est le contrôle : vous travaillez à partir d’un cas réel, vous voyez immédiatement si l’IDoc passe en 53 ou retombe en 51, et vous comprenez l’effet de votre correction avant de retraiter en masse. La prudence reste de mise selon l’environnement : tester de préférence dans un système non productif, et garder en tête que rejouer un IDoc entrant peut réellement créer le document applicatif. WE19 n’est pas un bac à sable inoffensif : c’est un outil de relance maîtrisée.
Retraiter les IDocs en erreur avec BD87
BD87 est la transaction de retraitement des IDocs : elle liste les IDocs selon leur statut et permet de relancer ceux qui sont en erreur, à l’unité ou en masse. C’est l’outil de production une fois la cause corrigée.
Le bon enchaînement est toujours le même. D’abord, vous diagnostiquez et corrigez la cause (avec WE02 pour lire, éventuellement WE19 pour valider votre correction sur un cas). Ensuite seulement, vous passez par BD87 pour relancer le lot d’IDocs concernés. BD87 vous présente les IDocs regroupés par statut ; vous sélectionnez ceux à retraiter et vous lancez le traitement.
Relancer en masse sans avoir corrigé la cause ne fait que reproduire les mêmes erreurs. Si une centaine d’IDocs sont en 51 pour la même raison (un référentiel incomplet), corrigez d’abord ce référentiel, vérifiez sur un cas avec WE19, puis retraitez l’ensemble. Sur de gros volumes récurrents, ce retraitement est souvent automatisé via un traitement de fond planifié, mais le principe ne change pas : diagnostic, correction, puis relance.
Vérifier les partner profiles (WE20) et la documentation (WE60)
Deux transactions complètent la boîte à outils du diagnostic, sans jamais relever du développement.
WE20, les profils partenaires (partner profiles). Un partenaire, c’est l’identité de l’émetteur ou du récepteur d’un IDoc (un client, un fournisseur, un système logique). Le profil partenaire définit, pour chaque type de message, comment l’IDoc doit être traité et par quel port il transite. Quand un flux entier ne part pas ou n’arrive pas, et que ce n’est pas une erreur de donnée sur un IDoc isolé, le profil partenaire est l’un des premiers endroits à inspecter : un type de message non déclaré pour un partenaire, et plus rien ne circule pour ce flux.
WE60, la documentation des types de base. WE60 génère la documentation d’un type de base : la liste de ses segments et de ses champs. C’est précieux quand vous devez comprendre où devrait se trouver une donnée, ou expliquer à un interlocuteur la structure d’un IDoc sans deviner. Pour un fonctionnel, c’est la carte qui transforme un IDoc obscur en structure lisible.
Côté prérequis transverses, gardez en tête deux choses très concrètes. D’abord, l’accès à ces transactions WE* (WE02, WE05, WE19, BD87, WE20, WE60) dépend de vos autorisations : si une transaction vous est refusée, ce n’est pas un bug, c’est un droit à demander à votre administration. Ensuite, la notion de partenaire et de port est structurante : un IDoc voyage toujours d’un partenaire à un autre, via un port. Comprendre ce trio (partenaire émetteur, partenaire récepteur, port) vous évite de chercher une erreur de donnée alors que le problème est un partenaire mal déclaré.
Pour aller au fond d’un concept précis, la documentation officielle SAP sur l’interface IDoc et ALE reste la référence pour vérifier un statut, un type de message ou le comportement d’un profil partenaire dans votre version.
Foire aux questions
Comment lire un IDoc SAP ?
Utilisez la transaction WE02 (ou WE05 pour une vue liste). Ouvrez l’IDoc, puis lisez-le dans l’ordre : l’en-tête de contrôle (sens, type de message, partenaires, port), les enregistrements de statut (ce qui s’est passé), puis les données rangées dans les segments (le contenu métier). Trois étages, toujours les mêmes.
Que signifie le statut IDoc 51 ?
Le statut 51 concerne un IDoc entrant et signifie « erreur » : le document applicatif n’a pas pu être créé dans SAP. La cause est presque toujours une donnée invalide ou un contrôle métier qui bloque (client inconnu, article inexistant, unité non reconnue). Le message associé au statut, lisible dans WE02, précise la nature exacte du blocage.
Quelle est la différence entre le statut IDoc 51 et 53 ?
Les deux concernent un IDoc entrant. Le statut 51 signifie que le traitement a échoué et que le document applicatif n’existe pas. Le statut 53 signifie le succès : le document applicatif a bien été créé dans SAP. En résumé, 51 = à diagnostiquer, 53 = traité avec succès.
Quelle transaction pour afficher un IDoc ?
WE02 est la transaction de référence pour afficher et lister les IDocs. WE05 offre une vue liste très proche. Pour la documentation de la structure (segments et champs d’un type de base), utilisez WE60. Pour les profils partenaires, WE20.
WE19 ou BD87 : quelle différence ?
WE19 est un outil de test : il sert à rejouer ou simuler le traitement d’un IDoc, souvent à partir d’un IDoc existant, pour valider une correction sur un cas précis. BD87 est l’outil de retraitement en production : il relance les IDocs en erreur, à l’unité ou en masse. En pratique : on diagnostique et on valide une correction avec WE02 puis WE19, et on retraite le lot avec BD87.
Faut-il savoir développer en ABAP pour diagnostiquer un IDoc ?
Non. Lire un IDoc, interpréter son statut, localiser la donnée fautive dans un segment et relancer le traitement avec BD87 sont des tâches purement fonctionnelles. L’ABAP n’intervient que pour comprendre le détail d’un contrôle applicatif très spécifique, et même là, c’est un travail conjoint avec un développeur.
En résumé
Diagnostiquer un IDoc SAP tient en une discipline de lecture : identifier le sens, lire le statut, localiser le segment fautif, corriger la cause, puis rejouer avec WE19 et retraiter avec BD87. Aucune de ces étapes ne demande de coder ; elles demandent de la méthode et le bon vocabulaire. La prochaine fois qu’on vous dira « regarde tes IDocs », vous saurez exactement où ouvrir le capot.
Pour pratiquer, prenez un IDoc en erreur dans votre système de test, ouvrez-le dans WE02 et déroulez les quatre étapes de la méthode d’analyse sur un cas réel. C’est en lisant des statuts 51 jusqu’à les comprendre du premier coup d’œil que l’on gagne cette autonomie.
À lire ensuite
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.
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
Michael A.
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.
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.