Uw datatemplate voor Retour- & Terugbetalingsverwerking
Uw datatemplate voor Retour- & Terugbetalingsverwerking
- Aanbevolen attributen om vast te leggen
- Belangrijkste activiteiten om te volgen
- Richtlijnen voor data-extractie
Attributen voor retouren- & terugbetalingsverwerking
| Naam | Beschrijving | ||
|---|---|---|---|
| Activiteitsnaam ActivityName | De naam van een specifieke bedrijfsactiviteit of gebeurtenis die heeft plaatsgevonden binnen het retour- en terugbetalingsproces. | ||
| Beschrijving Dit attribuut beschrijft een enkele stap of mijlpaal in de returns levenscyclus. Activiteiten vertegenwoordigen het werk dat wordt gedaan, zoals 'Return Order Approved' of 'Item Inspection Completed'. Deze zijn afgeleid van statuswijzigingen, documentcreatie of specifieke gebruikersacties vastgelegd in SAP S/4HANA. Het analyseren van de volgorde en frequentie van deze activiteiten vormt de kern van process mining. Het helpt de proceskaart te visualiseren, veelvoorkomende en zeldzame procespaden te vinden, en activiteiten aan te wijzen die frequent worden herhaald, wat duidt op herstelwerk of inefficiënties. Waarom het belangrijk is Activiteiten vormen de basis van de proceskaart, waardoor de visualisatie en analyse van de processtroom, knelpunten en variaties mogelijk worden. Waar te verkrijgen Activiteitsnamen zijn doorgaans afgeleid van een combinatie van data, zoals documentstatuswijzigingen in tabellen zoals VBUK/VBUP, creatie-gebeurtenissen in headertabellen zoals VBAK (verkoopdocumenten) en BKPF (boekhoudkundige documenten), en goederenbewegingsstatussen in MSEG. Voorbeelden Retouraanvraag GestartGoederen Ontvangen in MagazijnCreditnota aangemaaktTerugbetaling Verwerkt | |||
| Retourcase ID ReturnCaseId | De unieke kenmerk voor een enkel klant retourproces, dat alle gerelateerde activiteiten verbindt van initiatie tot afsluiting. | ||
| Beschrijving De Return Case-ID dient als de primaire kenmerk die alle gebeurtenissen en activiteiten groepeert die behoren tot één retour-instantie. Elk klant retourverzoek krijgt een unieke ID toegewezen, wat end-to-end tracking van het gehele proces mogelijk maakt. In process mining is dit attribuut onmisbaar bij het reconstrueren van de processtroom. Het maakt de analyse mogelijk van doorlooptijden per case, procesvarianten en knelpunten door verschillende gebeurtenissen zoals 'Return Request Initiated', 'Goods Received' en 'Refund Processed' te verbinden tot een coherente tijdlijn voor elke specifieke retour. Waarom het belangrijk is Dit is de essentiële key voor het tracken van een retour van start tot finish, wat alle case-level analysis mogelijk maakt, inclusief doorlooptijd en proces variant discovery. Waar te verkrijgen Dit is typisch het sales document nummer (VBELN) uit de returns order header tabel VBAK, waar de document category (VBTYP) een retour aangeeft. Voorbeelden 600001896000019060000191 | |||
| TijdsTip Gebeurtenis EventTime | De precieze timestamp die aangeeft wanneer een specifieke activiteit plaatsvond. | ||
| Beschrijving Event Time legt de datum en tijd vast dat een zakelijke gebeurtenis in het systeem werd geregistreerd. Deze timestamp is belangrijk voor het chronologisch ordenen van activiteiten en voor alle tijdgebonden analyses. In process mining wordt dit attribuut gebruikt om doorlooptijden tussen activiteiten te berekenen, de duur van elke stap te vinden en de procesprestaties over tijd te analyseren. Het vormt de basis voor het bekijken van knelpunten, het monitoren van SLA-naleving en het begrijpen van de het verloop in de tijd van het retourproces. Waarom het belangrijk is Deze timestamp is belangrijk voor het ordenen van gebeurtenissen, het berekenen van alle duren en doorlooptijden, en het vinden van procesvertragingen. Waar te verkrijgen Typisch afkomstig van datum- en tijd velden geassocieerd met documentcreatie of statuswijzigingen, zoals ERDAT (Creation Date) en ERZET (Creation Time) in tabellen zoals VBAK, LIKP en BKPF, of de posting date (BUDAT) in boekhouding documenten. Voorbeelden 2023-10-26T10:05:00Z2023-10-27T14:30:15Z2023-10-28T09:00:00Z | |||
| Bronsysteem-ID SourceSystemId | Identificatie voor het bronsysteem waaruit de data is opgehaald. | ||
| Beschrijving Dit attribuut specificeert het bronsysteem waar de gebeurtenis data is ontstaan. Voor dit proces zou het typisch de SAP S/4HANA instantie ID zijn. In omgevingen met meerdere systemen is dit veld kritiek voor data lineage, probleemoplossing en het waarborgen van data-integriteit. Het helpt data te differentiëren als retouren worden verwerkt over verschillende ERP-instanties of geïntegreerd zijn met externe systemen zoals een warehouse management system. Waarom het belangrijk is Biedt belangrijke context voor herkomst van de data en -herkomst, vooral in omgevingen met meerdere systemen, en verzekert data traceerbaarheid en vertrouwen. Waar te verkrijgen Deze waarde is meestal statisch en geconfigureerd tijdens data-extractie. Het kan worden opgehaald uit de administratieve Informatie van het SAP-systeem, zoals de System ID (SID). Voorbeelden S4H_PROD_100S4Q_DEV_200 | |||
| Tijdstip van extractie LastDataUpdateTimestamp | De timestamp die aangeeft wanneer de data voor dit gebeurtenis voor het voor het laatst is bijgewerkt of opgehaald. | ||
| Beschrijving Dit attribuut registreert de datum en tijd van de laatste data-extractie of -update. Het biedt metadata over hoe actueel de geanalyseerde data isset. Het is belangrijk voor het begrijpen van de tijdigheid van de process mining-analyse. Gebruikers kunnen zien hoe actueel de data is, wat vooral relevant is voor operationele monitoring en dashboards die lopende cases bijhouden. Waarom het belangrijk is Geeft de relevantie van de data aan, wat belangrijk is om ervoor te zorgen dat analyses en dashboards gebaseerd zijn op actuele Informatie. Waar te verkrijgen Dit wordt doorgaans gegenereerd en gestempeld op de dataset op het moment van data-extractie door de ETL of data pijplijn tool. Voorbeelden 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Eindtijd van het gebeurtenis EventEndTime | De timestamp die de voltooiing van een activiteit markeert, gebruikt voor het berekenen van de duur ervan. | ||
| Beschrijving Waar StartTime (EventTime) het begin van een activity markeert, geeft EventEndTime het einde ervan aan. Voor veel systeem-gegenereerde gebeurtenissen zijn de start- en eindtijden identiek, wat een momentane gebeurtenis vertegenwoordigt. Echter, voor activiteiten met een meetbare duur, zoals 'Item Inspection', is dit attribuut belangrijk. Dit attribuut maakt de directe berekening van de activity verwerkingstijd mogelijk. Dit is onmisbaar voor prestaties analysis en helpt te vinden welke specifieke stappen, en niet alleen de tussenliggende periodes, de meeste tijd in beslag nemen. Waarom het belangrijk is Maakt de precieze berekening van individuele activiteitsduren mogelijk, wat belangrijk is voor het opsporen van inefficiënties binnen specifieke processtappen. Waar te verkrijgen Dit is vaak derived. Voor sommige activiteiten kan het een apart veld zijn. Vaker is het de StartTime van de daaropvolgende activity 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 identificeert de specifieke user of systeemagent die verantwoordelijk is voor het voltooien van een taak, zoals het goedkeuren van een retour of het aanmaken van een creditnota. In SAP wordt dit vaak vastgelegd in velden die de user loggen die een document heeft aangemaakt of gewijzigd. Het analyseren per user helpt bij het vinden van high-performing individuen of teams, trainingsbehoeften en werklastverdeling. Het is ook belangrijk voor het onderzoeken van afwijkingen, aangezien het procesacties koppelt aan specifieke individuen, wat compliance en auditing efforts ondersteunt. Waarom het belangrijk is Wijs procesactiviteiten toe aan specifieke gebruikers, wat analyse van teamprestaties, werkdruk en compliance mogelijk maakt. Waar te verkrijgen Vaak te vinden in documentheadertabellen, zoals ERNAM (Aangemaakt door) in VBAK (Verkooporders), LIKP (Leveringen), en BKPF (Boekhoudkundige Documenten). Gebruikersdetails kunnen worden verrijkt uit de gebruikersmastertabel USR21. Voorbeelden CBROWNASMITHWF_BATCH | |||
| Klant-ID CustomerId | De unieke ID voor de klant die de retour initieert. | ||
| Beschrijving Dit attribuut identificeert de klant die de retour heeft aangevraagd. Het koppelt de proces-instantie aan een specifieke partij in de customer stamdata. Het analyseren van retouren per klant helpt bij het vinden van patronen, zoals klanten met ongewoon hoge retourpercentages, wat kan duiden op frauduleus gedrag of ontevredenheid. Het maakt ook segmentatie van het retourproces mogelijk op basis van klanttype, waarde of historie, wat service levels op maat toelaat. Waarom het belangrijk is Koppelt retouren aan specifieke klanten, wat analyse van klantgedrag, segmentatie en identificatie van frequente retoureerders mogelijk maakt. Waar te verkrijgen Gevonden in het klantnummer veld (KUNNR) in de retourorder headertabel (VBAK). Voorbeelden CUST-001234CUST-005678CUST-009012 | |||
| Product-ID ProductId | De unieke kenmerk voor het geretourneerde item. | ||
| Beschrijving Dit attribuut specificeert het materiaal of product dat het onderwerp is van de retour. Het koppelt het retourproces aan een specifiek item in de productcatalogus. Het analyseren van retouren per product is onmisbaar voor het vinden van items met hoge retourpercentages, wat kan duiden op kwaliteitsdefecten, slechte productbeschrijvingen of fabricageproblemen. Deze data helpt bedrijven weloverwogen beslissingen te nemen over productontwerp, supplier management en voorraadstrategie. Waarom het belangrijk is Koppelt het retourproces aan specifieke producten, wat analyse van retourpercentages op artikelniveau en identificatie van kwaliteits- of beschrijvingsproblemen mogelijk maakt. Waar te verkrijgen Gevonden in het materiaalnummer veld (MATNR) in de retourorder itemtabel (VBAP) of de retourlevering itemtabel (LIPS). Voorbeelden FG-10023HW-45981SW-LICENSE-PREM | |||
| Retourreden ReturnReason | De door de klant opgegeven reden voor het retourneren van het artikel. | ||
| Beschrijving Dit attribuut legt de door de klant opgegeven reden voor de retour vast, zoals 'Defect Item', 'Verkeerde Maat' of 'Niet Langer Nodig'. Dit wordt doorgaans geselecteerd uit een vooraf gedefinieerde lijst van reason codes tijdens het retourinitiatieproces. Het analyseren van retourredenen is belangrijk voor het vinden van productkwaliteitsproblemen, het verbeteren van productbeschrijvingen of het verfijnen van verkoopprocessen. Het biedt direct inzicht in klantontevredenheid en helpt bij het prioriteren van gebieden voor business improvement om het algehele retourpercentage te verminderen. Waarom het belangrijk is Biedt kritiek inzicht in waarom retouren plaatsvinden, en maakt oorzaakanalyse mogelijk om productkwaliteit, fulfilmentfouten of hiaten in klantverwachtingen aan te pakken. Waar te verkrijgen Typisch opgeslagen in de retour sales order item table (VBAP) in het veld ABGRU (Reason for rejection of sales documents). Voorbeelden 001 - Slechte Kwaliteit002 - Beschadigd tijdens Transport005 - Verkeerd Artikel Verzonden | |||
| Terugbetalingsbedrag RefundAmount | De uiteindelijke financiële waarde van de aan de klant uitgevoerde terugbetaling. | ||
| Beschrijving Dit attribuut vertegenwoordigt het daadwerkelijke bedrag dat aan de klant wordt gecrediteerd of terugbetaald na voltooiing van het retourproces. Deze waarde wordt vastgelegd in financiële documenten zoals creditnota's. Dit is een belangrijke financiële metriek die wordt gebruikt in diverse analyses. Het is belangrijk voor het 'Refund Bedrag Discrepancy Analysis' dashboard om te vergelijken met het aangevraagde bedrag. Het maakt ook segmentatie van retouren per waarde mogelijk om te vinden of high-waarde retouren een ander proces volgen of langer duren om op te lossen. Waarom het belangrijk is Trackt de financiële impact van retouren en is belangrijk voor het analyseren van de nauwkeurigheid van terugbetalingen, het vinden van high-waarde cases en het begrijpen van de totale kosten. Waar te verkrijgen Afkomstig van het netwaarde veld (NETWR) van het creditnota-document, te vinden in tabellen zoals VBRK (Billing Document Header) of BSEG (Boekhouding Document Segment). Voorbeelden 125.50999.0049.99 | |||
| Aangevraagd terugbetalingsbedrag RequestedRefundAmount | Het terugbetalingsbedrag dat aanvankelijk werd aangevraagd of verwacht aan het begin van het proces. | ||
| Beschrijving Dit attribuut legt de waarde vast van de geretourneerde goederen volgens het initiële retourverzoek. Het dient als een basislijn waartegen het uiteindelijke terugbetaalde bedrag kan worden vergeleken. Dit veld is specifiek vereist voor het 'Refund Bedrag Discrepancy Analysis' dashboard. Het vergelijken van het aangevraagde bedrag met het werkelijke terugbetalingsbedrag helpt bij het vinden van problemen zoals gedeeltelijke terugbetalingen als gevolg van itemschade, restocking fees of andere aanpassingen, wat financiële nauwkeurigheid en transparantie waarborgt. Waarom het belangrijk is Dient als basislijn voor het meten van de nauwkeurigheid van terugbetalingen, en helpt bij het vinden en analyseren van verschillen tussen verwachte en werkelijke terugbetalingswaarden. Waar te verkrijgen Typisch afkomstig van de netwaarde van de items op de initiële retour sales order. Dit zou de netwaarde (NETWR) zijn van de corresponderende line items in de VBAP tabel. Voorbeelden 125.501050.0049.99 | |||
| Credit Memo Nummer CreditMemoNumber | De unieke kenmerk voor het creditnota-document, dat de terugbetaling autoriseert. | ||
| Beschrijving Een creditnota is het factureringsdocument dat het account van de klant officieel crediteert voor de geretourneerde artikelen. Dit attribuut is het unieke nummer van dat financiële document. Het traceren van het Creditnota Nummer is belangrijk voor het analyseren van het financiële afwikkelingsgedeelte van het retourproces. Het markeert een kritieke mijlpaal, initieert vaak de feitelijke terugbetaling, en is noodzakelijk voor financiële reconciliatie en auditing. Waarom het belangrijk is Vertegenwoordigt de officiële financiële transactie voor de terugbetaling, belangrijk voor het volgen van de laatste fasen van het proces en voor financiële auditing. Waar te verkrijgen Dit is het billing document nummer (VBELN) uit de billing document header tabel (VBRK), waar de document category een creditnota aangeeft. Voorbeelden 900003459000034690000347 | |||
| Is Geautomatiseerd IsAutomated | Een indicator die aangeeft of een activiteit werd uitgevoerd door een systeem of een mens. | ||
| Beschrijving Dit boolean attribuut onderscheidt activiteiten die automatisch door een systeem worden uitgevoerd, zoals een workflow of background job, en die handmatig door een user worden uitgevoerd. Het is belangrijk voor het berekenen van de 'Automated Refund Approval Rate' KPI en voor het vinden van mogelijkheden om automatisering te verhogen. Door te filteren op manual taken, kunnen bedrijven hun procesverbeteringsinspanningen richten op gebieden waar automatisering de meest significante voordelen kan opleveren wat betreft snelheid, kosten en nauwkeurigheid. Waarom het belangrijk is Onderscheidt handmatige en geautomatiseerde taken, wat belangrijk is voor het vinden van automatiseringsmogelijkheden en het meten van de impact van digitale transformatie. Waar te verkrijgen Dit is typisch derived op basis van de Gebruiker Naam. Bijvoorbeeld, als de user 'WF_BATCH' is of een andere system ID, wordt de activity geflagged als geautomatiseerd. Voorbeelden truefalse | |||
| Is herstelwerk IsRework | Een indicator die aangeeft of een activiteit in een case een herhaling is van een eerdere activiteit. | ||
| Beschrijving Dit berekende boolean attribuut identificeert instanties van herstelwerk, waarbij een activity meer dan eens wordt uitgevoerd binnen dezelfde case. Bijvoorbeeld, als een iteminspectie moet worden herhaald of een creditnota wordt aangemaakt, geannuleerd en vervolgens opnieuw wordt aangemaakt. Dit attribuut is belangrijk voor het 'Refund Processing Rework Analysis' dashboard en de 'Refund Rework Rate' KPI. Het helpt procesinefficiëntie te kwantificeren door activiteiten te belichten die gevoelig zijn voor fouten of meerdere pogingen vereisen, wat wijst op gebieden die betere controls of training nodig hebben. Waarom het belangrijk is Belicht procesinefficiënties en -fouten door herhaald werk te markeren, wat gerichte verbeteringen mogelijk maakt om verspilling en vertragingen te verminderen. Waar te verkrijgen Deze flag wordt doorgaans berekend door de process mining-tool zelf of kan vooraf worden berekend in de datatransformatie. Het controleert of dezelfde activity naam eerder in dezelfde case is verschenen. Voorbeelden truefalse | |||
| Naleving Retourbeleid ReturnPolicyAdherence | Een indicator die aangeeft of de retourcase voldoet aan het gedefinieerde retourbeleid. | ||
| Beschrijving Dit berekende boolean attribuut geeft aan of een retour voldoet aan de criteria die zijn vastgelegd in het toepasselijke retourbeleid. De logic zou bijvoorbeeld kunnen controleren of de retour is geïnitieerd binnen de toegestane termijn of dat de retourreden geldig is voor het product. Dit attribuut ondersteunt direct het 'Return Policy Compliance Overzicht' dashboard. Het kwantificeert compliance rates en maakt het mogelijk om in te zoomen op non-compliant cases om de redenen voor afwijkingen te begrijpen, wat helpt om beleid effectiever te handhaven. Waarom het belangrijk is Kwantificeert naleving van business rules, en helpt bij het vinden en verminderen van beleidsovertredingen die de winstgevendheid kunnen beïnvloeden of procesuitzonderingen kunnen creëren. Waar te verkrijgen Berekend op basis van bedrijfsregels. Bijvoorbeeld, (Datum Aanvraag Retour - Originele Aankoopdatum) <= [Toegestane Retourdagen]. Dit vereist de Originele Aankoopdatum en de beleidsregels. Voorbeelden truefalse | |||
| Processende Agent ProcessingAgent | De specifieke agent of brongroep verantwoordelijk voor het afhandelen van een handmatige activity. | ||
| Beschrijving Dit attribuut identificeert de persoon of het team dat een bepaalde taak heeft uitgevoerd. Het kan specifieker zijn dan de 'Gebruiker Naam' door te verwijzen naar een rol of een team, vooral in een shared services omgeving. Dit is waardevol voor het 'Refund Approval Efficiency' dashboard om de prestaties van verschillende medewerkers of teams te analyseren. Het helpt bij het begrijpen van werklastverdeling, het vinden van trainingsbehoeften, en het erkennen van top performers of teams die best practices kunnen delen. Waarom het belangrijk is Maakt prestatieanalyse op agent- of teamniveau mogelijk, helpt bij het beheren van de werkdruk, het vinden van trainingsmogelijkheden en het verbeteren van de efficiency. Waar te verkrijgen Deze Informatie kan beschikbaar zijn via SAP Business Partner functies als medewerkers zijn toegewezen, of het kan worden afgeleid van de user's afdeling of rol in de HR organisatorische structuur. Voorbeelden Tier 1 SupportWarehouse InspectieteamAfdeling Financiën - AP | |||
| Refund SLA Target Datum RefundSlaTargetDate | De streefdatum waarop de terugbetaling voor de retourcase verwerkt moet zijn. | ||
| Beschrijving Dit attribuut definieert de Service Level Agreement (SLA) deadline voor het processen van de terugbetaling. Deze datum wordt meestal berekend op basis van business rules, bijvoorbeeld een bepaald aantal dagen nadat de retour is goedgekeurd of goederen zijn ontvangen. Dit veld is de basis voor het 'Refund SLA Adherence Monitoring' dashboard en de bijbehorende KPI. Het maakt proactieve tracking mogelijk van cases die risico lopen hun SLA te overschrijden en voor het analyseren van de grondoorzaken van vertragingen, wat uiteindelijk helpt de klanttevredenheid te verbeteren. Waarom het belangrijk is Biedt de basis voor het meten van SLA-compliance, en helpt bij het monitoren van prestaties, het prioriteren van achterstallige cases en het verbeteren van klanttevredenheid. Waar te verkrijgen Dit is bijna altijd een derived veld. De logic zou gebaseerd zijn op een key date (bijv. retourverzoek aanmaakdatum) plus een duur gedefinieerd door business rules, wat kan afhangen van factoren zoals klanttype of retourreden. Voorbeelden 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
| Resultaat Artikelinspectie ItemInspectionOutcome | Het resultaat van de fysieke inspectie van het geretourneerde item. | ||
| Beschrijving Dit attribuut registreert de uitkomst van het inspectieproces dat wordt uitgevoerd nadat de goederen zijn ontvangen in het warehouse. Gangbare uitkomsten zijn 'Accepted', 'Afgekeurd - Beschadigd' of 'Accepted - Verkoopbaar'. Deze data biedt belangrijke context voor volgende processtappen. Het bepaalt of een volledige terugbetaling, een gedeeltelijke terugbetaling of geen terugbetaling wordt uitgegeven. Het analyseren van deze uitkomst helpt bij het vinden van redenen voor afwijzingen en kan feedback geven over productverpakkingen of verzendpartners als items frequent beschadigd raken tijdens transport. Waarom het belangrijk is Verklaart het besluitvormingsproces achter goedkeuringen of afwijzingen van terugbetalingen, en biedt waardevolle data over de conditie van artikelen en redenen voor aanpassingen van terugbetalingen. Waar te verkrijgen Deze Informatie kan worden vastgelegd in een quality management module (QM) inspectielot, of als een status of reason code op het retourleveringsregelitem (LIPS). Het kan ook bestaan in een aangepast veld. Voorbeelden Geaccepteerd - HerverkoopbaarGeaccepteerd - Te refurbishenAfgekeurd - Schade door klantAfgekeurd - Verkeerd item geretourneerd | |||
| Retour Leveringsnummer ReturnDeliveryNumber | De unieke kenmerk voor het retourleveringsdocument. | ||
| Beschrijving Wanneer een klant fysiek goederen retourneert, wordt in SAP een return delivery document aangemaakt om de inbound logistics te beheren. Dit attribuut is het unieke nummer van dat document. Deze ID is belangrijk voor het tracken van de fysieke beweging van de geretourneerde goederen. Het verbindt de financiële en logistieke aspecten van de retour, wat gedetailleerde analyse van de goederenontvangst- en inspectiefasen van het proces mogelijk maakt. Waarom het belangrijk is Biedt een belangrijke link tussen de retouraanvraag en de fysieke ontvangst van goederen, belangrijk voor het analyseren van logistieke en warehouse verwerkingstijden. Waar te verkrijgen Dit is het delivery document nummer (VBELN) uit de delivery header tabel (LIKP), waar de document category een return delivery aangeeft. Voorbeelden 840000128400001384000014 | |||
| Retourbeleid ID ReturnPolicyId | De kenmerk van het retourbeleid dat van toepassing is op deze specifieke retourcase. | ||
| Beschrijving Dit attribuut geeft aan welk specifiek retourbeleid of welke set van rules van toepassing is op de transactie. Beleid kan variëren op basis van producttype, klantsegment of tijd sinds aankoop. Deze gegevens zijn belangrijk voor het 'Return Policy Compliance Overzicht'. Door elke case te associëren met een beleid, kan het systeem automatisch controleren op adherence aan rules, zoals retourdeadlines of itemconditievereisten, en afwijkingen markeren voor analyse. Waarom het belangrijk is Maakt geautomatiseerde compliance-controles tegen bedrijfsregels mogelijk, wat helpt te waarborgen dat retouren consistent en volgens beleid worden verwerkt. Waar te verkrijgen Dit is vaak geen standaard SAP veld en moet mogelijk worden derived op basis van business logic met behulp van data zoals producttype, klant en verkoopdatum. Het kan worden opgeslagen in een aangepast veld indien geïmplementeerd. Voorbeelden STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| Retourorderstatus ReturnOrderStatus | De huidige algemene status van de retourcase. | ||
| Beschrijving Dit attribuut biedt een high-level status van de retourcase op elk gegeven moment, zoals 'Open', 'In Process' of 'Gesloten'. Dit is vaak een aggregate status afgeleid van de laatst voltooide belangrijke mijlpaal. Dit is belangrijk voor het 'Current Return Case Status Dashboard', dat een operationeel overzicht biedt van de huidige workload en case-distributie. Het helpt managers te begrijpen hoeveel cases zich in elke fase van het proces bevinden, wat een betere toewijzing van middelen en werkdrukbeheer mogelijk maakt. Waarom het belangrijk is Biedt een momentopname van waar elke case zich in het proces bevindt, wat belangrijk is voor operationele dashboards die de huidige workload en status bijhouden. Waar te verkrijgen Afgeleid van de statusvelden op de relevante documenten. Bijvoorbeeld, van de headerstatus (GBSTK) of itemstatus (LFSTK) in de gerelateerde verkooporder (VBUK/VBUP) of leveringsdocumenten. Voorbeelden Wachten op GoederenontvangstWacht op InspectieWacht op TerugbetalingGesloten | |||
| SLA-naleving Terugbetaling RefundSlaAdherence | Een indicator die aangeeft of de terugbetaling binnen de Service Level Agreement (SLA) doelstelling is verwerkt. | ||
| Beschrijving Dit berekende attribuut controleert of de 'Refund Processed' activity plaatsvond op of vóór de 'Refund SLA Target Date'. Het geeft een eenvoudige true of false indicator van SLA-compliance voor elke case. Dit is de belangrijkste statistiek voor het 'Refund SLA Adherence Monitoring' dashboard en de 'Refund SLA Adherence Rate' KPI. Het helpt de prestaties te meten ten opzichte van klantverbintenissen en identificeert cases die niet aan de verwachtingen voldeden, wat oorzaakanalyse van vertragingen mogelijk maakt. Waarom het belangrijk is Meet direct de prestaties ten opzichte van klantgerichte toezeggingen, waardoor het een kritieke indicator is voor servicekwaliteit en klanttevredenheid. Waar te verkrijgen Berekend door de EventTime van de activiteit 'Refund Processed' te vergelijken met de 'RefundSLA-streefdatum' voor elke case. Voorbeelden truefalse | |||
| Verkooporganisatie SalesOrganization | De onderdeel verantwoordelijk voor de oorspronkelijke verkoop en de retour. | ||
| Beschrijving De Sales Organization is een belangrijk organisatorisch structuurelement in SAP dat een eenheid vertegenwoordigt die verantwoordelijk is voor de verkoop en distributie van producten en diensten. Het is toegewezen aan de retourtransactie. Dit attribuut maakt het mogelijk om het retourproces te filteren en te vergelijken tussen verschillende bedrijfsonderdelen, regio's of divisies. Het helpt bij het vinden of bepaalde sales organizations hogere retourpercentages of minder efficiënte retourverwerkingsprocessen hebben, wat een basis biedt voor organisatorische prestaties-analyse. Waarom het belangrijk is Maakt vergelijking van de prestaties en percentages van het retourproces mogelijk tussen verschillende bedrijfsonderdelen, regio's of verkoopkanalen. Waar te verkrijgen Gevonden in het verkooporganisatie veld (VKORG) in de retourorder headertabel (VBAK). Voorbeelden 10002100US01 | |||
Activiteiten voor retouren- & terugbetalingsverwerking
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Artikelinspectie voltooid | Vertegenwoordigt de voltooiing van de kwaliteits- en conditiebeoordeling van de geretourneerde goederen. In Advanced Returns Management is dit vaak een expliciete stap die de inspectie-uitkomst vastlegt en de daaropvolgende actie bepaalt, zoals terugbetaling of afschrijven. | ||
| Waarom het belangrijk is De duur en uitkomst van de inspectie hebben directe impact op de terugbetalingsverwerkingstijd en het voorraadbeheer. Deze activity is belangrijk voor het analyseren van inspectie-efficiëntie en herstelwerk. Waar te verkrijgen In SAP Advanced Returns Management (ARM) kan dit een expliciete gebeurtenis zijn vanuit de inspectietransactie. Het kan ook worden afgeleid uit een statuswijziging op het retourorderitem die het inspecpakketesultaat aangeeft. Vastleggen Vastgelegd uit transactielogs of statuswijzigingen gerelateerd aan de logistieke follow-up activiteiten in ARM. Gebeurtenistype explicit | |||
| Creditnota aangemaakt | Dit is de creatie van het officiële billing document dat de account van de klant crediteert voor het geretourneerde item. Dit is een expliciet gebeurtenis vastgelegd wanneer de creditnota wordt gegenereerd uit het creditnota-verzoek. | ||
| Waarom het belangrijk is Het aanmaken van de creditnota is een kritieke financiële mijlpaal. Het bevestigt het terug te betalen bedrag en autoriseert het betalingsproces om te beginnen. Waar te verkrijgen Vastgelegd vanuit de creatie van een factureringsdocument in tabel VBRK met een documentcategorie die een creditnota aangeeft. Dit is gekoppeld aan de creditnota-aanvraag in tabel VBFA. Vastleggen Event wordt geregistreerd bij het opslaan van een nieuw creditnota factureringsdocument (bijv. met transactie VF01). Gebeurtenistype explicit | |||
| Creditnota-aanvraag aangemaakt | Na een succesvolle inspectie markeert deze activiteit de creatie van een aanvraag om een creditnota aan de klant uit te reiken. Dit wordt vastgelegd als een nieuw verkoopdocument, een creditnota aanvraag, die verwijst naar de oorspronkelijke retourorder. | ||
| Waarom het belangrijk is Dit is de trigger voor het financiële settlement gedeelte van het retourproces. Het analyseren van de tijd van inspectie tot deze stap onthult efficiëntie in de handoff van logistics naar finance. Waar te verkrijgen Vastgelegd vanuit de creatie van een verkoopdocument in tabel VBAK met een documentcategorie voor Creditnota Aanvraag. De koppeling naar de retour wordt onderhouden in de documentstroomtabel VBFA. Vastleggen Event wordt geregistreerd bij het opslaan van een nieuw creditnota aanvraagdocument. Gebeurtenistype explicit | |||
| Goederen Ontvangen in Magazijn | Dit gebeurtenis markeert de fysieke ontvangst van het geretourneerde item in het warehouse of verwerkingscentrum. Het wordt expliciet vastgelegd wanneer een Post Goods Receipt (PGR) wordt uitgevoerd tegen de retourlevering, waardoor een material document wordt gecreëerd. | ||
| Waarom het belangrijk is Dit is een kritieke mijlpaal die de klok start voor inspectie en afhandeling. Vertragingen vóór dit punt zijn klantgedreven, terwijl vertragingen erna intern zijn. Waar te verkrijgen Vastgelegd uit de materiaaldocumenttabellen MSEG en MKPF voor het goederenontvangstbewegingstype dat geassocieerd is met retouren. De boekingsdatum (MKPF-BUDAT) geeft de gebeurtenis time aan. Vastleggen Event komt overeen met het boeken van een goederenontvangst voor de retourlevering. Gebeurtenistype explicit | |||
| Retouraanvraag Gestart | Dit is het startpunt van het retourproces, waar een retouraanvraag formeel in het systeem wordt aangemaakt. Dit gebeurtenis wordt expliciet vastgelegd wanneer een nieuw sales document van het return order type wordt opgeslagen in SAP S/4HANA. | ||
| Waarom het belangrijk is Deze activity markeert de officiële start van de retourcase levenscyclus. Het analyseren van de tijd vanaf dit gebeurtenis tot de afsluiting is belangrijk voor het meten van de totale retour doorlooptijd en de klantervaring. Waar te verkrijgen Dit is een expliciet gebeurtenis vastgelegd uit de creatie van een sales document in tabel VBAK waar de document category (VBAK-VBTYP) een return order aangeeft. De creation timestamp is VBAK-ERDAT. Vastleggen Event wordt geregistreerd bij het opslaan van een nieuwe retourverkooporder (bijv. met transactie VA01). Gebeurtenistype explicit | |||
| Retourcase afgesloten | Dit is de laatste activity, wat aangeeft dat het retourproces is voltooid en er geen verdere acties worden verwacht voor de case. Dit wordt doorgaans afgeleid wanneer het retouraanvraagdocument een definitieve, gesloten status bereikt in het systeem. | ||
| Waarom het belangrijk is Dit gebeurtenis definieert het einde van de proces levenscyclus, wat de berekening van de totale end-to-end doorlooptijd mogelijk maakt. Het bevestigt dat de case volledig is opgelost. Waar te verkrijgen Afgeleid van de algehele status van de retourorder in tabel VBAK of de items ervan in VBAP die een 'Voltooid' of 'Gesloten' staat bereiken. Dit wordt bepaald door de statusbeheerconfiguratie van het systeem. Vastleggen Afgeleid van de retourorder documentstatus die verandert naar 'Voltooid'. Gebeurtenistype inferred | |||
| Terugbetaling Verwerkt | Deze activity markeert de laatste stap van het terugbetalingsproces, waarbij het financiële credit wordt afgehandeld, wat betekent dat de betaling naar de klant is gestuurd. Dit wordt afgeleid uit de creatie van een clearing document in de finance module dat het openstaande credit op de klantrekening vereffent. | ||
| Waarom het belangrijk is Dit is het moment waarop de klant daadwerkelijk wordt betaald. De tijd die nodig is om deze stap te bereiken vanaf de retourinitiatie is een belangrijke driver van klanttevredenheid en belangrijk voor het meten van SLA-naleving. Waar te verkrijgen Afgeleid van de clearing documentInformatie in de financiële boekhouding regelitemtabel BSEG. De vereffeningsdatum (BSEG-AUGDT) op het klantregelitem geassocieerd met de creditnota geeft aan wanneer de terugbetaling is verwerkt. Vastleggen Afgeleid van het vereffeningsdatumveld dat is ingevuld voor het boekhoudkundige document geassocieerd met de creditnota. Gebeurtenistype inferred | |||
| Boekingsdocument Aangemaakt | Dit gebeurtenis vindt plaats wanneer de creditnota succesvol wordt geboekt in de financiële boekhouding module. Het creëert corresponderende entries in het general ledger, waardoor het credit officieel wordt vanuit een boekhouding perspectief. | ||
| Waarom het belangrijk is Deze activity bevestigt dat de credit is geïntegreerd in het financiële systeem. De tijd tussen het aanmaken van de creditnota en het boeken in de boekhouding kan problemen in de billing-to-finance interface belichten. Waar te verkrijgen Vastgelegd vanuit de creatie van een documentheader in de boekhoudtabel BKPF, die is gekoppeld aan de creditnota in VBRK (VBRK-BELNR). Vastleggen Event wordt geregistreerd bij de succesvolle boeking van het factureringsdocument naar Financiële Boekhouding. Gebeurtenistype explicit | |||
| Retour geweigerd | Geeft aan dat het geretourneerde artikel niet voldeed aan de retourbeleidscriteria en de aanvraag voor een terugbetaling of creditnota is geweigerd. Dit wordt doorgaans vastgelegd door een specifieke status of redencode die na inspectie wordt toegepast op het retourorderitem. | ||
| Waarom het belangrijk is Het tracken van afwijzingen helpt bij het analyseren van naleving van retourbeleid en het vinden van veelvoorkomende redenen voor afwijzing. Het is een belangrijke exception path in het proces. Waar te verkrijgen Afgeleid van een afwijsreden (VBAP-ABGRU) die is ingesteld op het retourorderitem of een specifieke status die is toegewezen tijdens het inspectieproces in Advanced Returns Management. Vastleggen Afgeleid van het instellen van een afwijsreden of een specifieke 'afgewezen' status op het retourdocumentitem. Gebeurtenistype inferred | |||
| Retour Order Goedgekeurd | Vertegenwoordigt de formele goedkeuring of vrijgave van de retouraanvraag, waardoor deze naar de volgende fase kan overgaan. Dit wordt doorgaans afgeleid van een statuswijziging op de header of het item van het verkoopdocument, wat aangeeft dat het is vrijgegeven van eventuele blokkeringen. | ||
| Waarom het belangrijk is Goedkeuringsstappen kunnen een aanzienlijke bron van vertraging zijn. Het traceren van deze activiteit helpt bij het vinden van knelpunten in de initiële autorisatiefase van het retourproces. Waar te verkrijgen Afgeleid van statusbeheertabellen of statusvelden direct binnen de VBAK- of VBAP-tabellen. Een wijziging in een vrijgavestatus of het verwijderen van een leveringsblokkering (VBAP-LIFSP) kan goedkeuring betekenen. Vastleggen Afgeleid van een wijziging in de header- of itemstatusvelden van de retourorder die vrijgave of goedkeuring aangeeft. Gebeurtenistype inferred | |||
| Retourlevering aangemaakt | Deze activity duidt op de creatie van een inbound delivery document, dat wordt gebruikt om de fysieke ontvangst van de geretourneerde goederen te beheren. Het systeem registreert dit als een expliciete creation gebeurtenis voor een delivery document dat verwijst naar de return order. | ||
| Waarom het belangrijk is Deze stap is een belangrijke logistieke mijlpaal. De tijd tussen retourapproval en delivery creation benadrukt de efficiëntie van het communiceren van retourInformatie aan het warehouse of de ontvangende afdeling. Waar te verkrijgen Vastgelegd vanuit de creatie van een leveringsheader in tabel LIKP, gekoppeld aan de voorafgaande retourorder via de documentstroomtabel VBFA. Vastleggen Event wordt geregistreerd bij het opslaan van een nieuw retourleveringsdocument (bijv. met transactie VL01N). Gebeurtenistype explicit | |||
| Ruilorder aangemaakt | Deze activity vertegenwoordigt een alternatieve oplossing waarbij, in plaats van een terugbetaling, een nieuwe sales order wordt aangemaakt om een vervangend item naar de klant te verzenden. Dit wordt vastgelegd wanneer een nieuwe sales order wordt aangemaakt met een referentie naar de oorspronkelijke retour. | ||
| Waarom het belangrijk is Deze activity helpt onderscheid te maken tussen retouren voor terugbetaling en retouren voor ruiling, die verschillende procespaden en klantuitkomsten hebben. Het is belangrijk voor variantanalyse. Waar te verkrijgen Vastgelegd vanuit de creatie van een nieuw verkoopdocument in VBAK dat is gekoppeld aan de retourorder in de documentstroomtabel (VBFA). Vastleggen Event wordt geregistreerd bij het opslaan van een nieuw verkooporderdocument dat is aangewezen als een vervanging. Gebeurtenistype explicit | |||
Extractiegidsen
Stappen
- Verificatie Verplichten: Zorg ervoor dat het gebruikersaccount dat de extractie uitvoert de nodige autorisaties heeft in SAP S/4HANA om toegang te krijgen tot de vereiste Core Data Services (CDS) Views. Belangrijke views omvatten I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry, en I_ClearedItem.
- Toegang Query Tool: Log in bij uw voorkeur SQL client of data-integratie tool die een verbinding heeft met de SAP S/4HANA database. Dit kan een van SAP's eigen tools zijn, zoals SAP Analytics Cloud, of een extern ETL-platform.
- Query Parameters Instellen: Voordat u uitvoert, moet u de geleverde SQL query aanpassen. Zoek de placeholder waarden en vervang deze door de juiste parameters voor uw omgeving. Dit omvat het instellen van de
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type], en andere documenttype- of bedrijfscodefilters. - Voer de Extractiequery Uit: Kopieer de volledige SQL query en voer deze uit in uw tool. De query is ontworpen om alle gespecificeerde activiteiten te verzamelen in één dataset door de resultaten van meerdere select-statements te unioneren.
- Begrijp de Query Logica: Elk
SELECTblok in deUNION ALLstructuur is verantwoordelijk voor het extraheren van één specifieke activiteit. Het combineert meerdere CDS views om de vereiste attributen te verzamelen, wijst een vaste string toe als deActiviteitNaam, en selecteert de relevante timestamp voor deEventTime. - Bekijk de Ruwe Data: Nadat de query is voltooid, voert u een korte beoordeling uit van de uitvoer. Controleer op een redelijk aantal rijen en zorg ervoor dat belangrijke kolommen zoals
ReturnCaseId,ActiviteitNaam, enEventTimenaar verwachting zijn ingevuld. - Datatransformatie: De query is gestructureerd om een platte event log format te produceren. Er zijn doorgaans geen significante structurele transformaties nodig. U moet echter mogelijk timestamp-formats of datatypes aanpassen, afhankelijk van de vereisten van uw doelsysteem.
- Exporteer de Event Log: Exporteer de queryresultatenset als een CSV-bestand. Zorg ervoor dat het bestand UTF-8-codering gebruikt om karakterproblemen te voorkomen, vooral met gebruikersnamen of productbeschrijvingen.
- Upload naar Process Mining Tool: Het resulterende CSV-bestand is nu klaar om te worden geüpload naar uw process mining platform, zoals ProcessMind. Map de kolommen uit het bestand naar de corresponderende velden in de tool, bijvoorbeeld
ReturnCaseIdnaar Case-ID,ActiviteitNaamnaar Activiteit, enEventTimenaar Timestamp.
Configuratie
- Verplichten: De uitvoerende gebruiker heeft display-autorisaties nodig voor objecten gerelateerd aan verkoopdocumenten (VBAK), leveringen (LIKP), facturering (VBRK), en boekhouding (BSEG, BKPF). Toegang tot de onderliggende CDS views is belangrijk.
- Dataomvangfilters: Het is belangrijk om de query te filteren op specifieke documenttypen om het retourproces te isoleren. Configureer de placeholders voor retourordertypen (bijv. 'RE'), creditnota-aanvraagtypen (bijv. 'G2'), en omruilordertypen (bijv. 'SO'). Filteren op
CompanyCodeofSalesOrganizationwordt ook sterk aanbevolen om de dataomvang te beperken. - Datumbereikfiltering: Om de prestaties en het datavolume te beheren, dient u altijd een datumbereikfilter toe te passen. Begin met een recente periode van 3 tot 6 maanden aan data. De query gebruikt de aanmaakdatum van de initiële retourorder (
I_SalesDocument.CreationDate) als de primaire filterconditie. - Prestatieoverwegingen: Dit is een volledige query die meerdere grote CDS views combineert. De uitvoering kan bron-intensief zijn op het bron S/4HANA-systeem. Plan de extractie tijdens daluren om de impact te minimaliseren. Voor zeer grote datasets, overweeg incrementele laadstrategieën.
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
- Verificatie Verplichten: Zorg ervoor dat het gebruikersaccount dat de extractie uitvoert de nodige autorisaties heeft in SAP S/4HANA om toegang te krijgen tot de vereiste Core Data Services (CDS) Views. Belangrijke views omvatten I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry, en I_ClearedItem.
- Toegang Query Tool: Log in bij uw voorkeur SQL client of data-integratie tool die een verbinding heeft met de SAP S/4HANA database. Dit kan een van SAP's eigen tools zijn, zoals SAP Analytics Cloud, of een extern ETL-platform.
- Query Parameters Instellen: Voordat u uitvoert, moet u de geleverde SQL query aanpassen. Zoek de placeholder waarden en vervang deze door de juiste parameters voor uw omgeving. Dit omvat het instellen van de
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type], en andere documenttype- of bedrijfscodefilters. - Voer de Extractiequery Uit: Kopieer de volledige SQL query en voer deze uit in uw tool. De query is ontworpen om alle gespecificeerde activiteiten te verzamelen in één dataset door de resultaten van meerdere select-statements te unioneren.
- Begrijp de Query Logica: Elk
SELECTblok in deUNION ALLstructuur is verantwoordelijk voor het extraheren van één specifieke activiteit. Het combineert meerdere CDS views om de vereiste attributen te verzamelen, wijst een vaste string toe als deActiviteitNaam, en selecteert de relevante timestamp voor deEventTime. - Bekijk de Ruwe Data: Nadat de query is voltooid, voert u een korte beoordeling uit van de uitvoer. Controleer op een redelijk aantal rijen en zorg ervoor dat belangrijke kolommen zoals
ReturnCaseId,ActiviteitNaam, enEventTimenaar verwachting zijn ingevuld. - Datatransformatie: De query is gestructureerd om een platte event log format te produceren. Er zijn doorgaans geen significante structurele transformaties nodig. U moet echter mogelijk timestamp-formats of datatypes aanpassen, afhankelijk van de vereisten van uw doelsysteem.
- Exporteer de Event Log: Exporteer de queryresultatenset als een CSV-bestand. Zorg ervoor dat het bestand UTF-8-codering gebruikt om karakterproblemen te voorkomen, vooral met gebruikersnamen of productbeschrijvingen.
- Upload naar Process Mining Tool: Het resulterende CSV-bestand is nu klaar om te worden geüpload naar uw process mining platform, zoals ProcessMind. Map de kolommen uit het bestand naar de corresponderende velden in de tool, bijvoorbeeld
ReturnCaseIdnaar Case-ID,ActiviteitNaamnaar Activiteit, enEventTimenaar Timestamp.
Configuratie
- Verplichten: De uitvoerende gebruiker heeft display-autorisaties nodig voor objecten gerelateerd aan verkoopdocumenten (VBAK), leveringen (LIKP), facturering (VBRK), en boekhouding (BSEG, BKPF). Toegang tot de onderliggende CDS views is belangrijk.
- Dataomvangfilters: Het is belangrijk om de query te filteren op specifieke documenttypen om het retourproces te isoleren. Configureer de placeholders voor retourordertypen (bijv. 'RE'), creditnota-aanvraagtypen (bijv. 'G2'), en omruilordertypen (bijv. 'SO'). Filteren op
CompanyCodeofSalesOrganizationwordt ook sterk aanbevolen om de dataomvang te beperken. - Datumbereikfiltering: Om de prestaties en het datavolume te beheren, dient u altijd een datumbereikfilter toe te passen. Begin met een recente periode van 3 tot 6 maanden aan data. De query gebruikt de aanmaakdatum van de initiële retourorder (
I_SalesDocument.CreationDate) als de primaire filterconditie. - Prestatieoverwegingen: Dit is een volledige query die meerdere grote CDS views combineert. De uitvoering kan bron-intensief zijn op het bron S/4HANA-systeem. Plan de extractie tijdens daluren om de impact te minimaliseren. Voor zeer grote datasets, overweeg incrementele laadstrategieën.
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'