Un jour ou l’autre, en mission, un utilisateur vous montre une commande client et vous demande pourquoi le prix affiché n’est pas celui qu’il attendait. Vous ouvrez la ligne, vous regardez le montant, et là, deux options : soit vous savez où SAP est allé chercher ce chiffre, soit vous bricolez. La détermination du prix SAP SD repose sur un mécanisme générique, la condition technique, qui relie quelques objets entre eux pour calculer chaque valeur d’une ligne de commande. Comprendre cet enchaînement, c’est passer du statut de spectateur à celui de quelqu’un capable d’expliquer, et de corriger, un prix.
La bonne nouvelle : ce mécanisme est logique. Une fois les bonnes briques dans le bon ordre, il n’y a plus de magie noire, juste une séquence que SAP déroule toujours de la même façon.
- SAP n’invente pas un prix : il l’applique via un schéma de calcul et le récupère dans des enregistrements de condition.
- La condition technique repose sur cinq briques : schéma de calcul, types de condition, séquence d’accès, tables et enregistrements de condition.
- La séquence d’accès va du plus spécifique au plus général et s’arrête au premier enregistrement trouvé : c’est l’origine de la plupart des prix « bizarres ».
- Un prix de vente existe seulement s’il y a un enregistrement de condition valide à la date du document, posé au bon niveau.
- Devant un prix surprenant, le premier réflexe est l’analyse du calcul du prix sur la ligne, avant toute modification.
La détermination du prix dans SAP SD, en une phrase
La détermination du prix dans SAP SD est le mécanisme par lequel le système calcule automatiquement chaque élément de prix d’un document de vente (prix de base, remises, majorations, taxes) en appliquant un schéma de calcul qui va chercher les bonnes valeurs dans des enregistrements de condition. C’est une définition que vous pouvez réutiliser telle quelle : SAP n’invente pas un prix, il le récupère et l’additionne selon des règles que le paramétrage a posées.
Tout cela repose sur ce que SAP appelle la condition technique (ou pricing), un mécanisme décrit dans la documentation officielle SAP sur la condition technique. C’est un mécanisme transverse : la même logique sert pour le prix, mais aussi pour la détermination des messages ou des comptes. En SD, vous la rencontrez d’abord sur le prix, et c’est le meilleur terrain pour la comprendre.
Pourquoi un consultant junior doit maîtriser ce mécanisme
Parce que le prix est l’endroit où les utilisateurs vous attendent. Une remise qui ne s’applique pas, une taxe en trop, un tarif client qui ne remonte pas : ce sont des tickets quotidiens en mission. Si vous comprenez la condition technique, vous ne subissez plus ces incidents. Vous savez par où entrer, quelle brique interroger, et vous donnez une réponse au lieu d’un haussement d’épaules. C’est exactement le type de réflexe attendu dans le profil d’un consultant SAP junior opérationnel.
C’est aussi un socle réutilisable. Une fois la mécanique acquise en SD, vous la retrouvez ailleurs dans SAP, presque à l’identique. L’investissement est rentable sur toute la carrière, et il s’inscrit dans le parcours pour apprendre SAP que vous construisez module après module.
Les 5 briques de la condition technique
La détermination du prix s’appuie sur cinq objets. Pris isolément, chacun est simple. C’est leur articulation qui produit le prix final.
Le schéma de calcul (pricing procedure)
Le schéma de calcul, en anglais pricing procedure, est la liste ordonnée des types de condition appliquée à un document de vente. C’est la recette : il dit quels éléments de prix entrent en jeu, dans quel ordre, et comment ils s’enchaînent (un sous-total ici, une remise calculée sur tel montant là). Quand vous ouvrez la détermination du prix d’une commande, ce que vous voyez à l’écran est l’exécution de ce schéma, ligne par ligne.
Les types de condition (condition types)
Un type de condition, ou condition type, est un élément de prix unitaire : le prix de base, une remise client, une majoration, une taxe. Chaque type de condition a son propre comportement (montant fixe, pourcentage, par quantité) et ses propres attributs. Le schéma de calcul ne fait que les empiler dans le bon ordre. Pensez-y comme aux lignes d’un ticket de caisse : chaque ligne est un type de condition.
La séquence d’accès (access sequence)
La séquence d’accès, ou access sequence, est l’ordre dans lequel SAP cherche un enregistrement de condition valide pour un type de condition donné. C’est elle qui répond à la question « où dois-je regarder en premier ? ». SAP descend la séquence du cas le plus spécifique vers le plus général, et s’arrête dès qu’il trouve une valeur. C’est ce détail qui explique la plupart des prix « bizarres » : SAP s’est arrêté plus tôt que vous ne le pensiez.
Les tables de condition (condition tables)
Une table de condition, ou condition table, définit la combinaison de critères qui sert de clé pour stocker un prix. Par exemple : un prix par client et par produit, ou un prix par groupe de clients, ou un prix par produit seul. Chaque niveau de la séquence d’accès pointe vers une table de condition. C’est la granularité de votre tarification : plus la table est précise, plus le prix est spécifique.
Les enregistrements de condition (condition records)
L’enregistrement de condition, ou condition record, est la donnée de base qui porte la valeur réelle : 100 EUR pour ce client et ce produit, un taux de remise pour ce groupe. C’est la seule brique qui contient un chiffre. Les quatre autres définissent la structure ; l’enregistrement, lui, remplit le montant. Quand un prix est faux, c’est très souvent ici que se trouve la réponse : enregistrement manquant, périmé, ou saisi au mauvais niveau.
| Critère | Type de condition (condition type) | Enregistrement de condition (condition record) |
|---|---|---|
| Rôle | Définit la nature d’un élément de prix et son comportement | Porte la valeur réelle pour un cas précis |
| Contient un chiffre ? | Non : c’est une structure | Oui : c’est la donnée qui porte le montant |
| Exemple | Prix de base, remise client, majoration, taxe | 100 EUR pour ce client et ce produit ; un taux de remise pour ce groupe |
| Niveau | Empilé dans le schéma de calcul | Posé à un niveau précis (client, produit) avec une validité |
| Quand un prix est faux | Vérifier qu’il est bien dans le schéma appliqué | Vérifier qu’il existe, est valide à la date et au bon niveau |
Comment SAP enchaîne ces briques pour trouver le prix
Maintenant que les cinq briques sont posées, voyons comment SAP les fait travailler ensemble. C’est un flux, toujours le même.
Le flux : du schéma de calcul au prix final de la ligne
Quand vous saisissez une ligne de commande, SAP détermine d’abord quel schéma de calcul s’applique (en fonction notamment de l’organisation commerciale et du client). Il parcourt ensuite chaque type de condition de ce schéma, dans l’ordre. Pour chaque type de condition, il déclenche la séquence d’accès, qui interroge les tables de condition l’une après l’autre. Dès qu’une table contient un enregistrement de condition correspondant, SAP prend la valeur, l’inscrit sur la ligne, et passe au type de condition suivant. À la fin du parcours, il additionne le tout selon les règles du schéma : le prix net de la ligne est le résultat de cette accumulation.
Retenez l’image : le schéma est la liste des courses, la séquence d’accès est l’itinéraire dans le magasin, et l’enregistrement de condition est le produit que vous mettez dans le panier.
Comment la séquence d’accès va chercher le bon enregistrement
C’est le point le plus mal compris, donc insistons. La séquence d’accès est ordonnée du plus spécifique au plus général. SAP teste le premier accès : s’il trouve un enregistrement, il s’arrête là, même s’il existe un autre enregistrement plus bas qui vous aurait semblé plus juste. C’est volontaire : on veut que le prix négocié spécifiquement pour un client l’emporte sur le tarif général. Conséquence pratique : quand un prix trop générique s’applique, c’est souvent qu’il manque l’enregistrement spécifique attendu au niveau du dessus.
Conditions manuelles vs automatiques, conditions d’en-tête
Tous les prix ne viennent pas d’un enregistrement. SAP autorise des modifications manuelles sur certains types de condition : un commercial peut saisir directement une remise exceptionnelle sur la ligne, dans les limites posées par le paramétrage. Il existe aussi des conditions d’en-tête (header conditions), qui s’appliquent à l’ensemble du document plutôt qu’à une seule ligne, par exemple une remise globale répartie sur toutes les positions. Savoir distinguer une valeur issue d’un enregistrement, une valeur saisie à la main et une condition d’en-tête évite déjà une bonne partie des fausses pistes de diagnostic.
Créer et analyser une condition de prix
Comprendre la théorie, c’est bien. Mais en mission, on vous demandera deux choses très concrètes : créer un prix, et comprendre pourquoi tel prix s’applique. Voici les deux gestes.
Créer un enregistrement de condition
Créer un prix de vente, c’est créer un enregistrement de condition pour un type de condition donné, à un niveau précis (par exemple ce produit, pour ce client, valable sur telle période). En SAP S/4HANA, l’application Fiori « Manage Prices – Sales » centralise cette maintenance : vous y créez, modifiez, copiez ou supprimez plusieurs enregistrements de condition au même endroit, et vous y posez les validités. Côté transaction classique, la transaction standard de création d’un enregistrement de condition est VK11 (modification et affichage suivant la même logique). Selon votre projet et votre version, vous travaillerez plutôt avec l’application Fiori ou plutôt en transaction : les deux pilotent les mêmes enregistrements de condition.
Le réflexe à garder : un prix n’existe que s’il y a un enregistrement de condition derrière, posé au bon niveau et valide à la date du document. Pas d’enregistrement valide, pas de valeur.
Analyser le pricing d’une ligne de commande
C’est l’outil que tout consultant junior devrait connaître en premier. Depuis une ligne de commande, SAP offre une fonction d’analyse du calcul du prix : elle déroule, type de condition par type de condition, ce que le système a fait. Pour chacun, elle indique quel accès a été tenté, lequel a abouti, et quel enregistrement de condition a fourni la valeur (ou pourquoi aucun n’a été trouvé). Au lieu de deviner, vous lisez la décision du système.
Quand un prix vous surprend, ouvrez l’analyse du calcul du prix avant toute autre chose. Dans la grande majorité des cas, elle vous dit en clair que tel accès n’a rien trouvé, ou que tel enregistrement a été retenu à la place de celui que vous attendiez. Le diagnostic part de là, pas d’une modification au hasard.
Cas concrets que rencontre un consultant junior
La théorie prend tout son sens sur des situations réelles. En voici trois que vous croiserez vite.
Remises et majorations (discounts and surcharges)
Les remises et majorations sont des types de condition comme les autres : elles ont leur séquence d’accès, leurs tables et leurs enregistrements. Une remise client en pourcentage, une majoration pour petite quantité, une remise par palier : tout cela se paramètre et se maintient via des enregistrements de condition. Quand une remise attendue ne s’applique pas, le raisonnement est identique au prix de base : le type de condition est-il dans le schéma de calcul, et existe-t-il un enregistrement valide au niveau visé ?
Détermination de la taxe (tax determination)
La taxe est, elle aussi, un type de condition, mais elle dépend de critères spécifiques : pays de départ, pays de destination, classification fiscale du client et du produit. La détermination de la taxe combine ces critères pour retrouver le bon taux. C’est souvent là que se nichent les écarts dans les contextes internationaux : une classification fiscale mal renseignée sur la fiche client ou article, et le taux remonté n’est pas le bon. Le mécanisme, lui, reste celui de la condition technique.
Quand le prix attendu n’apparaît pas : par où commencer le diagnostic
La méthode tient en trois temps, toujours dans le même ordre. Suivez-la avant de toucher au moindre paramétrage : neuf incidents de prix sur dix se résolvent dans cette séquence.
-
1Ouvrir l’analyse du pricing sur la ligne
Lancez l’analyse du calcul du prix sur la ligne concernée et lisez ce que SAP a réellement fait, type de condition par type de condition. C’est la décision du système, pas une supposition.
-
2Vérifier le type de condition concerné
Le type de condition est-il bien présent dans le schéma de calcul appliqué à ce document ? S’il n’y est pas, aucun enregistrement ne pourra remonter, quel que soit son contenu.
-
3Vérifier l’enregistrement de condition
Existe-t-il ? Est-il valide à la date du document ? Est-il posé au bon niveau (le bon client, le bon produit) ? La plupart des incidents se résolvent ici, sans toucher au paramétrage.
Cette discipline, prendre les vérifications dans le bon ordre plutôt qu’au hasard, fait gagner un temps considérable sur le terrain.
En résumé
La détermination du prix dans SAP SD n’est pas une boîte noire : c’est un enchaînement de cinq briques (schéma de calcul, types de condition, séquence d’accès, tables et enregistrements de condition) que le système déroule toujours de la même façon. Maîtriser ce flux, et savoir lire l’analyse du pricing, vous rend immédiatement plus utile sur une commande client. Prochaine étape concrète : dans votre environnement de test, ouvrez une commande, lancez l’analyse du calcul du prix sur une ligne, et suivez le chemin d’un type de condition jusqu’à son enregistrement. C’est en lisant la décision du système une première fois que tout le mécanisme se met en place dans votre tête.
Questions fréquentes
Qu’est-ce que la détermination du prix dans SAP SD ?
C’est le mécanisme par lequel SAP calcule automatiquement chaque élément de prix d’un document de vente. Il applique un schéma de calcul qui liste les types de condition à utiliser, puis va chercher les valeurs réelles dans des enregistrements de condition. Le prix net de la ligne est le résultat de cette accumulation ordonnée.
Quelle est la différence entre un type de condition et un enregistrement de condition ?
Le type de condition définit la nature d’un élément de prix (prix de base, remise, majoration, taxe) et son comportement. L’enregistrement de condition, lui, porte la valeur réelle pour un cas précis (par exemple 100 EUR pour ce client et ce produit). Le type de condition est la structure ; l’enregistrement est le chiffre.
À quoi sert la séquence d’accès dans le pricing SAP ?
La séquence d’accès définit l’ordre dans lequel SAP cherche un enregistrement de condition valide, du critère le plus spécifique au plus général. SAP s’arrête dès qu’il trouve une valeur. C’est ce qui permet à un prix négocié pour un client donné de l’emporter sur un tarif général.
Qu’est-ce que le schéma de calcul (pricing procedure) en SAP SD ?
C’est la liste ordonnée des types de condition appliquée à un document de vente. Il détermine quels éléments de prix entrent en jeu, dans quel ordre, et comment ils se combinent (sous-totaux, bases de calcul des remises). C’est la recette que SAP exécute pour produire le prix.
Comment savoir pourquoi un prix donné s’applique à une ligne de commande ?
Utilisez la fonction d’analyse du calcul du prix disponible sur la ligne de commande. Elle déroule, type de condition par type de condition, quel accès a été tenté, lequel a abouti, et quel enregistrement de condition a fourni la valeur. C’est le premier réflexe de diagnostic, avant toute modification.
Comment créer un prix de vente dans SAP SD ?
Vous créez un enregistrement de condition pour le type de condition voulu, au bon niveau (client, produit) et avec une période de validité. En SAP S/4HANA, l’application Fiori « Manage Prices – Sales » centralise cette maintenance ; en transaction classique, la transaction standard de création d’un enregistrement de condition est VK11. Sans enregistrement valide à la date du document, aucun prix ne remonte.
À lire ensuite
S/4HANA vs ECC : les différences clés pour votre carrière SAP
Quelle différence entre SAP ECC et S/4HANA ? Les différences clés expliquées simplement, le jargon décodé, la fin de maintenance d'ECC et ce que cela change pour votre carrière SAP.
Michael A.
Salaire consultant SAP : combien gagne-t-on (junior à senior) ?
Combien gagne un consultant SAP en France et au Luxembourg ? Fourchettes réelles et sourcées par niveau d'expérience (junior, confirmé, senior), TJM freelance et facteurs de salaire.
Michael A.
Key user SAP : rôle, missions et définition du rôle pivot
Le key user SAP (ou utilisateur clé) est le rôle pivot entre les utilisateurs métier et l'équipe projet. Définition, missions, projet et carrière.
Michael A.
Synchronisation des données entre SAP ERP et EWM : embedded, décentralisé et le rôle du CIF, ALE et DRF
Synchronisation des données entre SAP ERP et EWM : partage en embedded, transfert CIF/ALE/DRF en décentralisé, et ce qui se crée à la main vs en background.
Michael A.