Ihr Daten-Template für die Retouren- und Erstattungsbearbeitung
Ihr Daten-Template für die Retouren- und Erstattungsbearbeitung
- Empfohlene zu erfassende Attribute
- Wichtige zu verfolgende Aktivitäten
- Hinweise zur Extraktion
Attribute der Retouren- und Rückerstattungsabwicklung
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Der Name eines bestimmten Geschäfts-Events oder Prozessschritts, der innerhalb der Retourenabwicklung stattgefunden hat. | ||
| Beschreibung Dieses Attribut beschreibt eine einzelne, klar abgegrenzte Aktion oder Statusänderung im Lebenszyklus einer Retoure, etwa „Return Order Created“, „Goods Receipt Posted“ oder „Credit Memo Created“. Diese Aktivitäten bilden die Bausteine der Prozesskarte. Die Analyse ihrer Reihenfolge und Häufigkeit zeigt die häufigsten Prozesspfade, Abweichungen und Nachbearbeitungsschleifen. Sie ist entscheidend, um zu verstehen, was innerhalb eines Falls geschieht und in welcher Reihenfolge. Damit bildet sie die Grundlage für jede Process-Mining-Analyse. Warum das wichtig ist Aktivitäten definieren die Schritte eines Prozesses. Die Analyse ihrer Reihenfolge, Dauer und Häufigkeit bildet den Kern von Process Mining und zeigt, wie die Arbeit tatsächlich ausgeführt wird. Bezugsquelle Abgeleitet aus Statusänderungen in Tabellen wie VBUK/VBUP, Ereignissen zur Belegerstellung, beispielsweise in VBAK, LIKP oder VBRK, oder Änderungsprotokollen in den Tabellen CDHDR/CDPOS. Beispiele Retourenauftrag angelegtWareneingang gebuchtGutschrift angelegtPosition des Retourenauftrags abgeschlossen | |||
| Ereigniszeitpunkt EventTime | Das genaue Datum und die genaue Uhrzeit, zu denen die Aktivität stattgefunden hat. | ||
| Beschreibung Dieser Timestamp kennzeichnet den genauen Zeitpunkt, zu dem ein Geschäftsereignis eingetreten ist. Er wird für jede Aktivität im Prozess erfasst und bildet die chronologische Abfolge der Ereignisse innerhalb eines Case ab. Die Event Time ist für alle zeitbasierten Analysen entscheidend. Dazu gehören die Berechnung von Durchlaufzeiten zwischen Aktivitäten, die Identifizierung von Bottlenecks mit langen Wartezeiten sowie die Messung der gesamten Case-Dauer. Sie ermöglicht die Leistungsanalyse und Compliance-Prüfungen anhand von Service Level Agreements (SLAs). Warum das wichtig ist Dieser Timestamp ist entscheidend für die Berechnung aller Zeitdauern, die Analyse der Prozessleistung, die Identifizierung von Bottlenecks und das Verständnis des zeitlichen Ablaufs jedes Retouren-Case. Bezugsquelle Stammt aus verschiedenen Datums- und Zeitfeldern in den SAP-Tabellen. Für Erstellungsereignisse sind dies häufig die Felder ERDAT und ERZET, beispielsweise in VBAK. Für Änderungsereignisse werden UDATE und UTIME in der Tabelle CDHDR verwendet. Beispiele 2023-04-15T10:22:05Z2023-04-16T14:01:30Z2023-04-18T09:15:00Z | |||
| Retourenfall-ID ReturnCaseId | Die eindeutige Kennung für die Retourenanfrage einer Kundin oder eines Kunden, die alle zugehörigen Aktivitäten und Belege miteinander verknüpft. | ||
| Beschreibung Die Retourenfall-ID dient als Primärschlüssel zur Nachverfolgung des gesamten Lebenszyklus eines Retourenprozesses, vom Start bis zum Abschluss. Jede ID gehört zu einer bestimmten Retoure und umfasst alle zugehörigen Events, etwa Auftragserstellung, Lieferung, Prüfung und Gutschriftsverarbeitung. In der Prozessanalyse ist dieses Attribut grundlegend für die Erstellung der Prozesskarte. Das System kann einzelne Events zu durchgängigen Fallverläufen gruppieren. Dadurch lassen sich Prozessvarianten, Durchlaufzeiten und Engpässe für jeden einzelnen Retourenfall analysieren. Warum das wichtig ist Dies ist die zentrale Fallkennung, die alle Schritte eines Retourenverlaufs miteinander verbindet. Dadurch können Sie den durchgängigen Prozessablauf und die Leistung analysieren. Bezugsquelle In der Regel handelt es sich um die Nummer des Retourenauftrags aus dem Modul Sales and Distribution (SD). Sie steht in der Tabelle VBAK (Kopfdaten des Verkaufsbelegs) im Feld VBELN. Die Belegkategorie (VBAK-VBTYP) lautet bei Retouren „H“. Beispiele 600001236000045660000789 | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp, der angibt, wann die Daten für diesen Prozess zuletzt aktualisiert wurden. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion oder -aktualisierung. Es macht transparent, wie aktuell die analysierten Daten sind. Für die Analyse ist dies wichtig, um die Aktualität der Erkenntnisse einzuschätzen. Sie sehen, wie aktuell die Daten sind. Das beeinflusst die Aussagekraft der Ergebnisse, insbesondere bei der Überwachung laufender Abläufe. Warum das wichtig ist Zeigt die Aktualität der Daten an. So können Sie nachvollziehen, wie aktuell die Prozessanalyse ist und wann mit der nächsten Aktualisierung zu rechnen ist. Bezugsquelle Dies ist ein Metadatenattribut, das mit dem Ausführungszeitpunkt des Datenextraktionsjobs befüllt wird. Beispiele 2023-05-20T02:00:00Z2023-05-21T02:00:00Z | |||
| Quellsystem SourceSystem | Das System, aus dem die Daten extrahiert wurden. | ||
| Beschreibung Dieses Attribut kennzeichnet die Herkunft der Daten und ist in Umgebungen mit mehreren Systemen besonders wichtig. Es liefert den erforderlichen Kontext und unterstützt die Sicherstellung von Datenherkunft und Datenintegrität. Bei der Analyse dient es dazu, Daten zu segmentieren oder zu filtern, wenn Prozesse aus verschiedenen Quellsystemen zusammengeführt werden. Es bestätigt, dass die Ereignisse aus der erwarteten Anwendung stammen, in diesem Fall SAP ECC. Warum das wichtig ist Kennzeichnet die Herkunft der Daten. Das ist für Data Governance und Analysen über mehrere Unternehmenssysteme hinweg entscheidend. Bezugsquelle Dies ist ein statischer Wert, der während der Datenextraktion festgelegt wird, um die konkrete SAP-ECC-Instanz zu kennzeichnen, beispielsweise 'ECC_PROD_100'. Beispiele SAP_ECC_PRODSAPECC_FINANCE_200 | |||
| Angeforderter Erstattungsbetrag RequestedRefundAmount | Der erwartete Erstattungsbetrag, der in der Regel auf dem Nettowert der zurückgesendeten Artikel basiert. | ||
| Beschreibung Dieses Attribut stellt den ursprünglichen Geldwert der Retoure dar, wie er im Retourenauftrag erfasst wurde. Es dient als Grundlage für die Finanzanalyse und den Abgleich. Dieser Betrag wird mit dem „Tatsächlichen Erstattungsbetrag“ verglichen, um Abweichungen zu verfolgen. Er ist eine zentrale Kennzahl für das Dashboard „Erstattungsbetragsabweichungen verfolgen“. Die Analyse dieses Werts hilft dabei, die finanziellen Auswirkungen von Retouren zu überwachen und mögliche Probleme bei der Preis- oder Gutschriftsberechnung zu erkennen. Warum das wichtig ist Legt den ursprünglichen finanziellen Wert der Retoure fest. Dieser ist entscheidend, um finanzielle Abweichungen zu verfolgen und den Gesamtwert der zurückgesendeten Waren zu verstehen. Bezugsquelle Dieser Wert entspricht in der Regel dem Nettowert auf Positionsebene des Retourenauftrags. Er ist in der Tabelle VBAP im Feld NETWR zu finden. Beispiele 150.0049.991250.75 | |||
| Materialnummer MaterialNumber | Die eindeutige Kennung des zurückgesendeten Produkts. | ||
| Beschreibung Die Materialnummer oder SKU bezeichnet den konkreten Artikel, der von der Retoure betroffen ist. Dadurch wird eine detaillierte Analyse auf Produktebene möglich. Durch die Analyse der Retouren nach Materialnummer erkennen Unternehmen Produkte mit hohen Retourenquoten. Dies kann auf Qualitätsprobleme, ungenaue Beschreibungen oder Produktionsfehler hinweisen. Das Attribut ist für Dashboards wie 'Inventory Impact of Returns' wichtig und zeigt, wie verschiedene Produkte den Retourenprozess durchlaufen. Warum das wichtig ist Kennzeichnet die zurückgesendeten Produkte und macht mögliche Probleme bei der Qualitätskontrolle oder ungenaue Produktbeschreibungen sichtbar. Bezugsquelle Zu finden in der Tabelle für Vertriebsbelegpositionen VBAP, im Feld MATNR. Beispiele RM-1025FG-2050-BACC-5591 | |||
| Retourengrund ReturnReason | Der vom Kunden angegebene Grund für die Rücksendung des Artikels. | ||
| Beschreibung Dieses Attribut gibt anhand vordefinierter SAP-Grundcodes an, warum ein Produkt zurückgesendet wurde. Beispiele sind 'Beim Transport beschädigt', 'Falscher Artikel versendet' oder 'Passt nicht'. Für die Ursachenanalyse ist diese Dimension besonders wichtig. Wenn Analysten die Prozessübersicht oder KPIs nach Retourengrund filtern, erkennen sie, ob bestimmte Gründe mit längeren Bearbeitungszeiten, höheren Fehlerquoten bei der Prüfung oder bestimmten Prozessabweichungen verbunden sind. Diese Erkenntnisse können Verbesserungen in Produktqualität, Logistik oder Vertriebsprozessen anstoßen. Warum das wichtig ist Erklärt, warum Retouren entstehen. So können Sie durch Verbesserungen bei Produktqualität, Versand oder Produktbeschreibungen die Ursachen beheben und die Retourenquote senken. Bezugsquelle Zu finden in der Tabelle für Vertriebsbelegpositionen VBAP, im Feld ABGRU (Grund für die Ablehnung von Vertriebsbelegen). Beispiele 001 - Beschädigtes Produkt002 - Falsches Produkt005 - Zu spät eingetroffen | |||
| Retourenkanal ReturnChannel | Der Kanal, über den die Retoure initiiert wurde, zum Beispiel online, im Geschäft oder über ein Callcenter. | ||
| Beschreibung Dieses Attribut gibt die Herkunft oder den Eingangskanal der Retourenanfrage an. Es unterscheidet zwischen Retouren, die über ein Webportal, in einer Filiale oder durch einen Kundenservicemitarbeiter initiiert wurden. Die Segmentierung des Prozesses nach Retourenkanal ist entscheidend, um operative Unterschiede und den Ressourcenbedarf zu verstehen. Retouren in der Filiale können beispielsweise schneller geprüft werden, erfordern aber im Vergleich zu Online-Retouren andere Dokumentationsschritte. Dies ist eine wichtige Dimension für das Dashboard „Returns Process Throughput Trends“. Warum das wichtig ist Unterscheidet, wie Retouren initiiert werden. Dies wirkt sich häufig auf den Prozessablauf, den Ressourcenbedarf und die Durchlaufzeiten der verschiedenen Kanäle aus. Bezugsquelle Dies ist in SAP ECC häufig kein Standardfeld und muss möglicherweise aus einem kundenspezifischen Feld, beispielsweise in VBAK, bezogen oder aus anderen Daten wie der Verkaufsorganisation (VKORG) oder dem Vertriebsweg (VTWEG) abgeleitet werden. Ziehen Sie für die konkrete Implementierung die SAP-ECC-Dokumentation heran. Beispiele Online-PortalIm GeschäftCallcenter | |||
| Tatsächlicher Erstattungsbetrag ActualRefundAmount | Der endgültige Betrag, der dem Kunden gutgeschrieben und in den Finanzbelegen gebucht wurde. | ||
| Beschreibung Dieses Attribut stellt den endgültigen, bestätigten Erstattungsbetrag dar, der im Buchhaltungssystem verarbeitet und gebucht wurde. Aufgrund von Wiedereinlagerungsgebühren, Anpassungen auf Basis des Artikelzustands oder der Anwendung anderer Richtlinien kann dieser Betrag vom angeforderten Betrag abweichen. Dieses Attribut ist für das Dashboard „Erstattungsbetragsabweichungen verfolgen“ von zentraler Bedeutung. Der Vergleich mit dem angeforderten Betrag hilft, systematische Probleme bei der Erstattungsberechnung und im Genehmigungsprozess zu erkennen und die finanzielle Genauigkeit sicherzustellen. Warum das wichtig ist Stellt das endgültige finanzielle Ergebnis der Retoure dar. Der Vergleich mit dem angeforderten Betrag hilft, die Genauigkeit sicherzustellen und finanzielle Verluste zu erkennen. Bezugsquelle Wird aus dem Finanzbeleg bezogen, der mit der Gutschrift verknüpft ist. Der Wert ist für die relevante Sachkontenbuchung in der Regel in der Tabelle BSEG (Segment des Buchhaltungsbelegs), Feld WRBTR (Betrag in Belegwährung), zu finden. Beispiele 150.0045.001200.75 | |||
| Verarbeitende Person ProcessingAgent | Die Benutzer-ID der Person, die die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut erfasst den Benutzernamen der Person, die für die Ausführung eines bestimmten Prozessschritts verantwortlich ist, etwa für die Erstellung des Retourenauftrags oder die Buchung des Wareneingangs. Häufig wird diese Person als 'Changed By' oder 'Created By' bezeichnet. Die Analyse nach verarbeitender Person ist für das Leistungsmanagement und die Ressourcenanalyse wichtig. Sie hilft dabei, besonders leistungsstarke Mitarbeitende zu erkennen, Personen mit zusätzlichem Schulungsbedarf zu identifizieren und die Arbeitslast im Team zu verteilen. In Dashboards wie 'Agent Return Processing Performance' wird sie verwendet, um Durchlaufzeiten und Durchsatz zu vergleichen. Warum das wichtig ist Erfasst die Beteiligung einzelner Benutzer und ermöglicht die Analyse der Teamleistung, der Arbeitslastverteilung sowie des Schulungsbedarfs und bewährter Vorgehensweisen. Bezugsquelle Typischerweise in Feldern wie ERNAM (Created by) oder AENAM (Changed by) in Kopftabellen wie VBAK, LIKP und VBRK zu finden. Für Änderungsereignisse wird USERNAME in CDHDR verwendet. Beispiele CBURNSDSCRANTONJHALPERT | |||
| Abweichung des Erstattungsbetrags RefundAmountDiscrepancy | Die berechnete Differenz zwischen dem tatsächlichen und dem angeforderten Erstattungsbetrag. | ||
| Beschreibung Diese berechnete Kennzahl quantifiziert die finanzielle Differenz zwischen dem ursprünglich im Retourenauftrag angeforderten Betrag und dem Betrag, der schließlich in der Gutschrift ausgestellt wurde. Ein positiver Wert kann auf eine Teilerstattung hindeuten. Ein negativer Wert ist ungewöhnlich, könnte jedoch auf eine Überzahlung hinweisen. Dieses Attribut ist die zentrale Kennzahl für das Dashboard „Erstattungsbetragsabweichungen verfolgen“. Es hilft, Fälle mit finanziellen Abweichungen schnell zu erkennen und zu analysieren. Mögliche Ursachen sind die Bewertung des Artikelzustands, Wiedereinlagerungsgebühren oder Fehler. Die Überwachung unterstützt die finanzielle Kontrolle und die Einhaltung von Richtlinien. Warum das wichtig ist Misst finanzielle Abweichungen im Erstattungsprozess direkt und hilft, Richtlinienverstöße, Bearbeitungsfehler oder finanzielle Verluste zu erkennen. Bezugsquelle Berechnetes Feld: ActualRefundAmount - RequestedRefundAmount. Beispiele 0.00-4.99-50.00 | |||
| Buchungskreis CompanyCode | Die juristische Einheit oder das Unternehmen, das für die Transaktion verantwortlich ist. | ||
| Beschreibung Der Buchungskreis stellt in SAP eine eigenständige Buchhaltungseinheit dar. Alle Finanztransaktionen, einschließlich Retouren und Erstattungen, werden einem bestimmten Buchungskreis zugeordnet. Dieses Attribut ist für die Finanzberichterstattung und die Segmentierung des Prozesses in multinationalen Organisationen oder Unternehmen mit mehreren rechtlichen Einheiten unerlässlich. Die Analyse nach Buchungskreis ermöglicht den Vergleich der Leistung des Retourenprozesses zwischen verschiedenen juristischen Einheiten des Unternehmens. Warum das wichtig ist Ermöglicht das Filtern und Vergleichen von Retourenprozessen zwischen verschiedenen juristischen Einheiten einer Organisation. Dies ist für die Finanzanalyse von zentraler Bedeutung. Bezugsquelle Zu finden in der Tabelle VBAK, Kopf des Verkaufsbelegs, im Feld BUKRS_VF (Buchungskreis für die Fakturierung). Beispiele 10002000US01 | |||
| Einhaltung der Retourenrichtlinie ReturnPolicyAdherence | Ein Kennzeichen dafür, ob die Retoure allen definierten Geschäftsregeln und Richtlinien entspricht. | ||
| Beschreibung Dieses berechnete boolesche Attribut zeigt an, ob ein Retourenfall gemäß den standardmäßigen, vorgegebenen Unternehmensrichtlinien bearbeitet wurde. Die Logik kann mehrere Bedingungen prüfen, etwa ob die Retoure innerhalb des zulässigen Zeitraums initiiert wurde, ob der Ursachencode für das Produkt gültig ist oder ob für eine Ausnahme eine Genehmigung durch einen Manager vorliegt. Dieses Attribut bildet die Grundlage für das Dashboard „Compliance der Genehmigungsrichtlinie für Retouren“. Es ermöglicht die direkte Messung der Compliance-Rate und hilft zu erkennen, welche Richtlinien am häufigsten umgangen werden. Dadurch lassen sich gezielte Prozessverbesserungen oder Schulungen ableiten. Warum das wichtig ist Misst die Einhaltung von Geschäftsregeln, unterstützt die konsistente Durchsetzung von Richtlinien und identifiziert Fälle, die eine besondere Prüfung oder Genehmigung erfordern. Bezugsquelle Dies ist ein abgeleitetes Attribut, das auf einer Reihe von Geschäftsregeln basiert. Beispiel: (Return Initiation Date - Original Purchase Date) <= 30 days AND ReturnReason IS NOT NULL. Beispiele truefalse | |||
| Kunden-ID CustomerId | Die eindeutige Kennung des Kunden, der die Retoure veranlasst. | ||
| Beschreibung Dieses Attribut identifiziert den konkreten Kunden, der das Produkt zurücksendet, in der SAP-Terminologie die „Sold-to Party“. Es verknüpft die Retourentransaktion mit den Stammdaten des Kunden. Die Analyse nach Kunden-ID hilft, Kunden mit häufigen Retouren zu identifizieren. Dies kann auf Unzufriedenheit oder eine mögliche missbräuchliche Nutzung von Retourenrichtlinien hinweisen. In Verbindung mit Kundensegmentierungsdaten lässt sich außerdem untersuchen, ob bestimmte Kundengruppen ein anderes Retourenverhalten oder andere Prozesserfahrungen aufweisen. Warum das wichtig ist Verknüpft Retouren mit bestimmten Kunden und ermöglicht die Analyse des Kundenverhaltens, die Identifizierung wiederkehrender Retouren sowie die Bewertung der Auswirkungen auf Kundenbeziehungen. Bezugsquelle Zu finden in der Tabelle VBAK für den Kopf des Verkaufsbelegs, im Feld KUNNR (Sold-to Party). Beispiele CUST-100432CUST-203991CUST-831102 | |||
| Nummer der Gutschrift CreditMemoNumber | Die eindeutige Kennung des für die Erstattung ausgestellten Gutschriftsbelegs. | ||
| Beschreibung Die Gutschrift ist der offizielle Fakturabeleg in SAP, der die an den Kunden zu zahlende Erstattung formal dokumentiert. Diese Nummer identifiziert den Finanzbeleg eindeutig. Dieses Attribut ist für den finanziellen Abgleich und die Nachverfolgung des Prozesses von der operativen Retoure bis zur finanziellen Abwicklung unerlässlich. Es stellt einen wichtigen Meilenstein im Prozess dar und dient dazu, zugehörige Buchhaltungsbelege für Attribute wie den „Tatsächlichen Erstattungsbetrag“ zu finden. Warum das wichtig ist Stellt eine direkte Verbindung zu dem Finanzbeleg her, der die Erstattung an den Kunden autorisiert. Dies ist für die Finanzprüfung und den Abgleich unerlässlich. Bezugsquelle Die Gutschrift ist ein Fakturabeleg. Ihre Nummer ist in der Tabelle VBRK (Fakturabeleg: Kopfdaten), Feld VBELN, zu finden. Die Verknüpfung erfolgt über den Belegfluss des Retourenauftrags. Beispiele 900011229000334490005566 | |||
| SLA-konform IsSLACompliant | Ein Kennzeichen dafür, ob die Erstattung innerhalb des vereinbarten Service Level Agreements (SLA) verarbeitet wurde. | ||
| Beschreibung Dies ist ein berechnetes boolesches Attribut, das das tatsächliche Datum der Aktivität „Erstattung verarbeitet“ mit dem „Zieldatum für das Erstattungs-SLA“ vergleicht. Der Wert ist true, wenn die Erstattung fristgerecht abgeschlossen wurde, und andernfalls false. Dieses Attribut vereinfacht Analyse und Berichterstattung, da es für die SLA-Leistung jedes Falls ein eindeutiges binäres Ergebnis liefert. Es wird zur Berechnung der Gesamtrate „SLA-Konformität der Erstattungsbearbeitung“ verwendet und ermöglicht das einfache Filtern und Analysieren nicht konformer Fälle. Warum das wichtig ist Liefert für jeden Fall einen eindeutigen binären Indikator für die SLA-Leistung und vereinfacht dadurch die Überwachung und Berichterstattung zur Compliance. Bezugsquelle Dies ist ein berechnetes Attribut. Die Logik lautet: 'Refund Processed' EventTime <= RefundSLATargetDate. Beispiele truefalse | |||
| Status des Retourenauftrags ReturnOrderStatus | Der Gesamtbearbeitungsstatus des Retourenauftragsfalls. | ||
| Beschreibung Dieses Attribut zeigt den aktuellen Status des Retourenfalls, beispielsweise „Offen“, „In Bearbeitung“ oder „Abgeschlossen“. Es wird aus der Kombination der Status auf Kopf- oder Positionsebene des Verkaufsbelegs abgeleitet. Für die Analyse eignet sich dieses Attribut, um Fälle zu filtern und sich auf aktive oder abgeschlossene Retouren zu konzentrieren. Es unterstützt die Überwachung der Gesamtarbeitslast und des Fortschritts offener Fälle und liefert ein übergeordnetes Ergebnis für jeden Retourenprozess. Warum das wichtig ist Liefert einen Überblick darüber, an welcher Stelle des Lebenszyklus sich ein Fall befindet. Dadurch lassen sich offene, laufende oder abgeschlossene Retouren filtern und analysieren. Bezugsquelle Wird aus den Statusfeldern der Tabellen VBUK (Kopfstatus) und VBUP (Positionsstatus) abgeleitet. VBUK-GBSTK ist beispielsweise der Gesamtbearbeitungsstatus des Belegs. Beispiele OffenIn BearbeitungAbgeschlossen | |||
| Ursprünglicher Verkaufsbeleg OriginalSalesDocument | Die Nummer des ursprünglichen Verkaufsauftrags, auf den sich die Retoure bezieht. | ||
| Beschreibung Dieses Attribut stellt eine direkte Verbindung zum ursprünglichen Kauf des Kunden her. Es ist ein Referenzbeleg, der die Retoure mit den Details der ursprünglichen Transaktion verknüpft. Diese Verbindung ist für eine detaillierte Analyse besonders wertvoll. Sie ermöglicht es, die Gründe für Retouren aus bestimmten Aufträgen zu untersuchen, ursprüngliche Preise und Konditionen zu prüfen und den vollständigen Lebenszyklus vom Kundenauftrag bis zur Retoure zu verstehen. So lässt sich beispielsweise feststellen, ob Produkte aus bestimmten Kampagnen oder Vertriebskanälen häufiger retourniert werden. Warum das wichtig ist Verknüpft die Retoure mit dem ursprünglichen Verkauf und ermöglicht so eine durchgängige Sicht auf die Kundentransaktion sowie eine detaillierte Ursachenanalyse. Bezugsquelle Diese Referenz wird auf Positionsebene des Retourenauftrags gespeichert. Sie ist in der Tabelle VBAP im Feld VGBEL (Belegnummer des Referenzbelegs) zu finden. Beispiele 100034561000987110012345 | |||
| Werk Plant | Der physische Standort oder die Einrichtung, an dem beziehungsweise in der die zurückgesendete Ware angenommen und bearbeitet wird. | ||
| Beschreibung Das Werk bezeichnet in SAP einen physischen Standort, beispielsweise ein Lager oder Verteilzentrum, an dem Waren bearbeitet werden. Bei Retouren handelt es sich in der Regel um den Standort, an dem der Artikel angenommen und geprüft wird. Die Analyse nach Werk hilft, Leistungsunterschiede zwischen verschiedenen Einrichtungen zu erkennen. Sie kann zeigen, welche Lager Artikel effizienter prüfen oder einen höheren Durchsatz erzielen, und unterstützt damit das Dashboard „Durchsatz und Effizienz der Artikelprüfung“. Warum das wichtig ist Identifiziert den physischen Standort, an dem die Retoure bearbeitet wird, und ermöglicht den Leistungsvergleich zwischen verschiedenen Lagern oder Verteilzentren. Bezugsquelle Auf Positionsebene des Retourenauftrags in der Tabelle VBAP, Feld WERKS. Beispiele PL01WH02DC05 | |||
| Zieldatum für das Erstattungs-SLA RefundSLATargetDate | Das Datum, bis zu dem die Erstattung gemäß den Service Level Agreements voraussichtlich verarbeitet wird. | ||
| Beschreibung Dieses Attribut definiert die Frist für den Abschluss des Erstattungsprozesses eines bestimmten Retourenfalls. Es wird in der Regel anhand von Geschäftsregeln berechnet, beispielsweise „5 Werktage ab Wareneingang“. Dieses Zieldatum dient als Vergleichsmaßstab für die tatsächliche Leistung. Es ist die zentrale Grundlage für das Dashboard „SLA-Konformität der Erstattungsbearbeitung“. Damit kann das Unternehmen die Einhaltung von Zusagen gegenüber Kunden überwachen und Fälle erkennen, bei denen eine SLA-Verletzung droht. Warum das wichtig ist Legt das Leistungsziel für die Bearbeitung von Erstattungen fest. So kann das Unternehmen die SLA-Konformität messen und berichten sowie überfällige Fälle priorisieren. Bezugsquelle Dies ist in der Regel kein Standardfeld in SAP und muss anhand von Geschäftsregeln abgeleitet werden. Es könnte aus einem relevanten Datumsfeld, beispielsweise dem Wareneingangsdatum aus MKPF, zuzüglich einer konfigurierten Dauer berechnet werden. Ziehen Sie die SAP-ECC-Dokumentation oder die fachlichen Anforderungen heran. Beispiele 2023-04-25T23:59:59Z2023-04-28T23:59:59Z2023-05-02T23:59:59Z | |||
Aktivitäten der Retouren- und Rückerstattungsabwicklung
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Gutschrift an FI gebucht | Die Gutschrift wird an die Finanzbuchhaltung übergeben und dadurch zu einer offiziellen Forderungsbuchung. Dieser Schritt löst die eigentliche Erstattung an die Kundin oder den Kunden aus. | ||
| Warum das wichtig ist Diese Aktivität markiert den Zeitpunkt, an dem das Unternehmen die Erstattung finanziell erfasst. Verzögerungen zwischen Erstellung und Buchung der Gutschrift können die tatsächliche Auszahlung an die Kundin oder den Kunden verzögern. Bezugsquelle Dies ist ein abgeleitetes Event. Es wird erkannt, wenn der Buchungsstatus im Fakturabelegkopf (VBRK-RFBSK) auf „C“ aktualisiert wird (Buchungsbeleg wurde erstellt). Das tatsächliche Erstellungsdatum des Buchhaltungsbelegs steht in der Tabelle BKPF. Erfassen Ermitteln Sie den Timestamp, zu dem VBRK-RFBSK auf „C“ gesetzt wird, oder verwenden Sie das Erstellungsdatum (CPUDT) des verknüpften Buchhaltungsbelegs in BKPF. Ereignistyp inferred | |||
| Gutschrift angelegt | Ein Fakturabeleg, die Gutschrift, wird erstellt, um die finanzielle Gutschrift für die Kundin oder den Kunden zu autorisieren. Dieser offizielle Finanzbeleg legt den Erstattungsbetrag fest. | ||
| Warum das wichtig ist Dies ist ein wichtiger finanzieller Meilenstein. Die Analyse der Zeit bis zur Erstellung der Gutschrift zeigt Verzögerungen bei der Verarbeitung von Finanzbelegen nach Wareneingang und Prüfung. Bezugsquelle Dies ist ein explizites Event in der Tabelle VBRK (Kopf des Fakturabelegs). Das Erstellungsdatum steht in VBRK-ERDAT. Die Gutschrift ist im Belegfluss mit dem Retourenauftrag oder der Gutschriftsanforderung verknüpft. Erfassen Verwenden Sie den Erstellungs-Timestamp (ERDAT) aus der Tabelle VBRK für den relevanten Fakturabeleg. Ereignistyp explicit | |||
| Retourenauftrag abgeschlossen | Diese Aktivität markiert das Ende des Retourenprozesses aus Sicht von Vertrieb und Distribution. Sie tritt ein, wenn alle Positionen des Retourenauftrags vollständig bearbeitet und abgeschlossen sind. | ||
| Warum das wichtig ist Dies ist das primäre End-Event des Prozesses. Die Messung der Zeit von „Return Order Created“ bis zu dieser Aktivität ergibt die durchgängige Durchlaufzeit des Retourenfalls. Bezugsquelle Dies ist ein aus Statustabellen abgeleitetes Event. Es wird erfasst, wenn der Gesamtstatus des Verkaufsbelegkopfs (VBUK-GBSTK) auf „C“ aktualisiert wird (vollständig bearbeitet). Erfassen Ermitteln Sie den Timestamp aus Änderungsbelegen (CDHDR/CDPOS), zu dem sich das Kopfstatusfeld VBUK-GBSTK auf „C“ ändert. Ereignistyp inferred | |||
| Retourenauftrag angelegt | Diese Aktivität markiert den Beginn des Retourenprozesses, wenn eine Kundin oder ein Kunde die Rückgabe eines Produkts anfordert. Sie wird erfasst, sobald in SAP ECC ein neues Verkaufsdokument des Typs „Return“, beispielsweise RE, angelegt wird. | ||
| Warum das wichtig ist Dies ist das primäre Start-Event des Retourenprozesses. Die Zeit von dieser Aktivität bis zu weiteren Aktivitäten hilft dabei, die gesamte Durchlaufzeit zu messen und Verzögerungen in der Anfangsbearbeitung zu erkennen. Bezugsquelle Dies ist ein explizites Event in der Tabelle VBAK (Kopf des Verkaufsbelegs). Der Erstellungs-Timestamp wird für die entsprechende Verkaufsbelegnummer (VBAK-VBELN) mit dem Auftragstyp VBAK-AUART = „RE“ in VBAK-ERDAT und VBAK-ERZET gespeichert. Erfassen Verwenden Sie den Erstellungs-Timestamp (ERDAT, ERZET) aus der Tabelle VBAK für Verkaufsbelege des Typs „RE“. Ereignistyp explicit | |||
| Verwendungsentscheid getroffen | Nach der Prüfung trifft eine Qualitätsfachkraft oder prüfende Person eine formale Entscheidung über den Zustand des retournierten Artikels. Diese Entscheidung bestimmt den weiteren Prozess, etwa Wiedereinlagerung, Verschrottung oder Reparatur. | ||
| Warum das wichtig ist Diese Aktivität ist entscheidend, um die Effizienz und Ergebnisse der Prüfung zu verstehen. Die Entscheidung wirkt sich direkt auf den Erstattungsbetrag und die Bestandsverwaltung aus. Bezugsquelle Wenn SAP QM eingesetzt wird, ist dies ein explizites Event in der Tabelle QAVE (Verwendungsentscheid der Prüfverarbeitung). Der Entscheidungszeitpunkt wird in QAVE-VDATUM gespeichert. Die Verbindung zur Lieferung befindet sich in der Tabelle QALS. Erfassen Verwenden Sie das Datum des Verwendungsentscheids (VDATUM) aus der Tabelle QAVE, verknüpft über das Prüflos (QALS-PRUEFLOS). Ereignistyp explicit | |||
| Wareneingang gebucht | Diese Aktivität tritt ein, wenn der retournierte physische Artikel im Lager oder Bearbeitungszentrum eingeht. Erfasst wird sie durch die Buchung eines Warenbewegungsbelegs zur Retourenlieferung. | ||
| Warum das wichtig ist Dies ist ein wichtiger Meilenstein, der anzeigt, dass das Unternehmen den retournierten Artikel übernommen hat. Er bildet den Ausgangspunkt für die physische Prüfung und wirkt sich auf die Bestandsgenauigkeit aus. Bezugsquelle Dieses Event kann aus dem Warenbewegungsstatus der Position der Retourenlieferung in der Tabelle VBUP abgeleitet werden, beispielsweise WBSTA = „C“. Der genaue Timestamp steht im Kopf des Materialbelegs (MKPF-BUDAT) für den entsprechenden Wareneingang. Erfassen Ermitteln Sie das Buchungsdatum (BUDAT) aus der Tabelle MKPF für den mit der Retourenlieferung verknüpften Materialbeleg. Ereignistyp inferred | |||
| Gutschrift ausgeglichen | Der offene Gutschriftsposten in der Debitorenbuchhaltung wird ausgeglichen, normalerweise durch eine Zahlung an die Kundin oder den Kunden. Dieses Event markiert den endgültigen finanziellen Abschluss der Erstattung. | ||
| Warum das wichtig ist Diese Aktivität bestätigt den Geldabfluss und schließt die finanzielle Seite des Prozesses ab. Aus Sicht der Kundin oder des Kunden ist dies das tatsächliche Ende der Erstattung. Bezugsquelle Dies ist ein explizites Event aus dem FI-Modul. Das Ausgleichsdatum des Buchhaltungsbelegs wird für die entsprechende Kundenposition in der Tabelle BSEG (BSEG-AUGDT) gespeichert. Erfassen Verwenden Sie das Ausgleichsdatum (AUGDT) aus der Tabelle BSEG oder BSAD für den mit der Gutschrift verknüpften Buchhaltungsbeleg. Ereignistyp explicit | |||
| Gutschriftsanforderung angelegt | Eine Gutschriftsanforderung wird angelegt, um den Bedarf für eine Erstattung formal zu dokumentieren. In vielen Konfigurationen dient der Retourenauftrag selbst als Gutschriftsanforderung. | ||
| Warum das wichtig ist Dies ist der formale Beginn des finanziellen Abwicklungsteils im Retourenprozess. Das Event löst nachfolgende finanzielle Genehmigungen und die Erstellung von Belegen aus. Bezugsquelle Dies kann ein explizites Event in VBAK für einen Verkaufsbeleg des Typs „Credit Memo Request“, beispielsweise CR, sein. Alternativ kann es sich um dasselbe Event wie „Return Order Created“ handeln, wenn der Auftragstyp auf auftragsbezogene Fakturierung eingestellt ist. Erfassen Verwenden Sie den Erstellungs-Timestamp (ERDAT) aus VBAK für den Belegtyp „CR“ oder verwenden Sie das Event zur Erstellung des Retourenauftrags erneut. Ereignistyp explicit | |||
| Position des Retourenauftrags abgelehnt | Eine bestimmte Position des Retourenauftrags wird entweder bei der ersten Prüfung oder nach der Inspektion abgelehnt. Für diese Position findet keine weitere Bearbeitung, etwa eine Erstattung, statt. | ||
| Warum das wichtig ist Die Analyse von Ablehnungen hilft, ungültige Retourenanfragen zu erkennen, und kann in die Kommunikation von Kundenrichtlinien einfließen. Es handelt sich um einen wichtigen Prozesspfad, der nicht zu einer Erstattung führt. Bezugsquelle Dies ist ein abgeleitetes Event. Es wird normalerweise erfasst, wenn in der Tabelle VBAP ein eindeutiger Code für den „Reason for Rejection“ der Position gesetzt wird (VBAP-ABGRU). Der Timestamp muss aus Änderungsprotokollen stammen. Erfassen Ermitteln Sie den Timestamp aus Änderungsbelegen (CDHDR/CDPOS), zu dem das Feld VBAP-ABGRU für eine Retourenposition befüllt wird. Ereignistyp inferred | |||
| Position des Retourenauftrags abgeschlossen | Eine einzelne Position des Retourenauftrags wird als vollständig bearbeitet markiert. Dies geschieht normalerweise, nachdem alle logistischen und finanziellen Folgebelege für diese Position abgeschlossen wurden. | ||
| Warum das wichtig ist Die Nachverfolgung auf Positionsebene zeigt, welche Produkte oder Retourengründe die längsten Verzögerungen verursachen. Dadurch erhalten Sie eine detailliertere Sicht auf den Prozessabschluss. Bezugsquelle Dies ist ein aus Statustabellen abgeleitetes Event. Es wird erfasst, wenn der Gesamtstatus der Verkaufsbelegposition (VBUP-GBSTK) auf „C“ aktualisiert wird (vollständig bearbeitet). Erfassen Ermitteln Sie den Timestamp aus Änderungsbelegen (CDHDR/CDPOS), zu dem sich das Positionsstatusfeld VBUP-GBSTK auf „C“ ändert. Ereignistyp inferred | |||
| Retourenlieferung angelegt | Zur Steuerung des physischen Eingangs der retournierten Waren wird ein Lieferbeleg erstellt. Dieses Event zeigt, dass der logistische Prozess der Retoure begonnen hat. | ||
| Warum das wichtig ist Diese Aktivität erfasst den Übergang von der administrativen Bearbeitung zur physischen Logistik. Verzögerungen an dieser Stelle können die Lagerplanung und die gesamte Retourendurchlaufzeit beeinträchtigen. Bezugsquelle Dies ist ein explizites Event in der Tabelle LIKP (Lieferkopf). Der Erstellungs-Timestamp steht in LIKP-ERDAT. Die Verbindung zum Ursprungs-Retourenauftrag befindet sich in der Tabelle LIPS (LIPS-VGBEL). Erfassen Verwenden Sie den Erstellungs-Timestamp (ERDAT) aus der Tabelle LIKP für die mit dem Retourenauftrag verbundene Lieferung. Ereignistyp explicit | |||
| Sperre des Retourenauftrags entfernt | Diese Aktivität steht für die Genehmigung der Retourenanfrage und ermöglicht die Weiterbearbeitung. In der Regel wird sie durch eine Änderung des Belegstatus oder die Entfernung einer Liefer- oder Fakturasperre erfasst. | ||
| Warum das wichtig ist Diese Aktivität ist ein wichtiger Meilenstein der Genehmigung. Die Messung der Zeit bis zu diesem Schritt zeigt Engpässe bei Autorisierung und Genehmigung der Retoure. Bezugsquelle Dies ist ein abgeleitetes Event aus Änderungsprotokollen des Verkaufsbelegs. Prüfen Sie die Tabellen CDHDR und CDPOS auf Änderungen an Sperrfeldern in VBAK oder VBAP beziehungsweise an Statusfeldern in VBUK/VBUP. Erfassen Ermitteln Sie den Timestamp aus den Tabellen der Änderungsbelege (CDHDR/CDPOS), zu dem ein relevanter Sperrstatus entfernt wurde. Ereignistyp inferred | |||
Anleitungen zur Extraktion
Schritte
- ABAP-Programm erstellen: Verwenden Sie den Transaktionscode
SE38, um ein neues ausführbares ABAP-Programm zu erstellen, beispielsweiseZ_PM_RETURN_EXTRACTION. Geben Sie einen aussagekräftigen Titel an und speichern Sie das Programm als lokales Objekt oder in einem Entwicklungspaket. - Selektionsbild definieren: Definieren Sie im Programm ein Selektionsbild, über das Benutzer die Daten filtern können. Wichtige Filter sind der Erstellungszeitraum für Retourenaufträge (
S_ERDAT), die Belegart für Retouren (S_AUART, beispielsweise 'RE') und der Buchungskreis (P_BUKRS). - Datenstrukturen definieren: Erstellen Sie einen lokalen Strukturtyp, der dem erforderlichen Event-Log-Format entspricht. Die Struktur sollte die Felder
ReturnCaseId,ActivityName,EventTime,SourceSystem,LastDataUpdate,ProcessingAgent,ReturnReasonund weitere erforderliche Attribute enthalten. - Logik für die Datenselektion implementieren: Schreiben Sie die zentrale ABAP-Logik, um Daten für die 12 erforderlichen Aktivitäten auszuwählen. Dazu werden verschiedene SAP-Tabellen wie VBAK, VBAP, LIKP, VBRK, BKPF, CDHDR und CDPOS abgefragt. Verwenden Sie die Belegfluss-Tabelle VBFA, um verbundene Belege wie Lieferungen und Gutschriften mit dem ursprünglichen Retourenauftrag zu verknüpfen.
- 'Return Order Created' extrahieren: Wählen Sie Datensätze aus den Tabellen
VBAKundVBAPanhand der Kriterien des Selektionsbilds aus. Die Vertriebsbelegnummer (VBAK-VBELN) dient alsReturnCaseId. - Statusänderungen und wichtige Ereignisse extrahieren: Für Aktivitäten wie 'Return Order Block Removed' oder 'Return Order Item Rejected' fragen Sie die Änderungsbelegtabelle (
CDHDR,CDPOS) oder Statusfelder in Tabellen wieVBAP(ABGRU) ab. Für nachgelagerte logistische und finanzielle Aktivitäten wählen Sie Daten aus Tabellen wieLIKP,MKPF,VBRKundBKPFaus. Verwenden Sie VBFA, um sicherzustellen, dass diese mit den ursprünglichen Retourenaufträgen verknüpft sind. - Event-Log-Tabelle befüllen: Erstellen Sie für jede abgerufene Aktivität einen neuen Datensatz in einer internen Tabelle, die mit Ihrer Event-Log-Struktur definiert wurde. Übertragen Sie die Daten aus den SAP-Quelltabellen in die entsprechenden Felder. Ordnen Sie beispielsweise
VBAK-ERNAMdem FeldProcessingAgentsowieVBAK-ERDATundVBAK-ERZETdem FeldEventTimezu. - Aktivitätsdaten zusammenführen: Stellen Sie sicher, dass jede SELECT-Anweisung für eine Aktivität ihre Ergebnisse an dieselbe zentrale interne Tabelle anhängt. So entsteht eine flache Zieldatei, in der jede Zeile ein Ereignis darstellt.
- Timestamps und Systeminformationen verarbeiten: Verwenden Sie die Systemfelder
SY-DATUMundSY-UZEIT, um den TimestampLastDataUpdatefür jede Zeile zu befüllen. Verwenden SieSY-SYSIDfür das FeldSourceSystem. - Ausgabefunktion implementieren: Ergänzen Sie eine Funktion zur Anzeige der Ergebnisse in einem ALV Grid (SAP List Viewer) für die Online-Analyse, beispielsweise mit Funktionsbausteinen wie
REUSE_ALV_GRID_DISPLAY. Bieten Sie außerdem die Möglichkeit, die finale interne Tabelle als CSV- oder Textdatei auf den lokalen Rechner des Benutzers herunterzuladen. - Ausführen und exportieren: Starten Sie das Programm über
SE38. Geben Sie die gewünschten Selektionskriterien ein und führen Sie es aus. Sobald die Daten angezeigt oder verarbeitet wurden, verwenden Sie die Exportfunktion des Programms, um die Event-Log-Datei zu speichern. Speichern Sie die Datei in einem mit ProcessMind kompatiblen Format, üblicherweise als CSV mit Kopfzeile.
Konfiguration
- Datumsbereich: Geben Sie auf dem Selektionsbild einen Zeitraum für das Erstellungsdatum des Retourenauftrags an. Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten, um Datenvolumen und verwertbare Prozesserkenntnisse auszubalancieren.
- Retourenbelegart: Filtern Sie nach der in Ihrem System verwendeten Vertriebsbelegart für Retouren, beispielsweise 'RE' für Retouren oder 'CR' für eine Gutschriftsanforderung. Dieser Filter ist entscheidend, um den richtigen Prozess zu isolieren. Geben Sie die Werte in der Selektionsoption
S_AUARTein. - Buchungskreis: Geben Sie den relevanten Buchungskreis (
P_BUKRS) an, um die Daten auf eine bestimmte rechtliche Einheit zu begrenzen. Das ist in Umgebungen mit mehreren Unternehmen besonders wichtig. - Voraussetzungen: Der Benutzer, der das Programm ausführt, benötigt Berechtigungen für
SE38(Programmausführung) sowie Zugriff auf die zugrunde liegenden SD-, MM- und FI-Tabellen, beispielsweise VBAK, LIKP, VBRK, BKPF und CDHDR. Für die Entwicklung ist eine ABAP-Entwicklerrolle erforderlich. - Leistung: Bei sehr großen Datenmengen über mehrere Jahre kann das Programm lange Laufzeiten haben. Erwägen Sie, es als Hintergrundjob (
SM36) auszuführen und die Ausgabe in das Dateisystem des Applikationsservers zu schreiben, statt sie online anzuzeigen.
a Beispielabfrage abap
REPORT Z_PM_RETURN_EXTRACTION.
" =======================================================================
" DATA DECLARATIONS
" =======================================================================
TYPES: BEGIN OF ty_event_log,
returncaseid TYPE vbeln_va,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE sysysid,
lastdataupdate TYPE timestamp,
processingagent TYPE ernam,
returnreason TYPE augru,
materialnumber TYPE matnr,
returnchannel TYPE string, " Placeholder, needs custom logic
requestedrefundamount TYPE netwr,
actualrefundamount TYPE netwr,
END OF ty_event_log.
DATA: lt_event_log TYPE TABLE OF ty_event_log,
ls_event_log TYPE ty_event_log.
DATA: lv_timestamp TYPE timestamp,
lv_last_update TYPE timestamp.
" =======================================================================
" SELECTION SCREEN
" =======================================================================
SELECT-OPTIONS: s_erdat FOR sy-datum OBLIGATORY,
s_auart FOR vbak-auart.
PARAMETERS: p_bukrs TYPE bukrs OBLIGATORY.
" =======================================================================
" MAIN LOGIC
" =======================================================================
START-OF-SELECTION.
" Set static values for the extraction run
GET TIME STAMP FIELD lv_last_update.
" 1. Return Order Created & 6. Credit Memo Request Created
" Note: In many SAP standard processes, the Return Order itself acts as the Credit Memo Request.
SELECT h~vbeln, h~erdat, h~erzet, h~ernam, h~augru, i~matnr, i~netwr
INTO TABLE @DATA(lt_return_orders)
FROM vbak AS h
INNER JOIN vbap AS i ON h~vbeln = i~vbeln
WHERE h~erdat IN @s_erdat
AND h~auart IN @s_auart
AND h~bukrs_vf = @p_bukrs.
LOOP AT lt_return_orders INTO DATA(ls_return_order).
" Activity: Return Order Created
ls_event_log-returncaseid = ls_return_order-vbeln.
ls_event_log-activityname = 'Return Order Created'.
CONVERT DATE ls_return_order-erdat TIME ls_return_order-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_return_order-ernam.
ls_event_log-returnreason = ls_return_order-augru.
ls_event_log-materialnumber = ls_return_order-matnr.
ls_event_log-requestedrefundamount = ls_return_order-netwr.
APPEND ls_event_log TO lt_event_log.
" Activity: Credit Memo Request Created
ls_event_log-activityname = 'Credit Memo Request Created'.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
IF lt_return_orders IS NOT INITIAL.
" 2. Return Order Block Removed (Example for Delivery Block)
SELECT objectid, udate, utime, username
FROM cdhdr
INTO TABLE @DATA(lt_block_changes)
FOR ALL ENTRIES IN @lt_return_orders
WHERE objectclas = 'VERKBELEG'
AND objectid = @lt_return_orders-vbeln
AND tcode = 'VA02'.
IF sy-subrc = 0.
SELECT objectid, fname, value_new
INTO TABLE @DATA(lt_cdpos_block)
FROM cdpos
FOR ALL ENTRIES IN @lt_block_changes
WHERE objectclas = @lt_block_changes-objectclas
AND objectid = @lt_block_changes-objectid
AND changenr = @lt_block_changes-changenr
AND tabname = 'VBAK'
AND fname = 'LIFSK' " Delivery Block field
AND value_new = ''.
LOOP AT lt_cdpos_block INTO DATA(ls_cdpos_block).
READ TABLE lt_block_changes INTO DATA(ls_block_change) WITH KEY objectid = ls_cdpos_block-objectid.
IF sy-subrc = 0.
ls_event_log-returncaseid = ls_cdpos_block-objectid.
ls_event_log-activityname = 'Return Order Block Removed'.
CONVERT DATE ls_block_change-udate TIME ls_block_change-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_block_change-username.
CLEAR: ls_event_log-returnreason, ls_event_log-materialnumber, ls_event_log-requestedrefundamount, ls_event_log-actualrefundamount.
APPEND ls_event_log TO lt_event_log.
ENDIF.
ENDLOOP.
ENDIF.
" Get subsequent documents from flow
SELECT vbelv, vbtyp_n, vbeln, rfbsk
INTO TABLE @DATA(lt_doc_flow)
FROM vbfa
FOR ALL ENTRIES IN @lt_return_orders
WHERE vbelv = @lt_return_orders-vbeln
AND vbtyp_n IN ('J', 'R', 'M'). " J=Delivery, R=Goods Mvmt, M=Invoice
" 3. Return Delivery Created
SELECT vbeln, erdat, erzet, ernam FROM likp
INTO TABLE @DATA(lt_deliveries)
FOR ALL ENTRIES IN @lt_doc_flow
WHERE vbeln = @lt_doc_flow-vbeln AND @lt_doc_flow-vbtyp_n = 'J'.
LOOP AT lt_deliveries INTO DATA(ls_delivery).
READ TABLE lt_doc_flow INTO DATA(ls_doc_flow_del) WITH KEY vbeln = ls_delivery-vbeln.
ls_event_log-returncaseid = ls_doc_flow_del-vbelv.
ls_event_log-activityname = 'Return Delivery Created'.
CONVERT DATE ls_delivery-erdat TIME ls_delivery-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_delivery-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" 4. Goods Receipt Posted
SELECT mblnr, mjahr, budat, cputm, usnam FROM mkpf
INTO TABLE @DATA(lt_goods_receipt)
FOR ALL ENTRIES IN @lt_doc_flow
WHERE xblnr = @lt_doc_flow-vbeln AND @lt_doc_flow-vbtyp_n = 'R'.
LOOP AT lt_goods_receipt INTO DATA(ls_goods_receipt).
READ TABLE lt_doc_flow INTO DATA(ls_doc_flow_gr) WITH KEY vbeln = ls_goods_receipt-mblnr.
ls_event_log-returncaseid = ls_doc_flow_gr-vbelv.
ls_event_log-activityname = 'Goods Receipt Posted'.
CONVERT DATE ls_goods_receipt-budat TIME ls_goods_receipt-cputm INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_goods_receipt-usnam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" 5. Usage Decision Made (Requires QM Module implementation)
SELECT q~prueflos, q~vdatu, q~vzeit, q~vname
FROM qals AS q
INNER JOIN qave AS v ON q~prueflos = v~prueflos
INTO TABLE @DATA(lt_usage_decisions)
FOR ALL ENTRIES IN @lt_deliveries
WHERE q~kdauf = @lt_deliveries-vbeln.
LOOP AT lt_usage_decisions INTO DATA(ls_ud).
SELECT SINGLE vbelv FROM vbfa INTO @DATA(lv_vbelv_ud) WHERE vbeln = @ls_ud-prueflos.
ls_event_log-returncaseid = lv_vbelv_ud.
ls_event_log-activityname = 'Usage Decision Made'.
CONVERT DATE ls_ud-vdatu TIME ls_ud-vzeit INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_ud-vname.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" 7. Credit Memo Created
SELECT h~vbeln, h~erdat, h~erzet, h~ernam, i~netwr, i~vgbel
INTO TABLE @DATA(lt_cred_memos)
FROM vbrk AS h
INNER JOIN vbrp AS i ON h~vbeln = i~vbeln
FOR ALL ENTRIES IN @lt_doc_flow
WHERE h~vbeln = @lt_doc_flow-vbeln AND @lt_doc_flow-vbtyp_n = 'M'.
LOOP AT lt_cred_memos INTO DATA(ls_cred_memo).
ls_event_log-returncaseid = ls_cred_memo-vgbel.
ls_event_log-activityname = 'Credit Memo Created'.
CONVERT DATE ls_cred_memo-erdat TIME ls_cred_memo-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_cred_memo-ernam.
ls_event_log-actualrefundamount = ls_cred_memo-netwr.
APPEND ls_event_log TO lt_event_log.
" 8. Credit Memo Posted To FI
SELECT SINGLE budat, cputime, usnam FROM bkpf
INTO @DATA(ls_bkpf_post)
WHERE awkey = @ls_cred_memo-vbeln AND awtyp = 'VBRK'.
IF sy-subrc = 0.
ls_event_log-activityname = 'Credit Memo Posted To FI'.
CONVERT DATE ls_bkpf_post-budat TIME ls_bkpf_post-cputime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-processingagent = ls_bkpf_post-usnam.
APPEND ls_event_log TO lt_event_log.
ENDIF.
" 12. Credit Memo Cleared
SELECT SINGLE augdt FROM bseg
INTO @DATA(lv_augdt)
WHERE bukrs = @p_bukrs
AND belnr = @ls_cred_memo-vbeln
AND augdt IS NOT NULL.
IF sy-subrc = 0 AND lv_augdt IS NOT INITIAL.
ls_event_log-activityname = 'Credit Memo Cleared'.
CONVERT DATE lv_augdt INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
CLEAR: ls_event_log-processingagent.
APPEND ls_event_log TO lt_event_log.
ENDIF.
ENDLOOP.
" 9. Return Order Item Completed
SELECT vbeln, erdat, erzet, ernam, abgru FROM vbap
INTO TABLE @DATA(lt_items_completed)
FOR ALL ENTRIES IN @lt_return_orders
WHERE vbeln = @lt_return_orders-vbeln
AND gbsta = 'C'.
LOOP AT lt_items_completed INTO DATA(ls_item_completed).
ls_event_log-returncaseid = ls_item_completed-vbeln.
ls_event_log-activityname = 'Return Order Item Completed'.
CONVERT DATE ls_item_completed-erdat TIME ls_item_completed-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_item_completed-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" 10. Return Order Completed
SELECT vbeln, erdat, erzet, ernam FROM vbak
INTO TABLE @DATA(lt_orders_completed)
FOR ALL ENTRIES IN @lt_return_orders
WHERE vbeln = @lt_return_orders-vbeln
AND gbsta = 'C'.
LOOP AT lt_orders_completed INTO DATA(ls_order_completed).
ls_event_log-returncaseid = ls_order_completed-vbeln.
ls_event_log-activityname = 'Return Order Completed'.
CONVERT DATE ls_order_completed-erdat TIME ls_order_completed-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_order_completed-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" 11. Return Order Item Rejected
SELECT vbeln, erdat, erzet, ernam FROM vbap
INTO TABLE @DATA(lt_items_rejected)
FOR ALL ENTRIES IN @lt_return_orders
WHERE vbeln = @lt_return_orders-vbeln
AND abgru IS NOT NULL AND abgru <> ''.
LOOP AT lt_items_rejected INTO DATA(ls_item_rejected).
ls_event_log-returncaseid = ls_item_rejected-vbeln.
ls_event_log-activityname = 'Return Order Item Rejected'.
CONVERT DATE ls_item_rejected-erdat TIME ls_item_rejected-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_item_rejected-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
ENDIF.
" =======================================================================
" OUTPUT
" =======================================================================
cl_salv_table=>factory(
IMPORTING
r_salv_table = DATA(lo_alv)
CHANGING
t_table = lt_event_log ).
lo_alv->display( ). Schritte
- Voraussetzungen: Stellen Sie sicher, dass Sie über einen Datenbankbenutzer mit Lesezugriff auf die erforderlichen SAP-ECC-Tabellen verfügen. Dazu gehören Tabellen aus den Modulen Sales and Distribution (SD), Materials Management (MM) und Financial Accounting (FI). Für die Verbindung zur Datenbank benötigen Sie ein geeignetes SQL-Client-Tool wie DBeaver, SAP HANA Studio oder Oracle SQL Developer.
- Systemspezifika ermitteln: Ermitteln Sie vor der Ausführung der Abfrage die konkreten Belegarten, die in Ihrer Organisation für Retouren verwendet werden. Die Abfrage enthält den Platzhalter
[YOUR_RETURN_ORDER_TYPES]. Ersetzen Sie ihn durch die tatsächlichen Werte, beispielsweise 'RE' für Standardretouren. - Abfrage vorbereiten: Kopieren Sie die vollständige SQL-Abfrage aus dem Abschnitt 'query' in Ihren SQL-Client.
- Parameter konfigurieren: Suchen Sie am Anfang der Abfrage die Common Table Expression (CTE)
BaseReturnOrders. Passen Sie dieWHERE-Klausel an, indem Sie[START_DATE]und[END_DATE]durch den gewünschten Zeitraum ersetzen. Aktualisieren Sie die Liste der Retourenauftragsarten und filtern Sie bei Bedarf nach einem bestimmten Buchungskreis (BUKRS_VF). - Abfrage ausführen: Führen Sie die angepasste Abfrage in der SAP-ECC-Datenbank aus. Die Laufzeit hängt vom gewählten Zeitraum und der Größe der Datenbank ab.
- Rohdaten prüfen: Prüfen Sie die Ausgabe nach Abschluss der Abfrage kurz. Stellen Sie sicher, dass die Spalten
ReturnCaseId,ActivityNameundEventTimebefüllt sind und Daten für mehrere Aktivitäten vorliegen. - Als CSV exportieren: Exportieren Sie das gesamte Ergebnisset aus Ihrem SQL-Client in eine CSV-Datei. Verwenden Sie die UTF-8-Kodierung, damit alle Zeichen korrekt erhalten bleiben.
- Upload vorbereiten: Öffnen Sie die CSV-Datei und prüfen Sie, ob die Spaltenüberschriften exakt den erforderlichen Attributen entsprechen:
ReturnCaseId,ActivityName,EventTime,SourceSystemusw. Korrigieren Sie die Überschriften, falls Ihr SQL-Client sie beim Export geändert hat. - Finaler Upload: Laden Sie die bereinigte CSV-Datei zur Analyse in die ProcessMind-Plattform hoch.
Konfiguration
- Retourenbelegarten: Die Abfrage muss mit den konkreten Vertriebsbelegarten konfiguriert werden, die in Ihrem SAP-System Retourenaufträge darstellen. Ersetzen Sie dazu den Platzhalter
[YOUR_RETURN_ORDER_TYPES]. Häufige Beispiele sind 'RE' oder kundenspezifische 'Z'-Belegarten. - Datumsbereich: Für die Extraktion muss ein geeigneter Zeitraum definiert werden. Für eine erste Analyse empfiehlt sich in der Regel ein Zeitraum von 3 bis 6 Monaten. Verwenden Sie dafür die Platzhalter
[START_DATE]und[END_DATE]im Format 'YYYYMMDD'. - Buchungskreis: In Organisationen mit mehreren Buchungskreisen ist ein Filter für eine fokussierte Analyse erforderlich. Fügen Sie in der initialen CTE beispielsweise den Filter
VBAK.BUKRS_VF = '[YOUR_COMPANY_CODE]'hinzu, um den Umfang zu begrenzen. - Datenbankdialekt: Die bereitgestellte Abfrage verwendet gängige SQL-Funktionen. Datums- und Zeitumwandlungen wie
TO_TIMESTAMPsowie die Verkettung von Zeichenfolgen (CONCAT) können je nach zugrunde liegendem Datenbanksystem, beispielsweise Oracle, HANA oder DB2, geringfügige Syntaxanpassungen erfordern. - Erforderliche Berechtigungen: Der Datenbankbenutzer benötigt Lesezugriff auf die folgenden wichtigen Tabellen: VBAK, VBAP, VBFA, LIKP, LIPS, VBRK, VBRP, MKPF, MSEG, BKPF, BSAD, QALS, QAVE, CDHDR und CDPOS.
a Beispielabfrage sql
WITH BaseReturnOrders AS (
SELECT
VBAK.VBELN AS ReturnOrderNumber,
VBAP.POSNR AS ReturnOrderItemNumber
FROM VBAK
JOIN VBAP ON VBAK.VBELN = VBAP.VBELN
WHERE VBAK.AUART IN ('[YOUR_RETURN_ORDER_TYPES]') -- e.g., 'RE'
AND VBAK.ERDAT BETWEEN '[START_DATE]' AND '[END_DATE]' -- e.g., '20230101' and '20231231'
)
-- 1. Return Order Created
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Return Order Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(VBAK.ERDAT, VBAK.ERZET), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
VBAK.ERNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
UNION ALL
-- 2. Return Order Block Removed
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Return Order Block Removed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
CDHDR.USERNAME AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN CDHDR ON B.ReturnOrderNumber = CDHDR.OBJECTID
JOIN CDPOS ON CDHDR.OBJECTCLAS = CDPOS.OBJECTCLAS AND CDHDR.OBJECTID = CDPOS.OBJECTID AND CDHDR.CHANGENR = CDPOS.CHANGENR
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
WHERE CDHDR.OBJECTCLAS = 'VERKBELEG'
AND CDPOS.TABNAME = 'VBAK'
AND CDPOS.FNAME IN ('LIFSK', 'FAKSK')
AND CDPOS.VALUE_NEW = ''
AND CDPOS.VALUE_OLD <> ''
UNION ALL
-- 3. Return Delivery Created
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Return Delivery Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(LIKP.ERDAT, LIKP.ERZET), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
LIKP.ERNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'J'
JOIN LIKP ON VBFA.VBELN = LIKP.VBELN
UNION ALL
-- 4. Goods Receipt Posted
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Goods Receipt Posted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(MKPF.CPUDT, MKPF.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
MKPF.USNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'J'
JOIN LIPS ON VBFA.VBELN = LIPS.VBELN AND VBFA.POSNN = LIPS.POSNR
JOIN MSEG ON LIPS.VBELN = MSEG.LFBNR AND LIPS.POSNR = MSEG.LFPOS
JOIN MKPF ON MSEG.MBLNR = MKPF.MBLNR AND MSEG.MJAHR = MKPF.MJAHR
WHERE MSEG.BWART IN ('651', '653', '655') -- Standard returns movement types
UNION ALL
-- 5. Usage Decision Made
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Usage Decision Made' AS "ActivityName",
TO_TIMESTAMP(CONCAT(QAVE.ADAT, QAVE.ATIM), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
QAVE.AENAME AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'J'
JOIN QALS ON VBFA.VBELN = QALS.VBELN AND VBFA.POSNN = QALS.POSNR -- Linking inspection lot to delivery item
JOIN QAVE ON QALS.PRUEFLOS = QAVE.PRUEFLOS
UNION ALL
-- 6. Credit Memo Request Created (assumes a separate doc, or can be the return order itself)
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Credit Memo Request Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(CMR_VBAK.ERDAT, CMR_VBAK.ERZET), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
CMR_VBAK.ERNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'K' -- 'K' is Credit Memo Request
JOIN VBAK AS CMR_VBAK ON VBFA.VBELN = CMR_VBAK.VBELN
UNION ALL
-- 7. Credit Memo Created
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Credit Memo Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(VBRK.ERDAT, VBRK.ERZET), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
VBRK.ERNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
VBRP.NETWR AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'M'
JOIN VBRK ON VBFA.VBELN = VBRK.VBELN
JOIN VBRP ON VBRK.VBELN = VBRP.VBELN AND VBFA.POSNN = VBRP.POSNR
WHERE VBRK.FKART IN ('[YOUR_CREDIT_MEMO_TYPES]') -- e.g., 'G2'
UNION ALL
-- 8. Credit Memo Posted To FI
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Credit Memo Posted To FI' AS "ActivityName",
TO_TIMESTAMP(CONCAT(BKPF.CPUDT, BKPF.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
BKPF.USNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
VBRP.NETWR AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'M'
JOIN VBRK ON VBFA.VBELN = VBRK.VBELN
JOIN VBRP ON VBRK.VBELN = VBRP.VBELN AND VBFA.POSNN = VBRP.POSNR
JOIN BKPF ON VBRK.VBELN = BKPF.AWKEY AND BKPF.AWTYP = 'VBRK'
UNION ALL
-- 9. Return Order Item Completed
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Return Order Item Completed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
CDHDR.USERNAME AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN CDHDR ON CONCAT(B.ReturnOrderNumber, LPAD(B.ReturnOrderItemNumber, 6, '0')) = CDHDR.OBJECTID
JOIN CDPOS ON CDHDR.OBJECTCLAS = CDPOS.OBJECTCLAS AND CDHDR.OBJECTID = CDPOS.OBJECTID AND CDHDR.CHANGENR = CDPOS.CHANGENR
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
WHERE CDHDR.OBJECTCLAS = 'VERKBELEG'
AND CDPOS.TABNAME = 'VBUP'
AND CDPOS.FNAME = 'GBSTA'
AND CDPOS.VALUE_NEW = 'C'
UNION ALL
-- 10. Return Order Completed
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Return Order Completed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
CDHDR.USERNAME AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN CDHDR ON B.ReturnOrderNumber = CDHDR.OBJECTID
JOIN CDPOS ON CDHDR.OBJECTCLAS = CDPOS.OBJECTCLAS AND CDHDR.OBJECTID = CDPOS.OBJECTID AND CDHDR.CHANGENR = CDPOS.CHANGENR
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
WHERE CDHDR.OBJECTCLAS = 'VERKBELEG'
AND CDPOS.TABNAME = 'VBUK'
AND CDPOS.FNAME = 'GBSTK'
AND CDPOS.VALUE_NEW = 'C'
UNION ALL
-- 11. Return Order Item Rejected
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Return Order Item Rejected' AS "ActivityName",
TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
CDHDR.USERNAME AS "ProcessingAgent",
CDPOS.VALUE_NEW AS "ReturnReason", -- Using rejection reason for this specific event
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN CDHDR ON CONCAT(B.ReturnOrderNumber, LPAD(B.ReturnOrderItemNumber, 6, '0')) = CDHDR.OBJECTID
JOIN CDPOS ON CDHDR.OBJECTCLAS = CDPOS.OBJECTCLAS AND CDHDR.OBJECTID = CDPOS.OBJECTID AND CDHDR.CHANGENR = CDPOS.CHANGENR
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
WHERE CDHDR.OBJECTCLAS = 'VERKBELEG'
AND CDPOS.TABNAME = 'VBAP'
AND CDPOS.FNAME = 'ABGRU'
AND CDPOS.VALUE_NEW <> ''
UNION ALL
-- 12. Credit Memo Cleared
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Credit Memo Cleared' AS "ActivityName",
TO_TIMESTAMP(BSAD.AUGDT, 'YYYYMMDD') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
CLEAR_DOC.USNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
VBRP.NETWR AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'M'
JOIN VBRK ON VBFA.VBELN = VBRK.VBELN
JOIN VBRP ON VBRK.VBELN = VBRP.VBELN AND VBFA.POSNN = VBRP.POSNR
JOIN BSAD ON VBRK.VBELN = BSAD.VBELN
JOIN BKPF AS CLEAR_DOC ON BSAD.AUGBL = CLEAR_DOC.BELNR AND BSAD.BUKRS = CLEAR_DOC.BUKRS AND BSAD.GJAHR_AUGL = CLEAR_DOC.GJAHR; Bereit für den Start?
Beginnen Sie noch heute mit diesem Template, um Ihre Datenerfassung zu strukturieren und aussagekräftige Erkenntnisse zu Ihrem Retouren- und Erstattungsprozess zu gewinnen.
Optimieren Sie jetzt Ihre Retouren- und Erstattungsprozesse
Vereinfachen Sie Ihre Retourenprozesse in SAP ECC und verkürzen Sie die Durchlaufzeit um 30 Prozent. Starten Sie noch heute.
Keine Kreditkarte erforderlich, Einrichtung in wenigen Minuten