Commande SAP bloquée pour crédit : la débloquer (VKM1, VKM3) et comprendre OVA8

Tu enregistres une commande client comme tu le fais cent fois par semaine, et au lieu de passer, un message t’arrête : la commande est bloquée pour dépassement de la limite de crédit. Le client attend, le commercial s’impatiente, et toi tu cherches où cliquer pour libérer ça. Voilà le scénario derrière la plupart des cas de blocage crédit SAP dans le module SD (Sales & Distribution). La réponse courte tient en deux gestes : tu listes les documents bloqués avec la transaction VKM1, et tu libères une commande précise avec VKM3. Le blocage, lui, vient du contrôle crédit automatique, paramétré côté projet dans la transaction OVA8.

Avant d’entrer dans le « où je clique », un mot sur le « pourquoi ». Le contrôle crédit n’est pas là pour t’embêter : c’est un garde-fou qui empêche de livrer un client qui doit déjà trop d’argent. Une fois ce mécanisme compris, le déblocage devient un réflexe, pas une énigme. Cet article suit l’ordre de ton quotidien : d’abord débloquer, ensuite comprendre.

Pourquoi une commande SAP est bloquée pour crédit ?

Une commande SAP est bloquée pour crédit lorsque le contrôle crédit automatique du module SD détecte que la commande ferait dépasser au client sa limite de crédit autorisée. SAP n’annule pas la commande : il la met de côté, avec un statut « bloqué crédit », en attendant qu’une personne habilitée décide de la libérer ou non. La commande existe bel et bien dans le système ; elle est simplement gelée à l’étape de livraison.

Ce contrôle s’appuie sur la notion de zone de contrôle crédit (credit control area) : c’est le périmètre dans lequel SAP additionne ce qu’un client te doit déjà. À chaque client est rattachée une limite de crédit dans cette zone. Quand une nouvelle commande, ajoutée à l’encours existant, dépasse cette limite, le contrôle se déclenche.

Le contrôle crédit automatique, sans jargon

Imagine une jauge par client : d’un côté ce qu’il te doit déjà (factures ouvertes, livraisons non facturées, commandes en cours), de l’autre le plafond que ton entreprise lui accorde. Le contrôle crédit automatique compare en permanence la jauge au plafond. Tant qu’on reste sous le plafond, la commande passe sans rien dire. Dès qu’on le franchit, SAP lève le drapeau et bloque.

Ce qui entre exactement dans la jauge (commandes seules, livraisons, factures ouvertes) dépend du paramétrage. C’est précisément ce que le consultant règle dans OVA8, et nous y reviendrons plus bas. Pour l’instant, retiens l’idée : le blocage n’est pas un bug, c’est une décision automatique fondée sur un plafond.

Où la commande accroche dans le flux

Le point important pour un key-user, c’est de savoir à quel moment le blocage frappe. Le contrôle se fait généralement à l’enregistrement de la commande de vente, mais l’effet visible apparaît plus loin : une commande bloquée pour crédit ne pourra pas être livrée. C’est l’étape de livraison qui reste verrouillée tant que le déblocage n’a pas eu lieu.

Autrement dit, le blocage crédit ne t’empêche pas forcément de créer la commande, mais il t’empêche de la faire avancer. Tu peux te retrouver avec une commande enregistrée, visible, et pourtant impossible à livrer. C’est souvent là que naît la confusion : « la commande est là, alors pourquoi rien ne part ? » Parce qu’elle est en attente de libération crédit.

Attention : blocage crédit n’est pas blocage facture ni blocage autorisation

Le mot « bloqué » recouvre plusieurs réalités très différentes dans SAP, et les confondre fait perdre un temps fou. Pour t’y retrouver d’un coup d’œil :

• Blocage crédit (celui dont parle cet article) : la commande dépasse la limite de crédit du client. On le traite avec VKM1 / VKM3 dans le module SD.
• Blocage de facture fournisseur : une facture entrante en écart par rapport à la commande d’achat, côté MM. On le traite avec la transaction MRBR. Rien à voir avec le crédit client.
• Blocage d’autorisation : tu n’as pas le droit d’exécuter une transaction ou d’accéder à un objet. C’est un sujet de profil utilisateur, géré par ton administrateur SAP, pas de crédit.

Si ton message d’erreur parle de limite de crédit dépassée, tu es bien sur le bon article. Sinon, change de piste avant de chercher du côté de VKM3.

Débloquer la commande : VKM1, VKM3, VKM4, VKM5 (le décodeur)

Pour débloquer une commande, tu utilises la famille de transactions VKM. La plus directe pour un key-user au quotidien : VKM1 pour voir la liste des documents bloqués, VKM3 pour libérer une commande dont tu connais le numéro. SAP recharge la commande, tu valides la libération, et la livraison redevient possible.

La famille VKM regroupe plusieurs transactions proches, et c’est cette proximité qui sème la confusion. Voici de quoi trancher.

Quelle transaction VKM pour quel besoin

En pratique, l’essentiel des situations key-user se règle avec VKM1 (pour voir) et VKM3 (pour libérer une commande connue). Garde les autres en tête pour les cas particuliers, sans t’y noyer.

VKM1 : lister et libérer les documents bloqués

VKM1 affiche la liste des documents SD retenus pour dépassement de crédit, selon les critères que tu saisis sur l’écran de sélection (zone de contrôle crédit, client, dates). Tu obtiens une liste de commandes bloquées, et tu peux sélectionner une ligne pour la libérer directement depuis la liste.

C’est la transaction du « tour d’horizon » : avant de libérer quoi que ce soit, VKM1 te montre l’ampleur du sujet. Combien de commandes sont retenues, pour quels clients, depuis quand. Pour un contrôleur de gestion ou un analyste crédit, c’est l’écran de travail naturel en début de journée.

VKM3 : libérer une commande précise, pas à pas

Quand tu connais déjà le numéro de la commande à débloquer, VKM3 va droit au but. La marche à suivre est courte :

1. 1
   Lancer la transaction VKM3

   Ouvre la transaction VKM3 depuis la zone de commande SAP. C’est le point d’entrée dédié au traitement d’une commande de vente précise.

2. 2
   Saisir le numéro de la commande

   Renseigne le numéro de la commande de vente bloquée dans l’écran de sélection, puis valide. Inutile de connaître la zone de contrôle crédit : le numéro de commande suffit.

3. 3
   Afficher la commande et son statut crédit

   SAP affiche la commande retenue avec son statut crédit. Tu vois ce qui a déclenché le blocage (dépassement de limite) avant de décider de libérer.

4. 4
   Sélectionner la commande dans la liste

   Coche la ligne de la commande concernée. C’est elle que la libération va viser.

5. 5
   Libérer la commande

   Utilise la fonction de libération : le statut crédit passe à « libéré ». La commande n’est plus retenue par le contrôle crédit.

6. 6
   Sauvegarder

   Sauvegarde pour rendre la libération effective. La livraison de la commande peut désormais être créée normalement.

Une fois sauvegardée, la commande n’est plus retenue : sa livraison peut être créée normalement. Si la commande ne se libère pas comme attendu, ce n’est en général pas la transaction qui est en cause : c’est souvent une re-vérification du crédit qui se redéclenche, un cas qu’on détaille plus bas.

Qui a le droit de débloquer ?

Tout le monde ne peut pas libérer une commande bloquée pour crédit, et c’est voulu. Le déblocage est une décision financière : on accepte d’exposer l’entreprise au-delà du plafond fixé. Ce droit est généralement réservé à un profil dédié, souvent un analyste crédit ou un membre du contrôle de gestion, via les autorisations attachées au groupe de crédit concerné.

Si SAP te refuse la libération alors que tu vois bien la commande, ce n’est pas un problème de transaction : c’est que ton profil d’autorisations ne couvre pas le déblocage crédit. Le bon réflexe est de te rapprocher de la personne habilitée plutôt que de chercher une astuce technique.

Le blocage se propage : commande, livraison, facture

Le blocage crédit ne reste pas confiné à la commande : il se propage le long de la chaîne commande, livraison, facture (le flux Order-to-Cash). Comprendre où il frappe t’évite de chercher le problème au mauvais endroit, par exemple côté livraison alors que la cause est en amont.

Où le blocage frappe dans la chaîne O2C

Le flux de vente standard enchaîne trois grandes étapes : la commande de vente, la livraison, puis la facture. Le contrôle crédit s’insère le plus souvent au niveau de la commande, parfois aussi de la livraison, selon le paramétrage. La conséquence se lit en cascade : pas de libération crédit, pas de livraison ; pas de livraison, pas de facture. Le blocage en amont gèle tout l’aval.

C’est exactement ce qui rend le sujet déroutant quand on ne connaît pas le mécanisme. L’utilisateur voit « rien ne part en livraison » et cherche du côté de la logistique, alors que la vraie cause est une commande retenue pour crédit deux étapes plus tôt. Le réflexe à acquérir : devant une commande qui n’avance pas, vérifier d’abord son statut crédit.

Une commande bloquée peut-elle être livrée ou facturée ?

Non, pas tant qu’elle est retenue. Une commande bloquée pour crédit ne peut pas être livrée : la création de la livraison est empêchée tant que le statut crédit n’est pas libéré. Et sans livraison, il n’y a logiquement pas de facture à émettre. Le blocage agit comme un coupe-circuit : il interrompt la chaîne à l’endroit du contrôle.

C’est précisément l’intérêt du dispositif. Le but n’est pas de gêner la saisie, mais d’empêcher qu’une marchandise parte chez un client déjà trop endetté. Le déblocage, via VKM1 ou VKM3, rouvre le circuit en aval. D’ailleurs, une commande peut très bien franchir l’étape de détermination du prix dans une commande SD sans souci, et se faire arrêter juste après par le contrôle crédit : prix correct ne veut pas dire commande livrable.

Le piège du re-blocage après modification

Voici un cas qui surprend souvent. Tu libères une commande, tout va bien, puis quelqu’un en modifie la quantité ou le montant. Résultat : la commande peut se re-bloquer pour crédit. C’est normal. Une modification qui change la valeur exposée relance le contrôle, et la libération précédente ne vaut plus pour le nouveau montant.

Comprendre OVA8 : le moteur du contrôle crédit automatique

OVA8 est la transaction de paramétrage du contrôle crédit automatique dans SAP SD. C’est elle qui définit, pour une combinaison donnée, comment SAP réagit face à un dépassement : quel type de contrôle appliquer, et quel comportement déclencher (avertir, bloquer, ou les deux). C’est un sujet de consultant ; un key-user n’y touche pas au quotidien, mais comprendre ce qu’OVA8 décide aide à interpréter pourquoi une commande s’est bloquée.

Ce que paramètre OVA8

Le contrôle crédit automatique se règle pour une combinaison de trois éléments : la zone de contrôle crédit, le groupe de crédit (qui regroupe les types de documents soumis au contrôle, par exemple les commandes) et la catégorie de risque du client (le niveau de risque qu’on lui attribue). Pour chacune de ces combinaisons, OVA8 définit la réaction du système.

Concrètement, c’est ce qui explique qu’un même dépassement puisse bloquer pour un client classé « risque élevé » et seulement avertir pour un autre. Le comportement dépend de la catégorie de risque rattachée au client. C’est aussi pourquoi deux clients en apparence semblables peuvent se comporter différemment face au crédit : leur catégorie de risque diffère.

Contrôle statique ou dynamique

OVA8 distingue plusieurs types de contrôle. Sans entrer dans la configuration, deux familles suffisent à un key-user :

• Le contrôle statique compare l’encours global du client (commandes, livraisons, factures ouvertes) à sa limite, sans tenir compte du temps.
• Le contrôle dynamique ajoute une notion d’horizon : les valeurs au-delà d’une certaine échéance ne sont pas prises en compte dans le calcul du dépassement.

Ce que tu dois en retenir : selon le type de contrôle paramétré, ce qui « compte » dans la jauge n’est pas tout à fait le même. Cela peut expliquer un blocage qui paraît injustifié au premier regard, alors qu’il est cohérent avec la règle en vigueur.

Pourquoi OVA8 concerne le consultant, pas le key-user au quotidien

OVA8 est un écran de personnalisation : on y règle des comportements qui s’appliqueront à tout le monde, et une modification mal pensée peut bloquer (ou laisser passer) des milliers de commandes. C’est un terrain de consultant, à manipuler dans un environnement de paramétrage, pas en production sur un coup de tête.

Pour le key-user, l’intérêt d’OVA8 est purement explicatif : savoir qu’il existe, et que c’est lui qui « décide » du blocage, permet de poser les bonnes questions au consultant. « Ma commande bloque alors que la limite n’est pas dépassée » devient une question précise sur la catégorie de risque ou le type de contrôle, pas une plainte vague.

Où est la limite de crédit ? FD32 (ECC) contre UKM_BP (S/4HANA)

La limite de crédit d’un client ne se consulte pas au même endroit selon ta version de SAP. Sur l’ancien Credit Management (ECC), tu passes par FD32. Sur S/4HANA avec le SAP Credit Management (FSCM), la gestion de crédit a migré vers le partenaire commercial, et tu passes par UKM_BP. C’est l’une des bascules les plus déroutantes du sujet, parce que la transaction de réflexe d’hier n’existe plus de la même façon.

Sur ECC : FD32 et FD33

Dans le Credit Management historique (rattaché à FI-AR), la limite de crédit d’un client se gère par débiteur et par zone de contrôle crédit :

• FD32 sert à créer et modifier les données de crédit d’un client : limite, catégorie de risque, blocages éventuels.
• FD33 est la version affichage : tu consultes sans risquer de modifier.

C’est l’endroit où tu lis le plafond accordé au client et la catégorie de risque qui lui est attribuée. Si tu es encore sur un système ECC, FD33 est ta transaction de consultation de référence quand une commande bloque.

Sur S/4HANA FSCM : UKM_BP et le rôle BP UKM000

Avec S/4HANA, SAP a basculé sur le SAP Credit Management (issu de FSCM), et la logique change. Les données de crédit ne sont plus rattachées à un débiteur isolé mais au partenaire commercial (Business Partner). Tu y accèdes via la transaction UKM_BP, en travaillant le rôle de partenaire UKM000 (le rôle qui porte les données de gestion de crédit).

Conséquence pratique : si tu cherches FD32 sur un système S/4HANA, tu risques de ne plus la retrouver comme avant. Le bon réflexe devient UKM_BP. La catégorie de risque, la limite, les segments de crédit : tout est désormais porté côté partenaire commercial. Le parcours officiel SAP Learning Working with SAP Credit Management détaille cette organisation pour qui veut creuser la configuration.

ECC ou S/4HANA ? Voici ta transaction

Bonne nouvelle pour le déblocage : les transactions VKM (VKM1, VKM3) restent ton point d’entrée dans les deux mondes. C’est surtout la consultation de la limite qui change d’adresse entre ECC et S/4HANA.

Erreurs fréquentes et points d’attention

Quelques situations reviennent assez souvent pour mériter une liste à garder sous le coude. Aucune n’est compliquée, mais chacune fait perdre du temps quand on la découvre en production.

• La commande reste bloquée après libération. Souvent, c’est qu’une modification de quantité ou de montant a relancé le contrôle, ou que le paramétrage déclenche une nouvelle vérification. Vérifie le statut crédit après chaque modification de valeur.
• La limite n’est pas dépassée, et pourtant ça bloque. Regarde du côté de la catégorie de risque du client et du type de contrôle paramétré en OVA8 : ce qui entre dans la jauge n’est pas toujours ce que tu crois. Pense aussi aux données de crédit figées (un encours mal mis à jour).
• Tu ne trouves pas FD32 sur ton système. Tu es probablement sur S/4HANA : la gestion de crédit est passée sous UKM_BP (rôle BP UKM000). Change de transaction, pas de système.
• SAP refuse la libération. Ce n’est pas la transaction, c’est ton profil d’autorisations. Le déblocage crédit est réservé aux personnes habilitées : rapproche-toi de l’analyste crédit.
• « Rien ne part en livraison. » Avant de chercher côté logistique, vérifie le statut crédit de la commande. Un blocage en amont gèle toute la chaîne O2C.

FAQ

En résumé

Devant une commande SAP bloquée pour crédit, le réflexe tient en deux transactions : VKM1 pour voir ce qui est retenu, VKM3 pour libérer une commande précise. Le blocage lui-même vient du contrôle crédit automatique paramétré en OVA8, qui compare l’encours du client à sa limite, et il se propage à toute la chaîne commande, livraison, facture. Avant de chercher la limite d’un client, pose-toi une question simple : ECC ou S/4HANA ? Sur ECC tu passes par FD33, sur S/4HANA par UKM_BP. La prochaine fois qu’une commande refuse d’avancer, ouvre son statut crédit avant tout le reste, puis rapproche-toi de l’analyste crédit si la libération te dépasse. Pour replacer ce contrôle dans l’ensemble du module, le tour d’horizon du module SAP SD (Sales & Distribution) montre comment le crédit s’articule avec les autres étapes de la vente.

À lire ensuite

01

Tutos SAP

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. 17 min de lecture

02

Tutos SAP

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. 21 min de lecture

03

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

04

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