Ihr Daten-Template für die Bearbeitung von Rücksendungen und Erstattungen
Ihr Daten-Template für die Bearbeitung von Rücksendungen und Erstattungen
- Empfohlene Attribute für die Datenerfassung
- Wichtige Aktivitäten für die Nachverfolgung
- Anleitung zur Datenextraktion
Attribute für die Bearbeitung von Rücksendungen und Erstattungen
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Der Name eines bestimmten Geschäftsereignisses oder Prozessschritts im Retourenprozess. | ||
| Beschreibung Dieses Attribut bezeichnet eine einzelne, klar abgegrenzte Aktion oder Statusänderung im Lebenszyklus einer Retoure, etwa „Retourenauftrag erstellt“, „Wareneingang gebucht“ oder „Gutschrift erstellt“. Diese Aktivitäten bilden die Bausteine der Prozesslandkarte. Die Analyse ihrer Reihenfolge und Häufigkeit zeigt die häufigsten Prozesspfade, Abweichungen und Nacharbeitsschleifen. Sie ist entscheidend, um zu verstehen, was in einem Fall geschieht und in welcher Reihenfolge. Darauf bauen alle Process-Mining-Analysen auf. Warum das wichtig ist Aktivitäten bilden die Prozessschritte ab. Ihre Reihenfolge, Dauer und Häufigkeit zu analysieren, ist der Kern von Process Mining und zeigt, wie die Arbeit tatsächlich abläuft. Woher beziehen Abgeleitet aus Statusänderungen in Tabellen wie VBUK/VBUP, Belegerstellungsereignissen (z. B. in VBAK, LIKP, VBRK) oder Änderungsprotokollen in den Tabellen CDHDR/CDPOS. Beispiele Retourenauftrag angelegtWareneingang gebuchtGutschrift angelegtRetourenauftragsposition abgeschlossen | |||
| Ereigniszeit EventTime | Das genaue Datum und die Uhrzeit, zu denen die Aktivität stattgefunden hat. | ||
| Beschreibung Dieser Zeitstempel gibt den genauen Zeitpunkt eines Geschäftsereignisses an. Er wird für jede Aktivität im Prozess erfasst und bildet so die chronologische Abfolge der Ereignisse innerhalb eines Falls ab. Die Ereigniszeit ist für alle zeitbasierten Analysen entscheidend. Dazu gehören die Berechnung von Durchlaufzeiten zwischen Aktivitäten, das Erkennen von Engpässen durch Wartezeiten und die Messung der Gesamtdauer eines Falls. Sie ermöglicht außerdem Leistungsanalysen und Compliance-Prüfungen anhand von Service Level Agreements (SLAs). Warum das wichtig ist Dieser Zeitstempel ist unverzichtbar, um Zeitspannen zu berechnen, die Prozessleistung zu analysieren, Engpässe zu erkennen und den zeitlichen Verlauf jedes Retourenfalls nachzuvollziehen. Woher beziehen Die Daten stammen aus verschiedenen Datums- und Zeitfeldern in SAP-Tabellen. Bei Erstellungsereignissen sind dies häufig die Felder ERDAT und ERZET (z. B. in VBAK). Bei Änderungsereignissen stehen Datum und Uhrzeit in UDATE und UTIME der Tabelle CDHDR. Beispiele 2023-04-15T10:22:05Z2023-04-16T14:01:30Z2023-04-18T09:15:00Z | |||
| Retourenfall-ID ReturnCaseId | Die eindeutige Kennung der Retourenanfrage eines Kunden, über die alle zugehörigen Aktivitäten und Belege verknüpft werden. | ||
| Beschreibung Die Retourenfall-ID ist der Primärschlüssel, mit dem sich der gesamte Lebenszyklus einer Retoure von der Einleitung bis zum Abschluss verfolgen lässt. Jede ID gehört zu einer bestimmten Kundenretoure und umfasst alle zugehörigen Ereignisse, etwa Auftragserstellung, Lieferung, Prüfung und Gutschriftsbearbeitung. In der Prozessanalyse ist dieses Attribut grundlegend für den Aufbau der Prozesslandkarte. Es ermöglicht dem System, einzelne Ereignisse zu durchgängigen Fallverläufen zusammenzufassen. So lassen sich Prozessvarianten, Durchlaufzeiten und Engpässe für jeden einzelnen Retourenfall analysieren. Warum das wichtig ist Diese zentrale Fallkennung verknüpft alle Schritte einer Retoure und ermöglicht die Analyse des durchgängigen Prozessablaufs und seiner Leistung. Woher beziehen In der Regel ist dies die Nummer des Retourenauftrags aus dem Modul Vertrieb und Distribution (SD). Sie steht in der Tabelle VBAK (Verkaufsbelegkopf), im Feld VBELN. Die Belegart (VBAK-VBTYP) ist bei Retouren „H“. Beispiele 600001236000045660000789 | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Zeitstempel, der angibt, wann die Daten für diesen Prozess zuletzt aktualisiert wurden. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion oder Aktualisierung. So ist nachvollziehbar, wie aktuell die analysierten Daten sind. Für die Analyse ist dies wichtig, um die Aktualität der Erkenntnisse einzuschätzen. Benutzer sehen, auf welchem Stand die Daten sind. Das beeinflusst die Aussagekraft der Ergebnisse, insbesondere bei der Überwachung laufender Abläufe. Warum das wichtig ist Zeigt an, wie aktuell die Daten sind. So können Benutzer den Aktualitätsstand der Prozessanalyse einschätzen und erkennen, wann die nächste Aktualisierung zu erwarten ist. Woher beziehen Dieses Metadatenattribut wird mit dem Ausführungszeitstempel des Datenextraktionsjobs befüllt. Beispiele 2023-05-20T02:00:00Z2023-05-21T02:00:00Z | |||
| Quellsystem SourceSystem | Das System, aus dem die Daten extrahiert wurden. | ||
| Beschreibung Dieses Attribut gibt die Herkunft der Daten an. Das ist in Umgebungen mit mehreren Systemen wichtig, da es Kontext liefert und die Nachvollziehbarkeit und Integrität der Daten unterstützt. In der Analyse dient es dazu, Daten aus verschiedenen Quellsystemen zu segmentieren oder zu filtern. So lässt sich prüfen, ob die Ereignisse aus der erwarteten Anwendung stammen, in diesem Fall aus SAP ECC. Warum das wichtig ist Gibt die Herkunft der Daten an. Das ist wichtig für die Data Governance und für Analysen über mehrere Unternehmenssysteme hinweg. Woher beziehen Dies ist ein statischer Wert, der bei der Datenextraktion festgelegt wird, um die jeweilige SAP-ECC-Instanz zu kennzeichnen (z. B. „ECC_PROD_100“). Beispiele SAP_ECC_PRODSAPECC_FINANCE_200 | |||
| Angeforderter Erstattungsbetrag RequestedRefundAmount | Der erwartete Erstattungsbetrag, der sich in der Regel aus dem Nettowert der zurückgegebenen Positionen ergibt. | ||
| Beschreibung Dieses Attribut gibt den ursprünglichen Geldwert der Retoure an, wie er im Retourenauftrag erfasst wurde. Er dient als Ausgangswert für Finanzanalysen und den Abgleich. Der Betrag wird mit dem „Tatsächlichen Erstattungsbetrag“ verglichen, um Abweichungen zu erkennen. Dies ist eine wichtige Kennzahl im Dashboard „Abweichungen bei Erstattungsbeträgen“. Die Analyse hilft, die finanziellen Auswirkungen von Retouren zu überwachen und mögliche Probleme bei der Preisgestaltung oder Gutschriftsberechnung zu erkennen. Warum das wichtig ist Legt den ursprünglichen finanziellen Wert der Retoure fest. Das ist wichtig, um finanzielle Abweichungen nachzuverfolgen und den Gesamtwert der retournierten Waren zu ermitteln. Woher beziehen Dieser Wert entspricht in der Regel dem Nettowert auf Positionsebene des Retourenauftrags. Er steht in der Tabelle VBAP, im Feld NETWR. Beispiele 150.0049.991250.75 | |||
| Bearbeitende 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 einen bestimmten Prozessschritt verantwortlich war, etwa für die Erstellung des Retourenauftrags oder die Buchung des Wareneingangs. Häufig wird diese Person über die Felder „Geändert von“ oder „Erstellt von“ ermittelt. Die Auswertung nach bearbeitender Person ist wichtig für das Leistungsmanagement und die Ressourcenanalyse. Sie hilft, besonders leistungsstarke Mitarbeitende und Personen mit zusätzlichem Schulungsbedarf zu erkennen sowie die Arbeitslast im Team zu verteilen. In Dashboards wie „Leistung bei der Retourenbearbeitung nach Mitarbeitenden“ lassen sich Durchlaufzeiten und Durchsatz vergleichen. Warum das wichtig ist Erfasst die Beteiligung der Benutzer und ermöglicht Analysen zur Teamleistung und Arbeitslastverteilung. Außerdem lassen sich Schulungsbedarf und bewährte Vorgehensweisen erkennen. Woher beziehen Typische Felder sind ERNAM (Erstellt von) oder AENAM (Geändert von) in Kopftabellen wie VBAK, LIKP und VBRK. Bei Änderungsereignissen steht der Benutzername im Feld USERNAME der Tabelle CDHDR. Beispiele CBURNSDSCRANTONJHALPERT | |||
| Materialnummer MaterialNumber | Die eindeutige Kennung des zurückgegebenen Produkts. | ||
| Beschreibung Die Materialnummer, auch SKU genannt, bezeichnet genau den Artikel, um den es bei der Retoure geht. Damit sind detaillierte Analysen auf Produktebene möglich. Durch die Auswertung nach Materialnummer können Unternehmen Produkte mit hohen Retourenquoten erkennen. Diese können auf Qualitätsprobleme, ungenaue Beschreibungen oder Fertigungsmängel hindeuten. Das Attribut ist wichtig für Dashboards wie „Auswirkungen von Retouren auf den Bestand“ und zeigt, wie verschiedene Produkte den Retourenprozess durchlaufen. Warum das wichtig ist Zeigt, welche Produkte zurückgegeben werden, und macht mögliche Probleme bei der Qualitätskontrolle oder ungenaue Produktbeschreibungen sichtbar. Woher beziehen Zu finden in der Verkaufsbelegpositionstabelle VBAP, im Feld MATNR. Beispiele RM-1025FG-2050-BACC-5591 | |||
| Retourengrund ReturnReason | Der vom Kunden angegebene Grund für die Rückgabe der Position. | ||
| Beschreibung Dieses Attribut gibt anhand vordefinierter SAP-Grundcodes an, warum ein Produkt zurückgegeben wurde. Beispiele sind „Beim Transport beschädigt“, „Falscher Artikel geliefert“ oder „Passt nicht“. Der Retourengrund ist eine wichtige Dimension für die Ursachenanalyse. Filtern Analysten die Prozesslandkarte oder Kennzahlen nach Retourengrund, können sie feststellen, ob bestimmte Gründe mit längeren Bearbeitungszeiten, häufigeren fehlgeschlagenen Prüfungen oder bestimmten Prozessabweichungen verbunden sind. Diese Erkenntnisse können Verbesserungen bei Produktqualität, Logistik oder Vertrieb unterstützen. Warum das wichtig ist Zeigt, warum Retouren erfolgen. So lassen sich Ursachen analysieren und Retourenquoten senken, indem Probleme mit Produktqualität, Versand oder Produktbeschreibungen behoben werden. Woher beziehen Zu finden in der Verkaufsbelegpositionstabelle VBAP, im Feld ABGRU (Ablehnungsgrund für Verkaufsbelege). Beispiele 001 - Produkt beschädigt002 - Falsches Produkt005 - Zu spät eingetroffen | |||
| Retourenkanal ReturnChannel | Der Kanal, über den die Retoure eingeleitet wurde, etwa online, in einer Filiale oder über ein Callcenter. | ||
| Beschreibung Dieses Attribut gibt an, über welchen Kanal die Retourenanfrage eingegangen ist. Es unterscheidet beispielsweise zwischen Anfragen über ein Webportal, in einer Filiale oder über den Kundenservice. Die Segmentierung nach Retourenkanal ist wichtig, um Unterschiede im Betrieb und beim Ressourceneinsatz zu verstehen. Retouren in einer Filiale können beispielsweise schneller geprüft werden, aber andere Dokumentationsschritte erfordern als Online-Retouren. Der Kanal ist eine wichtige Dimension im Dashboard „Durchsatztrends im Retourenprozess“. Warum das wichtig ist Zeigt, über welchen Kanal Retouren eingeleitet werden. Das wirkt sich häufig auf den Prozessablauf, den Ressourcenbedarf und die Durchlaufzeiten aus. Woher beziehen Dieses Feld ist in SAP ECC häufig nicht standardmäßig vorhanden. Die Daten müssen gegebenenfalls aus einem kundenspezifischen Feld (z. B. in VBAK) stammen oder aus anderen Daten wie der Verkaufsorganisation (VKORG) oder dem Vertriebsweg (VTWEG) abgeleitet werden. Prüfen Sie die SAP-ECC-Dokumentation für die konkrete Implementierung. Beispiele OnlineportalIn der FilialeCallcenter | |||
| Tatsächlicher Erstattungsbetrag ActualRefundAmount | Der endgültige Betrag, der dem Kunden laut Finanzbelegen gutgeschrieben wurde. | ||
| Beschreibung Dieses Attribut gibt den endgültigen, bestätigten Erstattungsbetrag an, der im Buchhaltungssystem bearbeitet und gebucht wurde. Er kann vom angeforderten Betrag abweichen, etwa aufgrund von Wiedereinlagerungsgebühren, Anpassungen nach Prüfung des Warenzustands oder der Anwendung anderer Richtlinien. Das Attribut ist eine wichtige Kennzahl im Dashboard „Abweichungen bei Erstattungsbeträgen“. Der Vergleich mit dem angeforderten Betrag hilft, systematische Probleme bei der Berechnung und Freigabe von Erstattungen zu erkennen und die finanzielle Genauigkeit sicherzustellen. Warum das wichtig ist Gibt das endgültige finanzielle Ergebnis der Retoure an. Der Vergleich mit dem angeforderten Betrag hilft, die Genauigkeit zu prüfen und finanzielle Verluste zu erkennen. Woher beziehen Die Daten stammen aus dem Finanzbeleg zur Gutschrift. Sie stehen in der Regel in der Tabelle BSEG (Buchhaltungsbelegsegment), im Feld WRBTR (Betrag in Belegwährung), für die betreffende Sachkontenbuchung. Beispiele 150.0045.001200.75 | |||
| Abweichung beim Erstattungsbetrag RefundAmountDiscrepancy | Die berechnete Differenz zwischen dem tatsächlichen und dem angeforderten Erstattungsbetrag. | ||
| Beschreibung Diese berechnete Kennzahl beziffert die Differenz zwischen dem ursprünglich im Retourenauftrag angeforderten Betrag und dem schließlich in der Gutschrift ausgewiesenen Betrag. Ein positiver Wert kann auf eine Teilerstattung hindeuten. Ein negativer Wert ist ungewöhnlich, könnte aber eine Überzahlung anzeigen. Dieses Attribut ist die zentrale Kennzahl im Dashboard „Abweichungen bei Erstattungsbeträgen“. Es hilft, Fälle mit finanziellen Abweichungen schnell zu erkennen und zu analysieren. Mögliche Ursachen sind die Bewertung des Warenzustands, 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, Verstöße gegen Richtlinien, Bearbeitungsfehler oder finanzielle Verluste zu erkennen. Woher beziehen Berechnetes Feld: ActualRefundAmount - RequestedRefundAmount. Beispiele 0.00-4.99-50.00 | |||
| Buchungskreis CompanyCode | Die juristische Einheit oder das Unternehmen, das für den Geschäftsvorgang verantwortlich ist. | ||
| Beschreibung Der Buchungskreis ist in SAP eine eigenständige Buchhaltungseinheit. Alle Finanzvorgänge, einschließlich Retouren und Erstattungen, werden einem bestimmten Buchungskreis zugeordnet. Dieses Attribut ist für die Finanzberichterstattung und die Segmentierung von Prozessen in multinationalen Unternehmen oder Organisationen mit mehreren Rechtseinheiten wichtig. Die Auswertung nach Buchungskreis ermöglicht den Vergleich der Retourenprozesse zwischen verschiedenen Rechtseinheiten eines Unternehmens. Warum das wichtig ist Ermöglicht das Filtern und Vergleichen von Retourenprozessen zwischen verschiedenen Rechtseinheiten einer Organisation. Das ist für die Finanzanalyse wichtig. Woher beziehen Zu finden in der Verkaufsbelegkopftabelle VBAK, im Feld BUKRS_VF (Buchungskreis für die Fakturierung). Beispiele 10002000US01 | |||
| Einhaltung der Retourenrichtlinien ReturnPolicyAdherence | Ein Kennzeichen dafür, ob die Retoure allen festgelegten Geschäftsregeln und Richtlinien entspricht. | ||
| Beschreibung Dieses berechnete boolesche Attribut zeigt an, ob ein Retourenfall den geltenden Unternehmensrichtlinien gefolgt ist. Die Logik kann mehrere Bedingungen prüfen, etwa ob die Retoure innerhalb der zulässigen Frist eingeleitet wurde, ob der Grundcode für das Produkt gültig ist oder ob für eine Ausnahme eine Genehmigung durch eine Führungskraft vorliegt. Dieses Attribut bildet die Grundlage für das Dashboard „Einhaltung der Freigaberichtlinien für Retouren“. Es ermöglicht eine direkte Messung der Compliance-Rate und zeigt, welche Richtlinien am häufigsten umgangen werden. So lassen sich gezielte Prozessverbesserungen oder Schulungen planen. Warum das wichtig ist Misst die Einhaltung von Geschäftsregeln und unterstützt eine einheitliche Anwendung der Richtlinien. Außerdem lassen sich Fälle erkennen, die eine besondere Prüfung oder Freigabe erfordern. Woher beziehen Dieses Attribut wird anhand einer Reihe von Geschäftsregeln abgeleitet. Beispiel: (Datum der Retoureneinleitung - Datum des ursprünglichen Kaufs) <= 30 Tage UND ReturnReason IS NOT NULL. Beispiele truefalse | |||
| Gutschriftsnummer 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 auszuzahlende Erstattung festhält. Ihre Nummer identifiziert diesen Finanzbeleg eindeutig. Dieses Attribut ist für den finanziellen Abgleich und die Nachverfolgung vom operativen Retourenvorgang bis zum finanziellen Ausgleich wichtig. Es markiert einen zentralen Meilenstein im Prozess und hilft, zugehörige Buchhaltungsbelege für Attribute wie den „Tatsächlichen Erstattungsbetrag“ zu finden. Warum das wichtig ist Verweist direkt auf den Finanzbeleg, der die Erstattung an den Kunden veranlasst. Das ist wichtig für die Finanzprüfung und den Abgleich. Woher beziehen Die Gutschrift ist ein Fakturabeleg. Ihre Nummer steht in der Tabelle VBRK (Fakturabeleg: Kopfdaten), im Feld VBELN. Die Verknüpfung erfolgt über den Belegfluss des Retourenauftrags. Beispiele 900011229000334490005566 | |||
| Kunden-ID CustomerId | Die eindeutige Kennung des Kunden, der die Retoure veranlasst. | ||
| Beschreibung Dieses Attribut identifiziert den jeweiligen Kunden, der in SAP als „Auftraggeber“ geführt wird und das Produkt zurückgibt. Es verknüpft den Retourenvorgang mit den Kundenstammdaten. Die Auswertung nach Kunden-ID hilft, Kunden mit häufigen Retouren zu erkennen. Dies kann auf Unzufriedenheit oder eine mögliche missbräuchliche Nutzung der Retourenrichtlinien hindeuten. In Verbindung mit Kundensegmenten lässt sich außerdem untersuchen, ob sich das Retourenverhalten oder die Prozesserfahrung zwischen Kundengruppen unterscheidet. Warum das wichtig ist Verknüpft Retouren mit einzelnen Kunden. So lassen sich Kundenverhalten und wiederholte Retouren analysieren sowie Auswirkungen auf die Kundenbeziehung erkennen. Woher beziehen Zu finden in der Verkaufsbelegkopftabelle VBAK, im Feld KUNNR (Auftraggeber). Beispiele CUST-100432CUST-203991CUST-831102 | |||
| SLA eingehalten IsSLACompliant | Ein Kennzeichen dafür, ob die Erstattung innerhalb des vereinbarten Service Level Agreements (SLA) bearbeitet wurde. | ||
| Beschreibung Dieses berechnete boolesche Attribut vergleicht das tatsächliche Datum der Aktivität „Erstattung bearbeitet“ mit dem „Zieldatum für die Erstattung gemäß SLA“. Es ist wahr, wenn die Erstattung fristgerecht abgeschlossen wurde, andernfalls falsch. Das Attribut vereinfacht Analyse und Berichterstattung, indem es für jeden Fall ein eindeutiges Ja-Nein-Ergebnis zur SLA-Leistung liefert. Es dient zur Berechnung der Gesamtrate „SLA-Einhaltung bei der Erstattungsbearbeitung“ und ermöglicht es, Fälle ohne SLA-Einhaltung gezielt zu filtern und zu analysieren. Warum das wichtig ist Zeigt die SLA-Leistung für jeden Fall eindeutig als Ja oder Nein an und vereinfacht so die Überwachung und Berichterstattung zur Compliance. Woher beziehen Dies ist ein berechnetes Attribut. Die Logik lautet: Ereigniszeit von „Erstattung bearbeitet“ <= RefundSLATargetDate. Beispiele truefalse | |||
| Status des Retourenauftrags ReturnOrderStatus | Der Gesamtbearbeitungsstatus des Retourenfalls. | ||
| Beschreibung Dieses Attribut zeigt den aktuellen Status des Retourenfalls an, etwa „Offen“, „In Bearbeitung“ oder „Abgeschlossen“. Es wird aus den Statusangaben auf Kopf- oder Positionsebene des Verkaufsbelegs abgeleitet. In der Analyse lässt sich dieses Attribut verwenden, um offene oder abgeschlossene Retouren zu filtern. Es unterstützt die Überwachung der Arbeitslast und des Fortschritts bei offenen Fällen und zeigt das Gesamtergebnis jedes Retourenfalls. Warum das wichtig ist Zeigt auf hoher Ebene, an welcher Stelle im Lebenszyklus sich ein Fall befindet. So lassen sich offene, laufende oder abgeschlossene Retouren filtern und analysieren. Woher beziehen Abgeleitet aus den Statusfeldern in den Tabellen VBUK (Kopfstatus) und VBUP (Positionsstatus). VBUK-GBSTK gibt beispielsweise den Gesamtbearbeitungsstatus des Belegs an. Beispiele OffenIn BearbeitungAbgeschlossen | |||
| Ursprünglicher Verkaufsbeleg OriginalSalesDocument | Die Nummer des ursprünglichen Kundenauftrags, auf den sich die Retoure bezieht. | ||
| Beschreibung Dieses Attribut verweist direkt auf den ursprünglichen Kauf des Kunden. Als Referenzbeleg verknüpft es die Retoure mit den Einzelheiten des ursprünglichen Geschäftsvorgangs. Dieser Zusammenhang ist für weiterführende Analysen besonders wertvoll. Analysten können untersuchen, warum Verkäufe aus bestimmten Aufträgen retourniert werden, ursprüngliche Preise und Konditionen prüfen und den gesamten Lebenszyklus vom Kundenauftrag bis zur Retoure nachvollziehen. So lässt sich auch feststellen, ob Produkte aus bestimmten Kampagnen oder Vertriebskanälen häufiger zurückgegeben werden. Warum das wichtig ist Verknüpft die Retoure mit dem ursprünglichen Verkauf. So lässt sich der gesamte Kundenvorgang nachvollziehen und die Ursachenanalyse vertiefen. Woher beziehen Diese Referenz wird auf Positionsebene des Retourenauftrags gespeichert. Sie steht in der Tabelle VBAP, im Feld VGBEL (Belegnummer des Referenzbelegs). Beispiele 100034561000987110012345 | |||
| Werk Plant | Der physische Standort oder Betrieb, an dem die Retoure eingeht und bearbeitet wird. | ||
| Beschreibung Ein Werk bezeichnet in SAP einen physischen Standort, etwa ein Lager oder ein Distributionszentrum, an dem Waren bearbeitet werden. Bei Retouren ist dies in der Regel der Standort, an dem die Position eingeht und geprüft wird. Die Auswertung nach Werk zeigt Leistungsunterschiede zwischen Standorten. Sie kann aufdecken, welche Lager Positionen effizienter prüfen oder einen höheren Durchsatz erzielen. Diese Erkenntnisse unterstützen das Dashboard „Durchsatz und Effizienz bei der Positionsprüfung“. Warum das wichtig ist Gibt den Standort an, an dem die Retoure bearbeitet wird. So lassen sich verschiedene Lager oder Distributionszentren hinsichtlich ihrer Leistung vergleichen. Woher beziehen Zu finden auf Positionsebene des Retourenauftrags, in der Tabelle VBAP, im Feld WERKS. Beispiele PL01WH02DC05 | |||
| Zieldatum für die Erstattung gemäß SLA RefundSLATargetDate | Das Datum, bis zu dem die Erstattung gemäß den Service Level Agreements bearbeitet werden soll. | ||
| Beschreibung Dieses Attribut legt die Frist für den Abschluss der Erstattung eines Retourenfalls fest. Sie wird in der Regel anhand von Geschäftsregeln berechnet, etwa „5 Arbeitstage nach Wareneingang“. Das Zieldatum dient als Maßstab für die tatsächliche Leistung. Es ist die zentrale Grundlage des Dashboards „SLA-Einhaltung bei der Erstattungsbearbeitung“. Damit kann das Unternehmen die Einhaltung von Kundenzusagen ü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-Einhaltung messen und berichten sowie überfällige Fälle priorisieren. Woher beziehen Dieses Feld ist in SAP in der Regel nicht standardmäßig vorhanden und muss anhand von Geschäftsregeln abgeleitet werden. Es kann beispielsweise ausgehend von einem Stichtagsfeld (z. B. dem Wareneingangsdatum aus MKPF) berechnet werden, indem eine konfigurierte Dauer addiert wird. Prüfen Sie die SAP-ECC-Dokumentation oder die fachlichen Anforderungen. Beispiele 2023-04-25T23:59:59Z2023-04-28T23:59:59Z2023-05-02T23:59:59Z | |||
Aktivitäten bei der Bearbeitung von Rücksendungen und Erstattungen
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Gutschrift an FI gebucht | Die Gutschrift wird an die Finanzbuchhaltung übergeben und damit als offener Posten in der Debitorenbuchhaltung gebucht. Dieser Schritt löst die eigentliche Rückzahlung an den Kunden aus. | ||
| Warum das wichtig ist Diese Aktivität markiert den Zeitpunkt, an dem das Unternehmen die Erstattung finanziell erfasst. Verzögerungen zwischen der Erstellung und der Buchung der Gutschrift können die Rückzahlung an den Kunden hinauszögern. Woher beziehen Dieses Ereignis wird aus dem Buchungsstatus im Fakturabelegkopf (VBRK-RFBSK) abgeleitet. Es wird erfasst, wenn der Status auf „C“ gesetzt wird (Buchungsbeleg wurde erstellt). Das tatsächliche Erstellungsdatum des Buchhaltungsbelegs steht in der Tabelle BKPF. Erfassung Ermitteln Sie den Zeitstempel, zu dem VBRK-RFBSK auf „C“ gesetzt wird, oder verwenden Sie das Erstellungsdatum (CPUDT) des verknüpften Buchhaltungsbelegs aus BKPF. Ereignistyp inferred | |||
| Gutschrift angelegt | Ein Fakturabeleg (Gutschrift) wird erstellt, um die finanzielle Gutschrift für den Kunden zu veranlassen. Dieses offizielle Finanzdokument weist den Erstattungsbetrag verbindlich aus. | ||
| Warum das wichtig ist Dies ist ein wichtiger finanzieller Meilenstein im Prozess. Die Analyse der Zeit bis zur Erstellung der Gutschrift hilft, Verzögerungen bei der Bearbeitung von Finanzdokumenten nach Wareneingang und Prüfung zu erkennen. Woher beziehen Dieses explizite Ereignis wird in der Tabelle VBRK (Fakturabelegkopf) erfasst. Das Erstellungsdatum steht in VBRK-ERDAT. Die Gutschrift ist im Belegfluss mit dem Retourenauftrag oder dem Gutschriftsanforderungsbeleg verknüpft. Erfassung Verwenden Sie den Erstellungszeitstempel (ERDAT) aus der Tabelle VBRK für den betreffenden 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 zentrale Endereignis des Prozesses. Die Zeitspanne von „Retourenauftrag erstellt“ bis zu dieser Aktivität entspricht der durchgängigen Durchlaufzeit des Retourenfalls. Woher beziehen Dieses Ereignis wird aus den Statustabellen abgeleitet. Es wird erfasst, wenn der Gesamtstatus des Verkaufsbelegkopfs (VBUK-GBSTK) auf „C“ gesetzt wird (vollständig bearbeitet). Erfassung Ermitteln Sie anhand der Änderungsbelege (CDHDR/CDPOS) den Zeitstempel, zu dem sich das Statusfeld VBUK-GBSTK des Belegkopfs auf „C“ ändert. Ereignistyp inferred | |||
| Retourenauftrag angelegt | Diese Aktivität markiert den Beginn des Retourenprozesses, wenn ein Kunde die Rückgabe eines Produkts beantragt. Sie wird erfasst, sobald in SAP ECC ein neuer Verkaufsbeleg der Art „Retoure“ (z. B. RE) angelegt wird. | ||
| Warum das wichtig ist Dies ist das primäre Start-Event des Retourenprozesses. Die Zeitspanne zwischen dieser Aktivität und nachfolgenden Aktivitäten zeigt die gesamte Zykluszeit und mögliche Verzögerungen zu Beginn der Bearbeitung. Woher beziehen Dies ist ein explizites Ereignis in der Tabelle VBAK (Kopf des Verkaufsbelegs). Der Erstellungszeitpunkt wird für die entsprechende Verkaufsbelegnummer (VBAK-VBELN) mit der Auftragsart VBAK-AUART = 'RE' in VBAK-ERDAT und VBAK-ERZET gespeichert. Erfassung Verwenden Sie den Erstellungszeitpunkt (ERDAT, ERZET) aus der Tabelle VBAK für Verkaufsbelege der Art 'RE'. Ereignistyp explicit | |||
| Verwendungsentscheid getroffen | Nach der Prüfung trifft eine Qualitätsfachkraft oder ein Prüfer eine formelle Entscheidung über den Zustand des retournierten Artikels. Davon hängt der weitere Ablauf ab, etwa die Rückführung in den Bestand, die Verschrottung oder eine Reparatur. | ||
| Warum das wichtig ist Diese Aktivität ist entscheidend, um die Effizienz der Prüfung und ihre Ergebnisse zu verstehen. Der Verwendungsentscheid wirkt sich unmittelbar auf den Erstattungsbetrag und die Bestandsverwaltung aus. Woher beziehen Wenn SAP QM verwendet wird, ist dies ein explizites Ereignis in der Tabelle QAVE (Verwendungsentscheid bei der Prüfungsbearbeitung). Der Entscheidungszeitpunkt wird in QAVE-VDATUM gespeichert. Die Verknüpfung mit der Lieferung steht in der Tabelle QALS. Erfassung 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 findet statt, wenn der retournierte Artikel physisch im Lager oder Bearbeitungszentrum eingeht. Erfasst wird sie durch die Buchung eines Warenbewegungsbelegs zur Retourenlieferung. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein zeigt an, dass das Unternehmen den retournierten Artikel übernommen hat. Er markiert den Beginn der physischen Prüfung und wirkt sich auf die Bestandsgenauigkeit aus. Woher beziehen Dieses Ereignis lässt sich anhand des Warenbewegungsstatus der Retourenlieferungsposition in der Tabelle VBUP ableiten (z. B. WBSTA = 'C'). Der genaue Timestamp steht im Kopf des Materialbelegs (MKPF-BUDAT) für den entsprechenden Wareneingang. Erfassung Ermitteln Sie das Buchungsdatum (BUDAT) in der Tabelle MKPF für den Materialbeleg, der mit der Retourenlieferung verknüpft ist. Ereignistyp inferred | |||
| Gutschrift ausgeglichen | Der offene Gutschriftsposten in der Debitorenbuchhaltung wird ausgeglichen, in der Regel durch eine Auszahlung an den Kunden. Dieses Ereignis markiert den endgültigen finanziellen Abschluss der Erstattung. | ||
| Warum das wichtig ist Diese Aktivität bestätigt die Auszahlung und schließt den finanziellen Teil des Prozesses ab. Aus Kundensicht ist damit die Erstattung tatsächlich abgeschlossen. Woher beziehen Dieses explizite Ereignis stammt aus dem FI-Modul. Das Ausgleichsdatum des Buchhaltungsbelegs steht für die entsprechende Kundenposition in der Tabelle BSEG (BSEG-AUGDT). Erfassung Verwenden Sie das Ausgleichsdatum (AUGDT) aus der Tabelle BSEG oder BSAD für den Buchhaltungsbeleg, der mit der Gutschrift verknüpft ist. Ereignistyp explicit | |||
| Gutschriftsanforderung angelegt | Eine Gutschriftsanforderung dokumentiert den Erstattungsbedarf formell. In vielen Konfigurationen dient der Retourenauftrag selbst als Gutschriftsanforderung. | ||
| Warum das wichtig ist Damit beginnt der finanzielle Abwicklungsteil des Retourenprozesses. Die Gutschriftsanforderung löst nachfolgende finanzielle Freigaben und die Erstellung von Belegen aus. Woher beziehen Dies kann ein explizites Ereignis in VBAK für einen Verkaufsbeleg der Art „Gutschriftsanforderung“ (z. B. CR) sein. Ist die Auftragsart so konfiguriert, dass die Fakturierung auftragsbezogen erfolgt, kann es sich auch um dasselbe Ereignis wie „Retourenauftrag angelegt“ handeln. Erfassung Verwenden Sie den Erstellungszeitpunkt (ERDAT) aus VBAK für Belege der Art 'CR' oder verwenden Sie erneut das Ereignis „Retourenauftrag angelegt“. Ereignistyp explicit | |||
| Retourenauftragsposition abgelehnt | Eine bestimmte Position des Retourenauftrags wird entweder bei der ersten Prüfung oder nach der Warenprüfung abgelehnt. Für diese Position erfolgt dann keine weitere Bearbeitung, etwa in Form einer Erstattung. | ||
| Warum das wichtig ist Die Analyse von Ablehnungen hilft, ungültige Retourenanfragen zu erkennen und Informationen zur Kundenkommunikation über Retourenrichtlinien bereitzustellen. Dieser wichtige Prozesspfad führt nicht zu einer Erstattung. Woher beziehen Dieses Ereignis wird abgeleitet. Es wird in der Regel erfasst, wenn in der Tabelle VBAP für die Position ein eindeutiger Ablehnungsgrundcode (VBAP-ABGRU) eingetragen wird. Der Zeitstempel muss aus den Änderungsprotokollen stammen. Erfassung Ermitteln Sie anhand der Änderungsbelege (CDHDR/CDPOS) den Zeitstempel, zu dem das Feld VBAP-ABGRU für eine Retourenposition befüllt wird. Ereignistyp inferred | |||
| Retourenauftragsposition abgeschlossen | Eine einzelne Position im Retourenauftrag wird als vollständig bearbeitet gekennzeichnet. Dies geschieht in der Regel, nachdem alle logistischen und finanziellen Folgebelege für diese Position erstellt wurden. | ||
| Warum das wichtig ist Die Auswertung auf Positionsebene zeigt, bei welchen Produkten oder Retourengründen die längsten Verzögerungen auftreten. So lässt sich der Prozessabschluss genauer nachvollziehen. Woher beziehen Dieses Ereignis wird aus den Statustabellen abgeleitet. Es wird erfasst, wenn der Gesamtstatus der Verkaufsbelegposition (VBUP-GBSTK) auf „C“ gesetzt wird (vollständig bearbeitet). Erfassung Ermitteln Sie anhand der Änderungsbelege (CDHDR/CDPOS) den Zeitstempel, zu dem sich das Statusfeld VBUP-GBSTK der Position auf „C“ ändert. Ereignistyp inferred | |||
| Retourenlieferung angelegt | Ein Lieferbeleg wird angelegt, um den physischen Eingang der retournierten Ware zu verwalten. Dieses Ereignis zeigt an, dass der logistische Retourenprozess 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 Zykluszeit der Retoure beeinträchtigen. Woher beziehen Dies ist ein explizites Ereignis in der Tabelle LIKP (Lieferkopf). Der Erstellungszeitpunkt steht in LIKP-ERDAT. Die Verknüpfung mit dem ursprünglichen Retourenauftrag finden Sie in der Tabelle LIPS (LIPS-VGBEL). Erfassung Verwenden Sie den Erstellungszeitpunkt (ERDAT) aus der Tabelle LIKP für die mit dem Retourenauftrag verknüpfte Lieferung. Ereignistyp explicit | |||
| Sperre des Retourenauftrags aufgehoben | Diese Aktivität steht für die Freigabe des Retourenantrags, durch die der Vorgang in die nächste Phase übergehen kann. Sie wird üblicherweise anhand einer Änderung des Belegstatus oder der Aufhebung einer Liefer- oder Fakturasperre erfasst. | ||
| Warum das wichtig ist Diese Aktivität ist ein wichtiger Meilenstein im Freigabeprozess. Die Zeit bis zu diesem Schritt zeigt Engpässe bei der Retourenautorisierung und -freigabe auf. Woher beziehen Dies ist ein abgeleitetes Ereignis, das aus den Änderungsprotokollen des Verkaufsbelegs ermittelt wird. Prüfen Sie in den Tabellen CDHDR und CDPOS Änderungen an Sperrfeldern in VBAK oder VBAP sowie an Statusfeldern in VBUK/VBUP. Erfassung Ermitteln Sie anhand der Änderungsbelegtabellen (CDHDR/CDPOS) den Timestamp, zu dem eine relevante Statussperre aufgehoben wurde. Ereignistyp inferred | |||
Anleitungen zur Datenextraktion
Schritte
- ABAP-Programm erstellen: Verwenden Sie den Transaktionscode
SE38, um ein neues ausführbares ABAP-Programm anzulegen, zum BeispielZ_PM_RETURN_EXTRACTION. Geben Sie einen aussagekräftigen Titel ein und speichern Sie das Programm als lokales Objekt oder in einem Entwicklungspaket. - Selektionsbild definieren: Legen Sie im Programm ein Selektionsbild an, über das Benutzer die Daten filtern können. Wichtige Filter sind der Erstellungszeitraum für Rücksendeaufträge (
S_ERDAT), die Belegart für Rücksendungen (S_AUART, zum Beispiel 'RE') und der Buchungskreis (P_BUKRS). - Datenstrukturen definieren: Erstellen Sie einen lokalen Strukturtyp, der dem erforderlichen Format des Event Log entspricht. Die Struktur sollte Felder für
ReturnCaseId,ActivityName,EventTime,SourceSystem,LastDataUpdate,ProcessingAgent,ReturnReasonund weitere erforderliche Attribute enthalten. - Datenabfrage implementieren: Schreiben Sie die zentrale ABAP-Logik, um Daten für jede der 12 erforderlichen Aktivitäten auszuwählen. Dazu fragen Sie verschiedene SAP-Tabellen wie VBAK, VBAP, LIKP, VBRK, BKPF, CDHDR und CDPOS ab. Verknüpfen Sie über die Belegflusstabelle VBFA zugehörige Belege wie Lieferungen und Gutschriften mit dem ursprünglichen Rücksendeauftrag.
- „Rücksendeauftrag erstellt“ extrahieren: Wählen Sie anhand der Kriterien des Selektionsbilds Datensätze aus den Tabellen
VBAKundVBAPaus. Die Verkaufsbelegnummer (VBAK-VBELN) dient alsReturnCaseId. - Statusänderungen und wichtige Ereignisse extrahieren: Fragen Sie für Aktivitäten wie „Sperre des Rücksendeauftrags aufgehoben“ oder „Position des Rücksendeauftrags abgelehnt“ die Änderungsbelegtabellen (
CDHDR,CDPOS) oder Statusfelder in Tabellen wieVBAP(ABGRU) ab. Wählen Sie für logistische und finanzielle Folgeaktivitäten Daten aus Tabellen wieLIKP,MKPF,VBRKundBKPFaus. Verwenden SieVBFA, um sicherzustellen, dass diese mit den ursprünglichen Rücksendeaufträgen verknüpft sind. - Event-Log-Tabelle befüllen: Erstellen Sie für jede ermittelte Aktivität einen neuen Datensatz in einer internen Tabelle, die mit Ihrer Event-Log-Struktur definiert wurde. Ordnen Sie die Daten aus den SAP-Quelltabellen den entsprechenden Feldern zu, zum Beispiel
VBAK-ERNAMdem FeldProcessingAgentsowieVBAK-ERDATundVBAK-ERZETdem FeldEventTime. - 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 Datei, 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. Tragen Sie mitSY-SYSIDdas Quellsystem inSourceSystemein. - Ausgabe einrichten: Ergänzen Sie eine Funktion, die die Ergebnisse für die Online-Analyse in einem ALV-Grid (SAP List Viewer) anzeigt, beispielsweise mit Funktionsbausteinen wie
REUSE_ALV_GRID_DISPLAY. Bieten Sie außerdem die Möglichkeit, die fertige interne Tabelle als CSV- oder Textdatei auf den lokalen Rechner herunterzuladen. - Ausführen und exportieren: Starten Sie das Programm über
SE38. Geben Sie die gewünschten Selektionskriterien ein und führen Sie es aus. Speichern Sie anschließend das Event Log über die Exportfunktion. Achten Sie auf ein mit ProcessMind kompatibles Format, in der Regel CSV mit einer Kopfzeile.
Konfiguration
- Datumsbereich: Geben Sie im Selektionsbild einen Zeitraum für das Erstellungsdatum des Rücksendeauftrags an. Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten, um Datenvolumen und Aussagekraft in einem ausgewogenen Verhältnis zu halten.
- Rücksende-Belegart: Filtern Sie nach der in Ihrem System verwendeten Verkaufsbelegart für Rücksendungen, zum Beispiel 'RE' für Rücksendungen oder 'CR' für Gutschriftsanforderungen. Dieser Filter ist entscheidend, um den richtigen Prozess abzugrenzen. Geben Sie die Werte in der Selektionsoption
S_AUARTein. - Buchungskreis: Geben Sie den relevanten Buchungskreis (
P_BUKRS) an, um die Daten auf einen bestimmten Rechtsträger zu begrenzen. Das ist in Unternehmen mit mehreren Buchungskreisen besonders wichtig. - Voraussetzungen: Der ausführende Benutzer benötigt Berechtigungen für
SE38(Programmausführung) und Zugriff auf die zugrunde liegenden SD-, MM- und FI-Tabellen, zum Beispiel 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 die Programmausführung lange dauern. Führen Sie das Programm gegebenenfalls als Hintergrundjob (
SM36) aus und schreiben Sie die Ausgabe in das Dateisystem des Anwendungsservers, statt sie online anzuzeigen.
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 Vertrieb (SD), Materialwirtschaft (MM) und Finanzwesen (FI). Für die Verbindung zur Datenbank benötigen Sie ein geeignetes SQL-Client-Tool wie DBeaver, SAP HANA Studio oder Oracle SQL Developer.
- Systemspezifische Angaben ermitteln: Ermitteln Sie vor der Abfrage die Belegarten, die in Ihrem Unternehmen für Rücksendungen verwendet werden. Die Abfrage enthält den Platzhalter
[YOUR_RETURN_ORDER_TYPES]. Ersetzen Sie ihn durch die tatsächlichen Werte, zum Beispiel 'RE' für Standardrücksendungen. - Abfrage vorbereiten: Kopieren Sie die vollständige SQL-Abfrage aus dem Abschnitt „query“ in Ihren SQL-Client.
- Parameter festlegen: Suchen Sie am Anfang der Abfrage den Common Table Expression (CTE) mit dem Namen
BaseReturnOrders. Passen Sie dieWHERE-Klausel an den gewünschten Zeitraum an, indem Sie[START_DATE]und[END_DATE]ersetzen. Aktualisieren Sie die Liste der Rücksendeauftragsarten und filtern Sie bei Bedarf nach einem bestimmten Buchungskreis (BUKRS_VF). - Abfrage ausführen: Führen Sie die angepasste Abfrage für die SAP-ECC-Datenbank aus. Die Ausführungszeit 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. Kontrollieren Sie, ob die Spalten
ReturnCaseId,ActivityNameundEventTimebefüllt sind und Daten für mehrere Aktivitäten enthalten. - Als CSV exportieren: Exportieren Sie das gesamte Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Verwenden Sie UTF-8, 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 Überschriften, falls Ihr SQL-Client sie beim Export geändert hat. - Datei hochladen: Laden Sie die bereinigte CSV-Datei zur Analyse in ProcessMind hoch.
Konfiguration
- Rücksende-Belegarten: Konfigurieren Sie die Abfrage mit den Verkaufsbelegarten, die in Ihrem SAP-System Rücksendeaufträge kennzeichnen. Ersetzen Sie dazu den Platzhalter
[YOUR_RETURN_ORDER_TYPES]. Übliche Beispiele sind 'RE' oder kundenspezifische 'Z'-Belegarten. - Datumsbereich: Legen Sie einen geeigneten Zeitraum für die Extraktion fest. Für eine erste Analyse werden in der Regel 3 bis 6 Monate an Daten empfohlen. Verwenden Sie dafür die Platzhalter
[START_DATE]und[END_DATE]im Format 'YYYYMMDD'. - Buchungskreis: In Unternehmen mit mehreren Buchungskreisen ist ein Filter wichtig, damit die Analyse auf den gewünschten Bereich beschränkt bleibt. Fügen Sie der anfänglichen CTE beispielsweise den Filter
VBAK.BUKRS_VF = '[YOUR_COMPANY_CODE]'hinzu. - Datenbankdialekt: Die Abfrage verwendet gängige SQL-Funktionen. Datums- und Zeitumwandlungen wie
TO_TIMESTAMPsowie die Verkettung von Zeichenfolgen (CONCAT) müssen je nach Datenbanksystem, etwa Oracle, HANA oder DB2, möglicherweise leicht angepasst werden. - Erforderliche Berechtigungen: Der Datenbankbenutzer benötigt Lesezugriff auf folgende wichtige Tabellen: VBAK, VBAP, VBFA, LIKP, LIPS, VBRK, VBRP, MKPF, MSEG, BKPF, BSAD, QALS, QAVE, CDHDR und CDPOS.
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;Möchten Sie loslegen?
Verwenden Sie dieses Template noch heute, um Ihre Datenerfassung zu vereinfachen und aussagekräftige Erkenntnisse zu Ihrem Rücksende- und Erstattungsprozess zu gewinnen.
Optimieren Sie jetzt die Bearbeitung von Rücksendungen und Erstattungen
Vereinfachen Sie die Bearbeitung von Rücksendungen in SAP ECC und verkürzen Sie die Zykluszeit um 30 %. Starten Sie noch heute.
Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.