Jouw datatemplate voor Record to Report - Journal Entry
Jouw datatemplate voor Record to Report - Journal Entry
- Aanbevolen attributen voor een volledige analyse
- Belangrijke journaalpostactiviteiten om te volgen
- Praktische richtlijnen voor data-extractie uit SAP ECC
Record to Report - attributen van journal entries
| Naam | Beschrijving | ||
|---|---|---|---|
| Activiteitsnaam ActivityName | De naam van de bedrijfsactiviteit of het event dat op een bepaald moment in het Journal Entry-proces plaatsvond. | ||
| Beschrijving De Activiteitsnaam beschrijft een specifieke stap in de levenscyclus van een journal entry, zoals 'Journal Entry Created', 'Journal Entry Approved' of 'Journal Entry Posted'. Dit attribuut wordt meestal afgeleid uit meerdere SAP-bronnen, waaronder transactiecodes (TCODE), wijzigingsdocumentlogs (de tabellen CDHDR en CDPOS) en documentstatusvelden. Het analyseren van activiteiten vormt de kern van process mining. Je kunt proceskaarten visualiseren, overgangstijden tussen stappen berekenen en herstelrondes herkennen, bijvoorbeeld 'Journal Entry Rejected' gevolgd door 'Journal Entry Corrected'. Deze data vormt de basis voor dashboards over doorlooptijden, herstelpercentages en procesvarianten. Waarom dit belangrijk is Dit attribuut bepaalt de stappen in de proceskaart. Zo kun je de Journal Entry-workflow visualiseren, analyseren en optimaliseren. Waar je het vindt Afgeleid uit verschillende bronnen, waaronder transactiecodes in BKPF (TCODE), de documentstatus en workflowlogs in tabellen zoals SWW_WI2OBJ, of wijzigingsdocumenten in CDHDR en CDPOS. Voorbeelden Journal Entry aangemaaktJournal Entry goedgekeurdJournal Entry afgewezenJournal Entry geboekt | |||
| Eventtijd EventTime | De timestamp die aangeeft wanneer een specifieke activiteit of event voor de journal entry plaatsvond. | ||
| Beschrijving Eventtijd bevat de exacte datum en tijd van elke activiteit in het Journal Entry-proces. Deze data is nodig om alle tijdsgebonden metingen te berekenen, zoals doorlooptijden, verwerkingsduur en vertragingen tussen stappen. De bron van deze timestamp verschilt per activiteit. Het kan gaan om de aanmaakdatum en -tijd van het document (CPUDT/CPUTM) of om wijzigingstimestamps uit logs (CDHDR-UDATE/UTIME). Bij analyses gebruik je Eventtijd om events chronologisch te ordenen. Zo ontstaat de basis voor de proceskaart. Het attribuut is nodig voor alle tijdgerelateerde KPI's, zoals de gemiddelde doorlooptijd van een Journal Entry, de gemiddelde goedkeuringstijd en de tijd tussen goedkeuring en boeking. Waarom dit belangrijk is Deze timestamp vormt de basis voor alle tijdgerelateerde analyses. Je kunt er doorlooptijden, duur en bottlenecks mee berekenen. Waar je het vindt Afkomstig uit verschillende velden, afhankelijk van de activiteit. Meestal gaat het om de aanmaaktimestamp (CPUDT, CPUTM) uit BKPF of wijzigingstimestamps (UDATE, UTIME) uit CDHDR. Voorbeelden 2023-10-26T09:00:00Z2023-10-26T14:30:15Z2023-10-27T11:05:00Z | |||
| ID journaalpost JournalEntryId | De unieke identificatie van een financieel accountingdocument, opgebouwd uit de company code, het documentnummer en het boekjaar. | ||
| Beschrijving De Journal Entry ID is de primaire case-identificatie voor het volgen van de levenscyclus van een journal entry. Het is een samengestelde sleutel, meestal gevormd door de Company Code (BUKRS), het Document Number (BELNR) en het Fiscal Year (GJAHR) samen te voegen. Zo blijft de ID uniek binnen het hele SAP-systeem. Bij procesanalyse koppelt deze ID alle gerelateerde activiteiten, zoals aanmaken, parkeren, indienen, goedkeuren, afwijzen en boeken. Door deze identificatie te volgen, kun je de end-to-end-reis van elke journal entry reconstrueren, doorlooptijden meten en procesafwijkingen of bottlenecks voor specifieke boekingen vinden. Waarom dit belangrijk is Dit is de belangrijkste sleutel om een journal entry vanaf het aanmaken tot en met de definitieve boeking te volgen. Zo kun je het proces end-to-end analyseren en varianten vergelijken. Waar je het vindt Dit is een afgeleid attribuut, meestal een samenvoeging van velden uit de BKPF-tabel: Company Code (BUKRS), Document Number (BELNR) en Fiscal Year (GJAHR). Voorbeelden 1000-1000000123-20232000-1900000456-20231000-1800000789-2024 | |||
| Bronsysteem SourceSystem | Het systeem waaruit de procesdata is geëxtraheerd. | ||
| Beschrijving Dit attribuut identificeert de herkomst van de data, in dit geval de specifieke SAP ECC-instantie. Meestal is dit een vaste waarde die tijdens de data-extractie wordt toegevoegd. In omgevingen met meerdere ERP-systemen of databronnen is dit attribuut belangrijk. Het maakt de dataherkomst duidelijk en laat je analyses filteren of segmenteren op het systeem van herkomst. Waarom dit belangrijk is Maakt de dataherkomst duidelijk en is belangrijk voor het volgen van datakwaliteit, vooral in omgevingen met meerdere bronsystemen. Waar je het vindt Dit is meestal een vaste waarde die tijdens de datatransformatie wordt toegevoegd en de specifieke SAP ECC-instantie identificeert, bijvoorbeeld 'ECC_PROD_100'. Voorbeelden SAP ECC EHP8ECC_FIN_PRODSAP_ERP_60 | |||
| Laatste data-update LastDataUpdate | De timestamp die aangeeft wanneer de data voor het laatst uit het bronsysteem is geëxtraheerd of vernieuwd. | ||
| Beschrijving Dit attribuut registreert de datum en tijd van de meest recente data-extractie uit SAP ECC. Het is een metadataveld dat belangrijk is om te bepalen hoe actueel de geanalyseerde data is. In elk process mining-dashboard of elke analyse wil je weten wanneer de data voor het laatst is bijgewerkt. Zo kunnen gebruikers de data beter vertrouwen en onderbouwde beslissingen nemen. Het beantwoordt de vraag: 'Hoe actueel is deze informatie?'. Waarom dit belangrijk is Laat zien hoe actueel de data is. Zo begrijpen gebruikers over welke periode de analyse gaat en kunnen ze de resultaten beter beoordelen. Waar je het vindt Dit metadataveld wordt door de data-extractietool of het ETL-proces aangemaakt en opgeslagen wanneer de data wordt vernieuwd. Voorbeelden 2024-05-20T04:00:00Z2024-05-21T04:00:00Z2024-05-22T04:00:00Z | |||
| Bedrijfscode CompanyCode | De organisatie-eenheid die een zelfstandige juridische entiteit vertegenwoordigt waarvoor financiële overzichten worden opgesteld. | ||
| Beschrijving De Company Code is een belangrijke organisatie-eenheid in SAP Financials. Deze vertegenwoordigt een juridisch zelfstandige onderneming en is een belangrijk veld in de koptekst van het Journal Entry-document. Dit attribuut is nodig om procesanalyses per juridische entiteit te segmenteren. Je kunt procesprestaties, compliancepercentages en KPI-resultaten tussen bedrijfsonderdelen vergelijken. Zo zie je bijvoorbeeld of goedkeuringsvertragingen of veel terugdraaiingen specifiek zijn voor bepaalde company codes. Waarom dit belangrijk is Maakt het mogelijk om procesprestaties voor verschillende juridische entiteiten of bedrijfsonderdelen binnen de organisatie te filteren en vergelijken. Waar je het vindt Staat in de documentkopteksttabel BKPF, veld BUKRS. Voorbeelden 10002000US01DE01 | |||
| Boekingsdatum PostingDate | De datum waarop de transactie in het grootboek wordt vastgelegd en daarmee de financiële periode bepaalt. | ||
| Beschrijving De Boekingsdatum bepaalt in welke boekhoudperiode de journal entry wordt verwerkt. Dit is een belangrijk datumveld vanuit financieel en complianceperspectief, omdat de datum moet aansluiten op de planning en regelgeving rond het afsluiten van boekhoudperioden. Bij process mining gebruik je deze datum om compliance te controleren. Het dashboard 'Compliance Adherence Monitoring' en de KPI 'Compliance Conformance Rate' gebruiken dit attribuut om te controleren of boekingen binnen de juiste periode zijn verwerkt. Je kunt er ook trends in het aantal journal entries over tijd mee analyseren. Waarom dit belangrijk is Belangrijk voor financiële rapportage en complianceanalyse. Zo controleer je of boekingen in de juiste boekhoudperiode zijn verwerkt. Waar je het vindt Staat in de documentkopteksttabel BKPF, veld BUDAT. Voorbeelden 2023-10-312023-11-302024-01-15 | |||
| Documenttype DocumentType | Een classificatie voor accountingdocumenten die bepaalt hoe ze worden verwerkt en opgeslagen. | ||
| Beschrijving Het Documenttype onderscheidt verschillende soorten bedrijfstransacties, zoals een grootboekboeking (SA), leveranciersfactuur (KR) of activaboeking (AA). Het wordt ingesteld in de systeemconfiguratie en aan elke journal entry toegewezen. Dit attribuut is belangrijk voor analyses, omdat je het proces kunt segmenteren op basis van het soort transactie. Het dashboard 'Journal Entry Throughput by Type' en de KPI 'Average Cycle Time by Journal Entry Type' zijn rechtstreeks afhankelijk van dit veld. Zo ontdek je of bepaalde boekingstypen vaker leiden tot vertragingen, herstelwerk of terugdraaiingen. Waarom dit belangrijk is Maakt het mogelijk om analyses per transactietype te segmenteren. Zo zie je of procesproblemen specifiek zijn voor bepaalde typen journal entries. Waar je het vindt Staat in de documentkopteksttabel BKPF, veld BLART. Voorbeelden SAKRREAA | |||
| Gebruiker User | De SAP-gebruikers-ID van de persoon die de journal entry heeft aangemaakt of gewijzigd. | ||
| Beschrijving Dit attribuut legt de SAP-gebruikersnaam vast die verantwoordelijk is voor een activiteit, zoals het aanmaken, parkeren of boeken van een document. De bron is rechtstreeks de documentkoptekst of een wijzigingslog. Door het attribuut Gebruiker te analyseren, krijg je zicht op prestaties van teams en individuele gebruikers. Het ondersteunt het User Productivity-dashboard door activiteitenaantallen en verwerkingstijden per gebruiker te volgen. Ook zie je wie betrokken is bij herstelrondes, terugdraaiingen of complianceafwijkingen. Dat helpt bij gerichte training en procesverbetering. Waarom dit belangrijk is Identificeert de gebruiker die verantwoordelijk is voor elke activiteit. Zo kun je gebruikersprestaties, werkverdeling en patronen in herstelwerk analyseren. Waar je het vindt Meestal afkomstig uit de BKPF-tabel, het veld USNAM voor de maker, of uit de CDHDR-tabel, het veld USERNAME voor de persoon die de wijziging uitvoerde. Voorbeelden ABROWNCJONESDSMITH | |||
| Teruggedraaid IsReversed | Een boolean-vlag die aangeeft of de journal entry is teruggedraaid. | ||
| Beschrijving Deze vlag identificeert journal entries die later door een ander accountingdocument zijn teruggedraaid. In SAP is een teruggedraaid document gekoppeld aan het terugdraaiingsdocument, waardoor een duidelijke audit trail ontstaat. Dit attribuut vormt de basis voor het dashboard 'Journal Entry Reversal Analysis' en de KPI 'Journal Entry Reversal Rate'. Je kunt teruggedraaide boekingen isoleren en de oorzaken onderzoeken, zoals invoerfouten of een onjuiste boekhoudkundige verwerking. Zo verlaag je het aantal terugdraaiingen. Waarom dit belangrijk is Ondersteunt analyses van terugdraaiingen rechtstreeks door boekingen te markeren die later ongedaan zijn gemaakt. Zo vind je de oorzaken van fouten en verbeter je de datakwaliteit. Waar je het vindt Afgeleid uit het veld voor het nummer van het terugdraaiingsdocument (STBLG) in de BKPF-tabel. Als STBLG niet leeg is, is de vlag waar. Voorbeelden truefalse | |||
| Transactiecode TransactionCode | De SAP-transactiecode die wordt gebruikt om de journal entry aan te maken of te verwerken. | ||
| Beschrijving De Transactiecode (T-Code) is een unieke identificatie voor een specifieke functie of een specifiek programma in SAP. Voor journal entries laat de code zien hoe de boeking is aangemaakt, bijvoorbeeld handmatig (FB01, F-02), via parking (FV50) of via een geautomatiseerde interface. Dit attribuut is erg waardevol voor het dashboard 'Manual Activity Optimization'. Door de T-Code te analyseren, maak je onderscheid tussen handmatige en geautomatiseerde activiteiten. Je ziet welke handmatige processen de meeste tijd kosten en waar automatisering mogelijk is om handmatig werk te verminderen en de efficiëntie te verbeteren. Waarom dit belangrijk is Helpt onderscheid te maken tussen handmatige en geautomatiseerde processen en laat kansen voor automatisering en processtandaardisatie zien. Waar je het vindt Staat in de documentkopteksttabel BKPF, veld TCODE. Voorbeelden FB01F-02FV50FBD1 | |||
| Goedkeuringstijd ApprovalTime | De verstreken tijd vanaf het moment waarop een journaalpost ter goedkeuring wordt ingediend tot het moment waarop deze wordt goedgekeurd of afgewezen. | ||
| Beschrijving Deze metriek meet de duur van het goedkeuringssubproces, dat vaak een belangrijke bijdrage levert aan de totale doorlooptijd. De waarde wordt berekend als het tijdsverschil tussen de activiteit 'Journal Entry Submitted' en de bijbehorende activiteit 'Journal Entry Approved' of 'Journal Entry Rejected'. Goedkeuringstijd is de kernmetriek voor het dashboard 'Journal Entry Approval Performance' en de KPI 'Average Journal Entry Approval Time'. Door deze duur te analyseren, kun je bottlenecks in de goedkeuringsworkflow opsporen, de prestaties van goedkeurders meten en proceswijzigingen onderbouwen, zoals het aanpassen van goedkeuringsdrempels. Waarom dit belangrijk is Meet de duur van de goedkeuringsfase en helpt vertragingen in de controle- en goedkeuringsworkflow op te sporen en aan te pakken. Waar je het vindt Berekend door de timestamp van de gebeurtenis 'Journal Entry Submitted' af te trekken van de timestamp van de gebeurtenis 'Journal Entry Approved' of 'Journal Entry Rejected'. Voorbeelden P1DT2HPT4H15MP3D | |||
| Is geparkeerd IsParked | Een booleaanse vlag die aangeeft of de journaalpost vóór het boeken als geparkeerd document is opgeslagen. | ||
| Beschrijving Door een document te parkeren kan een gebruiker een onvolledige journaalpost opslaan zonder dat dit invloed heeft op financiële saldi. Een andere gebruiker kan de post daarna aanvullen of controleren voordat deze wordt geboekt. Deze vlag laat zien welke boekingen een parkeeractie hebben doorlopen. Door dit attribuut te analyseren, krijg je inzicht in het gebruik van de parkeerfunctie. Je ziet bijvoorbeeld of parkeren als informele controle wordt gebruikt en daardoor vertraging veroorzaakt. Ook ondersteunt het de analyse van de end-to-end-doorlooptijd, waarbij je onderscheid maakt tussen boekingen die meteen worden geboekt en boekingen die eerst worden geparkeerd. Waarom dit belangrijk is Identificeert boekingen waarbij de parkeerfunctie is gebruikt. Dat kan een bron van vertraging zijn of wijzen op een informeel controleproces. Waar je het vindt Afgeleid van het documentstatusveld (BSTAT) in tabel BKPF. Een 'V' geeft aan dat het document geparkeerd is. Voorbeelden truefalse | |||
| Is herstelwerk IsRework | Een booleaanse vlag die aangeeft of een journaalpost een herstelwerk-lus heeft doorlopen, bijvoorbeeld doordat deze is afgewezen en daarna gecorrigeerd. | ||
| Beschrijving Deze vlag identificeert cases die van het 'happy path' zijn afgeweken en corrigerende actie nodig hadden. De waarde wordt meestal op true gezet wanneer voor een journaalpost een reeks activiteiten zoals 'Journal Entry Rejected' gevolgd door 'Journal Entry Corrected' wordt waargenomen. Dit attribuut is essentieel voor het berekenen van de KPI 'Journal Entry Rework Rate' en voor analyses in het dashboard 'Rework and Rejection Rate'. Het helpt de omvang van inefficiëntie in het proces te meten en vormt een basis voor onderzoek naar de grondoorzaken van herstelwerk, zoals onduidelijke vereisten of onvoldoende documentatie. Waarom dit belangrijk is Markeert boekingen die correctie nodig hadden. Zo kun je herstelwerk kwantificeren en de grondoorzaken analyseren om het first-time-right-percentage te verbeteren. Waar je het vindt Dit is een berekend attribuut dat wordt afgeleid door de activiteitenreeks van een case te analyseren. Er is sprake van een herstelwerk-lus als een afwijzings- of correctieactiviteit voorkomt. Voorbeelden truefalse | |||
| Kostenplaats CostCenter | Een organisatorische eenheid binnen een controllinggebied die een locatie vertegenwoordigt waar kosten worden gemaakt. | ||
| Beschrijving De kostenplaats is een belangrijk stamgegeven uit de module Controlling (CO) en wordt vaak toegewezen op het niveau van de boekingsregel. Je gebruikt deze om kosten voor een specifieke afdeling, functie of locatie bij te houden. Met een kostenplaats kun je het journaalpostproces gedetailleerder analyseren. Zo zie je bijvoorbeeld of bepaalde afdelingen meer herstelwerk veroorzaken, langere doorlooptijden hebben of verantwoordelijk zijn voor meer handmatige boekingen. Daarmee krijg je inzicht in de procesefficiëntie per afdeling. Waarom dit belangrijk is Maakt het mogelijk om de procesprestaties per afdeling of functioneel gebied te analyseren, zodat je lokale inefficiënties kunt opsporen. Waar je het vindt Te vinden in de tabel met documentregels BSEG, veld KOSTL. Voorbeelden 4100CC_FINANCE_US10010101 | |||
| Reden voor terugdraaiing ReversalReason | Een code die aangeeft waarom een journal entry is teruggedraaid. | ||
| Beschrijving Wanneer een document wordt teruggeboekt, kan de gebruiker in SAP een reden opgeven. Deze code geeft gestructureerde informatie over de reden van de terugboeking, bijvoorbeeld een onjuiste boekingsdatum of een invoerfout. Dit attribuut is een belangrijke invoer voor het dashboard 'Journal Entry Reversal Analysis'. Door de meest voorkomende redenen voor terugboekingen te analyseren, kunnen organisaties structurele problemen in hun processen of hiaten in trainingen herkennen. Zo kunnen ze gerichte maatregelen nemen om toekomstige fouten te voorkomen en het terugboekingspercentage te verlagen. Waarom dit belangrijk is Geeft direct inzicht in de redenen voor terugboekingen, zodat je gericht de grondoorzaken kunt analyseren en toekomstige fouten kunt verminderen. Waar je het vindt Te vinden in de documentkopteksttabel BKPF, veld STGRD. Voorbeelden 010205 | |||
| Totaalbedrag document TotalDocumentAmount | De totale waarde van de journal entry in de documentvaluta. | ||
| Beschrijving Dit attribuut staat voor de totale financiële waarde van de journal entry. Meestal wordt het berekend door de absolute waarden van alle debet- en creditregelitems van het document op te tellen. Door het proces op financiële waarde te analyseren, ontdek je belangrijke patronen. Boekingen met een hoge waarde kunnen bijvoorbeeld een andere, strengere goedkeuringsroute volgen. Je kunt dit attribuut gebruiken om analyses te filteren of segmenteren en te zien of doorlooptijden, afwijzingspercentages of goedkeuringsvertragingen samenhangen met het bedrag van de boeking. Waarom dit belangrijk is Maakt analyses van de financiële impact mogelijk, bijvoorbeeld door verwerkingstijden of afwijzingspercentages te vergelijken met de geldwaarde van journal entries. Waar je het vindt Dit is een berekend veld dat wordt afgeleid door het bedragveld (WRBTR of DMBTR) van alle regelitems in de BSEG-tabel voor een bepaalde journal entry op te tellen. Voorbeelden 1500.0025000.75125.50 | |||
| Valutacode CurrencyKey | De valutacode voor de bedragen die in de journal entry zijn vastgelegd. | ||
| Beschrijving Dit attribuut geeft de valuta van de journal entry aan, zoals USD, EUR of JPY. Het biedt context voor alle financiële bedragen in het document. Hoewel dit niet altijd een primaire analysedimensie is, is het belangrijk om geldbedragen correct te interpreteren. In internationale organisaties kun je er ook analyses mee segmenteren om te zien of processen verschillen voor boekingen in vreemde valuta en lokale valuta. Waarom dit belangrijk is Biedt de nodige context voor alle geldbedragen, zodat je financiële analyses en interpretaties correct kunt uitvoeren. Waar je het vindt Staat in de documentkopteksttabel BKPF, veld WAERS. Voorbeelden USDEURGBPJPY | |||
Record to Report - activiteiten voor journal entries
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Journal Entry geboekt | Dit is de centrale activiteit waarbij de journal entry officieel in het grootboek wordt vastgelegd en financiële overzichten beïnvloedt. Dit event wordt expliciet vastgelegd wanneer de documentstatus op 'posted' wordt gezet en een boekingsdatum wordt toegewezen. | ||
| Waarom dit belangrijk is Dit is het belangrijkste meetpunt en betekent dat de journal entry succesvol is verwerkt. De end-to-end-doorlooptijd wordt vaak tot dit moment gemeten. Het is ook een belangrijk event voor analyses van de financiële afsluiting. Waar je het vindt Dit wordt vastgesteld wanneer een document in de BKPF-tabel een boekingsdatum heeft, BKPF-BUDAT. Voor geparkeerde documenten komt dit overeen met het moment waarop BKPF-BSTAT verandert van 'V' naar leeg. De timestamp van de boeking is de invoerdatum BKPF-CPUDT. Vastleggen Identificeer wanneer BKPF-BSTAT verandert van 'V' naar leeg, of bij directe boekingen het aanmaak-event. Eventtype explicit | |||
| Journal Entry geparkeerd | Deze activiteit markeert het aanmaken van een journal entry in een voorlopige status, voordat deze officieel in het grootboek wordt geboekt. In SAP wordt dit expliciet vastgelegd wanneer een gebruiker een document opslaat via een parkingtransactie en de documentstatus op 'parked' zet. | ||
| Waarom dit belangrijk is Dit is een belangrijk startevent voor processen met controle en goedkeuring. Door de tijd tussen parkeren en boeken te analyseren, zie je vertragingen in de voorbereidende en goedkeuringsfasen. Waar je het vindt Dit event wordt geïdentificeerd in de documentkopteksttabel BKPF. Een document geldt als geparkeerd wanneer het wordt aangemaakt met BKPF-BSTAT = 'V'. De timestamp van het event is de aanmaakdatum en -tijd, BKPF-CPUDT en BKPF-CPUTM. Vastleggen Identificeer het aanmaken van een document in BKPF wanneer BKPF-BSTAT 'V' is. Eventtype explicit | |||
| Journal Entry goedgekeurd | Deze activiteit markeert de definitieve goedkeuring van een journal entry binnen een workflow, waarna deze kan worden geboekt. Je haalt dit event uit de workflowlog wanneer de laatste stap 'release' of 'approve' is afgerond. | ||
| Waarom dit belangrijk is Dit is een belangrijk meetpunt dat het goedkeuringsproces afsluit. De duur tot aan deze activiteit is een belangrijke KPI voor de efficiëntie van de goedkeuring. De tijd tussen dit event en de boeking meet de vertraging na goedkeuring. Waar je het vindt Leid dit af uit de voltooiingstimestamp van de laatste goedkeuringsstap in de SAP Business Workflow-log. Dit is de laatste goedkeuringsactie voordat het document wordt geboekt of klaarstaat voor boeking. Vastleggen Identificeer het afronden van de laatste stap 'release' of 'approve' in workflowlogs. Eventtype inferred | |||
| Journal Entry ingediend | Deze activiteit betekent dat de maker een geparkeerde journal entry heeft afgerond en dat deze klaar is voor controle en goedkeuring. Meestal wordt dit vastgelegd wanneer een SAP Business Workflow-taak voor het geparkeerde document wordt gestart. | ||
| Waarom dit belangrijk is Hiermee gaat de verantwoordelijkheid over van de maker naar de goedkeurder en start de klok voor KPI's rond de doorlooptijd van de goedkeuring. Het is een belangrijk meetpunt voor de efficiëntie van de goedkeuringsworkflow. Waar je het vindt Leid dit af uit de starttijd van de goedkeuringsworkflow die aan het financiële documentobject is gekoppeld. Hiervoor analyseer je workflowlogtabellen zoals SWW_WI2OBJ om de workflow te vinden die is gestart voor de specifieke company code, het documentnummer en het boekjaar. Vastleggen Identificeer het start-event van de workflow voor het geparkeerde documentobject. Eventtype inferred | |||
| Journal Entry teruggedraaid | Deze activiteit markeert het terugdraaien van een eerder geboekte journal entry. Een terugdraaiing is een nieuw accountingdocument dat de oorspronkelijke boeking neutraliseert. | ||
| Waarom dit belangrijk is Dit is een belangrijk event voor het meten van datakwaliteit en procesnauwkeurigheid. Veel terugdraaiingen wijzen op structurele problemen bij de oorspronkelijke invoer of goedkeuring. Elke terugdraaiing betekent extra herstelwerk. Waar je het vindt Dit event wordt geïdentificeerd in de koptekst van het oorspronkelijke document, de BKPF-tabel. Wanneer een document wordt teruggedraaid, vult SAP het nummer van het terugdraaiingsdocument (BKPF-STBLG) en de reden voor terugdraaiing (BKPF-STGRD) in. De timestamp van het event is de boekingsdatum van het nieuwe terugdraaiingsdocument. Vastleggen Identificeer wanneer BKPF-STBLG op het oorspronkelijke document is ingevuld. De timestamp is de boekingsdatum van het terugdraaiingsdocument. Eventtype explicit | |||
| Documentatie toegevoegd | Deze activiteit staat voor het toevoegen van ondersteunende documenten, zoals facturen of spreadsheets, aan de journal entry. Dit event wordt niet expliciet als standaard accounting-event gelogd. Meestal leid je het af uit het aanmaken van bijlagen die aan het accountingdocumentobject zijn gekoppeld. | ||
| Waarom dit belangrijk is Door deze activiteit te volgen, controleer je of beleid rond verplichte documentatie wordt nageleefd. Vertraging bij het toevoegen van documenten kan een oorzaak zijn van langere goedkeuringscycli. Waar je het vindt Dit is lastig betrouwbaar vast te leggen als event met timestamp. Je kunt het mogelijk afleiden door de GOS-bijlagentabellen, zoals SOOD, te analyseren en de timestamp van het aanmaken van de bijlage te koppelen aan de objectsleutel van de journal entry. Vastleggen Leid dit af uit de aanmaaktimestamp van gekoppelde objecten in GOS-tabellen, zoals SOOD. Eventtype inferred | |||
| Geparkeerde Journal Entry verwijderd | Dit staat voor het verwijderen van een geparkeerde journal entry die nooit is geboekt. Dit kan gebeuren na een afwijzing of wanneer de boeking per ongeluk is aangemaakt. | ||
| Waarom dit belangrijk is Deze activiteit markeert een onsuccesvol einde van het proces. Door te analyseren waarom geparkeerde documenten worden verwijderd, ontdek je problemen zoals dubbele boekingen of onduidelijkheid over het proces. Waar je het vindt Dit event wordt vastgelegd wanneer de status van een geparkeerd document in de BKPF-tabel verandert. Het statusveld BKPF-BSTAT wordt bijgewerkt naar 'Z' (geparkeerd document verwijderd). De timestamp van de wijziging staat in de documentwijzigingslogs (CDHDR). Vastleggen Identificeer wanneer BKPF-BSTAT wordt bijgewerkt naar 'Z'. Eventtype explicit | |||
| Handmatige invoer geïdentificeerd | Deze activiteit bepaalt of een journal entry via een handmatige online transactie is aangemaakt of via een geautomatiseerde interface of batchproces. Het is geen gebruikersactie, maar een berekend attribuut van de boeking op basis van systeemdata. | ||
| Waarom dit belangrijk is Het onderscheid tussen handmatige en geautomatiseerde boekingen is belangrijk voor gerichte procesverbetering. Handmatige processen zijn vaak het uitgangspunt voor standaardisatie en automatisering. Waar je het vindt Dit wordt berekend door velden in de documentkopteksttabel BKPF te analyseren. Transactiecodes (BKPF-TCODE) zoals 'FB01', 'FB50' of 'FV50' wijzen op handmatige invoer. Andere T-codes of specifieke namen voor batchinvoer (BKPF-AWKEY) wijzen op automatisering. Vastleggen Leid dit af uit BKPF-TCODE of andere indicatoren van het bronsysteem in de documentkoptekst. Eventtype calculated | |||
| Intercompany-boeking geïdentificeerd | Een berekende activiteit die markeert dat een journal entry betrekking heeft op meer dan één company code. Dit bepaal je door de regelitems van één financieel document te analyseren. | ||
| Waarom dit belangrijk is Intercompany-transacties kunnen complexere verwerkings- en goedkeuringseisen hebben. Door ze te identificeren, kun je hun doorlooptijden en procespaden apart analyseren en specifieke bottlenecks vinden. Waar je het vindt Dit wordt berekend door de regelitemtabel BSEG te controleren voor een bepaald documentnummer (BELNR). Als de regelitems meer dan één unieke company code (BSEG-BUKRS) bevatten, is sprake van een intercompany-boeking. Vastleggen Controleer of voor één BKPF-BELNR meerdere unieke waarden van BSEG-BUKRS voorkomen. Eventtype calculated | |||
| Journal Entry aangemaakt | Dit staat voor het aanmaken van een journal entry die rechtstreeks wordt geboekt, zonder voorafgaande parkingstap. Dit wordt vastgelegd wanneer een document in SAP wordt aangemaakt via een directe boekingstransactie. | ||
| Waarom dit belangrijk is Deze activiteit is een alternatief startpunt voor eenvoudigere journal entry-processen zonder goedkeuringsworkflow. Zo maak je onderscheid tussen eenvoudige directe boekingen en complexere geparkeerde boekingen. Waar je het vindt Dit event komt overeen met het aanmaken van een document in de BKPF-tabel wanneer de documentstatus BKPF-BSTAT leeg is, dus geboekt. De timestamp van het event is de aanmaakdatum, BKPF-CPUDT. Voor deze documenten vinden de events 'Created' en 'Posted' gelijktijdig plaats. Vastleggen Identificeer het aanmaken van een document in BKPF wanneer BKPF-BSTAT leeg is. Eventtype explicit | |||
| Journal Entry afgewezen | Deze activiteit betekent dat een journal entry definitief is afgewezen en niet wordt geboekt. Dit is meestal een eindstatus in een goedkeuringsworkflow, waarna het geparkeerde document uiteindelijk wordt verwijderd. | ||
| Waarom dit belangrijk is Het volgen van afwijzingen is belangrijk voor kwaliteitsbeheer. Door de redenen en frequentie van afwijzingen te analyseren, verbeter je het percentage journal entries dat in één keer goed is. Waar je het vindt Dit resultaat komt uit de SAP Business Workflow-log en staat voor een definitieve gebruikersbeslissing 'reject' die het proces beëindigt. Het geparkeerde document kan daarna worden verwijderd. Vastleggen Identificeer de eindstatus 'reject' in de workflowlog voor het document. Eventtype inferred | |||
| Journal Entry gecorrigeerd | Deze activiteit geeft aan dat de oorspronkelijke maker een geparkeerde journal entry heeft aangepast nadat deze voor wijzigingen was teruggestuurd. Je leidt dit af door wijzigingen aan het document te detecteren na een event 'Changes Requested'. | ||
| Waarom dit belangrijk is Door correcties te volgen, zie je hoeveel werk in herstelrondes gaat zitten. De tijd tussen het wijzigingsverzoek en de correctie laat zien hoe lang het duurt om problemen met ingediende boekingen op te lossen. Waar je het vindt Leid dit af door wijzigingsdocumentlogs, de tabellen CDHDR en CDPOS, voor het geparkeerde document te analyseren. Een wijziging na een afwijzing in de workflow betekent dat er een correctie is uitgevoerd. De timestamp komt uit de CDHDR-tabel. Vastleggen Identificeer een wijziging in CDHDR/CDPOS na een afwijzing. Eventtype inferred | |||
| Regelitem van Journal Entry vereffend | Deze activiteit staat voor het vereffenen van een regelitem op een G/L-rekening met open posten, zoals een bankverrekeningsrekening. Dit gebeurt wanneer een regelitem aan een ander wordt gekoppeld en daarmee wordt afgesloten. | ||
| Waarom dit belangrijk is Bij processen zoals bankreconciliatie is de tijd tot vereffening een belangrijke KPI. Deze activiteit helpt de efficiëntie van reconciliatie en maandafsluitingen te analyseren. Waar je het vindt Dit event wordt vastgelegd in de regelitemtabel BSEG. Wanneer een regelitem is vereffend, zijn de velden voor de vereffeningsdatum (BSEG-AUGDT) en het vereffeningsdocument (BSEG-AUGBL) gevuld. De timestamp van het event is de vereffeningsdatum. Vastleggen Identificeer wanneer de vereffeningsdatum (BSEG-AUGDT) voor een regelitem is ingevuld. Eventtype explicit | |||
| Wijzigingen aan Journal Entry gevraagd | Dit is het moment in de workflow waarop een goedkeurder de journal entry heeft gecontroleerd en deze voor correctie terugstuurt naar de maker. Je haalt dit event uit workflowlogs met een gebruikersbeslissing als 'rejection' of 'send back'. | ||
| Waarom dit belangrijk is Deze activiteit is belangrijk om herstelrondes te herkennen. Die zijn een belangrijke bron van inefficiëntie en procesafwijkingen. Een hoge frequentie wijst op problemen met de kwaliteit van de boeking of onduidelijke eisen. Waar je het vindt Dit event wordt afgeleid uit de timestamp van een specifieke gebruikersbeslissing in de SAP Business Workflow-log die overeenkomt met een actie als 'reject' of 'send for correction'. Vastleggen Identificeer de timestamp van de beslissing 'rejection' of 'rework' in workflowlogs. Eventtype inferred | |||
Extractiegidsen
Stappen
- Maak het ABAP-programma: Ga in het SAP-systeem naar transactiecode SE38 (ABAP Editor). Geef het nieuwe programma een naam, bijvoorbeeld Z_PM_JE_EXTRACTION, en klik op Create. Geef het programma een passende titel en stel het programmatype in op 'Executable Program'.
- Definieer het selectiescherm: Definieer in de broncode het selectiescherm. Hiermee kunnen gebruikers parameters opgeven, zoals een datumbereik voor het aanmaken van documenten, bedrijfsnummers en documenttypen, om het datavolume voor de extractie te beperken.
- Declareer datastructuren: Definieer een interne tabelstructuur voor de uiteindelijke event log-data. Deze structuur moet alle vereiste velden bevatten: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate en aanbevolen attributen zoals User, CompanyCode en PostingDate.
- Implementeer de logica voor dataselectie: Schrijf de belangrijkste ABAP SQL-query's om data voor elk van de 14 vereiste activiteiten te extraheren. Selecteer hiervoor data uit primaire tabellen zoals BKPF (Header) en BSEG (Line Item), wijzigingslogtabellen CDHDR en CDPOS, workflowtabellen zoals SWWLOGHIST en clearingtabellen zoals BSAS en BSAK.
- Extraheer geparkeerde en geboekte documenten: Selecteer voor gebeurtenissen 'Journal Entry Parked' gegevens uit BKPF waarbij de documentstatus (BSTAT) 'V' is. Selecteer voor gebeurtenissen 'Journal Entry Created' en 'Journal Entry Posted' gegevens uit BKPF waarbij de status leeg is, wat op een normaal, geboekt document wijst.
- Extraheer wijzigings- en verwijderingsgebeurtenissen: Raadpleeg de wijzigingsdocumenttabellen CDHDR en CDPOS voor objectklasse 'BELEG'. Filter op de documentsleutel om wijzigingen te vinden die overeenkomen met de activiteiten 'Journal Entry Corrected' of 'Parked Journal Entry Deleted'.
- Extraheer workflowgebeurtenissen: Raadpleeg de workflowtabellen om activiteiten zoals 'Journal Entry Submitted', 'Approved', 'Rejected' en 'Changes Requested' vast te leggen. Gebruik tabel SWW_WI2OBJ om het boekingsdocument aan een workflow-instantie te koppelen en lees daarna SWWLOGHIST voor specifieke gebruikersbeslissingen of statuswijzigingen.
- Identificeer berekende gebeurtenissen: Controleer voor 'Manual Entry Identified' de transact code (BKPF-TCODE) aan de hand van een lijst met bekende transact codes voor handmatige boekingen. Analyseer voor 'Cross-Company Posting Identified' de BSEG-regels van een document om te bepalen of meerdere bedrijfsnummers betrokken zijn.
- Consolideer en transformeer de data: Transformeer de data van elke activiteit tijdens de selectie naar de uiteindelijke event log-structuur. Voeg Company Code, Document Number en Fiscal Year samen om JournalEntryId te maken. Zet SAP-datums en -tijden om in één EventTime-timestamp. Voeg de resultaten van elke query toe aan de uiteindelijke interne tabel.
- Implementeer bestandsexport: Gebruik ABAP-instructies voor bestandsverwerking, zoals OPEN DATASET, LOOP AT, TRANSFER en CLOSE DATASET, om de geconsolideerde interne tabel naar een CSV- of plat bestand te schrijven in de map van de SAP-applicatieserver, die je via transactie AL11 kunt bekijken.
- Plan als achtergrondtaak: Ga naar transactie SM36 (Define Background Job). Maak een nieuwe taak, definieer een stap die je ABAP-programma uitvoert en stel een planning in, bijvoorbeeld elke nacht of week buiten piekuren, om de extractie te automatiseren.
- Haal het bestand op en formatteer het: Gebruik transactie CG3Y of werk samen met je systeembeheerder om het gegenereerde bestand van de applicatieserver naar je lokale computer te downloaden. Controleer of de codering en indeling van het bestand geschikt zijn voor upload naar je process mining-tool.
Configuratie
- Datumbereik: Het is belangrijk om een datumbereik te definiëren om de prestaties te bewaken. Gebruik de aanmaakdatum van het document (BKPF-CPUDT) als primaire filter. Voor een eerste analyse raden we een periode van 3 tot 6 maanden aan. Gebruik voor tests een bereik van enkele dagen waarvan je weet dat er data beschikbaar is.
- Filter voor bedrijfsnummer: Filter altijd op bedrijfsnummer (BKPF-BUKRS). Data voor alle bedrijfsnummers tegelijk extraheren kan zeer veel systeembronnen gebruiken. Begin met één of een kleine groep relevante bedrijfsnummers.
- Filter voor documenttype: Gebruik het documenttypefilter (BKPF-BLART) om de scope te beperken tot specifieke typen journaalposten, zoals 'SA' voor G/L-documenten, als je niet alle documenttypen hoeft te analyseren.
- Workflowtaak-ID's: De logica voor het extraheren van workflowgebeurtenissen hangt af van de specifieke taak-ID's die in jouw systeem worden gebruikt voor goedkeuring, afwijzing en indiening. Deze ID's moet je in de broncode van het programma configureren op basis van de workflowdefinities van je organisatie.
- Aandacht voor prestaties: Het programma koppelt meerdere grote tabellen, vooral CDPOS en de workflowhistorietabellen. Uitvoering tijdens piekuren kan de systeemprestaties beïnvloeden. Plan de extractie daarom altijd als achtergrondtaak buiten piekuren. Overweeg secundaire database-indexen aan te maken als prestaties regelmatig een probleem zijn.
- Vereisten: Voor deze methode heb je een gebruiker nodig met ABAP-ontwikkelautorisaties (voor SE38) en rechten om achtergrondtaken aan te maken en te beheren (voor SM36). De gebruiker of taak heeft ook leestoegang nodig tot alle relevante financiële, workflow- en systeemtabellen (BKPF, BSEG, CDHDR, CDPOS, SWWLOGHIST enzovoort).
a Voorbeeldquery abap
REPORT Z_PM_JE_EXTRACTION.
*&---------------------------------------------------------------------*
*& Data Structures for Final Event Log
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE string,
lastdataupdate TYPE timestamp,
username TYPE uname,
companycode TYPE bukrs,
documenttype TYPE blart,
postingdate TYPE budat,
transactioncode TYPE tcode,
isreversed TYPE abap_bool,
END OF ty_event_log.
DATA: lt_final_log TYPE STANDARD TABLE OF ty_event_log.
DATA: ls_event TYPE ty_event_log.
*&---------------------------------------------------------------------*
*& Selection Screen Parameters
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_blart FOR bkpf-blart,
s_cpudt FOR bkpf-cpudt OBLIGATORY.
PARAMETERS: p_sysid TYPE sy-sysid DEFAULT sy-sysid.
*&---------------------------------------------------------------------*
*& Main Logic
*&---------------------------------------------------------------------*
START-OF-SELECTION.
DATA(lv_last_update) = cl_abap_context_info=>get_system_timestamp( ).
" 1. Journal Entry Parked
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
'Journal Entry Parked' AS activityname,
a~cpudt, a~cputm,
a~usnam AS username,
a~bukrs AS companycode,
a~blart AS documenttype,
a~bldat AS postingdate,
a~tcode AS transactioncode
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~bstat = 'V' " Parked Document
INTO TABLE @DATA(lt_parked).
IF sy-subrc = 0.
LOOP AT lt_parked ASSIGNING FIELD-SYMBOL(<fs_parked>).
ls_event-journalentryid = <fs_parked>-journalentryid.
ls_event-activityname = <fs_parked>-activityname.
CONVERT DATE <fs_parked>-cpudt TIME <fs_parked>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_parked>-username.
ls_event-companycode = <fs_parked>-companycode.
ls_event-documenttype = <fs_parked>-documenttype.
ls_event-postingdate = <fs_parked>-postingdate.
ls_event-transactioncode = <fs_parked>-transactioncode.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 2. Journal Entry Created (directly posted, not parked first)
" 9. Journal Entry Posted
" These two events happen at the same time for a direct posting.
SELECT CONCAT( bukrs, belnr, gjahr ) AS journalentryid,
cpudt, cputm, usnam, bukrs, blart, budat, tcode, stblg
FROM bkpf
WHERE bukrs IN s_bukrs
AND blart IN s_blart
AND cpudt IN s_cpudt
AND bstat = '' " Normal, posted document
INTO TABLE @DATA(lt_posted).
IF sy-subrc = 0.
LOOP AT lt_posted ASSIGNING FIELD-SYMBOL(<fs_posted>).
" Activity: Journal Entry Created
ls_event-journalentryid = <fs_posted>-journalentryid.
ls_event-activityname = 'Journal Entry Created'.
CONVERT DATE <fs_posted>-cpudt TIME <fs_posted>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_posted>-usnam.
ls_event-companycode = <fs_posted>-bukrs.
ls_event-documenttype = <fs_posted>-blart.
ls_event-postingdate = <fs_posted>-budat.
ls_event-transactioncode = <fs_posted>-tcode.
ls_event-isreversed = COND #( WHEN <fs_posted>-stblg IS NOT INITIAL THEN abap_true ELSE abap_false ).
APPEND ls_event TO lt_final_log.
" Activity: Journal Entry Posted
ls_event-activityname = 'Journal Entry Posted'.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 3. Documentation Attached (via GOS)
SELECT a~instid_a, c~cr_timestamp
FROM srgbtbrel AS a
INNER JOIN sood AS b ON a~instid_b = b~objid
INNER JOIN socf AS c ON b~filid = c~filid
WHERE a~typeid_a = 'BKPF'
AND a~bukrs IN s_bukrs
INTO TABLE @DATA(lt_attachments).
IF sy-subrc = 0.
LOOP AT lt_attachments ASSIGNING FIELD-SYMBOL(<fs_attach>).
ls_event-journalentryid = |{ <fs_attach>-instid_a(4) }{ <fs_attach>-instid_a+4(10) }{ <fs_attach>-instid_a+14(4) }|.
ls_event-activityname = 'Documentation Attached'.
ls_event-eventtime = <fs_attach>-cr_timestamp.
" Other attributes may need to be looked up from BKPF if needed.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 4, 5, 6, 7, 8: Workflow events (Submitted, Changes Requested, Corrected, Approved, Rejected)
" This is a simplified example. Real logic depends on specific workflow templates.
SELECT a~instid, b~wi_cd, b~wi_ct, b~wi_aagent, b~wi_text
FROM sww_wi2obj AS a
INNER JOIN swwloghist AS b ON a~wi_id = b~wi_id
WHERE a~typeid = 'BKPF'
AND a~catid = 'BO'
AND a~bukrs IN s_bukrs
AND b~wi_cd BETWEEN s_cpudt-low AND s_cpudt-high
INTO TABLE @DATA(lt_workflow).
IF sy-subrc = 0.
LOOP AT lt_workflow ASSIGNING FIELD-SYMBOL(<fs_wf>).
ls_event-journalentryid = |{ <fs_wf>-instid(4) }{ <fs_wf>-instid+4(10) }{ <fs_wf>-instid+14(4) }|.
ls_event-activityname = CASE <fs_wf>-wi_text. " Simplified logic based on work item text
WHEN '[Placeholder for Submit Text]' THEN 'Journal Entry Submitted'
WHEN '[Placeholder for Approve Text]' THEN 'Journal Entry Approved'
WHEN '[Placeholder for Reject Text]' THEN 'Journal Entry Rejected'
WHEN '[Placeholder for Rework Text]' THEN 'Journal Entry Changes Requested'
ELSE ''
ENDCASE.
IF ls_event-activityname IS NOT INITIAL.
CONVERT DATE <fs_wf>-wi_cd TIME <fs_wf>-wi_ct INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_wf>-wi_aagent.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
ENDIF.
" 10. Manual Entry Identified & 11. Cross-Company Posting Identified
SELECT bukrs, belnr, gjahr, tcode FROM bkpf
WHERE bukrs IN s_bukrs AND blart IN s_blart AND cpudt IN s_cpudt
INTO TABLE @DATA(lt_calc_base).
LOOP AT lt_calc_base ASSIGNING FIELD-SYMBOL(<fs_calc>).
ls_event-journalentryid = |{ <fs_calc>-bukrs }{ <fs_calc>-belnr }{ <fs_calc>-gjahr }|.
" Check for manual entry T-Codes
IF <fs_calc>-tcode = 'FB01' OR <fs_calc>-tcode = 'F-02' OR <fs_calc>-tcode = 'FB50'.
ls_event-activityname = 'Manual Entry Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
" Check for cross-company posting
SELECT SINGLE bukrs FROM bseg WHERE belnr = <fs_calc>-belnr AND gjahr = <fs_calc>-gjahr AND bukrs <> <fs_calc>-bukrs INTO @DATA(lv_cross_bukrs).
IF sy-subrc = 0.
ls_event-activityname = 'Cross-Company Posting Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 12. Journal Entry Line Item Cleared
SELECT a~bukrs, a~belnr, a~gjahr, a~augdt, a~augbl
FROM bsas AS a " G/L Cleared Items
WHERE a~bukrs IN s_bukrs
AND a~budat IN s_cpudt
INTO TABLE @DATA(lt_cleared_gl).
IF sy-subrc = 0.
LOOP AT lt_cleared_gl ASSIGNING FIELD-SYMBOL(<fs_clr>).
ls_event-journalentryid = |{ <fs_clr>-bukrs }{ <fs_clr>-belnr }{ <fs_clr>-gjahr }|.
ls_event-activityname = 'Journal Entry Line Item Cleared'.
CONVERT DATE <fs_clr>-augdt INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
" User is often not directly available for clearing events
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 13. Parked Journal Entry Deleted & 6. Journal Entry Corrected
SELECT objectid, changenr, username, udate, utime FROM cdhdr
WHERE objectclas = 'BELEG'
AND udate IN s_cpudt
INTO TABLE @DATA(lt_cdhdr).
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
SELECT SINGLE tcode FROM cdpos WHERE changenr = <fs_cdhdr>-changenr AND fname = 'BSTAT' AND value_new = 'Z' INTO @DATA(lv_deleted_tcode).
ls_event-journalentryid = |{ <fs_cdhdr>-objectid(4) }{ <fs_cdhdr>-objectid+4(10) }{ <fs_cdhdr>-objectid+14(4) }|.
CONVERT DATE <fs_cdhdr>-udate TIME <fs_cdhdr>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_cdhdr>-username.
IF sy-subrc = 0.
ls_event-activityname = 'Parked Journal Entry Deleted'.
APPEND ls_event TO lt_final_log.
ELSE.
ls_event-activityname = 'Journal Entry Corrected'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 14. Journal Entry Reversal Processed
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
a~cpudt, a~cputm, a~usnam
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~stblg IS NOT NULL " Document is a reversal
INTO TABLE @DATA(lt_reversals).
IF sy-subrc = 0.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
ls_event-journalentryid = <fs_rev>-journalentryid.
ls_event-activityname = 'Journal Entry Reversal Processed'.
CONVERT DATE <fs_rev>-cpudt TIME <fs_rev>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_rev>-usnam.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" Final step: Output to file
DATA(lv_filename) = |/tmp/je_extraction_{ sy-datum }_{ sy-uzeit }.csv|.
OPEN DATASET lv_filename FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc = 0.
" Write header
DATA(lv_header) = 'JournalEntryId,ActivityName,EventTime,SourceSystem,LastDataUpdate,User,CompanyCode,DocumentType,PostingDate,TransactionCode,IsReversed'.
TRANSFER lv_header TO lv_filename.
LOOP AT lt_final_log INTO ls_event.
DATA(lv_line) = |"{ ls_event-journalentryid }","|
|{ ls_event-activityname }","|
|{ ls_event-eventtime }","|
|{ ls_event-sourcesystem }","|
|{ ls_event-lastdataupdate }","|
|{ ls_event-username }","|
|{ ls_event-companycode }","|
|{ ls_event-documenttype }","|
|{ ls_event-postingdate }","|
|{ ls_event-transactioncode }","|
|{ ls_event-isreversed }"|.
TRANSFER lv_line TO lv_filename.
ENDLOOP.
CLOSE DATASET lv_filename.
ENDIF. Stappen
- Maak verbinding met de database: Vraag alleen-lezengegevens aan voor de SAP ECC-database. Gebruik een standaard-SQL-client, zoals DBeaver, SAP HANA Studio of SQL Server Management Studio, om verbinding te maken met de database.
- Bereid de SQL-query voor: Kopieer de volledige SQL-query uit de sectie 'query' van dit document naar je SQL-client.
- Stel extractieparameters in: Configureer vóór uitvoering de placeholders in de query. Vervang '[START_DATE]' en '[END_DATE]' door het gewenste datumbereik in de notatie 'YYYYMMDD'. Vervang '[COMPANY_CODE_1]' en '[COMPANY_CODE_2]' door de specifieke SAP-bedrijfsnummers die je wilt analyseren.
- Definieer het bronsysteem: Vervang in de hoofd-
SELECT-instructie de placeholder '[Your SAP System ID]' door de echte SAP System ID (SID), zodat de databron correct wordt geïdentificeerd. - Voer de query uit: Voer de geconfigureerde SQL-query uit op de SAP-database. De uitvoeringstijd hangt af van het datumbereik en de omvang van je databasetabellen.
- Controleer de eerste resultaten: Bekijk na afloop kort de geretourneerde rijen om te controleren of de data goed wordt gevuld. Controleer of er verschillende activiteiten zijn en of belangrijke velden zoals
JournalEntryIdenEventTimeniet leeg zijn. - Verwerk timestamps: De query voegt datum- en tijdvelden samen tot een tekenreeks in de notatie
YYYYMMDDHHMMSS. Controleer of je nabewerking of doelsysteem deze notatie kan verwerken. Pas anders de SQL-functieCONCATaan naar een ISO 8601-notatie zoalsYYYY-MM-DDTHH:MI:SS, als je database dit ondersteunt. - Exporteer de data: Exporteer de volledige resultatenset vanuit je SQL-client naar een CSV-bestand. Gebruik UTF-8-codering om problemen met speciale tekens te voorkomen.
- Bereid de upload voor: Controleer vóór upload naar een process mining-tool of de kolomkoppen overeenkomen met het vereiste dataschema.
JournalEntryId,ActivityNameenEventTimezijn essentieel. Voeg de kolomLastDataUpdatetoe en vul deze met de timestamp van het moment waarop de extractie is uitgevoerd. - Voer de eindcontrole uit: Voer de stappen uit de sectie 'validationSteps' uit om te controleren of de geëxtraheerde data volledig en correct is voordat je met de analyse begint.
Configuratie
- Databasemachtigingen: De databasegebruiker heeft leestoegang nodig tot de volgende SAP-tabellen: BKPF, BSEG, CDHDR, CDPOS, T001 en V_USERNAME. Voor workflowgerelateerde activiteiten is ook toegang tot SWW_WI2OBJ en SWWLOGHIST nodig. Deze toegang wordt meestal alleen aan gespecialiseerde technische teams verleend.
- Filteren op datumbereik: Het is belangrijk om de data op een specifiek datumbereik te filteren voor goede queryprestaties. De query gebruikt placeholders voor een begin- en einddatum, die worden toegepast op de aanmaakdatum van het document (
BKPF.CPUDT). Voor een eerste analyse raden we een periode van 3 tot 6 maanden aan. - Filteren op entiteit: Filter altijd op bedrijfsnummer (
BKPF.BUKRS) om het datavolume beheersbaar te houden en de analyse af te bakenen. Je kunt ook filteren op documenttype (BKPF.BLART) om alleen relevante typen journaalposten op te nemen, bijvoorbeeld 'SA' voor G/L-documenten. Zo sluit je operationele documenten zoals facturen of betalingen uit als die buiten de scope vallen. - Aandacht voor prestaties: Rechtstreekse queries op kerntabellen zoals BSEG en CDPOS kunnen veel systeembronnen gebruiken. Voer deze extractie bij voorkeur buiten piekuren uit om de systeemprestaties voor eindgebruikers niet te beïnvloeden. Extraheer niet meer dan één jaar aan data in één uitvoering.
- Workflowtaak-ID's: De query bevat placeholders zoals '[WF_TASK_ID_SUBMIT]' en '[WF_TASK_ID_APPROVE]'. Vervang deze door de echte taak-ID's uit de specifieke workflowconfiguratie voor journaalposten in jouw systeem. Je kunt deze achterhalen met hulp van een SAP Workflow-specialist of door de technische workflowdefinitie in transactie PFTC te analyseren.
a Voorbeeldquery sql
WITH DOC_HEADERS AS (
SELECT
BUKRS,
BELNR,
GJAHR,
BLART,
BLDAT,
BUDAT,
CPUDT,
CPUTM,
USNAM,
TCODE,
BSTAT,
STBLG,
XRECH
FROM BKPF
WHERE CPUDT BETWEEN '[START_DATE]' AND '[END_DATE]'
AND BUKRS IN ('[COMPANY_CODE_1]', '[COMPANY_CODE_2]')
)
-- Event 1: Journal Entry Created (Directly Posted)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = '' OR H.BSTAT = 'U'
UNION ALL
-- Event 2: Journal Entry Parked
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = 'V'
UNION ALL
-- Event 3: Journal Entry Posted (from Parked state)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT <> 'V'
AND P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW <> 'V'
UNION ALL
-- Event 4: Parked Journal Entry Deleted
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Parked Journal Entry Deleted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND C.TCODE = 'FBV0'
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW = 'Z'
UNION ALL
-- Event 5: Journal Entry Reversal Processed
SELECT
CONCAT(H.BUKRS, H.STBLG, H.GJAHR) AS "JournalEntryId", -- Linking to the original document
'Journal Entry Reversal Processed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
TRUE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.STBLG IS NOT NULL AND H.STBLG <> ''
UNION ALL
-- Event 6: Journal Entry Line Item Cleared
SELECT
CONCAT(B.BUKRS, B.BELNR, B.GJAHR) AS "JournalEntryId",
'Journal Entry Line Item Cleared' AS "ActivityName",
TO_TIMESTAMP(B.AUGDT, 'YYYYMMDD') AS "EventTime", -- Clearing date used as event time
U.NAME_TEXT AS "User",
B.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode", -- Clearing transaction is in the clearing document header, complex to retrieve here
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM BSEG B
JOIN DOC_HEADERS H ON B.BUKRS = H.BUKRS AND B.BELNR = H.BELNR AND B.GJAHR = H.GJAHR
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE B.AUGBL IS NOT NULL AND B.AUGBL <> '' AND B.AUGDT <> '00000000'
UNION ALL
-- Event 7: Journal Entry Corrected (changes to a parked document)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT = 'V' AND C.TCODE IN ('FBV2', 'FBV4') -- FBV2 is change parked doc, FBV4 is change parked doc header
UNION ALL
-- Event 8: Documentation Attached (inferred from GOS attachment creation, requires configuration)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(CONCAT(REL.RECDATE, '000000'), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SRGBTBREL REL ON REL.INSTID_A = CONCAT('BUS2081', H.BUKRS, H.BELNR, H.GJAHR) -- BUS2081 is object type for BKPF
LEFT JOIN V_USERNAME U ON REL.RECUNAM = U.BNAME
WHERE REL.TYPEID_A = 'BUS2081' AND REL.RELTYPE = 'ATTA'
UNION ALL
-- Events 9-13 from Workflow (Submitted, Changes Requested, Approved, Rejected) requires specific workflow config
-- This is a generic template. The WI_RH_TASK must be adapted to your system.
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
CASE
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_SUBMIT]' THEN 'Journal Entry Submitted'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_APPROVE]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Approved'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_REJECT]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Rejected'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_CHANGES_REQ]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Changes Requested'
ELSE NULL
END AS "ActivityName",
TO_TIMESTAMP(CONCAT(LOG.EVT_DATE, LOG.EVT_TIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SWW_WI2OBJ WIOBJ ON WIOBJ.INSTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND WIOBJ.TYPEID = 'BKPF'
JOIN SWWLOGHIST LOG ON WIOBJ.WI_ID = LOG.WI_ID
LEFT JOIN V_USERNAME U ON LOG.EXEC_USER = U.BNAME
WHERE LOG.WI_RH_TASK IN ('[WF_TASK_ID_SUBMIT]', '[WF_TASK_ID_APPROVE]', '[WF_TASK_ID_REJECT]', '[WF_TASK_ID_CHANGES_REQ]')
UNION ALL
-- Event 14: Manual Entry Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Manual Entry Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.TCODE IN ('FB01', 'F-02', 'FB50', 'F-04', 'F-22', 'F-43', 'FB60', 'FB70', 'FV50', 'FV60', 'FV70')
UNION ALL
-- Event 15: Cross-Company Posting Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Cross-Company Posting Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.XRECH = 'X' Stappen
- SAP-verbinding instellen: Configureer in je externe ETL-tool een nieuwe bronverbinding met je SAP ECC-systeem. Hiervoor heb je meestal de gegevens van de applicatieserver, client, systeemnummer en een speciale SAP-gebruiker met de benodigde RFC-autorisaties nodig.
- Databronnen definiëren: Voeg binnen je extractieproject de benodigde SAP-tabellen toe als databronnen. De belangrijkste tabellen zijn BKPF (kop van boekingsdocument), BSEG (segment van boekingsdocument), VBSEGK (kop van geparkeerd document), CDHDR (kop van wijzigingsdocument), CDPOS (items van wijzigingsdocument), SWW_WI2OBJ (workflow-naar-objectkoppelingen), SWWLOGHIST (workflowlog) en SRGBTBREL (relaties voor GOS-bijlagen).
- Basisgebeurtenissen extraheren (aangemaakt en geparkeerd): Maak de eerste dataflow om de eerste gebeurtenissen te extraheren. Gebruik voor 'Journal Entry Parked' VBSEGK als bron. Gebruik voor 'Journal Entry Created' BKPF en filter daarbij op documenten die geen tegenboekingen zijn en niet oorspronkelijk zijn geparkeerd. Dit kun je doen met een anti-join op VBSEGK.
- Workflowgebeurtenissen extraheren: Maak een dataflow die BKPF koppelt aan SWW_WI2OBJ via de objectsleutel (bedrijfscode + documentnummer + boekjaar) om de ID van de workflow-instantie te vinden. Koppel dit resultaat aan SWWLOGHIST om gebeurtenissen zoals 'Submitted', 'Approved', 'Rejected' en 'Changes Requested' te extraheren op basis van de uitkomsten van workflowtaken en gebruikersbeslissingen in de log.
- Wijzigings- en verwijderingsgebeurtenissen extraheren: Gebruik de tabellen CDHDR en CDPOS om wijzigingen te identificeren. Filter voor 'Journal Entry Corrected' op wijzigingen aan geparkeerde documenten (Object Class 'FIPP'). Zoek voor 'Parked Journal Entry Deleted' naar verwijderingsmarkeringen in de wijzigingslogs van geparkeerde documenten.
- Bijlagegebeurtenissen extraheren: Koppel BKPF aan SRGBTBREL om 'Documentation Attached' vast te leggen. Gebruik daarbij objecttype 'BKPF' en relatie '[Your attachment relationship type]'. De aanmaakdatum van de koppeling geldt als tijdstip van de gebeurtenis.
- Clearing- en tegenboekingsgebeurtenissen extraheren: Zoek voor 'Journal Entry Line Item Cleared' in de BSEG-tabel naar regels waarin het veld voor het clearingdocument (AUGBL) is ingevuld. Het tijdstip van de gebeurtenis is de boekingsdatum van het clearingdocument (AUGDT). Zoek voor 'Journal Entry Reversal Processed' in BKPF naar documenten die tegenboekingen zijn, herkenbaar aan een waarde in het veld voor het tegengeboekte document (STBLG).
- Berekende gebeurtenissen afleiden: Maak aparte logica voor berekende gebeurtenissen. Filter voor 'Manual Entry Identified' in BKPF op basis van een lijst met handmatige transactiecodes, bijvoorbeeld FB01, FB50 en F-02. Groepeer voor 'Cross-Company Posting Identified' de BSEG-tabel op document-ID en identificeer documenten met meer dan één unieke bedrijfscode.
- Alle eventflows combineren: Gebruik een UNION-transformatie in je ETL-tool om de uitvoer van alle afzonderlijke eventflows, zoals Created, Parked en Approved, samen te voegen in één eventlogtabel. Zorg dat de kolomnamen en datatypen in alle flows overeenkomen.
- Toewijzen aan het uiteindelijke schema: Wijs de gecombineerde data toe aan de vereiste structuur van het event log. Maak daarbij
JournalEntryId,ActivityName,EventTime,Useren andere vereiste en aanbevolen attributen aan. Voeg statische kolommen toe, zoalsSourceSystem, en gebruik de uitvoeringstijd van de ETL-job voorLastDataUpdate. - Incrementeel laden configureren: Stel voor doorlopende extracties een strategie voor incrementeel laden in. Gebruik de laatste aanmaak- of wijzigingsdatum, bijvoorbeeld BKPF.CPUDT of CDHDR.UDATE, als watermark om alleen nieuwe of bijgewerkte records sinds de vorige run op te halen.
- Exporteren naar ProcessMind: Plan de extractiejob en configureer de laatste uitvoerstap om het event log op te slaan als CSV- of Parquet-bestand op een locatie die ProcessMind kan bereiken voor upload.
Configuratie
- Vereisten vooraf: Een gelicentieerde externe ETL-tool, bijvoorbeeld Theobald Xtract Universal, Informatica of Talend, met een speciale SAP-connector. Een SAP-gebruikersaccount met RFC-toegang en autorisaties om financiële tabellen, bijvoorbeeld S_TABU_DIS voor tabelgroepen F_00 en F_WF, workflowdata en wijzigingslogs te lezen.
- Verbindingsparameters: Je hebt het IP-adres of de hostnaam van de SAP Application Server, het systeemnummer en de client-ID nodig. Gebruik veilig gebruikersbeheer voor de SAP-gebruikersnaam en het wachtwoord.
- Belangrijke filters: Pas altijd bronfilters toe op bedrijfscode (BKPF.BUKRS) en boekjaar (BKPF.GJAHR) om het datavolume te beperken. Het is sterk aan te raden om ook te filteren op de aanmaakdatum van het document (BKPF.CPUDT) en zo een specifieke extractieperiode vast te leggen, bijvoorbeeld de afgelopen 6 maanden.
- Datumbereik selecteren: Kies voor de eerste lading een representatieve periode van bijvoorbeeld 3 tot 6 maanden. Gebruik voor volgende deltabeladingen een watermark op een timestampveld zoals
CPUDT, zodat alleen nieuwe records worden opgehaald. - Aandachtspunten voor prestaties: Joins op BSEG, CDPOS en workflowtabellen kunnen erg traag zijn. Zorg dat je ETL-tool filters waar mogelijk doorgeeft aan de SAP-bron. Extraheer data in kleinere delen of pakketten als de tool dit ondersteunt, vooral bij grote historische ladingen.
- Workflow aanpassen: De logica voor het identificeren van workflowactiviteiten zoals 'Approved' en 'Rejected' hangt sterk af van je specifieke workflowtemplates. Je moet de juiste workflowtaak-ID's en sleutels voor gebruikersbeslissingen in je systeem identificeren en in de filters gebruiken.
a Voorbeeldquery sql
/*
This is a logical representation of the extraction configuration in a third-party ETL tool.
It is not executable SQL but defines the sources, joins, and transformations for each activity.
Placeholders like [Your SAP Source], [Date Filter], and [Company Code Filter] must be configured in the tool.
*/
-- Extraction block for 'Journal Entry Parked'
SELECT
CONCAT(v.BUKRS, v.VBELN, v.GJAHR) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(CONCAT(v.CPUDT, v.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
v.USNAM AS User,
v.BUKRS AS CompanyCode,
v.BLART AS DocumentType,
v.BUDAT AS PostingDate,
v.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].VBSEGK v
WHERE [Date Filter on v.CPUDT] AND [Company Code Filter on v.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Created'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
LEFT JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE h.BSTAT = '' AND v.VBELN IS NULL AND h.STBLG IS NULL
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Posted' (from parked)
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Or a more precise posting time from change logs if available
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Submitted', 'Approved', 'Rejected', 'Changes Requested'
SELECT
CONCAT(SUBSTRING(o.INSTID, 3, 4), SUBSTRING(o.INSTID, 7, 10), SUBSTRING(o.INSTID, 17, 4)) AS JournalEntryId,
CASE
WHEN wl.WI_TEXT LIKE '%Submit%' THEN 'Journal Entry Submitted'
WHEN wl.WI_TEXT LIKE '%Approve%' THEN 'Journal Entry Approved'
WHEN wl.WI_TEXT LIKE '%Reject%' THEN 'Journal Entry Rejected'
WHEN wl.WI_TEXT LIKE '%Request Changes%' THEN 'Journal Entry Changes Requested'
END AS ActivityName,
CAST(CONCAT(wl.WI_CD, wl.WI_CT) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
wl.EXEC_USER AS User,
SUBSTRING(o.INSTID, 3, 4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SWW_WI2OBJ o
JOIN [Your SAP Source].SWWLOGHIST wl ON o.WI_ID = wl.WI_ID
WHERE o.TYPEID = 'BKPF' AND o.CATID = 'BO'
AND wl.WI_TEXT IN ('[Your Submit Task Name]', '[Your Approve Task Name]', '[Your Reject Task Name]', '[Your Changes Request Task Name]')
AND [Date Filter on wl.WI_CD]
UNION ALL
-- Extraction block for 'Journal Entry Corrected'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'U'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Parked Journal Entry Deleted'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Parked Journal Entry Deleted' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'D'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Documentation Attached'
SELECT
CONCAT(SUBSTRING(r.INSTID_A, 3, 4), SUBSTRING(r.INSTID_A, 7, 10), SUBSTRING(r.INSTID_A, 17, 4)) AS JournalEntryId,
'Documentation Attached' AS ActivityName,
-- Note: A precise timestamp is often unavailable. Using document creation time as a proxy.
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SRGBTBREL r
JOIN [Your SAP Source].BKPF h ON h.BUKRS = SUBSTRING(r.INSTID_A, 3, 4) AND h.BELNR = SUBSTRING(r.INSTID_A, 7, 10) AND h.GJAHR = SUBSTRING(r.INSTID_A, 17, 4)
WHERE r.TYPEID_A = 'BKPF' AND r.RELTYPE = '[Configure based on your system]'
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Reversal Processed'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.STBLG IS NOT NULL AND h.STBLG <> ''
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Is Reversed' flag on original document
SELECT
CONCAT(h_orig.BUKRS, h_orig.BELNR, h_orig.GJAHR) AS JournalEntryId,
'Is Reversed' AS ActivityName, -- This is an attribute update, modeled as an event
CAST(CONCAT(h_rev.CPUDT, h_rev.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h_rev.USNAM AS User,
h_orig.BUKRS AS CompanyCode,
h_orig.BLART AS DocumentType,
h_orig.BUDAT AS PostingDate,
h_orig.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h_rev
JOIN [Your SAP Source].BKPF h_orig ON h_rev.STBLG = h_orig.BELNR AND h_rev.BUKRS = h_orig.BUKRS AND h_rev.GJAHR_S = h_orig.GJAHR
WHERE h_rev.STBLG IS NOT NULL AND h_rev.STBLG <> ''
AND [Date Filter on h_rev.CPUDT] AND [Company Code Filter on h_rev.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Line Item Cleared'
SELECT
CONCAT(i.BUKRS, i.BELNR, i.GJAHR) AS JournalEntryId,
'Journal Entry Line Item Cleared' AS ActivityName,
CAST(i.AUGDT AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
NULL AS User, -- User who performed clearing is on the clearing document header
i.BUKRS AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BSEG i
WHERE i.AUGBL IS NOT NULL AND i.AUGBL <> ''
AND [Date Filter on i.AUGDT] AND [Company Code Filter on i.BUKRS]
UNION ALL
-- Extraction block for 'Manual Entry Identified'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Manual Entry Identified' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.TCODE IN ('FB01', 'F-02', 'FB50', 'FV50', '[Add other manual T-Codes]')
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Cross-Company Posting Identified'
SELECT
JournalEntryId,
'Cross-Company Posting Identified' AS ActivityName,
EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
User,
CompanyCode,
DocumentType,
PostingDate,
TransactionCode,
IsReversed
FROM (
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed,
(SELECT COUNT(DISTINCT i.BUKRS) FROM [Your SAP Source].BSEG i WHERE i.BELNR = h.BELNR AND i.BUKRS = h.BUKRS AND i.GJAHR = h.GJAHR) as CompanyCodeCount
FROM [Your SAP Source].BKPF h
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
) AS CrossCompanyCheck
WHERE CompanyCodeCount > 1 Klaar om aan de slag te gaan?
Gebruik deze datatemplate om je process mining-traject voor Record to Report - Journal Entry te starten. Krijg waardevolle inzichten en verbeter de efficiëntie van je financiële bedrijfsvoering.
Optimaliseer je Record to Report - Journal Entry-proces nu
Verlaag de doorlooptijd van journaalposten met 30% en zorg voor foutloze rapportage.
Je hebt geen creditcard nodig. Begin vandaag met verbeteren.