Jouw datatemplate voor Order to Cash - facturatie en facturering
Jouw datatemplate voor Order to Cash - facturatie en facturering
- Aanbevolen attributen om te verzamelen
- Belangrijkste activiteiten om te volgen
- Extractiehandleiding voor SAP S/4HANA
Attributen voor Order to Cash - Facturatie en factuurverwerking
| Naam | Beschrijving | ||
|---|---|---|---|
| Factuurnummer InvoiceNumber | De unieke identificatie van een facturatiedocument, die als primaire case-identificatie voor het facturatieproces dient. | ||
| Beschrijving Het factuurnummer, in SAP bekend als het nummer van het facturatiedocument, identificeert elke facturatietransactie uniek. Het fungeert als centrale sleutel die alle gerelateerde activiteiten koppelt, van het aanmaken en boeken van de factuur tot het ontvangen en vereffenen van de betaling. In process mining is dit attribuut essentieel voor het koppelen van cases. Alle gebeurtenissen met hetzelfde factuurnummer worden gegroepeerd in één procesinstantie. Zo kun je de volledige end-to-end levenscyclus van elke afzonderlijke factuur analyseren. Je kunt doorlooptijden volgen, afwijkingen vinden en het verloop van elke factuur analyseren. Waarom dit belangrijk is Dit is de basisidentificatie die alle gerelateerde facturatieactiviteiten aan één case koppelt en end-to-end procesanalyse mogelijk maakt. Waar je het vindt SAP-tabel: VBRK, veld: VBELN Voorbeelden 900012349000567890009012 | |||
| Activiteitsnaam ActivityName | De naam van de bedrijfsactiviteit of gebeurtenis die binnen het facturatieproces plaatsvond, zoals 'Factuur gegenereerd' of 'Betaling ontvangen'. | ||
| Beschrijving De activiteitsnaam beschrijft een specifieke stap of mijlpaal in de levenscyclus van de factuur. Deze activiteiten worden afgeleid uit verschillende datapunten in SAP, zoals transactiecodes, wijzigingen in documentstatussen of specifieke logregels, om een opeenvolgende procesflow te maken. Het analyseren van de volgorde en frequentie van deze activiteiten vormt de kern van process mining. Hiermee kun je de procesmap visualiseren, veelvoorkomende en zeldzame procesvarianten ontdekken, bottlenecks tussen stappen vinden en de frequentie meten van activiteiten zonder toegevoegde waarde, zoals herstelwerk of annuleringen. Waarom dit belangrijk is Dit attribuut definieert de processtappen. Daarmee kun je procesmaps visualiseren en de procesflow, varianten en bottlenecks analyseren. Waar je het vindt Afgeleid uit verschillende bronnen, waaronder transactiecodes (SY-TCODE), statussen van wijzigingsdocumenten (tabellen CDHDR/CDPOS) of logs van bedrijfsworkflows (bijvoorbeeld SWW_WI2OBJ). Voorbeelden Factuur gegenereerdFactuur geboekt in de boekhoudingBetaling van klant ontvangenFactuur geannuleerd | |||
| Gebeurtenistijd EventTime | De precieze timestamp die aangeeft wanneer een activiteit of gebeurtenis plaatsvond. | ||
| Beschrijving De gebeurtenistijd bevat de datum en tijd van elke activiteit en vormt de chronologische basis van het proces. Deze timestamp is belangrijk voor het berekenen van tijdsduur, doorlooptijden en wachttijden tussen verschillende stappen in het facturatieproces. In analyses wordt de gebeurtenistijd gebruikt om activiteiten in de juiste volgorde te zetten, KPI's zoals Days Sales Outstanding en de doorlooptijd voor het genereren van facturen te berekenen en tijdsgebonden bottlenecks te vinden. Zo krijg je een dynamisch beeld van het proces: je ziet hoe de prestaties in de tijd veranderen en hoe lang elke fase van de facturatiecyclus duurt. Waarom dit belangrijk is Dit levert de chronologische volgorde van gebeurtenissen op. Die is nodig voor het berekenen van alle tijdsgebonden meetwaarden, zoals doorlooptijden en tijdsduur. Waar je het vindt Geëxtraheerd uit verschillende datum- en tijdvelden, afhankelijk van de activiteit, zoals aanmaakdatum en -tijd (VBRK-ERDAT, VBRK-ERZET), wijzigingstimestamps (CDHDR-UDATE, CDHDR-UTIME) of boekingsdatum (BKPF-BUDAT). Voorbeelden 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| Eindtijd EndTime | De precieze timestamp die aangeeft wanneer een activiteit of gebeurtenis is afgerond. | ||
| Beschrijving De eindtijd markeert het moment waarop een activiteit is afgerond. In process mining wordt deze vaak afgeleid als de starttijd van de volgende activiteit in de case. Als het systeem zowel start- als eindgebeurtenissen registreert, kan de eindtijd ook rechtstreeks uit de bron komen. Dit attribuut is nodig om de verwerkingstijd van afzonderlijke activiteiten te berekenen. Door de starttijd van de eindtijd af te trekken, meet je hoe lang elke stap duurt. Dat is belangrijk voor bottleneckanalyse, bijvoorbeeld om vertragingen bij de goedkeuring van facturen te vinden. Waarom dit belangrijk is Hiermee kun je de exacte duur, oftewel de verwerkingstijd, van elke activiteit berekenen. Dat is de basis voor bottleneckanalyse. Waar je het vindt Dit is een afgeleid attribuut voor process mining. Meestal wordt het berekend als de StartTime van de volgende gebeurtenis in de casereeks. In sommige situaties leggen specifieke tabellen de voltooiingstijd vast. Voorbeelden 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| Factuurbedrag InvoiceAmount | De totale nettowaarde van de factuur. | ||
| Beschrijving Dit attribuut staat voor de totale geldwaarde van de gefactureerde goederen of diensten, exclusief belastingen. Het is een belangrijk financieel datapunt voor elke factuurcase. Het factuurbedrag wordt voor veel analyses gebruikt. Je kunt het proces op waarde segmenteren, bijvoorbeeld om te zien of facturen met een hoge waarde anders worden verwerkt of vaker vertraging oplopen. Het vormt ook de basis voor financiële rapportages en het berekenen van de totale waarde van openstaande vorderingen. Waarom dit belangrijk is Het kwantificeert de financiële waarde van elke factuur. Zo kun je op waarde analyseren, incasso prioriteren en de financiële impact beoordelen. Waar je het vindt SAP-tabel: VBRK, veld: NETWR Voorbeelden 1500.0025000.50125.75 | |||
| Factuurdatum InvoiceDate | De officiële datum waarop de factuur aan de klant is uitgegeven. | ||
| Beschrijving De factuurdatum, in SAP ook wel facturatiedatum genoemd, vormt het startpunt voor veel financiële berekeningen. Vanaf deze datum worden betalingstermijnen, vervaldatums en de ouderdom van de vordering bepaald. Deze datum is een belangrijk attribuut op caseniveau voor financiële analyses. Het is de basis voor het berekenen van de KPI Days Sales Outstanding (DSO) en voor rapportages over de ouderdom van openstaande facturen. Die rapportages zijn belangrijk voor het beheren van cashflow en incasso. Waarom dit belangrijk is Dit is de belangrijkste datum voor financiële berekeningen en vormt het startpunt voor DSO, vervaldatums en analyses van de ouderdom van facturen. Waar je het vindt SAP-tabel: VBRK, veld: FKDAT Voorbeelden 2023-03-202023-04-012023-05-18 | |||
| Gebruikersnaam UserName | De gebruikers-ID van de medewerker die de activiteit heeft uitgevoerd. | ||
| Beschrijving Dit attribuut legt de SAP-gebruikers-ID vast die verantwoordelijk is voor een bepaalde gebeurtenis, zoals het aanmaken van een factuur, het boeken van een document of het vereffenen van een betaling. Het koppelt processtappen aan de personen of teams die ze uitvoeren. Door op gebruikersnaam te analyseren, kun je goed presterende medewerkers, opleidingsbehoeften of onevenwichtige werkverdeling vinden. Het is ook belangrijk voor compliance-analyse: je ziet wie kritieke activiteiten heeft uitgevoerd en hoe verschillende gebruikers hetzelfde proces uitvoeren. Waarom dit belangrijk is Het koppelt procesactiviteiten aan specifieke gebruikers. Zo kun je werkbelasting, prestaties en compliance op individueel of teamniveau analyseren. Waar je het vindt Voor aanmaakgebeurtenissen staat dit in VBRK-ERNAM. Voor latere wijzigingen vind je het in wijzigingshistorietabellen zoals CDHDR-USERNAME of in workflowlogs. Voorbeelden CBURNSHSIMPSONLLEONARD | |||
| Klantnaam CustomerName | De naam van de klant aan wie de factuur is uitgegeven. | ||
| Beschrijving Dit attribuut identificeert de wettelijke naam van de gefactureerde klant. De data komt uit de centrale klantstamgegevens in SAP. Door het proces per klant te analyseren, kun je patronen bij specifieke accounts vinden. Zo zie je welke klanten structureel te laat betalen, de meeste geschillen indienen of voor wie het facturatieproces het minst efficiënt verloopt. Daarmee kun je klantrelatiebeheer en incassostrategieën gerichter aanpakken. Waarom dit belangrijk is Het maakt klantgerichte analyses mogelijk. Zo kun je betaalgedrag, de frequentie van geschillen en procesinefficiënties bij specifieke accounts vinden. Waar je het vindt Opgehaald uit klantstamtabel KNA1 (veld: NAME1), gekoppeld via de betaler-ID in de factuurkop (VBRK-KUNRG). Voorbeelden Elektriciteitscentrale SpringfieldKwik-E-MartCyberdyne Systems | |||
| Regio Region | De geografische regio van de klant. | ||
| Beschrijving Het attribuut regio geeft het geografische gebied aan, zoals een staat of provincie, dat bij het adres van de klant hoort. Deze data maakt meestal deel uit van het klantstamrecord. Dit attribuut is belangrijk voor het dashboard voor regionale facturatieprestaties. Je kunt er KPI's zoals doorlooptijden, foutpercentages en DSO tussen regio's mee vergelijken. Zo worden regionale verschillen in procesuitvoering, compliance of efficiëntie zichtbaar en kun je gerichte verbeteringen en standaardisatie van goede werkwijzen aanpakken. Waarom dit belangrijk is Hiermee kun je facturatieprestaties tussen geografische gebieden vergelijken, regionale verschillen vinden en processen standaardiseren. Waar je het vindt Opgehaald uit klantstamtabel KNA1 (veld: REGIO), gekoppeld via de betaler-ID in de factuurkop (VBRK-KUNRG). Voorbeelden CANYTXBA | |||
| Vervaldatum betaling PaymentDueDate | De datum waarop de klant de factuur uiterlijk moet betalen. | ||
| Beschrijving De vervaldatum van de betaling wordt berekend op basis van de factuurdatum en de afgesproken betalingstermijnen. Het is de uiterste datum waarop de betaling moet zijn ontvangen voordat de factuur achterstallig wordt. Dit attribuut is belangrijk voor het volgen van de effectiviteit van incasso en het voorspellen van cashflow. Het wordt rechtstreeks gebruikt bij het berekenen van de KPI voor tijdige betalingen en bij het indelen van facturen in ouderdomsrapportages. Door de vervaldatum te vergelijken met de werkelijke betaaldatum, kun je de effectiviteit van verschillende betalingstermijnen beoordelen. Waarom dit belangrijk is Het bepaalt de uiterste betaaldatum van de klant en is daarmee belangrijk voor het berekenen van tijdige betalingen en het beheren van debiteuren. Waar je het vindt Deze datum wordt niet rechtstreeks opgeslagen, maar berekend op basis van de factuurdatum (VBRK-FKDAT) en de sleutel voor betalingstermijnen (VBRK-ZTERM), met de standaardfuncties van SAP voor datumvaststelling. Voorbeelden 2023-04-192023-05-012023-06-17 | |||
| Bedrijfsnummer CompanyCode | De organisatorische eenheid waarvoor de financiële transactie wordt geregistreerd. | ||
| Beschrijving Het bedrijfsnummer is een belangrijke organisatorische entiteit in SAP Financials. Het staat voor een juridisch zelfstandige onderneming waarvoor financiële overzichten worden opgesteld. Elk facturatiedocument wordt aan een specifiek bedrijfsnummer toegewezen. Analyseren per bedrijfsnummer is belangrijk in organisaties met meerdere ondernemingen. Je kunt procesprestaties, financiële meetwaarden zoals DSO en compliance tussen juridische entiteiten vergelijken. Het biedt een organisatorisch filter op hoog niveau voor alle procesdashboards. Waarom dit belangrijk is Hiermee kun je processen per juridische entiteit analyseren en prestaties en financiële consolidatie binnen de organisatie vergelijken. Waar je het vindt SAP-tabel: VBRK, veld: BUKRS Voorbeelden 10002000US01 | |||
| Betalingsstatus PaymentStatus | De huidige status van de factuurbetaling, zoals Open, Betaald of Achterstallig. | ||
| Beschrijving De betalingsstatus geeft een momentopname van de positie van een factuur in de incassocyclus. Dit is geen afzonderlijk veld in SAP, maar wordt afgeleid door de vereffeningsstatus van het bijbehorende boekhoudingsdocument te controleren. Dit attribuut is belangrijk voor het dashboard voor de ouderdom van openstaande facturen. Je kunt alle openstaande facturen op status en ouderdom segmenteren, zodat het incassoteam het werk goed kan prioriteren. Ook het volgen van statusovergangen helpt om het incassoproces zelf te bewaken. Waarom dit belangrijk is Het geeft in één oogopslag de incassostatus van een factuur weer. Dat is belangrijk voor het beheren van vorderingen en het prioriteren van incassoactiviteiten. Waar je het vindt Afgeleid door de vereffeningsstatus van het boekhoudingsdocument (VBRK-BELNR) te controleren in financiële tabellen zoals BSID (open posten) en BSAD (vereffende posten). Voorbeelden OpenBetaaldAchterstalligGedeeltelijk betaald | |||
| Betalingstermijnen PaymentTerms | De code die de betalingsvoorwaarden definieert, zoals de toegestane betalingstermijn. | ||
| Beschrijving Betalingstermijnen zijn vooraf vastgelegde voorwaarden die met een klant zijn afgesproken en bepalen wanneer een factuur moet worden betaald. Voorbeelden zijn 'Net 30' (betaling binnen 30 dagen) of '2/10 Net 30' (2% korting bij betaling binnen 10 dagen, anders betaling binnen 30 dagen). Door betalingstermijnen te analyseren, kun je de effectiviteit ervan beoordelen. Door verschillende betalingstermijnen te koppelen aan de werkelijke tijd tot ontvangst van de betaling, zie je welke voorwaarden snelle betaling het meest stimuleren en kun je de termijnen aanpassen om de cashflow te verbeteren. Waarom dit belangrijk is Het definieert het afgesproken betalingsschema. Zo kun je analyseren welke voorwaarden het beste zorgen voor tijdige betaling door klanten. Waar je het vindt SAP-tabel: VBRK, veld: ZTERM Voorbeelden Z030Z060ZB60 | |||
| Bronsysteem SourceSystem | Identificeert het specifieke bronsysteem waaruit de data is geëxtraheerd. | ||
| Beschrijving Dit attribuut geeft de herkomst van de data aan. Dat is vooral nuttig in omgevingen met meerdere SAP-instanties of andere geïntegreerde systemen. Meestal bevat het de systeem-ID en het klantnummer. In analyses helpt het om processen en prestaties tussen verschillende systemen of organisatieonderdelen te onderscheiden. Het maakt de dataherkomst inzichtelijk en geeft context, vooral wanneer data uit meerdere bronnen wordt gecombineerd voor een volledig procesbeeld. Waarom dit belangrijk is Dit geeft belangrijke context over de herkomst van de data, zorgt voor duidelijkheid in omgevingen met meerdere systemen en ondersteunt datagovernance. Waar je het vindt Dit is meestal een statische waarde die tijdens de data-extractie wordt vastgelegd. Vaak bestaat deze uit de systeem-ID (SY-SYSID) en de client (SY-MANDT). Voorbeelden S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| Facturatiedocumenttype BillingDocumentType | Een code die het facturatiedocument classificeert, zoals een factuur, creditnota of annulering. | ||
| Beschrijving Het facturatiedocumenttype is een belangrijk veld dat transacties binnen het facturatieproces categoriseert. Het bepaalt hoe het document wordt verwerkt, waaronder de nummerreeks en boekingsregels voor de boekhouding. Met dit attribuut kun je het proces filteren en specifieke transactietypen analyseren. Je kunt bijvoorbeeld een aparte procesweergave maken voor creditnota's om de redenen en procesflow van financiële correcties te begrijpen. Ook kun je standaardfacturen los van annuleringen analyseren voor een duidelijker beeld van het primaire facturatieproces. Waarom dit belangrijk is Het classificeert transacties en maakt gerichte analyses mogelijk van specifieke documentflows, zoals standaardfacturen, creditnota's of annuleringen. Waar je het vindt SAP-tabel: VBRK, veld: FKART Voorbeelden F2G2S1L2 | |||
| Laatste data-update LastDataUpdate | De timestamp die aangeeft wanneer de data voor deze gebeurtenis voor het laatst is geëxtraheerd of vernieuwd. | ||
| Beschrijving Dit attribuut registreert de datum en tijd van de laatste data-extractie uit het bronsysteem. Het is een metadataveld dat belangrijk is om te begrijpen hoe actueel de geanalyseerde data is. Deze informatie wordt gebruikt om de actualiteit van de analyse te controleren en verversingsschema's voor de data te beheren. Zo weten belanghebbenden hoe actueel de data is wanneer ze beslissingen nemen op basis van procesdashboards en Process Mining-inzichten. Waarom dit belangrijk is Dit geeft aan hoe actueel de data is. Dat is belangrijk om op de analyse te kunnen vertrouwen en de relevantie ervan voor de huidige bedrijfsvoering te begrijpen. Waar je het vindt Deze timestamp wordt tijdens het data-extractie- en laadproces (ETL) gegenereerd en aan elk record toegevoegd. Voorbeelden 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| Op tijd betaald IsPaidOnTime | Een booleaanse vlag die aangeeft of de factuur op of vóór de vervaldatum is betaald. | ||
| Beschrijving Dit is een berekend attribuut dat de werkelijke betaaldatum vergelijkt met de geplande vervaldatum. De waarde is 'true' als de betaling op tijd is ontvangen en 'false' als de betaling te laat was. Deze vlag vereenvoudigt de berekening en visualisatie van de KPI voor tijdige betalingen. Je kunt eenvoudig filteren en segmenteren om de kenmerken van te laat en op tijd betaalde facturen te analyseren. Zo vind je patronen bij specifieke klanten, regio's of betalingstermijnen die tot late betalingen leiden. Waarom dit belangrijk is Het vereenvoudigt prestatiemeting door elke factuur duidelijk als 'op tijd' of 'te laat' te markeren en ondersteunt rechtstreeks de KPI voor tijdige betalingen. Waar je het vindt Dit is een berekend veld. De logica vergelijkt de timestamp van de activiteit 'Klantbetaling ontvangen' met de waarde in het attribuut 'PaymentDueDate'. Voorbeelden truefalse | |||
| Reden van creditnota CreditMemoReason | De redenencode die aangeeft waarom een creditnota is uitgegeven. | ||
| Beschrijving Wanneer een factuur onjuist is en moet worden gecrediteerd, wordt meestal een reden aan het creditnotadocument toegewezen. Zo kun je de oorzaken van facturatiefouten gestructureerd indelen. Dit attribuut ondersteunt rechtstreeks de KPI voor het facturatiefoutpercentage. Door redenen voor creditnota's te verzamelen en te analyseren, kan een organisatie de meest voorkomende fouten vinden, zoals prijsfouten of productretouren. Deze analyse leidt tot procesverbeteringen die financiële correcties en herstelwerk verminderen. Waarom dit belangrijk is Het deelt de redenen voor het verstrekken van credit in categorieën in. Zo zie je welke oorzaken van facturatiefouten het vaakst voorkomen en kun je de kwaliteit verbeteren. Waar je het vindt SAP-tabel: VBRK, veld: AUGRU (orderreden). Dit veld wordt gebruikt voor credit- en debetnotaverzoeken die vervolgens worden gefactureerd. Voorbeelden 001 - Prijsverschil002 - Slechte kwaliteit005 - Retour van klant | |||
| Reden van geschil CustomerDisputeReason | De reden die een klant opgeeft om een factuur te betwisten. | ||
| Beschrijving Wanneer een klant een factuur betwist, wordt de reden van het geschil vaak vastgelegd. Het kan bijvoorbeeld gaan om prijsfouten, onjuiste aantallen of beschadigde goederen. Deze informatie kan worden opgeslagen in de SAP-module Dispute Management of als tekstnotitie. Het analyseren van redenen voor geschillen is belangrijk voor de KPI voor het facturatiefoutpercentage en de bijbehorende foutanalyse. Zo vind je de oorzaken van onjuiste facturen en kan de organisatie problemen eerder in het proces aanpakken, de factuurkwaliteit verbeteren en de klanttevredenheid verhogen. Waarom dit belangrijk is Het verklaart waarom facturen worden betwist en geeft rechtstreeks inzicht in de oorzaken van facturatiefouten en klantontevredenheid. Waar je het vindt Als SAP Dispute Management wordt gebruikt, vind je deze informatie in tabellen zoals UDM_DISPUTE. Anders kan de data worden afgeleid uit redenencodes op gerelateerde documenten of uit tekstvelden. Voorbeelden Onjuiste prijsVerschil in hoeveelheidBeschadigde goederen ontvangen | |||
| Valuta Currency | De valutacode voor het factuurbedrag. | ||
| Beschrijving Dit attribuut geeft aan in welke valuta de factuurbedragen zijn uitgedrukt, zoals USD, EUR of JPY. Het biedt de nodige context voor alle geldbedragen. In een internationale organisatie is valuta nodig voor correcte financiële analyses en rapportages. Je kunt financiële data per regio goed optellen door alle bedragen naar één rapportagevaluta om te rekenen en de facturatieprestaties in regio's met verschillende lokale valuta vergelijken. Waarom dit belangrijk is Het biedt de nodige context voor alle geldbedragen en zorgt voor een correcte financiële analyse en rapportage, vooral in internationale bedrijfsvoering. Waar je het vindt SAP-tabel: VBRK, veld: WAERK Voorbeelden USDEURGBP | |||
| Verkoopordernummer SalesOrderNumber | De identificatie van de oorspronkelijke verkooporder die tot de factuur heeft geleid. | ||
| Beschrijving Het verkoopordernummer koppelt het facturatiedocument aan de voorafgaande verkoopactiviteiten. Eén verkooporder kan leiden tot één of meer facturen. Deze koppeling maakt de volledige documentflow zichtbaar. Dit attribuut is belangrijk voor een echte end-to-end Order-to-Cash-analyse. Je kunt de procesweergave stroomopwaarts uitbreiden en facturatieproblemen koppelen aan mogelijke oorzaken bij het aanmaken of uitvoeren van de verkooporder. Zo kun je bijvoorbeeld de totale doorlooptijd voor het genereren van de factuur berekenen vanaf het moment waarop de order is uitgevoerd. Waarom dit belangrijk is Het koppelt de factuur aan de oorspronkelijke verkooporder en geeft zo een breder end-to-end beeld van het Order-to-Cash-proces dan alleen de facturatie. Waar je het vindt SAP-tabel: VBRP (gegevens van facturatiedocumentpost), veld: AUBEL Voorbeelden 100001231000045610000789 | |||
Activiteiten voor Order to Cash - Facturatie en factuurverwerking
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Betaling van klant ontvangen | Deze activiteit markeert het boeken van een binnenkomende klantbetaling in het financiële systeem. De betaling is op dit moment mogelijk nog niet aan een specifieke factuur gekoppeld, maar het bedrag is wel geregistreerd. | ||
| Waarom dit belangrijk is Dit is een belangrijk moment voor het berekenen van Days Sales Outstanding (DSO). Het betekent dat de betaling is ontvangen, ook als de afstemming nog niet is afgerond. Waar je het vindt Vastgelegd op basis van de boekingsdatum (BKPF-BUDAT) van het klantbetalingsdocument (meestal documenttype 'DZ' in tabel BKPF). Vastleggen De gebeurtenis is gebaseerd op het aanmaken van het betalingsdocument in BKPF/BSEG. Eventtype explicit | |||
| Betaling verwerkt/verrekend | Geeft het moment weer waarop de binnenkomende klantbetaling aan de openstaande factuurpost wordt gekoppeld en deze vereffent in het subgrootboek debiteuren. Met deze activiteit is de transactie financieel afgerond. | ||
| Waarom dit belangrijk is Meet de efficiëntie van het betalingsverwerkingsproces. Vertragingen op dit punt kunnen een verkeerd beeld geven van de werkelijke status van klantrekeningen en onnodig werk veroorzaken voor incassoteams. Waar je het vindt Deze gebeurtenis wordt vastgelegd via de vereffeningsdatum (BSEG-AUGDT) op de regel van het oorspronkelijke factuurdocument. Deze datum wordt ingevuld wanneer een vereffeningsdocument de post vereffent. Vastleggen Vastgelegd vanuit het veld voor de vereffeningsdatum (AUGDT) in de tabel BSEG/ACDOCA voor de factuurregel. Eventtype explicit | |||
| Factuur geboekt in de boekhouding | Dit staat voor het succesvol boeken van het facturatiedocument in de financiële administratie. Het is een belangrijk moment waarop de factuur een officiële post op debiteuren wordt en boekingen in het grootboek ontstaan. | ||
| Waarom dit belangrijk is Deze activiteit bevestigt dat de factuur een juridisch financieel document is. De tijd tussen aanmaak en boeking is een belangrijke KPI voor de efficiëntie van de interne verwerking. Waar je het vindt Deze gebeurtenis wordt vastgelegd wanneer het bijbehorende boekhoudkundige document wordt aangemaakt. Het facturatiedocument (VBRK-VBELN) is via VBRK-BELNR gekoppeld aan het boekhoudkundige document (BKPF-BELNR). De boekingsdatum is BKPF-BUDAT. Vastleggen Wordt vastgelegd op basis van de boekingsdatum (BUDAT) van het boekhoudkundige document in tabel BKPF dat aan het facturatiedocument is gekoppeld. Eventtype explicit | |||
| Factuur gegenereerd | Deze activiteit markeert het aanmaken van het facturatiedocument in het systeem. Het is een expliciete gebeurtenis die wordt vastgelegd wanneer een gebruiker een transactie zoals VF01 uitvoert of wanneer een achtergrondtaak de factuur aanmaakt. Daardoor ontstaat een nieuwe regel in de koptekstabel van het facturatiedocument. | ||
| Waarom dit belangrijk is Dit is de primaire startgebeurtenis van het facturatieproces. Door de tijd tussen het uitvoeren van de order en deze activiteit te analyseren, kun je de doorlooptijd van de factuuraanmaak meten en de eerste procesvertragingen herkennen. Waar je het vindt Wordt bij het aanmaken vastgelegd in de SAP S/4HANA-tabel VBRK (Billing Document: Header Data). De aanmaakdatum (VBRK-ERDAT) en -tijd (VBRK-ERZET) vormen de timestamp. Vastleggen De gebeurtenis wordt vastgelegd op basis van de aanmaaktimestamp van het facturatiedocument in tabel VBRK. Eventtype explicit | |||
| Factuur gesloten | Deze activiteit geeft de eindstatus van een volledig betaalde factuur aan. Functioneel is dit hetzelfde als 'Betaling verwerkt/verrekend' en geeft het aan dat het proces voor deze factuur is afgerond. | ||
| Waarom dit belangrijk is Dit is de belangrijkste eindgebeurtenis voor het normale procesverloop. Door de totale doorlooptijd tot dit punt te meten, krijg je een volledig beeld van de end-to-end levenscyclus van facturatie en factuurverwerking. Waar je het vindt Afgeleid van de status van de klantregel in het boekhoudingsdocument. Een post is gesloten of 'vereffend' wanneer de velden voor de vereffeningsdatum (BSEG-AUGDT) en het vereffeningsdocument (BSEG-AUGBL) zijn ingevuld. Vastleggen Afgeleid van het invullen van de vereffeningsdatum (AUGDT) in de tabel BSEG/ACDOCA voor de factuurregel. Eventtype inferred | |||
| Betalingsherinnering verzonden | Dit staat voor het versturen van een betalingsherinnering of aanmaning aan een klant voor een achterstallige factuur. Het is een expliciete gebeurtenis die door de geautomatiseerde aanmaningsprocedure wordt gegenereerd. | ||
| Waarom dit belangrijk is Hiermee kun je de effectiviteit van het aanmaningsproces analyseren. Je ziet of herinneringen betalingen versnellen en welke aanmaningsniveaus het meeste effect hebben. Waar je het vindt Wordt vastgelegd in de tabellen met aanmaningshistorie (MAHNV, MHND) wanneer de aanmaningsrun, transactie F150, wordt uitgevoerd voor de openstaande post van de factuur. Vastleggen Wordt vastgelegd op basis van de uitvoerdatum van de aanmaning in de tabellen met aanmaningshistorie. Eventtype explicit | |||
| Boeking van factuur geblokkeerd | Deze gebeurtenis vindt plaats wanneer een factuur is aangemaakt, maar automatisch wordt geblokkeerd voor boeking in de financiële administratie. Dat kan verschillende oorzaken hebben, zoals kredietcontroles of inconsistenties in de data. De status wordt afgeleid uit het veld voor de boekingsstatus van het facturatiedocument. | ||
| Waarom dit belangrijk is Dit maakt bottlenecks zichtbaar waarbij facturen wel zijn aangemaakt, maar niet meteen naar de financiële administratie worden vrijgegeven. Daardoor loopt de volledige incassocyclus vertraging op. Het is een belangrijke aanwijzing voor problemen met datakwaliteit of kredietbeheer. Waar je het vindt Wordt afgeleid uit het veld voor de boekingsstatus in de koptekstabel van het facturatiedocument (VBRK-RFBSK). Een status zoals 'A' (Billing document blocked for forwarding to FI) wijst op een blokkade. Vastleggen Wordt afgeleid door de waarde van het veld voor de boekingsstatus (VBRK-RFBSK) direct na het aanmaken van de factuur te controleren. Eventtype inferred | |||
| Creditnota aangemaakt | Deze activiteit staat voor het aanmaken van een creditnota. Die wordt aan een klant verstrekt om een te hoog gefactureerd bedrag te corrigeren of geretourneerde goederen te crediteren. Vaak is de creditnota gekoppeld aan een oorspronkelijke factuur. | ||
| Waarom dit belangrijk is Maakt problemen zichtbaar die na de facturatie tot financiële correcties leiden. Door creditnota's te analyseren, kun je prijsfouten, productproblemen en andere oorzaken van omzetverlies vinden. Waar je het vindt Expliciet aangemaakt als nieuw facturatiedocument in VBRK, met een specifiek facturatietype voor creditnota's (bijvoorbeeld 'G2'). Vaak verwijst het naar de oorspronkelijke verkooporder of factuur. Vastleggen Vastgelegd bij het aanmaken van een facturatiedocument in VBRK met een facturatietype voor creditnota's. Eventtype explicit | |||
| Factuur geannuleerd | Dit gebeurt wanneer een eerder aangemaakte factuur wordt geannuleerd. Meestal wordt daarbij een bijbehorend annuleringsdocument aangemaakt. Hiermee worden de oorspronkelijke factuur en het boekhoudkundige effect ervan teruggedraaid. | ||
| Waarom dit belangrijk is Dit wijst op herstelwerk, correcties of facturatiefouten. Een hoog aantal annuleringen wijst op aanzienlijke problemen eerder in het proces, bijvoorbeeld bij het invoeren van verkooporders of de facturatieconfiguratie. Waar je het vindt Vastgelegd wanneer een annuleringsfactuur wordt aangemaakt (bijvoorbeeld documenttype 'S1'). Dit nieuwe document in VBRK verwijst in het veld VBRK-SFAKN naar het oorspronkelijke factuurnummer. Vastleggen De gebeurtenis wordt vastgelegd op basis van de aanmaakdatum van het annuleringsdocument in VBRK dat naar de oorspronkelijke factuur verwijst. Eventtype explicit | |||
| Factuur naar klant verzonden | Deze activiteit markeert het moment waarop de factuur naar de klant is verzonden, bijvoorbeeld per post, e-mail of EDI. Hoe dit wordt vastgelegd, hangt af van de configuratie van outputbeheer in SAP. | ||
| Waarom dit belangrijk is Dit is het officiële begin van de betaaltermijn vanuit het perspectief van de klant. Vertraging bij het versturen van de factuur heeft rechtstreeks gevolgen voor Days Sales Outstanding (DSO) en de cashflow. Waar je het vindt Kan expliciet worden vastgelegd in de tabellen voor outputbeheer, zoals NAST voor oudere methoden of het S/4HANA-equivalent daarvan. Als dit niet expliciet wordt vastgelegd, wordt vaak aangenomen dat de gebeurtenis plaatsvindt op hetzelfde moment als 'Invoice Posted To Accounting'. Vastleggen Controleer de verwerkingslogs in de tabellen voor outputbeheer op een timestamp die bij het outputtype van de factuur hoort. Eventtype explicit | |||
| Herstelwerk in facturatie vastgesteld | Een berekende gebeurtenis die een herstelwerk-lus identificeert: een factuur is geannuleerd en daarna is voor dezelfde verkooporder een nieuwe factuur aangemaakt. Het gaat niet om één transactie, maar om een patroon van gebeurtenissen. | ||
| Waarom dit belangrijk is Ondersteunt rechtstreeks de KPI voor het herstelwerkpercentage in de facturatie door correcties te kwantificeren. Zo kun je inefficiënties lokaliseren en de kosten van slechte kwaliteit in het facturatieproces meten. Waar je het vindt Dit patroon wordt berekend door een gebeurtenis 'Factuur geannuleerd' te identificeren die wordt gevolgd door een nieuwe gebeurtenis 'Factuur gegenereerd'. Beide verwijzen naar hetzelfde brondocument, zoals een verkoopordernummer. Vastleggen Afgeleid door een reeks van 'Factuur geannuleerd' en 'Factuur gegenereerd' voor dezelfde verkooporderreferentie te detecteren. Eventtype calculated | |||
| Klantgeschil geopend | Deze activiteit vindt plaats wanneer een klant bezwaar maakt tegen een factuur en dit bezwaar formeel in het systeem wordt vastgelegd. Hiervoor is de SAP Dispute Management-module nodig. | ||
| Waarom dit belangrijk is Dit maakt problemen met factuurnauwkeurigheid, productkwaliteit of dienstverlening zichtbaar die tot betalingsvertraging leiden. Door de redenen voor geschillen te analyseren, kun je de oorzaken aanpakken en de klanttevredenheid verbeteren. Waar je het vindt Wordt vastgelegd wanneer een geschilcase wordt aangemaakt in de tabellen van Dispute Management, bijvoorbeeld UDM_CASE, en aan de documentregel van het boekhoudkundige document wordt gekoppeld. Vastleggen Wordt vastgelegd op basis van de aanmaaktimestamp van de geschilcase die aan de factuur is gekoppeld. Eventtype explicit | |||
| Vervaldatum van betaling bereikt | Een berekende gebeurtenis die de datum weergeeft waarop de factuur volgens de afgesproken betalingsvoorwaarden officieel moet zijn betaald. Het is geen transactionele gebeurtenis, maar een datum die uit factuurdata wordt afgeleid. | ||
| Waarom dit belangrijk is Dit vormt een belangrijke basis voor het meten van tijdige betalingen en het analyseren van betaalgedrag van klanten. Zo kun je onderscheid maken tussen betalingen op tijd en achterstallige betalingen. Waar je het vindt Wordt berekend op basis van de basisdatum voor betaling (BSEG-ZFBDT) en de betalingsvoorwaarden die zijn opgeslagen in de klantregel van het boekhoudkundige document. Vastleggen Wordt afgeleid door het aantal dagen van de betalingsvoorwaarde op te tellen bij de basisdatum voor betaling in de documentregel van het boekhoudkundige document (BSEG). Eventtype calculated | |||
Extractiegidsen
Stappen
- Vereisten: Zorg dat je een gebruikersaccount in SAP S/4HANA hebt met de juiste autorisaties om Core Data Services (CDS)-views te bevragen. Je hebt specifiek leestoegang nodig tot views zoals I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase en I_DunningHistory.
- Open de data-extractietool: Log in op je SAP S/4HANA-systeem. Je kunt verschillende tools gebruiken om SQL-query's op CDS-views uit te voeren, zoals SAP HANA Studio, DBeaver via de SAP HANA-client of de SAP Analysis for Microsoft Excel-plugin. In deze handleiding gaan we uit van een standaard SQL-client.
- Bepaal de systeemparameters: Bepaal voordat je de query uitvoert de relevante bedrijfscodes en de datumperiode voor je analyse. Begin bij voorkeur met een beperkte scope, bijvoorbeeld de laatste 3 tot 6 maanden. Zo blijven de uitvoeringstijden beheersbaar.
- Bereid de SQL-query voor: Kopieer de volledige SQL-query uit de sectie 'query' van dit document naar je SQL-client.
- Pas placeholders aan: Wijzig de placeholderwaarden in de query. Vervang
'YYYY-MM-DD'door de gewenste begin- en einddatum. Vervang'XXXX'door de bedrijfscode(s) die je wilt analyseren. Mogelijk moet je ook de placeholder voor creditmemodocumenttypen aanpassen, bijvoorbeeld'G2', afhankelijk van je systeemconfiguratie. - Voer de query uit: Voer de aangepaste SQL-query uit op de SAP S/4HANA-database. De uitvoeringstijd hangt af van de hoeveelheid data in de gekozen periode.
- Controleer de resultaten: Controleer de uitvoer zodra de query klaar is. De resultatenset moet een platte tabel zijn waarin elke rij één activiteit in het facturatieproces vertegenwoordigt. Dit is je event log.
- Transformeer de data indien nodig: De query is ontworpen om een schoon event log op te leveren. Controleer wel of de timestampindeling compatibel is met je process mining-tool. De query gebruikt
ABAP_SYSTEM_UTCL_TO_TIMESTAMPom een standaard UTC-timestamp te maken. Die indeling is doorgaans breed compatibel. - Exporteer het event log: Exporteer de volledige resultatenset vanuit je SQL-client naar een CSV-bestand. Gebruik UTF-8-codering om problemen met tekens te voorkomen.
- Upload naar ProcessMind: Upload het gegenereerde CSV-bestand naar het ProcessMind-platform. Koppel kolommen zoals InvoiceNumber, ActivityName en EventTime aan de bijbehorende velden in de tool.
Configuratie
- Datumperiode: Stel de begin- en einddatum in de
WHERE-clause van de eerste Common Table Expression (CTE) in. Voor een eerste analyse raden we 3 tot 6 maanden aan, zodat datavolume en prestaties in balans blijven. Filter opBillingDocumentDate. - Bedrijfscode: Filter op een of meer waarden van
CompanyCodeom de extractie te beperken tot relevante juridische entiteiten. Dit filter is belangrijk om de scope beheersbaar te houden. - Documenttypen: De query bevat logica om creditmemo's te herkennen op basis van
BillingDocumentType. Configureer de placeholder, bijvoorbeeld('G2', 'CR'), met de documenttypen die jouw organisatie voor creditmemo's gebruikt. - Vereisten: Toegang tot de onderliggende CDS-views is verplicht. Je SAP-securityteam moet hiervoor specifieke rollen en autorisaties toewijzen. Voor activiteiten zoals 'Customer Dispute Opened' of 'Payment Reminder Issued' moeten bovendien de SAP-modules SAP Dispute Management en SAP Financials Dunning actief worden gebruikt.
- Prestaties: De query gebruikt meerdere joins en unions. Bij zeer grote datasets, bijvoorbeeld meerdere jaren aan data, kun je de query buiten piekuren uitvoeren of strengere filters toepassen om de eerste data-extractie te beperken.
a Voorbeeldquery sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime; Stappen
- Controleer of je directe leestoegang hebt tot het SAP HANA-schema met de facturatie- en gerelateerde financiële tabellen. Vraag de schemanaam, verbindingsgegevens, toegestane datumperiode, scope van bedrijfscodes, facturatiedocumenttypen en eventuele klant- of regi filters op bij de systeemeigenaar. Vervang in de query alleen de placeholders voor verbinding en filters.
- Controleer de relevante SAP S/4HANA-databronnen en hun veldkoppelingen in het doelsysteem. De query gebruikt VBRK en VBRP voor facturatiedata. Daarnaast zijn geconfigureerde bronnen nodig voor boekhouding, outputbeheer, geschilbeheer, aanmaningen, inkomende betalingen, clearing en documentrelaties. Vervang placeholders voor bronnen en velden pas nadat je ze hebt gecontroleerd aan de hand van het systeemdatadictionary.
- Stel de extractieperiode in met een inclusief begintijdstip en exclusief eindtijdstip. Voor de eerste run raden we 3 tot 6 maanden aan. Beperk de extractie op bedrijfscode en, waar passend, factureringstype. Zo houd je het volume onder controle en voorkom je dat niet-gerelateerde facturatieprocessen door elkaar lopen.
- Voer de query uit met een alleen-lezen HANA-databasegebruiker. De query maakt één eventrij aan voor elke expliciet geëxtraheerde activiteit. ProcessMind hoeft geen events af te leiden. Berekende activiteiten, waaronder Payment Due Date Reached en Billing Rework Identified, worden door SQL-logica gegenereerd en als rijen teruggegeven.
- Controleer het schema van de resultaten. Het event log moet InvoiceNumber, ActivityName, EventTime, UserName, InvoiceDate, PaymentDueDate, InvoiceAmount, CustomerName, Region en EndTime bevatten. Controleer of InvoiceNumber, ActivityName en EventTime in elke rij zijn ingevuld.
- Controleer de betekenis en relaties van events. Vergelijk rijen voor Invoice Generated met gegevens over het aanmaken van factuurkoppen, rijen voor Invoice Posted To Accounting met de boekingsstatus, rijen voor Invoice Sent To Customer met outputrecords, betalingsrijen met boekhoudkundige documenten en clearingrijen met vereffende factuurposten. Controleer alle secties die afhankelijk zijn van placeholders voordat je de query in productie gebruikt.
- Normaliseer het resultaat voor ProcessMind. Houd één rij per event aan, gebruik een consistent type timestamp en een vaste tijdzone, bewaar InvoiceNumber als tekst zodat voorloopnullen behouden blijven en zorg dat ActivityName-waarden exact overeenkomen met de vereiste activiteitsnamen. Sorteer op InvoiceNumber en EventTime. Gebruik een vaste secundaire sortering als meerdere events dezelfde timestamp hebben.
- Exporteer het resultaat als UTF-8-CSV of een ander door ProcessMind ondersteund tabelindeling. Koppel InvoiceNumber als case-ID, ActivityName als activiteitenkolom en EventTime als eventtimestamp. Voeg de aanbevolen attributen toe als die beschikbaar zijn. Upload het bestand daarna via het geconfigureerde ProcessMind-importproces en controleer tot slot het aantal rijen en activiteiten.
Configuratie
- Datumperiode: Begin met 3 tot 6 maanden. Gebruik een inclusief begintijdstip en exclusief eindtijdstip om dubbele events tussen incrementele runs te voorkomen.
- Case-ID: Gebruik InvoiceNumber uit de factuurkop. Bewaar dit als tekenreeks, omdat SAP-documentnummers voorloopnullen kunnen bevatten.
- Vereiste activiteiten: De extractie moet expliciete rijen opleveren voor Invoice Generated, Invoice Posting Blocked, Invoice Posted To Accounting, Invoice Sent To Customer, Payment Due Date Reached, Customer Dispute Opened, Payment Reminder Issued, Customer Payment Received, Cash Applied/Reconciled, Invoice Closed, Invoice Cancelled, Credit Memo Created en Billing Rework Identified.
- Filters: Pas filters voor Company Code, facturatiedocumenttype, verkooporganisatie, klant, regio en datum pas toe nadat je de bijbehorende velden en bedrijfscontext in het doelsysteem hebt gecontroleerd. Ga er niet van uit dat elk facturatiedocumenttype hetzelfde boekhoud- of outputproces volgt.
- Bronconfiguratie: VBRK en VBRP zijn de primaire facturatiebronnen. Bronnen voor boekhouding, output, geschillen, aanmaningen, betalingen, clearing en documentstromen moeten worden geconfigureerd op basis van de geïmplementeerde SAP S/4HANA-release en ingeschakelde modules. Vervang verwijzingen tussen blokhaken door gecontroleerde objecten en velden.
- Berekende events: Payment Due Date Reached wordt afgeleid uit betalingsvoorwaarden en vervaldatumdata. Billing Rework Identified wordt afgeleid uit patronen van annulering en daaropvolgende factuurgeneratie. Dit zijn door SQL gegenereerde eventrijen, geen oorspronkelijke transactieregels.
- Prestaties: Voeg filters voor datum, bedrijfscode, factureringstype en documentnummer toe aan elke bronquery. Selecteer alleen de benodigde kolommen, vermijd onbeperkte joins met grote boekhoudingstabellen, verwerk de periode in maand- of weekbatches en gebruik uitvoeringsplannen van de database om zware joins te vinden.
- Incrementele extractie: Gebruik een stabiele watermark op basis van aanmaak- of boekingstimestamps in de bron. Verwerk een kleine overlap opnieuw om laat binnengekomen output-, betalings-, geschil- en clearingrecords mee te nemen. Verwijder daarna duplicaten op basis van InvoiceNumber, ActivityName en EventTime, aangevuld met de relevante brondocumentsleutel.
- Autorisaties: De extractiegebruiker heeft leestoegang nodig tot de geselecteerde HANA-schemaobjecten en -velden. Controleer of directe databasetoegang volgens het securitybeleid van je organisatie is toegestaan en of je voldoet aan de eisen voor het verwerken van persoonsgegevens en klantdata.
- Functionele vereisten: Data voor outputbeheer, boekhoudintegratie, geschilbeheer, aanmaningen, inkomende betalingen en clearing is alleen beschikbaar als deze onderdelen in het systeem zijn geconfigureerd en worden gebruikt. Ontbrekende modules of bronrecords leiden tot ontbrekende activiteiten, niet tot afgeleide events.
- Tijdzone: Standaardiseer timestamps naar de tijdzone die ProcessMind vereist. Leg vast of de bron-timestamps in UTC, lokale systeemtijd of een andere geconfigureerde tijdzone zijn opgeslagen.
a Voorbeeldquery sql
WITH
billing_headers AS (
SELECT
h.VBELN AS InvoiceNumber,
h.FKDAT AS InvoiceDate,
h.NETWR AS InvoiceAmount,
h.KUNAG AS CustomerNumber,
h.ERDAT AS BillingCreatedDate,
h.ERZET AS BillingCreatedTime,
h.ERNAM AS BillingCreatedBy,
h.BUKRS AS CompanyCode,
h.FKART AS BillingType,
h.FKSTO AS CancellationIndicator,
h.RFBSK AS AccountingPostingStatus,
h.ZTERM AS PaymentTerms,
h.ZFBDT AS BaselineDate,
h.NETDT AS PaymentDueDate,
h.VBELV AS PrecedingDocument
FROM [Your HANA schema].VBRK h
WHERE h.ERDAT >= '[Start date, YYYY-MM-DD]'
AND h.ERDAT < '[End date, YYYY-MM-DD]'
AND h.BUKRS IN ([Company code filter])
AND h.FKART IN ([Billing document type filter])
),
customer_data AS (
SELECT
c.KUNNR AS CustomerNumber,
c.NAME1 AS CustomerName,
c.REGION AS Region
FROM [Your customer master source] c
),
invoice_base AS (
SELECT
b.InvoiceNumber,
b.InvoiceDate,
b.InvoiceAmount,
b.CustomerNumber,
c.CustomerName,
c.Region,
b.BillingCreatedDate,
b.BillingCreatedTime,
b.BillingCreatedBy,
b.CompanyCode,
b.BillingType,
b.CancellationIndicator,
b.AccountingPostingStatus,
b.PaymentTerms,
b.BaselineDate,
b.PaymentDueDate,
b.PrecedingDocument
FROM billing_headers b
LEFT JOIN customer_data c
ON c.CustomerNumber = b.CustomerNumber
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Generated' AS ActivityName,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EventTime,
i.BillingCreatedBy AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EndTime
FROM invoice_base i
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posting blocked status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
a.StatusTimestamp AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
a.StatusTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posted status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
o.SentTimestamp AS EventTime,
o.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
o.SentTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your output management source] o
ON o.InvoiceNumber = i.InvoiceNumber
AND o.OutputStatus = '[Successfully sent status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM invoice_base i
WHERE i.PaymentDueDate IS NOT NULL
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
d.OpenedTimestamp AS EventTime,
d.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
d.OpenedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dispute management source] d
ON d.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
r.IssuedTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.IssuedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dunning or payment reminder source] r
ON r.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Payment Received' AS ActivityName,
p.ReceivedTimestamp AS EventTime,
p.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
p.ReceivedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your incoming payment source] p
ON p.CustomerNumber = i.CustomerNumber
AND p.CompanyCode = i.CompanyCode
AND p.ReceivedTimestamp >= TO_TIMESTAMP(TO_VARCHAR(i.InvoiceDate))
UNION ALL
SELECT
i.InvoiceNumber,
'Cash Applied/Reconciled' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Closed' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
x.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
LEFT JOIN [Your billing cancellation or document flow source] x
ON x.InvoiceNumber = i.InvoiceNumber
WHERE i.CancellationIndicator = '[Cancellation indicator value]'
OR x.InvoiceNumber IS NOT NULL
UNION ALL
SELECT
cm.ReferenceInvoiceNumber AS InvoiceNumber,
'Credit Memo Created' AS ActivityName,
cm.CreatedTimestamp AS EventTime,
cm.UserName,
i.InvoiceDate,
i.PaymentDueDate,
cm.Amount AS InvoiceAmount,
i.CustomerName,
i.Region,
cm.CreatedTimestamp AS EndTime
FROM [Your credit memo source] cm
INNER JOIN invoice_base i
ON i.InvoiceNumber = cm.ReferenceInvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
r.ReworkTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.ReworkTimestamp AS EndTime
FROM invoice_base i
INNER JOIN (
SELECT
old_invoice.InvoiceNumber,
new_invoice.InvoiceNumber AS ReplacementInvoiceNumber,
new_invoice.BillingCreatedDate AS ReworkTimestamp,
new_invoice.BillingCreatedBy AS UserName
FROM invoice_base old_invoice
INNER JOIN invoice_base new_invoice
ON new_invoice.PrecedingDocument = old_invoice.InvoiceNumber
AND new_invoice.BillingCreatedDate > old_invoice.BillingCreatedDate
WHERE old_invoice.CancellationIndicator = '[Cancellation indicator value]'
) r
ON r.InvoiceNumber = i.InvoiceNumber
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
InvoiceDate,
PaymentDueDate,
InvoiceAmount,
CustomerName,
Region,
EndTime
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; Klaar om aan de slag te gaan?
Gebruik deze template om je datavoorbereiding te versnellen en je Order to Cash-proces voor facturatie en facturering te optimaliseren. Zet je SAP S/4H4ANA-data vandaag nog om in bruikbare inzichten.
Optimaliseer Order to Cash-facturatie voor 30% snellere cashflow
Maak inefficiënties kleiner en verkort je facturatiecyclus vandaag nog met 30%.
Je hebt geen creditcard nodig. Je kunt binnen enkele minuten aan de slag.