Ihr Daten-Template für den Order-to-Cash-Prozess: Auftragsabwicklung im Vertrieb
Ihr Daten-Template für den Order-to-Cash-Prozess: Auftragsabwicklung im Vertrieb
- Empfohlene Attribute für die Erfassung
- Wichtige Aktivitäten für die Nachverfolgung
- Hinweise zur Datenextraktion mit SAP ECC
Attribute für den Order-to-Cash-Prozess: Auftragsabwicklung im Vertrieb
| Name | Beschreibung | ||
|---|---|---|---|
| Kundenauftrag SalesOrder | Die eindeutige Kennung eines Kundenauftrags. Sie dient als zentraler Case für die Nachverfolgung des gesamten Order-to-Cash-Prozesses. | ||
| Beschreibung Der Kundenauftrag ist das zentrale Dokument im Vertriebsprozess. Er enthält die Anfrage eines Kunden nach Waren oder Dienstleistungen sowie alle Informationen, die für die Bearbeitung von Anfang bis Ende erforderlich sind. Im Process Mining dient dieses Attribut als Case-ID. Jede eindeutige Kundenauftragsnummer steht für eine vollständige Prozessinstanz. Die Analyse nach Kundenauftrag ermöglicht es, den gesamten Prozessverlauf nachzuverfolgen, Durchlaufzeiten zu messen und Abweichungen bei einzelnen Kundenaufträgen zu erkennen. Warum das wichtig ist Der Kundenauftrag ist der zentrale Schlüssel, mit dem sich alle zugehörigen Aktivitäten und Ereignisse verknüpfen lassen. So kann der gesamte Verlauf jedes Kundenauftrags analysiert werden. Woher beziehen Zu finden in der Tabelle VBAK (Verkaufsbeleg: Kopfdaten), im Feld VBELN. Beispiele 900001234590000123469000012347 | |||
| Aktivität Activity | Die Bezeichnung eines bestimmten Geschäftsschritts oder Ereignisses im Kundenauftragsprozess. | ||
| Beschreibung Dieses Attribut beschreibt einen einzelnen Schritt im Order-to-Cash-Prozess, zum Beispiel „Kundenauftrag erstellt“, „Lieferung angelegt“ oder „Zahlung eingegangen“. Anhand dieser Aktivitäten wird der Prozessablauf für jeden Kundenauftrag rekonstruiert. Die Analyse der Reihenfolge und Zeitpunkte dieser Aktivitäten bildet den Kern des Process Mining. Sie macht den Prozessablauf sichtbar, hilft Engpässe und Prozessvarianten zu erkennen und ermöglicht die Konformitätsprüfung anhand eines Sollmodells. Aktivitäten werden in der Regel aus einer Kombination von Belegerstellungsereignissen, Statusänderungen oder bestimmten Transaktionscodes im System abgeleitet. Warum das wichtig ist Aktivitäten bilden die Grundlage der Prozessdarstellung. Sie ermöglichen es, den Prozessablauf zu visualisieren und Abweichungen sowie Engpässe zu analysieren. Woher beziehen Dieses abgeleitete Attribut wird üblicherweise bei der Datenextraktion erstellt. Dazu werden SAP-Transaktionscodes (T-Codes), Belegstatusänderungen (z. B. in den Tabellen VBUK und VBUP) oder Änderungsbelege (Tabellen CDHDR und CDPOS) verständlichen Aktivitätsnamen zugeordnet. Beispiele Kundenauftrag erstelltLieferung erstelltWarenausgang gebuchtRechnung erstelltZahlung eingegangen | |||
| Letzte Datenaktualisierung LastDataUpdate | Timestamp der letzten Aktualisierung der Daten dieses Datensatzes aus dem Quellsystem. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion oder Aktualisierung eines Ereignisses oder Case. So ist ersichtlich, wie aktuell die analysierten Daten sind. In Dashboards und Berichten hilft diese Information den Benutzern, die Aktualität der Daten einzuschätzen. Sie zeigt, ob die Analyse den aktuellen Betriebsstand abbildet oder auf älteren Daten beruht, und schafft Klarheit darüber, wie aktuell die Ergebnisse sind. Warum das wichtig ist Macht die Aktualität der Daten transparent. Das ist wichtig, damit Benutzer auf Grundlage der Process-Mining-Analyse rechtzeitig fundierte Entscheidungen treffen können. Woher beziehen Dieses Metadatenattribut wird zum Zeitpunkt der Datenübernahme vom Datenextraktionstool oder -prozess befüllt. Es ist nicht in den SAP-Quelltabellen gespeichert. Beispiele 2024-06-10T05:00:00Z2024-06-11T05:00:00Z2024-06-12T05:00:00Z | |||
| Quellsystem SourceSystem | Gibt an, aus welchem Quellsystem die Daten extrahiert wurden. | ||
| Beschreibung Dieses Attribut bezeichnet das Ursprungssystem, zum Beispiel eine bestimmte SAP-ECC-Instanz oder Mandantennummer. Es ordnet die Daten ein, insbesondere in Umgebungen mit mehreren Produktivsystemen oder Daten aus Altsystemen. In der Analyse dient es dazu, Daten nach ihrer Herkunft zu filtern oder aufzuschlüsseln. Das ist besonders hilfreich, um Prozesse systemübergreifend zu vergleichen oder bei Systemmigrationen die Datenintegrität und -konsistenz sicherzustellen. Warum das wichtig ist Liefert wichtigen Kontext, insbesondere in Umgebungen mit mehreren Systemen. So lassen sich Prozesse vergleichen und die Herkunft der Daten nachvollziehen. Woher beziehen Dieser Wert wird üblicherweise bei der Datenextraktion ergänzt. Meist handelt es sich um einen statischen Wert für die SAP-System-ID (SAPSID) oder den Mandanten (MANDT). Beispiele ECC_PROD_800SAP_ERP_EU1ECC_QAS_300 | |||
| Startzeit StartTime | Der Timestamp, der angibt, wann eine Aktivität oder ein Ereignis begonnen hat. | ||
| Beschreibung Die Startzeit, auch Ereignis-Timestamp genannt, erfasst Datum und Uhrzeit einer bestimmten Aktivität. Sie zeigt zum Beispiel, wann ein Kundenauftrag angelegt, ein Warenausgang gebucht oder eine Rechnung gebucht wurde. Dieser Timestamp ist die Grundlage für alle zeitbezogenen Analysen im Process Mining. Mit ihm lassen sich die Zykluszeiten zwischen Aktivitäten und die Gesamtdauer eines Case berechnen sowie Verzögerungen und Engpässe erkennen. Genaue Timestamps sind entscheidend für Dashboards zur Leistungsanalyse, etwa zur Überwachung termingerechter Lieferungen oder der Durchlaufzeiten bei der Auftragserfüllung. Warum das wichtig ist Dieses wichtige Attribut ist die Grundlage für die Berechnung aller Leistungskennzahlen, etwa von Zykluszeiten und Dauern. Diese Kennzahlen sind entscheidend, um Engpässe zu erkennen. Woher beziehen Dieses zusammengesetzte Attribut wird üblicherweise aus einem Datumsfeld (z. B. ERDAT) und einem Zeitfeld (z. B. ERZET) verschiedener SAP-Tabellen gebildet, etwa VBAK (Kundenauftrag), LIKP (Lieferung) und VBRK (Rechnung). Beispiele 2023-04-15T09:00:12Z2023-04-16T14:30:00Z2023-04-20T11:22:45Z | |||
| Absagegrund RejectionReason | Ein Code für den Grund, aus dem eine Kundenauftragsposition abgelehnt oder storniert wurde. | ||
| Beschreibung Der Absagegrund erklärt, warum ein Kundenauftrag oder eine bestimmte Position nicht erfüllt wurde. Mögliche Gründe sind eine Stornierung durch den Kunden, die Nichtverfügbarkeit eines Produkts oder andere geschäftliche Ursachen. Dieses Attribut ist wichtig für das Dashboard „Trends bei Kundenauftragsstornierungen“. Die Analyse der häufigsten Absagegründe hilft, Ursachen für entgangene Verkäufe zu erkennen. Daraus können Verbesserungen bei der Bestandsverwaltung, der Preisgestaltung oder der Kundenkommunikation abgeleitet werden, um die Auftragsstornierungsquote zu senken. Warum das wichtig ist Erklärt, warum Aufträge storniert werden. Die Ursachenanalyse hilft, entgangene Verkäufe zu verringern und die Prognosegenauigkeit zu verbessern. Woher beziehen Zu finden in der Tabelle VBAP (Verkaufsbeleg: Positionsdaten), im Feld ABGRU. Beispiele 0215Z5 | |||
| Benutzer User | Die Benutzer-ID des Mitarbeitenden, der das Dokument erstellt oder zuletzt geändert beziehungsweise die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut erfasst die SAP-Benutzer-ID, die für ein bestimmtes Ereignis im Prozess verantwortlich ist. Es zeigt zum Beispiel, welcher Sachbearbeiter den Auftrag angelegt oder welcher Mitarbeitende im Lager den Warenausgang gebucht hat. Die Analyse nach Benutzer hilft, die Arbeitslast zu verteilen, Schulungsbedarf zu erkennen und Unterschiede darin aufzudecken, wie Benutzer dieselbe Aufgabe ausführen. Sie ist wichtig für Dashboards zur Ressourcenleistung und Compliance sowie zur Erkennung manueller Eingriffe. Warum das wichtig ist Macht Ressourcenleistung und Arbeitslast sichtbar, hilft benutzerspezifische Prozessabweichungen zu erkennen und unterstützt die Compliance- und Automatisierungsanalyse. Woher beziehen In vielen SAP-Kopftabellen als Feld „Erstellt von“ (ERNAM) oder „Geändert von“ (AENAM) zu finden, zum Beispiel in VBAK, LIKP und VBRK. Beispiele CBURKEJSMITHRWILLIAMS | |||
| Kundennummer CustomerNumber | Die eindeutige Kennung des Kunden, der den Kundenauftrag erteilt hat. | ||
| Beschreibung Dieses Attribut bezeichnet den Auftraggeber, also das Hauptkundenkonto des Kundenauftrags. Es verknüpft den Vorgang mit einem bestimmten Kunden in den Stammdaten. Die Analyse nach Kundennummer zeigt kundenspezifische Abläufe und Leistungen. Sie hilft beispielsweise zu ermitteln, bei welchen Kunden die Durchlaufzeiten am längsten, die Nacharbeitsquoten am höchsten oder Auftragsänderungen am häufigsten sind. Das ist wichtig, um das Kundenbeziehungsmanagement und den Service zu verbessern. Warum das wichtig ist Ermöglicht eine kundenbezogene Analyse. So lassen sich Prozessprobleme bei bestimmten Kunden erkennen und kundenspezifische Leistungen messen. Woher beziehen Zu finden in der Tabelle VBAK (Verkaufsbeleg: Kopfdaten), im Feld KUNNR. Beispiele 100234100567200112 | |||
| Liefersperre DeliveryBlock | Ein Code, der angibt, ob ein Kundenauftrag für die Lieferung gesperrt ist und deshalb kein Lieferbeleg angelegt werden kann. | ||
| Beschreibung Die Liefersperre ist ein Status auf Kopf- oder Positionsebene eines Kundenauftrags, der den Prozess vor dem Lieferschritt vorübergehend anhält. Ein Benutzer kann die Sperre manuell setzen. Das System kann sie auch automatisch auslösen, etwa bei einer Überschreitung des Kreditlimits oder unvollständigen Daten. Dieses Attribut ist entscheidend für das Dashboard „Analyse von Auftragssperren und Nacharbeit“. Die Analyse von Häufigkeit, Dauer und Gründen der Liefersperren hilft, wesentliche Engpässe bei der Auftragserfüllung zu erkennen. Weniger Sperren tragen zu termingerechten Lieferungen und kürzeren Durchlaufzeiten bei. Warum das wichtig ist Zeigt Engpässe bei der Auftragserfüllung direkt auf. Um den Prozessfluss zu verbessern, muss klar sein, warum und wie oft Aufträge gesperrt werden. Woher beziehen Zu finden in der Tabelle VBAK (Verkaufsbeleg: Kopfdaten), im Feld LIFSK. Beispiele 0102Z1 | |||
| Materialnummer MaterialNumber | Die eindeutige Kennung eines verkauften Produkts oder einer Dienstleistung. | ||
| Beschreibung Die Materialnummer identifiziert die konkrete Position in einem Kundenauftrag. Da ein Kundenauftrag mehrere Materialien enthalten kann, wird dieses Attribut üblicherweise auf Positionsebene analysiert. Die Analyse nach Materialnummer hilft, produktspezifische Probleme aufzudecken. Sie zeigt beispielsweise, ob bestimmte Produkte mit längeren Erfüllungszeiten, häufigeren Liefersperren oder mehr Rechnungsabweichungen verbunden sind. Das ist wichtig für das Lieferketten- und Produktmanagement, um die Abläufe für verschiedene Produktlinien zu optimieren. Warum das wichtig ist Ermöglicht eine produktbezogene Prozessanalyse und zeigt, bei welchen Produkten Ineffizienzen wie Verzögerungen, Sperren oder Nacharbeit auftreten. Woher beziehen Zu finden in der Tabelle VBAP (Verkaufsbeleg: Positionsdaten), im Feld MATNR. Beispiele FG-1001-ARAW-205BSERV-INSTALL | |||
| Nettobetrag NetAmount | Der Gesamtwert des Kundenauftrags ohne Steuern und Rabatte auf Kopfebene. | ||
| Beschreibung Der Nettobetrag gibt den Geldwert des Kundenauftrags an. Er ist eine wichtige Finanzkennzahl für jede Prozessinstanz. Dieses Attribut ist für eine wertbezogene Process-Mining-Analyse unerlässlich. Es hilft, Verbesserungsmaßnahmen auf Aufträge mit hohem Wert auszurichten. Analysten können Prozessprobleme wie Verzögerungen oder Nacharbeit mit ihren finanziellen Auswirkungen in Verbindung bringen und so die Grundlage für Veränderungen stärken. Beispielsweise lässt sich untersuchen, ob Aufträge mit hohem Wert effizienter oder weniger effizient als Aufträge mit niedrigem Wert bearbeitet werden. Warum das wichtig ist Ermöglicht eine wertbezogene Analyse und hilft, Verbesserungsmaßnahmen auf Aufträge mit den größten finanziellen Auswirkungen für das Unternehmen auszurichten. Woher beziehen Zu finden in der Tabelle VBAK (Verkaufsbeleg: Kopfdaten), im Feld NETWR. Beispiele 1500.0012550.75850.50 | |||
| Verkaufsorganisation SalesOrganization | Die Organisationseinheit, die für den Verkauf von Produkten oder Dienstleistungen verantwortlich ist. | ||
| Beschreibung Die Verkaufsorganisation ist eine zentrale Organisationseinheit in SAP, die das Unternehmen nach seinen Vertriebsanforderungen gliedert. Sie ist für die Aushandlung von Verkaufsbedingungen und den Vertrieb von Waren und Dienstleistungen zuständig. Im Process Mining ist dieses Attribut eine wichtige Analysedimension. Es ermöglicht, Prozessleistung, Effizienz und Compliance zwischen verschiedenen Vertriebseinheiten, Regionen oder Geschäftsbereichen zu vergleichen. So lassen sich bewährte Vorgehensweisen leistungsstarker Organisationen erkennen und Verbesserungsmöglichkeiten in anderen Bereichen aufzeigen. Warum das wichtig ist Ermöglicht ein Benchmarking zwischen Organisationseinheiten und Regionen, um Prozesseffizienz und Compliance zu vergleichen. Woher beziehen Zu finden in der Tabelle VBAK (Verkaufsbeleg: Kopfdaten), im Feld VKORG. Beispiele 100025003100 | |||
| Bestätigtes Lieferdatum ConfirmedDeliveryDate | Das Datum, an dem die Lieferung der Waren oder Dienstleistungen dem Kunden zugesagt wurde. | ||
| Beschreibung Dies ist das dem Kunden zugesagte Lieferdatum, das sich nach Materialverfügbarkeit und Terminplanung richtet. Es dient als Grundlage für die Messung der Lieferleistung. Dieses Attribut bildet die Grundlage für das Dashboard „Leistung bei termingerechter Lieferung“ und die Kennzahl zur termingerechten Lieferung. Durch den Vergleich des bestätigten Lieferdatums mit dem tatsächlichen Datum des Warenausgangs lässt sich feststellen, ob ein Auftrag pünktlich, früher oder verspätet geliefert wurde. Dies ist ein wichtiger Maßstab für die Zuverlässigkeit der Lieferkette und die Kundenzufriedenheit. Warum das wichtig ist Dient als Vergleichswert für die Leistung bei termingerechter Lieferung, einer wichtigen Kennzahl für Kundenzufriedenheit und Effizienz der Lieferkette. Woher beziehen Zu finden in der Tabelle VBEP (Verkaufsbeleg: Einteilungen), im Feld EDATU. Beispiele 2023-05-102023-06-202023-07-01 | |||
| Kreditprüfungsstatus CreditCheckStatus | Gibt den Status der Kreditprüfung für den Verkaufsbeleg an. | ||
| Beschreibung Dieses Attribut zeigt das Ergebnis der automatischen oder manuellen Kreditprüfung eines Kundenauftrags. Übliche Statuswerte sind „Genehmigt“, „Abgelehnt“ oder „Gesperrt“. Dieses Attribut ist wichtig für das Dashboard „Analyse der Bearbeitungszeit der Kreditprüfung“. Verzögerungen oder Sperren bei der Kreditprüfung können die gesamte Durchlaufzeit der Auftragserfüllung erheblich verlängern. Die Analyse des Status zeigt, wie effizient das Kreditmanagement arbeitet und wie es sich auf die Vertriebsgeschwindigkeit auswirkt. Warum das wichtig ist Wirkt sich direkt auf die Bearbeitungsgeschwindigkeit von Aufträgen aus. Die Analyse dieses Status hilft, Engpässe im Kreditmanagement zu erkennen, die die Auftragserfüllung verzögern. Woher beziehen Zu finden in der Tabelle VBUK (Verkaufsbeleg: Kopfstatus) oder direkt in VBAK als Kreditstatusfeld (z. B. CMGST). Beispiele ABD | |||
| Nacharbeit erfolgt IsRework | Ein boolescher Wert, der angibt, ob ein Kundenauftrag nach seiner ursprünglichen Erstellung wesentlich geändert oder nachbearbeitet wurde. | ||
| Beschreibung Dieses berechnete Attribut kennzeichnet Prozessinstanzen mit Nacharbeit, zum Beispiel nach einer oder mehreren Aktivitäten vom Typ „Kundenauftrag geändert“. Welche Änderungen als Nacharbeit gelten, etwa Änderungen an Preis, Menge oder Lieferdatum, wird bei der Projekteinstellung festgelegt. Dieses Attribut ist wichtig für das Dashboard „Nacharbeit und Änderungshäufigkeit bei Kundenaufträgen“ und die Kennzahl zur Nacharbeitsquote bei Kundenaufträgen. Es vereinfacht die Analyse, indem Aufträge mit einem durchgängigen Ablauf direkt mit Aufträgen verglichen werden können, die manuelle Änderungen erforderten. So lassen sich die Auswirkungen der Nacharbeit auf Durchlaufzeiten und Kosten beziffern. Warum das wichtig ist Beziffert die Häufigkeit von Nacharbeit und ermöglicht die Analyse ihrer Ursachen sowie ihrer Auswirkungen auf Prozesseffizienz und Durchlaufzeit. Woher beziehen Dieses berechnete Attribut wird aus dem Event Log abgeleitet. Die Logik prüft, ob Aktivitäten vom Typ „Kundenauftrag geändert“ oder bestimmte Änderungsereignisse aus den Tabellen CDHDR/CDPOS vorliegen. Beispiele truefalse | |||
| Termingerecht geliefert IsOnTimeDelivery | Ein boolescher Wert, der angibt, ob die Ware am bestätigten Lieferdatum oder früher versandt wurde. | ||
| Beschreibung Dieses berechnete Attribut vergleicht das tatsächliche Warenausgangsdatum mit dem bestätigten Lieferdatum eines Kundenauftrags. Liegt das Warenausgangsdatum am bestätigten Datum oder davor, wird der Wert auf „wahr“ gesetzt, andernfalls auf „falsch“. Dieses Attribut vereinfacht die Erstellung des Dashboards „Leistung bei termingerechter Lieferung“ und die Berechnung der Kennzahl zur termingerechten Lieferung. Die Leistung lässt sich damit einfach aggregieren und visualisieren, ohne Datumsvergleiche für jede Analyse oder jedes Chart erneut durchführen zu müssen. So ist die Zuverlässigkeit der Lieferungen auf einen Blick erkennbar. Warum das wichtig ist Liefert ein klares und einfaches Maß für die Lieferleistung und erleichtert die Berechnung der Gesamtkennzahl zur termingerechten Lieferung. Woher beziehen Dieses Attribut wird berechnet. Dazu wird der Timestamp der Aktivität „Warenausgang gebucht“ mit dem Wert des Attributs „ConfirmedDeliveryDate“ verglichen. Beispiele truefalse | |||
| Versandbedingungen ShippingConditions | Legt die allgemeinen Versandbedingungen für die Lieferung von Waren an den Kunden fest. | ||
| Beschreibung Die Versandbedingungen legen fest, wie ein Auftrag versandt wird, zum Beispiel als Standardversand, Expressversand oder zur Abholung. Sie werden mit dem Kunden vereinbart und beeinflussen die Logistikplanung. Dieses Attribut wird in der Analyse „Effizienz und Kosten der Versandart“ verwendet. Durch die Aufschlüsselung nach Versandbedingungen können Unternehmen untersuchen, ob bestimmte Versandarten häufiger zu Verzögerungen oder längeren Durchlaufzeiten führen. Diese Daten helfen, die Logistik zu optimieren und die Lieferzeiterwartungen der Kunden zu steuern. Warum das wichtig ist Ermöglicht die Analyse der Logistikleistung und zeigt, ob bestimmte Versandarten mit Verzögerungen oder höherer Effizienz verbunden sind. Woher beziehen Zu finden in der Tabelle VBAK (Verkaufsbeleg: Kopfdaten), im Feld VSBED. Beispiele 011020 | |||
Aktivitäten im Order-to-Cash-Prozess: Auftragsabwicklung im Vertrieb
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Auftrag bestätigt | Diese Aktivität zeigt an, dass der Kundenauftrag alle anfänglichen Prüfungen bestanden hat und zur Abwicklung freigegeben ist. Sie wird üblicherweise abgeleitet, wenn der Auftrag nicht mehr blockiert ist und in seinen Einteilungen bestätigte Mengen aufweist. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein markiert den Übergang von der Auftragserfassung zur Auftragsabwicklung. Er bildet den Ausgangspunkt für die Messung der Durchlaufzeiten und der Leistung bei termingerechter Lieferung. Woher beziehen Lässt sich ableiten, wenn Einteilungen in VBEP eine bestätigte Menge aufweisen (BMENG > 0) und der Auftrag nicht für die Lieferung blockiert ist (z. B. wenn VBUK-LIFSK leer ist). Erfassung Abgeleitet aus der Bestätigung der Einteilung (VBEP-BMENG > 0) und der Aufhebung von Sperren auf Kopfebene. Ereignistyp inferred | |||
| Auftragsposition abgeschlossen | Diese Aktivität kennzeichnet den endgültigen Abschluss einer Kundenauftragsposition. Sie zeigt an, dass die Position vollständig geliefert und fakturiert wurde und als erledigt gilt. Der Abschluss wird aus dem Gesamtstatus der Position abgeleitet. | ||
| Warum das wichtig ist Dieses Ereignis markiert den erfolgreichen Abschluss des Prozesses. Die Analyse der Abschlusszeitpunkte zeigt die Dauer des gesamten Prozesses und hilft, unnötig lange offene Aufträge zu erkennen. Woher beziehen Abgeleitet aus dem Gesamtstatusfeld der Position in der Tabelle VBUP (Verkaufsbeleg: Positionsstatus). Wenn VBUP-GBSTA den Wert 'C' (Vollständig bearbeitet) hat, gilt die Position als abgeschlossen. Erfassung Abgeleitet aus der Änderung des Positionsstatus (VBUP-GBSTA) auf 'C' (Vollständig bearbeitet). Ereignistyp inferred | |||
| Kundenauftrag erstellt | Kennzeichnet die Erstellung eines neuen Kundenauftrags. Dieses explizite Ereignis wird erfasst, wenn ein Benutzer einen neuen Auftrag speichert, üblicherweise über die Transaktion VA01 in SAP. | ||
| Warum das wichtig ist Dies ist das primäre Start-Event des Order-to-Cash-Prozesses. Der Zeitpunkt ist entscheidend, um die gesamte Durchlaufzeit und die Anzahl eingehender Aufträge zu messen. Woher beziehen Erfasst in der Tabelle VBAK (Kopfdaten des Verkaufsbelegs) anhand des Erstellungsdatums (ERDAT) und der Erstellungszeit (ERZET). Der Transaktionscode ist in VBAK-TCODE gespeichert. Erfassung Ereignis auf Grundlage des Erstellungs-Timestamps (ERDAT, ERZET) in der Tabelle VBAK. Ereignistyp explicit | |||
| Rechnung erstellt | Kennzeichnet die Erstellung der Kundenrechnung oder des Fakturabelegs. Dieses explizite Ereignis erzeugt einen neuen Beleg im System und leitet damit den Zahlungsteil des Prozesses ein. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein startet die Messung der „Zahlungszykluszeit ab Rechnungsstellung“. Verzögerungen bei der Rechnungsstellung wirken sich direkt auf den Cashflow aus. Woher beziehen Erfasst in der Tabelle VBRK (Fakturabeleg: Kopfdaten) anhand des Erstellungsdatums (ERDAT). Die Verknüpfung mit dem Kundenauftrag oder der Lieferung ist in der Tabelle VBFA hinterlegt. Erfassung Ereignis auf Grundlage des Erstellungszeitstempels (ERDAT) in der Tabelle VBRK. Ereignistyp explicit | |||
| Warenausgang gebucht | Bei diesem wichtigen Ereignis geht das Eigentum an den Waren über und sie verlassen offiziell das Lager. Die explizite Finanzbuchung erstellt einen Materialbeleg und aktualisiert den Bestand. | ||
| Warum das wichtig ist Dies ist das Versandereignis und ein wichtiger Meilenstein für die Messung termingerechter Lieferungen und der Durchlaufzeiten. Es löst finanzielle Aktualisierungen aus und markiert einen unumkehrbaren Schritt in der physischen Auftragsabwicklung. Woher beziehen Erstellung eines Materialbelegs (MKPF/MSEG) mit einer Warenbewegungsart für den Warenausgang (z. B. 601), der mit dem Lieferbeleg verknüpft ist. Erfassung Erstellung eines Materialbelegs (MKPF/MSEG) mit einer Warenbewegungsart für den Warenausgang, verknüpft mit der Lieferung. Ereignistyp explicit | |||
| Zahlung eingegangen | Dieses Ereignis zeigt an, dass die Zahlung des Kunden eingegangen und der Rechnung zugeordnet wurde. Damit wird der offene Debitorenposten ausgeglichen. Es handelt sich um ein Buchungsereignis, das sich aus dem Ausgleich eines Finanzbelegs ableiten lässt. | ||
| Warum das wichtig ist Damit wird der Verkaufserlös endgültig vereinnahmt. Das Ereignis markiert den Endpunkt für die Messung der „Zahlungszykluszeit ab Rechnungsstellung“ und der gesamten „Durchlaufzeit der Auftragserfüllung“. Woher beziehen Abgeleitet aus den Ausgleichsbeleginformationen für den Debitorenposten in der Tabelle BSEG. Sind BSEG-AUGBL (Ausgleichsbeleg) und BSEG-AUGDT (Ausgleichsdatum) ausgefüllt, gilt die Zahlung als eingegangen. Erfassung Abgeleitet aus dem ausgefüllten Ausgleichsdatum (AUGDT) in der Tabelle BSEG für den Debitorenposten. Ereignistyp inferred | |||
| Auftrag storniert | Zeigt an, dass ein Kundenauftrag vor der Erfüllung storniert wurde. Dies wird üblicherweise erfasst, indem für alle relevanten Auftragspositionen ein „Absagegrund“ hinterlegt wird. | ||
| Warum das wichtig ist Dieser kritische Endpunkt bei einem Prozessabbruch unterstützt direkt die Kennzahl „Auftragsstornierungsquote“. Wann und warum Aufträge storniert werden, gibt Aufschluss über Probleme im Vertriebsprozess. Woher beziehen Abgeleitet aus dem ausgefüllten Feld VBAP-ABGRU (Absagegrund) für alle aktiven Positionen eines Kundenauftrags. Das Änderungsdatum ist in CDHDR/CDPOS zu finden. Erfassung Abgeleitet aus dem ausgefüllten Feld „Absagegrund“ (VBAP-ABGRU) für alle Positionen. Ereignistyp inferred | |||
| Bonitätsprüfung durchgeführt | Zeigt an, dass die automatische oder manuelle Bonitätsprüfung des Kunden für den Auftrag abgeschlossen ist. Dies wird üblicherweise aus einer Änderung des Gesamtbonitätsstatus des Belegs abgeleitet. | ||
| Warum das wichtig ist Die Bonitätsprüfung ist häufig ein kritischer Engpass. Die Dauer dieses Schritts zu messen, ist entscheidend für die „Analyse der Bearbeitungszeit von Bonitätsprüfungen“ und eine schnellere Auftragsbearbeitung. Woher beziehen Abgeleitet aus den Bonitätsstatusfeldern in der Tabelle VBUK (Verkaufsbeleg: Kopfstatus). Eine Änderung von VBUK-CMGST von „blockiert“ zu „freigegeben“ kennzeichnet diese Aktivität. Erfassung Abgeleitet aus Änderungen am Feld für den Gesamtbonitätsstatus (VBUK-CMGST). Ereignistyp inferred | |||
| Kommissionierung abgeschlossen | Zeigt an, dass alle Positionen der Lieferung physisch aus dem Lager kommissioniert wurden. Bei Verwendung von Warehouse Management (WM) lässt sich dies aus dem Status des Transportauftrags ableiten. | ||
| Warum das wichtig ist Die Analyse der Kommissionierzeit hilft, Lagerabläufe zu verbessern. Verzögerungen in diesem Schritt wirken sich direkt auf den gesamten Versandzeitplan und die Durchlaufzeit der Auftragsabwicklung aus. Woher beziehen Abgeleitet aus der Änderung des Kommissionierstatus der Lieferposition in der Tabelle LIPS-KOSTA auf „C“ (vollständig kommissioniert). Wenn WM aktiv ist, lässt sich das Ereignis aus der Bestätigung des Transportauftrags ableiten (Tabellen LTAK/LTAP). Erfassung Abgeleitet aus einer Änderung des Kommissionierstatus (LIPS-KOSTA) oder der Bestätigung des WM-Transportauftrags. Ereignistyp inferred | |||
| Kundenauftrag geändert | Bezeichnet eine Änderung an einem bestehenden Kundenauftrag nach dessen erstmaliger Erstellung. Änderungen an Feldern wie Menge, Preis oder Datum werden in den dafür vorgesehenen Änderungsbelegt Tabellen (CDHDR, CDPOS) erfasst. | ||
| Warum das wichtig ist Die Erfassung von Änderungen hilft, Nacharbeit, instabile Prozesse und Probleme mit der Datenqualität zu erkennen. Häufige Änderungen können auf Fehler bei der ursprünglichen Auftragserfassung hindeuten und zu Verzögerungen führen. Woher beziehen Abgerufen aus den Änderungsbelegtabellen CDHDR (Kopf) und CDPOS (Position) für OBJECTCLAS = 'VERKBELEG'. Timestamp und geändertes Feld lassen sich ermitteln. Erfassung Ereignis aus Änderungsbelegtabellen (CDHDR, CDPOS) für Verkaufsbelegobjekte. Ereignistyp explicit | |||
| Lieferblock gesetzt | Bezeichnet das Setzen eines Lieferblocks für einen Kundenauftrag, wodurch die Erstellung eines Lieferbelegs verhindert wird. Das Ereignis lässt sich explizit aus Änderungsprotokollen erfassen oder aus Statustabellen ableiten. | ||
| Warum das wichtig ist Diese Aktivität steht in direktem Zusammenhang mit der KPI „Blockierungsquote bei Kundenaufträgen“. Wenn Sie ermitteln, warum und wie oft Sperren gesetzt werden, können Sie Ursachen für Verzögerungen bei der Auftragsabwicklung aufdecken. Woher beziehen In Änderungsprotokollen (CDHDR/CDPOS) für das Feld VBAK-LIFSK zu finden. Alternativ lässt sich das Ereignis daran erkennen, dass das Feld VBAK-LIFSK befüllt ist. Erfassung Ereignis aus Änderungsbelegen für das Feld VBAK-LIFSK oder VBAP-LIFSP. Ereignistyp explicit | |||
| Liefernachweis bestätigt | Diese Aktivität steht für die Bestätigung, dass der Kunde die Ware erhalten hat. Sie wird erfasst, sobald der Zustellnachweis im System verbucht wird. Dabei wird häufig der Status des Lieferbelegs aktualisiert. | ||
| Warum das wichtig ist Dieses Ereignis liefert das tatsächliche Lieferdatum. Es ist entscheidend, um die „Leistung bei termingerechter Lieferung“ zuverlässig mit dem zugesagten Datum abzugleichen. Woher beziehen Abgeleitet aus dem Status des Zustellnachweises (VBUK-PODAT), der auf „C“ (Bestätigt) gesetzt wird. Das Bestätigungsdatum ist in VLPOD-PODAT gespeichert. Diese Funktion ist nicht immer implementiert. Erfassung Abgeleitet aus der Aktualisierung des POD-Status der Lieferung (VBUK-PODAT) oder einem Eintrag in der Tabelle VLPOD. Ereignistyp inferred | |||
| Lieferung erstellt | Dieses Ereignis kennzeichnet die Erstellung des Auslieferungsbelegs. Er weist das Lager an, mit Kommissionierung und Versand zu beginnen. Das explizite Ereignis wird aus dem Belegfluss erfasst. | ||
| Warum das wichtig ist Dies ist der erste Schritt der physischen Auftragsabwicklung. Die Zeit zwischen Auftragsbestätigung und Erstellung der Lieferung zeigt, wie schnell der Logistikprozess beginnt. Woher beziehen Erstellung eines Eintrags in der Tabelle LIKP (SD-Beleg: Kopfdaten der Lieferung). Die Verknüpfung mit dem Kundenauftrag wird in der Belegflusstabelle VBFA geführt. Erfassung Ereignis auf Grundlage des Erstellungs-Timestamps in der Tabelle LIKP, verknüpft über die Tabelle VBFA. Ereignistyp explicit | |||
| Rechnung storniert | Steht für die Rücknahme eines zuvor erstellten Fakturabelegs. Bei dieser expliziten Transaktion wird ein neuer Stornobeleg angelegt, der den ursprünglichen Beleg ausgleicht. | ||
| Warum das wichtig ist Die Erfassung von Rechnungsstornierungen hilft, Probleme bei der Preisgestaltung, Abweichungen beim Versand oder Datenfehler aufzudecken. Sie unterstützt die Kennzahl „Rechnungsabweichungsquote“. Woher beziehen Explizites Ereignis, erfasst durch die Erstellung eines Stornofakturabelegs (VBRK-VBTYP = 'N' oder 'O'). Die ursprüngliche Rechnung ist in VBRK-SFAKN referenziert. Erfassung Erstellung eines Stornobelegs in VBRK mit Verweis auf die ursprüngliche Rechnung. Ereignistyp explicit | |||
Anleitungen zur Datenextraktion
Schritte
- Programm entwickeln: Erstellen Sie über die Transaktion SE38 oder SE80 ein neues ausführbares ABAP-Programm. Darin wird die gesamte Extraktionslogik implementiert.
- Selektionsbild definieren: Legen Sie in Ihrem Programm ein Selektionsbild zum Filtern der Daten an. Fügen Sie Parameter für das Anlegedatum des Verkaufsbelegs (VBAK-ERDAT), die Verkaufsorganisation (VBAK-VKORG) und die Verkaufsbelegart (VBAK-AUART) hinzu. So lässt sich die Extraktion wiederverwenden und gezielt steuern.
- Daten deklarieren: Definieren Sie die internen Tabellen und Strukturen, in denen die Daten aus den verschiedenen SAP-Tabellen gespeichert werden, zum Beispiel VBAK, VBAP, VBFA, CDHDR, CDPOS, VBRK und BSAD. Definieren Sie außerdem die endgültige Ausgabestruktur für das Event Log mit den erforderlichen Attributen.
- Basisdaten der Kundenaufträge auslesen: Schreiben Sie die erste SELECT-Anweisung, um anhand der Eingaben im Selektionsbild die Kundenauftragsköpfe (VBAK) und -positionen (VBAP) abzurufen. Daraus entsteht der zentrale Datensatz der zu analysierenden Cases.
- Ereignis „Angelegt“ extrahieren: Durchlaufen Sie die ausgewählten VBAK-Datensätze. Füllen Sie für jeden Datensatz die Event-Log-Struktur mit der Aktivität „Kundenauftrag angelegt“ und verwenden Sie VBAK-ERDAT und VBAK-ERZET als StartTime.
- Änderungsereignisse extrahieren: Lesen Sie für die ausgewählten Kundenaufträge Datensätze aus CDHDR und CDPOS aus, bei denen OBJECTCLAS den Wert 'VERKBELEG' hat. Ermitteln Sie anhand der Ergebnisse bestimmte Feldänderungen. Eine Änderung an VBAK-LIFSK weist beispielsweise auf das Ereignis „Liefersperre gesetzt“ hin, eine Änderung an VBUK-CMGST auf „Kreditprüfung durchgeführt“. Andere relevante Änderungen können als „Kundenauftrag geändert“ protokolliert werden.
- Belegflussdaten extrahieren: Fragen Sie für die ausgewählten Kundenaufträge die Belegflusstabelle VBFA ab. Sie verknüpft Kundenaufträge mit nachfolgenden Belegen wie Lieferungen, Warenbewegungen und Rechnungen. Rufen Sie alle zugehörigen Belege für die weitere Verarbeitung ab.
- Liefer- und Erfüllungsereignisse extrahieren: Fragen Sie anhand der Lieferbelegnummern aus VBFA LIKP und LIPS ab, um Ereignisse vom Typ „Lieferung angelegt“ zu erfassen. Lesen Sie MKPF und MSEG für Warenausgangsbelege mit der Bewegungsart '601' aus, um das Ereignis „Warenausgang gebucht“ zu erfassen. Wenn Warehouse Management aktiv ist, fragen Sie LTAK und LTAP ab, um den Bestätigungszeitpunkt der letzten Transportauftragsposition und damit „Kommissionierung abgeschlossen“ zu ermitteln. Prüfen Sie den Lieferkopfstatus VBUK-PODAT auf „Abliefernachweis bestätigt“.
- Fakturierungs- und Zahlungsereignisse extrahieren: Fragen Sie anhand der Fakturabelegnummern aus VBFA VBRK und VBRP ab, um die Ereignisse „Rechnung erstellt“ und „Rechnung storniert“ (wenn VBRK-FKSTO = 'X') zu erfassen. Um „Zahlung eingegangen“ zu ermitteln, verknüpfen Sie die Rechnung aus VBRK mit dem Buchhaltungsbeleg in BKPF und suchen Sie anschließend in BSAD nach dem Ausgleichsbeleg und dem Ausgleichsdatum.
- Statusbasierte Ereignisse extrahieren: Leiten Sie Geschäftsereignisse aus den Statustabellen VBUP (Positionsstatus) und VBUK (Kopfstatus) ab. Eine Position gilt beispielsweise als „Auftragsposition abgeschlossen“, wenn VBUP-GBSTA den Wert 'C' hat. Ein Auftrag gilt als „Auftrag storniert“, wenn für alle relevanten Positionen ein „Ablehnungsgrund“ (VBAP-ABGRU) gesetzt ist.
- Daten zusammenführen und formatieren: Fassen Sie alle erfassten Ereignisse in einer einzigen internen Tabelle zusammen. Stellen Sie sicher, dass alle Attribute (SalesOrder, Activity, StartTime, User usw.) für jeden Ereignisdatensatz korrekt ausgefüllt sind. Fügen Sie die Zeitstempel SourceSystem und LastDataUpdate hinzu.
- Ausgabedatei erstellen: Exportieren Sie die endgültige interne Tabelle mit dem Funktionsbaustein GUI_DOWNLOAD oder der Methode cl_gui_frontend_services=>gui_download als CSV-Datei auf den lokalen Rechner des Benutzers. Speichern Sie die Datei mit UTF-8-Kodierung.
Konfiguration
- Voraussetzungen: ABAP-Entwicklerberechtigungen, zum Beispiel Zugriff auf die Transaktion SE38, sowie Leseberechtigungen für alle erforderlichen SAP-Tabellen, darunter VBAK, VBAP, CDHDR, CDPOS, VBFA, LIKP, LIPS, VBRK, VBRP, MKPF, MSEG und BSAD.
- Selektionsparameter: Das Programm muss ein Selektionsbild mit Filterparametern enthalten. Wichtige Parameter sind:
- Datumsbereich: Ein verpflichtender Datumsbereich für das Anlegedatum der Kundenaufträge (VBAK-ERDAT). Beginnen Sie mit einem aktuellen Zeitraum von 3 bis 6 Monaten, damit der Datensatz überschaubar bleibt.
- Verkaufsorganisation: Filtern Sie nach VBAK-VKORG, um die Analyse auf bestimmte Geschäftseinheiten zu begrenzen.
- Verkaufsbelegart: Filtern Sie nach VBAK-AUART, um nur relevante Auftragsarten, etwa Standardaufträge, einzubeziehen und andere wie Angebote und Retouren auszuschließen.
- Leistungsaspekte: Die Extraktion aus Änderungsprotokollen (CDHDR, CDPOS) und dem Belegfluss (VBFA) kann bei großen Datenmengen sehr langsam sein. Optimieren Sie das Programm so, dass in WHERE-Klauseln Indexfelder verwendet werden. Planen Sie sehr große Extraktionen über die Transaktion SM36 als Hintergrundjob außerhalb der Spitzenzeiten ein.
- Aktivierung des Änderungsprotokolls: Diese Methode setzt die Änderungsbelegfunktion von SAP voraus. Prüfen Sie, ob die Änderungsprotokollierung für wichtige Datenelemente wie LIFSK, CMGST und ABGRU aktiviert ist. Dies lässt sich für das Objekt VERKBELEG über die Transaktion SCDO kontrollieren.
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 Lesezugriff auf die zugrunde liegende SAP-ECC-Datenbank haben. Für die Verbindung und Ausführung der Abfragen benötigen Sie ein Datenbank-Client-Tool wie DBeaver, SQL Server Management Studio oder Oracle SQL Developer.
- SQL-Skript abrufen: Kopieren Sie die vollständige SQL-Abfrage aus dem Abschnitt „query“ dieses Dokuments.
- 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 passenden Anmeldedaten.
- Abfrage konfigurieren: Fügen Sie das SQL-Skript in ein neues Abfragefenster ein. Suchen Sie im Hauptausdruck Common Table Expression (CTE) mit dem Namen SalesOrders den Konfigurationsabschnitt. Ersetzen Sie die Platzhalter für das Startdatum ('{StartDate}'), das Enddatum ('{EndDate}'), die Verkaufsorganisationen ('{SalesOrgs}') und die Belegarten ('{DocTypes}') durch die tatsächlichen Werte für Ihre Analyse.
- Abfrage ausführen: Führen Sie das konfigurierte SQL-Skript aus. Je nach Zeitraum und Größe Ihrer SAP-Datenbank kann die Abfrage mehrere Minuten dauern.
- Ergebnisse prüfen: Nach Abschluss der Abfrage wird eine Ergebnismenge angezeigt. Prüfen Sie kurz, ob die erwarteten Spalten (SalesOrder, Activity, StartTime usw.) enthalten sind und Datensätze für verschiedene Aktivitäten zurückgegeben werden.
- Daten exportieren: Speichern Sie die Ergebnismenge über die Exportfunktion Ihres Datenbank-Clients als CSV-Datei. Wählen Sie einen aussagekräftigen Dateinamen, zum Beispiel SAP_O2C_Event_Log.csv.
- Für ProcessMind formatieren: Öffnen Sie die CSV-Datei in einem Tabelleneditor. Prüfen Sie, ob die Spaltenüberschriften exakt den erforderlichen Attributen entsprechen, zum Beispiel SalesOrder, Activity und StartTime. Achten Sie darauf, dass StartTime und LastDataUpdate ein einheitliches, von ProcessMind unterstütztes Datums- und Zeitformat verwenden, etwa YYYY-MM-DD HH:MI:SS.
- In ProcessMind hochladen: Laden Sie die fertig formatierte CSV-Datei in Ihr ProcessMind-Projekt hoch.
Konfiguration
- Datumsbereich: Die Abfrage verwendet die Platzhalter ('{StartDate}' und '{EndDate}'), um Kundenaufträge nach ihrem Anlegedatum (VBAK.ERDAT) zu filtern. Ein typischer Analysezeitraum umfasst 3 bis 6 Monate. So erhalten Sie eine repräsentative Stichprobe, ohne die Datenbank übermäßig zu belasten.
- Filter für Verkaufsorganisationen: Verwenden Sie den Platzhalter '{SalesOrgs}', um die Extraktion auf bestimmte Verkaufsorganisationen zu begrenzen, zum Beispiel '1000' und '2000'. Das grenzt die Analyse gezielt ein und verbessert die Abfrageleistung.
- Filter für Belegarten: Verwenden Sie den Platzhalter '{DocTypes}', um bestimmte Kundenauftragsarten auszuwählen, zum Beispiel 'OR' für einen Standardauftrag. So schließen Sie irrelevante Belege wie kostenlose Lieferungen oder Retouren aus dem Hauptprozess aus.
- Quellsystemkennung: Der fest codierte Platzhalter '{SourceSystemName}' kennzeichnet jeden Datensatz mit dem Ursprungssystem. Ersetzen Sie ihn durch einen aussagekräftigen Namen für Ihre SAP-ECC-Instanz, zum Beispiel SAP_ECC_PRD.
- Datenbankkompatibilität: Die Funktion zum Zusammenführen von Datums- und Zeitfeldern, [Your DB-specific timestamp function], ist ein Platzhalter. Ersetzen Sie sie durch die passende Funktion für Ihre Datenbank, zum Beispiel 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: Für diese Methode benötigen Sie direkte Datenbankzugangsdaten mit Lesezugriff. Der Datenbankbenutzer muss auf alle in der Abfrage referenzierten Tabellen zugreifen dürfen, darunter VBAK, VBAP, VBFA, CDHDR, CDPOS, LIKP, VBRK und BSAD.
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 <> ''; Möchten Sie loslegen?
Nutzen Sie dieses Daten-Template, um das volle Potenzial Ihrer Auftragsabwicklung im Vertrieb auszuschöpfen. Beginnen Sie noch heute damit, die Effizienz zu steigern und den Cashflow zu beschleunigen.
Optimieren Sie noch heute die Auftragsabwicklung im Vertrieb
Beseitigen Sie Engpässe, verkürzen Sie die Zykluszeit um 30 % und verbessern Sie schnell Ihren Cashflow.
Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.