Daten-Template: Auftragseingang bis Zahlungseingang – Verkaufsauftragsbearbeitung
Ihr Order-to-Cash – Daten-Template für die Vertriebsauftragsabwicklung
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Verfolgung
- Extraktionsanleitung für SAP ECC
Order to Cash - Kundenauftragsabwicklung Attribute
| Name | Beschreibung | ||
|---|---|---|---|
Kundenauftrag SalesOrder | Der eindeutige Identifikator für ein Kundenauftragsdokument, der als primärer Case zur Verfolgung des gesamten Order-to-Cash-Prozesses dient. | ||
Beschreibung Der Kundenauftrag ist das zentrale Dokument im Verkaufsprozess, das die Anfrage eines Kunden nach Waren oder Dienstleistungen darstellt. Er enthält alle Informationen, die zur vollständigen Bearbeitung der Kundenanfrage erforderlich sind. Im Process Mining wird dieses Attribut als Case ID verwendet. Jede eindeutige Kundenauftragsnummer repräsentiert eine End-to-End-Prozessinstanz. Die Analyse von Prozessen nach Kundenauftrag ermöglicht die Verfolgung des vollständigen Lebenszyklus, die Messung von Durchlaufzeiten (Cycle Times) und die Identifizierung von Abweichungen für jeden einzelnen Kundenauftrag. Warum es wichtig ist Es ist der entscheidende Schlüssel, um alle verbundenen Activities und Events zu verknüpfen und so eine vollständige End-to-End-Analyse des Verlaufs jedes Kundenauftrags zu ermöglichen. Woher erhalten Gefunden in der Tabelle für Verkaufsbelegkopfdaten (VBAK) als Feld VBELN. Beispiele 900001234590000123469000012347 | |||
Aktivität Activity | Der Name eines spezifischen Geschäftsschritts oder Events, das innerhalb des Kundenauftragsprozesses aufgetreten ist. | ||
Beschreibung Dieses Attribut beschreibt einen einzelnen Schritt im Order-to-Cash-Prozess, wie zum Beispiel 'Kundenauftrag erstellt', 'Lieferung erstellt' oder 'Zahlung erhalten'. Diese Aktivitäten sind die Bausteine, die verwendet werden, um den Prozessfluss für jeden Kundenauftrag zu rekonstruieren.\n\nDie Analyse der Sequenz und der zeitlichen Abfolge dieser Aktivitäten ist der Kern von Process Mining. Sie hilft, die Prozesslandkarte zu visualisieren, Engpässe zu identifizieren, Prozessvarianten aufzudecken und die Compliance mit einem Standardmodell zu überprüfen. Aktivitäten werden typischerweise aus einer Kombination von Belegerstellungs-Events, Statusänderungen oder spezifischen, im System erfassten Transaktionscodes abgeleitet. Warum es wichtig ist Aktivitäten bilden das Rückgrat der Prozesslandkarte und ermöglichen die Visualisierung und Analyse des Prozessflusses sowie von Abweichungen und Engpässen. Woher erhalten Dies ist ein abgeleitetes Attribut, das typischerweise während der Datenextraktion durch die Abbildung von SAP-Transaktionscodes (T-Codes), Dokumentstatusänderungen (z.B. aus Tabellen wie VBUK, VBUP) oder Änderungsbelegprotokollen (Tabellen CDHDR, CDPOS) auf benutzerfreundliche Aktivitätennamen generiert wird. Beispiele Kundenauftrag erstelltLieferung erstelltWarenausgangRechnung erstelltZahlung erhalten | |||
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 Datenextraktion oder Aktualisierung für ein bestimmtes Event oder einen Case. Es bietet Transparenz über die Aktualität der analysierten Daten.\n\nIn Dashboards und Berichten ist diese Information entscheidend, damit Benutzer die Aktualität der Erkenntnisse verstehen. Sie hilft zu bestätigen, ob die Analyse den aktuellsten Stand der Vorgänge widerspiegelt oder auf älteren Daten basiert, und hilft, die Erwartungen der Benutzer an die Aktualität der Daten zu managen. Warum es wichtig ist Stellt sicher, dass Benutzer über die Aktualität der Daten informiert sind, was entscheidend ist, um zeitnahe und fundierte Entscheidungen basierend auf der Process Mining-Analyse zu treffen. Woher erhalten Dies ist ein Metadaten-Attribut, das vom Datenextraktions-Tool oder -Prozess zum Zeitpunkt der Datenerfassung befüllt wird. Es ist nicht in den Quell-SAP-Tabellen gespeichert. Beispiele 2024-06-10T05:00:00Z2024-06-11T05:00:00Z2024-06-12T05:00:00Z | |||
Quellsystem SourceSystem | Identifiziert das Quellsystem, aus dem die Daten extrahiert wurden. | ||
Beschreibung Dieses Attribut gibt das Ursprungssystem an, zum Beispiel einen spezifischen SAP-ECC-Instanznamen oder eine Mandantennummer. Es liefert Kontext für die Daten, insbesondere in Umgebungen mit mehreren Produktionssystemen oder Daten aus Altsystemen.\n\nIn der Analyse wird es verwendet, um Daten anhand ihres Ursprungs zu filtern oder zu segmentieren. Dies ist besonders nützlich, um Prozesse über verschiedene Systeme hinweg zu vergleichen oder bei Systemmigrationsprojekten die Datenintegrität und Konsistenz zu gewährleisten. Warum es wichtig ist Bietet wesentlichen Kontext, insbesondere in Multi-System-Landschaften, ermöglicht den Prozessvergleich und stellt eine klare Datenherkunft sicher. Woher erhalten Dieser Wert wird typischerweise während des Datenextraktionsprozesses hinzugefügt und ist oft ein statischer Wert, der die SAP-System-ID (SAPSID) oder den Mandanten (MANDT) darstellt. Beispiele ECC_PROD_800SAP_ERP_EU1ECC_QAS_300 | |||
Startzeit StartTime | Der Timestamp, der anzeigt, wann eine Aktivität oder ein Event begann. | ||
Beschreibung Der Startzeitpunkt, auch bekannt als Event Timestamp, zeichnet das präzise Datum und die Uhrzeit auf, zu der eine spezifische Aktivität stattgefunden hat. Zum Beispiel würde er erfassen, wann ein Kundenauftrag erstellt, Waren ausgeliefert oder eine Rechnung gebucht wurde. Dieser Timestamp ist grundlegend für alle zeitbasierten Analysen im Process Mining. Er wird verwendet, um Durchlaufzeiten (Cycle Times) zwischen Aktivitäten zu berechnen, die Gesamtdauer eines Case zu messen und Verzögerungen oder Bottlenecks zu identifizieren. Genaue Timestamps sind entscheidend für Performance-Analyse-Dashboards, wie z.B. jene, die die pünktliche Lieferung oder Durchlaufzeiten überwachen. Warum es wichtig ist Dies ist ein kritisches Attribut zur Berechnung aller Performance-Kennzahlen, wie Durchlaufzeiten und Dauern, die für die Identifizierung von Engpässen unerlässlich sind. Woher erhalten Dies ist ein zusammengesetztes Attribut, das typischerweise durch die Kombination eines Datumsfeldes (z.B. ERDAT) und eines Zeitfeldes (z.B. ERZET) aus verschiedenen SAP-Tabellen wie VBAK (Verkaufsauftrag), LIKP (Lieferung) und VBRK (Rechnung) abgeleitet wird. Beispiele 2023-04-15T09:00:12Z2023-04-16T14:30:00Z2023-04-20T11:22:45Z | |||
Ablehnungsgrund RejectionReason | Ein Code, der den Grund angibt, warum eine Verkaufsauftragsposition abgelehnt oder storniert wurde. | ||
Beschreibung Der Ablehnungsgrund liefert den Kontext dafür, warum ein Kundenauftrag oder eine spezifische Position nicht erfüllt wurde. Dies könnte auf Kundenstornierung, Produktnichtverfügbarkeit oder andere geschäftliche Gründe zurückzuführen sein. Dieses Attribut ist wesentlich für das Dashboard zu Kundenauftragsstornierungstrends. Durch die Analyse der häufigsten Ablehnungsgründe kann ein Unternehmen die Ursachen für verlorene Umsätze identifizieren. Diese Erkenntnis kann Verbesserungen im Bestandsmanagement, der Preisstrategie oder der Kundenkommunikation vorantreiben, um die Kundenauftragsstornierungsrate zu reduzieren. Warum es wichtig ist Liefert das 'Warum' hinter Auftragsstornierungen und ermöglicht eine Ursachenanalyse, um verlorene Umsätze zu reduzieren und die Prognosegenauigkeit zu verbessern. Woher erhalten Gefunden in der Tabelle für Verkaufsbelegpositionen (VBAP) als Feld ABGRU. Beispiele 0215Z5 | |||
Benutzer User | Die Benutzer-ID des Mitarbeiters, der das Dokument erstellt oder zuletzt geändert oder die Aktivität durchgeführt hat. | ||
Beschreibung Dieses Attribut erfasst die SAP user ID, die für ein bestimmtes Event im Prozess verantwortlich ist. Es identifiziert beispielsweise den Sachbearbeiter im Vertrieb, der den Auftrag erstellt hat, oder das Lagerpersonal, das den Warenausgang gebucht hat.\n\nDie Analyse des Prozesses nach Benutzer hilft, die Arbeitslastverteilung zu verstehen, Schulungsbedarf zu identifizieren und Unterschiede in der Ausführung derselben Aufgaben durch verschiedene Benutzer zu erkennen. Dies ist essenziell für Dashboards, die sich auf Ressourcenauslastung, Compliance und die Erkennung manueller Eingriffe konzentrieren. Warum es wichtig ist Bietet Transparenz über Ressourcenleistung und Arbeitslast, hilft bei der Identifizierung benutzerspezifischer Prozessabweichungen und ist entscheidend für die Compliance- und Automatisierungsanalyse. Woher erhalten Gefunden in vielen SAP-Kopftabellen als Feld 'Erstellt von' (ERNAM) oder 'Geändert von' (AENAM), wie z. B. in VBAK, LIKP, VBRK. Beispiele CBURKEJSMITHRWILLIAMS | |||
Kundenauftrags-Durchlaufzeit SalesOrderCycleTime | Die Gesamtdauer von der Erstellung des Kundenauftrags bis zu dessen endgültigem Abschluss oder Zahlung. | ||
Beschreibung Diese berechnete Kennzahl misst die End-to-End-Bearbeitungszeit für einen einzelnen Kundenauftrag. Sie wird typischerweise als Differenz zwischen dem Timestamp der allerersten Aktivität ('Kundenauftrag erstellt') und der allerletzten Aktivität (z.B. 'Zahlung erhalten' oder 'Auftragsposition abgeschlossen') berechnet.\n\nDieses Attribut ist die primäre Kennzahl für das Dashboard zur 'End-to-End-Durchlaufzeit von Kundenaufträgen' und den KPI zur 'Durchlaufzeit der Kundenauftragsabwicklung'. Es bietet eine Überblicksansicht der Prozesseffizienz und ist eine kritische Kennzahl zur Identifizierung langlaufender Aufträge und der allgemeinen Prozessgesundheit. Die Analyse der Verteilung dieser Kennzahl hilft, Benchmarks zu setzen und die Auswirkungen von Verbesserungsinitiativen im Laufe der Zeit zu verfolgen. Warum es wichtig ist Dies ist der primäre KPI zur Messung der Gesamtprozessgeschwindigkeit und -effizienz, der eine kritische Grundlage für Verbesserungsinitiativen bietet. Woher erhalten Hierbei handelt es sich um eine berechnete Kennzahl, die aus dem Event Log abgeleitet wird, indem die Differenz zwischen dem maximalen und minimalen Startzeitpunkt für einen bestimmten Verkaufsauftrag ermittelt wird. Beispiele 10 Tage 4 Stunden25 Tage 11 Stunden5 Tage 2 Stunden | |||
Kundennummer CustomerNumber | Der eindeutige Identifikator für den Kunden, der den Kundenauftrag platziert hat. | ||
Beschreibung Dieses Attribut repräsentiert den 'Auftraggeber', das primäre Kundenkonto, das mit dem Kundenauftrag verknüpft ist. Es verbindet die Transaktion mit einem spezifischen Kunden in den Stammdaten.\n\nDie Analyse nach Kundennummer ermöglicht es, den Prozess zu segmentieren, um kundenspezifisches Verhalten und die Leistung zu verstehen. Es hilft, Fragen zu beantworten, wie welche Kunden die längsten Durchlaufzeiten, die höchsten Nacharbeitsquoten oder die häufigsten Auftragsänderungen haben. Dies ist entscheidend für die Verbesserung des Kundenbeziehungsmanagement und der Service-Levels. Warum es wichtig ist Ermöglicht eine kundenorientierte Analyse, die dabei hilft, Prozessprobleme zu identifizieren, die bestimmte Kunden betreffen, und kundenspezifische Leistungen zu messen. Woher erhalten Gefunden in der Tabelle für Verkaufsbelegkopfdaten (VBAK) als Feld KUNNR. Beispiele 100234100567200112 | |||
Liefersperre DeliveryBlock | Ein Code, der angibt, ob ein Verkaufsauftrag für die Lieferung gesperrt ist, was die Erstellung eines Lieferbelegs verhindert. | ||
Beschreibung Die Liefersperre ist ein Status, der für einen Kundenauftrag (auf Kopf- oder Positionsebene) gesetzt wird, um den Prozess vor dem Lieferschritt temporär anzuhalten. Sperren können manuell durch einen Benutzer oder automatisch durch das System gesetzt werden, z. B. aufgrund einer Kreditlimitüberschreitung oder unvollständiger Daten. Dieses Attribut ist entscheidend für das Dashboard zur Analyse von Kundenauftragssperren und Nacharbeit. Die Analyse der Häufigkeit, Dauer und Gründe für Liefersperren hilft, Hauptengpässe im Abwicklungsprozess zu identifizieren. Die Reduzierung dieser Sperren ist entscheidend für die Verbesserung der pünktlichen Lieferung und der gesamten Durchlaufzeit (Cycle Time). Warum es wichtig ist Identifiziert direkt Engpässe im Abwicklungsprozess. Die Analyse, warum und wie oft Aufträge blockiert werden, ist entscheidend für die Verbesserung der Prozesseffizienz. Woher erhalten Gefunden in der Tabelle für Verkaufsbelegkopfdaten (VBAK) als Feld LIFSK. Beispiele 0102Z1 | |||
Materialnummer MaterialNumber | Der eindeutige Identifikator für ein Produkt oder eine Dienstleistung, die verkauft wird. | ||
Beschreibung Die Materialnummer identifiziert den spezifischen Artikel auf einer Kundenauftragsposition. Da ein einzelner Kundenauftrag mehrere Materialien enthalten kann, wird dieses Attribut typischerweise auf Positionsebene analysiert. Die Analyse des Prozesses nach Materialnummer hilft, produktspezifische Probleme aufzudecken. Sie kann aufzeigen, ob bestimmte Produkte mit längeren Erfüllungszeiten, häufigeren Liefersperren oder öfteren Rechnungsabweichungen verbunden sind. Dies ist entscheidend für das Supply Chain und Produktmanagement, um den Prozess für verschiedene Produktlinien zu optimieren. Warum es wichtig ist Ermöglicht eine produktbasierte Prozessanalyse, die aufzeigt, welche Produkte mit Prozessineffizienzen wie Verzögerungen, Blockaden oder Nacharbeiten verbunden sind. Woher erhalten Gefunden in der Tabelle für Verkaufsbelegpositionen (VBAP) als Feld MATNR. Beispiele FG-1001-ARAW-205BSERV-INSTALL | |||
Nettobetrag NetAmount | Der Gesamtwert des Kundenauftrags, ohne Steuern und Rabatte auf Kopfebene. | ||
Beschreibung Nettobetrag repräsentiert den monetären Wert des Kundenauftrags. Es ist eine wichtige Finanzkennzahl, die mit jeder Prozessinstanz verbunden ist. Dieses Attribut ist wesentlich für wertbasiertes Process Mining. Es ermöglicht die Priorisierung von Prozessverbesserungsinitiativen, indem der Fokus auf hochwertige Aufträge gelegt wird. Analysten können Prozessprobleme, wie Verzögerungen oder Nacharbeiten, mit finanziellen Auswirkungen korrelieren, was den Aufbau eines stärkeren Business Case für Veränderungen unterstützt. Zum Beispiel kann damit analysiert werden, ob hochwertige Aufträge effizienter oder weniger effizient als niedrigwertige Aufträge bearbeitet werden. Warum es wichtig ist Ermöglicht eine wertbasierte Analyse, die dabei hilft, Verbesserungsbemühungen bei Aufträgen zu priorisieren, die den größten finanziellen Einfluss auf das Unternehmen haben. Woher erhalten Gefunden in der Tabelle für Verkaufsbelegkopfdaten (VBAK) als Feld NETWR. Beispiele 1500.0012550.75850.50 | |||
Vertriebsorganisation SalesOrganization | Die Organisationseinheit, verantwortlich für den Verkauf von Produkten oder Dienstleistungen. | ||
Beschreibung Eine Vertriebsorganisation ist eine zentrale Organisationseinheit in SAP, die das Unternehmen nach ihren Vertriebsanforderungen strukturiert. Sie ist verantwortlich für die Aushandlung von Verkaufsbedingungen und den Vertrieb von Waren und Dienstleistungen. Im Process Mining ist dieses Attribut eine kritische Dimension für die Analyse. Es ermöglicht den Vergleich von Prozess-Performance, Effizienz und Compliance über verschiedene Vertriebseinheiten, Regionen oder Geschäftsbereiche hinweg. Dies hilft, Best Practices in leistungsstarken Organisationen und Verbesserungsbereiche in anderen zu identifizieren. Warum es wichtig ist Ermöglicht organisatorisches Benchmarking, um die Prozesseffizienz und Compliance über verschiedene Geschäftseinheiten oder Regionen hinweg zu vergleichen. Woher erhalten Gefunden in der Tabelle für Verkaufsbelegkopfdaten (VBAK) als Feld VKORG. Beispiele 100025003100 | |||
Bestätigter Liefertermin ConfirmedDeliveryDate | Das Datum, an dem die Lieferung der Waren oder Dienstleistungen dem Kunden bestätigt wurde. | ||
Beschreibung Dies ist der dem Kunden zugesagte Liefertermin, basierend auf Materialverfügbarkeit und Planung. Er dient als Grundlage für die Messung der Lieferperformance. Dieses Attribut bildet die Grundlage für das Dashboard zur Pünktlichkeitsleistung der Lieferung und den KPI der Pünktlichkeitsrate. Durch den Vergleich des bestätigten Liefertermins mit dem tatsächlichen Warenausgangsdatum kann die Analyse feststellen, ob ein Auftrag pünktlich, zu früh oder zu spät geliefert wurde. Dies ist ein primäres Maß für die Zuverlässigkeit der Lieferkette und die Kundenzufriedenheit. Warum es wichtig ist Dies ist der Referenzwert zur Messung der Pünktlichkeitsleistung der Lieferung, ein kritischer KPI für Kundenzufriedenheit und Effizienz der Lieferkette. Woher erhalten Gefunden in der Tabelle für Verkaufsbeleg-Einplantabelle (VBEP) als Feld EDATU. Beispiele 2023-05-102023-06-202023-07-01 | |||
Ist Nacharbeit IsRework | Ein Boolean Flag, das angibt, ob ein Verkaufsauftrag nach der initialen Erstellung eine signifikante Änderung oder Nachbearbeitungsaktivität durchlaufen hat. | ||
Beschreibung Dieses berechnete Attribut identifiziert Prozessinstanzen, die Nacharbeit erfahren haben, wie zum Beispiel eine oder mehrere Aktivitäten des Typs 'Kundenauftrag geändert'. Die spezifische Logik dafür, was Nacharbeit darstellt – beispielsweise eine Änderung von Preis, Menge oder Lieferdatum – wird während der Projekteinrichtung definiert.\n\nDieses Attribut ist entscheidend für das Dashboard zur 'Häufigkeit der Kundenauftrags-Nacharbeit und -Änderungen' und den KPI zur 'Kundenauftrags-Nacharbeitsrate'. Es vereinfacht die Analyse, indem es eine direkte Filterung und einen Vergleich zwischen Aufträgen ermöglicht, die einen 'direkten Durchlauf' hatten, und solchen, die manuelle Änderungen erforderten. Dies hilft, die Auswirkungen der Nacharbeit auf Durchlaufzeiten und Kosten zu quantifizieren. Warum es wichtig ist Quantifiziert direkt die Häufigkeit von Nacharbeit und ermöglicht so die Analyse ihrer Ursachen sowie deren Auswirkungen auf die gesamte Prozesseffizienz und die Durchlaufzeit. Woher erhalten Dies ist ein berechnetes Attribut, das aus dem Event Log abgeleitet wird. Die Logik prüft das Vorhandensein von Aktivitäten des Typs 'Kundenauftrag geändert' oder spezifischer Änderungsereignisse aus den Tabellen CDHDR/CDPOS. Beispiele truefalsch | |||
Kreditprüfungsstatus CreditCheckStatus | Zeigt den Status der Kreditprüfung für den Verkaufsbeleg an. | ||
Beschreibung Dieses Attribut zeigt das Ergebnis der automatisierten oder manuellen Kreditprüfung eines Kundenauftrags. Gängige Status sind 'Genehmigt', 'Abgelehnt' oder 'Gesperrt'.\n\nDies ist ein Schlüsselattribut für das Dashboard zur 'Analyse der Kreditprüfungslaufzeit'. Verzögerungen oder Sperren in der Kreditprüfungsphase können die gesamte Durchlaufzeit der Auftragsabwicklung erheblich beeinflussen. Die Analyse dieses Status hilft, die Effizienz des Kreditmanagementprozesses und dessen Auswirkungen auf die Verkaufsgeschwindigkeit zu verstehen. Warum es wichtig ist Wirkt sich direkt auf die Bearbeitungsgeschwindigkeit von Aufträgen aus. Die Analyse dieses Status hilft, Engpässe im Kreditmanagement zu identifizieren, die die Auftragsabwicklung verzögern. Woher erhalten Gefunden in der Tabelle für Verkaufsbelegkopfstatus (VBUK) oder direkt in VBAK als Kreditstatusfeld (z. B. CMGST). Beispiele ABD | |||
Pünktliche Lieferung IsOnTimeDelivery | Ein Boolean Flag, das angibt, ob die Waren am oder vor dem bestätigten Lieferdatum versandt wurden. | ||
Beschreibung Dieses berechnete Attribut vergleicht das tatsächliche Warenausgangsdatum mit dem Bestätigtes Lieferdatum für einen Kundenauftrag. Wenn das Warenausgangsdatum am oder vor dem bestätigten Datum liegt, wird es als wahr markiert, anderenfalls als falsch.\n\nDieses Attribut vereinfacht die Erstellung des Dashboards zur 'Pünktlichen Lieferperformance' und die Berechnung des KPI zur 'Pünktlichen Lieferrate'. Es ermöglicht eine einfache Aggregation und Visualisierung der Leistung, ohne dass Datumsvergleiche direkt in jeder Analyse oder jedem Diagramm durchgeführt werden müssen. Dies bietet ein klares, auf einen Blick erkennbares Maß für die Lieferzuverlässigkeit. Warum es wichtig ist Bietet ein klares und einfaches Maß für die Lieferperformance und ermöglicht die einfache Berechnung des gesamten On-Time Delivery Rate KPI. Woher erhalten Dies ist ein berechnetes Attribut. Die Logik vergleicht den Timestamp der Aktivität 'Warenausgang' mit dem Wert aus dem Attribut Bestätigtes Lieferdatum. Beispiele truefalsch | |||
Versandbedingungen ShippingConditions | Definiert die allgemeine Versandstrategie für die Lieferung von Waren an den Kunden. | ||
Beschreibung Die Lieferbedingungen legen fest, wie ein Auftrag versendet wird, zum Beispiel 'Standard', 'Express' oder 'Abholung'. Dies wird mit dem Kunden vereinbart und beeinflusst die Logistikplanung. Dieses Attribut wird in der Analyse 'Effizienz und Kosten der Versandmethode' verwendet. Durch die Segmentierung des Prozesses nach Lieferbedingungen können Unternehmen analysieren, ob bestimmte Methoden anfälliger für Verzögerungen sind oder längere Durchlaufzeiten aufweisen. Diese Daten helfen, die Logistik zu optimieren und Kundenerwartungen hinsichtlich der Lieferzeiten zu managen. Warum es wichtig ist Ermöglicht die Analyse der Logistikleistung und hilft dabei zu bestimmen, ob bestimmte Versandarten mit Verzögerungen oder höherer Effizienz korrelieren. Woher erhalten Gefunden in der Tabelle für Verkaufsbelegkopfdaten (VBAK) als Feld VSBED. Beispiele 011020 | |||
Order to Cash - Kundenauftragsabwicklung Activities
| Aktivität | Beschreibung | ||
|---|---|---|---|
Auftrag bestätigt | Diese Aktivität kennzeichnet, dass der Kundenauftrag alle initialen Prüfungen bestanden hat und zur Abwicklung bestätigt ist. Sie wird typischerweise abgeleitet, wenn der Auftrag nicht mehr gesperrt ist und bestätigte Mengen in seinen Terminpositionen enthält. | ||
Warum es wichtig ist Dies ist ein wichtiger Meilenstein, der die Auftragserfassung von der Ausführung trennt. Er ist der Ausgangspunkt für die Messung von Ausführungs-Durchlaufzeiten und der Pünktlichkeitsleistung der Lieferung. Woher erhalten Kann abgeleitet werden, wenn Einteilungen in VBEP eine bestätigte Menge (BMENG > 0) aufweisen und der Auftrag nicht für die Lieferung gesperrt ist (z.B. VBUK-LIFSK ist leer). Erfassen Abgeleitet aus der Terminpositionsbestätigung (VBEP-BMENG > 0) und der Aufhebung von Sperren auf Kopfebene. Ereignistyp inferred | |||
Auftragsposition geschlossen | Diese Aktivität kennzeichnet den endgültigen Abschluss einer Kundenauftragsposition, was darauf hindeutet, dass sie vollständig geliefert, fakturiert und als abgeschlossen gilt. Dies wird aus dem Gesamtstatus der Position abgeleitet. | ||
Warum es wichtig ist Dient als erfolgreiches Endereignis für den Prozess. Die Analyse des Zeitpunkts, wann Artikel abgeschlossen werden, hilft, die Ende-zu-Ende-Prozessdauer zu verstehen und Aufträge zu identifizieren, die unnötig offen bleiben. Woher erhalten Abgeleitet aus dem Gesamtstatusfeld in der VBUP-Tabelle (Verkaufsbeleg: Positionsstatus) für die Position. Wenn VBUP-GBSTA 'C' (Vollständig bearbeitet) ist, ist die Position abgeschlossen. Erfassen Abgeleitet aus der Änderung des Positionsstatus (VBUP-GBSTA) auf 'C' (Vollständig bearbeitet). Ereignistyp inferred | |||
Kundenauftrag erstellt | Kennzeichnet die Anlage eines neuen Kundenauftragsbelegs. Dies ist ein explizites Event, das erfasst wird, wenn ein Benutzer einen neuen Auftrag speichert, typischerweise über Transaktion VA01 in SAP. | ||
Warum es wichtig ist Dies ist das primäre Start-Event für den Order-to-Cash-Prozess. Die Analyse seines Zeitpunkts ist entscheidend für die Messung der Gesamtdurchlaufzeit und der Auftragseingangsraten. Woher erhalten Erfasst in der VBAK-Tabelle (Sales Document Header Data) unter Verwendung des Erstellungsdatums (ERDAT) und der Uhrzeit (ERZET). Der Transaktionscode ist in VBAK-TCODE gespeichert. Erfassen Ereignis basierend auf Erstellungs-Timestamp (ERDAT, ERZET) in der VBAK-Tabelle. Ereignistyp explicit | |||
Rechnung erstellt | Kennzeichnet die Anlage der Kundenrechnung oder des Fakturabelegs. Dies ist ein explizites Event, das ein neues Dokument im System generiert und den Zahlungsteil des Prozesses initiiert. | ||
Warum es wichtig ist Dies ist ein entscheidender Meilenstein, der die Messung der Rechnung-zu-Zahlung-Durchlaufzeit startet. Verzögerungen bei der Rechnungsstellung wirken sich direkt auf den Cashflow aus. Woher erhalten Erfasst in der VBRK-Tabelle (Billing Document: Header Data) basierend auf ihrem Erstellungsdatum (ERDAT). Die Verknüpfung zum Kundenauftrag oder zur Lieferung befindet sich in der VBFA-Tabelle. Erfassen Ereignis basierend auf Erstellungs-Timestamp (ERDAT) in der VBRK-Tabelle. Ereignistyp explicit | |||
Warenausgang | Ein kritisches Event, bei dem das Eigentum an den Waren übergeht und diese das Lager offiziell verlassen. Dies ist eine explizite Finanzbuchung, die einen Materialbeleg erzeugt und den Bestand aktualisiert. | ||
Warum es wichtig ist Dies ist das Ereignis 'Versand' und ein wichtiger Meilenstein zur Messung der Pünktlichkeit der Lieferung und der Ausführungs-Durchlaufzeiten. Es löst Finanzaktualisierungen aus und ist ein Punkt ohne Wiederkehr im physischen Ausführungsprozess. Woher erhalten Erstellung eines Materialbelegs (MKPF/MSEG) mit einer Warenausgangsbewegungsart (z.B. 601), der mit dem Lieferbeleg verknüpft ist. Erfassen Erstellung eines Materialbelegs (MKPF/MSEG) mit einer Warenausgangsbewegungsart, verknüpft mit der Lieferung. Ereignistyp explicit | |||
Zahlung erhalten | Dieses Event signalisiert, dass die Kundenzahlung eingegangen und auf die Rechnung gebucht wurde, wodurch die offene Forderungsposition ausgeglichen wird. Dies ist ein buchhalterisches Event, abgeleitet aus der Ausbuchung eines Finanzbelegs. | ||
Warum es wichtig ist Dies ist der letzte Schritt zur Cashflow-Realisierung aus dem Verkauf. Es ist der Endpunkt für die Messung der Rechnung-zu-Zahlung-Durchlaufzeit und der Gesamtdurchlaufzeit der Auftragsabwicklung. Woher erhalten Abgeleitet aus den Ausgleichsbeleginformationen in der BSEG-Tabelle für die Kundenposition. Wenn BSEG-AUGBL (Ausgleichsbeleg) und BSEG-AUGDT (Ausgleichsdatum) befüllt sind, ist die Zahlung eingegangen. Erfassen Abgeleitet aus der Befüllung des Ausgleichsdatums (AUGDT) in der Tabelle BSEG für die Forderungsposition. Ereignistyp inferred | |||
Auftrag storniert | Zeigt an, dass ein Verkaufsauftrag vor der Abwicklung storniert wurde. Dies wird typischerweise erfasst, indem ein 'Ablehnungsgrund' auf alle relevanten Positionen des Auftrags angewendet wird. | ||
Warum es wichtig ist Dies ist ein kritischer Fehlerendpunkt, der den KPI für die Auftragsstornierungsrate direkt unterstützt. Das Verständnis, wann und warum Aufträge storniert werden, liefert Einblicke in Probleme des Vertriebsprozesses. Woher erhalten Abgeleitet aus der Befüllung des Feldes VBAP-ABGRU (Ablehnungsgrund) für alle aktiven Positionen eines Kundenauftrags. Das Datum der Änderung ist in CDHDR/CDPOS zu finden. Erfassen Abgeleitet aus der Befüllung des Feldes 'Ablehnungsgrund' (VBAP-ABGRU) bei allen Positionen. Ereignistyp inferred | |||
Kommissionierung abgeschlossen | Bedeutet, dass alle Artikel für die Lieferung physisch aus dem Lager entnommen wurden. Wird Warehouse Management (WM) verwendet, kann dies aus dem Status des Transportauftrags abgeleitet werden. | ||
Warum es wichtig ist Die Analyse der Kommissionierzeit hilft, Lagerabläufe zu optimieren. Verzögerungen hier wirken sich direkt auf den gesamten Lieferzeitrahmen und den Abwicklungszyklus aus. Woher erhalten Abgeleitet aus der Änderung des Kommissionierstatus der Lieferposition in Tabelle LIPS-KOSTA auf 'C' (vollständig kommissioniert). Wenn WM aktiv ist, kann dies aus der Transportauftragsbestätigung (LTAK/LTAP-Tabellen) abgeleitet werden. Erfassen Abgeleitet aus der Änderung des Kommissionierstatus (LIPS-KOSTA) oder der Bestätigung des WM-Transportauftrags. Ereignistyp inferred | |||
Kreditprüfung durchgeführt | Zeigt den Abschluss der automatischen oder manuellen Kreditprüfung für den Kunden im Kundenauftrag an. Dies wird typischerweise aus einer Änderung des gesamten Kreditstatus des Dokuments abgeleitet. | ||
Warum es wichtig ist Die Kreditprüfung ist oft ein kritischer Engpass. Die Messung der benötigten Zeit für diesen Schritt ist wesentlich für die Analyse der Bearbeitungszeit der Kreditprüfung und für die Beschleunigung der Auftragsabwicklung. Woher erhalten Abgeleitet aus den Kreditstatusfeldern in der VBUK-Tabelle (Verkaufsbeleg: Kopfstatus). Eine Änderung von VBUK-CMGST von 'gesperrt' auf 'freigegeben' kennzeichnet diese Activity. Erfassen Abgeleitet aus Änderungen im Gesamtstatusfeld (VBUK-CMGST). Ereignistyp inferred | |||
Kundenauftrag geändert | Stellt eine Änderung dar, die an einem bestehenden Kundenauftrag nach dessen erstmaliger Erfassung vorgenommen wurde. Diese Änderungen werden in dedizierten Änderungslog-Tabellen (CDHDR, CDPOS) erfasst, wenn Felder wie Menge, Preis oder Daten geändert werden. | ||
Warum es wichtig ist Das Nachverfolgen von Änderungen hilft, Nacharbeit, Prozessinstabilität und Probleme mit der Datenqualität zu identifizieren. Eine hohe Häufigkeit von Änderungen kann auf Probleme im ursprünglichen Auftragserfassungsprozess hinweisen, was zu Verzögerungen führt. Woher erhalten Abgerufen aus Änderungsbelegtabellen CDHDR (Kopf) und CDPOS (Position) für OBJECTCLAS = 'VERKBELEG'. Der Timestamp und das geänderte Feld können identifiziert werden. Erfassen Ereignis aus Änderungsbelegtabellen (CDHDR, CDPOS) für Verkaufsbelegobjekte. Ereignistyp explicit | |||
Liefernachweis bestätigt | Diese Aktivität repräsentiert die Bestätigung, dass der Kunde die Waren erhalten hat. Sie wird erfasst, wenn der Liefernachweis im System verbucht wird, wobei oft der Status des Lieferbelegs aktualisiert wird. | ||
Warum es wichtig ist Dieses Event liefert das tatsächliche Lieferdatum, das wesentlich ist, um die 'Pünktliche Lieferrate' genau gegen das zugesagte Datum zu messen. Woher erhalten Abgeleitet aus der Einstellung des Abliefernachweisstatus (VBUK-PODAT) auf 'C' (Bestätigt). Das Bestätigungsdatum wird in VLPOD-PODAT gespeichert. Dies ist nicht immer implementiert. Erfassen Abgeleitet aus der Aktualisierung des POD-Status der Lieferung (VBUK-PODAT) oder dem VLPOD-Tabelleneintrag. Ereignistyp inferred | |||
Liefersperre gesetzt | Stellt eine Aktion dar, bei der eine Liefersperre für den Kundenauftrag gesetzt wird, was die Erstellung eines Lieferbelegs verhindert. Dies kann explizit aus Änderungslogs erfasst oder aus Statustabellen abgeleitet werden. | ||
Warum es wichtig ist Diese Aktivität steht in direktem Zusammenhang mit dem KPI 'Kundenauftragssperrenrate'. Das Identifizieren, warum und wie oft Sperren gesetzt werden, hilft, Gründe für Lieferverzögerungen aufzudecken. Woher erhalten Kann in Änderungsprotokollen (CDHDR/CDPOS) für das Feld VBAK-LIFSK gefunden werden. Alternativ wird es abgeleitet, wenn das Feld VBAK-LIFSK gefüllt wird. Erfassen Ereignis aus Änderungsbelegen für Feld VBAK-LIFSK oder VBAP-LIFSP. Ereignistyp explicit | |||
Lieferung erstellt | Dieses Event kennzeichnet die Erstellung des Auslieferungsbelegs, der die Anweisung an das Lager ist, mit den Kommissionierungs- und Versandaktivitäten zu beginnen. Dies ist ein explizites Event, das aus dem Belegfluss erfasst wird. | ||
Warum es wichtig ist Dies ist der erste Schritt im physischen Ausführungsprozess. Die Zeit zwischen Auftragsbestätigung und Liefererstellung zeigt, wie schnell der Logistikprozess eingeleitet wird. Woher erhalten Die Erstellung eines Datensatzes in der LIKP-Tabelle (SD-Beleg: Lieferbelegkopfdaten). Die Verknüpfung zum Kundenauftrag wird in der Belegflusstabelle VBFA gepflegt. Erfassen Ereignis basierend auf Erstellungs-Timestamp in der LIKP-Tabelle, verknüpft über die VBFA-Tabelle. Ereignistyp explicit | |||
Rechnung storniert | Stellt die Stornierung eines zuvor erstellten Fakturabelegs dar. Dies ist eine explizite Transaktion, die ein neues Stornodokument zur Aufhebung des Originals erstellt. | ||
Warum es wichtig ist Das Nachverfolgen von Rechnungsstornierungen hilft, Probleme mit der Preisgestaltung, Versanddifferenzen oder Datenfehlern zu identifizieren. Dies unterstützt den KPI 'Rechnungsdiskrepanzrate'. Woher erhalten Ein explizites Ereignis, erfasst durch die Erstellung eines Stornorechnungsbelegs (VBRK-VBTYP = 'N' oder 'O'). Die Originalrechnung wird in VBRK-SFAKN referenziert. Erfassen Erstellung eines Stornobelegs in VBRK, der auf die Originalrechnung verweist. Ereignistyp explicit | |||
Extraktionsleitfäden
Schritte
- Programmentwicklung: Verwenden Sie die Transaktion SE38 oder SE80, um ein neues ausführbares ABAP-Programm zu erstellen. Dieses Programm wird die gesamte Extraktionslogik beherbergen.
- Selektionsbild definieren: Erstellen Sie in Ihrem Programm ein Selektionsbild zur Filterung der Daten. Fügen Sie Parameter für das Erstellungsdatum des Verkaufsbelegs (VBAK-ERDAT), die Vertriebsorganisation (VBAK-VKORG) und die Verkaufsbelegart (VBAK-AUART) ein. Dies macht die Extraktion wiederverwendbar und handhabbar.
- Datendeklarationen: Definieren Sie die internen Tabellen und Strukturen, die zur Aufnahme der Daten aus verschiedenen SAP-Tabellen (z.B. VBAK, VBAP, VBFA, CDHDR, CDPOS, VBRK, BSAD) benötigt werden. Definieren Sie außerdem die finale Ausgabestruktur für das Event Log, die den erforderlichen Attributen entspricht.
- Basis-Verkaufsbelege auswählen: Schreiben Sie die initiale SELECT-Anweisung, um Verkaufsbelegköpfe (VBAK) und Positionen (VBAP) basierend auf den Benutzereingaben im Selektionsbild abzurufen. Dies bildet den Kerndatensatz der zu analysierenden Cases.
- 'Erstellungs'-Event extrahieren: Durchlaufen Sie die ausgewählten VBAK-Datensätze. Für jeden Datensatz befüllen Sie die Event Log-Struktur mit der Activity 'Verkaufsauftrag erstellt', unter Verwendung von VBAK-ERDAT und VBAK-ERZET für den StartTime.
- Change Log Events extrahieren: Wählen Sie Datensätze aus CDHDR und CDPOS aus, bei denen der OBJECTCLAS 'VERKBELEG' für die ausgewählten Verkaufsbelege ist. Durchlaufen Sie die Ergebnisse, um spezifische Feldänderungen zu identifizieren. Zum Beispiel weist eine Änderung an VBAK-LIFSK auf einen 'Lieferblock gesetzt' hin, und eine Änderung an VBUK-CMGST auf eine 'Kreditprüfung durchgeführt'. Jede andere relevante Änderung kann als 'Verkaufsauftrag geändert' protokolliert werden.
- Belegflussdaten extrahieren: Fragen Sie für die ausgewählten Verkaufsbelege die Belegflusstabelle (VBFA) ab. Diese Tabelle verknüpft Verkaufsaufträge mit nachfolgenden Belegen wie Lieferungen, Warenbewegungen und Rechnungen. Wählen Sie alle zugehörigen Belege zur weiteren Verarbeitung aus.
- Liefer- und Fulfillment-Events extrahieren: Verwenden Sie die Lieferbelegnummern aus VBFA und fragen Sie LIKP und LIPS nach 'Lieferung erstellt'-Events ab. Fragen Sie MKPF und MSEG nach Warenausgangsbelegen (Bewegungsart '601') ab, um das Event 'Warenausgang' zu erfassen. Wenn Warehouse Management aktiv ist, fragen Sie LTAK und LTAP ab, um die Bestätigungszeit für die letzte Transportauftragsposition zu finden und so 'Kommissionierung abgeschlossen' zu bestimmen. Überprüfen Sie den Lieferkopfstatus VBUK-PODAT für 'Liefernachweis bestätigt'.
- Fakturierungs- und Zahlungs-Events extrahieren: Verwenden Sie die Fakturabelegnummern aus VBFA und fragen Sie VBRK und VBRP ab, um 'Rechnung erstellt' und 'Rechnung storniert' (wenn VBRK-FKSTO = 'X') Events zu erfassen. Um 'Zahlung erhalten' zu finden, verknüpfen Sie die Rechnung aus VBRK mit dem Buchhaltungsbeleg in BKPF und finden Sie dann den Ausgleichsbeleg und das Ausgleichsdatum in BSAD.
- Statusbasierte Events extrahieren: Verwenden Sie die Statustabellen VBUP (Positionsstatus) und VBUK (Kopfstatus), um Geschäfts-Events abzuleiten. Zum Beispiel gilt eine Position als 'Auftragsposition abgeschlossen', wenn VBUP-GBSTA gleich 'C' ist. Ein Auftrag ist 'Auftrag storniert', wenn ein 'Ablehnungsgrund' (VBAP-ABGRU) für alle relevanten Positionen festgelegt ist.
- Konsolidieren und formatieren: Kombinieren Sie alle erfassten Events in einer einzigen finalen internen Tabelle. Stellen Sie sicher, dass alle Attribute (SalesOrder, Activity, StartTime, User, etc.) für jeden Event-Datensatz korrekt gefüllt sind. Fügen Sie die SourceSystem- und LastDataUpdate-Timestamps hinzu.
- Ausgabedatei generieren: Verwenden Sie den Funktionsbaustein GUI_DOWNLOAD oder die Methode cl_gui_frontend_services=>gui_download, um die finale interne Tabelle in eine CSV-Datei auf dem lokalen Rechner des Benutzers zu exportieren. Stellen Sie sicher, dass die Datei mit UTF-8-Kodierung gespeichert wird.
Konfiguration
- Voraussetzungen: ABAP-Entwicklerberechtigungen (z.B. Zugriff auf Transaktion SE38) und Leseberechtigungen für alle erforderlichen SAP-Tabellen, einschließlich VBAK, VBAP, CDHDR, CDPOS, VBFA, LIKP, LIPS, VBRK, VBRP, MKPF, MSEG und BSAD.
- Selektionsparameter: Das Programm muss einen Selektionsbildschirm mit Parametern zur Filterung enthalten. Wichtige Parameter sind:
- Datumsbereich: Ein obligatorischer Datumsbereich für die Vertriebsbelegerstellung (VBAK-ERDAT). Beginnen Sie mit einem aktuellen Zeitraum von 3-6 Monaten, um das Datenvolumen überschaubar zu halten.
- Vertriebsorganisation: Filtern Sie nach VBAK-VKORG, um die Analyse auf spezifische Geschäftseinheiten zu konzentrieren.
- Vertriebsbelegart: Filtern Sie nach VBAK-AUART, um nur relevante Auftragsarten (z.B. Standardaufträge) einzubeziehen und andere (z.B. Angebote, Retouren) auszuschließen.
- Leistungsaspekte: Die Extraktion aus Änderungsbelegtabellen (CDHDR, CDPOS) und dem Belegfluss (VBFA) kann bei großen Datenmengen sehr langsam sein. Das Programm sollte so optimiert werden, dass es Indexfelder in WHERE-Klauseln verwendet. Für sehr große Extraktionen sollte das Programm außerhalb der Spitzenzeiten als Hintergrundjob über die Transaktion SM36 eingeplant werden.
- Änderungsbeleg-Aktivierung: Diese Methode basiert auf der Änderungsbelegfunktionalität von SAP. Stellen Sie sicher, dass die Änderungsbelegprotokollierung für wichtige Datenelemente (z.B. LIFSK, CMGST, ABGRU) aktiviert ist. Dies kann über Transaktion SCDO für das Objekt VERKBELEG überprüft werden.
a Beispielabfrage abap
REPORT Z_O2C_PM_EXTRACTOR.
*&---------------------------------------------------------------------*
*& Data Declarations
*&---------------------------------------------------------------------*
TABLES: vbak.
TYPES: BEGIN OF ty_event_log,
salesorder TYPE vbeln_va,
activity TYPE string,
starttime TYPE string,
sourcesystem TYPE logsys,
lastdataupdate TYPE string,
user TYPE ernam,
customernumber TYPE kunnr,
salesorganization TYPE vkorg,
netamount TYPE netwr,
materialnumber TYPE matnr,
deliveryblock TYPE lifsk,
rejectionreason TYPE abgru,
salesordercycletime TYPE string, " Placeholder for calculation
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log.
DATA: gs_event_log TYPE ty_event_log.
DATA: gv_sysid TYPE logsys.
DATA: gv_last_update TYPE string.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_erdat FOR vbak-erdat OBLIGATORY,
s_vkorg FOR vbak-vkorg,
s_auart FOR vbak-auart.
PARAMETERS: p_file TYPE rlgrap-filename OBLIGATORY DEFAULT 'C:\temp\o2c_event_log.csv'.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
CALL FUNCTION 'OWN_LOGICAL_SYSTEM_GET'
IMPORTING
own_logical_system = gv_sysid.
CONCATENATE sy-datum sy-uzeit INTO gv_last_update.
PERFORM get_base_data.
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*& Form get_base_data
*&---------------------------------------------------------------------*
FORM get_base_data.
TYPES: BEGIN OF ty_order_item,
vbeln TYPE vbeln_va,
posnr TYPE posnr_va,
erdat TYPE erdat,
erzet TYPE erzet,
ernam TYPE ernam,
kunnr TYPE kunnr,
vkorg TYPE vkorg,
netwr TYPE netwr_ak,
matnr TYPE matnr,
lifsk TYPE lifsk,
abgru TYPE abgru,
END OF ty_order_item.
DATA: lt_order_items TYPE TABLE OF ty_order_item.
SELECT h~vbeln i~posnr h~erdat h~erzet h~ernam h~kunnr h~vkorg h~netwr i~matnr h~lifsk i~abgru
INTO TABLE lt_order_items
FROM vbak AS h
INNER JOIN vbap AS i ON h~vbeln = i~vbeln
WHERE h~erdat IN s_erdat
AND h~vkorg IN s_vkorg
AND h~auart IN s_auart.
CHECK sy-subrc = 0.
DATA(lt_vbeln_range) = VALUE rsdsselopt_t(
FOR <fs_item> IN lt_order_items WHERE ( vbeln = <fs_item>-vbeln )
( sign = 'I' option = 'EQ' low = <fs_item>-vbeln ) ).
SORT lt_vbeln_range BY low.
DELETE ADJACENT DUPLICATES FROM lt_vbeln_range COMPARING low.
PERFORM extract_order_created USING lt_order_items.
PERFORM extract_changes USING lt_vbeln_range lt_order_items.
PERFORM extract_doc_flow_events USING lt_vbeln_range lt_order_items.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_order_created
*&---------------------------------------------------------------------*
FORM extract_order_created USING it_order_items TYPE ANY TABLE.
FIELD-SYMBOLS: <fs_item> TYPE any.
DATA: lt_unique_orders TYPE HASHED TABLE OF vbeln_va WITH UNIQUE KEY table_line.
lt_unique_orders = VALUE #( FOR <order> IN it_order_items ( CONV vbeln_va( <order>-vbeln ) ) ).
LOOP AT it_order_items ASSIGNING <fs_item> WHERE table_line IN lt_unique_orders.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_item>-vbeln.
gs_event_log-activity = 'Sales Order Created'.
CONCATENATE <fs_item>-erdat <fs_item>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_item>-ernam.
gs_event_log-customernumber = <fs_item>-kunnr.
gs_event_log-salesorganization = <fs_item>-vkorg.
gs_event_log-netamount = <fs_item>-netwr.
APPEND gs_event_log TO gt_event_log.
DELETE lt_unique_orders WHERE table_line = <fs_item>-vbeln.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_changes
*&---------------------------------------------------------------------*
FORM extract_changes USING it_vbeln_range TYPE rsdsselopt_t it_order_items TYPE ANY TABLE.
DATA: lt_cdhdr TYPE TABLE OF cdhdr,
lt_cdpos TYPE TABLE OF cdpos.
SELECT * INTO TABLE lt_cdhdr FROM cdhdr
WHERE objectclas = 'VERKBELEG'
AND objectid IN it_vbeln_range
AND tcode = 'VA02'.
IF sy-subrc = 0.
SELECT * INTO TABLE lt_cdpos FROM cdpos
FOR ALL ENTRIES IN lt_cdhdr
WHERE objectclas = lt_cdhdr-objectclas
AND objectid = lt_cdhdr-objectid
AND changenr = lt_cdhdr-changenr.
ENDIF.
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
DATA(lv_order_info) = REF #( it_order_items[ vbeln = <fs_cdhdr>-objectid ] ).
IF lv_order_info IS NOT BOUND. CONTINUE. ENDIF.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_cdhdr>-objectid.
gs_event_log-user = <fs_cdhdr>-username.
CONCATENATE <fs_cdhdr>-udate <fs_cdhdr>-utime INTO gs_event_log-starttime.
gs_event_log-customernumber = lv_order_info->kunnr.
gs_event_log-salesorganization = lv_order_info->vkorg.
gs_event_log-netamount = lv_order_info->netwr.
" Generic Change Event
gs_event_log-activity = 'Sales Order Changed'.
APPEND gs_event_log TO gt_event_log.
LOOP AT lt_cdpos ASSIGNING FIELD-SYMBOL(<fs_cdpos>)
WHERE objectclas = <fs_cdhdr>-objectclas
AND objectid = <fs_cdhdr>-objectid
AND changenr = <fs_cdhdr>-changenr.
CASE <fs_cdpos>-fname.
WHEN 'LIFSK'. " Delivery Block
gs_event_log-activity = 'Delivery Block Set'.
gs_event_log-deliveryblock = <fs_cdpos>-value_new.
APPEND gs_event_log TO gt_event_log.
WHEN 'CMGST'. " Credit Status
IF <fs_cdpos>-value_new = 'B'. " B = Credit Check OK
gs_event_log-activity = 'Credit Check Performed'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
WHEN 'ABGRU'. " Rejection Reason
IF <fs_cdpos>-value_new IS NOT INITIAL.
gs_event_log-activity = 'Order Cancelled'.
gs_event_log-rejectionreason = <fs_cdpos>-value_new.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDCASE.
ENDLOOP.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_doc_flow_events
*&---------------------------------------------------------------------*
FORM extract_doc_flow_events USING it_vbeln_range TYPE rsdsselopt_t it_order_items TYPE ANY TABLE.
DATA: lt_vbfa TYPE TABLE OF vbfa,
lt_vbrk TYPE TABLE OF vbrk,
lt_likp TYPE TABLE OF likp,
lt_mseg TYPE TABLE OF mseg,
lt_bsad TYPE TABLE OF bsad,
lt_vbup TYPE TABLE OF vbup.
SELECT * INTO TABLE lt_vbfa FROM vbfa
WHERE vbelv IN it_vbeln_range
AND ( vbtyp_n = 'J' " Delivery
OR vbtyp_n = 'M' " Invoice
OR vbtyp_n = 'N' " Invoice Cancellation
OR vbtyp_n = 'R' ). " Goods Movement
IF lt_vbfa IS INITIAL. RETURN. ENDIF.
SELECT vbeln, erdat, erzet, ernam, fksto, belnr FROM vbrk INTO TABLE lt_vbrk
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbeln
AND ( lt_vbfa-vbtyp_n = 'M' OR lt_vbfa-vbtyp_n = 'N' ).
SELECT vbeln, erdat, erzet, ernam, podat FROM likp INTO TABLE lt_likp
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbeln AND lt_vbfa-vbtyp_n = 'J'.
SELECT mblnr, mjahr, zeile, bwart, budat, cpuzt, usnam FROM mseg INTO TABLE lt_mseg
FOR ALL ENTRIES IN lt_vbfa
WHERE mblnr = lt_vbfa-vbeln AND mjahr = lt_vbfa-mjahr AND zeile = lt_vbfa-posnn AND lt_vbfa-vbtyp_n = 'R' AND bwart = '601'.
SELECT augdt, belnr, gjahr, kunnr FROM bsad INTO TABLE lt_bsad
FOR ALL ENTRIES IN lt_vbrk
WHERE belnr = lt_vbrk-belnr AND gjahr = SUBSTRING( val = lt_vbrk-erdat len = 4 ).
SELECT vbeln, posnr, gbsta FROM vbup INTO TABLE lt_vbup
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbelv AND posnr = lt_vbfa-posnv.
LOOP AT lt_vbfa ASSIGNING FIELD-SYMBOL(<fs_vbfa>).
DATA(lv_order_info) = REF #( it_order_items[ vbeln = <fs_vbfa>-vbelv ] ).
IF lv_order_info IS NOT BOUND. CONTINUE. ENDIF.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_vbfa>-vbelv.
gs_event_log-customernumber = lv_order_info->kunnr.
gs_event_log-salesorganization = lv_order_info->vkorg.
gs_event_log-netamount = lv_order_info->netwr.
gs_event_log-materialnumber = lv_order_info->matnr.
CASE <fs_vbfa>-vbtyp_n.
WHEN 'J'. " Delivery
READ TABLE lt_likp ASSIGNING FIELD-SYMBOL(<fs_likp>) WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0.
gs_event_log-activity = 'Delivery Created'.
CONCATENATE <fs_likp>-erdat <fs_likp>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_likp>-ernam.
APPEND gs_event_log TO gt_event_log.
" Picking Completed - simplified logic, check status
gs_event_log-activity = 'Picking Completed'. APPEND gs_event_log TO gt_event_log.
" POD Confirmed
IF <fs_likp>-podat IS NOT INITIAL.
gs_event_log-activity = 'Proof Of Delivery Confirmed'.
gs_event_log-starttime = <fs_likp>-podat.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
WHEN 'R'. " Goods Issue
READ TABLE lt_mseg ASSIGNING FIELD-SYMBOL(<fs_mseg>) WITH KEY mblnr = <fs_vbfa>-vbeln mjahr = <fs_vbfa>-mjahr zeile = <fs_vbfa>-posnn.
IF sy-subrc = 0.
gs_event_log-activity = 'Goods Issued'.
CONCATENATE <fs_mseg>-budat <fs_mseg>-cpuzt INTO gs_event_log-starttime.
gs_event_log-user = <fs_mseg>-usnam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
WHEN 'M'. " Invoice
READ TABLE lt_vbrk ASSIGNING FIELD-SYMBOL(<fs_vbrk>) WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0.
gs_event_log-activity = 'Invoice Created'.
CONCATENATE <fs_vbrk>-erdat <fs_vbrk>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_vbrk>-ernam.
APPEND gs_event_log TO gt_event_log.
" Payment Received
READ TABLE lt_bsad ASSIGNING FIELD-SYMBOL(<fs_bsad>) WITH KEY belnr = <fs_vbrk>-belnr.
IF sy-subrc = 0 AND <fs_bsad>-augdt IS NOT INITIAL.
gs_event_log-activity = 'Payment Received'.
gs_event_log-starttime = <fs_bsad>-augdt.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
WHEN 'N'. " Invoice Cancellation
READ TABLE lt_vbrk ASSIGNING <fs_vbrk> WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0 AND <fs_vbrk>-fksto = 'X'.
gs_event_log-activity = 'Invoice Cancelled'.
CONCATENATE <fs_vbrk>-erdat <fs_vbrk>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_vbrk>-ernam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDCASE.
ENDLOOP.
" Infer other events from status
LOOP AT lt_vbup ASSIGNING FIELD-SYMBOL(<fs_vbup>).
IF <fs_vbup>-gbsta = 'C'.
DATA(lv_order_info_stat) = REF #( it_order_items[ vbeln = <fs_vbup>-vbeln ] ).
IF lv_order_info_stat IS NOT BOUND. CONTINUE. ENDIF.
gs_event_log-salesorder = <fs_vbup>-vbeln.
gs_event_log-activity = 'Order Item Closed'.
" Timestamp for closed is harder, using current time as placeholder
CONCATENATE sy-datum sy-uzeit INTO gs_event_log-starttime.
gs_event_log-user = sy-uname.
gs_event_log-customernumber = lv_order_info_stat->kunnr.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
" Order Confirmed (Simplified - assumes if not blocked it's confirmed)
LOOP AT it_order_items ASSIGNING FIELD-SYMBOL(<fs_item>).
IF <fs_item>-lifsk IS INITIAL.
gs_event_log-salesorder = <fs_item>-vbeln.
gs_event_log-activity = 'Order Confirmed'.
CONCATENATE <fs_item>-erdat <fs_item>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_item>-ernam.
gs_event_log-customernumber = <fs_item>-kunnr.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form write_output_file
*&---------------------------------------------------------------------*
FORM write_output_file.
DATA: lt_final_output TYPE TABLE OF ty_event_log.
" Add common fields
LOOP AT gt_event_log ASSIGNING FIELD-SYMBOL(<fs_event>).
<fs_event>-sourcesystem = gv_sysid.
<fs_event>-lastdataupdate = gv_last_update.
ENDLOOP.
SORT gt_event_log BY salesorder starttime.
DELETE ADJACENT DUPLICATES FROM gt_event_log COMPARING ALL FIELDS.
lt_final_output = gt_event_log.
DATA: lt_fieldnames TYPE TABLE OF string.
APPEND 'SalesOrder' TO lt_fieldnames.
APPEND 'Activity' TO lt_fieldnames.
APPEND 'StartTime' TO lt_fieldnames.
APPEND 'SourceSystem' TO lt_fieldnames.
APPEND 'LastDataUpdate' TO lt_fieldnames.
APPEND 'User' TO lt_fieldnames.
APPEND 'CustomerNumber' TO lt_fieldnames.
APPEND 'SalesOrganization' TO lt_fieldnames.
APPEND 'NetAmount' TO lt_fieldnames.
APPEND 'MaterialNumber' TO lt_fieldnames.
APPEND 'DeliveryBlock' TO lt_fieldnames.
APPEND 'RejectionReason' TO lt_fieldnames.
APPEND 'SalesOrderCycleTime' TO lt_fieldnames.
DATA(lv_header) = REDUCE string(
INIT s = ''
FOR field IN lt_fieldnames
NEXT s = s && COND #( WHEN s = '' THEN field ELSE |,{ field }| ) ).
DATA: lt_file_content TYPE TABLE OF string.
APPEND lv_header TO lt_file_content.
LOOP AT lt_final_output INTO DATA(ls_output).
DATA(lv_line) = |"{ ls_output-salesorder }","{ ls_output-activity }","{ ls_output-starttime }","{ ls_output-sourcesystem }","{ ls_output-lastdataupdate }","{ ls_output-user }","{ ls_output-customernumber }","{ ls_output-salesorganization }",{ ls_output-netamount },"{ ls_output-materialnumber }","{ ls_output-deliveryblock }","{ ls_output-rejectionreason }","{ ls_output-salesordercycletime }"|.
APPEND lv_line TO lt_file_content.
ENDLOOP.
cl_gui_frontend_services=>gui_download(
EXPORTING
filename = p_file
filetype = 'ASC'
CHANGING
data_tab = lt_file_content ).
ENDFORM.Schritte
- Voraussetzungen: Stellen Sie sicher, dass Sie direkten, schreibgeschützten Zugriff auf die zugrunde liegende SAP ECC-Datenbank haben. Sie benötigen ein Datenbank-Client-Tool wie DBeaver, SQL Server Management Studio oder Oracle SQL Developer, um sich zu verbinden und Abfragen auszuführen.
- SQL-Skript abrufen: Kopieren Sie die vollständige SQL-Abfrage, die im Abschnitt 'query' dieses Dokuments bereitgestellt wird.
- Mit der Datenbank verbinden: Öffnen Sie Ihren Datenbank-Client und stellen Sie eine Verbindung zur SAP ECC-Datenbankinstanz her. Sie benötigen die Serveradresse, den Port, den Datenbanknamen und die entsprechenden Anmeldeinformationen.
- Abfrage konfigurieren: Fügen Sie das SQL-Skript in ein neues Abfrage-Editor-Fenster ein. Suchen Sie den Konfigurationsbereich innerhalb der Haupt-Common Table Expression (CTE) namens SalesOrders. Ersetzen Sie die Platzhalterwerte für das Startdatum ('{StartDate}'), Enddatum ('{EndDate}'), Vertriebsorganisationen ('{SalesOrgs}') und Belegarten ('{DocTypes}') durch die tatsächlichen Werte für Ihre Analyse.
- Abfrage ausführen: Führen Sie das konfigurierte SQL-Skript aus. Je nach Datumsbereich und Größe Ihrer SAP-Datenbank kann diese Abfrage mehrere Minuten in Anspruch nehmen.
- Ergebnisse überprüfen: Sobald die Abfrage abgeschlossen ist, wird ein Ergebnisdatensatz angezeigt. Überprüfen Sie kurz die Daten, um sicherzustellen, dass sie die erwarteten Spalten (SalesOrder, Activity, StartTime, etc.) enthalten und dass Zeilen für verschiedene Aktivitäten zurückgegeben werden.
- Daten exportieren: Verwenden Sie die Exportfunktion Ihres Datenbank-Clients, um den Ergebnisdatensatz als CSV-Datei zu speichern. Geben Sie der Datei einen aussagekräftigen Namen, z.B. SAP_O2C_Event_Log.csv.
- Für ProcessMind formatieren: Öffnen Sie die CSV-Datei in einem Tabellenkalkulationsprogramm. Vergewissern Sie sich, dass die Spaltenüberschriften genau den erforderlichen Attributen (z.B. SalesOrder, Activity, StartTime) entsprechen. Stellen Sie sicher, dass das Datums- und Zeitformat für StartTime und LastDataUpdate konsistent und von ProcessMind unterstützt wird, z.B. YYYY-MM-DD HH:MI:SS.
- In ProcessMind hochladen: Laden Sie die finale, formatierte CSV-Datei zur Analyse in Ihr ProcessMind-Projekt hoch.
Konfiguration
- Datumsbereich: Die Abfrage verwendet Platzhalter ('{StartDate}' und '{EndDate}'), um Vertriebsbelege basierend auf ihrem Erstellungsdatum (VBAK.ERDAT) zu filtern. Ein typischer Analysezeitraum beträgt 3 bis 6 Monate Daten, um eine repräsentative Stichprobe ohne übermäßige Datenbanklast zu gewährleisten.
- Filter für Vertriebsorganisationen: Verwenden Sie den Platzhalter '{SalesOrgs}', um die Extraktion auf spezifische Vertriebsorganisationen (z.B. '1000', '2000') zu begrenzen. Dies ist entscheidend, um die Analyse zu fokussieren und die Abfrage-Performance zu verbessern.
- Filter für Belegarten: Verwenden Sie den Platzhalter '{DocTypes}', um spezifische Vertriebsbelegarten (z.B. 'OR' für Standardauftrag) auszuwählen. Dies hilft, irrelevante Belege wie kostenlose Lieferungen oder Retouren aus dem Hauptprozessfluss auszuschließen.
- Quellsystem-Identifikator: Der fest codierte Platzhalter '{SourceSystemName}' wird verwendet, um jeden Datensatz mit seinem Quellsystem zu kennzeichnen. Er sollte auf einen aussagekräftigen Namen für Ihre SAP ECC-Instanz (z. B. SAP_ECC_PRD) gesetzt werden.
- Datenbankkompatibilität: Die Funktion zur Kombination von Datums- und Uhrzeitfeldern, [Ihre DB-spezifische Timestamp-Funktion], ist ein Platzhalter. Sie müssen diese durch die korrekte Funktion für Ihre spezifische Datenbank ersetzen (z.B. TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UZEIT), 'YYYYMMDDHH24MISS') für SAP HANA oder CAST(CDHDR.UDATE AS DATETIME) + CAST(CDHDR.UZEIT AS DATETIME) für SQL Server).
- Voraussetzungen: Diese Methode erfordert direkte, schreibgeschützte Zugangsdaten zur Datenbank. Der Datenbankbenutzer muss über die Berechtigung verfügen, auf alle in der Abfrage referenzierten Tabellen zuzugreifen, einschließlich VBAK, VBAP, VBFA, CDHDR, CDPOS, LIKP, VBRK und BSAD.
a Beispielabfrage sql
WITH SalesOrders AS (
SELECT VBELN
FROM VBAK
WHERE ERDAT BETWEEN '{StartDate}' AND '{EndDate}' -- Filter by creation date
AND VKORG IN ('{SalesOrgs}') -- Filter by Sales Organization(s)
AND AUART IN ('{DocTypes}') -- Filter by Sales Document Type(s)
)
-- 1. Sales Order Created
SELECT
vbak.VBELN AS "SalesOrder",
'Sales Order Created' AS "Activity",
[Your DB-specific timestamp function](vbak.ERDAT, vbak.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbak.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBAK vbak
JOIN SalesOrders so ON vbak.VBELN = so.VBELN
UNION ALL
-- 2. Sales Order Changed
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Sales Order Changed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG' AND cdhdr.TCODE IN ('VA02')
UNION ALL
-- 3. Credit Check Performed (Release)
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Credit Check Performed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'CMGST'
AND cdpos.VALUE_NEW = 'B' -- Credit status 'Released'
UNION ALL
-- 4. Order Confirmed (Overall status not blocked)
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Order Confirmed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'GBSTK'
AND cdpos.VALUE_OLD <> 'A' AND cdpos.VALUE_NEW = 'A' -- Status changes to 'Not yet processed'
UNION ALL
-- 5. Delivery Block Set
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Delivery Block Set' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
cdpos.VALUE_NEW AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBAK'
AND cdpos.FNAME = 'LIFSK'
AND cdpos.VALUE_NEW IS NOT NULL AND cdpos.VALUE_NEW <> ''
UNION ALL
-- 6. Delivery Created
SELECT
vbfa.VBELV AS "SalesOrder",
'Delivery Created' AS "Activity",
[Your DB-specific timestamp function](likp.ERDAT, likp.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
likp.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN LIKP likp ON vbfa.VBELN = likp.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J'
UNION ALL
-- 7. Picking Completed
SELECT
vbfa.VBELV AS "SalesOrder",
'Picking Completed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN CDHDR cdhdr ON vbfa.VBELN = cdhdr.OBJECTID
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J'
AND cdhdr.OBJECTCLASS = 'LIEFERUNG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'PKSTK'
AND cdpos.VALUE_NEW = 'C'
UNION ALL
-- 8. Goods Issued
SELECT
vbfa_gi.VBELV AS "SalesOrder",
'Goods Issued' AS "Activity",
[Your DB-specific timestamp function](mkpf.BUDAT, mkpf.CPUTM) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
mkpf.USNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa_gi
JOIN SalesOrders so ON vbfa_gi.VBELV = so.VBELN
JOIN MKPF mkpf ON vbfa_gi.VBELN = mkpf.XBLNR -- XBLNR is Reference Document Number
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa_gi.VBTYP_V = 'J' AND vbfa_gi.VBTYP_N = 'R'
UNION ALL
-- 9. Proof Of Delivery Confirmed
SELECT
vbfa.VBELV AS "SalesOrder",
'Proof Of Delivery Confirmed' AS "Activity",
[Your DB-specific timestamp function](likp.PODAT, '000000') AS "StartTime", -- PODAT is only a date
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
likp.AENAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN LIKP likp ON vbfa.VBELN = likp.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J' AND likp.PODAT IS NOT NULL AND likp.PODAT <> '00000000'
UNION ALL
-- 10. Invoice Created
SELECT
vbfa.VBELV AS "SalesOrder",
'Invoice Created' AS "Activity",
[Your DB-specific timestamp function](vbrk.ERDAT, vbrk.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbrk.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'M'
UNION ALL
-- 11. Invoice Cancelled
SELECT
vbfa.VBELV AS "SalesOrder",
'Invoice Cancelled' AS "Activity",
[Your DB-specific timestamp function](vbrk.ERDAT, vbrk.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbrk.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'M' AND vbfa.VBTYP_N = 'N'
UNION ALL
-- 12. Payment Received
SELECT
vbfa.VBELV AS "SalesOrder",
'Payment Received' AS "Activity",
[Your DB-specific timestamp function](bsad.AUGDT, '000000') AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
NULL AS "User", -- Clearing user not readily available here
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN BSAD bsad ON vbrk.VBELN = bsad.VBLNR
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'M'
AND bsad.AUGDT IS NOT NULL AND bsad.AUGDT <> '00000000'
UNION ALL
-- 13. Order Item Closed
SELECT DISTINCT
cdhdr.OBJECTID AS "SalesOrder",
'Order Item Closed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
vbap.MATNR AS "MaterialNumber",
NULL AS "DeliveryBlock",
vbap.ABGRU AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAP vbap ON cdhdr.OBJECTID = vbap.VBELN AND SUBSTRING(cdpos.TABKEY, 4, 6) = vbap.POSNR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUP'
AND cdpos.FNAME = 'GBSTA'
AND cdpos.VALUE_NEW = 'C' -- Item is completely processed
UNION ALL
-- 14. Order Cancelled
SELECT DISTINCT
cdhdr.OBJECTID AS "SalesOrder",
'Order Cancelled' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
vbap.MATNR AS "MaterialNumber",
NULL AS "DeliveryBlock",
cdpos.VALUE_NEW AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAP vbap ON cdhdr.OBJECTID = vbap.VBELN AND SUBSTRING(cdpos.TABKEY, 4, 6) = vbap.POSNR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBAP'
AND cdpos.FNAME = 'ABGRU'
AND cdpos.VALUE_NEW IS NOT NULL AND cdpos.VALUE_NEW <> '';