Datatemplate voor Order-to-Cash, facturering en factuurverwerking
Datatemplate voor Order-to-Cash, facturering en factuurverwerking
- Aanbevolen attributen om te verzamelen
- Belangrijke activiteiten om te volgen
- Extractiehandleiding voor SAP S/4HANA
Attributen voor Order-to-Cash, facturering en factuurverwerking
| Naam | Beschrijving | ||
|---|---|---|---|
| Factuurnummer InvoiceNumber | De unieke identificatiecode van een facturatiedocument. Deze dient als de belangrijkste case-ID voor het facturatieproces. | ||
| Beschrijving Het factuurnummer, in SAP bekend als het nummer van het facturatiedocument, identificeert elke factureringstransactie uniek. Het vormt de centrale sleutel die alle bijbehorende activiteiten koppelt, van het aanmaken en boeken van de factuur tot het ontvangen en afstemmen van de betaling. Bij process mining is dit attribuut essentieel om events aan cases te koppelen. Alle events met hetzelfde factuurnummer worden samengevoegd in één procesinstantie. Zo kun je het facturatieproces voor elke afzonderlijke factuur van begin tot eind analyseren. Je kunt doorlooptijden volgen, afwijkingen opsporen en het verloop van elke factuur analyseren. Waarom dit belangrijk is Dit is de unieke identificatiecode die alle bijbehorende facturatieactiviteiten aan één case koppelt. Zo wordt analyse van het volledige proces mogelijk. Waar vind je dit? SAP-tabel: VBRK, veld: VBELN Voorbeelden 900012349000567890009012 | |||
| Activiteitsnaam ActivityName | De naam van de bedrijfsactiviteit of het event in het facturatieproces, zoals 'Factuur aangemaakt' of 'Betaling ontvangen'. | ||
| Beschrijving De activiteitsnaam beschrijft een specifieke stap of mijlpaal in het facturatieproces. De activiteiten worden afgeleid van verschillende gegevens in SAP, zoals transactiecodes, wijzigingen in documentstatus of specifieke logboekregels. Samen vormen ze een opeenvolgend procesverloop. De volgorde en frequentie van deze activiteiten vormen de basis van process mining. Je kunt het proces visualiseren, veelvoorkomende en zeldzame procesvarianten ontdekken, bottlenecks tussen stappen opsporen en meten hoe vaak activiteiten zonder toegevoegde waarde voorkomen, zoals herstelwerk of annuleringen. Waarom dit belangrijk is Dit attribuut beschrijft de processtappen en maakt het mogelijk procesmodellen te visualiseren en het procesverloop, de varianten en bottlenecks te analyseren. Waar vind je dit? Afgeleid van verschillende bronnen, waaronder transactiecodes (SY-TCODE), statussen in wijzigingsdocumenten (tabellen CDHDR/CDPOS) of bedrijfsworkflowlogs (bijvoorbeeld SWW_WI2OBJ). Voorbeelden Factuur aangemaaktFactuur geboekt in de financiële administratieBetaling van klant ontvangenFactuur geannuleerd | |||
| Eventtijd EventTime | De exacte timestamp waarop een activiteit of event plaatsvond. | ||
| Beschrijving De eventtijd bevat voor elke activiteit de datum en tijd en vormt zo de chronologische basis van het proces. Deze timestamp is belangrijk voor het berekenen van duur, doorlooptijden en wachttijden tussen de verschillende stappen in het facturatieproces. Bij analyses wordt de eventtijd gebruikt om activiteiten op volgorde te zetten, belangrijke prestatie-indicatoren te berekenen, zoals Days Sales Outstanding en de doorlooptijd voor het genereren van facturen, en tijdsgebonden bottlenecks op te sporen. Zo zie je hoe de prestaties in de loop van de tijd veranderen en hoelang elke fase van de facturatiecyclus duurt. Waarom dit belangrijk is De eventtijd bepaalt de chronologische volgorde van events. Dat is nodig om tijdsgebonden metrieken, zoals doorlooptijden en duur, te berekenen. Waar vind je dit? Afkomstig van verschillende datum- en tijdvelden, afhankelijk van de activiteit. Voorbeelden zijn de aanmaakdatum en -tijd (VBRK-ERDAT, VBRK-ERZET), wijzigingstimestamps (CDHDR-UDATE, CDHDR-UTIME) en de boekingsdatum (BKPF-BUDAT). Voorbeelden 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| Eindtijd EndTime | De exacte timestamp waarop een activiteit of gebeurtenis is afgerond. | ||
| Beschrijving De eindtijd geeft aan wanneer een activiteit is afgerond. Bij process mining wordt deze vaak afgeleid van de starttijd van de volgende activiteit in de case. Je kunt de eindtijd ook rechtstreeks uit de bron halen als het systeem zowel start- als eindgebeurtenissen registreert. Met dit attribuut bereken je de verwerkingstijd van afzonderlijke activiteiten. Trek de starttijd af van de eindtijd om de duur van elke stap te meten. Dat is belangrijk voor bottleneckanalyse, bijvoorbeeld om vertragingen bij de goedkeuring van facturen op te sporen. Waarom dit belangrijk is Hiermee bereken je de exacte duur (verwerkingstijd) van elke activiteit, wat essentieel is voor bottleneckanalyse. Waar vind je dit? Dit is een afgeleid attribuut voor process mining. Meestal wordt het berekend als de StartTime van de volgende gebeurtenis in de case. In sommige situaties registreren specifieke tabellen de eindtijden. 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 geeft de totale geldwaarde weer van de goederen of diensten op de factuur, exclusief belastingen. Het is een belangrijk financieel gegeven voor elke factuurcase. Je kunt het factuurbedrag voor allerlei analyses gebruiken. Zo kun je het proces indelen op basis van de waarde en nagaan of facturen met een hoog bedrag anders worden verwerkt of vaker vertraging oplopen. Het bedrag vormt ook de basis voor financiële rapportages en voor het berekenen van de totale waarde van openstaande vorderingen. Waarom dit belangrijk is Het geeft de financiële waarde van elke factuur weer. Zo kun je op waarde analyseren, bepalen welke betalingen prioriteit hebben en de financiële impact inschatten. Waar vind je dit? SAP-tabel: VBRK, veld: NETWR Voorbeelden 1500.0025000.50125.75 | |||
| Factuurdatum InvoiceDate | De officiële datum waarop de factuur aan de klant is verstrekt. | ||
| Beschrijving De factuurdatum, in SAP ook wel de factureringsdatum genoemd, is het uitgangspunt voor veel financiële berekeningen. Op basis van deze datum worden de betalingsvoorwaarden, vervaldatum en ouderdom van de openstaande 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 zijn belangrijk voor het beheer van de cashflow en het innen van betalingen. Waarom dit belangrijk is Dit is de belangrijkste datum voor financiële berekeningen en vormt het uitgangspunt voor DSO, vervaldata en de analyse van de ouderdom van facturen. Waar vind je dit? 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 van degene die verantwoordelijk is voor een event, zoals het aanmaken van een factuur, het boeken van een document of het afletteren van een betaling. Zo worden processtappen gekoppeld aan de personen of teams die ze uitvoeren. Door op gebruikersnaam te analyseren, kun je zien wie goed presteert, waar training nodig is en of het werk gelijkmatig is verdeeld. Dit is ook belangrijk voor complianceanalyse: je ziet wie belangrijke activiteiten heeft uitgevoerd en hoe verschillende gebruikers hetzelfde proces uitvoeren. Waarom dit belangrijk is Het koppelt procesactiviteiten aan specifieke gebruikers. Zo kun je de werkverdeling, prestaties en compliance per persoon of team analyseren. Waar vind je dit? Bij aanmaakactiviteiten staat de gebruikersnaam in VBRK-ERNAM. Bij latere wijzigingen vind je die in wijzigingshistorietabellen, zoals CDHDR-USERNAME, of in workflowlogs. Voorbeelden CBURNSHSIMPSONLLEONARD | |||
| Klantnaam CustomerName | De naam van de klant aan wie de factuur is verstrekt. | ||
| Beschrijving Dit attribuut bevat de officiële naam van de klant aan wie de factuur is gericht. De naam komt uit de centrale klantstamgegevens in SAP. Door het proces per klant te analyseren, kun je patronen bij specifieke accounts herkennen. Zo zie je welke klanten vaak te laat betalen, de meeste geschillen indienen of met de meeste vertraging in het facturatieproces te maken hebben. Daarmee kun je het klantbeheer en de aanpak voor het innen van betalingen beter afstemmen. Waarom dit belangrijk is Je kunt per klant betaalgedrag, het aantal geschillen en inefficiënties in het proces analyseren. Waar vind je dit? Afkomstig uit de klantstamgegevenstabel KNA1 (veld: NAME1), gekoppeld via de betaler-ID in de kopgegevens van de factuur (VBRK-KUNRG). Voorbeelden Springfield Power PlantKwik-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 staat doorgaans in de klantstamgegevens. Dit attribuut is belangrijk voor het dashboard met facturatieprestaties per regio. Je kunt er belangrijke metrieken mee vergelijken, zoals doorlooptijden, foutpercentages en DSO. Zo worden regionale verschillen in de uitvoering, compliance of efficiëntie zichtbaar en kun je verbeteringen gericht doorvoeren en goede werkwijzen standaardiseren. Waarom dit belangrijk is Je kunt de facturatieprestaties tussen regio’s vergelijken, regionale verschillen opsporen en processen standaardiseren. Waar vind je dit? Afkomstig uit de klantstamgegevenstabel KNA1 (veld: REGIO), gekoppeld via de betaler-ID in de kopgegevens van de factuur (VBRK-KUNRG). Voorbeelden CANYTXBA | |||
| Vervaldatum betaling PaymentDueDate | De datum waarop de klant de factuur naar verwachting moet betalen. | ||
| Beschrijving De vervaldatum van de betaling wordt berekend op basis van de factuurdatum en de afgesproken betalingsvoorwaarden. Dit is de uiterste datum waarop de betaling moet zijn ontvangen om te voorkomen dat de factuur achterstallig wordt. Dit attribuut is belangrijk om de effectiviteit van het innen van betalingen te volgen en de cashflow te voorspellen. Het wordt gebruikt bij het berekenen van de KPI voor tijdige betalingen en om facturen in ouderdomsrapportages in te delen. Door de vervaldatum met de werkelijke betaaldatum te vergelijken, kun je beoordelen hoe goed verschillende betalingsvoorwaarden werken. Waarom dit belangrijk is Deze datum bepaalt wanneer de klant uiterlijk moet betalen. Je hebt hem nodig om het percentage tijdige betalingen te berekenen en openstaande vorderingen te beheren. Waar vind je dit? Deze datum wordt niet rechtstreeks opgeslagen, maar berekend op basis van de factuurdatum (VBRK-FKDAT) en de sleutel voor betalingsvoorwaarden (VBRK-ZTERM), met de standaardfuncties van SAP voor datumbepaling. Voorbeelden 2023-04-192023-05-012023-06-17 | |||
| Bedrijfscode CompanyCode | De organisatorische eenheid waarvoor de financiële transactie wordt geregistreerd. | ||
| Beschrijving De bedrijfscode is een belangrijke organisatorische eenheid in SAP Financials. Deze staat voor een juridisch zelfstandig bedrijf waarvoor financiële overzichten worden opgesteld. Elk factuurdocument is aan een specifieke bedrijfscode gekoppeld. In organisaties met meerdere bedrijven is analyse per bedrijfscode essentieel. Je kunt zo de procesprestaties, financiële kengetallen zoals DSO en compliance tussen juridische entiteiten vergelijken. De bedrijfscode biedt een filter op organisatieniveau voor alle procesdashboards. Waarom dit belangrijk is Hiermee kun je processen per juridische entiteit analyseren en prestaties vergelijken en financiële gegevens binnen de organisatie consolideren. Waar vind je dit? SAP-tabel: VBRK, veld: BUKRS Voorbeelden 10002000US01 | |||
| Betalingsstatus PaymentStatus | De huidige status van de factuurbetaling, bijvoorbeeld Open, Betaald of Achterstallig. | ||
| Beschrijving De betalingsstatus laat zien waar een factuur zich bevindt in het incassoproces. In SAP staat deze status niet in één veld. Je leidt de status af door de vereffeningsstatus van het bijbehorende boekhoudkundige document te controleren. Dit attribuut is essentieel voor het dashboard met openstaande facturen naar ouderdom. Je kunt alle openstaande facturen indelen op status en ouderdom, zodat het incassoteam het werk goed kan prioriteren. Ook kun je de overgangen tussen statussen volgen om het incassoproces zelf te bewaken. Waarom dit belangrijk is Dit geeft in één oogopslag de incassostatus van een factuur weer. Zo kun je openstaande vorderingen beheren en incassoacties prioriteren. Waar vind je dit? Afgeleid door de vereffeningsstatus van het boekhoudkundige document (VBRK-BELNR) te controleren in financiële tabellen zoals BSID (open posten) en BSAD (vereffende posten). Voorbeelden OpenBetaaldAchterstalligGedeeltelijk betaald | |||
| Betalingsvoorwaarden PaymentTerms | De code met de afgesproken betalingsvoorwaarden, zoals de betalingstermijn. | ||
| Beschrijving Betalingsvoorwaarden zijn vooraf vastgelegde afspraken met een klant over wanneer een factuur betaald moet zijn. Voorbeelden zijn ‘Netto 30’ (betaling binnen 30 dagen) en ‘2/10 Netto 30’ (2% korting bij betaling binnen 10 dagen, anders betaling binnen 30 dagen). Door de betalingsvoorwaarden te analyseren, zie je hoe goed ze werken. Vergelijk de verschillende voorwaarden met de werkelijke tijd die nodig is om betalingen te ontvangen. Zo ontdek je welke afspraken klanten het meest stimuleren om op tijd te betalen en kun je de voorwaarden aanpassen om de cashflow te verbeteren. Waarom dit belangrijk is Dit legt het afgesproken betalingsschema vast. Zo kun je analyseren welke voorwaarden klanten het meest helpen om op tijd te betalen. Waar vind je dit? SAP-tabel: VBRK, veld: ZTERM Voorbeelden Z030Z060ZB60 | |||
| Bronsysteem SourceSystem | Identificeert het specifieke bronsysteem waaruit de data is geëxtraheerd. | ||
| Beschrijving Dit attribuut geeft aan waar de data vandaan komt. Dat is vooral handig in omgevingen met meerdere SAP-instanties of andere gekoppelde systemen. Meestal bevat het de systeem-ID en het clientnummer. Bij analyses helpt dit attribuut om processen en prestaties tussen systemen of organisatieonderdelen te vergelijken. Het maakt de herkomst van de data traceerbaar en geeft context, vooral wanneer data uit meerdere bronnen wordt gecombineerd voor een volledig procesbeeld. Waarom dit belangrijk is Het geeft belangrijke context over de herkomst van de data, zorgt voor duidelijkheid in omgevingen met meerdere systemen en ondersteunt datagovernance. Waar vind je dit? Dit is meestal een vaste waarde die tijdens de data-extractie wordt bepaald. Vaak bestaat de waarde uit de systeem-ID (SY-SYSID) en client (SY-MANDT). Voorbeelden S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| Factuurdocumenttype BillingDocumentType | Een code die het factuurdocument indeelt, bijvoorbeeld als factuur, creditnota of annulering. | ||
| Beschrijving Het factuurdocumenttype is een belangrijk veld dat transacties in het factureringsproces indeelt. Het bepaalt hoe het document wordt verwerkt, waaronder het nummerbereik en de boekingsregels. 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 processtappen van financiële correcties te onderzoeken. Ook kun je standaardfacturen apart van annuleringen analyseren voor een duidelijker beeld van het gewone factureringsproces. Waarom dit belangrijk is Dit deelt transacties in, zodat je specifieke documentstromen kunt analyseren, zoals standaardfacturen, creditnota’s of annuleringen. Waar vind je dit? SAP-tabel: VBRK, veld: FKART Voorbeelden F2G2S1L2 | |||
| Laatste data-update LastDataUpdate | De timestamp die aangeeft wanneer de data voor dit event voor het laatst is geëxtraheerd of vernieuwd. | ||
| Beschrijving Dit attribuut registreert de datum en tijd waarop de data voor het laatst uit het bronsysteem is opgehaald. Het is een metadataveld dat aangeeft hoe actueel de geanalyseerde data is. Je kunt deze informatie gebruiken om te controleren hoe recent de analyse is en om geplande data-updates te beheren. Zo weten betrokkenen hoe actueel de data is wanneer ze beslissingen nemen op basis van process mining-dashboards en -inzichten. Waarom dit belangrijk is Dit geeft aan hoe actueel de data is. Dat is belangrijk om de analyse goed te kunnen beoordelen en te begrijpen hoe relevant die is voor de huidige bedrijfsvoering. Waar vind je dit? Deze timestamp wordt tijdens het data-extractie- en laadproces (ETL) gegenereerd en aan elke record toegevoegd. Voorbeelden 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| Op tijd betaald IsPaidOnTime | Een booleaanse aanduiding die aangeeft of de factuur op of vóór de vervaldatum is betaald. | ||
| Beschrijving Dit berekende attribuut vergelijkt de werkelijke betaaldatum met de geplande vervaldatum. De waarde is ‘true’ als de betaling op tijd is gedaan en ‘false’ als deze te laat is. Met deze aanduiding bereken en visualiseer je eenvoudig de KPI voor het percentage betalingen op tijd. Je kunt facturen makkelijk filteren en indelen om te vergelijken welke kenmerken voorkomen bij facturen die op tijd of te laat worden betaald. Zo ontdek je patronen rond bepaalde klanten, regio’s of betalingsvoorwaarden die tot late betalingen leiden. Waarom dit belangrijk is Dit maakt prestatiemeting eenvoudiger: elke factuur krijgt duidelijk de aanduiding ‘op tijd’ of ‘te laat’. Daarmee ondersteunt het rechtstreeks de KPI voor het percentage betalingen op tijd. Waar vind je dit? Dit is een berekend veld. De logica vergelijkt de timestamp van de activiteit ‘Klantbetaling ontvangen’ met de waarde van het attribuut ‘PaymentDueDate’. Voorbeelden truefalse | |||
| Reden creditnota CreditMemoReason | De redenencode die aangeeft waarom een creditnota is uitgegeven. | ||
| Beschrijving Wanneer een factuur niet klopt en gecrediteerd moet worden, krijgt het creditnotadocument meestal een reden. Zo kun je de oorzaken van factureringsfouten op een vaste manier indelen. Dit attribuut ondersteunt rechtstreeks de KPI voor het percentage factureringsfouten. Door de redenen voor creditnota’s te verzamelen en te analyseren, ontdek je welke fouten het vaakst voorkomen, zoals prijsfouten of productretouren. Met die analyse kun je processen verbeteren en financiële correcties en herstelwerk beperken. Waarom dit belangrijk is Dit deelt de redenen voor creditering in. Zo zie je welke factureringsfouten het vaakst voorkomen en waar kwaliteitsverbeteringen nodig zijn. Waar vind je dit? SAP-tabel: VBRK, veld: AUGRU (orderreden). Dit veld wordt gebruikt voor verzoeken om credit- of debetnota’s die vervolgens worden gefactureerd. Voorbeelden 001 - Prijsverschil002 - Slechte kwaliteit005 - Retour van klant | |||
| Reden van betwisting CustomerDisputeReason | De reden die een klant opgeeft om een factuur te betwisten. | ||
| Beschrijving Wanneer een klant een factuur betwist, wordt de reden vaak vastgelegd. Het kan bijvoorbeeld gaan om een prijsfout, een onjuist aantal of beschadigde goederen. Deze informatie kan in de SAP-module Dispute Management staan of als tekstnotitie zijn opgeslagen. Analyse van de redenen voor betwisting is essentieel voor de KPI voor het percentage factureringsfouten en de bijbehorende foutenanalyses. Zo ontdek je de oorzaken van onjuiste facturen en kun je structurele problemen in eerdere processtappen aanpakken. Dat verbetert de factuurkwaliteit en de klanttevredenheid. Waarom dit belangrijk is Dit maakt duidelijk waarom klanten facturen betwisten en geeft rechtstreeks inzicht in de oorzaken van factureringsfouten en ontevredenheid. Waar vind je dit? Als SAP Dispute Management wordt gebruikt, vind je deze informatie in tabellen zoals UDM_DISPUTE. Anders kun je de informatie afleiden uit redenencodes op gerelateerde documenten of uit tekstvelden. Voorbeelden Onjuiste prijsOnjuist aantalBeschadigde goederen ontvangen | |||
| Valuta Currency | De valutacode van het factuurbedrag. | ||
| Beschrijving Dit attribuut geeft aan in welke valuta de factuurbedragen zijn uitgedrukt, bijvoorbeeld USD, EUR of JPY. Zo is duidelijk hoe de geldbedragen moeten worden geïnterpreteerd. Voor een internationale organisatie is valuta nodig voor correcte financiële analyses en rapportages. Je kunt bedragen omrekenen naar één rapportagevaluta en de facturatieprestaties vergelijken tussen regio’s met verschillende lokale valuta. Waarom dit belangrijk is Het geeft context aan alle geldbedragen en helpt financiële analyses en rapportages nauwkeurig te houden, vooral bij bedrijfsvoering in meerdere landen. Waar vind je dit? 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 factuurdocument aan de eerdere verkoopactiviteiten. Eén verkooporder kan tot een of meer facturen leiden. Dankzij deze koppeling zie je de volledige documentstroom. Dit attribuut is essentieel voor een volledige Order-to-Cash-analyse van begin tot eind. Je kunt de procesweergave uitbreiden naar eerdere stappen en factureringsproblemen koppelen aan mogelijke oorzaken bij het aanmaken of afhandelen van de verkooporder. Zo kun je bijvoorbeeld de totale doorlooptijd voor het genereren van de factuur berekenen vanaf het moment dat de order is afgehandeld. Waarom dit belangrijk is Dit koppelt de factuur aan de oorspronkelijke verkooporder. Zo krijg je een breder beeld van het Order-to-Cash-proces, ook van de stappen vóór de facturering. Waar vind je dit? SAP-tabel: VBRP (gegevens van factuurdocumentregels), veld: AUBEL Voorbeelden 100001231000045610000789 | |||
Activiteiten voor Order-to-Cash, facturering en factuurverwerking
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Betaling afgeletterd | Dit is het moment waarop de binnenkomende klantbetaling wordt gekoppeld aan de openstaande factuur en deze afboekt in de subadministratie debiteuren. Vanuit financieel oogpunt is de transactie hiermee afgerond. | ||
| Waarom dit belangrijk is Meet hoe efficiënt binnenkomende betalingen worden verwerkt. Vertragingen kunnen een onjuist beeld geven van de klantrekeningen en onnodig werk opleveren voor het incassoteam. Waar vind je dit? Dit event wordt vastgelegd aan de hand van de afletterdatum (BSEG-AUGDT) op de regel van het boekhoudkundige document van de oorspronkelijke factuur. Deze datum wordt ingevuld wanneer een afletterdocument de post afboekt. Vastleggen Afkomstig van het veld voor de afletterdatum (AUGDT) in tabel BSEG/ACDOCA voor de factuurregel. Gebeurtenistype explicit | |||
| Betaling van klant ontvangen | Deze activiteit markeert de boeking 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 Een belangrijke mijlpaal voor het berekenen van Days Sales Outstanding (DSO). Het geld is ontvangen, ook als de afstemming nog moet plaatsvinden. Waar vind je dit? Afkomstig van de boekingsdatum (BKPF-BUDAT) van het betalingsdocument van de klant, meestal documenttype 'DZ' in tabel BKPF. Vastleggen Het event is gebaseerd op het aanmaken van het betalingsdocument in BKPF/BSEG. Gebeurtenistype explicit | |||
| Factuur aangemaakt | Deze activiteit markeert het moment waarop het facturatiedocument in het systeem wordt aangemaakt. Dit expliciete event wordt vastgelegd wanneer een gebruiker bijvoorbeeld transactie VF01 uitvoert of wanneer een achtergrondtaak de factuur aanmaakt. Daardoor ontstaat een nieuwe regel in de kopgegevenstabel van het facturatiedocument. | ||
| Waarom dit belangrijk is Dit is het belangrijkste startevent van het facturatieproces. Door de tijd tussen het afhandelen van de order en deze activiteit te analyseren, kun je de doorlooptijd voor het genereren van facturen meten en vertragingen aan het begin van het proces opsporen. Waar vind je dit? Wordt bij het aanmaken vastgelegd in de SAP S/4HANA-tabel VBRK (facturatiedocument: kopgegevens). De aanmaakdatum (VBRK-ERDAT) en -tijd (VBRK-ERZET) vormen de timestamp. Vastleggen Het event wordt afgeleid van de timestamp waarop het facturatiedocument in tabel VBRK is aangemaakt. Gebeurtenistype explicit | |||
| Factuur afgesloten | Deze activiteit geeft aan dat een factuur volledig is betaald. Functioneel is dit hetzelfde als 'Betaling afgeletterd' en betekent het dat het proces voor deze factuur is afgerond. | ||
| Waarom dit belangrijk is Dit is het belangrijkste eindevent van de ideale route. Door de totale doorlooptijd tot dit punt te meten, krijg je een volledig beeld van het facturatieproces van begin tot eind. Waar vind je dit? Afgeleid van de status van de debiteurenregel in het boekhoudkundige document. Een post is afgesloten of 'afgeletterd' wanneer de velden voor de afletterdatum (BSEG-AUGDT) en het afletterdocument (BSEG-AUGBL) zijn ingevuld. Vastleggen Afgeleid van de ingevulde afletterdatum (AUGDT) in tabel BSEG/ACDOCA voor de factuurregel. Gebeurtenistype inferred | |||
| Factuur geboekt in de financiële administratie | Dit staat voor de succesvolle boeking van het facturatiedocument in de financiële administratie. Het is een belangrijke mijlpaal: de factuur wordt een officiële post op de debiteurenrekening en er worden boekingen in het grootboek aangemaakt. | ||
| Waarom dit belangrijk is Deze activiteit bevestigt dat de factuur een officieel financieel document is. De tijd tussen het aanmaken en boeken is een belangrijke prestatiemaatstaf voor de efficiëntie van de interne verwerking. Waar vind je dit? Dit event 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 staat in BKPF-BUDAT. Vastleggen Afkomstig van de boekingsdatum (BUDAT) in tabel BKPF van het boekhoudkundige document dat aan het facturatiedocument is gekoppeld. Gebeurtenistype explicit | |||
| Betalingsherinnering verstuurd | Dit staat voor het versturen van een betalingsherinnering of aanmaning voor een achterstallige factuur. Het is een expliciet event dat wordt aangemaakt door de geautomatiseerde aanmaningsprocedure. | ||
| 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 vind je dit? Wordt vastgelegd in de aanmaningshistorietabellen (MAHNV, MHND) wanneer de aanmaningsrun (transactie F150) wordt uitgevoerd voor de openstaande post van de factuur. Vastleggen Afkomstig van de uitvoerdatum van de aanmaning in de aanmaningshistorietabellen. Gebeurtenistype explicit | |||
| Creditnota aangemaakt | Deze activiteit staat voor het aanmaken van een creditnota. Die wordt aan een klant verstrekt om een te hoog bedrag te corrigeren of om een tegoed te geven voor geretourneerde goederen. Vaak is de creditnota gekoppeld aan een oorspronkelijke factuur. | ||
| Waarom dit belangrijk is Maakt financiële correcties na de facturatie zichtbaar. Door creditnota’s te analyseren, kun je prijsfouten, productproblemen en andere oorzaken van omzetverlies opsporen. Waar vind je dit? Wordt expliciet aangemaakt als nieuw facturatiedocument in VBRK, met een specifiek factureringstype voor creditnota’s, bijvoorbeeld 'G2'. Vaak verwijst het naar de oorspronkelijke verkooporder of factuur. Vastleggen Afkomstig van de aanmaak in VBRK van een facturatiedocument met een factureringstype voor creditnota’s. Gebeurtenistype explicit | |||
| Factuur geannuleerd | Dit gebeurt wanneer een eerder aangemaakte factuur wordt geannuleerd. Meestal wordt daarvoor een bijbehorend annuleringsdocument aangemaakt. Daarmee worden de oorspronkelijke factuur en de financiële gevolgen ervan teruggedraaid. | ||
| Waarom dit belangrijk is Wijst op herstelwerk, correcties of facturatiefouten. Veel annuleringen duiden op problemen eerder in het proces, bijvoorbeeld bij het invoeren van verkooporders of de configuratie van de facturatie. Waar vind je dit? Wordt vastgelegd wanneer een annuleringsdocument voor de facturatie wordt aangemaakt, bijvoorbeeld met documenttype 'S1'. Dit nieuwe document in VBRK verwijst naar het oorspronkelijke factuurnummer in het veld VBRK-SFAKN. Vastleggen Het event wordt afgeleid van de aanmaakdatum in VBRK van het annuleringsdocument dat naar de oorspronkelijke factuur verwijst. Gebeurtenistype explicit | |||
| Factuur geblokkeerd voor boeking | Dit event treedt op wanneer een factuur is aangemaakt, maar automatisch wordt geblokkeerd voor boeking in de financiële administratie. Dat kan bijvoorbeeld komen door een kredietcontrole of inconsistente data. De status wordt afgeleid van het boekingsstatusveld van het facturatiedocument. | ||
| Waarom dit belangrijk is Maakt bottlenecks zichtbaar waarbij facturen wel zijn aangemaakt, maar niet meteen worden vrijgegeven voor de financiële administratie. Daardoor loopt de hele cyclus voor het innen van betalingen vertraging op. Dit kan wijzen op problemen met de datakwaliteit of het kredietbeheer. Waar vind je dit? Afgeleid van het boekingsstatusveld in de kopgegevenstabel van het facturatiedocument (VBRK-RFBSK). Een status zoals 'A' (facturatiedocument geblokkeerd voor doorboeking naar FI) wijst op een blokkade. Vastleggen Afgeleid door de waarde van het boekingsstatusveld (VBRK-RFBSK) direct na het aanmaken van de factuur te controleren. Gebeurtenistype inferred | |||
| 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 voor uitvoerbeheer in SAP. | ||
| Waarom dit belangrijk is Voor de klant begint hiermee officieel de betalingstermijn. Vertraging bij het verzenden van de factuur heeft direct invloed op Days Sales Outstanding (DSO) en de cashflow. Waar vind je dit? Kan expliciet worden vastgelegd in de tabellen voor uitvoerbeheer, zoals NAST voor oudere methoden of het equivalent daarvan in S/4HANA. Als het event niet expliciet wordt vastgelegd, wordt vaak aangenomen dat het tegelijk plaatsvindt met 'Factuur geboekt in de financiële administratie'. Vastleggen Controleer de verwerkingslogs in de tabellen voor uitvoerbeheer op een timestamp die bij het uitvoertype van de factuur hoort. Gebeurtenistype explicit | |||
| Herstelwerk bij facturatie vastgesteld | Een berekend event dat een herstelcyclus aangeeft: een factuur is geannuleerd en daarna is voor dezelfde verkooporder een nieuwe aangemaakt. Het gaat niet om één transactie, maar om een patroon van events. | ||
| Waarom dit belangrijk is Ondersteunt rechtstreeks de KPI voor herstelwerk bij facturatie door correcties te tellen. Zo kun je inefficiënties opsporen en de kosten van gebrekkige kwaliteit in het facturatieproces meten. Waar vind je dit? Dit patroon wordt berekend door een event 'Factuur geannuleerd' te zoeken, gevolgd door een nieuw event 'Factuur aangemaakt'. Beide moeten terug te voeren zijn op hetzelfde brondocument, zoals een verkoopordernummer. Vastleggen Afgeleid door voor dezelfde verkooporderverwijzing de opeenvolging van 'Factuur geannuleerd' en 'Factuur aangemaakt' vast te stellen. Gebeurtenistype calculated | |||
| Klantgeschil aangemaakt | Deze activiteit vindt plaats wanneer een klant bezwaar maakt tegen een factuur en dit formeel in het systeem wordt vastgelegd. Hiervoor is de SAP-module Dispute Management nodig. | ||
| Waarom dit belangrijk is Maakt problemen met de facturatie, 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 vind je dit? Wordt vastgelegd wanneer een geschilcase wordt aangemaakt in de tabellen van Dispute Management (bijvoorbeeld UDM_CASE). Deze is gekoppeld aan de regel van het boekhoudkundige document. Vastleggen Afkomstig van de aanmaaktimestamp van de geschilcase die aan de factuur is gekoppeld. Gebeurtenistype explicit | |||
| Vervaldatum van betaling bereikt | Een berekend event dat de datum aangeeft waarop de factuur volgens de afgesproken betalingsvoorwaarden officieel moet zijn betaald. Het is geen transactie-event, maar wordt afgeleid van factuurgegevens. | ||
| Waarom dit belangrijk is Dit is een belangrijke basis voor het meten van tijdige betalingen en het analyseren van betaalgedrag. Zo kun je onderscheid maken tussen tijdige en te late betalingen. Waar vind je dit? Berekend op basis van de basisdatum voor betaling (BSEG-ZFBDT) en de betalingsvoorwaarden die zijn opgeslagen in de debiteurenregel van het boekhoudkundige document. Vastleggen Afgeleid door het aantal dagen van de betalingsvoorwaarde op te tellen bij de basisdatum voor betaling in de regel van het boekhoudkundige document (BSEG). Gebeurtenistype calculated | |||
Extractiegidsen
Stappen
- Vereisten: Zorg dat je een gebruikersaccount in SAP S/4HANA hebt met de juiste autorisaties om Core Data Services (CDS)-views op te vragen. Je hebt in elk geval leestoegang nodig tot views zoals I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase en I_DunningHistory.
- Toegang tot de data-extractietool: Meld je aan bij 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 met de SAP HANA-client of de SAP Analysis for Microsoft Excel-plug-in. In deze gids gaan we uit van een standaard SQL-client.
- Systeemparameters bepalen: Bepaal voordat je de query uitvoert welke Company Codes en welke periode je wilt analyseren. Begin bij voorkeur met een beperkte periode, bijvoorbeeld de afgelopen 3 tot 6 maanden. Zo blijft de uitvoeringstijd van de query beheersbaar.
- De SQL-query voorbereiden: Kopieer de volledige SQL-query uit het gedeelte ‘query’ van dit document naar de SQL-client van je keuze.
- Placeholders aanpassen: Vervang de placeholderwaarden in de query. Vul bij
'YYYY-MM-DD'de gewenste begin- en einddatum in. Vervang'XXXX'door de gewenste Company Code(s). Mogelijk moet je ook de placeholder voor creditnota-documenttypen aanpassen, bijvoorbeeld'G2', afhankelijk van de configuratie van je systeem. - De query uitvoeren: Voer de aangepaste SQL-query uit op de SAP S/4HANA-database. De uitvoeringstijd hangt af van de hoeveelheid data in de gekozen periode.
- De resultaten controleren: Controleer de uitvoer zodra de query klaar is. De resultaten moeten een platte tabel vormen, waarin elke rij één activiteit in het facturatieproces weergeeft. Dit is je event log.
- Data transformeren (indien nodig): De query levert een event log op in een bruikbaar formaat. Controleer wel of de timestamp-indeling geschikt is voor je process mining-tool. De query gebruikt
ABAP_SYSTEM_UTCL_TO_TIMESTAMPom timestamps om te zetten naar een standaard UTC-timestamp. Die indeling is met de meeste tools compatibel. - Het event log exporteren: Exporteer alle resultaten vanuit je SQL-client naar een CSV-bestand. Sla het bestand op in UTF-8 om problemen met tekens te voorkomen.
- Uploaden naar ProcessMind: Upload het CSV-bestand naar ProcessMind en koppel de kolommen uit het bestand, zoals InvoiceNumber, ActivityName en EventTime, aan de bijbehorende velden in de tool.
Configuratie
- Datumbereik: Stel de begin- en einddatum in de
WHERE-clause van de eerste Common Table Expression (CTE) in. Voor een eerste analyse is een periode van 3 tot 6 maanden aan te raden. Zo houd je de hoeveelheid data en de prestaties in balans. Het filter wordt toegepast opBillingDocumentDate. - Company Code: Filter op een of meer waarden van
CompanyCodeom alleen relevante juridische entiteiten mee te nemen. Dit filter is belangrijk om de omvang van de data te beperken. - Documenttypen: De query bevat logica om creditnota’s te herkennen op basis van
BillingDocumentType. Stel de placeholder, bijvoorbeeld('G2', 'CR'), in op de documenttypen die je organisatie voor creditnota’s gebruikt. - Vereisten: Toegang tot de onderliggende CDS-views is verplicht. Hiervoor moet het SAP-beveiligingsteam de juiste rollen en autorisaties toewijzen. Voor activiteiten zoals ‘Klantgeschil geopend’ of ‘Betalingsherinnering verstuurd’ moeten ook de bijbehorende SAP-modules, SAP Dispute Management en SAP Financials Dunning, actief in gebruik zijn.
- Prestaties: De query gebruikt meerdere joins en unions. Bij zeer grote datasets, bijvoorbeeld data over meerdere jaren, kun je de query buiten piekuren uitvoeren of strengere filters toepassen om de eerste data-extractie te beperken.
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 bijbehorende financiële tabellen. Vraag de schemanaam, verbindingsgegevens, toegestane periode, Company Code-scope, facturatiedocumenttypen en eventuele filters voor klanten of regio’s op bij de systeemeigenaar. Vervang in de query alleen de placeholders voor de verbinding en filters.
- Controleer welke SAP S/4HANA-bronnen en veldkoppelingen in het doelsysteem van toepassing zijn. De query gebruikt VBRK en VBRP voor facturatiegegevens. Daarnaast zijn geconfigureerde bronnen nodig voor boekhouding, outputbeheer, geschillenbeheer, betalingsherinneringen, inkomende betalingen, aflettering en documentrelaties. Vervang placeholders tussen vierkante haken voor bronnen en velden pas nadat je ze hebt gecontroleerd aan de hand van het systeemdatadictionary.
- Stel de extractieperiode in met een inclusieve begintimestamp en een exclusieve eindtimestamp. Voor de eerste uitvoering is een periode van drie tot zes maanden aan te raden. Beperk de extractie op Company Code en, waar nodig, facturatietype. Zo houd je de hoeveelheid data beheersbaar en voorkom je dat niet-gerelateerde facturatieprocessen door elkaar lopen.
- Voer de query uit met een alleen-lezen HANA-databasegebruiker. De query maakt voor elke expliciet geëxtraheerde activiteit één eventrij aan. ProcessMind leidt geen events af. Berekende activiteiten, waaronder Vervaldatum betaling bereikt en Herstelwerk facturatie vastgesteld, worden met SQL-logica aangemaakt en als rijen teruggegeven.
- Controleer het schema van de resultaten. Het event log moet de velden InvoiceNumber, ActivityName, EventTime, UserName, InvoiceDate, PaymentDueDate, InvoiceAmount, CustomerName, Region en EndTime bevatten. Controleer of InvoiceNumber, ActivityName en EventTime voor elke rij zijn ingevuld.
- Controleer de betekenis van de events en de onderlinge relaties. Vergelijk rijen voor Invoice Generated met gegevens over het aanmaken van facturatiekoppen, rijen voor Invoice Posted To Accounting met de boekingsstatus, rijen voor Invoice Sent To Customer met outputrecords, betalingsrijen met boekhoudkundige documenten en afletteringsrijen met afgeletterde factuurposten. Controleer alle onderdelen die afhankelijk zijn van placeholders voordat je de query in productie gebruikt.
- Maak de resultaten geschikt voor ProcessMind. Gebruik één rij per event, een consistent timestampgegevenstype en een vaste tijdzone. Behoud InvoiceNumber als tekst, zodat voorloopnullen niet verloren gaan, en zorg dat de waarden van ActivityName exact overeenkomen met de vereiste activiteitsnamen. Sorteer op InvoiceNumber en EventTime. Gebruik een vaste secundaire sortering als meerdere events dezelfde timestamp hebben.
- Exporteer de resultaten als UTF-8-CSV of in een ander tabelvormig formaat dat ProcessMind ondersteunt. Koppel InvoiceNumber aan de case-ID, ActivityName aan de activiteitskolom en EventTime aan de eventtimestamp. Voeg aanbevolen attributen toe als die beschikbaar zijn. Upload het bestand daarna via het ingestelde importproces van ProcessMind en controleer tot slot het aantal rijen en activiteiten.
Configuratie
- Datumbereik: Begin met drie tot zes maanden. Gebruik een inclusieve begintimestamp en een exclusieve eindtimestamp om dubbele events tussen opeenvolgende extracties te voorkomen.
- Case-ID: Gebruik InvoiceNumber uit de facturatiekop. Bewaar deze waarde 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 de bedrijfscontext in het doelsysteem hebt gecontroleerd. Ga er niet van uit dat elk facturatiedocumenttype hetzelfde boekhoudkundige of outputproces volgt.
- Bronconfiguratie: VBRK en VBRP zijn de primaire facturatiebronnen. Bronnen voor boekhouding, output, geschillen, betalingsherinneringen, betalingen, aflettering en documentstromen moeten worden geconfigureerd op basis van de geïnstalleerde SAP S/4HANA-release en ingeschakelde modules. Vervang verwijzingen tussen vierkante haken door gecontroleerde objecten en velden.
- Berekende events: Payment Due Date Reached wordt afgeleid uit de betalingsvoorwaarden en vervaldatumgegevens. Billing Rework Identified wordt afgeleid uit patronen van annuleringen en daaropvolgende factuuraanmaak. Dit zijn met SQL aangemaakte eventrijen, geen oorspronkelijke transactierecords.
- Prestaties: Pas filters voor datum, Company Code, facturatietype en documentnummer toe in elke bronquery. Selecteer alleen de benodigde kolommen, vermijd onbeperkte joins met grote boekhoudingstabellen en verwerk de periode in maand- of weekbatches. Gebruik uitvoeringsplannen van de database om zware joins op te sporen.
- Incrementele extractie: Gebruik een stabiele watermark op basis van aanmaak- of boekingstimestamps uit de bron. Verwerk een korte overlappende periode opnieuw om laat binnengekomen output-, betalings-, geschillen- en afletteringsrecords mee te nemen. Verwijder daarna duplicaten op basis van InvoiceNumber, ActivityName en EventTime, aangevuld met de relevante brondocumentcode.
- Autorisaties: De extractiegebruiker heeft leestoegang nodig tot de geselecteerde HANA-schemaobjecten en -velden. Controleer of directe databasetoegang is toegestaan volgens het beveiligingsbeleid van je organisatie en of aan de vereisten voor de verwerking van persoonsgegevens en klantgegevens wordt voldaan.
- Functionele vereisten: Gegevens over outputbeheer, boekhoudkundige integratie, geschillenbeheer, betalingsherinneringen, inkomende betalingen en aflettering zijn alleen beschikbaar als deze functies in het systeem zijn geconfigureerd en worden gebruikt. Ontbrekende modules of bronrecords leiden tot ontbrekende activiteiten, niet tot afgeleide events.
- Tijdzone: Zet timestamps om naar de tijdzone die ProcessMind vereist. Leg vast of de timestamps in de bron zijn opgeslagen in UTC, lokale systeemtijd of een andere geconfigureerde tijdzone.
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 data sneller voor te bereiden en aan de slag te gaan met het optimaliseren van het facturatieproces binnen Order to Cash. Zet vandaag nog SAP S/4HANA-data om in inzichten waarmee je aan de slag kunt.
Verbeter de facturatie binnen Order to Cash en versnel de cashflow met 30%
Verhelp inefficiënties en verkort vanaf vandaag de facturatiecyclus met 30%.
Je hebt geen creditcard nodig. Je kunt binnen enkele minuten aan de slag.