Data Template: Order to Cash - Sales Order Processing
Uw Order to Cash - Datatemplate voor Verkooporderverwerking.
- Aanbevolen attributen om vast te leggen
- Belangrijkste activiteiten om te volgen
- Extractiehandleiding voor SAP ECC
Order to Cash - Attributes Verkooporderverwerking
| Naam | Beschrijving | ||
|---|---|---|---|
Verkooporder SalesOrder | De unieke identificatie voor een verkooporderdocument, dat dient als de primaire case voor het volgen van het gehele Order-to-Cashproces. | ||
Beschrijving De Verkooporder is het centrale document in het verkoopproces, dat het verzoek van een klant om goederen of diensten vertegenwoordigt. Het bevat alle informatie die nodig is om het verzoek van de klant van begin tot eind te verwerken. In process mining wordt dit attribuut gebruikt als de Case ID. Elk uniek Verkoopordernummer vertegenwoordigt één end-to-end procesinstantie. Het analyseren van processen op basis van de Verkooporder maakt het mogelijk de complete levenscyclus te volgen, doorlooptijden te meten en variaties voor elke individuele klantorder te identificeren. Waarom het belangrijk is Dit is de sleutel om alle gerelateerde activiteiten en events te koppelen, zodat u het volledige end‑to‑end‑traject van elke klantorder kunt analyseren. Waar te verkrijgen Te vinden in de Sales Document Header Data tabel (VBAK) als het veld VBELN. Voorbeelden 900001234590000123469000012347 | |||
Activiteit Activity | De naam van een specifieke bedrijfsstap of event die plaatsvond binnen het verkooporderproces. | ||
Beschrijving Dit attribuut beschrijft een enkele stap in het Order-to-Cash proces, zoals 'Verkooporder Aangemaakt', 'Levering Aangemaakt' of 'Betaling Ontvangen'. Deze activiteiten zijn de bouwstenen die worden gebruikt om de processtroom voor elke verkooporder te reconstrueren. Het analyseren van de opeenvolging en het tijdstip van deze activiteiten vormt de kern van Process Mining. Het helpt bij het visualiseren van de proceskaart, het identificeren van knelpunten, het ontdekken van procesvarianten en het controleren op compliance met een standaardmodel. Activiteiten zijn doorgaans afgeleid van een combinatie van events voor documentcreatie, statuswijzigingen of specifieke transactiecodes die in het systeem zijn vastgelegd. Waarom het belangrijk is Activiteiten vormen de ruggengraat van de proceskaart, waardoor visualisatie en analyse van de process flow, afwijkingen en knelpunten mogelijk zijn. Waar te verkrijgen Dit is een afgeleid attribute, meestal gegenereerd tijdens data-extractie door SAP transactiecodes (T-Codes), wijzigingen in documentstatus (bijv. uit tabellen VBUK, VBUP) of wijzigingslogboeken (tabellen CDHDR, CDPOS) te koppelen aan gebruiksvriendelijke activiteitsnamen. Voorbeelden Verkooporder aangemaaktLevering AangemaaktGoederen UitgegevenFactuur aangemaaktBetaling Ontvangen | |||
Bronsysteem SourceSystem | Identificeert het bronsysteem waaruit de data is geëxtraheerd. | ||
Beschrijving Dit attribuut specificeert het bronsysteem, bijvoorbeeld een specifieke SAP ECC-instantienaam of clientnummer. Het biedt context voor de data, met name in omgevingen met meerdere productiesystemen of data van legacy-systemen. In de analyse wordt het gebruikt om data te filteren of te segmenteren op basis van de oorsprong. Dit is bijzonder nuttig voor het vergelijken van processen over verschillende systemen of tijdens systeemmigratieprojecten om data-integriteit en consistentie te waarborgen. Waarom het belangrijk is Biedt essentiële context, met name in multi-systeemlandschappen, waardoor procesvergelijking mogelijk is en de data lineage duidelijk is. Waar te verkrijgen Deze waarde wordt doorgaans toegevoegd tijdens het data-extractieproces en is vaak een statische waarde die de SAP Systeem ID (SAPSID) of client (MANDT) vertegenwoordigt. Voorbeelden ECC_PROD_800SAP_ERP_EU1ECC_QAS_300 | |||
Laatste data-update LastDataUpdate | Timestamp die aangeeft wanneer de data voor dit record voor het laatst is ververst vanuit het bronsysteem. | ||
Beschrijving Dit attribuut registreert de datum en tijd van de meest recente data-extractie of update voor een gegeven event of case. Het biedt transparantie over de actualiteit van de data die wordt geanalyseerd. In dashboards en rapporten is deze informatie cruciaal voor gebruikers om de tijdigheid van de inzichten te begrijpen. Het helpt bevestigen of de analyse de meest actuele operationele status weerspiegelt of gebaseerd is op oudere data, en helpt zo de verwachtingen van de gebruiker over de actualiteit van de data te beheren. Waarom het belangrijk is Zorgt ervoor dat gebruikers op de hoogte zijn van de actualiteit van de data, wat cruciaal is voor het nemen van tijdige en weloverwogen beslissingen op basis van de process mining-analyse. Waar te verkrijgen Dit is een metadata-attribute dat wordt ingevuld door de data-extractietool of het proces op het moment van data-inname. Het is niet opgeslagen in de bron SAP-tabellen. Voorbeelden 2024-06-10T05:00:00Z2024-06-11T05:00:00Z2024-06-12T05:00:00Z | |||
Starttijd StartTime | De timestamp die aangeeft wanneer een activiteit of event begon. | ||
Beschrijving De Starttijd, ook bekend als de event timestamp, registreert de exacte datum en tijd waarop een specifieke activiteit plaatsvond. Zo legt het bijvoorbeeld vast wanneer een verkooporder werd aangemaakt, wanneer goederen werden uitgegeven, of wanneer een factuur werd geboekt. Deze timestamp is fundamenteel voor alle tijdsgebonden analyses in process mining. Het wordt gebruikt om doorlooptijden tussen activiteiten te berekenen, de totale duur van een case te meten en vertragingen of knelpunten te identificeren. Nauwkeurige timestamps zijn cruciaal voor dashboards voor prestatie-analyse, zoals die de tijdige levering of fulfilment-doorlooptijden monitoren. Waarom het belangrijk is Dit is een cruciaal attribute voor het berekenen van alle prestatiemetrieken, zoals doorlooptijden en procesduren, die essentieel zijn voor het identificeren van knelpunten. Waar te verkrijgen Dit is een samengesteld attribute, doorgaans afgeleid uit de combinatie van een datumveld (bijv. ERDAT) en een tijdveld (bijv. ERZET) uit verschillende SAP-tabellen zoals VBAK (Verkooporder), LIKP (Levering) en VBRK (Factuur). Voorbeelden 2023-04-15T09:00:12Z2023-04-16T14:30:00Z2023-04-20T11:22:45Z | |||
Gebruiker User | De gebruikers-ID van de medewerker die het document heeft aangemaakt of voor het laatst gewijzigd, of de activiteit heeft uitgevoerd. | ||
Beschrijving Dit attribuut registreert de SAP user ID die verantwoordelijk is voor een specifieke event in het proces. Het identificeert bijvoorbeeld de verkoopmedewerker die de order heeft aangemaakt of het magazijnpersoneel dat de goederenuitgifte heeft geboekt. Het analyseren van het proces per gebruiker helpt bij het begrijpen van de werkdrukverdeling, het identificeren van trainingsbehoeften en het detecteren van variaties in hoe verschillende gebruikers dezelfde taak uitvoeren. Dit is essentieel voor dashboards die gericht zijn op resourceprestaties, compliance en het identificeren van handmatige interventies. Waarom het belangrijk is Biedt inzicht in resourceprestaties en werkbelasting, helpt bij het identificeren van gebruikersspecifieke procesafwijkingen, en is essentieel voor compliance en automatiseringsanalyse. Waar te verkrijgen Te vinden in veel SAP-kopregeltabellen als het veld 'Created by' (ERNAM) of 'Changed by' (AENAM), zoals in VBAK, LIKP, VBRK. Voorbeelden CBURKEJSMITHRWILLIAMS | |||
Klantnummer CustomerNumber | De unieke identificatie voor de klant die de verkooporder heeft geplaatst. | ||
Beschrijving Dit attribuut vertegenwoordigt de klant (Sold-to Party), het primaire klantaccount dat is gekoppeld aan de verkooporder. Het verbindt de transactie met een specifieke klant in de stamdata. Analyseren op klantnummer maakt segmentatie van het proces mogelijk om klantspecifiek gedrag en prestaties te begrijpen. Het helpt vragen te beantwoorden zoals welke klanten de langste doorlooptijden, hoogste herbewerkingspercentages of meest frequente orderwijzigingen hebben. Dit is cruciaal voor het verbeteren van klantrelatiebeheer en serviceniveaus. Waarom het belangrijk is Maakt klantgerichte analyse mogelijk, helpt bij het identificeren van procesproblemen die specifieke klanten beïnvloeden en bij het meten van klantspecifieke prestaties. Waar te verkrijgen Te vinden in de Sales Document Header Data tabel (VBAK) als het veld KUNNR. Voorbeelden 100234100567200112 | |||
Leveringsblokkade DeliveryBlock | Een code die aangeeft of een sales order is geblokkeerd voor levering, waardoor de aanmaak van een leveringsdocument wordt voorkomen. | ||
Beschrijving De Leveringsblokkade is een status die is ingesteld op een verkooporder (op header- of itemniveau) om het proces tijdelijk te stoppen vóór de leveringsstap. Blokkades kunnen handmatig door een gebruiker of automatisch door het systeem worden ingesteld vanwege redenen zoals het overschrijden van de kredietlimiet of onvolledige data. Dit attribuut is cruciaal voor het dashboard 'Analyse van verkooporderblokkades en herwerk'. Het analyseren van de frequentie, duur en redenen voor leveringsblokkades helpt bij het identificeren van belangrijke knelpunten in het fulfilmentproces. Het verminderen van deze blokkades is essentieel voor het verbeteren van de tijdige levering en de algehele doorlooptijd. Waarom het belangrijk is Identificeert direct knelpunten in het afhandelingsproces. Het analyseren van waarom en hoe vaak orders geblokkeerd worden, is cruciaal voor het verbeteren van de procesefficiëntie. Waar te verkrijgen Te vinden in de Sales Document Header Data tabel (VBAK) als het veld LIFSK. Voorbeelden 0102Z1 | |||
Materiaalnummer MaterialNumber | De unieke identificatie voor een product of dienst die wordt verkocht. | ||
Beschrijving Het Artikelnummer identificeert het specifieke item op een verkooporderregel. Aangezien één verkooporder meerdere materialen kan bevatten, wordt dit attribuut doorgaans op itemniveau geanalyseerd. Het analyseren van het proces op basis van Artikelnummer helpt bij het blootleggen van productspecifieke problemen. Het kan onthullen of bepaalde producten gepaard gaan met langere fulfilmenttijden, een hogere frequentie van leveringsblokkades, of frequentere factuurverschillen. Dit is cruciaal voor supply chain management en productmanagement om het proces voor verschillende productlijnen te optimaliseren. Waarom het belangrijk is Maakt productgebaseerde procesanalyse mogelijk, waardoor duidelijk wordt welke producten geassocieerd zijn met procesinefficiënties zoals vertragingen, blokkades of herstelwerk. Waar te verkrijgen Te vinden in de Sales Document Item Data tabel (VBAP) als het veld MATNR. Voorbeelden FG-1001-ARAW-205BSERV-INSTALL | |||
Nettobedrag NetAmount | De totale waarde van de verkooporder, exclusief belastingen en kortingen op headerniveau. | ||
Beschrijving Net Amount staat voor de monetaire waarde van de verkooporder. Het is een belangrijke financiële metric die bij elke case hoort. Dit attribute is essentieel voor waarde‑gedreven process mining. Het stelt u in staat verbeterinitiatieven te prioriteren door te focussen op orders met een hoge waarde. Analisten kunnen procesproblemen, zoals vertraging of rework, koppelen aan de financiële impact en zo een sterkere business case voor verandering onderbouwen. U kunt bijvoorbeeld analyseren of orders met een hoge waarde efficiënter of juist minder efficiënt worden verwerkt dan orders met een lage waarde. Waarom het belangrijk is Maakt waardegebaseerde analyse mogelijk, helpt bij het prioriteren van verbeteringsinspanningen voor orders met de meest significante financiële impact op het bedrijf. Waar te verkrijgen Te vinden in de Sales Document Header Data tabel (VBAK) als het veld NETWR. Voorbeelden 1500.0012550.75850.50 | |||
Reden van afwijzing RejectionReason | Een code die de reden aangeeft waarom een sales order-item werd afgewezen of geannuleerd. | ||
Beschrijving De Afwijsreden geeft context waarom een verkooporder of een specifiek item niet is afgehandeld. Dit kan te wijten zijn aan annulering door de klant, productonbeschikbaarheid of andere zakelijke redenen. Dit attribuut is essentieel voor het dashboard 'Trends in verkooporderannuleringen'. Door de meest voorkomende afwijsredenen te analyseren, kan een bedrijf de hoofdoorzaken van gemiste verkopen identificeren. Dit inzicht kan leiden tot verbeteringen in voorraadbeheer, prijsstrategie of klantcommunicatie om het annuleringspercentage van verkooporders te verminderen. Waarom het belangrijk is Geeft inzicht in het 'waarom' achter orderannuleringen, wat root cause analysis mogelijk maakt om gemiste verkopen te verminderen en de forecast accuracy te verbeteren. Waar te verkrijgen Te vinden in de Sales Document Item Data tabel (VBAP) als het veld ABGRU. Voorbeelden 0215Z5 | |||
Verkooporder cycle time SalesOrderCycleTime | De totale duur vanaf de aanmaak van de verkooporder tot de uiteindelijke afsluiting of betaling ervan. | ||
Beschrijving Deze berekende metriek meet de end-to-end verwerkingstijd voor een enkele verkooporder. Deze wordt doorgaans berekend als het verschil tussen de timestamp van de allereerste activiteit ('Verkooporder Aangemaakt') en de allerlaatste activiteit (bijv. 'Betaling Ontvangen' of 'Orderitem Afgesloten'). Dit attribuut is de primaire metriek voor het dashboard 'End-to-End Doorlooptijd Verkooporder' en de KPI 'Doorlooptijd Orderafhandeling'. Het biedt een overzicht op hoog niveau van procesefficiëntie en is een cruciale metriek voor het identificeren van langlopende orders en de algehele procesgezondheid. Het analyseren van de distributie van deze metriek helpt bij het vaststellen van benchmarks en het volgen van de impact van verbeterinitiatieven in de loop van de tijd. Waarom het belangrijk is Dit is de primaire KPI voor het meten van de algehele processnelheid en efficiëntie, en biedt een cruciale basislijn voor verbeterinitiatieven. Waar te verkrijgen Dit is een berekende metriek, afgeleid uit het event log door het verschil te nemen tussen de maximale en minimale Starttijd voor een specifieke Verkooporder. Voorbeelden 10 dagen 4 uur25 dagen 11 uur5 dagen 2 uur | |||
Verkooporganisatie SalesOrganization | De organisatie-eenheid die verantwoordelijk is voor de verkoop van producten of diensten. | ||
Beschrijving Een Sales Organization is een belangrijke organisatorische entiteit in SAP, die het bedrijf structureert op basis van zijn verkoopvereisten. Het is verantwoordelijk voor het onderhandelen over verkoopvoorwaarden en het distribueren van goederen en diensten. Binnen process mining is dit attribute een cruciale dimensie voor analyse, waarmee u procesprestaties, efficiëntie en compliance tussen verschillende verkoopunits, regio's of divisies kunt vergelijken. Dit helpt bij het identificeren van best practices in goed presterende organisaties en gebieden voor verbetering in andere. Waarom het belangrijk is Maakt organisatorische benchmarking mogelijk, waardoor vergelijking van procesefficiëntie en compliance tussen verschillende bedrijfseenheden of regio's mogelijk is. Waar te verkrijgen Te vinden in de Sales Document Header Data tabel (VBAK) als het veld VKORG. Voorbeelden 100025003100 | |||
Bevestigde leveringsdatum ConfirmedDeliveryDate | De datum waarop de levering van goederen of diensten aan de klant is bevestigd. | ||
Beschrijving Dit is de overeengekomen leverdatum die aan de klant is doorgegeven, gebaseerd op beschikbaarheid van materiaal en planning. Het dient als basislijn voor het meten van leveringsprestaties. Dit attribute vormt de basis voor het dashboard 'Prestaties Tijdige Levering' en de KPI 'Percentage Tijdige Levering'. Door de Bevestigde Leverdatum te vergelijken met de werkelijke 'Datum Goederen Uitgegeven', kan de analyse bepalen of een order op tijd, te vroeg of te laat werd geleverd. Dit is een primaire maatstaf voor de betrouwbaarheid van de supplychain en klanttevredenheid. Waarom het belangrijk is Dit is het referentiepunt voor het meten van de prestaties van tijdige levering, een cruciale KPI voor klanttevredenheid en efficiëntie van de supplychain. Waar te verkrijgen Te vinden in de Sales Document Schedule Line tabel (VBEP) als het veld EDATU. Voorbeelden 2023-05-102023-06-202023-07-01 | |||
Is herstelwerk IsRework | Een booleaanse vlag die aangeeft of een sales order na de initiële aanmaak een significante wijziging of herwerkactiviteit heeft ondergaan. | ||
Beschrijving Dit berekende attribuut identificeert procesinstanties die herbewerking (rework) hebben ondergaan, zoals een of meer 'Verkooporder Gewijzigd' activiteiten. De specifieke logica die bepaalt wat herbewerking omvat, bijvoorbeeld een wijziging van prijs, kwantiteit of leveringsdatum, wordt gedefinieerd tijdens de projectopzet. Dit attribuut is cruciaal voor het dashboard 'Frequentie Herbewerking en Wijziging Verkooporders' en de KPI 'Percentage Herbewerking Verkooporders'. Het vereenvoudigt de analyse door directe filtering en vergelijking mogelijk te maken tussen orders die direct werden verwerkt en orders die handmatige wijzigingen vereisten. Dit helpt de impact van herbewerking op doorlooptijden en kosten te kwantificeren. Waarom het belangrijk is Kwantificeert direct de frequentie van herwerk, waardoor de oorzaken en de impact ervan op de algehele procesefficiëntie en cycle time geanalyseerd kunnen worden. Waar te verkrijgen Dit is een berekend attribuut afgeleid van het event log. De logica controleert op de aanwezigheid van 'Verkooporder Gewijzigd' activiteiten of specifieke wijzigings-events uit de tabellen CDHDR/CDPOS. Voorbeelden truefalse | |||
Is Tijdige Levering IsOnTimeDelivery | Een booleaanse vlag die aangeeft of de goederen op of vóór de bevestigde leverdatum zijn verzonden. | ||
Beschrijving Dit berekende attribuut vergelijkt de werkelijke goederenuitgiftedatum met de ConfirmedDeliveryDate voor een verkooporder. Als de goederenuitgiftedatum op of vóór de bevestigde datum ligt, wordt het als waar (true) gemarkeerd; anders als onwaar (false). Dit attribuut vereenvoudigt de creatie van het dashboard 'Prestaties Tijdige Levering' en de berekening van de KPI 'Percentage Tijdige Levering'. Het maakt eenvoudige aggregatie en visualisatie van prestaties mogelijk zonder dat datumvergelijkingen ad hoc hoeven plaats te vinden binnen elke analyse of grafiek. Dit biedt een duidelijke, directe maatstaf voor leveringsbetrouwbaarheid. Waarom het belangrijk is Biedt een duidelijke en eenvoudige meting van de leveringsprestaties, waardoor het gemakkelijk wordt om de totale On-Time Delivery Rate KPI te berekenen. Waar te verkrijgen Dit is een berekend attribuut. De logica vergelijkt de timestamp van de activiteit 'Goederen Uitgegeven' met de waarde uit het attribuut 'ConfirmedDeliveryDate'. Voorbeelden truefalse | |||
Kredietcontrolestatus CreditCheckStatus | Geeft de status aan van de kredietcontrole voor het verkoopdocument. | ||
Beschrijving Dit attribuut toont de uitkomst van de geautomatiseerde of handmatige kredietcontrole die op een verkooporder is uitgevoerd. Gangbare statussen zijn 'Goedgekeurd', 'Afgewezen' of 'Geblokkeerd'. Dit is een kernattribuut voor het dashboard 'Analyse van de Verwerkingstijd van Kredietcontroles'. Vertragingen of blokkades in de kredietcontrolefase kunnen de totale orderdoorlooptijd aanzienlijk beïnvloeden. Het analyseren van deze status helpt om de efficiëntie van het kredietbeheerproces en de impact ervan op de verkoopsnelheid te begrijpen. Waarom het belangrijk is Beïnvloedt direct de snelheid van orderverwerking. Het analyseren van deze status helpt bij het identificeren van knelpunten in kredietbeheer die orderafhandeling vertragen. Waar te verkrijgen Te vinden in de Sales Document Header Status tabel (VBUK) of direct in VBAK als het kredietstatusveld (bijv. CMGST). Voorbeelden ABD | |||
Verzendvoorwaarden ShippingConditions | Bepaalt de algemene verzendstrategie voor de levering van goederen aan de klant. | ||
Beschrijving Verzendvoorwaarden bepalen hoe een bestelling wordt verzonden, bijvoorbeeld 'Standard', 'Express' of 'Pickup'. Dit wordt overeengekomen met de klant en beïnvloedt de logistieke planning. Dit attribuut wordt gebruikt in de 'Analyse van de efficiëntie en kosten van verzendmethoden'. Door het proces te segmenteren op basis van verzendvoorwaarden, kunnen bedrijven analyseren of bepaalde methoden vaker leiden tot vertragingen of langere doorlooptijden hebben. Deze data helpt de logistiek te optimaliseren en klantverwachtingen over levertijden te beheren. Waarom het belangrijk is Maakt analyse van logistieke prestaties mogelijk, en helpt te bepalen of bepaalde verzendmethoden correleren met vertragingen of hogere efficiëntie. Waar te verkrijgen Te vinden in de Sales Document Header Data tabel (VBAK) als het veld VSBED. Voorbeelden 011020 | |||
Order to Cash - Activiteiten Verkooporderverwerking
| Activiteit | Beschrijving | ||
|---|---|---|---|
Betaling Ontvangen | Dit event betekent dat de betaling van de klant is ontvangen en op de factuur is verwerkt, waardoor de openstaande debiteurenpost is afgeboekt. Dit is een boekhoudkundige gebeurtenis, afgeleid van het afboeken van een financieel document. | ||
Waarom het belangrijk is Dit is de laatste stap in het incasseren van geld uit de verkoop. Het is het eindpunt voor het meten van de 'Doorlooptijd Factuur tot Betaling' en de algehele 'Doorlooptijd Afhandeling Verkooporder'. Waar te verkrijgen Afgeleid uit de clearingdocument‑informatie in tabel BSEG voor de klantenregelpost. Wanneer BSEG‑AUGBL (Clearing Document) en BSEG‑AUGDT (Clearing Date) zijn ingevuld, is de betaling ontvangen. Vastleggen Afgeleid uit het invullen van de clearingdatum (AUGDT) in tabel BSEG voor de AR‑regelpost. Gebeurtenistype inferred | |||
Factuur aangemaakt | Markeert het aanmaken van de klantfactuur of het billing document. Dit is een expliciet event dat een nieuw document in het systeem aanmaakt en het betalingsdeel van het proces start. | ||
Waarom het belangrijk is Dit is een cruciale mijlpaal die het begin markeert van de 'Doorlooptijd Factuur tot Betaling'. Vertragingen bij facturatie hebben direct impact op de cashflow. Waar te verkrijgen Vastgelegd in de VBRK-tabel (Billing Document: Header Data) op basis van de aanmaakdatum (ERDAT). De koppeling naar de verkooporder of levering bevindt zich in de VBFA-tabel. Vastleggen Event gebaseerd op aanmaak timestamp (ERDAT) in VBRK tabel. Gebeurtenistype explicit | |||
Goederen Uitgegeven | Een kritieke event waarbij het eigendom van goederen overgaat en deze het magazijn verlaten. Een financiële boeking creëert een materiaaldocument en werkt de voorraad bij. | ||
Waarom het belangrijk is Dit is de 'verzending' event en een belangrijke mijlpaal voor het meten van tijdige levering en doorlooptijden van de orderuitvoering. Het activeert financiële updates en is een punt zonder omkeer in het fysieke uitvoeringsproces. Waar te verkrijgen Aanmaak van een materiaaldocument (MKPF/MSEG) met een goederenuitgiftebewegingstype (bijv. 601), dat is gekoppeld aan het leveringsdocument. Vastleggen Aanmaak van een materiaaldocument (MKPF/MSEG) met een goederenuitgiftebewegingstype, gekoppeld aan de levering. Gebeurtenistype explicit | |||
Order Bevestigd | Deze activiteit geeft aan dat de verkooporder alle initiële controles heeft doorstaan en is bevestigd voor afhandeling. Dit wordt doorgaans afgeleid wanneer de order niet langer geblokkeerd is en bevestigde hoeveelheden in de leveringsschema's heeft. | ||
Waarom het belangrijk is Dit is een belangrijke mijlpaal die de orderinvoer scheidt van de uitvoering. Het is het startpunt voor het meten van de doorlooptijden van de orderuitvoering en de prestatiemeting van tijdige levering. Waar te verkrijgen Kan worden afgeleid wanneer schedule lines in VBEP een bevestigde hoeveelheid (BMENG > 0) hebben en de order niet is geblokkeerd voor levering (bijv. VBUK-LIFSK is leeg). Vastleggen Afgeleid uit bevestiging van de planningsregel (VBEP‑BMENG > 0) en het verwijderen van blokkades op kopniveau. Gebeurtenistype inferred | |||
Orderitem gesloten | Deze activiteit markeert de definitieve afsluiting van een verkooporderitem, wat aangeeft dat het volledig is geleverd, gefactureerd en als compleet wordt beschouwd. Dit wordt afgeleid uit de algehele status van het item. | ||
Waarom het belangrijk is Dient als de succesvolle eind-event voor het proces. Het analyseren van wanneer items sluiten, helpt de end-to-end procesduur te begrijpen en orders te identificeren die onnodig open blijven staan. Waar te verkrijgen Afgeleid uit het algehele statusveld in tabel VBUP (Sales Document: Item Status) voor het item. Wanneer VBUP‑GBSTA 'C' (volledig verwerkt) is, wordt het item gesloten. Vastleggen Afgeleid wanneer de itemstatus (VBUP‑GBSTA) wijzigt naar 'C' (volledig verwerkt). Gebeurtenistype inferred | |||
Verkooporder aangemaakt | Markeert het aanmaken van een nieuwe verkooporder. Dit is een expliciet event dat wordt vastgelegd wanneer een gebruiker een nieuwe order opslaat, meestal via transactie VA01 in SAP. | ||
Waarom het belangrijk is Dit is de primaire start event voor het Order to Cash-proces. Het analyseren van de timing is cruciaal voor het meten van de algehele doorlooptijd en orderintakepercentages. Waar te verkrijgen Vastgelegd in de VBAK-tabel (Sales Document Header Data) met de aanmaakdatum (ERDAT) en -tijd (ERZET). De transactiecode is opgeslagen in VBAK-TCODE. Vastleggen Event gebaseerd op aanmaak timestamp (ERDAT, ERZET) in VBAK tabel. Gebeurtenistype explicit | |||
Factuur geannuleerd | Vertegenwoordigt de omkering van een eerder aangemaakt factuurdocument. Dit is een expliciete transactie die een nieuw annuleringsdocument aanmaakt ter compensatie van het originele. | ||
Waarom het belangrijk is Het volgen van factuurannuleringen helpt bij het identificeren van problemen met prijsstelling, verzendingsverschillen of datafouten. Dit ondersteunt de KPI 'Percentage Factuurafwijkingen'. Waar te verkrijgen Een expliciete event vastgelegd door de aanmaak van een annuleringsfactuurdocument (VBRK-VBTYP = 'N' of 'O'). Naar de oorspronkelijke factuur wordt verwezen in VBRK-SFAKN. Vastleggen Aanmaak van een annuleringsdocument in VBRK, verwijzend naar de oorspronkelijke factuur. Gebeurtenistype explicit | |||
Kredietcontrole uitgevoerd | Geeft aan dat de automatische of handmatige kredietcontrole voor de klant in de verkooporder is afgerond. Dit wordt doorgaans afgeleid uit een wijziging in de algehele kredietstatus van het document. | ||
Waarom het belangrijk is De kredietcontrole is vaak een cruciaal knelpunt. Het meten van de tijd die deze stap in beslag neemt, is essentieel voor de 'Analyse van de doorlooptijd van kredietcontroles' en voor het versnellen van de orderverwerking. Waar te verkrijgen Afgeleid uit de kredietstatusvelden in tabel VBUK (Sales Document: Header Status). Een wijziging van VBUK‑CMGST van geblokkeerd naar vrijgegeven markeert deze activiteit. Vastleggen Afgeleid uit wijzigingen in het veld voor de algehele kredietstatus (VBUK‑CMGST). Gebeurtenistype inferred | |||
Levering Aangemaakt | Dit event markeert de creatie van het uitgaande leveringsdocument, de instructie aan het magazijn om te beginnen met pick- en verzendactiviteiten. Dit is een expliciet event vastgelegd vanuit de documentstroom. | ||
Waarom het belangrijk is Dit is de eerste stap in het fysieke uitvoeringsproces. De tijd tussen orderbevestiging en aanmaken van levering geeft aan hoe snel het logistieke proces wordt gestart. Waar te verkrijgen De aanmaak van een record in de LIKP-tabel (SD Document: Leveringsheaderdata). De koppeling met de verkooporder wordt bijgehouden in de documentstroomtabel VBFA. Vastleggen Event gebaseerd op aanmaak timestamp in LIKP tabel, gekoppeld via VBFA tabel. Gebeurtenistype explicit | |||
Leveringsbewijs bevestigd | Deze activiteit vertegenwoordigt de bevestiging dat de klant de goederen heeft ontvangen. Deze wordt vastgelegd wanneer het bewijs van levering in het systeem wordt geregistreerd, waarbij vaak de status van het leveringsdocument wordt bijgewerkt. | ||
Waarom het belangrijk is Dit event registreert de werkelijke leveringsdatum, wat essentieel is voor het nauwkeurig meten van het percentage tijdige levering (On-Time Delivery Rate) ten opzichte van de overeengekomen datum. Waar te verkrijgen Afgeleid wanneer de proof of delivery‑status (VBUK‑PODAT) op 'C' (Confirmed) staat. De bevestigingsdatum staat in VLPOD‑PODAT. Dit is niet altijd ingericht. Vastleggen Afgeleid uit een update van de POD‑status op de levering (VBUK‑PODAT) of een record in de VLPOD‑tabel. Gebeurtenistype inferred | |||
Leveringsblokkade ingesteld | Vertegenwoordigt een actie waarbij een leveringsblokkade op de verkooporder wordt toegepast, waardoor de aanmaak van een leveringsdocument wordt voorkomen. Dit kan expliciet worden vastgelegd vanuit change logs of worden afgeleid uit status tables. | ||
Waarom het belangrijk is Deze activiteit heeft direct betrekking op de KPI 'Verkooporderblokkeringspercentage'. Het identificeren waarom en hoe vaak blokkades worden ingesteld, helpt bij het blootleggen van redenen voor fulfilmentvertragingen. Waar te verkrijgen Kan worden gevonden in change logs (CDHDR/CDPOS) voor veld VBAK-LIFSK. Als alternatief wordt het afgeleid door te observeren wanneer het VBAK-LIFSK veld is gevuld. Vastleggen Event uit wijzigingsdocumenten voor veld VBAK-LIFSK of VBAP-LIFSP. Gebeurtenistype explicit | |||
Order geannuleerd | Geeft aan dat een verkooporder vóór afhandeling is geannuleerd. Dit wordt doorgaans vastgelegd door een 'reden voor afwijzing' toe te passen op alle relevante artikelen van de order. | ||
Waarom het belangrijk is Dit is een kritiek annuleringspunt dat direct bijdraagt aan de 'Annuleringspercentage Orders' KPI. Inzicht in wanneer en waarom orders worden geannuleerd, biedt waardevolle informatie over problemen in het verkoopproces. Waar te verkrijgen Afgeleid wanneer het veld VBAP‑ABGRU (Reason for rejection) is ingevuld voor alle actieve items op een verkooporder. De datum van de wijziging is te vinden in CDHDR/CDPOS. Vastleggen Afgeleid uit het invullen van het veld 'Reason for Rejection' (VBAP‑ABGRU) voor alle items. Gebeurtenistype inferred | |||
Verkooporder gewijzigd | Vertegenwoordigt een wijziging aan een bestaande verkooporder na de initiële aanmaak. Deze wijzigingen worden vastgelegd in speciale change log tables (CDHDR, CDPOS) wanneer velden zoals hoeveelheid, prijs of datums worden gewijzigd. | ||
Waarom het belangrijk is Het volgen van wijzigingen helpt bij het identificeren van herbewerking, procesinstabiliteit en problemen met datakwaliteit. Een hoge frequentie van wijzigingen kan duiden op problemen in het initiële orderinvoerproces, leidend tot vertragingen. Waar te verkrijgen Opgehaald uit change document tables CDHDR (header) en CDPOS (item) voor OBJECTCLAS = 'VERKBELEG'. De timestamp en het gewijzigde veld kunnen worden geïdentificeerd. Vastleggen Event uit wijzigingsdocumenttabellen (CDHDR, CDPOS) voor verkoopdocumentobjecten. Gebeurtenistype explicit | |||
Verzamelen Voltooid | Geeft aan dat alle artikelen voor de levering fysiek zijn verzameld uit het magazijn. Als Warehouse Management (WM) wordt gebruikt, kan dit worden afgeleid uit de status van de Transportorder. | ||
Waarom het belangrijk is Het analyseren van picktijd helpt bij het optimaliseren van magazijnoperaties. Vertragingen hier hebben directe invloed op de algehele verzendtermijn en fulfillmentcyclus. Waar te verkrijgen Afgeleid wanneer de pickstatus van het leveringsitem in tabel LIPS‑KOSTA wijzigt naar 'C' (volledig gepickt). Als WM actief is, kan dit worden afgeleid uit bevestiging van de Transfer Order (tabellen LTAK/LTAP). Vastleggen Afgeleid uit een wijziging in de pickstatus (LIPS‑KOSTA) of bevestiging van de WM Transfer Order. Gebeurtenistype inferred | |||
Extractie Guides
Stappen
- Programmaontwikkeling: Gebruik transactie SE38 of SE80 om een nieuw uitvoerbaar ABAP-programma te creëren. Dit programma zal de volledige extractielogica bevatten.
- Selectiescherm definiëren: Maak in uw programma een selectiescherm om de data te filteren. Voeg parameters toe voor de aanmaakdatum van het verkoopdocument (VBAK-ERDAT), de Sales Organization (VBAK-VKORG) en het verkoopdocumenttype (VBAK-AUART). Dit maakt de extractie herbruikbaar en beheersbaar.
- Datadeclaraties: Definieer de interne tabellen en structuren die nodig zijn om de data van verschillende SAP-tabellen (VBAK, VBAP, VBFA, CDHDR, CDPOS, VBRK, BSAD) te bevatten. Definieer ook de uiteindelijke outputstructuur voor de event log die overeenkomt met de vereiste attributes.
- Basis Sales Orders selecteren: Schrijf de initiële SELECT-statement om sales order headers (VBAK) en items (VBAP) op te halen op basis van de invoerwaarden voor het selectiescherm van de gebruiker. Dit vormt de kern dataset van cases die moeten worden geanalyseerd.
- 'Aanmaak' Event extraheren: Loop door de geselecteerde VBAK records. Voor elk record vult u de event log-structuur met de 'Sales Order Created' activiteit, waarbij u VBAK-ERDAT en VBAK-ERZET gebruikt voor de StartTime.
- Wijzigingslogboek-events extraheren: Selecteer records uit CDHDR en CDPOS waar de OBJECTCLAS 'VERKBELEG' is voor de geselecteerde sales orders. Loop door de resultaten om specifieke veldwijzigingen te identificeren. Een wijziging aan VBAK-LIFSK duidt bijvoorbeeld op een 'Delivery Block Set', en een wijziging aan VBUK-CMGST op een 'Credit Check Performed'. Elke andere relevante wijziging kan worden gelogd als 'Sales Order Changed'.
- Documentstroomgegevens extraheren: Voor de geselecteerde sales orders voert u een query uit op de documentstroomtabel (VBFA). Deze tabel koppelt sales orders aan daaropvolgende documenten zoals leveringen, goederenbewegingen en facturen. Selecteer alle gerelateerde documenten voor verdere verwerking.
- Levering- en fulfilment-events extraheren: Gebruik de leveringsdocumentnummers van VBFA en voer een query uit op LIKP en LIPS voor 'Delivery Created' events. Voer een query uit op MKPF en MSEG voor goederenuitgiftedocumenten (bewegingstype '601') om het 'Goods Issued' event vast te leggen. Als Warehouse Management actief is, voert u een query uit op LTAK en LTAP om de bevestigingstijd te vinden voor de laatste transferorderitem om 'Picking Completed' te bepalen. Controleer de leveringsheaderstatus VBUK-PODAT voor 'Proof of Delivery Confirmed'.
- Facturatie- en betaling-events extraheren: Gebruik de factureringsdocumentnummers van VBFA en voer een query uit op VBRK en VBRP om 'Invoice Created' en 'Invoice Cancelled' (VBRK-FKSTO = 'X') events vast te leggen. Om 'Payment Received' te vinden, koppelt u de factuur van VBRK aan het boekhoudkundig document in BKPF, en vindt u vervolgens het vereffeningsdocument en de vereffeningsdatum in BSAD.
- Statusgebaseerde events extraheren: Gebruik de statustabellen VBUP (Item Status) en VBUK (Header Status) om zakelijke events af te leiden. Een item wordt bijvoorbeeld beschouwd als 'Order Item Closed' wanneer VBUP-GBSTA gelijk is aan 'C'. Een order is 'Order Cancelled' wanneer een 'Reason for Rejection' (VBAP-ABGRU) is ingesteld voor alle relevante items.
- Consolideren en formatteren: Combineer alle vastgelegde events in één finale interne tabel. Zorg ervoor dat alle attributes (SalesOrder, Activity, StartTime, User, etc.) correct zijn ingevuld voor elke eventrecord. Voeg de SourceSystem en LastDataUpdate-timestamps toe.
- Outputbestand genereren: Gebruik de GUI_DOWNLOAD-functiemodule of cl_gui_frontend_services=>gui_download methode om de finale interne tabel te exporteren naar een CSV-bestand op de lokale machine van de gebruiker. Zorg ervoor dat het bestand wordt opgeslagen met UTF-8-codering.
Configuratie
- Vereisten: ABAP-ontwikkelaarsautorisaties (bijv. toegang tot transactie SE38), en leesrechten op alle vereiste SAP-tabellen, waaronder VBAK, VBAP, CDHDR, CDPOS, VBFA, LIKP, LIPS, VBRK, VBRP, MKPF, MSEG en BSAD.
- Selectieparameters: Het programma dient te beschikken over een selectiescherm met filterparameters. Belangrijke parameters zijn:
- Datumbereik: Een verplicht datumbereik voor de aanmaakdatum van verkooporders (VBAK-ERDAT). Begin met een recente periode van 3-6 maanden om de dataset beheersbaar te houden.
- Verkooporganisatie: Filter op VBAK-VKORG om de analyse te richten op specifieke bedrijfseenheden.
- Verkoopdocumenttype: Filter op VBAK-AUART om alleen relevante ordertypen (bijv. standaardorders) op te nemen en andere (bijv. offertes, retouren) uit te sluiten.
- Prestatieoverwegingen: Het extraheren uit wijzigingslogtabellen (CDHDR, CDPOS) en documentstroom (VBFA) kan zeer traag zijn bij grote datavolumes. Het programma dient geoptimaliseerd te worden voor het gebruik van indexvelden in WHERE-clausules. Voor zeer grote extracties, plan het programma dan in als achtergrondtaak te draaien tijdens daluren via transactie SM36.
- Activering Wijzigingslog: Deze methode maakt gebruik van de wijzigingsdocumentfunctionaliteit van SAP. Controleer of wijzigingslogging is ingeschakeld voor belangrijke data-elementen (bijv. LIFSK, CMGST, ABGRU). Dit kan worden gecontroleerd via transactie SCDO voor object VERKBELEG.
a Voorbeeldquery abap
REPORT Z_O2C_PM_EXTRACTOR.
*&---------------------------------------------------------------------*
*& Data Declarations
*&---------------------------------------------------------------------*
TABLES: vbak.
TYPES: BEGIN OF ty_event_log,
salesorder TYPE vbeln_va,
activity TYPE string,
starttime TYPE string,
sourcesystem TYPE logsys,
lastdataupdate TYPE string,
user TYPE ernam,
customernumber TYPE kunnr,
salesorganization TYPE vkorg,
netamount TYPE netwr,
materialnumber TYPE matnr,
deliveryblock TYPE lifsk,
rejectionreason TYPE abgru,
salesordercycletime TYPE string, " Placeholder for calculation
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log.
DATA: gs_event_log TYPE ty_event_log.
DATA: gv_sysid TYPE logsys.
DATA: gv_last_update TYPE string.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_erdat FOR vbak-erdat OBLIGATORY,
s_vkorg FOR vbak-vkorg,
s_auart FOR vbak-auart.
PARAMETERS: p_file TYPE rlgrap-filename OBLIGATORY DEFAULT 'C:\temp\o2c_event_log.csv'.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
CALL FUNCTION 'OWN_LOGICAL_SYSTEM_GET'
IMPORTING
own_logical_system = gv_sysid.
CONCATENATE sy-datum sy-uzeit INTO gv_last_update.
PERFORM get_base_data.
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*& Form get_base_data
*&---------------------------------------------------------------------*
FORM get_base_data.
TYPES: BEGIN OF ty_order_item,
vbeln TYPE vbeln_va,
posnr TYPE posnr_va,
erdat TYPE erdat,
erzet TYPE erzet,
ernam TYPE ernam,
kunnr TYPE kunnr,
vkorg TYPE vkorg,
netwr TYPE netwr_ak,
matnr TYPE matnr,
lifsk TYPE lifsk,
abgru TYPE abgru,
END OF ty_order_item.
DATA: lt_order_items TYPE TABLE OF ty_order_item.
SELECT h~vbeln i~posnr h~erdat h~erzet h~ernam h~kunnr h~vkorg h~netwr i~matnr h~lifsk i~abgru
INTO TABLE lt_order_items
FROM vbak AS h
INNER JOIN vbap AS i ON h~vbeln = i~vbeln
WHERE h~erdat IN s_erdat
AND h~vkorg IN s_vkorg
AND h~auart IN s_auart.
CHECK sy-subrc = 0.
DATA(lt_vbeln_range) = VALUE rsdsselopt_t(
FOR <fs_item> IN lt_order_items WHERE ( vbeln = <fs_item>-vbeln )
( sign = 'I' option = 'EQ' low = <fs_item>-vbeln ) ).
SORT lt_vbeln_range BY low.
DELETE ADJACENT DUPLICATES FROM lt_vbeln_range COMPARING low.
PERFORM extract_order_created USING lt_order_items.
PERFORM extract_changes USING lt_vbeln_range lt_order_items.
PERFORM extract_doc_flow_events USING lt_vbeln_range lt_order_items.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_order_created
*&---------------------------------------------------------------------*
FORM extract_order_created USING it_order_items TYPE ANY TABLE.
FIELD-SYMBOLS: <fs_item> TYPE any.
DATA: lt_unique_orders TYPE HASHED TABLE OF vbeln_va WITH UNIQUE KEY table_line.
lt_unique_orders = VALUE #( FOR <order> IN it_order_items ( CONV vbeln_va( <order>-vbeln ) ) ).
LOOP AT it_order_items ASSIGNING <fs_item> WHERE table_line IN lt_unique_orders.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_item>-vbeln.
gs_event_log-activity = 'Sales Order Created'.
CONCATENATE <fs_item>-erdat <fs_item>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_item>-ernam.
gs_event_log-customernumber = <fs_item>-kunnr.
gs_event_log-salesorganization = <fs_item>-vkorg.
gs_event_log-netamount = <fs_item>-netwr.
APPEND gs_event_log TO gt_event_log.
DELETE lt_unique_orders WHERE table_line = <fs_item>-vbeln.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_changes
*&---------------------------------------------------------------------*
FORM extract_changes USING it_vbeln_range TYPE rsdsselopt_t it_order_items TYPE ANY TABLE.
DATA: lt_cdhdr TYPE TABLE OF cdhdr,
lt_cdpos TYPE TABLE OF cdpos.
SELECT * INTO TABLE lt_cdhdr FROM cdhdr
WHERE objectclas = 'VERKBELEG'
AND objectid IN it_vbeln_range
AND tcode = 'VA02'.
IF sy-subrc = 0.
SELECT * INTO TABLE lt_cdpos FROM cdpos
FOR ALL ENTRIES IN lt_cdhdr
WHERE objectclas = lt_cdhdr-objectclas
AND objectid = lt_cdhdr-objectid
AND changenr = lt_cdhdr-changenr.
ENDIF.
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
DATA(lv_order_info) = REF #( it_order_items[ vbeln = <fs_cdhdr>-objectid ] ).
IF lv_order_info IS NOT BOUND. CONTINUE. ENDIF.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_cdhdr>-objectid.
gs_event_log-user = <fs_cdhdr>-username.
CONCATENATE <fs_cdhdr>-udate <fs_cdhdr>-utime INTO gs_event_log-starttime.
gs_event_log-customernumber = lv_order_info->kunnr.
gs_event_log-salesorganization = lv_order_info->vkorg.
gs_event_log-netamount = lv_order_info->netwr.
" Generic Change Event
gs_event_log-activity = 'Sales Order Changed'.
APPEND gs_event_log TO gt_event_log.
LOOP AT lt_cdpos ASSIGNING FIELD-SYMBOL(<fs_cdpos>)
WHERE objectclas = <fs_cdhdr>-objectclas
AND objectid = <fs_cdhdr>-objectid
AND changenr = <fs_cdhdr>-changenr.
CASE <fs_cdpos>-fname.
WHEN 'LIFSK'. " Delivery Block
gs_event_log-activity = 'Delivery Block Set'.
gs_event_log-deliveryblock = <fs_cdpos>-value_new.
APPEND gs_event_log TO gt_event_log.
WHEN 'CMGST'. " Credit Status
IF <fs_cdpos>-value_new = 'B'. " B = Credit Check OK
gs_event_log-activity = 'Credit Check Performed'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
WHEN 'ABGRU'. " Rejection Reason
IF <fs_cdpos>-value_new IS NOT INITIAL.
gs_event_log-activity = 'Order Cancelled'.
gs_event_log-rejectionreason = <fs_cdpos>-value_new.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDCASE.
ENDLOOP.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_doc_flow_events
*&---------------------------------------------------------------------*
FORM extract_doc_flow_events USING it_vbeln_range TYPE rsdsselopt_t it_order_items TYPE ANY TABLE.
DATA: lt_vbfa TYPE TABLE OF vbfa,
lt_vbrk TYPE TABLE OF vbrk,
lt_likp TYPE TABLE OF likp,
lt_mseg TYPE TABLE OF mseg,
lt_bsad TYPE TABLE OF bsad,
lt_vbup TYPE TABLE OF vbup.
SELECT * INTO TABLE lt_vbfa FROM vbfa
WHERE vbelv IN it_vbeln_range
AND ( vbtyp_n = 'J' " Delivery
OR vbtyp_n = 'M' " Invoice
OR vbtyp_n = 'N' " Invoice Cancellation
OR vbtyp_n = 'R' ). " Goods Movement
IF lt_vbfa IS INITIAL. RETURN. ENDIF.
SELECT vbeln, erdat, erzet, ernam, fksto, belnr FROM vbrk INTO TABLE lt_vbrk
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbeln
AND ( lt_vbfa-vbtyp_n = 'M' OR lt_vbfa-vbtyp_n = 'N' ).
SELECT vbeln, erdat, erzet, ernam, podat FROM likp INTO TABLE lt_likp
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbeln AND lt_vbfa-vbtyp_n = 'J'.
SELECT mblnr, mjahr, zeile, bwart, budat, cpuzt, usnam FROM mseg INTO TABLE lt_mseg
FOR ALL ENTRIES IN lt_vbfa
WHERE mblnr = lt_vbfa-vbeln AND mjahr = lt_vbfa-mjahr AND zeile = lt_vbfa-posnn AND lt_vbfa-vbtyp_n = 'R' AND bwart = '601'.
SELECT augdt, belnr, gjahr, kunnr FROM bsad INTO TABLE lt_bsad
FOR ALL ENTRIES IN lt_vbrk
WHERE belnr = lt_vbrk-belnr AND gjahr = SUBSTRING( val = lt_vbrk-erdat len = 4 ).
SELECT vbeln, posnr, gbsta FROM vbup INTO TABLE lt_vbup
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbelv AND posnr = lt_vbfa-posnv.
LOOP AT lt_vbfa ASSIGNING FIELD-SYMBOL(<fs_vbfa>).
DATA(lv_order_info) = REF #( it_order_items[ vbeln = <fs_vbfa>-vbelv ] ).
IF lv_order_info IS NOT BOUND. CONTINUE. ENDIF.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_vbfa>-vbelv.
gs_event_log-customernumber = lv_order_info->kunnr.
gs_event_log-salesorganization = lv_order_info->vkorg.
gs_event_log-netamount = lv_order_info->netwr.
gs_event_log-materialnumber = lv_order_info->matnr.
CASE <fs_vbfa>-vbtyp_n.
WHEN 'J'. " Delivery
READ TABLE lt_likp ASSIGNING FIELD-SYMBOL(<fs_likp>) WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0.
gs_event_log-activity = 'Delivery Created'.
CONCATENATE <fs_likp>-erdat <fs_likp>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_likp>-ernam.
APPEND gs_event_log TO gt_event_log.
" Picking Completed - simplified logic, check status
gs_event_log-activity = 'Picking Completed'. APPEND gs_event_log TO gt_event_log.
" POD Confirmed
IF <fs_likp>-podat IS NOT INITIAL.
gs_event_log-activity = 'Proof Of Delivery Confirmed'.
gs_event_log-starttime = <fs_likp>-podat.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
WHEN 'R'. " Goods Issue
READ TABLE lt_mseg ASSIGNING FIELD-SYMBOL(<fs_mseg>) WITH KEY mblnr = <fs_vbfa>-vbeln mjahr = <fs_vbfa>-mjahr zeile = <fs_vbfa>-posnn.
IF sy-subrc = 0.
gs_event_log-activity = 'Goods Issued'.
CONCATENATE <fs_mseg>-budat <fs_mseg>-cpuzt INTO gs_event_log-starttime.
gs_event_log-user = <fs_mseg>-usnam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
WHEN 'M'. " Invoice
READ TABLE lt_vbrk ASSIGNING FIELD-SYMBOL(<fs_vbrk>) WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0.
gs_event_log-activity = 'Invoice Created'.
CONCATENATE <fs_vbrk>-erdat <fs_vbrk>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_vbrk>-ernam.
APPEND gs_event_log TO gt_event_log.
" Payment Received
READ TABLE lt_bsad ASSIGNING FIELD-SYMBOL(<fs_bsad>) WITH KEY belnr = <fs_vbrk>-belnr.
IF sy-subrc = 0 AND <fs_bsad>-augdt IS NOT INITIAL.
gs_event_log-activity = 'Payment Received'.
gs_event_log-starttime = <fs_bsad>-augdt.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
WHEN 'N'. " Invoice Cancellation
READ TABLE lt_vbrk ASSIGNING <fs_vbrk> WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0 AND <fs_vbrk>-fksto = 'X'.
gs_event_log-activity = 'Invoice Cancelled'.
CONCATENATE <fs_vbrk>-erdat <fs_vbrk>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_vbrk>-ernam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDCASE.
ENDLOOP.
" Infer other events from status
LOOP AT lt_vbup ASSIGNING FIELD-SYMBOL(<fs_vbup>).
IF <fs_vbup>-gbsta = 'C'.
DATA(lv_order_info_stat) = REF #( it_order_items[ vbeln = <fs_vbup>-vbeln ] ).
IF lv_order_info_stat IS NOT BOUND. CONTINUE. ENDIF.
gs_event_log-salesorder = <fs_vbup>-vbeln.
gs_event_log-activity = 'Order Item Closed'.
" Timestamp for closed is harder, using current time as placeholder
CONCATENATE sy-datum sy-uzeit INTO gs_event_log-starttime.
gs_event_log-user = sy-uname.
gs_event_log-customernumber = lv_order_info_stat->kunnr.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
" Order Confirmed (Simplified - assumes if not blocked it's confirmed)
LOOP AT it_order_items ASSIGNING FIELD-SYMBOL(<fs_item>).
IF <fs_item>-lifsk IS INITIAL.
gs_event_log-salesorder = <fs_item>-vbeln.
gs_event_log-activity = 'Order Confirmed'.
CONCATENATE <fs_item>-erdat <fs_item>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_item>-ernam.
gs_event_log-customernumber = <fs_item>-kunnr.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form write_output_file
*&---------------------------------------------------------------------*
FORM write_output_file.
DATA: lt_final_output TYPE TABLE OF ty_event_log.
" Add common fields
LOOP AT gt_event_log ASSIGNING FIELD-SYMBOL(<fs_event>).
<fs_event>-sourcesystem = gv_sysid.
<fs_event>-lastdataupdate = gv_last_update.
ENDLOOP.
SORT gt_event_log BY salesorder starttime.
DELETE ADJACENT DUPLICATES FROM gt_event_log COMPARING ALL FIELDS.
lt_final_output = gt_event_log.
DATA: lt_fieldnames TYPE TABLE OF string.
APPEND 'SalesOrder' TO lt_fieldnames.
APPEND 'Activity' TO lt_fieldnames.
APPEND 'StartTime' TO lt_fieldnames.
APPEND 'SourceSystem' TO lt_fieldnames.
APPEND 'LastDataUpdate' TO lt_fieldnames.
APPEND 'User' TO lt_fieldnames.
APPEND 'CustomerNumber' TO lt_fieldnames.
APPEND 'SalesOrganization' TO lt_fieldnames.
APPEND 'NetAmount' TO lt_fieldnames.
APPEND 'MaterialNumber' TO lt_fieldnames.
APPEND 'DeliveryBlock' TO lt_fieldnames.
APPEND 'RejectionReason' TO lt_fieldnames.
APPEND 'SalesOrderCycleTime' TO lt_fieldnames.
DATA(lv_header) = REDUCE string(
INIT s = ''
FOR field IN lt_fieldnames
NEXT s = s && COND #( WHEN s = '' THEN field ELSE |,{ field }| ) ).
DATA: lt_file_content TYPE TABLE OF string.
APPEND lv_header TO lt_file_content.
LOOP AT lt_final_output INTO DATA(ls_output).
DATA(lv_line) = |"{ ls_output-salesorder }","{ ls_output-activity }","{ ls_output-starttime }","{ ls_output-sourcesystem }","{ ls_output-lastdataupdate }","{ ls_output-user }","{ ls_output-customernumber }","{ ls_output-salesorganization }",{ ls_output-netamount },"{ ls_output-materialnumber }","{ ls_output-deliveryblock }","{ ls_output-rejectionreason }","{ ls_output-salesordercycletime }"|.
APPEND lv_line TO lt_file_content.
ENDLOOP.
cl_gui_frontend_services=>gui_download(
EXPORTING
filename = p_file
filetype = 'ASC'
CHANGING
data_tab = lt_file_content ).
ENDFORM.Stappen
- Vereisten: Zorg ervoor dat u directe, alleen-lezen toegang hebt tot de onderliggende SAP ECC database. U hebt een databaseclienttool nodig, zoals DBeaver, SQL Server Management Studio of Oracle SQL Developer, om verbinding te maken en query's uit te voeren.
- SQL-script verkrijgen: Kopieer de complete SQL-query uit het 'query'-gedeelte van dit document.
- Verbinding maken met de database: Open uw databaseclient en breng een verbinding tot stand met de SAP ECC database-instantie. U hebt het serveradres, de poort, de databasenaam en de juiste inloggegevens nodig.
- Query configureren: Plak het SQL-script in een nieuw query-editorvenster. Zoek het configuratiegedeelte binnen de hoofd Common Table Expression (CTE) genaamd SalesOrders. Vervang de placeholderwaarden voor de startdatum ('{StartDate}'), einddatum ('{EndDate}'), Sales Organizations ('{SalesOrgs}') en documenttypen ('{DocTypes}') door de daadwerkelijke waarden voor uw analyse.
- Query uitvoeren: Voer het geconfigureerde SQL-script uit. Afhankelijk van het datumbereik en de grootte van uw SAP database, kan deze query enkele minuten duren.
- Resultaten controleren: Zodra de query is voltooid, wordt een resultatenset weergegeven. Scan kort de data om te controleren of deze de verwachte kolommen (SalesOrder, Activity, StartTime, etc.) bevat en dat er rijen worden geretourneerd voor verschillende activiteiten.
- Data exporteren: Gebruik de exportfunctionaliteit van uw databaseclient om de resultatenset op te slaan als een CSV-bestand. Geef het bestand een beschrijvende naam, zoals SAP_O2C_Event_Log.csv.
- Formatteren voor ProcessMind: Open het CSV-bestand in een spreadsheeteditor. Controleer of de kolomkoppen exact overeenkomen met de vereiste attributes (bijv. SalesOrder, Activity, StartTime). Zorg ervoor dat het datum- en tijdformaat voor StartTime en LastDataUpdate consistent is en wordt ondersteund door ProcessMind, zoals YYYY-MM-DD HH:MI:SS.
- Uploaden naar ProcessMind: Upload het uiteindelijke, geformatteerde CSV-bestand naar uw ProcessMind project voor analyse.
Configuratie
- Datumbereik: De query maakt gebruik van placeholders ('{StartDate}' en '{EndDate}') om verkooporders te filteren op basis van hun aanmaakdatum (VBAK.ERDAT). Een gebruikelijke analyseperiode is 3 tot 6 maanden data om een representatieve steekproef te garanderen zonder de database overmatig te belasten.
- Filter op Verkooporganisatie: Gebruik de '{SalesOrgs}' placeholder om de extractie te beperken tot specifieke verkooporganisaties (bijv. '1000', '2000'). Dit is essentieel om de analyse te richten en de queryprestaties te verbeteren.
- Filter op Documenttype: Gebruik de '{DocTypes}' placeholder om specifieke verkoopordertypen te selecteren (bijv. 'OR' voor Standaardorder). Dit helpt irrelevante documenten, zoals gratis leveringen of retouren, van de hoofdprocesstroom uit te sluiten.
- Bronsysteem-identificatie: Een hardgecodeerde placeholder '{SourceSystemName}' wordt gebruikt om elk record te taggen met het bronsysteem. Dit dient te worden ingesteld op een zinvolle naam voor uw SAP ECC-instantie (bijv. SAP_ECC_PRD).
- Databasecompatibiliteit: De functie voor het combineren van datum- en tijdvelden, [Your DB-specific timestamp function], is een placeholder. U moet deze vervangen door de juiste functie voor uw specifieke database (bijv. TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UZEIT), 'YYYYMMDDHH24MISS') voor SAP HANA of CAST(CDHDR.UDATE AS DATETIME) + CAST(CDHDR.UZEIT AS DATETIME) voor SQL Server).
- Vereisten: Deze methode vereist directe, alleen-lezen databasegegevens. De databasegebruiker dient toegang te hebben tot alle tabellen waarnaar in de query wordt verwezen, waaronder VBAK, VBAP, VBFA, CDHDR, CDPOS, LIKP, VBRK en BSAD.
a Voorbeeldquery sql
WITH SalesOrders AS (
SELECT VBELN
FROM VBAK
WHERE ERDAT BETWEEN '{StartDate}' AND '{EndDate}' -- Filter by creation date
AND VKORG IN ('{SalesOrgs}') -- Filter by Sales Organization(s)
AND AUART IN ('{DocTypes}') -- Filter by Sales Document Type(s)
)
-- 1. Sales Order Created
SELECT
vbak.VBELN AS "SalesOrder",
'Sales Order Created' AS "Activity",
[Your DB-specific timestamp function](vbak.ERDAT, vbak.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbak.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBAK vbak
JOIN SalesOrders so ON vbak.VBELN = so.VBELN
UNION ALL
-- 2. Sales Order Changed
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Sales Order Changed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG' AND cdhdr.TCODE IN ('VA02')
UNION ALL
-- 3. Credit Check Performed (Release)
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Credit Check Performed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'CMGST'
AND cdpos.VALUE_NEW = 'B' -- Credit status 'Released'
UNION ALL
-- 4. Order Confirmed (Overall status not blocked)
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Order Confirmed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'GBSTK'
AND cdpos.VALUE_OLD <> 'A' AND cdpos.VALUE_NEW = 'A' -- Status changes to 'Not yet processed'
UNION ALL
-- 5. Delivery Block Set
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Delivery Block Set' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
cdpos.VALUE_NEW AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBAK'
AND cdpos.FNAME = 'LIFSK'
AND cdpos.VALUE_NEW IS NOT NULL AND cdpos.VALUE_NEW <> ''
UNION ALL
-- 6. Delivery Created
SELECT
vbfa.VBELV AS "SalesOrder",
'Delivery Created' AS "Activity",
[Your DB-specific timestamp function](likp.ERDAT, likp.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
likp.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN LIKP likp ON vbfa.VBELN = likp.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J'
UNION ALL
-- 7. Picking Completed
SELECT
vbfa.VBELV AS "SalesOrder",
'Picking Completed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN CDHDR cdhdr ON vbfa.VBELN = cdhdr.OBJECTID
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J'
AND cdhdr.OBJECTCLASS = 'LIEFERUNG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'PKSTK'
AND cdpos.VALUE_NEW = 'C'
UNION ALL
-- 8. Goods Issued
SELECT
vbfa_gi.VBELV AS "SalesOrder",
'Goods Issued' AS "Activity",
[Your DB-specific timestamp function](mkpf.BUDAT, mkpf.CPUTM) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
mkpf.USNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa_gi
JOIN SalesOrders so ON vbfa_gi.VBELV = so.VBELN
JOIN MKPF mkpf ON vbfa_gi.VBELN = mkpf.XBLNR -- XBLNR is Reference Document Number
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa_gi.VBTYP_V = 'J' AND vbfa_gi.VBTYP_N = 'R'
UNION ALL
-- 9. Proof Of Delivery Confirmed
SELECT
vbfa.VBELV AS "SalesOrder",
'Proof Of Delivery Confirmed' AS "Activity",
[Your DB-specific timestamp function](likp.PODAT, '000000') AS "StartTime", -- PODAT is only a date
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
likp.AENAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN LIKP likp ON vbfa.VBELN = likp.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J' AND likp.PODAT IS NOT NULL AND likp.PODAT <> '00000000'
UNION ALL
-- 10. Invoice Created
SELECT
vbfa.VBELV AS "SalesOrder",
'Invoice Created' AS "Activity",
[Your DB-specific timestamp function](vbrk.ERDAT, vbrk.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbrk.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'M'
UNION ALL
-- 11. Invoice Cancelled
SELECT
vbfa.VBELV AS "SalesOrder",
'Invoice Cancelled' AS "Activity",
[Your DB-specific timestamp function](vbrk.ERDAT, vbrk.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbrk.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'M' AND vbfa.VBTYP_N = 'N'
UNION ALL
-- 12. Payment Received
SELECT
vbfa.VBELV AS "SalesOrder",
'Payment Received' AS "Activity",
[Your DB-specific timestamp function](bsad.AUGDT, '000000') AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
NULL AS "User", -- Clearing user not readily available here
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN BSAD bsad ON vbrk.VBELN = bsad.VBLNR
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'M'
AND bsad.AUGDT IS NOT NULL AND bsad.AUGDT <> '00000000'
UNION ALL
-- 13. Order Item Closed
SELECT DISTINCT
cdhdr.OBJECTID AS "SalesOrder",
'Order Item Closed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
vbap.MATNR AS "MaterialNumber",
NULL AS "DeliveryBlock",
vbap.ABGRU AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAP vbap ON cdhdr.OBJECTID = vbap.VBELN AND SUBSTRING(cdpos.TABKEY, 4, 6) = vbap.POSNR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUP'
AND cdpos.FNAME = 'GBSTA'
AND cdpos.VALUE_NEW = 'C' -- Item is completely processed
UNION ALL
-- 14. Order Cancelled
SELECT DISTINCT
cdhdr.OBJECTID AS "SalesOrder",
'Order Cancelled' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
vbap.MATNR AS "MaterialNumber",
NULL AS "DeliveryBlock",
cdpos.VALUE_NEW AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAP vbap ON cdhdr.OBJECTID = vbap.VBELN AND SUBSTRING(cdpos.TABKEY, 4, 6) = vbap.POSNR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBAP'
AND cdpos.FNAME = 'ABGRU'
AND cdpos.VALUE_NEW IS NOT NULL AND cdpos.VALUE_NEW <> '';