Datatemplate voor de verwerking van retouren en terugbetalingen
Datatemplate voor de verwerking van retouren en terugbetalingen
- Aanbevolen attributen om te verzamelen
- Belangrijke activiteiten om te volgen
- Aanwijzingen voor data-extractie
Attributen voor retouren en terugbetalingen
| Naam | Beschrijving | ||
|---|---|---|---|
| Activiteitsnaam ActivityName | De naam van een specifieke bedrijfsactiviteit of gebeurtenis in het retour- en terugbetalingsproces. | ||
| Beschrijving Dit attribuut beschrijft één stap of mijlpaal in de levenscyclus van een retour. Activiteiten staan voor het werk dat wordt uitgevoerd, zoals ‘Retourorder goedgekeurd’ of ‘Artikelinspectie afgerond’. Ze worden afgeleid uit statuswijzigingen, het aanmaken van documenten of specifieke gebruikersacties die in SAP S/4HANA zijn vastgelegd. De volgorde en frequentie van deze activiteiten analyseren is de kern van process mining. Zo kun je het proces in kaart brengen, veelvoorkomende en zeldzame procesroutes herkennen en activiteiten opsporen die vaak worden herhaald. Dat kan wijzen op herstelwerk of inefficiënties. Waarom dit belangrijk is Activiteiten vormen de basis van de proceskaart en maken het mogelijk het procesverloop, bottlenecks en variaties te visualiseren en analyseren. Waar vind je dit? Activiteitsnamen worden meestal afgeleid uit een combinatie van data, zoals statuswijzigingen van documenten in tabellen als VBUK/VBUP, aanmaakgebeurtenissen in koptabellen als VBAK (verkoopdocumenten) en BKPF (boekhoudkundige documenten), en goederenbewegingsstatussen in MSEG. Voorbeelden Retouraanvraag ingediendGoederen ontvangen in het magazijnCreditnota aangemaaktTerugbetaling verwerkt | |||
| Retourcase-ID ReturnCaseId | De unieke identificatiecode van één retourproces van een klant. Deze koppelt alle bijbehorende activiteiten, van de start tot de afsluiting. | ||
| Beschrijving De retourcase-ID is de belangrijkste identificatiecode waarmee alle gebeurtenissen en activiteiten van één retour worden gegroepeerd. Elke retouraanvraag van een klant krijgt een unieke ID, zodat je het hele proces van begin tot eind kunt volgen. Bij process mining is dit attribuut essentieel om het procesverloop te reconstrueren. Door uiteenlopende gebeurtenissen zoals ‘Retouraanvraag ingediend’, ‘Goederen ontvangen’ en ‘Terugbetaling verwerkt’ aan elkaar te koppelen in een tijdlijn per retour, kun je de duur van cases, procesvarianten en bottlenecks analyseren. Waarom dit belangrijk is Dit is de belangrijkste sleutel om een retour van begin tot eind te volgen. Hiermee kun je analyses op caseniveau uitvoeren, zoals de doorlooptijd bepalen en procesvarianten ontdekken. Waar vind je dit? Dit is meestal het nummer van het verkoopdocument (VBELN) uit de kop van de retourordertabel VBAK. De documentcategorie (VBTYP) geeft aan dat het om een retour gaat. Voorbeelden 600001896000019060000191 | |||
| Tijdstip van gebeurtenis EventTime | De exacte timestamp die aangeeft wanneer een specifieke activiteit plaatsvond. | ||
| Beschrijving Het tijdstip van de gebeurtenis legt de datum en tijd vast waarop een bedrijfsgebeurtenis in het systeem is geregistreerd. Deze timestamp is nodig om activiteiten chronologisch te ordenen en analyses op basis van tijd uit te voeren. Bij process mining gebruik je dit attribuut om doorlooptijden tussen activiteiten te berekenen, de duur van elke stap te bepalen en procesprestaties in de tijd te analyseren. Het vormt de basis voor het opsporen van bottlenecks, het bewaken van SLA-naleving en het begrijpen van het verloop van het retourproces. Waarom dit belangrijk is Deze timestamp is nodig om gebeurtenissen te ordenen, alle tijdsduren en doorlooptijden te berekenen en vertragingen in het proces op te sporen. Waar vind je dit? Meestal afkomstig uit datum- en tijdvelden die horen bij het aanmaken van documenten of statuswijzigingen, zoals ERDAT (aanmaakdatum) en ERZET (aanmaaktijd) in tabellen als VBAK, LIKP en BKPF, of de boekingsdatum (BUDAT) in boekhoudkundige documenten. Voorbeelden 2023-10-26T10:05:00Z2023-10-27T14:30:15Z2023-10-28T09:00:00Z | |||
| ID van het bronsysteem SourceSystemId | Identificatiecode van het bronsysteem waaruit de data is opgehaald. | ||
| Beschrijving Dit attribuut geeft aan uit welk registratiesysteem de gebeurtenisdata afkomstig is. Voor dit proces is dat meestal de ID van de SAP S/4HANA-instantie. In omgevingen met meerdere systemen is dit veld belangrijk om de herkomst van data te volgen, problemen op te lossen en de data-integriteit te waarborgen. Het helpt data te onderscheiden wanneer retouren in verschillende ERP-instanties worden verwerkt of wanneer systemen zijn gekoppeld aan externe systemen, zoals een magazijnbeheersysteem. Waarom dit belangrijk is Geeft belangrijke context over de herkomst en geschiedenis van data, vooral in omgevingen met meerdere systemen. Zo blijft de data traceerbaar en betrouwbaar. Waar vind je dit? Deze waarde is meestal statisch en wordt tijdens het ophalen van de data ingesteld. Je kunt de waarde vinden in de beheergegevens van het SAP-systeem, bijvoorbeeld als System ID (SID). Voorbeelden S4H_PROD_100S4Q_DEV_200 | |||
| Laatste data-update LastDataUpdateTimestamp | De timestamp die aangeeft wanneer de data voor deze gebeurtenis voor het laatst is bijgewerkt of opgehaald. | ||
| Beschrijving Dit attribuut registreert de datum en tijd van de laatste data-extractie of update. Het geeft metadata over hoe actueel de geanalyseerde dataset is. Zo kun je zien hoe recent de data is, wat vooral van belang is voor operationele monitoring en dashboards die lopende cases volgen. Waarom dit belangrijk is Geeft aan hoe actueel de data is. Dat is belangrijk om te zorgen dat analyses en dashboards op recente informatie zijn gebaseerd. Waar vind je dit? Dit wordt meestal tijdens het ophalen van de data door de ETL- of datapijplijntool gegenereerd en aan de dataset toegevoegd. Voorbeelden 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Eindtijd van gebeurtenis EventEndTime | De timestamp waarop een activiteit is afgerond. Deze wordt gebruikt om de duur van de activiteit te berekenen. | ||
| Beschrijving StartTime (EventTime) markeert het begin van een activiteit, terwijl EventEndTime het einde aangeeft. Bij veel systeemgebeurtenissen zijn de begin- en eindtijd gelijk, omdat de gebeurtenis direct plaatsvindt. Voor activiteiten met een meetbare duur, zoals ‘Artikelinspectie’, is dit attribuut wel belangrijk. Met dit attribuut kun je de verwerkingstijd van een activiteit rechtstreeks berekenen. Dat is essentieel voor prestatieanalyses: je ziet welke specifieke stappen de meeste tijd kosten, niet alleen hoeveel tijd ertussen zit. Waarom dit belangrijk is Maakt het mogelijk de duur van afzonderlijke activiteiten nauwkeurig te berekenen. Zo kun je inefficiënties in specifieke processtappen opsporen. Waar vind je dit? Dit wordt vaak afgeleid. Voor sommige activiteiten is er een apart veld. Vaker is het de StartTime van de volgende activiteit in de case. Voorbeelden 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| Gebruikersnaam UserName | De gebruikers-ID van de medewerker die de activiteit heeft uitgevoerd. | ||
| Beschrijving Dit attribuut geeft aan welke gebruiker of systeemagent verantwoordelijk was voor een taak, zoals het goedkeuren van een retour of het aanmaken van een creditnota. In SAP wordt dit vaak vastgelegd in velden die registreren wie een document heeft aangemaakt of gewijzigd. Door op gebruiker te analyseren, kun je goed presterende medewerkers of teams herkennen, opleidingsbehoeften vaststellen en de werkverdeling bekijken. Dit is ook belangrijk om afwijkingen te onderzoeken: procesacties zijn zo te koppelen aan specifieke personen, wat helpt bij compliance en audits. Waarom dit belangrijk is Koppelt procesactiviteiten aan specifieke gebruikers, zodat je teamprestaties, werkverdeling en compliance kunt analyseren. Waar vind je dit? Deze informatie staat vaak in documentkoptabellen, bijvoorbeeld in ERNAM (aangemaakt door) in VBAK (verkooporders), LIKP (leveringen) en BKPF (boekhoudkundige documenten). Gebruikersgegevens kunnen worden aangevuld vanuit de gebruikerstabel USR21. Voorbeelden CBROWNASMITHWF_BATCH | |||
| Klant-ID CustomerId | De unieke identificatiecode van de klant die de retour aanvraagt. | ||
| Beschrijving Dit attribuut geeft aan welke klant de retour heeft aangevraagd. Zo wordt de procesinstantie gekoppeld aan een specifieke klant in de klantstamgegevens. Door retouren per klant te analyseren, kun je patronen herkennen, zoals klanten met een opvallend hoog retourpercentage. Dat kan wijzen op fraude of ontevredenheid. Je kunt het retourproces ook indelen op basis van klanttype, waarde of geschiedenis en de dienstverlening daarop afstemmen. Waarom dit belangrijk is Koppelt retouren aan specifieke klanten, zodat je klantgedrag en klantsegmenten kunt analyseren en klanten kunt herkennen die vaak artikelen retourneren. Waar vind je dit? Te vinden in het veld voor het klantnummer (KUNNR) in de kop van de retourordertabel (VBAK). Voorbeelden CUST-001234CUST-005678CUST-009012 | |||
| Product-ID ProductId | De unieke identificatiecode van het artikel dat wordt geretourneerd. | ||
| Beschrijving Dit attribuut geeft aan om welk materiaal of product het bij de retour gaat. Zo wordt het retourproces gekoppeld aan een specifiek artikel in de productcatalogus. Door retouren per product te analyseren, kun je artikelen met een hoog retourpercentage opsporen. Dat kan wijzen op kwaliteitsgebreken, onduidelijke productbeschrijvingen of problemen bij de productie. Met deze data kunnen bedrijven onderbouwde beslissingen nemen over productontwerp, leveranciersbeheer en voorraadstrategie. Waarom dit belangrijk is Koppelt het retourproces aan specifieke producten. Zo kun je retourpercentages per artikel analyseren en problemen met kwaliteit of productbeschrijvingen opsporen. Waar vind je dit? Te vinden in het veld voor het materiaalnummer (MATNR) in de tabel met retourorderregels (VBAP) of de tabel met retourleveringsregels (LIPS). Voorbeelden FG-10023HW-45981SW-LICENSE-PREM | |||
| Retourreden ReturnReason | De reden die de klant opgeeft voor het retourneren van het artikel. | ||
| Beschrijving Dit attribuut legt de opgegeven reden voor de retour vast, zoals ‘Defect artikel’, ‘Verkeerde maat’ of ‘Niet meer nodig’. De klant kiest deze reden meestal uit een vooraf bepaalde lijst met redencodes wanneer de retour wordt aangemeld. Door retourredenen te analyseren, kun je problemen met productkwaliteit opsporen, productbeschrijvingen verbeteren of verkoopprocessen aanpassen. De redenen geven rechtstreeks inzicht in ontevredenheid bij klanten en helpen bepalen waar verbeteringen nodig zijn om het totale retourpercentage te verlagen. Waarom dit belangrijk is Geeft inzicht in de redenen voor retouren en helpt met oorzaakanalyse van problemen met productkwaliteit, fouten bij de afhandeling of verschillen tussen verwachtingen en de werkelijkheid. Waar vind je dit? Meestal opgeslagen in het veld ABGRU (reden voor afwijzing van verkoopdocumenten) in de tabel met retourorderregels (VBAP). Voorbeelden 001 - Slechte kwaliteit002 - Beschadigd tijdens transport005 - Verkeerd artikel verzonden | |||
| Terugbetalingsbedrag RefundAmount | Het uiteindelijke bedrag dat aan de klant is terugbetaald. | ||
| Beschrijving Dit attribuut geeft het bedrag weer dat de klant na afronding van het retourproces daadwerkelijk als tegoed of terugbetaling heeft ontvangen. Dit bedrag staat in financiële documenten, zoals creditnota’s. Dit is een belangrijke financiële metriek voor verschillende analyses. Het is nodig voor het dashboard ‘Analyse van afwijkingen in terugbetalingsbedragen’, waarmee je het uiteindelijke bedrag vergelijkt met het aangevraagde bedrag. Je kunt retouren ook op bedrag indelen om te zien of retouren met een hoge waarde een ander proces volgen of langer duren. Waarom dit belangrijk is Brengt de financiële gevolgen van retouren in kaart en is belangrijk om de juistheid van terugbetalingen te analyseren, retouren met een hoge waarde op te sporen en de totale kosten te begrijpen. Waar vind je dit? Afkomstig uit het veld voor de nettowaarde (NETWR) van het creditnotadocument, in tabellen als VBRK (kop van het factuurdocument) of BSEG (regelpost van het boekhoudkundige document). Voorbeelden 125.50999.0049.99 | |||
| Aangevraagd terugbetalingsbedrag RequestedRefundAmount | Het bedrag dat aan het begin van het proces is aangevraagd of verwacht voor de terugbetaling. | ||
| Beschrijving Dit attribuut bevat de waarde van de goederen volgens de oorspronkelijke retouraanvraag. Het vormt de basis voor een vergelijking met het uiteindelijke terugbetalingsbedrag. Dit veld is nodig voor het dashboard ‘Analyse van afwijkingen in terugbetalingsbedragen’. Door het aangevraagde bedrag te vergelijken met het daadwerkelijke bedrag, kun je problemen opsporen, zoals gedeeltelijke terugbetalingen vanwege schade aan artikelen, herbevoorradingskosten of andere correcties. Zo blijven de financiële gegevens nauwkeurig en transparant. Waarom dit belangrijk is Dient als referentie om de nauwkeurigheid van terugbetalingen te meten en verschillen tussen verwachte en werkelijke terugbetalingsbedragen op te sporen en te analyseren. Waar vind je dit? Meestal gebaseerd op de nettowaarde van de artikelen op de oorspronkelijke retourorder. Dit is de nettowaarde (NETWR) van de bijbehorende orderregels in de tabel VBAP. Voorbeelden 125.501050.0049.99 | |||
| Creditnotanummer CreditMemoNumber | De unieke identificatiecode van het creditnotadocument waarmee de terugbetaling wordt goedgekeurd. | ||
| Beschrijving Een creditnota is het factuurdocument waarmee het account van de klant officieel wordt gecrediteerd voor de geretourneerde artikelen. Dit attribuut bevat het unieke nummer van dat financiële document. Het creditnotanummer volgen is belangrijk om de financiële afhandeling van het retourproces te analyseren. Het markeert een belangrijke mijlpaal en leidt vaak tot de daadwerkelijke terugbetaling. Ook is het nodig voor financiële aansluitingen en audits. Waarom dit belangrijk is Dit is de officiële financiële transactie voor de terugbetaling. Het nummer is belangrijk om de laatste processtappen te volgen en financiële audits uit te voeren. Waar vind je dit? Dit is het factuurdocumentnummer (VBELN) uit de kop van de factuurdocumenttabel (VBRK). De documentcategorie geeft aan dat het om een creditnota gaat. Voorbeelden 900003459000034690000347 | |||
| Is geautomatiseerd IsAutomated | Een aanduiding die aangeeft of een activiteit door een systeem of een medewerker is uitgevoerd. | ||
| Beschrijving Dit booleaanse attribuut maakt onderscheid tussen activiteiten die automatisch door een systeem worden uitgevoerd, zoals een workflow of achtergrondtaak, en activiteiten die een gebruiker handmatig uitvoert. Het is nodig om de KPI ‘Percentage automatisch goedgekeurde terugbetalingen’ te berekenen en mogelijkheden voor meer automatisering te vinden. Door handmatige taken te filteren, kunnen bedrijven verbeteringen richten op de onderdelen waar automatisering de meeste winst kan opleveren in snelheid, kosten en nauwkeurigheid. Waarom dit belangrijk is Maakt onderscheid tussen handmatige en geautomatiseerde taken. Dat helpt om mogelijkheden voor automatisering te vinden en de impact van digitale transformatie te meten. Waar vind je dit? Dit wordt meestal afgeleid van de gebruikersnaam. Als de gebruiker bijvoorbeeld ‘WF_BATCH’ of een andere systeem-ID is, wordt de activiteit als geautomatiseerd gemarkeerd. Voorbeelden truefalse | |||
| Is herhaalwerk IsRework | Een aanduiding die aangeeft of een activiteit in een case een herhaling is van een eerdere activiteit. | ||
| Beschrijving Dit berekende booleaanse attribuut herkent herhaalwerk: een activiteit die meer dan één keer binnen dezelfde case wordt uitgevoerd. Een artikelinspectie kan bijvoorbeeld opnieuw nodig zijn, of een creditnota wordt aangemaakt, geannuleerd en daarna opnieuw aangemaakt. Dit attribuut is nodig voor het dashboard ‘Analyse van herhaalwerk bij terugbetalingen’ en de KPI ‘Percentage herhaalwerk bij terugbetalingen’. Het maakt inefficiëntie meetbaar door activiteiten te markeren die vaak fouten opleveren of meerdere pogingen vereisen. Zo zie je waar betere controles of training nodig zijn. Waarom dit belangrijk is Maakt inefficiëntie en fouten zichtbaar door herhaald werk te markeren. Zo kun je gericht verbeteringen doorvoeren en verspilling en vertragingen terugdringen. Waar vind je dit? Deze aanduiding wordt meestal berekend door de process mining-tool zelf of vooraf in de datatransformatie. De controle kijkt of dezelfde activiteitsnaam al eerder in dezelfde case is voorgekomen. Voorbeelden truefalse | |||
| Naleving SLA terugbetaling RefundSlaAdherence | Een aanduiding die aangeeft of de terugbetaling binnen de SLA-streefdatum is verwerkt. | ||
| Beschrijving Dit berekende attribuut controleert of de activiteit ‘Terugbetaling verwerkt’ op of vóór de ‘Streefdatum SLA terugbetaling’ heeft plaatsgevonden. Per case geeft het eenvoudig aan of de SLA is nageleefd. Dit is de belangrijkste metriek voor het dashboard ‘Bewaking naleving SLA terugbetalingen’ en de KPI ‘Nalevingspercentage SLA terugbetalingen’. Je kunt prestaties toetsen aan de afspraken met klanten en cases opsporen die niet aan de verwachtingen voldoen. Daarna kun je de oorzaken van vertragingen analyseren. Waarom dit belangrijk is Meet rechtstreeks of afspraken met klanten worden nagekomen. Daarmee is dit een belangrijke indicator voor de servicekwaliteit en klanttevredenheid. Waar vind je dit? Berekend door voor elke case de EventTime van de activiteit ‘Terugbetaling verwerkt’ te vergelijken met de ‘RefundSlaTargetDate’. Voorbeelden truefalse | |||
| Naleving van het retourbeleid ReturnPolicyAdherence | Een aanduiding die aangeeft of de retourcase voldoet aan het vastgestelde retourbeleid. | ||
| Beschrijving Dit berekende booleaanse attribuut geeft aan of een retour voldoet aan de criteria van het toepasselijke retourbeleid. De logica kan bijvoorbeeld controleren of de retour binnen de toegestane termijn is aangemeld en of de retourreden geldig is voor het product. Dit attribuut ondersteunt het dashboard ‘Overzicht naleving retourbeleid’. Het maakt nalevingspercentages meetbaar en laat je inzoomen op cases die niet aan het beleid voldoen. Zo kun je de redenen voor afwijkingen achterhalen en het beleid beter handhaven. Waarom dit belangrijk is Maakt naleving van bedrijfsregels meetbaar. Zo kun je beleidsovertredingen opsporen en terugdringen die de winstgevendheid kunnen schaden of uitzonderingen in het proces veroorzaken. Waar vind je dit? Berekend op basis van bedrijfsregels. Bijvoorbeeld: (datum waarop de retour is aangemeld - oorspronkelijke aankoopdatum) <= [toegestane retourtermijn]. Hiervoor zijn de oorspronkelijke aankoopdatum en de beleidsregels nodig. Voorbeelden truefalse | |||
| Nummer van de retourlevering ReturnDeliveryNumber | De unieke identificatiecode van het retourleveringsdocument. | ||
| Beschrijving Wanneer een klant goederen fysiek retourneert, wordt in SAP een retourleveringsdocument aangemaakt om de inkomende logistiek te beheren. Dit attribuut bevat het unieke nummer van dat document. Deze ID is belangrijk om de fysieke verplaatsing van retourgoederen te volgen. Het document verbindt de financiële en logistieke aspecten van de retour en maakt een gedetailleerde analyse mogelijk van de goederenontvangst en inspectie. Waarom dit belangrijk is Verbindt de retourorder met de fysieke ontvangst van goederen. Dit is belangrijk om de logistiek en de verwerkingstijden in het magazijn te analyseren. Waar vind je dit? Dit is het leveringsdocumentnummer (VBELN) uit de levertabelkop (LIKP). De documentcategorie geeft aan dat het om een retourlevering gaat. Voorbeelden 840000128400001384000014 | |||
| Resultaat artikelinspectie ItemInspectionOutcome | Het resultaat van de fysieke inspectie van het geretourneerde artikel. | ||
| Beschrijving Dit attribuut legt het resultaat vast van de inspectie nadat de goederen in het magazijn zijn ontvangen. Veelvoorkomende uitkomsten zijn ‘Goedgekeurd’, ‘Afgekeurd - beschadigd’ en ‘Goedgekeurd - geschikt voor wederverkoop’. Deze data geeft context voor de volgende processtappen. Het resultaat bepaalt of er een volledige, gedeeltelijke of geen terugbetaling wordt gedaan. Analyse van de uitkomst helpt om redenen voor afkeuringen te vinden. Als artikelen vaak tijdens het transport beschadigd raken, kan dit ook informatie opleveren over de productverpakking of vervoerders. Waarom dit belangrijk is Geeft inzicht in de redenen voor goedkeuring of afwijzing van terugbetalingen en levert waardevolle data over de staat van artikelen en aanpassingen aan terugbetalingen. Waar vind je dit? Deze informatie kan worden vastgelegd in een inspectielot van de module voor kwaliteitsbeheer (QM), of als status- of redenencode op de retourleveringsregel (LIPS). Mogelijk staat de informatie ook in een aangepast veld. Voorbeelden Goedgekeurd - geschikt voor wederverkoopGoedgekeurd - opknappen vereistAfgekeurd - schade veroorzaakt door klantAfgekeurd - verkeerd artikel geretourneerd | |||
| Retourbeleid-ID ReturnPolicyId | De identificatie van het retourbeleid dat van toepassing is op deze retourcase. | ||
| Beschrijving Dit attribuut geeft aan welk retourbeleid of welke set regels op de transactie van toepassing is. Het beleid kan verschillen per producttype, klantsegment of tijd sinds de aankoop. Deze data is nodig voor het dashboard ‘Overzicht naleving retourbeleid’. Door elke case aan een beleid te koppelen, kan het systeem automatisch controleren of de regels worden gevolgd, bijvoorbeeld voor retourtermijnen en de staat van artikelen. Afwijkingen worden gemarkeerd voor analyse. Waarom dit belangrijk is Maakt automatische controle aan de hand van bedrijfsregels mogelijk. Zo worden retouren consistent en volgens het beleid verwerkt. Waar vind je dit? Dit is vaak geen standaardveld in SAP. Mogelijk moet je het afleiden op basis van bedrijfslogica en data zoals producttype, klant en verkoopdatum. Als dit is ingericht, kan het in een aangepast veld worden opgeslagen. Voorbeelden STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| Status retourorder ReturnOrderStatus | De huidige algemene status van de retourcase. | ||
| Beschrijving Dit attribuut geeft op elk moment de algemene status van de retourcase weer, zoals ‘Open’, ‘In behandeling’ of ‘Gesloten’. Vaak wordt deze status afgeleid van de laatst voltooide belangrijke mijlpaal. Dit is nodig voor het dashboard ‘Huidige status retourcases’, dat een operationeel overzicht geeft van de werkvoorraad en de verdeling van cases. Managers zien hoeveel cases zich in elke procesfase bevinden en kunnen de inzet van mensen en de werkdruk beter verdelen. Waarom dit belangrijk is Geeft per case weer waar deze zich in het proces bevindt. Dat is nodig voor operationele dashboards die de huidige werkvoorraad en status volgen. Waar vind je dit? Afgeleid van de statusvelden in de relevante documenten. Bijvoorbeeld van de kopstatus (GBSTK) of artikelstatus (LFSTK) in de bijbehorende verkooporder (VBUK/VBUP) of leveringsdocumenten. Voorbeelden Wacht op goederenontvangstWacht op inspectieWacht op terugbetalingGesloten | |||
| Streefdatum SLA terugbetaling RefundSlaTargetDate | De datum waarop de terugbetaling voor de retourcase uiterlijk verwerkt moet zijn. | ||
| Beschrijving Dit attribuut bepaalt de deadline van de Service Level Agreement (SLA) voor de verwerking van de terugbetaling. De datum wordt meestal berekend op basis van bedrijfsregels, bijvoorbeeld een bepaald aantal dagen nadat de retour is goedgekeurd of de goederen zijn ontvangen. Dit veld vormt de basis voor het dashboard ‘Bewaking naleving SLA terugbetalingen’ en de bijbehorende KPI. Je kunt cases volgen die het risico lopen hun SLA te overschrijden en de oorzaken van vertragingen analyseren. Zo kun je uiteindelijk de klanttevredenheid verbeteren. Waarom dit belangrijk is Biedt een basis om de naleving van de SLA te meten, prestaties te volgen, oudere cases prioriteit te geven en de klanttevredenheid te verbeteren. Waar vind je dit? Dit is vrijwel altijd een afgeleid veld. De berekening gebruikt een belangrijke datum, zoals de aanmaakdatum van het retourverzoek, plus een duur die is vastgelegd in bedrijfsregels. Die kan afhangen van factoren zoals het klanttype of de retourreden. Voorbeelden 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
| Verantwoordelijke voor verwerking ProcessingAgent | De medewerker of groep die verantwoordelijk is voor een handmatige activiteit. | ||
| Beschrijving Dit attribuut geeft aan welke persoon of welk team een taak heeft uitgevoerd. Het kan specifieker zijn dan ‘Gebruikersnaam’, bijvoorbeeld door een rol of team te vermelden. Dat is vooral handig in een omgeving met gedeelde diensten. Dit helpt om de prestaties van verschillende medewerkers of teams te analyseren in het dashboard ‘Efficiëntie goedkeuring terugbetalingen’. Zo krijg je inzicht in de verdeling van het werk, zie je waar training nodig is en herken je goed presterende medewerkers of teams met best practices om te delen. Waarom dit belangrijk is Maakt prestatieanalyse per medewerker of team mogelijk. Zo kun je de werkdruk beheren, trainingsbehoeften vaststellen en de efficiëntie verbeteren. Waar vind je dit? Deze informatie is mogelijk beschikbaar via de SAP Business Partner-functies als medewerkers zijn toegewezen. Je kunt deze ook afleiden uit de afdeling of rol van de gebruiker in de HR-organisatiestructuur. Voorbeelden Ondersteuning niveau 1MagazijninspectieteamFinanciële afdeling - crediteurenadministratie | |||
| Verkooporganisatie SalesOrganization | De organisatie-eenheid die verantwoordelijk is voor de oorspronkelijke verkoop en de retour. | ||
| Beschrijving De verkooporganisatie is een belangrijk onderdeel van de organisatiestructuur in SAP. Deze staat voor de eenheid die verantwoordelijk is voor de verkoop en distributie van producten en diensten en wordt aan de retourtransactie toegewezen. Met dit attribuut kun je het retourproces filteren en vergelijken tussen verschillende bedrijfseenheden, regio’s of divisies. Zo kun je nagaan of bepaalde verkooporganisaties hogere retourpercentages hebben of retouren minder efficiënt afhandelen. Dat vormt de basis voor een analyse van de prestaties per organisatie. Waarom dit belangrijk is Maakt het mogelijk de prestaties en retourpercentages van verschillende bedrijfseenheden, regio’s of verkoopkanalen met elkaar te vergelijken. Waar vind je dit? Te vinden in het veld voor de verkooporganisatie (VKORG) in de kop van de retourordertabel (VBAK). Voorbeelden 10002100US01 | |||
Activiteiten voor retouren en terugbetalingen
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Aanvraag voor creditnota aangemaakt | Na een geslaagde inspectie markeert deze activiteit het aanmaken van een aanvraag om de klant een tegoed te geven. Dit wordt vastgelegd als een nieuw verkoopdocument, een aanvraag voor een creditnota, met een verwijzing naar de oorspronkelijke retourorder. | ||
| Waarom dit belangrijk is Dit is het startpunt van de financiële afhandeling van het retourproces. De tijd tussen de inspectie en deze stap laat zien hoe efficiënt de overdracht van logistiek naar financiën verloopt. Waar vind je dit? Dit wordt vastgelegd wanneer in tabel VBAK een verkoopdocument met de documentcategorie Aanvraag voor creditnota wordt aangemaakt. De koppeling met de retour staat in de documentstroomtabel VBFA. Vastleggen De gebeurtenis wordt vastgelegd wanneer een nieuwe aanvraag voor een creditnota wordt opgeslagen. Gebeurtenistype explicit | |||
| Artikelinspectie afgerond | Dit is de afronding van de kwaliteits- en conditiebeoordeling van de retourgoederen. Bij Advanced Returns Management is dit vaak een expliciete stap waarin de inspectie-uitkomst wordt vastgelegd en de vervolgstap wordt bepaald, zoals terugbetaling of afschrijving. | ||
| Waarom dit belangrijk is De duur en uitkomst van de inspectie hebben direct invloed op de verwerkingstijd van de terugbetaling en het voorraadbeheer. Deze activiteit is belangrijk om de efficiëntie van inspecties en herstelwerk te analyseren. Waar vind je dit? In SAP Advanced Returns Management (ARM) kan dit een expliciete gebeurtenis zijn uit de inspectietransactie. De gebeurtenis kan ook worden afgeleid uit een statuswijziging van de retourorderregel die de inspectie-uitkomst aangeeft. Vastleggen Dit wordt vastgelegd aan de hand van transactielogboeken of statuswijzigingen voor logistieke vervolgactiviteiten in ARM. Gebeurtenistype explicit | |||
| Creditnota aangemaakt | Dit is het aanmaken van het officiële factuurdocument waarmee het account van de klant wordt gecrediteerd voor het retourartikel. SAP legt deze gebeurtenis expliciet vast wanneer de creditnota wordt gegenereerd op basis van de aanvraag voor een creditnota. | ||
| Waarom dit belangrijk is Het aanmaken van de creditnota is een belangrijke financiële mijlpaal. Hiermee wordt het terug te betalen bedrag bevestigd en kan de betaling worden gestart. Waar vind je dit? Dit wordt vastgelegd wanneer in tabel VBRK een factuurdocument wordt aangemaakt waarvan de documentcategorie aangeeft dat het om een creditnota gaat. Dit document is in tabel VBFA gekoppeld aan de aanvraag voor een creditnota. Vastleggen De gebeurtenis wordt vastgelegd wanneer een nieuw factuurdocument voor een creditnota wordt opgeslagen, bijvoorbeeld met transactie VF01. Gebeurtenistype explicit | |||
| Goederen ontvangen in het magazijn | Deze gebeurtenis markeert de fysieke ontvangst van het retourartikel in het magazijn of verwerkingscentrum. Het systeem registreert dit expliciet wanneer een goederenontvangst (PGR) voor de retourlevering wordt geboekt en er een materiaaldocument wordt aangemaakt. | ||
| Waarom dit belangrijk is Dit is een belangrijke mijlpaal: vanaf dit moment begint de tijd voor inspectie en beoordeling te lopen. Vertragingen hiervoor worden veroorzaakt door de klant, vertragingen daarna zijn intern. Waar vind je dit? Dit wordt vastgelegd in de materiaaldocumenttabellen MSEG en MKPF voor het goederenontvangstbewegingstype dat bij retouren hoort. De boekingsdatum (MKPF-BUDAT) geeft het tijdstip van de gebeurtenis aan. Vastleggen De gebeurtenis komt overeen met het boeken van een goederenontvangst voor de retourlevering. Gebeurtenistype explicit | |||
| Retouraanvraag ingediend | Dit is het begin van het retourproces: in het systeem wordt een retourorder aangemaakt. SAP S/4HANA registreert deze gebeurtenis wanneer een nieuw verkoopdocument van het type retourorder wordt opgeslagen. | ||
| Waarom dit belangrijk is Deze activiteit markeert de officiële start van de retourcase. De tijd tussen deze gebeurtenis en de afsluiting is belangrijk om de totale doorlooptijd van het retourproces en de klantervaring te meten. Waar vind je dit? Dit is een expliciete gebeurtenis die wordt vastgelegd wanneer in tabel VBAK een verkoopdocument wordt aangemaakt waarvan de documentcategorie (VBAK-VBTYP) aangeeft dat het om een retourorder gaat. Het aanmaaktijdstip staat in VBAK-ERDAT. Vastleggen De gebeurtenis wordt vastgelegd wanneer een nieuwe retourorder wordt opgeslagen, bijvoorbeeld met transactie VA01. Gebeurtenistype explicit | |||
| Retourcase afgesloten | Dit is de laatste activiteit. Het retourproces is afgerond en er worden geen verdere acties voor de case verwacht. Dit wordt meestal afgeleid wanneer de retourorder in het systeem de definitieve status ‘Afgesloten’ heeft bereikt. | ||
| Waarom dit belangrijk is Deze gebeurtenis markeert het einde van de proceslevenscyclus en maakt het mogelijk de totale doorlooptijd te berekenen. Ook bevestigt de gebeurtenis dat de case volledig is afgehandeld. Waar vind je dit? Dit wordt afgeleid wanneer de algemene status van de retourorder in tabel VBAK of van de regels in VBAP de status ‘Voltooid’ of ‘Afgesloten’ bereikt. Dit hangt af van de statusbeheerconfiguratie van het systeem. Vastleggen Dit wordt afgeleid wanneer de status van het retourorderdocument verandert in ‘Voltooid’. Gebeurtenistype inferred | |||
| Terugbetaling verwerkt | Deze activiteit markeert de laatste stap van het terugbetalingsproces. De financiële creditpost wordt vereffend, wat betekent dat de betaling naar de klant is verstuurd. Dit wordt afgeleid uit het aanmaken van een vereffeningsdocument in de financiële module, waarmee de openstaande creditpost op de rekening van de klant wordt afgehandeld. | ||
| Waarom dit belangrijk is Op dit moment ontvangt de klant daadwerkelijk de betaling. De tijd vanaf het indienen van de retouraanvraag tot deze stap heeft veel invloed op de klanttevredenheid en is belangrijk om de naleving van SLA’s te meten. Waar vind je dit? Dit wordt afgeleid uit de gegevens van het vereffeningsdocument in de regelpostentabel BSEG van de financiële administratie. De vereffeningsdatum (BSEG-AUGDT) op de klantregelpost die bij de creditnota hoort, geeft aan wanneer de terugbetaling is verwerkt. Vastleggen Dit wordt afgeleid wanneer het veld voor de vereffeningsdatum is ingevuld voor het boekhoudkundige document dat bij de creditnota hoort. Gebeurtenistype inferred | |||
| Boekhoudkundig document aangemaakt | Deze gebeurtenis vindt plaats wanneer de creditnota met succes wordt geboekt in de financiële administratie. Daarbij worden de bijbehorende posten in het grootboek aangemaakt en is de creditnota boekhoudkundig officieel. | ||
| Waarom dit belangrijk is Deze activiteit bevestigt dat de creditnota in het financiële systeem is verwerkt. De tijd tussen het aanmaken van de creditnota en de boeking in de financiële administratie kan problemen in de koppeling tussen facturatie en financiën aan het licht brengen. Waar vind je dit? Dit wordt vastgelegd wanneer in de boekhoudingstabel BKPF een documentkop wordt aangemaakt die is gekoppeld aan de creditnota in VBRK (VBRK-BELNR). Vastleggen De gebeurtenis wordt vastgelegd wanneer het factuurdocument met succes in de financiële administratie is geboekt. Gebeurtenistype explicit | |||
| Omruilorder aangemaakt | Deze activiteit staat voor een alternatieve afhandeling: in plaats van een terugbetaling wordt een nieuwe verkooporder aangemaakt om een vervangend artikel naar de klant te sturen. Dit wordt vastgelegd wanneer een nieuwe verkooporder wordt aangemaakt met een verwijzing naar de oorspronkelijke retour. | ||
| Waarom dit belangrijk is Met deze activiteit kun je retouren voor terugbetaling onderscheiden van retouren voor omruiling. Die volgen verschillende procesroutes en leiden tot verschillende resultaten voor de klant. Dit is belangrijk voor variantanalyse. Waar vind je dit? Dit wordt vastgelegd wanneer in VBAK een nieuw verkoopdocument wordt aangemaakt dat via de documentstroomtabel VBFA aan de retourorder is gekoppeld. Vastleggen De gebeurtenis wordt vastgelegd wanneer een nieuwe verkooporder voor een vervangend artikel wordt opgeslagen. Gebeurtenistype explicit | |||
| Retour afgewezen | Dit betekent dat het retourartikel niet voldoet aan de voorwaarden van het retourbeleid en dat de aanvraag voor terugbetaling of tegoed is afgewezen. Dit wordt meestal vastgelegd met een specifieke status of reden op de retourorderregel na de inspectie. | ||
| Waarom dit belangrijk is Door afwijzingen te volgen, kun je nagaan of het retourbeleid wordt nageleefd en veelvoorkomende afwijsredenen opsporen. Dit is een belangrijke uitzonderingsroute in het proces. Waar vind je dit? Dit wordt afgeleid wanneer een afwijsreden (VBAP-ABGRU) is ingesteld op de retourorderregel of wanneer tijdens het inspectieproces in Advanced Returns Management een specifieke status is toegekend. Vastleggen Dit wordt afgeleid wanneer een afwijsreden of een specifieke status ‘afgewezen’ is ingesteld op de regel van het retourdocument. Gebeurtenistype inferred | |||
| Retourlevering aangemaakt | Deze activiteit geeft aan dat een inkomend leveringsdocument is aangemaakt. Dat document wordt gebruikt om de fysieke ontvangst van de retourgoederen te beheren. Het systeem registreert dit expliciet wanneer een leveringsdocument met een verwijzing naar de retourorder wordt aangemaakt. | ||
| Waarom dit belangrijk is Dit is een belangrijke logistieke mijlpaal. De tijd tussen de goedkeuring van de retour en het aanmaken van de levering laat zien hoe efficiënt retourinformatie wordt doorgegeven aan het magazijn of de ontvangstafdeling. Waar vind je dit? Dit wordt vastgelegd wanneer in tabel LIKP een leveringskop wordt aangemaakt. Via de documentstroomtabel VBFA is deze gekoppeld aan de voorafgaande retourorder. Vastleggen De gebeurtenis wordt vastgelegd wanneer een nieuw retourleveringsdocument wordt opgeslagen, bijvoorbeeld met transactie VL01N. Gebeurtenistype explicit | |||
| Retourorder goedgekeurd | Dit is de formele goedkeuring of vrijgave van de retourorder, waarna deze naar de volgende stap kan. Dit wordt meestal afgeleid uit een statuswijziging in de kop of regel van het verkoopdocument, waaruit blijkt dat eventuele blokkades zijn opgeheven. | ||
| Waarom dit belangrijk is Goedkeuringsstappen kunnen veel vertraging veroorzaken. Door deze activiteit te volgen, kun je bottlenecks in de eerste autorisatiefase van het retourproces opsporen. Waar vind je dit? Dit wordt afgeleid uit statustabellen of statusvelden in de tabellen VBAK of VBAP. Een wijziging van de vrijgavestatus of het opheffen van een leveringsblokkade (VBAP-LIFSP) kan op goedkeuring wijzen. Vastleggen Dit wordt afgeleid uit een wijziging in de statusvelden van de kop of regel van de retourorder, waaruit vrijgave of goedkeuring blijkt. Gebeurtenistype inferred | |||
Extractiegidsen
Stappen
- Controleer de vereisten: Controleer of het gebruikersaccount waarmee je de extractie uitvoert de benodigde autorisaties heeft om de vereiste Core Data Services (CDS)-views in SAP S/4HANA te openen. Belangrijke views zijn I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry en I_ClearedItem.
- Open de querytool: Meld je aan bij de SQL-client of dataintegratietool van je keuze die verbinding heeft met de SAP S/4HANA-database. Dit kan een SAP-tool zijn, zoals SAP Analytics Cloud, of een ETL-platform van een andere leverancier.
- Stel de queryparameters in: Pas de meegeleverde SQL-query aan voordat je deze uitvoert. Zoek de tijdelijke waarden op en vervang ze door de juiste parameters voor je omgeving. Stel onder meer
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type]en de filters voor documenttype of bedrijfsnummer in. - Voer de extractiequery uit: Kopieer de volledige SQL-query en voer deze uit in je tool. De query verzamelt de opgegeven activiteiten in één dataset door de resultaten van meerdere SELECT-statements samen te voegen.
- Bekijk de querylogica: Elk
SELECT-blok in deUNION ALL-structuur haalt één specifieke activiteit op. Het combineert meerdere CDS-views om de benodigde attributen te verzamelen, kent een vaste tekenreeks toe alsActivityNameen selecteert de bijbehorende timestamp voorEventTime. - Controleer de ruwe data: Bekijk de uitvoer kort nadat de query is voltooid. Controleer of het aantal rijen aannemelijk is en of belangrijke kolommen zoals
ReturnCaseId,ActivityNameenEventTimenaar verwachting zijn gevuld. - Transformeer de data: De query levert een plat event log op. Meestal zijn er geen grote structurele aanpassingen nodig. Mogelijk moet je wel de timestampnotatie of datatypen aanpassen aan de vereisten van het doelsysteem.
- Exporteer het event log: Exporteer de queryresultaten als CSV-bestand. Gebruik UTF-8-codering om problemen met tekens in bijvoorbeeld gebruikersnamen of productbeschrijvingen te voorkomen.
- Upload naar de process mining-tool: Het CSV-bestand is nu klaar om naar je process mining-platform te uploaden, bijvoorbeeld ProcessMind. Koppel de kolommen uit het bestand aan de bijbehorende velden in de tool, zoals
ReturnCaseIdaan Case-ID,ActivityNameaan Activiteit enEventTimeaan Timestamp.
Configuratie
- Vereisten: De gebruiker die de extractie uitvoert, heeft leesautorisaties nodig voor objecten die betrekking hebben op verkoopdocumenten (VBAK), leveringen (LIKP), facturering (VBRK) en boekhouding (BSEG, BKPF). Toegang tot de onderliggende CDS-views is essentieel.
- Filters voor de datascope: Filter de query op specifieke documenttypen om het retourproces af te bakenen. Stel de tijdelijke waarden in voor retourordertypen (bijvoorbeeld 'RE'), creditnota-aanvraagtypen (bijvoorbeeld 'G2') en omruilordertypen (bijvoorbeeld 'SO'). Het is ook sterk aan te raden om te filteren op
CompanyCodeofSalesOrganization, zodat de datascope beperkt blijft. - Filter op datumbereik: Gebruik altijd een datumbereikfilter om de prestaties en hoeveelheid data te beheersen. Begin met een recente periode van 3 tot 6 maanden. De query gebruikt de aanmaakdatum van de oorspronkelijke retourorder (
I_SalesDocument.CreationDate) als primaire filtervoorwaarde. - Aandachtspunten voor prestaties: Deze uitgebreide query combineert meerdere grote CDS-views. De uitvoering kan veel resources vragen van het bronsysteem S/4HANA. Plan de extractie buiten piekuren om de impact te beperken. Overweeg bij zeer grote datasets een incrementele laadstrategie.
a Voorbeeldquery sql
WITH ReturnOrders AS (
SELECT
SalesDocument AS ReturnCaseId,
CreationDate,
CreationDateTime,
CreatedByUser,
OrderReason,
SoldToParty
FROM I_SalesDocument
WHERE SalesDocumentType = '[Your Return Order Type]' -- e.g., 'RE'
AND CreationDate BETWEEN '[Start Date]' AND '[End Date]'
AND CompanyCode = '[Your Company Code]'
)
-- 1. Return Request Initiated
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Return Request Initiated' AS "ActivityName",
RO.CreationDateTime AS "EventTime",
RO.CreationDateTime AS "EventEndTime",
RO.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM ReturnOrders RO
JOIN I_SalesDocumentItem I ON RO.ReturnCaseId = I.SalesDocument
UNION ALL
-- 2. Return Order Approved
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Order Approved' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus <> 'A' -- Not Open, implying it has been processed/approved
AND I.SDProcessStatus <> 'A'
UNION ALL
-- 3. Return Delivery Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Return Delivery Created' AS "ActivityName",
LH.CreationDateTime AS "EventTime",
LH.CreationDateTime AS "EventEndTime",
LH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
LI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocument AS LH ON DF.SubsequentDocument = LH.DeliveryDocument
JOIN I_DeliveryDocumentItem AS LI ON LH.DeliveryDocument = LI.DeliveryDocument
WHERE DF.PrecedingDocumentCategory = 'C' AND DF.SubsequentDocumentCategory = 'J'
UNION ALL
-- 4. Goods Received at Warehouse
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Goods Received at Warehouse' AS "ActivityName",
MH.CreationDateTime AS "EventTime",
MH.CreationDateTime AS "EventEndTime",
MH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
MI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocumentItem AS LI ON DF.SubsequentDocument = LI.DeliveryDocument AND DF.SubsequentDocumentItem = LI.DeliveryDocumentItem
JOIN I_MaterialDocumentItem AS MI ON LI.DeliveryDocument = MI.DeliveryDocument AND LI.DeliveryDocumentItem = MI.DeliveryDocumentItem
JOIN I_MaterialDocumentHeader AS MH ON MI.MaterialDocument = MH.MaterialDocument AND MI.MaterialDocumentYear = MH.MaterialDocumentYear
WHERE DF.SubsequentDocumentCategory = 'J' AND MH.GoodsMovementType = '[Your Return Goods Receipt MVT]' -- e.g., '651', '653'
UNION ALL
-- 5. Item Inspection Completed
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Item Inspection Completed' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.ReturnsInspectionStatus = '4' -- 'Inspection Completed', adjust value based on your config
UNION ALL
-- 6. Return Rejected
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Return Rejected' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.SalesDocumentItemRejectionReason <> ''
UNION ALL
-- 7. Credit Memo Request Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Request Created' AS "ActivityName",
CM_REQ.CreationDateTime AS "EventTime",
CM_REQ.CreationDateTime AS "EventEndTime",
CM_REQ.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument
JOIN I_SalesDocumentItem I ON CM_REQ.SalesDocument = I.SalesDocument
WHERE CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]' -- e.g., 'CR'
UNION ALL
-- 8. Exchange Order Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Exchange Order Created' AS "ActivityName",
EX_ORD.CreationDateTime AS "EventTime",
EX_ORD.CreationDateTime AS "EventEndTime",
EX_ORD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS EX_ORD ON DF.SubsequentDocument = EX_ORD.SalesDocument
JOIN I_SalesDocumentItem I ON EX_ORD.SalesDocument = I.SalesDocument
WHERE EX_ORD.SalesDocumentType = '[Your Exchange Order Type]' -- e.g., 'OR'
UNION ALL
-- 9. Credit Memo Created
SELECT
DF_CM.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Created' AS "ActivityName",
BD.CreationDateTime AS "EventTime",
BD.CreationDateTime AS "EventEndTime",
BD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
BD.TotalNetAmount AS "RefundAmount",
BDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow AS DF_CM ON CM_REQ.SalesDocument = DF_CM.PrecedingDocument
JOIN I_BillingDocument AS BD ON DF_CM.SubsequentDocument = BD.BillingDocument
JOIN I_BillingDocumentItem AS BDI ON BD.BillingDocument = BDI.BillingDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE DF.PrecedingDocumentCategory = 'C'
UNION ALL
-- 10. Accounting Document Created
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Accounting Document Created' AS "ActivityName",
JE.CreationDateTime AS "EventTime",
JE.CreationDateTime AS "EventEndTime",
JE.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
JE.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_JournalEntry AS JE
JOIN I_JournalEntryItem JRI ON JE.AccountingDocument = JRI.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK'
UNION ALL
-- 11. Refund Processed
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Refund Processed' AS "ActivityName",
CI.ClearingDate AS "EventTime",
CI.ClearingDate AS "EventEndTime",
CI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CI.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_ClearedItem AS CI
JOIN I_JournalEntryItem JRI ON CI.AccountingDocument = JRI.AccountingDocument AND CI.FiscalYear = JRI.FiscalYear AND CI.LedgerGLLineItem = JRI.LedgerGLLineItem
JOIN I_JournalEntry JE ON JRI.AccountingDocument = JE.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK' AND CI.ClearingDate IS NOT NULL
UNION ALL
-- 12. Return Case Closed
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Case Closed' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus = 'C' -- 'Completed' Stappen
- Controleer of je directe leestoegang hebt tot het SAP HANA-schema met de relevante data over verkoop, leveringen, facturering, materiaaldocumenten, inspecties, statussen en boekhouding. De exacte schema’s, views en veldnamen verschillen per SAP S/4HANA-implementatie. Vervang daarom elke tijdelijke waarde tussen vierkante haken door de objecten en velden die in je systeem zijn ingesteld.
- Bepaal de scope van de extractie met [Start date], [End date], [Company Code filter] en [Return document type filter]. Gebruik voor de eerste extractie een voortschrijdende periode van drie tot zes maanden. Verleng die periode pas nadat je de prestaties en volledigheid hebt gecontroleerd.
- Haal de retourorders op uit [Your sales document header table] en [Your sales document item table]. Beperk de selectie tot de documenttypen voor retourorders die zijn ingesteld in [Your return order document type configuration]. Behoud het retourordernummer en het artikelnummer als primaire koppeling met vervolgdocumenten.
- Volg de documentstroom van retourorders naar inkomende retourleveringen, creditnota-aanvragen, omruilorders en creditnota’s via [Your document flow table or view]. Ga er niet van uit dat de documentstroom in VBAK of VBAP is opgeslagen. Stel de relatievelden in volgens het documentstroommodel van het systeem.
- Haal expliciete aanmaakgebeurtenissen op uit de relevante documentkop- en artikelrecords. Haal goedkeurings-, afwijzings-, inspectie-, afsluitings-, goederenontvangst-, boekhoud- en aflettergebeurtenissen op uit de ingestelde bronnen voor statussen, inspecties, materiaaldocumenten, boekhouding en aflettering. Geef elke activiteit als een afzonderlijke eventrij weer, want ProcessMind leidt geen gebeurtenissen af.
- Zet timestamps om naar een consistent databasetimestampformaat en een vaste tijdzone. Gebruik voor elke activiteit de ingestelde prioriteitsvolgorde voor eventtimestamps. Als alleen een datum en tijd beschikbaar zijn, combineer die dan met de tijdzone die is ingesteld in [Your system time zone].
- Vul voor elke gebeurtenis ReturnCaseId in. Gebruik het oorspronkelijke retourordernummer of de ingestelde retourcase-ID als Advanced Returns Management een aparte case-sleutel opslaat. Sluit gebeurtenissen die niet aan een retourcase kunnen worden gekoppeld uit of zet ze in een uitzonderingsbestand om ze te herstellen.
- Vul de verplichte kolommen ReturnCaseId, ActivityName, EventTime, SourceSystemId en LastDataUpdateTimestamp in. Vul waar mogelijk ook de aanbevolen kolommen in, waaronder EventEndTime, UserName, ReturnReason, RefundAmount, ProductId en CustomerId. Gebruik één rij per keer dat een activiteit plaatsvindt en voeg activiteiten niet samen tot één caserij.
- Controleer de resultaten aan de hand van de controles in validationSteps. Bevestig dat alle twaalf activiteitsnamen voorkomen, dat de timestamps per case in een aannemelijke volgorde staan en dat de documentverwijzingen overeenkomen met de brontabellen.
- Exporteer de resultaten als UTF-8-CSV of een ander door ProcessMind ondersteund tabelbestand. Behoud de exacte kolomnamen, gebruik één kopregel en houd timestamps in een eenduidige ISO-notatie. Upload het event log met ReturnCaseId als case-ID en ActivityName als activiteitskolom.
Configuratie
- Datumbereik: Begin met drie tot zes maanden. Gebruik de parameters [Start date] en [End date] en neem voldoende historie mee om cases op te nemen die vóór de gekozen periode zijn gestart, maar erbinnen zijn afgerond.
- Retourpopulatie: Filter op de documenttypen voor retourorders die zijn ingesteld in [Your return order document type configuration]. Leg een documenttype niet vast in de query voordat je hebt gecontroleerd of het in het doelsysteem wordt gebruikt.
- Organisatiefilters: Gebruik filters voor [Company Code filter], verkooporganisatie, distributiekanaal, divisie, vestiging of klant alleen als dat nodig is. Controleer of filters geen vervolgdocumenten tussen bedrijven of binnen hetzelfde concern uitsluiten.
- Bronobjecten: Vervang de tijdelijke waarden [Your table name] en [Your view name] door goedgekeurde SAP S/4HANA-tabellen of CDS-views. VBAK, VBAP, VBRK en VBRP zijn mogelijk beschikbaar in de implementatie, maar controleer het gebruik en eventuele uitbreidingen voordat je de query uitvoert.
- Timestamps verwerken: Stel voor elke activiteit de bronvelden voor timestamps en de tijdzone in. Sla EventTime en EventEndTime op een consistente manier op, bij voorkeur in UTC of in de afgesproken ProcessMind-tijdzone.
- Statussen interpreteren: Stel de exacte statuswaarden, redenencodes, inspectieresultaten en afsluitindicatoren in die in het systeem staan voor goedkeuring, afwijzing, afronding van inspectie en afsluiting van een case.
- Bronsysteem-ID: Vervang [Source system identifier] door een vaste waarde, zoals de SAP-systeem-ID die het extractieplatform gebruikt.
- Verversingstimestamp: Vervang [Extraction timestamp] door de timestamp waarop de query is gestart of waarop de bronsnapshot is gemaakt. Gebruik voor alle rijen in één extractierun dezelfde waarde, tenzij timestamps per rij nodig zijn.
- Prestaties: Beperk eerst de retourpopulatie voordat je grote bronnen voor documentstromen, boekhouding, materiaaldocumenten en statussen combineert. Gebruik geïndexeerde velden of velden waarmee partities kunnen worden overgeslagen, vermijd scans zonder beperkingen en materialiseer tussenresultaten alleen na goedkeuring van de databasebeheerder.
- Incrementele extractie: Gebruik voor terugkerende runs [Last successful extraction timestamp] en een gecontroleerde overlapperiode om late wijzigingen mee te nemen. Verwijder dubbele records op basis van ReturnCaseId, ActivityName, de brondocumentsleutel en EventTime.
- Autorisaties en vereisten: Zorg voor leestoegang tot alle ingestelde bronobjecten en velden, toestemming voor directe databasetoegang en bevestiging dat de vereiste SAP-componenten en functies van Advanced Returns Management actief zijn, waar van toepassing.
- Gegevensbescherming: Beperk klant- en financiële velden tot wat minimaal nodig is, volg de privacyregels van je organisatie en beveilig geëxporteerde bestanden.
a Voorbeeldquery sql
WITH
parameters AS (
SELECT
CAST('[Start date]' AS TIMESTAMP) AS start_ts,
CAST('[End date]' AS TIMESTAMP) AS end_ts,
CAST('[Extraction timestamp]' AS TIMESTAMP) AS extraction_ts,
CAST('[Source system identifier]' AS NVARCHAR(100)) AS source_system_id
FROM DUMMY
),
return_orders AS (
SELECT
h.[Return order number] AS return_case_id,
i.[Return order item number] AS return_item_id,
h.[Return order creation timestamp] AS return_created_ts,
h.[Return order creator] AS return_creator,
h.[Customer number] AS customer_id,
i.[Product number] AS product_id,
i.[Return reason] AS return_reason,
i.[Return order quantity] AS return_quantity,
h.[Company code] AS company_code,
h.[Return order document type] AS return_document_type
FROM [Your sales document header table] h
INNER JOIN [Your sales document item table] i
ON h.[Sales document number] = i.[Sales document number]
CROSS JOIN parameters p
WHERE h.[Return order creation timestamp] >= p.start_ts
AND h.[Return order creation timestamp] < p.end_ts
AND h.[Return order document type] IN ([Your return order document type filter])
AND h.[Company code] IN ([Company Code filter])
),
document_flow AS (
SELECT
ro.return_case_id,
ro.return_item_id,
f.[Preceding document number] AS preceding_document_id,
f.[Preceding item number] AS preceding_item_id,
f.[Subsequent document number] AS subsequent_document_id,
f.[Subsequent item number] AS subsequent_item_id,
f.[Subsequent document category] AS subsequent_document_category,
f.[Document flow creation timestamp] AS flow_created_ts
FROM return_orders ro
LEFT JOIN [Your document flow table or view] f
ON f.[Preceding document number] = ro.return_case_id
AND f.[Preceding item number] = ro.return_item_id
),
return_delivery AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS delivery_id,
df.subsequent_item_id AS delivery_item_id,
d.[Delivery creation timestamp] AS delivery_created_ts,
d.[Delivery creator] AS delivery_creator,
d.[Delivery completion timestamp] AS delivery_completed_ts
FROM document_flow df
INNER JOIN [Your delivery header table] d
ON d.[Delivery number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Inbound delivery document category]'
),
credit_memo_requests AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_request_id,
df.subsequent_item_id AS credit_memo_request_item_id,
c.[Credit memo request creation timestamp] AS request_created_ts,
c.[Credit memo request creator] AS request_creator
FROM document_flow df
INNER JOIN [Your credit memo request header table] c
ON c.[Credit memo request number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo request document category]'
),
exchange_orders AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS exchange_order_id,
df.subsequent_item_id AS exchange_order_item_id,
e.[Exchange order creation timestamp] AS exchange_created_ts,
e.[Exchange order creator] AS exchange_creator
FROM document_flow df
INNER JOIN [Your exchange order header table] e
ON e.[Exchange order number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Exchange order document category]'
),
credit_memos AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_id,
df.subsequent_item_id AS credit_memo_item_id,
b.[Credit memo creation timestamp] AS credit_memo_created_ts,
b.[Credit memo creator] AS credit_memo_creator,
b.[Credit memo amount] AS refund_amount,
b.[Accounting document number] AS accounting_document_id,
b.[Company code] AS billing_company_code
FROM document_flow df
INNER JOIN [Your billing document header table] b
ON b.[Billing document number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo document category]'
),
approval_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Approval timestamp] AS event_ts,
s.[Approval user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your approved or released status values])
),
inspection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Inspection completion timestamp] AS event_ts,
q.[Inspection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection status] IN ([Your completed inspection status values])
),
rejection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Rejection timestamp] AS event_ts,
q.[Rejection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection outcome or rejection code] IN ([Your rejection reason values])
),
goods_receipt_events AS (
SELECT
rd.return_case_id,
rd.return_item_id,
m.[Goods receipt posting timestamp] AS event_ts,
m.[Goods receipt posting user] AS user_name
FROM return_delivery rd
INNER JOIN [Your material document header table] m
ON m.[Reference delivery number] = rd.delivery_id
INNER JOIN [Your material document item table] mi
ON mi.[Material document number] = m.[Material document number]
AND mi.[Material document item number] = [Your material document item linkage]
WHERE m.[Goods movement type] IN ([Your goods receipt movement type values])
),
accounting_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
a.[Accounting posting timestamp] AS event_ts,
a.[Accounting user] AS user_name
FROM credit_memos cm
INNER JOIN [Your accounting document header table] a
ON a.[Accounting document number] = cm.accounting_document_id
AND a.[Company code] = cm.billing_company_code
WHERE a.[Accounting document status] IN ([Your posted accounting status values])
),
refund_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
cl.[Clearing timestamp] AS event_ts,
cl.[Clearing user] AS user_name
FROM credit_memos cm
INNER JOIN [Your customer clearing table or view] cl
ON cl.[Cleared accounting document number] = cm.accounting_document_id
WHERE cl.[Clearing status] IN ([Your completed clearing status values])
),
closure_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Closure timestamp] AS event_ts,
s.[Closure user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your final closed status values])
),
events AS (
SELECT ro.return_case_id, ro.return_item_id, 'Return Request Initiated' AS activity_name, ro.return_created_ts AS event_time, CAST(NULL AS TIMESTAMP) AS event_end_time, ro.return_creator AS user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)) AS refund_amount, ro.product_id, ro.customer_id FROM return_orders ro
UNION ALL
SELECT ae.return_case_id, ae.return_item_id, 'Return Order Approved', ae.event_ts, CAST(NULL AS TIMESTAMP), ae.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM approval_events ae INNER JOIN return_orders ro ON ro.return_case_id = ae.return_case_id AND ro.return_item_id = ae.return_item_id
UNION ALL
SELECT rd.return_case_id, rd.return_item_id, 'Return Delivery Created', rd.delivery_created_ts, rd.delivery_completed_ts, rd.delivery_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM return_delivery rd INNER JOIN return_orders ro ON ro.return_case_id = rd.return_case_id AND ro.return_item_id = rd.return_item_id
UNION ALL
SELECT gr.return_case_id, gr.return_item_id, 'Goods Received at Warehouse', gr.event_ts, CAST(NULL AS TIMESTAMP), gr.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM goods_receipt_events gr INNER JOIN return_orders ro ON ro.return_case_id = gr.return_case_id AND ro.return_item_id = gr.return_item_id
UNION ALL
SELECT ie.return_case_id, ie.return_item_id, 'Item Inspection Completed', ie.event_ts, CAST(NULL AS TIMESTAMP), ie.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM inspection_events ie INNER JOIN return_orders ro ON ro.return_case_id = ie.return_case_id AND ro.return_item_id = ie.return_item_id
UNION ALL
SELECT re.return_case_id, re.return_item_id, 'Return Rejected', re.event_ts, CAST(NULL AS TIMESTAMP), re.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM rejection_events re INNER JOIN return_orders ro ON ro.return_case_id = re.return_case_id AND ro.return_item_id = re.return_item_id
UNION ALL
SELECT cr.return_case_id, cr.return_item_id, 'Credit Memo Request Created', cr.request_created_ts, CAST(NULL AS TIMESTAMP), cr.request_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM credit_memo_requests cr INNER JOIN return_orders ro ON ro.return_case_id = cr.return_case_id AND ro.return_item_id = cr.return_item_id
UNION ALL
SELECT eo.return_case_id, eo.return_item_id, 'Exchange Order Created', eo.exchange_created_ts, CAST(NULL AS TIMESTAMP), eo.exchange_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM exchange_orders eo INNER JOIN return_orders ro ON ro.return_case_id = eo.return_case_id AND ro.return_item_id = eo.return_item_id
UNION ALL
SELECT cm.return_case_id, cm.return_item_id, 'Credit Memo Created', cm.credit_memo_created_ts, CAST(NULL AS TIMESTAMP), cm.credit_memo_creator, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM credit_memos cm INNER JOIN return_orders ro ON ro.return_case_id = cm.return_case_id AND ro.return_item_id = cm.return_item_id
UNION ALL
SELECT ac.return_case_id, ac.return_item_id, 'Accounting Document Created', ac.event_ts, CAST(NULL AS TIMESTAMP), ac.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM accounting_events ac INNER JOIN return_orders ro ON ro.return_case_id = ac.return_case_id AND ro.return_item_id = ac.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ac.return_case_id AND cm.return_item_id = ac.return_item_id
UNION ALL
SELECT rf.return_case_id, rf.return_item_id, 'Refund Processed', rf.event_ts, CAST(NULL AS TIMESTAMP), rf.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM refund_events rf INNER JOIN return_orders ro ON ro.return_case_id = rf.return_case_id AND ro.return_item_id = rf.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = rf.return_case_id AND cm.return_item_id = rf.return_item_id
UNION ALL
SELECT ce.return_case_id, ce.return_item_id, 'Return Case Closed', ce.event_ts, CAST(NULL AS TIMESTAMP), ce.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM closure_events ce INNER JOIN return_orders ro ON ro.return_case_id = ce.return_case_id AND ro.return_item_id = ce.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ce.return_case_id AND cm.return_item_id = ce.return_item_id
)
SELECT
e.return_case_id AS "ReturnCaseId",
e.activity_name AS "ActivityName",
e.event_time AS "EventTime",
e.event_end_time AS "EventEndTime",
e.user_name AS "UserName",
e.return_reason AS "ReturnReason",
e.refund_amount AS "RefundAmount",
e.product_id AS "ProductId",
e.customer_id AS "CustomerId",
p.source_system_id AS "SourceSystemId",
p.extraction_ts AS "LastDataUpdateTimestamp"
FROM events e
CROSS JOIN parameters p
WHERE e.event_time IS NOT NULL
ORDER BY e.return_case_id, e.event_time, e.activity_name; Klaar om aan de slag te gaan?
Met deze template heb je de basiskennis om data over retouren en terugbetalingen te extraheren en te analyseren. Zet vandaag de eerste stap naar betere processen.
Optimaliseer nu het proces voor retouren en terugbetalingen in SAP S/4HANA
Spoor inefficiënties op, verkort de doorlooptijd met 30% en verhoog de tevredenheid.
Je hebt geen creditcard nodig. Begin vandaag met optimaliseren.