Jouw datatemplate voor betalingsverwerking in de crediteurenadministratie
Jouw datatemplate voor betalingsverwerking in de crediteurenadministratie
- Belangrijkste attributen voor analyse van leveranciers en betalingen
- Belangrijke procesmomenten in de betalingscyclus
- Specifieke extractielogica voor SAP S/4HANA-systemen
Attributen voor crediteurenbetalingen
| Naam | Beschrijving | ||
|---|---|---|---|
| Activiteit Activity | De specifieke taak of wijziging van de eventstatus die voor de factuur is vastgelegd. | ||
| Beschrijving Dit attribuut staat voor de afzonderlijke processtappen tijdens de levenscyclus van de factuur. Het legt gebeurtenissen vast zoals het aanmaken, boeken, blokkeren, goedkeuren en vereffenen van de factuur. De activiteitsnamen zijn afgeleid van transactiet codes, vermeldingen in wijzigingslogs of workflowstatussen in het bronsysteem. Voor analyse is dit veld belangrijk voor het in kaart brengen van procesflowvarianten. Hiermee kan de process mining-engine de volgorde van stappen visualiseren, herstelwerklussen herkennen en bepalen waar het proces afwijkt van de standaardroute. Het is het kernelement van het event log. Waarom dit belangrijk is Het bepaalt de knooppunten in de procesmap en maakt workflows en bottlenecks zichtbaar. Waar je het vindt Afgeleid van transactietcodes (TCODE) of de kop (CDHDR) en het item (CDPOS) van wijzigingsdocumenten Voorbeelden Factuur geboektBetaalblokkade toegepastBetaalrun uitgevoerdFactuur verwerkt | |||
| Eventtijd EventTime | De exacte timestamp waarop de activiteit plaatsvond. | ||
| Beschrijving Event Time legt de exacte datum en tijd vast waarop een activiteit in de SAP-database is verwerkt. Deze timestamp levert de tijdsdimensie die nodig is om gebeurtenissen binnen een case in de juiste volgorde te zetten. Meestal wordt de timestamp samengesteld uit de CPU Date- en CPU Time-velden uit systeemlogs of documentkoppen. In analyses is dit attribuut essentieel voor het berekenen van doorlooptijden, duur en throughput. Je kunt er tijdsverschillen tussen stappen mee meten, zoals de tijd tussen factuurontvangst en definitieve goedkeuring. Dat helpt bij het vinden van bottlenecks en het beoordelen van KPI’s zoals Average Invoice Approval Time. Waarom dit belangrijk is Het bepaalt de chronologische volgorde van gebeurtenissen en vormt de basis voor alle tijdgebaseerde prestatieberekeningen. Waar je het vindt SAP-tabel BKPF, veld 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 | |||
| Factuurnummer InvoiceNumber | De unieke identificatie van de leveranciersfactuur die wordt verwerkt. | ||
| Beschrijving Het Invoice Number is de primaire sleutel voor het volgen van de levenscyclus van een te betalen post binnen het SAP S/4HANA-systeem. Het verwijst specifiek naar het nummer van het boekhoudkundige document dat wordt gegenereerd wanneer de factuur in het grootboek wordt geboekt. In de standaardterminologie van SAP komt dit overeen met het Document Number (BELNR) binnen een specifieke Company Code en een specifiek boekjaar. In procesanalyse dient dit attribuut als Case ID. Het koppelt alle afzonderlijke activiteiten, van de eerste ontvangst en het parkeren van de factuur tot verschillende goedkeuringsblokkades en wijzigingen en uiteindelijk de vereffeningsbetaling. Door gebeurtenissen op basis van deze identificatie te groeperen, kunnen analisten de volledige end-to-endgeschiedenis van elke betalingsverplichting reconstrueren. Waarom dit belangrijk is Het dient als de definitieve Case ID, waarmee je de volledige betalingsprocesflow van begin tot eind kunt reconstrueren. Waar je het vindt SAP-tabel BKPF (kop van boekhoudkundig document), veld BELNR, of ACDOCA-veld BELNR Voorbeelden 1900000523510000289119000006015100003002 | |||
| Bronsysteem SourceSystem | De identificatie van de SAP S/4HANA-instantie waaruit de data afkomstig is. | ||
| Beschrijving Dit attribuut identificeert de specifieke ERP-installatie of client waaruit de procesdata is geëxtraheerd. In omgevingen met meerdere SAP-instanties of legacy-systemen die naast elkaar draaien, zorgt dit veld ervoor dat de herkomst van de data behouden blijft en dat je systemen kunt vergelijken. Voor analyses werkt dit veld als filter op hoofdniveau. Analisten kunnen data ermee scheiden bij het vergelijken van prestaties tussen regionale systeeminstallaties of bij het controleren van dataconsistentie tijdens migratieprojecten. Zo worden procesvariaties die door de systeemconfiguratie ontstaan in de juiste context geplaatst. Waarom dit belangrijk is Het onderscheidt databronnen in omgevingen met meerdere systemen, zodat je data correct kunt segmenteren. Waar je het vindt Systeem-ID (SY-SYSID) uit de SAP-installatiecontext Voorbeelden SAP_PROD_01S4H_NA_100ERP_EU_200 | |||
| Laatste data-update LastDataUpdate | De timestamp die aangeeft wanneer de record voor het laatst is geëxtraheerd of vernieuwd. | ||
| Beschrijving Last Data Update markeert het moment waarop de data succesvol in het process mining-platform is geladen. Het geeft niet aan wanneer de bedrijfsgebeurtenis plaatsvond, maar hoe actueel de dataset is. Dat is belangrijk om vertrouwen in de analyticsdashboards te behouden. In analyses helpt dit attribuut gebruikers te begrijpen hoe actueel de informatie is. Het is vooral relevant voor dashboards die bijna realtime worden bijgewerkt, zoals Payment Block Analysis. Zo baseer je beslissingen op de meest recente status van het SAP S/4HANA-systeem. Waarom dit belangrijk is Het laat zien hoe actueel de data is, wat belangrijk is voor operationele dashboards. Waar je het vindt Gegenereerd door het ETL-/extractieproces Voorbeelden 2023-10-27T23:59:59.000Z2023-11-01T06:00:00.000Z | |||
| Bedrijfsnummer CompanyCode | De organisatorische eenheid waarvoor de balans en winst-en-verliesrekening worden opgesteld. | ||
| Beschrijving De Company Code staat voor de zelfstandige boekhoudkundige entiteit binnen de organisatie. Het is de centrale organisatorische eenheid voor externe verslaglegging en wordt gebruikt om financiële data te structureren. Elke factuur is aan precies één Company Code toegewezen. In analyses maakt dit attribuut het mogelijk om KPI’s per juridische entiteit of regio te segmenteren. In dashboards kun je de efficiëntie van Accounts Payable-teams bij verschillende dochterondernemingen vergelijken. Zo zie je bijvoorbeeld of een specifieke vestiging vaker handmatige betaalblokkades heeft dan de concernstandaard. Waarom dit belangrijk is Het segmenteert het proces per juridische entiteit en maakt interne benchmarking mogelijk. Waar je het vindt SAP-tabel BKPF, veld BUKRS Voorbeelden US01DE1010002000 | |||
| Betalingsvoorwaarden PaymentTerms | De sleutel voor de afgesproken betalingsvoorwaarden en kortingen. | ||
| Beschrijving Betalingsvoorwaarden bepalen wanneer een factuur vervalt en of er een betalingskorting geldt bij vroeg betalen. Deze code, bijvoorbeeld 'Z001', verwijst naar regels zoals 'Netto 30' of '2% 10, netto 30'. De code wordt overgenomen uit de leveranciersstamgegevens naar de factuur, maar kan handmatig worden aangepast. In analyses is dit attribuut de basis voor de dashboards voor optimalisatie van betalingskortingen en naleving van betalingsvoorwaarden bij leveranciers. Hiermee kan het systeem de oorspronkelijke vervaldatum berekenen en bepalen of de betaling binnen de optimale periode is uitgevoerd om de korting te ontvangen. Waarom dit belangrijk is Het bepaalt de verwachte termijn en financiële voordelen en is belangrijk voor analyses van kortingen. Waar je het vindt SAP-tabel BSEG-veld ZTERM Voorbeelden Z001NT300001 | |||
| Clearingdatum ClearingDate | De datum waarop de factuur door betaling is vereffend. | ||
| Beschrijving De clearingdatum registreert wanneer de openstaande post in de crediteurenadministratie is vereffend, meestal via een betaalrun of een handmatige betalingsboeking. Daarmee eindigt de verplichting feitelijk. In analyses wordt dit attribuut gebruikt om de uiteindelijke doorlooptijd van het proces te berekenen. Het is de timestamp voor de activiteit 'Betaling vereffend' en wordt vergeleken met de uiterste betaaldatum om de prestaties van tijdige betalingen te bepalen. De data wordt rechtstreeks gebruikt in het dashboard voor efficiëntie van betalingsvereffening. Waarom dit belangrijk is Het markeert het einde van het betalingsproces en wordt gebruikt om te bepalen of de betaling op tijd was. Waar je het vindt SAP-tabel BSEG of veld AUGDT Voorbeelden 2023-11-012023-11-15 | |||
| Documenttype DocumentType | Classificeert het boekhoudkundige document, bijvoorbeeld leveranciersfactuur, betaling of creditnota. | ||
| Beschrijving Het documenttype is een code van twee tekens in SAP waarmee de boekhoudkundige transactie wordt geclassificeerd. Veelvoorkomende typen zijn 'KR' voor leveranciersfacturen, 'KZ' voor betalingen aan leveranciers en 'RE' voor bruto ontvangst van een factuur. Het bepaalt het nummerbereik en de veldstatus van het document. In analyses wordt dit attribuut gebruikt om de procesomvang te filteren. Een analist kan bijvoorbeeld creditnota's uitsluiten om alleen de efficiëntie van uitgaande betalingen te bekijken. Het helpt ook om de verdeling van verwerkte transactietypen te bepalen en ondersteunt het dashboard voor complexiteit van procesvarianten. Waarom dit belangrijk is Het classificeert de case, bijvoorbeeld als factuur of creditnota, zodat je gerichte analyses kunt uitvoeren. Waar je het vindt 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 meestal opgeslagen in het veld Amount in Document Currency. In analyses gebruik je het Invoice Amount om werk te prioriteren. Dashboards zoals Manual Touch Point Distribution laten hiermee zien of veel handmatig werk wordt besteed aan facturen met een lage waarde. Zo kan de organisatie verbeteringen richten op transacties met een hoge waarde, waar procesfouten een groter financieel risico vormen. Waarom dit belangrijk is Het geeft het financiële gewicht van de case weer en helpt bij het prioriteren van inefficiënties in processen met een hoge waarde. Waar je het vindt 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 login-ID van de persoon of systeemagent die verantwoordelijk is voor een processtap. Dat kan een gebruiker zijn die handmatig data invoert, maar ook een ID van een achtergrondtaak, zoals 'BATCH_USER', die geautomatiseerde taken uitvoert. In analyses kun je met dit attribuut het automatiseringspercentage van activiteiten berekenen. Door menselijke gebruikers en systeemaccounts van elkaar te onderscheiden, kunnen analisten het automatiseringsniveau van het proces meten. Het wordt ook gebruikt in het dashboard voor de verdeling van handmatige contactmomenten, om de werkdruk over teams te beoordelen. Waarom dit belangrijk is Het maakt onderscheid tussen handmatig en geautomatiseerd werk, zodat je het automatiseringspercentage kunt berekenen. Waar je het vindt SAP-tabel BKPF-veld USNAM of CDHDR-veld USERNAME Voorbeelden BSMITHWF-BATCHRJONES | |||
| Is te late betaling IsLatePayment | Een booleaanse vlag die aangeeft of de betaling na de uiterste betaaldatum is uitgevoerd. | ||
| Beschrijving Dit berekende attribuut is waar als de clearingdatum na de uiterste betaaldatum ligt. Het is een binaire classificatie van de procesprestaties. In analyses wordt deze vlag gebruikt om het aantal niet-conforme cases te tellen voor de KPI voor de frequentie van boetes door te late betaling. Je kunt in een dashboard eenvoudig de waarden 'Waar' tellen, zonder complexe datumformules in de visualisatielaag. Waarom dit belangrijk is Het vereenvoudigt de berekening van KPI's voor tijdige betalingen. Waar je het vindt Berekend: clearingdatum > uiterste betaaldatum Voorbeelden truefalse | |||
| Is zonder handmatige tussenkomst IsTouchless | Een booleaanse vlag die aangeeft of de factuur zonder handmatige tussenkomst is verwerkt. | ||
| Beschrijving Dit attribuut wordt berekend door de eventstroom van een case te analyseren. Als de case alleen geautomatiseerde activiteiten bevat, bijvoorbeeld met gebruiker 'system' of specifieke achtergrond-TCODES, en geen handmatige wijzigingen of blokkades bevat, wordt de case als zonder handmatige tussenkomst gemarkeerd. In analyses is dit de belangrijkste meting voor de KPI voor het percentage facturen zonder handmatige tussenkomst. De organisatie kan hiermee het resultaat van automatiseringsinitiatieven volgen en bepalen welke typen cases, bijvoorbeeld per leverancier of regio, zonder menselijke tussenkomst door het systeem lopen. Waarom dit belangrijk is Het is de belangrijkste maatstaf voor procesautomatisering en efficiëntie. Waar je het vindt Berekend op basis van de volgorde van activiteiten en gebruikerstypen Voorbeelden truefalse | |||
| Leveranciersnummer VendorNumber | De unieke identificatie van de leverancier die bij de factuur hoort. | ||
| Beschrijving Het Vendor Number verwijst naar de specifieke crediteurenrekening in het SAP-subgrootboek. Het koppelt de factuur aan de stamgegevens met betalingstermijnen, bankgegevens en contactinformatie. In S/4HANA is dit vaak gekoppeld aan het Business Partner-concept, maar in veel tabellen blijft de oude veldnaam LIFNR behouden. In analyses is dit attribuut de basis voor het dashboard Vendor Payment Term Compliance. Analisten kunnen procesprestaties per leverancier samenvoegen en leveranciers herkennen die regelmatig blokkades, prijsafwijkingen of vertragingen veroorzaken. Dit ondersteunt beslissingen over strategische inkoop en leveranciersrelatiebeheer. Waarom dit belangrijk is Het maakt het mogelijk om prestaties per leverancier te bundelen, wat belangrijk is om de oorzaken van vertragingen te vinden. Waar je het vindt SAP-tabel BKPF, veld LIFNR, of ACDOCA-veld LIFNR Voorbeelden 100050VEND-US-99200400 | |||
| Reden voor betalingsblokkade PaymentBlockReason | De code die aangeeft waarom een factuur is geblokkeerd voor betaling. | ||
| Beschrijving Dit attribuut bevat de specifieke reden voor de blokkade van een factuur, waardoor de automatische betaalrun de factuur niet kan meenemen. Voorbeelden zijn 'A' voor geblokkeerd voor betaling, 'R' voor factuurcontrole of handmatige blokkades die gebruikers instellen. In analyses is dit veld de belangrijkste basis voor het dashboard voor analyse van handmatige betalingsblokkades. Door de verschillende blokkeringsredenen te tellen, kan de organisatie structurele problemen opsporen, zoals terugkerende prijsverschillen of ontbrekende goederenontvangsten die het betalingsproces vertragen. Waarom dit belangrijk is Het laat zien waardoor het proces precies stilvalt, zodat je gericht naar de oorzaak kunt zoeken. Waar je het vindt SAP-tabel BSEG-veld ZLSPR Voorbeelden ABR* | |||
| Uiterste betaaldatum NetDueDate | De berekende datum waarop de factuur uiterlijk moet zijn betaald om boetes te voorkomen. | ||
| Beschrijving De uiterste betaaldatum is de definitieve deadline voor betaling. Je berekent deze door het maximale aantal betalingsdagen op te tellen bij de basisdatum. Soms wordt deze datum expliciet opgeslagen, maar in analyseweergaven is het vaak een berekend veld. In analyses is dit de belangrijkste referentie voor de tracker voor te late betalingen en boetes. Door de werkelijke clearingdatum te vergelijken met de uiterste betaaldatum, ontstaat de meting 'Dagen te laat betaald'. Daarmee kun je de efficiëntie van het crediteurenteam en het risico op problemen met leveranciers in kaart brengen. Waarom dit belangrijk is Het is de deadline voor het proces. Als je die mist, kan dat gevolgen hebben voor de kredietwaardigheid en extra kosten veroorzaken. Waar je het vindt Berekend: basisdatum + maximaal aantal betalingsdagen (ZBD1T/ZBD2T/ZBD3T) Voorbeelden 2023-11-302023-12-01 | |||
| Basisdatum BaselineDate | De datum vanaf wanneer de betalingsvoorwaarden gelden en vervaldatums worden berekend. | ||
| Beschrijving De basisdatum is het startpunt voor de berekening van de uiterste betaaldatum en de perioden voor betalingskorting. Meestal is dit de factuurdatum of boekingsdatum, afhankelijk van de configuratie en de leveranciersstamgegevens. In analyses is deze datum nodig om de status 'Te laat' te berekenen. Fouten in de basisdatum leiden vaak tot te vroege betalingen, met gevolgen voor de kasstroom, of tot te late betalingen, met mogelijke boetes. Het controleren van deze datum maakt deel uit van de analyse van naleving van betalingsvoorwaarden bij leveranciers. Waarom dit belangrijk is Het is het uitgangspunt voor alle berekeningen van vervaldatums. Waar je het vindt SAP-tabel BSEG-veld ZFBDT Voorbeelden 2023-10-012023-10-15 | |||
| Bedrag van gemiste korting DiscountLostAmount | De geldwaarde van betalingskortingen die beschikbaar waren, maar niet zijn gebruikt. | ||
| Beschrijving Dit berekende attribuut staat voor het geld dat is blijven liggen. Het wordt bepaald door te controleren of de betaling na de kortingsdeadline is uitgevoerd. Als dat zo is, wordt de waarde van de gemiste korting over het factuurbedrag berekend. In analyses is dit een belangrijke financiële meting voor de optimalisatie van betalingskortingen. Het maakt de kosten van inefficiëntie in concrete bedragen zichtbaar en onderbouwt de businesscase voor procesverbetering. Waarom dit belangrijk is Het maakt het directe financiële verlies door vertragingen in het proces meetbaar. Waar je het vindt Berekend: als clearingdatum > kortingsdatum, dan factuurbedrag * kortingspercentage Voorbeelden 30.000.00150.00 | |||
| Boekjaar FiscalYear | Het financiële jaar waartoe de factuur behoort. | ||
| Beschrijving Het boekjaar is de periode die voor financiële rapportages wordt gebruikt. Samen met het bedrijfsnummer en documentnummer vormt het de samengestelde primaire sleutel van een financieel document in SAP. In analyses is dit technisch nodig om cases uniek te identificeren. Het ondersteunt ook vergelijkingen tussen jaren. Zo blijft de case-ID 'Factuurnummer' uniek over tientallen jaren aan historische data. Waarom dit belangrijk is Technische vereiste voor unieke case-identificatie in SAP FI. Waar je het vindt SAP-tabel BKPF-veld GJAHR Voorbeelden 20232024 | |||
| Dagen voor betalingskorting 1 CashDiscountDays1 | Het aantal dagen vanaf de basisdatum waarin de eerste betalingskorting beschikbaar is. | ||
| Beschrijving Dit attribuut bepaalt de periode voor de gunstigste betalingsvoorwaarden, bijvoorbeeld '10' in '2% 10, netto 30'. De waarde komt uit de voorwaarden die in de factuurregel zijn opgeslagen. In analyses helpt dit om de 'Doeldatum' voor de optimalisatie van betalingskortingen te bepalen. Als de factuur binnen deze periode wordt vereffend, wordt de korting ontvangen. Met dit veld kun je de gemiste besparing door trage verwerking meten. Waarom dit belangrijk is Het bepaalt de periode waarin je financiële besparingen kunt realiseren. Waar je het vindt 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) waartegen de factuur wordt gecontroleerd. Niet elke factuur, bijvoorbeeld voor diverse kosten, heeft een verwijzing naar een inkooporder. In analyses is dit veld belangrijk voor de analyse van het three-way-matchpercentage. Analisten kunnen hiermee facturen met en zonder inkooporder van elkaar onderscheiden. Die hebben meestal heel verschillende goedkeuringsworkflows. Het ondersteunt ook end-to-end process mining door data uit crediteurenadministratie te koppelen aan inkoopdata. Waarom dit belangrijk is Het koppelt crediteurenadministratie aan inkoop en maakt analyse van three-way matching en uitbreiding van het proces mogelijk. Waar je het vindt SAP-tabel BSEG-veld EBELN Voorbeelden 45000012344500009876 | |||
| Percentage betalingskorting 1 CashDiscountPercentage1 | Het kortingspercentage dat beschikbaar is als je binnen de eerste kortingsperiode betaalt. | ||
| Beschrijving Dit attribuut staat voor het financiële voordeel dat de leverancier biedt bij vroeg betalen, bijvoorbeeld '2' in '2% 10'. In analyses wordt het gebruikt om de waarde 'Mogelijke betalingskorting' te berekenen. Door dit percentage met het factuurbedrag te vermenigvuldigen, laten de dashboards zien hoeveel geld verloren gaat door inefficiënte processen. Dat ondersteunt de businesscase voor automatisering. Waarom dit belangrijk is Het maakt de mogelijke besparing meetbaar en is belangrijk voor ROI-berekeningen. Waar je het vindt SAP-tabel BSEG-veld ZBD1P Voorbeelden 2.03.00.0 | |||
| Valuta Currency | De valutacode die bij het factuurbedrag hoort. | ||
| Beschrijving Het attribuut Valuta geeft aan in welke valuta het factuurbedrag is uitgedrukt, zoals USD, EUR of GBP. Zo kunnen financiële waarden correct worden geïnterpreteerd. Dat is belangrijk bij het samenvoegen van data uit verschillende internationale bedrijfsnummers. In analyses zorgt dit veld ervoor dat financiële KPI's correct worden berekend. Vaak wordt het gebruikt om waarden om te rekenen naar een rapportagevaluta voor wereldwijde dashboards. Zonder dit attribuut hebben geaggregeerde metingen zoals totale uitgaven of de gemiddelde factuurwaarde geen betekenis in een omgeving met meerdere valuta. Waarom dit belangrijk is Het geeft context bij financiële bedragen en is nodig voor betrouwbare wereldwijde rapportages. Waar je het vindt SAP-tabel BKPF-veld WAERS Voorbeelden USDEURGBPJPY | |||
Activiteiten voor crediteurenbetalingen
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Betaalblokkade toegepast | Geeft aan dat op de factuurregel een betaalblokkade is ingesteld, waardoor de factuur niet in de betaalrun wordt meegenomen. Dit wordt vastgelegd door wijzigingen in het veld ZLSPR in de BSEG-tabel via wijzigingsdocumenten te volgen. | ||
| Waarom dit belangrijk is Blokkades zijn de belangrijkste oorzaak van te late betalingen en procesfrictie. Ze hebben rechtstreeks invloed op het dashboard Manual Payment Block Analysis. Waar je het vindt CDPOS- en CDHDR-tabellen (wijzigingsdocumenten), waarbij wordt gezocht naar updates van het veld BSEG-ZLSPR. Vastleggen Vastgelegd wanneer CDPOS-records in ZLSPR wijzigen Eventtype explicit | |||
| Betaalblokkade verwijderd | Geeft aan dat een eerder toegepaste betaalblokkade is opgeheven, waardoor de factuur kan worden betaald. Dit wordt herkend wanneer het veld ZLSPR in BSEG van een waarde verandert naar null of leeg. | ||
| Waarom dit belangrijk is Dit dient vaak als alternatief voor 'Invoice Approved' in systemen zonder expliciete workflowlogs en markeert het einde van de periode met het bottleneck. Waar je het vindt CDPOS- en CDHDR-tabellen, waarbij wordt gezocht naar een wijziging van BSEG-ZLSPR naar leeg. Vastleggen Vastgelegd wanneer CDPOS de verwijdering van ZLSPR registreert Eventtype explicit | |||
| Betaalrun uitgevoerd | Staat voor de uitvoering van de betaalrun waarin betaalinstructies worden gegenereerd. Dit wordt gevolgd via de statusupdate in de REGUH- of REGUP-tabellen. | ||
| Waarom dit belangrijk is De operationele toezegging om te betalen, belangrijk voor het analyseren van de efficiëntie van het bundelen van betalingen. Waar je het vindt REGUH-tabel, meestal gekoppeld aan de uitvoerdatum en identificatie van de run. Vastleggen Vastgelegd wanneer de status van de betaalrun wordt bijgewerkt Eventtype explicit | |||
| Betaling vereffend | Markeert de definitieve afstemming waarbij de openstaande post op de leveranciersrekening met de betaling wordt vereffend. Dit wordt vastgelegd via het veld AUGDT (clearingdatum) in de BSEG-tabel. | ||
| Waarom dit belangrijk is De eindstatus van het proces. Dit geeft aan dat de levenscyclus is afgerond en de boekhouding in balans is. Een hoog percentage handmatige clearing wijst op inefficiënties bij de afstemming. Waar je het vindt BSEG-tabel, veld AUGDT (clearingdatum). Vastleggen Vastgelegd wanneer het veld AUGDT is gevuld Eventtype explicit | |||
| Betalingsdocument aangemaakt | Het aanmaken van het boekhoudkundige document dat de bank crediteert en de leverancier debiteert. Dit is terug te vinden in BKPF met een documenttype voor betalingen, zoals ZP of KZ. | ||
| Waarom dit belangrijk is De financiële uitvoering van de betaling, gebruikt om Days Payable Outstanding (DPO) te berekenen. Waar je het vindt BKPF-tabel, gefilterd op Document Type (BLART) dat specifiek is voor betalingen. Vastleggen Vastgelegd wanneer het betalingsdocument in BKPF is aangemaakt Eventtype explicit | |||
| Factuur geboekt | Dit staat voor de officiële vastlegging van de verplichting in het grootboek. De activiteit wordt afgeleid van de aanmaaktimestamp in de BKPF-tabel of de invoerdatum in de ACDOCA-tabel. | ||
| Waarom dit belangrijk is Dit is het primaire startpunt van de financiële tijdlijn en vormt de basis voor vervaldatums en ouderdomsanalyses. Waar je het vindt BKPF-tabel, met CPUDT (invoerdatum) en CPUTM (invoertijd). Vastleggen Vastgelegd wanneer de BKPF-record is aangemaakt Eventtype explicit | |||
| Betalingskorting gemist | Een berekende gebeurtenis die de datum markeert waarop het recht op betalingskorting vervalt. Dit wordt bepaald door de kortingsvervaldatum te vergelijken met de huidige datum of de betaaldatum. | ||
| Waarom dit belangrijk is Belangrijk voor de Early Payment Discount Optimizer, die gemiste financiële kansen zichtbaar maakt. Waar je het vindt Berekend als: BSEG-ZFBDT + BSEG-ZBD1T (kortingsdagen 1). Vastleggen Afgeleid door de datum te vergelijken met de kortingsvervaldatum Eventtype calculated | |||
| Betalingstermijnen gewijzigd | Legt een wijziging vast van de betalingstermijnen van een openstaande factuur, waardoor de vervaldatum of de mogelijkheid op korting verandert. Dit wordt gevolgd via wijzigingslogs voor het veld ZTERM in de BSEG-tabel. | ||
| Waarom dit belangrijk is Veelvuldige wijzigingen wijzen mogelijk op fouten in stamgegevens of handmatige overschrijvingen die de kasstroomprognose en Vendor Payment Term Compliance beïnvloeden. Waar je het vindt CDPOS- en CDHDR-tabellen, waarbij wordt gezocht naar updates van het veld BSEG-ZTERM. Vastleggen Vastgelegd wanneer CDPOS-records in ZTERM wijzigen Eventtype explicit | |||
| Betalingsvoorstel aangemaakt | Geeft aan dat de factuur is opgenomen in een betalingsvoorstelrun (F110), de eerste stap van het geautomatiseerde betaalprogramma. Dit wordt vastgelegd vanuit de REGUH-tabel, waarin vereffeningsgegevens worden opgeslagen. | ||
| Waarom dit belangrijk is Geeft aan dat de factuur voor betaling is geselecteerd en de validatiecontroles binnen het betaalprogramma heeft doorlopen. Waar je het vindt Aanmaaktimestamp van de REGUH-tabel (sleutels LAUFD en LAUFI). Vastleggen Vastgelegd wanneer de REGUH-record is aangemaakt Eventtype 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 data-invoer. De activiteit wordt expliciet vastgelegd vanuit de VBKPF-tabel of door documenten in BKPF met een statuscode voor geparkeerde documenten te herkennen voordat ze worden geboekt. | ||
| Waarom dit belangrijk is Parkeren markeert het begin van de data-invoerfase en helpt de vertraging tussen ontvangst en het ontstaan van de financiële verplichting te meten. Waar je het vindt VBKPF-tabel voor kopgegevens van geparkeerde documenten of BKPF met een specifieke documentstatus (BSTAT = V). Vastleggen Vastgelegd wanneer de VBKPF-record is aangemaakt Eventtype explicit | |||
| Factuur teruggedraaid | Geeft aan dat het factuurdocument is teruggedraaid of geannuleerd. Dit wordt vastgelegd door het veld STBLG (terdraaiingsdocument) in de BKPF-tabel te controleren. | ||
| Waarom dit belangrijk is Staat voor herstelwerk en procesfalen en brengt verspilling en mogelijk dubbel werk in beeld. Waar je het vindt BKPF-tabel, veld STBLG is niet leeg. Vastleggen Vastgelegd wanneer het veld STBLG is gevuld Eventtype explicit | |||
| Factuur vervalt | Een berekende timestamp die het moment aangeeft waarop de factuur de nettovervaldatum bereikt. Deze wordt berekend door het aantal dagen van de betalingstermijn op te tellen bij de basisdatum in de BSEG-tabel. | ||
| Waarom dit belangrijk is Dient als referentiepunt voor On-Time Payment Performance en Late Payment Penalty Tracker. Waar je het vindt Berekend als: BSEG-ZFBDT (basisdatum) + BSEG-ZBD1T/ZBD2T/ZBD3T (dagen). Vastleggen Afgeleid door de huidige datum te vergelijken met de nettovervaldatum Eventtype calculated | |||
| Hoeveelheidsafwijking gedetecteerd | Afgeleide activiteit die wijst op een verschil tussen de gefactureerde hoeveelheid en de ontvangen hoeveelheid. Dit wordt afgeleid uit een specifieke Payment Block Key, meestal 'M' voor Quantity Variance, die op de factuurregel is toegepast. | ||
| Waarom dit belangrijk is Belangrijk voor het analyseren van matchingeffectiviteit en de datakwaliteit in de supply chain. Waar je het vindt Afgeleid uit de waarde 'M' van BSEG-ZLSPR, of uit de systeemspecifieke configuratie voor hoeveelheidsblokkades. Vastleggen Vergelijk de waarde van ZLSPR met 'M' Eventtype inferred | |||
| Prijsafwijking gedetecteerd | Afgeleide activiteit die wijst op een verschil tussen de factuurprijs en de prijs op de inkooporder. Dit wordt afgeleid uit een specifieke Payment Block Key, meestal 'R' voor Invoice Verification, die automatisch bij het boeken wordt toegepast. | ||
| Waarom dit belangrijk is Brengt de oorzaken van handmatig herstelwerk in beeld en ondersteunt de Three Way Match Rate Analysis. Waar je het vindt Afgeleid uit de waarde 'R' van BSEG-ZLSPR, of uit de systeemspecifieke configuratie voor prijsblokkades, op het moment van boeken. Vastleggen Vergelijk de waarde van ZLSPR met 'R' Eventtype inferred | |||
Extractiegidsen
Stappen
Identificeer de benodigde CDS-views: Controleer of de standaard-CDS-views van SAP S/4HANA beschikbaar zijn. De belangrijkste benodigde views zijn I_JournalEntry (kop), I_OperationalAcctgDocItem (items, equivalent van BSEG), I_SupplierInvoice (logistiek), I_PaymentProposalItem (F110) en I_ChangeDocument (voor logs).
Configureer gebruikersrechten: Zorg dat de databasegebruiker of technische servicegebruiker SELECT-rechten heeft op de DDL SQL-views die bij de CDS-entiteiten horen. Dit beheer je meestal via SAP HANA Studio of de ABAP Eclipse Development Tools (ADT).
Bereid de SQL-omgeving voor: Open je SQL-interface, bijvoorbeeld SAP HANA Studio, DBeaver met een HANA-verbinding of een process mining-connector die SQL accepteert. Deze methode gaat uit van directe SQL-toegang tot de HANA-laag, waar de CDS-views als views beschikbaar zijn.
Bepaal de scope: Bepaal de Company Code (CompanyCode) en het bereik van de boekjaren om de hoeveelheid data te beperken. Dit is belangrijk voor de prestaties bij het opvragen van de view met items van operationele boekingsdocumenten.
Implementeer de activiteitenlogica: Kopieer de SQL-query hieronder. Deze query gebruikt UNION ALL om 14 afzonderlijke logicaonderdelen te combineren tot één event log-structuur. Elk onderdeel richt zich op een specifieke activiteit, zoals Invoice Posted of Payment Cleared.
Verwerk wijzigingsdocumenten: De query bevat onderdelen voor wijzigingen in betalingsvoorwaarden en betalingsblokkades. Hiervoor wordt de view I_ChangeDocument gebruikt. Als deze view niet actief is in jouw S/4-release, moet je de onderliggende tabellen CDHDR/CDPOS mogelijk opnemen in een aangepaste CDS-view.
Controleer berekende events: Bekijk de logica voor Invoice Due en Cash Discount Lost. Dit zijn berekende events die ontstaan door dagen op te tellen bij de basisdatum uit de view met operationele items.
Voer de extractie uit: Voer de query uit. Bij grote datasets is het sterk aan te raden de extractie op te delen per boekjaar of Company Code, zodat geheugenproblemen worden voorkomen.
Controleer de datumindeling: Zorg dat de kolom EventTime de indeling YYYY-MM-DD HH:MM:SS heeft. SAP HANA SQL geeft timestamps terug die je, afhankelijk van je doelapplicatie, mogelijk moet casten.
Exporteer de data: Sla de resultatenset op als CSV- of Parquet-bestand. Controleer of de kopteksten overeenkomen met de kolommen in de uiteindelijke SELECT-instructie.
Zet de data klaar voor upload: Als je process mining-tool een specifiek CSV-formaat vereist, bijvoorbeeld een specifieke datumnotatie, pas je deze transformaties toe in een nabewerkingsscript of in SQL met TO_VARCHAR-functies.
Voer de eindcontrole uit: Laad een steekproef in ProcessMind en controleer of de Case ID (factuurnummer) alle activiteiten van boeken tot clearing correct groepeert.
Configuratie
- Filter op Company Code: Beperk de query tot specifieke organisatie-eenheden (CompanyCode = '1000') om context en prestaties te behouden.
- Datumbereik: Pas een filter toe op PostingDate of CreationDate, bijvoorbeeld de afgelopen 12 maanden, om de hoeveelheid data beheersbaar te houden.
- Rekeningtype: Filter I_OperationalAcctgDocItem op FinancialAccountType = 'K' (leverancier) om grootboek- en klantregels uit te sluiten.
- Activering van CDS-views: Controleer of de views I_JournalEntry, I_OperationalAcctgDocItem en I_PaymentProposalItem actief zijn en zijn vrijgegeven voor SQL-toegang.
- Prestaties van wijzigingslogs: Een query op I_ChangeDocument kan veel bronnen gebruiken. Beperk deze subqueries met ObjectClass 'BELEG' en specifieke veldnamen zoals ZLSPR en ZTERM.
a 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 directe SQL-toegang beschikbaar is tot het SAP HANA-schema met ACDOCA, BKPF, BSEG, VBKPF, REGUH, REGUP en de relevante tabellen voor wijzigingsdocumenten. Vervang [Your SAP HANA schema] en de verbindingsgegevens door waarden die voor jouw systeem zijn goedgekeurd.
- Bevestig de factuurpopulatie en rapportageperiode. Stel [Start date] en [End date] in op de indeling YYYYMMDD en configureer [Company code filter] als een geldige SQL-predicate, zoals BUKRS IN ('1000','2000').
- Controleer de SAP-release en lokale configuratie voor geparkeerde documenten, statusvelden van het betaalprogramma, typen betalingsdocumenten en opslag van wijzigingsdocumenten. De query gebruikt gedocumenteerde bronobjecten en voorzichtige veldkoppelingen, maar lokale uitbreidingen en releaseverschillen moet je vóór productiegebruik controleren.
- Voer de query uit op SAP HANA met een goedgekeurde SQL-client of extractieservice. De query maakt één eventregel aan voor elke expliciet geëxtraheerde activiteit. ProcessMind leidt geen activiteiten af die niet in het resultaat staan.
- Controleer de brondata en pas de gemarkeerde configuratiepredicates aan voor de parkeerstatus, typen betalingsdocumenten, status van betalingsvoorstellen en betaalruns en objectklassen van wijzigingsdocumenten. Maak deze predicates niet ruimer zonder dubbele of niet-gerelateerde boekingsdocumenten te controleren.
- Controleer de joins met InvoiceNumber, CompanyCode, boekjaar, nummer van het boekingsdocument, leveranciersnummer en regelitem waar dat van toepassing is. Controleer of factuurnummers in het doelsysteem consistent voorkomen in BKPF, BSEG, ACDOCA, REGUH en REGUP.
- Controleer de berekende events. Invoice Due wordt aangemaakt op de berekende uiterste betaaldatum. Cash Discount Lost wordt aangemaakt op de vroegste toepasselijke kortingsdeadline als er vóór die deadline geen betaling heeft plaatsgevonden. Dit zijn afgeleide regels. Houd ze duidelijk gescheiden van events uit bronrecords.
- Exporteer het resultaat als een vlak UTF-8-CSV-bestand of een ander door ProcessMind ondersteund tabelindeling. Behoud exact de kolomnamen InvoiceNumber, Activity, EventTime, SourceSystem en LastDataUpdate. Houd één regel per event aan en aggregeer activiteiten niet per factuur.
- Upload het event log naar ProcessMind. Koppel InvoiceNumber als case-identificatie, Activity als activiteitnaam en EventTime als event timestamp. Koppel de overige kolommen als event- of case-attributen volgens de importconfiguratie van ProcessMind.
Configuratie
- Datumbereik: Gebruik voor de eerste extractie een voortschrijdende periode van 3 tot 6 maanden. Gebruik predicates voor boekingsdatum, wijzigingsdatum en datum van het betaalprogramma consequent en breid het bereik uit bij de controle van lange betalingstermijnen.
- Schema: Vervang [Your SAP HANA schema] door het schema dat eigenaar is van de SAP-objecten. Controleer of de omgeving cliëntafhankelijke objecten via het geselecteerde schema beschikbaar maakt of dat je een expliciete client-predicate nodig hebt.
- Filter op bedrijf: Configureer [Company code filter] om BUKRS te beperken tot de benodigde bedrijfscodes. Pas dezelfde scope toe op BKPF, BSEG, ACDOCA, REGUH, REGUP en bronnen voor wijzigingsdocumenten waar die velden beschikbaar zijn.
- Documentfiltering: Controleer de predicate voor het factuurdocumenttype en die voor het betalingsdocumenttype. De query bevat gangbare voorbeelden, maar documenttypen zijn configureerbaar en moeten aansluiten op het doelsysteem.
- Geparkeerde facturen: Controleer hoe de status van geparkeerde documenten in VBKPF of BKPF wordt weergegeven. De query gebruikt een configureerbare predicate voor de parkeerstatus, omdat de codering per release en implementatie kan verschillen.
- Betalingswijzigingen: Controleer de objectklasse van het wijzigingsdocument, de tabelnaam, veldnamen en waardeweergave voor BSEG-ZLSPR en BSEG-ZTERM. Controleer de opslag van wijzigingsdocumenten en de veldnamen in het doelsysteem.
- Betaalprogramma: Controleer de REGUH- en REGUP-velden voor de status van voorstellen en uitvoering, uitvoerdatum, run-ID en koppeling met het boekingsdocument. De lokale configuratie van het betaalprogramma kan de beschikbare statuswaarden beïnvloeden.
- Prestaties: Beperk het datumbereik en de bedrijfscodes, selecteer alleen de benodigde kolommen en pas filters per bron toe vóór de joins. Materialiseer bij grote datasets gefilterde subsets van bronnen of gebruik een goedgekeurde HANA calculation view of extractieschema.
- Autorisaties: Je hebt leestoegang nodig tot de relevante objecten in het SAP HANA-schema en tot views met boekhoudkundige data, betaalprogramma-data en gegevens over wijzigingsdocumenten. Stem dit af met de SAP-security- en datagovernanceteams.
- Functionele voorwaarden: De relevante functionaliteit voor Financial Accounting, Accounts Payable, het betaalprogramma en wijzigingsdocumenten moet actief zijn en data bevatten. Als een brontabel niet in de implementatie wordt gebruikt, configureer je een goedgekeurd alternatief op basis van het systeemontwerp.
- Verwerking van timestamps: BKPF en BSEG bevatten meestal datum en tijd in afzonderlijke velden. De query combineert deze tot een timestamp. Controleer de tijdzone van het bronsysteem en pas de vereiste conversie toe vóór de upload naar ProcessMind.
- Databescherming: Beperk leveranciers- en boekhouddata tot de goedgekeurde scope en pas het beleid van je organisatie voor bewaartermijnen, maskering en toegang toe.
a 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 aan de slag te gaan?
Zet je financiële data om in bruikbare inzichten en begin vandaag nog met het optimaliseren van je betaalcycli. Ons team helpt je bij elke stap van je process mining-traject.
Verwerking van crediteurenbetalingen optimaliseren in SAP S/4HANA
Verwijder knelpunten en verkort je doorlooptijd met 30%.
Je hebt geen creditcard nodig. Je bent in 5 minuten klaar met de installatie.