Was die Verfügbarkeitsprüfung bestätigt, geht als Zusage aus dem Haus und wird beim Kunden gemessen. Deshalb ist Advanced ATP keine Konfigurationsaufgabe, sondern zuerst eine Reihe fachlicher Entscheidungen. Diese Seite beschreibt, was bei einer Einführung zu klären ist — und an welchen Stellen eine Einführung nicht wirkt, obwohl alles eingerichtet aussieht.
Ein Dachbegriff, mehrere eigenständige Bausteine
Im System heißt der Dachbegriff „Erweitertes Available-to-Promise (ATP)“. Er hängt am Switch-Framework-Objekt S4H_AATP und bringt mit S4H_AATP_IMG einen eigenen Customizing-Knoten mit. Darunter liegen mehrere Bausteine, die getrennt ausgeliefert, getrennt eingeführt und getrennt entschieden werden.
- Produktverfügbarkeitsprüfung — die eigentliche Prüfung im Beleg
- Kontingentierung (Product Allocation) — verteilt knappe Mengen über Kontingentierungsobjekte und Kontingentierungssequenzen auf Kunden, Werke oder Merkmalskombinationen
- Verfügbarkeitsschutz (Supply Protection) — reserviert Bestand für definierte Merkmalskombinationen
- Rückstandsbearbeitung (Backorder Processing) — priorisiert bestehende Bestätigungen neu, ausführbar über die Transaktion ATP_BOP
- Freigabe zur Lieferung (Release for Delivery) — eigene App im Standardumfang
- Alternativenbasierte Bestätigung (Alternative-Based Confirmation)
In neueren Releaseständen kommt die Bestätigung basierend auf Zugangserzeugung (Supply-Based Confirmation) dazu. Die erste Frage einer Einführung lautet deshalb nie „wie richten wir ATP ein“, sondern: Welcher dieser Bausteine löst das Problem, das im Haus tatsächlich weh tut?
Erst der Schalter im Einteilungstyp, dann der Baustein
Bevor ein aATP-Baustein überhaupt wirkt, muss die Prüfung im Vertriebsbeleg angestoßen werden. Das entscheidet der Einteilungstyp. In der Einteilungstyp-Steuerung (VOV6, Tabelle TVEP) ist die Verfügbarkeitsprüfung ein eigenes Ankreuzfeld: ATPPR. Es ist unabhängig von der Lieferrelevanz (LFREL) und von der Bedarfsübergabe (BEDSD). Alle Kombinationen kommen im Standard vor — es gibt Einteilungstypen, die einen Bedarf übergeben und trotzdem nicht auf Verfügbarkeit prüfen.
Welcher Einteilungstyp gezogen wird, entscheidet die Einteilungstypfindung (VOV5, Tabelle TVEPZ) aus Positionstyp und Dispomerkmal des Materials (MARC-DISMM). Im Lieferplan mit Abruf heißt das: Ein geändertes Dispomerkmal ändert den Einteilungstyp und damit die Frage, ob überhaupt geprüft wird. Diese Kette gehört an den Anfang der Aufnahme, nicht ans Ende.
Ein eingerichteter aATP-Baustein wirkt nur dort, wo die Verfügbarkeitsprüfung im Einteilungstyp eingeschaltet ist. Das ist der häufigste Grund dafür, dass nach einer Einführung im Beleg nichts anders aussieht.
Wo die Bausteine im System liegen
Jeder Baustein bringt eigene Konfigurationsobjekte und eine eigene Persistenz mit. Das ist für die Aufwandsschätzung relevant: Wer zwei Bausteine einführt, führt zwei Konzepte ein, nicht eines mit zwei Häkchen.
| Kontingentierung | Kontingentierungsobjekt und Kontingentierungssequenz; Persistenz unter anderem PALLOCOBJ, PASQNC, PAQTYASSGMT, PACTLG |
| Verfügbarkeitsschutz | eigener Merkmalskatalog; Persistenz unter anderem SUP_OBJECT, SUP_CVC, SUP_TIMEBUCKET, SUP_CHARC |
| Rückstandsbearbeitung | BOP-Segmente und BOP-Varianten (ABOPSEGMENT, ABOPVARIANT); Transaktion ATP_BOP |
Was vorab zu entscheiden ist
- Wer bei Knappheit zuerst bedient wird. Das ist eine Geschäftsentscheidung und keine Konfigurationsaufgabe. Steht sie nicht vorher fest, wird die Konfiguration zum Stellvertreterstreit.
- Nach welchem Merkmal verteilt oder geschützt wird — Kunde, Werk, Produktgruppe, Zeitraster. Danach richtet sich, ob Kontingentierung oder Verfügbarkeitsschutz das passende Werkzeug ist.
- Ob bestehende Bestätigungen verändert werden dürfen. Ein Rückstandslauf verschiebt Zusagen, die der Vertrieb bereits kommuniziert hat.
- Welche Belegarten und Einteilungstypen überhaupt in den Geltungsbereich fallen — und welche bewusst draußen bleiben.
- Wer die Läufe im Betrieb verantwortet, wann sie laufen und wie eine verschlechterte Bestätigung kommuniziert wird.
Zwei Fallen, die regelmäßig Zeit kosten
Die erste ist sprachlich. SAP sagt Kontingentierung, nicht „Kontingente“, und Rückstandsbearbeitung, nicht „Backorder-Bearbeitung“. Mischformen aus Deutsch und Englisch klingen harmlos, führen in Konzeptpapieren aber dazu, dass zwei Beteiligte über zwei verschiedene Bausteine reden und es erst im Test merken.
Die zweite ist die Gleichsetzung von „ausgeliefert“ mit „einsatzbereit“. Die Bausteine liegen im Standardumfang. Ob sie in einem konkreten System nutzbar sind, ist eine getrennte Frage — Prüfgruppen, Customizing, technische Anbindung. Wer beides gleichsetzt, sagt einen Termin zu, den die Systemseite nicht hält. Ich prüfe das am System, bevor ich einen Plan unterschreibe.
Womit ich in so einer Einführung beauftragt werde
- Aufnahme des Ist-Standes: welche Einteilungstypen heute prüfen, welche nicht und warum
- Fachliche Vorklärung: welcher Baustein das gestellte Problem löst — und welcher nicht
- Konzept und Konfiguration der ausgewählten Bausteine, jede Änderung im Transport
- Testfälle über den echten Belegweg statt über Direktbuchungen in die Tabellen
- Betriebsanleitung: Läufe, Zuständigkeiten, Eskalationsweg bei verschlechterter Bestätigung
- Dokumentierte Übergabe an das Inhouse-Team
Gibt es für eine Anforderung einen dokumentierten Standardweg, nehme ich ihn statt einer Eigenentwicklung. Wo der Standard nicht reicht, sage ich das vor der Beauftragung und nicht im Test.
Wenn eine Verfügbarkeitsplanung ansteht oder eine eingerichtete nicht wirkt: Nennen Sie mir den Releasestand, die betroffene Belegart und das Symptom im Beleg. Damit lässt sich schon im ersten Gespräch einordnen, welcher Baustein greift und was vorher zu klären ist.