Advanced Shipping and Receiving verklammert Transportmanagement und Lagerverwaltung zu einem gemeinsamen Lade- und Entladeschritt. Im Deutschen heisst der Prozess „erweiterter Warenannahme- und Versandprozess“, in SAP-eigenen Feldtexten mit EWV abgekürzt. Auf dieser Seite steht, was ich bei einer Einführung kläre: an welchen Belegen die Kette hängt, wo die Relevanz gesetzt wird und welche Verwechslungen mich in der Fehlersuche Zeit gekostet haben.
Was der Prozess zusammenfasst
Ohne diesen Prozess laufen zwei Versandwelten nebeneinander: Das Lager kommissioniert, packt und bucht den Warenausgang, das Transportmanagement plant Frachteinheiten und Frachtaufträge und dokumentiert die Verladung für sich. Advanced Shipping and Receiving ersetzt das durch einen Schritt, den beide Seiten teilen. Die Transaktion heisst im System schlicht „Frachtaufträge laden oder entladen“ (/SCMTMS/ASR) und deckt damit Versand und Warenannahme in derselben Logik ab. Genau an dieser Naht setze ich an: Was vorher zweimal dokumentiert wurde, läuft danach als ein Schritt.
Die Belegkette, die ich zuerst aufnehme
Bevor ich über die Verladung spreche, nehme ich die Belegkette auf. Sie beginnt im Vertriebs- oder Beschaffungsbeleg und endet in der Frachtabrechnung; dazwischen liegen zwei getrennte Belegwelten mit eigenen Nummern und eigenen Tabellen. Diese Aufstellung ist das Erste, was ich mit dem Fachbereich durchgehe.
| SD-Lieferung (LIKP) | trägt den Steuerschlüssel für die Belegübertragung an das Transportmanagement |
| TM-Planung | Frachteinheit und Frachtauftrag, beide in /SCMTMS/D_TORROT, unterschieden über die Belegkategorie (FU beziehungsweise TO) |
| EWM-Lieferbeleg | Anlieferung (/SCDL/DB_PROCH_I) beziehungsweise Auslieferungsauftrag (/SCDL/DB_PROCH_O) |
| Lageraufgabe | je Bewegung, gesteuert über die Lagerprozessart (/SCWM/T333); offen in /SCWM/ORDIM_O, quittiert in /SCWM/ORDIM_C |
| Lagerauftrag | Bündelung der Lageraufgaben je Aktivitätsbereich (/SCWM/WHO, Feld AREAWHO) |
| Lade- und Entladeschritt | gemeinsamer Schritt von Transportmanagement und Lager (/SCMTMS/ASR) |
| Frachtabrechnungsbeleg | entsteht aus dem Frachtauftrag heraus (/SCMTMS/D_SF_ROT) |
Das Scharnier ist die Lieferung
Will ich wissen, ob Transportmanagement und Lager sauber verzahnt sind, schaue ich in den Lieferkopf. LIKP trägt genau vier Felder mit dem Präfix TM_: den Steuerschlüssel für die Belegübertragung (TM_CTRL_KEY), die Relevanz für den erweiterten Warenannahme- und Versandprozess (TM_ADV_SHIP_RECV), den Lagerausführungsstatus (TM_WHSE_EXEC) und die Lagerausführungssperre (TM_WHSE_BLOCK).
Auf den Lagerausführungsstatus sehe ich dabei zuerst. Er macht die Reihenfolge unmissverständlich: erst die Transportplanung, dann die Lagerausführung. Seine Domäne kennt fünf Werte.
| leer | nicht relevant |
| 1 | Lieferung ist für die Lagerausführung gesperrt |
| 2 | Lieferung ist für die Lagerausführung freigegeben |
| 3 | Lieferung ist in Lagerabwicklung |
| 4 | Lieferung ist bereit für den Versand |
Eine Lieferung, die im Lager nicht auftaucht, ist deshalb häufig kein Lagerproblem. Ich prüfe dann den Status: Steht er auf 1, wartet die Lieferung auf die Freigabe aus der Transportplanung.
Wo ich die Relevanz suche
Der Prozess wird nicht mit einem Schalter eingeschaltet. Die Relevanz kann an mehreren Stellen hängen, und genau diese Stellen gleiche ich ab, bevor der erste Test läuft.
- Lokation — Feld ADV_SHP_RECV_RLV im Lokationsstamm
- Frachtauftragsart — Feld ASR_SETTING im Belegarten-Customizing /SCMTMS/C_TORTY; die Domäne kennt nur zwei Ausprägungen, deaktivieren und aktivieren
- einzelner Frachtbeleg — Feld ASR_SETTING in /SCMTMS/D_TORROT
- Lieferung — LIKP-TM_ADV_SHIP_RECV
- Stopp im Frachtauftrag — eigenes Kennzeichen für die Stopprelevanz
- sofortiges Laden im Prozess — eigenes Kennzeichen auf dem Lieferbeleg
Deshalb reicht es mir nicht, nur die Frachtauftragsart zu prüfen. Ist dort nichts hinterlegt, kann die Relevanz allein über die Lokation kommen — der Prozess ist dann aktiv, obwohl das Belegarten-Customizing leer aussieht. Das ist die Stelle, an der ich in der Praxis Zeit verloren habe: Wer diese beiden Ebenen nicht auseinanderhält, diskutiert stundenlang über ein vermeintlich fehlendes Customizing.
Verwechslungen, die mich in der Einführung Zeit gekostet haben
- Ich trenne den Auslieferungsauftrag im Lager von der Auslieferung aus dem Vertrieb. Es sind zwei Belege in zwei Welten, mit eigenen Nummern und eigenen Tabellen; der Lagerbeleg ist Folgebeleg, nicht Kopie.
- Beim Transportbedarf frage ich nach, welche Welt gemeint ist — der Begriff ist doppelt belegt. Im klassischen Lagerverwaltungsumfeld ist er die Vorstufe des Transportauftrags (LTBK, LTBP), im Transportmanagement die Vorstufe der Frachteinheit — und dort kann er transient sein. Die Kategorienliste führt eigene Werte für „transient“; dann existiert schlicht kein persistenter Beleg, den man aufrufen könnte.
- Nach einem „Lagerprozess“ suche ich im System nicht mehr — als Objekt gibt es ihn nicht. Lagerprozessart und Lagerprozesstyp sind zwei verschiedene Felder mit zwei verschiedenen Aufgaben; die Art steuert, wie eine Lageraufgabe abgewickelt wird.
- Die Packstruktur heisst je nach Welt anders: im ERP Packvorschrift, im Lager Packspezifikation. Ich kläre deshalb vorab, welche von beiden gemeint ist; wer sie gleichsetzt, plant die Verteilung falsch.
Was ich bei einer Einführung übernehme
- Aufnahme der bestehenden Versandabwicklung und Abgrenzung, welcher Teil künftig gemeinsam laufen soll
- Festlegung der Relevanz über Lokation, Belegart und Lieferung, einschliesslich der Frage, was bewusst ausserhalb bleibt
- Durchstich der Kette von der Lieferung über die Transportplanung und die Lagerausführung bis zum Lade- und Entladeschritt
- Abstimmung der Schnittstellen an den Rändern: Avis und Kennzeichnung zum Kunden, Frachtabrechnung Richtung Beschaffung und Rechnungswesen
- Eingrenzung eines Fehlerbildes im laufenden Betrieb, mit Befund und Korrekturvorschlag
- dokumentierte Übergabe an das Inhouse-Team
Jede transportfähige Änderung geht in einen Transport, auch die kleine. Gibt es einen dokumentierten Standardweg, nehme ich ihn statt einer Eigenentwicklung.
Wenn eine Lieferung nicht im Lager ankommt oder die Verladung nicht zur Frachtabrechnung passt: Nennen Sie mir den Belegtyp, den Lagerausführungsstatus und den betroffenen Beleg. Damit ordne ich im Telefonat ein, an welcher der beiden Welten es hängt. Den Umfang klären wir im ersten Gespräch.
Aus der Praxis
Ausgangslage. Ein Automobilkonzern baute ein konzernweites Template für den Outbound auf — Vertrieb, Lager und Transport in einem gemeinsamen Prozessbild. Versand und Transportplanung liefen dort als getrennte Welten mit eigenen Belegen. Für den erweiterten Warenannahme- und Versandprozess stand ein konzernweiter Rollout an, zusammen mit der Anbindung der Lagerverwaltung.
Auftrag. Ich war dort fachlich für das Prozessthema Outbound zuständig, über Vertrieb, Lager und Transport hinweg. Mein Auftrag war der konzernweite Rollout der Advanced-Shipping-and-Receiving-Funktion für das Transportmanagement, einschließlich der Integration in die Lagerverwaltung. Der Prozess sollte im Template liegen und nicht je Standort neu entstehen.
Vorgehen. Ich habe den gemeinsamen Lade- und Entladeschritt im Outbound-Template entworfen und mit der Lagerausführung verzahnt. Konzept, Umsetzung und Abnahme habe ich mit den Prozesseignern und dem Template-Gremium abgestimmt. Die Kette lief danach durch Integrations-, Abnahme- und Prozesskettentests, bevor sie in die Werke ging.
Ergebnis. Der gemeinsame Lade- und Entladeschritt liegt seither als Baustein des Outbound-Templates vor und wird über den konzernweiten Rollout in die Werke getragen. Übergeben habe ich ihn an die Prozesseigner im Konzern. Was mir dabei an Verwechslungen und verstreuten Relevanzstellen begegnet ist, steht in den Abschnitten oben.