Ihr Daten-Template für den Retouren- & Erstattungsprozess
Ihr Daten-Template für den Retouren- & Erstattungsprozess
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Verfolgung
- Extraktionsanleitung
Attribute der Retouren- und Rückerstattungsabwicklung
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Der Name einer spezifischen Geschäftsaktivität oder eines Ereignisses, das innerhalb des Retouren- und Rückerstattungsprozesses stattfand. | ||
| Beschreibung Dieses Attribut beschreibt einen einzelnen Schritt oder Meilenstein im Retouren-Lebenszyklus. Aktivitäten repräsentieren die durchgeführte Arbeit, wie 'Retourenauftrag genehmigt' oder 'Artikelprüfung abgeschlossen'. Diese werden aus Statusänderungen, Dokumentenerstellungen oder spezifischen Benutzeraktionen in SAP S/4HANA abgeleitet. Die Analyse der Reihenfolge und Häufigkeit dieser Aktivitäten ist der Kern des Process Mining. Es hilft, die Prozesslandkarte zu visualisieren, häufige und seltene Prozesspfade zu identifizieren und Aktivitäten zu lokalisieren, die häufig wiederholt werden, was auf Nacharbeiten oder Ineffizienzen hindeutet. Bedeutung Aktivitäten bilden das Rückgrat der Prozesskarte und ermöglichen die Visualisierung und Analyse des Prozessflusses, der Datenquelle Aktivitätsnamen werden in der Regel aus einer Kombination von Daten abgeleitet, etwa aus Belegstatusänderungen (VBUK/VBUP), Erstellungsereignissen in Kopftabellen wie VBAK (Verkaufsbelege) und BKPF (Buchhaltungsbelege) sowie Warenbewegungsstati in MSEG. Beispiele Retourenanfrage initiiertWare im Lager eingegangenGutschrift erstelltRefund Processed | |||
| Ereigniszeit EventTime | Der genaue Timestamp, der angibt, wann eine spezifische Aktivität stattfand. | ||
| Beschreibung Event Time erfasst Datum und Uhrzeit, zu der ein Ereignis im System registriert wurde. Dieser Timestamp ist essenziell für die chronologische Sortierung und alle zeitbasierten Analysen. Im Process Mining dient dieses Attribut zur Berechnung von Durchlaufzeiten, zur Ermittlung der Dauer einzelner Schritte und zur Performance-Analyse. Es bildet die Grundlage, um Bottlenecks zu identifizieren, SLAs zu überwachen und die zeitliche Dynamik des Retourenprozesses zu verstehen. Bedeutung Dieser Timestamp ist essenziell für die Reihenfolge der Events, die Berechnung aller Dauern und Zykluszeiten sowie die Identifizierung von Prozessverzögerungen. Datenquelle Typischerweise aus Datums- und Zeitfeldern bezüglich Dokumentenerstellung oder Statusänderungen bezogen, wie ERDAT (Erstellungsdatum) und ERZET (Erstellungszeit) in Tabellen wie VBAK, LIKP und BKPF, oder dem Buchungsdatum (BUDAT) in Buchhaltungsbelegen. Beispiele 2023-10-26T10:05:00Z2023-10-27T14:30:15Z2023-10-28T09:00:00Z | |||
| Retourenfall-ID ReturnCaseId | Der eindeutige Identifikator für einen einzelnen Kundenretourenprozess, der alle zugehörigen Aktivitäten von der Initiierung bis zum Abschluss verknüpft. | ||
| Beschreibung Die Retourenfall-ID dient als primärer Identifikator, der alle Events und Aktivitäten eines einzelnen Retourenvorgangs gruppiert. Jeder Kundenretourenantrag erhält eine eindeutige ID, die eine End-to-End-Verfolgung des gesamten Prozesses ermöglicht. Im Process Mining ist dieses Attribut grundlegend für die Rekonstruktion des Prozessflusses. Es ermöglicht die Analyse von Falldauern, Prozessvarianten und Engpässen, indem disparate Events wie 'Retourenanfrage initiiert', 'Wareneingang' und 'Rückerstattung bearbeitet' zu einer kohärenten Zeitleiste für jede spezifische Retoure verknüpft werden. Bedeutung Dies ist der essenzielle Schlüssel, um eine Retoure von Anfang bis Ende zu verfolgen, und ermöglicht alle Analysen auf Case-Ebene, einschließlich Zykluszeit und Prozessvarianten-Erkennung. Datenquelle Dies ist typischerweise die Verkaufsbelegnummer (VBELN) aus der Retourenauftragskopftabelle VBAK, wobei die Belegkategorie (VBTYP) eine Retoure anzeigt. Beispiele 600001896000019060000191 | |||
| Letzte Datenaktualisierung LastDataUpdateTimestamp | Der Timestamp, der angibt, wann die Daten für dieses Ereignis zuletzt aktualisiert oder extrahiert wurden. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion oder -aktualisierung. Es liefert Metadaten über die Aktualität des analysierten Datensatzes. Es ist wichtig für das Verständnis der Aktualität der Process Mining Analyse. Benutzer können sehen, wie aktuell die Daten sind, was besonders relevant für das operative Monitoring und Dashboards ist, die laufende Fälle verfolgen. Bedeutung Zeigt die Aktualität der Daten an, was entscheidend ist, um sicherzustellen, dass Analysen und Dashboards auf aktuellen Informationen basieren. Datenquelle Dies wird typischerweise generiert und auf dem Datensatz gestempelt, zum Zeitpunkt der Datenextraktion durch das ETL- oder Datenpipeline-Tool. Beispiele 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Quellsystem-ID SourceSystemId | Bezeichner für das Quellsystem, aus dem die `Daten` extrahiert wurden. | ||
| Beschreibung Dieses Attribut spezifiziert das führende System, aus dem die Event-Daten stammen. Für diesen Prozess wäre dies typischerweise die SAP S/4HANA Instanz-ID. In Umgebungen mit mehreren Systemen ist dieses Feld entscheidend für die Datenherkunft, Fehlerbehebung und Sicherstellung der Datenintegrität. Es hilft, Daten zu differenzieren, wenn Retouren über verschiedene ERP-Instanzen verarbeitet oder mit externen Systemen wie einem Lagerverwaltungssystem integriert werden. Bedeutung Bietet entscheidenden Kontext für Datenherkunft und -abstammung, insbesondere in Multi-System-Landschaften, um Datennachvollziehbarkeit und Vertrauen zu gewährleisten. Datenquelle Dieser Wert ist in der Regel statisch und wird während der Datenextraktion konfiguriert. Er kann aus den administrativen Informationen des SAP-Systems, wie der System-ID (SID), abgerufen werden. Beispiele S4H_PROD_100S4Q_DEV_200 | |||
| Benutzername UserName | Die Benutzer-ID des Mitarbeiters, der die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut identifiziert den spezifischen Benutzer oder Systemagenten, der für die Erledigung einer Aufgabe verantwortlich ist, wie die Genehmigung einer Retoure oder die Erstellung einer Gutschrift. In SAP wird dies oft in Feldern erfasst, die den Benutzer protokollieren, der ein Dokument erstellt oder geändert hat. Die Analyse nach Benutzern hilft, leistungsstarke Einzelpersonen oder Teams, Schulungsbedarfe und die Arbeitslastverteilung zu identifizieren. Es ist auch unerlässlich für die Untersuchung von Abweichungen, da es Prozessaktionen mit spezifischen Personen verknüpft und Compliance- und Audit-Bemühungen unterstützt. Bedeutung Ordnet Prozessaktivitäten spezifischen Benutzern zu, um Analysen zu Teamleistung, Arbeitslast und Compliance zu ermöglichen. Datenquelle Häufig in Belegkopftabellen zu finden, wie z.B. ERNAM (Erstellt von) in VBAK (Verkaufsaufträge), LIKP (Lieferungen) und BKPF (Buchhaltungsbelege). Benutzerdetails können aus der Benutzermastertabelle USR21 angereichert werden. Beispiele CBROWNASMITHWF_BATCH | |||
| Endzeit des Events EventEndTime | Der Timestamp, der den Abschluss einer Aktivität markiert und zur Berechnung ihrer Dauer verwendet wird. | ||
| Beschreibung Während die Startzeit (EventTime) den Beginn einer Aktivität markiert, kennzeichnet die EventEndTime deren Abschluss. Bei vielen systemgenerierten Events sind die Start- und Endzeiten identisch und repräsentieren ein sofortiges Ereignis. Für Aktivitäten mit messbarer Dauer, wie beispielsweise 'Artikelprüfung', ist dieses Attribut jedoch entscheidend. Dieses Attribut ermöglicht die direkte Berechnung der Bearbeitungszeit einer Aktivität. Dies ist grundlegend für die Leistungsanalyse und hilft zu identifizieren, welche spezifischen Schritte – und nicht nur die Lücken dazwischen – die meiste Zeit in Anspruch nehmen. Bedeutung Ermöglicht die präzise Berechnung individueller Datenquelle Dies ist oft abgeleitet. Für einige Aktivitäten könnte es ein separates Feld sein. Häufiger ist es die StartTime der nachfolgenden Aktivität im Case. Beispiele 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| Kunden-ID CustomerId | Der eindeutige Identifikator für den Kunden, der die Retoure initiiert. | ||
| Beschreibung Dieses Attribut identifiziert den Kunden, der die Retoure angefordert hat. Es verknüpft die Prozessinstanz mit einer spezifischen Partei in den Kundenstammdaten. Die Analyse von Retouren nach Kunden hilft, Muster zu erkennen, wie Kunden mit ungewöhnlich hohen Retourenquoten, die auf betrügerisches Verhalten oder Unzufriedenheit hindeuten könnten. Es ermöglicht auch eine Segmentierung des Retourenprozesses basierend auf Kundentyp, Wert oder Historie, was maßgeschneiderte Service-Levels erlaubt. Bedeutung Verknüpft Retouren mit spezifischen Kunden, ermöglicht die Analyse des Kundenverhaltens, die Segmentierung und die Identifizierung häufiger Rücksender. Datenquelle Im Kundenfeld (KUNNR) der Retourenauftrags-Kopftabelle (VBAK) gefunden. Beispiele CUST-001234CUST-005678CUST-009012 | |||
| Produkt-ID ProductId | Der eindeutige Identifikator für den Artikel, der zurückgesendet wird. | ||
| Beschreibung Dieses Attribut spezifiziert das Material oder Produkt, das Gegenstand der Retoure ist. Es verknüpft den Retourenprozess mit einem spezifischen Artikel im Produktkatalog. Die Analyse von Retouren nach Produkt ist grundlegend, um Artikel mit hohen Retourenquoten zu identifizieren, die auf Qualitätsmängel, schlechte Produktbeschreibungen oder Fertigungsprobleme hindeuten könnten. Diese Daten helfen Unternehmen, fundierte Entscheidungen über Produktdesign, Lieferantenmanagement und Bestandsstrategie zu treffen. Bedeutung Verknüpft den Retourenprozess mit spezifischen Produkten, ermöglicht die Analyse von Artikel-Retourenquoten und die Identifizierung von Qualitäts- oder Beschreibungsfehlern. Datenquelle Im Materialnummernfeld (MATNR) der Retourenauftragspositionstabelle (VBAP) oder der Retourenlieferpositionstabelle (LIPS) gefunden. Beispiele FG-10023HW-45981SW-LICENSE-PREM | |||
| Rückerstattungsbetrag RefundAmount | Der endgültige monetäre Wert der an den Kunden ausgezahlten Rückerstattung. | ||
| Beschreibung Dieses Attribut repräsentiert den tatsächlichen Betrag, der dem Kunden nach Abschluss des Retourenprozesses gutgeschrieben oder erstattet wird. Dieser Wert wird in Finanzdokumenten wie Gutschriften erfasst. Dies ist eine wichtige Finanzkennzahl, die in verschiedenen Analysen verwendet wird. Es ist essenziell für das Dashboard 'Analyse von Rückerstattungsbetragsdiskrepanzen', um es mit dem angefragten Betrag zu vergleichen. Es ermöglicht auch die Segmentierung von Retouren nach Wert, um zu identifizieren, ob hochpreisige Retouren einem anderen Prozess folgen oder länger zur Lösung benötigen. Bedeutung Verfolgt die finanziellen Auswirkungen von Retouren und ist essenziell für die Analyse der Rückerstattungsgenauigkeit, die Identifizierung hochpreisiger Fälle und das Verständnis der Gesamtkosten. Datenquelle Stammt aus dem Netto-Wertfeld (NETWR) des Gutschriftsbelegs, zu finden in Tabellen wie VBRK (Fakturabelegkopf) oder BSEG (Buchhaltungsbelegsegment). Beispiele 125.50999,0049.99 | |||
| Rückgabegrund ReturnReason | Der vom Kunden angegebene Grund für die Rücksendung des Artikels. | ||
| Beschreibung Dieses Attribut erfasst den vom Kunden angegebenen Retourengrund, wie 'Defekter Artikel', 'Falsche Größe' oder 'Nicht mehr benötigt'. Dies wird typischerweise aus einer vordefinierten Liste von Grundcodes während des Retoureninitiierungsprozesses ausgewählt. Die Analyse der Retourengründe ist entscheidend, um Produktqualitätsprobleme zu identifizieren, Produktbeschreibungen zu verbessern oder Verkaufsprozesse zu verfeinern. Es bietet direkten Einblick in die Kundenunzufriedenheit und hilft, Bereiche für Geschäftsverbesserungen zu priorisieren, um die gesamte Retourenquote zu reduzieren. Bedeutung Bietet entscheidende Einblicke, warum Retouren erfolgen, und ermöglicht eine Ursachenanalyse, um Produktqualität, Erfüllungsfehler oder Kundenerwartungslücken anzugehen. Datenquelle Typischerweise in der Retourenverkaufsauftragspositionstabelle (VBAP) gespeichert, im Feld ABGRU (Grund für Ablehnung von Verkaufsbelegen). Beispiele 001 - Schlechte Qualität002 - Transportschaden005 - Falscher Artikel versendet | |||
| `Verkaufsorganisation` SalesOrganization | Die Organisationseinheit, die für den ursprünglichen Verkauf und die Retoure verantwortlich ist. | ||
| Beschreibung Die Verkaufsorganisation ist ein wichtiges Element der Organisationsstruktur in SAP, das eine Einheit darstellt, die für den Verkauf und die Distribution von Produkten und Dienstleistungen verantwortlich ist. Sie wird der Retourentransaktion zugeordnet. Dieses Attribut ermöglicht das Filtern und Vergleichen des Retourenprozesses über verschiedene Geschäftseinheiten, Regionen oder Divisionen hinweg. Es hilft zu identifizieren, ob bestimmte Verkaufsorganisationen höhere Retourenquoten oder weniger effiziente Retourenabwicklungsprozesse aufweisen, und bietet eine Grundlage für die Analyse der Organisationsleistung. Bedeutung Ermöglicht den Vergleich der Retourenprozessleistung und -quoten über verschiedene Geschäftseinheiten, Regionen oder Vertriebskanäle hinweg. Datenquelle Im Vertriebsorganisationsfeld (VKORG) der Retourenauftrags-Kopftabelle (VBAK) gefunden. Beispiele 10002100US01 | |||
| Angefragter Rückerstattungsbetrag RequestedRefundAmount | Der Rückerstattungsbetrag, der ursprünglich angefordert oder zu Beginn des Prozesses erwartet wurde. | ||
| Beschreibung Dieses Attribut erfasst den Wert der zurückgesendeten Ware gemäß der ursprünglichen Retourenanfrage. Es dient als Basis, mit der der endgültige Rückerstattungsbetrag verglichen werden kann. Dieses Feld ist speziell für das Dashboard 'Analyse von Rückerstattungsbetragsdiskrepanzen' erforderlich. Der Vergleich des angefragten Betrags mit dem tatsächlichen Rückerstattungsbetrag hilft, Probleme wie Teilerstattungen aufgrund von Artikelschäden, Wiederauffüllungsgebühren oder andere Anpassungen zu identifizieren, wodurch finanzielle Genauigkeit und Transparenz gewährleistet werden. Bedeutung Dient als Grundlage zur Messung der Rückerstattungsgenauigkeit und hilft, Diskrepanzen zwischen erwarteten und tatsächlichen Rückerstattungsbeträgen zu identifizieren und zu analysieren. Datenquelle Typischerweise aus dem Nettowert der Artikel des ursprünglichen Retourenverkaufsauftrags bezogen. Dies wäre der Nettowert (NETWR) aus den entsprechenden Positionen in der Tabelle VBAP. Beispiele 125.501050,0049.99 | |||
| Bearbeiter ProcessingAgent | Der spezifische Agent oder die Ressourcengruppe, die für die Bearbeitung einer manuellen Aktivität verantwortlich ist. | ||
| Beschreibung Dieses Attribut identifiziert die Person oder das Team, die/das eine bestimmte Aufgabe ausgeführt hat. Es kann spezifischer sein als der 'Benutzername', indem es sich auf eine Rolle oder ein Team bezieht, insbesondere in einer Shared-Services-Umgebung. Dies ist wertvoll für das Dashboard 'Effizienz der Rückerstattungsgenehmigung', um die Leistung verschiedener Agenten oder Teams zu analysieren. Es hilft, die Arbeitslastverteilung zu verstehen, Schulungsbedarfe zu identifizieren und Top-Performer oder Teams zu erkennen, die Best Practices teilen könnten. Bedeutung Ermöglicht die Performance-Analyse auf Agenten- oder Teamebene, hilft bei der Arbeitslastverwaltung, identifiziert Schulungsmöglichkeiten und verbessert die Effizienz. Datenquelle Diese Information könnte über SAP Business Partner Funktionen verfügbar sein, wenn Agenten zugeordnet sind, oder sie könnte aus der Abteilung oder Rolle des Benutzers in der HR-Organisationsstruktur abgeleitet werden. Beispiele Tier 1 SupportLagerinspektionsteamFinanzabteilung - Kreditoren | |||
| Case-Zykluszeit CycleTime | Die gesamte verstrichene Zeit von der Initiierung bis zum Abschluss eines Retourenfalls. | ||
| Beschreibung Diese berechnete Metrik misst die End-to-End-Dauer des gesamten Retourenprozesses für einen einzelnen Fall. Sie wird typischerweise als Zeitdifferenz zwischen dem ersten und letzten Event berechnet, z. B. von 'Retourenanfrage initiiert' bis 'Retourenfall abgeschlossen'. Die Zykluszeit ist ein primärer KPI für die Prozesseffizienz. Sie wird im Dashboard 'Gesamte Retouren-Durchlaufzeit' verwendet, um die Leistung zu überwachen, Benchmarks zu setzen und Trends zu identifizieren. Die Analyse der Faktoren, die mit längeren Zykluszeiten korrelieren, wie Produkttyp oder Retourengrund, kann systemische Ineffizienzen aufzeigen. Bedeutung Dies ist ein fundamentaler KPI zur Messung der gesamten Prozesseffizienz und wirkt sich direkt auf die Kundenzufriedenheit und Betriebskosten aus. Datenquelle Dies ist ein berechnetes Feld. Es wird berechnet, indem die Differenz zwischen dem maximalen und minimalen EventTime für jede eindeutige ReturnCaseId ermittelt wird. Beispiele 5T 4h 30m12T 2h 15m2T 8h 0m | |||
| Einhaltung der Retourenrichtlinie ReturnPolicyAdherence | Ein Flag, das anzeigt, ob der Retouren-`Case` der definierten Retourenrichtlinie entspricht. | ||
| Beschreibung Dieses berechnete boolesche Attribut gibt an, ob eine Retoure die in der anwendbaren Retourenrichtlinie festgelegten Kriterien erfüllt. Die Logik könnte zum Beispiel prüfen, ob die Retoure innerhalb des zulässigen Zeitrahmens initiiert wurde oder ob der Retourengrund für das Produkt gültig ist. Dieses Attribut unterstützt direkt das Dashboard 'Übersicht zur Einhaltung der Retourenrichtlinie'. Es quantifiziert die Compliance-Raten und ermöglicht das Eintauchen in nicht-konforme Fälle, um die Gründe für Abweichungen zu verstehen, was hilft, Richtlinien effektiver durchzusetzen. Bedeutung Quantifiziert die Einhaltung von Geschäftsregeln und hilft, Richtlinienverstöße zu identifizieren und zu reduzieren, die die Rentabilität beeinträchtigen oder Prozessausnahmen verursachen können. Datenquelle Berechnet basierend auf Geschäftsregeln. Zum Beispiel (Retoureninitiierungsdatum - Ursprüngliches Kaufdatum) <= [Erlaubte Retourentage]. Dies erfordert das ursprüngliche Kaufdatum und die Richtlinienregeln. Beispiele truefalsch | |||
| Einhaltung der Rückerstattungs-SLA RefundSlaAdherence | Ein Flag, das anzeigt, ob die Rückerstattung innerhalb des `Service Level Agreement` (SLA)-Ziels verarbeitet wurde. | ||
| Beschreibung Dieses berechnete Attribut prüft, ob die Aktivität 'Rückerstattung bearbeitet' am oder vor dem 'Rückerstattungs-SLA-Zieldatum' stattfand. Es liefert einen einfachen True/False-Indikator für die SLA-Compliance jedes Falls. Dies ist die Kernmetrik für das Dashboard 'Überwachung der Rückerstattungs-SLA-Einhaltung' und den KPI 'Rückerstattungs-SLA-Einhaltungsrate'. Es hilft, die Leistung im Vergleich zu Kundenverpflichtungen zu messen und Fälle zu identifizieren, die Erwartungen nicht erfüllten, was eine Ursachenanalyse von Verzögerungen ermöglicht. Bedeutung Misst direkt die Leistung anhand kundenorientierter Verpflichtungen und ist somit ein kritischer Indikator für Servicequalität und Kundenzufriedenheit. Datenquelle Berechnet durch den Vergleich der Beispiele truefalsch | |||
| Ergebnis der Artikelprüfung ItemInspectionOutcome | Das Ergebnis der physischen Prüfung des retournierten Artikels. | ||
| Beschreibung Dieses Attribut erfasst das Ergebnis des Prüfprozesses, der nach Wareneingang im Lager durchgeführt wird. Häufige Ergebnisse sind 'Akzeptiert', 'Abgelehnt - Beschädigt' oder 'Akzeptiert - Wiederverkäuflich'. Diese Daten liefern entscheidenden Kontext für nachfolgende Prozessschritte. Sie bestimmen, ob eine vollständige Rückerstattung, eine Teilerstattung oder keine Rückerstattung erfolgt. Die Analyse dieses Ergebnisses hilft, Gründe für Ablehnungen zu identifizieren und kann Feedback zu Produktverpackung oder Versandpartnern geben, wenn Artikel häufig beim Transport beschädigt werden. Bedeutung Erläutert den Entscheidungsprozess hinter Rückerstattungsgenehmigungen oder -ablehnungen und liefert wertvolle Datenquelle Diese Information kann in einem Prüflos des Qualitätsmanagementmoduls (QM) erfasst werden, oder als Status- oder Grundcode in der Retourenlieferposition (LIPS). Sie kann auch in einem kundenspezifischen Feld existieren. Beispiele Angenommen - WiederverkäuflichAngenommen - Zur AufbereitungAbgelehnt - Vom Kunden verursachter SchadenAbgelehnt - Falscher Artikel zurückgesendet | |||
| Gutschriftsnummer CreditMemoNumber | Der eindeutige Identifikator für den Gutschriftsbeleg, der die Rückerstattung autorisiert. | ||
| Beschreibung Eine Gutschrift ist der Fakturabeleg, der das Kundenkonto offiziell für die zurückgesandten Artikel gutschreibt. Dieses Die Verfolgung der Gutschriftsnummer ist entscheidend für die Analyse des finanziellen Abwicklungsteils des Retourenprozesses. Sie markiert einen kritischen Meilenstein, der oft die tatsächliche Rückerstattungszahlung auslöst, und ist für die finanzielle Abstimmung und Prüfung notwendig. Bedeutung Stellt die offizielle Finanztransaktion für die Rückerstattung dar, entscheidend für die Verfolgung der letzten Prozessphasen und für die Finanzprüfung. Datenquelle Dies ist die Fakturabelegnummer (VBELN) aus der Fakturabelegkopftabelle (VBRK), wobei die Belegkategorie eine Gutschrift anzeigt. Beispiele 900003459000034690000347 | |||
| Ist automatisiert IsAutomated | Ein Flag, das anzeigt, ob eine `Aktivität` von einem System oder einem Menschen durchgeführt wurde. | ||
| Beschreibung Dieses boolesche Attribut unterscheidet zwischen Aktivitäten, die automatisch von einem System (z. B. einem Workflow oder Hintergrundjob) ausgeführt werden, und solchen, die manuell von einem Benutzer durchgeführt werden. Es ist essenziell für die Berechnung des KPIs 'Automatisierte Rückerstattungsgenehmigungsrate' und zur Identifizierung von Automatisierungsmöglichkeiten. Durch das Filtern nach manuellen Aufgaben können Unternehmen ihre Prozessverbesserungsbemühungen auf Bereiche konzentrieren, in denen die Automatisierung die größten Vorteile in Bezug auf Geschwindigkeit, Kosten und Genauigkeit bringen könnte. Bedeutung Unterscheidet zwischen manuellen und automatisierten Aufgaben, was entscheidend ist für die Identifizierung von Automatisierungsmöglichkeiten und die Messung des Einflusses der digitalen Transformation. Datenquelle Dies wird typischerweise basierend auf dem Benutzernamen abgeleitet. Zum Beispiel, wenn der Benutzer 'WF_BATCH' oder eine andere System-ID ist, wird die Aktivität als automatisiert gekennzeichnet. Beispiele truefalsch | |||
| Ist Nacharbeit IsRework | Ein Kennzeichen (Flag), das angibt, ob eine Aktivität in einem Case eine Wiederholung einer vorherigen Aktivität ist. | ||
| Beschreibung Dieses berechnete boolesche Attribut identifiziert Nacharbeitsinstanzen, bei denen eine Aktivität innerhalb desselben Falls mehr als einmal durchgeführt wird. Zum Beispiel, wenn eine Artikelprüfung wiederholt werden muss oder eine Gutschrift erstellt, storniert und dann neu erstellt wird. Dieses Attribut ist essenziell für das Dashboard 'Analyse von Nacharbeiten in der Rückerstattungsbearbeitung' und den KPI 'Rückerstattungs-Nacharbeitsrate'. Es hilft, Prozessineffizienz zu quantifizieren, indem es Aktivitäten hervorhebt, die fehleranfällig sind oder mehrere Versuche erfordern, und somit auf Bereiche hinweist, die bessere Kontrollen oder Schulungen benötigen. Bedeutung Hebt Prozesseffizienzen und Fehler hervor, indem wiederholte Arbeiten gekennzeichnet werden, was gezielte Verbesserungen zur Reduzierung von Verschwendung und Verzögerungen ermöglicht. Datenquelle Dieses Flag wird typischerweise vom Process Mining Tool selbst berechnet oder kann in der Datentransformation vorab berechnet werden. Es prüft, ob derselbe Aktivitätsname bereits früher im selben Case aufgetaucht ist. Beispiele truefalsch | |||
| Retourenauftragsstatus ReturnOrderStatus | Der aktuelle Gesamtstatus des Retourenfalls. | ||
| Beschreibung Dieses Attribut liefert einen Status auf hoher Ebene für den Retourenfall zu jedem gegebenen Zeitpunkt, wie 'Offen', 'In Bearbeitung' oder 'Abgeschlossen'. Dies ist oft ein aggregierter Status, der vom letzten abgeschlossenen wichtigen Meilenstein abgeleitet wird. Dies ist essenziell für das 'Dashboard des aktuellen Retourenfallstatus', das eine operative Ansicht der aktuellen Arbeitslast und Fallverteilung bietet. Es hilft Managern zu verstehen, wie viele Fälle sich in jeder Phase des Prozesses befinden, und ermöglicht eine bessere Ressourcenallokation und Arbeitslastverwaltung. Bedeutung Liefert einen Überblick, wo sich jeder Fall im Prozess befindet, was für operative Dashboards, die die aktuelle Arbeitslast und den Status verfolgen, unerlässlich ist. Datenquelle Abgeleitet von den Statusfeldern der relevanten Belege. Zum Beispiel vom Kopfstatus (GBSTK) oder Positionsstatus (LFSTK) in den zugehörigen Verkaufsaufträgen (VBUK/VBUP) oder Lieferbelegen. Beispiele Wareneingang ausstehendWarte auf PrüfungRückerstattung ausstehendGeschlossen | |||
| Retourenliefernummer ReturnDeliveryNumber | Der eindeutige Identifikator für den Retourenlieferbeleg. | ||
| Beschreibung Wenn ein Kunde Waren physisch zurücksendet, wird in SAP ein Retourenlieferbeleg erstellt, um die Inbound-Logistik zu verwalten. Dieses Attribut ist die eindeutige Nummer dieses Belegs. Diese ID ist wichtig für die Verfolgung der physischen Bewegung der retournierten Ware. Sie verbindet die finanziellen und logistischen Aspekte der Retoure und ermöglicht eine detaillierte Analyse der Wareneingangs- und Prüfphasen des Prozesses. Bedeutung Stellt eine wichtige Verbindung zwischen dem Retourenauftrag und dem physischen Wareneingang her, entscheidend für die Analyse von Logistik- und Lagerbearbeitungszeiten. Datenquelle Dies ist die Lieferbelegnummer (VBELN) aus der Lieferbelegkopftabelle (LIKP), wobei die Belegkategorie eine Retourenlieferung anzeigt. Beispiele 840000128400001384000014 | |||
| Retourenrichtlinien-ID ReturnPolicyId | Der Identifikator der Retourenrichtlinie, die für diesen spezifischen Retourenfall gilt. | ||
| Beschreibung Dieses Attribut gibt an, welche spezifische Retourenrichtlinie oder welcher Regelsatz für die Transaktion anwendbar ist. Richtlinien können je nach Produkttyp, Kundensegment oder Zeit seit dem Kauf variieren. Diese Daten sind essenziell für die 'Übersicht zur Einhaltung der Retourenrichtlinie'. Indem jeder Fall einer Richtlinie zugeordnet wird, kann das System automatisch die Einhaltung von Regeln, wie Retourenfristen oder Artikelzustandsanforderungen, überprüfen und Abweichungen zur Analyse kennzeichnen. Bedeutung Ermöglicht die automatisierte Datenquelle Dies ist oft kein Standard-SAP-Feld und muss möglicherweise basierend auf Geschäftslogik abgeleitet werden, unter Verwendung von Daten wie Produkttyp, Kunde und Verkaufsdatum. Es könnte in einem kundenspezifischen Feld gespeichert werden, falls implementiert. Beispiele STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| Rückerstattungs-SLA-Zieldatum RefundSlaTargetDate | Das Zieldatum, bis zu dem die Rückerstattung für den Retourenfall bearbeitet werden sollte. | ||
| Beschreibung Dieses Attribut definiert die Service Level Agreement (SLA)-Frist für die Bearbeitung der Rückerstattung. Dieses Datum wird normalerweise auf Basis von Geschäftsregeln berechnet, zum Beispiel eine bestimmte Anzahl von Tagen nach Genehmigung der Retoure oder Wareneingang. Dieses Feld ist die Basis für das Dashboard 'Überwachung der Rückerstattungs-SLA-Einhaltung' und den zugehörigen KPI. Es ermöglicht die proaktive Verfolgung von Fällen, bei denen das Risiko einer SLA-Verletzung besteht, und die Analyse der Ursachen für Verzögerungen, was letztendlich zur Verbesserung der Kundenzufriedenheit beiträgt. Bedeutung Liefert die Grundlage zur Messung der SLA-Compliance, hilft bei der Leistungsüberwachung, Priorisierung überfälliger Fälle und Verbesserung der Kundenzufriedenheit. Datenquelle Dies ist fast immer ein abgeleitetes Feld. Die Logik basiert auf einem Schlüsseldatum (z. B. Erstellungsdatum der Retourenanfrage) plus einer durch Geschäftsregeln definierten Dauer, die von Faktoren wie Kundentyp oder Retourengrund abhängen kann. Beispiele 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
Aktivitäten der Retouren- und Rückerstattungsabwicklung
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Artikelprüfung abgeschlossen | Stellt den Abschluss der Qualitäts- und Zustandsbewertung der retournierten Ware dar. Im erweiterten Retourenmanagement ist dies oft ein expliziter Schritt, der das Prüfergebnis erfasst und die nachfolgende Maßnahme wie Rückerstattung oder Verschrottung festlegt. | ||
| Bedeutung Die Dauer und das Ergebnis der Prüfung wirken sich direkt auf die Bearbeitungszeit der Rückerstattung und das Bestandsmanagement aus. Diese Aktivität ist entscheidend für die Analyse der Prüfeffizienz und von Nacharbeiten. Datenquelle Im SAP Advanced Returns Management (ARM) kann dies ein explizites Erfassen Erfasst aus Transaktionsprotokollen oder Statusänderungen im Zusammenhang mit den logistischen Folge- Ereignistyp explicit | |||
| Gutschrift erstellt | Dies ist die Erstellung des offiziellen Fakturabelegs, der das Kundenkonto für den retournierten Artikel gutschreibt. Dies ist ein explizites Event, das erfasst wird, wenn die Gutschrift aus der Gutschriftsanforderung generiert wird. | ||
| Bedeutung Die Erstellung der Gutschrift ist ein kritischer finanzieller Meilenstein. Sie bestätigt den zu erstattenden Betrag und autorisiert den Beginn des Zahlungsprozesses. Datenquelle Erfasst aus der Erstellung eines Fakturabelegs in Tabelle VBRK mit einer Belegkategorie, die eine Gutschrift anzeigt. Dies ist mit der Gutschriftsanforderung in der Tabelle VBFA verknüpft. Erfassen Das Event wird beim Sichern eines neuen Gutschrifts-Fakturabelegs (z.B. mit Transaktion VF01) aufgezeichnet. Ereignistyp explicit | |||
| Gutschriftsanforderung erstellt | Nach einer erfolgreichen Prüfung markiert diese `Aktivität` die Erstellung einer Anforderung zur Ausstellung einer Gutschrift an den Kunden. Dies wird als neues Verkaufsbeleg, eine Gutschriftsanforderung, erfasst, die auf den ursprünglichen Retourenauftrag verweist. | ||
| Bedeutung Dies ist der Auslöser für den finanziellen Abwicklungsteil des Retourenprozesses. Die Analyse der Zeit von der Prüfung bis zu diesem Schritt zeigt die Effizienz der Übergabe von der Logistik zur Finanzabteilung auf. Datenquelle Erfasst aus der Erstellung eines Verkaufsbelegs in Tabelle VBAK mit einer Belegkategorie für Gutschriftsanforderung. Die Verknüpfung zur Retoure wird in der Belegflusstabelle VBFA gepflegt. Erfassen Das Event wird beim Sichern eines neuen Gutschriftsanforderungsbelegs aufgezeichnet. Ereignistyp explicit | |||
| Refund Processed | Diese Aktivität kennzeichnet den letzten Schritt des Rückerstattungsprozesses, bei dem die finanzielle Gutschrift ausgeglichen wird, was bedeutet, dass die Zahlung an den Kunden gesendet wurde. Dies wird durch die Erstellung eines Ausgleichsbelegs im Finanzmodul abgeleitet, der die offene Gutschrift auf dem Kundenkonto ausgleicht. | ||
| Bedeutung Dies ist der Moment, in dem der Kunde tatsächlich bezahlt wird. Die Zeit, die benötigt wird, um diesen Schritt von der Retoureninitiierung an zu erreichen, ist ein wichtiger Faktor für die Kundenzufriedenheit und entscheidend für die Messung der SLA-Einhaltung. Datenquelle Abgeleitet aus den Ausgleichsbeleginformationen in der Finanzbuchhaltungspositionstabelle BSEG. Das Ausgleichs- Erfassen Abgeleitet vom Ausgleichs- Ereignistyp inferred | |||
| Retourenanfrage initiiert | Dies ist der Startpunkt des Retourenprozesses, bei dem ein Retourenauftrag formal im System erstellt wird. Dieses Event wird explizit erfasst, wenn ein neuer Verkaufsbeleg vom Typ Retourenauftrag in SAP S/4HANA gespeichert wird. | ||
| Bedeutung Diese Aktivität markiert den offiziellen Start des Retourenfall-Lebenszyklus. Die Analyse der Zeit von diesem Event bis zum Abschluss ist entscheidend für die Messung der gesamten Retouren-Durchlaufzeit und des Kundenerlebnisses. Datenquelle Dies ist ein explizites Event, das aus der Erstellung eines Verkaufsbelegs in Tabelle VBAK erfasst wird, wobei die Belegkategorie (VBAK-VBTYP) einen Retourenauftrag anzeigt. Der Erstellungs-Timestamp ist VBAK-ERDAT. Erfassen Das Event wird beim Sichern eines neuen Retourenauftrags (z.B. mit Transaktion VA01) aufgezeichnet. Ereignistyp explicit | |||
| Retourenfall abgeschlossen | Dies ist die letzte Aktivität, die anzeigt, dass der Retourenprozess abgeschlossen ist und keine weiteren Aktionen für den Fall erwartet werden. Dies wird typischerweise abgeleitet, wenn der Retourenauftragsbeleg einen finalen, geschlossenen Status im System erreicht. | ||
| Bedeutung Dieses Event definiert das Ende des Prozesslebenszyklus und ermöglicht die Berechnung der gesamten End-to-End-Durchlaufzeit. Es bestätigt, dass der Fall vollständig gelöst wurde. Datenquelle Abgeleitet vom Gesamtstatus des Retourenauftrags in Tabelle VBAK oder seiner Positionen in VBAP, die einen Status 'Komplett' oder 'Geschlossen' erreichen. Dies wird durch die Statusverwaltungskonfiguration des Systems bestimmt. Erfassen Abgeleitet von der Statusänderung des Retourenauftragsbelegs auf 'Komplett'. Ereignistyp inferred | |||
| Ware im Lager eingegangen | Dieses Event markiert den physischen Wareneingang des retournierten Artikels im Lager oder Bearbeitungszentrum. Es wird explizit erfasst, wenn ein Wareneingang (PGR) gegen die Retourenlieferung gebucht wird, wodurch ein Materialbeleg erstellt wird. | ||
| Bedeutung Dies ist ein kritischer Meilenstein, der den Startpunkt für Prüfung und Entsorgung markiert. Verzögerungen vor diesem Punkt sind kundeninduziert, während Verzögerungen danach intern sind. Datenquelle Erfasst aus den Materialbelegtabellen MSEG und MKPF für die Warenbewegungstyp im Zusammenhang mit Retouren. Das Buchungsdatum (MKPF-BUDAT) gibt die Erfassen Das Event entspricht der Buchung eines Wareneingangs für die Retourenlieferung. Ereignistyp explicit | |||
| Buchhaltungsbeleg erstellt | Dieses Event tritt ein, wenn die Gutschrift erfolgreich in das Finanzbuchhaltungsmodul gebucht wird. Es erstellt entsprechende Einträge im Hauptbuch, wodurch die Gutschrift aus buchhalterischer Sicht offiziell wird. | ||
| Bedeutung Diese Aktivität bestätigt, dass die Gutschrift in das Finanzsystem integriert wurde. Die Zeitspanne zwischen der Erstellung der Gutschrift und der Buchung kann Probleme in der Schnittstelle zwischen Fakturierung und Finanzbuchhaltung aufzeigen. Datenquelle Erfasst aus der Erstellung eines Belegkopfes in der Buchhaltungstabelle BKPF, der mit der Gutschrift in VBRK (VBRK-BELNR) verknüpft ist. Erfassen Das Event wird bei erfolgreicher Buchung des Fakturabelegs in die Finanzbuchhaltung aufgezeichnet. Ereignistyp explicit | |||
| Retoure abgelehnt | Zeigt an, dass der zurückgesendete Artikel die Kriterien der Retourenrichtlinie nicht erfüllt hat und die Anfrage auf Rückerstattung oder Gutschrift abgelehnt wurde. Dies wird typischerweise durch einen spezifischen Status- oder Ablehnungsgrundcode erfasst, der der Retourenposition nach der Prüfung zugewiesen wird. | ||
| Bedeutung Die Verfolgung von Ablehnungen hilft bei der Analyse der Einhaltung von Retourenrichtlinien und bei der Identifizierung häufiger Ablehnungsgründe. Es ist ein wichtiger Ausnahme-Pfad im Prozess. Datenquelle Abgeleitet von einem Ablehnungsgrund (VBAP-ABGRU), der für die Retourenposition gesetzt wird, oder einem spezifischen Status, der während des Inspektionsprozesses im Advanced Returns Management zugewiesen wird. Erfassen Abgeleitet von der Festlegung eines Ablehnungsgrundes oder eines spezifischen 'abgelehnten' Status auf der Retourenbelegposition. Ereignistyp inferred | |||
| Retourenauftrag genehmigt | Stellt die formale Genehmigung oder Freigabe des Retourenauftrags dar, wodurch dieser in die nächste Phase übergehen kann. Dies wird typischerweise aus einer Statusänderung im Verkaufsbelegkopf oder in der Position abgeleitet, was anzeigt, dass er von etwaigen Sperren freigegeben wurde. | ||
| Bedeutung Genehmigungsschritte können eine erhebliche Verzögerungsquelle sein. Die Verfolgung dieser Datenquelle Abgeleitet aus Statusverwaltungstabellen oder Statusfeldern direkt in den Tabellen VBAK oder VBAP. Eine Änderung eines Freigabestatus oder die Aufhebung einer Liefersperre (VBAP-LIFSP) kann eine Genehmigung bedeuten. Erfassen Abgeleitet von einer Änderung der Kopf- oder Positionsstatusfelder des Retourenauftrags, die eine Freigabe oder Genehmigung anzeigen. Ereignistyp inferred | |||
| Retourenlieferung erstellt | Diese Aktivität bedeutet die Erstellung eines Retourenlieferbelegs, der zur Verwaltung des physischen Wareneingangs der retournierten Ware verwendet wird. Das System erfasst dies als ein explizites Erstellungsereignis für einen Lieferbeleg, der sich auf den Retourenauftrag bezieht. | ||
| Bedeutung Dieser Schritt ist ein wichtiger logistischer Meilenstein. Die Zeit zwischen Retourenfreigabe und Liefererstellung verdeutlicht die Effizienz der Kommunikation von Retoureninformationen an das Lager oder die Empfangsabteilung. Datenquelle Erfasst aus der Erstellung eines Lieferkopfes in Tabelle LIKP, verknüpft mit dem vorhergehenden Retourenauftrag über die Belegflusstabelle VBFA. Erfassen Das Event wird beim Sichern eines neuen Retourenlieferbelegs (z.B. mit Transaktion VL01N) aufgezeichnet. Ereignistyp explicit | |||
| Umtauschauftrag erstellt | Diese Aktivität stellt eine alternative Lösung dar, bei der anstelle einer Rückerstattung ein neuer Verkaufsauftrag erstellt wird, um einen Ersatzartikel an den Kunden zu versenden. Dies wird erfasst, wenn ein neuer Verkaufsauftrag mit Bezug auf die ursprüngliche Retoure erstellt wird. | ||
| Bedeutung Diese Aktivität hilft, zwischen Retouren für eine Rückerstattung und Retouren für einen Umtausch zu unterscheiden, die unterschiedliche Prozesspfade und Kundenergebnisse aufweisen. Sie ist entscheidend für die Variantenanalyse. Datenquelle Erfasst aus der Erstellung eines neuen Verkaufsbelegs in VBAK, der mit dem Retourenauftrag in der Belegflusstabelle (VBFA) verknüpft ist. Erfassen Das Event wird beim Sichern eines neuen Verkaufsbelegs aufgezeichnet, der als Ersatz gekennzeichnet ist. Ereignistyp explicit | |||
Extraktionsleitfäden
Schritte
- Prüfung der Voraussetzungen: Stellen Sie sicher, dass das ausführende Benutzerkonto in SAP S/4HANA berechtigt ist, auf die erforderlichen Core Data Services (CDS) Views zuzugreifen (u. a. I_SalesDocument, I_SDDocumentFlow, I_JournalEntry).
- Abfragetool öffnen: Melden Sie sich bei Ihrem SQL-Client oder ETL-Tool an, das mit der SAP S/4HANA-Datenbank verbunden ist (z. B. SAP Analytics Cloud oder Drittanbieter-Plattformen).
- Abfrageparameter setzen: Passen Sie die Platzhalter in der SQL-Abfrage an Ihre Umgebung an. Dies umfasst
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type]sowie Buchungskreisfilter. - Extraktions-Query ausführen: Führen Sie die vollständige SQL-Abfrage aus. Die Query bündelt alle Aktivitäten über
UNION ALL-Statements zu einem einheitlichen Datensatz. - Logik der Abfrage verstehen: Jeder
SELECT-Block extrahiert eine spezifische Aktivität. Er verknüpft CDS-Views, weist denActivityNameals festen String zu und wählt den Zeitstempel fürEventTimeaus. - Rohdaten prüfen: Kontrollieren Sie das Ergebnis kurz auf Plausibilität (Zeilenanzahl, korrekte Befüllung von
ReturnCaseId,ActivityNameundEventTime). - Datentransformation: Die Query liefert bereits ein flaches Event Log Format. Eventuell müssen Sie lediglich Zeitstempelformate an die Anforderungen Ihres Zielsystems anpassen.
- Event Log exportieren: Speichern Sie das Ergebnis als CSV-Datei. Nutzen Sie UTF-8-Codierung, um Darstellungsfehler bei Sonderzeichen oder Benutzernamen zu vermeiden.
- Upload ins Process Mining Tool: Die CSV-Datei kann nun in Plattformen wie ProcessMind hochgeladen werden. Mappen Sie dabei
ReturnCaseIdauf Case ID,ActivityNameauf Aktivität undEventTimeauf Zeitstempel.
Konfiguration
- Voraussetzungen: Der ausführende Benutzer benötigt Anzeige-Berechtigungen für Objekte im Zusammenhang mit Verkaufsbelegen (VBAK), Lieferungen (LIKP), Fakturierung (VBRK) und Buchhaltung (BSEG, BKPF). Der Zugriff auf die zugrunde liegenden CDS Views ist unerlässlich.
- Datenumfangsfilter: Es ist entscheidend, die Abfrage nach spezifischen Belegarten zu filtern, um den Retourenprozess zu isolieren. Konfigurieren Sie die Platzhalter für Retourenauftragsarten (z.B. 'RE'), Gutschriftsanforderungsarten (z.B. 'G2') und Austauschauftragsarten (z.B. 'SO'). Die Filterung nach
CompanyCodeoderSalesOrganizationwird ebenfalls dringend empfohlen, um den Datenumfang zu begrenzen. - Datumsbereichsfilterung: Um die Performance und das Datenvolumen zu steuern, wenden Sie immer einen Datumsbereichsfilter an. Beginnen Sie mit einem aktuellen Zeitraum von 3 bis 6 Monaten Daten. Die Abfrage verwendet das Erstellungsdatum des ursprünglichen Retourenauftrags (
I_SalesDocument.CreationDate) als primäre Filterbedingung. - Performanceüberlegungen: Dies ist eine umfassende Abfrage, die mehrere große CDS Views miteinander verbindet. Die Ausführung kann auf dem Quellsystem S/4HANA ressourcenintensiv sein. Planen Sie die Extraktion außerhalb der Geschäftszeiten, um die Auswirkungen zu minimieren. Für sehr große
Datasetssollten inkrementelle Ladestrategien in Betracht gezogen werden.
a Beispielabfrage sql
WITH ReturnOrders AS (
SELECT
SalesDocument AS ReturnCaseId,
CreationDate,
CreationDateTime,
CreatedByUser,
OrderReason,
SoldToParty
FROM I_SalesDocument
WHERE SalesDocumentType = '[Your Return Order Type]' -- e.g., 'RE'
AND CreationDate BETWEEN '[Start Date]' AND '[End Date]'
AND CompanyCode = '[Your Company Code]'
)
-- 1. Return Request Initiated
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Return Request Initiated' AS "ActivityName",
RO.CreationDateTime AS "EventTime",
RO.CreationDateTime AS "EventEndTime",
RO.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM ReturnOrders RO
JOIN I_SalesDocumentItem I ON RO.ReturnCaseId = I.SalesDocument
UNION ALL
-- 2. Return Order Approved
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Order Approved' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus <> 'A' -- Not Open, implying it has been processed/approved
AND I.SDProcessStatus <> 'A'
UNION ALL
-- 3. Return Delivery Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Return Delivery Created' AS "ActivityName",
LH.CreationDateTime AS "EventTime",
LH.CreationDateTime AS "EventEndTime",
LH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
LI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocument AS LH ON DF.SubsequentDocument = LH.DeliveryDocument
JOIN I_DeliveryDocumentItem AS LI ON LH.DeliveryDocument = LI.DeliveryDocument
WHERE DF.PrecedingDocumentCategory = 'C' AND DF.SubsequentDocumentCategory = 'J'
UNION ALL
-- 4. Goods Received at Warehouse
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Goods Received at Warehouse' AS "ActivityName",
MH.CreationDateTime AS "EventTime",
MH.CreationDateTime AS "EventEndTime",
MH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
MI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocumentItem AS LI ON DF.SubsequentDocument = LI.DeliveryDocument AND DF.SubsequentDocumentItem = LI.DeliveryDocumentItem
JOIN I_MaterialDocumentItem AS MI ON LI.DeliveryDocument = MI.DeliveryDocument AND LI.DeliveryDocumentItem = MI.DeliveryDocumentItem
JOIN I_MaterialDocumentHeader AS MH ON MI.MaterialDocument = MH.MaterialDocument AND MI.MaterialDocumentYear = MH.MaterialDocumentYear
WHERE DF.SubsequentDocumentCategory = 'J' AND MH.GoodsMovementType = '[Your Return Goods Receipt MVT]' -- e.g., '651', '653'
UNION ALL
-- 5. Item Inspection Completed
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Item Inspection Completed' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.ReturnsInspectionStatus = '4' -- 'Inspection Completed', adjust value based on your config
UNION ALL
-- 6. Return Rejected
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Return Rejected' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.SalesDocumentItemRejectionReason <> ''
UNION ALL
-- 7. Credit Memo Request Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Request Created' AS "ActivityName",
CM_REQ.CreationDateTime AS "EventTime",
CM_REQ.CreationDateTime AS "EventEndTime",
CM_REQ.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument
JOIN I_SalesDocumentItem I ON CM_REQ.SalesDocument = I.SalesDocument
WHERE CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]' -- e.g., 'CR'
UNION ALL
-- 8. Exchange Order Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Exchange Order Created' AS "ActivityName",
EX_ORD.CreationDateTime AS "EventTime",
EX_ORD.CreationDateTime AS "EventEndTime",
EX_ORD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS EX_ORD ON DF.SubsequentDocument = EX_ORD.SalesDocument
JOIN I_SalesDocumentItem I ON EX_ORD.SalesDocument = I.SalesDocument
WHERE EX_ORD.SalesDocumentType = '[Your Exchange Order Type]' -- e.g., 'OR'
UNION ALL
-- 9. Credit Memo Created
SELECT
DF_CM.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Created' AS "ActivityName",
BD.CreationDateTime AS "EventTime",
BD.CreationDateTime AS "EventEndTime",
BD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
BD.TotalNetAmount AS "RefundAmount",
BDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow AS DF_CM ON CM_REQ.SalesDocument = DF_CM.PrecedingDocument
JOIN I_BillingDocument AS BD ON DF_CM.SubsequentDocument = BD.BillingDocument
JOIN I_BillingDocumentItem AS BDI ON BD.BillingDocument = BDI.BillingDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE DF.PrecedingDocumentCategory = 'C'
UNION ALL
-- 10. Accounting Document Created
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Accounting Document Created' AS "ActivityName",
JE.CreationDateTime AS "EventTime",
JE.CreationDateTime AS "EventEndTime",
JE.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
JE.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_JournalEntry AS JE
JOIN I_JournalEntryItem JRI ON JE.AccountingDocument = JRI.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK'
UNION ALL
-- 11. Refund Processed
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Refund Processed' AS "ActivityName",
CI.ClearingDate AS "EventTime",
CI.ClearingDate AS "EventEndTime",
CI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CI.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_ClearedItem AS CI
JOIN I_JournalEntryItem JRI ON CI.AccountingDocument = JRI.AccountingDocument AND CI.FiscalYear = JRI.FiscalYear AND CI.LedgerGLLineItem = JRI.LedgerGLLineItem
JOIN I_JournalEntry JE ON JRI.AccountingDocument = JE.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK' AND CI.ClearingDate IS NOT NULL
UNION ALL
-- 12. Return Case Closed
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Case Closed' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus = 'C' -- 'Completed' Schritte
- Prüfung der Voraussetzungen: Stellen Sie sicher, dass das ausführende Benutzerkonto in SAP S/4HANA berechtigt ist, auf die erforderlichen Core Data Services (CDS) Views zuzugreifen (u. a. I_SalesDocument, I_SDDocumentFlow, I_JournalEntry).
- Abfragetool öffnen: Melden Sie sich bei Ihrem SQL-Client oder ETL-Tool an, das mit der SAP S/4HANA-Datenbank verbunden ist (z. B. SAP Analytics Cloud oder Drittanbieter-Plattformen).
- Abfrageparameter setzen: Passen Sie die Platzhalter in der SQL-Abfrage an Ihre Umgebung an. Dies umfasst
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type]sowie Buchungskreisfilter. - Extraktions-Query ausführen: Führen Sie die vollständige SQL-Abfrage aus. Die Query bündelt alle Aktivitäten über
UNION ALL-Statements zu einem einheitlichen Datensatz. - Logik der Abfrage verstehen: Jeder
SELECT-Block extrahiert eine spezifische Aktivität. Er verknüpft CDS-Views, weist denActivityNameals festen String zu und wählt den Zeitstempel fürEventTimeaus. - Rohdaten prüfen: Kontrollieren Sie das Ergebnis kurz auf Plausibilität (Zeilenanzahl, korrekte Befüllung von
ReturnCaseId,ActivityNameundEventTime). - Datentransformation: Die Query liefert bereits ein flaches Event Log Format. Eventuell müssen Sie lediglich Zeitstempelformate an die Anforderungen Ihres Zielsystems anpassen.
- Event Log exportieren: Speichern Sie das Ergebnis als CSV-Datei. Nutzen Sie UTF-8-Codierung, um Darstellungsfehler bei Sonderzeichen oder Benutzernamen zu vermeiden.
- Upload ins Process Mining Tool: Die CSV-Datei kann nun in Plattformen wie ProcessMind hochgeladen werden. Mappen Sie dabei
ReturnCaseIdauf Case ID,ActivityNameauf Aktivität undEventTimeauf Zeitstempel.
Konfiguration
- Voraussetzungen: Der ausführende Benutzer benötigt Anzeige-Berechtigungen für Objekte im Zusammenhang mit Verkaufsbelegen (VBAK), Lieferungen (LIKP), Fakturierung (VBRK) und Buchhaltung (BSEG, BKPF). Der Zugriff auf die zugrunde liegenden CDS Views ist unerlässlich.
- Datenumfangsfilter: Es ist entscheidend, die Abfrage nach spezifischen Belegarten zu filtern, um den Retourenprozess zu isolieren. Konfigurieren Sie die Platzhalter für Retourenauftragsarten (z.B. 'RE'), Gutschriftsanforderungsarten (z.B. 'G2') und Austauschauftragsarten (z.B. 'SO'). Die Filterung nach
CompanyCodeoderSalesOrganizationwird ebenfalls dringend empfohlen, um den Datenumfang zu begrenzen. - Datumsbereichsfilterung: Um die Performance und das Datenvolumen zu steuern, wenden Sie immer einen Datumsbereichsfilter an. Beginnen Sie mit einem aktuellen Zeitraum von 3 bis 6 Monaten Daten. Die Abfrage verwendet das Erstellungsdatum des ursprünglichen Retourenauftrags (
I_SalesDocument.CreationDate) als primäre Filterbedingung. - Performanceüberlegungen: Dies ist eine umfassende Abfrage, die mehrere große CDS Views miteinander verbindet. Die Ausführung kann auf dem Quellsystem S/4HANA ressourcenintensiv sein. Planen Sie die Extraktion außerhalb der Geschäftszeiten, um die Auswirkungen zu minimieren. Für sehr große
Datasetssollten inkrementelle Ladestrategien in Betracht gezogen werden.
a Beispielabfrage sql
WITH ReturnOrders AS (
SELECT
SalesDocument AS ReturnCaseId,
CreationDate,
CreationDateTime,
CreatedByUser,
OrderReason,
SoldToParty
FROM I_SalesDocument
WHERE SalesDocumentType = '[Your Return Order Type]' -- e.g., 'RE'
AND CreationDate BETWEEN '[Start Date]' AND '[End Date]'
AND CompanyCode = '[Your Company Code]'
)
-- 1. Return Request Initiated
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Return Request Initiated' AS "ActivityName",
RO.CreationDateTime AS "EventTime",
RO.CreationDateTime AS "EventEndTime",
RO.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM ReturnOrders RO
JOIN I_SalesDocumentItem I ON RO.ReturnCaseId = I.SalesDocument
UNION ALL
-- 2. Return Order Approved
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Order Approved' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus <> 'A' -- Not Open, implying it has been processed/approved
AND I.SDProcessStatus <> 'A'
UNION ALL
-- 3. Return Delivery Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Return Delivery Created' AS "ActivityName",
LH.CreationDateTime AS "EventTime",
LH.CreationDateTime AS "EventEndTime",
LH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
LI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocument AS LH ON DF.SubsequentDocument = LH.DeliveryDocument
JOIN I_DeliveryDocumentItem AS LI ON LH.DeliveryDocument = LI.DeliveryDocument
WHERE DF.PrecedingDocumentCategory = 'C' AND DF.SubsequentDocumentCategory = 'J'
UNION ALL
-- 4. Goods Received at Warehouse
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Goods Received at Warehouse' AS "ActivityName",
MH.CreationDateTime AS "EventTime",
MH.CreationDateTime AS "EventEndTime",
MH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
MI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocumentItem AS LI ON DF.SubsequentDocument = LI.DeliveryDocument AND DF.SubsequentDocumentItem = LI.DeliveryDocumentItem
JOIN I_MaterialDocumentItem AS MI ON LI.DeliveryDocument = MI.DeliveryDocument AND LI.DeliveryDocumentItem = MI.DeliveryDocumentItem
JOIN I_MaterialDocumentHeader AS MH ON MI.MaterialDocument = MH.MaterialDocument AND MI.MaterialDocumentYear = MH.MaterialDocumentYear
WHERE DF.SubsequentDocumentCategory = 'J' AND MH.GoodsMovementType = '[Your Return Goods Receipt MVT]' -- e.g., '651', '653'
UNION ALL
-- 5. Item Inspection Completed
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Item Inspection Completed' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.ReturnsInspectionStatus = '4' -- 'Inspection Completed', adjust value based on your config
UNION ALL
-- 6. Return Rejected
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Return Rejected' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.SalesDocumentItemRejectionReason <> ''
UNION ALL
-- 7. Credit Memo Request Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Request Created' AS "ActivityName",
CM_REQ.CreationDateTime AS "EventTime",
CM_REQ.CreationDateTime AS "EventEndTime",
CM_REQ.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument
JOIN I_SalesDocumentItem I ON CM_REQ.SalesDocument = I.SalesDocument
WHERE CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]' -- e.g., 'CR'
UNION ALL
-- 8. Exchange Order Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Exchange Order Created' AS "ActivityName",
EX_ORD.CreationDateTime AS "EventTime",
EX_ORD.CreationDateTime AS "EventEndTime",
EX_ORD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS EX_ORD ON DF.SubsequentDocument = EX_ORD.SalesDocument
JOIN I_SalesDocumentItem I ON EX_ORD.SalesDocument = I.SalesDocument
WHERE EX_ORD.SalesDocumentType = '[Your Exchange Order Type]' -- e.g., 'OR'
UNION ALL
-- 9. Credit Memo Created
SELECT
DF_CM.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Created' AS "ActivityName",
BD.CreationDateTime AS "EventTime",
BD.CreationDateTime AS "EventEndTime",
BD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
BD.TotalNetAmount AS "RefundAmount",
BDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow AS DF_CM ON CM_REQ.SalesDocument = DF_CM.PrecedingDocument
JOIN I_BillingDocument AS BD ON DF_CM.SubsequentDocument = BD.BillingDocument
JOIN I_BillingDocumentItem AS BDI ON BD.BillingDocument = BDI.BillingDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE DF.PrecedingDocumentCategory = 'C'
UNION ALL
-- 10. Accounting Document Created
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Accounting Document Created' AS "ActivityName",
JE.CreationDateTime AS "EventTime",
JE.CreationDateTime AS "EventEndTime",
JE.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
JE.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_JournalEntry AS JE
JOIN I_JournalEntryItem JRI ON JE.AccountingDocument = JRI.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK'
UNION ALL
-- 11. Refund Processed
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Refund Processed' AS "ActivityName",
CI.ClearingDate AS "EventTime",
CI.ClearingDate AS "EventEndTime",
CI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CI.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_ClearedItem AS CI
JOIN I_JournalEntryItem JRI ON CI.AccountingDocument = JRI.AccountingDocument AND CI.FiscalYear = JRI.FiscalYear AND CI.LedgerGLLineItem = JRI.LedgerGLLineItem
JOIN I_JournalEntry JE ON JRI.AccountingDocument = JE.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK' AND CI.ClearingDate IS NOT NULL
UNION ALL
-- 12. Return Case Closed
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Case Closed' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus = 'C' -- 'Completed'