> Continu verbeteren van processen > Order to cash: facturering en facturen > Oracle Fusion Financials > Datatemplate

Datatemplate voor Order to Cash - facturering en factuurverwerking

Oracle Fusion Financials

Attributen voor Order to Cash - facturering en factuurverwerking(22) Activiteiten voor Order to Cash - facturering en factuurverwerking(13) Extractiegidsen(2)

Datatemplate voor Order to Cash - facturering en factuurverwerking

Deze template helpt je de data te verzamelen die nodig is om het proces Order to Cash - facturering en factuurverwerking te analyseren. Je vindt erin welke attributen je verzamelt, welke activiteiten je volgt en hoe je de data praktisch extraheert. Zo stel je een dataset samen waarmee je process mining en procesoptimalisatie kunt uitvoeren.

Aanbevolen attributen om te verzamelen
Belangrijke activiteiten om te volgen
Richtlijnen voor data-extractie uit Oracle Fusion Financials

Nieuw met event logs? Lees hoe je een event log voor process mining maakt.

Template downloaden

Attributen voor Order to Cash - facturering en factuurverwerking

Dit zijn de aanbevolen datavelden voor je event log, zodat je Order to Cash - facturering en factuurverwerking volledig kunt analyseren.

3 Verplicht 5 Aanbevolen 14 Optioneel

	Naam	Beschrijving
	Factuurnummer InvoiceNumber	De unieke identificatiecode van elke factuur. Deze dient als primaire Case-ID om alle bijbehorende activiteiten te volgen.
Beschrijving Het factuurnummer vormt de basis voor de analyse van het facturatieproces. Het fungeert als Case-ID en groepeert alle events, van het aanmaken van de factuur tot de uiteindelijke betaling en afsluiting. Zo krijg je een volledig end-to-endbeeld van de levenscyclus van één factuur. Met process mining kun je op basis van het factuurnummer procesvarianten visualiseren, de doorlooptijd per factuur berekenen en bottlenecks of herstelwerk bij specifieke transacties opsporen. Dit gegeven is nodig voor dashboards zoals 'End-to-end-doorlooptijd factuur' en voor KPI’s als Days Sales Outstanding (DSO) per factuur. Waarom dit belangrijk is Dit attribuut koppelt alle bijbehorende facturatie- en betalingsactiviteiten aan één case. Zo kun je de levenscyclus van de factuur volledig en nauwkeurig analyseren. Waar vind je dit? Dit is meestal het transactienummer (TRX_NUMBER) uit de tabel RA_CUSTOMER_TRX_ALL in Oracle Fusion Financials. Voorbeelden INV-1002345983451CM-55432
	Starttijd EventTimestamp	De exacte datum en tijd waarop een activiteit of event plaatsvond.
Beschrijving De eventtimestamp legt het exacte moment vast waarop een activiteit plaatsvond. Hiermee bepaal je de chronologische volgorde van events per factuur. Dat is nodig om het procesverloop op te bouwen en tijdsanalyses uit te voeren. Dit attribuut vormt de basis voor alle berekeningen van duur en prestaties. Je gebruikt het om de tijd tussen activiteiten te meten, end-to-end-doorlooptijden te berekenen, te bepalen of betalingen op tijd zijn en trends te analyseren. KPI’s zoals 'Gemiddelde goedkeuringstijd factuur' en 'End-to-end-doorlooptijd factuur' worden rechtstreeks uit deze timestamps berekend. Waarom dit belangrijk is Timestamps zijn nodig om prestatiemaatstaven te berekenen, zoals doorlooptijden, vertragingen en het halen van deadlines. Ze vormen de basis voor kwantitatieve procesanalyse. Waar vind je dit? Deze waarde komt uit verschillende datumvelden in Oracle Fusion Financials-tabellen, zoals CREATION_DATE in RA_CUSTOMER_TRX_ALL of statuswijzigingstimestamps in workflowtabellen. Voorbeelden 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-20T11:25:10Z
	Activiteitsnaam ActivityName	De naam van de specifieke bedrijfsgebeurtenis of taak die op een bepaald moment in de levenscyclus van de factuur plaatsvond.
Beschrijving De activiteitsnaam beschrijft een stap in het facturatieproces, zoals 'Factuur aangemaakt', 'Factuur goedgekeurd' of 'Klantbetaling ontvangen'. Samen vormen deze events de reeks acties in het procesverloop van elke factuur. Dit attribuut is de basis voor procesontdekking. De process mining-tool gebruikt het om een visuele weergave te maken van hoe facturen daadwerkelijk worden verwerkt. Je kunt procesvarianten analyseren, herstelwerk opsporen, zoals meerdere goedkeuringsstappen, en de frequentie en duur van elke fase meten. Alle dashboards en KPI’s gebruiken dit attribuut om het procesverloop inzichtelijk te maken. Waarom dit belangrijk is Dit attribuut bepaalt de stappen op de proceskaart. Daarmee kun je de workflow voor facturen visualiseren en analyseren, en inefficiënties opsporen. Waar vind je dit? Deze informatie is af te leiden uit verschillende tabellen en statuswijzigingen in Oracle Fusion Financials, zoals tabellen met de workflowgeschiedenis (bijvoorbeeld voor goedkeuringen) en transactievelden met statusinformatie. Voorbeelden Factuur aangemaaktFactuur goedgekeurdKlantbetaling ontvangenFactuur gesloten
	Bedrijfseenheid BusinessUnit	De bedrijfseenheid binnen de organisatie die de factuur heeft uitgegeven.
Beschrijving De bedrijfseenheid is de organisatie-eenheid die verantwoordelijk is voor de transactie. Dit is een belangrijk gegeven voor financiële segmentatie en rapportage binnen grote organisaties. Met dit attribuut kun je de procesprestaties van verschillende bedrijfsonderdelen vergelijken. Je kunt bijvoorbeeld nagaan of de DSO sterk verschilt tussen bedrijfseenheden of dat één eenheid veel vaker herstelwerk bij facturatie heeft. Zo kun je verbeteringen richten op de plekken waar ze het meest nodig zijn. Waarom dit belangrijk is Maakt het mogelijk prestaties tussen organisatie-eenheden te vergelijken. Zo kun je goede werkwijzen opsporen en op detailniveau zien waar verbetering nodig is. Waar vind je dit? Beschikbaar in transactietabellen zoals RA_CUSTOMER_TRX_ALL, vaak als ORG_ID, dat verwijst naar de definities van bedrijfseenheden. Voorbeelden US ConsultingEMEA ManufacturingAPAC Services
	Factuurbedrag InvoiceAmount	Het totale bedrag van de factuur.
Beschrijving Dit attribuut bevat het totale bedrag dat op de factuur verschuldigd is. Het is een belangrijke financiële maatstaf voor de geldstromen binnen het facturatieproces. Je kunt het factuurbedrag gebruiken om transacties met een hoge waarde voorrang te geven, het totaal aan openstaande vorderingen te berekenen en KPI’s zoals Days Sales Outstanding (DSO) te wegen. Ook kun je het proces indelen op basis van financiële impact. Zo zie je bijvoorbeeld of facturen met een hoog bedrag een andere goedkeuringsroute volgen of langer op betaling wachten. Waarom dit belangrijk is Geeft elke case financiële context. Zo kun je analyses op basis van waarde uitvoeren, facturen met hoge bedragen prioriteren en belangrijke financiële KPI’s berekenen. Waar vind je dit? Te vinden in de tabel RA_CUSTOMER_TRX_ALL, waarschijnlijk in een veld zoals INVOICE_AMOUNT of een verwant veld met het totale transactiebedrag. Voorbeelden 5000.001250.75250000.00
	Factuurstatus InvoiceStatus	De huidige status van de factuur in de levenscyclus, bijvoorbeeld 'Open', 'Gesloten' of 'Betwist'.
Beschrijving De factuurstatus laat zien waar een factuur zich in het proces bevindt. Veelvoorkomende statussen zijn open (onbetaald), gesloten (betaald), betwist en ongeldig gemaakt. Dit attribuut is handig voor monitoring op hoofdlijnen en om gegevens te filteren. Het dashboard Realtime kasstroomprognose gebruikt de status bijvoorbeeld om openstaande bedragen in te delen. Zo zie je snel welke facturen achterstallig of betwist zijn, of volledig zijn betaald. Waarom dit belangrijk is Geeft snel een overzicht op hoofdlijnen van de huidige status van een factuur. Zo kun je gegevens eenvoudig filteren en indelen voor financiële rapportages en operationeel beheer. Waar vind je dit? Af te leiden uit statusvelden in tabellen zoals RA_CUSTOMER_TRX_ALL of AR_PAYMENT_SCHEDULES_ALL, bijvoorbeeld het veld STATUS. Voorbeelden OpenGeslotenBetwistWacht op goedkeuring
	Klantnaam CustomerName	De naam van de klant of organisatie waaraan de factuur is gericht.
Beschrijving Dit attribuut geeft aan welke klant bij de factuur hoort. Het is een belangrijke dimensie om procesdata op te splitsen en te filteren. Met een analyse op klantnaam zie je welke klanten de langste betalingstermijnen hebben, vaak facturen betwisten of consequent op tijd betalen. Dit is belangrijk voor het dashboard DSO-trend en helpt om incassostrategieën af te stemmen op het betaalgedrag van specifieke klanten. Waarom dit belangrijk is Maakt het mogelijk het proces per klant te analyseren. Zo worden verschillen in gedrag en betalingspatronen zichtbaar, net als mogelijke relatieproblemen die de kasstroom beïnvloeden. Waar vind je dit? Af te leiden door de transactietabel (RA_CUSTOMER_TRX_ALL) te koppelen aan klantgegevens uit tabellen zoals HZ_PARTIES. Voorbeelden Global Tech Inc.Innovate Solutions LLCApex Manufacturing
	Vervaldatum DueDate	De datum waarop de factuur betaald moet zijn.
Beschrijving De vervaldatum is een belangrijke datum die op basis van de betalingsvoorwaarden de uiterste betaaldatum van een factuur bepaalt. Deze datum is nodig om de incasso en financiële gezondheid te bewaken. De vervaldatum vormt de basis voor de KPI Betalingen op tijd en voor ouderdomsrapportages van openstaande betalingen. In dashboards kun je ermee de kasstroom voorspellen en zien wanneer betalingen worden verwacht. Ook worden facturen zichtbaar die achterstallig zijn en waarvoor incasso nodig is. Waarom dit belangrijk is Dit is de belangrijkste maatstaf voor het meten van tijdige betalingen, het berekenen van DSO en het beheren van de ouderdom van openstaande vorderingen. Waar vind je dit? Te vinden in de tabel AR_PAYMENT_SCHEDULES_ALL, meestal in het veld DUE_DATE. Voorbeelden 2023-05-302023-06-152023-07-01
	Betaalmethode PaymentMethod	De manier waarop de klant betaalt, bijvoorbeeld via een bankoverschrijving of creditcard.
Beschrijving Dit attribuut geeft aan hoe een klant de factuur heeft betaald. Deze informatie is nuttig om betalingstrends en kosten te analyseren. Betaalmethoden kunnen verschillen in verwerkingstijd en transactiekosten. Met een analyse per betaalmethode zie je of bepaalde methoden vaker leiden tot afstemmingsfouten of vertragingen. Ook kun je bepalen hoe je klanten kunt stimuleren om efficiëntere betaalmethoden te gebruiken. Waarom dit belangrijk is Helpt bij het analyseren van de verwerkingstijd, transactiekosten en afstemmingsfouten van verschillende betaalmethoden. Waar vind je dit? Te vinden in tabellen met betalingsontvangsten, zoals AR_CASH_RECEIPTS_ALL. Daarin staat een veld met de betaalmethode. Voorbeelden ACHBankoverschrijvingCreditcardCheque
	Betalingsvoorwaarden PaymentTerms	De afgesproken voorwaarden voor de betaling van een factuur, zoals 'Netto 30 dagen' of '2% binnen 10 dagen, netto 30 dagen'.
Beschrijving De betalingsvoorwaarden bepalen wanneer en hoe een factuur moet worden betaald. Ze kunnen ook kortingen bevatten voor vroeg betalen. Deze informatie is belangrijk voor het beheer van openstaande vorderingen en de kasstroom. Dit attribuut is nodig om de juiste vervaldatum te berekenen en mogelijkheden voor korting bij vroeg betalen te vinden. De KPI Kortingspercentage bij vroeg betalen is rechtstreeks afhankelijk van deze data om te bepalen voor welke facturen korting gold. Waarom dit belangrijk is Bepaalt de betalingsregels voor een factuur. Dit heeft rechtstreeks invloed op de berekening van de vervaldatum en op het volgen en verbeteren van het gebruik van kortingen bij vroeg betalen. Waar vind je dit? Te vinden in de tabel RA_TERMS en gekoppeld aan de transactie via term_id in RA_CUSTOMER_TRX_ALL. Voorbeelden Netto 30 dagenNetto 60 dagen2% binnen 10 dagen, netto 30 dagen
	Bronsysteem SourceSystem	Het systeem waaruit de eventdata zijn gehaald.
Beschrijving Dit attribuut geeft aan uit welke brontoepassing de data afkomstig zijn. Voor dit proces is dat meestal Oracle Fusion Financials, maar het kan ook een specifieke module zijn, zoals Oracle Receivables (AR). In omgevingen met meerdere gekoppelde systemen helpt dit veld om databronnen van elkaar te onderscheiden. Het is belangrijk voor datavalidatie en gegevensbeheer en zorgt ervoor dat de analyse op de juiste dataset is gebaseerd. Waarom dit belangrijk is Geeft aan waar de data vandaan komen. Dat is belangrijk voor gegevensbeheer, het oplossen van problemen en de zekerheid dat de analyse op het juiste bronsysteem is gebaseerd. Waar vind je dit? Dit is meestal een vaste waarde ('Oracle Fusion Financials') die tijdens de data-extractie en -transformatie wordt toegevoegd. Voorbeelden Oracle Fusion FinancialsOracle AR CloudFusion Apps
	Days Sales Outstanding DaysSalesOutstanding	Het aantal dagen tussen de factuurdatum en de datum waarop de betaling is ontvangen.
Beschrijving Days Sales Outstanding (DSO) is een belangrijke financiële maatstaf voor de gemiddelde tijd tussen het versturen van een factuur en de ontvangst van de betaling. Dit attribuut berekent de DSO voor elke afzonderlijke factuur. De totale DSO is een belangrijke KPI, maar een berekening per factuur maakt een gedetailleerdere analyse mogelijk. Je kunt trenddashboards maken, kenmerken van facturen met een hoge DSO opsporen en de financiële gevolgen van procesvertragingen meten. Deze berekening op detailniveau helpt te begrijpen welke factoren de totale DSO bepalen. Waarom dit belangrijk is Berekent een belangrijke maatstaf voor de kasstroom per factuur. Zo kun je gedetailleerd analyseren wat de incassotijd en financiële prestaties beïnvloedt. Waar vind je dit? Berekend door het verschil te bepalen tussen de timestamp van de activiteit 'Klantbetaling ontvangen' en het attribuut 'Factuurdatum'. Voorbeelden 356228
	Doorlooptijd factuur InvoiceCycleTime	De totale tijd vanaf het aanmaken van de factuur tot de afsluiting.
Beschrijving Dit attribuut meet de end-to-end-doorlooptijd van de volledige levenscyclus van één factuurcase. De berekening is het tijdsverschil tussen de eerste activiteit, meestal 'Factuur aangemaakt', en de laatste activiteit, 'Factuur gesloten'. Deze maatstaf geeft op hoofdlijnen inzicht in de efficiëntie van het hele proces. Het is de belangrijkste maatstaf voor het dashboard 'End-to-end-doorlooptijd factuur'. Door dit attribuut uit te splitsen naar bijvoorbeeld klant of bedrijfseenheid, zie je welke facturen het langst duren en kun je de oorzaken onderzoeken. Waarom dit belangrijk is Geeft één belangrijke maatstaf voor de snelheid van het hele proces. Zo zie je snel welke facturen de meeste tijd kosten, van begin tot eind. Waar vind je dit? Dit is een berekende metriek: het verschil tussen de maximale en minimale EventTimestamp voor elke unieke InvoiceNumber. Voorbeelden 45 dagen en 8 uur32 dagen en 2 uur90 dagen en 12 uur
	Eindtijd EventEndTime	De exacte datum en tijd waarop een activiteit of event is afgerond.
Beschrijving De eindtijd van het event legt vast wanneer een activiteit is afgerond. Veel events duren maar een moment, maar sommige activiteiten, zoals 'Factuur goedkeuren', nemen tijd in beslag. Ze beginnen wanneer de factuur ter goedkeuring wordt ingediend en eindigen zodra er een besluit is genomen. Met een eindtijd kun je de verwerkingstijd van activiteiten nauwkeurig berekenen. Zo zie je hoelang gebruikers aan specifieke taken besteden. Ook wordt de bottleneckanalyse nauwkeuriger, omdat je wachttijd kunt onderscheiden van de daadwerkelijke verwerkingstijd. Waarom dit belangrijk is Maakt een nauwkeurige berekening van de verwerkingstijd van activiteiten mogelijk. Zo kun je actieve werktijd onderscheiden van wachttijd, wat belangrijk is voor een gedetailleerde bottleneckanalyse. Waar vind je dit? Vaak af te leiden uit de starttijd van de volgende activiteit in het proces. Voor sommige activiteiten is er een apart veld voor de eindtijd in de workflowlogs. Voorbeelden 2023-04-15T09:05:12Z2023-04-18T15:00:00Z2023-05-20T11:25:45Z
	Facturatieafdeling BillingDepartment	De interne afdeling of het team dat verantwoordelijk is voor het aanmaken en beheren van de factuur.
Beschrijving Dit attribuut geeft aan welk team of welke afdeling binnen de organisatie de facturatie heeft afgehandeld. Het voegt een extra laag organisatiecontext toe aan de analyse. Door het proces per facturatieafdeling in te delen, kan een bedrijf de efficiëntie en nauwkeurigheid van teams vergelijken. Zo wordt duidelijk welke afdelingen vaker herstelwerk hebben, langere goedkeuringscycli kennen of bijdragen aan een hogere DSO. Dat laat zien waar gerichte training of standaardisatie van het proces kan helpen. Waarom dit belangrijk is Maakt het mogelijk prestaties van interne teams te vergelijken. Zo kun je goede werkwijzen, benodigde middelen en mogelijkheden voor procesverbetering opsporen. Waar vind je dit? Deze informatie kan worden afgeleid van de gebruiker die de factuur heeft aangemaakt. Koppel de gebruiker daarvoor aan de toegewezen afdeling in het HR-systeem, bijvoorbeeld via PER_ALL_ASSIGNMENTS_F. Voorbeelden BedrijfsfacturatieFacturatieteam dienstverleningFacturatie productverkoop
	Factuurdatum InvoiceDate	De officiële datum waarop de factuur is uitgegeven.
Beschrijving De factuurdatum, ook wel transactiedatum genoemd, is de datum die op de factuur staat. Deze datum vormt het uitgangspunt voor de berekening van de betalingstermijn. De factuurdatum is nodig om Days Sales Outstanding (DSO) te berekenen. DSO meet de tijd tussen de factuurdatum en de betaaldatum. De factuurdatum is niet hetzelfde als de aanmaakdatum in het systeem. Voor de klant is dit het officiële begin van de betalingstermijn. Waarom dit belangrijk is Vormt de officiële startdatum van de levenscyclus van een factuur en is de basis voor de KPI Days Sales Outstanding (DSO). Waar vind je dit? Te vinden in het veld TRX_DATE van de tabel RA_CUSTOMER_TRX_ALL. Voorbeelden 2023-04-142023-05-182023-06-25
	Gebruiker User	De medewerker of systeemgebruiker die een activiteit heeft uitgevoerd.
Beschrijving Het attribuut Gebruiker geeft aan wie verantwoordelijk was voor een processtap. Dat kan de gebruiker zijn die de factuur heeft aangemaakt, de manager die deze heeft goedgekeurd of de incassomedewerker die een herinnering heeft verstuurd. Met een analyse per gebruiker kun je opleidingsbehoeften, de verdeling van het werk en prestatieverschillen tussen medewerkers of teams in kaart brengen. Zo zie je of bepaalde gebruikers vaker fouten maken of dat specifieke goedkeurders steeds een bottleneck vormen. Waarom dit belangrijk is Maakt duidelijk wie verantwoordelijk is voor processtappen. Zo kun je prestaties en werkverdeling analyseren en opleidingsbehoeften opsporen. Waar vind je dit? Afkomstig uit gebruikers-ID-velden zoals CREATED_BY of LAST_UPDATED_BY in verschillende transactie- en workflowtabellen. Vervolgens wordt deze ID gekoppeld aan gebruikerstabellen, zoals PER_ALL_PEOPLE_F, om de naam van de gebruiker op te halen. Voorbeelden john.smithjane.doeCollectionsBot
	Is herstelwerk IsRework	Een booleaanse vlag die aangeeft of een activiteit als herstelwerk geldt, bijvoorbeeld een herhaalde goedkeuring of correctie.
Beschrijving Dit berekende attribuut markeert activiteiten die onnodig of dubbel werk zijn. Voorbeelden zijn een factuur die wordt afgewezen en daarna opnieuw ter goedkeuring wordt ingediend, of een correctie na de eerste aanmaak. Met deze markering kun je de impact van herstelwerk eenvoudig meten. De KPI Herstelwerkpercentage facturatie wordt rechtstreeks uit dit attribuut berekend. Dashboards kunnen laten zien hoe vaak herstelwerk voorkomt en hoeveel extra doorlooptijd het veroorzaakt. Zo vind je de bronnen van inefficiëntie en fouten. Waarom dit belangrijk is Maakt procesinefficiëntie meetbaar door onnodig of herhaald werk te markeren. Zo kun je eenvoudig de gevolgen van kwaliteitsproblemen voor kosten en tijd bepalen. Waar vind je dit? Wordt tijdens de datatransformatie berekend op basis van de volgorde van activiteiten. Als bijvoorbeeld de activiteit 'Factuur goedgekeurd' wordt voorafgegaan door 'Factuur afgewezen' voor dezelfde case, wordt dit als herstelwerk gemarkeerd. Voorbeelden truefalse
	Laatste data-update LastDataUpdate	De timestamp die aangeeft wanneer de data voor dit event voor het laatst zijn vernieuwd of uit het bronsysteem zijn gehaald.
Beschrijving Dit attribuut bevat de timestamp van de meest recente data-extractie. Het is een metadataveld dat aangeeft hoe actueel de geanalyseerde data zijn. Analisten gebruiken deze informatie om te controleren of ze met actuele gegevens werken en om te zien hoe recent de data zijn. Dit is vooral belangrijk voor dashboards die realtime of bijna realtime gegevens tonen. De timestamp maakt eventuele vertraging in de data zichtbaar. Waarom dit belangrijk is Laat zien hoe actueel de data zijn. Zo weet je of analyses en conclusies zijn gebaseerd op informatie die recent genoeg is. Waar vind je dit? Dit metadataveld wordt aangemaakt tijdens het ETL-proces (extractie, transformatie en laden). Meestal komt de waarde overeen met het tijdstip waarop de datapijplijn is uitgevoerd. Voorbeelden 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Op tijd betaald IsPaidOnTime	Een booleaanse vlag die aangeeft of de factuur op of vóór de vervaldatum is betaald.
Beschrijving Dit berekende attribuut geeft eenvoudig aan of een betaling op tijd is gedaan. De waarde wordt bepaald door de datum van de activiteit 'Klantbetaling ontvangen' te vergelijken met het attribuut 'Vervaldatum' van de factuur. Deze vlag maakt analyse en rapportage voor de KPI Betalingen op tijd eenvoudiger. Je kunt gegevens makkelijk filteren en uitsplitsen om te zien welke factoren, zoals klant, regio of factuurbedrag, samenhangen met te late betalingen. Het is een belangrijke maatstaf voor de effectiviteit van incasso. Waarom dit belangrijk is Maakt de prestaties van incasso eenvoudiger meetbaar. Ook kun je makkelijk analyseren welke factoren bijdragen aan tijdige of te late betalingen. Waar vind je dit? Berekend door de timestamp van de laatste betalingsactiviteit te vergelijken met het attribuut DueDate. De logica is: `PaymentTimestamp <= DueDate`. Voorbeelden truefalse
	Reden van bezwaar DisputeReason	De reden die de klant opgeeft om een factuur te betwisten.
Beschrijving Wanneer een klant een factuur betwist, wordt de reden vastgelegd. Het kan bijvoorbeeld gaan om de prijs, de hoeveelheid, de kwaliteit van de dienstverlening of een ander probleem. Een analyse van bezwaarredenen helpt om oorzaken te achterhalen. Als je weet waarom klanten het vaakst bezwaar maken, kan de organisatie onderliggende problemen met prijzen, orderafhandeling of datakwaliteit aanpakken. Zo wordt de gemiddelde afhandelingstijd van factuurbezwaren korter en neemt de klanttevredenheid toe. Waarom dit belangrijk is Geeft rechtstreeks inzicht in de oorzaken van betalingsvertragingen en ontevreden klanten. Zo kan de organisatie structurele problemen aanpakken. Waar vind je dit? Deze informatie kan zijn opgeslagen in Oracle Collections of een verwante module voor bezwaarbeheer. Mogelijk staat ze in een aparte bezwarentabel of als redenencode op de transactie zelf. Voorbeelden Onjuiste prijsHoeveelheid komt niet overeenBeschadigde goederenDubbele factuur
	Regio Region	De geografische regio die bij de klant of transactie hoort.
Beschrijving De regio geeft de factuur geografische context, meestal op basis van de locatie van de klant. Zo kun je procesprestaties per gebied analyseren. Een analyse per regio kan verschillen aan het licht brengen die samenhangen met lokale regelgeving, marktomstandigheden of de prestaties van regionale teams. Je kunt dashboards zoals DSO-trend en End-to-end-doorlooptijd factuur per regio uitsplitsen. Zo zie je of bepaalde gebieden specifieke problemen hebben met het betaald krijgen van facturen. Waarom dit belangrijk is Maakt het mogelijk het proces geografisch in te delen. Zo worden regionale verschillen in prestaties, klantgedrag of compliance zichtbaar. Waar vind je dit? Meestal af te leiden uit de adresgegevens van de klant in TCA (HZ_LOCATIONS, HZ_PARTY_SITES). Dit is geen rechtstreeks veld op de factuur. Voorbeelden Noord-AmerikaEuropaAzië-Pacific

Verplicht Aanbevolen Optioneel

Activiteiten voor Order to Cash - facturering en factuurverwerking

Leg deze belangrijke processtappen en mijlpalen vast in je event log om het proces goed in kaart te brengen.

6 Aanbevolen 7 Optioneel

	Activiteit	Beschrijving
	Betaling aan factuur gekoppeld	De ontvangen klantbetaling is succesvol aan de betreffende factuur gekoppeld en verlaagt het openstaande saldo. Dit wordt vastgelegd als een afzonderlijke transactie.
Waarom dit belangrijk is Deze activiteit bevestigt dat de betaling correct is toegewezen. Dat is belangrijk voor nauwkeurige verouderingsrapporten en financiële overzichten. Hiermee is de betaling definitief verwerkt als afboeking op de vordering. Waar vind je dit? Expliciet vastgelegd in de tabel AR_RECEIVABLE_APPLICATIONS_ALL. De velden apply_date en gl_date geven aan wanneer de betaling is gekoppeld. Vastleggen Gebruik apply_date uit de tabel AR_RECEIVABLE_APPLICATIONS_ALL, waarin de kasontvangst aan de factuur wordt gekoppeld. Gebeurtenistype explicit
	Factuur aangemaakt	De factuurtransactie wordt voor het eerst in het systeem aangemaakt, vaak met de status Concept of Onvolledig. Deze gebeurtenis wordt vastgelegd wanneer een gebruiker voor het eerst een nieuwe factuur opslaat in de module Accounts Receivable.
Waarom dit belangrijk is Dit is het begin van het factureringsproces. Door de tijd tussen aanmaak en afronding te analyseren, kun je vertragingen bij de invoer van gegevens of problemen met de systeemprestaties opsporen. Waar vind je dit? Deze gebeurtenis wordt vastgelegd aan de hand van de aanmaakdatum van de transactierecord in de tabel RA_CUSTOMER_TRX_ALL. De eerste status is vaak ‘Incomplete’. Vastleggen Gebruik creation_date uit de tabel RA_CUSTOMER_TRX_ALL voor het betreffende factuurnummer. Gebeurtenistype explicit
	Factuur gesloten	De factuur is volledig betaald en afgestemd. De levenscyclus is daarmee afgerond. Dit event wordt meestal afgeleid wanneer het openstaande saldo van de factuur nul wordt en de status wordt bijgewerkt.
Waarom dit belangrijk is Dit is de definitieve afhandeling van de factuur en markeert het einde van het proces. De totale tijd tot deze status is de end-to-end-doorlooptijd, een belangrijke KPI voor het facturatieproces. Waar vind je dit? Af te leiden uit de tabel AR_PAYMENT_SCHEDULES_ALL wanneer de status wordt bijgewerkt naar 'CLOSED' en amount_due_remaining nul is. Het veld 'gl_date_closed' geeft de sluitingsdatum aan. Vastleggen Gebruik voor de betreffende factuur de waarde van gl_date_closed in AR_PAYMENT_SCHEDULES_ALL. Gebeurtenistype inferred
	Factuur goedgekeurd	De factuur heeft alle benodigde goedkeuringen gekregen en kan naar de klant worden verstuurd. Deze gebeurtenis wordt vastgelegd wanneer de goedkeuringsworkflow succesvol is afgerond en de factuurstatus wordt bijgewerkt.
Waarom dit belangrijk is Dit is een belangrijke mijlpaal voordat de factuur naar de klant kan. Vertragingen hebben rechtstreeks invloed op het moment waarop de betalingstermijn ingaat en daarmee op Days Sales Outstanding (DSO). Waar vind je dit? Af te leiden uit de laatste statusupdate van de factuurtransactie of de timestamp waarop de bijbehorende BPM-workflowtaak is afgerond. Vastleggen Leg de timestamp vast waarop de goedkeuringsstatus van de factuur op ‘Approved’ wordt gezet. Gebeurtenistype inferred
	Factuur naar klant verzonden	De factuur is via de voorkeursmethode van de klant bezorgd, bijvoorbeeld per e-mail of per post. Het systeem registreert vaak de timestamp waarop de bezorging plaatsvindt.
Waarom dit belangrijk is Met deze activiteit begint de betalingstermijn. De tijd tussen goedkeuring en bezorging meten is belangrijk om de efficiëntie van het factuurdistributieproces te beoordelen. Waar vind je dit? Dit is af te leiden uit het veld ‘last_printed_date’ in RA_CUSTOMER_TRX_ALL of uit logs in Oracle Business Intelligence Publisher als de factuur elektronisch wordt bezorgd. Vastleggen Gebruik de timestamp uit het relevante bezorgings- of afdruklog voor de factuur. Gebeurtenistype inferred
	Klantbetaling ontvangen	Een betaling van een klant is als kasontvangst in het systeem ingevoerd. Op dit moment is de betaling mogelijk nog niet aan een specifieke factuur gekoppeld.
Waarom dit belangrijk is Dit is een belangrijke mijlpaal die de instroom van geld markeert. De tijd tussen ontvangst van de betaling en de koppeling aan een factuur geeft aan hoe efficiënt het kasbeheer verloopt. Waar vind je dit? Expliciet vastgelegd wanneer een record wordt aangemaakt in de tabel AR_CASH_RECEIPTS_ALL. receipt_date geeft aan wanneer de betaling is verwerkt. Vastleggen Gebruik creation_date of receipt_date uit de tabel AR_CASH_RECEIPTS_ALL. Gebeurtenistype explicit
	Betalingsherinnering verstuurd	Er is een aanmaning of betalingsherinnering naar de klant verstuurd voor een achterstallige factuur. Deze actie wordt expliciet vastgelegd door de incassomodule.
Waarom dit belangrijk is Door herinneringen te volgen, kun je de effectiviteit van het incassoproces meten. Zo zie je welke aanpak tot snellere betalingen leidt. Waar vind je dit? Expliciet vastgelegd in de module Oracle Advanced Collections. Aanmaningsgeschiedenis wordt bijvoorbeeld geregistreerd in tabellen zoals IEX_DUNNINGS, met de datum en het niveau van de verstuurde herinnering. Vastleggen Haal de gegevens uit de tabellen met aanmaningsgeschiedenis en koppel de aanmaningstransactie aan de factuur. Gebeurtenistype explicit
	Factuur aangepast	Het factuurbedrag is gewijzigd, bijvoorbeeld door een afboeking of credit. Dit is een expliciete transactie die het openstaande saldo van de factuur aanpast.
Waarom dit belangrijk is Aanpassingen wijzen vaak op geschillen, tegemoetkomingen of correcties. Door het aantal en de waarde van aanpassingen te analyseren, kun je onderliggende problemen in het Order to Cash-proces vinden. Waar vind je dit? Expliciet vastgelegd in de tabel AR_ADJUSTMENTS_ALL. De creation_date van het aanpassingsrecord markeert de gebeurtenis. Vastleggen Gebruik creation_date uit de tabel AR_ADJUSTMENTS_ALL voor de betreffende factuur. Gebeurtenistype explicit
	Factuur afgerond	De invoer van de factuurgegevens is afgerond en de transactie is klaar voor validatie en boekhouding. Dit wordt doorgaans vastgelegd wanneer de factuurstatus verandert van ‘Incomplete’ naar ‘Complete’.
Waarom dit belangrijk is Deze mijlpaal markeert het einde van de gegevensinvoer. De tijd tussen aanmaak en afronding geeft een beeld van de efficiëntie van de gegevensinvoer en controle door de factureringsafdeling. Waar vind je dit? Af te leiden uit een statuswijziging van de factuurtransactie in de tabel RA_CUSTOMER_TRX_ALL. Zoek de timestamp van de statuswijziging naar ‘Complete’. Vastleggen Volg de statusgeschiedenis van de transactie in RA_CUSTOMER_TRX_ALL of gerelateerde workflowtabellen. Gebeurtenistype inferred
	Factuur afgewezen	Een goedkeurder heeft de factuur afgewezen, meestal vanwege fouten in gegevens zoals prijzen of aantallen. De factuur gaat terug voor correctie, waardoor herstelwerk nodig is.
Waarom dit belangrijk is Door afwijzingen te volgen, komen problemen met de juistheid van facturen en interne controles aan het licht. Analyse van het aantal afwijzingen en de redenen ervoor helpt verbeterpunten en trainingsbehoeften te vinden. Waar vind je dit? Af te leiden uit een statusupdate van de factuurtransactie of de uitkomst ‘Rejected’ van de BPM-workflowtaak. Vastleggen Leg de timestamp vast waarop de goedkeuringsstatus van de factuur op ‘Rejected’ wordt gezet. Gebeurtenistype inferred
	Factuur ter goedkeuring ingediend	De factuur wordt ter goedkeuring ingediend via een workflow, als die is ingesteld. Dit wordt vastgelegd wanneer de factuurstatus verandert in een status voor goedkeuring in behandeling en meldingen naar de aangewezen goedkeurders worden verstuurd.
Waarom dit belangrijk is Dit markeert het begin van de goedkeuringsronde. Door deze activiteit te volgen, kun je de daaropvolgende goedkeuringstijd meten en analyseren. Die tijd is een belangrijk onderdeel van de totale doorlooptijd van de factuur. Waar vind je dit? Af te leiden uit een statuswijziging van de factuurtransactie of vast te leggen via de Oracle Business Process Management (BPM)-workflowtabellen, waarin de start van de goedkeuringstaak wordt geregistreerd. Vastleggen Bepaal de timestamp waarop de goedkeuringsstatus van de factuur verandert in ‘Pending’ of een vergelijkbare status. Gebeurtenistype inferred
	Geschil gestart	De klant heeft de factuur formeel betwist en er is een geschilcase aangemaakt in het systeem. Dit wordt doorgaans vastgelegd door een statusveld in het betalingsschema van de factuur te wijzigen.
Waarom dit belangrijk is Een geschil zet het betalingsproces stil en vraagt om handmatige afhandeling. Door het aantal geschillen en de afhandelingstijd te analyseren, kun je de oorzaken vinden, zoals fouten in prijzen of verzending. Waar vind je dit? Dit is af te leiden uit de status in de tabel AR_PAYMENT_SCHEDULES_ALL wanneer die op een geschilstatus staat, of uit aanmaakrecords in AR_DISPUTE_HISTORY. Vastleggen Bepaal wanneer de geschilmarkering of -status voor het betalingsschema van de factuur wordt geactiveerd. Gebeurtenistype inferred
	Vervaldatum betaling bereikt	De contractuele uiterste betaaldatum van de factuur is verstreken. Dit is geen transactiegebeurtenis, maar wordt berekend op basis van de factuurvoorwaarden en de huidige datum.
Waarom dit belangrijk is Deze berekende gebeurtenis is belangrijk voor verouderingsanalyses en het berekenen van DSO. Zo maak je onderscheid tussen facturen die op tijd zijn betaald en achterstallige facturen, en kun je incassoactiviteiten gericht inzetten. Waar vind je dit? Dit is een berekende gebeurtenis. De gebeurtenis vindt plaats wanneer de huidige datum later is dan de waarde in het veld due_date in de tabel AR_PAYMENT_SCHEDULES_ALL voor een bepaalde factuur. Vastleggen Bereken dit door de huidige datum te vergelijken met het veld due_date in AR_PAYMENT_SCHEDULES_ALL. Gebeurtenistype calculated

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data op uit Oracle Fusion Financials

Stappen

Ga naar BI Publisher: Meld je aan bij Oracle Fusion Applications en open via het menu Navigator achtereenvolgens Tools en Reports and Analytics. Klik op Browse Catalog om de Business Intelligence Catalog te openen.
Maak een datamodel: Klik in de catalogus op het dropdownmenu New en kies Data Model. De editor voor datamodellen wordt geopend.
Stel de SQL Query-dataset in: Klik in het deelvenster Data Model op het pluspictogram naast Data Sets en kies SQL Query. Geef de dataset in het dialoogvenster een naam, bijvoorbeeld AR_INVOICE_LIFECYCLE. Selecteer de juiste databron, meestal ApplicationDB_FSCM.
Voer de SQL-query in: Kopieer de volledige SQL-query uit het gedeelte query van dit document en plak deze in het tekstveld SQL Query. De parameters zoals :P_START_DATE, :P_END_DATE en :P_BUSINESS_UNIT worden automatisch herkend.
Stel parameters in en bekijk de data: Ga naar het tabblad Parameters om standaardwaarden in te stellen of weergaveopties voor de gebruiker te configureren. Ga daarna naar het tabblad Data, vul parameterwaarden in, bijvoorbeeld een korte periode, en klik op View om de query te testen en een voorbeeld van de resultaten te bekijken.
Sla het datamodel op: Controleer of de data klopt, klik op het pictogram Save en sla het datamodel op in een geschikte map, bijvoorbeeld onder Shared Folders/Custom/ProcessMining.
Maak een rapport: Ga terug naar de catalogus, klik op het dropdownmenu New en kies Report. Selecteer in de rapportwizard de optie 'Use Data Model' en zoek het datamodel op dat je net hebt opgeslagen.
Stel de rapportindeling in: Maak in de editor voor rapportindelingen geen complexe indeling. Kies 'Create Table' en sleep alle kolommen uit de dataset naar de tabel. Het doel is een onbewerkte data-export, geen opgemaakt rapport.
Stel CSV in als standaarduitvoer: Stel in de rapportinstellingen CSV in als standaarduitvoerformaat. Zo wordt het rapport uitgevoerd als een tekstbestand dat geschikt is voor process mining.
Plan het rapport in: Zoek het rapport in de catalogus, klik op More en kies Schedule. Maak een nieuwe taak aan, stel de parameters in, zoals de periode en bedrijfseenheid, en kies een bestemming. Vaak is dit de Content Server (UCM) of een externe SFTP-server.
Haal het event log op: Ga na afloop van de geplande taak naar de opgegeven bestemming, bijvoorbeeld de UCM-contentrepository, en download het gegenereerde CSV-bestand. Dit bestand is je event log.
Bereid het bestand voor upload voor: Controleer of het CSV-bestand de juiste kolomkoppen bevat, zoals gedefinieerd in de query (InvoiceNumber, ActivityName, EventTimestamp enzovoort). Het bestand is nu klaar om naar je process mining-platform te uploaden.

Configuratie

BI Publisher-parameters: De query gebruikt parameters om het bereik van de data te bepalen. Deze verschijnen automatisch wanneer je een rapport maakt op basis van het datamodel.
- :P_START_DATE: De begindatum van de extractieperiode (notatie YYYY-MM-DD). De query filtert activiteiten op basis van hun timestamp.
- :P_END_DATE: De einddatum van de extractieperiode (notatie YYYY-MM-DD).
- :P_BUSINESS_UNIT: De naam van de bedrijfseenheid waarop je de facturen wilt filteren. Zo beperk je de hoeveelheid data en houd je de analyse gericht.
Periode: Haal voor een eerste test en analyse een beperkte periode op, bijvoorbeeld 3 tot 6 maanden aan data. Voor een volledige analyse kun je, afhankelijk van de bedrijfsbehoeften, 12 tot 18 maanden ophalen.
Configuratie van statuscodes: De query bevat tijdelijke waarden zoals '[Your Pending Approval Status]'. Vervang deze door de statuscodes die in jouw Oracle Fusion-implementatie worden gebruikt voor goedkeuringsworkflows van facturen. Vraag een functioneel analist om de juiste waarden op te zoeken in de tabel RA_CUST_TRX_TYPES_ALL of in de systeemopzoeklijsten.
Prestaties: Data over een lange periode of uit alle bedrijfseenheden tegelijk ophalen kan veel systeembronnen vragen. Plan het BI Publisher-rapport bij voorkeur buiten piekuren in, zodat andere gebruikers geen last hebben van tragere systeemprestaties.
Vereisten: Je hebt een gebruikersaccount nodig met rollen waarmee je datamodellen en rapporten in BI Publisher kunt maken, zoals BI Administrator of een aangepaste rol met vergelijkbare rechten. Ook moet je data-beveiligingsprofiel toegang geven tot de benodigde data over debiteuren, klanten en bedrijfseenheden.

Voorbeeldquery sql

WITH BaseInvoices AS (
    SELECT
        rct.trx_number,
        rct.customer_trx_id,
        hp.party_name AS customer_name,
        rct.trx_date,
        rct.creation_date,
        rct.last_update_date,
        rct.complete_flag,
        aps.status AS payment_schedule_status,
        aps.amount_due_original,
        aps.due_date,
        aps.dispute_flag,
        aps.gl_date_closed,
        rct.last_printed_date,
        rct.status_trx,
        bu.bu_name AS business_unit
    FROM
        ra_customer_trx_all rct
    JOIN
        hz_cust_accounts hca ON rct.bill_to_customer_id = hca.cust_account_id
    JOIN
        hz_parties hp ON hca.party_id = hp.party_id
    JOIN
        ar_payment_schedules_all aps ON rct.customer_trx_id = aps.customer_trx_id
    JOIN
        fun_all_business_units_v bu ON rct.org_id = bu.bu_id
    WHERE
        bu.bu_name = :P_BUSINESS_UNIT
        AND rct.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD') + 1
        AND aps.class = 'INV'
)
-- 1. Invoice Created
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Created' AS "ActivityName",
    bi.creation_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi

UNION ALL

-- 2. Invoice Completed
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Completed' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.complete_flag = 'Y'

UNION ALL

-- 3. Invoice Submitted for Approval
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Submitted for Approval' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.status_trx = '[Your Pending Approval Status]' -- Placeholder: Configure status based on your system

UNION ALL

-- 4. Invoice Approved
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Approved' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.status_trx = '[Your Approved Status]' -- Placeholder: Configure status based on your system

UNION ALL

-- 5. Invoice Rejected
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Rejected' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.status_trx = '[Your Rejected Status]' -- Placeholder: Configure status based on your system

UNION ALL

-- 6. Invoice Sent to Customer
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Sent to Customer' AS "ActivityName",
    bi.last_printed_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.last_printed_date IS NOT NULL

UNION ALL

-- 7. Payment Due Date Reached
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Payment Due Date Reached' AS "ActivityName",
    bi.due_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.due_date <= CURRENT_TIMESTAMP

UNION ALL

-- 8. Payment Reminder Issued
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Payment Reminder Issued' AS "ActivityName",
    dlt.trx_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
JOIN
    ar_dunning_letters_trx dlt ON bi.customer_trx_id = dlt.customer_trx_id

UNION ALL

-- 9. Dispute Initiated
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Dispute Initiated' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp", -- Uses last update as a proxy for dispute date
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    'Disputed' AS "InvoiceStatus", -- Overrides status
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.dispute_flag = 'Y'

UNION ALL

-- 10. Customer Payment Received
SELECT DISTINCT
    bi.trx_number AS "InvoiceNumber",
    'Customer Payment Received' AS "ActivityName",
    acr.receipt_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
JOIN
    ar_receivable_applications_all ara ON bi.customer_trx_id = ara.applied_customer_trx_id
JOIN
    ar_cash_receipts_all acr ON ara.cash_receipt_id = acr.cash_receipt_id
WHERE
    ara.status = 'APP'

UNION ALL

-- 11. Payment Applied to Invoice
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Payment Applied to Invoice' AS "ActivityName",
    ara.apply_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
JOIN
    ar_receivable_applications_all ara ON bi.customer_trx_id = ara.applied_customer_trx_id
WHERE
    ara.status = 'APP'

UNION ALL

-- 12. Invoice Adjusted
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Adjusted' AS "ActivityName",
    adj.creation_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
JOIN
    ar_adjustments_all adj ON bi.customer_trx_id = adj.customer_trx_id

UNION ALL

-- 13. Invoice Closed
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Closed' AS "ActivityName",
    bi.gl_date_closed AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    'Closed' AS "InvoiceStatus", -- Overrides status
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.payment_schedule_status = 'CL' AND bi.gl_date_closed IS NOT NULL

Stappen

Vereisten: Installeer Python 3.6 of hoger en de bibliotheken requests en pandas. Je kunt deze installeren met pip: pip install requests pandas.
Oracle Fusion-inloggegevens: Zorg dat je de juiste inloggegevens hebt voor toegang tot de Oracle Fusion REST API’s. Je hebt de basis-URL van je Fusion-omgeving nodig, een gebruikersnaam en het wachtwoord van een gebruiker die voldoende rechten heeft om debiteurendata te lezen.
Configureer het script: Open het meegeleverde Python-script in een editor. Zoek bovenaan het script het configuratiegedeelte en vervang de tijdelijke waarden voor FUSION_URL, USERNAME, PASSWORD en eventuele filterparameters zoals start_date.
Bekijk de API-eindpunten: Het script gebruikt vooral het eindpunt receivablesInvoices om de belangrijkste factuurdata op te halen. Daarna vraagt het ook data op via eindpunten zoals receivablesReceipts, receivablesReceiptApplications, receivablesAdjustments en collectionsDelinquentTransactions om bijbehorende activiteiten te verzamelen.
Paginering afhandelen: De hulpfunctie get_paginated_data verwerkt de paginering van de API automatisch. De functie volgt de link next in het API-antwoord totdat alle records voor een query zijn opgehaald.
Data ophalen: Eerst haalt het script een lijst met facturen op binnen de opgegeven periode. Vervolgens doorloopt het elke factuur om de details en bijbehorende activiteiten te verzamelen.
Activiteiten aanmaken: Voor elke factuur maakt het script regels aan voor verschillende activiteiten. Sommige activiteiten, zoals 'Invoice Created', komen rechtstreeks uit factuurvelden (CreationDate). Voor andere, zoals 'Payment Applied to Invoice', zijn aparte API-aanroepen nodig. De resultaten worden gekoppeld aan het factuurnummer.
Berekende activiteiten verwerken: De activiteit 'Payment Due Date Reached' is geen rechtstreekse transactie. Het script berekent deze door te controleren of de DueDate van de factuur is verstreken en de factuur nog niet is betaald.
Voer het script uit: Start het script vanuit de terminal met python your_script_name.py. Tijdens het ophalen van data voor elke factuur geeft het script de voortgang weer.
Controleer de uitvoer: Na afloop staat het bestand oracle_fusion_ar_event_log.csv in dezelfde map. Dit bestand bevat het geëxtraheerde event log.
Bereid het bestand voor upload voor: Open het gegenereerde CSV-bestand. Controleer of de kolomkoppen CaseId, ActivityName en EventTimestamp zijn voor een eenvoudige proceskaart. Je kunt de gegenereerde kolommen, zoals InvoiceNumber, ActivityName, EventTimestamp en InvoiceAmount, ook tijdens het uploaden aan de juiste velden in je process mining-tool koppelen.

Configuratie

Basis-URL van de API: De hoofd-URL van je Oracle Fusion Financials-omgeving, bijvoorbeeld https://[your-pod].fa.em2.oraclecloud.com/fscmRestApi/resources/11.13.18.05.
Authenticatie: Het script gebruikt Basic Authentication. Controleer of de gebruikersaccount rollen heeft zoals 'Accounts Receivable Manager' of een aangepaste rol met rechten voor toegang tot de REST-bronnen receivablesInvoices, receivablesReceipts, receivablesReceiptApplications, receivablesAdjustments en collectionsDelinquentTransactions.
Filter op periode: Het script gebruikt een parameter q met een filter op CreationDate om het aantal facturen bij de eerste extractie te beperken. Begin bij voorkeur met een kortere periode, bijvoorbeeld 3 tot 6 maanden, om de extractieduur en belasting van de API te beperken. Voorbeeld: CreationDate between 'YYYY-MM-DD' and 'YYYY-MM-DD'.
Paginering: De parameter limit in de API-aanroepen bepaalt hoeveel records per verzoek worden teruggegeven. Een waarde tussen 100 en 500 werkt doorgaans efficiënt. Het script heeft standaard een limiet ingesteld.
Filter voor bedrijfseenheid: Je kunt een filter voor de bedrijfseenheid toevoegen aan de queryparameter (q) om de extractie te beperken, bijvoorbeeld: BusinessUnitName = '[Your Business Unit Name]'.
Prestaties: Bij grote hoeveelheden data kan het ophalen van facturen één voor één traag zijn. Het script doet meerdere API-aanroepen per factuur. Als je meer dan 100.000 facturen hebt, kun je het script in batches uitvoeren of buiten piekuren plannen om vertragingen en API-limieten te voorkomen.

Voorbeeldquery python

import requests
import pandas as pd
import datetime
import os

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Oracle Fusion instance URL, username, and password
FUSION_URL = class="hl-string">"https://[your-pod].fa.em2.oraclecloud.com/fscmRestApi/resources/11.13.18.05"
USERNAME = class="hl-string">"YOUR_USERNAME"
PASSWORD = class="hl-string">"YOUR_PASSWORD"

class=class="hl-string">"hl-comment"># --- Filter Parameters ---
class=class="hl-string">"hl-comment"># Define the date range for the initial invoice query
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"
class=class="hl-string">"hl-comment"># Optional: Filter by a specific Business Unit
BUSINESS_UNIT_FILTER = class="hl-string">"" class=class="hl-string">"hl-comment"># e.g., class="hl-string">" and BusinessUnitName = 'US1 Business Unit'"

class=class="hl-string">"hl-comment"># API call settings
API_LIMIT = 100

def get_paginated_data(endpoint, params):
    class="hl-string">"""Helper function to handle pagination for Oracle Fusion REST API calls."""
    all_items = []
    url = fclass="hl-string">"{FUSION_URL}/{endpoint}"
    
    while url:
        try:
            response = requests.get(url, auth=(USERNAME, PASSWORD), params=params)
            response.raise_for_status()
            data = response.json()
            all_items.extend(data.get(class="hl-string">'items', []))
            
            class=class="hl-string">"hl-comment"># Get the next page link
            links = data.get(class="hl-string">'links', [])
            next_link = next((link[class="hl-string">'href'] for link in links if link[class="hl-string">'rel'] == class="hl-string">'next'), None)
            url = next_link
            class=class="hl-string">"hl-comment"># Params are only needed for the first request
            params = {}

        except requests.exceptions.HTTPError as e:
            print(fclass="hl-string">"HTTP Error fetching data from {url}: {e}")
            print(fclass="hl-string">"Response body: {response.text}")
            break
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Request Error: {e}")
            break
            
    return all_items


def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    event_log = []
    today = datetime.datetime.now().strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')

    class=class="hl-string">"hl-comment"># 1. Fetch main invoice data
    print(class="hl-string">"Fetching invoices...")
    invoice_params = {
        class="hl-string">'q': fclass="hl-string">"CreationDate between '{START_DATE}' and '{END_DATE}'{BUSINESS_UNIT_FILTER}",
        class="hl-string">'fields': class="hl-string">'TransactionNumber,CreationDate,TransactionDate,CreatedBy,LastUpdateDate,LastUpdatedBy,Amount,AmountDueRemaining,Status,CompletedDate,CustomerName,DueDate,BusinessUnitName,ApprovalStatus,paymentSchedules,CustomerTransactionId',
        class="hl-string">'limit': API_LIMIT,
        class="hl-string">'expand': class="hl-string">'paymentSchedules'
    }
    invoices = get_paginated_data(class="hl-string">'receivablesInvoices', invoice_params)
    print(fclass="hl-string">"Found {len(invoices)} invoices.")

    class=class="hl-string">"hl-comment"># 2. Process each invoice to generate events
    for i, inv in enumerate(invoices):
        print(fclass="hl-string">"Processing invoice {i+1}/{len(invoices)}: {inv.get('TransactionNumber')}")
        
        case_id = inv.get(class="hl-string">'TransactionNumber')
        cust_trx_id = inv.get(class="hl-string">'CustomerTransactionId')
        common_attrs = {
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'InvoiceAmount': inv.get(class="hl-string">'Amount'),
            class="hl-string">'CustomerName': inv.get(class="hl-string">'CustomerName'),
            class="hl-string">'DueDate': inv.get(class="hl-string">'DueDate'),
            class="hl-string">'InvoiceStatus': inv.get(class="hl-string">'Status'),
            class="hl-string">'BusinessUnit': inv.get(class="hl-string">'BusinessUnitName')
        }

        class=class="hl-string">"hl-comment"># Event: Invoice Created
        event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Created', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'CreationDate')})

        class=class="hl-string">"hl-comment"># Event: Invoice Completed
        if inv.get(class="hl-string">'CompletedDate'):
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Completed', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'CompletedDate')})
        
        class=class="hl-string">"hl-comment"># Events: Approval Cycle (based on final status)
        if inv.get(class="hl-string">'ApprovalStatus') == class="hl-string">'APPROVED':
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Approved', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})
        elif inv.get(class="hl-string">'ApprovalStatus') == class="hl-string">'REJECTED':
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Rejected', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})
        elif inv.get(class="hl-string">'ApprovalStatus') == class="hl-string">'PENDING':
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Submitted for Approval', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})
        
        class=class="hl-string">"hl-comment"># Placeholder for class="hl-string">'Invoice Sent to Customer' - requires specific configuration
        class=class="hl-string">"hl-comment"># This might come from BI Publisher or another module. Using LastUpdateDate if status is class="hl-string">'COMPLETE' as an example.
        if inv.get(class="hl-string">'Status') == class="hl-string">'COMPLETE': class=class="hl-string">"hl-comment"># This is a proxy event
             event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Sent to Customer', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})

        class=class="hl-string">"hl-comment"># Event: Payment Due Date Reached (calculated)
        if inv.get(class="hl-string">'DueDate') and inv.get(class="hl-string">'DueDate') < today and inv.get(class="hl-string">'AmountDueRemaining', 0) > 0:
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Payment Due Date Reached', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'DueDate')})

        class=class="hl-string">"hl-comment"># Event: Dispute Initiated
        for ps in inv.get(class="hl-string">'paymentSchedules', []):
            if ps.get(class="hl-string">'DisputeDate'):
                event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Dispute Initiated', class="hl-string">'EventTimestamp': ps.get(class="hl-string">'DisputeDate')})
                break class=class="hl-string">"hl-comment"># Assuming one dispute event per invoice for simplicity

        class=class="hl-string">"hl-comment"># Event: Invoice Closed
        if inv.get(class="hl-string">'AmountDueRemaining') == 0 and inv.get(class="hl-string">'Status') == class="hl-string">'CLOSED':
             event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Closed', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})
        
        class=class="hl-string">"hl-comment"># 3. Fetch related events using other APIs
        if cust_trx_id:
            class=class="hl-string">"hl-comment"># Events: Payment Applied and Payment Received
            apps = get_paginated_data(class="hl-string">'receivablesReceipts', {class="hl-string">'q': fclass="hl-string">'AppliedCustomerTransactionId={cust_trx_id}', class="hl-string">'onlyData': class="hl-string">'true', class="hl-string">'fields': class="hl-string">'ReceiptNumber,ReceiptDate,ActivityApplication.ApplyDate,ActivityApplication.AppliedCustomerTransactionId'})
            for app in apps:
                for activity_app in app.get(class="hl-string">'ActivityApplication', []):
                    if activity_app.get(class="hl-string">'AppliedCustomerTransactionId') == cust_trx_id:
                        event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Customer Payment Received', class="hl-string">'EventTimestamp': app.get(class="hl-string">'ReceiptDate')})
                        event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Payment Applied to Invoice', class="hl-string">'EventTimestamp': activity_app.get(class="hl-string">'ApplyDate')})

            class=class="hl-string">"hl-comment"># Event: Invoice Adjusted
            adjustments = get_paginated_data(class="hl-string">'receivablesAdjustments', {class="hl-string">'q': fclass="hl-string">'CustomerTransactionId={cust_trx_id}', class="hl-string">'onlyData': class="hl-string">'true', class="hl-string">'fields': class="hl-string">'ApplyDate'})
            for adj in adjustments:
                event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Adjusted', class="hl-string">'EventTimestamp': adj.get(class="hl-string">'ApplyDate')})

            class=class="hl-string">"hl-comment"># Event: Payment Reminder Issued (from Delinquency data)
            reminders = get_paginated_data(class="hl-string">'collectionsDelinquentTransactions', {class="hl-string">'q': fclass="hl-string">'TransactionId={cust_trx_id}', class="hl-string">'onlyData': class="hl-string">'true', class="hl-string">'fields': class="hl-string">'LastDunningLetterDate'})
            for rem in reminders:
                if rem.get(class="hl-string">'LastDunningLetterDate'):
                    event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Payment Reminder Issued', class="hl-string">'EventTimestamp': rem.get(class="hl-string">'LastDunningLetterDate')})

    class=class="hl-string">"hl-comment"># 4. Create DataFrame and save to CSV
    if not event_log:
        print(class="hl-string">"No events generated. Exiting.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTimestamp'])
    class=class="hl-string">"hl-comment"># Ensure required columns are present
    df_final = df[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'DueDate', class="hl-string">'InvoiceStatus', class="hl-string">'BusinessUnit']]

    output_filename = class="hl-string">'oracle_fusion_ar_event_log.csv'
    df_final.to_csv(output_filename, index=False)
    print(fclass="hl-string">"\nEvent log successfully saved to {os.path.abspath(output_filename)}")

if __name__ == class="hl-string">'__main__':
    main()

Klaar om aan de slag te gaan?

Gebruik deze template om je data voor te bereiden, het proces Order to Cash - facturering en factuurverwerking te verbeteren en betalingen sneller te innen. Krijg inzicht in de bedrijfsvoering met Oracle Fusion Financials en werk efficiënter.

Terug naar de verbetergids

Template downloaden

Optimaliseer nu de facturering en factuurverwerking in Oracle

Verkort de factureringscyclus met 30% en verbeter je cashflow met onze oplossing.

Start je gratis proefperiode

Geen creditcard nodig. Binnen enkele minuten ingesteld.

Datatemplate voor Order to Cash - facturering en factuurverwerking

Datatemplate voor Order to Cash - facturering en factuurverwerking

Attributen voor Order to Cash - facturering en factuurverwerking

Activiteiten voor Order to Cash - facturering en factuurverwerking

Extractiegidsen

Oracle BI Publisher-rapport voor data over facturering en factuurverwerking

Stappen

Configuratie

Voorbeeldquery sql

Data extraheren met een Python-script via de Oracle Fusion REST API’s

Stappen

Configuratie

Voorbeeldquery python

Klaar om aan de slag te gaan?

Optimaliseer nu de facturering en factuurverwerking in Oracle