Tu paramètres ta batch détermination SAP et le moteur ne s’enclenche pas. Tu sors les lots dans le mauvais ordre alors que la sort rule est bien configurée. Bienvenue dans le club des consultants qui ont passé deux jours sur un point qui se résout en cinq minutes une fois qu’on connaît les bonnes transactions. Voici les 6 étapes propres et les 4 pièges qui font perdre des journées en mission.
C’est quoi la batch détermination en clair ?
La batch détermination SAP est la fonction qui sélectionne automatiquement les lots à consommer ou à livrer selon des critères que tu définis : date d’expiration, statut qualité, plant, caractéristique technique du lot (paramétrée via le système de classification SAP). Elle remplace la saisie manuelle d’un numéro de lot par un moteur de règles. C’est ce moteur qui rend possible le FIFO industriel à grande échelle.
Définition d’un lot SAP
Un lot (batch) en SAP est une instance physique d’un matériel, identifiée par un numéro unique et porteuse de caractéristiques propres : date de production, fournisseur, numéro de série, résultat de contrôle qualité. Le lot vit dans la table MCH1 et son stock dans MCHB. Tu le crées via MSC1N ou il naît automatiquement à la réception (MIGO mouvement 101).
Quand le moteur s’enclenche
La batch détermination se déclenche dans quatre contextes : à la création ou release d’un ordre de fabrication ou de procédé, lors d’une livraison sortante (SD), lors d’un picking WM ou EWM, et lors d’un transfert de stock entre plants. Dans tous ces cas, le système ne sélectionne pas le lot tout seul. Il applique la search procédure que tu as configurée, et c’est elle qui pilote l’enchaînement des règles. La documentation SAP Help Portal détaille les contextes d’usage par module.
Les modules concernés (PP, MM, SD, WM)
La batch détermination est utilisée par plusieurs modules SAP, chacun avec son cas d’usage typique et sa transaction de déclenchement.
| Module | Cas d’usage | Transaction |
|---|---|---|
| PP (Production Planning) | Consommation de composants dans un ordre de fabrication ou de procédé | CO01 / COR1 |
| MM (Materials Management) | Sortie de stock manuelle, transfert | MIGO |
| SD (Sales and Distribution) | Picking d’une livraison sortante | VL01N / VL02N |
| WM / EWM | Transfer order picking en magasin | LT03 / Fiori warehouse |
On reste sur la configuration PP (ordre de fabrication) dans la suite. C’est là que la plupart des consultants tombent sur le sujet pour la première fois. Les principes (condition table, access séquence, search procédure) sont identiques pour SD, MM et WM. Seules les transactions d’assignment changent.
Configurer la batch détermination en 6 étapes
Le customizing tient en 6 objets à enchaîner dans l’ordre. Le path SPRO :
Logistics → Central Functions → Batch Management → Batch Determination → Batch Search Procedure
Voici les 6 étapes, dans l’ordre.
- 1
Créer la condition table
La condition table définit la clé de recherche : quels champs SAP utilisera-t-il pour chercher un record de stratégie ? En PP, la combinaison classique est plant plus matériel plus order type. Tu crées la table dans le customizing batch détermination, sous l’application
PP(ou MM, SD, WM selon ton cas).
Écran de customizing de la condition table 030 : on choisit les champs (plant, material, customer) qui structurent la matrice de détermination du lot. - 2
Définir l’access séquence
L’access séquence ordonne les condition tables par priorité. SAP teste les tables de la plus spécifique à la plus générale jusqu’à trouver un record. Si tu as deux tables (plant plus matériel, et plant seul), tu places la plus spécifique en première position.
Access sequence batch determination : ordre dans lequel SAP teste les condition tables, de la plus spécifique (plant + material) à la plus générale, jusqu’à trouver un record applicable. - 3
Paramétrer la sort rule
La sort rule pilote l’ordre de tri des lots éligibles : FIFO sur date de production (caractéristique HSDAT), tri sur date d’expiration (caractéristique VFDAT), LIFO ou critère custom. Tu la crées dans
CU70en sélectionnant les caractéristiques de tri et leur ordre ascendant ou descendant. Étape souvent oubliée à l’affectation au strategy type, voir piège 3 plus bas.
Sort rule batch determination : SAP trie les lots candidats par caractéristique (date de production, FIFO, FEFO) en mode ascendant ou descendant avant de proposer la sélection. - 4
Construire le strategy type
Le strategy type lie l’access séquence à une logique de sélection des lots et à une sort rule. C’est l’objet pivot du customizing : il déclare comment SAP doit chercher (access séquence), filtrer (caractéristique class) et trier (sort rule) les lots.
Strategy type YB11 : conteneur central qui agrège access sequence, class de caractéristiques et sort rule. C’est lui que la search procedure appellera pour exécuter la détermination. - 5
Assembler la search procédure
La search procédure regroupe un ou plusieurs strategy types dans un ordre d’exécution. SAP exécute les strategy types un à un jusqu’à trouver suffisamment de lots pour couvrir la quantité demandée. C’est le conteneur final du customizing.
Search procedure : enchaînement ordonné des strategy types testés un à un jusqu’à couvrir la quantité demandée. C’est le point d’entrée final du customizing batch determination. - 6
Assigner via OPL8
Dernière étape, et celle qui rate le plus souvent : tu affectes la search procédure au type d’ordre via
OPL8(Order Type Dependent Parameters). Sans cette étape, le moteur ne s’enclenche jamais : tout ton customizing est correct mais inactif. Vérifie pour chaque order type concerné. Pour le détail Manufacturing, voir la SAP KBA 3649584.
Transaction OPL8 : affectation de la search procedure batch determination au type d’ordre de production (ou DSD pour SD, OMI4 pour MM). Sans ce lien, le moteur ne s’enclenche pas.
Une fois les 6 étapes faites, tu maintiens les condition records dans COB1. C’est l’étape qui transforme le customizing (technique) en données opérationnelles (métier).
Maintenir les records dans COB1, l’étape qu’on oublie
Sur les missions PP que j’ai vues, l’oubli de maintenir COB1 après le go-live est récurrent. Le moteur de batch détermination est silencieux sur ses propres records manquants : il ne lève aucune erreur, il rend juste la liste de lots vide. Le consultant qui débugue passe sa journée à chercher dans la config, alors que le problème est dans la donnée.
Pierre Balbinot, consultant SAP PP/PM
COB1 crée et maintient les condition records du moteur batch détermination. Sans record dans COB1, ton customizing est valide mais le moteur ne trouve aucune stratégie applicable et rend une liste de lots vide. C’est le piège silencieux numéro un.
COB1 vs MBC1 : ne pas confondre
COB1 est la transaction de création et maintenance des condition records (côté customizing et données maîtres). MBC1 est la transaction d’exécution de la batch search côté utilisateur, qui consomme les records configurés en COB1. En clair : COB1 écrit les règles, MBC1 les applique. Sur S/4HANA, MBC1 est largement remplacée par les apps Fiori Manage Batches et Maintain Batch Search Strategies, mais COB1 reste la transaction de référence pour la configuration.
ECC vs S/4HANA : ce qui change vraiment
La logique de batch détermination est strictement identique entre ECC et S/4HANA. Ce qui bouge, c’est les données maîtres autour et l’UI.
SAP ECC
- Batch level configurable plant ou material via
OMCT - Classification batch via class type 022 (plant) ou 023 (material/client)
- UI 100% SAP GUI :
COB1,MSC1N,MSC2N OPL8etCU70identiques au customizing S/4
SAP S/4HANA
- Batch level remonté au client par défaut, classification simplifiée class 023
- Apps Fiori Manage Batches et Maintain Batch Search Strategies complètent le GUI
COB1,OPL8,CU70conservés à l’identique- Migration ECC vers S/4 : aucune refonte du customizing batch détermination
Tu peux donc rassurer les chefs de projet en migration : le batch détermination ne fait pas partie des chantiers à refondre. Tu transportes ton customizing tel quel, tu vérifies le batch level (qui peut bouger côté MM) et tu testes en non-régression. Pour les classes et batch levels post-migration, la SAP KBA 3078948 donne la matrice à jour.
4 pièges qu’on rencontre en prod
Piège 1 : Batch Management activé après mouvements de stock
Tu actives le flag Batch Management dans MM02 sur un matériel qui a déjà du stock dans MCHB. De base, SAP ne te laissera pas faire (message d’erreur). Mais si tu le forces d’une manière ou d’une autre … Résultat : MIGO bloque chaque mouvement avec un message d’erreur sur la cohérence du batch level. La parade : activer Batch Management avant tout mouvement, ou archiver le stock existant avant de basculer le flag. La création de la Production Version qui sert souvent de pré-requis suit la même logique de timing.
Piège 2 : OPL8 oublié sur un order type custom
Tu copies un order type standard PP01 en ZP01 pour un besoin métier spécifique. Tu reportes l’ensemble du customizing dépendant, sauf l’affectation de la search procédure dans OPL8. Le moteur batch détermination ne s’enclenche jamais sur ZP01 et ne lève aucune erreur. Tu cherches dans le customizing pendant des heures alors que la cause est une ligne manquante dans OPL8.
Piège 3 : Sort rule définie mais pas affectée au strategy type
Tu crées une sort rule FIFO propre dans CU70, tu valides, tu testes. SAP sort les lots dans un ordre apparemment aléatoire. Cause : la sort rule existe mais n’est pas reliée au strategy type concerné. Le moteur sélectionne donc les lots sans tri. La parade : ouvrir le strategy type, onglet sort séquence, lier explicitement la sort rule.
Piège 4 : Class type 022 vs 023 mal choisie
Tu travailles avec un batch level material (S/4 par défaut) mais tu as classé le matériel via class type 022 (plant level). Les caractéristiques ne se propagent pas, le moteur ignore tes filtres et te rend tous les lots disponibles. La parade : aligner le class type sur le batch level réel (023 pour material/client, 022 pour plant).
FAQ : SAP Batch Determination
Quelle est la différence entre COB1 et MBC1 ?
COB1 crée et maintient les condition records (search strategy records) côté customizing et données maîtres. MBC1 est la transaction d’exécution de la batch search côté utilisateur, qui applique les records configurés en COB1. En clair : COB1 écrit les règles, MBC1 les applique. Sur S/4HANA, MBC1 est largement remplacée par les apps Fiori Manage Batches mais COB1 reste la référence pour la configuration.
Pourquoi ma batch détermination ne se déclenche pas dans l’ordre de fabrication ?
Trois causes reviennent en mission. La search procédure pas affectée à l’order type via OPL8 (sans cette ligne, le moteur ne s’enclenche jamais). Aucun condition record dans COB1 pour la combinaison plant plus matériel plus order type. Ou le matériel n’a pas le flag Batch Management actif dans MM02. Vérifie ces trois points avant de creuser le customizing.
Comment activer la batch détermination sur un type d’ordre existant ?
Aller dans OPL8, sélectionner ton order type et ton plant, ouvrir l’onglet Implementation. Renseigner la search procédure dans le champ Batch Search Procedure et activer le flag Automatic Batch Determination si tu veux que le moteur s’enclenche sans intervention utilisateur. Sauvegarder. Le moteur sera actif sur les ordres créés à partir de cette ligne. Les ordres déjà créés ne reçoivent pas la nouvelle config.
Faut-il refaire la configuration en migrant ECC vers S/4HANA ?
Non. Le customizing batch détermination est conservé tel quel lors d’une migration ECC vers S/4HANA. Les transactions COB1, OPL8 et CU70 sont identiques. Ce qui peut bouger côté MM : le batch level (qui peut remonter au client par défaut sur S/4) et la classification (class 023 majoritaire). Tu transportes ton customizing, tu vérifies le batch level avec OMCT en pré-go-live et tu fais une non-régression sur les ordres types critiques.
Peut-on forcer un ordre FIFO strict avec batch détermination ?
Oui, à condition que ta sort rule soit créée dans CU70 sur la caractéristique date de production (ou date de réception selon ta convention) en ordre ascendant, puis affectée au strategy type concerné dans son onglet sort séquence. Si tu oublies l’affectation au strategy type, ta sort rule existe mais n’est jamais appliquée et SAP sélectionne les lots dans un ordre apparemment aléatoire (voir piège 3).
La batch détermination fonctionne-t-elle en MIGO 261 (consommation manuelle) ?
Oui, mais avec une nuance. Le moteur s’enclenche au goods issue côté ordre de fabrication (release ou confirmation), pas à la saisie manuelle MIGO 261 hors ordre. Si tu fais un mouvement 261 directement sur un cost center sans passer par un ordre, la batch détermination en PP n’a pas de contexte pour s’enclencher. Pour ce cas, configure une search procédure côté MM (application 02) et affecte-la au movement type 261 via OMK1.
La batch détermination est un moteur silencieux. Il ne lève pas d’erreur quand il manque un record. Il ne te dit pas que ta sort rule n’est pas reliée. Quand un consultant me dit “mon batch détermination ne marche pas”, je commence toujours par COB1 et OPL8. Le customizing technique vient après.
Si tu veux aller plus loin sur le module PP end-to-end, on prépare une formation SAP PP complète qui sortira sur notre catalogue de formations courtes dans les prochains mois. Pour les pré-requis liés à la création de la Production Version, voir notre tutoriel Production Version SAP. Et côté logistique, la même logique de cascade s’applique pour la storage bin type search en SAP WM, où SAP filtre les bins candidats sur 3 niveaux avant de retenir l’emplacement final.
À lire ensuite
Gestion des lots SAP : guide débutant (MM, PP, QM)
Comprenez la gestion des lots dans SAP : à quoi ça sert, comment activer le batch management dans MM, PP, QM, et créer un lot avec MSC1N. Guide pas à...
Pierre B.
SAP LTMOM : guide 2026 Migration Object Modeler, workflow 4 phases et arbitrage vs Migrate Your Data Fiori
Quand utiliser SAP LTMOM en 2026 face à LTMC, Migrate Your Data Fiori et alternatives ETL. Workflow Source Structure → Target Structure → Field Mapping → Runtime Object expliqué.
Pierre B.
MRP Area SAP : guide 2026 OM01, tables MDLV/MDMA et arbitrage Plant vs Storage Location vs Subcontracting
Quand activer un MRP Area SAP en 2026 S/4HANA. Configuration OM01, tables MDLV/MDMA, arbitrage entre 3 types (Plant, Storage Location, Subcontracting) et intégration MRP Live.
Michael A.
Numéro de série SAP : guide de décision OIS2, 6 procédures et arbitrage matériel vs équipement PM
Quand activer la sérialisation SAP, comment paramétrer le profil OIS2, choisir parmi les 6 serializing procedures et arbitrer entre numéro de série matériel et équipement PM.
Pierre B.