Ihr Daten-Template für die Retouren- und Erstattungsverarbeitung
Ihr Daten-Template für die Retouren- und Erstattungsverarbeitung
- Empfohlene zu erfassende Attribute
- Wichtige zu überwachende Aktivitäten
- Hinweise zur Extraktion
Attribute der Retouren- und Rückerstattungsabwicklung
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Der Name einer bestimmten Geschäftsaktivität oder eines Events, das innerhalb des Retouren- und Rückerstattungsprozesses stattgefunden hat. | ||
| Beschreibung Dieses Attribut beschreibt einen einzelnen Schritt oder Meilenstein im Lebenszyklus einer Retoure. Aktivitäten stehen für ausgeführte Arbeiten, etwa „Retourenauftrag genehmigt“ oder „Artikelprüfung abgeschlossen“. Sie werden aus Statusänderungen, der Erstellung von Dokumenten oder bestimmten Benutzeraktionen in SAP S/4HANA abgeleitet. Die Analyse der Reihenfolge und Häufigkeit dieser Aktivitäten bildet den Kern des Process Mining. Sie hilft, die Prozesslandkarte zu visualisieren, häufige und seltene Prozesspfade zu erkennen sowie Aktivitäten zu identifizieren, die wiederholt auftreten und damit auf Nacharbeit oder Ineffizienzen hinweisen. Warum das wichtig ist Aktivitäten bilden das Rückgrat der Prozesslandkarte. Sie ermöglichen die Visualisierung und Analyse des Prozessflusses, von Engpässen und von Abweichungen. Bezugsquelle Aktivitätsnamen werden in der Regel aus einer Kombination verschiedener Daten abgeleitet, etwa aus Dokumentstatusänderungen in Tabellen wie VBUK/VBUP, aus Erstellungsevents in Kopftabellen wie VBAK (Verkaufsdokumente) und BKPF (Buchhaltungsbelege) sowie aus Warenbewegungsstatus in MSEG. Beispiele Rückgabeanfrage eröffnetWaren im Lager eingegangenGutschrift angelegtRückerstattung verarbeitet | |||
| Eventzeit EventTime | Der präzise Timestamp, der angibt, wann eine bestimmte Aktivität stattgefunden hat. | ||
| Beschreibung Eventzeit erfasst das Datum und die Uhrzeit, zu denen ein Geschäftsereignis im System aufgezeichnet wurde. Dieser Timestamp ist entscheidend für die chronologische Anordnung von Aktivitäten und für alle zeitbezogenen Analysen. Im Process Mining wird dieses Attribut verwendet, um Durchlaufzeiten zwischen Aktivitäten zu berechnen, die Dauer einzelner Schritte zu ermitteln und die Prozessleistung im Zeitverlauf zu analysieren. Es bildet die Grundlage für die Ermittlung von Engpässen, die Überwachung der SLA-Einhaltung und das Verständnis der zeitlichen Abläufe im Retourenprozess. Warum das wichtig ist Dieser Timestamp ist unverzichtbar für die Anordnung von Events, die Berechnung sämtlicher Dauern und Durchlaufzeiten sowie die Ermittlung von Prozessverzögerungen. Bezugsquelle In der Regel stammen die Werte aus Datums- und Zeitfeldern, die mit der Erstellung von Dokumenten oder Statusänderungen verbunden sind, etwa ERDAT (Erstellungsdatum) und ERZET (Erstellungszeit) in Tabellen wie VBAK, LIKP und BKPF oder aus dem Buchungsdatum (BUDAT) in Buchhaltungsbelegen. Beispiele 2023-10-26T10:05:00Z2023-10-27T14:30:15Z2023-10-28T09:00:00Z | |||
| Retourenfall-ID ReturnCaseId | Die eindeutige Kennung für einen einzelnen Retourenprozess des Kunden, die alle zugehörigen Aktivitäten von der Einleitung bis zum Abschluss verknüpft. | ||
| Beschreibung Die Retourenfall-ID ist die primäre Kennung, die alle Events und Aktivitäten eines einzelnen Retourenfalls zusammenführt. Jeder Retourenanfrage des Kunden wird eine eindeutige ID zugewiesen. Dadurch lässt sich der gesamte Prozess durchgängig verfolgen. 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 es voneinander getrennte Events wie „Retourenanfrage eingeleitet“, „Ware eingegangen“ und „Rückerstattung verarbeitet“ für jede einzelne Retoure zu einer zusammenhängenden Zeitleiste verbindet. Warum das wichtig ist Dies ist der zentrale Schlüssel für die Nachverfolgung einer Retoure vom Anfang bis zum Ende. Er ermöglicht alle Analysen auf Case-Ebene, einschließlich der Durchlaufzeit und der Ermittlung von Prozessvarianten. Bezugsquelle In der Regel handelt es sich um die Verkaufsbelegnummer (VBELN) aus der Kopfdatentabelle VBAK des Retourenauftrags. Die Dokumentkategorie (VBTYP) kennzeichnet dabei eine Retoure. Beispiele 600001896000019060000191 | |||
| ID des Quellsystems SourceSystemId | Kennung des Quellsystems, aus dem die Daten extrahiert wurden. | ||
| Beschreibung Dieses Attribut gibt an, aus welchem führenden System die Eventdaten stammen. Für diesen Prozess handelt es sich in der Regel um die ID der SAP-S/4HANA-Instanz. In Umgebungen mit mehreren Systemen ist dieses Feld für die Datenherkunft, die Fehleranalyse und die Sicherstellung der Datenintegrität entscheidend. Es hilft, Daten zu unterscheiden, wenn Retouren über verschiedene ERP-Instanzen verarbeitet oder mit externen Systemen wie einem Lagerverwaltungssystem integriert werden. Warum das wichtig ist Liefert wichtigen Kontext zur Datenherkunft und Datenlinie, insbesondere in Landschaften mit mehreren Systemen, und stellt die Nachvollziehbarkeit und Vertrauenswürdigkeit der Daten sicher. Bezugsquelle Dieser Wert ist normalerweise statisch und wird bei der Datenextraktion konfiguriert. Er kann aus den administrativen Informationen des SAP-Systems, etwa der System-ID (SID), abgerufen werden. Beispiele S4H_PROD_100S4Q_DEV_200 | |||
| Letzte Datenaktualisierung LastDataUpdateTimestamp | Der Timestamp, der angibt, wann die Daten für dieses Event 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. Diese Information ist wichtig, um die Aktualität der Process-Mining-Analyse einzuschätzen. Sie zeigt, wie aktuell die Daten sind, was insbesondere für die operative Überwachung und Dashboards zur Nachverfolgung laufender Cases relevant ist. Warum das wichtig ist Zeigt die Aktualität der Daten an. Das ist entscheidend, damit Analysen und Dashboards auf aktuellen Informationen basieren. Bezugsquelle Dieser Wert wird in der Regel zum Zeitpunkt der Datenextraktion durch das ETL- oder Datenpipeline-Tool im Datensatz erzeugt und mit einem Timestamp versehen. Beispiele 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Benutzername UserName | Die Benutzer-ID des Mitarbeiters, der die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut identifiziert den Benutzer oder Systemagenten, der für die Ausführung einer Aufgabe verantwortlich ist, etwa für die Genehmigung einer Retoure oder die Erstellung einer Gutschrift. In SAP wird diese Information häufig in Feldern erfasst, die den Benutzer protokollieren, der ein Dokument angelegt oder geändert hat. Die Analyse nach Benutzer hilft, leistungsstarke Personen oder Teams, Schulungsbedarf und die Arbeitsverteilung zu erkennen. Sie ist außerdem für die Untersuchung von Abweichungen wichtig, da sie Prozessaktionen einzelnen Personen zuordnet und damit Compliance- und Audit-Anforderungen unterstützt. Warum das wichtig ist Ordnet Prozessaktivitäten bestimmten Benutzern zu und ermöglicht so die Analyse von Teamleistung, Arbeitsauslastung und Compliance. Bezugsquelle Häufig in Dokumentkopftabellen zu finden, etwa ERNAM (Angelegt von) in VBAK (Verkaufsaufträge), LIKP (Lieferungen) und BKPF (Buchhaltungsbelege). Benutzerdetails können über die Benutzerstammtabelle USR21 ergänzt werden. Beispiele CBROWNASMITHWF_BATCH | |||
| Endzeit des Events EventEndTime | Der Timestamp, der den Abschluss einer Aktivität kennzeichnet und zur Berechnung ihrer Dauer verwendet wird. | ||
| Beschreibung Während StartTime (EventTime) den Beginn einer Aktivität markiert, kennzeichnet EventEndTime deren Abschluss. Bei vielen systemgenerierten Events sind Start- und Endzeit identisch, da sie einen punktuellen Vorgang darstellen. Für Aktivitäten mit messbarer Dauer, etwa „Artikelprüfung“, ist dieses Attribut jedoch entscheidend. Es ermöglicht die direkte Berechnung der Bearbeitungszeit einer Aktivität. Das ist eine wichtige Grundlage für die Leistungsanalyse, da sich damit nicht nur die Zeitabstände zwischen Aktivitäten, sondern auch die zeitaufwendigsten Prozessschritte identifizieren lassen. Warum das wichtig ist Ermöglicht die präzise Berechnung der Dauer einzelner Aktivitäten und hilft dadurch, Ineffizienzen in bestimmten Prozessschritten gezielt zu erkennen. Bezugsquelle Dieser Wert wird häufig abgeleitet. Für einige Aktivitäten kann ein eigenes Feld vorhanden sein. Häufiger entspricht er der StartTime der nachfolgenden Aktivität im Case. Beispiele 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| Kunden-ID CustomerId | Die eindeutige Kennung des Kunden, der die Retoure einleitet. | ||
| Beschreibung Dieses Attribut identifiziert den Kunden, der die Retoure angefordert hat. Es verknüpft die Prozessinstanz mit einer bestimmten Partei in den Kundenstammdaten. Die Analyse von Retouren nach Kunde hilft, Muster zu erkennen, etwa Kunden mit ungewöhnlich hohen Retourenquoten. Dies kann auf betrügerisches Verhalten oder Unzufriedenheit hinweisen. Außerdem ermöglicht sie die Segmentierung des Retourenprozesses nach Kundentyp, Wert oder Historie und damit eine gezielte Gestaltung der Servicelevel. Warum das wichtig ist Verknüpft Retouren mit bestimmten Kunden und ermöglicht die Analyse des Kundenverhaltens, die Segmentierung sowie die Ermittlung von Kunden mit besonders häufigen Retouren. Bezugsquelle Zu finden im Kundennummernfeld (KUNNR) der Kopfdatentabelle des Retourenauftrags (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. Dies kann auf Qualitätsmängel, unzureichende Produktbeschreibungen oder Herstellungsprobleme hinweisen. Die Daten unterstützen fundierte Entscheidungen zu Produktdesign, Lieferantenmanagement und Bestandsstrategie. Warum das wichtig ist Verknüpft den Retourenprozess mit bestimmten Produkten und ermöglicht die Analyse von Retourenquoten auf Artikelebene sowie die Ermittlung von Qualitäts- oder Beschreibungsproblemen. Bezugsquelle Zu finden im Materialnummernfeld (MATNR) der Positionstabelle des Retourenauftrags (VBAP) oder der Positionstabelle der Retourenanlieferung (LIPS). Beispiele FG-10023HW-45981SW-LICENSE-PREM | |||
| Retourengrund ReturnReason | Der vom Kunden angegebene Grund für die Retoure des Artikels. | ||
| Beschreibung Dieses Attribut erfasst den vom Kunden genannten Retourengrund, etwa „Artikel defekt“, „Falsche Größe“ oder „Nicht mehr benötigt“. In der Regel wird er bei der Einleitung der Retoure aus einer vordefinierten Liste von Ursachencodes ausgewählt. Die Analyse von Retourengründen ist entscheidend, um Qualitätsprobleme bei Produkten zu erkennen, Produktbeschreibungen zu verbessern oder Vertriebsprozesse anzupassen. Sie liefert direkte Erkenntnisse zur Unzufriedenheit der Kunden und hilft, Verbesserungsmaßnahmen zu priorisieren, um die Retourenquote insgesamt zu senken. Warum das wichtig ist Liefert wichtige Erkenntnisse darüber, warum Retouren entstehen, und ermöglicht eine Ursachenanalyse zu Produktqualität, Fehlern bei der Auftragsabwicklung oder nicht erfüllten Kundenerwartungen. Bezugsquelle In der Regel in der Positionstabelle des Retourenverkaufsauftrags (VBAP) im Feld ABGRU (Ablehnungsgrund für Verkaufsdokumente) gespeichert. Beispiele 001 - Mangelhafte Qualität002 - Beim Transport beschädigt005 - Falscher Artikel versendet | |||
| Rückerstattungsbetrag RefundAmount | Der endgültige Geldbetrag, der dem Kunden erstattet wird. | ||
| Beschreibung Dieses Attribut stellt den tatsächlichen Betrag dar, der dem Kunden nach Abschluss des Retourenprozesses gutgeschrieben oder erstattet wird. Der Wert wird in Finanzdokumenten wie Gutschriften erfasst. Er ist eine wichtige Finanzkennzahl für verschiedene Analysen. Das Dashboard „Analyse von Abweichungen beim Rückerstattungsbetrag“ verwendet ihn zum Vergleich mit dem angeforderten Betrag. Außerdem lassen sich Retouren nach ihrem Wert segmentieren, um zu erkennen, ob hochwertige Retouren einem anderen Prozess folgen oder länger bearbeitet werden. Warum das wichtig ist Erfasst die finanziellen Auswirkungen von Retouren und ist entscheidend für die Analyse der Genauigkeit von Rückerstattungen, die Ermittlung hochwertiger Cases und das Verständnis der Gesamtkosten. Bezugsquelle Stammt aus dem Nettowertfeld (NETWR) des Gutschriftsdokuments, das in Tabellen wie VBRK (Fakturadokumentkopf) oder BSEG (Segment des Buchhaltungsbelegs) zu finden ist. Beispiele 125.50999.0049.99 | |||
| Angeforderter Rückerstattungsbetrag RequestedRefundAmount | Der zu Beginn des Prozesses ursprünglich angeforderte oder erwartete Rückerstattungsbetrag. | ||
| Beschreibung Dieses Attribut erfasst den Wert der retournierten Waren gemäß der ursprünglichen Retourenanfrage. Er dient als Vergleichsbasis für den endgültig erstatteten Betrag. Dieses Feld wird speziell für das Dashboard „Analyse von Abweichungen beim Rückerstattungsbetrag“ benötigt. Der Vergleich des angeforderten mit dem tatsächlichen Rückerstattungsbetrag hilft, Teilrückerstattungen aufgrund beschädigter Artikel, Wiedereinlagerungsgebühren oder anderer Anpassungen zu erkennen und dadurch finanzielle Genauigkeit und Transparenz sicherzustellen. Warum das wichtig ist Dient als Vergleichsbasis für die Messung der Genauigkeit von Rückerstattungen und hilft, Abweichungen zwischen erwarteten und tatsächlichen Rückerstattungsbeträgen zu erkennen und zu analysieren. Bezugsquelle Stammt in der Regel aus dem Nettowert der Artikel im ursprünglichen Retourenverkaufsauftrag. Dabei handelt es sich um den Nettowert (NETWR) der entsprechenden Positionen in der Tabelle VBAP. Beispiele 125.501050.0049.99 | |||
| Automatisiert IsAutomated | Ein Kennzeichen dafür, ob eine Aktivität von einem System oder von einem Menschen 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 Aktivitäten, die ein Benutzer manuell ausführt. Es ist entscheidend für die Berechnung der KPI „Automatisierungsquote bei Rückerstattungsgenehmigungen“ und für die Ermittlung von Automatisierungsmöglichkeiten. Durch die Filterung nach manuellen Aufgaben können Unternehmen Verbesserungsmaßnahmen auf Bereiche konzentrieren, in denen Automatisierung den größten Nutzen bei Geschwindigkeit, Kosten und Genauigkeit verspricht. Warum das wichtig ist Unterscheidet zwischen manuellen und automatisierten Aufgaben. Das ist entscheidend, um Automatisierungsmöglichkeiten zu erkennen und die Auswirkungen der digitalen Transformation zu messen. Bezugsquelle Wird in der Regel anhand des Benutzernamens abgeleitet. Wenn der Benutzer beispielsweise „WF_BATCH“ oder eine andere System-ID ist, wird die Aktivität als automatisiert gekennzeichnet. Beispiele truefalse | |||
| Bearbeitungsmitarbeiter ProcessingAgent | Der bestimmte Mitarbeiter oder die Ressourcengruppe, die für eine manuelle Aktivität verantwortlich ist. | ||
| Beschreibung Dieses Attribut identifiziert die Person oder das Team, die beziehungsweise das eine bestimmte Aufgabe ausgeführt hat. Es kann genauer sein als der „Benutzername“, da es insbesondere in Shared-Services-Umgebungen eine Rolle oder ein Team bezeichnet. Das ist für das Dashboard „Effizienz der Rückerstattungsgenehmigung“ wertvoll, um die Leistung verschiedener Mitarbeiter oder Teams zu analysieren. Es hilft, die Arbeitsverteilung zu verstehen, Schulungsbedarf zu erkennen und besonders leistungsstarke Personen oder Teams mit übertragbaren Best Practices zu identifizieren. Warum das wichtig ist Ermöglicht die Leistungsanalyse auf Ebene von Mitarbeitern oder Teams und unterstützt die Steuerung der Arbeitsauslastung, die Ermittlung von Schulungsmöglichkeiten und die Verbesserung der Effizienz. Bezugsquelle Diese Information kann über SAP-Business-Partner-Funktionen verfügbar sein, wenn Mitarbeiter zugeordnet sind. Alternativ lässt sie sich aus der Abteilung oder Rolle des Benutzers in der HR-Organisationsstruktur ableiten. Beispiele Support der Stufe 1Prüfungsteam des LagersFinanzabteilung, Kreditorenbuchhaltung | |||
| Einhaltung der Retourenrichtlinie ReturnPolicyAdherence | Ein Kennzeichen dafür, ob der Retourenfall die definierte Rückgaberichtlinie einhält. | ||
| Beschreibung Dieses berechnete boolesche Attribut gibt an, ob eine Retoure die Kriterien der geltenden Rückgaberichtlinie 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. Dieses Attribut unterstützt direkt das Dashboard „Übersicht zur Compliance mit Rückgaberichtlinien“. Es quantifiziert die Compliance-Quote und ermöglicht den Drill-down in nicht konforme Cases, um die Gründe für Abweichungen zu verstehen und Richtlinien wirksamer durchzusetzen. Warum das wichtig ist Quantifiziert die Einhaltung von Geschäftsregeln und hilft, Richtlinienverstöße zu erkennen und zu reduzieren, die die Profitabilität beeinträchtigen oder Prozessausnahmen verursachen können. Bezugsquelle Wird auf Grundlage von Geschäftsregeln berechnet. Zum Beispiel: (Datum der Retoureneinleitung – Datum des ursprünglichen Kaufs) <= [Zulässige Rückgabetage]. Dafür werden das Datum des ursprünglichen Kaufs und die Richtlinienregeln benötigt. Beispiele truefalse | |||
| Einhaltung des Erstattungs-SLA RefundSlaAdherence | Ein Kennzeichen, das angibt, ob die Erstattung innerhalb des Zielwerts des Service Level Agreement (SLA) verarbeitet wurde. | ||
| Beschreibung Dieses berechnete Attribut prüft, ob die Aktivität „Erstattung verarbeitet“ am oder vor dem „Zieldatum für das Erstattungs-SLA“ stattgefunden hat. Für jeden Case liefert es eine einfache Ja-oder-Nein-Anzeige zur SLA-Konformität. Dies ist die zentrale Kennzahl für das Dashboard „Überwachung der Erstattungs-SLA-Einhaltung“ und den KPI „Erstattungs-SLA-Einhaltungsquote“. Sie unterstützt die Messung der Leistung im Verhältnis zu Kundenverpflichtungen und identifiziert Fälle, in denen Erwartungen nicht erfüllt wurden. Dadurch wird eine Ursachenanalyse von Verzögerungen möglich. Warum das wichtig ist Misst direkt die Leistung im Verhältnis zu kundenbezogenen Verpflichtungen und ist damit ein wichtiger Indikator für Servicequalität und Kundenzufriedenheit. Bezugsquelle Wird berechnet, indem der EventTime der Aktivität „Erstattung verarbeitet“ mit dem „RefundSlaTargetDate“ jedes Cases verglichen wird. Beispiele truefalse | |||
| Ergebnis der Artikelprüfung ItemInspectionOutcome | Das Ergebnis der physischen Prüfung des retournierten Artikels. | ||
| Beschreibung Dieses Attribut erfasst das Ergebnis der Prüfung, die nach dem Wareneingang im Lager durchgeführt wird. Häufige Ergebnisse sind „Akzeptiert“, „Abgelehnt, beschädigt“ oder „Akzeptiert, wiederverkaufsfähig“. Diese Daten liefern wichtigen Kontext für die nachfolgenden Prozessschritte. Sie bestimmen, ob eine vollständige Rückerstattung, eine Teilrückerstattung oder keine Rückerstattung erfolgt. Die Analyse des Ergebnisses hilft, Ablehnungsgründe zu erkennen. Wenn Artikel häufig beim Transport beschädigt werden, kann sie außerdem Hinweise auf Probleme bei der Verpackung oder mit Versandpartnern liefern. Warum das wichtig ist Erklärt die Entscheidungsgrundlage für die Genehmigung oder Ablehnung von Rückerstattungen und liefert wertvolle Daten zum Artikelzustand sowie zu den Gründen für Anpassungen des Rückerstattungsbetrags. Bezugsquelle Diese Information kann in einem Prüflos des Qualitätsmanagements (QM) oder als Status- beziehungsweise Ursachencode auf der Position der Retourenanlieferung (LIPS) erfasst werden. Sie kann auch in einem kundenspezifischen Feld vorliegen. Beispiele Angenommen, wiederverkaufsfähigAngenommen, Aufarbeitung erforderlichAbgelehnt, vom Kunden verursachter SchadenAbgelehnt, falscher Artikel zurückgesendet | |||
| Gutschriftsnummer CreditMemoNumber | Die eindeutige Kennung des Gutschriftsdokuments, das die Rückerstattung autorisiert. | ||
| Beschreibung Eine Gutschrift ist das Fakturadokument, mit dem das Kundenkonto offiziell für die retournierten Artikel gutgeschrieben wird. Dieses Attribut enthält die eindeutige Nummer dieses Finanzdokuments. Die Nachverfolgung der Gutschriftsnummer ist für die Analyse der finanziellen Abwicklung des Retourenprozesses entscheidend. Sie markiert einen wichtigen Meilenstein, löst häufig die eigentliche Rückerstattungszahlung aus und wird für den finanziellen Abgleich sowie für Audits benötigt. Warum das wichtig ist Steht für die offizielle Finanztransaktion der Rückerstattung und ist entscheidend für die Nachverfolgung der letzten Prozessphasen sowie für Finanzprüfungen. Bezugsquelle Dabei handelt es sich um die Fakturadokumentnummer (VBELN) aus der Kopfdatentabelle der Fakturadokumente (VBRK). Die Dokumentkategorie kennzeichnet eine Gutschrift. Beispiele 900003459000034690000347 | |||
| ID der Rückgaberichtlinie ReturnPolicyId | Die Kennung der Rückgaberichtlinie, die für diesen Retourenfall gilt. | ||
| Beschreibung Dieses Attribut gibt an, welche Rückgaberichtlinie oder welches Regelwerk für die Transaktion gilt. Richtlinien können je nach Produkttyp, Kundensegment oder Zeit seit dem Kauf variieren. Diese Daten sind für die „Übersicht zur Compliance mit Rückgaberichtlinien“ entscheidend. Durch die Zuordnung jedes Cases zu einer Richtlinie kann das System automatisch prüfen, ob Regeln wie Rückgabefristen oder Anforderungen an den Artikelzustand eingehalten werden, und Abweichungen für die Analyse kennzeichnen. Warum das wichtig ist Ermöglicht die automatisierte Prüfung der Compliance mit Geschäftsregeln und trägt dazu bei, Retouren einheitlich und richtlinienkonform zu bearbeiten. Bezugsquelle Dies ist häufig kein Standardfeld in SAP und muss möglicherweise anhand von Geschäftslogik abgeleitet werden, etwa aus Produkttyp, Kunde und Verkaufsdatum. Falls implementiert, kann der Wert in einem kundenspezifischen Feld gespeichert werden. Beispiele STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| Ist Nacharbeit IsRework | Ein Kennzeichen, das angibt, ob eine Aktivität in einem Case eine Wiederholung einer vorherigen Aktivität ist. | ||
| Beschreibung Dieses berechnete boolesche Attribut identifiziert Nacharbeit, wenn eine Aktivität innerhalb desselben Cases mehr als einmal ausgeführt wird. Beispiele sind eine wiederholte Artikelprüfung oder eine Gutschrift, die erstellt, storniert und anschließend erneut erstellt wird. Dieses Attribut ist für das Dashboard „Analyse der Nacharbeit in der Erstattungsverarbeitung“ und den KPI „Nacharbeitsquote bei Erstattungen“ unverzichtbar. Es quantifiziert Prozessineffizienzen, indem es Aktivitäten hervorhebt, die fehleranfällig sind oder mehrere Versuche erfordern. So lassen sich Bereiche erkennen, in denen bessere Kontrollen oder Schulungen erforderlich sind. Warum das wichtig ist Macht Prozessineffizienzen und Fehler sichtbar, indem wiederholte Arbeit gekennzeichnet wird. Dadurch können Sie gezielt Verbesserungen umsetzen und Verschwendung sowie Verzögerungen reduzieren. Bezugsquelle Dieses Kennzeichen wird in der Regel vom Process-Mining-Tool selbst berechnet oder bereits in der Datentransformation ermittelt. Es prüft, ob derselbe Aktivitätsname zuvor im selben Case aufgetreten ist. Beispiele truefalse | |||
| Nummer der Retourenanlieferung ReturnDeliveryNumber | Die eindeutige Kennung des Dokuments für die Retourenanlieferung. | ||
| Beschreibung Wenn ein Kunde Waren physisch zurücksendet, wird in SAP ein Dokument für die Retourenanlieferung angelegt, um die eingehende Logistik zu steuern. Dieses Attribut enthält die eindeutige Nummer dieses Dokuments. Die ID ist wichtig für die Nachverfolgung der physischen Bewegung der retournierten Waren. Sie verbindet die finanziellen und logistischen Aspekte der Retoure und ermöglicht eine detaillierte Analyse der Wareneingangs- und Prüfphasen. Warum das wichtig ist Stellt eine wichtige Verbindung zwischen Retourenauftrag und physischem Wareneingang her und ist entscheidend für die Analyse von Logistik- und Lagerbearbeitungszeiten. Bezugsquelle Dabei handelt es sich um die Lieferdokumentnummer (VBELN) aus der Lieferkopftabelle (LIKP). Die Dokumentkategorie kennzeichnet eine Retourenanlieferung. Beispiele 840000128400001384000014 | |||
| Status des Retourenauftrags ReturnOrderStatus | Der aktuelle Gesamtstatus des Retourenfalls. | ||
| Beschreibung Dieses Attribut liefert zu jedem Zeitpunkt einen übergeordneten Status des Retourenfalls, etwa „Offen“, „In Bearbeitung“ oder „Geschlossen“. Häufig handelt es sich um einen aggregierten Status, der aus dem zuletzt abgeschlossenen wichtigen Meilenstein abgeleitet wird. Das Attribut ist für das Dashboard „Aktueller Status der Retourenfälle“ entscheidend. Es bietet eine operative Übersicht über Arbeitsbestand und Fallverteilung. So können Verantwortliche erkennen, wie viele Cases sich in den einzelnen Prozessphasen befinden, und Ressourcen sowie Arbeitslast besser steuern. Warum das wichtig ist Liefert eine Momentaufnahme der Position jedes Cases im Prozess und ist damit für operative Dashboards zur Überwachung von Arbeitsbestand und Status unverzichtbar. Bezugsquelle Abgeleitet aus den Statusfeldern der relevanten Dokumente, beispielsweise aus dem Kopfstatus (GBSTK) oder Positionsstatus (LFSTK) des zugehörigen Verkaufsauftrags (VBUK/VBUP) oder der Lieferdokumente. Beispiele Warten auf WareneingangPrüfung ausstehendRückerstattung ausstehendGeschlossen | |||
| Verkaufsorganisation SalesOrganization | Die Organisationseinheit, die für den ursprünglichen Verkauf und die Retoure verantwortlich ist. | ||
| Beschreibung Die Verkaufsorganisation ist ein zentrales Organisationselement in SAP. Sie steht für eine Einheit, die für den Verkauf und Vertrieb von Produkten und Dienstleistungen verantwortlich ist, und wird der Retourentransaktion zugeordnet. Dieses Attribut ermöglicht es, den Retourenprozess über verschiedene Geschäftsbereiche, Regionen oder Divisionen hinweg zu filtern und zu vergleichen. So lässt sich erkennen, ob bestimmte Verkaufsorganisationen höhere Retourenquoten oder weniger effiziente Retourenprozesse aufweisen. Damit bildet es eine Grundlage für die Analyse der Organisationsleistung. Warum das wichtig ist Ermöglicht den Vergleich von Leistung und Quoten des Retourenprozesses über verschiedene Geschäftsbereiche, Regionen oder Vertriebskanäle hinweg. Bezugsquelle Zu finden im Feld für die Verkaufsorganisation (VKORG) der Kopfdatentabelle des Retourenauftrags (VBAK). Beispiele 10002100US01 | |||
| Zieldatum für Rückerstattungs-SLA RefundSlaTargetDate | Das Zieldatum, bis zu dem die Rückerstattung für den Retourenfall verarbeitet sein sollte. | ||
| Beschreibung Dieses Attribut definiert die Frist des Service Level Agreement (SLA) für die Verarbeitung der Rückerstattung. Das Datum wird in der Regel anhand von Geschäftsregeln berechnet, beispielsweise als eine bestimmte Anzahl von Tagen nach der Genehmigung der Retoure oder dem Wareneingang. Dieses Feld bildet die Grundlage für das Dashboard „Überwachung der Rückerstattungs-SLA-Einhaltung“ und die zugehörige KPI. Es ermöglicht die frühzeitige Nachverfolgung von Cases, bei denen ein SLA-Verstoß droht, sowie die Analyse der Ursachen von Verzögerungen. So lässt sich die Customer Experience verbessern. Warum das wichtig ist Liefert die Grundlage für die Messung der SLA-Compliance und unterstützt die Überwachung der Leistung, die Priorisierung überfälliger Cases und die Verbesserung der Customer Experience. Bezugsquelle Dies ist fast immer ein abgeleitetes Feld. Die Logik basiert auf einem Stichtag, etwa dem Erstellungsdatum der Retourenanfrage, zuzüglich einer durch Geschäftsregeln definierten Dauer. Dabei können Faktoren wie Kundentyp oder Retourengrund berücksichtigt werden. 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 bezeichnet den Abschluss der Qualitäts- und Zustandsbewertung der zurückgesendeten Waren. Im Advanced Returns Management ist dies häufig ein ausdrücklicher Schritt, der das Prüfergebnis erfasst und die anschließende Maßnahme wie Erstattung oder Verschrottung bestimmt. | ||
| Warum das wichtig ist Dauer und Ergebnis der Prüfung wirken sich unmittelbar auf die Bearbeitungszeit von Erstattungen und die Bestandsverwaltung aus. Diese Aktivität ist entscheidend für die Analyse der Prüfungseffizienz und von Nachbearbeitungen. Bezugsquelle Im SAP Advanced Returns Management (ARM) kann dies ein ausdrückliches Ereignis aus der Prüftransaktion sein. Alternativ lässt es sich aus einer Statusänderung der Rückgabeauftragsposition ableiten, die das Prüfergebnis anzeigt. Erfassen Erfasst aus Transaktionsprotokollen oder Statusänderungen im Zusammenhang mit den logistischen Folgeaktivitäten in ARM. Ereignistyp explicit | |||
| Gutschrift angelegt | Dabei wird das offizielle Fakturadokument erstellt, mit dem das Kundenkonto für den retournierten Artikel gutgeschrieben wird. Das explizite Event wird erfasst, sobald die Gutschrift aus der Gutschriftanforderung erzeugt wird. | ||
| Warum das wichtig ist Die Erstellung der Gutschrift ist ein wichtiger finanzieller Meilenstein. Sie bestätigt den zu erstattenden Betrag und gibt den Zahlungsprozess frei. Bezugsquelle Erfasst bei der Erstellung eines Fakturadokuments in der Tabelle VBRK mit einer Dokumentkategorie, die eine Gutschrift kennzeichnet. Die Verknüpfung zur Gutschriftanforderung erfolgt über die Tabelle VBFA. Erfassen Das Event wird beim Speichern eines neuen Fakturadokuments für eine Gutschrift erfasst, beispielsweise über die Transaktion VF01. Ereignistyp explicit | |||
| Gutschriftanforderung angelegt | Nach einer erfolgreichen Prüfung kennzeichnet diese Aktivität die Erstellung einer Anforderung zur Ausstellung einer Gutschrift für den Kunden. Sie wird als neues Verkaufsdokument, eine Gutschriftanforderung, erfasst, die auf den ursprünglichen Retourenauftrag verweist. | ||
| Warum das wichtig ist Dies ist der Auslöser für die finanzielle Abwicklung im Retourenprozess. Die Analyse der Zeitspanne von der Prüfung bis zu diesem Schritt zeigt, wie effizient die Übergabe von der Logistik an die Finanzabteilung erfolgt. Bezugsquelle Erfasst bei der Erstellung eines Verkaufsdokuments in der Tabelle VBAK mit einer Dokumentkategorie für Gutschriftanforderungen. Die Verbindung zur Retoure wird in der Belegfluss-Tabelle VBFA gepflegt. Erfassen Das Event wird beim Speichern eines neuen Dokuments für eine Gutschriftanforderung erfasst. Ereignistyp explicit | |||
| Retourenfall geschlossen | Dies ist die letzte Aktivität. Sie zeigt an, dass der Retourenprozess abgeschlossen ist und für den Case keine weiteren Aktionen erwartet werden. In der Regel wird sie daraus abgeleitet, dass der Retourenauftrag im System einen finalen, geschlossenen Status erreicht. | ||
| Warum das wichtig ist Dieses Event definiert das Ende des Prozesslebenszyklus und ermöglicht die Berechnung der gesamten End-to-End-Durchlaufzeit. Es bestätigt, dass der Case vollständig bearbeitet wurde. Bezugsquelle Abgeleitet daraus, dass der Gesamtstatus des Retourenauftrags in der Tabelle VBAK oder der Status seiner Positionen in VBAP den Zustand „Abgeschlossen“ oder „Geschlossen“ erreicht. Maßgeblich ist die Statusverwaltung des Systems. Erfassen Abgeleitet daraus, dass sich der Status des Retourenauftragsdokuments in „Abgeschlossen“ ändert. Ereignistyp inferred | |||
| Rückerstattung verarbeitet | Diese Aktivität kennzeichnet den letzten Schritt des Rückerstattungsprozesses. Dabei wird die finanzielle Gutschrift ausgeglichen, was bedeutet, dass die Zahlung an den Kunden gesendet wurde. Abgeleitet wird dies aus der Erstellung eines Ausgleichsbelegs im Finanzwesen, der die offene Gutschrift auf dem Kundenkonto ausgleicht. | ||
| Warum das wichtig ist In diesem Moment erhält der Kunde tatsächlich seine Zahlung. Die Zeit von der Einleitung der Retoure bis zu diesem Schritt beeinflusst die Customer Experience maßgeblich und ist entscheidend für die Messung der SLA-Einhaltung. Bezugsquelle Abgeleitet aus den Informationen zum Ausgleichsbeleg in der Einzelpostentabelle BSEG des Finanzwesens. Das Ausgleichsdatum (BSEG-AUGDT) auf dem zur Gutschrift gehörenden Kundenposten zeigt an, wann die Rückerstattung verarbeitet wurde. Erfassen Abgeleitet daraus, dass das Feld für das Ausgleichsdatum im zur Gutschrift gehörenden Buchhaltungsbeleg gefüllt ist. Ereignistyp inferred | |||
| Rückgabeanfrage eröffnet | Dies ist der Ausgangspunkt des Rückgabeprozesses. Dabei wird im System formal ein Rückgabeauftrag angelegt. Das Ereignis wird ausdrücklich erfasst, sobald ein neuer Verkaufsbeleg des Rückgabeauftragstyps in SAP S/4HANA gespeichert wird. | ||
| Warum das wichtig ist Diese Aktivität markiert den offiziellen Beginn des Lebenszyklus eines Rückgabefalls. Die Analyse der Zeit von diesem Ereignis bis zum Abschluss ist entscheidend, um die gesamte Rückgabedauer und die Customer Experience zu messen. Bezugsquelle Dies ist ein ausdrücklich erfasstes Ereignis bei der Anlage eines Verkaufsbelegs in der Tabelle VBAK, dessen Belegkategorie (VBAK-VBTYP) einen Rückgabeauftrag kennzeichnet. Der Anlage-Timestamp ist VBAK-ERDAT. Erfassen Das Ereignis wird beim Speichern eines neuen Rückgabeauftrags erfasst, beispielsweise über die Transaktion VA01. Ereignistyp explicit | |||
| Waren im Lager eingegangen | Dieses Ereignis markiert den physischen Eingang des zurückgesendeten Artikels im Lager oder Bearbeitungszentrum. Es wird ausdrücklich erfasst, wenn ein Post Goods Receipt (PGR) für die Retourenlieferung gebucht und dadurch ein Materialbeleg angelegt wird. | ||
| Warum das wichtig ist Dies ist ein kritischer Meilenstein, ab dem die Zeit für Prüfung und Disposition läuft. Verzögerungen vor diesem Punkt werden durch Kunden verursacht, während Verzögerungen danach intern entstehen. Bezugsquelle Erfasst aus den Materialbelegt Tabellen MSEG und MKPF für die bei Rückgaben verwendete Warenbewegungsart. Das Buchungsdatum (MKPF-BUDAT) gibt den Zeitpunkt des Ereignisses an. Erfassen Das Ereignis entspricht der Buchung eines Wareneingangs für die Retourenlieferung. Ereignistyp explicit | |||
| Austauschauftrag angelegt | Diese Aktivität steht für eine alternative Lösung: Statt einer Rückerstattung wird ein neuer Verkaufsauftrag angelegt, um dem Kunden einen Ersatzartikel zu senden. Erfasst wird dies, wenn ein neuer Verkaufsauftrag mit Bezug auf die ursprüngliche Retoure angelegt wird. | ||
| Warum das wichtig ist Diese Aktivität unterscheidet zwischen Retouren mit Rückerstattung und Retouren mit Austausch. Beide Varianten folgen unterschiedlichen Prozesspfaden und führen zu unterschiedlichen Ergebnissen für den Kunden. Sie ist daher für die Variantenanalyse besonders relevant. Bezugsquelle Erfasst bei der Erstellung eines neuen Verkaufsdokuments in VBAK, das im Belegfluss (VBFA) mit dem Retourenauftrag verknüpft ist. Erfassen Das Event wird beim Speichern eines neuen Verkaufsauftrags erfasst, der als Ersatzauftrag gekennzeichnet ist. Ereignistyp explicit | |||
| Buchhaltungsbeleg angelegt | Dieses Event tritt auf, wenn die Gutschrift erfolgreich im Finanzwesen gebucht wurde. Dabei entstehen entsprechende Buchungen im Hauptbuch, wodurch die Gutschrift auch aus buchhalterischer Sicht offiziell wird. | ||
| Warum das wichtig ist Diese Aktivität bestätigt, dass die Gutschrift in das Finanzsystem übernommen wurde. Die Zeit zwischen der Erstellung der Gutschrift und der Buchung im Finanzwesen kann auf Probleme an der Schnittstelle zwischen Fakturierung und Finanzwesen hinweisen. Bezugsquelle Erfasst bei der Erstellung eines Belegkopfs in der Buchhaltungstabelle BKPF, der mit der Gutschrift in VBRK (VBRK-BELNR) verknüpft ist. Erfassen Das Event wird nach der erfolgreichen Buchung des Fakturadokuments im Finanzwesen erfasst. Ereignistyp explicit | |||
| Retourenlieferung angelegt | Diese Aktivität bezeichnet die Anlage eines Wareneingangs-Lieferbelegs, der zur Verwaltung des physischen Eingangs der zurückgesendeten Waren dient. Das System erfasst dies als ausdrückliches Anlageereignis für einen Lieferbeleg mit Bezug zum Rückgabeauftrag. | ||
| Warum das wichtig ist Dieser Schritt ist ein wichtiger logistischer Meilenstein. Die Zeit zwischen der Genehmigung der Rückgabe und der Anlage der Lieferung zeigt, wie effizient Rückgabeinformationen an das Lager oder die Wareneingangsabteilung übermittelt werden. Bezugsquelle Erfasst bei der Anlage eines Lieferkopfs in der Tabelle LIKP, der über die Belegfluss-Tabelle VBFA mit dem vorausgehenden Rückgabeauftrag verknüpft ist. Erfassen Das Ereignis wird beim Speichern eines neuen Retourenlieferbelegs erfasst, beispielsweise über die Transaktion VL01N. Ereignistyp explicit | |||
| Rückgabe abgelehnt | Zeigt an, dass der zurückgesendete Artikel die Kriterien der Rückgaberichtlinie nicht erfüllt und die Erstattungs- oder Gutschriftanfrage abgelehnt wurde. In der Regel wird dies erfasst, indem nach der Prüfung ein bestimmter Status oder Ursachencode auf die Rückgabeauftragsposition angewendet wird. | ||
| Warum das wichtig ist Die Nachverfolgung von Ablehnungen unterstützt die Analyse der Compliance mit Rückgaberichtlinien und die Ermittlung häufiger Ablehnungsgründe. Sie bildet einen wichtigen Ausnahmeweg im Prozess ab. Bezugsquelle Abgeleitet daraus, dass ein Ablehnungsgrund (VBAP-ABGRU) auf der Position des Retourenauftrags gesetzt oder während des Prüfprozesses im Advanced Returns Management ein bestimmter Status zugewiesen wurde. Erfassen Abgeleitet daraus, dass ein Ablehnungsgrund oder ein bestimmter Status „abgelehnt“ auf der Position des Retourendokuments gesetzt wurde. Ereignistyp inferred | |||
| Rückgabeauftrag genehmigt | Diese Aktivität bezeichnet die formale Genehmigung oder Freigabe des Rückgabeauftrags, sodass er in die nächste Phase übergehen kann. In der Regel wird sie aus einer Statusänderung auf Kopf- oder Positionsebene des Verkaufsbelegs abgeleitet, die zeigt, dass vorhandene Sperren aufgehoben wurden. | ||
| Warum das wichtig ist Genehmigungsschritte können eine wesentliche Verzögerungsquelle sein. Die Überwachung dieser Aktivität hilft, Engpässe in der anfänglichen Autorisierungsphase des Rückgabeprozesses zu erkennen. Bezugsquelle Abgeleitet aus Tabellen der Statusverwaltung oder Statusfeldern direkt in den Tabellen VBAK oder VBAP. Eine Änderung des Freigabestatus oder die Entfernung einer Liefersperre (VBAP-LIFSP) kann eine Genehmigung anzeigen. Erfassen Abgeleitet aus einer Änderung der Statusfelder auf Kopf- oder Positionsebene des Rückgabeauftrags, die eine Freigabe oder Genehmigung anzeigt. Ereignistyp inferred | |||
Extraktionsleitfäden
Schritte
- Voraussetzungen prüfen: Stellen Sie sicher, dass das Benutzerkonto, das die Extraktion ausführt, in SAP S/4HANA über die erforderlichen Berechtigungen für den Zugriff auf die benötigten Core Data Services (CDS) Views 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.
- Abfrage-Tool öffnen: Melden Sie sich bei Ihrem bevorzugten SQL-Client oder Datenintegrationstool an, das mit der SAP-S/4HANA-Datenbank verbunden ist. Dabei kann es sich um SAP-eigene Tools wie SAP Analytics Cloud oder eine ETL-Plattform eines Drittanbieters handeln.
- Abfrageparameter festlegen: Vor der Ausführung müssen Sie die bereitgestellte SQL-Abfrage anpassen. Suchen Sie die Platzhalter und ersetzen Sie sie durch die korrekten Parameter für Ihre Umgebung. Dazu gehören
[Startdatum],[Enddatum],[Ihre Quellsystem-ID],[Ihre Retourenauftragsart]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 Tool aus. Die Abfrage sammelt alle angegebenen Aktivitäten in einem Datensatz, indem sie die Ergebnisse mehrerer SELECT-Anweisungen per UNION zusammenführt.
- Abfragelogik verstehen: Jeder
SELECT-Block in der StrukturUNION ALLextrahiert eine bestimmte Aktivität. Er verknüpft mehrere CDS Views, um die erforderlichen Attribute zu erfassen, weistActivityNameeinen festen Textwert zu und wählt den relevanten Timestamp fürEventTimeaus. - Rohdaten prüfen: Prüfen Sie nach Abschluss der Abfrage kurz die Ausgabe. Achten Sie auf eine plausible Zeilenanzahl und stellen Sie sicher, dass wichtige Spalten wie
ReturnCaseId,ActivityNameundEventTimeerwartungsgemäß befüllt sind. - Datentransformation: Die Abfrage erzeugt ein flaches Event-Log-Format. In der Regel sind keine wesentlichen strukturellen Transformationen erforderlich. Je nach Anforderungen Ihres Zielsystems müssen Sie jedoch möglicherweise Timestamp-Formate oder Datentypen anpassen.
- Event Log exportieren: Exportieren Sie das Abfrageergebnis als CSV-Datei. Stellen Sie sicher, dass die Datei UTF-8-kodiert ist, um Zeichenprobleme zu vermeiden, insbesondere bei Benutzernamen oder Produktbeschreibungen.
- In das Process-Mining-Tool hochladen: Die resultierende CSV-Datei kann nun in Ihre Process-Mining-Plattform, beispielsweise ProcessMind, hochgeladen werden. Ordnen Sie die Spalten der Datei den entsprechenden Feldern im Tool zu, etwa
ReturnCaseIdder Case-ID,ActivityNameder Aktivität undEventTimedem Timestamp.
Konfiguration
- Voraussetzungen: Der ausführende Benutzer benötigt Anzeigeberechtigungen 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 erforderlich.
- Filter für den Datenumfang: Die Abfrage muss nach bestimmten Belegarten gefiltert werden, um den Retourenprozess abzugrenzen. Konfigurieren Sie die Platzhalter für Retourenauftragsarten, beispielsweise „RE“, für Gutschriftsanforderungsarten, beispielsweise „G2“, und für Austauschauftragsarten, beispielsweise „SO“. Eine Filterung nach
CompanyCodeoderSalesOrganizationwird ebenfalls dringend empfohlen, um den Datenumfang zu begrenzen. - Filterung des Datumsbereichs: Wenden Sie zur Steuerung von Leistung und Datenvolumen immer einen Datumsfilter an. Beginnen Sie mit einem aktuellen Zeitraum von drei bis sechs Monaten. Die Abfrage verwendet das Erstellungsdatum des ursprünglichen Retourenauftrags (
I_SalesDocument.CreationDate) als primäre Filterbedingung. - Überlegungen zur Leistung: Diese umfassende Abfrage verknüpft mehrere große CDS Views. Die Ausführung kann das Quellsystem S/4HANA stark beanspruchen. Planen Sie die Extraktion außerhalb der Spitzenzeiten, um die Auswirkungen zu begrenzen. Bei sehr großen Datenmengen sollten Sie Strategien für inkrementelles Laden prüfen.
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
- Bestätigen Sie, dass direkter Lesezugriff auf das SAP-HANA-Schema mit den relevanten Daten zu Verkäufen, Lieferungen, Fakturierung, Materialbelegen, Prüfungen, Status und Buchhaltung verfügbar ist. Schema, Views und Feldnamen unterscheiden sich je nach SAP-S/4HANA-Bereitstellung. Ersetzen Sie daher jeden Platzhalter in eckigen Klammern durch die in Ihrem System konfigurierten Objekte und Felder.
- Definieren Sie den Extraktionsumfang mit [Startdatum], [Enddatum], [Filter für Buchungskreis] und [Filter für Retourenbelegart]. Verwenden Sie für die erste Extraktion einen rollierenden Zeitraum von drei bis sechs Monaten und erweitern Sie ihn erst, nachdem Leistung und Vollständigkeit geprüft wurden.
- Ermitteln Sie die Retourenauftragsmenge aus [Ihrer Tabelle für Verkaufsbelegköpfe] und [Ihrer Tabelle für Verkaufsbelegpositionen]. Beschränken Sie die Menge auf die Retourenauftragsarten, die in [Ihrer Konfiguration der Retourenauftragsarten] hinterlegt sind. Bewahren Sie Retourenauftragsnummer und Positionsnummer als primäre Verknüpfung zu nachgelagerten Belegen.
- Lösen Sie den Belegfluss von Retourenaufträgen zu Eingangslieferungen für Retouren, Gutschriftsanforderungen, Austauschaufträgen und Gutschriften über [Ihre Tabelle oder View für den Belegfluss] auf. Gehen Sie nicht davon aus, dass der Belegfluss in VBAK oder VBAP gespeichert ist. Konfigurieren Sie die Beziehungsfelder entsprechend dem im System verwendeten Belegflussmodell.
- Extrahieren Sie explizite Erstellungsereignisse aus den relevanten Belegkopf- und Positionsdatensätzen. Extrahieren Sie Genehmigungs-, Ablehnungs-, Prüfungs-, Abschluss-, Wareneingangs-, Buchungs- und Ausgleichsereignisse aus den konfigurierten Quellen für Status, Prüfungen, Materialbelege, Buchhaltung und Ausgleich. Jede Aktivität muss als separate Ereigniszeile ausgegeben werden, da ProcessMind keine Ereignisse ableitet.
- Normalisieren Sie Timestamps in einen einheitlichen Datenbank-Timestamp-Typ und eine einheitliche Zeitzone. Verwenden Sie für jede Aktivität die konfigurierte Priorität der Ereignis-Timestamps. Wenn nur Datum und Uhrzeit verfügbar sind, kombinieren Sie diese mithilfe der in [Ihrer Systemzeitzone] konfigurierten Zeitzone.
- Befüllen Sie
ReturnCaseIdfür jedes Ereignis. Verwenden Sie die Nummer des ursprünglichen Retourenauftrags oder den konfigurierten Retouren-Case-Identifier, wenn Advanced Returns Management einen separaten Case-Schlüssel speichert. Ereignisse ohne Verknüpfung zu einem Retouren-Case müssen ausgeschlossen oder zur Nachbearbeitung in eine Ausgabeliste für Ausnahmen aufgenommen werden. - Befüllen Sie die erforderlichen Spalten
ReturnCaseId,ActivityName,EventTime,SourceSystemIdundLastDataUpdateTimestamp. Ergänzen Sie, sofern verfügbar, die empfohlenen SpaltenEventEndTime,UserName,ReturnReason,RefundAmount,ProductIdundCustomerId. Verwenden Sie eine Zeile pro Aktivitätsvorkommen und fassen Sie Aktivitäten nicht in einer einzigen Case-Zeile zusammen. - Validieren Sie das Ergebnis anhand der Prüfungen in
validationSteps. Bestätigen Sie, dass alle zwölf Aktivitätsnamen vorhanden sind, dass die Timestamps innerhalb jedes Cases plausibel geordnet sind und dass die Belegreferenzen mit den Quelltabellen übereinstimmen. - Exportieren Sie das Ergebnis als UTF-8-kodierte CSV-Datei oder in einem anderen von ProcessMind unterstützten Tabellenformat. Bewahren Sie die exakten Spaltennamen, verwenden Sie eine Kopfzeile, behalten Sie Timestamps in einem eindeutigen ISO-Format bei und laden Sie das Event Log mit
ReturnCaseIdals Case-Identifier sowieActivityNameals Aktivitätsspalte hoch.
Konfiguration
- Datumsbereich: Beginnen Sie mit drei bis sechs Monaten. Verwenden Sie die Parameter [Startdatum] und [Enddatum] und berücksichtigen Sie ausreichend Historie, um Cases zu erfassen, die vor dem ausgewählten Zeitraum begonnen, aber innerhalb dieses Zeitraums abgeschlossen wurden.
- Retourenmenge: Filtern Sie nach den in [Ihrer Konfiguration der Retourenauftragsarten] hinterlegten Retourenauftragsarten. Hinterlegen Sie keine Belegart fest, bevor sie im Zielsystem geprüft wurde.
- Organisationsfilter: Wenden Sie [Filter für Buchungskreis], Verkaufsorganisation, Vertriebsweg, Sparte, Werk oder Kundenfilter nur bei Bedarf an. Stellen Sie sicher, dass Filter keine Folgebelege aus anderen Buchungskreisen oder konzerninternen Vorgängen ausschließen.
- Quellobjekte: Ersetzen Sie die Platzhalter [Ihr Tabellenname] und [Ihr View-Name] durch freigegebene SAP-S/4HANA-Tabellen oder CDS Views. VBAK, VBAP, VBRK und VBRP können in der Bereitstellung verfügbar sein. Ihre Verwendung und Erweiterungen müssen jedoch vor der Ausführung geprüft werden.
- Verarbeitung von Timestamps: Konfigurieren Sie für jede Aktivität die Quellfelder für Timestamps und die Zeitzone. Speichern Sie
EventTimeundEventEndTimeeinheitlich, vorzugsweise als UTC oder in der vereinbarten ProcessMind-Zeitzone. - Interpretation von Statuswerten: Konfigurieren Sie die exakten Statuswerte, Ursachencodes, Prüfergebnisse und Abschlusskennzeichen, die im System Genehmigung, Ablehnung, abgeschlossene Prüfung und Case-Abschluss darstellen.
- Quellsystem-Identifier: Ersetzen Sie [Quellsystem-Identifier] durch einen stabilen Wert, beispielsweise die von der Extraktionsplattform verwendete SAP-Systemkennung.
- Aktualisierungs-Timestamp: Ersetzen Sie [Extraktions-Timestamp] durch den Timestamp, zu dem die Abfrageausführung begonnen hat oder der Quellsnapshot erstellt wurde. Verwenden Sie für alle Zeilen eines Extraktionslaufs denselben Wert, sofern keine zeilenbezogenen Aktualisierungs-Timestamps erforderlich sind.
- Leistung: Begrenzen Sie die anfängliche Retourenmenge, bevor Sie große Quellen für Belegfluss, Buchhaltung, Materialbelege und Status verknüpfen. Verwenden Sie indizierte Felder oder Felder zur Partitionsbereinigung, vermeiden Sie uneingeschränkte Scans und materialisieren Sie Zwischenergebnisse nur nach Freigabe durch die Datenbankadministration.
- Inkrementelle Extraktion: Verwenden Sie bei wiederkehrenden Läufen [Timestamp der letzten erfolgreichen Extraktion] und ein kontrolliertes Überlappungsfenster, um nachträgliche Aktualisierungen zu erfassen. Entfernen Sie Duplikate anhand von
ReturnCaseId,ActivityName, Quellbelegschlüssel undEventTime. - Berechtigungen und Voraussetzungen: Holen Sie Leseberechtigungen für alle konfigurierten Quellobjekte und Felder, die Genehmigung für den direkten Datenbankzugriff sowie die Bestätigung ein, dass die erforderlichen SAP-Komponenten und Funktionen von Advanced Returns Management, sofern zutreffend, aktiv sind.
- Datenschutz: Beschränken Sie Kunden- und Finanzfelder auf das erforderliche Minimum, befolgen Sie die Datenschutzvorgaben Ihrer Organisation und sichern Sie exportierte Dateien.
a 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; Bereit für den Start?
Mit diesem Template verfügen Sie über das grundlegende Wissen, um Ihre Daten zur Retouren- und Erstattungsverarbeitung zu extrahieren und zu analysieren. Beginnen Sie noch heute mit der Weiterentwicklung Ihrer Prozesse.
Optimieren Sie die Retouren- und Erstattungsverarbeitung in SAP S/4HANA jetzt
Identifizieren Sie Ineffizienzen, verkürzen Sie die Durchlaufzeit um 30 % und steigern Sie die Zufriedenheit.
Keine Kreditkarte erforderlich. Beginnen Sie noch heute mit der Optimierung.