Ihr Order-to-Cash-Daten-Template für die Kundenauftragsbearbeitung
Ihr Order-to-Cash-Daten-Template für die Kundenauftragsbearbeitung
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Verfolgung
- Extraktionsanleitung für SAP ECC
Order to Cash - Kundenauftragsabwicklung Attribute
| Name | Beschreibung | ||
|---|---|---|---|
| Verkaufsauftrag 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. Bedeutung 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. Datenquelle 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 z. B. „Kundenauftrag angelegt“, „Lieferung erstellt“ oder „Zahlung erhalten“. Diese Aktivitäten bilden die Bausteine zur Rekonstruktion des Prozessflusses für jeden einzelnen Auftrag. Die Analyse der Reihenfolge und des Zeitpunkts dieser Aktivitäten ist der Kern von Process Mining. Sie hilft dabei, die Prozesslandkarte zu visualisieren, Bottlenecks zu identifizieren, Prozessvarianten zu entdecken und die Compliance mit einem Standardmodell zu prüfen. Aktivitäten werden in der Regel aus einer Kombination von Belegerstellungs-Events, Statusänderungen oder spezifischen Transaktionscodes im System abgeleitet. Bedeutung Aktivitäten bilden das Rückgrat der Prozesslandkarte und ermöglichen die Visualisierung und Analyse des Prozessflusses sowie von Abweichungen und Engpässen. Datenquelle 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 Verkaufsauftrag 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 gibt Datum und Uhrzeit der letzten Datenextraktion oder Aktualisierung für ein Event oder einen Case an. Es schafft Transparenz über die Aktualität der analysierten Daten. In Dashboards und Berichten ist diese Information entscheidend, damit die Anwender die Zeitnähe der gewonnenen Erkenntnisse einschätzen können. Es hilft zu bestätigen, ob die Analyse den aktuellen Stand des Geschäftsbetriebs widerspiegelt oder auf älteren Daten basiert, wodurch Erwartungen an die Datenaktualität gesteuert werden. Bedeutung 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. Datenquelle 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 Quellsystem an, zum Beispiel den Namen einer SAP ECC-Instanz oder eine Mandantennummer. Es liefert den Kontext für die Daten, besonders in Umgebungen mit mehreren Produktivsystemen oder Daten aus Altsystemen. In der Analyse wird es verwendet, um Daten basierend auf ihrer Herkunft zu filtern oder zu segmentieren. Dies ist besonders nützlich für den Vergleich von Prozessen über verschiedene Systeme hinweg oder bei Systemmigrationen, um die Datenintegrität und -konsistenz sicherzustellen. Bedeutung Bietet wesentlichen Kontext, insbesondere in Multi-System-Landschaften, ermöglicht den Prozessvergleich und stellt eine klare Datenherkunft sicher. Datenquelle 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. Bedeutung 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. Datenquelle 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. Bedeutung Liefert das 'Warum' hinter Auftragsstornierungen und ermöglicht eine Ursachenanalyse, um verlorene Umsätze zu reduzieren und die Prognosegenauigkeit zu verbessern. Datenquelle 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 des Verantwortlichen für ein bestimmtes Event im Prozess. Es identifiziert beispielsweise den Sachbearbeiter im Vertrieb, der den Auftrag angelegt hat, oder den Lagerarbeiter, der den Warenausgang gebucht hat. Die Analyse des Prozesses nach Benutzern hilft dabei, die Verteilung der Arbeitsbelastung zu verstehen, Schulungsbedarf zu ermitteln und Abweichungen in der Arbeitsweise zu erkennen. Das ist essenziell für Dashboards, die sich auf Ressourcenleistung, Compliance und manuelle Eingriffe konzentrieren. Bedeutung Bietet Transparenz über Ressourcenleistung und Arbeitslast, hilft bei der Identifizierung benutzerspezifischer Prozessabweichungen und ist entscheidend für die Compliance- und Automatisierungsanalyse. Datenquelle 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 normalerweise als Differenz zwischen dem Timestamp der allerersten Aktivität („Kundenauftrag angelegt“) und der allerletzten Aktivität (z. B. „Zahlung erhalten“ oder „Auftragsposition geschlossen“) berechnet. Dieses Attribut ist der Hauptmesswert für das Dashboard zur End-to-End-Durchlaufzeit von Kundenaufträgen und den zugehörigen KPI zur Auftragsabwicklung. Es bietet einen Überblick über die Prozesseffizienz auf hoher Ebene und ist eine kritische Kennzahl zur Identifizierung langlaufender Aufträge sowie der allgemeinen Prozessgesundheit. Die Analyse der Verteilung dieser Kennzahl hilft dabei, Benchmarks zu setzen und den Erfolg von Optimierungsmaßnahmen im Zeitverlauf zu verfolgen. Bedeutung Dies ist der primäre KPI zur Messung der Gesamtprozessgeschwindigkeit und -effizienz, der eine kritische Grundlage für Verbesserungsinitiativen bietet. Datenquelle 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 Verkaufsauftrag verknüpft ist. Es verbindet die Transaktion mit einem spezifischen Kunden in den Stammdaten. Die Analyse nach Kundennummer ermöglicht eine Segmentierung des Prozesses, um kundenspezifisches Verhalten und Performance zu verstehen. Sie hilft bei der Beantwortung von Fragen wie: Welche Kunden haben die längsten Durchlaufzeiten, die höchsten Nacharbeitsraten oder die häufigsten Auftragsänderungen? Dies ist entscheidend für die Verbesserung des Customer Relationship Managements und des Serviceniveaus. Bedeutung Ermöglicht eine kundenorientierte Analyse, die dabei hilft, Prozessprobleme zu identifizieren, die bestimmte Kunden betreffen, und kundenspezifische Leistungen zu messen. Datenquelle 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). Bedeutung Identifiziert direkt Engpässe im Abwicklungsprozess. Die Analyse, warum und wie oft Aufträge blockiert werden, ist entscheidend für die Verbesserung der Prozesseffizienz. Datenquelle 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. Bedeutung Ermöglicht eine produktbasierte Prozessanalyse, die aufzeigt, welche Produkte mit Prozessineffizienzen wie Verzögerungen, Blockaden oder Nacharbeiten verbunden sind. Datenquelle 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. Bedeutung 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. Datenquelle Gefunden in der Tabelle für Verkaufsbelegkopfdaten (VBAK) als Feld NETWR. Beispiele 1500.0012550.75850.50 | |||
| Verkaufsorganisation 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. Bedeutung Ermöglicht organisatorisches Benchmarking, um die Prozesseffizienz und Compliance über verschiedene Geschäftseinheiten oder Regionen hinweg zu vergleichen. Datenquelle 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. Bedeutung Dies ist der Referenzwert zur Messung der Pünktlichkeitsleistung der Lieferung, ein kritischer KPI für Kundenzufriedenheit und Effizienz der Lieferkette. Datenquelle 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, bei denen Nacharbeit angefallen ist, wie z. B. durch eine oder mehrere Aktivitäten vom Typ „Kundenauftrag geändert“. Die spezifische Logik dafür – etwa Preis-, Mengen- oder Lieferterminänderungen – wird während des Projekt-Setups definiert. Dieses Attribut ist zentral für das Dashboard „Häufigkeit von Nacharbeit und Änderungen bei Kundenaufträgen“ und den entsprechenden KPI. Es vereinfacht die Analyse, indem es eine direkte Filterung und den Vergleich zwischen Aufträgen ermöglicht, die den Idealpfad („Straight-through“) durchlaufen haben, und solchen, die manuelle Änderungen erforderten. Dies hilft, die Auswirkungen von Nacharbeit auf Durchlaufzeiten und Kosten zu quantifizieren. Bedeutung 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. Datenquelle 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 an. Typische Status sind „Genehmigt“, „Abgelehnt“ oder „Gesperrt“. Dies ist ein Schlüsselattribut für das Dashboard „Analyse der Bearbeitungszeit der Kreditprüfung“. Verzögerungen oder Sperren in dieser Phase können die gesamte Durchlaufzeit der Auftragsabwicklung erheblich beeinflussen. Die Analyse dieses Status hilft dabei, die Effizienz des Kreditmanagements und dessen Auswirkungen auf die Vertriebsgeschwindigkeit zu verstehen. Bedeutung 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. Datenquelle 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ätigten Lieferdatum ( Dieses Attribut vereinfacht die Erstellung des Dashboards zur Liefertreue und die Berechnung des On-Time Delivery Rate KPIs. Es ermöglicht eine einfache Aggregation und Visualisierung der Performance, ohne dass Datumsvergleiche ad hoc in jeder Analyse oder jedem Diagramm durchgeführt werden müssen. Dies bietet ein klares, schnelles Maß für die Lieferzuverlässigkeit. Bedeutung Bietet ein klares und einfaches Maß für die Lieferperformance und ermöglicht die einfache Berechnung des gesamten On-Time Delivery Rate KPI. Datenquelle 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. Bedeutung Ermöglicht die Analyse der Logistikleistung und hilft dabei zu bestimmen, ob bestimmte Versandarten mit Verzögerungen oder höherer Effizienz korrelieren. Datenquelle 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. | ||
| Bedeutung 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. Datenquelle 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. | ||
| Bedeutung 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. Datenquelle 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 | |||
| 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. | ||
| Bedeutung 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. Datenquelle 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 | |||
| Verkaufsauftrag 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. | ||
| Bedeutung 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. Datenquelle 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 | |||
| 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. | ||
| Bedeutung 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. Datenquelle 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. | ||
| Bedeutung 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. Datenquelle 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. | ||
| Bedeutung 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. Datenquelle 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. | ||
| Bedeutung Die Analyse der Kommissionierzeit hilft, Lagerabläufe zu optimieren. Verzögerungen hier wirken sich direkt auf den gesamten Lieferzeitrahmen und den Abwicklungszyklus aus. Datenquelle 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. | ||
| Bedeutung 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. Datenquelle 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 | |||
| 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. | ||
| Bedeutung Dieses Event liefert das tatsächliche Lieferdatum, das wesentlich ist, um die 'Pünktliche Lieferrate' genau gegen das zugesagte Datum zu messen. Datenquelle 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. | ||
| Bedeutung 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. Datenquelle 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. | ||
| Bedeutung Dies ist der erste Schritt im physischen Ausführungsprozess. Die Zeit zwischen Auftragsbestätigung und Liefererstellung zeigt, wie schnell der Logistikprozess eingeleitet wird. Datenquelle 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. | ||
| Bedeutung Das Nachverfolgen von Rechnungsstornierungen hilft, Probleme mit der Preisgestaltung, Versanddifferenzen oder Datenfehlern zu identifizieren. Dies unterstützt den KPI 'Rechnungsdiskrepanzrate'. Datenquelle 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 | |||
| Verkaufsauftrag 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. | ||
| Bedeutung 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. Datenquelle 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 | |||
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 <> '';