Ihr Datentemplate für die Retouren- und Rückerstattungsbearbeitung
Ihr Datentemplate für die Retouren- und Rückerstattungsbearbeitung
- Empfohlene Attribute für die Datenerfassung
- Wichtige Aktivitäten zur Nachverfolgung
- Hinweise zur Datenextraktion
Attribute für die Retouren- und Rückerstattungsabwicklung
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Name einer bestimmten geschäftlichen Aktivität oder eines Ereignisses im Retouren- und Erstattungsprozess. | ||
| Beschreibung Dieses Attribut beschreibt einen einzelnen Schritt oder Meilenstein im Retourenprozess. Aktivitäten stehen für ausgeführte Arbeit, etwa „Retourenauftrag freigegeben“ oder „Artikelprüfung abgeschlossen“. Sie werden aus Statusänderungen, der Anlage von Belegen oder bestimmten Benutzeraktionen in SAP S/4HANA abgeleitet. Die Analyse der Abfolge und Häufigkeit dieser Aktivitäten bildet den Kern des Process Mining. Sie hilft, den Prozessablauf zu visualisieren, häufige und seltene Prozesspfade zu erkennen und Aktivitäten aufzudecken, die oft wiederholt werden und damit auf Nacharbeit oder Ineffizienzen hindeuten. Warum das wichtig ist Aktivitäten bilden das Rückgrat der Prozessübersicht. Sie ermöglichen die Visualisierung und Analyse des Prozessablaufs, von Engpässen und Abweichungen. Woher beziehen Aktivitätsnamen werden in der Regel aus verschiedenen Daten abgeleitet, etwa aus Statusänderungen von Belegen in Tabellen wie VBUK/VBUP, aus Anlageereignissen in Kopftabellen wie VBAK (Verkaufsbelege) und BKPF (Buchhaltungsbelege) sowie aus Warenbewegungsstatus in MSEG. Beispiele Retourenantrag eingeleitetWare im Lager eingegangenGutschrift angelegtErstattung abgewickelt | |||
| Ereigniszeitpunkt EventTime | Der genaue Timestamp, der angibt, wann eine bestimmte Aktivität stattgefunden hat. | ||
| Beschreibung Der Ereigniszeitpunkt gibt Datum und Uhrzeit an, zu denen ein Geschäftsereignis im System erfasst wurde. Dieser Timestamp ist entscheidend, um Aktivitäten chronologisch zu ordnen und zeitbezogene Analysen durchzuführen. Im Process Mining dient dieses Attribut dazu, Zykluszeiten zwischen Aktivitäten zu berechnen, die Dauer einzelner Schritte zu ermitteln und die Prozessleistung im Zeitverlauf zu analysieren. Es bildet die Grundlage, um Engpässe zu erkennen, die SLA-Einhaltung zu überwachen und den zeitlichen Verlauf des Retourenprozesses zu verstehen. Warum das wichtig ist Dieser Timestamp ist entscheidend, um Ereignisse zu ordnen, sämtliche Dauern und Zykluszeiten zu berechnen und Prozessverzögerungen zu erkennen. Woher beziehen Die Daten stammen üblicherweise aus Datums- und Uhrzeitfeldern zur Beleganlage oder zu Statusänderungen, etwa 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 | Eindeutige Kennung für einen einzelnen Retourenprozess, die alle zugehörigen Aktivitäten vom Beginn bis zum Abschluss miteinander verknüpft. | ||
| Beschreibung Die Retourenfall-ID ist die zentrale Kennung, mit der alle Ereignisse und Aktivitäten eines einzelnen Retourenfalls zusammengefasst werden. Jeder Retourenantrag erhält eine eindeutige ID, über die sich der gesamte Prozess verfolgen lässt. Im Process Mining ist dieses Attribut grundlegend für die Rekonstruktion des Prozessablaufs. Es ermöglicht die Analyse von Falldauern, Prozessvarianten und Engpässen, indem einzelne Ereignisse wie „Retourenantrag eingeleitet“, „Ware im Lager eingegangen“ und „Erstattung abgewickelt“ zu einer zusammenhängenden Zeitleiste für jede Retoure verknüpft werden. Warum das wichtig ist Diese Kennung ist unverzichtbar, um eine Retoure vom Anfang bis zum Ende zu verfolgen. Sie ermöglicht alle fallbezogenen Analysen, darunter die Zykluszeit und das Erkennen von Prozessvarianten. Woher beziehen In der Regel handelt es sich um die Verkaufsbelegnummer (VBELN) aus der Retourenauftragskopftabelle VBAK. Die Belegkategorie (VBTYP) kennzeichnet den Beleg als Retoure. Beispiele 600001896000019060000191 | |||
| Letzte Datenaktualisierung LastDataUpdateTimestamp | Der Timestamp, der angibt, wann die Daten zu diesem Ereignis zuletzt aktualisiert oder extrahiert wurden. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion oder -aktualisierung. Es liefert Metadaten zur Aktualität des analysierten Datensatzes. Die Angabe ist wichtig, um die Aktualität der Process-Mining-Analyse einzuschätzen. Benutzer sehen, wie aktuell die Daten sind. Das ist besonders für die operative Überwachung und Dashboards relevant, die laufende Fälle verfolgen. Warum das wichtig ist Zeigt die Aktualität der Daten an. Das ist entscheidend, damit Analysen und Dashboards auf dem neuesten Informationsstand basieren. Woher beziehen Dieser Wert wird üblicherweise zum Zeitpunkt der Datenextraktion vom ETL- oder Datenpipeline-Tool erzeugt und dem Datensatz hinzugefügt. Beispiele 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Quellsystem-ID SourceSystemId | Kennung des Quellsystems, aus dem die Daten extrahiert wurden. | ||
| Beschreibung Dieses Attribut gibt das führende System an, aus dem die Ereignisdaten stammen. Bei diesem Prozess ist das üblicherweise die ID der SAP-S/4HANA-Instanz. In Umgebungen mit mehreren Systemen ist dieses Feld entscheidend für die Datenherkunft, die Fehlerbehebung und die Sicherstellung der Datenintegrität. Es hilft, Daten zu unterscheiden, wenn Retouren in verschiedenen ERP-Instanzen bearbeitet oder mit externen Systemen wie einem Lagerverwaltungssystem verknüpft werden. Warum das wichtig ist Liefert wichtige Informationen zur Herkunft und Abstammung der Daten, insbesondere in Umgebungen mit mehreren Systemen. So bleiben die Daten nachvollziehbar und vertrauenswürdig. Woher beziehen Dieser Wert ist in der Regel statisch und wird bei der Datenextraktion konfiguriert. Er lässt sich aus den Verwaltungsinformationen des SAP-Systems abrufen, zum Beispiel aus der System-ID (SID). Beispiele S4H_PROD_100S4Q_DEV_200 | |||
| Benutzername UserName | Die Benutzer-ID des Mitarbeitenden, der die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut identifiziert den Benutzer oder Systemagenten, der für die Ausführung einer Aufgabe verantwortlich war, etwa für die Freigabe einer Retoure oder die Anlage einer Gutschrift. In SAP wird dies häufig in Feldern erfasst, die den Benutzer dokumentieren, der einen Beleg angelegt oder geändert hat. Die Analyse nach Benutzern hilft, leistungsstarke Mitarbeitende oder Teams, Schulungsbedarf und die Verteilung der Arbeitslast zu erkennen. Sie ist auch wichtig, um Abweichungen zu untersuchen: Prozessaktionen lassen sich bestimmten Personen zuordnen, was Compliance-Prüfungen und Audits unterstützt. Warum das wichtig ist Ordnet Prozessaktivitäten bestimmten Benutzern zu und ermöglicht so die Analyse von Teamleistung, Arbeitslast und Compliance. Woher beziehen Die Angaben finden sich häufig in Belegkopftabellen, etwa in ERNAM (Erstellt von) in VBAK (Verkaufsaufträge), LIKP (Lieferungen) und BKPF (Buchhaltungsbelege). Benutzerdaten lassen sich über die Benutzertabelle USR21 ergänzen. Beispiele CBROWNASMITHWF_BATCH | |||
| Endzeitpunkt des Ereignisses EventEndTime | Der Timestamp, der den Abschluss einer Aktivität markiert und zur Berechnung ihrer Dauer dient. | ||
| Beschreibung Während StartTime (EventTime) den Beginn einer Aktivität markiert, gibt EventEndTime ihren Abschluss an. Bei vielen systemgenerierten Ereignissen sind Start- und Endzeit identisch, da sie unmittelbar eintreten. Bei Aktivitäten mit messbarer Dauer, etwa einer „Artikelprüfung“, ist dieses Attribut jedoch entscheidend. Mit diesem Attribut lässt sich die Bearbeitungszeit einer Aktivität direkt berechnen. Das ist grundlegend für die Leistungsanalyse und zeigt, welche konkreten Schritte am meisten Zeit beanspruchen, nicht nur die Wartezeiten dazwischen. Warum das wichtig ist Ermöglicht die genaue Berechnung der Dauer einzelner Aktivitäten. So lassen sich Ineffizienzen in bestimmten Prozessschritten gezielt erkennen. Woher beziehen Dieser Wert wird häufig abgeleitet. Für manche Aktivitäten gibt es ein eigenes Feld. Häufiger entspricht er der StartTime der nachfolgenden Aktivität im selben Fall. Beispiele 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| Erstattungsbetrag RefundAmount | Der endgültige Geldbetrag, der dem Kunden erstattet wird. | ||
| Beschreibung Dieses Attribut gibt den tatsächlichen Betrag an, der dem Kunden nach Abschluss des Retourenprozesses gutgeschrieben oder erstattet wurde. Der Wert ist in Finanzbelegen wie Gutschriften erfasst. Diese wichtige finanzielle Kennzahl dient verschiedenen Analysen. Im Dashboard „Analyse von Abweichungen beim Erstattungsbetrag“ wird sie mit dem beantragten Betrag verglichen. Außerdem lassen sich Retouren nach Wert segmentieren, um festzustellen, ob bei hochpreisigen Retouren andere Abläufe gelten oder die Bearbeitung länger dauert. Warum das wichtig ist Erfasst die finanziellen Auswirkungen von Retouren und ist wichtig, um die Genauigkeit von Erstattungen zu analysieren, Fälle mit hohem Wert zu erkennen und die Gesamtkosten zu verstehen. Woher beziehen Der Wert stammt aus dem Nettowertfeld (NETWR) des Gutschriftsbelegs, das sich in Tabellen wie VBRK (Abrechnungsbelegkopf) oder BSEG (Buchhaltungsbelegsegment) befindet. Beispiele 125.50999.0049.99 | |||
| Kunden-ID CustomerId | Die eindeutige Kennung des Kunden, der die Retoure veranlasst. | ||
| Beschreibung Dieses Attribut identifiziert den Kunden, der die Retoure beantragt hat. Es verknüpft den Prozessfall mit einem bestimmten Eintrag in den Kundenstammdaten. Die Analyse von Retouren nach Kunden hilft, Muster zu erkennen, etwa ungewöhnlich hohe Retourenquoten, die auf betrügerisches Verhalten oder Unzufriedenheit hindeuten können. Außerdem lässt sich der Retourenprozess nach Kundentyp, Wert oder Historie segmentieren, um den Service gezielt anzupassen. Warum das wichtig ist Verknüpft Retouren mit bestimmten Kunden und ermöglicht die Analyse des Kundenverhaltens, die Segmentierung sowie das Erkennen von Kunden mit häufigen Retouren. Woher beziehen Die Kundennummer steht im Feld KUNNR der Retourenauftragskopftabelle VBAK. Beispiele CUST-001234CUST-005678CUST-009012 | |||
| Produkt-ID ProductId | Die eindeutige Kennung des retournierten Artikels. | ||
| Beschreibung Dieses Attribut gibt das Material oder Produkt an, auf das sich die Retoure bezieht. Es verknüpft den Retourenprozess mit einem bestimmten Artikel im Produktkatalog. Die Analyse von Retouren nach Produkt ist grundlegend, um Artikel mit hohen Retourenquoten zu erkennen. Diese können auf Qualitätsmängel, unzureichende Produktbeschreibungen oder Herstellungsprobleme hindeuten. Die Daten unterstützen fundierte Entscheidungen zu Produktdesign, Lieferantenmanagement und Bestandsstrategie. Warum das wichtig ist Verknüpft den Retourenprozess mit bestimmten Produkten. So lassen sich Retourenquoten auf Artikelebene analysieren und Probleme mit Qualität oder Produktbeschreibungen erkennen. Woher beziehen Die Produktnummer steht im Feld MATNR der Retourenauftragspositionstabelle VBAP oder der Retourenlieferungspositionstabelle LIPS. Beispiele FG-10023HW-45981SW-LICENSE-PREM | |||
| Retourengrund ReturnReason | Der vom Kunden angegebene Grund für die Rücksendung des Artikels. | ||
| Beschreibung Dieses Attribut erfasst den vom Kunden angegebenen Retourengrund, etwa „Artikel defekt“, „Falsche Größe“ oder „Nicht mehr benötigt“. Üblicherweise wird der Grund zu Beginn des Retourenprozesses aus einer vordefinierten Liste ausgewählt. Die Analyse der Retourengründe ist wichtig, um Qualitätsprobleme bei Produkten zu erkennen, Produktbeschreibungen zu verbessern oder Verkaufsprozesse anzupassen. Sie zeigt unmittelbar, was Kunden unzufrieden macht, und hilft dabei, Verbesserungsmaßnahmen zu priorisieren und die Retourenquote insgesamt zu senken. Warum das wichtig ist Zeigt, warum Retouren erfolgen, und ermöglicht Ursachenanalysen zu Produktqualität, Fehlern bei der Auftragsabwicklung oder abweichenden Kundenerwartungen. Woher beziehen Der Grund ist üblicherweise im Feld ABGRU (Ablehnungsgrund für Verkaufsbelege) der Retourenauftragspositionstabelle VBAP gespeichert. Beispiele 001 - Mangelhafte Qualität002 - Beim Transport beschädigt005 - Falscher Artikel versendet | |||
| Beantragter Erstattungsbetrag RequestedRefundAmount | Der zu Beginn des Prozesses beantragte oder erwartete Erstattungsbetrag. | ||
| Beschreibung Dieses Attribut erfasst den Wert der Ware, die laut ursprünglichem Retourenantrag zurückgesendet wird. Er dient als Vergleichswert für den endgültigen Erstattungsbetrag. Dieses Feld wird speziell für das Dashboard „Analyse von Abweichungen beim Erstattungsbetrag“ benötigt. Der Vergleich des beantragten Betrags mit der tatsächlichen Erstattung hilft, Probleme wie Teilrückerstattungen aufgrund von Artikelschäden, Wiedereinlagerungsgebühren oder anderen Anpassungen zu erkennen. So lassen sich finanzielle Genauigkeit und Transparenz sicherstellen. Warum das wichtig ist Dient als Referenzwert, um die Genauigkeit von Rückerstattungen zu messen und Abweichungen zwischen den erwarteten und den tatsächlichen Rückerstattungsbeträgen zu erkennen und zu analysieren. Woher beziehen Der Wert wird üblicherweise aus dem Nettowert der Positionen im ursprünglichen Retourenauftrag übernommen. Gemeint ist der Nettowert (NETWR) der entsprechenden Positionen in der Tabelle VBAP. Beispiele 125.501050.0049.99 | |||
| Bearbeitende Stelle ProcessingAgent | Der zuständige Bearbeiter oder die zuständige Ressourcengruppe für eine manuelle Aktivität. | ||
| Beschreibung Dieses Attribut gibt an, welche Person oder welches Team eine bestimmte Aufgabe ausgeführt hat. Es kann genauer sein als „Benutzername“, da es insbesondere in Shared-Service-Umgebungen eine Rolle oder ein Team bezeichnet. Im Dashboard „Effizienz der Rückerstattungsfreigabe“ lassen sich damit die Leistungen verschiedener Bearbeiter oder Teams vergleichen. So können Sie die Arbeitsverteilung nachvollziehen, Schulungsbedarf erkennen und leistungsstarke Mitarbeitende oder Teams mit bewährten Vorgehensweisen identifizieren. Warum das wichtig ist Ermöglicht die Leistungsanalyse nach Bearbeiter oder Team. So können Sie die Arbeitslast steuern, Schulungsbedarf erkennen und die Effizienz verbessern. Woher beziehen Diese Information ist möglicherweise über SAP-Business-Partner-Funktionen verfügbar, wenn Bearbeiter zugewiesen sind. Alternativ lässt sie sich aus der Abteilung oder Rolle des Benutzers in der HR-Organisationsstruktur ableiten. Beispiele Support der Stufe 1Team für LagerprüfungenFinanzabteilung - Kreditorenbuchhaltung | |||
| Einhaltung der Rückerstattungs-SLA RefundSlaAdherence | Kennzeichnet, ob die Rückerstattung innerhalb der SLA-Frist bearbeitet wurde. | ||
| Beschreibung Dieses berechnete Attribut prüft, ob die Aktivität „Rückerstattung bearbeitet“ am oder vor dem „Zieldatum für die Rückerstattungs-SLA“ stattgefunden hat. Für jeden Case zeigt es einfach an, ob die SLA eingehalten wurde. Das Attribut ist die zentrale Kennzahl für das Dashboard „Überwachung der Einhaltung der Rückerstattungs-SLA“ und die KPI „Einhaltungsquote der Rückerstattungs-SLA“. Es misst die Leistung im Vergleich zu den Zusagen gegenüber Kunden und zeigt Cases auf, bei denen die Erwartungen nicht erfüllt wurden. So lassen sich die Ursachen von Verzögerungen analysieren. Warum das wichtig ist Misst direkt, ob Zusagen gegenüber Kunden eingehalten werden. Damit ist das Attribut ein wichtiger Indikator für Servicequalität und Kundenzufriedenheit. Woher beziehen Wird für jeden Case berechnet, indem der EventTime der Aktivität „Rückerstattung bearbeitet“ mit dem „RefundSlaTargetDate“ verglichen wird. Beispiele truefalse | |||
| Einhaltung der Rücksenderichtlinien ReturnPolicyAdherence | Kennzeichnet, ob der Retourenfall der festgelegten Retourenrichtlinie entspricht. | ||
| Beschreibung Dieses berechnete boolesche Attribut gibt an, ob eine Retoure die Kriterien der geltenden Retourenrichtlinie erfüllt. Die Logik kann beispielsweise prüfen, ob die Retoure innerhalb der zulässigen Frist eingeleitet wurde oder ob der Retourengrund für das Produkt gültig ist. Das Attribut unterstützt direkt das Dashboard „Übersicht zur Einhaltung der Retourenrichtlinien“. Es quantifiziert die Einhaltungsquoten und ermöglicht es, nicht konforme Cases genauer zu untersuchen und die Gründe für Abweichungen zu verstehen. So können Richtlinien wirksamer durchgesetzt werden. Warum das wichtig ist Quantifiziert die Einhaltung von Geschäftsregeln. So lassen sich Richtlinienverstöße erkennen und reduzieren, die die Rentabilität beeinträchtigen oder Ausnahmen im Prozess verursachen können. Woher beziehen Wird anhand von Geschäftsregeln berechnet. Beispiel: (Datum der Retoureneinleitung - ursprüngliches Kaufdatum) <= [zulässige Rückgabefrist in Tagen]. Dafür werden das ursprüngliche Kaufdatum und die Richtlinien benötigt. Beispiele truefalse | |||
| Ergebnis der Warenprüfung ItemInspectionOutcome | Das Ergebnis der physischen Prüfung der retournierten Ware. | ||
| Beschreibung Dieses Attribut erfasst das Ergebnis der Prüfung, die nach dem Wareneingang im Lager erfolgt. Häufige Ergebnisse sind „Angenommen“, „Abgelehnt - beschädigt“ oder „Angenommen - wiederverkaufsfähig“. Diese Daten liefern wichtigen Kontext für die nachfolgenden Prozessschritte. Sie bestimmen, ob eine vollständige, teilweise oder keine Rückerstattung erfolgt. Die Analyse der Ergebnisse hilft, Gründe für Ablehnungen zu erkennen. Wenn Waren häufig beim Transport beschädigt werden, können die Erkenntnisse auch Hinweise zur Produktverpackung oder zu Versandpartnern liefern. Warum das wichtig ist Macht nachvollziehbar, wie Rückerstattungen freigegeben oder abgelehnt werden. Die Daten geben Aufschluss über den Zustand der Ware und die Gründe für Anpassungen der Rückerstattung. Woher beziehen Diese Information kann in einem Prüflos des Qualitätsmanagementmoduls (QM) oder als Status- beziehungsweise Ursachencode in der Retourenlieferposition (LIPS) erfasst sein. Möglicherweise ist sie auch in einem benutzerdefinierten Feld gespeichert. Beispiele Angenommen - wiederverkaufsfähigAngenommen - Aufarbeitung erforderlichAbgelehnt - vom Kunden verursachter SchadenAbgelehnt - falscher Artikel retourniert | |||
| Gutschriftsnummer CreditMemoNumber | Die eindeutige Kennung des Gutschriftsbelegs, der die Erstattung autorisiert. | ||
| Beschreibung Eine Gutschrift ist der Abrechnungsbeleg, mit dem dem Kundenkonto der Wert der retournierten Artikel offiziell gutgeschrieben wird. Dieses Attribut enthält die eindeutige Nummer des Finanzbelegs. Die Gutschriftsnummer ist wichtig für die Analyse der finanziellen Abwicklung des Retourenprozesses. Sie markiert einen entscheidenden Meilenstein, der häufig die tatsächliche Erstattung auslöst, und wird für den finanziellen Abgleich und Audits benötigt. Warum das wichtig ist Steht für die offizielle Finanztransaktion zur Erstattung. Sie ist entscheidend, um die letzten Prozessschritte nachzuverfolgen und Finanzprüfungen durchzuführen. Woher beziehen Dies ist die Abrechnungsbelegnummer (VBELN) aus der Abrechnungsbelegkopftabelle VBRK. Die Belegkategorie kennzeichnet den Beleg als Gutschrift. Beispiele 900003459000034690000347 | |||
| Ist automatisiert IsAutomated | Kennzeichnet, ob eine Aktivität von einem System oder einer Person ausgeführt wurde. | ||
| Beschreibung Dieses boolesche Attribut unterscheidet zwischen Aktivitäten, die automatisch von einem System ausgeführt werden, etwa durch einen Workflow oder einen Hintergrundjob, und solchen, die ein Benutzer manuell ausführt. Es ist entscheidend für die Berechnung der KPI „Anteil automatisierter Rückerstattungsfreigaben“ und hilft dabei, Automatisierungspotenziale zu erkennen. Wenn Unternehmen nach manuellen Aufgaben filtern, können sie Verbesserungsmaßnahmen auf Bereiche konzentrieren, in denen Automatisierung besonders viel bei Geschwindigkeit, Kosten und Genauigkeit bewirken kann. Warum das wichtig ist Unterscheidet zwischen manuellen und automatisierten Aufgaben. Das ist wichtig, um Automatisierungspotenziale zu erkennen und die Auswirkungen der digitalen Transformation zu messen. Woher beziehen Dieser Wert wird üblicherweise anhand des Benutzernamens abgeleitet. Lautet der Benutzer beispielsweise „WF_BATCH“ oder hat er eine andere System-ID, wird die Aktivität als automatisiert gekennzeichnet. Beispiele truefalse | |||
| Ist Nacharbeit IsRework | Kennzeichnet, ob eine Aktivität in einem Case eine Wiederholung einer früheren Aktivität ist. | ||
| Beschreibung Dieses berechnete boolesche Attribut erkennt Nacharbeit, bei der eine Aktivität innerhalb desselben Case mehr als einmal ausgeführt wird. Das ist zum Beispiel der Fall, wenn eine Warenprüfung wiederholt oder eine Gutschrift erstellt, storniert und anschließend erneut erstellt wird. Das Attribut ist wichtig für das Dashboard „Nacharbeitsanalyse der Rückerstattungsbearbeitung“ und die KPI „Nacharbeitsquote bei Rückerstattungen“. Es macht Prozessineffizienzen sichtbar, indem es Aktivitäten hervorhebt, bei denen häufig Fehler auftreten oder mehrere Versuche nötig sind. So erkennen Sie Bereiche, in denen bessere Kontrollen oder Schulungen erforderlich sind. Warum das wichtig ist Macht Prozessineffizienzen und Fehler sichtbar, indem wiederholte Arbeit gekennzeichnet wird. So können Sie gezielt Verbesserungen umsetzen und Verschwendung sowie Verzögerungen reduzieren. Woher beziehen Dieses Kennzeichen wird üblicherweise vom Process-Mining-Tool selbst berechnet oder bereits bei der Datentransformation ermittelt. Dabei wird geprüft, ob derselbe Aktivitätsname im selben Case bereits zuvor aufgetreten ist. Beispiele truefalse | |||
| Nummer der Retourenlieferung ReturnDeliveryNumber | Die eindeutige Kennung des Retourenlieferbelegs. | ||
| Beschreibung Wenn ein Kunde Ware physisch zurücksendet, wird in SAP ein Retourenlieferbeleg für die Abwicklung der Anlieferung angelegt. Dieses Attribut enthält die eindeutige Nummer des Belegs. Die ID ist wichtig, um den physischen Weg der retournierten Ware nachzuverfolgen. Sie verknüpft die finanziellen und logistischen Aspekte der Retoure und ermöglicht eine detaillierte Analyse des Wareneingangs und der Prüfphase. Warum das wichtig ist Verknüpft den Retourenauftrag mit dem physischen Wareneingang. Das ist wichtig für die Analyse der Logistik- und Lagerbearbeitungszeiten. Woher beziehen Dies ist die Lieferbelegnummer (VBELN) aus der Lieferkopftabelle LIKP. Die Belegkategorie kennzeichnet den Beleg als Retourenlieferung. Beispiele 840000128400001384000014 | |||
| Retourenrichtlinien-ID ReturnPolicyId | Die Kennung der Retourenrichtlinie, die für diesen Retourenfall gilt. | ||
| Beschreibung Dieses Attribut gibt an, welche Retourenrichtlinie oder welches Regelwerk für den Vorgang gilt. Die Richtlinien können je nach Produkttyp, Kundensegment oder Zeit seit dem Kauf variieren. Diese Daten sind für die „Übersicht zur Einhaltung der Retourenrichtlinien“ unerlässlich. Wenn jeder Case einer Richtlinie zugeordnet ist, kann das System automatisch prüfen, ob Vorgaben wie Rückgabefristen oder Anforderungen an den Zustand der Ware eingehalten wurden, und Abweichungen zur Analyse kennzeichnen. Warum das wichtig ist Ermöglicht die automatisierte Prüfung anhand von Geschäftsregeln. So lassen sich Retouren einheitlich und gemäß den geltenden Richtlinien bearbeiten. Woher beziehen Dieses Feld ist in SAP häufig nicht standardmäßig vorhanden. Der Wert muss möglicherweise anhand von Geschäftslogik und Daten wie Produkttyp, Kunde und Verkaufsdatum abgeleitet werden. Falls implementiert, kann er in einem benutzerdefinierten Feld gespeichert sein. Beispiele STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| Status des Retourenauftrags ReturnOrderStatus | Der aktuelle Gesamtstatus des Retourenfalls. | ||
| Beschreibung Dieses Attribut zeigt den übergeordneten Status des Retourenfalls zu einem bestimmten Zeitpunkt an, zum Beispiel „Offen“, „In Bearbeitung“ oder „Abgeschlossen“. Häufig wird der Gesamtstatus aus dem zuletzt abgeschlossenen wichtigen Meilenstein abgeleitet. Das Dashboard „Aktueller Status der Retourenfälle“ bietet eine operative Übersicht über die aktuelle Arbeitslast und die Verteilung der Cases. Führungskräfte sehen, wie viele Cases sich in den einzelnen Prozessphasen befinden, und können Ressourcen und Arbeitslast besser steuern. Warum das wichtig ist Zeigt den aktuellen Prozessstand jedes Case. Das ist eine wichtige Grundlage für operative Dashboards zur Überwachung der Arbeitslast und des Status. Woher beziehen Wird aus den Statusfeldern der relevanten Belege abgeleitet, zum Beispiel aus dem Kopfstatus (GBSTK) oder dem Positionsstatus (LFSTK) des zugehörigen Verkaufsauftrags (VBUK/VBUP) oder der Lieferbelege. Beispiele Wareneingang ausstehendPrüfung ausstehendRückerstattung ausstehendAbgeschlossen | |||
| Verkaufsorganisation SalesOrganization | Die Organisationseinheit, die für den ursprünglichen Verkauf und die Retoure verantwortlich ist. | ||
| Beschreibung Die Verkaufsorganisation ist ein wichtiges Organisationselement in SAP. Sie steht für eine Einheit, die für den Verkauf und Vertrieb von Produkten und Dienstleistungen verantwortlich ist, und wird dem Retourenvorgang zugeordnet. Mit diesem Attribut lassen sich Retourenprozesse nach Geschäftseinheit, Region oder Geschäftsbereich filtern und vergleichen. So können Unternehmen erkennen, ob bestimmte Verkaufsorganisationen höhere Retourenquoten oder weniger effiziente Retourenprozesse aufweisen. Das schafft eine Grundlage für die Analyse der Organisationsleistung. Warum das wichtig ist Ermöglicht den Vergleich von Leistung und Retourenquoten zwischen Geschäftseinheiten, Regionen und Vertriebskanälen. Woher beziehen Die Verkaufsorganisation steht im Feld VKORG der Retourenauftragskopftabelle VBAK. Beispiele 10002100US01 | |||
| Zieldatum für die Rückerstattungs-SLA RefundSlaTargetDate | Das Datum, bis zu dem die Rückerstattung für den Retourenfall bearbeitet werden soll. | ||
| Beschreibung Dieses Attribut legt die Frist des Service Level Agreements (SLA) für die Bearbeitung der Rückerstattung fest. Das Datum wird in der Regel anhand von Geschäftsregeln berechnet, zum Beispiel auf Basis einer bestimmten Anzahl von Tagen nach der Freigabe der Retoure oder dem Wareneingang. Dieses Feld bildet die Grundlage für das Dashboard „Überwachung der Einhaltung der Rückerstattungs-SLA“ und die zugehörige KPI. Damit können Sie gefährdete Cases frühzeitig verfolgen und die Ursachen von Verzögerungen analysieren. So lässt sich letztlich die Kundenzufriedenheit verbessern. Warum das wichtig ist Dient als Grundlage für die Messung der SLA-Einhaltung. So können Sie die Leistung überwachen, ältere Cases priorisieren und die Kundenzufriedenheit verbessern. Woher beziehen Dieser Wert wird fast immer abgeleitet. Die Berechnung basiert auf einem Stichtag, zum Beispiel dem Erstellungsdatum der Retourenanfrage, zuzüglich einer durch Geschäftsregeln festgelegten Frist. Diese kann von Faktoren wie Kundentyp oder Retourengrund abhängen. 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 | Diese Aktivität steht für den Abschluss der Qualitäts- und Zustandsprüfung der retournierten Ware. Im Advanced Returns Management ist dies häufig ein expliziter Schritt, bei dem das Prüfergebnis erfasst und die anschließende Maßnahme festgelegt wird, etwa eine Erstattung oder Verschrottung. | ||
| Warum das wichtig ist Dauer und Ergebnis der Prüfung wirken sich unmittelbar auf die Bearbeitungszeit der Erstattung und die Bestandsverwaltung aus. Diese Aktivität ist wichtig, um die Effizienz der Prüfung und notwendige Nacharbeit zu analysieren. Woher beziehen In SAP Advanced Returns Management (ARM) kann dies als explizites Ereignis aus der Prüftransaktion erfasst werden. Alternativ lässt sich die Aktivität aus einer Statusänderung der Retourenauftragsposition ableiten, die das Prüfergebnis anzeigt. Erfassung Die Aktivität wird aus Transaktionsprotokollen oder Statusänderungen zu den logistischen Folgeaktivitäten in ARM erfasst. Ereignistyp explicit | |||
| Erstattung abgewickelt | Diese Aktivität markiert den letzten Schritt des Erstattungsprozesses: Die finanzielle Gutschrift wird ausgeglichen und die Zahlung an den Kunden gilt als erfolgt. Sie wird aus der Anlage eines Ausgleichsbelegs im Finanzmodul abgeleitet, der den offenen Gutschriftsbetrag auf dem Kundenkonto ausgleicht. | ||
| Warum das wichtig ist Zu diesem Zeitpunkt erhält der Kunde tatsächlich seine Zahlung. Die Zeit vom Beginn der Retoure bis zu diesem Schritt beeinflusst die Kundenzufriedenheit maßgeblich und ist entscheidend für die Messung der SLA-Einhaltung. Woher beziehen Die Aktivität wird aus den Informationen zum Ausgleichsbeleg in der Einzelpostentabelle der Finanzbuchhaltung BSEG abgeleitet. Das Ausgleichsdatum (BSEG-AUGDT) im Kundenposten zur Gutschrift zeigt, wann die Erstattung abgewickelt wurde. Erfassung Die Aktivität wird abgeleitet, wenn im Buchhaltungsbeleg zur Gutschrift das Feld für das Ausgleichsdatum ausgefüllt ist. Ereignistyp inferred | |||
| Gutschrift angelegt | Hier wird der offizielle Abrechnungsbeleg angelegt, der dem Kundenkonto den Wert des retournierten Artikels gutschreibt. Das Ereignis wird explizit erfasst, wenn die Gutschrift aus dem Gutschriftsantrag erstellt wird. | ||
| Warum das wichtig ist Die Anlage der Gutschrift ist ein wichtiger finanzieller Meilenstein. Sie bestätigt den Erstattungsbetrag und gibt den Zahlungsprozess frei. Woher beziehen Die Aktivität wird erfasst, wenn in der Tabelle VBRK ein Abrechnungsbeleg mit der Belegkategorie „Gutschrift“ angelegt wird. Dieser ist in der Tabelle VBFA mit dem Gutschriftsantrag verknüpft. Erfassung Das Ereignis wird erfasst, wenn ein neuer Gutschriftsbeleg gespeichert wird, zum Beispiel über die Transaktion VF01. Ereignistyp explicit | |||
| Gutschriftsantrag angelegt | Nach erfolgreicher Prüfung markiert diese Aktivität die Anlage eines Antrags auf Gutschrift für den Kunden. Erfasst wird sie als neues Verkaufsdokument, ein Gutschriftsantrag mit Bezug zum ursprünglichen Retourenauftrag. | ||
| Warum das wichtig ist Damit beginnt die finanzielle Abwicklung der Retoure. Die Zeit von der Prüfung bis zu diesem Schritt zeigt, wie effizient die Übergabe von der Logistik an die Finanzabteilung erfolgt. Woher beziehen Die Aktivität wird erfasst, wenn in der Tabelle VBAK ein Verkaufsdokument mit der Belegkategorie „Gutschriftsantrag“ angelegt wird. Die Verknüpfung zur Retoure ist in der Belegflusstabelle VBFA hinterlegt. Erfassung Das Ereignis wird erfasst, wenn ein neuer Gutschriftsantrag gespeichert wird. Ereignistyp explicit | |||
| Retourenantrag eingeleitet | Hier beginnt der Retourenprozess: Im System wird offiziell ein Retourenauftrag angelegt. Das Ereignis wird explizit erfasst, wenn in SAP S/4HANA ein neues Verkaufsdokument vom Typ Retourenauftrag gespeichert wird. | ||
| Warum das wichtig ist Diese Aktivität markiert den offiziellen Beginn des Retourenfalls. Die Zeitspanne von diesem Ereignis bis zum Abschluss ist entscheidend, um die gesamte Zykluszeit der Retoure und die Customer Experience zu messen. Woher beziehen Dieses Ereignis wird explizit erfasst, wenn in der Tabelle VBAK ein Verkaufsdokument angelegt wird, dessen Belegkategorie (VBAK-VBTYP) einen Retourenauftrag kennzeichnet. Der Erstellungszeitpunkt steht in VBAK-ERDAT. Erfassung Das Ereignis wird erfasst, wenn ein neuer Retourenauftrag gespeichert wird, zum Beispiel über die Transaktion VA01. Ereignistyp explicit | |||
| Retourenfall abgeschlossen | Dies ist die letzte Aktivität. Sie zeigt an, dass der Retourenprozess abgeschlossen ist und für den Fall keine weiteren Maßnahmen erwartet werden. Üblicherweise wird sie abgeleitet, wenn der Retourenauftrag im System den endgültigen Status „Abgeschlossen“ erreicht. | ||
| Warum das wichtig ist Dieses Ereignis markiert das Ende des Prozesslebenszyklus und ermöglicht die Berechnung der gesamten End-to-End-Zykluszeit. Es bestätigt, dass der Fall vollständig bearbeitet wurde. Woher beziehen Die Aktivität wird abgeleitet, wenn der Gesamtstatus des Retourenauftrags in der Tabelle VBAK oder der Status seiner Positionen in VBAP den Zustand „Vollständig“ oder „Abgeschlossen“ erreicht. Maßgeblich ist die Konfiguration der Statusverwaltung im System. Erfassung Die Aktivität wird abgeleitet, wenn sich der Status des Retourenauftrags auf „Vollständig“ ändert. Ereignistyp inferred | |||
| Ware im Lager eingegangen | Dieses Ereignis markiert den physischen Eingang des retournierten Artikels im Lager oder Bearbeitungszentrum. Es wird explizit erfasst, wenn für die Retourenlieferung ein Wareneingang gebucht und dadurch ein Materialbeleg angelegt wird. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein markiert den Beginn der Zeit für Prüfung und Entscheidung über die weitere Behandlung. Verzögerungen davor liegen im Einflussbereich des Kunden, danach sind sie intern bedingt. Woher beziehen Die Aktivität wird aus den Materialbelegtabellen MSEG und MKPF für die mit Retouren verknüpfte Wareneingangsbewegungsart erfasst. Das Buchungsdatum (MKPF-BUDAT) gibt den Ereigniszeitpunkt an. Erfassung Das Ereignis entspricht der Buchung eines Wareneingangs für die Retourenlieferung. Ereignistyp explicit | |||
| Buchhaltungsbeleg angelegt | Dieses Ereignis tritt ein, wenn die Gutschrift erfolgreich in der Finanzbuchhaltung gebucht wird. Dabei entstehen die entsprechenden Hauptbucheinträge, sodass die Gutschrift auch aus buchhalterischer Sicht offiziell ist. | ||
| Warum das wichtig ist Diese Aktivität bestätigt, dass die Gutschrift in das Finanzsystem übernommen wurde. Die Zeit zwischen der Anlage der Gutschrift und ihrer Buchung kann auf Probleme an der Schnittstelle zwischen Abrechnung und Finanzbuchhaltung hinweisen. Woher beziehen Die Aktivität wird erfasst, wenn in der Buchhaltungstabelle BKPF ein Belegkopf angelegt wird, der mit der Gutschrift in VBRK verknüpft ist (VBRK-BELNR). Erfassung Das Ereignis wird erfasst, sobald der Abrechnungsbeleg erfolgreich in der Finanzbuchhaltung gebucht wurde. Ereignistyp explicit | |||
| Ersatzauftrag angelegt | Diese Aktivität steht für eine alternative Lösung: Statt einer Erstattung wird ein neuer Verkaufsauftrag angelegt, um dem Kunden einen Ersatzartikel zu senden. Erfasst wird sie, wenn ein neuer Verkaufsauftrag mit Bezug zur ursprünglichen Retoure angelegt wird. | ||
| Warum das wichtig ist Diese Aktivität unterscheidet Retouren mit Erstattung von Retouren mit Ersatzlieferung. Für beide gelten unterschiedliche Prozessabläufe und Kundenergebnisse. Sie ist daher wichtig für die Variantenanalyse. Woher beziehen Die Aktivität wird erfasst, wenn in VBAK ein neues Verkaufsdokument angelegt wird, das in der Belegflusstabelle (VBFA) mit dem Retourenauftrag verknüpft ist. Erfassung Das Ereignis wird erfasst, wenn ein neuer Verkaufsauftrag gespeichert wird, der als Ersatzlieferung gekennzeichnet ist. Ereignistyp explicit | |||
| Retoure abgelehnt | Dieses Ereignis zeigt an, dass der zurückgesendete Artikel die Kriterien der Retourenrichtlinie nicht erfüllt und der Erstattungs- oder Gutschriftsantrag abgelehnt wurde. Üblicherweise wird es nach der Prüfung durch einen bestimmten Status oder Ablehnungsgrund in der Retourenauftragsposition erfasst. | ||
| Warum das wichtig ist Die Erfassung von Ablehnungen hilft dabei, die Einhaltung der Retourenrichtlinien zu analysieren und häufige Ablehnungsgründe zu erkennen. Sie bildet einen wichtigen Ausnahmeweg im Prozess. Woher beziehen Die Aktivität wird abgeleitet, wenn in der Retourenauftragsposition ein Ablehnungsgrund (VBAP-ABGRU) eingetragen oder während der Prüfung im Advanced Returns Management ein bestimmter Status zugewiesen wird. Erfassung Die Aktivität wird abgeleitet, wenn im Retourenbeleg eine Ablehnungsbegründung oder ein bestimmter Status „Abgelehnt“ für die Position eingetragen wird. Ereignistyp inferred | |||
| Retourenauftrag freigegeben | Diese Aktivität steht für die formelle Freigabe des Retourenauftrags, durch die er in die nächste Phase übergehen kann. Sie wird üblicherweise aus einer Statusänderung im Kopf oder in der Position des Verkaufsdokuments abgeleitet, die anzeigt, dass bestehende Sperren aufgehoben wurden. | ||
| Warum das wichtig ist Freigabeschritte können erhebliche Verzögerungen verursachen. Wenn Sie diese Aktivität verfolgen, erkennen Sie Engpässe in der anfänglichen Genehmigungsphase des Retourenprozesses. Woher beziehen Die Aktivität wird aus den Tabellen der Statusverwaltung oder aus Statusfeldern in den Tabellen VBAK oder VBAP abgeleitet. Eine Änderung des Freigabestatus oder die Aufhebung einer Liefersperre (VBAP-LIFSP) kann auf eine Freigabe hindeuten. Erfassung Die Aktivität wird aus einer Änderung der Statusfelder im Kopf oder in der Position des Retourenauftrags abgeleitet, die eine Freigabe anzeigt. Ereignistyp inferred | |||
| Retourenlieferung angelegt | Diese Aktivität kennzeichnet die Anlage eines Anlieferungsbelegs, mit dem der physische Eingang der retournierten Ware verwaltet wird. Das System erfasst sie explizit als Anlage eines Lieferbelegs mit Bezug zum Retourenauftrag. | ||
| Warum das wichtig ist Dieser Schritt ist ein wichtiger logistischer Meilenstein. Die Zeit zwischen der Freigabe der Retoure und der Anlage der Lieferung zeigt, wie effizient die Retoureninformationen an das Lager oder die Warenannahme übermittelt werden. Woher beziehen Die Aktivität wird erfasst, wenn in der Tabelle LIKP ein Lieferkopf angelegt wird, der über die Belegflusstabelle VBFA mit dem vorhergehenden Retourenauftrag verknüpft ist. Erfassung Das Ereignis wird erfasst, wenn ein neuer Retourenlieferbeleg gespeichert wird, zum Beispiel über die Transaktion VL01N. Ereignistyp explicit | |||
Anleitungen zur Datenextraktion
Schritte
- Voraussetzungen prüfen: Stellen Sie sicher, dass das Benutzerkonto, mit dem Sie die Daten extrahieren, über die erforderlichen Berechtigungen für den Zugriff auf die benötigten Core Data Services (CDS) Views in SAP S/4HANA verfügt. Zu den wichtigen Views gehören I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry und I_ClearedItem.
- Abfragewerkzeug öffnen: Melden Sie sich bei Ihrem bevorzugten SQL-Client oder Datenintegrationswerkzeug an, das mit der SAP-S/4HANA-Datenbank verbunden ist. Dazu können SAP-eigene Werkzeuge wie SAP Analytics Cloud oder eine ETL-Plattform eines Drittanbieters gehören.
- Abfrageparameter festlegen: Passen Sie vor der Ausführung die bereitgestellte SQL-Abfrage an. Suchen Sie die Platzhalter und ersetzen Sie sie durch die für Ihre Umgebung passenden Parameter. Dazu gehören
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type]sowie weitere Filter für Belegarten oder Buchungskreise. - Extraktionsabfrage ausführen: Kopieren Sie die vollständige SQL-Abfrage und führen Sie sie in Ihrem Werkzeug aus. Die Abfrage führt die Ergebnisse mehrerer SELECT-Anweisungen zusammen und erfasst so alle angegebenen Aktivitäten in einem Datensatz.
- Abfragelogik nachvollziehen: Jeder
SELECT-Block in derUNION ALL-Struktur extrahiert eine bestimmte Aktivität. Dazu verknüpft er mehrere CDS Views, um die benötigten Attribute abzurufen, weistActivityNameeinen festen Textwert zu und wählt den passenden Timestamp fürEventTimeaus. - Rohdaten prüfen: Prüfen Sie die Ausgabe nach Abschluss der Abfrage kurz. Achten Sie auf eine plausible Zeilenanzahl und darauf, dass wichtige Spalten wie
ReturnCaseId,ActivityNameundEventTimewie erwartet befüllt sind. - Daten umwandeln: Die Abfrage erzeugt ein flaches Event-Log-Format. In der Regel sind keine größeren strukturellen Umwandlungen nötig. Je nach Anforderungen des Zielsystems müssen Sie jedoch möglicherweise Timestamp-Formate oder Datentypen anpassen.
- Event Log exportieren: Exportieren Sie das Abfrageergebnis als CSV-Datei. Verwenden Sie UTF-8 als Zeichenkodierung, damit Zeichen in Benutzernamen oder Produktbeschreibungen korrekt dargestellt werden.
- In das Process-Mining-Werkzeug hochladen: Die erzeugte CSV-Datei kann nun in Ihre Process-Mining-Plattform, beispielsweise ProcessMind, hochgeladen werden. Ordnen Sie die Spalten der Datei den entsprechenden Feldern im Werkzeug zu, etwa
ReturnCaseIdder Case-ID,ActivityNameder Aktivität undEventTimedem Timestamp.
Konfiguration
- Voraussetzungen: Der ausführende Benutzer benötigt Anzeigeberechtigungen für Objekte zu Verkaufsbelegen (VBAK), Lieferungen (LIKP), Fakturierung (VBRK) und Buchhaltung (BSEG, BKPF). Der Zugriff auf die zugrunde liegenden CDS Views ist erforderlich.
- Filter für den Datenumfang: Filtern Sie die Abfrage unbedingt nach bestimmten Belegarten, um den Retourenprozess abzugrenzen. Konfigurieren Sie die Platzhalter für Retourenauftragsarten (z. B. 'RE'), Gutschriftsanforderungsarten (z. B. 'G2') und Austauschauftragsarten (z. B. 'SO'). Es empfiehlt sich außerdem, nach
CompanyCodeoderSalesOrganizationzu filtern, um den Datenumfang zu begrenzen. - Filter für den Zeitraum: Begrenzen Sie den Zeitraum, um Leistung und Datenvolumen zu steuern. Beginnen Sie mit den Daten der letzten drei bis sechs Monate. Als primäre Filterbedingung verwendet die Abfrage das Erstellungsdatum des ursprünglichen Retourenauftrags (
I_SalesDocument.CreationDate). - Leistungsaspekte: Diese umfassende Abfrage verknüpft mehrere große CDS Views. Ihre Ausführung kann das Quellsystem S/4HANA stark beanspruchen. Planen Sie die Extraktion außerhalb der Hauptgeschäftszeiten, um die Auswirkungen zu begrenzen. Bei sehr großen Datensätzen empfiehlt sich eine inkrementelle Datenübernahme.
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üfen Sie, ob direkter Lesezugriff auf das SAP-HANA-Schema mit den relevanten Daten zu Verkauf, Lieferung, Fakturierung, Materialbelegen, Prüfungen, Status und Buchhaltung verfügbar ist. Schema, Views und Feldnamen unterscheiden sich je nach SAP-S/4HANA-Installation. Ersetzen Sie daher jeden Platzhalter in eckigen Klammern durch die in Ihrem System konfigurierten Objekte und Felder.
- Legen Sie den Extraktionsumfang mit [Start date], [End date], [Company Code filter] und [Return document type filter] fest. Verwenden Sie für die erste Extraktion einen rollierenden Zeitraum von drei bis sechs Monaten. Verlängern Sie ihn erst, wenn Leistung und Vollständigkeit geprüft wurden.
- Ermitteln Sie die Retourenaufträge anhand von [Your sales document header table] und [Your sales document item table]. Beschränken Sie die Auswahl auf die Retourenauftragsarten, die unter [Your return order document type configuration] konfiguriert sind. Verwenden Sie die Nummer des Retourenauftrags und die Positionsnummer als primäre Verknüpfung zu nachgelagerten Belegen.
- Ermitteln Sie den Belegfluss von Retourenaufträgen zu Retourenanlieferungen, Gutschriftsanforderungen, Austauschaufträgen und Gutschriften mithilfe von [Your document flow table or view]. Gehen Sie nicht davon aus, dass der Belegfluss in VBAK oder VBAP gespeichert ist. Richten Sie die Verknüpfungsfelder entsprechend dem im System verwendeten Belegflussmodell ein.
- Extrahieren Sie explizite Erstellungsereignisse aus den relevanten Belegkopf- und Belegpositionsdaten. Rufen Sie Freigabe-, Ablehnungs-, Prüfungs-, Abschluss-, Wareneingangs-, Buchhaltungs- und Ausgleichsereignisse aus den konfigurierten Status-, Prüfungs-, Materialbeleg-, Buchhaltungs- und Ausgleichsdaten ab. Geben Sie jede Aktivität als separate Ereigniszeile aus, da ProcessMind Ereignisse nicht selbst ableitet.
- Vereinheitlichen Sie Timestamps auf einen konsistenten Datenbank-Timestamp-Typ und eine einheitliche Zeitzone. Verwenden Sie für jede Aktivität die konfigurierte Rangfolge der Ereignis-Timestamps. Wenn nur Datum und Uhrzeit vorliegen, kombinieren Sie diese anhand der unter [Your system time zone] konfigurierten Systemzeitzone.
- Befüllen Sie
ReturnCaseIdfür jedes Ereignis. Verwenden Sie die Nummer des ursprünglichen Retourenauftrags oder, falls Advanced Returns Management einen separaten Fallbezeichner speichert, die konfigurierte Retourenfall-ID. Schließen Sie Ereignisse ohne Zuordnung zu einem Retourenfall aus oder geben Sie sie zur Nachbearbeitung in einer Ausnahmedatei aus. - Befüllen Sie die Pflichtspalten
ReturnCaseId,ActivityName,EventTime,SourceSystemIdundLastDataUpdateTimestamp. Ergänzen Sie nach Möglichkeit auch die empfohlenen SpaltenEventEndTime,UserName,ReturnReason,RefundAmount,ProductIdundCustomerId. Verwenden Sie eine Zeile pro Aktivitätsvorkommen und fassen Sie Aktivitäten nicht zu einer einzelnen Fallzeile zusammen. - Prüfen Sie das Ergebnis anhand der unter
validationStepsaufgeführten Kontrollen. Stellen Sie sicher, dass alle zwölf Aktivitätsnamen vorhanden sind, die Timestamps innerhalb jedes Falls plausibel geordnet sind und die Belegreferenzen mit den Quelldaten übereinstimmen. - Exportieren Sie das Ergebnis als UTF-8-CSV oder in einem anderen von ProcessMind unterstützten Tabellenformat. Behalten Sie die exakten Spaltennamen bei, verwenden Sie eine Kopfzeile, speichern Sie Timestamps in einem eindeutigen ISO-Format und laden Sie das Event Log mit
ReturnCaseIdals Case-ID undActivityNameals Aktivitätsspalte hoch.
Konfiguration
- Zeitraum: Beginnen Sie mit drei bis sechs Monaten. Verwenden Sie die Parameter [Start date] und [End date]. Berücksichtigen Sie genügend historische Daten, damit auch Fälle erfasst werden, die vor dem ausgewählten Zeitraum begonnen und innerhalb dieses Zeitraums abgeschlossen wurden.
- Retourenfälle: Filtern Sie nach den Retourenauftragsarten, die unter [Your return order document type configuration] konfiguriert sind. Hinterlegen Sie keine Belegart fest, bevor Sie sie im Zielsystem geprüft haben.
- Organisationsfilter: Verwenden Sie Filter für [Company Code filter], Verkaufsorganisation, Vertriebsweg, Sparte, Werk oder Kunde nur bei Bedarf. Prüfen Sie, dass dadurch keine Folgebelege zwischen Buchungskreisen oder konzerninternen Folgebelege ausgeschlossen werden.
- Quellobjekte: Ersetzen Sie die Platzhalter [Your table name] und [Your view name] durch freigegebene SAP-S/4HANA-Tabellen oder CDS Views. VBAK, VBAP, VBRK und VBRP sind möglicherweise in Ihrer Installation verfügbar. Prüfen Sie vor der Ausführung, ob sie verwendet und erweitert werden dürfen.
- Umgang mit Timestamps: Konfigurieren Sie für jede Aktivität die Quellfelder für Timestamps und die Zeitzone. Speichern Sie
EventTimeundEventEndTimeeinheitlich, vorzugsweise in UTC oder in der vereinbarten ProcessMind-Zeitzone. - Statusauslegung: Konfigurieren Sie die genauen Statuswerte, Ursachencodes, Prüfergebnisse und Abschlusskennzeichen, die im System Freigabe, Ablehnung, abgeschlossene Prüfung und Fallabschluss abbilden.
- Quellsystemkennung: Ersetzen Sie [Source system identifier] durch einen stabilen Wert, beispielsweise die SAP-Systemkennung, die von der Extraktionsplattform verwendet wird.
- Aktualisierungszeitpunkt: Ersetzen Sie [Extraction timestamp] durch den Zeitpunkt, zu dem die Abfrage gestartet oder der Quellsystem-Snapshot erstellt wurde. Verwenden Sie für alle Zeilen eines Extraktionslaufs denselben Wert, sofern keine Aktualisierungszeitstempel auf Zeilenebene erforderlich sind.
- Leistung: Begrenzen Sie zunächst die Retourenfälle, bevor Sie große Belegfluss-, Buchhaltungs-, Materialbeleg- und Statusdaten verknüpfen. Verwenden Sie indizierte Felder oder Felder, die das Überspringen von Partitionen ermöglichen, und vermeiden Sie uneingeschränkte Tabellenscans. Zwischenergebnisse sollten Sie nur nach Freigabe durch die Datenbankadministration materialisieren.
- Inkrementelle Extraktion: Verwenden Sie bei wiederkehrenden Läufen [Last successful extraction timestamp] und ein kontrolliertes Überlappungsfenster, um nachträgliche Änderungen zu erfassen. Entfernen Sie Duplikate anhand von
ReturnCaseId,ActivityName, dem Quellbelegschlüssel undEventTime. - Berechtigungen und Voraussetzungen: Holen Sie Leseberechtigungen für alle konfigurierten Quellobjekte und Felder sowie die Freigabe für den direkten Datenbankzugriff ein. Prüfen Sie außerdem, ob die erforderlichen SAP-Komponenten und Funktionen von Advanced Returns Management aktiviert sind.
- Datenschutz: Beschränken Sie Kunden- und Finanzdaten auf das erforderliche Minimum, beachten Sie die Datenschutzvorgaben Ihrer Organisation und schützen Sie exportierte Dateien.
Beispielabfrage sql
WITH
parameters AS (
SELECT
CAST('[Start date]' AS TIMESTAMP) AS start_ts,
CAST('[End date]' AS TIMESTAMP) AS end_ts,
CAST('[Extraction timestamp]' AS TIMESTAMP) AS extraction_ts,
CAST('[Source system identifier]' AS NVARCHAR(100)) AS source_system_id
FROM DUMMY
),
return_orders AS (
SELECT
h.[Return order number] AS return_case_id,
i.[Return order item number] AS return_item_id,
h.[Return order creation timestamp] AS return_created_ts,
h.[Return order creator] AS return_creator,
h.[Customer number] AS customer_id,
i.[Product number] AS product_id,
i.[Return reason] AS return_reason,
i.[Return order quantity] AS return_quantity,
h.[Company code] AS company_code,
h.[Return order document type] AS return_document_type
FROM [Your sales document header table] h
INNER JOIN [Your sales document item table] i
ON h.[Sales document number] = i.[Sales document number]
CROSS JOIN parameters p
WHERE h.[Return order creation timestamp] >= p.start_ts
AND h.[Return order creation timestamp] < p.end_ts
AND h.[Return order document type] IN ([Your return order document type filter])
AND h.[Company code] IN ([Company Code filter])
),
document_flow AS (
SELECT
ro.return_case_id,
ro.return_item_id,
f.[Preceding document number] AS preceding_document_id,
f.[Preceding item number] AS preceding_item_id,
f.[Subsequent document number] AS subsequent_document_id,
f.[Subsequent item number] AS subsequent_item_id,
f.[Subsequent document category] AS subsequent_document_category,
f.[Document flow creation timestamp] AS flow_created_ts
FROM return_orders ro
LEFT JOIN [Your document flow table or view] f
ON f.[Preceding document number] = ro.return_case_id
AND f.[Preceding item number] = ro.return_item_id
),
return_delivery AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS delivery_id,
df.subsequent_item_id AS delivery_item_id,
d.[Delivery creation timestamp] AS delivery_created_ts,
d.[Delivery creator] AS delivery_creator,
d.[Delivery completion timestamp] AS delivery_completed_ts
FROM document_flow df
INNER JOIN [Your delivery header table] d
ON d.[Delivery number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Inbound delivery document category]'
),
credit_memo_requests AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_request_id,
df.subsequent_item_id AS credit_memo_request_item_id,
c.[Credit memo request creation timestamp] AS request_created_ts,
c.[Credit memo request creator] AS request_creator
FROM document_flow df
INNER JOIN [Your credit memo request header table] c
ON c.[Credit memo request number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo request document category]'
),
exchange_orders AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS exchange_order_id,
df.subsequent_item_id AS exchange_order_item_id,
e.[Exchange order creation timestamp] AS exchange_created_ts,
e.[Exchange order creator] AS exchange_creator
FROM document_flow df
INNER JOIN [Your exchange order header table] e
ON e.[Exchange order number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Exchange order document category]'
),
credit_memos AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_id,
df.subsequent_item_id AS credit_memo_item_id,
b.[Credit memo creation timestamp] AS credit_memo_created_ts,
b.[Credit memo creator] AS credit_memo_creator,
b.[Credit memo amount] AS refund_amount,
b.[Accounting document number] AS accounting_document_id,
b.[Company code] AS billing_company_code
FROM document_flow df
INNER JOIN [Your billing document header table] b
ON b.[Billing document number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo document category]'
),
approval_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Approval timestamp] AS event_ts,
s.[Approval user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your approved or released status values])
),
inspection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Inspection completion timestamp] AS event_ts,
q.[Inspection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection status] IN ([Your completed inspection status values])
),
rejection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Rejection timestamp] AS event_ts,
q.[Rejection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection outcome or rejection code] IN ([Your rejection reason values])
),
goods_receipt_events AS (
SELECT
rd.return_case_id,
rd.return_item_id,
m.[Goods receipt posting timestamp] AS event_ts,
m.[Goods receipt posting user] AS user_name
FROM return_delivery rd
INNER JOIN [Your material document header table] m
ON m.[Reference delivery number] = rd.delivery_id
INNER JOIN [Your material document item table] mi
ON mi.[Material document number] = m.[Material document number]
AND mi.[Material document item number] = [Your material document item linkage]
WHERE m.[Goods movement type] IN ([Your goods receipt movement type values])
),
accounting_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
a.[Accounting posting timestamp] AS event_ts,
a.[Accounting user] AS user_name
FROM credit_memos cm
INNER JOIN [Your accounting document header table] a
ON a.[Accounting document number] = cm.accounting_document_id
AND a.[Company code] = cm.billing_company_code
WHERE a.[Accounting document status] IN ([Your posted accounting status values])
),
refund_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
cl.[Clearing timestamp] AS event_ts,
cl.[Clearing user] AS user_name
FROM credit_memos cm
INNER JOIN [Your customer clearing table or view] cl
ON cl.[Cleared accounting document number] = cm.accounting_document_id
WHERE cl.[Clearing status] IN ([Your completed clearing status values])
),
closure_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Closure timestamp] AS event_ts,
s.[Closure user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your final closed status values])
),
events AS (
SELECT ro.return_case_id, ro.return_item_id, 'Return Request Initiated' AS activity_name, ro.return_created_ts AS event_time, CAST(NULL AS TIMESTAMP) AS event_end_time, ro.return_creator AS user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)) AS refund_amount, ro.product_id, ro.customer_id FROM return_orders ro
UNION ALL
SELECT ae.return_case_id, ae.return_item_id, 'Return Order Approved', ae.event_ts, CAST(NULL AS TIMESTAMP), ae.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM approval_events ae INNER JOIN return_orders ro ON ro.return_case_id = ae.return_case_id AND ro.return_item_id = ae.return_item_id
UNION ALL
SELECT rd.return_case_id, rd.return_item_id, 'Return Delivery Created', rd.delivery_created_ts, rd.delivery_completed_ts, rd.delivery_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM return_delivery rd INNER JOIN return_orders ro ON ro.return_case_id = rd.return_case_id AND ro.return_item_id = rd.return_item_id
UNION ALL
SELECT gr.return_case_id, gr.return_item_id, 'Goods Received at Warehouse', gr.event_ts, CAST(NULL AS TIMESTAMP), gr.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM goods_receipt_events gr INNER JOIN return_orders ro ON ro.return_case_id = gr.return_case_id AND ro.return_item_id = gr.return_item_id
UNION ALL
SELECT ie.return_case_id, ie.return_item_id, 'Item Inspection Completed', ie.event_ts, CAST(NULL AS TIMESTAMP), ie.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM inspection_events ie INNER JOIN return_orders ro ON ro.return_case_id = ie.return_case_id AND ro.return_item_id = ie.return_item_id
UNION ALL
SELECT re.return_case_id, re.return_item_id, 'Return Rejected', re.event_ts, CAST(NULL AS TIMESTAMP), re.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM rejection_events re INNER JOIN return_orders ro ON ro.return_case_id = re.return_case_id AND ro.return_item_id = re.return_item_id
UNION ALL
SELECT cr.return_case_id, cr.return_item_id, 'Credit Memo Request Created', cr.request_created_ts, CAST(NULL AS TIMESTAMP), cr.request_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM credit_memo_requests cr INNER JOIN return_orders ro ON ro.return_case_id = cr.return_case_id AND ro.return_item_id = cr.return_item_id
UNION ALL
SELECT eo.return_case_id, eo.return_item_id, 'Exchange Order Created', eo.exchange_created_ts, CAST(NULL AS TIMESTAMP), eo.exchange_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM exchange_orders eo INNER JOIN return_orders ro ON ro.return_case_id = eo.return_case_id AND ro.return_item_id = eo.return_item_id
UNION ALL
SELECT cm.return_case_id, cm.return_item_id, 'Credit Memo Created', cm.credit_memo_created_ts, CAST(NULL AS TIMESTAMP), cm.credit_memo_creator, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM credit_memos cm INNER JOIN return_orders ro ON ro.return_case_id = cm.return_case_id AND ro.return_item_id = cm.return_item_id
UNION ALL
SELECT ac.return_case_id, ac.return_item_id, 'Accounting Document Created', ac.event_ts, CAST(NULL AS TIMESTAMP), ac.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM accounting_events ac INNER JOIN return_orders ro ON ro.return_case_id = ac.return_case_id AND ro.return_item_id = ac.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ac.return_case_id AND cm.return_item_id = ac.return_item_id
UNION ALL
SELECT rf.return_case_id, rf.return_item_id, 'Refund Processed', rf.event_ts, CAST(NULL AS TIMESTAMP), rf.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM refund_events rf INNER JOIN return_orders ro ON ro.return_case_id = rf.return_case_id AND ro.return_item_id = rf.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = rf.return_case_id AND cm.return_item_id = rf.return_item_id
UNION ALL
SELECT ce.return_case_id, ce.return_item_id, 'Return Case Closed', ce.event_ts, CAST(NULL AS TIMESTAMP), ce.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM closure_events ce INNER JOIN return_orders ro ON ro.return_case_id = ce.return_case_id AND ro.return_item_id = ce.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ce.return_case_id AND cm.return_item_id = ce.return_item_id
)
SELECT
e.return_case_id AS "ReturnCaseId",
e.activity_name AS "ActivityName",
e.event_time AS "EventTime",
e.event_end_time AS "EventEndTime",
e.user_name AS "UserName",
e.return_reason AS "ReturnReason",
e.refund_amount AS "RefundAmount",
e.product_id AS "ProductId",
e.customer_id AS "CustomerId",
p.source_system_id AS "SourceSystemId",
p.extraction_ts AS "LastDataUpdateTimestamp"
FROM events e
CROSS JOIN parameters p
WHERE e.event_time IS NOT NULL
ORDER BY e.return_case_id, e.event_time, e.activity_name; Möchten Sie loslegen?
Mit diesem Template erhalten Sie das nötige Grundlagenwissen, um Ihre Daten zur Retouren- und Rückerstattungsabwicklung zu extrahieren und zu analysieren. Starten Sie noch heute den Weg zu besseren Prozessen.
Optimieren Sie jetzt die Retouren- und Rückerstattungsabwicklung in SAP S/4HANA
Erkennen Sie Ineffizienzen, verkürzen Sie die Zykluszeit um 30 % und steigern Sie die Zufriedenheit.
Keine Kreditkarte erforderlich. Beginnen Sie noch heute mit der Optimierung.