Ihr Daten-Template für die Lagerverwaltung
Ihr Daten-Template für die Lagerverwaltung
- Empfohlene Attribute für eine umfassende Analyse
- Wichtige Aktivitäten, die Sie im Prozess erfassen sollten
- Hinweise zur Datenextraktion aus SAP EWM
Attribute der Lagerverwaltung
| Name | Beschreibung | ||
|---|---|---|---|
| Warehouse Order WarehouseOrder | Die eindeutige Kennung eines Warehouse Order, der mehrere von einer Ressource auszuführende Lageraufgaben zusammenfasst. | ||
| Beschreibung Der Warehouse Order dient als primäre Case-ID, um den durchgängigen Prozess der Warenbearbeitung im Lager nachzuverfolgen. Er steht für ein Arbeitspaket, etwa die Kommissionierung von Artikeln für eine Auslieferung oder die Einlagerung eingegangener Waren. Jeder Warehouse Order umfasst eine oder mehrere Lageraufgaben. In Process Mining ermöglicht die Analyse nach Warehouse Order einen umfassenden Einblick in den gesamten Lebenszyklus eines bestimmten Arbeitspakets. So lassen sich Engpässe erkennen, die Gesamtzykluszeit von der Anlage bis zum Abschluss messen und alle Aktivitäten nachvollziehen, die zu einer einzelnen logistischen Anweisung gehören. Warum das wichtig ist Diese zentrale Kennung verknüpft alle zugehörigen Lageraktivitäten. So lassen sich der Prozess durchgängig analysieren und die Zykluszeit für eine einzelne Arbeitseinheit messen. Woher beziehen Diese Kennung findet sich üblicherweise in der Kopftabelle für Warehouse Orders in SAP EWM, zum Beispiel in /SCWM/WHO. Beispiele 200000145200000146200000147 | |||
| Aktivitätsname ActivityName | Der Name der konkreten Lagerverwaltungsaktivität oder des eingetretenen Ereignisses, zum Beispiel „Kommissionieraufgabe angelegt“ oder „Warenausgang gebucht“. | ||
| Beschreibung Dieses Attribut beschreibt einen einzelnen Schritt oder ein Ereignis im Lagerverwaltungsprozess. Diese Aktivitäten bilden die Bausteine der Prozesslandkarte und stehen für Aufgaben wie Anlage, Bestätigung, Verpackung, Verladung und Warenbewegungen. Die Analyse der Reihenfolge und Häufigkeit dieser Aktivitäten ist eine Grundlage für Process Mining. Sie macht den Prozessablauf sichtbar, zeigt häufige und seltene Pfade, deckt Abweichungen von der Standardvorgehensweise auf und hilft, Schritte mit Verzögerungen oder Nacharbeit zu ermitteln. Warum das wichtig ist Das Attribut legt die Prozessschritte fest. Es bildet die Grundlage der Prozesslandkarte und ermöglicht die Analyse von Prozessabläufen, Abweichungen und Engpässen. Woher beziehen Wird aus Statusänderungen, Ereignismeldungen oder Transaktionsprotokollen zu Warehouse Orders und Aufgaben abgeleitet, etwa aus der Tabelle /SCWM/ORDIM_C (Bestätigungen), oder durch Auswertung der Statusfelder in /SCWM/WHO und /SCWM/ORDIM_O. Beispiele Kommissionieraufgabe bestätigtEinlagerungsaufgabe angelegtWareneingang gebuchtWarehouse Order abgeschlossen | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp, der angibt, wann die Daten dieses Datensatzes zuletzt aus dem Quellsystem aktualisiert wurden. | ||
| Beschreibung Dieses Attribut erfasst, wann die Daten zuletzt aus dem Quellsystem extrahiert wurden. Es gibt wichtigen Aufschluss darüber, wie aktuell die analysierten Daten sind. Für Analysen und Dashboards ist es wichtig zu wissen, wie aktuell die Daten sind, um fundierte Entscheidungen zu treffen. Anhand dieses Timestamps erkennen Benutzer, ob sie Echtzeitinformationen oder einen Datenstand von einem bestimmten Zeitpunkt betrachten. So können sie die Aktualität der Daten besser einschätzen. Warum das wichtig ist Zeigt die Aktualität der Daten an. So können Benutzer einschätzen, wie aktuell ihre Prozessanalyse ist. Woher beziehen Dieses Metadatenfeld wird üblicherweise während der Datenextraktion (ETL) erzeugt und hinzugefügt. Es enthält den Timestamp der Datenladung. Beispiele 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Quellsystem SourceSystem | Gibt das Quellsystem an, aus dem die Daten extrahiert wurden, zum Beispiel die SAP-EWM-Produktivinstanz. | ||
| Beschreibung Dieses Attribut gibt das führende System an, aus dem die Lagerverwaltungsdaten stammen. In Unternehmen mit mehreren Systemen ist es wichtig, die Herkunft der Daten für Rückverfolgbarkeit und Kontext zu kennzeichnen. Bei der Analyse hilft das Attribut, Prozesse zu unterscheiden, die mehrere Systeme umfassen, oder Prozesse aus verschiedenen Instanzen zu vergleichen, etwa aus getrennten Systemen für unterschiedliche Regionen. So bleibt die Datenherkunft nachvollziehbar und auditfähig. Warum das wichtig ist Sorgt für Rückverfolgbarkeit und Kontext, insbesondere bei mehreren SAP-Instanzen oder integrierten Systemen, und macht die Datenherkunft nachvollziehbar. Woher beziehen Dabei handelt es sich üblicherweise um einen statischen Wert, der während der Datenextraktion, -transformation und -ladung (ETL) hinzugefügt wird. Er kennzeichnet die jeweilige SAP-S/4HANA- oder EWM-Instanz. Beispiele SAP_EWM_PROD_EUS4H_US_100EWM_APAC_PRD | |||
| Startzeit EventTime | Der Timestamp, der angibt, wann die Aktivität oder das Ereignis begonnen hat. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit, zu denen eine bestimmte Lageraktivität stattgefunden hat. Es ist die zentrale Zeitangabe für die chronologische Sortierung von Ereignissen und die Berechnung der Zeitabstände zwischen ihnen. In Process Mining ist die Startzeit entscheidend, um die Ereignisse für jeden Case chronologisch anzuordnen. Sie dient zur Berechnung von Zyklus-, Warte- und Verarbeitungszeiten, die für die Leistungsanalyse, das Erkennen von Engpässen und die SLA-Überwachung wichtig sind. Warum das wichtig ist Dieser Timestamp ist entscheidend, um Ereignisse chronologisch anzuordnen und zeitbasierte Leistungskennzahlen wie Zykluszeiten und Zeitdauern zu berechnen. Woher beziehen Findet sich üblicherweise in Ereignis- oder Bestätigungstabellen wie /SCWM/ORDIM_C (zum Beispiel im Feld CONF_TIMESTAMP) oder in Protokollen zu Statusänderungen von Warehouse Orders und Aufgaben. Beispiele 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-26T11:20:00Z | |||
| Benutzer-ID User | Die Kennung der Lagerkraft oder des Benutzers, der die Aktivität ausgeführt oder bestätigt hat. | ||
| Beschreibung Dieses Attribut erfasst die Benutzer-ID der Person, die für die Ausführung einer Lageraufgabe verantwortlich ist. Das kann die kommissionierende Person sein, die eine Entnahme bestätigt, die Verpackungskraft an einer Verpackungsstation oder die Gabelstaplerfahrerin beziehungsweise der Gabelstaplerfahrer, die oder der eine Einlagerung bestätigt. Diese Daten sind wichtig für das Dashboard „Ressourcen- und Gerätenutzung“. Sie ermöglichen die Analyse der Leistung einzelner Personen oder Teams, helfen, Schulungsbedarf zu erkennen, und unterstützen eine ausgewogenere Verteilung der Arbeitslast im Lager. Warum das wichtig ist Ordnet Aufgaben bestimmten Personen zu. So lässt sich die Leistung nach Benutzer oder Team analysieren und das Ressourcenmanagement sowie die Arbeitslastverteilung unterstützen. Woher beziehen Findet sich üblicherweise in den Bestätigungsdaten einer Lageraufgabe, zum Beispiel im Feld UNAME der Tabelle /SCWM/ORDIM_C. Beispiele JSMITHARODRIGUEZOPERATOR_05 | |||
| Endzeit EventEndTime | Der Timestamp, der angibt, wann eine Aktivität oder ein Ereignis abgeschlossen wurde. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit, zu denen eine bestimmte Lageraktivität beendet wurde. Bei einzelnen Ereignissen entspricht die Endzeit oft der Startzeit. Bei Aktivitäten mit messbarer Dauer, etwa Verpackung oder Verladung, kann sie davon abweichen. Eine separate Endzeit ermöglicht die genaue Berechnung der Bearbeitungsdauer einzelner Aktivitäten. Das ist wichtig für Leistungs-Dashboards, die die Dauer bestimmter Schritte wie „Effizienz bei Kommissionierung und Verpackung“ analysieren und zeigen, welche Aufgaben am meisten Zeit beanspruchen. Warum das wichtig ist Ermöglicht die genaue Berechnung der Dauer einzelner Aktivitäten. Das ist wichtig, um zeitaufwendige Schritte und ressourcenintensive Aufgaben zu erkennen. Woher beziehen Bei einzelnen Ereignissen entspricht die Endzeit häufig dem Start-Timestamp. Bei länger dauernden Aufgaben kann sie in Tabellen wie /SCWM/ORDIM_C als separates Feld vorliegen oder aus einer späteren Statusänderung abgeleitet werden. Beispiele 2023-10-26T10:05:00Z2023-10-26T10:25:45Z2023-10-26T11:20:00Z | |||
| Materialnummer MaterialNumber | Die eindeutige Kennung des Produkts oder Materials, das im Rahmen der Lageraufgabe bearbeitet wird. | ||
| Beschreibung Dieses Attribut gibt das Material an, das bewegt, kommissioniert, verpackt oder entgegengenommen wird. Es ist eine wichtige Dimension, um die Lagerleistung nach Produkteigenschaften aufzuschlüsseln und zu analysieren. Die Analyse nach Materialnummer beantwortet Fragen wie: Bei welchen Produkten dauert die Einlagerung am längsten? Welche sind besonders häufig von Kommissionierfehlern betroffen? Für welche ist eine Qualitätsprüfung erforderlich? Das ist wichtig für die Dashboards „Leistung bei Wareneingang und Einlagerung“ sowie „Durchlaufzeit der Qualitätsprüfung“. Warum das wichtig ist Ermöglicht es, Prozessdaten nach Produkt zu filtern und aufzuschlüsseln. So lassen sich produktspezifische Probleme bei Handhabung, Lagerung oder Qualitätskontrolle erkennen. Woher beziehen Diese Information ist üblicherweise in Tabellen zu Lageraufgaben wie /SCWM/ORDIM_O verfügbar und mit den Materialstammdaten verknüpft. Beispiele FIN-1001RAW-2050SFIN-300-A | |||
| Priorität Priority | Die einem Lagerauftrag zugewiesene Prioritätsstufe, die seine Dringlichkeit angibt, zum Beispiel hoch, mittel oder niedrig. | ||
| Beschreibung Dieses Attribut ordnet Lageraufträge nach ihrer geschäftlichen Bedeutung oder Dringlichkeit ein. Aufträge mit hoher Priorität können beispielsweise Expresslieferungen oder die Versorgung einer kritischen Produktion betreffen und müssen schneller bearbeitet werden. Die Priorität ist eine wichtige Dimension für das Dashboard und die KPI zur Einhaltung der Bearbeitungsfristen für priorisierte Aufträge. Sie ermöglicht es, die Leistung zu filtern und aufzuschlüsseln. So lässt sich sicherstellen, dass besonders wichtige Aufträge innerhalb der erwarteten Fristen bearbeitet werden und der Lagerbetrieb die Geschäftsziele unterstützt. Warum das wichtig ist Ermöglicht eine gezielte Analyse und Überwachung, damit dringende Aufträge ihre Serviceziele erreichen. Das wirkt sich direkt auf die Kundenzufriedenheit aus. Woher beziehen Die Priorität kann im zugrunde liegenden Lieferbeleg festgelegt und an den Lagerauftrag übertragen werden. Sie ist möglicherweise in Tabellen wie /SCWM/WHO zu finden. Beispiele HochMittelNiedrig | |||
| Status des Warehouse Order WarehouseOrderStatus | Der aktuelle oder endgültige Status des Warehouse Order, zum Beispiel „Abgeschlossen“ oder „Storniert“. | ||
| Beschreibung Dieses Attribut gibt das Endergebnis eines Lagerauftrags an. Ob ein Auftrag erfolgreich abgeschlossen oder storniert wurde, ist entscheidend, um Erfolgsquoten zu analysieren und Gründe für nicht abgeschlossene Aufträge zu ermitteln. Bei vielen Analysen dient dieses Attribut als wichtiger Filter. Für die Berechnung der durchgängigen Lagerdurchlaufzeit werden beispielsweise in der Regel nur abgeschlossene Aufträge berücksichtigt. Außerdem hilft es dabei, Häufigkeit und Ursachen stornierter Aufträge zu untersuchen. Warum das wichtig ist Gibt das Ergebnis eines Cases an. So lassen sich abgeschlossene und stornierte Aufträge unterscheiden, was für eine präzise Analyse von Zykluszeit und Durchsatz entscheidend ist. Woher beziehen Das Statusfeld befindet sich in der Regel in der Kopftabelle für Lageraufträge, /SCWM/WHO. Beispiele AbgeschlossenIn BearbeitungStorniert | |||
| Warehouse-Order-Typ WarehouseOrderType | Ordnet den Warehouse Order nach seinem Zweck ein, zum Beispiel Einlagerung, Kommissionierung oder interne Nachschubversorgung. | ||
| Beschreibung Der Warehouse-Order-Typ kategorisiert Aufträge nach ihrer logistischen Funktion. Diese Unterscheidung ist wichtig, weil verschiedene Auftragstypen unterschiedlichen Prozessabläufen folgen und andere Leistungserwartungen haben. In der Analyse dient dieses Attribut als zentrale Dimension für Filter und Vergleiche. Das Dashboard „Durchsatz und Volumen der Warehouse Orders“ nutzt es beispielsweise, um die Leistung bei Wareneingangsprozessen (Einlagerung) und Auslieferungsprozessen (Kommissionierung) getrennt darzustellen. So erhalten Sie ein aussagekräftigeres Bild der Lagerabläufe. Warum das wichtig ist Ermöglicht die Aufschlüsselung der Analyse nach Prozesskategorie, etwa Wareneingang oder Auslieferung, und damit aussagekräftigere Vergleiche und Erkenntnisse. Woher beziehen Der Wert wird anhand des Lagerprozesstyps bestimmt, der häufig in der Kopftabelle für Warehouse Orders /SCWM/WHO zu finden ist. Beispiele PICKPUTWREPLSTGE | |||
| Angefordertes Abschlussdatum RequestedCompletionDate | Das Datum, bis zu dem ein Lagerauftrag mit hoher Priorität abgeschlossen werden soll. | ||
| Beschreibung Dieses Attribut legt die Service-Level-Vereinbarung (SLA) oder das angestrebte Abschlussdatum für einen Lagerauftrag fest. Anhand dieser Frist wird die tatsächliche Abschlusszeit gemessen, um festzustellen, ob der Auftrag pünktlich erledigt wurde. Das Datum ist für die Berechnung der KPI „Erfüllungsquote priorisierter Aufträge“ erforderlich. Durch den Vergleich des tatsächlichen Abschlusszeitpunkts mit dem angeforderten Datum lässt sich die Einhaltung der Serviceziele quantifizieren. Außerdem werden Aufträge sichtbar, bei denen eine Verspätung droht oder die bereits verspätet sind. Warum das wichtig ist Legt die SLA für einen Auftrag fest und dient als Maßstab für die pünktliche Erfüllung, insbesondere bei Artikeln mit hoher Priorität. Woher beziehen Dieses Datum wird häufig aus dem geplanten Warenausgangs- oder Lieferdatum des Auslieferungsauftrags abgeleitet, der den Lagerauftrag ausgelöst hat. Weitere Informationen finden Sie in der Dokumentation zu SAP Extended Warehouse Management. Beispiele 2023-10-27T17:00:00Z2023-10-28T12:00:00Z | |||
| Durchgängige Zykluszeit EndToEndCycleTime | Die gesamte Zeit vom Anlegen bis zum endgültigen Abschluss eines Lagerauftrags. | ||
| Beschreibung Diese KPI misst die gesamte Dauer eines Lagerauftrags von Anfang bis Ende. Sie ist ein wichtiger übergeordneter Indikator für Effizienz und Geschwindigkeit des Lagerbetriebs. Die Kennzahl bildet die Grundlage für das Dashboard zur durchgängigen Lagerdurchlaufzeit. Wird sie im Zeitverlauf verfolgt und nach Dimensionen wie Auftragstyp oder Material aufgeschlüsselt, lassen sich systematische Ineffizienzen erkennen und die Auswirkungen von Prozessverbesserungen auf den gesamten Betrieb messen. Warum das wichtig ist Diese zentrale KPI misst die Gesamteffizienz des Lagerprozesses und bietet einen übergeordneten Überblick über die operative Leistung. Woher beziehen Auf Case-Ebene berechnet, indem der Timestamp des ersten Ereignisses („Lagerauftrag angelegt“) vom Timestamp des letzten Ereignisses („Lagerauftrag abgeschlossen“) abgezogen wird. Beispiele 8640017280043200 | |||
| Geplante Abfahrtszeit PlannedDepartureTime | Der geplante Zeitpunkt, zu dem die Sendung das Lager verlassen soll. | ||
| Beschreibung Dieses Attribut gibt den angestrebten Versandzeitpunkt an, nachdem Kommissionierung, Verpackung und Verladung abgeschlossen sind. Er dient als Maßstab für die Pünktlichkeit der letzten Phase des Auslieferungsprozesses. Dieser Timestamp ist entscheidend für das Dashboard zur pünktlichen Versandabwicklung. Durch den Vergleich der tatsächlichen mit der geplanten Versandzeit lassen sich Verzögerungen bei der Verladung, der Abstimmung mit dem Frachtführer oder der Dokumentation erkennen. Das liefert Erkenntnisse zur Effizienz der Logistik- und Transportplanung. Warum das wichtig ist Dient als Vergleichswert für die Messung der pünktlichen Versandabwicklung. Das ist wichtig für die Logistikplanung und die Einhaltung der Zeitpläne von Frachtführern. Woher beziehen Diese Informationen sind üblicherweise im Transport- oder Versanddokument enthalten, das mit den Lageraufträgen verknüpft ist. Weitere Informationen finden Sie in der Dokumentation zu SAP Extended Warehouse Management. Beispiele 2023-10-27T18:00:00Z2023-10-28T14:00:00Z | |||
| Geplante Menge PlannedQuantity | Die erwartete Materialmenge für einen bestimmten Lagerauftrag. | ||
| Beschreibung Dieses Attribut gibt die Zielmenge eines Materials an, die gemäß der Anweisung für den Lagerauftrag bewegt, kommissioniert oder vereinnahmt werden soll. Sie dient als Vergleichswert für die tatsächlich ausgeführte Menge. Die geplante Menge ist eine wichtige Grundlage für das Dashboard „Analyse von Bestandsabweichungen“ und die KPI „Bestandsgenauigkeit“. Durch den Vergleich mit der tatsächlichen Menge kann das System Abweichungen erkennen, die auf Kommissionierfehler, Fehler bei der Warenannahme oder Probleme bei der Dateneingabe hindeuten. So lässt sich die Bestandsgenauigkeit verbessern. Warum das wichtig ist Dient als Vergleichswert zur Berechnung der Bestandsgenauigkeit und zur Ermittlung von Abweichungen. Das ist entscheidend, um korrekte Lagerbestände sicherzustellen. Woher beziehen Zu finden in den Daten zum Lagerauftrag, zum Beispiel in der Tabelle /SCWM/ORDIM_O, häufig in einem Feld wie NISTA (Zielmenge). Beispiele 10050250 | |||
| Lagerplatz StorageLocation | Der konkrete Ort im Lager, etwa ein Lagerfach, an den Waren bewegt oder von dem sie entnommen werden. | ||
| Beschreibung Dieses Attribut bezeichnet den physischen Ort, der an einem Lagerauftrag beteiligt ist, zum Beispiel den Quelllagerplatz bei der Kommissionierung oder den Ziellagerplatz bei der Einlagerung. Die Angabe kann einen größeren Lagerbereich oder eine genaue Regalposition bezeichnen. Die Analyse nach Lagerplatz kann operative Erkenntnisse liefern, etwa zu besonders stark frequentierten Bereichen mit hohen Kommissionierraten oder zu Bereichen, in denen es häufig zu Verzögerungen oder Fehlern kommt. Auch für die Analyse der Einhaltung von Kommissionierwegen ist sie hilfreich, um die Wege der Kommissionierer durch das Lager nachzuvollziehen. Warum das wichtig ist Ordnet Bewegungen einem Ort im Lager zu. So lassen sich Bewegungseffizienz, Zugänglichkeit der Lagerplätze und die Optimierung von Kommissionierwegen analysieren. Woher beziehen In der Regel in Tabellen zu Lageraufträgen wie /SCWM/ORDIM_O zu finden, mit Angaben zum Quelllagerplatz (VLPLA) und Ziellagerplatz (NLPLA). Beispiele 01-02-03PACK-STATION-01GI-ZONE-A | |||
| Mengenabweichung QuantityVariance | Die Differenz zwischen der geplanten und der tatsächlich bestätigten Menge eines Auftrags. | ||
| Beschreibung Diese berechnete Kennzahl gibt die Abweichung bei einem Lagerauftrag an. Ein Wert ungleich null bedeutet, dass die tatsächliche Menge nicht mit dem Systemeintrag übereinstimmt. Das kann auf ein Problem wie einen Kommissionierfehler, einen Fehler bei der Warenannahme oder einen beschädigten Artikel hindeuten. Dieses Attribut unterstützt direkt das Dashboard „Analyse von Bestandsabweichungen“, indem es das Ausmaß der Fehler sichtbar macht. Die Analyse von Häufigkeit und Größe der Abweichungen hilft, systematische Probleme in der Bestandsverwaltung und bei der operativen Ausführung zu erkennen und gezielte Verbesserungen der Genauigkeit einzuleiten. Warum das wichtig ist Quantifiziert Bestands- und Betriebsabweichungen direkt. So lassen sich Ausmaß und Ursachen der Differenzen leicht erkennen und analysieren. Woher beziehen Für jeden relevanten Auftrag berechnet, indem PlannedQuantity von ActualQuantity abgezogen wird. Beispiele 0-15 | |||
| Pünktlich abgeschlossen IsOnTime | Ein boolesches Kennzeichen, das angibt, ob ein Lagerauftrag bis zum angeforderten Abschlussdatum erledigt wurde. | ||
| Beschreibung Dieses Kennzeichen gibt eindeutig an, ob die SLA eingehalten wurde. Es prüft, ob das letzte Abschlussereignis eines Lagerauftrags am oder vor dem angegebenen angeforderten Abschlussdatum eingetreten ist. Das Attribut ist für das Dashboard zur Einhaltung der Bearbeitungsfristen für priorisierte Aufträge erforderlich. Es vereinfacht die Erstellung von KPIs und Visualisierungen, da pünktliche und verspätete Aufträge einfach gezählt und gefiltert werden können. So lässt sich die Leistung anhand der Serviceziele schnell beurteilen, ohne komplexe Datumsberechnungen in der Analyseebene durchführen zu müssen. Warum das wichtig ist Vereinfacht die Analyse der SLA-Leistung, indem für jeden Auftrag eindeutig angezeigt wird, ob die Erfüllung pünktlich oder verspätet erfolgte. Woher beziehen Dieses Attribut wird berechnet. Dazu wird der Timestamp der Aktivität „Lagerauftrag abgeschlossen“ mit dem Attribut „RequestedCompletionDate“ verglichen. Beispiele truefalse | |||
| Tatsächliche Menge ActualQuantity | Die tatsächliche Materialmenge, die der Benutzer für einen Lagerauftrag bestätigt hat. | ||
| Beschreibung Dieses Attribut gibt die Menge an, die der Lagerist tatsächlich bearbeitet und bestätigt hat. Das kann die aus einem Lagerplatz entnommene, eingelagerte oder bei einem Wareneingang gezählte Menge sein. Der Vergleich der tatsächlichen mit der geplanten Menge ist eine wesentliche Grundlage für die „Analyse von Bestandsabweichungen“. Eine Abweichung zwischen den beiden Werten weist direkt auf eine Prozessausnahme hin, die untersucht werden sollte. Sie ist ein direktes Maß für die operative Genauigkeit und fließt in die KPIs „Bestandsgenauigkeit“ und „Kommissionierfehlerquote“ ein. Warum das wichtig ist Dieses Attribut bildet ab, welche Menge tatsächlich bearbeitet wurde. Der Vergleich mit der geplanten Menge misst direkt die operative Genauigkeit und macht Fehler sichtbar. Woher beziehen Zu finden in den Bestätigungsdaten für Lageraufträge, zum Beispiel in der Tabelle /SCWM/ORDIM_C, häufig in einem Feld wie NDIFF (Differenzmenge) oder abgeleitet aus den bestätigten Mengen. Beispiele 10049250 | |||
| Verwendetes Gerät EquipmentUsed | Die Kennung des Geräts, etwa eines Gabelstaplers oder Hubwagens, mit dem der Lagerauftrag ausgeführt wird. | ||
| Beschreibung Dieses Attribut gibt das Flurförderzeug an, das einem Lagerauftrag zugewiesen ist oder für dessen Ausführung verwendet wird. Dazu zählen beispielsweise ein bestimmter Gabelstapler, ein fahrerloses Transportfahrzeug (AGV) oder ein bestimmter Wagentyp. Diese Daten bilden die Grundlage für das Dashboard „Ressourcen- und Gerätenutzung“ und die KPI „Gerätenutzungsgrad“. Wenn erfasst wird, welches Gerät für welche Aufträge und wie lange eingesetzt wird, können Verantwortliche Nutzungsmuster analysieren, Wartungen planen und fundierte Entscheidungen über Größe und Zusammensetzung des Fuhrparks treffen. Warum das wichtig ist Ermöglicht die Analyse der Gerätenutzung und -effizienz. So lassen sich der Fuhrpark besser planen und Engpässe bei Ressourcen erkennen. Woher beziehen Wenn das Ressourcenmanagement in SAP EWM eingerichtet ist, können diese Informationen in den Details zum Lagerauftrag oder Auftrag gespeichert sein. Weitere Informationen finden Sie in der Dokumentation zu SAP Extended Warehouse Management. Beispiele FORKLIFT-07AGV-02CART-15 | |||
| Warehouse Task WarehouseTask | Die eindeutige Kennung einer einzelnen Warehouse Task, die Teil eines Warehouse Order ist. | ||
| Beschreibung Eine Warehouse Task ist die Anweisung, eine bestimmte Warenbewegung auszuführen, etwa ein Produkt von einem Lagerplatz zu einer Verpackungsstation zu bewegen. Ein Warehouse Order fasst eine oder mehrere solcher Aufgaben zusammen. Die Analyse auf Aufgabenebene bietet einen detaillierteren Einblick in die Lagerabläufe. Sie zeigt die Ressourcenleistung bei bestimmten Bewegungen, hilft schwer erreichbare Lagerplätze zu erkennen und ermöglicht die Analyse der Effizienz einzelner Kommissionier- oder Einlagerungsaktivitäten. Warum das wichtig ist Ermöglicht eine detaillierte Analyse einzelner Bewegungen und Schritte innerhalb eines größeren Warehouse Order. Woher beziehen Findet sich in Tabellen zu Lageraufgaben wie /SCWM/ORDIM_O (Aufgabendaten) und /SCWM/ORDIM_C (Bestätigungsdaten). Beispiele 300000451300000452300000453 | |||
Aktivitäten der Lagerverwaltung
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Einlagerungsaufgabe bestätigt | Eine Lagerkraft bestätigt den Abschluss der Einlagerungs-Warehouse-Task. Damit ist die Ware physisch am vorgesehenen Lagerplatz eingelagert. Die Bestandsposition wird dadurch in Echtzeit aktualisiert. | ||
| Warum das wichtig ist Diese Aktivität ist ein wichtiger Meilenstein im Wareneingang und bestätigt, dass der Bestand für die Kommissionierung verfügbar ist. Verzögerungen wirken sich direkt auf die KPI „Zykluszeit vom Wareneingang bis zur Einlagerung“ aus. Woher beziehen Wird anhand des Bestätigungs-Timestamps (Feld CONFIRMED_AT) in der Warehouse-Task-Tabelle /SCWM/WT erfasst. Der Aufgabenstatus (STAT) wechselt ebenfalls zu „Bestätigt“. Erfassung Verwenden Sie den Bestätigungs-Timestamp aus der Tabelle /SCWM/WT für die mit dem Warehouse Order verknüpften Einlagerungsaufgaben. Ereignistyp explicit | |||
| Kommissionieraufgabe bestätigt | Eine Lagerkraft bestätigt den Abschluss einer Kommissionier-Warehouse-Task. Damit wird bestätigt, dass die Ware physisch aus ihrem Lagerplatz entnommen wurde. Die Bestätigung erfolgt in der Regel über einen RF-Scanner. | ||
| Warum das wichtig ist Dies ist ein wichtiger Meilenstein bei der Auftragsabwicklung und wirkt sich direkt auf die Durchlaufzeit vom Auftrag bis zum Versand aus. Die Analyse dieser Aktivität hilft, die Produktivität der Kommissionierenden zu messen und Engpässe bei der Kommissionierung zu erkennen. Woher beziehen Wird anhand des Bestätigungs-Timestamps (Feld CONFIRMED_AT) in der Warehouse-Task-Tabelle /SCWM/WT erfasst. Der Aufgabenstatus (STAT) wird auf „Bestätigt“ gesetzt. Erfassung Verwenden Sie den Bestätigungs-Timestamp aus der Tabelle /SCWM/WT für die mit dem Warehouse Order verknüpften Kommissionieraufgaben. Ereignistyp explicit | |||
| Verpackung abgeschlossen | Diese Aktivität zeigt an, dass alle Artikel einer Sendung in eine Handling Unit verpackt wurden, die nun geschlossen und etikettiert ist. Die verpackte Ware ist bereit für den nächsten Schritt, etwa die Bereitstellung oder Verladung. | ||
| Warum das wichtig ist Dieser Meilenstein schließt die Verpackungsphase ab. Er ist Voraussetzung für Bereitstellung und Versand. Verzögerungen wirken sich daher direkt auf die Gesamtdurchlaufzeit und die KPI „Durchlaufzeit für Verpackung und Bereitstellung“ aus. Woher beziehen Lässt sich erfassen, wenn der Status der Handling Unit (HU) auf „Geschlossen“ gesetzt oder die letzte verpackungsbezogene Warehouse Task für den WO bestätigt wird. Die Tabelle /SCWM/HUHDR enthält Statusinformationen zur HU. Erfassung Ermitteln Sie den Timestamp, zu dem die letzte mit dem Auftrag verknüpfte Versand-Handling-Unit geschlossen oder abgeschlossen wird. Ereignistyp inferred | |||
| Warehouse Order abgeschlossen | Der Status des Warehouse Order wird auf „Abgeschlossen“ gesetzt, sobald alle zugehörigen Lageraufgaben bestätigt wurden. Damit ist das Arbeitspaket aus Sicht der Ausführung beendet. | ||
| Warum das wichtig ist Dies ist das primäre erfolgreiche End-Event des Prozesses. Es ist entscheidend für die Berechnung der durchgängigen Lagerzykluszeit und die Messung des Gesamtdurchsatzes. Woher beziehen Wird erfasst, indem die Änderung des Statusfelds (STAT) auf „Abgeschlossen“ in der Kopftabelle für Warehouse Orders, /SCWM/WHO, nachverfolgt wird. Dafür kann das Änderungsprotokoll der Tabelle (DBTABLOG) oder ein eigenes Timestamp-Feld verwendet werden. Erfassung Ermitteln Sie den Timestamp, zu dem der Status in /SCWM/WHO auf „C“ (Abgeschlossen) gesetzt wird. Ereignistyp inferred | |||
| Warehouse Order angelegt | Diese Aktivität kennzeichnet die Anlage eines Warehouse Order (WO), eines Arbeitspakets aus mehreren Lageraufgaben. Das System erstellt einen WO, um Aufgaben für die Mitarbeitenden im Lager zu bündeln und zu organisieren, etwa nach Aktivitätsbereich, Queue oder Produkt. | ||
| Warum das wichtig ist Dies ist das primäre Start-Event für den Lagerausführungsprozess. Die Zeit von der Anlage bis zur ersten Aktion zeigt, ob es Verzögerungen bei der Aufgabenzuweisung oder der Ressourcenplanung gibt. Woher beziehen Dieses Ereignis wird anhand des Anlage-Timestamps (Feld CREATED_AT) in der Kopftabelle für Warehouse Orders, /SCWM/WHO, erfasst. Erfassung Ermitteln Sie für jede Warehouse-Order-Nummer (WHO) den Anlage-Timestamp aus der Tabelle /SCWM/WHO. Ereignistyp explicit | |||
| Warenausgang gebucht | Dies ist der letzte logistische und finanzielle Schritt im System, durch den die Waren formell aus dem Lagerbestand ausgebucht werden. Damit geht das rechtliche Eigentum über und die Sendung gilt offiziell als versandt. | ||
| Warum das wichtig ist Ein wichtiger Endpunkt des Auslieferungsprozesses, der die Abrechnung und Bestandsaktualisierung auslöst. Er ist eine zentrale Grundlage für die Messung termingerechter Sendungen und der KPI „Verlade- und Versanddauer“. Woher beziehen Lässt sich aus der Buchung eines mit dem Warehouse Order verknüpften Auslieferungsbelegs ableiten. Prüfen Sie den Belegfluss oder Statusfelder wie DGI_STAT in der Tabelle /SCDL/DB_PROCH_O. Erfassung Ermitteln Sie den Timestamp, zu dem der Warenausgangsstatus der zugehörigen Auslieferung auf „Abgeschlossen“ gesetzt wird. Ereignistyp explicit | |||
| Bereitstellungsaufgabe bestätigt | Eine Lagerkraft bestätigt, dass eine verpackte Handling Unit von einer Verpackungsstation oder einem Konsolidierungsbereich in einen vorgesehenen Bereitstellungsbereich für Sendungen bewegt wurde. Die Ware ist nun für die Verladung positioniert. | ||
| Warum das wichtig ist Damit geht der Prozess von der internen Bearbeitung in die Auslieferungslogistik über. Verzögerungen bei der Bereitstellung können zu unorganisierten Verladerampen und verpassten Abholzeiten des Frachtführers führen. Woher beziehen Wird anhand des Bestätigungs-Timestamps (Feld CONFIRMED_AT) einer Warehouse Task (/SCWM/WT) mit einem Prozesstyp für Bereitstellungsbewegungen erfasst. Erfassung Ermitteln Sie den Bestätigungs-Timestamp der Bereitstellungs-Warehouse-Task, die mit der Handling Unit oder Lieferung verknüpft ist. Ereignistyp explicit | |||
| Einlagerungsaufgabe angelegt | Das System erstellt eine konkrete Anweisung, eine Warehouse Task (WT), um die eingegangenen Waren vom Wareneingangsbereich zu einem endgültigen Lagerplatz zu bewegen. Diese Aktivität zeigt an, dass das System für die Einlagerung bereit ist. | ||
| Warum das wichtig ist Die Zeit zwischen Anlage und Bestätigung der Aufgabe zeigt, wie lange es dauert, bis Lagerkräfte die Einlagerungsanweisung übernehmen und ausführen. So werden mögliche Engpässe bei Personal oder Ausrüstung sichtbar. Woher beziehen Wird anhand des Anlage-Timestamps (Feld CREATED_AT) der betreffenden Warehouse Task in der Tabelle /SCWM/WT erfasst, deren Prozesstyp die Einlagerung kennzeichnet. Erfassung Filtern Sie die mit dem Warehouse Order verknüpften Warehouse Tasks nach dem Prozesstyp Einlagerung und verwenden Sie deren Anlage-Timestamp. Ereignistyp explicit | |||
| Kommissionieraufgabe angelegt | Das System erstellt eine Warehouse Task (WT), um Waren für einen Auslieferungsauftrag aus einem Lagerplatz zu entnehmen. Sie dient als Anweisung an eine Lagerkraft, ein Produkt zu entnehmen. | ||
| Warum das wichtig ist Damit beginnt der physische Auslieferungsprozess. Die Zeit zwischen Anlage und Bestätigung der Kommissionieraufgaben ist entscheidend für die Analyse der Kommissioniereffizienz und der verfügbaren Ressourcen. Woher beziehen Wird anhand des Anlage-Timestamps (Feld CREATED_AT) der betreffenden Warehouse Task in der Tabelle /SCWM/WT erfasst, deren Prozesstyp die Kommissionierung kennzeichnet. Erfassung Filtern Sie die mit dem Warehouse Order verknüpften Warehouse Tasks nach dem Prozesstyp Kommissionierung und verwenden Sie deren Anlage-Timestamp. Ereignistyp explicit | |||
| Verladung abgeschlossen | Zeigt an, dass alle Waren einer Sendung physisch auf die Transporteinheit verladen wurden. Dies ist Voraussetzung für die Warenausgangsbuchung und die Abfahrt des Fahrzeugs. | ||
| Warum das wichtig ist Ein wichtiger Meilenstein vor dem Versand. Verzögerungen zwischen dem Abschluss der Verladung und der Warenausgangsbuchung können auf Dokumentations- oder Systemprobleme hinweisen, die den Frachtführer aufhalten. Woher beziehen Lässt sich aus der Statusänderung der zugehörigen Transporteinheit (TU) oder des Auslieferungsauftrags auf „Verladung abgeschlossen“ ableiten. Relevant sind die Status in den Tabellen /SCWM/TU und /SCDL/DB_PROCH_O. Erfassung Erfassen Sie den Timestamp, zu dem der Status der TU oder des Auslieferungsauftrags aktualisiert wird, um den Abschluss der Verladung anzuzeigen. Ereignistyp inferred | |||
| Verladung begonnen | Diese Aktivität kennzeichnet den Beginn der physischen Verladung der Waren aus dem Bereitstellungsbereich auf einen Lkw oder eine Transporteinheit. Häufig wird sie durch eine Benutzeraktion im System ausgelöst. | ||
| Warum das wichtig ist Damit beginnt der letzte physische Schritt im Lager. Die Analyse der Verladedauer hilft, die Nutzung der Verladerampen und die Durchlaufzeit des Frachtführers zu optimieren. Woher beziehen Lässt sich aus der Statusänderung der zugehörigen Transporteinheit (TU) oder des Auslieferungsauftrags auf „Verladung begonnen“ ableiten. Die Tabelle /SCWM/TU_STATUS kann dafür geprüft werden. Erfassung Erfassen Sie den Timestamp, zu dem der Status der TU oder des Auslieferungsauftrags aktualisiert wird, um den Verladungsbeginn anzuzeigen. Ereignistyp inferred | |||
| Verpackung begonnen | Kennzeichnet den Beginn der Verpackung. Dabei werden kommissionierte Artikel zusammengeführt und in Versandbehälter oder Handling Units gelegt. Häufig ist dies der erste Schritt an einem Verpackungsarbeitsplatz. | ||
| Warum das wichtig ist Damit beginnt die Phase der Mehrwertleistungen. Wenn Sie die Verpackungsdauer messen, können Sie die Gestaltung, Besetzung und Materialversorgung des Arbeitsbereichs optimieren. Woher beziehen Dieses Ereignis muss möglicherweise abgeleitet werden. Als Grundlage kann der erste Scan eines Artikels oder einer Handling Unit an einer Verpackungsstation dienen, der häufig in Protokollen des Arbeitsbereichs oder der Handling Unit erfasst wird. Auch Tabellen wie /SCWM/PACKSPEC und zugehörige Ausführungsprotokolle können als Datenquelle dienen. Erfassung Verwenden Sie den Timestamp der ersten Bestätigung einer verpackungsbezogenen Warehouse Task für die Lieferung oder den Anlagezeitpunkt der endgültigen Versand-HU. Ereignistyp inferred | |||
| Warehouse Order storniert | Der Warehouse Order wird storniert, bevor alle Aufgaben abgeschlossen sind. Dadurch wird die weitere Ausführung verhindert. Gründe können fehlender Bestand, Änderungen an Kundenaufträgen oder andere Ausnahmen sein. | ||
| Warum das wichtig ist Dies steht für einen Fehler- oder Ausnahmeprozess. Die Analyse der Häufigkeit und Gründe von Stornierungen hilft, vorgelagerte Probleme in der Planung, Bestandsgenauigkeit oder Auftragsverwaltung zu erkennen. Woher beziehen Wird erfasst, indem die Änderung des Statusfelds (STAT) auf „Storniert“ in der Kopftabelle für Warehouse Orders, /SCWM/WHO, nachverfolgt wird. Erfassung Ermitteln Sie den Timestamp, zu dem der Status in /SCWM/WHO auf einen Stornierungsstatus gesetzt wird. Ereignistyp inferred | |||
| Wareneingang gebucht | Kennzeichnet die formelle Übernahme von Waren eines externen Lieferanten oder aus der Produktion in den Lagerbestand. Diese wichtige Buchung für Finanzen und Bestand macht die Waren sichtbar und für nachfolgende Prozesse wie die Einlagerung verfügbar. | ||
| Warum das wichtig ist Dies ist ein wichtiger Meilenstein im Wareneingangsprozess. Die Zeit zwischen der Ankunft der Waren und dieser Buchung kann auf Rückstände im Wareneingangsbereich hinweisen und die Verfügbarkeit des Bestands beeinträchtigen. Woher beziehen Lässt sich aus der Buchung eines mit dem Warehouse Order verknüpften Anlieferungsbelegs ableiten. Prüfen Sie den Belegfluss oder Statusfelder wie DGRSTAT in der Tabelle /SCDL/DB_PROCH_I. Erfassung Ermitteln Sie den Timestamp, zu dem der Wareneingangsstatus der zugehörigen Anlieferung auf „Abgeschlossen“ gesetzt wird. Ereignistyp inferred | |||
Anleitungen zur Datenextraktion
Schritte
- Voraussetzung: CDS-Views identifizieren oder erstellen: Die wichtigsten Datenquellen sind die standardmäßigen SAP-S/4HANA-CDS-Views für die Lagerverwaltung. Zu den zentralen Views gehören
I_WarehouseOrderfür Ereignisse auf Auftragsebene undI_WarehouseTaskfür Ereignisse auf Aufgabenebene. Für weitere Logistikereignisse werden außerdem Views wieI_OutboundDeliveryItem,I_InboundDeliveryItemundI_EWMTransportationUnitbenötigt. Stellen Sie sicher, dass diese Views in Ihrem System aktiv sind. - Benutzerdefinierten CDS-View erstellen: Um Daten aus mehreren Quellen in einem einheitlichen Event-Log-Format zusammenzuführen, müssen Sie einen benutzerdefinierten CDS-View erstellen. Verwenden Sie dazu die ABAP Development Tools (ADT) in Eclipse und legen Sie eine neue Data Definition an. Dieser View führt Datensätze aus verschiedenen Quellen mit
UNION ALLzusammen. Jeder Datensatz steht für eine eigene Geschäftsaktivität. - Struktur des Event Logs festlegen: Definieren Sie in Ihrem benutzerdefinierten CDS-View die Felder, die als Spalten im Event Log erscheinen sollen. Dazu gehören
WarehouseOrder,ActivityName,EventTimesowie weitere erforderliche und empfohlene Attribute. Ordnen Sie diese Felder den zugrunde liegenden Standard-CDS-Views zu. - Ereignisse für Lageraufträge modellieren: Fügen Sie die ersten
SELECT-Anweisungen in Ihre Union ein. Wählen Sie Daten ausI_WarehouseOrderaus, um anhand des Erstellungszeitstempels das Ereignis 'Warehouse Order Created' zu erzeugen. Ergänzen Sie weitereSELECT-Anweisungen für die Ereignisse 'Warehouse Order Completed' und 'Warehouse Order Canceled'. Filtern Sie dazu nach dem Auftragsstatus und verwenden Sie die passenden Bestätigungs- oder Änderungszeitstempel. - Ereignisse für Lageraufgaben modellieren: Fügen Sie
SELECT-Anweisungen fürI_WarehouseTaskhinzu. Erzeugen Sie die Ereignisse 'Putaway Task Created' und 'Putaway Task Confirmed', indem Sie nach Lagerprozesskategorien für die Einlagerung filtern. Erstellen Sie ebenso die Ereignisse 'Picking Task Created', 'Picking Task Confirmed' und 'Staging Task Confirmed' anhand der jeweiligen Prozesskategorien und der Erstellungs- und Bestätigungszeitstempel. - Warenbewegungsereignisse modellieren: Verknüpfen Sie lieferbezogene Views mit Lageraufgaben, um Warenbewegungen zu erfassen. Wählen Sie für 'Goods Receipt Posted' Daten aus
I_InboundDeliveryItemund verwenden Sie das FeldActualGoodsMovementDateTime. Für 'Goods Issue Posted' verwenden Sie dasselbe Feld ausI_OutboundDeliveryItemund verknüpfen die Daten mit dem zugehörigen Lagerauftrag oder der Lageraufgabe. - Lade- und Verpackungsereignisse modellieren: Wählen Sie Daten aus
I_EWMTransportationUnitaus, um die Ereignisse 'Loading Started' und 'Loading Completed' anhand der dafür vorgesehenen Zeitstempel zu erfassen. Die Verpackung kann komplex sein. Verwenden Sie daher einen Handling-Unit-View als Ersatz: Der Erstellungszeitpunkt kann 'Packing Started' und der Zeitpunkt einer Statusänderung 'Packing Completed' abbilden. Je nach Verpackungsprozess müssen Sie diesen Schritt möglicherweise anpassen. - CDS-View mit Annotationen bereitstellen: Ergänzen Sie die Definition Ihres benutzerdefinierten CDS-Views um die Annotation
@OData.publish: true. Dadurch generiert SAP automatisch einen OData-Service auf Grundlage der View-Struktur. - CDS-View und OData-Service aktivieren: Aktivieren Sie die neue Data Definition in ADT. Öffnen Sie anschließend auf dem SAP-Gateway-Hub-System die Transaktion
/IWFND/MAINT_SERVICE, suchen Sie den neu generierten OData-Service und aktivieren Sie ihn. Danach sind die Daten über einen REST-API-Endpunkt verfügbar. - Daten extrahieren: Verbinden Sie Ihre Zieldatenplattform oder Ihr ETL-Tool mit dem aktivierten OData-Service-Endpunkt. Verwenden Sie Filter direkt in der OData-URI, zum Beispiel einen Filter auf
EventTime, um den Datenumfang zu begrenzen (z. B.?$filter=EventTime ge datetime'2023-01-01T00:00:00'). - Daten für Process Mining formatieren: Speichern Sie die extrahierten Daten in einer flachen Datei, beispielsweise im CSV-Format. Die Spaltenüberschriften müssen den erforderlichen Attributen für ProcessMind entsprechen (
WarehouseOrder,ActivityName,EventTimeusw.). Laden Sie die fertige Datei in das Process-Mining-Tool hoch.
Konfiguration
- Benutzerdefinierter CDS-View: Zum Zusammenführen der Ereignisdaten muss ein eigener CDS-View erstellt werden, zum Beispiel
Z_C_EWM_EVENTLOG_CDS. Er ist das zentrale Objekt für die Extraktion. - OData-Service: Der aus dem benutzerdefinierten CDS-View generierte OData-Service muss aktiviert werden. Der Servicename entspricht in der Regel dem Namen des CDS-Views mit dem Suffix
_CDS. - Filter für den Zeitraum: Beim Aufruf der OData-API muss unbedingt ein Datumsfilter auf das Feld
EventTimeangewendet werden. Für eine erste Analyse eignet sich in der Regel ein Zeitraum von 3 bis 6 Monaten. Ohne Filter kann die Abfrage zu lange laufen oder die Systemleistung beeinträchtigen. - Filter für Entitäten: Um den Datenumfang weiter zu begrenzen, können Sie Attribute wie die Lagernummer (
Warehouse), den Lagerauftragstyp (WarehouseOrderType) oder bestimmte Materialien (MaterialNumber) filtern. - Systemberechtigungen: Die Person, die den CDS-View erstellt, benötigt Entwicklerzugriff auf SAP über ADT. Der Benutzer oder das Servicekonto, das die OData-API aufruft, benötigt Berechtigungen für den Zugriff auf die zugrunde liegenden Lagerverwaltungsdaten.
a Beispielabfrage sql
DEFINE VIEW Z_C_EWM_EVENTLOG_CDS
WITH PARAMETERS
P_StartDate : abap.dats,
P_EndDate : abap.dats
AS SELECT FROM I_WarehouseOrder AS WO
{
-- Required Attributes
WO.WarehouseOrder AS WarehouseOrder,
CAST('Warehouse Order Created' AS abap.char(40)) AS ActivityName,
WO.CreationDateTime AS EventTime,
CAST('S4HANA_EWM' AS abap.char(20)) AS SourceSystem,
tstmp_current_utctimestamp() AS LastDataUpdate,
-- Recommended Attributes
CAST(NULL AS abap.tstp) AS EventEndTime,
CAST(NULL AS abap.char(40)) AS MaterialNumber,
WO.CreationUser AS User,
WO.WarehouseOrderType AS WarehouseOrderType,
WO.WarehouseOrderStatus AS WarehouseOrderStatus,
WO.Priority AS Priority,
CAST(NULL AS abap.dec(15, 2)) AS ProcessingTime
}
WHERE
CAST(WO.CreationDateTime AS abap.dats) BETWEEN :P_StartDate AND :P_EndDate
UNION ALL
SELECT FROM I_WarehouseOrder AS WO
{
WO.WarehouseOrder,
CAST('Warehouse Order Completed' AS abap.char(40)) AS ActivityName,
WO.ConfirmationDateTime AS EventTime,
CAST('S4HANA_EWM' AS abap.char(20)) AS SourceSystem,
tstmp_current_utctimestamp() AS LastDataUpdate,
CAST(NULL AS abap.tstp) AS EventEndTime,
CAST(NULL AS abap.char(40)) AS MaterialNumber,
WO.ConfirmationUser AS User,
WO.WarehouseOrderType,
WO.WarehouseOrderStatus,
WO.Priority,
CAST(NULL AS abap.dec(15, 2)) AS ProcessingTime
}
WHERE
WO.WarehouseOrderStatus = 'C' AND
CAST(WO.ConfirmationDateTime AS abap.dats) BETWEEN :P_StartDate AND :P_EndDate
UNION ALL
SELECT FROM I_WarehouseOrder AS WO
{
WO.WarehouseOrder,
CAST('Warehouse Order Canceled' AS abap.char(40)) AS ActivityName,
WO.LastChangeDateTime AS EventTime,
CAST('S4HANA_EWM' AS abap.char(20)) AS SourceSystem,
tstmp_current_utctimestamp() AS LastDataUpdate,
CAST(NULL AS abap.tstp) AS EventEndTime,
CAST(NULL AS abap.char(40)) AS MaterialNumber,
WO.LastChangeUser AS User,
WO.WarehouseOrderType,
WO.WarehouseOrderStatus,
WO.Priority,
CAST(NULL AS abap.dec(15, 2)) AS ProcessingTime
}
WHERE
WO.WarehouseOrderStatus = 'X' AND
CAST(WO.LastChangeDateTime AS abap.dats) BETWEEN :P_StartDate AND :P_EndDate
UNION ALL
SELECT FROM I_WarehouseTask AS WT
LEFT JOIN I_InboundDeliveryItem AS IBD ON WT.DeliveryDocument = IBD.InboundDelivery AND WT.DeliveryDocumentItem = IBD.InboundDeliveryItem
{
WT.WarehouseOrder,
CAST('Goods Receipt Posted' AS abap.char(40)) AS ActivityName,
IBD.ActualGoodsMovementDateTime AS EventTime,
CAST('S4HANA_EWM' AS abap.char(20)) AS SourceSystem,
tstmp_current_utctimestamp() AS LastDataUpdate,
CAST(NULL AS abap.tstp) AS EventEndTime,
WT.Product AS MaterialNumber,
IBD.LastChangedByUser AS User,
WT.WarehouseOrderType,
CAST(NULL AS abap.char(1)) AS WarehouseOrderStatus,
CAST(NULL AS abap.numc(2)) AS Priority,
CAST(NULL AS abap.dec(15, 2)) AS ProcessingTime
}
WHERE
WT.WhseTskProcessCat = '1' AND -- Putaway
IBD.GoodsMovementStatus = 'C' AND -- Completed
CAST(IBD.ActualGoodsMovementDateTime AS abap.dats) BETWEEN :P_StartDate AND :P_EndDate
UNION ALL
SELECT FROM I_WarehouseTask AS WT
{
WT.WarehouseOrder,
CAST('Putaway Task Created' AS abap.char(40)) AS ActivityName,
WT.CreationDateTime AS EventTime,
CAST('S4HANA_EWM' AS abap.char(20)) AS SourceSystem,
tstmp_current_utctimestamp() AS LastDataUpdate,
WT.ConfirmationDateTime AS EventEndTime,
WT.Product AS MaterialNumber,
WT.CreationUser AS User,
WT.WarehouseOrderType,
CAST(NULL AS abap.char(1)) AS WarehouseOrderStatus,
CAST(NULL AS abap.numc(2)) AS Priority,
CAST(NULL AS abap.dec(15, 2)) AS ProcessingTime
}
WHERE
WT.WhseTskProcessCat = '1' AND -- Putaway
CAST(WT.CreationDateTime AS abap.dats) BETWEEN :P_StartDate AND :P_EndDate
UNION ALL
SELECT FROM I_WarehouseTask AS WT
{
WT.WarehouseOrder,
CAST('Putaway Task Confirmed' AS abap.char(40)) AS ActivityName,
WT.ConfirmationDateTime AS EventTime,
CAST('S4HANA_EWM' AS abap.char(20)) AS SourceSystem,
tstmp_current_utctimestamp() AS LastDataUpdate,
CAST(NULL AS abap.tstp) AS EventEndTime,
WT.Product AS MaterialNumber,
WT.ConfirmationUser AS User,
WT.WarehouseOrderType,
CAST(NULL AS abap.char(1)) AS WarehouseOrderStatus,
CAST(NULL AS abap.numc(2)) AS Priority,
WT.ProcessorProcTimeInSec AS ProcessingTime
}
WHERE
WT.WhseTskProcessCat = '1' AND -- Putaway
WT.WarehouseTaskStatus = 'C' AND
CAST(WT.ConfirmationDateTime AS abap.dats) BETWEEN :P_StartDate AND :P_EndDate
UNION ALL
SELECT FROM I_WarehouseTask AS WT
{
WT.WarehouseOrder,
CAST('Picking Task Created' AS abap.char(40)) AS ActivityName,
WT.CreationDateTime AS EventTime,
CAST('S4HANA_EWM' AS abap.char(20)) AS SourceSystem,
tstmp_current_utctimestamp() AS LastDataUpdate,
WT.ConfirmationDateTime AS EventEndTime,
WT.Product AS MaterialNumber,
WT.CreationUser AS User,
WT.WarehouseOrderType,
CAST(NULL AS abap.char(1)) AS WarehouseOrderStatus,
CAST(NULL AS abap.numc(2)) AS Priority,
CAST(NULL AS abap.dec(15, 2)) AS ProcessingTime
}
WHERE
WT.WhseTskProcessCat = '2' AND -- Stock Removal
CAST(WT.CreationDateTime AS abap.dats) BETWEEN :P_StartDate AND :P_EndDate
UNION ALL
SELECT FROM I_WarehouseTask AS WT
{
WT.WarehouseOrder,
CAST('Picking Task Confirmed' AS abap.char(40)) AS ActivityName,
WT.ConfirmationDateTime AS EventTime,
CAST('S4HANA_EWM' AS abap.char(20)) AS SourceSystem,
tstmp_current_utctimestamp() AS LastDataUpdate,
CAST(NULL AS abap.tstp) AS EventEndTime,
WT.Product AS MaterialNumber,
WT.ConfirmationUser AS User,
WT.WarehouseOrderType,
CAST(NULL AS abap.char(1)) AS WarehouseOrderStatus,
CAST(NULL AS abap.numc(2)) AS Priority,
WT.ProcessorProcTimeInSec AS ProcessingTime
}
WHERE
WT.WhseTskProcessCat = '2' AND -- Stock Removal
WT.WarehouseTaskStatus = 'C' AND
CAST(WT.ConfirmationDateTime AS abap.dats) BETWEEN :P_StartDate AND :P_EndDate
UNION ALL
SELECT FROM I_WarehouseTask AS WT
{
WT.WarehouseOrder,
CAST('Packing Started' AS abap.char(40)) AS ActivityName,
WT.CreationDateTime AS EventTime,
CAST('S4HANA_EWM' AS abap.char(20)) AS SourceSystem,
tstmp_current_utctimestamp() AS LastDataUpdate,
WT.ConfirmationDateTime AS EventEndTime,
WT.Product AS MaterialNumber,
WT.CreationUser AS User,
WT.WarehouseOrderType,
CAST(NULL AS abap.char(1)) AS WarehouseOrderStatus,
CAST(NULL AS abap.numc(2)) AS Priority,
CAST(NULL AS abap.dec(15, 2)) AS ProcessingTime
}
WHERE
WT.WhseTskProcessCat = '5' AND -- Packing
CAST(WT.CreationDateTime AS abap.dats) BETWEEN :P_StartDate AND :P_EndDate
UNION ALL
SELECT FROM I_WarehouseTask AS WT
{
WT.WarehouseOrder,
CAST('Packing Completed' AS abap.char(40)) AS ActivityName,
WT.ConfirmationDateTime AS EventTime,
CAST('S4HANA_EWM' AS abap.char(20)) AS SourceSystem,
tstmp_current_utctimestamp() AS LastDataUpdate,
CAST(NULL AS abap.tstp) AS EventEndTime,
WT.Product AS MaterialNumber,
WT.ConfirmationUser AS User,
WT.WarehouseOrderType,
CAST(NULL AS abap.char(1)) AS WarehouseOrderStatus,
CAST(NULL AS abap.numc(2)) AS Priority,
WT.ProcessorProcTimeInSec AS ProcessingTime
}
WHERE
WT.WhseTskProcessCat = '5' AND -- Packing
WT.WarehouseTaskStatus = 'C' AND
CAST(WT.ConfirmationDateTime AS abap.dats) BETWEEN :P_StartDate AND :P_EndDate
UNION ALL
SELECT FROM I_WarehouseTask AS WT
{
WT.WarehouseOrder,
CAST('Staging Task Confirmed' AS abap.char(40)) AS ActivityName,
WT.ConfirmationDateTime AS EventTime,
CAST('S4HANA_EWM' AS abap.char(20)) AS SourceSystem,
tstmp_current_utctimestamp() AS LastDataUpdate,
CAST(NULL AS abap.tstp) AS EventEndTime,
WT.Product AS MaterialNumber,
WT.ConfirmationUser AS User,
WT.WarehouseOrderType,
CAST(NULL AS abap.char(1)) AS WarehouseOrderStatus,
CAST(NULL AS abap.numc(2)) AS Priority,
WT.ProcessorProcTimeInSec AS ProcessingTime
}
WHERE
WT.WhseTskProcessCat = '4' AND -- Staging
WT.WarehouseTaskStatus = 'C' AND
CAST(WT.ConfirmationDateTime AS abap.dats) BETWEEN :P_StartDate AND :P_EndDate
UNION ALL
SELECT FROM I_EWMTransportationUnit AS TU
INNER JOIN I_WarehouseTask AS WT ON TU.TransportationUnit = WT.ShipmentOrTransportationUnit
{
WT.WarehouseOrder,
CAST('Loading Started' AS abap.char(40)) AS ActivityName,
TU.LoadingStartDateTime AS EventTime,
CAST('S4HANA_EWM' AS abap.char(20)) AS SourceSystem,
tstmp_current_utctimestamp() AS LastDataUpdate,
TU.LoadingEndDateTime AS EventEndTime,
WT.Product AS MaterialNumber,
TU.LastChangeUser AS User,
WT.WarehouseOrderType,
CAST(NULL AS abap.char(1)) AS WarehouseOrderStatus,
CAST(NULL AS abap.numc(2)) AS Priority,
CAST(NULL AS abap.dec(15, 2)) AS ProcessingTime
}
WHERE
TU.LoadingStartDateTime IS NOT NULL AND
CAST(TU.LoadingStartDateTime AS abap.dats) BETWEEN :P_StartDate AND :P_EndDate
UNION ALL
SELECT FROM I_EWMTransportationUnit AS TU
INNER JOIN I_WarehouseTask AS WT ON TU.TransportationUnit = WT.ShipmentOrTransportationUnit
{
WT.WarehouseOrder,
CAST('Loading Completed' AS abap.char(40)) AS ActivityName,
TU.LoadingEndDateTime AS EventTime,
CAST('S4HANA_EWM' AS abap.char(20)) AS SourceSystem,
tstmp_current_utctimestamp() AS LastDataUpdate,
CAST(NULL AS abap.tstp) AS EventEndTime,
WT.Product AS MaterialNumber,
TU.LastChangeUser AS User,
WT.WarehouseOrderType,
CAST(NULL AS abap.char(1)) AS WarehouseOrderStatus,
CAST(NULL AS abap.numc(2)) AS Priority,
CAST(NULL AS abap.dec(15, 2)) AS ProcessingTime
}
WHERE
TU.LoadingEndDateTime IS NOT NULL AND
TU.LoadingStatus = 'C' AND
CAST(TU.LoadingEndDateTime AS abap.dats) BETWEEN :P_StartDate AND :P_EndDate
UNION ALL
SELECT FROM I_WarehouseTask AS WT
LEFT JOIN I_OutboundDeliveryItem AS OBD ON WT.DeliveryDocument = OBD.OutboundDelivery AND WT.DeliveryDocumentItem = OBD.OutboundDeliveryItem
{
WT.WarehouseOrder,
CAST('Goods Issue Posted' AS abap.char(40)) AS ActivityName,
OBD.ActualGoodsMovementDateTime AS EventTime,
CAST('S4HANA_EWM' AS abap.char(20)) AS SourceSystem,
tstmp_current_utctimestamp() AS LastDataUpdate,
CAST(NULL AS abap.tstp) AS EventEndTime,
WT.Product AS MaterialNumber,
OBD.LastChangedByUser AS User,
WT.WarehouseOrderType,
CAST(NULL AS abap.char(1)) AS WarehouseOrderStatus,
CAST(NULL AS abap.numc(2)) AS Priority,
CAST(NULL AS abap.dec(15, 2)) AS ProcessingTime
}
WHERE
WT.WhseTskProcessCat = '2' AND -- Stock Removal
OBD.GoodsMovementStatus = 'C' AND -- Completed
CAST(OBD.ActualGoodsMovementDateTime AS abap.dats) BETWEEN :P_StartDate AND :P_EndDateSchritte
- Klären Sie, ob der direkte Lesezugriff auf das SAP-EWM-Datenbankschema genehmigt ist. Ermitteln Sie anschließend die physischen Datenbankobjekte für Lagerauftragsköpfe, Lageraufgaben, den Statusverlauf von Lageraufträgen, Wareneingangs- und Warenausgangsbuchungen, Verpackung, Bereitstellung und Verladung. Die logischen Referenzen /SCWM/WHO und /SCWM/WT sind häufig ein guter Ausgangspunkt. Prüfen Sie jedoch die tatsächlichen Objekte, Felder, Statuscodes, die Bedeutung der Zeitstempel und das Datenbankschema in Ihrem System.
- Lassen Sie sich von der technischen SAP-EWM-Verantwortung oder dem Data Dictionary die verifizierte Feldzuordnung geben. Ordnen Sie Lagerauftrags-ID, Lagerauftragstyp, Status, Priorität, Lageraufgaben-ID, Aufgabenkategorie oder Prozesstyp, Material, Benutzer, Erstellungszeitstempel, Bestätigungszeitstempel, Verpackungszeitstempel, Bereitstellungszeitstempel, Verladezeitstempel, Wareneingangszeitstempel, Warenausgangszeitstempel, Quellsystem und Zeitstempel der letzten Aktualisierung zu. Gehen Sie nicht davon aus, dass ein Feld in derselben Tabelle vorhanden ist oder ein Statuscode in allen Installationen dieselbe Bedeutung hat.
- Richten Sie die Extraktionsverbindung mit einem schreibgeschützten Datenbankkonto, dem Produktions- oder Berichtsschema und parametrisierten Werten für Start- und Enddatum der Extraktion, Quellsystemnamen sowie unternehmensspezifische Filter ein. Wenden Sie den Datumsfilter auf den jeweiligen Ereigniszeitstempel an, nicht nur auf den Erstellungszeitstempel des Lagerauftrags. So werden auch spätere Ereignisse im Auftragslebenszyklus berücksichtigt.
- Erstellen Sie die Ereigniszeilen, indem Sie für jede ausdrücklich erforderliche Aktivität eine Zeile auswählen. Die Abfrage muss für jede Aktivität die verifizierten Quellfelder verwenden. ProcessMind soll Ereignisse nicht selbst ableiten müssen. Wenn eine Aktivität im Statusverlauf oder Anwendungsprotokoll statt in einem aktuellen Kopffeld erfasst wird, verwenden Sie diesen Verlauf oder das Protokoll und übernehmen Sie den Ereigniszeitstempel sowie den ausführenden Benutzer.
- Vereinheitlichen Sie alle Aktivitätszeitstempel auf eine Zeitzone, vorzugsweise UTC, oder dokumentieren Sie die Zeitzone des SAP-Applikationsservers. Überführen Sie quellenspezifische Status- und Prozesscodes in die exakten Aktivitätsnamen des Event Logs: Warehouse Order Created, Goods Receipt Posted, Putaway Task Created, Putaway Task Confirmed, Picking Task Created, Picking Task Confirmed, Packing Started, Packing Completed, Staging Task Confirmed, Loading Started, Loading Completed, Goods Issue Posted, Warehouse Order Completed und Warehouse Order Canceled.
- Stellen Sie sicher, dass jede Ausgabezeile
WarehouseOrder,ActivityName,EventTime,SourceSystemundLastDataUpdateenthält. Füllen SieEventEndTimeaus, wenn ein verlässlicher Abschlusszeitstempel vorhanden ist. Ordnen Sie Ereignisse auf Aufgabenebene dem zugehörigen Lagerauftrag zu. Enthält ein Lagerauftrag mehrere relevante Aufgaben, behalten Sie für jedes Aufgabenereignis eine eigene Zeile bei und verwenden Sie weiterhin den Lagerauftrag als Case-ID. Verwenden Sie einen stabilen Tie-Breaker, etwa die Aufgaben-ID oder Ereignis-ID aus der Quelle, sofern das Zielformat dies unterstützt. - Prüfen Sie das Ergebnis vor dem Export. Kontrollieren Sie, ob alle 14 Aktivitätsnamen vorkommen, sofern die entsprechenden Geschäftsereignisse in den Quelldaten vorhanden sind, ob die Zeitstempel im angeforderten Zeitraum liegen, ob Lageraufträge unerwartet leer sind und ob sich doppelte Zeilen durch mehrere Aufgaben oder wiederholte Statusänderungen erklären lassen. Gleichen Sie die Anzahl mit SAP-Betriebsberichten oder einem unabhängig genehmigten Datenexport ab.
- Exportieren Sie das Ergebnis als ProcessMind-kompatible Datei mit Trennzeichen oder als Datenbankabfrageergebnis mit einem Ereignis pro Zeile. Verwenden Sie die exakten erforderlichen Spaltennamen, ein eindeutiges Zeitstempelformat wie ISO 8601, Textwerte in Anführungszeichen, wenn das Trennzeichenformat dies erfordert, und eine Kopfzeile. Laden Sie die Datei in ProcessMind hoch oder richten Sie die Datenbankverbindung ein. Legen Sie
WarehouseOrderals Case-ID,ActivityNameals Aktivität undEventTimeals Startzeitstempel fest. Verwenden SieEventEndTimeals Endzeitstempel, sofern verfügbar.
Konfiguration
- Zuordnung der Quellobjekte: Prüfen Sie die physischen Datenbankobjekte und Felder für Lageraufträge, Lageraufgaben, Statusverlauf, Warenbewegungen, Verpackung, Bereitstellung und Verladung. /SCWM/WHO und /SCWM/WT können als logische Objekte relevant sein. Die konkrete Darstellung in der installierten Datenbank muss jedoch vor der Implementierung bestätigt werden.
- Zeitraum: Beginnen Sie mit einem begrenzten Zeitraum von drei bis sechs Monaten. Verwenden Sie für erste Tests einen kürzeren Zeitraum und erweitern Sie ihn nach dem Abgleich. Lassen Sie zwischen inkrementellen Läufen einen kleinen Überlappungszeitraum, damit verspätete Buchungen und Korrekturen erfasst werden.
- Auswahl der Ereigniszeitstempel: Verwenden Sie für erstellte Aktivitäten die Erstellungszeitstempel, für bestätigte Aktivitäten die Bestätigungszeitstempel, für Wareneingangs- und Warenausgangsbuchungen die Buchungszeitstempel sowie verifizierte Ausführungszeitstempel für Verpackung, Bereitstellung und Verladung. Verwenden Sie nicht für alle Ereignisse den Erstellungszeitpunkt des Lagerauftrags.
- Filter: Verwenden Sie ausschließlich verifizierte Geschäftsfilter, etwa Lagernummer, Buchungskreis, Belegart, Lagerauftragstyp, Aktivitätsbereich, Queue, Werk oder Quellsystem. Felder für Buchungskreis und Belegart können sich in verknüpften Objekten befinden und müssen im Zielsystem zugeordnet werden.
- Statuszuordnung: Legen Sie die genauen SAP-Status- oder Prozesscodes für abgeschlossene und stornierte Lageraufträge fest. Lassen Sie die Zuordnung von der fachlichen EWM-Verantwortung prüfen, da Statuscodes und ihre Speicherung je nach Release und Implementierung variieren können.
- SourceSystem: Verwenden Sie einen stabilen Wert, der die EWM-Produktiv- oder Berichtsinstanz kennzeichnet. Leiten Sie ihn nicht aus einem möglicherweise leeren Geschäftsfeld ab.
- LastDataUpdate: Tragen Sie für jede Zeile eines Laufs einheitlich den Extraktionszeitpunkt oder den Zeitpunkt der Aktualisierung der Quelldaten ein.
- Inkrementelle Extraktion: Verwenden Sie einen gespeicherten High-Water-Mark auf Grundlage des zuletzt erfolgreich extrahierten Quellzeitstempels und berücksichtigen Sie verspätet eintreffende Datensätze durch ein Überlappungsfenster. Entfernen Sie Duplikate anhand verifizierter Quellkennungen, sofern vorhanden.
- Leistung: Begrenzen Sie den Zeitraum frühzeitig, wählen Sie nur erforderliche Spalten aus und filtern Sie indizierte Felder. Vermeiden Sie Funktionen auf indizierten Zeitstempelspalten in Prädikaten und verarbeiten Sie große Zeiträume in Tages- oder Wochenpaketen. Verwenden Sie, sofern zulässig, eine Berichtskopie der Datenbank.
- Verknüpfungsstrategie: Prüfen Sie die Kardinalität zwischen Lageraufträgen und Lageraufgaben. Vermeiden Sie eine unbeabsichtigte Vervielfachung beim Verknüpfen von Aufgaben, Status, Material und Handling Units. Aggregieren Sie die Daten oder wählen Sie den passenden Ereignisdatensatz vor der Verknüpfung aus.
- Zeitzonen: Legen Sie die Quellzeitzone und die Umrechnungsregel fest. Speichern Sie Zeitstempel einheitlich und dokumentieren Sie den Umgang mit der Sommerzeit.
- Voraussetzungen: Schreibgeschützte Datenbankberechtigung, genehmigter Zugriff auf das EWM-Schema, verifizierte Zuordnungen aus dem Data Dictionary, Leseberechtigung für relevante Betriebs- und Verlaufsobjekte sowie eine genehmigte ProcessMind-Importkonfiguration. Die erforderlichen SAP-Module, Lizenzen und Berechtigungen hängen von der installierten EWM-Architektur ab und müssen von der Systemverantwortung bestätigt werden.
a Beispielabfrage sql
WITH
params AS (
SELECT
CAST('[Start date and time]' AS TIMESTAMP) AS start_time,
CAST('[End date and time]' AS TIMESTAMP) AS end_time,
CAST('[Source system name]' AS VARCHAR(255)) AS source_system,
CAST(CURRENT_TIMESTAMP AS TIMESTAMP) AS last_data_update
),
warehouse_orders AS (
SELECT
CAST(wo.[Warehouse order ID field] AS VARCHAR(255)) AS WarehouseOrder,
CAST(wo.[Warehouse order type field] AS VARCHAR(255)) AS WarehouseOrderType,
CAST(wo.[Warehouse order status field] AS VARCHAR(255)) AS WarehouseOrderStatus,
CAST(wo.[Priority field] AS VARCHAR(255)) AS Priority,
CAST(wo.[Warehouse order creation timestamp field] AS TIMESTAMP) AS WarehouseOrderCreatedTime,
CAST(wo.[Warehouse order completion timestamp field] AS TIMESTAMP) AS WarehouseOrderCompletedTime,
CAST(wo.[Warehouse order cancellation timestamp field] AS TIMESTAMP) AS WarehouseOrderCanceledTime,
CAST(wo.[Material number field] AS VARCHAR(255)) AS MaterialNumber,
CAST(wo.[User field] AS VARCHAR(255)) AS [User]
FROM [Your warehouse order header table] wo
),
warehouse_tasks AS (
SELECT
CAST(wt.[Warehouse order ID field] AS VARCHAR(255)) AS WarehouseOrder,
CAST(wt.[Warehouse task ID field] AS VARCHAR(255)) AS WarehouseTask,
CAST(wt.[Task category or process type field] AS VARCHAR(255)) AS TaskType,
CAST(wt.[Material number field] AS VARCHAR(255)) AS MaterialNumber,
CAST(wt.[Task creation timestamp field] AS TIMESTAMP) AS TaskCreatedTime,
CAST(wt.[Task confirmation timestamp field] AS TIMESTAMP) AS TaskConfirmedTime,
CAST(wt.[User field] AS VARCHAR(255)) AS [User]
FROM [Your warehouse task table] wt
),
events AS (
SELECT wo.WarehouseOrder, 'Warehouse Order Created' AS ActivityName, wo.WarehouseOrderCreatedTime AS EventTime, CAST(NULL AS TIMESTAMP) AS EventEndTime, wo.MaterialNumber, wo.[User], wo.WarehouseOrderType, wo.WarehouseOrderStatus, wo.Priority FROM warehouse_orders wo
UNION ALL
SELECT gr.[Warehouse order ID field], 'Goods Receipt Posted', CAST(gr.[Goods receipt posting timestamp field] AS TIMESTAMP), CAST(NULL AS TIMESTAMP), CAST(gr.[Material number field] AS VARCHAR(255)), CAST(gr.[User field] AS VARCHAR(255)), wo.WarehouseOrderType, wo.WarehouseOrderStatus, wo.Priority FROM [Your goods receipt posting table] gr LEFT JOIN warehouse_orders wo ON wo.WarehouseOrder = CAST(gr.[Warehouse order ID field] AS VARCHAR(255))
UNION ALL
SELECT wt.WarehouseOrder, 'Putaway Task Created', wt.TaskCreatedTime, CAST(NULL AS TIMESTAMP), wt.MaterialNumber, wt.[User], wo.WarehouseOrderType, wo.WarehouseOrderStatus, wo.Priority FROM warehouse_tasks wt LEFT JOIN warehouse_orders wo ON wo.WarehouseOrder = wt.WarehouseOrder WHERE wt.TaskType = '[Verified putaway task type]'
UNION ALL
SELECT wt.WarehouseOrder, 'Putaway Task Confirmed', wt.TaskConfirmedTime, CAST(NULL AS TIMESTAMP), wt.MaterialNumber, wt.[User], wo.WarehouseOrderType, wo.WarehouseOrderStatus, wo.Priority FROM warehouse_tasks wt LEFT JOIN warehouse_orders wo ON wo.WarehouseOrder = wt.WarehouseOrder WHERE wt.TaskType = '[Verified putaway task type]' AND wt.TaskConfirmedTime IS NOT NULL
UNION ALL
SELECT wt.WarehouseOrder, 'Picking Task Created', wt.TaskCreatedTime, CAST(NULL AS TIMESTAMP), wt.MaterialNumber, wt.[User], wo.WarehouseOrderType, wo.WarehouseOrderStatus, wo.Priority FROM warehouse_tasks wt LEFT JOIN warehouse_orders wo ON wo.WarehouseOrder = wt.WarehouseOrder WHERE wt.TaskType = '[Verified picking task type]'
UNION ALL
SELECT wt.WarehouseOrder, 'Picking Task Confirmed', wt.TaskConfirmedTime, CAST(NULL AS TIMESTAMP), wt.MaterialNumber, wt.[User], wo.WarehouseOrderType, wo.WarehouseOrderStatus, wo.Priority FROM warehouse_tasks wt LEFT JOIN warehouse_orders wo ON wo.WarehouseOrder = wt.WarehouseOrder WHERE wt.TaskType = '[Verified picking task type]' AND wt.TaskConfirmedTime IS NOT NULL
UNION ALL
SELECT pk.[Warehouse order ID field], 'Packing Started', CAST(pk.[Packing start timestamp field] AS TIMESTAMP), CAST(NULL AS TIMESTAMP), CAST(pk.[Material number field] AS VARCHAR(255)), CAST(pk.[User field] AS VARCHAR(255)), wo.WarehouseOrderType, wo.WarehouseOrderStatus, wo.Priority FROM [Your packing event table] pk LEFT JOIN warehouse_orders wo ON wo.WarehouseOrder = CAST(pk.[Warehouse order ID field] AS VARCHAR(255))
UNION ALL
SELECT pk.[Warehouse order ID field], 'Packing Completed', CAST(pk.[Packing completion timestamp field] AS TIMESTAMP), CAST(NULL AS TIMESTAMP), CAST(pk.[Material number field] AS VARCHAR(255)), CAST(pk.[User field] AS VARCHAR(255)), wo.WarehouseOrderType, wo.WarehouseOrderStatus, wo.Priority FROM [Your packing event table] pk LEFT JOIN warehouse_orders wo ON wo.WarehouseOrder = CAST(pk.[Warehouse order ID field] AS VARCHAR(255))
UNION ALL
SELECT st.[Warehouse order ID field], 'Staging Task Confirmed', CAST(st.[Staging confirmation timestamp field] AS TIMESTAMP), CAST(NULL AS TIMESTAMP), CAST(st.[Material number field] AS VARCHAR(255)), CAST(st.[User field] AS VARCHAR(255)), wo.WarehouseOrderType, wo.WarehouseOrderStatus, wo.Priority FROM [Your staging event table] st LEFT JOIN warehouse_orders wo ON wo.WarehouseOrder = CAST(st.[Warehouse order ID field] AS VARCHAR(255))
UNION ALL
SELECT ld.[Warehouse order ID field], 'Loading Started', CAST(ld.[Loading start timestamp field] AS TIMESTAMP), CAST(NULL AS TIMESTAMP), CAST(ld.[Material number field] AS VARCHAR(255)), CAST(ld.[User field] AS VARCHAR(255)), wo.WarehouseOrderType, wo.WarehouseOrderStatus, wo.Priority FROM [Your loading event table] ld LEFT JOIN warehouse_orders wo ON wo.WarehouseOrder = CAST(ld.[Warehouse order ID field] AS VARCHAR(255))
UNION ALL
SELECT ld.[Warehouse order ID field], 'Loading Completed', CAST(ld.[Loading completion timestamp field] AS TIMESTAMP), CAST(NULL AS TIMESTAMP), CAST(ld.[Material number field] AS VARCHAR(255)), CAST(ld.[User field] AS VARCHAR(255)), wo.WarehouseOrderType, wo.WarehouseOrderStatus, wo.Priority FROM [Your loading event table] ld LEFT JOIN warehouse_orders wo ON wo.WarehouseOrder = CAST(ld.[Warehouse order ID field] AS VARCHAR(255))
UNION ALL
SELECT gi.[Warehouse order ID field], 'Goods Issue Posted', CAST(gi.[Goods issue posting timestamp field] AS TIMESTAMP), CAST(NULL AS TIMESTAMP), CAST(gi.[Material number field] AS VARCHAR(255)), CAST(gi.[User field] AS VARCHAR(255)), wo.WarehouseOrderType, wo.WarehouseOrderStatus, wo.Priority FROM [Your goods issue posting table] gi LEFT JOIN warehouse_orders wo ON wo.WarehouseOrder = CAST(gi.[Warehouse order ID field] AS VARCHAR(255))
UNION ALL
SELECT wo.WarehouseOrder, 'Warehouse Order Completed', wo.WarehouseOrderCompletedTime, CAST(NULL AS TIMESTAMP), wo.MaterialNumber, wo.[User], wo.WarehouseOrderType, wo.WarehouseOrderStatus, wo.Priority FROM warehouse_orders wo WHERE wo.WarehouseOrderCompletedTime IS NOT NULL
UNION ALL
SELECT wo.WarehouseOrder, 'Warehouse Order Canceled', wo.WarehouseOrderCanceledTime, CAST(NULL AS TIMESTAMP), wo.MaterialNumber, wo.[User], wo.WarehouseOrderType, wo.WarehouseOrderStatus, wo.Priority FROM warehouse_orders wo WHERE wo.WarehouseOrderCanceledTime IS NOT NULL
)
SELECT
e.WarehouseOrder,
e.ActivityName,
e.EventTime,
e.EventEndTime,
p.source_system AS SourceSystem,
p.last_data_update AS LastDataUpdate,
e.MaterialNumber,
e.[User],
e.WarehouseOrderType,
e.WarehouseOrderStatus,
e.Priority
FROM events e
CROSS JOIN params p
WHERE e.WarehouseOrder IS NOT NULL
AND e.EventTime IS NOT NULL
AND e.EventTime >= p.start_time
AND e.EventTime < p.end_time
ORDER BY e.WarehouseOrder, e.EventTime, e.ActivityName;Möchten Sie beginnen?
Starten Sie noch heute mit der Optimierung Ihres Lagerbetriebs. Verwenden Sie dieses Template, um die Effizienz zu steigern und Aufträge schneller zu erfüllen.
Kommissionierfehler vermeiden und Lagerverwaltung jetzt optimieren
Erreichen Sie eine Bestandsgenauigkeit von 99,5 % und vermeiden Sie Verzögerungen bei der Auftragsabwicklung innerhalb weniger Wochen.
Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.