Transportation Management läuft im S/4HANA embedded, im selben Mandanten wie Vertrieb und Lager. Die Kette ist kurz: aus dem Vertriebs- oder Beschaffungsbeleg entstehen Frachteinheiten, die auf Frachtaufträge verplant werden, und aus dem Frachtauftrag entsteht der Frachtabrechnungsbeleg. Interessant ist nicht die Kette, sondern das Scharnier zur SD-Lieferung — und die Frage, ob es TM überhaupt braucht.
Sechs Belegkategorien, eine Tabelle
Frachteinheit und Frachtauftrag sind keine getrennten Tabellen. Beide liegen in derselben Persistenz und werden allein über die Belegkategorie unterschieden. Die zugehörige Domäne hat genau sechs Festwerte:
| Kategorie | Bezeichnung |
|---|---|
| FU | Frachteinheit |
| TO | Frachtauftrag |
| BO | Frachtbuchung |
| TC | Frachtauftragskopie für Ausschreibung |
| SO | Serviceauftrag |
| TU | Transporteinheit |
Die letzte Zeile ist die wichtige: Die Transporteinheit ist eine Belegkategorie neben den anderen, nicht eine Ebene darüber. Sie gehört zur klassischen Integration von Transport und Lager. Fällt sie weg, ist man im erweiterten Warenannahme- und Versandprozess.
Auf der Kategorie sitzen die Belegarten, gepflegt in einer eigenen Customizing-Tabelle. Wer ein Belegartenproblem sucht, schaut dort und nicht in den Beleg: Die Belegart entscheidet unter anderem, ob ein Frachtauftrag überhaupt für den erweiterten Warenannahme- und Versandprozess vorgesehen ist.
Das Scharnier ist der Lieferkopf
LIKP trägt genau vier Felder mit dem Präfix TM_. Zwei davon tragen den ganzen Prozess.
Das erste ist der Steuerschlüssel für die Belegübertragung an TM (LIKP-TM_CTRL_KEY). Er entscheidet, ob und wie die Lieferung überhaupt an das Transportmanagement geht. Seine Domäne hat keine Festwerte — die gültigen Schlüssel stammen aus dem Customizing der Transportrelevanz, das es getrennt für Verkaufs- und für Lieferbelege gibt. Aus dem Data Dictionary lässt sich die erlaubte Belegung deshalb nicht ableiten.
Das zweite ist der Lagerausführungsstatus (LIKP-TM_WHSE_EXEC). Er gibt dem Lager frei — oder eben nicht. Seine Domäne kennt fünf Werte:
| leer | nicht relevant |
| 1 | Lieferung ist für Lagerausführung gesperrt |
| 2 | Lieferung ist für Lagerausführung freigegeben |
| 3 | Lieferung ist in Lagerabwicklung |
| 4 | Lieferung ist bereit für Versand |
Die Werte beweisen die Reihenfolge: erst Transportplanung, dann Lagerausführung. Eine Lieferung, die im Lager nicht auftaucht, ist deshalb oft kein Lagerproblem. Sie steht auf 1 und wartet.
Daneben stehen die Lagerausführungssperre mit drei Ausprägungen — nicht gesperrt, in Transportplanung, nicht GTS-konform — und die Relevanz für den erweiterten Warenannahme- und Versandprozess. Der mittlere Wert der Sperre ist die häufige Ursache, der letzte der teure: Er kommt aus der Außenhandelsprüfung, nicht aus dem Transport.
Vom Frachtauftrag zur Abrechnung
Der Frachtabrechnungsbeleg entsteht nicht neben dem Frachtauftrag, sondern aus ihm heraus: über ein Aktionsprofil, das auf jedem erzeugten Beleg stehen bleibt und damit die Herkunft dokumentiert. Von dort geht es in die Beschaffung und ins Rechnungswesen. In deutschen Texten begegnet der Beleg als FAB, technisch unter dem Kürzel SFIR — wer nach einem der beiden Kürzel sucht, findet die Tabellen des anderen nicht.
Braucht es TM überhaupt?
Die Frage kommt in jedem Projekt, in dem Frachtkosten mit Spediteuren abzurechnen sind. Im S/4HANA gibt es dafür drei Standardwege — und keinen vierten.
- Frachtabrechnung im embedded TM. Die Zielarchitektur, mit Planung, Frachtkostenberechnung und Abrechnungsbeleg in einem Zug.
- Transportabwicklung in Logistics Execution. Transportbeleg und Frachtkostenbeleg, Frachtkalkulation über die Konditionstechnik, Kontierung und Bestellfindung, Leistungserfassung, dann Gutschriftsverfahren oder Rechnungsprüfung. Funktional der nächste Verwandte zu TM; die Objekte und ihr Standard-Customizing liegen im S/4HANA vor. Haken: Die Anwendung steht im Compatibility Scope, dessen Ende SAP derzeit für Ende 2030 plant. Nur das Routen-Objekt ist dauerhaft übernommen worden.
- Reine Dienstleistungsbeschaffung. Rahmenvertrag je Spediteur, Leistungserfassung, Rechnungsprüfung oder Gutschriftsverfahren. Dauerhaft und ohne Ablaufdatum — aber der Preis kommt aus dem Vertrag, nicht aus einer Frachtkalkulation. Das ist der eigentliche Funktionsverlust gegenüber den ersten beiden Wegen.
Für die Eingangsfracht gibt es zusätzlich den Weg über geplante Bezugsnebenkosten in der Bestellung, mit dem Spediteur als Frachtlieferanten. Dauerhaft, aber nur für die Beschaffungsseite.
Was in der Diskussion oft als Argument auftaucht und keines ist: das Gutschriftsverfahren. Es gibt es in allen drei Varianten, als Einzel- oder Sammelgutschrift je Spediteur und Periode. Es spricht weder für noch gegen TM.
Ein Wort, zwei Objekte: Transportbedarf
Im klassischen Lagerverwaltungsumfeld ist der Transportbedarf die Vorstufe des Transportauftrags. Im Transportmanagement ist er die Vorstufe der Frachteinheit — ein völlig anderes Objekt, in einem anderen Namensraum. Sucht man im Data Dictionary nach dem Begriff, kommen ausschließlich die Treffer der Lagerseite; der TM-Begriff steckt in einer Kategorien-Domäne.
Dazu kommt: Diese Domäne kennt eigene Werte für „transient“. Dann existiert schlicht kein Beleg, den man aufrufen könnte — die Frachteinheit entsteht direkt am Vorgängerbeleg. Wer in dieser Konstellation nach einem Transportbedarf sucht, sucht nach etwas, das es nie gab.
Die Lagerseite derselben Kette steht unter EWM, der gemeinsame Lade- und Entladeschritt unter Advanced Shipping and Receiving. Zurück zur Übersicht: EWM/TM.
Steht eine Lieferung in der Transportplanung fest: Nennen Sie mir Belegart, Steuerschlüssel, Lagerausführungsstatus und Sperre. Aus diesen vier Werten lässt sich im Telefonat sagen, ob die Ursache im Transport, im Lager oder im Außenhandel sitzt.