Uw Data Template voor Retour- & Terugbetalingsverwerking
Uw Data Template voor Retour- & Terugbetalingsverwerking
- Aanbevolen attributen om vast te leggen
- Belangrijkste activiteiten om te volgen
- Richtlijnen voor data-extractie
Retour- & Terugbetalingsverwerking Attributes
| Naam | Omschrijving | ||
|---|---|---|---|
| Activiteitsnaam ActivityName | De naam van een specifieke business activity of event die heeft plaatsgevonden binnen het retour- en terugbetalingsproces. | ||
| Omschrijving Dit attribute beschrijft een enkele stap of mijlpaal in de returns lifecycle. Activities 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 sequentie en frequentie van deze activities is de kern van process mining. Het helpt de proces map te visualiseren, veelvoorkomende en zeldzame procespaden te identificeren, en activities aan te wijzen die frequent worden herhaald, wat duidt op rework of inefficiënties. Het belang Activiteiten vormen de ruggengraat van de proceskaart, waardoor de visualisatie en analyse van de processtroom, knelpunten en variaties mogelijk wordt. Vindplaats Activiteitsnamen zijn doorgaans afgeleid van een combinatie van data, zoals documentstatuswijzigingen in tabellen zoals VBUK/VBUP, creatie-events in headertabellen zoals VBAK (verkoopdocumenten) en BKPF (boekhoudkundige documenten), en goederenbewegingsstatussen in MSEG. Voorbeelden Retourverzoek GeïnitieerdGoederen Ontvangen in MagazijnCreditnota aangemaaktTerugbetaling Verwerkt | |||
| Retour Case ID ReturnCaseId | De unieke identifier voor een enkel klant retourproces, dat alle gerelateerde activities verbindt van initiatie tot afsluiting. | ||
| Omschrijving De Return Case ID dient als de primaire identifier die alle events en activities groepeert die behoren tot één retour-instance. Elk klant retourverzoek krijgt een unieke ID toegewezen, wat end-to-end tracking van het gehele proces mogelijk maakt. In process mining is dit attribute fundamenteel voor het reconstrueren van de proces flow. Het maakt de analyse mogelijk van case-duren, procesvarianten en bottlenecks door verschillende events zoals 'Return Request Initiated', 'Goods Received' en 'Refund Processed' te verbinden tot een coherente tijdlijn voor elke specifieke retour. Het belang Dit is de essentiële key voor het tracken van een retour van start tot finish, wat alle case-level analysis mogelijk maakt, inclusief cycle time en proces variant discovery. Vindplaats 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 activity plaatsvond. | ||
| Omschrijving Event Time legt de datum en tijd vast dat een zakelijke gebeurtenis in het systeem werd geregistreerd. Deze timestamp is cruciaal voor het chronologisch ordenen van activiteiten en voor alle tijdgebaseerde analyses. In process mining wordt dit attribuut gebruikt om doorlooptijden tussen activiteiten te berekenen, de duur van elke stap te identificeren en de procesprestaties over tijd te analyseren. Het vormt de basis voor het ontdekken van knelpunten, het monitoren van SLA-naleving en het begrijpen van de temporele dynamiek van het retourproces. Het belang Deze timestamp is essentieel voor het ordenen van events, het berekenen van alle duren en cycle times, en het identificeren van procesvertragingen. Vindplaats Typisch afkomstig van datum- en tijd fields 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 accounting 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 werd geëxtraheerd. | ||
| Omschrijving Dit attribute specificeert het system of record waar de event data is ontstaan. Voor dit proces zou het typisch de SAP S/4HANA instance ID zijn. In omgevingen met meerdere systemen is dit field kritiek voor data lineage, troubleshooting en het waarborgen van data-integriteit. Het helpt data te differentiëren als retouren worden verwerkt over verschillende ERP-instances of geïntegreerd zijn met externe systemen zoals een warehouse management system. Het belang Biedt cruciale context voor data-oorsprong en -herkomst, vooral in multi-systeem landschappen, en verzekert data traceability en vertrouwen. Vindplaats 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 | |||
| Laatste data-update LastDataUpdateTimestamp | De timestamp die aangeeft wanneer de data voor dit event voor het laatst is ververst of geëxtraheerd. | ||
| Omschrijving Dit attribute registreert de datum en tijd van de laatste data-extractie of -update. Het biedt metadata over de versheid van de geanalyseerde dataset. 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. Het belang Geeft de actualiteit van de data aan, wat cruciaal is om ervoor te zorgen dat analyses en dashboards gebaseerd zijn op actuele informatie. Vindplaats Dit wordt doorgaans gegenereerd en gestempeld op de dataset op het moment van data-extractie door de ETL of data pipeline tool. Voorbeelden 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Eindtijd van het event EventEndTime | De timestamp die de voltooiing van een activiteit markeert, gebruikt voor het berekenen van de duur ervan. | ||
| Omschrijving Waar StartTime (EventTime) het begin van een activity markeert, geeft EventEndTime het einde ervan aan. Voor veel systeem-gegenereerde events zijn de start- en eindtijden identiek, wat een momentane gebeurtenis vertegenwoordigt. Echter, voor activities met een meetbare duur, zoals 'Item Inspection', is dit attribute cruciaal. Dit attribute maakt de directe berekening van de activity processing time mogelijk. Dit is fundamenteel voor performance analysis en helpt te identificeren welke specifieke stappen, en niet alleen de tussenliggende periodes, de meeste tijd in beslag nemen. Het belang Maakt de precieze berekening van individuele activiteitsduren mogelijk, wat essentieel is voor het opsporen van inefficiënties binnen specifieke processtappen. Vindplaats Dit is vaak derived. Voor sommige activities kan het een apart field 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. | ||
| Omschrijving Dit attribute 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 fields die de user loggen die een document heeft aangemaakt of gewijzigd. Het analyseren per user helpt bij het identificeren van high-performing individuen of teams, trainingsbehoeften en workload-distributie. Het is ook essentieel voor het onderzoeken van afwijkingen, aangezien het procesacties koppelt aan specifieke individuen, wat compliance en auditing efforts ondersteunt. Het belang Wijs procesactiviteiten toe aan specifieke gebruikers, wat analyse van teamprestaties, werkdruk en compliance mogelijk maakt. Vindplaats Vaak te vinden in documentheader tabellen, 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 identifier voor de klant die de retour initieert. | ||
| Omschrijving Dit attribute identificeert de klant die de retour heeft aangevraagd. Het koppelt de proces-instance aan een specifieke partij in de customer master data. Het analyseren van retouren per klant helpt bij het identificeren 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. Het belang Koppelt retouren aan specifieke klanten, wat analyse van klantgedrag, segmentatie en identificatie van frequente retoureerders mogelijk maakt. Vindplaats Gevonden in het klantnummer veld (KUNNR) in de retourorder headertabel (VBAK). Voorbeelden CUST-001234CUST-005678CUST-009012 | |||
| Product-ID ProductId | De unieke identifier voor het geretourneerde item. | ||
| Omschrijving Dit attribute specificeert het materiaal of product dat het onderwerp is van de retour. Het koppelt het retourproces aan een specifiek item in de product catalogus. Het analyseren van retouren per product is fundamenteel voor het identificeren 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. Het belang Koppelt het retourproces aan specifieke producten, wat analyse van retourpercentages op artikelniveau en identificatie van kwaliteits- of beschrijvingsproblemen mogelijk maakt. Vindplaats 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 item. | ||
| Omschrijving Dit attribute 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 cruciaal voor het identificeren 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. Het belang Biedt kritiek inzicht in waarom retouren plaatsvinden, en maakt root cause analysis mogelijk om productkwaliteit, fulfilmentfouten of hiaten in klantverwachtingen aan te pakken. Vindplaats Typisch opgeslagen in de retour sales order item table (VBAP) in het field ABGRU (Reason for rejection of sales documents). Voorbeelden 001 - Slechte Kwaliteit002 - Beschadigd tijdens Transport005 - Verkeerd Artikel Verzonden | |||
| Terugbetalingsbedrag RefundAmount | De uiteindelijke monetaire waarde van de aan de klant uitgevoerde terugbetaling. | ||
| Omschrijving Dit attribute 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 metric die wordt gebruikt in diverse analyses. Het is essentieel voor het 'Refund Amount Discrepancy Analysis' dashboard om te vergelijken met het aangevraagde bedrag. Het maakt ook segmentatie van retouren per waarde mogelijk om te identificeren of high-value retouren een ander proces volgen of langer duren om op te lossen. Het belang Trackt de financiële impact van retouren en is essentieel voor het analyseren van de nauwkeurigheid van terugbetalingen, het identificeren van high-value cases en het begrijpen van de totale kosten. Vindplaats Afkomstig van het netwaarde veld (NETWR) van het creditnota-document, te vinden in tabellen zoals VBRK (Billing Document Header) of BSEG (Accounting Document Segment). Voorbeelden 125.50999.0049.99 | |||
| Aangevraagd Terugbetalingsbedrag RequestedRefundAmount | Het terugbetalingsbedrag dat aanvankelijk werd aangevraagd of verwacht aan het begin van het proces. | ||
| Omschrijving Dit attribute legt de waarde vast van de geretourneerde goederen volgens het initiële retourverzoek. Het dient als een baseline waartegen het uiteindelijke terugbetaalde bedrag kan worden vergeleken. Dit field is specifiek vereist voor het 'Refund Amount Discrepancy Analysis' dashboard. Het vergelijken van het aangevraagde bedrag met het werkelijke terugbetalingsbedrag helpt bij het identificeren van problemen zoals gedeeltelijke terugbetalingen als gevolg van itemschade, restocking fees of andere aanpassingen, wat financiële nauwkeurigheid en transparantie waarborgt. Het belang Dient als baseline voor het meten van de nauwkeurigheid van terugbetalingen, en helpt bij het identificeren en analyseren van discrepanties tussen verwachte en werkelijke terugbetalingswaarden. Vindplaats 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 | |||
| Creditnota Nummer CreditMemoNumber | De unieke identifier voor het creditnota-document, dat de terugbetaling autoriseert. | ||
| Omschrijving 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 essentieel 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. Het belang Vertegenwoordigt de officiële financiële transactie voor de terugbetaling, cruciaal voor het volgen van de laatste fasen van het proces en voor financiële auditing. Vindplaats Dit is het billing document nummer (VBELN) uit de billing document header tabel (VBRK), waar de document category een creditnota aangeeft. Voorbeelden 900003459000034690000347 | |||
| Doorlooptijd per case CycleTime | De totale verstreken tijd vanaf de initiatie tot de afsluiting van een retour case. | ||
| Omschrijving Deze berekende metric meet de end-to-end duur van het gehele retourproces voor een enkele case. Het wordt doorgaans berekend als het tijdsverschil tussen de eerste en laatste events, zoals van 'Return Request Initiated' tot 'Return Case Closed'. Cycle Time is een primaire KPI voor procesefficiëntie. Het wordt gebruikt in het 'Overall Return Cycle Time' dashboard om performance te monitoren, benchmarks in te stellen en trends te identificeren. Het analyseren van de factoren die correleren met langere cycle times, zoals producttype of retourreden, kan systemische inefficiënties onthullen. Het belang Dit is een fundamentele KPI voor het meten van de algehele procesefficiëntie en heeft directe impact op klanttevredenheid en operationele kosten. Vindplaats Dit is een berekend field. Het wordt berekend door het verschil te nemen tussen de maximum en minimum EventTime voor elke unieke ReturnCaseId. Voorbeelden 5d 4h 30m12d 2h 15m2d 8h 0m | |||
| Is Geautomatiseerd IsAutomated | Een indicator die aangeeft of een activiteit werd uitgevoerd door een systeem of een mens. | ||
| Omschrijving Dit boolean attribute onderscheidt activities die automatisch door een systeem worden uitgevoerd, zoals een workflow of background job, en die handmatig door een user worden uitgevoerd. Het is essentieel voor het berekenen van de 'Automated Refund Approval Rate' KPI en voor het identificeren van mogelijkheden om automatisering te verhogen. Door te filteren op manual tasks, kunnen bedrijven hun procesverbeteringsinspanningen richten op gebieden waar automatisering de meest significante voordelen kan opleveren wat betreft snelheid, kosten en nauwkeurigheid. Het belang Onderscheidt handmatige en geautomatiseerde taken, wat cruciaal is voor het identificeren van automatiseringsmogelijkheden en het meten van de impact van digitale transformatie. Vindplaats Dit is typisch derived op basis van de User Name. 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. | ||
| Omschrijving Dit berekende boolean attribute identificeert instances van rework, 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 attribute is essentieel voor het 'Refund Processing Rework Analysis' dashboard en de 'Refund Rework Rate' KPI. Het helpt procesinefficiëntie te kwantificeren door activities te belichten die gevoelig zijn voor fouten of meerdere pogingen vereisen, wat wijst op gebieden die betere controls of training nodig hebben. Het belang Belicht procesinefficiënties en -fouten door herhaald werk te markeren, wat gerichte verbeteringen mogelijk maakt om verspilling en vertragingen te verminderen. Vindplaats Deze flag wordt doorgaans berekend door de process mining tool zelf of kan vooraf worden berekend in de data transformatie. Het controleert of dezelfde activity naam eerder in dezelfde case is verschenen. Voorbeelden truefalse | |||
| Naleving Retourbeleid ReturnPolicyAdherence | Een indicator die aangeeft of de retour case voldoet aan het gedefinieerde retourbeleid. | ||
| Omschrijving Dit berekende boolean attribute 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 attribute ondersteunt direct het 'Return Policy Compliance Overview' 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. Het belang Kwantificeert compliance met business rules, en helpt bij het identificeren en verminderen van beleidsovertredingen die de winstgevendheid kunnen beïnvloeden of procesuitzonderingen kunnen creëren. Vindplaats Berekend op basis van bedrijfsregels. Bijvoorbeeld, (Datum Aanvraag Retour - Originele Aankoopdatum) <= [Toegestane Retourdagen]. Dit vereist de Originele Aankoopdatum en de beleidsregels. Voorbeelden truefalse | |||
| Resultaat Artikelinspectie ItemInspectionOutcome | Het resultaat van de fysieke inspectie van het geretourneerde item. | ||
| Omschrijving Dit attribute 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 cruciale 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 identificeren van redenen voor afwijzingen en kan feedback geven over productverpakkingen of verzendpartners als items frequent beschadigd raken tijdens transport. Het belang Verklaart het besluitvormingsproces achter goedkeuringen of afwijzingen van terugbetalingen, en biedt waardevolle data over de conditie van artikelen en redenen voor aanpassingen van terugbetalingen. Vindplaats 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 custom field. Voorbeelden Geaccepteerd - HerverkoopbaarGeaccepteerd - Te refurbishenAfgekeurd - Schade door klantAfgekeurd - Verkeerd item geretourneerd | |||
| Retour Leveringsnummer ReturnDeliveryNumber | De unieke identifier voor het retourleveringsdocument. | ||
| Omschrijving Wanneer een klant fysiek goederen retourneert, wordt in SAP een return delivery document aangemaakt om de inbound logistics te beheren. Dit attribute 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. Het belang Biedt een cruciale link tussen de retouraanvraag en de fysieke ontvangst van goederen, essentieel voor het analyseren van logistieke en warehouse verwerkingstijden. Vindplaats Dit is het delivery document nummer (VBELN) uit de delivery header tabel (LIKP), waar de document category een return delivery aangeeft. Voorbeelden 840000128400001384000014 | |||
| Retour Orderstatus ReturnOrderStatus | De huidige algemene status van de retour case. | ||
| Omschrijving Dit attribute biedt een high-level status van de retour case 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 essentieel 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 resource-allocatie en workload management mogelijk maakt. Het belang Biedt een momentopname van waar elke case zich in het proces bevindt, wat essentieel is voor operationele dashboards die de huidige workload en status bijhouden. Vindplaats 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 Wacht op GoederenontvangstWacht op InspectieWacht op TerugbetalingGesloten | |||
| Retourbeleid ID ReturnPolicyId | De identifier van het retourbeleid dat van toepassing is op deze specifieke retour case. | ||
| Omschrijving Dit attribute 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 data is essentieel voor het 'Return Policy Compliance Overview'. 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. Het belang Maakt geautomatiseerde compliance-controles tegen bedrijfsregels mogelijk, wat helpt te waarborgen dat retouren consistent en volgens beleid worden verwerkt. Vindplaats Dit is vaak geen standaard SAP field 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 custom field indien geïmplementeerd. Voorbeelden STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| SLA-naleving Terugbetaling RefundSlaAdherence | Een indicator die aangeeft of de terugbetaling binnen de Service Level Agreement (SLA) doelstelling is verwerkt. | ||
| Omschrijving Dit berekende attribute 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 kern metric voor het 'Refund SLA Adherence Monitoring' dashboard en de 'Refund SLA Adherence Rate' KPI. Het helpt de performance te meten ten opzichte van klantverbintenissen en identificeert cases die niet aan de verwachtingen voldeden, wat root cause analysis van vertragingen mogelijk maakt. Het belang Meet direct de prestaties ten opzichte van klantgerichte toezeggingen, waardoor het een kritieke indicator is voor servicekwaliteit en klanttevredenheid. Vindplaats Berekend door de EventTime van de activiteit 'Refund Processed' te vergelijken met de 'RefundSlaTargetDate' voor elke case. Voorbeelden truefalse | |||
| SLA-streefdatum Terugbetaling RefundSlaTargetDate | De streefdatum waarop de terugbetaling voor de retour case verwerkt moet zijn. | ||
| Omschrijving Dit attribute definieert de Service Level Agreement (SLA) deadline voor het verwerken 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 field 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 root causes van vertragingen, wat uiteindelijk helpt de klanttevredenheid te verbeteren. Het belang Biedt de basis voor het meten van SLA compliance, en helpt bij het monitoren van performance, het prioriteren van achterstallige cases en het verbeteren van klanttevredenheid. Vindplaats Dit is bijna altijd een derived field. 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 | |||
| Verkooporganisatie SalesOrganization | De organisatorische eenheid verantwoordelijk voor de oorspronkelijke verkoop en de retour. | ||
| Omschrijving De Sales Organization is een essentieel 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 attribute maakt het mogelijk om het retourproces te filteren en te vergelijken tussen verschillende business units, regio's of divisies. Het helpt bij het identificeren of bepaalde sales organizations hogere retourpercentages of minder efficiënte retourverwerkingsprocessen hebben, wat een basis biedt voor organisatorische performance-analyse. Het belang Maakt vergelijking van de prestaties en percentages van het retourproces mogelijk over verschillende bedrijfseenheden, regio's of verkoopkanalen. Vindplaats Gevonden in het verkooporganisatie veld (VKORG) in de retourorder headertabel (VBAK). Voorbeelden 10002100US01 | |||
| Verwerkingsagent ProcessingAgent | De specifieke agent of resourcegroep verantwoordelijk voor het afhandelen van een handmatige activity. | ||
| Omschrijving Dit attribute identificeert de persoon of het team dat een bepaalde taak heeft uitgevoerd. Het kan specifieker zijn dan de 'User Name' 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 performance van verschillende agents of teams te analyseren. Het helpt bij het begrijpen van workload-distributie, het identificeren van trainingsbehoeften, en het erkennen van top performers of teams die best practices kunnen delen. Het belang Maakt prestatieanalyse op agent- of teamniveau mogelijk, helpt bij het beheren van de werkdruk, het identificeren van trainingsmogelijkheden en het verbeteren van de efficiëntie. Vindplaats Deze informatie kan beschikbaar zijn via SAP Business Partner functies als agents 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 | |||
Retour- & Terugbetalingsverwerking Activities
| Activiteit | Omschrijving | ||
|---|---|---|---|
| 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. | ||
| Het belang De duur en uitkomst van de inspectie hebben directe impact op de terugbetalingsverwerkingstijd en het voorraadbeheer. Deze activity is van vitaal belang voor het analyseren van inspectie-efficiëntie en rework. Vindplaats 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 inspectieresultaat 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 event vastgelegd wanneer de creditnota wordt gegenereerd uit het creditnota-verzoek. | ||
| Het belang 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. Vindplaats 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. | ||
| Het belang 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. Vindplaats 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 event 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. | ||
| Het belang 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. Vindplaats Vastgelegd uit de materiaaldocumenttabellen MSEG en MKPF voor het goederenontvangstbewegingstype dat geassocieerd is met retouren. De boekingsdatum (MKPF-BUDAT) geeft de event time aan. Vastleggen Event komt overeen met het boeken van een goederenontvangst voor de retourlevering. Gebeurtenistype explicit | |||
| Retour Case 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. | ||
| Het belang Dit event definieert het einde van de proces lifecycle, wat de berekening van de totale end-to-end cycle time mogelijk maakt. Het bevestigt dat de case volledig is opgelost. Vindplaats 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 | |||
| Retourverzoek Geïnitieerd | Dit is het startpunt van het retourproces, waar een retouraanvraag formeel in het systeem wordt aangemaakt. Dit event wordt expliciet vastgelegd wanneer een nieuw sales document van het return order type wordt opgeslagen in SAP S/4HANA. | ||
| Het belang Deze activity markeert de officiële start van de retour case lifecycle. Het analyseren van de tijd vanaf dit event tot de afsluiting is cruciaal voor het meten van de totale retour cycle time en de klantervaring. Vindplaats Dit is een expliciet event 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 | |||
| 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. | ||
| Het belang 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 cruciaal voor het meten van SLA adherence. Vindplaats Afgeleid van de clearing documentinformatie in de financiële boekhouding regelitemtabel BSEG. De clearing datum (BSEG-AUGDT) op het klantregelitem geassocieerd met de creditnota geeft aan wanneer de terugbetaling is verwerkt. Vastleggen Afgeleid van het clearing datumveld dat is ingevuld voor het boekhoudkundige document geassocieerd met de creditnota. Gebeurtenistype inferred | |||
| Boekingsdocument Aangemaakt | Dit event vindt plaats wanneer de creditnota succesvol wordt geboekt in de financiële accounting module. Het creëert corresponderende entries in het general ledger, waardoor het credit officieel wordt vanuit een accounting perspectief. | ||
| Het belang 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 accounting kan problemen in de billing-to-finance interface belichten. Vindplaats 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 | |||
| Omruilorder 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. | ||
| Het belang Deze activity helpt onderscheid te maken tussen retouren voor terugbetaling en retouren voor ruiling, die verschillende procespaden en klantuitkomsten hebben. Het is cruciaal voor variant analysis. Vindplaats 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 | |||
| Retour Afgewezen | 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 reden code die na inspectie wordt toegepast op het retourorderitem. | ||
| Het belang Het tracken van afwijzingen helpt bij het analyseren van compliance met retourbeleid en het identificeren van veelvoorkomende redenen voor afwijzing. Het is een belangrijke exception path in het proces. Vindplaats 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. | ||
| Het belang Goedkeuringsstappen kunnen een aanzienlijke bron van vertraging zijn. Het traceren van deze activiteit helpt bij het identificeren van knelpunten in de initiële autorisatiefase van het retourproces. Vindplaats 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 event voor een delivery document dat verwijst naar de return order. | ||
| Het belang 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. Vindplaats 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 | |||
Extractie Guides
Stappen
- Verificatie Vereisten: 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 deActivityName, 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,ActivityName, 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,ActivityNamenaar Activity, enEventTimenaar Timestamp.
Configuratie
- Vereisten: 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 essentieel.
- Dataomvangfilters: Het is cruciaal 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 uitgebreide query die meerdere grote CDS views combineert. De uitvoering kan resource-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 Vereisten: 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 deActivityName, 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,ActivityName, 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,ActivityNamenaar Activity, enEventTimenaar Timestamp.
Configuratie
- Vereisten: 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 essentieel.
- Dataomvangfilters: Het is cruciaal 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 uitgebreide query die meerdere grote CDS views combineert. De uitvoering kan resource-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'