Datatemplate voor de verwerking van crediteurenbetalingen
Datatemplate voor de verwerking van crediteurenbetalingen
- Belangrijke attributen voor analyses van leveranciers en betalingen
- Essentiële procesmomenten in de betalingscyclus
- Specifieke extractielogica voor SAP S/4HANA-systemen
Attributen voor de verwerking van crediteurenbetalingen
| Naam | Beschrijving | ||
|---|---|---|---|
| Activiteit Activity | De specifieke taak of statuswijziging van een gebeurtenis die voor de factuur is vastgelegd. | ||
| Beschrijving Dit attribuut staat voor de afzonderlijke processtappen in de levenscyclus van de factuur. Het legt gebeurtenissen vast zoals het aanmaken, boeken en blokkeren van de factuur, de goedkeuring en de betalingsvereffening. De activiteitsnamen zijn afgeleid van transactiecodes, wijzigingslogboeken of statusupdates van workflows in het bronsysteem. Dit veld is belangrijk om procesvarianten in kaart te brengen. De process mining-engine gebruikt het om de volgorde van stappen te visualiseren, herstelwerk te herkennen en te bepalen waar het proces afwijkt van de ideale route. Het is een kernonderdeel van het event log. Waarom dit belangrijk is Dit veld bepaalt de knooppunten in de proceskaart en maakt workflows en bottlenecks zichtbaar. Waar vind je dit? Afgeleid van transactiecodes (TCODE) of de kop (CDHDR) en regels (CDPOS) van wijzigingsdocumenten Voorbeelden Factuur geboektBetalingsblokkade ingesteldBetalingsrun uitgevoerdFactuur vereffend | |||
| Factuurnummer InvoiceNumber | De unieke identificatie van de leveranciersfactuur die wordt verwerkt. | ||
| Beschrijving Het factuurnummer is de primaire sleutel waarmee je de levenscyclus van een te betalen post in SAP S/4HANA volgt. Het verwijst specifiek naar het nummer van het boekingsdocument dat wordt aangemaakt wanneer de factuur in het grootboek wordt geboekt. In de standaardterminologie van SAP komt dit overeen met het documentnummer (BELNR) binnen een specifieke bedrijfs code en een specifiek boekjaar. Bij procesanalyse dient dit attribuut als Case-ID. Het koppelt alle afzonderlijke activiteiten aan elkaar, van de eerste ontvangst en het parkeren van de factuur tot verschillende goedkeuringsblokkeringen en wijzigingen en de uiteindelijke betalingsvereffening. Door gebeurtenissen op basis van deze identificatie te groeperen, kunnen analisten de volledige geschiedenis van elke betalingsverplichting reconstrueren. Waarom dit belangrijk is Dit is de definitieve Case-ID waarmee je het betalingsproces van begin tot eind kunt reconstrueren. Waar vind je dit? SAP-tabel BKPF (kop van boekingsdocument), veld BELNR, of ACDOCA, veld BELNR Voorbeelden 1900000523510000289119000006015100003002 | |||
| Tijdstip van gebeurtenis EventTime | De exacte timestamp waarop de activiteit plaatsvond. | ||
| Beschrijving Het tijdstip van de gebeurtenis legt de exacte datum en tijd vast waarop een activiteit in de SAP-database is verwerkt. Zo kun je gebeurtenissen binnen een case chronologisch ordenen. Deze timestamp wordt meestal samengesteld uit de velden CPU-datum en CPU-tijd in de systeemlogboeken of documentkoppen. Voor de analyse is dit attribuut nodig om doorlooptijden, duur en doorvoer te berekenen. Je kunt er de tijd tussen processtappen mee meten, bijvoorbeeld tussen de ontvangst en de definitieve goedkeuring van een factuur. Zo spoor je bottlenecks op en beoordeel je KPI’s zoals de gemiddelde goedkeuringstijd van facturen. Waarom dit belangrijk is Dit attribuut bepaalt de chronologische volgorde van gebeurtenissen en vormt de basis voor alle tijdgebonden prestatieberekeningen. Waar vind je dit? SAP-tabel BKPF, velden CPUDT (invoerdatum) en CPUTM (invoertijd), of CDHDR, velden UDATE en UTIME Voorbeelden 2023-10-12T08:30:00.000Z2023-10-12T14:15:22.000Z2023-10-15T09:00:00.000Z | |||
| Bronsysteem SourceSystem | De identificatie van de SAP S/4HANA-instantie waaruit de data afkomstig is. | ||
| Beschrijving Dit attribuut geeft aan uit welke ERP-installatie of client de procesdata is gehaald. Als meerdere SAP-instanties of oudere systemen naast elkaar draaien, helpt dit veld de herkomst van de data vast te leggen en systemen met elkaar te vergelijken. Bij analyses kun je dit veld als filter gebruiken. Zo kunnen analisten data scheiden wanneer ze prestaties van regionale systeeminstallaties vergelijken of de consistentie van data tijdens migratieprojecten controleren. Ook maakt het duidelijk wanneer procesverschillen het gevolg zijn van systeeminstellingen. Waarom dit belangrijk is Hiermee onderscheid je databronnen in omgevingen met meerdere systemen en kun je data nauwkeurig segmenteren. Waar vind je dit? Systeem-ID (SY-SYSID) uit de SAP-installatiecontext Voorbeelden SAP_PROD_01S4H_NA_100ERP_EU_200 | |||
| Laatste data-update LastDataUpdate | De timestamp waarop de record voor het laatst is geëxtraheerd of vernieuwd. | ||
| Beschrijving Laatste data-update geeft aan wanneer de data met succes in het process mining-platform is geladen. Dit is niet het tijdstip van de bedrijfsgebeurtenis, maar geeft aan hoe actueel de dataset is. Dat is belangrijk om op de dashboards te kunnen vertrouwen. Met dit attribuut zien gebruikers hoe actueel de informatie is. Dat is vooral van belang bij dashboards die bijna realtime worden bijgewerkt, zoals de analyse van betalingsblokkeringen. Zo zijn beslissingen gebaseerd op de meest recente status van het SAP S/4HANA-systeem. Waarom dit belangrijk is Dit laat zien hoe actueel de data is, wat belangrijk is voor operationele dashboards. Waar vind je dit? Gegenereerd door het ETL- of extractieproces Voorbeelden 2023-10-27T23:59:59.000Z2023-11-01T06:00:00.000Z | |||
| Bedrijfs code CompanyCode | De organisatorische eenheid waarvoor de balans en winst-en-verliesrekening worden opgesteld. | ||
| Beschrijving De bedrijfs code is de zelfstandige boekhoudkundige entiteit binnen de organisatie. Dit is de centrale organisatorische eenheid voor de externe boekhouding en de indeling van financiële data. Elke factuur is aan precies één bedrijfs code toegewezen. Met dit attribuut kun je KPI’s uitsplitsen per juridische entiteit of regio. Dashboards gebruiken het om de efficiëntie van crediteurenteams bij verschillende dochterondernemingen te vergelijken. Zo zie je bijvoorbeeld of een bepaalde vestiging vaker handmatige betalingsblokkeringen heeft dan de rest van de organisatie. Waarom dit belangrijk is Hiermee kun je het proces per juridische entiteit uitsplitsen en interne vergelijkingen maken. Waar vind je dit? SAP-tabel BKPF, veld BUKRS Voorbeelden US01DE1010002000 | |||
| Betalingsvoorwaarden PaymentTerms | De code voor de afgesproken betalings- en kortingsvoorwaarden. | ||
| Beschrijving Betalingsvoorwaarden bepalen wanneer een factuur vervalt en of er korting geldt bij vroeg betalen. Deze code (bijvoorbeeld ‘Z001’) verwijst naar regels zoals ‘netto 30 dagen’ of ‘2% korting bij betaling binnen 10 dagen, netto 30 dagen’. De voorwaarden worden overgenomen uit de leveranciersstamgegevens, maar kunnen handmatig worden gewijzigd. Dit attribuut is belangrijk voor de dashboards voor vroegbetalingskorting en naleving van betalingstermijnen van leveranciers. Het systeem kan hiermee de basisvervaldatum berekenen en vaststellen of de betaling binnen de gunstigste termijn is gedaan om korting te krijgen. Waarom dit belangrijk is Dit bepaalt de verwachte betalingstermijn en financiële voordelen, en is belangrijk voor de kortingsanalyse. Waar vind je dit? SAP-tabel BSEG, veld ZTERM Voorbeelden Z001NT300001 | |||
| Documentsoort DocumentType | Classificeert het boekingsdocument, bijvoorbeeld als leveranciersfactuur, betaling of creditnota. | ||
| Beschrijving De documentsoort is een code van twee tekens in SAP die de boekhoudkundige transactie classificeert. Veelvoorkomende soorten zijn ‘KR’ voor leveranciersfacturen, ‘KZ’ voor leveranciersbetalingen en ‘RE’ voor bruto factuurontvangst. De documentsoort bepaalt het nummerbereik en de veldstatus van het document. Bij analyses gebruik je dit attribuut om de scope van het proces te filteren. Een analist kan bijvoorbeeld creditnota’s uitsluiten om alleen de efficiëntie van uitgaande betalingen te bekijken. Het attribuut laat ook zien welke transactiesoorten worden verwerkt en ondersteunt het dashboard over de complexiteit van procesvarianten. Waarom dit belangrijk is Hiermee kun je cases indelen als factuur of creditnota en de analyse daarop filteren. Waar vind je dit? SAP-tabel BKPF, veld BLART Voorbeelden KRREKZKG | |||
| Factuurbedrag InvoiceAmount | Het totale brutobedrag van de factuur in de documentvaluta. | ||
| Beschrijving Dit attribuut geeft de financiële waarde van de factuur weer zoals die in het brondocument is vastgelegd. Het staat voor de verplichting die aan de leverancier moet worden voldaan. In SAP S/4HANA wordt dit doorgaans opgeslagen in het veld Bedrag in documentvaluta. Bij analyses gebruik je het factuurbedrag om werk te prioriteren. Dashboards zoals de verdeling van handmatige contactmomenten laten zien of tijdrovende handmatige activiteiten worden besteed aan facturen met een lage waarde. Zo kan de organisatie verbeteringen richten op transacties met een hoge waarde, waar procesfouten grotere financiële risico’s met zich meebrengen. Waarom dit belangrijk is Dit geeft het financiële gewicht van de case aan en helpt inefficiënties bij transacties met een hoge waarde te prioriteren. Waar vind je dit? SAP-tabel BKPF of BSEG, veld WRBTR Voorbeelden 1500.00250.5010000.00 | |||
| Gebruikersnaam UserName | De ID van de gebruiker die de activiteit heeft uitgevoerd. | ||
| Beschrijving De gebruikersnaam bevat de aanmeld-ID van de persoon of systeemagent die verantwoordelijk is voor een processtap. Dit kan een gebruiker zijn die handmatig data invoert, of een ID van een achtergrondtaak (bijvoorbeeld ‘BATCH_USER’) die geautomatiseerde taken uitvoert. Met dit attribuut kun je het automatiseringspercentage van activiteiten berekenen. Door menselijke gebruikers te onderscheiden van systeemaccounts, kunnen analisten meten hoeveel van het proces is geautomatiseerd. Het wordt ook gebruikt in het dashboard voor de verdeling van handmatige contactmomenten om de werklast van teams te beoordelen. Waarom dit belangrijk is Hiermee onderscheid je handmatig werk van geautomatiseerd werk en kun je het automatiseringspercentage berekenen. Waar vind je dit? SAP-tabel BKPF, veld USNAM, of CDHDR, veld USERNAME Voorbeelden BSMITHWF-BATCHRJONES | |||
| Is betaling te laat IsLatePayment | Een booleaanse waarde die aangeeft of de betaling na de nettovervaldatum is gedaan. | ||
| Beschrijving Dit berekende attribuut is waar als de verrekeningsdatum na de nettovervaldatum valt. Het geeft in één oogopslag aan of de betaling op tijd was. In analyses gebruik je deze waarde om het aantal cases te tellen dat niet aan de voorwaarden voldoet voor de KPI Frequentie van boetes voor te late betaling. Zo kun je in een dashboard eenvoudig de waarden ‘Waar’ tellen, zonder daar ingewikkelde datumformules voor nodig te hebben. Waarom dit belangrijk is Zo bereken je KPI’s voor tijdige betalingen eenvoudiger. Waar vind je dit? Berekend: Verrekeningsdatum > Nettovervaldatum Voorbeelden truefalse | |||
| Leveranciersnummer VendorNumber | De unieke identificatie van de leverancier bij de factuur. | ||
| Beschrijving Het leveranciersnummer verwijst naar de specifieke crediteurenrekening in het SAP-subgrootboek. Het koppelt de factuur aan de stamgegevens met betalingsvoorwaarden, bankgegevens en contactinformatie. In S/4HANA is dit vaak gekoppeld aan het concept Business Partner, maar in veel tabellen blijft de oude veldnaam LIFNR in gebruik. Bij analyses is dit attribuut belangrijk voor het dashboard over naleving van betalingstermijnen van leveranciers. Analisten kunnen procesprestaties per leverancier samenvatten en zien welke leveranciers regelmatig blokkeringen, prijsverschillen of vertragingen veroorzaken. Dit ondersteunt beslissingen over strategische inkoop en het beheer van leveranciersrelaties. Waarom dit belangrijk is Hiermee kun je prestaties per leverancier vergelijken en de oorzaken van vertragingen opsporen. Waar vind je dit? SAP-tabel BKPF, veld LIFNR, of ACDOCA, veld LIFNR Voorbeelden 100050VEND-US-99200400 | |||
| Nettovervaldatum NetDueDate | De berekende datum waarop de factuur uiterlijk moet zijn betaald om boetes te voorkomen. | ||
| Beschrijving De nettovervaldatum is de uiterste betaaldatum. Je berekent deze door het maximale aantal dagen van de betalingstermijn bij de basisdatum op te tellen. Soms is de datum expliciet opgeslagen, maar vaak wordt deze berekend in analyseweergaven. Dit is de belangrijkste referentiedatum voor het bijhouden van te late betalingen en boetes. Door de werkelijke vereffeningsdatum met de nettovervaldatum te vergelijken, bereken je het aantal dagen dat de betaling te laat was. Zo kun je de efficiëntie van het crediteurenteam en het risico op problemen met leveranciers beoordelen. Waarom dit belangrijk is Dit is de uiterste datum voor het proces. Als je die mist, kan dat de kredietwaardigheid schaden en extra kosten veroorzaken. Waar vind je dit? Berekend als: basisdatum + maximale betalingstermijn in dagen (ZBD1T/ZBD2T/ZBD3T) Voorbeelden 2023-11-302023-12-01 | |||
| Reden betalingsblokkering PaymentBlockReason | De code die aangeeft waarom een factuur is geblokkeerd voor betaling. | ||
| Beschrijving Dit attribuut bevat de specifieke reden waarom een factuur niet wordt meegenomen in de automatische betalingsrun. Voorbeelden zijn ‘A’ voor geblokkeerd voor betaling, ‘R’ voor factuurcontrole of een handmatige blokkering door een gebruiker. Dit veld is de belangrijkste basis voor het dashboard voor analyse van handmatige betalingsblokkeringen. Door de verschillende redenen voor blokkering bij elkaar op te tellen, kan de organisatie structurele problemen opsporen, zoals terugkerende prijsverschillen of ontbrekende goederenontvangsten die de betaling vertragen. Waarom dit belangrijk is Dit maakt de specifieke oorzaken van processtops zichtbaar, zodat je gericht de oorzaak kunt onderzoeken. Waar vind je dit? SAP-tabel BSEG, veld ZLSPR Voorbeelden ABR* | |||
| Vereffeningsdatum ClearingDate | De datum waarop de factuur door betaling is vereffend. | ||
| Beschrijving De vereffeningsdatum geeft aan wanneer de openstaande post in het crediteurenboek is afgeboekt, meestal via een betalingsrun of een handmatige betalingsboeking. Daarmee komt de verplichting ten einde. Bij analyses gebruik je dit attribuut om de totale doorlooptijd van het proces te berekenen. Het is de timestamp voor de activiteit ‘Betaling vereffend’ en wordt vergeleken met de nettovervaldatum om te bepalen of op tijd is betaald. De datum wordt ook gebruikt in het dashboard voor de efficiëntie van betalingsvereffening. Waarom dit belangrijk is Dit markeert het einde van het betalingsproces en laat zien of de betaling op tijd is gedaan. Waar vind je dit? SAP-tabel BSEG, veld AUGDT Voorbeelden 2023-11-012023-11-15 | |||
| Zonder handmatige tussenkomst IsTouchless | Een booleaanse waarde die aangeeft of de factuur zonder handmatige tussenkomst is verwerkt. | ||
| Beschrijving Dit attribuut wordt berekend door de eventstroom van een case te analyseren. Een case krijgt de waarde ‘zonder handmatige tussenkomst’ als deze alleen geautomatiseerde activiteiten bevat, zoals activiteiten van de gebruiker ‘system’ of specifieke achtergrond-TCODES, en er geen handmatige wijzigingen of blokkades zijn. In analyses is dit de belangrijkste metriek voor de KPI Percentage facturen zonder handmatige tussenkomst. Zo kan de organisatie volgen hoe goed automatiseringsinitiatieven werken en zien welke typen cases, bijvoorbeeld per leverancier of regio, zonder menselijke tussenkomst door het systeem lopen. Waarom dit belangrijk is Dit is de belangrijkste maatstaf voor procesautomatisering en efficiëntie. Waar vind je dit? Berekend op basis van de volgorde van activiteiten en gebruikerstypen Voorbeelden truefalse | |||
| Basisdatum BaselineDate | De datum vanaf wanneer de betalingsvoorwaarden gelden en de vervaldatums worden berekend. | ||
| Beschrijving De basisdatum is het uitgangspunt voor de berekening van de nettovervaldatum en de kortingsperioden. Afhankelijk van de configuratie en de leveranciersstamgegevens is dit meestal de factuurdatum of de boekingsdatum. Voor de analyse is deze datum nodig om vast te stellen of een betaling te laat is. Een onjuiste basisdatum kan leiden tot te vroege betalingen, met gevolgen voor de cashflow, of te late betalingen, met mogelijke boetes. De juistheid van deze datum controleren hoort bij de analyse van naleving van betalingstermijnen van leveranciers. Waarom dit belangrijk is Dit is het uitgangspunt voor alle berekeningen van vervaldatums. Waar vind je dit? SAP-tabel BSEG, veld ZFBDT Voorbeelden 2023-10-012023-10-15 | |||
| Bedrag aan misgelopen korting DiscountLostAmount | De geldwaarde van beschikbare contantkortingen die niet zijn benut. | ||
| Beschrijving Dit berekende attribuut laat zien hoeveel korting is misgelopen. Het wordt berekend door na te gaan of de betaling na de kortingsdatum is gedaan. Is dat het geval, dan wordt het gemiste kortingspercentage toegepast op het factuurbedrag. Dit is een belangrijke financiële metriek voor de optimalisatie van kortingen bij vroege betaling. De berekening maakt de kosten van inefficiënte processen concreet en onderbouwt zo de businesscase voor procesverbeteringen. Waarom dit belangrijk is Zo wordt het directe financiële verlies door procesvertragingen zichtbaar. Waar vind je dit? Berekend: als de verrekeningsdatum na de kortingsdatum valt, dan factuurbedrag × kortingspercentage Voorbeelden 30.000.00150.00 | |||
| Boekjaar FiscalYear | Het boekjaar waartoe de factuur behoort. | ||
| Beschrijving Het boekjaar is de periode waarop de financiële rapportage betrekking heeft. Samen met de bedrijfs code en het documentnummer vormt het de samengestelde primaire sleutel van een financieel document in SAP. Voor analyses is dit nodig om cases uniek te identificeren. Het ondersteunt ook vergelijkingen tussen boekjaren en zorgt ervoor dat de Case-ID ‘Factuurnummer’ uniek blijft, ook bij data over meerdere decennia. Waarom dit belangrijk is Technische vereiste om cases in SAP FI uniek te identificeren. Waar vind je dit? SAP-tabel BKPF, veld GJAHR Voorbeelden 20232024 | |||
| Dagen voor contantkorting 1 CashDiscountDays1 | Het aantal dagen vanaf de basisdatum waarin de eerste contantkorting beschikbaar is. | ||
| Beschrijving Dit attribuut bepaalt de termijn voor de gunstigste betalingsvoorwaarden, bijvoorbeeld ‘10’ in ‘2% korting bij betaling binnen 10 dagen, netto 30 dagen’. De waarde komt uit de voorwaarden op de factuurregel. Bij analyses gebruik je dit om de streefdatum voor de optimalisatie van vroegbetalingskorting te bepalen. Als de factuur binnen deze termijn wordt vereffend, wordt de korting toegepast. Met dit veld kun je zien hoeveel korting je misloopt door lange verwerkingstijden. Waarom dit belangrijk is Dit bepaalt binnen welke termijn je financieel voordeel kunt behalen. Waar vind je dit? SAP-tabel BSEG, veld ZBD1T Voorbeelden 10140 | |||
| Inkoopdocument PurchasingDocument | Het inkoopordernummer dat bij de factuur hoort. | ||
| Beschrijving Dit attribuut koppelt de factuur aan het voorafgaande inkoopproces. Het bevat het nummer van de inkooporder (PO) waarmee de factuur wordt vergeleken. Niet alle facturen, zoals facturen voor diverse uitgaven, hebben een verwijzing naar een inkooporder. Dit veld is belangrijk voor de analyse van het percentage driewegmatches. Analisten kunnen facturen met en zonder inkooporder van elkaar onderscheiden, omdat daarvoor doorgaans heel andere goedkeuringsworkflows gelden. Het maakt ook process mining van begin tot eind mogelijk door crediteurendata aan inkoopdata te koppelen. Waarom dit belangrijk is Dit koppelt crediteuren aan inkoop en maakt analyse van driewegmatches en uitbreiding van de procesanalyse mogelijk. Waar vind je dit? SAP-tabel BSEG, veld EBELN Voorbeelden 45000012344500009876 | |||
| Percentage contantkorting 1 CashDiscountPercentage1 | Het kortingspercentage dat geldt als de factuur binnen de eerste kortingsperiode wordt betaald. | ||
| Beschrijving Dit attribuut geeft het financiële voordeel aan dat de leverancier biedt bij vroeg betalen, bijvoorbeeld ‘2’ in ‘2% korting bij betaling binnen 10 dagen’. Bij analyses gebruik je dit om de mogelijke contantkorting te berekenen. Door dit percentage met het factuurbedrag te vermenigvuldigen, laten dashboards zien hoeveel geld verloren gaat door inefficiënte processen. Zo kun je onderbouwen waarom automatisering zinvol is. Waarom dit belangrijk is Dit geeft de mogelijke besparing aan en is nodig voor berekeningen van het rendement op investering. Waar vind je dit? SAP-tabel BSEG, veld ZBD1P Voorbeelden 2.03.00.0 | |||
| Valuta Currency | De valutacode van het factuurbedrag. | ||
| Beschrijving Het attribuut Valuta geeft aan in welke valuta het factuurbedrag is uitgedrukt, bijvoorbeeld USD, EUR of GBP. Zo kunnen financiële bedragen correct worden geïnterpreteerd en data uit internationale bedrijfs codes worden samengevoegd. Dit veld zorgt ervoor dat financiële KPI’s correct worden berekend. Vaak wordt het gebruikt om bedragen voor wereldwijde dashboards om te rekenen naar een rapportagevaluta. Zonder dit attribuut hebben totalen zoals de totale uitgaven of de gemiddelde factuurwaarde geen betekenis in een omgeving met meerdere valuta. Waarom dit belangrijk is Dit geeft context aan financiële bedragen en is nodig voor correcte wereldwijde rapportages. Waar vind je dit? SAP-tabel BKPF, veld WAERS Voorbeelden USDEURGBPJPY | |||
Activiteiten voor de verwerking van crediteurenbetalingen
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Betaling vereffend | Markeert de definitieve afstemming waarbij de openstaande post op de leveranciersrekening tegen de betaling wordt weggestreept. Vastgelegd in het veld AUGDT (vereffeningsdatum) van de BSEG-tabel. | ||
| Waarom dit belangrijk is De eindstatus van het proces. De levenscyclus is voltooid en de boekhouding is in evenwicht. Een hoog percentage handmatige vereffeningen wijst op inefficiënties bij de afstemming. Waar vind je dit? BSEG-tabel, veld AUGDT (vereffeningsdatum). Vastleggen Geregistreerd zodra het veld AUGDT is ingevuld Gebeurtenistype explicit | |||
| Betalingsblokkade ingesteld | Geeft aan dat er een betalingsblokkade is ingesteld op een factuurregel, waardoor deze niet in de betaalrun wordt meegenomen. Dit wordt vastgelegd door wijzigingen in het veld ZLSPR in de tabel BSEG via wijzigingsdocumenten te volgen. | ||
| Waarom dit belangrijk is Blokkades zijn de belangrijkste oorzaak van te late betalingen en vertragingen in het proces. Ze hebben rechtstreeks invloed op het dashboard voor analyse van handmatige betalingsblokkades. Waar vind je dit? Tabellen CDPOS en CDHDR (wijzigingsdocumenten), voor wijzigingen in het veld BSEG-ZLSPR. Vastleggen Geregistreerd wanneer CDPOS een wijziging in ZLSPR vastlegt Gebeurtenistype explicit | |||
| Betalingsblokkade opgeheven | Geeft aan dat een eerder ingestelde betalingsblokkade is opgeheven en de factuur dus kan worden betaald. Dit wordt herkend wanneer het veld ZLSPR in BSEG verandert van een waarde naar null of leeg. | ||
| Waarom dit belangrijk is In systemen zonder expliciete workflowlogs geldt dit vaak als benadering van 'Factuur goedgekeurd' en markeert het het einde van de bottleneckperiode. Waar vind je dit? Tabellen CDPOS en CDHDR, voor wijzigingen waarbij BSEG-ZLSPR leeg wordt. Vastleggen Geregistreerd wanneer CDPOS vastlegt dat ZLSPR is verwijderd Gebeurtenistype explicit | |||
| Betalingsdocument aangemaakt | Het aanmaken van het boekingsdocument dat de bankrekening crediteert en de leveranciersrekening debiteert. Dit is te vinden in BKPF met een documentsoort voor betalingen (bijvoorbeeld ZP of KZ). | ||
| Waarom dit belangrijk is De financiële afwikkeling van de betaling, gebruikt om Days Payable Outstanding (DPO) te berekenen. Waar vind je dit? BKPF-tabel, gefilterd op documentsoort (BLART) voor betalingen. Vastleggen Geregistreerd bij het aanmaken van een betalingsdocument in BKPF Gebeurtenistype explicit | |||
| Betalingsrun uitgevoerd | Geeft aan dat de betalingsrun is uitgevoerd en betaalopdrachten zijn aangemaakt. Dit wordt bijgehouden via de statuswijziging in de tabellen REGUH of REGUP. | ||
| Waarom dit belangrijk is De operationele verplichting om te betalen, essentieel voor de analyse van de efficiëntie van het bundelen van betalingen. Waar vind je dit? REGUH-tabel, doorgaans gekoppeld aan de uitvoeringsdatum en identificatie. Vastleggen Geregistreerd bij een statuswijziging van de betalingsrun Gebeurtenistype explicit | |||
| Factuur geboekt | Dit is de officiële registratie van de verplichting in het grootboek. De activiteit wordt afgeleid van de aanmaaktimestamp in de tabel BKPF of de boekingsdatum in de tabel ACDOCA. | ||
| Waarom dit belangrijk is Dit is het beginpunt van de financiële tijdlijn en vormt de basis voor vervaldatums en verouderingsanalyse. Waar vind je dit? Tabel BKPF, met CPUDT (invoerdatum) en CPUTM (invoertijd). Vastleggen Geregistreerd bij het aanmaken van een BKPF-record Gebeurtenistype explicit | |||
| Betalingstermijn gewijzigd | Legt een wijziging vast in de betalingstermijn van een openstaande factuur, waardoor de vervaldatum of het recht op korting verandert. Dit wordt gevolgd via wijzigingslogs van het veld ZTERM in de tabel BSEG. | ||
| Waarom dit belangrijk is Regelmatige wijzigingen kunnen wijzen op fouten in stamgegevens of handmatige aanpassingen die de kasstroomprognoses en de naleving van betalingstermijnen door leveranciers beïnvloeden. Waar vind je dit? Tabellen CDPOS en CDHDR, voor wijzigingen in het veld BSEG-ZTERM. Vastleggen Geregistreerd wanneer CDPOS een wijziging in ZTERM vastlegt Gebeurtenistype explicit | |||
| Betalingsvoorstel aangemaakt | Geeft aan dat de factuur is opgenomen in een betaalvoorstelrun (F110), de eerste stap van het automatische betalingsprogramma. Dit wordt vastgelegd in de tabel REGUH, waarin afwikkelingsgegevens worden opgeslagen. | ||
| Waarom dit belangrijk is Geeft aan dat de factuur is geselecteerd voor betaling en de validatiecontroles van het betalingsprogramma heeft doorstaan. Waar vind je dit? Tijdstempel waarop de REGUH-tabel is aangemaakt (sleutels LAUFD en LAUFI). Vastleggen Geregistreerd bij het aanmaken van een REGUH-record Gebeurtenistype explicit | |||
| Factuur geparkeerd | Geeft aan dat een factuur in SAP is ingevoerd, maar nog niet in het grootboek is geboekt. Dit wordt vaak gebruikt voor voorlopige gegevensinvoer. De gebeurtenis wordt rechtstreeks vastgelegd in de tabel VBKPF of herkend aan documenten in BKPF met een geparkeerde statuscode, voordat ze worden geboekt. | ||
| Waarom dit belangrijk is Parkeren markeert het begin van de gegevensinvoer en helpt de vertraging tussen ontvangst en het ontstaan van een financiële verplichting te meten. Waar vind je dit? Tabel VBKPF voor kopgegevens van geparkeerde documenten, of BKPF met een specifieke documentstatus (BSTAT = V). Vastleggen Geregistreerd bij het aanmaken van een VBKPF-vermelding Gebeurtenistype explicit | |||
| Factuur teruggedraaid | Geeft aan dat het factuurdocument is teruggedraaid of geannuleerd. Dit wordt vastgesteld aan de hand van het veld STBLG (terdraaiingsdocument) in de BKPF-tabel. | ||
| Waarom dit belangrijk is Wijst op herstelwerk en een procesfout, en maakt verspilling en mogelijk dubbel werk zichtbaar. Waar vind je dit? BKPF-tabel, veld STBLG is niet leeg. Vastleggen Geregistreerd zodra het veld STBLG is ingevuld Gebeurtenistype explicit | |||
| Factuur vervallen | Een berekende timestamp voor het moment waarop de nettovervaldatum van de factuur is bereikt. Deze wordt berekend door de dagen van de betalingstermijn op te tellen bij de basisdatum in de tabel BSEG. | ||
| Waarom dit belangrijk is Dient als referentiepunt voor de prestaties van tijdige betalingen en de tracker voor boetes bij te late betaling. Waar vind je dit? Berekend: BSEG-ZFBDT (basisdatum) + BSEG-ZBD1T/ZBD2T/ZBD3T (dagen). Vastleggen Afleiden door de huidige datum te vergelijken met de nettovervaldatum Gebeurtenistype calculated | |||
| Hoeveelheidsverschil vastgesteld | Afgeleide activiteit die wijst op een verschil tussen de gefactureerde hoeveelheid en de ontvangen hoeveelheid. Dit wordt afgeleid uit een specifieke betalingsblokkeringssleutel, meestal 'M' voor een hoeveelheidsverschil, die op de regel wordt ingesteld. | ||
| Waarom dit belangrijk is Belangrijk voor de analyse van de efficiëntie van matching en de datakwaliteit in de toeleveringsketen. Waar vind je dit? Afgeleid van de waarde 'M' in BSEG-ZLSPR (of een systeemspecifieke instelling voor hoeveelheidsblokkades). Vastleggen Vergelijk de waarde van ZLSPR met 'M' Gebeurtenistype inferred | |||
| Korting voor contante betaling misgelopen | Een berekende gebeurtenis die de datum markeert waarop het recht op korting voor contante betaling verviel. Dit wordt afgeleid door de uiterste kortingsdatum te vergelijken met de huidige datum of de betaaldatum. | ||
| Waarom dit belangrijk is Essentieel voor de optimalisatie van kortingen bij vroege betaling, zodat gemiste financiële kansen zichtbaar worden. Waar vind je dit? Berekend: BSEG-ZFBDT + BSEG-ZBD1T (kortingsdagen 1). Vastleggen Afleiden door de datum te vergelijken met de uiterste kortingsdatum Gebeurtenistype calculated | |||
| Prijsverschil vastgesteld | Afgeleide activiteit die wijst op een verschil tussen de factuurprijs en de prijs op de inkooporder. Dit wordt afgeleid uit een specifieke betalingsblokkeringssleutel, meestal 'R' voor factuurcontrole, die automatisch wordt ingesteld bij het boeken. | ||
| Waarom dit belangrijk is Brengt de oorzaken van handmatig herstelwerk aan het licht en ondersteunt de analyse van het three-way-matchpercentage. Waar vind je dit? Afgeleid van de waarde 'R' in BSEG-ZLSPR (of een systeemspecifieke instelling voor prijsblokkades) op het moment van boeken. Vastleggen Vergelijk de waarde van ZLSPR met 'R' Gebeurtenistype inferred | |||
Extractiegidsen
Stappen
Benodigde CDS-views vaststellen: Controleer of de standaard-CDS-views van SAP S/4HANA beschikbaar zijn. De belangrijkste benodigde views zijn I_JournalEntry (kop), I_OperationalAcctgDocItem (posten, equivalent van BSEG), I_SupplierInvoice (logistiek), I_PaymentProposalItem (F110) en I_ChangeDocument (voor logs).
Gebruikersrechten instellen: Zorg dat de databasegebruiker of technische servicegebruiker SELECT-rechten heeft op de DDL SQL-views die bij de CDS-entiteiten horen. Dit regel je meestal via SAP HANA Studio of ABAP Development Tools voor Eclipse (ADT).
SQL-omgeving voorbereiden: Open de SQL-interface, bijvoorbeeld SAP HANA Studio, DBeaver met een verbinding met HANA of een process mining-connector die SQL ondersteunt. Deze methode gaat uit van rechtstreekse SQL-toegang tot de HANA-laag, waar de CDS-views als views beschikbaar zijn.
Scope bepalen: Bepaal de bedrijfscode (CompanyCode) en het bereik van boekjaren om de hoeveelheid data te beperken. Dit is belangrijk voor de prestaties bij het opvragen van de view met operationele boekingsdocumentposten.
Activiteitenlogica instellen: Kopieer de SQL-query hieronder. Met UNION ALL combineert deze query 14 afzonderlijke logische blokken in één event log. Elk blok richt zich op een specifieke activiteit, zoals Factuur geboekt of Betaling verrekend.
Wijzigingsdocumenten verwerken: De query bevat onderdelen voor wijzigingen in betalingsvoorwaarden en blokkeringen. Hiervoor wordt de view I_ChangeDocument gebruikt. Is deze view niet actief in jouw S/4-release, dan moet je mogelijk de onderliggende tabellen (CDHDR/CDPOS) in een aangepaste CDS-view opnemen.
Berekende events verwerken: Controleer de logica voor Factuur vervallen en Contantkorting misgelopen. Dit zijn berekende events die ontstaan door dagen op te tellen bij de basisdatum in de view met operationele posten.
Extractie uitvoeren: Voer de query uit. Bij grote datasets is het sterk aan te raden de extractie op te splitsen per boekjaar of bedrijfscode om geheugenproblemen te voorkomen.
Datum- en tijdnotatie controleren: Controleer of de kolom EventTime de notatie YYYY-MM-DD HH:MM:SS heeft. SAP HANA SQL geeft timestamps terug die je mogelijk moet omzetten voor de doelapplicatie.
Data exporteren: Sla het resultaat op als CSV- of Parquet-bestand. Zorg dat de kolomnamen overeenkomen met de kolommen in de uiteindelijke SELECT-instructie.
Data voorbereiden voor upload: Vereist de process mining-tool een specifieke CSV-notatie, bijvoorbeeld een specifieke datummaskering, pas de omzettingen dan toe in een script voor nabewerking of in SQL met TO_VARCHAR-functies.
Eindcontrole uitvoeren: Laad een voorbeeld in ProcessMind en controleer of de Case-ID (factuurnummer) alle activiteiten van boeking tot verrekening correct groepeert.
Configuratie
- Filter op bedrijfscode: Beperk de query tot specifieke organisatie-eenheden (CompanyCode = '1000') om de context te behouden en de prestaties op peil te houden.
- Datumbereik: Filter op PostingDate of CreationDate, bijvoorbeeld de afgelopen 12 maanden, om de hoeveelheid data te beperken.
- Rekeningtype: Filter I_OperationalAcctgDocItem op FinancialAccountType = 'K' (leverancier) om regels voor grootboekrekeningen en klanten uit te sluiten.
- CDS-view activeren: Controleer of de views I_JournalEntry, I_OperationalAcctgDocItem en I_PaymentProposalItem actief zijn en SQL-toegang bieden.
- Prestaties van het wijzigingslog: Een query op I_ChangeDocument kan veel bronnen gebruiken. Beperk deze subquery’s tot ObjectClass 'BELEG' en specifieke veldnamen zoals ZLSPR en ZTERM.
Voorbeeldquery sql
/* SAP S/4HANA CDS View Extraction for Accounts Payable */
/* Combined Event Log Query */
/* 1. Invoice Parked */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Parked' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
JE.CreatedByUser AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
CASE WHEN JE.CreationDateTime > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) THEN 'True' ELSE 'False' END AS IsLatePayment,
'False' AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K' -- Vendor
AND JE.AccountingDocumentCategory = 'V' -- Parked Document
UNION ALL
/* 2. Invoice Posted */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Posted' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
JE.CreatedByUser AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
'False' AS IsLatePayment,
CASE WHEN JE.CreatedByUser = 'BATCH_USER' THEN 'True' ELSE 'False' END AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JE.AccountingDocumentCategory <> 'V' -- Exclude Parked
UNION ALL
/* 3. Price Variance Detected (Inferred at Posting) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Price Variance Detected' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.PaymentBlockingReason = 'R' -- Standard SAP Price Variance Block Key
UNION ALL
/* 4. Quantity Variance Detected (Inferred at Posting) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Quantity Variance Detected' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.PaymentBlockingReason = 'M' -- Standard SAP Quantity Variance Block Key
UNION ALL
/* 5. Payment Block Applied (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Block Applied' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
CD.NewValue AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZLSPR'
AND CD.OldValue IS NULL AND CD.NewValue IS NOT NULL
UNION ALL
/* 6. Payment Block Removed (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Block Removed' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZLSPR'
AND CD.OldValue IS NOT NULL AND (CD.NewValue IS NULL OR CD.NewValue = '')
UNION ALL
/* 7. Payment Terms Changed (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Terms Changed' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
CD.NewValue AS PaymentTerms,
NULL AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZTERM'
UNION ALL
/* 8. Invoice Due (Calculated) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Due' AS Activity,
TO_TIMESTAMP(ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays))) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) < CURRENT_DATE
UNION ALL
/* 9. Cash Discount Lost (Calculated) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Cash Discount Lost' AS Activity,
TO_TIMESTAMP(ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.CashDiscount1Days))) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.CashDiscount1Days > 0
AND (JEItem.ClearingDate IS NULL OR JEItem.ClearingDate > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.CashDiscount1Days)))
UNION ALL
/* 10. Payment Proposal Created */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Proposal Created' AS Activity,
PPI.ProposalRunDate AS EventTime, -- Often just a date, cast to timestamp if needed
JE.CompanyCode,
PPI.Supplier AS VendorNumber,
PPI.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PPI.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_PaymentProposalItem AS PPI
JOIN I_JournalEntry AS JE
ON PPI.CompanyCode = JE.CompanyCode
AND PPI.AccountingDocument = JE.AccountingDocument
AND PPI.FiscalYear = JE.FiscalYear
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JEItem.FinancialAccountType = 'K'
UNION ALL
/* 11. Payment Run Executed */
/* Derived from existence in payment tables with a run ID */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Run Executed' AS Activity,
PPI.PaymentRunDate AS EventTime,
JE.CompanyCode,
PPI.Supplier AS VendorNumber,
PPI.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PPI.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_PaymentProposalItem AS PPI
JOIN I_JournalEntry AS JE
ON PPI.CompanyCode = JE.CompanyCode
AND PPI.AccountingDocument = JE.AccountingDocument
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
WHERE PPI.PaymentRunID IS NOT NULL
UNION ALL
/* 12. Payment Document Created */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Document Created' AS Activity,
PayJE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
PayJE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PayJE.CreatedByUser AS UserName,
PayJE.PostingDate AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
JOIN I_JournalEntry AS PayJE
ON JEItem.ClearingJournalEntry = PayJE.AccountingDocument
AND JEItem.ClearingJournalEntryFiscalYear = PayJE.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.ClearingJournalEntry IS NOT NULL
UNION ALL
/* 13. Payment Cleared */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Cleared' AS Activity,
TO_TIMESTAMP(JEItem.ClearingDate) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
JEItem.ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
CASE WHEN JEItem.ClearingDate > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) THEN 'True' ELSE 'False' END AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.ClearingDate IS NOT NULL
UNION ALL
/* 14. Invoice Reversed */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Reversed' AS Activity,
RevJE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
RevJE.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
JOIN I_JournalEntry AS RevJE
ON JE.ReverseDocument = RevJE.AccountingDocument
AND JE.ReverseDocumentFiscalYear = RevJE.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JE.ReverseDocument IS NOT NULL Stappen
- Controleer of je rechtstreeks toegang hebt tot de SAP HANA-schema’s met ACDOCA, BKPF, BSEG, VBKPF, REGUH, REGUP en de relevante tabellen met wijzigingsdocumenten. Vervang [Your SAP HANA schema] en de verbindingsgegevens door waarden die voor jouw systeem zijn goedgekeurd.
- Bepaal welke facturen je wilt opnemen en over welke rapportageperiode. Stel [Start date] en [End date] in op YYYYMMDD en vul [Company code filter] in met een geldige SQL-voorwaarde, zoals BUKRS IN ('1000','2000').
- Controleer de SAP-release en lokale instellingen voor geparkeerde documenten, statusvelden van het betalingsprogramma, betalingdocumenttypen en de opslag van wijzigingsdocumenten. De query gebruikt gedocumenteerde bronobjecten en voorzichtige veldkoppelingen. Controleer lokale uitbreidingen en verschillen tussen releases voordat je de query in productie gebruikt.
- Voer de query uit op SAP HANA met een goedgekeurde SQL-client of extractieservice. De query maakt één eventregel voor elke activiteit die expliciet wordt geëxtraheerd. ProcessMind leidt geen activiteiten af die niet in het resultaat staan.
- Controleer de brond data en pas de gemarkeerde configuratiefilters aan voor de status van geparkeerde documenten, betalingdocumenttypen, de status van betalingsvoorstellen en betalingsruns, en objectklassen van wijzigingsdocumenten. Maak deze filters niet ruimer zonder eerst dubbele of niet-gerelateerde boekhoudkundige documenten te controleren.
- Controleer de joins met InvoiceNumber, CompanyCode, boekjaar, boekingsdocumentnummer, leveranciersnummer en, waar van toepassing, postnummer. Controleer in het doelsysteem of factuurdocumentnummers in BKPF, BSEG, ACDOCA, REGUH en REGUP op dezelfde manier zijn vastgelegd.
- Controleer de berekende events. Factuur vervallen wordt aangemaakt op de berekende nettovervaldatum. Contantkorting misgelopen wordt aangemaakt op de eerstvolgende toepasselijke kortingsdeadline als er vóór die datum geen betaling is gedaan. Dit zijn afgeleide regels. Maak duidelijk onderscheid tussen deze regels en events uit bronrecords.
- Exporteer het resultaat als een platte UTF-8-CSV of een ander tabelbestandsformaat dat ProcessMind ondersteunt. Behoud exact de kolomnamen InvoiceNumber, Activity, EventTime, SourceSystem en LastDataUpdate. Houd één regel per event aan en groepeer activiteiten niet per factuur.
- Upload het event log naar ProcessMind en koppel InvoiceNumber aan de case-ID, Activity aan de activiteitsnaam en EventTime aan de eventtimestamp. Koppel de overige kolommen als event- of case-attributen volgens de importinstellingen van ProcessMind.
Configuratie
- Datumbereik: Gebruik voor de eerste extractie een voortschrijdende periode van 3 tot 6 maanden. Pas filters voor boekingsdatum, wijzigingsdatum en datum van het betalingsprogramma consequent toe. Vergroot het bereik als je lange betalingstermijnen wilt controleren.
- Schema: Vervang [Your SAP HANA schema] door het schema waarin de SAP-objecten staan. Controleer of de omgeving clientafhankelijke objecten via het gekozen schema beschikbaar maakt of dat je een expliciet clientfilter nodig hebt.
- Filter op bedrijfscode: Stel [Company code filter] zo in dat BUKRS wordt beperkt tot de benodigde bedrijfscodes. Pas dezelfde scope toe op BKPF, BSEG, ACDOCA, REGUH, REGUP en bronnen met wijzigingsdocumenten, voor zover die velden beschikbaar zijn.
- Documentfilters: Controleer het filter voor factuurdocumenttypen en het filter voor betalingdocumenttypen. De query bevat gangbare voorbeelden, maar documenttypen verschillen per systeem en moeten daarop worden afgestemd.
- Geparkeerde facturen: Controleer hoe de status van geparkeerde documenten in VBKPF of BKPF wordt weergegeven. De query gebruikt een instelbaar statusfilter, omdat de codering per release en implementatie kan verschillen.
- Betalingswijzigingen: Controleer de objectklasse, tabelnaam, veldnamen en waardeweergave van wijzigingsdocumenten voor BSEG-ZLSPR en BSEG-ZTERM. Controleer hoe wijzigingsdocumenten in het doelsysteem zijn opgeslagen en welke veldnamen daar worden gebruikt.
- Betalingsprogramma: Controleer welke REGUH- en REGUP-velden worden gebruikt voor de status van voorstellen en uitvoeringen, de uitvoeringsdatum, de run-ID en de koppeling met boekingsdocumenten. Lokale instellingen van het betalingsprogramma kunnen invloed hebben op de beschikbare statuswaarden.
- Prestaties: Beperk het datumbereik en de bedrijfscodes, selecteer alleen benodigde kolommen en pas filters per bron toe voordat je joins uitvoert. Maak bij grote datasets gefilterde subsets of gebruik een goedgekeurde HANA-calculatieweergave of een extractieschema.
- Autorisaties: Je hebt leestoegang nodig tot de relevante SAP HANA-schemaobjecten en eventuele views met boekhoudkundige data, gegevens van het betalingsprogramma en wijzigingsdocumenten. Stem dit af met de SAP-beveiligings- en datagovernanceteams.
- Functionele vereisten: De relevante functies voor Financial Accounting, crediteurenadministratie, het betalingsprogramma en wijzigingsdocumenten moeten actief zijn en data bevatten. Wordt een brontabel niet gebruikt in de implementatie, stel dan op basis van het systeemontwerp een goedgekeurde vervanging in.
- Timestampverwerking: BKPF en BSEG bevatten datums en tijden meestal in aparte velden. De query combineert deze tot een timestamp. Controleer de tijdzone van het bronsysteem en pas de benodigde omzetting toe voordat je de data uploadt naar ProcessMind.
- Gegevensbescherming: Beperk leveranciers- en boekhoudkundige data tot de goedgekeurde scope en volg het beleid van de organisatie voor bewaartermijnen, maskering en toegang.
Voorbeeldquery sql
WITH
params AS (
SELECT
TO_DATE('[Start date]', 'YYYYMMDD') AS start_date,
TO_DATE('[End date]', 'YYYYMMDD') AS end_date,
'[Source system identifier]' AS source_system
FROM DUMMY
),
base_bkpf AS (
SELECT
b.MANDT,
b.BUKRS,
b.BELNR,
b.GJAHR,
b.BLART,
b.BLDAT,
b.BUDAT,
b.CPUDT,
b.CPUTM,
b.USNAM,
b.STBLG,
b.STJAH,
b.XBLNR,
b.WAERS,
b.BKTXT,
p.source_system,
p.start_date,
p.end_date
FROM [Your SAP HANA schema].BKPF b
CROSS JOIN params p
WHERE b.BUDAT BETWEEN TO_VARCHAR(p.start_date, 'YYYYMMDD') AND TO_VARCHAR(p.end_date, 'YYYYMMDD')
AND [Company code filter]
),
invoice_bseg AS (
SELECT
k.MANDT,
k.BUKRS,
k.BELNR,
k.GJAHR,
k.BLART,
k.BLDAT,
k.BUDAT,
k.CPUDT,
k.CPUTM,
k.USNAM,
k.STBLG,
k.STJAH,
k.XBLNR,
k.WAERS,
k.BKTXT,
k.source_system,
s.BUZEI,
s.LIFNR,
s.WRBTR,
s.DMBTR,
s.ZTERM,
s.ZLSPR,
s.ZFBDT,
s.ZBD1T,
s.ZBD2T,
s.ZBD3T,
s.AUGDT,
s.AUGBL,
s.SHKZG,
s.SGTXT,
s.XREF1,
s.XREF2,
s.XREF3
FROM base_bkpf k
INNER JOIN [Your SAP HANA schema].BSEG s
ON s.MANDT = k.MANDT
AND s.BUKRS = k.BUKRS
AND s.BELNR = k.BELNR
AND s.GJAHR = k.GJAHR
WHERE s.LIFNR IS NOT NULL
AND s.LIFNR <> ''
),
acdoca_invoice AS (
SELECT
a.RCLNT AS MANDT,
a.RBUKRS AS BUKRS,
a.BELNR,
a.GJAHR,
a.BUZEI,
a.RACCT,
a.HSL,
a.WSL,
a.RWCUR,
a.BUDAT,
a.BLDAT,
a.AUGDT,
a.AUGBL
FROM [Your SAP HANA schema].ACDOCA a
WHERE a.BUDAT BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
AND [ACDOCA company code filter]
),
invoice_cases AS (
SELECT DISTINCT
i.MANDT,
i.BUKRS,
i.BELNR,
i.GJAHR,
i.BUZEI,
i.LIFNR,
i.WRBTR,
i.ZTERM,
i.ZLSPR,
i.ZFBDT,
i.ZBD1T,
i.ZBD2T,
i.ZBD3T,
i.AUGDT,
i.AUGBL,
i.BLART,
i.BLDAT,
i.BUDAT,
i.CPUDT,
i.CPUTM,
i.USNAM,
i.STBLG,
i.STJAH,
i.XBLNR,
i.WAERS,
i.source_system,
COALESCE(NULLIF(i.XBLNR, ''), i.BELNR) AS InvoiceNumber,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD3T, '')), 0)) AS NetDueDate,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD1T, '')), 0)) AS DiscountDueDate1,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD2T, '')), 0)) AS DiscountDueDate2
FROM invoice_bseg i
LEFT JOIN acdoca_invoice a
ON a.MANDT = i.MANDT
AND a.BUKRS = i.BUKRS
AND a.BELNR = i.BELNR
AND a.GJAHR = i.GJAHR
AND a.BUZEI = i.BUZEI
),
change_events AS (
SELECT
c.MANDT,
c.OBJECTID,
c.TABKEY,
c.FNAME,
c.VALUE_OLD,
c.VALUE_NEW,
c.UDATE,
c.UTIME,
c.USERNAME
FROM [Your SAP HANA schema].[Your change document item table name] c
WHERE c.TABNAME = 'BSEG'
AND c.FNAME IN ('ZLSPR', 'ZTERM')
AND c.UDATE BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
AND [Change document object class filter]
),
reguh_events AS (
SELECT
r.MANDT,
r.LAUFD,
r.LAUFI,
r.XVORL,
r.ZBUKR,
r.LIFNR,
r.VBLNR,
r.AUSFD,
r.AUSDT,
r.LAUFD AS RunDate,
r.ZALDT,
r.RZAWE,
r.XEINZ,
r.XPGRO,
r.XAVIS,
r.XVORL AS ProposalIndicator
FROM [Your SAP HANA schema].REGUH r
WHERE r.LAUFD BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
),
regup_events AS (
SELECT
u.MANDT,
u.LAUFD,
u.LAUFI,
u.ZBUKR,
u.LIFNR,
u.VBLNR,
u.BUKRS,
u.BELNR,
u.GJAHR,
u.BUZEI,
u.XVORL,
u.AUGBL,
u.AUGDT
FROM [Your SAP HANA schema].REGUP u
WHERE u.LAUFD BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Parked' AS Activity,
TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
i.source_system AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
i.LIFNR AS VendorNumber,
i.BUKRS AS CompanyCode,
i.WRBTR AS InvoiceAmount,
i.BLART AS DocumentType,
i.ZTERM AS PaymentTerms,
i.ZLSPR AS PaymentBlockReason,
i.USNAM AS UserName,
i.AUGDT AS ClearingDate,
i.NetDueDate,
CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END AS IsLatePayment,
FALSE AS IsTouchless
FROM invoice_cases i
INNER JOIN [Your SAP HANA schema].VBKPF v
ON v.MANDT = i.MANDT
AND v.BUKRS = i.BUKRS
AND v.BELNR = i.BELNR
AND v.GJAHR = i.GJAHR
WHERE [VBKPF parked status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Posted', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i
UNION ALL
SELECT i.InvoiceNumber, 'Payment Block Applied', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, c.VALUE_NEW, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZLSPR' AND COALESCE(c.VALUE_OLD, '') = '' AND COALESCE(c.VALUE_NEW, '') <> ''
UNION ALL
SELECT i.InvoiceNumber, 'Price Variance Detected', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.ZLSPR = 'R'
UNION ALL
SELECT i.InvoiceNumber, 'Quantity Variance Detected', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.ZLSPR = 'M'
UNION ALL
SELECT i.InvoiceNumber, 'Payment Terms Changed', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, c.VALUE_NEW, i.ZLSPR, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZTERM'
UNION ALL
SELECT i.InvoiceNumber, 'Payment Block Removed', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, c.VALUE_OLD, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZLSPR' AND COALESCE(c.VALUE_OLD, '') <> '' AND COALESCE(c.VALUE_NEW, '') = ''
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Due', TO_TIMESTAMP(TO_VARCHAR(i.NetDueDate, 'YYYYMMDD') || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.NetDueDate IS NOT NULL
UNION ALL
SELECT i.InvoiceNumber, 'Cash Discount Lost', TO_TIMESTAMP(TO_VARCHAR(CASE WHEN i.DiscountDueDate1 <= i.DiscountDueDate2 THEN i.DiscountDueDate1 ELSE i.DiscountDueDate2 END, 'YYYYMMDD') || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.AUGDT IS NULL OR i.AUGDT > CASE WHEN i.DiscountDueDate1 <= i.DiscountDueDate2 THEN i.DiscountDueDate1 ELSE i.DiscountDueDate2 END
UNION ALL
SELECT i.InvoiceNumber, 'Payment Proposal Created', TO_TIMESTAMP(r.RunDate || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN regup_events u ON u.BUKRS = i.BUKRS AND u.BELNR = i.BELNR AND u.GJAHR = i.GJAHR AND u.BUZEI = i.BUZEI INNER JOIN reguh_events r ON r.MANDT = u.MANDT AND r.LAUFD = u.LAUFD AND r.LAUFI = u.LAUFI AND r.LIFNR = u.LIFNR WHERE [Payment proposal status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Payment Run Executed', TO_TIMESTAMP(r.RunDate || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN regup_events u ON u.BUKRS = i.BUKRS AND u.BELNR = i.BELNR AND u.GJAHR = i.GJAHR AND u.BUZEI = i.BUZEI INNER JOIN reguh_events r ON r.MANDT = u.MANDT AND r.LAUFD = u.LAUFD AND r.LAUFI = u.LAUFI AND r.LIFNR = u.LIFNR WHERE [Payment run executed status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Payment Document Created', TO_TIMESTAMP(p.CPUDT || LPAD(COALESCE(p.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, p.BLART, i.ZTERM, i.ZLSPR, p.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN [Your SAP HANA schema].BKPF p ON p.MANDT = i.MANDT AND p.BUKRS = i.BUKRS AND p.BELNR = i.AUGBL AND p.GJAHR = i.GJAHR WHERE p.BLART IN ('ZP', 'KZ')
UNION ALL
SELECT i.InvoiceNumber, 'Payment Cleared', TO_TIMESTAMP(i.AUGDT || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.AUGDT IS NOT NULL
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Reversed', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.STBLG IS NOT NULL AND i.STBLG <> ''
)
SELECT
InvoiceNumber,
Activity,
EventTime,
SourceSystem,
LastDataUpdate,
VendorNumber,
CompanyCode,
InvoiceAmount,
DocumentType,
PaymentTerms,
PaymentBlockReason,
UserName,
ClearingDate,
NetDueDate,
IsLatePayment,
IsTouchless
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, Activity; Klaar om te beginnen?
Zet financiële data om in inzichten waarmee je aan de slag kunt en begin vandaag nog met het optimaliseren van betalingscycli. Ons team helpt je bij elke stap van je process mining-traject.
Verbeter de verwerking van crediteurenbetalingen in SAP S/4HANA
Verwijder bottlenecks en verkort de doorlooptijd met 30%.
Geen creditcard nodig. De installatie duurt 5 minuten.