Contrôle de disponibilité SAP (ATP) : pourquoi ta commande n’est pas confirmée
Tu as le stock sous les yeux, le commercial t’appelle, et la quantité confirmée de la ligne reste à zéro ? La réponse tient en une phrase : le contrôle de disponibilité SAP ne lit pas ton stock, il calcule un disponible sur un périmètre décidé par le paramétrage. Ce périmètre inclut des choses que tu ne vois pas à l’écran, et en exclut d’autres que tu croyais acquises. C’est un sujet qui traverse trois modules à la fois : la commande client (SD) déclenche le contrôle, mais le calcul compte aussi les ordres de fabrication (PP) et les mouvements de gestion des stocks (MM). On va voir où lire le verdict, avec CO09.
- Le renversement : « disponible » au sens ATP n’est pas une lecture de ton stock, c’est un calcul sur un périmètre paramétré.
- Deux paramètres décident de tout : le groupe de contrôle de disponibilité (porté par la fiche article) et la règle de contrôle (portée par l’opération).
- Leur combinaison pointe une portée de vérification : la liste des stocks, entrées et sorties réellement comptés.
- Où lire le verdict :
CO09, avec l’article, la division et la règle de contrôle. Tu y lis la quantité ATP cumulée et la ligne qui consomme la quantité. - Trois cas classiques : le délai de réapprovisionnement total (confirmations lointaines ou optimistes), contrôle à la commande vs à la livraison, et livraison complète ou partielle côté client.
- Ton rôle de key user : constater, documenter avec
CO09, formuler une demande précise. Changer une portée impacte tous les articles qui portent le groupe.
Le malentendu de départ : SAP ne regarde pas le stock que tu regardes
« Disponible » au sens ATP n’est pas une lecture de ton état de stock. C’est un calcul. SAP part des stocks, ajoute les entrées prévues, retranche les sorties prévues, et te rend une quantité disponible à la promesse (ATP, pour available to promise) à une date précise.
Le point qui débloque tout est ailleurs : la liste des éléments qui entrent dans ce calcul n’est pas une constante. C’est un paramètre. La documentation SAP est explicite sur ce point : tu peux définir les types de stock retenus (stock de sécurité, stock en transfert, stock en contrôle qualité, stock bloqué), les entrées retenues (commandes d’achat, ordres de fabrication) et les sorties retenues (commandes client, réservations issues de la gestion des stocks).
La liste des éléments comptés n’est pas une propriété de l’article ni une règle universelle de SAP : c’est un paramètre. Tant que tu cherches l’explication dans le stock, tu cherches au mauvais endroit. Cherche-la dans le périmètre.
Conséquence directe, et c’est elle qui surprend : deux articles posés dans le même magasin peuvent se comporter différemment à la confirmation. Non pas parce que leur stock diffère, mais parce qu’ils ne portent pas le même paramétrage.
Un mot pour écarter une confusion fréquente : si la quantité est bien confirmée mais que la commande n’avance pas, ce n’est pas ce sujet. Regarde du côté du blocage de crédit, l’autre grande cause de commande à l’arrêt.
Les deux paramètres qui décident de tout : règle de contrôle et portée de vérification
Le mécanisme repose sur une cascade à trois étages, dont aucun n’apparaît sur ta commande. C’est pour ça qu’il est absent de ton diagnostic.
Le groupe de contrôle de disponibilité (côté fiche article)
La fiche article porte un champ qui décide si un contrôle a lieu et de quel type. Dans la documentation SAP, il se trouve sur la vue Sales: General/Plant Data, dans le champ Availability check (contrôle de disponibilité), et il est valable pour une division donnée. Ce même groupe est également mobilisé côté données de planification des besoins.
Retiens le principe plutôt que l’emplacement : le groupe voyage avec l’article, pas avec la commande. Deux articles, deux groupes, deux comportements. Va lire la valeur dans ton propre système avant de conclure.
La règle de contrôle (l’opération qui déclenche)
La règle de contrôle, elle, est rattachée à l’opération. Créer une commande client, créer une livraison, sortir des marchandises, lancer un ordre de fabrication : chacune de ces opérations se voit affecter sa règle en customizing. C’est la raison pour laquelle un même article peut répondre différemment selon le moment où tu l’interroges.
La portée de vérification (ce que SAP compte vraiment)
Ce n’est ni le groupe seul ni la règle seule qui décide : c’est la combinaison des deux. Pour un couple groupe + règle donné, le customizing définit les stocks, les entrées et les sorties pris en compte dans le contrôle. Cette liste est la portée de vérification.
Chaque élément tombe alors d’un côté ou de l’autre. Et le même élément peut changer de colonne d’un paramétrage à l’autre : c’est exactement là que se creuse l’écart entre ton stock et ta quantité confirmée.
Ce que la portée compte
- Les types de stock retenus par le paramétrage
- Les entrées prévues retenues : commandes d’achat, ordres de fabrication
- Les sorties prévues retenues : commandes client, réservations
- Le délai de réapprovisionnement total, tant que la case dédiée ne le neutralise pas
Ce que la portée ignore
- Les types de stock décochés : stock de sécurité, stock en transfert, stock en contrôle qualité, stock bloqué
- Les commandes d’achat, si elles ne sont pas retenues en entrée
- Les réservations, si elles ne sont pas retenues en sortie
- Tout élément hors périmètre : présent dans le système, absent du calcul
Une seule case dans cette liste explique parfois toute une journée de discussion. Le stock en contrôle qualité est-il compté ? Les commandes d’achat le sont-elles ? Deux réponses différentes, deux quantités confirmées différentes, pour un stock physique rigoureusement identique.
C’est aussi pour cette raison qu’un stock présent n’est pas toujours un stock confirmable : il existe physiquement, mais reste en contrôle qualité et la portée l’exclut. Si tu travailles en gestion des lots, tu croiseras ce cas régulièrement.
Pourquoi c’est un sujet SD, PP ET MM à la fois
Le contrôle de disponibilité est le point exact où trois modules se touchent. C’est ce qui le rend difficile à diagnostiquer quand on ne connaît qu’un seul des trois.
SD déclenche et porte le résultat. La commande client lance le contrôle, et c’est sur sa ligne que s’inscrivent la quantité confirmée et la date. Le contrôle se fait au niveau de la division, pour une date bien précise : la date de disponibilité matière, que le système calcule à rebours depuis la date de livraison souhaitée par le client.
PP alimente le périmètre. Les ordres de fabrication peuvent compter comme entrées prévues dans le calcul. Et les besoins issus de tes commandes client sont transmis à la planification des besoins, qui décide ensuite comment approvisionner. Si tu travailles avec des divisions de calcul des besoins, ce périmètre de planification conditionne lui aussi ce que le contrôle va trouver.
MM fournit la matière du calcul. Les niveaux de stock, les types de stock, les commandes d’achat en entrée et les réservations sont exactement ce que la portée retient ou ignore. Le même contrôle tourne d’ailleurs hors de SD : à la création d’une réservation, à une sortie de marchandises, sur un ordre de fabrication.
C’est la difficulté réelle du poste de key user : ta commande n’est pas confirmée à cause de quelque chose qui se passe en dehors de ton module. C’est ce qui rend une montée en compétence sur le flux entier plus rentable qu’un approfondissement module par module.
Diagnostiquer avec CO09 : la situation de disponibilité ligne par ligne
La transaction CO09 affiche la situation de disponibilité telle que SAP la calcule. Pas ton stock : le résultat du calcul, avec les éléments réellement retenus. C’est l’outil qui rend l’écart visible.
-
1Ouvre la situation de disponibilité (CO09)
Dans le menu SAP, le chemin passe par Logistique, Gestion des articles, Gestion des stocks, Environnement, Stock, puis Situation de disponibilité.
-
2Saisis les trois informations d’entrée
L’article, la division, et la règle de contrôle. Cette troisième information est celle qu’on oublie : c’est elle qui détermine ce que l’écran va compter.
-
3Lis la quantité ATP cumulée
C’est le verdict. Si elle est à zéro à la date qui t’intéresse, SAP n’a rien à confirmer, quel que soit le stock que tu vois par ailleurs.
-
4Identifie la ligne qui consomme la quantité
L’écran liste les éléments retenus, entrées et sorties, dans le temps. Cherche celui qui absorbe le stock avant ta commande.
-
5Compare avec ce que tu croyais disponible
L’écart entre ton état de stock et cette liste, c’est exactement la portée de vérification. Ce qui manque à l’écran n’est pas absent du système : il est exclu du calcul.
CO09 ne montre pas tout le stock : il montre le stock compté. La différence entre les deux est la réponse à ta question.
Les cas qui reviennent le plus (et ce qu’ils veulent dire)
Trois symptômes reviennent en boucle, avec trois causes distinctes. Aucune n’est un dysfonctionnement.
« Il me confirme dans 3 mois » : le délai de réapprovisionnement total
Le contrôle ne répond pas seulement oui ou non. Quand la date souhaitée ne peut pas être tenue, le système calcule en avant la prochaine date à laquelle la quantité devient atteignable, puis crée une ligne d’échéances supplémentaire avec cette nouvelle date. Une date lointaine est donc le symptôme d’une entrée attendue tard, pas d’un refus.
Le délai de réapprovisionnement total est l’autre moitié de l’explication, et le paramètre le plus contre-intuitif du lot. SAP considère que l’article sera disponible au plus tard à l’expiration de ce délai : tout besoin dont la date de disponibilité matière tombe après ce délai est donc confirmé. Sans stock, sans commande d’achat, sans rien. C’est ce qui explique les confirmations optimistes, et une case dédiée dans la portée de vérification le neutralise.
« C’était confirmé hier, plus aujourd’hui » : contrôle à la commande ou à la livraison
Créer une commande et créer une livraison sont deux opérations distinctes. Elles portent donc deux règles de contrôle distinctes, qui peuvent pointer deux portées différentes. Une quantité confirmée à la commande peut très bien ne plus l’être à la livraison, sans que rien n’ait bougé physiquement.
Une confirmation acquise peut aussi se perdre quand le système réordonnance les quantités entre commandes concurrentes. C’est un sujet à part entière, avec ses propres transactions, et ce n’est pas celui d’aujourd’hui.
« Il ne confirme rien alors qu’il y a du stock » : livraison complète ou partielle
Le plus discret des trois, parce que la cause n’est pas dans l’article mais dans le client. L’accord de livraison se maintient dans les données du partenaire, par domaine commercial, et s’affine dans la fiche info client-article, qui est prioritaire.
La conséquence est nette. Si le client exige une livraison complète, les quantités ne peuvent pas être fractionnées : tant que la totalité n’est pas disponible à une même date, tu n’obtiens rien. Le même article, le même stock, avec des livraisons partielles autorisées, aurait donné une confirmation partielle immédiate puis une seconde plus tard. Ce n’est pas le stock qui a changé, c’est l’accord client.
Où ça se paramètre : le chemin SPRO
Le contrôle de disponibilité se paramètre dans le customizing, via la transaction SPRO. Le chemin complet, tel que la documentation SAP le donne :
Chemin SPRO :
SAP Customizing IMG → Sales and Distribution → Basic Functions → Availability Check and Transfer of Requirements → Availability Check → Availability Check with ATP Logic or Against Planning → Define Checking Groups
Ce chemin n’est pas le seul point d’entrée : les mêmes réglages se retrouvent côté Production, et la portée applicable aux mouvements de marchandises et aux réservations se configure sous Gestion des articles. Cohérent avec ce qu’on a vu plus haut, le contrôle de disponibilité n’appartient à aucun module en propre.
La portée est définie pour une combinaison groupe + règle. La modifier impacte tous les articles qui portent ce groupe, sur toutes les opérations qui utilisent cette règle. Un ajustement fait pour débloquer une commande peut donc en déplacer beaucoup d’autres. Ce n’est pas une question de droits, mais de rayon d’impact.
En production, ce n’est donc pas ton rôle de toucher à ce réglage.
Ton rôle est en amont, et il a plus de valeur qu’il n’en a l’air : constater, documenter le cas avec CO09, et formuler une demande précise. « Le groupe X avec la règle Y exclut le stock en contrôle qualité, et voici la commande où ça se voit » fait gagner un temps considérable à la personne qui traitera le sujet.
ATP classique ou aATP : ce qui change en S/4HANA
Le contrôle de disponibilité classique n’a pas disparu en S/4HANA. Il s’y ajoute aATP (Advanced Available-to-Promise), une évolution qui étend le contrôle avec des fonctions supplémentaires.
Je reste volontairement en retrait sur le détail fonctionnel : le périmètre exact d’aATP dépend de ta version et de ce qui est activé chez toi. Pour ce détail, la référence est la documentation SAP sur le contrôle de disponibilité produit, qui fait autorité et suit les versions.
Le raisonnement de cet article, un périmètre paramétré plutôt qu’une lecture de stock, reste le bon point de départ dans les deux cas. SAP décrit d’ailleurs la logique ATP comme la stratégie principale du contrôle de disponibilité matière : d’autres existent, comme le contrôle contre les allocations produit.
FAQ
Le stock est là, pourquoi SAP ne confirme pas ma commande ?
Parce que SAP ne regarde pas le stock physique : il calcule un disponible sur un périmètre défini par la portée de vérification. Une partie de ton stock peut être déjà consommée par d’autres commandes ou réservations, ou simplement exclue du calcul, comme le stock en contrôle qualité ou le stock bloqué.
À quoi sert la transaction CO09 ?
À afficher la situation de disponibilité telle que SAP la calcule, avec les éléments retenus par la règle de contrôle que tu saisis. Tu y lis la quantité ATP cumulée et la ligne qui consomme la quantité. C’est l’outil qui rend visible l’écart entre ton stock et le disponible.
Quelle est la différence entre la règle de contrôle et la portée de vérification ?
La règle de contrôle est rattachée à l’opération : créer une commande, créer une livraison. La portée de vérification est le contenu, c’est-à-dire la liste des stocks, entrées et sorties comptés. Elle est définie pour la combinaison du groupe porté par l’article et de la règle.
Un key user peut-il modifier le contrôle de disponibilité lui-même ?
Non en production : c’est du customizing. Et la portée n’est pas propre à un article : elle vaut pour tous ceux qui portent le même groupe de contrôle. Le key user diagnostique, documente le cas, et transmet une demande précise. Le changement passe par le consultant.
Pourquoi ma commande est confirmée mais à une date lointaine ?
Le contrôle ne répond pas seulement oui ou non. Quand la date souhaitée n’est pas tenable, le système calcule en avant la première date où la quantité devient atteignable d’après les entrées prévues du périmètre, et crée une ligne d’échéances à cette date. La date lointaine est le symptôme d’une entrée attendue tard.
Pourquoi SAP confirme une quantité alors qu’il n’y a aucun stock ?
Regarde le délai de réapprovisionnement total. SAP considère que l’article sera disponible au plus tard à l’expiration de ce délai, et confirme donc tout besoin dont la date de disponibilité matière tombe au-delà. Ce comportement se neutralise dans la portée de vérification.
Le contrôle de disponibilité est-il différent en S/4HANA ?
S/4HANA apporte aATP (Advanced Available-to-Promise), qui étend le contrôle de disponibilité classique. Le périmètre exact dépend de ta version et de ce qui est activé. La documentation SAP officielle est la bonne référence pour le détail fonctionnel.
Le réflexe à prendre
Le contrôle de disponibilité ne te ment pas et ne bugue pas. Il applique une règle que quelqu’un a écrite, sur un périmètre que tu n’as pas choisi et que rien n’affiche à l’écran de la commande.
Alors fais-le maintenant, sur ton propre cas : prends l’article qui pose problème aujourd’hui, ouvre CO09 avec sa division et sa règle de contrôle, et cherche la ligne qui consomme la quantité. Tu vas trouver un élément que tu pensais compté et qui ne l’est pas. C’est le moment où le paramétrage cesse d’être quelque chose que tu subis.
À lire ensuite
« Objet verrouillé par un utilisateur » : comprendre et lever un verrou SAP (SM12)
Tu tombes sur un objet verrouillé par un utilisateur SAP ? Ce n'est pas une panne : trouve qui tient le verrou et sache pourquoi le lever n'est pas ton...
Michael A.
Commande SAP bloquée pour crédit : la débloquer (VKM1, VKM3) et comprendre OVA8
Blocage credit SAP : debloquez votre commande avec VKM1/VKM3, comprenez OVA8 et la bascule FD32 vers UKM_BP en S/4HANA. Guide key-user.
Michael A.
Wave management SAP EWM : maîtriser les vagues de préparation
Wave management SAP EWM : comprendre les vagues de preparation, creer un wave template, liberer une vague et relier vague, warehouse task et order.
Michael A.
Nomenclature et gamme SAP PP : comprendre et créer le couple BOM / routing
Nomenclature (BOM) et gamme (routing) SAP PP expliquees : difference, creation en CS01 et CA01, et lien avec la version de fabrication. Guide key-user.
Michael A.