Datatemplate voor order-to-cash, verwerking van verkooporders
Datatemplate voor order-to-cash, verwerking van verkooporders
- Aanbevolen attributen om te verzamelen
- Belangrijke activiteiten om te volgen
- Aanwijzingen voor data-extractie uit SAP ECC
Attributen voor order-to-cash, verwerking van verkooporders
| Naam | Beschrijving | ||
|---|---|---|---|
| Verkooporder SalesOrder | De unieke identificatiecode van een verkooporderdocument. Deze dient als de primaire case voor het volgen van het volledige order-to-cash-proces. | ||
| Beschrijving De verkooporder is het centrale document in het verkoopproces en bevat het verzoek van een klant om goederen of diensten. Alle informatie die nodig is om dit verzoek van begin tot eind af te handelen, staat erin. Bij process mining wordt dit attribuut gebruikt als Case-ID. Elk uniek verkoopordernummer staat voor één procesinstantie van begin tot eind. Door processen per verkooporder te analyseren, kun je de volledige levenscyclus volgen, doorlooptijden meten en verschillen tussen afzonderlijke klantorders opsporen. Waarom dit belangrijk is Dit is de sleutel waarmee je alle bijbehorende activiteiten en gebeurtenissen koppelt. Zo kun je het volledige traject van elke klantorder analyseren. Waar vind je dit? Te vinden in de tabel met kopgegevens van verkoopdocumenten (VBAK), in het veld VBELN. Voorbeelden 900001234590000123469000012347 | |||
| Activiteit Activity | De naam van een specifieke bedrijfsstap of gebeurtenis in het verkooporderproces. | ||
| Beschrijving Dit attribuut beschrijft één stap in het order-to-cash-proces, zoals 'Verkooporder aangemaakt', 'Levering aangemaakt' of 'Betaling ontvangen'. Deze activiteiten vormen de bouwstenen waarmee je de processtroom van elke verkooporder reconstrueert. De volgorde en timing van activiteiten analyseren is de kern van process mining. Zo kun je de proceskaart visualiseren, bottlenecks opsporen, procesvarianten ontdekken en controleren of het proces voldoet aan een standaardmodel. Activiteiten worden meestal afgeleid uit een combinatie van documentaanmaak, statuswijzigingen en transactiecodes die in het systeem zijn vastgelegd. Waarom dit belangrijk is Activiteiten vormen de basis van de proceskaart en maken het mogelijk de processtroom, afwijkingen en bottlenecks te visualiseren en analyseren. Waar vind je dit? Dit is een afgeleid attribuut. Tijdens de data-extractie worden SAP-transactiecodes (T-codes), statuswijzigingen van documenten (bijvoorbeeld in de tabellen VBUK en VBUP) of wijzigingslogboeken (tabellen CDHDR en CDPOS) doorgaans gekoppeld aan herkenbare activiteitsnamen. Voorbeelden Verkooporder aangemaaktLevering aangemaaktGoederen afgeboektFactuur aangemaaktBetaling ontvangen | |||
| Bronsysteem SourceSystem | Geeft aan uit welk systeem de data is gehaald. | ||
| Beschrijving Dit attribuut vermeldt het systeem waar de data vandaan komt, bijvoorbeeld de naam van een SAP ECC-instantie of het clientnummer. Zo krijgt de data context, vooral in omgevingen met meerdere productiesystemen of gegevens uit oudere systemen. In analyses kun je de data hiermee filteren of uitsplitsen naar herkomst. Dat is handig om processen in verschillende systemen te vergelijken of de datakwaliteit en consistentie tijdens een systeemmigratie te controleren. Waarom dit belangrijk is Geeft belangrijke context, vooral in omgevingen met meerdere systemen. Zo kun je processen vergelijken en blijft de herkomst van de data duidelijk. Waar vind je dit? Deze waarde wordt meestal tijdens de data-extractie toegevoegd. Vaak is het een vaste waarde voor de SAP System ID (SAPSID) of de client (MANDT). Voorbeelden ECC_PROD_800SAP_ERP_EU1ECC_QAS_300 | |||
| Laatste data-update LastDataUpdate | Timestamp die aangeeft wanneer de data voor deze registratie voor het laatst vanuit het bronsysteem is bijgewerkt. | ||
| Beschrijving Dit attribuut registreert de datum en tijd van de meest recente data-extractie of update voor een gebeurtenis of case. Zo zie je hoe actueel de geanalyseerde data is. In dashboards en rapporten helpt deze informatie gebruikers te beoordelen hoe recent de inzichten zijn. Je ziet of de analyse de huidige situatie in de bedrijfsvoering weergeeft of op oudere data is gebaseerd. Zo weten gebruikers waar ze aan toe zijn. Waarom dit belangrijk is Zo weten gebruikers hoe actueel de data is en kunnen ze op basis van process mining tijdig en goed onderbouwd beslissingen nemen. Waar vind je dit? Dit is een metadatattribuut dat de data-extractietool of het extractieproces invult wanneer de data wordt ingelezen. Het staat niet in de SAP-brontabellen. Voorbeelden 2024-06-10T05:00:00Z2024-06-11T05:00:00Z2024-06-12T05:00:00Z | |||
| Starttijd StartTime | De timestamp die aangeeft wanneer een activiteit of gebeurtenis begon. | ||
| Beschrijving De starttijd, ook wel de eventtimestamp genoemd, legt de exacte datum en tijd van een activiteit vast. Bijvoorbeeld wanneer een verkooporder is aangemaakt, goederen zijn afgegeven of een factuur is geboekt. Deze timestamp vormt de basis voor alle tijdsanalyses bij process mining. Je gebruikt hem om doorlooptijden tussen activiteiten en de totale duur van een case te berekenen, en om vertragingen of bottlenecks op te sporen. Nauwkeurige timestamps zijn belangrijk voor prestatiedashboards, bijvoorbeeld voor het volgen van tijdige leveringen of doorlooptijden van de orderafhandeling. Waarom dit belangrijk is Dit attribuut is nodig om prestatiemaatstaven zoals doorlooptijden en duur te berekenen en bottlenecks op te sporen. Waar vind je dit? Dit samengestelde attribuut wordt meestal afgeleid door een datumveld (bijvoorbeeld ERDAT) en een tijdveld (bijvoorbeeld ERZET) uit verschillende SAP-tabellen te combineren, zoals VBAK (verkooporder), LIKP (levering) en VBRK (factuur). Voorbeelden 2023-04-15T09:00:12Z2023-04-16T14:30:00Z2023-04-20T11:22:45Z | |||
| Afwijsreden RejectionReason | Een code die aangeeft waarom een verkooporderregel is afgewezen of geannuleerd. | ||
| Beschrijving De afwijsreden geeft aan waarom een verkooporder of specifieke orderregel niet is afgehandeld. Mogelijke redenen zijn een annulering door de klant, een product dat niet beschikbaar is of andere zakelijke omstandigheden. Dit attribuut is belangrijk voor het dashboard 'Trends in annuleringen van verkooporders'. Door de meest voorkomende afwijsredenen te analyseren, kun je de oorzaken van verloren verkopen opsporen. Op basis daarvan kun je het voorraadbeheer, de prijsstrategie of de communicatie met klanten verbeteren en het aantal geannuleerde orders terugdringen. Waarom dit belangrijk is Laat zien waarom orders worden geannuleerd. Zo kun je oorzaken opsporen, verloren verkopen beperken en de nauwkeurigheid van prognoses verbeteren. Waar vind je dit? Te vinden in de tabel met regelgegevens van verkoopdocumenten (VBAP), in het veld ABGRU. Voorbeelden 0215Z5 | |||
| Artikelnummer MaterialNumber | De unieke identificatiecode van een verkocht product of een verkochte dienst. | ||
| Beschrijving Het artikelnummer identificeert het specifieke artikel op een verkooporderregel. Omdat één verkooporder meerdere artikelen kan bevatten, wordt dit attribuut meestal op regelniveau geanalyseerd. Door het proces per artikelnummer te analyseren, kun je problemen met specifieke producten opsporen. Zo zie je of bepaalde producten vaker leiden tot langere afhandeling, leveringsblokkeringen of factuurverschillen. Dit helpt supplychain- en productmanagers om het proces voor verschillende productgroepen te verbeteren. Waarom dit belangrijk is Maakt procesanalyse per product mogelijk. Zo zie je welke producten samenhangen met vertragingen, blokkeringen of herstelwerk. Waar vind je dit? Te vinden in de tabel met regelgegevens van verkoopdocumenten (VBAP), in het veld MATNR. Voorbeelden FG-1001-ARAW-205BSERV-INSTALL | |||
| Gebruiker User | De gebruikers-ID van de medewerker die het document heeft aangemaakt of voor het laatst heeft gewijzigd, of de activiteit heeft uitgevoerd. | ||
| Beschrijving Dit attribuut legt de SAP-gebruikers-ID vast van degene die verantwoordelijk is voor een gebeurtenis in het proces. Zo zie je bijvoorbeeld welke verkoopmedewerker de order heeft aangemaakt of welke magazijnmedewerker de goederenafgifte heeft geboekt. Door het proces per gebruiker te analyseren, krijg je inzicht in de werkverdeling, zie je waar training nodig is en ontdek je verschillen in de manier waarop gebruikers dezelfde taak uitvoeren. Dit is belangrijk voor dashboards over bronprestaties, compliance en handmatige handelingen. Waarom dit belangrijk is Geeft inzicht in bronprestaties en werkverdeling, helpt procesafwijkingen per gebruiker op te sporen en is belangrijk voor compliance en automatiseringsanalyse. Waar vind je dit? In veel SAP-koptabellen te vinden als het veld 'Gemaakt door' (ERNAM) of 'Gewijzigd door' (AENAM), bijvoorbeeld in VBAK, LIKP en VBRK. Voorbeelden CBURKEJSMITHRWILLIAMS | |||
| Klantnummer CustomerNumber | De unieke identificatiecode van de klant die de verkooporder heeft geplaatst. | ||
| Beschrijving Dit attribuut staat voor de 'Sold-to Party', de hoofdklant die aan de verkooporder is gekoppeld. Het verbindt de transactie met een specifieke klant in de stamgegevens. Met het klantnummer kun je het proces uitsplitsen en klantgedrag en prestaties per klant bekijken. Zo zie je welke klanten de langste doorlooptijden hebben, de meeste herstelwerkzaamheden nodig hebben of het vaakst hun order wijzigen. Dit helpt bij het verbeteren van klantrelaties en de dienstverlening. Waarom dit belangrijk is Maakt analyse per klant mogelijk. Zo kun je procesproblemen bij specifieke klanten opsporen en de prestaties per klant meten. Waar vind je dit? Te vinden in de tabel met kopgegevens van verkoopdocumenten (VBAK), in het veld KUNNR. Voorbeelden 100234100567200112 | |||
| Leveringsblokkering DeliveryBlock | Een code die aangeeft of een verkooporder is geblokkeerd voor levering, waardoor er geen leveringsdocument kan worden aangemaakt. | ||
| Beschrijving De leveringsblokkering is een status op een verkooporder, op kop- of regelniveau, waarmee het proces tijdelijk wordt stilgezet vóór de leveringsstap. Een gebruiker kan de blokkering handmatig instellen. Het systeem kan dit ook automatisch doen, bijvoorbeeld bij een overschrijding van de kredietlimiet of onvolledige gegevens. Dit attribuut is belangrijk voor het dashboard 'Analyse van verkooporderblokkeringen en herstelwerk'. Door het aantal, de duur en de redenen van leveringsblokkeringen te analyseren, kun je de belangrijkste bottlenecks in de orderafhandeling opsporen. Minder blokkeringen helpen om leveringen op tijd af te handelen en de totale doorlooptijd te verkorten. Waarom dit belangrijk is Maakt bottlenecks in de orderafhandeling zichtbaar. Door te analyseren waarom en hoe vaak orders worden geblokkeerd, kun je de doorstroming verbeteren. Waar vind je dit? Te vinden in de tabel met kopgegevens van verkoopdocumenten (VBAK), in het veld LIFSK. Voorbeelden 0102Z1 | |||
| Netto bedrag NetAmount | De totale waarde van de verkooporder, exclusief belastingen en kortingen op kopniveau. | ||
| Beschrijving Het netto bedrag is de geldwaarde van de verkooporder. Dit is een belangrijke financiële maatstaf voor elke procesinstantie. Met dit attribuut kun je process mining toepassen op basis van orderwaarde. Zo kun je verbeteringen richten op orders met een hoge waarde. Analisten kunnen procesproblemen, zoals vertragingen of herstelwerk, koppelen aan financiële gevolgen. Dat helpt om de businesscase voor verandering te onderbouwen. Je kunt bijvoorbeeld nagaan of orders met een hoge waarde efficiënter worden verwerkt dan orders met een lage waarde. Waarom dit belangrijk is Maakt analyse op basis van orderwaarde mogelijk. Zo kun je verbeteringen richten op orders met de grootste financiële impact voor het bedrijf. Waar vind je dit? Te vinden in de tabel met kopgegevens van verkoopdocumenten (VBAK), in het veld NETWR. Voorbeelden 1500.0012550.75850.50 | |||
| Verkooporganisatie SalesOrganization | De organisatie-eenheid die verantwoordelijk is voor de verkoop van producten of diensten. | ||
| Beschrijving Een verkooporganisatie is een belangrijke organisatie-eenheid in SAP die de bedrijfsstructuur afstemt op de verkoop. De eenheid is verantwoordelijk voor het onderhandelen over verkoopvoorwaarden en het distribueren van goederen en diensten. Bij process mining is dit attribuut een belangrijke dimensie voor analyses. Je kunt er procesprestaties, efficiëntie en compliance mee vergelijken tussen verkoopafdelingen, regio's of divisies. Zo ontdek je wat goed presterende organisaties anders doen en waar andere onderdelen kunnen verbeteren. Waarom dit belangrijk is Maakt vergelijking tussen organisatieonderdelen mogelijk, zodat je de procesefficiëntie en compliance in verschillende bedrijfseenheden of regio's kunt beoordelen. Waar vind je dit? Te vinden in de tabel met kopgegevens van verkoopdocumenten (VBAK), in het veld VKORG. Voorbeelden 100025003100 | |||
| Bevestigde leverdatum ConfirmedDeliveryDate | De datum waarop de levering van goederen of diensten aan de klant is bevestigd. | ||
| Beschrijving Dit is de afgesproken leverdatum die aan de klant is doorgegeven, op basis van de beschikbaarheid van materialen en de planning. De datum dient als uitgangspunt om de leverprestaties te meten. Dit attribuut vormt de basis voor het dashboard 'Prestaties van tijdige levering' en de KPI voor het percentage tijdige leveringen. Door de bevestigde leverdatum te vergelijken met de werkelijke datum van goederenafgifte, zie je of een order op tijd, eerder of later is geleverd. Dit is een belangrijke maatstaf voor de betrouwbaarheid van de toeleveringsketen en de klanttevredenheid. Waarom dit belangrijk is Dit is de maatstaf voor tijdige leveringen, een belangrijke KPI voor klanttevredenheid en efficiëntie in de toeleveringsketen. Waar vind je dit? Te vinden in de tabel met schemaregels van verkoopdocumenten (VBEP), in het veld EDATU. Voorbeelden 2023-05-102023-06-202023-07-01 | |||
| Is herstelwerk IsRework | Een booleaanse waarde die aangeeft of een verkooporder na de eerste aanmaak ingrijpend is gewijzigd of herstelwerk heeft ondergaan. | ||
| Beschrijving Dit berekende attribuut markeert procesinstanties waarin herstelwerk heeft plaatsgevonden, bijvoorbeeld na een of meer activiteiten met de naam 'Verkooporder gewijzigd'. Tijdens de projectinrichting bepaal je wat als herstelwerk geldt, bijvoorbeeld een wijziging van de prijs, hoeveelheid of leverdatum. Dit attribuut is belangrijk voor het dashboard 'Herstelwerk en wijzigingsfrequentie van verkooporders' en de KPI voor het percentage verkooporders met herstelwerk. Je kunt orders hiermee eenvoudig filteren en vergelijken: welke zijn zonder onderbreking afgehandeld en welke vereisten handmatige wijzigingen? Zo zie je wat herstelwerk betekent voor doorlooptijden en kosten. Waarom dit belangrijk is Maakt zichtbaar hoe vaak herstelwerk voorkomt. Zo kun je de oorzaken en de gevolgen voor de procesefficiëntie en doorlooptijd analyseren. Waar vind je dit? Dit is een berekend attribuut op basis van het event log. De logica controleert of er activiteiten met de naam 'Verkooporder gewijzigd' of specifieke wijzigingsgebeurtenissen in de tabellen CDHDR/CDPOS voorkomen. Voorbeelden truefalse | |||
| Is op tijd geleverd IsOnTimeDelivery | Een booleaanse waarde die aangeeft of de goederen op of vóór de bevestigde leverdatum zijn verzonden. | ||
| Beschrijving Dit berekende attribuut vergelijkt de werkelijke datum van goederenafgifte met de 'ConfirmedDeliveryDate' van een verkooporder. Vond de goederenafgifte op of vóór de bevestigde datum plaats, dan is de waarde waar. Anders is de waarde onwaar. Met dit attribuut maak je eenvoudig het dashboard 'Prestaties van tijdige levering' en bereken je de KPI voor het percentage tijdige leveringen. Je kunt prestaties eenvoudig optellen en visualiseren, zonder in elke analyse of grafiek opnieuw datums te vergelijken. Zo zie je in één oogopslag hoe betrouwbaar de leveringen zijn. Waarom dit belangrijk is Geeft een duidelijke, eenvoudige maatstaf voor leverprestaties en maakt het makkelijk om de KPI voor het totale percentage tijdige leveringen te berekenen. Waar vind je dit? Dit is een berekend attribuut. De logica vergelijkt de timestamp van de activiteit 'Goederen afgegeven' met de waarde van het attribuut 'ConfirmedDeliveryDate'. Voorbeelden truefalse | |||
| Kredietcontrolestatus CreditCheckStatus | Geeft de status van de kredietcontrole voor het verkoopdocument aan. | ||
| Beschrijving Dit attribuut toont de uitkomst van de automatische of handmatige kredietcontrole van een verkooporder. Veelvoorkomende statussen zijn 'Goedgekeurd', 'Afgewezen' en 'Geblokkeerd'. Dit attribuut is belangrijk voor het dashboard 'Analyse van de verwerkingstijd van kredietcontroles'. Vertragingen of blokkeringen bij de kredietcontrole kunnen de totale doorlooptijd van de orderafhandeling flink verlengen. Door deze status te analyseren, krijg je inzicht in de efficiëntie van het kredietbeheer en de gevolgen daarvan voor de verkoopsnelheid. Waarom dit belangrijk is Heeft direct invloed op de snelheid van de orderverwerking. Door deze status te analyseren, kun je bottlenecks in het kredietbeheer opsporen die de orderafhandeling vertragen. Waar vind je dit? Te vinden in de tabel met kopstatussen van verkoopdocumenten (VBUK) of rechtstreeks in VBAK als kredietstatusveld, bijvoorbeeld CMGST. Voorbeelden ABD | |||
| Verzendvoorwaarden ShippingConditions | Bepaalt de algemene verzendmethode voor de levering van goederen aan de klant. | ||
| Beschrijving De verzendvoorwaarden bepalen hoe een order wordt verzonden, bijvoorbeeld als standaardzending, expreszending of afhalen. De voorwaarden worden met de klant afgesproken en zijn van invloed op de logistieke planning. Je gebruikt dit attribuut voor de analyse 'Efficiëntie en kosten van verzendmethoden'. Door het proces uit te splitsen naar verzendvoorwaarden, kun je nagaan of bepaalde methoden vaker tot vertragingen of langere doorlooptijden leiden. Deze data helpt de logistiek te verbeteren en de verwachtingen van klanten over levertijden te beheren. Waarom dit belangrijk is Maakt analyse van logistieke prestaties mogelijk. Zo kun je nagaan of bepaalde verzendmethoden samenhangen met vertragingen of juist efficiënter zijn. Waar vind je dit? Te vinden in de tabel met kopgegevens van verkoopdocumenten (VBAK), in het veld VSBED. Voorbeelden 011020 | |||
Activiteiten voor order-to-cash, verwerking van verkooporders
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Betaling ontvangen | Deze gebeurtenis geeft aan dat de betaling van de klant is ontvangen en aan de factuur is toegewezen. Daarmee wordt de openstaande post bij debiteuren afgeboekt. Dit is een boekhoudkundige gebeurtenis die wordt afgeleid uit de afboeking van een financieel document. | ||
| Waarom dit belangrijk is Dit is de laatste stap voordat de verkoopopbrengst binnen is. Het is het eindpunt voor het meten van de doorlooptijd van factuur tot betaling en de totale doorlooptijd van orderafhandeling. Waar vind je dit? Afgeleid uit de gegevens van het vereffeningsdocument voor de klantregel in de BSEG-tabel. Zodra BSEG-AUGBL (vereffeningsdocument) en BSEG-AUGDT (vereffeningsdatum) zijn ingevuld, is de betaling ontvangen. Vastleggen Afgeleid uit de ingevulde vereffeningsdatum (AUGDT) voor de debiteurenregel in de BSEG-tabel. Gebeurtenistype inferred | |||
| Factuur aangemaakt | Geeft aan dat de klantfactuur of het facturatiedocument is aangemaakt. Dit is een expliciete gebeurtenis die een nieuw document in het systeem aanmaakt en het betalingsdeel van het proces start. | ||
| Waarom dit belangrijk is Dit is een belangrijke mijlpaal: vanaf dit moment wordt de doorlooptijd van factuur tot betaling gemeten. Vertraging bij het factureren heeft direct gevolgen voor de cashflow. Waar vind je dit? Vastgelegd in de VBRK-tabel (facturatiedocument: kopgegevens), op basis van de aanmaakdatum (ERDAT). De koppeling met de verkooporder of levering staat in de VBFA-tabel. Vastleggen Gebeurtenis op basis van de aanmaaktimestamp (ERDAT) in de VBRK-tabel. Gebeurtenistype explicit | |||
| Goederen afgeboekt | Een belangrijke gebeurtenis waarbij het eigendom van de goederen overgaat en ze het magazijn officieel verlaten. Dit is een financiële boeking die een materiaaldocument aanmaakt en de voorraad bijwerkt. | ||
| Waarom dit belangrijk is Dit is de verzendgebeurtenis en een belangrijke mijlpaal voor het meten van tijdige levering en de doorlooptijd van de afhandeling. De gebeurtenis leidt tot financiële updates en is een onomkeerbare stap in het fysieke afhandelingsproces. Waar vind je dit? Aanmaak van een materiaaldocument (MKPF/MSEG) met een goederenafgiftebewegingstype (bijvoorbeeld 601), gekoppeld aan het leveringsdocument. Vastleggen Aanmaak van een materiaaldocument (MKPF/MSEG) met een goederenafgiftebewegingstype, gekoppeld aan de levering. Gebeurtenistype explicit | |||
| Order bevestigd | Deze activiteit geeft aan dat de verkooporder alle eerste controles heeft doorstaan en klaar is voor afhandeling. Dit wordt meestal afgeleid wanneer de order niet meer is geblokkeerd en bevestigde hoeveelheden op de schedule lines heeft. | ||
| Waarom dit belangrijk is Dit is een belangrijke mijlpaal die de invoer van de order scheidt van de afhandeling. Vanaf dit punt kun je de doorlooptijd van de afhandeling en de prestaties van tijdige levering meten. Waar vind je dit? Dit kan worden afgeleid wanneer schedule lines in VBEP een bevestigde hoeveelheid hebben (BMENG > 0) en de order niet is geblokkeerd voor levering (bijvoorbeeld wanneer VBUK-LIFSK leeg is). Vastleggen Afgeleid uit de bevestiging van schedule lines (VBEP-BMENG > 0) en het opheffen van blokkades op kopniveau. Gebeurtenistype inferred | |||
| Orderregel gesloten | Deze activiteit markeert de definitieve afsluiting van een verkooporderregel. De regel is volledig geleverd en gefactureerd en geldt als afgerond. Dit wordt afgeleid uit de algemene status van de regel. | ||
| Waarom dit belangrijk is Dit is de succesvolle eindgebeurtenis van het proces. Door te analyseren wanneer regels worden afgesloten, krijg je inzicht in de totale procesduur en zie je welke orders onnodig lang openstaan. Waar vind je dit? Afgeleid uit het veld voor de algemene status van de regel in de VBUP-tabel (verkoopdocument: regelstatus). De regel is gesloten wanneer VBUP-GBSTA 'C' is (Volledig verwerkt). Vastleggen Afgeleid uit de regelstatus (VBUP-GBSTA), die verandert in 'C' (Volledig verwerkt). Gebeurtenistype inferred | |||
| Verkooporder aangemaakt | Dit markeert het aanmaken van een nieuw verkoopdocument. De gebeurtenis wordt vastgelegd wanneer een gebruiker een nieuwe order opslaat, meestal via transactie VA01 in SAP. | ||
| Waarom dit belangrijk is Dit is de belangrijkste startgebeurtenis voor het Order-to-Cash-proces. De timing ervan analyseren is essentieel om de totale doorlooptijd en het aantal binnenkomende orders te meten. Waar vind je dit? Vastgelegd in tabel VBAK (kopgegevens verkoopdocument) met de aanmaakdatum (ERDAT) en -tijd (ERZET). De transactiecode staat in VBAK-TCODE. Vastleggen Gebeurtenis op basis van de aanmaaktimestamp (ERDAT, ERZET) in tabel VBAK. Gebeurtenistype explicit | |||
| Factuur geannuleerd | Geeft aan dat een eerder aangemaakt facturatiedocument is teruggedraaid. Dit is een expliciete transactie die een nieuw annuleringsdocument aanmaakt om het oorspronkelijke document te verrekenen. | ||
| Waarom dit belangrijk is Door factuurannuleringen bij te houden, kun je problemen met prijzen, verschillen in verzending of gegevensfouten opsporen. Dit helpt bij het bepalen van de KPI voor het percentage factuurverschillen. Waar vind je dit? Expliciete gebeurtenis die wordt vastgelegd wanneer een annuleringsdocument voor facturatie wordt aangemaakt (VBRK-VBTYP = 'N' of 'O'). De oorspronkelijke factuur wordt vermeld in VBRK-SFAKN. Vastleggen Aanmaak van een annuleringsdocument in VBRK, met een verwijzing naar de oorspronkelijke factuur. Gebeurtenistype explicit | |||
| Kredietcontrole uitgevoerd | Dit geeft aan dat de automatische of handmatige kredietcontrole voor de klant bij de verkooporder is afgerond. Meestal wordt dit afgeleid uit een wijziging van de algemene kredietstatus van het document. | ||
| Waarom dit belangrijk is De kredietcontrole is vaak een belangrijke bottleneck. De benodigde tijd meten is essentieel voor de 'Analyse van de verwerkingstijd van kredietcontroles' en om orders sneller te verwerken. Waar vind je dit? Afgeleid uit de kredietstatusvelden in tabel VBUK (status van verkoopdocument: kop). Een wijziging van VBUK-CMGST van geblokkeerd naar vrijgegeven markeert deze activiteit. Vastleggen Afgeleid uit wijzigingen van het veld voor de algemene kredietstatus (VBUK-CMGST). Gebeurtenistype inferred | |||
| Levering aangemaakt | Deze gebeurtenis markeert het aanmaken van het uitgaande leveringsdocument. Dat is de opdracht aan het magazijn om te beginnen met verzamelen en verzenden. De gebeurtenis wordt rechtstreeks uit de documentstroom gehaald. | ||
| Waarom dit belangrijk is Dit is de eerste stap in de fysieke afhandeling. De tijd tussen de orderbevestiging en het aanmaken van de levering laat zien hoe snel het logistieke proces op gang komt. Waar vind je dit? Het aanmaken van een record in tabel LIKP (kopgegevens leveringsdocument). De koppeling met de verkooporder staat in documentstroomtabel VBFA. Vastleggen Gebeurtenis op basis van de aanmaaktimestamp in tabel LIKP, gekoppeld via tabel VBFA. Gebeurtenistype explicit | |||
| Leveringsblokkade ingesteld | Dit is een actie waarbij een leveringsblokkade op de verkooporder wordt ingesteld, zodat er geen leveringsdocument kan worden aangemaakt. De blokkade kan rechtstreeks uit wijzigingslogs worden gehaald of uit statustabellen worden afgeleid. | ||
| Waarom dit belangrijk is Deze activiteit houdt rechtstreeks verband met de KPI 'Percentage geblokkeerde verkooporders'. Door te achterhalen waarom en hoe vaak blokkades worden ingesteld, kun je de oorzaken van vertragingen bij de afhandeling vinden. Waar vind je dit? Terug te vinden in wijzigingslogs (CDHDR/CDPOS) voor veld VBAK-LIFSK. Je kunt de blokkade ook afleiden uit het moment waarop het veld VBAK-LIFSK wordt ingevuld. Vastleggen Gebeurtenis uit wijzigingsdocumenten voor veld VBAK-LIFSK of VBAP-LIFSP. Gebeurtenistype explicit | |||
| Ontvangstbevestiging bevestigd | Deze activiteit geeft aan dat de klant de goederen heeft ontvangen. De activiteit wordt vastgelegd zodra het bewijs van levering in het systeem wordt geregistreerd. Vaak wordt dan ook de status van het leveringsdocument bijgewerkt. | ||
| Waarom dit belangrijk is Deze gebeurtenis bevat de werkelijke leverdatum. Die is nodig om het percentage tijdige leveringen nauwkeurig te vergelijken met de beloofde datum. Waar vind je dit? Afgeleid uit de bewijs-van-leveringstatus (VBUK-PODAT), die op 'C' (Bevestigd) wordt gezet. De bevestigingsdatum staat in VLPOD-PODAT. Dit is niet in elk systeem geïmplementeerd. Vastleggen Afgeleid uit de bijgewerkte POD-status van de levering (VBUK-PODAT) of een vermelding in de VLPOD-tabel. Gebeurtenistype inferred | |||
| Order geannuleerd | Geeft aan dat een verkooporder vóór de afhandeling is geannuleerd. Dit wordt meestal vastgelegd door voor alle relevante orderregels een afwijsreden in te vullen. | ||
| Waarom dit belangrijk is Dit is een eindpunt voor mislukte orders en vormt de basis voor de KPI voor het percentage geannuleerde orders. Door te begrijpen wanneer en waarom orders worden geannuleerd, krijg je inzicht in problemen in het verkoopproces. Waar vind je dit? Afgeleid uit het ingevulde veld VBAP-ABGRU (afwijsreden) voor alle actieve regels van een verkooporder. De wijzigingsdatum is te vinden in CDHDR/CDPOS. Vastleggen Afgeleid uit het ingevulde veld 'Afwijsreden' (VBAP-ABGRU) voor alle regels. Gebeurtenistype inferred | |||
| Orderverzameling afgerond | Dit geeft aan dat alle artikelen voor de levering fysiek uit het magazijn zijn verzameld. Als Warehouse Management (WM) wordt gebruikt, kan dit worden afgeleid uit de status van de Transfer Order. | ||
| Waarom dit belangrijk is Door de verzameltijd te analyseren, kun je de magazijnprocessen verbeteren. Vertragingen in deze stap hebben direct invloed op de totale verzendtijd en de doorlooptijd van de afhandeling. Waar vind je dit? Afgeleid uit de wijziging van de verzamelstatus van het leveringsartikel in tabel LIPS-KOSTA naar 'C' (volledig verzameld). Als WM actief is, kan dit worden afgeleid uit de bevestiging van de Transfer Order (tabellen LTAK/LTAP). Vastleggen Afgeleid uit een wijziging van de verzamelstatus (LIPS-KOSTA) of de bevestiging van de WM Transfer Order. Gebeurtenistype inferred | |||
| Verkooporder gewijzigd | Dit staat voor een wijziging aan een bestaande verkooporder na de eerste aanmaak. Wijzigingen worden vastgelegd in speciale wijzigingslogtabellen (CDHDR, CDPOS) wanneer bijvoorbeeld de hoeveelheid, prijs of datum wordt aangepast. | ||
| Waarom dit belangrijk is Door wijzigingen te volgen, kun je herstelwerk, instabiliteit in het proces en problemen met de datakwaliteit opsporen. Veelvuldige wijzigingen kunnen wijzen op problemen bij de eerste invoer van de order en tot vertragingen leiden. Waar vind je dit? Opgehaald uit de wijzigingsdocumenttabellen CDHDR (kop) en CDPOS (regel) voor OBJECTCLAS = 'VERKBELEG'. De timestamp en het gewijzigde veld zijn hierin terug te vinden. Vastleggen Gebeurtenis uit wijzigingsdocumenttabellen (CDHDR, CDPOS) voor verkoopdocumentobjecten. Gebeurtenistype explicit | |||
Extractiegidsen
Stappen
- Programma ontwikkelen: Maak met transactie SE38 of SE80 een nieuw uitvoerbaar ABAP-programma. Hierin komt de volledige extractielogica.
- Selectiescherm definiëren: Maak in het programma een selectiescherm om de data te filteren. Voeg parameters toe voor de aanmaakdatum van het verkoopdocument (VBAK-ERDAT), de verkooporganisatie (VBAK-VKORG) en het verkoopdocumenttype (VBAK-AUART). Zo kun je de extractie opnieuw gebruiken en beheren.
- Datadeclaraties: Definieer de interne tabellen en structuren voor de gegevens uit verschillende SAP-tabellen, zoals VBAK, VBAP, VBFA, CDHDR, CDPOS, VBRK en BSAD. Definieer ook de uitvoerstructuur voor het event log, met de vereiste attributen.
- Basisverkooporders selecteren: Schrijf de eerste SELECT-instructie om de kopgegevens (VBAK) en artikelen (VBAP) van verkooporders op te halen op basis van de invoer op het selectiescherm. Dit vormt de basisset van cases voor de analyse.
- Gebeurtenis 'Aangemaakt' ophalen: Loop door de geselecteerde VBAK-records. Vul voor elk record de structuur van het event log met de activiteit 'Verkooporder aangemaakt'. Gebruik VBAK-ERDAT en VBAK-ERZET als StartTime.
- Gebeurtenissen uit het wijzigingslogboek ophalen: Selecteer uit CDHDR en CDPOS de records waarvan OBJECTCLAS 'VERKBELEG' is en die bij de geselecteerde verkooporders horen. Loop door de resultaten en zoek naar specifieke veldwijzigingen. Een wijziging van VBAK-LIFSK betekent bijvoorbeeld 'Leveringsblokkade ingesteld' en een wijziging van VBUK-CMGST 'Kredietcontrole uitgevoerd'. Leg andere relevante wijzigingen vast als 'Verkooporder gewijzigd'.
- Documentstroomgegevens ophalen: Raadpleeg voor de geselecteerde verkooporders de documentstroomtabel VBFA. Deze tabel koppelt verkooporders aan vervolgdocumenten, zoals leveringen, goederenbewegingen en facturen. Selecteer alle gerelateerde documenten voor verdere verwerking.
- Leverings- en afhandelingsgebeurtenissen ophalen: Raadpleeg LIKP en LIPS met de leveringsdocumentnummers uit VBFA om gebeurtenissen als 'Levering aangemaakt' op te halen. Raadpleeg MKPF en MSEG voor goederenafgifte-documenten (bewegingssoort '601') om de gebeurtenis 'Goederen afgegeven' vast te leggen. Is Warehouse Management actief, raadpleeg dan LTAK en LTAP voor de bevestigingstijd van het laatste transferorderartikel. Daarmee bepaal je wanneer 'Picken voltooid' is. Controleer de leveringsstatus VBUK-PODAT voor 'Aflevering bevestigd'.
- Facturerings- en betalingsgebeurtenissen ophalen: Raadpleeg VBRK en VBRP met de factuurdocumentnummers uit VBFA om gebeurtenissen als 'Factuur aangemaakt' en 'Factuur geannuleerd' (waarbij VBRK-FKSTO = 'X') vast te leggen. Koppel voor 'Betaling ontvangen' de factuur uit VBRK aan het boekhoudkundige document in BKPF en zoek daarna het vereffeningsdocument en de vereffeningsdatum op in BSAD.
- Gebeurtenissen op basis van status ophalen: Gebruik de statustabellen VBUP (artikelstatus) en VBUK (kopstatus) om bedrijfsgebeurtenissen af te leiden. Een artikel geldt bijvoorbeeld als 'Verkooporderartikel gesloten' wanneer VBUP-GBSTA gelijk is aan 'C'. Een order is 'Order geannuleerd' wanneer voor alle relevante artikelen een 'Reden voor afwijzing' (VBAP-ABGRU) is ingesteld.
- Gegevens samenvoegen en opmaken: Voeg alle vastgelegde gebeurtenissen samen in één interne eindtabel. Vul voor elke gebeurtenis alle attributen correct in, zoals SalesOrder, Activity, StartTime en User. Voeg de tijdstempels SourceSystem en LastDataUpdate toe.
- Uitvoerbestand genereren: Gebruik de functiemodule GUI_DOWNLOAD of de methode cl_gui_frontend_services=>gui_download om de interne eindtabel als CSV-bestand naar de lokale computer van de gebruiker te exporteren. Sla het bestand op met UTF-8-codering.
Configuratie
- Vereisten: ABAP-ontwikkelaarsautorisaties, bijvoorbeeld toegang tot transactie SE38, en leesrechten voor alle vereiste SAP-tabellen, waaronder VBAK, VBAP, CDHDR, CDPOS, VBFA, LIKP, LIPS, VBRK, VBRP, MKPF, MSEG en BSAD.
- Selectieparameters: Het programma moet een selectiescherm met filterparameters bevatten. Belangrijke parameters zijn:
- Datumbereik: Een verplicht datumbereik voor het aanmaken van verkooporders (VBAK-ERDAT). Begin met een recente periode van 3 tot 6 maanden om de dataset beheersbaar te houden.
- Verkooporganisatie: Filter op VBAK-VKORG om de analyse op specifieke bedrijfseenheden te richten.
- Verkoopdocumenttype: Filter op VBAK-AUART om alleen relevante ordertypen, zoals standaardorders, op te nemen en andere, zoals offertes en retouren, uit te sluiten.
- Prestaties: Het ophalen van grote hoeveelheden data uit wijzigingslogboektabellen (CDHDR, CDPOS) en de documentstroom (VBFA) kan erg traag zijn. Optimaliseer het programma door indexvelden in WHERE-clausules te gebruiken. Plan zeer grote extracties met transactie SM36 als achtergrondtaak tijdens rustige uren.
- Activering van wijzigingslogboek: Deze methode is afhankelijk van SAP-functionaliteit voor wijzigingsdocumenten. Controleer of wijzigingsregistratie is ingeschakeld voor belangrijke data-elementen, zoals LIFSK, CMGST en ABGRU. Dit kun je controleren via transactie SCDO voor object VERKBELEG.
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 dat je directe, alleen-lezen toegang hebt tot de onderliggende SAP ECC-database. Je hebt een databasetool nodig, zoals DBeaver, SQL Server Management Studio of Oracle SQL Developer, om verbinding te maken en queries uit te voeren.
- SQL-script ophalen: Kopieer de volledige SQL-query uit het gedeelte 'query' van dit document.
- Verbinding maken met de database: Open je databasetool en maak verbinding met de SAP ECC-database-instantie. Je hebt het serveradres, de poort, de databasenaam en de juiste inloggegevens nodig.
- Query instellen: Plak het SQL-script in een nieuw queryvenster. Zoek in de hoofd-Common Table Expression (CTE) met de naam SalesOrders het configuratiegedeelte. Vervang de tijdelijke waarden voor de begindatum ('{StartDate}'), einddatum ('{EndDate}'), verkooporganisaties ('{SalesOrgs}') en documenttypen ('{DocTypes}') door de waarden voor je analyse.
- Query uitvoeren: Voer het ingestelde SQL-script uit. Afhankelijk van het datumbereik en de omvang van je SAP-database kan dit enkele minuten duren.
- Resultaten controleren: Na afloop verschijnt een resultatenset. Controleer kort of de verwachte kolommen erin staan, zoals SalesOrder, Activity en StartTime, en of er rijen voor verschillende activiteiten zijn.
- Data exporteren: Gebruik de exportfunctie van je databasetool om de resultatenset als CSV-bestand op te slaan. Geef het bestand een duidelijke naam, zoals SAP_O2C_Event_Log.csv.
- Bestand klaarmaken voor ProcessMind: Open het CSV-bestand in een spreadsheetprogramma. Controleer of de kolomkoppen exact overeenkomen met de vereiste attributen, zoals SalesOrder, Activity en StartTime. Gebruik voor StartTime en LastDataUpdate een consistente datum- en tijdnotatie die ProcessMind ondersteunt, bijvoorbeeld YYYY-MM-DD HH:MI:SS.
- Uploaden naar ProcessMind: Upload het definitieve CSV-bestand naar je ProcessMind-project voor analyse.
Configuratie
- Datumbereik: De query gebruikt tijdelijke waarden ('{StartDate}' en '{EndDate}') om verkooporders te filteren op aanmaakdatum (VBAK.ERDAT). Een analyseperiode van 3 tot 6 maanden levert meestal een representatieve steekproef op zonder de database zwaar te belasten.
- Filter voor verkooporganisatie: Gebruik de tijdelijke waarde '{SalesOrgs}' om de extractie te beperken tot specifieke verkooporganisaties, bijvoorbeeld '1000' en '2000'. Zo richt je de analyse beter en verbeter je de queryprestaties.
- Filter voor documenttype: Gebruik de tijdelijke waarde '{DocTypes}' om specifieke typen verkooporders te selecteren, bijvoorbeeld 'OR' voor een standaardorder. Zo blijven irrelevante documenten, zoals gratis leveringen of retouren, buiten de hoofdprocesstroom.
- Identificatie van bronsysteem: De vaste tijdelijke waarde '{SourceSystemName}' wordt gebruikt om elke record van de naam van het bronsysteem te voorzien. Vul hier een herkenbare naam voor je SAP ECC-instantie in, bijvoorbeeld SAP_ECC_PRD.
- Databasecompatibiliteit: De functie voor het combineren van datum- en tijdvelden, [Your DB-specific timestamp function], is een tijdelijke aanduiding. Vervang deze door de juiste functie voor je database, bijvoorbeeld 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: Voor deze methode heb je directe, alleen-lezen databasegegevens nodig. De databasegebruiker moet bevoegd zijn om alle tabellen in de query te lezen, waaronder VBAK, VBAP, VBFA, CDHDR, CDPOS, LIKP, VBRK en BSAD.
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 <> ''; Klaar om te beginnen?
Gebruik deze datatemplate om het order-to-cash-proces voor verkooporders te verbeteren. Werk aan een efficiëntere bedrijfsvoering en een snellere cashflow.
Verbeter vandaag nog de verwerking van verkooporders
Haal bottlenecks weg, verkort de doorlooptijd met 30% en verbeter snel de cashflow.
Geen creditcard nodig. Binnen enkele minuten ingesteld.