Ihr Warehouse Management Daten-Template
Ihr Warehouse Management Daten-Template
- Empfohlene Attribute für eine umfassende Analyse
- Wichtige Aktivitäten zur Verfolgung in Ihrem Materialfluss
- Praktische Anleitung zur Datenextraktion aus Blue Yonder WMS
Warehouse Management Attribute
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Der Name der spezifischen Lageraufgabe oder des eingetretenen Events, z.B. 'Waren kommissioniert' oder 'Versand abgefertigt'. | ||
| Beschreibung Dieses Attribut beschreibt den spezifischen Schritt oder die Aufgabe, die innerhalb des Warehouse Management Prozesses ausgeführt wurde. Jedes Event im Prozess-Log ist mit einem Aktivitätsnamen verbunden und bildet die Abfolge der Schritte, die den Prozessfluss ausmachen. In der Analyse ist der Aktivitätsname fundamental für die Entdeckung der Prozesskarte, die Analyse von Übergängen zwischen Schritten und die Identifizierung von Engpässen oder Abweichungen vom Standardverfahren. Er wird in praktisch allen Process Mining Analysen verwendet, von der Konformitätsprüfung bis zur Leistungsüberwachung. Bedeutung Dieses Attribut ist entscheidend für den Aufbau der Prozesskarte, da es die einzelnen Schritte definiert und die Visualisierung sowie Analyse des Prozessflusses ermöglicht. Datenquelle Diese Informationen finden sich typischerweise in den Lagertask- oder Event Log Tabellen, oft abgeleitet von einem Aufgabentyp oder Statuscode. Beispiele Kommissionieraufgabe erstelltWaren aus Lager entnommenSendung versandt | |||
| Event Startzeit EventStartTime | Der Timestamp, der angibt, wann eine spezifische Lageraktivität oder ein Event begann. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit, zu der eine Lageraufgabe oder ein Event initiiert wurde. Es bietet den chronologischen Kontext für alle Aktivitäten innerhalb eines Case. Dieser Timestamp ist essenziell für alle zeitbasierten Process Mining Analysen. Er wird verwendet, um Events zu ordnen, Zykluszeiten zwischen Aktivitäten zu berechnen, die Dauer des gesamten Prozesses zu messen und Wartezeiten oder Verzögerungen zu identifizieren. Er bildet das Rückgrat der Leistungsanalyse und ist erforderlich, um die Prozesskarte zu animieren. Bedeutung Der Start-Timestamp ist zwingend erforderlich, um Events chronologisch zu ordnen und alle Leistungsmetriken, wie Zykluszeiten und Wartezeiten, zu berechnen. Datenquelle In Event Log- oder Aufgabentabellen zu finden, entsprechend der Erstellungs- oder Startzeit einer aufgezeichneten Aktion. Beispiele 2023-10-26T08:30:00Z2023-10-26T09:15:10Z2023-10-26T11:05:45Z | |||
| Lagerauftrag WarehouseOrder | Die eindeutige Kennung für einen Lagerauftrag, die als primärer Case zur Verfolgung aller damit verbundenen logistischen Aktivitäten von der Erstellung bis zum Abschluss dient. | ||
| Beschreibung Der Warehouse Order ist die zentrale Kennung, die alle Events und Aufgaben im Zusammenhang mit einer spezifischen logistischen Anforderung, wie einem Wareneingang oder einem Warenausgang, gruppiert. Er repräsentiert eine komplette Arbeitseinheit innerhalb des Lagers. Im Process Mining wird dieses Attribut verwendet, um den Case zu definieren und so die End-to-End-Analyse des gesamten Auftragslebenszyklus zu ermöglichen. Durch die Verfolgung aller Aktivitäten, die mit einem einzelnen Warehouse Order verbunden sind, können Analysten die gesamten Erfüllungszeiten messen, häufige Prozessvariationen identifizieren und den vollständigen Weg eines Auftrags durch die Anlage verstehen. Bedeutung Dies ist die essenzielle Case-Kennung, die alle damit verbundenen Lageraktivitäten verbindet und eine vollständige End-to-End-Analyse des Auftragserfüllungs- oder Wareneingangsprozesses ermöglicht. Datenquelle Dies ist typischerweise der Primärschlüssel in der Kopfzeilentabelle des Lagerauftrags. Konsultieren Sie die Blue Yonder WMS Dokumentation für Tabellen, die sich auf das Auftragsmanagement beziehen. Beispiele WO-0012845WO-0012991WO-0013057 | |||
| Letzte Datenaktualisierung LastDataUpdate | `Timestamp`, der anzeigt, wann die `Daten` für diesen `Datensatz` zuletzt aus dem `Quellsystem` aktualisiert wurden. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit der letzten Extraktion oder Aktualisierung des Datensatzes aus Blue Yonder WMS. Es liefert Metadaten über die Aktualität der analysierten Daten. Dieser Timestamp ist wichtig für die Data Governance und damit Benutzer die Aktualität ihrer Analyse verstehen. Er stellt sicher, dass Stakeholder über die Gültigkeit der Daten informiert sind und darauf vertrauen können, dass sie einen aktuellen und relevanten Snapshot des Prozesses betrachten. Bedeutung Dieser Timestamp informiert Benutzer über die Aktualität der Daten und stellt sicher, dass sie den durch die Analyse abgedeckten Zeitraum verstehen. Datenquelle Dies ist ein Metadatenfeld, das typischerweise während des Datenextraktionsprozesses (ETL) generiert und hinzugefügt wird. Beispiele 2024-01-15T04:00:00Z2024-01-16T04:00:00Z | |||
| Quellsystem SourceSystem | Das System, aus dem die Daten extrahiert wurden, in diesem Fall Blue Yonder WMS. | ||
| Beschreibung Dieses Attribut identifiziert das Ursprungssystem für die Event-Daten. In einer modernen IT-Landschaft können Daten für einen einzelnen End-to-End-Prozess aus mehreren Systemen stammen, wie z.B. einem ERP, WMS und TMS. Die Angabe des Quellsystems ist entscheidend für die Data Governance, Fehlerbehebung und das Verständnis des Datenkontexts. Sie hilft, Datenqualitätsprobleme zu ihrer Herkunft zurückzuverfolgen und ist essenziell beim Zusammenführen von Daten aus mehreren Quellen, um eine einheitliche Prozessansicht zu erstellen. Bedeutung Es liefert essentielle Datenherkunftsinformationen, die helfen, Daten zur Validierung und in Szenarien, in denen Daten aus mehreren Systemen zusammengeführt werden, bis zu ihrem Ursprung zurückzuverfolgen. Datenquelle Dies ist typischerweise ein statischer Wert, der während des Datenextraktionsprozesses hinzugefügt wird, um den Ursprung des Datensatzes zu kennzeichnen. Beispiele BlueYonderWMS_USBlueYonderWMS_EU | |||
| Angefordertes Fertigstellungsdatum RequestedCompletionDate | Das Datum und die Uhrzeit, bis zu der der Lagerauftrag abgeschlossen und versandt werden soll oder angefordert wurde. | ||
| Beschreibung Das Requested Completion Date stellt die Service Level Agreement (SLA) oder das Ziel für die Erfüllung eines ausgehenden Lagerauftrags dar. Es ist die Frist, bis zu der die Waren kommissioniert, verpackt und versandbereit sein sollten. Dieses Datum ist der Maßstab, an dem die tatsächliche Leistung gemessen wird. Es wird verwendet, um die KPI der pünktlichen Versandrate zu berechnen, indem es mit dem tatsächlichen Versand-Timestamp verglichen wird. Die Analyse von Aufträgen basierend auf diesem Attribut hilft zu identifizieren, welche Aufträge verspätet sein könnten, und die Ursachen für SLA-Verletzungen zu diagnostizieren. Bedeutung Dieses Attribut ist der Maßstab für die Messung der Pünktlichkeit und entscheidend für die Berechnung der KPI für die pünktliche Versandrate. Datenquelle Typischerweise in der Kopfzeilentabelle des Lagerauftrags gespeichert, oft vom ursprünglichen Verkaufsauftrag oder der Lieferanfrage übernommen. Beispiele 2023-10-27T17:00:00Z2023-10-28T12:00:00Z2023-11-01T17:00:00Z | |||
| Benutzer-/Bediener-ID UserOperatorId | Die Kennung des Lageristen oder Bedieners, der die Aktivität durchgeführt hat. | ||
| Beschreibung Dieses Attribut erfasst die eindeutige ID der Person, die für die Ausführung einer bestimmten Lageraufgabe verantwortlich ist, wie z.B. Kommissionierung, Verpackung oder Einlagerung. Es verknüpft Prozessaktivitäten mit Personalressourcen. Die Analyse von Aktivitäten nach User/Operator ID ist essenziell, um die Ressourcenauslastung, Arbeitslastverteilung und individuelle Leistung zu verstehen. Sie hilft, Fragen zu beantworten, wie z.B. welche Bediener am effizientesten sind, wer zusätzliche Schulungen benötigt oder wie Aufgaben innerhalb eines Teams verteilt sind. Dies ist eine primäre Dimension für das Dashboard zur Lagerressourcenauslastung. Bedeutung Dieses Attribut verknüpft Prozessschritte mit den ausführenden Personen und ermöglicht so die Analyse von Ressourcenleistung, Arbeitslast und Schulungsbedarf. Datenquelle Häufig in Aufgaben- oder Transaktionstabellen zu finden, verknüpft mit dem Benutzer, der während des Vorgangs im System oder auf dem Handheld-Gerät angemeldet war. Beispiele JSMITHBWILLISAMILLER | |||
| Endzeit des Events EventEndTime | Der Timestamp, der angibt, wann eine spezifische Lageraktivität oder ein Event abgeschlossen wurde. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit, zu der eine Lageraufgabe oder ein Event abgeschlossen wurde. Sofern verfügbar, bietet es ein präzises Maß für die Bearbeitungszeit jeder Aktivität. Das Vorhandensein von Start- und Endzeit ermöglicht eine detailliertere Leistungsanalyse. Es erlaubt die Trennung von Wartezeit (Zeit zwischen Aktivitäten) und Bearbeitungszeit (Dauer der Aktivität selbst). Dies ist entscheidend, um herauszufinden, ob Verzögerungen durch Leerlaufzeiten oder durch zu lange dauernde Aufgaben verursacht werden. Bedeutung Es ermöglicht die präzise Berechnung der Aktivitätsbearbeitungszeit und unterscheidet diese von der Wartezeit, was entscheidend für gezielte Leistungsverbesserungen ist. Datenquelle In Event Log- oder Aufgabentabellen zu finden, entsprechend der Abschluss- oder Endzeit einer aufgezeichneten Aktion. Beispiele 2023-10-26T08:35:12Z2023-10-26T09:20:05Z2023-10-26T11:06:00Z | |||
| Geplante Menge PlannedQuantity | Die erwartete Menge an Artikeln für eine bestimmte Aufgabe, z.B. die zu kommissionierende oder zu empfangende Menge. | ||
| Beschreibung Die geplante Menge repräsentiert die vom Lagerauftrag für eine bestimmte Aufgabe festgelegte Zielanzahl von Einheiten. Bei einer Wareneingangslieferung ist dies die vom Lieferanten erwartete Menge. Bei einer Kommissionieraufgabe ist es die vom Kundenauftrag angeforderte Menge. Dieses Attribut ist entscheidend für die Genauigkeitsanalyse. Durch den Vergleich der geplanten Menge mit der tatsächlichen Menge ist es möglich, Abweichungen bei Wareneingangs-, Kommissionier- oder Bestandszählungen zu identifizieren. Es unterstützt direkt KPIs wie die Kommissioniermengen-Abweichungsrate und ist essenziell für das Dashboard zur Mengen-Genauigkeitsprüfung. Bedeutung Es dient als Basis für die Genauigkeitsmessung und ermöglicht die Erkennung von Mengenabweichungen bei Wareneingangs- und Kommissionieraktivitäten. Datenquelle In den Detail- oder Positionstabellen zu finden, die mit Lageraufträgen oder spezifischen Aufgaben verknüpft sind. Beispiele 1005024 | |||
| Lagerort StorageLocation | Der spezifische Ort innerhalb des Lagers, z.B. ein Lagerplatz oder Gang, wo Waren gelagert oder kommissioniert werden. | ||
| Beschreibung Dieses Attribut identifiziert den physischen Standort innerhalb des Lagers, der mit einer Aufgabe verbunden ist. Für eine Einlagerungsaktivität ist es der Zielplatz. Für eine Kommissionieraktivität ist es der Quellplatz. Dies könnte als zusammengesetzter Code dargestellt werden, der Gang, Regal, Fach und Lagerplatznummer umfasst. Die Analyse von Daten nach Lagerort hilft beim Verständnis der Effizienz des Lagerlayouts, der Slotting-Strategien und der Ressourcenbewegung. Sie wird verwendet, um stark frequentierte Bereiche, unterausgelastete Zonen und potenzielle Engpässe im Materialfluss zu identifizieren. Dieses Attribut ist fundamental für das Dashboard für Lagerort-Nutzungstrends. Bedeutung Es liefert entscheidenden Kontext für die Analyse des Lagerlayouts, der Effektivität der Einlagerungsstrategie und die Identifizierung von Bewegungsengpässen. Datenquelle Verfügbar in Tabellen im Zusammenhang mit Inventar, Lageraufgaben (Kommissionierung, Einlagerung) und Stammdaten der Lagerplätze. Beispiele A1-R03-S02-B01B5-R10-S04-B05C2-R01-S01-B02 | |||
| Prioritätsstufe PriorityLevel | Die Priorität des Lagerauftrags, z.B. 'Hoch', 'Standard' oder 'Niedrig'. | ||
| Beschreibung Das Prioritätslevel gibt die Dringlichkeit eines Lagerauftrags an. Aufträge mit hoher Priorität, wie z.B. Expresslieferungen, sollen schneller bearbeitet werden als Standardaufträge. Dieses Attribut wird vom WMS verwendet, um Aufgaben zu sequenzieren und Ressourcen zuzuweisen. Im Process Mining ist dieses Attribut entscheidend, um zu analysieren, ob Priorisierungsstrategien effektiv sind. Das Dashboard für die High Priority Order Fulfillment stützt sich auf dieses Feld, um nach dringenden Aufträgen zu filtern und deren Zykluszeiten mit denen von Standardaufträgen zu vergleichen. Es hilft zu überprüfen, ob hochpriorisierte Aufträge tatsächlich schneller durch den Prozess laufen oder ob sie in denselben Engpässen stecken bleiben. Bedeutung Dies ermöglicht die Analyse, ob Aufträge mit hoher Priorität schneller bearbeitet werden als Standardaufträge, und validiert die Wirksamkeit von Priorisierungsregeln. Datenquelle Diese Informationen sind normalerweise in der Kopfzeilentabelle des Lagerauftrags gespeichert. Beispiele HochStandardNiedrig | |||
| Tatsächliche Menge ActualQuantity | Die tatsächlich gehandhabte Menge an Artikeln während einer Aufgabe, z.B. die physisch gezählte oder kommissionierte Menge. | ||
| Beschreibung Die tatsächliche Menge ist die Anzahl der Einheiten, die von einem Lagerarbeiter während einer Aufgabe physisch verarbeitet wurden. Dies kann die Anzahl der von einem Lieferanten erhaltenen Artikel, die Anzahl der aus einem Lagerfach entnommenen Einheiten oder die in einen Versandbehälter verpackte Menge sein. Im Vergleich zur geplanten Menge zeigt dieses Attribut Prozessausnahmen und Fehler auf. Es ist die Kernmetrik zur Berechnung von Abweichungsraten, die Schlüsselindikatoren für die operative Qualität sind. Diese Daten sind entscheidend für die Identifizierung von Problemen bei Lieferantensendungen, Kommissionierfehlern oder Bestandsungenauigkeiten. Bedeutung Der Vergleich mit der geplanten Menge ist unerlässlich, um Prozessfehler zu identifizieren und wichtige Qualitäts-KPIs wie Abweichungsraten zu berechnen. Datenquelle In Aufgabenbestätigungs- oder Transaktionsprotokoll-Tabellen zu finden, wo Bediener die ausgeführte Menge aufzeichnen. Beispiele 1004924 | |||
| Aktivitätsbearbeitungszeit ActivityProcessingTime | Die Dauer in Sekunden oder Minuten, die zur Durchführung einer einzelnen Aktivität erforderlich ist. | ||
| Beschreibung Dies ist eine berechnete Metrik, die die verstrichene Zeit zwischen dem Start und dem Ende einer Aktivität misst. Sie repräsentiert die tatsächlich auf eine Aufgabe verwendete Zeit, im Gegensatz zur Wartezeit, bis die Aufgabe beginnt. Diese Metrik ist fundamental für die Leistungsanalyse und hilft zu identifizieren, welche spezifischen Aktivitäten am zeitaufwendigsten sind. Sie ermöglicht Analysten, zwischen Prozessschritten, die von Natur aus langsam sind, und Verzögerungen, die zwischen den Schritten auftreten, zu unterscheiden, was gezieltere Verbesserungsbemühungen ermöglicht. Dies ist eine Schlüsselmetrik für Dashboards, die auf Durchsatz und Engpässe ausgerichtet sind. Bedeutung Es isoliert die Zeit, die aktiv an einer Aufgabe gearbeitet wird, und hilft so, genau zu bestimmen, welche spezifischen Aktivitäten am längsten zur Fertigstellung benötigen. Datenquelle Berechnet durch Subtrahieren von EventStartTime von EventEndTime für jeden Aktivitätseintrag. Beispiele 31229515 | |||
| Anlagen-ID EquipmentId | Bezeichner für die verwendete Materialtransportausrüstung, wie z.B. ein bestimmter Gabelstapler oder ein Förderband. | ||
| Beschreibung Die Equipment ID gibt an, welches Maschinen- oder Ausrüstungsstück zur Durchführung einer Lageraufgabe verwendet wurde. Dies kann Gabelstapler, Hubwagen, fahrerlose Transportsysteme (FTS) oder spezifische Packstationen umfassen. Dieses Attribut ermöglicht die Analyse der Auslastung, Leistung und des Wartungsbedarfs von Geräten. Durch die Verfolgung von Aktivitäten pro Gerät können Manager über- oder unterausgelastete Assets identifizieren, die Effizienz verschiedener Maschinentypen vergleichen und Daten für die Wartungsplanung sammeln. Es ist eine Schlüsseldimension für das Dashboard zur Lagerressourcenauslastung. Bedeutung Es ermöglicht die Analyse der Anlagenauslastung und -leistung und hilft, die Zuweisung von Assets und Wartungspläne zu optimieren. Datenquelle Kann in Aufgaben-Ausführungsprotokollen erfasst werden, insbesondere in Umgebungen, in denen Bediener sich an Geräten anmelden. Beispiele FORKLIFT-07AGV-03PACKSTATION-12 | |||
| Aufgabenstatus TaskStatus | Der Endstatus einer bestimmten Aufgabe, z.B. 'Completed', 'Canceled' oder 'Failed'. | ||
| Beschreibung Dieses Attribut beschreibt das Ergebnis einer spezifischen Lageraufgabe. Während viele Aufgaben erfolgreich abgeschlossen werden, können einige von einem Vorgesetzten storniert werden oder aufgrund von System- oder Betriebsproblemen fehlschlagen. Dies bietet mehr Kontext als nur der Aktivitätsname. Die Analyse nach Task Status ist nützlich, um Ausnahmen und Prozessfehler zu verstehen. Eine hohe Rate an stornierten oder fehlgeschlagenen Aufgaben kann auf zugrundeliegende Probleme mit der Bestandsgenauigkeit, Systemkonfiguration oder Bedienerschulung hinweisen. Es hilft, Aktivitäten zu identifizieren, die anfällig für Fehler sind und weitere Untersuchungen erfordern. Bedeutung Es liefert das Ergebnis einer Aktivität und ermöglicht die Analyse von Ausnahmen wie stornierten oder fehlgeschlagenen Aufgaben, die auf tiefere operative Probleme hinweisen können. Datenquelle Typischerweise in der Aufgabentabelle zu finden, die den Endzustand des Aufgabendatensatzes angibt. Beispiele AbgeschlossenStorniertAuf Wartestellung | |||
| Ist Mengenabweichung IsQuantityMismatch | Ein boolesches Flag, das anzeigt, ob die tatsächlich bearbeitete Menge von der geplanten Menge für eine Aufgabe abweicht. | ||
| Beschreibung Dieses berechnete Attribut ist ein einfaches Flag, das eine Mengendifferenz für eine bestimmte Aufgabe, z.B. Kommissionierung oder Wareneingang, anzeigt. Es wird auf 'true' gesetzt, wenn die 'Tatsächliche Menge' nicht der 'Geplanten Menge' entspricht. Dieses Flag wird verwendet, um Fehler im Prozess leicht zu identifizieren und zu zählen. Es vereinfacht die Berechnung von KPIs wie der Kommissionier-Mengendifferenzrate und der Wareneingangs-Mengendifferenzrate. Es erleichtert auch die Ursachenanalyse, indem es Analysten ermöglicht, nach allen Diskrepanz-Events zu filtern und nach Mustern in Bezug auf Produkte, Bediener oder Standorte zu suchen. Bedeutung Es kennzeichnet Ereignisse mit Mengenfehlern, vereinfacht die Berechnung von Abweichungsraten und ermöglicht eine gezielte Analyse ungenauer Aufgaben. Datenquelle Berechnet durch den Vergleich der Felder PlannedQuantity und ActualQuantity für jede relevante Aktivität. Beispiele falschtruefalsch | |||
| Ist pünktlicher Versand IsOnTimeShipment | Ein boolesches Flag, das wahr ist, wenn die Sendung am oder vor dem angeforderten Fertigstellungstermin versandt wurde. | ||
| Beschreibung Dieses berechnete Attribut liefert einen einfachen Wahrheitswert, der anzeigt, ob ein Auftrag seine Versand-SLA eingehalten hat. Es wird abgeleitet, indem der Timestamp der Aktivität 'Shipment Dispatched' mit dem 'Requested Completion Date' des Auftrags verglichen wird. Dieses Flag vereinfacht die Analyse und Visualisierung der Pünktlichkeit. Es ermöglicht eine einfache Filterung und Aggregation, um die KPI der pünktlichen Versandrate zu berechnen und das entsprechende Dashboard zu versorgen. Es ermöglicht auch eine Ursachenanalyse, um gemeinsame Merkmale verspäteter Sendungen zu identifizieren. Bedeutung Dieses boolesche Flag vereinfacht die Berechnung der KPI für die pünktliche Versandrate und ermöglicht eine einfache Filterung zur Analyse der Merkmale von verspäteten Aufträgen. Datenquelle Berechnet durch den Vergleich des EventStartTime der Aktivität "Shipment Dispatched" mit dem Attribut RequestedCompletionDate. Beispiele truefalschtrue | |||
| Lager-ID WarehouseId | Bezeichner für das spezifische Lager oder Distributionszentrum, in dem die Aktivität stattfand. | ||
| Beschreibung Die Warehouse ID identifiziert eindeutig die Anlage, in der der Prozess stattfindet. Dies ist essenziell für Organisationen, die mehrere Distributionszentren betreiben. Dieses Attribut ermöglicht Benchmarking und Vergleichsanalysen über verschiedene Standorte hinweg. Durch Filtern oder Aufteilen der Daten nach Warehouse ID können Unternehmen die Leistung vergleichen, Best Practices an leistungsstarken Standorten identifizieren und verstehen, warum bestimmte Anlagen zurückliegen. Es bietet eine entscheidende Dimension für die standortübergreifende Betriebsdatenanalyse. Bedeutung Für Multi-Site-Organisationen ist dieses Attribut unerlässlich, um die Leistung zu benchmarken und Prozesse an verschiedenen Standorten zu vergleichen. Datenquelle Dies ist oft ein übergeordnetes Organisationsfeld, das in fast allen Transaktionstabellen verfügbar ist oder aus der Systeminstanz abgeleitet werden kann. Beispiele WHC-01DC-EAST-03FAC-WEST | |||
| Lagerauftragstyp WarehouseOrderType | Kategorisiert den Lagerauftrag, zum Beispiel als Wareneingang, Warenausgang oder interne Umlagerung. | ||
| Beschreibung Dieses Attribut klassifiziert den übergeordneten Zweck des Lagerauftrags. Gängige Typen umfassen eingehende Lieferungen von Lieferanten, ausgehende Sendungen an Kunden, Retourenabwicklung oder interne Lagerbewegungen zwischen Lagerorten. Die Segmentierung des Prozesses nach Warehouse Order Type ist ein grundlegender erster Schritt in jeder Analyse. Inbound- und Outbound-Prozesse unterscheiden sich oft erheblich, mit unterschiedlichen Schritten, Ressourcen und Leistungszielen. Dieses Attribut ermöglicht das Filtern der Daten, um einen spezifischen Prozess, wie Wareneingang oder Auftragserfüllung, isoliert zu analysieren. Bedeutung Es ermöglicht die Trennung und vergleichende Analyse verschiedener Prozesse, wie z.B. Wareneingang vs. Warenausgang, die unterschiedliche Abläufe und Ziele haben. Datenquelle In der Kopfzeilentabelle des Lagerauftrags zu finden, typischerweise als Dokumententyp- oder Auftragskategoriefeld. Beispiele WareneingangslieferungAusgehender VersandInterne Weiterleitung | |||
| Produkt-SKU ProductSku | Die Stock Keeping Unit (SKU) oder Materialnummer des bearbeiteten Artikels. | ||
| Beschreibung Dieses Attribut identifiziert das spezifische Produkt, das an einer Lageraufgabe beteiligt ist. Es liefert detaillierte Informationen über die Materialien, die bewegt, gelagert, kommissioniert und verpackt werden. Die Analyse des Prozesses nach Produkt-SKU kann Muster im Zusammenhang mit bestimmten Artikeln aufdecken. Zum Beispiel können einige Produkte anfällig für Kommissionierfehler sein, längere Einlagerungszeiten aufgrund spezieller Handhabungsanforderungen haben oder an ineffizienten Orten gelagert werden. Dies ermöglicht eine produktspezifische Prozessoptimierung und Verbesserung der Slotting-Strategien. Bedeutung Es ermöglicht eine Analyse auf Produktebene, die hilft, Artikel zu identifizieren, die Prozessverzögerungen, Fehler verursachen oder eine spezielle Handhabung erfordern. Datenquelle Diese Informationen befinden sich auf der Positionsebene der Lagerauftrags- oder Aufgabentabellen. Beispiele PN-A5540-BSKU-300-RED-LGHW-88201 | |||
| Sendungs-ID ShipmentId | Die eindeutige Kennung für die ausgehende Sendung, zu der ein Lagerauftrag gehört. | ||
| Beschreibung Die Shipment ID ist eine übergeordnete Kennung, die mehrere Lageraufträge zusammenfassen kann, wenn diese im selben LKW oder Container versandt werden. Für einen einzelnen Auftrag kann sie identisch mit dem Lagerauftrag oder der Liefernummer sein. Die Analyse nach Shipment ID bietet einen Überblick über den Versandprozess. Sie kann helfen zu verstehen, wie Aufträge konsolidiert werden, die Zeit von der Bereitstellung bis zum endgültigen Versand einer kompletten LKW-Ladung zu messen und die Effizienz der Versandabteilung zu analysieren. Sie verbindet Lageraktivitäten mit dem letzten Transportabschnitt der Lieferkette. Bedeutung Es gruppiert Lageraufträge, die zusammen versendet werden, und ermöglicht die Analyse der Sendungskonsolidierungs- und Versandprozesse. Datenquelle In Versand- oder Transporttabellen zu finden, die mit den Lageraufträgen verknüpft sind. Beispiele SHP-45000123SHP-45000124SHP-45000125 | |||
Warehouse Management Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Kommissionieraufgabe erstellt | Dieses Event bedeutet die Erstellung einer Aufgabe für einen Bediener, Waren aus einem Lagerort zur Erfüllung eines ausgehenden Auftrags zu entnehmen. Es ist ein explizites Event, das vom WMS generiert wird, wenn ein ausgehender Auftrag zur Kommissionierung freigegeben wird. | ||
| Bedeutung Dies ist der Start des physischen Outbound-Prozesses. Die Analyse der Zeit von der Auftragserstellung bis zur Erstellung der Kommissionieraufgabe zeigt Verzögerungen bei der Auftragsbearbeitung und -zuweisung auf. Datenquelle In den Aufgabenmanagement- oder Lagersteuerungstabellen protokolliert. Es entspricht dem Erstellungs-Timestamp der Kommissionieraufgaben, die mit dem Lagerauftrag verknüpft sind. Erfassen Erstellungs-Timestamp der systemgenerierten Kommissionieraufgabe. Ereignistyp explicit | |||
| Lagerauftrag abgeschlossen | Dies ist der Endstatus des Lagerauftrags, der anzeigt, dass alle damit verbundenen Aktivitäten, einschließlich des Versands, abgeschlossen und der Auftrag geschlossen ist. Es wird erfasst, wenn der Lebenszyklusstatus des Auftrags auf 'Completed' oder 'Closed' aktualisiert wird. | ||
| Bedeutung Diese Aktivität markiert das definitive Ende des Prozess-Case. Sie stellt sicher, dass die Prozessanalyse den vollständigen Lebenszyklus jedes Auftrags von Anfang bis Ende erfasst. Datenquelle Dies kann aus einer Statusänderung in der Kopfzeilentabelle des Lagerauftrags abgeleitet werden. Suchen Sie nach einem Endstatus wie 'Completed', 'Closed' oder 'Invoiced' zusammen mit dem Timestamp dieser Statusänderung. Erfassen Abgeleitet vom Zeitstempel der letzten Statusänderung im Auftragsheader. Ereignistyp inferred | |||
| Lagerauftrag erstellt | Dieses Event markiert die Erstellung eines Lagerauftrags, der das zentrale Dokument zur Verwaltung von eingehenden, ausgehenden oder internen Lageraufgaben ist. Es wird typischerweise als explizite Transaktion erfasst, wenn ein neuer Auftrag manuell oder über eine Integration in das Blue Yonder WMS eingegeben wird. | ||
| Bedeutung Dies ist der definitive Start des Prozesses. Die Analyse der Zeit von diesem Event bis zum Abschluss liefert die gesamte Durchlaufzeit der Auftragserfüllung, die für die Messung der Gesamteffizienz und die Einhaltung von Service Level Agreements unerlässlich ist. Datenquelle Dieses Event wird wahrscheinlich in einer Auftrags-Kopfzeilentabelle erfasst, aufgezeichnet durch den Erstellungs-Timestamp des Lagerauftragsdatensatzes. Suchen Sie nach Tabellen, die mit Erfassen Vom Erstellungs-Timestamp des Lagerauftragsdatensatzes. Ereignistyp explicit | |||
| Sendung versandt | Dieses Event bedeutet, dass die verpackten Waren auf den LKW des Spediteurs verladen wurden und der LKW das Lager verlassen hat. Dies wird typischerweise erfasst, wenn ein 'Goods Issue' im System gebucht wird, wodurch die Sendung finalisiert wird. | ||
| Bedeutung Dies ist ein kritischer Meilenstein, der das Ende der Lagerverantwortung für den Auftrag markiert. Es ist der letzte Datenpunkt zur Messung der pünktlichen Versandleistung und der End-to-End-Durchlaufzeit der Erfüllung. Datenquelle Dies ist eine wichtige Finanz- und Logistiktransaktion, oft als 'Warenausgang buchen' (PGI) bezeichnet. Der Timestamp für diese Transaktion dient als Versandzeit und wird üblicherweise in den Tabellen der ausgehenden Lieferung oder des Versanddokuments gespeichert. Erfassen Timestamp der Warenausgangsbuchung (PGI) Transaktion. Ereignistyp explicit | |||
| Waren in Lager eingelagert | Dieses Event bestätigt, dass Waren erfolgreich bewegt und in ihren vorgesehenen Lagerplatz gescannt wurden. Es wird erfasst, wenn ein Bediener den Abschluss der Einlagerungsaufgabe bestätigt, typischerweise mit einem Handheld-RF-Gerät. | ||
| Bedeutung Dies markiert das Ende des Wareneingangsprozesses und macht den Bestand für die Erfüllung verfügbar. Die Analyse der Zeit vom Wareneingang bis zu diesem Punkt ist entscheidend für das Dashboard 'Wareneingang bis Einlagerung Zykluszeit'. Datenquelle Als Timestamp-Transaktion erfasst, wenn der Status der Einlagerungsaufgabe auf 'Completed' oder 'Confirmed' aktualisiert wird. Diese Daten finden Sie in den Lagertask- oder Umbuchungsauftragstabellen. Erfassen Bestätigungs-Timestamp der Einlagerungslageraufgabe. Ereignistyp explicit | |||
| Wareneingang und gezählt | Dieses Event bedeutet, dass Waren entladen, gescannt und ihre Mengen mit den Lieferdokumenten abgeglichen wurden. Es wird normalerweise erfasst, wenn ein Wareneingangsmitarbeiter die erhaltenen Mengen im System für jeden Artikel des Wareneingangsauftrags bestätigt. | ||
| Bedeutung Dies ist ein kritischer Meilenstein, der den Lagerbestand offiziell im System verfügbar macht, wenn auch noch nicht versandbereit. Die Dauer und Genauigkeit dieses Schritts wirken sich direkt auf die Bestandsübersicht und den Beginn des Einlagerungsprozesses aus. Datenquelle Dies ist eine explizite Transaktion, die in Bestands- oder Wareneingangsprotokollen erfasst wird. Suchen Sie nach Transaktionen im Zusammenhang mit der Buchung des Wareneingangs oder Statusänderungen der eingehenden Lieferpositionen auf 'Received'. Erfassen Timestamp der Transaktion, die den Wareneingang bestätigt. Ereignistyp explicit | |||
| Bereitstellung für den Versand | Stellt die Bewegung von verpackten Behältern vom Packbereich zu einem vorgesehenen Bereitstellungsbereich für den Versand dar, um auf die Abholung durch den Spediteur zu warten. Das Event wird protokolliert, wenn ein Bediener die Bewegung der Handling Unit in den Bereitstellungsbereich bestätigt. | ||
| Bedeutung Diese Aktivität hilft, die Verweilzeit zu analysieren, d.h. die Zeit, die verpackte Aufträge vor der Verladung warten. Lange Bereitstellungszeiten können auf eine schlechte Koordination mit Spediteuren oder eine ineffiziente Nutzung des Bereitstellungsbereichs hinweisen. Datenquelle Dieses Event kann aus einer Standortänderung der Handling Unit oder des Versandcontainers zu einem Bereitstellungsort abgeleitet werden. Es kann auch eine explizite 'Move to Stage' Aufgabenbestätigung sein. Erfassen Abgeleitet aus Bestandsbewegungs-Logs, die die Umlagerung in einen Bereitstellungsplatz zeigen. Ereignistyp inferred | |||
| Einlagerungsaufgabe erstellt | Diese Aktivität markiert die Systemerstellung einer Aufgabe, um empfangene Waren von der Wareneingangsdock zu einem endgültigen Lagerort zu transportieren. Es ist ein explizites System-Event, das von der WMS-Logik generiert wird, um einen Lageristen anzuweisen. | ||
| Bedeutung Dies ist der Start des Einlagerungsprozesses. Verzögerungen zwischen Wareneingang und Erstellung der Einlagerungsaufgabe können auf Systemkonfigurations- oder Leistungsprobleme hinweisen, wodurch Waren im Wareneingangsbereich liegen bleiben. Datenquelle Generiert und protokolliert in den Aufgabenmanagement- oder Lagersteuerungstabellen. Suchen Sie nach dem Erstellungs-Timestamp von Einlagerungsaufgaben oder Umlagerungsaufträgen, die mit der Wareneingangslieferung verknüpft sind. Erfassen Erstellungs-Timestamp der systemgenerierten Einlagerungsaufgabe. Ereignistyp explicit | |||
| Lagerauftrag storniert | Stellt die Stornierung eines Lagerauftrags dar, bevor dieser vollständig bearbeitet oder versandt wurde. Dieses Event wird erfasst, wenn ein Benutzer eine Stornierungstransaktion ausführt und den Status des Auftrags auf 'Canceled' aktualisiert. | ||
| Bedeutung Die Analyse von Stornierungen hilft, Gründe für Prozessfehler zu identifizieren, wie z.B. Bestandsverfügbarkeit oder Kundenänderungen. Es ist ein kritisches Endereignis für das Verständnis von Prozessabweichungen und -ausfällen. Datenquelle Dies ist typischerweise ein abgeleitetes Event, das auf dem Endstatus des Lagerauftrags basiert. Es würde der Timestamp der Statusänderung auf 'Canceled' oder 'Deleted' verwendet. Erfassen Abgeleitet vom Zeitstempel einer Statusänderung auf "Storniert". Ereignistyp inferred | |||
| Qualitätsinspektion durchgeführt | Stellt eine Qualitätsprüfung der Wareneingänge dar. Dies kann ein Standardschritt für bestimmte Materialien oder ein durch Ausnahmen ausgelöstes Event sein und wird erfasst, wenn ein Qualitätsprüfer seine Befunde im System festhält. | ||
| Bedeutung Qualitätsprüfungen können eine erhebliche Verzögerungsquelle im Wareneingangsprozess darstellen. Die Analyse ihrer Häufigkeit und Dauer hilft, Qualitätsprobleme bei Lieferanten und Engpässe im Prüf-Workflow zu identifizieren. Datenquelle In den Qualitätsmanagement (QM) Modulen oder Protokollen, die mit der eingehenden Lieferung verbunden sind, erfasst. Suchen Sie nach spezifischen Transaktionscodes für Qualitätsprüfungsergebnisse oder Statusänderungen des Inventars auf 'Quality Hold'. Erfassen Timestamp des Abschlusses der Qualitätsprüfung oder der Statusaktualisierung. Ereignistyp explicit | |||
| Verpackung initiiert | Diese Aktivität markiert den Beginn des Verpackungsprozesses an einer Packstation. Sie wird typischerweise protokolliert, wenn ein Bediener die kommissionierten Artikel oder den Auftragsbehälter an der Packstation scannt, um die Sendung vorzubereiten. | ||
| Bedeutung Dieses Event signalisiert die Übergabe von der Kommissionierung zum Verpacken. Es hilft, die Verpackungsphase des Erfüllungsprozesses zu isolieren, um spezifische Engpässe innerhalb des Verpackungsbereichs zu identifizieren. Datenquelle Dies kann ein explizites Transaktionsprotokoll der Benutzeroberfläche einer Packstation sein. Alternativ könnte es aus der ersten mit Zeitstempel versehenen Aktivität abgeleitet werden, die mit einem Verpackungsarbeitsplatz für diesen Auftrag verbunden ist. Erfassen Timestamp der Transaktion 'Verpackung starten' an einer Packstation. Ereignistyp explicit | |||
| Waren an Rampe angekommen | Diese Aktivität markiert die physische Ankunft eines LKW oder Spediteurs am Wareneingang des Lagers, bevor das Entladen beginnt. Dieses Event wird oft explizit von einem Yard Management Modul protokolliert oder wenn ein Torwart die Lieferung anmeldet. | ||
| Bedeutung Die Verfolgung der Ankunftszeit hilft, die Pünktlichkeit der Spediteure zu messen und Verzögerungen zwischen der Ankunft des Spediteurs und dem Beginn des Wareneingangsprozesses zu identifizieren. Sie zeigt potenzielle Engpässe im Yard Management oder an den Wareneingangstoren auf. Datenquelle Typischerweise in einem Yard Management oder Gate Control Modul innerhalb von Blue Yonder WMS erfasst. Es könnte auch eine manuelle Timestamp-Eingabe durch einen Wareneingangsmitarbeiter bei Ankunft des LKWs sein. Erfassen Timestamp der Spediteur-Check-in-Transaktion. Ereignistyp explicit | |||
| Waren aus Lager entnommen | Stellt den Abschluss der Kommissionieraufgabe dar, bei der ein Bediener die Artikel entnommen und die Aktion im System bestätigt hat. Das Event wird erfasst, wenn der Bediener die Artikel scannt und die Kommissionierung auf seinem Gerät bestätigt. | ||
| Bedeutung Dieser Meilenstein schließt die Kommissionierphase ab. Die Genauigkeit und Dauer dieser Aktivität sind entscheidend für die Gesamteffizienz der Auftragserfüllung und bilden die Grundlage für die Analyse der 'Picking Accuracy'. Datenquelle Erfasst vom Bestätigungs-Timestamp, wenn der Status der Kommissionieraufgabe auf "Abgeschlossen" geändert wird. Dies ist in den Lageraufgabentabellen zu finden, oft verknüpft mit dem spezifischen Bediener und der Ausrüstung. Erfassen Bestätigungs-Timestamp der Kommissionierlageraufgabe. Ereignistyp explicit | |||
| Waren verpackt | Dieses Event bestätigt, dass alle Artikel für eine Sendung in Versandbehälter verpackt und Etiketten generiert wurden. Es wird erfasst, wenn der Packer den Abschluss des Verpackungsprozesses für den Auftrag im System bestätigt. | ||
| Bedeutung Dies markiert den Abschluss wertschöpfender Aktivitäten innerhalb der Lagermauern. Die Zeit von diesem Punkt bis zum Versand repräsentiert die Bereitstellungs- und Ladezeit, ein Schlüsselbereich für potenzielle Verzögerungen. Datenquelle Dies ist eine explizite Transaktion, die protokolliert wird, wenn der Verpackungsprozess abgeschlossen ist. Suchen Sie nach einer Statusänderung der ausgehenden Lieferung auf 'Packed' oder einem Abschluss-Timestamp der Packstationstransaktion. Erfassen Timestamp der Transaktion 'Verpackung bestätigen' oder 'Container schließen'. Ereignistyp explicit | |||
| Wareneingang gemeldet | Stellt den Eingang einer Advanced Shipping Notification (ASN) von einem Lieferanten dar, die anzeigt, dass Waren auf dem Weg zum Lager sind. Dies ist ein explizites Event, das erfasst wird, wenn eine ASN empfangen und vom System verarbeitet wird, oft über EDI oder ein Portal. | ||
| Bedeutung Diese Aktivität ist der Auslöser für die Eingangsplanung und Ressourcenzuweisung. Die Zeitspanne zwischen dieser Benachrichtigung und dem physischen Wareneingang ist eine zentrale KPI zur Messung der Lieferantenleistung und der Transparenz der Eingangspipeline. Datenquelle Erfasst aus ASN-Empfangsprotokollen oder dem Erstellungs-Timestamp des Wareneingangsdokuments innerhalb von Blue Yonder WMS. Überprüfen Sie Tabellen, die sich auf ASNs oder eingehende Versandbenachrichtigungen beziehen. Erfassen Timestamp aus einer ASN- oder Wareneingangslieferdokumentenerstellung. Ereignistyp explicit | |||
Extraktionsleitfäden
Schritte
- Voraussetzungen und Zugriff: Stellen Sie sicher, dass Sie ein Benutzerkonto für Blue Yonder WMS mit den erforderlichen Berechtigungen zur Ausführung von MOCA-Befehlen und zum Zugriff auf die benötigten Tabellen, wie ord_hdr, pckwrk_dtl und invmov, haben. Sie benötigen Zugriff auf einen MOCA-Client, wie die MOCA Console oder eine Befehlszeilenschnittstelle.
- MOCA-Skript überprüfen und anpassen: Kopieren Sie das bereitgestellte MOCA-Skript. Überprüfen Sie sorgfältig die Tabellen- und Spaltennamen, um sicherzustellen, dass sie Ihrer spezifischen Blue Yonder WMS-Implementierung entsprechen. Achten Sie besonders auf Platzhalter wie
@[where_clause_dates]und@[where_clause_warehouse], die durch tatsächliche Werte ersetzt werden müssen. - Extraktionsparameter definieren: Ersetzen Sie die Platzhaltervariablen im Skript. Für
@[where_clause_dates]definieren Sie einen spezifischen Datumsbereich, zum Beispielwhere adddte between 'JJJJ-MM-TT' and 'JJJJ-MM-TT'. Für@[where_clause_warehouse]geben Sie die Lager-IDs an, die Sie extrahieren möchten, zum Beispielwhere wh_id = '[Ihre Lager-ID]'. - Verbindung zum MOCA-Server herstellen: Starten Sie Ihren MOCA-Client (z.B. MOCA Console) und stellen Sie eine Verbindung zur korrekten Blue Yonder WMS-Umgebung her.
- MOCA-Skript ausführen: Fügen Sie das angepasste Skript in die MOCA Console ein. Führen Sie den Befehl aus. Das Skript wird auf dem Server ausgeführt und sammelt Daten für alle angegebenen Aktivitäten.
- Ausführung überwachen: Bei großen Datensätzen kann die Abfrage eine erhebliche Zeit in Anspruch nehmen. Überwachen Sie die Konsole auf Fehlermeldungen oder Leistungswarnungen. Wenn die Abfrage eine Zeitüberschreitung aufweist, erwägen Sie, sie für kleinere Datumsbereiche auszuführen.
- Ergebnisse in eine Datei exportieren: Sobald das Skript erfolgreich ausgeführt wurde, werden die Ergebnisse in der Konsole angezeigt. Verwenden Sie die Exportfunktion des Clients, um die Ausgabe als CSV-Datei zu speichern. Eine gängige Methode über die Befehlszeile ist es, die Ausgabe direkt in eine Datei umzuleiten, zum Beispiel:
mocarun -S "[Ihr MOCA Skript]" > event_log.csv. - CSV für ProcessMind formatieren: Öffnen Sie die exportierte CSV-Datei. Überprüfen Sie, ob die Spaltenüberschriften mit den in der Abfrage angegebenen Attributen übereinstimmen (
WarehouseOrder,ActivityName,EventStartTime, etc.). Stellen Sie sicher, dass die Datei mit UTF-8-Kodierung gespeichert wird, um Zeichenprobleme beim Upload zu vermeiden. - Überprüfen und hochladen: Führen Sie eine letzte Überprüfung des Dateiinhaltes durch und suchen Sie nach offensichtlichen Fehlern oder Inkonsistenzen. Sobald Sie zufrieden sind, laden Sie die CSV-Datei zur Analyse in ProcessMind hoch.
Konfiguration
- Datumsbereich: Es wird empfohlen, Daten für einen Zeitraum von 3 bis 6 Monaten zu extrahieren, um eine repräsentative Stichprobe von Prozessvariationen sicherzustellen. Der Datumsfilter-Platzhalter
@[where_clause_dates]sollte auf die primäre Timestamp-Spalte in jeder SELECT-Anweisung angewendet werden, wie z.B.adddteodermoddte. - Lager- und Kundenfilter: Verwenden Sie immer Filter, um den Umfang der Extraktion zu begrenzen. Der Platzhalter
@[where_clause_warehouse]sollte verwendet werden, um nach spezifischen Lager-IDs (wh_id) und gegebenenfalls Kunden-IDs (client_id) zu filtern. Dies ist entscheidend für Leistung und Datenrelevanz. - Auftragstyp-Filter: Um die Analyse zu fokussieren, sollten Sie das Filtern nach spezifischen Lagerauftragstypen (
ordtyp) in Betracht ziehen. Sie möchten zum Beispiel nur ausgehende Kundenaufträge oder eingehende Bestellungen analysieren. Dies kann der WHERE-Klausel in den relevanten Abschnitten des Skripts hinzugefügt werden. - Performance-Überlegungen: Das Extraktionsskript verbindet und vereinigt mehrere große Tabellen. Um die Systemleistung nicht zu beeinträchtigen, planen Sie die Extraktion für Stunden außerhalb der Spitzenzeiten. Die Extraktion von Daten in kleineren, inkrementellen Batches (z.B. ein Monat auf einmal) ist eine sichere Strategie für sehr große Umgebungen.
- Voraussetzungen: Der Benutzer, der das Skript ausführt, muss Lesezugriffsrechte für alle in der Abfrage referenzierten Tabellen haben, einschließlich
ord_hdr,ord_dtl,invmov,pckwrk_dtl,asnhdrundtrn_log. Der Benutzer muss außerdem berechtigt sein, MOCA-Befehle auszuführen.
a Beispielabfrage config
publish data
where wh_id = '[Your Warehouse ID]'
and event_time between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
|
[
/* 1. Warehouse Order Created */
select
ordnum as WarehouseOrder,
'Warehouse Order Created' as ActivityName,
adddte as EventStartTime,
moddte as EventEndTime,
add_usr_id as UserOperatorId,
ordqty as PlannedQuantity,
null as ActualQuantity,
null as StorageLocation,
req_ship_dte as RequestedCompletionDate,
prifld as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from ord_hdr
where ordtyp in ('ORD', 'INB')
and adddte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 2. Inbound Delivery Notified */
select
supnum as WarehouseOrder, /* ASN number often used as the order key for inbound */
'Inbound Delivery Notified' as ActivityName,
adddte as EventStartTime,
moddte as EventEndTime,
add_usr_id as UserOperatorId,
null as PlannedQuantity,
null as ActualQuantity,
null as StorageLocation,
expdte as RequestedCompletionDate,
null as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from asnhdr
where adddte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 3. Goods Arrived at Dock */
select
refnum as WarehouseOrder,
'Goods Arrived at Dock' as ActivityName,
cmpl_dte as EventStartTime,
cmpl_dte as EventEndTime,
mod_usr_id as UserOperatorId,
null as PlannedQuantity,
null as ActualQuantity,
dstloc as StorageLocation, /* Typically a receiving dock location */
null as RequestedCompletionDate,
null as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from trn_log
where trncod = 'RCV_ARVL'
and cmpl_dte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 4. Goods Received and Counted */
select
ordnum as WarehouseOrder,
'Goods Received and Counted' as ActivityName,
cmpl_dte as EventStartTime,
cmpl_dte as EventEndTime,
mod_usr_id as UserOperatorId,
untqty as PlannedQuantity,
actqty as ActualQuantity,
srcloc as StorageLocation,
null as RequestedCompletionDate,
null as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from invmov
where trntyp = 'R' /* Standard receipt transaction type */
and cmpl_dte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 5. Quality Inspection Performed */
select
ordnum as WarehouseOrder,
'Quality Inspection Performed' as ActivityName,
cmpl_dte as EventStartTime,
cmpl_dte as EventEndTime,
mod_usr_id as UserOperatorId,
untqty as PlannedQuantity,
actqty as ActualQuantity,
srcloc as StorageLocation,
null as RequestedCompletionDate,
null as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from invmov
where trntyp = 'H' and trncod = 'QA_CMP' /* Example transaction for QA Hold Release/Complete */
and cmpl_dte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 6. Putaway Task Created */
select
ordnum as WarehouseOrder,
'Putaway Task Created' as ActivityName,
adddte as EventStartTime,
moddte as EventEndTime,
add_usr_id as UserOperatorId,
pckqty as PlannedQuantity,
null as ActualQuantity,
srcloc as StorageLocation,
null as RequestedCompletionDate,
prifld as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from pckwrk_dtl
where wrktyp = 'P' /* Putaway work type */
and adddte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 7. Goods Put Away in Storage */
select
ordnum as WarehouseOrder,
'Goods Put Away in Storage' as ActivityName,
cmpl_dte as EventStartTime,
cmpl_dte as EventEndTime,
mod_usr_id as UserOperatorId,
untqty as PlannedQuantity,
actqty as ActualQuantity,
dstloc as StorageLocation,
null as RequestedCompletionDate,
null as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from invmov
where trntyp = 'M' and trncod = 'PUTAWAY' /* Move transaction for putaway */
and cmpl_dte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 8. Picking Task Created */
select
ordnum as WarehouseOrder,
'Picking Task Created' as ActivityName,
adddte as EventStartTime,
moddte as EventEndTime,
add_usr_id as UserOperatorId,
pckqty as PlannedQuantity,
null as ActualQuantity,
srcloc as StorageLocation,
null as RequestedCompletionDate,
prifld as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from pckwrk_dtl
where wrktyp = 'O' /* Outbound Picking work type */
and adddte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 9. Goods Picked from Storage */
select
ordnum as WarehouseOrder,
'Goods Picked from Storage' as ActivityName,
pk_end_dte as EventStartTime,
pk_end_dte as EventEndTime,
pckr_id as UserOperatorId,
pckqty as PlannedQuantity,
actqty as ActualQuantity,
srcloc as StorageLocation,
null as RequestedCompletionDate,
prifld as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from pckwrk_dtl
where wrktyp = 'O'
and statcod = 'P' /* Status 'Picked' */
and pk_end_dte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 10. Packing Initiated */
select
ordnum as WarehouseOrder,
'Packing Initiated' as ActivityName,
cmpl_dte as EventStartTime,
cmpl_dte as EventEndTime,
mod_usr_id as UserOperatorId,
null as PlannedQuantity,
null as ActualQuantity,
dstloc as StorageLocation, /* Packing station */
null as RequestedCompletionDate,
null as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from trn_log
where trncod = 'PACK_INIT'
and cmpl_dte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 11. Goods Packed */
select
ordnum as WarehouseOrder,
'Goods Packed' as ActivityName,
moddte as EventStartTime,
moddte as EventEndTime,
mod_usr_id as UserOperatorId,
null as PlannedQuantity,
null as ActualQuantity,
null as StorageLocation,
req_ship_dte as RequestedCompletionDate,
prifld as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from ord_hdr
where statcod >= 80 and statcod < 90 /* Example status range for Packed */
and moddte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 12. Staging for Shipment */
select
ordnum as WarehouseOrder,
'Staging for Shipment' as ActivityName,
cmpl_dte as EventStartTime,
cmpl_dte as EventEndTime,
mod_usr_id as UserOperatorId,
untqty as PlannedQuantity,
actqty as ActualQuantity,
dstloc as StorageLocation, /* Staging lane */
null as RequestedCompletionDate,
null as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from invmov
where trncod = 'STG_MOVE' /* Move to staging transaction */
and cmpl_dte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 13. Shipment Dispatched */
select
ordnum as WarehouseOrder,
'Shipment Dispatched' as ActivityName,
act_ship_dte as EventStartTime,
act_ship_dte as EventEndTime,
mod_usr_id as UserOperatorId,
ordqty as PlannedQuantity,
shpqty as ActualQuantity,
null as StorageLocation,
req_ship_dte as RequestedCompletionDate,
prifld as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from ord_hdr
where statcod = 90 /* Status Shipped */
and act_ship_dte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 14. Warehouse Order Completed */
select
ordnum as WarehouseOrder,
'Warehouse Order Completed' as ActivityName,
moddte as EventStartTime,
moddte as EventEndTime,
mod_usr_id as UserOperatorId,
ordqty as PlannedQuantity,
shpqty as ActualQuantity,
null as StorageLocation,
req_ship_dte as RequestedCompletionDate,
prifld as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from ord_hdr
where statcod = 99 /* Status Completed/Closed */
and moddte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 15. Warehouse Order Canceled */
select
ordnum as WarehouseOrder,
'Warehouse Order Canceled' as ActivityName,
moddte as EventStartTime,
moddte as EventEndTime,
mod_usr_id as UserOperatorId,
ordqty as PlannedQuantity,
null as ActualQuantity,
null as StorageLocation,
req_ship_dte as RequestedCompletionDate,
prifld as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from ord_hdr
where statcod = 91 /* Example Canceled status */
and moddte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
]Schritte
- Datenbankverbindung herstellen: Besorgen Sie sich schreibgeschützte Anmeldeinformationen und Verbindungsdetails (Serveradresse, Datenbankname, Port) für die zugrunde liegende Blue Yonder WMS-Datenbank, die typischerweise Oracle oder SQL Server ist. Verwenden Sie einen Standard-SQL-Client wie DBeaver, Oracle SQL Developer oder SQL Server Management Studio zur Verbindung.
- Kern-WMS-Tabellen identifizieren: Die bereitgestellte Abfrage stützt sich auf Standard-Blue Yonder WMS-Tabellen wie
ord(Bestellungen),pckwrk(Kommissionierarbeit),wrkque(Arbeitsschlange),invmov(Bestandsbewegungen) undlodhdr(Lade-Header). Überprüfen Sie diese Tabellennamen und Spaltenstrukturen mit dem Datenwörterbuch Ihres Systems, da Anpassungen vorhanden sein können. - SQL-Abfrage überprüfen und parametrieren: Kopieren Sie das bereitgestellte SQL-Skript in Ihren SQL-Client. Suchen Sie die Platzhaltervariablen innerhalb des
BaseOrdersCommon Table Expression (CTE) am Anfang des Skripts. - Datumsbereich festlegen: Ändern Sie die Klauseln
adddte >= 'JJJJ-MM-TT'undadddte < 'JJJJ-MM-TT', um das Zeitfenster für die Datenextraktion zu definieren. Ein Zeitraum von 3 bis 6 Monaten wird für die erste Analyse empfohlen. - Systemspezifische Filter anwenden: Passen Sie den Filter
wh_id = '[Ihre_Lager-ID]'an, um die Extraktion auf ein bestimmtes Lager zu begrenzen. Fügen Sie bei Bedarf weitere Filter hinzu oder ändern Sie diese, z.B.client_idfür Multi-Client-Umgebungen. - Extraktionsskript ausführen: Führen Sie das vollständige SQL-Skript aus. Die Abfrage wurde entwickelt, um Ereignisse aus mehreren Tabellen in einem einzigen, vereinheitlichten Event Log-Format zu konsolidieren. Die Ausführungszeit variiert je nach Datumsbereich und Datenvolumen.
- Erste Ergebnisse validieren: Nach Abschluss der Abfrage überprüfen Sie kurz die Ausgabe. Prüfen Sie, ob die Spalten
WarehouseOrder,ActivityNameundEventStartTimewie erwartet gefüllt sind. Die Anzahl der Zeilen sollte deutlich größer sein als die Anzahl der eindeutigen Lageraufträge. - Event Log exportieren: Exportieren Sie die Abfrageergebnisse in eine CSV-Datei. Stellen Sie sicher, dass die Dateikodierung auf UTF-8 eingestellt ist, um Zeichenkodierungsprobleme beim Upload zu vermeiden.
- Für den Upload vorbereiten: Bestätigen Sie, dass die Spaltenüberschriften in der exportierten CSV-Datei mit den erforderlichen Attributen übereinstimmen, z.B.
WarehouseOrder,ActivityName,EventStartTime. Die Datei ist nun bereit für den Upload in die Process Mining-Software.
Konfiguration
- Voraussetzungen: Sie müssen über schreibgeschützten SQL-Zugriff auf die Blue Yonder WMS-Datenbank verfügen. Vertrautheit mit der spezifischen WMS-Konfiguration und dem Datenmodell Ihres Unternehmens ist äußerst vorteilhaft.
- Datenbankverbindung: Diese Methode erfordert eine direkte Datenbankkonnektivität. Stellen Sie sicher, dass alle notwendigen Firewall-Regeln oder Netzwerkzugriffsberechtigungen vorhanden sind, bevor Sie beginnen.
- Filterung nach Datumsbereich: Es ist entscheidend, einen spezifischen Datumsbereich in der
WHERE-Klausel der Abfrage festzulegen, um das Datenvolumen zu steuern. Ein Zeitraum von 3 bis 6 Monaten ist typischerweise ausreichend für eine aussagekräftige Analyse, ohne die Datenbank übermäßig zu belasten. - Filterung nach Lager und Client: In Umgebungen mit mehreren Lagern oder Clients filtern Sie immer nach der spezifischen
wh_id(Lager-ID) undclient_id(Client-ID), um sicherzustellen, dass die Analyse fokussiert und der Datensatz überschaubar ist. - Performance-Überlegungen: Die Ausführung dieser Abfrage auf einer aktiven Produktionsdatenbank kann die Systemleistung beeinträchtigen. Es wird dringend empfohlen, sie außerhalb der Spitzenzeiten oder, falls verfügbar, vorzugsweise gegen eine dedizierte Berichts- oder replizierte Datenbank auszuführen.
- Systemanpassungen: Die bereitgestellte Abfrage verwendet Standard-Tabellen- und Spaltennamen. Seien Sie darauf vorbereitet, diese Namen basierend auf Anpassungen oder Versionsunterschieden in Ihrer Blue Yonder WMS-Instanz anzupassen. Konsultieren Sie Ihren internen WMS-Administrator oder das Datenwörterbuch für Anleitungen.
a Beispielabfrage sql
WITH BaseOrders AS (
SELECT
ordnum AS WarehouseOrder
FROM
ord
WHERE
adddte >= '2023-01-01' -- Placeholder: Set your start date
AND adddte < '2023-07-01' -- Placeholder: Set your end date
AND wh_id = '[Your_Warehouse_ID]' -- Placeholder: Set your warehouse ID
)
-- 1. Warehouse Order Created
SELECT
o.ordnum AS WarehouseOrder,
'Warehouse Order Created' AS ActivityName,
o.adddte AS EventStartTime,
o.adddte AS EventEndTime,
o.add_usr_id AS UserOperatorId,
o.req_shp_dte AS RequestedCompletionDate,
o.prirty AS PriorityLevel,
CAST(o.ordqty AS DECIMAL(18, 4)) AS PlannedQuantity,
NULL AS ActualQuantity,
NULL AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM ord o
WHERE o.ordnum IN (SELECT WarehouseOrder FROM BaseOrders)
UNION ALL
-- 2. Inbound Delivery Notified (ASN Received)
SELECT
a.ordnum AS WarehouseOrder,
'Inbound Delivery Notified' AS ActivityName,
a.adddte AS EventStartTime,
a.adddte AS EventEndTime,
a.add_usr_id AS UserOperatorId,
a.exp_arv_dte AS RequestedCompletionDate,
NULL AS PriorityLevel,
CAST(ad.qtyord AS DECIMAL(18, 4)) AS PlannedQuantity,
NULL AS ActualQuantity,
NULL AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM asnhdr a
JOIN asndtl ad ON a.asnhdr_id = ad.asnhdr_id
WHERE a.ordnum IN (SELECT WarehouseOrder FROM BaseOrders)
UNION ALL
-- 3. Goods Arrived at Dock
SELECT
t.ordnum AS WarehouseOrder,
'Goods Arrived at Dock' AS ActivityName,
t.checkin_dte AS EventStartTime,
t.checkin_dte AS EventEndTime,
t.usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
NULL AS PriorityLevel,
NULL AS PlannedQuantity,
NULL AS ActualQuantity,
t.dock_loc AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM trk_log t -- Note: Yard management table may vary
WHERE t.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND t.checkin_dte IS NOT NULL
UNION ALL
-- 4. Goods Received and Counted
SELECT
i.ordnum AS WarehouseOrder,
'Goods Received and Counted' AS ActivityName,
i.moddte AS EventStartTime,
i.moddte AS EventEndTime,
i.mod_usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
NULL AS PriorityLevel,
CAST(i.qtyexp AS DECIMAL(18, 4)) AS PlannedQuantity,
CAST(i.qtyrcv AS DECIMAL(18, 4)) AS ActualQuantity,
i.inv_loc AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM rcvlin i -- Receiving Line table
WHERE i.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND i.qtyrcv > 0
UNION ALL
-- 5. Quality Inspection Performed
SELECT
q.ordnum AS WarehouseOrder,
'Quality Inspection Performed' AS ActivityName,
q.insp_dte AS EventStartTime,
q.insp_dte AS EventEndTime,
q.usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
NULL AS PriorityLevel,
CAST(q.insp_qty AS DECIMAL(18, 4)) AS PlannedQuantity,
CAST(q.act_qty AS DECIMAL(18, 4)) AS ActualQuantity,
q.stoloc AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM qc_log q -- Quality Control log table may vary
WHERE q.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND q.status = 'COMPLETED'
UNION ALL
-- 6. Putaway Task Created
SELECT
w.ordnum AS WarehouseOrder,
'Putaway Task Created' AS ActivityName,
w.adddte AS EventStartTime,
NULL AS EventEndTime,
w.add_usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
w.wrkprt AS PriorityLevel,
CAST(w.untqty AS DECIMAL(18, 4)) AS PlannedQuantity,
NULL AS ActualQuantity,
w.frmloc AS StorageLocation, -- From receiving dock
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM wrkque w
WHERE w.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND w.wrktyp = 'PUTAWAY'
UNION ALL
-- 7. Goods Put Away in Storage
SELECT
m.ordnum AS WarehouseOrder,
'Goods Put Away in Storage' AS ActivityName,
m.adddte AS EventStartTime,
m.adddte AS EventEndTime,
m.usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
NULL AS PriorityLevel,
NULL AS PlannedQuantity,
CAST(m.movqty AS DECIMAL(18, 4)) AS ActualQuantity,
m.toloc AS StorageLocation, -- Destination storage location
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM invmov m -- Inventory Movement table
WHERE m.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND m.trntyp = 'PUTFIN' -- Putaway Finish transaction type
UNION ALL
-- 8. Picking Task Created
SELECT
w.ordnum AS WarehouseOrder,
'Picking Task Created' AS ActivityName,
w.adddte AS EventStartTime,
NULL AS EventEndTime,
w.add_usr_id AS UserOperatorId,
o.req_shp_dte AS RequestedCompletionDate,
w.wrkprt AS PriorityLevel,
CAST(w.untqty AS DECIMAL(18, 4)) AS PlannedQuantity,
NULL AS ActualQuantity,
w.frmloc AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM wrkque w
JOIN ord o ON w.ordnum = o.ordnum
WHERE w.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND w.wrktyp = 'PICK'
UNION ALL
-- 9. Goods Picked from Storage
SELECT
p.ordnum AS WarehouseOrder,
'Goods Picked from Storage' AS ActivityName,
p.moddte AS EventStartTime,
p.moddte AS EventEndTime,
p.mod_usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
NULL AS PriorityLevel,
CAST(p.pckqty AS DECIMAL(18, 4)) AS PlannedQuantity, -- Often planned and actual are the same here
CAST(p.pckqty AS DECIMAL(18, 4)) AS ActualQuantity,
p.pckloc AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM pckwrk p
WHERE p.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND p.wrksts = 'C' -- Status for Completed Pick
UNION ALL
-- 10. Packing Initiated
SELECT
s.ordnum AS WarehouseOrder,
'Packing Initiated' AS ActivityName,
s.moddte AS EventStartTime,
NULL AS EventEndTime,
s.mod_usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
NULL AS PriorityLevel,
NULL AS PlannedQuantity,
NULL AS ActualQuantity,
s.pckstn AS StorageLocation, -- Packing Station
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM ord_status_log s -- Status log table may vary
WHERE s.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND s.ordsta = 'PCK_START'
UNION ALL
-- 11. Goods Packed
SELECT
c.ordnum AS WarehouseOrder,
'Goods Packed' AS ActivityName,
c.moddte AS EventStartTime,
c.moddte AS EventEndTime,
c.mod_usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
NULL AS PriorityLevel,
NULL AS PlannedQuantity,
CAST(c.actqty AS DECIMAL(18, 4)) AS ActualQuantity,
c.pckstn AS StorageLocation, -- Packing Station
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM ship_cntr c -- Shipping Container table
WHERE c.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND c.cntr_sts = 'PACKED'
UNION ALL
-- 12. Staging for Shipment
SELECT
m.ordnum AS WarehouseOrder,
'Staging for Shipment' AS ActivityName,
m.adddte AS EventStartTime,
m.adddte AS EventEndTime,
m.usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
NULL AS PriorityLevel,
NULL AS PlannedQuantity,
CAST(m.movqty AS DECIMAL(18, 4)) AS ActualQuantity,
m.toloc AS StorageLocation, -- Staging location
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM invmov m
WHERE m.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND m.trntyp = 'STAGEMOV' -- Staging Movement transaction type
UNION ALL
-- 13. Shipment Dispatched
SELECT
l.ordnum AS WarehouseOrder,
'Shipment Dispatched' AS ActivityName,
l.shp_dte AS EventStartTime,
l.shp_dte AS EventEndTime,
l.mod_usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
NULL AS PriorityLevel,
NULL AS PlannedQuantity,
CAST(sl.shpqty AS DECIMAL(18, 4)) AS ActualQuantity,
l.wh_id AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM lodhdr l
JOIN ship_line sl ON l.lodnum = sl.lodnum
WHERE l.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND l.lodsts = 'S' -- Shipped status
UNION ALL
-- 14. Warehouse Order Completed
SELECT
o.ordnum AS WarehouseOrder,
'Warehouse Order Completed' AS ActivityName,
o.moddte AS EventStartTime,
o.moddte AS EventEndTime,
o.mod_usr_id AS UserOperatorId,
o.req_shp_dte AS RequestedCompletionDate,
o.prirty AS PriorityLevel,
CAST(o.ordqty AS DECIMAL(18, 4)) AS PlannedQuantity,
CAST(o.shpqty AS DECIMAL(18, 4)) AS ActualQuantity,
NULL AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM ord o
WHERE o.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND o.ordsta = 'C' -- Status for Completed
UNION ALL
-- 15. Warehouse Order Canceled
SELECT
o.ordnum AS WarehouseOrder,
'Warehouse Order Canceled' AS ActivityName,
o.moddte AS EventStartTime,
o.moddte AS EventEndTime,
o.mod_usr_id AS UserOperatorId,
o.req_shp_dte AS RequestedCompletionDate,
o.prirty AS PriorityLevel,
CAST(o.ordqty AS DECIMAL(18, 4)) AS PlannedQuantity,
NULL AS ActualQuantity,
NULL AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM ord o
WHERE o.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND o.ordsta = 'X'; -- Status for Canceled