> Kontinuierliche Prozessverbesserung > Bearbeitung von Retouren und Rückerstattungen > Oracle Fusion SCM > Daten Template

Ihr Daten-Template für Retouren- und Erstattungsprozesse

Oracle Fusion SCM

← Zurück zum Leitfaden zur Verbesserung

Attribute für die Bearbeitung von Retouren und Rückerstattungen (21) Aktivitäten für die Bearbeitung von Retouren und Rückerstattungen (15) Anleitungen zur Extraktion (3)

Ihr Daten-Template für Retouren- und Erstattungsprozesse

Dieses Template unterstützt Sie bei der Analyse Ihrer Retouren- und Erstattungsprozesse in Oracle Fusion SCM. Es beschreibt die wichtigsten zu erfassenden Attribute und zu verfolgenden Aktivitäten und enthält klare Hinweise zur Extraktion dieser Daten. Verwenden Sie es, um wertvolle Erkenntnisse zu Ihrem Prozess zu gewinnen und Verbesserungsmöglichkeiten zu erkennen.

Empfohlene Attribute für die Erfassung
Wichtige Aktivitäten für die Prozessanalyse
Schrittweise Anleitung zur Extraktion aus Oracle Fusion SCM

Neu bei Event Logs? Lernen Sie, wie Sie ein Process-Mining-Event-Log erstellen.

Template herunterladen

Attribute für die Bearbeitung von Retouren und Rückerstattungen

Dies sind die empfohlenen Datenfelder für Ihr Event Log, um die Bearbeitung von Retouren und Rückerstattungen in Oracle Fusion SCM umfassend zu analysieren.

5 Erforderlich 7 Empfohlen 9 Optional

	Name	Beschreibung
	Aktivität ActivityName	Der Name eines bestimmten Geschäftsschritts oder Ereignisses, das innerhalb des Retouren- und Erstattungsprozesses stattgefunden hat.
Beschreibung Dieses Attribut beschreibt einen einzelnen Schritt oder Meilenstein im Lebenszyklus einer Retoure, etwa „RMA erstellt“, „Artikel geprüft“ oder „Erstattung verarbeitet“. Jede Aktivität stellt einen eigenständigen Prozesspunkt dar, der in den Event Logs des Systems erfasst wird. Die Analyse der Reihenfolge und Dauer dieser Aktivitäten bildet den Kern von Process Mining. Sie ermöglicht die Visualisierung von Prozessmodellen, die Identifizierung von Engpässen zwischen Schritten und die Berechnung aktivitätsspezifischer Durchlaufzeiten. Diese Daten sind entscheidend, um Prozessabläufe, Nacharbeitsschleifen und die Einhaltung von Standardarbeitsanweisungen zu verstehen. Warum das wichtig ist Aktivitäten bilden das Rückgrat des Prozessmodells und ermöglichen die Visualisierung und Analyse von Prozessabläufen, Varianten und Engpässen. Bezugsquelle Abgeleitet aus Event Logs, Statusänderungen oder bestimmten Transaktionsdatensätzen in Oracle-Fusion-SCM-Modulen wie Order Management und Inventory Management. Beispiele RMA erstelltArtikel eingegangenGutschrift erstelltErstattung verarbeitet
	Ereigniszeit EventTime	Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein bestimmtes Ereignis stattgefunden hat.
Beschreibung Die Ereigniszeit oder Startzeit bezeichnet das genaue Datum und die genaue Uhrzeit, zu der eine Aktivität im Quellsystem erfasst wurde. Sie liefert den zeitlichen Kontext für jeden Prozessschritt. Dieser Timestamp ist für alle zeitbasierten Analysen unverzichtbar. Er wird verwendet, um Ereignisse korrekt zu ordnen, Durchlaufzeiten zwischen Aktivitäten zu berechnen, die Gesamtdauer eines Falls zu messen und die Leistung anhand von Service Level Agreements (SLAs) zu bewerten. Ohne genaue Timestamps lassen sich Prozesseffizienz und Verzögerungen nicht analysieren und Prozessdynamiken nicht verstehen. Warum das wichtig ist Dieses Attribut liefert die zeitliche Reihenfolge der Ereignisse. Sie ist grundlegend für die Berechnung aller dauerbasierten Kennzahlen und die Erkennung von Prozessengpässen. Bezugsquelle Diese Information ist in Oracle Fusion SCM typischerweise in einem Feld wie „Erstellungsdatum“, „Timestamp“ oder „Datum der letzten Aktualisierung“ zu finden, das mit Transaktions- oder Statusdatensätzen verknüpft ist. Beispiele 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
	ID des Retourenfalls ReturnCaseId	Die zentrale Kennung, die alle Aktivitäten eines bestimmten Kunden-Retouren- oder Erstattungsfalls miteinander verknüpft.
Beschreibung Die ID des Retourenfalls dient als eindeutige Fallkennung für den gesamten Retouren- und Erstattungsprozess. Sie verknüpft jedes Ereignis, von der Erstellung der Return Material Authorization (RMA) bis zur abschließenden Erstattungsabwicklung und zum Schließen des Falls. In der Process-Mining-Analyse ist dieses Attribut grundlegend für die Rekonstruktion des End-to-End-Ablaufs jeder Retoure. Es ermöglicht Analysten, den vollständigen Lebenszyklus zu verfolgen, die gesamte Durchlaufzeit zu messen und Unterschiede in der Bearbeitung verschiedener Retouren zu verstehen. Alle weiteren Ereignisdaten werden anhand dieser ID gruppiert, um eine zusammenhängende Prozesssicht zu bilden. Warum das wichtig ist Dies ist der entscheidende Schlüssel, um alle zusammengehörigen Ereignisse zu einer einzelnen Prozessinstanz zu verbinden und eine End-to-End-Analyse zu ermöglichen. Bezugsquelle Diese Kennung wird in der Regel in den Modulen Oracle Order Management oder Service erzeugt, sobald eine Retourenanfrage eingeleitet wird. Beispiele RMA-2023-00123RMA-2023-00456RMA-2023-00789
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, zu dem die Daten zuletzt aktualisiert oder aus dem Quellsystem extrahiert wurden.
Beschreibung Dieses Attribut gibt an, wann der Datensatz zuletzt aktualisiert wurde. Es bezeichnet das Aktualitätsdatum des gesamten Datensatzes, nicht einzelner Ereignisse. Die Kenntnis des Zeitpunkts der letzten Datenaktualisierung ist entscheidend, damit Benutzer die Aktualität der Analyse einschätzen können. So lassen sich Dashboards und KPIs richtig interpretieren, etwa ob sie Echtzeitinformationen oder Daten zeigen, die mehrere Stunden oder Tage alt sind. Für jedes Process-Mining-Projekt ist dies ein wichtiges Metadatum. Warum das wichtig ist Informiert Benutzer über die Aktualität der Daten und stellt sicher, dass sie Kontext und zeitliche Aussagekraft ihrer Analyse richtig einschätzen können. Bezugsquelle Dieser Timestamp wird während des ETL-Prozesses erzeugt und hinzugefügt. Beispiele 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Quellsystem SourceSystem	Das System, aus dem die Daten extrahiert wurden.
Beschreibung Dieses Attribut identifiziert das ursprüngliche Informationssystem, in dem die Ereignisdaten erfasst wurden. Für diesen Prozess wäre dies typischerweise „Oracle Fusion SCM“. In Umgebungen mit mehreren integrierten Systemen ist dieses Feld für Datenherkunft und Fehleranalyse entscheidend. Es bestätigt die Herkunft der Daten und ermöglicht, die Analyse auf Ereignisse bestimmter Systeme zu beschränken. So bleiben Datenqualität und Kontext erhalten. Warum das wichtig ist Es liefert wichtigen Kontext zur Datenherkunft und ist daher für Datenvalidierung und Analysen in Umgebungen mit mehreren Systemen unverzichtbar. Bezugsquelle Dieser Wert wird häufig während des ETL-Prozesses als statischer Wert hinzugefügt, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele Oracle Fusion SCMOracle SCM Cloud
	Angeforderter Erstattungsbetrag RequestedRefundAmount	Der Geldbetrag, den der Kunde zu Beginn für die Retoure angefordert hat.
Beschreibung Dieses Attribut erfasst den vom Kunden zu Beginn des Prozesses angeforderten Erstattungswert. Er dient als Ausgangsbetrag für den Vergleich mit der endgültigen Erstattung. Dieser Datenpunkt ist entscheidend für das Dashboard „Angeforderte und tatsächliche Erstattungsbeträge“ sowie für die KPI „Abweichungsquote des Erstattungsbetrags“. Die Analyse der Differenz zwischen angeforderten und tatsächlichen Beträgen kann Probleme wie falsch retournierte Artikel, Wiedereinlagerungsgebühren oder Anpassungen aufgrund von Richtlinien aufdecken. Dadurch entstehen wertvolle Erkenntnisse zur finanziellen Genauigkeit und Kundenzufriedenheit. Warum das wichtig ist Dient als Grundlage für die Finanzanalyse, ermöglicht die Berechnung von Erstattungsabweichungen und macht mögliche Probleme sichtbar. Bezugsquelle Dieser Wert sollte im RMA- oder Retourenanfragekopf in Oracle Fusion SCM gespeichert werden, wahrscheinlich im Modul Order Management. Beispiele 129.9945.501200.00
	Bearbeitungsverantwortlicher ProcessingAgent	Der Benutzer oder Bearbeiter, der für die Ausführung einer bestimmten Aktivität im Retourenprozess verantwortlich ist.
Beschreibung Dieses Attribut identifiziert den Mitarbeiter oder Systembenutzer, der eine bestimmte Aufgabe ausgeführt hat, etwa die Genehmigung einer RMA oder die Bearbeitung einer Erstattung. Wenn keine Zuordnung zu einzelnen Personen erfasst wird, kann es sich auch um ein Team oder eine Abteilung handeln. Die Analyse der Leistung einzelner Bearbeiter ist für das operative Management entscheidend. Dieses Attribut ermöglicht das Dashboard „Leistung der Bearbeiter in der Retourenabwicklung“ und damit Vergleiche von Arbeitslast, Aktivitätsdauer und Nacharbeitsquoten zwischen verschiedenen Bearbeitern. Die Erkenntnisse können Schulungsbedarf aufzeigen, besonders leistungsstarke Bearbeiter identifizieren und eine bessere Ressourcenplanung unterstützen. Warum das wichtig ist Ermöglicht die Leistungsanalyse nach Benutzer oder Team und hilft, besonders leistungsstarke Bearbeiter, Schulungsmöglichkeiten und unausgeglichene Arbeitslasten zu erkennen. Bezugsquelle Typischerweise in Feldern wie „USER_ID“, „PROCESSED_BY“ oder „AGENT_NAME“ in Transaktionsprotokollen innerhalb von Oracle Fusion SCM zu finden. Beispiele j.doea.smithm.jones
	Endzeit EndTime	Der Timestamp, der angibt, wann eine Aktivität abgeschlossen wurde.
Beschreibung Die Endzeit markiert den Abschluss einer Aktivität. Während StartTime den Beginn eines Ereignisses angibt, wird die Endzeit benötigt, um die tatsächliche Bearbeitungszeit dieses Ereignisses zu berechnen. Bei Ereignissen ohne Dauer können StartTime und Endzeit identisch sein. In der Analyse ergibt die Differenz zwischen Endzeit und StartTime die „Bearbeitungszeit“ einer Aktivität. Das ist entscheidend, um zeitaufwendige Prozessschritte von Wartezeiten zwischen Schritten zu unterscheiden. Die Information ist für eine detaillierte Engpassanalyse und die Berechnung der Ressourceneffizienz unverzichtbar. Warum das wichtig ist Dieses Attribut wird benötigt, um die tatsächliche Bearbeitungszeit einzelner Aktivitäten zu berechnen und aktive Arbeitszeit von Wartezeit zu unterscheiden. Bezugsquelle Dies kann ein separates Feld in den Protokollen des Quellsystems sein oder aus der StartTime der nachfolgenden Aktivität abgeleitet werden. Beispiele 2023-10-26T10:05:00Z2023-10-26T15:00:10Z2023-10-27T11:30:00Z
	Retourengrund ReturnReason	Der vom Kunden angegebene Grund für die Retoure.
Beschreibung Dieses Attribut enthält den Grund für die Retoure. In der Regel wählt der Kunde ihn aus einer vordefinierten Liste aus, etwa „Defekter Artikel“, „Falsche Größe“ oder „Nicht mehr benötigt“. Die Analyse von Retourengründen liefert wichtige Erkenntnisse zur Produktqualität, zur Genauigkeit des Verkaufsprozesses und zum Kundenverhalten. Anhand dieser Daten lassen sich Produkte mit hohen Fehlerquoten identifizieren, Produktbeschreibungen verbessern, um Fehlbestellungen zu reduzieren, und die Ursachen von Retouren nachvollziehen. Daraus können gezielte Verbesserungen entstehen, die das gesamte Retourenvolumen senken. Warum das wichtig ist Liefert wichtige Erkenntnisse darüber, warum Retouren entstehen, und unterstützt Verbesserungen an Produkten und Verkaufsprozessen. Bezugsquelle Wird in Oracle Order Management üblicherweise als Code oder Textfeld auf der RMA-Position gespeichert. Beispiele DefektFalscher Artikel versendetZu spät angekommenBesserer Preis verfügbar
	Retourenstatus ReturnStatus	Der aktuelle oder abschließende Status des Retourenfalls.
Beschreibung Dieses Attribut gibt den Gesamtstatus des Retourenfalls zu einem bestimmten Zeitpunkt oder sein abschließendes Ergebnis an, etwa „Geschlossen, erstattet“, „Geschlossen, abgelehnt“ oder „In Bearbeitung“. Der Retourenstatus ist für die Analyse und Überwachung von Ergebnissen entscheidend. Er ermöglicht, Fälle nach ihrem Ergebnis zu filtern, Prozessabläufe genehmigter und abgelehnter Retouren zu vergleichen und das Dashboard „Aktueller Status von Retourenfällen“ zu speisen. Das Verständnis der Ergebnisverteilung ist wesentlich, um die Prozesseffektivität zu messen. Warum das wichtig ist Liefert das Ergebnis eines Falls und ist damit entscheidend für Filterung, Vergleichsanalysen und das Verständnis von Erfolgsquoten im Prozess. Bezugsquelle In der Regel als Statusfeld im Hauptdatensatz des Retouren- oder RMA-Auftragskopfs in Oracle Order Management verfügbar. Beispiele Wareneingang ausstehendPrüfung abgeschlossenGeschlossen, erstattetGeschlossen, abgelehnt
	Tatsächlicher Erstattungsbetrag ActualRefundAmount	Der endgültige Geldbetrag, der tatsächlich verarbeitet und an den Kunden erstattet wurde.
Beschreibung Dieses Attribut bezeichnet den endgültig bestätigten Betrag, der nach Anwendung aller Prüfungen, Anpassungen und Gebühren an den Kunden zurückgezahlt wurde. Der Wert bildet das tatsächliche finanzielle Ergebnis des Retourenfalls ab. Dieser finanzielle Datenpunkt wird im Dashboard „Angeforderte und tatsächliche Erstattungsbeträge“ verwendet. Der Vergleich mit dem angeforderten Betrag ist entscheidend für die Berechnung der KPI „Abweichungsquote des Erstattungsbetrags“ und für das Verständnis der finanziellen Auswirkungen von Retourenrichtlinien, Artikelzuständen und Bearbeitungsanpassungen. Warum das wichtig ist Stellt das tatsächliche finanzielle Ergebnis der Retoure dar und ermöglicht die Analyse von Abweichungen sowie die Finanzberichterstattung. Bezugsquelle Diese Informationen stammen wahrscheinlich aus dem Credit Memo oder den mit dem Retourenfall in Oracle Fusion Financials verknüpften Transaktionsdaten der Kreditorenbuchhaltung. Beispiele 129.9940.000.00
	Zieldatum für das Refund-SLA RefundSlaTargetDate	Das Datum, bis zu dem die Erstattung gemäß der Service-Level-Vereinbarung abgeschlossen sein soll.
Beschreibung Dieses Attribut legt die Frist für den Abschluss des Erstattungsprozesses eines bestimmten Falls fest. Das SLA-Ziel richtet sich häufig nach Unternehmensrichtlinien, der Kundenstufe oder dem Retourengrund. Dieses Datum dient als Maßstab für Termintreue und Compliance. Es wird direkt im Dashboard „Refund Policy SLA Compliance“ verwendet und ist für die Berechnung der KPI „Refund SLA Conformance Rate“ erforderlich. Durch den Vergleich des tatsächlichen Abschlussdatums der Erstattung mit diesem Ziel lassen sich SLA-Verstöße erkennen und Fälle priorisieren, bei denen eine verspätete Bearbeitung droht. Warum das wichtig ist Dient als Maßstab für die Messung der Termintreue und ist entscheidend für die Berechnung von KPIs zur SLA-Compliance. Bezugsquelle Kann als eigenes Datumsfeld im Retourenfall vorliegen oder durch Addition eines vordefinierten Zeitraums, beispielsweise 14 Tage, zum Startdatum der Retoure abgeleitet werden. Beispiele 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z
	Abweichung beim Erstattungsbetrag RefundAmountDiscrepancy	Die berechnete Differenz zwischen dem angeforderten und dem tatsächlich erstatteten Betrag.
Beschreibung Diese Kennzahl quantifiziert die finanzielle Differenz zwischen dem vom Kunden angeforderten und dem tatsächlich erhaltenen Betrag. Sie wird berechnet, indem „ActualRefundAmount“ von „RequestedRefundAmount“ abgezogen wird. Dieser berechnete Wert bildet die Grundlage für die KPI „Refund Amount Discrepancy Rate“. Ein Wert ungleich null weist auf eine Anpassung während des Prozesses hin. Die Analyse der Gründe für solche Abweichungen, etwa Wiedereinlagerungsgebühren oder Abzüge wegen Beschädigungen, liefert Erkenntnisse zur Wirksamkeit von Richtlinien und zur Kundenkommunikation. Warum das wichtig ist Quantifiziert finanzielle Anpassungen im Erstattungsprozess und unterstützt die Analyse der Auswirkungen von Richtlinien und Prüfergebnissen. Bezugsquelle Berechnetes Feld: „RequestedRefundAmount“ - „ActualRefundAmount“. Beispiele 0.005.50-10.00
	Disposition Code DispositionCode	Ein Code, der die endgültige Behandlung des zurückgesendeten physischen Artikels angibt.
Beschreibung Der Disposition Code gibt an, was nach der Prüfung mit dem zurückgesendeten Produkt geschehen ist, beispielsweise ob es wieder in den Bestand aufgenommen, verschrottet, zur Aufarbeitung weitergeleitet oder an den Lieferanten zurückgesendet wurde. Diese Informationen sind wertvoll für die Analyse der finanziellen und operativen Auswirkungen von Retouren. Durch die Auswertung der Disposition Codes kann ein Unternehmen die Kosten nicht wiederverkaufsfähiger Waren nachvollziehen und Möglichkeiten zur Verbesserung der Aufarbeitungsprozesse erkennen. So wird der Retourenprozess mit Bestands- und Finanzergebnissen verknüpft. Warum das wichtig ist Verknüpft den Retourenprozess mit dem physischen Ergebnis im Bestand und liefert Erkenntnisse zu Verwertungsquoten und Kosten. Bezugsquelle Diese Informationen werden nach Abschluss der Prüfaktivität in den Modulen Oracle Inventory Management oder Warehouse Management erfasst. Beispiele RETURN_TO_STOCKSCRAPREFURBISHRETURN_TO_VENDOR
	Kunden-ID CustomerId	Die eindeutige Kennung des Kunden, der die Retoure veranlasst hat.
Beschreibung Dieses Attribut ist die eindeutige ID des Kunden, der mit dem Retourenfall verbunden ist. Es verknüpft den Retourenprozess mit der Kundendatenbank. Eine kundenorientierte Retourenanalyse kann wichtige Muster sichtbar machen. So lassen sich beispielsweise Kunden mit ungewöhnlich vielen Retouren identifizieren. Dies kann auf Zufriedenheitsprobleme oder möglichen Betrug hindeuten. Außerdem ermöglicht die Analyse nach Kundensegmenten, unterschiedliche Retourenverhalten bestimmter Gruppen zu erkennen. Warum das wichtig ist Ermöglicht eine kundenorientierte Analyse, mit der sich Kunden mit wiederholten Retouren, Verhaltensmuster von Segmenten und möglicher Betrug erkennen lassen. Bezugsquelle Ist in Oracle Order Management als Kunden- oder Party-ID im Kopf der ursprünglichen Verkaufsbestellung oder der Retourenanfrage zu finden. Beispiele CUST-100589743ACC-54321
	Lager-ID WarehouseId	Die Kennung des Lagers oder Standorts, an dem der zurückgesendete Artikel eingegangen ist.
Beschreibung Dieses Attribut bezeichnet den konkreten physischen Standort, etwa ein Distributionszentrum oder Lager, an dem der vom Kunden zurückgesendete Artikel eingegangen ist und bearbeitet wurde. Die Analyse nach Lagerstandort ist wichtig, um standortspezifische Leistungsprobleme zu erkennen. Sie ermöglicht den Vergleich von Prüfzeiten, Dispositionsergebnissen und gesamten Durchlaufzeiten zwischen verschiedenen Standorten. Dadurch lassen sich operative Ineffizienzen, Personalengpässe oder Schulungsbedarf an bestimmten Standorten sichtbar machen. Warum das wichtig ist Ermöglicht die Leistungsanalyse nach Standort und hilft, regionale oder standortspezifische Engpässe und Ineffizienzen zu erkennen. Bezugsquelle Dieses häufig als „ORGANIZATION_ID“ bezeichnete Feld ist in Oracle Inventory Management mit der Wareneingangstransaktion verknüpft. Beispiele WH-US-WESTWH-EU-CENTRALDC-01
	Nacharbeit IsRework	Ein boolesches Kennzeichen, das angibt, ob eine Aktivität Teil einer Nacharbeitsschleife ist.
Beschreibung Dieses Kennzeichen identifiziert Aktivitäten, die innerhalb desselben Falls Wiederholungen früherer Schritte darstellen und damit auf eine Prozessschleife oder Nacharbeit hindeuten. Wenn ein Artikel beispielsweise die Prüfung nicht besteht und erneut geprüft werden muss, wird das zweite Prüfereignis als Nacharbeit gekennzeichnet. Dieses Attribut ist grundlegend für die Quantifizierung von Prozessineffizienzen. Es wird im Dashboard „Return Processing Rework Rates“ und zur Berechnung der KPI „Return Rework Event Frequency“ verwendet. Die Menge und Ursachen von Nacharbeit zu erkennen, ist ein zentrales Ziel von Process Mining, da sie direkt auf unnötigen Aufwand, Verzögerungen und höhere Kosten hinweisen. Warum das wichtig ist Kennzeichnet Prozessineffizienzen und Schleifen direkt und erleichtert dadurch die Quantifizierung und Analyse der Ursachen von Nacharbeit. Bezugsquelle Dies ist ein berechnetes Attribut, das von den Algorithmen der Process-Mining-Software ermittelt wird. Diese erkennen wiederholte Aktivitäten innerhalb eines einzelnen Falls. Beispiele truefalse
	Produkt-ID ProductId	Die eindeutige Kennung des zurückgesendeten Produkts.
Beschreibung Dieses Attribut ist die eindeutige Kennung, etwa eine SKU oder Artikelnummer, des konkreten Produkts im Retourenfall. Es verknüpft den Retourenprozess mit dem Produktkatalog. Eine Analyse auf Produktebene ist entscheidend, um problematische Artikel zu erkennen. Wenn Sie die Prozessanalyse nach Product ID filtern oder dimensionieren, können Sie Produkte mit hohen Retourenquoten, langen Prüfzeiten oder bestimmten Fehlermustern identifizieren. Diese Informationen sind für Qualitätskontrolle, Lieferkettenmanagement und Produktentwicklung von großer Bedeutung. Warum das wichtig ist Verknüpft den Retourenprozess mit bestimmten Produkten und ermöglicht die Analyse von Produktqualität und Retourenmustern. Bezugsquelle Dabei handelt es sich in Oracle Order Management oder den Inventory-Modulen um „INVENTORY_ITEM_ID“ oder ein vergleichbares Feld auf der RMA-Position. Beispiele PROD-5540-ASKU-98765ITEM-001-B
	Retourenart ReturnType	Kategorisiert die Retoure nach dem erwarteten Ergebnis, etwa Erstattung, Austausch oder Reparatur.
Beschreibung Dieses Attribut klassifiziert die Art der bearbeiteten Retoure. Der Prozessablauf und die erforderlichen Schritte können sich deutlich unterscheiden, je nachdem, ob der Kunde eine finanzielle Erstattung, ein Ersatzprodukt oder einen reparierten Artikel erhält. Die Analyse nach Return Type ist entscheidend, um Prozessvarianten zu verstehen. Sie ermöglicht separate Prozessmodelle für Erstattungen und Austausche und hilft dabei, individuelle Engpässe sowie Leistungsmerkmale der jeweiligen Prozessvariante zu erkennen. Diese Segmentierung bildet die Grundlage für gezielte Prozessverbesserungen. Warum das wichtig ist Ermöglicht die Analyse nach unterschiedlichen Prozessvarianten, da Austausche und Erstattungen häufig verschiedene Schritte durchlaufen. Bezugsquelle Dabei handelt es sich in Oracle Order Management üblicherweise um ein Kategorie- oder Typfeld im RMA-Kopf oder auf der RMA-Position. Beispiele RückerstattungUmtauschReparatur
	RMA-Nummer RmaNumber	Die eindeutige Kennung der Return Merchandise Authorization-Transaktion.
Beschreibung Die RMA-Nummer ist eine formelle Genehmigung für die Rücksendung eines Produkts durch den Kunden. In vielen Systemen entspricht sie der Return Case ID, in manchen Systemen ist sie jedoch eine separate, zuvor vergebene Kennung. Dieses Attribut dient als zentrale geschäftliche Referenznummer, die internen Anwendern und Kunden vertraut ist. Es kann zum Suchen und Filtern von Fällen verwendet werden und ist häufig die wichtigste Nummer in der Kommunikation zur Retoure. Warum das wichtig ist Dient als zentrale geschäftliche Referenznummer und ist für die operative Nachverfolgung sowie die Kommunikation mit Kunden von großer Bedeutung. Bezugsquelle Dies ist die primäre Kennung des Return Merchandise Authorization-Objekts in Oracle Order Management. Beispiele 789001789002789003
	SLA-konform IsSlaCompliant	Ein boolesches Kennzeichen, das angibt, ob die Erstattung innerhalb des festgelegten SLA-Ziels bearbeitet wurde.
Beschreibung Dieses berechnete Attribut liefert für jeden Retourenfall einen einfachen Wahr-oder-Falsch-Wert zur SLA-Konformität. Es wird durch den Vergleich des tatsächlichen Timestamps der Erstattungsbearbeitung mit „RefundSlaTargetDate“ bestimmt. Das Kennzeichen ist entscheidend für die einfache Messung und Visualisierung von Compliance-Quoten. Es bildet die Grundlage für das Dashboard „Refund Policy SLA Compliance“ und vereinfacht die Berechnung der KPI „Refund SLA Conformance Rate“. Außerdem ermöglicht es eine schnelle Filterung und Ursachenanalyse, um zu verstehen, warum bestimmte Fälle ihr SLA nicht einhalten. Warum das wichtig ist Vereinfacht die Überwachung und Berichterstattung zur SLA-Einhaltung, indem ein Datumsvergleich in eine einfache boolesche Kennzahl umgewandelt wird. Bezugsquelle Berechnetes Feld. Der Wert ist wahr, wenn der Timestamp von „Refund Processed“ am oder vor „RefundSlaTargetDate“ liegt, andernfalls falsch. Beispiele truefalse

Erforderlich Empfohlen Optional

Aktivitäten für die Bearbeitung von Retouren und Rückerstattungen

Dies sind die wichtigsten Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um den Prozess präzise zu erkennen und Engpässe zu identifizieren.

7 Empfohlen 8 Optional

	Aktivität	Beschreibung
	Artikel eingegangen	Diese Aktivität markiert den physischen Eingang des retournierten Artikels im Lager oder Bearbeitungszentrum. In Oracle Fusion Inventory Management wird sie ausdrücklich erfasst, wenn die Ware gescannt und als Eingang zur RMA verbucht wird.
Warum das wichtig ist Der Wareneingang ist ein wichtiger Meilenstein, der nachfolgende Prüfungs- und Bearbeitungsschritte auslöst. Die Messung der Zeit zwischen „RMA genehmigt“ und „Artikel eingegangen“ hilft, Logistik- und Versandprozesse zu analysieren. Bezugsquelle Dies ist eine ausdrücklich in Oracle Inventory Management erfasste Transaktion. Das Ereignis entspricht dem Transaktionsdatum des RMA-Wareneingangs. Erfassen Verwenden Sie den Transaktions-Timestamp des RMA-Wareneingangs in Inventory. Ereignistyp explicit
	Artikel geprüft	Diese Aktivität zeigt den Abschluss der Artikelprüfung an, bei der eine Qualitätsbewertung erfasst wird. In Oracle Inventory Management oder Quality Management wird sie in der Regel als ausdrückliche Transaktion erfasst, die den RMA-Status aktualisiert.
Warum das wichtig ist Das Prüfergebnis beeinflusst direkt die nächsten Schritte, etwa die Genehmigung oder Ablehnung der Erstattung. Die Dauer der Prüfung selbst ist ein wichtiger Leistungsindikator für die Effizienz im Lager. Bezugsquelle Erfasst anhand des Transaktions-Timestamps, zu dem ein Prüfer die Prüfaufgabe für den RMA-Wareneingang in Oracle Inventory oder Quality Management abschließt. Erfassen Verwenden Sie den Abschluss-Timestamp der Prüftransaktion. Ereignistyp explicit
	Erstattung verarbeitet	Diese Aktivität markiert den Abschluss der Erstattungszahlung an den Kunden. Sie wird ausdrücklich erfasst, sobald die Zahlungsausgleichstransaktion in Oracle Financials verbucht wird.
Warum das wichtig ist Dies ist ein entscheidender Endpunkt für die Messung der gesamten Erstattungsdurchlaufzeit aus Kundensicht. Er bestätigt, dass die finanzielle Verpflichtung gegenüber dem Kunden erfüllt wurde. Bezugsquelle Dieses Ereignis wird anhand des Buchungs- oder Ausgleichsdatums der Zahlungstransaktion in Oracle Accounts Payable oder Treasury erfasst, mit der die Gutschrift ausgeglichen wird. Erfassen Verwenden Sie das Ausgleichsdatum der Zahlungstransaktion, mit der die Gutschrift beglichen wird. Ereignistyp explicit
	Gutschrift erstellt	Dies ist die finanzielle Aktivität, bei der in Accounts Receivable eine Gutschrift erstellt wird, um eine Erstattung an den Kunden zu autorisieren. Das Ereignis wird durch den Retourenprozess in Order Management ausdrücklich ausgelöst.
Warum das wichtig ist Die Erstellung einer Gutschrift ist ein eindeutiger Meilenstein und zeigt, dass sich das Unternehmen zur Erstattung an den Kunden verpflichtet. Sie löst den gesamten Teil des Prozesses zur finanziellen Abwicklung aus. Bezugsquelle Dies ist eine ausdrückliche Transaktion in Oracle Accounts Receivable. Das Ereignis kann über die Verkaufsauftragsreferenz auf der Gutschrift mit der ursprünglichen RMA verknüpft werden. Erfassen Verwenden Sie das Erstellungsdatum der Gutschrifttransaktion in AR. Ereignistyp explicit
	Retourenfall geschlossen	Dies ist die letzte Aktivität und zeigt an, dass alle mit der RMA verbundenen Aktionen abgeschlossen sind, einschließlich Wareneingang, Retourenentscheidung und finanzieller Abwicklung. Das Ereignis wird aus einem abschließenden Status „Geschlossen“ des RMA-Auftrags abgeleitet.
Warum das wichtig ist Dieses Ereignis bildet das eindeutige Ende des Prozesses. Es ist entscheidend für die Berechnung der End-to-End-Durchlaufzeit und stellt sicher, dass keine Fälle dauerhaft offen bleiben. Bezugsquelle Abgeleitet aus dem Timestamp, zu dem der RMA-Auftragskopf und alle zugehörigen Zeilen in Oracle Order Management den abschließenden Status „Geschlossen“ erreichen. Erfassen Erfassen Sie den letzten Timestamp, zu dem sich der Status des RMA-Kopfs oder einer RMA-Zeile auf „Geschlossen“ ändert. Ereignistyp inferred
	RMA erstellt	Diese Aktivität markiert den offiziellen Beginn des Retourenprozesses. Dabei wird in Oracle Fusion SCM eine Return Material Authorization (RMA) erstellt. Das Ereignis wird in der Regel ausdrücklich erfasst, wenn ein Benutzer oder ein automatisierter Prozess einen neuen RMA-Verkaufsauftrag anlegt.
Warum das wichtig ist Dies ist das zentrale Start-Ereignis für den gesamten Retourenprozess. Die Analyse der Zeit von dieser Aktivität bis zu nachfolgenden Aktivitäten zeigt die gesamte Prozessdauer und hilft, Verzögerungen zu Beginn zu erkennen. Bezugsquelle Dieses Ereignis wird anhand des Erstellungs-Timestamps des Retourenauftragskopfs in Oracle Fusion Order Management erfasst. Es entspricht dem ersten Speichern des RMA-Dokuments. Erfassen Erfassen Sie das Erstellungsdatum des Datensatzes für den Retourenauftragskopf. Ereignistyp explicit
	RMA genehmigt	Dieser wichtige Meilenstein zeigt, dass die Retourenanfrage gemäß den Geschäftsregeln geprüft und genehmigt wurde. In der Regel wird er aus einer Statusänderung der RMA abgeleitet und ermöglicht nachfolgende Prozessschritte wie den Versand durch den Kunden.
Warum das wichtig ist Die Genehmigung ist ein entscheidendes Gateway im Prozess. Verzögerungen an dieser Stelle wirken sich direkt auf die gesamte Retourendurchlaufzeit und die Kundenzufriedenheit aus. Diese Aktivität ist daher wesentlich für die Analyse von Genehmigungsengpässen. Bezugsquelle Abgeleitet aus dem Timestamp der Statusänderung des RMA-Auftragskopfs oder der Auftragszeile auf „Genehmigt“ oder „Wareneingang ausstehend“. Erfassen Erfassen Sie den Timestamp, zu dem der RMA-Status auf einen genehmigten Status aktualisiert wird. Ereignistyp inferred
	Artikel vom Kunden versendet	Diese Aktivität bezeichnet den Versand des retournierten Artikels durch den Kunden an das Unternehmen. Das Ereignis wird in Oracle SCM häufig nicht direkt erfasst, kann jedoch aus Daten der Versanddienstleister oder einer manuellen Aktualisierung abgeleitet werden.
Warum das wichtig ist Diese Aktivität liefert Erkenntnisse über das Kundenverhalten und die Dauer des Warentransports. So lassen sich Verzögerungen in der internen Bearbeitung von Verzögerungen durch den Versand unterscheiden. Bezugsquelle Dieses Ereignis kann aus Versanddaten eines mit der RMA verknüpften Versanddienstleisters oder aus einer manuellen Statusaktualisierung in Oracle SCM abgeleitet werden. Ohne entsprechende Integration ist es möglicherweise nicht verfügbar. Erfassen Timestamp aus einer integrierten API des Versanddienstleisters oder aus einem manuell erfassten Datenfeld. Ereignistyp inferred
	Artikelprüfung gestartet	Dies bezeichnet den Beginn der physischen Prüfung des retournierten Artikels zur Bewertung seines Zustands. Das Ereignis kann aus einer Änderung des Lagerorts oder Status im Warehouse-Management-Modul abgeleitet oder durch einen ausdrücklichen Scan erfasst werden.
Warum das wichtig ist Die Messung der Zeit zwischen Wareneingang und Prüfungsbeginn macht Wartezeiten an der Prüfstation sichtbar, die häufig einen Engpass darstellen. Bezugsquelle Das Ereignis kann durch eine Statusänderung der Wareneingangszeile oder eine Transaktion erfasst werden, mit der der Artikel in Oracle Inventory Management an einen Prüfplatz verschoben wird. Für eine ausdrückliche Erfassung kann eine individuelle Konfiguration erforderlich sein. Erfassen Timestamp einer Statusänderung oder einer Bestandsübertragung in einen Prüfbereich. Ereignistyp inferred
	Austauschauftrag erstellt	Diese Aktivität tritt auf, wenn der Kunde statt einer Erstattung einen Austausch angefordert hat. Es handelt sich um ein ausdrückliches Ereignis, bei dem ein neuer Verkaufsauftrag erstellt und häufig mit der ursprünglichen RMA verknüpft wird.
Warum das wichtig ist Diese Aktivität kennzeichnet eine wichtige Prozessvariante. Für eine präzise Durchlaufzeitanalyse der einzelnen Pfade müssen Austausch- und Erstattungsprozesse getrennt betrachtet werden. Bezugsquelle Dies ist ein ausdrückliches Ereignis, bei dem in Order Management ein neues Verkaufsauftragsdokument erstellt wird. Es muss über ein Referenzfeld mit der RMA verknüpft werden. Erfassen Verwenden Sie das Erstellungsdatum des mit der RMA verknüpften neuen Verkaufsauftrags. Ereignistyp explicit
	Erstattung eingeleitet	Diese Aktivität zeigt an, dass der Zahlungsprozess für die Erstattung begonnen hat. Häufig wird sie aus einer Statusänderung der Gutschrift abgeleitet, bei der der Status von „Offen“ in einen Status wechselt, der die Zahlungsbearbeitung anzeigt.
Warum das wichtig ist Diese Aktivität trennt die Genehmigung und Erstellung der Gutschrift von der eigentlichen Zahlungsabwicklung. Diese kann von einem anderen Team oder System übernommen werden und eine mögliche Verzögerungsquelle darstellen. Bezugsquelle Abgeleitet aus einer Statusänderung der Gutschrift in Accounts Receivable oder aus der Erstellung eines Zahlungsdatensatzes in Accounts Payable, der auf die Gutschrift verweist. Erfassen Identifizieren Sie den Timestamp, zu dem sich der Status der Gutschrift auf „Zahlung ausstehend“ oder einen ähnlichen Status ändert. Ereignistyp inferred
	Kunde benachrichtigt	Dies bezeichnet die an den Kunden gesendete Mitteilung zur Bestätigung der Lösung seines Retourenfalls, beispielsweise dass die Erstattung verarbeitet oder ein Ersatzartikel versendet wurde. Das Ereignis wird häufig aus einem Mitteilungsprotokoll oder einer Statusaktualisierung des Falls abgeleitet.
Warum das wichtig ist Eine zeitnahe Kundenkommunikation ist entscheidend für die Zufriedenheit. Die Analyse hilft sicherzustellen, dass Service Level Agreements für Mitteilungen eingehalten werden. Bezugsquelle Hierfür ist eine Analyse der Systeme erforderlich. Das Ereignis kann von einem integrierten CRM- oder Mitteilungssystem protokolliert werden oder aus einer manuellen Statusaktualisierung der RMA beziehungsweise einer zugehörigen Serviceanfrage hervorgehen. Erfassen Timestamp aus einem externen Mitteilungssystem oder einer manuellen Aktualisierung. Ereignistyp inferred
	Retourenentscheidung getroffen	Nach der Prüfung bezeichnet diese Aktivität die Entscheidung über den weiteren Umgang mit dem retournierten Artikel, etwa „In Bestand zurückführen“ oder „Verschrotten“. Sie wird durch eine ausdrückliche Bestandstransaktion erfasst, die den Artikel an seinen endgültigen Bestimmungsort verschiebt.
Warum das wichtig ist Dieser Schritt ist entscheidend für die Bestandsgenauigkeit und den finanziellen Abgleich. Die Analyse der Retourenentscheidungen hilft, Retourengründe und Qualitätsprobleme bei Produkten zu verstehen. Bezugsquelle Erfasst als Transaktion in Oracle Inventory Management, beispielsweise als Übertragung zwischen Subinventories oder als Aktualisierung des Artikelstatus nach der Prüfung. Erfassen Erfassen Sie den Timestamp der Bestandstransaktion, mit der die Retourenentscheidung umgesetzt wird. Ereignistyp explicit
	RMA abgelehnt	Dies bezeichnet die endgültige Entscheidung, die Retourenanfrage des Kunden abzulehnen. In der Regel wird das Ereignis aus einer Statusänderung der RMA auf „Abgelehnt“ oder „Storniert“ während der Genehmigungsphase abgeleitet.
Warum das wichtig ist Dies ist ein wichtiger Ausnahmeweg. Die Analyse der Häufigkeit und Gründe von Ablehnungen kann Probleme mit Retourenrichtlinien, Kundenerwartungen oder Betrugsversuchen aufzeigen. Bezugsquelle Abgeleitet aus dem Timestamp der Statusänderung des RMA-Auftragskopfs oder der Auftragszeile auf „Abgelehnt“ oder einen entsprechenden abschließenden Status. Erfassen Identifizieren Sie den Timestamp der Statusänderung auf „Abgelehnt“ oder „Storniert“. Ereignistyp inferred
	RMA zur Genehmigung eingereicht	Dies bezeichnet den Zeitpunkt, zu dem die erstellte RMA zur internen Prüfung und Genehmigung eingereicht wird. Häufig wird das Ereignis aus einer Statusänderung der RMA abgeleitet, die den Wechsel vom Entwurfs- oder Erfassungsstatus in den Status „Genehmigung ausstehend“ anzeigt.
Warum das wichtig ist Die Erfassung dieses Ereignisses hilft, die Dauer der Phase vor der Genehmigung zu messen. So lässt sich die Zeit für die Dateneingabe von der tatsächlichen Wartezeit auf eine Entscheidung des Genehmigenden trennen. Bezugsquelle Abgeleitet aus dem Timestamp, zu dem sich der Status des RMA-Auftragskopfs oder der Auftragszeile in der Genehmigungs-Workflow von Order Management auf „Genehmigung ausstehend“ oder einen entsprechenden Status ändert. Erfassen Identifizieren Sie den Timestamp der Statusänderung auf „Genehmigung ausstehend“. Ereignistyp inferred

Anleitungen zur Extraktion

So erhalten Sie Ihre Daten aus Oracle Fusion SCM

Schritte

Zum OTBI Analysis Editor navigieren: Melden Sie sich bei Ihrer Oracle Fusion Cloud SCM-Instanz an. Öffnen Sie im Navigator-Menü den Bereich Tools und wählen Sie anschließend Reports and Analytics. Klicken Sie auf „Create“ und wählen Sie im Dropdown-Menü „Analysis“.
Subject Areas auswählen: Wählen Sie im Dialogfeld „Select Subject Area“ die primären Subject Areas aus, die Retouren- und Erstattungsdaten enthalten. Wählen Sie „Sales - CRM All Lines“ und „Receivables - Transactions Real Time“. Diese kombinieren Sie zu einer umfassenden Sicht auf den Prozess.
In den erweiterten Modus wechseln: Nach der Auswahl der Subject Areas wird der Analysis Editor geöffnet. Wechseln Sie sofort zum Tab „Advanced“, um auf den Editor für logisches SQL zuzugreifen. Dieser ist erforderlich, um die benötigte Struktur des Event Logs zu erstellen.
Die Event-Log-Abfrage erstellen: Kopieren Sie das vollständige logische SQL aus dem Abschnitt „Query“ dieses Dokuments und fügen Sie es im Tab „Advanced“ in das Textfeld „SQL Query“ ein. Die Abfrage enthält mehrere UNION-ALL-Klauseln, um jede der 15 erforderlichen Aktivitäten als eigene Zeile abzurufen.
Abfrageparameter festlegen: Ersetzen Sie die Platzhalterwerte in der Abfrage. Aktualisieren Sie insbesondere die Platzhalter [START_DATE] und [END_DATE], um den Zeitraum für die Extraktion festzulegen. Je nach Konfiguration Ihrer Organisation müssen Sie möglicherweise auch Filter für bestimmte Business Units oder Return Order Types anpassen.
Abfrage validieren: Klicken Sie auf „Validate SQL“, um die Syntax zu prüfen. Das System gleicht Spaltennamen und Struktur mit den ausgewählten Subject Areas ab.
Ergebnisse prüfen: Öffnen Sie den Tab „Results“, um die Ausgabe in der Vorschau anzuzeigen. Die Daten sollten im Format eines Event Logs erscheinen, wobei jede Zeile eine einzelne Aktivität im Retourenprozess darstellt. Prüfen Sie, ob Spalten wie ReturnCaseId, ActivityName und EventTime erwartungsgemäß befüllt sind.
Analyse speichern: Wenn Sie mit den Ergebnissen zufrieden sind, klicken Sie auf das Symbol „Save Analysis“. Geben Sie einen aussagekräftigen Namen ein, beispielsweise „ProcessMind Returns and Refund Extraction“, und speichern Sie die Analyse in einem freigegebenen Ordner.
Exportzeitplan erstellen: Um die Extraktion zu automatisieren, können Sie die Analyse regelmäßig ausführen lassen. Suchen Sie auf der Oracle-BI-Startseite die gespeicherte Analyse, klicken Sie auf „More“ und wählen Sie „Schedule“.
Exportauftrag konfigurieren: Legen Sie in den Zeitplanoptionen die Häufigkeit fest, beispielsweise täglich oder wöchentlich. Wählen Sie im Bereich „Delivery“ als Ausgabeformat CSV. Konfigurieren Sie das Ziel, etwa Content Server oder E-Mail, an das die Ausgabedatei gesendet wird. Aktivieren Sie den Zeitplan, um die automatischen Extraktionen zu starten.

Konfiguration

Subject Areas: Die primären Subject Areas für diese Analyse sind „Sales - CRM All Lines“ für RMA-Auftragsköpfe, Positionen und Statushistorie sowie „Receivables - Transactions Real Time“ für Details zu Credit Memos und Erstattungszahlungen. Zusätzliche Subject Areas wie „Inventory - Inventory Transactions Real Time“ können erforderlich sein, wenn detailliertere Informationen zu Prüfung und Disposition benötigt werden.
Filterung nach Zeitraum: Ein Filter für den Zeitraum ist entscheidend, um das Datenvolumen zu begrenzen und eine erfolgreiche Ausführung der Analyse sicherzustellen. Wir empfehlen, jeweils Daten für einen Zeitraum von 3 bis 6 Monaten zu extrahieren. Die bereitgestellte Abfrage filtert nach dem Erstellungsdatum der RMA.
Wichtige Filter: Zusätzlich zum Zeitraum sollten Sie nach Order Type filtern, um gezielt Return Material Authorization (RMA)-Aufträge auszuwählen. Auch die Filterung nach einer bestimmten Business Unit oder Legal Entity wird empfohlen, um den Datenumfang passend einzugrenzen.
Modus für logisches SQL: Für diese Extraktionsmethode müssen Sie den Tab „Advanced“ verwenden und eine benutzerdefinierte Abfrage für logisches SQL mit UNION-ALL-Anweisungen erstellen. Dieser Ansatz ist erforderlich, um die Transaktionsdaten in das von ProcessMind benötigte Event-Log-Format umzuwandeln.
Voraussetzungen: Der Benutzer, der die Extraktion ausführt, benötigt eine Rolle mit den erforderlichen Berechtigungen zum Erstellen und Ausführen von OTBI-Analysen, beispielsweise die Rolle „BI Author“. Der Zugriff auf die angegebenen Subject Areas für Sales, Receivables und gegebenenfalls Inventory ist ebenfalls erforderlich.

a Beispielabfrage sql

SELECT
    "Sales - CRM All Lines"."Order"."Order Number" AS "ReturnCaseId",
    'RMA Created' AS "ActivityName",
    CAST("Sales - CRM All Lines"."Order"."Creation Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    "Sales - CRM All Lines"."Order"."Created By" AS "ProcessingAgent",
    "Sales - CRM All Lines"."Order"."Header Status" AS "ReturnStatus",
    "Sales - CRM All Lines"."Order"."Order Amount" AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    "Sales - CRM All Lines"."Order"."Return Reason" AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines"
WHERE "Sales - CRM All Lines"."Order"."Order Type" = 'Return'
AND "Sales - CRM All Lines"."Order"."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'RMA Approval Submitted' AS "ActivityName",
    CAST(T4663."Status Change Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    T4663."Updated By" AS "ProcessingAgent",
    T4663."New Status" AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654, "Sales - CRM All Lines"."Header Status History" T4663
WHERE T4654."Order Key" = T4663."Order Key" AND T4654."Order Type" = 'Return' AND T4663."New Status" = 'Pending Approval' AND T4654."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'RMA Approved' AS "ActivityName",
    CAST(T4663."Status Change Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    T4663."Updated By" AS "ProcessingAgent",
    T4663."New Status" AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654, "Sales - CRM All Lines"."Header Status History" T4663
WHERE T4654."Order Key" = T4663."Order Key" AND T4654."Order Type" = 'Return' AND T4663."New Status" = 'Awaiting Receiving' AND T4654."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'Item Shipped By Customer' AS "ActivityName",
    CAST(NULL AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime", NULL AS "ProcessingAgent", NULL AS "ReturnStatus", NULL AS "RequestedRefundAmount", NULL AS "ActualRefundAmount", NULL AS "ReturnReason", NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654 WHERE T4654."Order Type" = 'Return' AND 1=0 -- Placeholder: This event is not standard. Adapt if custom fields exist.
UNION ALL
SELECT
    "Sales - CRM All Lines"."Order"."Order Number" AS "ReturnCaseId",
    'Item Received' AS "ActivityName",
    CAST("Sales - CRM All Lines"."Fulfillment Line"."Actual Arrival Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    "Sales - CRM All Lines"."Fulfillment Line"."Last Updated By" AS "ProcessingAgent",
    "Sales - CRM All Lines"."Fulfillment Line"."Fulfillment Line Status" AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines"
WHERE "Sales - CRM All Lines"."Order"."Order Type" = 'Return' AND "Sales - CRM All Lines"."Fulfillment Line"."Actual Arrival Date" IS NOT NULL
AND "Sales - CRM All Lines"."Order"."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'Item Inspection Started' AS "ActivityName",
    CAST(NULL AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime", NULL AS "ProcessingAgent", NULL AS "ReturnStatus", NULL AS "RequestedRefundAmount", NULL AS "ActualRefundAmount", NULL AS "ReturnReason", NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654 WHERE T4654."Order Type" = 'Return' AND 1=0 -- Placeholder: Requires Inventory subject area or custom fields.
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'Item Inspected' AS "ActivityName",
    CAST(NULL AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime", NULL AS "ProcessingAgent", NULL AS "ReturnStatus", NULL AS "RequestedRefundAmount", NULL AS "ActualRefundAmount", NULL AS "ReturnReason", NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654 WHERE T4654."Order Type" = 'Return' AND 1=0 -- Placeholder: Requires Inventory subject area or custom fields.
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'Return Disposition Determined' AS "ActivityName",
    CAST(NULL AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime", NULL AS "ProcessingAgent", NULL AS "ReturnStatus", NULL AS "RequestedRefundAmount", NULL AS "ActualRefundAmount", NULL AS "ReturnReason", NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654 WHERE T4654."Order Type" = 'Return' AND 1=0 -- Placeholder: Requires Inventory subject area.
UNION ALL
SELECT
    "Receivables - Transactions Real Time"."Transaction Details"."Reference Transaction Number" AS "ReturnCaseId",
    'Credit Memo Created' AS "ActivityName",
    CAST("Receivables - Transactions Real Time"."Transaction Details"."Transaction Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    "Receivables - Transactions Real Time"."Transaction Details"."Created By" AS "ProcessingAgent",
    "Receivables - Transactions Real Time"."Transaction Details"."Transaction Status" AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    "Receivables - Transactions Real Time"."Transaction Details"."Transaction Amount" AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Receivables - Transactions Real Time"
WHERE "Receivables - Transactions Real Time"."Transaction Details"."Transaction Class" = 'Credit Memo'
AND "Receivables - Transactions Real Time"."Transaction Details"."Transaction Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    "Receivables - Transactions Real Time"."Transaction Details"."Reference Transaction Number" AS "ReturnCaseId",
    'Refund Initiated' AS "ActivityName",
    CAST("Receivables - Transactions Real Time"."Receipt Application Details"."Application Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    "Receivables - Transactions Real Time"."Receipt Application Details"."Created By" AS "ProcessingAgent",
    'Refund Initiated' AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    "Receivables - Transactions Real Time"."Receipt Application Details"."Amount Applied" * -1 AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Receivables - Transactions Real Time"
WHERE "Receivables - Transactions Real Time"."Transaction Details"."Transaction Class" = 'Credit Memo'
AND "Receivables - Transactions Real Time"."Transaction Details"."Transaction Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    "Receivables - Transactions Real Time"."Transaction Details"."Reference Transaction Number" AS "ReturnCaseId",
    'Refund Processed' AS "ActivityName",
    CAST("Receivables - Transactions Real Time"."Receipt Application Details"."GL Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    "Receivables - Transactions Real Time"."Receipt Application Details"."Created By" AS "ProcessingAgent",
    'Refund Processed' AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    "Receivables - Transactions Real Time"."Receipt Application Details"."Amount Applied" * -1 AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Receivables - Transactions Real Time"
WHERE "Receivables - Transactions Real Time"."Transaction Details"."Transaction Class" = 'Credit Memo' AND "Receivables - Transactions Real Time"."Receipt Application Details"."GL Date" IS NOT NULL
AND "Receivables - Transactions Real Time"."Transaction Details"."Transaction Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'Customer Notified' AS "ActivityName",
    CAST(NULL AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime", NULL AS "ProcessingAgent", NULL AS "ReturnStatus", NULL AS "RequestedRefundAmount", NULL AS "ActualRefundAmount", NULL AS "ReturnReason", NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654 WHERE T4654."Order Type" = 'Return' AND 1=0 -- Placeholder: Requires integration with a notification or CRM system.
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'Return Case Closed' AS "ActivityName",
    CAST(T4663."Status Change Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    T4663."Updated By" AS "ProcessingAgent",
    T4663."New Status" AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654, "Sales - CRM All Lines"."Header Status History" T4663
WHERE T4654."Order Key" = T4663."Order Key" AND T4654."Order Type" = 'Return' AND T4663."New Status" = 'Closed' AND T4654."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'RMA Rejected' AS "ActivityName",
    CAST(T4663."Status Change Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    T4663."Updated By" AS "ProcessingAgent",
    T4663."New Status" AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654, "Sales - CRM All Lines"."Header Status History" T4663
WHERE T4654."Order Key" = T4663."Order Key" AND T4654."Order Type" = 'Return' AND T4663."New Status" IN ('Canceled', 'Rejected') AND T4654."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    "Sales - CRM All Lines"."Order"."Return Reference Order Number" AS "ReturnCaseId",
    'Exchange Order Created' AS "ActivityName",
    CAST("Sales - CRM All Lines"."Order"."Creation Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    "Sales - CRM All Lines"."Order"."Created By" AS "ProcessingAgent",
    "Sales - CRM All Lines"."Order"."Header Status" AS "ReturnStatus",
    "Sales - CRM All Lines"."Order"."Order Amount" AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    "Sales - CRM All Lines"."Order"."Return Reason" AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines"
WHERE "Sales - CRM All Lines"."Order"."Return Reference Order Number" IS NOT NULL
AND "Sales - CRM All Lines"."Order"."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'

Schritte

Prüfen Sie, ob Oracle BI Cloud Connector, die erforderlichen SCM-Subject-Areas oder View Objects, die Bereitstellung in einem Cloud-Speicher sowie die benötigten Datenquellen für Oracle Fusion SCM, Inventory Management, Quality Management, Order Management, Accounts Receivable, Zahlungen und Mitteilungen in Ihrer Umgebung verfügbar sind. Stimmen Sie die Berechtigungen mit Ihrem Oracle-Administrator ab.
Identifizieren Sie die konfigurierten BICC-View-Objects, die Informationen zu Retourenkopf, Genehmigungshistorie, Wareneingangstransaktionen, Prüfdatensätzen, Dispositionstransaktionen, Credit Memo, Erstattung, Austauschauftrag, Benachrichtigung und Abschluss enthalten. RmaHeaderAll ist ein Beispiel für ein View Object für Retourenköpfe. Ersetzen Sie jeden in eckigen Klammern angegebenen Quellverweis im Extraktionsskript durch das entsprechende View Object oder den in Ihrer Umgebung bereitgestellten Export.
Konfigurieren Sie einen BICC-Extraktionsauftrag für die erforderlichen View Objects. Wählen Sie je nach verfügbaren Änderungsverfolgungsfeldern eine inkrementelle oder vollständige Extraktion, konfigurieren Sie die Bereitstellung im Cloud-Speicher und legen Sie das erforderliche Start- und Enddatum für das Extraktionsfenster fest. Verwenden Sie [Configure based on your system], wenn sich Auftragsname, Speicherort oder View-Object-Konfiguration des BICC-Auftrags unterscheiden.
Extrahieren Sie die Quelldaten in den Cloud-Speicher. Bewahren Sie Quellkennungen, Ereignis-Timestamps, Statuswerte, Benutzer- oder Agentenkennungen, Geldbeträge, Retourengründe, SLA-Daten und den BICC-Aktualisierungs-Timestamp auf. Überschreiben Sie Quell-Timestamps bei der Zusammenführung von Dateien nicht.
Laden Sie die bereitgestellten Dateien in einen Staging-Bereich. Vereinheitlichen Sie die Quellspaltennamen zu ReturnCaseId, ActivityName, EventTime, SourceSystem, LastDataUpdate, EndTime, ProcessingAgent, ReturnStatus, RequestedRefundAmount, ActualRefundAmount, ReturnReason und RefundSlaTargetDate. Konvertieren Sie Timestamps in eine einheitliche vereinbarte Zeitzone und bewahren Sie die ursprüngliche Zeitzone separat auf, sofern erforderlich.
Wenden Sie die Ereignisregeln aus dem Extraktionsskript an. Jede Regel muss eine eigene Ereigniszeile erzeugen. Statusänderungen für abgeleitete Aktivitäten müssen auf der relevanten Statushistorie oder einem zuverlässigen Aktualisierungs-Timestamp basieren. Wenn historische Statusänderungen erforderlich sind, dürfen Sie sich nicht ausschließlich auf den aktuellen Status stützen, da dadurch frühere Ereignisse fehlen würden.
Führen Sie alle aktivitätsspezifischen Ereigniszeilen zusammen, entfernen Sie nur exakte Duplikate, die durch wiederholte Quelldatenbereitstellung entstanden sind, und behalten Sie legitime wiederholte Ereignisse bei, wenn die Quelldatensätze separate Geschäftsvorgänge darstellen. Prüfen Sie, ob ReturnCaseId für jede Ereigniszeile befüllt ist.
Ergänzen Sie jedes Ereignis um die zuletzt verfügbaren Attribute auf Fallebene. Bewahren Sie dabei ereignisspezifische Werte auf, sofern vorhanden. Befüllen Sie SourceSystem mit Oracle Fusion SCM oder dem konfigurierten Quellnamen und LastDataUpdate mit dem BICC-Extraktions- oder Quellaktualisierungs-Timestamp.
Führen Sie die unten beschriebenen Validierungsprüfungen durch. Stellen Sie sicher, dass alle 15 erforderlichen Aktivitätsnamen vorhanden sind, die Timestamps innerhalb des Extraktionszeitraums oder eines ausdrücklich dokumentierten operativen Zeitfensters liegen und die abschließenden Aktivitäten mit dem finalen Retourenstatus übereinstimmen.
Exportieren Sie das resultierende Event Log als CSV oder in einem anderen von ProcessMind unterstützten Format. Fügen Sie eine Zeile pro Ereignis sowie exakt die Spalten ReturnCaseId, ActivityName, EventTime, SourceSystem und LastDataUpdate ein. Ergänzen Sie außerdem die empfohlenen Attribute, sofern verfügbar. Laden Sie die Datei in ProcessMind hoch und ordnen Sie ReturnCaseId als Fallkennung, ActivityName als Aktivität und EventTime als Ereignis-Timestamp zu.

Konfiguration

Extraktionsmethode: Konfigurieren Sie Oracle BI Cloud Connector für die Massenbereitstellung der erforderlichen SCM- und zugehörigen View Objects in einem Cloud-Speicher. Der konkrete BICC-Auftrag, der Speicherpfad und die verfügbaren View Objects hängen von der jeweiligen Oracle-Fusion-Umgebung ab.
Quellobjekte: RmaHeaderAll kann Informationen zum Retourenkopf liefern. Für Genehmigungshistorie, Wareneingang, Prüfung, Disposition, Credit Memo, Erstattung, Austausch, Benachrichtigung und Abschluss können zusätzliche View Objects oder bereitgestellte Exporte erforderlich sein. Verwenden Sie [Your view object name], wenn eine entsprechende Quelle noch nicht bestätigt wurde.
Zeitraum: Beginnen Sie mit Daten aus 3 bis 6 Monaten. Erweitern Sie den Zeitraum erst, nachdem Sie Datenvolumen, Verfügbarkeit historischer Statuswerte und Kapazität des Cloud-Speichers geprüft haben. Verwenden Sie für inkrementelle Ladevorgänge ein Überlappungsfenster, um verspätet eingehende Aktualisierungen zu erfassen.
Inkrementelle Extraktion: Bevorzugen Sie einen dokumentierten Änderungs-Timestamp oder einen von BICC unterstützten inkrementellen Mechanismus. Wenn nur Daten zum aktuellen Zustand verfügbar sind, lassen sich historische abgeleitete Ereignisse nicht zuverlässig rekonstruieren.
Filter: Wenden Sie Filter für Unternehmen, Business Unit, Inventory Organization, Dokumenttyp, Retourenart, Order Type, Operating Unit und Status nur an, wenn die zugehörigen Quellfelder und ihre fachliche Bedeutung bestätigt sind. Verwenden Sie [Company-specific filter] und [Document type filter] für umgebungsspezifische Bedingungen.
Ereignis-Timestamps: Verwenden Sie nach Möglichkeit den Timestamp des Geschäftsvorgangs. Setzen Sie einen Status- oder Datensatzaktualisierungs-Timestamp nur für ausdrücklich dokumentierte abgeleitete Ereignisse ein und halten Sie die Ableitungsregel im Datenverzeichnis fest.
Duplikatbereinigung: Entfernen Sie Duplikate anhand von ReturnCaseId, ActivityName, EventTime, der Quellereigniskennung und, sofern verfügbar, dem Quellsystem. Fassen Sie separate Wareneingangs-, Prüf- oder Zahlungsereignisse nicht allein deshalb zusammen, weil sie dieselbe Fallkennung haben.
Leistung: Teilen Sie die Extraktion nach Zeitraum, Business Unit, Inventory Organization oder einer anderen unterstützten Quellpartition auf. Vermeiden Sie uneingeschränkte vollständige Extraktionen während der Geschäftszeiten in Umgebungen mit hohem Datenvolumen. Überwachen Sie Laufzeit des BICC-Auftrags, Dateigröße, Kapazität des Cloud-Speichers und die Leistung des nachgelagerten Staging-Bereichs.
Voraussetzungen: Bestätigen Sie den BICC-Zugriff, den Zugriff auf den Cloud-Speicher, die erforderlichen Oracle-Fusion-Rollen, den Zugriff auf die relevanten Daten aus SCM, Inventory Management, Quality Management, Order Management, Accounts Receivable, Zahlungen und Mitteilungen sowie gegebenenfalls erforderliche Lizenzen für Reporting oder Integration.
Sicherheit: Verwenden Sie freigegebene Zugangsdaten und verschlüsselten Cloud-Speicher. Beschränken Sie die Exporte auf die unbedingt erforderlichen Attribute und wenden Sie die Aufbewahrungs- und Zugriffsrichtlinien Ihrer Organisation an.
Verfügbarkeit der Quellen: Einige Aktivitäten, insbesondere Kundenversand, Beginn der Prüfung, Einleitung der Erstattung und Kundenbenachrichtigung, können externe Daten von Transportdienstleistern, Lagern, Zahlungs- oder Kommunikationssystemen erfordern. Verwenden Sie [Configure based on your system], wenn diese Quellen nicht über BICC bereitgestellt werden.

a Beispielabfrage sql

WITH
source_data AS (
    SELECT
        r.return_case_id,
        r.created_timestamp,
        r.approval_submitted_timestamp,
        r.approved_timestamp,
        r.customer_shipped_timestamp,
        r.item_received_timestamp,
        r.inspection_started_timestamp,
        r.inspected_timestamp,
        r.disposition_determined_timestamp,
        r.credit_memo_created_timestamp,
        r.refund_initiated_timestamp,
        r.refund_processed_timestamp,
        r.customer_notified_timestamp,
        r.closed_timestamp,
        r.rejected_timestamp,
        r.exchange_order_created_timestamp,
        r.end_timestamp,
        r.processing_agent,
        r.return_status,
        r.requested_refund_amount,
        r.actual_refund_amount,
        r.return_reason,
        r.refund_sla_target_date,
        r.last_data_update
    FROM [Your configured return event source] r
    WHERE r.last_data_update >= [Start date parameter]
      AND r.last_data_update < [End date parameter]
      AND ([Company-specific filter])
),
events AS (
    SELECT return_case_id AS ReturnCaseId, 'RMA Created' AS ActivityName, created_timestamp AS EventTime, 'Oracle Fusion SCM' AS SourceSystem, last_data_update AS LastDataUpdate, end_timestamp AS EndTime, processing_agent AS ProcessingAgent, return_status AS ReturnStatus, requested_refund_amount AS RequestedRefundAmount, actual_refund_amount AS ActualRefundAmount, return_reason AS ReturnReason, refund_sla_target_date AS RefundSlaTargetDate FROM source_data WHERE created_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'RMA Approval Submitted', approval_submitted_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE approval_submitted_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'RMA Approved', approved_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE approved_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Item Shipped By Customer', customer_shipped_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE customer_shipped_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Item Received', item_received_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE item_received_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Item Inspection Started', inspection_started_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE inspection_started_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Item Inspected', inspected_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE inspected_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Return Disposition Determined', disposition_determined_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE disposition_determined_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Credit Memo Created', credit_memo_created_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE credit_memo_created_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Refund Initiated', refund_initiated_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE refund_initiated_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Refund Processed', refund_processed_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE refund_processed_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Customer Notified', customer_notified_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE customer_notified_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Return Case Closed', closed_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE closed_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'RMA Rejected', rejected_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE rejected_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Exchange Order Created', exchange_order_created_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE exchange_order_created_timestamp IS NOT NULL
)
SELECT
    ReturnCaseId,
    ActivityName,
    EventTime,
    SourceSystem,
    LastDataUpdate,
    EndTime,
    ProcessingAgent,
    ReturnStatus,
    RequestedRefundAmount,
    ActualRefundAmount,
    ReturnReason,
    RefundSlaTargetDate
FROM events
WHERE ReturnCaseId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY ReturnCaseId, EventTime, ActivityName;

Schritte

Python-Umgebung einrichten: Stellen Sie sicher, dass Python 3.6 oder neuer installiert ist. Installieren Sie die erforderlichen Bibliotheken mit pip: pip install requests pandas.
Zugriff auf Oracle Fusion SCM konfigurieren: Beschaffen Sie Zugangsdaten für einen Oracle-Fusion-Benutzer mit den erforderlichen Rollen für den Zugriff auf REST-APIs. Dazu gehören in der Regel die Rollen Order Manager und Accounts Receivable Manager. Der Benutzer muss berechtigt sein, Verkaufsaufträge (RMAs) und Gutschriften aus der Debitorenbuchhaltung einzusehen.
API-Endpunkte ermitteln: Bestätigen Sie die Basis-URL Ihrer Oracle-Fusion-SCM-Instanz. Das Skript verwendet die REST-Ressourcen salesOrdersForOrderHub und receivablesCreditMemos. Die Version 11.13.18.05 muss möglicherweise an Ihre Umgebung angepasst werden.
Python-Skript anpassen: Öffnen Sie das bereitgestellte Python-Skript. Aktualisieren Sie die Platzhaltervariablen am Anfang des Skripts: ORACLE_BASE_URL, ORACLE_USERNAME und ORACLE_PASSWORD. Passen Sie die Variable RMA_ORDER_TYPE an den spezifischen Auftragstypcode an, der in Ihrem System für RMAs verwendet wird.
Extraktionszeitraum festlegen: Ändern Sie die Variablen START_DATE und END_DATE im Skript, um den Zeitraum für die Datenextraktion festzulegen. Es empfiehlt sich, zunächst mit einem kürzeren Zeitraum, beispielsweise einem Monat, zu beginnen und das Skript zu testen.
Skript ausführen: Führen Sie das Skript über die Befehlszeile aus: python extract_oracle_returns.py. Das Skript verbindet sich mit den Oracle-APIs, ruft die Daten ab, verarbeitet sie und gibt Statusmeldungen in der Konsole aus.
Event Log abrufen: Nach erfolgreicher Ausführung erstellt das Skript im selben Verzeichnis eine Datei mit dem Namen returns_event_log.csv. Diese Datei enthält das extrahierte Event Log.
Daten prüfen und für den Upload vorbereiten: Öffnen Sie die Datei returns_event_log.csv in einer Tabellenkalkulation. Prüfen Sie die Daten auf Vollständigkeit und Richtigkeit, insbesondere die Spalten ActivityName und EventTime. Stellen Sie sicher, dass die Spaltenüberschriften den Anforderungen Ihres Process-Mining-Tools entsprechen.
In ProcessMind hochladen: Laden Sie die erzeugte CSV-Datei direkt in ProcessMind hoch. Ordnen Sie die Spalten der CSV-Datei den entsprechenden Attributen in ProcessMind zu (ReturnCaseId zur Case-ID, ActivityName zur Aktivität, EventTime zum Timestamp).

Konfiguration

API-Endpunkte: Das Skript verwendet hauptsächlich zwei REST-API-Endpunkte: /fscmRestApi/resources/11.13.18.05/salesOrdersForOrderHub für RMA-Auftragsdaten und /fscmRestApi/resources/11.13.18.05/receivablesCreditMemos für Finanzdaten zu Erstattungen.
Authentifizierung: Das Skript verwendet die Basisauthentifizierung. Der bereitgestellte Benutzername und das Passwort müssen zu einem Benutzerkonto mit API-Zugriff und ausreichenden Berechtigungen zum Lesen von Auftrags- und Debitorendaten gehören.
Datumsbereich: Die Extraktion wird nach dem Feld CreationDate der RMA-Aufträge gefiltert. Konfigurieren Sie die Variablen START_DATE und END_DATE im Skript. Für Erstladungen wird ein Zeitraum von 3 bis 6 Monaten empfohlen. Verwenden Sie für laufende Aktualisierungen ein gleitendes Zeitfenster.
Filter für den RMA-Auftragstyp: Die Variable RMA_ORDER_TYPE im Skript muss unbedingt konfiguriert werden. Dadurch werden ausschließlich Retourenaufträge und keine Standardverkaufsaufträge extrahiert. Den Code für Ihren RMA-Auftragstyp finden Sie in der Einrichtungsaufgabe Manage Order Types in Oracle Fusion.
Mapping von Statuscodes: Das Skript ordnet die internen Statuscodes von Oracle, etwa DOO_AWAITING_RECEIVING und DOO_CLOSED, den geschäftsfreundlichen Werten von ActivityName zu. Dieses Mapping muss möglicherweise an Ihre spezifische Oracle-SCM-Konfiguration angepasst werden.
Voraussetzungen: Sie benötigen Zugriff auf eine Oracle-Fusion-SCM-Umgebung. Das Benutzerkonto für die Extraktion muss über Rollen wie Order Manager (ORA_DOO_ORDER_MANAGER_JOB) und Accounts Receivable Manager (ORA_AR_ACCOUNTS_RECEIVABLE_MANAGER_JOB) oder entsprechende benutzerdefinierte Rollen mit Zugriff auf die erforderlichen REST-APIs verfügen.

a Beispielabfrage python

import requests
import pandas as pd
from datetime import datetime
import json

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
ORACLE_BASE_URL = class="hl-string">"https://[your_oracle_fusion_instance].fa.ocs.oraclecloud.com"
ORACLE_USERNAME = class="hl-string">"[your_api_user]"
ORACLE_PASSWORD = class="hl-string">"[your_api_password]"
RMA_ORDER_TYPE = class="hl-string">"ORA_RETURN_ORDER"  class=class="hl-string">"hl-comment"># IMPORTANT: Configure with your specific RMA Order Type Code
START_DATE = class="hl-string">"2023-01-01T00:00:00.000Z" class=class="hl-string">"hl-comment"># Format: YYYY-MM-DDTHH:MM:SS.sssZ
END_DATE = class="hl-string">"2023-06-30T23:59:59.000Z"

class=class="hl-string">"hl-comment"># --- Helper Functions --- #
def get_paginated_data(endpoint, params):
    class="hl-string">"""Fetches all data from a paginated Oracle REST API endpoint."""
    all_items = []
    url = fclass="hl-string">"{ORACLE_BASE_URL}{endpoint}"
    params[class="hl-string">'limit'] = 200 class=class="hl-string">"hl-comment"># Max limit can be up to 500
    params[class="hl-string">'offset'] = 0

    while True:
        print(fclass="hl-string">"Fetching data from {url} with offset {params['offset']}...")
        try:
            response = requests.get(url, auth=(ORACLE_USERNAME, ORACLE_PASSWORD), params=params)
            response.raise_for_status()
            data = response.json()
            items = data.get(class="hl-string">'items', [])
            if not items:
                break
            all_items.extend(items)
            if data.get(class="hl-string">'hasMore', False):
                params[class="hl-string">'offset'] += len(items)
            else:
                break
        except requests.exceptions.HTTPError as e:
            print(fclass="hl-string">"HTTP Error: {e}")
            print(fclass="hl-string">"Response content: {response.text}")
            break
        except json.JSONDecodeError as e:
            print(fclass="hl-string">"JSON Decode Error: {e}")
            print(fclass="hl-string">"Response content: {response.text}")
            break
    return all_items

class=class="hl-string">"hl-comment"># --- Main Extraction Logic --- #
if __name__ == class="hl-string">"__main__":
    event_log_records = []
    last_data_update = datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># 1. Fetch all RMA Orders
    print(class="hl-string">"Fetching RMA orders...")
    rma_params = {
        class="hl-string">'finder': class="hl-string">'findOrders',
        class="hl-string">'q': fclass="hl-string">"OrderTypeCode='{RMA_ORDER_TYPE}' and CreationDate between '{START_DATE}' and '{END_DATE}'",
        class="hl-string">'fields': class="hl-string">'OrderNumber,CreationDate,CreatedBy,LastUpdateDate,LastUpdatedBy,OrderStatus,ReturnReasonCode,CrossReference,lines',
        class="hl-string">'expand': class="hl-string">'lines.fulfillmentLines'
    }
    rma_orders = get_paginated_data(class="hl-string">"/fscmRestApi/resources/11.13.18.05/salesOrdersForOrderHub", rma_params)

    class=class="hl-string">"hl-comment"># 2. Fetch all related Credit Memos (can be optimized by filtering on creation date)
    print(class="hl-string">"Fetching Credit Memos...")
    cm_params = {
        class="hl-string">'fields': class="hl-string">'TransactionNumber,TransactionDate,Amount,CustomerTransactionId,SalesOrderNumber'
    }
    credit_memos = get_paginated_data(class="hl-string">"/fscmRestApi/resources/11.13.18.05/receivablesCreditMemos", cm_params)
    cm_map = {cm[class="hl-string">'SalesOrderNumber']: cm for cm in credit_memos if class="hl-string">'SalesOrderNumber' in cm}

    print(fclass="hl-string">"Processing {len(rma_orders)} RMA orders...")
    for rma in rma_orders:
        case_id = rma.get(class="hl-string">'OrderNumber')
        if not case_id:
            continue

        class=class="hl-string">"hl-comment"># Helper to add events
        def add_event(activity, timestamp, agent, status, reason=None, end_time=None):
            if timestamp:
                event_log_records.append({
                    class="hl-string">'ReturnCaseId': case_id,
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': timestamp,
                    class="hl-string">'EndTime': end_time if end_time else timestamp,
                    class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion SCM',
                    class="hl-string">'LastDataUpdate': last_data_update,
                    class="hl-string">'ProcessingAgent': agent,
                    class="hl-string">'ReturnStatus': status,
                    class="hl-string">'ReturnReason': reason,
                    class="hl-string">'RequestedRefundAmount': None, class=class="hl-string">"hl-comment"># Placeholder
                    class="hl-string">'ActualRefundAmount': None, class=class="hl-string">"hl-comment"># Placeholder
                    class="hl-string">'RefundSlaTargetDate': None class=class="hl-string">"hl-comment"># Placeholder
                })

        class=class="hl-string">"hl-comment"># Activity: RMA Created
        add_event(class="hl-string">'RMA Created', rma.get(class="hl-string">'CreationDate'), rma.get(class="hl-string">'CreatedBy'), class="hl-string">'Draft', rma.get(class="hl-string">'ReturnReasonCode'))

        class=class="hl-string">"hl-comment"># Activities from Fulfillment Lines
        if class="hl-string">'lines' in rma and rma[class="hl-string">'lines']:
            for line in rma[class="hl-string">'lines'][class="hl-string">'items']:
                if class="hl-string">'fulfillmentLines' in line and line[class="hl-string">'fulfillmentLines']:
                    for ff_line in line[class="hl-string">'fulfillmentLines'][class="hl-string">'items']:
                        ff_status = ff_line.get(class="hl-string">'StatusCode')
                        last_update = ff_line.get(class="hl-string">'LastUpdateDate', rma.get(class="hl-string">'LastUpdateDate'))
                        agent = ff_line.get(class="hl-string">'LastUpdatedBy', rma.get(class="hl-string">'LastUpdatedBy'))

                        class=class="hl-string">"hl-comment"># The following is an inference based on typical status flows.
                        class=class="hl-string">"hl-comment"># Your specific statuses may vary.
                        if ff_status in [class="hl-string">'DOO_AWAIT_APPROVAL', class="hl-string">'DOO_SUBMITTED']:
                            add_event(class="hl-string">'RMA Approval Submitted', last_update, agent, ff_status)
                        elif ff_status == class="hl-string">'DOO_AWAIT_RECEIVING':
                            add_event(class="hl-string">'RMA Approved', last_update, agent, ff_status)
                        elif ff_status in [class="hl-string">'DOO_PARTIALLY_FULFILLED', class="hl-string">'DOO_SHIPMENT_CONFIRMED']:
                             add_event(class="hl-string">'Item Received', ff_line.get(class="hl-string">'ActualShipDate', last_update), agent, ff_status)
                             class=class="hl-string">"hl-comment"># Infer inspection events based on receipt
                             add_event(class="hl-string">'Item Inspection Started', ff_line.get(class="hl-string">'ActualShipDate', last_update), agent, class="hl-string">'Awaiting Inspection')
                             add_event(class="hl-string">'Item Inspected', last_update, agent, class="hl-string">'Inspection Complete')
                        elif ff_status == class="hl-string">'DOO_AWAIT_BILLING':
                            add_event(class="hl-string">'Return Disposition Determined', last_update, agent, ff_status)
                        elif ff_status == class="hl-string">'DOO_CLOSED':
                            add_event(class="hl-string">'Return Case Closed', last_update, agent, ff_status)
                        elif ff_status in [class="hl-string">'DOO_CANCELED', class="hl-string">'DOO_REJECTED']:
                            add_event(class="hl-string">'RMA Rejected', last_update, agent, ff_status)
                        
                        class=class="hl-string">"hl-comment"># Placeholder activities not directly available
                        add_event(class="hl-string">'Item Shipped By Customer', None, class="hl-string">'Customer', class="hl-string">'In Transit')
                        add_event(class="hl-string">'Customer Notified', None, class="hl-string">'System', class="hl-string">'Notification Sent')

        class=class="hl-string">"hl-comment"># Activity: Exchange Order Created
        if rma.get(class="hl-string">'CrossReference'):
             add_event(class="hl-string">'Exchange Order Created', rma.get(class="hl-string">'LastUpdateDate'), rma.get(class="hl-string">'LastUpdatedBy'), rma.get(class="hl-string">'OrderStatus'))

        class=class="hl-string">"hl-comment"># Activities from Credit Memos
        if case_id in cm_map:
            cm = cm_map[case_id]
            cm_date = cm.get(class="hl-string">'TransactionDate')
            cm_amount = cm.get(class="hl-string">'Amount')
            add_event(class="hl-string">'Credit Memo Created', cm_date, class="hl-string">'System', class="hl-string">'Credit Memo Issued')
            add_event(class="hl-string">'Refund Initiated', cm_date, class="hl-string">'System', class="hl-string">'Refund In Progress')
            class=class="hl-string">"hl-comment"># Assuming refund is processed shortly after creation for this example
            add_event(class="hl-string">'Refund Processed', cm_date, class="hl-string">'System', class="hl-string">'Refund Complete')

            class=class="hl-string">"hl-comment"># Update refund amounts on all events for this case
            for rec in event_log_records:
                if rec[class="hl-string">'ReturnCaseId'] == case_id:
                    rec[class="hl-string">'ActualRefundAmount'] = cm_amount
                    rec[class="hl-string">'RequestedRefundAmount'] = cm_amount class=class="hl-string">"hl-comment"># Assuming requested equals actual

    class=class="hl-string">"hl-comment"># 4. Create and Save DataFrame
    if not event_log_records:
        print(class="hl-string">"No events were generated. Check your configuration and date range.")
    else:
        df = pd.DataFrame(event_log_records)
        df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'], errors=class="hl-string">'coerce')
        df = df.dropna(subset=[class="hl-string">'EventTime'])
        df = df.sort_values(by=[class="hl-string">'ReturnCaseId', class="hl-string">'EventTime'])

        class=class="hl-string">"hl-comment"># Reorder columns
        column_order = [
            class="hl-string">'ReturnCaseId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'EndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
            class="hl-string">'ProcessingAgent', class="hl-string">'ReturnStatus', class="hl-string">'ReturnReason', class="hl-string">'RequestedRefundAmount', 
            class="hl-string">'ActualRefundAmount', class="hl-string">'RefundSlaTargetDate'
        ]
        df = df[column_order]

        df.to_csv(class="hl-string">'returns_event_log.csv', index=False)
        print(class="hl-string">"Successfully created returns_event_log.csv")

Bereit für den Start?

Verwenden Sie dieses Template, um Ihre Datenerfassung zu vereinfachen und aussagekräftige Erkenntnisse zu Ihren Retouren- und Erstattungsprozessen zu gewinnen. Beginnen Sie noch heute mit der Optimierung Ihres Prozesses.

Zurück zum Leitfaden zur Verbesserung Template herunterladen

Beseitigen Sie Engpässe und optimieren Sie Ihre Retouren- und Erstattungsprozesse jetzt

Identifizieren Sie Ineffizienzen und reduzieren Sie die Durchlaufzeit in Oracle Fusion SCM um 30 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Einrichtung in weniger als 5 Minuten.

Ihr Daten-Template für Retouren- und Erstattungsprozesse

Ihr Daten-Template für Retouren- und Erstattungsprozesse

Attribute für die Bearbeitung von Retouren und Rückerstattungen

Aktivitäten für die Bearbeitung von Retouren und Rückerstattungen

Anleitungen zur Extraktion

Export aus Oracle Transactional Business Intelligence (OTBI)

Schritte

Konfiguration

a Beispielabfrage sql

Extraktion von View Objects mit Oracle BI Cloud Connector (BICC)

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit Oracle Fusion SCM REST-APIs

Schritte

Konfiguration

a Beispielabfrage python

Bereit für den Start?

Beseitigen Sie Engpässe und optimieren Sie Ihre Retouren- und Erstattungsprozesse jetzt

Ihr Daten-Template für Retouren- und Erstattungsprozesse

Ihr Daten-Template für Retouren- und Erstattungsprozesse

Attribute für die Bearbeitung von Retouren und Rückerstattungen

Aktivitäten für die Bearbeitung von Retouren und Rückerstattungen

Anleitungen zur Extraktion

Export aus Oracle Transactional Business Intelligence (OTBI)

Schritte

Konfiguration

a Beispielabfrage sql

Extraktion von View Objects mit Oracle BI Cloud Connector (BICC)

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit Oracle Fusion SCM REST-APIs

Schritte

Konfiguration

a Beispielabfrage python

Bereit für den Start?

Beseitigen Sie Engpässe und optimieren Sie Ihre Retouren- und Erstattungsprozesse jetzt

Ihre Privatsphäre ist uns wichtig