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

Un document de sortie SAP ne se déclenche jamais “parce que c’est comme ça”. Quand une commande client part en confirmation par e-mail, qu’une facture s’imprime sur la bonne imprimante, ou qu’un avis d’expédition s’envoie en EDI au client, le système a pris une décision. Et cette décision suit une mécanique précise, la même que celle qui sert au prix. C’est exactement ce que recouvre l’output management SAP (la gestion des messages de sortie), et le point d’entrée de cette mécanique côté paramétrage s’appelle 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 ?”. Cet article répond côté fonctionnel, en suivant le fil “comment SAP décide”, pas “comment je développe un formulaire”. On ne touche ni à SAPscript, ni à Adobe, ni à l’ALE. On regarde la logique de décision.

Le problème métier : à un instant T, SAP doit décider quoi sortir, pour qui, par quel canal

Prends une commande client que tu viens d’enregistrer. À cet instant, SAP doit répondre à trois questions, en même temps et automatiquement :

• Quoi ? Faut-il sortir un document, et lequel (une confirmation de commande, un accusé, un avis) ?
• Pour qui ? Quel destinataire, c’est-à-dire quelle fonction partenaire (le donneur d’ordre, le réceptionnaire des marchandises, le payeur) ?
• Comment et quand ? Par quel support de sortie (medium) : impression, e-mail, EDI, fax ? Et à quel moment : tout de suite, ou plus tard par un job ?

Personne ne code en dur ces réponses. Si on le faisait, chaque client, chaque organisation commerciale, chaque type de document demanderait une exception dans le programme. Ce serait ingérable. SAP a donc besoin d’un mécanisme paramétrable qui regarde le contexte du document et en déduit la sortie correcte. Ce mécanisme, tu le connais peut-être déjà sous un autre nom.

La réponse de SAP : la technique de condition, la même que pour le prix

La documentation SAP est explicite sur ce point : tout comme la détermination du prix et la détermination des textes, la sortie des documents est pilotée par la technique de condition (condition technique). C’est le cœur de l’article, et c’est aussi le meilleur raccourci d’apprentissage que je puisse te donner.

Si tu as déjà compris la technique de condition expliquée dans la détermination du prix, tu connais déjà 90 % de l’output management. Ce sont les mêmes briques, dans le même ordre, avec le même vocabulaire. Seul l’objet change : au lieu de déterminer un montant, SAP détermine quel message de sortie proposer et avec quelles propriétés.

Voici la correspondance terme à terme entre les deux mondes :

Les briques de la détermination des messages : output type, séquence d’accès, tables, fiches, procédure

Reprenons chaque brique dans l’ordre où SAP les utilise.

Le type de message (output type)

Le type de message, ou output type, est l’unité de base. C’est lui qui représente “une confirmation de commande”, “une facture imprimée”, “un avis d’expédition EDI”. Dans le standard SD, la confirmation de commande porte souvent le code BA00. Une fiche condition rattachée à un output type contient ses propriétés dans un contexte donné : le support de sortie, le timing, la langue, et la fonction partenaire destinataire.

La séquence d’accès (access sequence)

La séquence d’accès est la stratégie de recherche. La règle, écrite noir sur blanc dans la doc SAP, est de chercher “du spécifique au général”. Concrètement, chaque étape de la séquence pointe vers une table de condition, et SAP les parcourt dans l’ordre : d’abord la combinaison la plus fine (ce client précis, cette organisation commerciale), puis des combinaisons plus larges si rien n’a été trouvé. Dès qu’une fiche condition correspond, SAP s’arrête. Exactement comme pour le prix.

Les tables de condition (condition tables)

Chaque table de condition définit une combinaison de champs clés sur laquelle une fiche peut exister. Par exemple : une fiche par organisation commerciale, ou une fiche par client et type de document. C’est cette structure qui rend la sortie paramétrable sans toucher au code : on ajoute une combinaison, pas une exception logicielle.

Les fiches conditions de sortie (condition records)

C’est la donnée de maître que le métier saisit. Une fiche condition de sortie dit, par exemple : “pour le client C650 en organisation commerciale 1010, sortir la confirmation BA00 par fax”. C’est là que se décide concrètement le support et le destinataire. Le consultant met en place la mécanique ; le key-user, lui, vit le plus souvent dans les fiches conditions, car c’est l’endroit où l’on règle un cas client sans demander de développement.

La procédure de détermination des messages

La procédure est la liste ordonnée des output types que SAP doit évaluer pour un objet donné (l’en-tête de la commande, ou un poste). Elle est affectée selon le type de document. C’est l’équivalent direct de la procédure de prix : sans procédure affectée, SAP ne sait pas quoi chercher, et rien ne sort.

NACE : la transaction où tout se règle

À quoi sert la transaction NACE ? C’est le point d’entrée unique du paramétrage de l’output management classique. Depuis NACE, tu choisis l’application concernée (par exemple V1 pour les ventes, V3 pour la facturation) puis tu accèdes à tout l’arbre de la technique de condition : les output types, les séquences d’accès, les tables de condition, les procédures, et l’affectation aux types de documents. C’est l’écran où le consultant assemble la mécanique décrite plus haut.

Un point de vocabulaire important sur les versions de SAP S/4HANA. À côté de l’output management classique piloté par NACE, SAP propose le New Output Management, qui ne repose plus sur la technique de condition mais sur un moteur de règles, le BRF+ (Business Rule Framework plus), avec des tables de décision à la place des séquences d’accès et des fiches conditions. Il se paramètre ailleurs, via les composants Cross-Application et l’activation par type d’objet applicatif, par exemple SALES_DOCUMENT. Les deux mondes coexistent. Pour savoir lequel s’applique, on vérifie d’abord si le New Output Management est actif pour l’objet concerné. Tant qu’il est inactif, c’est bien la mécanique NACE classique qui pilote la sortie. Pour le détail officiel des deux mondes selon ta version, la documentation officielle SAP S/4HANA on-premise fait foi.

Pour un key-user, la bonne nouvelle est que la logique de décision reste la même dans les deux cas : SAP regarde le contexte du document, du plus spécifique au plus général, pour en déduire quoi sortir, par quel canal et pour qui. Seuls le moteur et l’emplacement du paramétrage changent.

Medium et timing : par quel canal et à quel moment SAP sort le document

Une fois que SAP a déterminé quel output type proposer, deux propriétés de la fiche condition pilotent la sortie réelle.

Le support de sortie (medium) dit comment le document est émis. La doc SAP cite l’impression, l’e-mail, l’EDI (Electronic Data Interchange, pour les échanges automatisés entre systèmes), le fax. Concrètement : une confirmation de commande peut partir en impression pour un client, et en EDI pour un autre, simplement parce que leurs fiches conditions diffèrent. C’est de la donnée, pas du développement.

Le timing (dispatch time) dit quand le document part. SAP propose plusieurs moments standards. Le document peut être émis automatiquement dès que l’objet est enregistré (envoi immédiat), ou bien mis en file d’attente pour être traité par un programme qui tourne à intervalles réguliers (par job). Le programme standard RSNAST00 est précisément celui qui balaie les messages en attente et les émet au tour suivant. C’est une distinction qui sauve beaucoup de temps en diagnostic : un document “qui ne part pas” est très souvent un document parfaitement déterminé, mais simplement en attente de son job.

NAST : la table où SAP enregistre sa décision et le statut du message

Quand SAP a décidé de sortir un message pour un document, il enregistre cette décision et son statut dans la table des messages, NAST. Chaque enregistrement y porte un statut de traitement : à traiter, traité avec succès, ou en erreur. C’est la mémoire de la décision de sortie.

Pour le key-user, NAST et l’écran de sortie d’un document sont les deux premiers réflexes de diagnostic. Sur le document lui-même, l’écran de sortie liste les messages déterminés et leur statut. Et SAP fournit une fonction d’analyse dédiée : depuis un document de vente, on ouvre l’écran de sortie puis l’analyse de détermination, en suivant ce chemin de menu :

Chemin de menu :

Extras → Output (Sortie) → En-tête (ou Poste) → Edit → Goto → Analyse de détermination

Cette analyse te dit pourquoi un output type a été proposé, ou pourquoi il ne l’a pas été. C’est l’exact équivalent de l’analyse de prix. Quand on me demande “pourquoi mon document de sortie SAP ne part pas”, ma première réponse est presque toujours : lance l’analyse de détermination, puis regarde le statut dans la sortie du document.

Cas pratique de bout en bout : de la commande au document sorti

Suivons une confirmation de commande, du clic d’enregistrement jusqu’au document émis. C’est cette séquence que SAP exécute, et c’est aussi celle que tu remontes à l’envers quand quelque chose cloche.

1. 1
   Identification de la procédure

   Tu enregistres la commande client. SAP regarde le type de document et identifie la procédure de détermination des messages affectée à l’en-tête.

2. 2
   Lancement de la séquence d’accès

   Pour chaque output type de la procédure (par exemple BA00), SAP lance la séquence d’accès et parcourt les tables de condition du spécifique au général.

3. 3
   Correspondance d’une fiche condition

   Dès qu’une fiche condition correspond au contexte (ce client, cette organisation commerciale), SAP retient l’output type avec ses propriétés : support de sortie, timing, fonction partenaire.

4. 4
   Enregistrement dans NAST

   SAP crée l’enregistrement de message dans NAST, avec son statut initial.

5. 5
   Application du timing

   Selon le timing, le message part immédiatement, ou attend le passage du programme d’émission (RSNAST00 pour le traitement par job).

6. 6
   Transmission sur le medium

   Le document est transmis sur le bon medium (imprimante, e-mail, EDI) au partenaire retenu.

Si à l’arrivée rien n’est sorti, tu rejoues cette chaîne à l’envers : le statut NAST d’abord, puis l’analyse de détermination pour voir où la recherche a échoué, puis la fiche condition manquante ou mal ciblée. Neuf fois sur dix, le problème est une fiche condition absente ou un timing mal compris, pas un bug.

Erreurs fréquentes et points de contrôle pour le key-user

Voici les confusions que je vois le plus souvent chez les juniors, et le réflexe de contrôle associé.

• Confondre “pas déterminé” et “pas encore parti”. Un message déterminé mais en attente de job n’est pas une erreur. Vérifie le timing avant de paniquer.
• Chercher le problème dans le formulaire. Si aucun message n’apparaît dans la sortie du document, le souci est dans la détermination (technique de condition), pas dans le SAPscript ou l’Adobe. Le formulaire ne se pose la question qu’une fois le message déterminé.
• Oublier la fonction partenaire. Un output type peut être parfaitement déterminé mais ne jamais arriver si le partenaire destinataire n’a pas d’adresse e-mail ou de coordonnées valides pour le medium choisi.
• Ignorer l’analyse de détermination. C’est l’outil que SAP fournit exprès pour répondre à “pourquoi”. Ne devine pas, lance l’analyse.
• Penser que NACE et le New Output Management s’excluent. Les deux coexistent sur le même système (le New Output Management repose sur un moteur de règles BRF+, pas sur la technique de condition classique). Vérifie lequel est actif pour ton objet avant de chercher au mauvais endroit.

Questions fréquentes

Pour conclure

L’output management SAP n’est pas une boîte noire : c’est une décision, prise par la technique de condition, exactement comme le prix. Une fois que tu vois NACE, les output types, la séquence d’accès, les fiches conditions et la table NAST comme un seul mécanisme de décision, le diagnostic devient mécanique plutôt que magique. La prochaine fois qu’un document ne sort pas, ne cherche pas au hasard : ouvre l’analyse de détermination et regarde le statut NAST. Et si tu veux ancrer définitivement la mécanique, relis la détermination du prix SAP SD en gardant en tête que tu apprends, en réalité, la même technique deux fois.

À 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

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. 18 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