Prozessketten, Cluster, Customizing und Logging in SAP WM und SAP EWM

Das Aktionsframework aus dem status C Connected Warehouse.

Das hauseigene Aktionsframework ist ein zentraler Baustein des status C Connected Warehouse: Es zerlegt wiederkehrende Prozesslogiken in kleine Aktionen, setzt diese zu Prozessketten zusammen und lässt sich auf kundenspezifische Bedürfnisse einfach customizen – über alle Produkte des Connected Warehouses hinweg.

Das Ergebnis: einheitliche Benutzerführung, robusteres Coding und kundenspezifische Erweiterungen ohne Modifikation.

Unsere Autoren und Experten

Pascal Contursi

Business Development & Digital-Marketing

Autor

Hendrik Piotter

Entwicklung SAP

Experte
Zuletzt aktualisiert am 07.05.2026

Was ist das Aktionsframework von status C?

In der Lagerpraxis sind Prozesse selten „einfach nur Standard“. Selbst in scheinbar klaren Abläufen – etwa beim Quittieren einer Lageraufgabe – sind oft Prüfungen, Eingaben und Folgeschritte nötig: Leerplatzkontrolle, Differenzenkennzeichen, Ausnahmecodes, Quittierungsschritte, Folgeaktionen wie Fahraufträge oder Liftläufe. 

Genau solche wiederkehrenden Blöcke sind teuer, wenn man sie jedes Mal neu „hart“ in eine Anwendung programmiert. Und noch teurer wird es, wenn dieselbe Logik in mehreren Produkten über diverse Lagerhardware hinweg konsistent laufen soll. 

Genau hier setzt das Aktionsframework von status C an. Das Aktionsframework ist ein leichtgewichtiges Framework, das in alle Produkte des Connected Warehouses integriert ist und zwei Dinge ermöglicht:

  1. Elementare Aktionen: kleine, klar abgegrenzte Funktion (z. B. „Nullkontrolle prüfen“, „Seriennummern erfassen“, „Quittierung ausführen“).

  2. Prozessketten: eine konfigurierbare Abfolge solcher Aktionen – als „Orchestrierung“ für einen Prozessschritt. 

Kernidee: Beim Klick auf „Bestätigen/Quittieren“ wird kein monolithischer, hartcodierter Ablauf mehr ausgeführt, sondern eine definierte Prozesskette gestartet. 

Übergreifende Verfügbarkeit sorgt für flächendeckende Dominanz in allen Prozessen.

Das Aktionsframework ist nicht nur ein Feature für ein einzelnes Modul, sondern ein übergreifender Mechanismus: Aktionen und Prozessketten „ziehen“ sich durch alle Produkte – von kleineren Kernidee: Beim Klick auf „Bestätigen/Quittieren“ wird kein monolithischer, hartcodierter Ablauf mehr ausgeführt, sondern eine definierte Prozesskette gestartet. 

Ausprägungen bis zur vollständigen Integration über mehrere Produkte hinweg. 

Das ist entscheidend, weil viele Prozesslogiken produktübergreifend identisch sein sollen: Quittierlogiken, Standardprüfungen und Benutzerführung müssen sich nicht je Produkt „neu erfinden“. 

Der Kernmechanismus: Prozessketten per Customizing

Ein typisches Beispiel ist die Bestätigung/Quittierung:

  • EWM-Spezifika prüfen (z. B. Leerplatzkontrolle)

  • Differenzenkennzeichen / Ausnahmecodes

  • Quittierungsschritte (z. B. LB quittieren)

  • Optionale Folgeprozesse (z. B. nächster Fahrauftrag, Liftlauf etc.) 

Statt einen komplexen Ablauf als zusammenhängenden „Methodenblock“ fest zu codieren, wird die Logik in klar abgegrenzte Aktionen zerlegt und zu einer Prozesskette zusammengesetzt. Welche Prozesskette in einem Prozessschritt ausgeführt wird, wird per Customizing gesteuert – typischerweise direkt am jeweiligen UI-Button (z. B. „Bestätigen“, „Abbrechen“, „Überspringen“).

Dieses Prinzip lässt sich auch an Lift-Panels abbilden: Der Quittierimpuls wird technisch als Button-Trigger verarbeitet, sodass die konfigurierte Prozesskette im Hintergrund läuft, ohne den Anwenderfluss zu verändern. 

Ein großer Hebel ist die Wiederverwendbarkeit: Teilketten (z. B. Nullkontrolle + Differenzen + Ausnahmecodes) lassen sich kopieren und in andere Produkte/Prozesse übernehmen, sofern sie dort genauso gelten.

Zusätzlich profitiert jeder Kunde im Standardumfang von einem kontinuierlich wachsenden Set an Best-Practice-Prozessketten: Bewährte Präzedenzfälle aus Kundenprojekten fließen als wiederverwendbare Aktionen und Teilketten in den Baukasten ein – und werden als vordefinierte Prozessketten mit ausgeliefert.

Bereit für personalisierte Prozessketten? Lassen Sie uns sprechen!

Chirurgische Präzision statt Coding Chaos.

Elementare Aktionen und konstantes Prozesslogging für besseres Bugfixing:

Elementare Aktionen folgen einem klaren Schema:

  • Aktionsname (mit definierter Nomenklatur)

  • zuständige Implementierung (z. B. nur in einer ABAP-Klasse)

  • kurze Beschreibung/Dokumentation dessen, was die Aktion tut.

Wichtig: Es können ausschließlich diejenigen Aktionen im Customizing eingestellt werden, die der semantischen Anforderung (Implementierung des Interface) genügen.

Das sorgt für „chirurgische“ Eingriffe: Wenn eine Aktion einen Bug aufweist, wird dieser an einer Stelle korrigiert – und alle Produkte, die diese Aktion nutzen, profitieren davon. 

Ein weiterer Vorteil, den man im Alltag extrem schnell schätzen lernt, ist das konstante Prozesslogging. Die zentrale Quelle hierbei ist der standard SAP-Applikationslog. Mit dem Aktionsframework von status C werden Aktionen über definierte Objekte/Unterobjekte sichtbar und nachvollziehbar.

Beispiel aus dem Support: Ein Kunde kann „nicht quittieren“. Statt Ratespiel:

  • User + Zeitpunkt identifizieren

  • ins SAP-Applikationslog gehen

  • Aktionskette sehen (was wurde geklickt, welche Aktionen liefen, wo trat der Fehler auf)

  • zielgerichtet beheben.

Damit können auch kundenseitige SAP-Teams bereits in die Fehlersuche einsteigen – und Supportfälle werden schneller gelöst. 

Hendrik Piotter

Softwarearchitekt SAP, status C AG

„Wer Lagerprozesse heute noch als starre Methodenblöcke hart codiert, programmiert lediglich die teuren Altlasten von morgen. Statt monolithischer Abläufe nutzen wir modulare Prozessketten für eine Codebase, die modifikationsfrei mit den Anforderungen unserer Kunden wächst.“

Datencontainer: Eine gemeinsame „Sprache“ für alle Aktionen.

Damit Aktionen in einer Prozesskette sauber zusammenarbeiten, nutzt das Aktionsframework ein zentrales Konstrukt: Daten- und Produktcontainer. 

  • Er enthält Kontextdaten (z. B. aktive Lageraufgabe, Produkt, Sollmenge, Charge etc.) und einen gemeinsamen Datenpool, statt Verbuchungslogiken.

  • UI-Ein-/Ausgabefelder spiegeln sich in diesen Container; Änderungen werden sofort repliziert.

  • Der Container wird in die Prozesskette gegeben – und Aktionen können Werte validieren/anpassen, sodass alle Folgeaktionen mit den aktualisierten Daten weiterarbeiten.

Das macht Abläufe stabiler und ermöglicht, Daten „mitzunehmen“ – z. B. wenn während der Bestätigung Seriennummern erfasst werden und diese Information in Folgeaktionen oder Anzeigen wiederverwendet werden soll. 

Vorteile des Aktionsframeworks in SAP EWM auf einen Blick:

1) Einheitliche Quittier- und Prozesslogiken über alle Produkte

Standardbuchungen und Prozesslogiken laufen über Prozessketten vollkommen identisch; Produktspezifika bleiben da, wo sie hingehören (z. B. Bildsteuerung/gerätetypische Aspekte). 

Das Ergebnis ist auch in der Nutzerführung sichtbar: Wenn Seriennummern oder Differenzen erfasst werden müssen, sieht der Ablauf über alle status C Softwareprodukte identisch aus. 

2) Robustheit & Wartbarkeit: Anpassungen zentral umsetzen und überall wirksam machen

Anpassungen oder Erweiterungen an zentral genutzten Aktionen werden an einer Stelle umgesetzt und wirken anschließend konsistent über alle Produkte und Prozessketten hinweg. Bei Bedarf lassen sich solche Updates auch als gezielter Mini-Patch ausliefern – ohne komplettes Upgrade.

3) Kundenlogiken modifikationsfrei integrieren

Wenn ein Kunde beim Quittierzeitpunkt zusätzliche Anforderungen hat – z. B. drucken, Z-Tabellen befüllen, Materialetiketten-Scan erzwingen oder Pop-ups – wird das als kundenspezifische Aktion umgesetzt und in die Standardprozesskette eingehängt. 

Wichtig: Die Codebase des Standardprodukts bleibt unangetastet; die Erweiterung kann im Kundenumfeld verbleiben. 

Praxisbeispiele:

So wirkt das Framework im echten Lageralltag.

Praxisbeispiel 1:

Optionale Zusatzlogik (z. B. Advanced Order Picking) ohne Hardcoding.

Problem: Ein optionaler Prozessschritt (z. B. ein Add-on zum Add-on) soll vor/nach der Quittierung laufen – aber nicht bei jedem Kunden.

Lösung: Es wird eine eigene Aktion bereitgestellt und in die Prozesskette eingebunden; das Standardprodukt bleibt unabhängig von dieser Option. 

Ergebnis: Robusteres Coding, weniger Verzweigungen im Standard, Optionen bleiben konfigurierbar. 

Praxisbeispiel 2:

Kundenspezifische Anforderungen beim Quittieren (Druck, Z-Tabellen, Pflicht-Scan).

Problem: Der Kunde verlangt beim Quittieren zusätzliche Schritte: Etikett drucken, Z-Tabellen füllen, Materialetikett scannen.

Lösung: Umsetzung als kundenspezifische „Z-Aktion“ (granularer Baustein) und Einhängen in die Standardprozesskette – ohne Anpassung der Status-C-Standardcodebase. 

Ergebnis: Schnelleres Projekt, geringeres Upgrade-Risiko, Erweiterungen bleiben sauber getrennt. 

Praxisbeispiel 3:

Zusätzliche Anzeigen/Datenfelder zentral über den Datencontainer.

Problem: Zusätzliche Felder (z. B. Länder-Codes, HU-Infos etc.) sollen in mehreren Oberflächen verfügbar sein.

Lösung: Einmalige Erweiterung am Datencontainer; danach kann das Feld angezeigt und in Aktionen genutzt werden.

Ergebnis: Zentrale Datenhaltung, konsistente Darstellung und Verifikation – produktübergreifend.

Lesen Sie hier, wie unsere Kunden bereits von unserem Aktionsframework profitieren:

20. August 2025

Cloudbasiertes Ladungsträgermanagement bei Daimler Truck

And the Innovation Award goes to: Die Daimler Truck AG, alogis und status C. Wenn über 3.500 interne und externe Nutzer an einem einzigen Wochenende auf ein neues System umziehen, dabei Cloud-Apps und SAP RPM auf einer zentralen Plattform zusammenfinden und der Zugriff über die SAP Workzone rollengesteuert erfolgt, ist höchste Präzision gefragt. Doch der Aufwand hat sich gelohnt – denn Daimler Truck verfügt nun über ein ausgezeichnetes, zukunftsfähiges Container-Managementsystem.

5. August 2025

Embedded SAP TM und Fiori bei Daimler Truck

Daimler Truck AG transformiert das Ladungsträgermanagement: Elf Werke, über 4,5 Millionen Lieferabrufe und mehr als 375.000 Leihgutkontenrelationen – migriert in nur einem Wochenende. Mit einer SAP S/4HANA-Lösung inklusive Embedded TM und SAP Fiori gelang der Go-Live einen Monat vor Plan – und das bei voller Systemstabilität. Erfahren Sie, wie intuitive Anwendungen, ein durchdachtes Schulungskonzept und die enge Zusammenarbeit mit status C und alogis ein Projekt dieser Größe erfolgreich machten – und ein skalierbares Fundament für die Zukunft gelegt wurde.

19. März 2025

AutoStore-Integration direkt in SAP bei Balluff

Weltweit auf Effizienz programmiert – AutoStore-Integration bei Balluff in Rekordzeit.

Zwei Kontinente, zwei Standorte, ein Ziel: maximale Effizienz. Mit der AutoStore-Integration in Veszprém (Ungarn) und Florence (USA) optimiert Balluff seine Lager- und Distributionsprozesse für die Zukunft.

Unter 30 Tage pro Standort, maßgeschneidertes Customizing und eine Pick-Leistungssteigerung von bis zu 70 % – mit status C store:IT trifft Automatisierung auf Präzision.