Datatemplate voor kredietbeheer en incasso
Datatemplate voor kredietbeheer en incasso
- Aanbevolen attributen voor een volledige analyse
- Belangrijke activiteiten om bij te houden voor procesontdekking
- Stapsgewijze uitleg voor data-extractie
Attributen voor kredietbeheer en incasso
| Naam | Beschrijving | ||
|---|---|---|---|
| Activiteitsnaam ActivityName | De naam van de specifieke bedrijfsgebeurtenis of taak die op een bepaald moment in het kredietbeheerproces plaatsvond. | ||
| Beschrijving Dit attribuut beschrijft één stap in de levenscyclus van een factuur, zoals ‘Factuur aangemaakt’, ‘Aanmaningsprocedure gestart’ of ‘Betaling ontvangen’. Elke activiteit is een afzonderlijke gebeurtenis die de case verder brengt. De volgorde en frequentie van activiteiten analyseren is de kern van process mining. Zo ontdek je hoe het proces werkelijk verloopt, waar cases vastlopen, waar activiteiten opnieuw worden uitgevoerd en hoe het werkelijke proces afwijkt van het ontworpen of gewenste proces. De activiteitsnaam vormt de basis voor proceskaarten en berekeningen van de tijd tussen stappen. Waarom dit belangrijk is Dit attribuut bepaalt de stappen op de proceskaart en maakt het mogelijk om de levenscyclus van een factuur van begin tot eind te visualiseren en analyseren. Waar vind je dit? Dit is een conceptueel veld dat is afgeleid van verschillende bedrijfsgebeurtenissen in Oracle Fusion Financials. Het wordt vaak samengesteld door transactiestatussen, gebeurtenisdatums of specifieke acties uit modules zoals Receivables (AR) en Advanced Collections aan elkaar te koppelen. Voorbeelden Factuur aangemaaktAanmaningsprocedure gestartBetaling ontvangenGeschil geregistreerd | |||
| Factuurnummer InvoiceNumber | De unieke identificatie van elke klantfactuur. Dit is de belangrijkste case-ID voor het kredietbeheerproces. | ||
| Beschrijving Het factuurnummer is de centrale sleutel die alle gebeurtenissen en activiteiten rond één vordering koppelt, van het aanmaken tot de uiteindelijke betaling of afschrijving. Zo krijg je een volledig beeld van het factuurtraject. Bij process mining gebruik je dit attribuut om het traject van elke factuur te reconstrueren. Door alle bijbehorende activiteiten onder één factuurnummer te groeperen, kunnen analisten processtromen visualiseren, veelvoorkomende en afwijkende routes herkennen en doorlooptijden meten voor het hele proces of specifieke stappen, zoals de afhandeling van een geschil of de verwerking van een betaling. Waarom dit belangrijk is Dit is de essentiële case-ID die alle bijbehorende processtappen koppelt. Zo kun je het traject van elke factuur, van uitgifte tot afsluiting, reconstrueren en analyseren. Waar vind je dit? Deze identificatie staat in Oracle Fusion Financials meestal als TRX_NUMBER in de tabel RA_CUSTOMER_TRX_ALL. Voorbeelden INV-1005679884321AR-2023-04-112 | |||
| Tijdstip gebeurtenis EventTime | De exacte datum en tijd waarop de activiteit plaatsvond, oftewel de timestamp van de gebeurtenis. | ||
| Beschrijving Het tijdstip van de gebeurtenis, oftewel de timestamp, legt het exacte moment vast waarop een activiteit plaatsvond. Dit is nodig om gebeurtenissen chronologisch te ordenen en de processtroom correct op te bouwen. Zonder nauwkeurige timestamps kun je de volgorde van gebeurtenissen niet goed bepalen. Bij analyses gebruik je dit attribuut om de duur en doorlooptijden tussen activiteiten te berekenen. Dat is belangrijk om prestaties te meten. Zo bereken je KPI’s zoals de doorlooptijd van geschillenafhandeling of de betalingstermijn van facturen. Ook kun je hiermee trends in de procesprestaties over verschillende perioden analyseren. Waarom dit belangrijk is Deze timestamp is nodig om gebeurtenissen te ordenen, doorlooptijden en duur te berekenen en procesprestaties over tijd te analyseren. Waar vind je dit? Afgeleid van verschillende datumvelden in Oracle Fusion Financials-tabellen, zoals TRX_DATE in RA_CUSTOMER_TRX_ALL voor het aanmaken van een factuur of de aanmaakdatum van een incassoactie. Voorbeelden 2023-04-15T10:00:00Z2023-05-01T14:30:00Z2023-05-20T09:15:22Z | |||
| Bronsysteem SourceSystem | Het systeem waar de data vandaan komt. | ||
| Beschrijving Dit attribuut geeft aan in welke brontoepassing de gebeurtenisdata is vastgelegd. In een complexe IT-omgeving kunnen meerdere systemen betrokken zijn bij één end-to-end-proces. Het bronsysteem vermelden is belangrijk voor datagovernance, probleemoplossing en inzicht in de context van de data. Als gebeurtenissen uit verschillende systemen in één procesoverzicht worden gecombineerd, kun je ze hiermee van elkaar onderscheiden en blijft de herkomst van de data duidelijk. Waarom dit belangrijk is Maakt duidelijk waar de data vandaan komt. Dat is belangrijk voor datavalidatie, governance en inzicht in de technologische context van het proces. Waar vind je dit? Dit is meestal een vaste waarde die tijdens de data-extractie wordt toegevoegd om de herkomst van de records aan te geven. Voorbeelden Oracle Fusion FinancialsOracle AROracle Collections | |||
| Laatste data-update LastDataUpdate | De timestamp die aangeeft wanneer de data voor deze gebeurtenis voor het laatst is vernieuwd of uit het bronsysteem is gehaald. | ||
| Beschrijving Dit attribuut geeft de datum en tijd van de meest recente data-extractie aan. Het is een metadataveld dat geen deel uitmaakt van het bedrijfsproces zelf, maar wel laat zien hoe actueel de geanalyseerde data is. Analisten gebruiken deze timestamp om te controleren of ze met actuele informatie werken en om te weten tot welk moment de data loopt. Dit is belangrijk voor datagovernance en om gebruikers duidelijk te maken hoe actueel de data in dashboards en rapporten is. Waarom dit belangrijk is Geeft aan hoe actueel de data is, zodat analisten en belanghebbenden weten hoe recent en relevant de informatie is. Waar vind je dit? Deze waarde wordt tijdens het extractie- en laadproces (ETL) gegenereerd en aan elk record toegevoegd. Voorbeelden 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Aanmaningsniveau DunningLevel | De fase of het niveau van de aanmaningsprocedure die op de factuur is toegepast. | ||
| Beschrijving Het aanmaningsniveau geeft aan hoe dringend de betalingsherinnering is. Meestal loopt de urgentie na verloop van tijd op. Niveau 1 kan bijvoorbeeld een vriendelijke herinnering per e-mail zijn, terwijl niveau 3 een formele brief of telefoontje kan betekenen. Door het proces per aanmaningsniveau te analyseren, kun je de effectiviteit van de aanmaningsstrategie beoordelen. Het dashboard voor aanmaningseffectiviteit gebruikt dit attribuut om te laten zien hoeveel facturen na elke aanmaningsstap worden betaald. Zo kan de bedrijfsvoering bepalen welke acties het beste werken en het tijdstip en de inhoud van herinneringen aanpassen om meer betalingen te innen. Waarom dit belangrijk is Houdt bij hoe ver de incasso is opgeschaald. Dit is belangrijk om de effectiviteit van de aanmaningsstrategie te beoordelen. Waar vind je dit? Deze data wordt beheerd in de Oracle Advanced Collections-module. Je vindt ze in tabellen met de aanmaningsgeschiedenis, zoals IEX_DUNNINGS. Voorbeelden Niveau 1: herinneringNiveau 2: waarschuwingNiveau 3: laatste aanmaning | |||
| Factuurbedrag InvoiceAmount | Het totale geldbedrag van de factuur. | ||
| Beschrijving Het factuurbedrag is de totale waarde van de goederen of diensten die aan de klant zijn gefactureerd. Dit financiële attribuut laat zien wat de financiële impact van het proces is. Bij analyses gebruik je het factuurbedrag om incassoacties te prioriteren, bijvoorbeeld door facturen met een hoog bedrag voorrang te geven. Je kunt ook betalingsgedrag per transactiebedrag analyseren en de financiële gevolgen van afschrijvingen berekenen. Dashboards zoals de analyse van het afschrijvingspercentage per klantsegment gebruiken deze waarde om de omvang van financiële verliezen te bepalen. Waarom dit belangrijk is Geeft het proces financiële context. Zo kun je facturen met hoge bedragen prioriteren en de financiële gevolgen van procesinefficiënties analyseren. Waar vind je dit? Deze informatie kan worden afgeleid uit de tabel AR_PAYMENT_SCHEDULES_ALL, waarin het verschuldigde bedrag van een factuur staat. Voorbeelden 5000.001250.75250000.00 | |||
| Gebruiker User | De gebruiker of systeem-ID die de activiteit heeft uitgevoerd. | ||
| Beschrijving Dit attribuut geeft aan welke medewerker of systeemgebruiker verantwoordelijk was voor een activiteit, zoals het goedkeuren van een kredietlimiet, het boeken van een betaling of het afhandelen van een betwisting. Door activiteiten per gebruiker te analyseren, krijg je inzicht in de werkverdeling, individuele prestaties en compliance. Bij geautomatiseerde activiteiten kun je zien welke systeemprocessen betrokken waren. Ook kun je opleidingsbehoeften of mogelijk frauduleus gedrag opsporen door gebruikersgedrag te volgen. Waarom dit belangrijk is Koppelt procesactiviteiten aan specifieke personen of geautomatiseerde systemen. Zo kun je prestaties en werkverdeling volgen en controles uitvoeren. Waar vind je dit? Afkomstig uit de kolommen ‘CREATED_BY’ of ‘LAST_UPDATED_BY’ in verschillende transactie- en geschiedenistabellen van Oracle Fusion Financials. Voorbeelden jjansendebiteurenmedewerker_1SYSTEEMAUTOMATISERING | |||
| Incassomedewerker Collector | De naam of ID van de incassomedewerker die aan de factuur is toegewezen. | ||
| Beschrijving De incassomedewerker is de persoon of het team dat verantwoordelijk is voor de incasso van een achterstallige factuur. Deze toewijzing is een belangrijke stap in het incassoproces. Dit attribuut is belangrijk voor prestatiebeheer en de verdeling van bronnen binnen de incassoafdeling. Door resultaten per incassomedewerker te analyseren, kunnen managers de effectiviteit beoordelen, opleidingsbehoeften vaststellen en de werkdruk verdelen. Het dashboard voor de effectiviteit van de toewijzing van incassomedewerkers gebruikt dit attribuut om succespercentages en doorlooptijden tussen medewerkers te vergelijken. Waarom dit belangrijk is Maakt het mogelijk om de prestaties van individuele incassomedewerkers of teams te analyseren, de inzet van bronnen te verbeteren en de algehele efficiëntie van incasso te verhogen. Waar vind je dit? Deze informatie wordt meestal opgeslagen in de Oracle Advanced Collections-module, vaak in tabellen zoals IEX_CASES_ALL_B of gerelateerde toewijzingstabellen. Voorbeelden Jan JansenJanneke de VriesIncassoteam A | |||
| Klantnummer CustomerNumber | Een unieke identificatie van de klant bij de factuur. | ||
| Beschrijving Het klantnummer koppelt een factuur aan een specifieke klantrekening. Zo kun je het krediet- en incassoproces analyseren en uitsplitsen op basis van klantkenmerken. Met het klantnummer kunnen analisten onderzoeken of bepaalde klanten steeds te laat betalen, vaker geschillen melden of meer incassoacties nodig hebben. Deze informatie is belangrijk om incassostrategieën op klanten af te stemmen, kredietvoorwaarden aan te passen en klantsegmenten met een hoog risico te herkennen. Dit ondersteunt rechtstreeks analyses zoals de analyse van het afschrijvingspercentage per klantsegment. Waarom dit belangrijk is Maakt het mogelijk om het proces per klant uit te splitsen en patronen, risico’s en kansen voor gerichte incassostrategieën te herkennen. Waar vind je dit? Staat meestal als BILL_TO_CUSTOMER_ID in de tabel RA_CUSTOMER_TRX_ALL en verwijst naar HZ_CUST_ACCOUNTS. Voorbeelden CUST-0012389455ACME-CORP-US | |||
| Klantsegment CustomerSegment | De indeling van een klant in een bepaalde groep, bijvoorbeeld op basis van omvang, sector of strategisch belang. | ||
| Beschrijving Klantsegment is een categorisch attribuut waarmee klanten op basis van gedeelde kenmerken in groepen worden ingedeeld. Segmenten kunnen bijvoorbeeld worden bepaald door kenmerken als ‘Strategisch’, ‘MKB’ of ‘Enterprise’, of door sectoren als ‘Productie’ en ‘Detailhandel’. Met dit attribuut kun je processen tussen segmenten vergelijken. Analisten zien bijvoorbeeld of een segment vaker geschillen heeft of een langere betalingstermijn. Op basis daarvan kun je kredietbeleid en incassostrategieën afstemmen op de behoeften en risico’s van elk segment. Dit ondersteunt dashboards zoals de analyse van het afschrijvingspercentage per klantsegment. Waarom dit belangrijk is Maakt vergelijkingen mogelijk en laat zien hoe procesprestaties en risico’s verschillen tussen klantgroepen. Waar vind je dit? Wordt vaak beheerd in klantstamgegevens (HZ_CUST_ACCOUNTS of gerelateerde tabellen) of afgeleid van klantkenmerken zoals omzet of sector. Voorbeelden Grote ondernemingKlein en middelgroot bedrijfOverheidStrategische partner | |||
| Vervaldatum DueDate | De datum waarop de factuur betaald moet zijn. | ||
| Beschrijving De vervaldatum is een belangrijke datum die contractueel is afgesproken voor de betaling. Aan de hand van deze datum bepaal je of een betaling op tijd is. Dit attribuut helpt achterstallige facturen te herkennen en te berekenen hoeveel dagen de betalingstermijn is verstreken. Het is de belangrijkste invoer om te bepalen wanneer je een aanmaningsprocedure start en wordt gebruikt voor KPI’s zoals Days Sales Outstanding (DSO). Ook heb je de vervaldatum nodig voor ouderdomsrapportages waarin openstaande schulden worden ingedeeld. Waarom dit belangrijk is Dient als uitgangspunt om te bepalen of een factuur achterstallig is. Zo kun je incassoactiviteiten starten en de ouderdom van facturen analyseren. Waar vind je dit? Beschikbaar in de tabel AR_PAYMENT_SCHEDULES_ALL als DUE_DATE. Voorbeelden 2023-05-302023-06-152023-07-01 | |||
| Bedrijfseenheid BusinessUnit | De specifieke bedrijfseenheid of organisatorische entiteit die de factuur heeft uitgegeven. | ||
| Beschrijving In grote organisaties is de bedrijfsvoering vaak verdeeld over meerdere bedrijfseenheden. Dit attribuut geeft aan bij welke bedrijfseenheid de factuur hoort. Door het proces per bedrijfseenheid te analyseren, kun je de prestaties van verschillende onderdelen van de organisatie vergelijken. Zo worden verschillen zichtbaar in de toepassing van krediet- en incassobeleid en zie je welke bedrijfseenheden hun vorderingen het beste beheren. Dit helpt om goede werkwijzen te delen en processen waar nodig gelijk te trekken. Waarom dit belangrijk is Maakt het mogelijk prestaties van verschillende organisatieonderdelen te vergelijken en helpt goede werkwijzen en verbeterpunten te vinden. Waar vind je dit? Beschikbaar in de tabel RA_CUSTOMER_TRX_ALL via het veld ORG_ID, dat verwijst naar de organisatiestructuur. Voorbeelden Bedrijfseenheid Noord-AmerikaBedrijfseenheid EMEADivisie Global Services | |||
| Betalingsvoorwaarden PaymentTerms | De afgesproken voorwaarden die bepalen wanneer de betaling moet plaatsvinden. | ||
| Beschrijving De betalingsvoorwaarden bepalen wanneer een klant moet betalen, bijvoorbeeld ‘Netto 30 dagen’ of ‘Netto 60 dagen’. Op basis hiervan wordt de vervaldatum van de factuur berekend. Door betaalgedrag per betalingsvoorwaarde te analyseren, kun je patronen ontdekken. Klanten met een kortere betalingstermijn betalen bijvoorbeeld mogelijk vaker te laat. Je kunt deze informatie gebruiken om het kredietbeleid te herzien en te verbeteren, en klanten in te delen voor verschillende incassostrategieën. Zo begrijp je beter waarom bepaalde facturen achterstallig raken. Waarom dit belangrijk is Geeft context bij de afgesproken betalingstermijn en maakt het mogelijk betaalgedrag bij verschillende kredietvoorwaarden te vergelijken. Waar vind je dit? Dit wordt opgeslagen in de tabel RA_TERMS en gekoppeld aan de factuurtransactie. Voorbeelden Netto 30 dagenNetto 60 dagenTe betalen bij ontvangst | |||
| Dagen achterstallig DaysOverdue | Het aantal dagen dat de vervaldatum van een factuur is verstreken. | ||
| Beschrijving Deze berekende metriek geeft aan hoeveel dagen een onbetaalde factuur achterstallig is. De waarde is het verschil tussen de huidige datum (voor openstaande facturen) of de betaaldatum (voor gesloten facturen) en de vervaldatum. Het aantal dagen achterstallig is een belangrijke maatstaf voor ouderdomsanalyses en het prioriteren van incassoactiviteiten. Het is de belangrijkste metriek in het dashboard voor de ouderdom en status van achterstallige facturen. Daar worden facturen ingedeeld in ouderdomscategorieën, bijvoorbeeld 1-30 dagen en 31-60 dagen. Zo kan het incassoteam zich richten op de oudste schulden met het grootste risico. Waarom dit belangrijk is Geeft de omvang van betalingsvertragingen aan en vormt een belangrijke maatstaf voor het prioriteren van incassoactiviteiten en het analyseren van de ouderdom van facturen. Waar vind je dit? Dit is een berekend veld. De logica is: CurrentDate - DueDate voor openstaande facturen, of PaymentDate - DueDate voor gesloten facturen. Voorbeelden 1545920 | |||
| Eindtijd EndTime | De timestamp waarop een activiteit met een bepaalde duur is afgerond. | ||
| Beschrijving Bij activiteiten met een duidelijk begin en einde legt dit attribuut het tijdstip van afronding vast. Veel gebeurtenissen in process mining vinden op één moment plaats, maar sommige activiteiten, zoals ‘Betwisting onderzoeken’, kunnen een tijd duren. Met een aparte eindtijd kun je de verwerkingstijd van activiteiten nauwkeurig berekenen. Dat is preciezer dan de duur afleiden uit de starttijd van de volgende activiteit, vooral als er tussendoor niets gebeurt. De eindtijd is belangrijk om het gebruik van capaciteit te analyseren en te zien welke processtappen de meeste tijd kosten. Waarom dit belangrijk is Maakt het mogelijk nauwkeurig te berekenen hoelang activiteiten duren en geeft inzicht in bottlenecks en capaciteitsgebruik. Waar vind je dit? Dit is vaak een conceptueel attribuut. De waarde kan afkomstig zijn van een timestamp voor de laatste wijziging of een specifiek veld voor de sluitingsdatum in de brontabellen die bij de activiteit horen. Voorbeelden 2023-04-15T11:30:00Z2023-05-02T09:00:00Z2023-05-21T16:45:00Z | |||
| Factuurstatus InvoiceStatus | De huidige status van de factuur in de levenscyclus. | ||
| Beschrijving De factuurstatus laat zien waar de factuur op dit moment staat in het proces. Veelvoorkomende statussen zijn ‘Open’, ‘Betaald’, ‘Betwist’, ‘Achterstallig’ en ‘Afgeboekt’. Dit attribuut geeft een overzicht op hoofdlijnen van de status van de openstaande vorderingen. In process mining kun je dit attribuut gebruiken om cases te filteren op specifieke groepen, zoals alle openstaande facturen waarvan de betalingstermijn is verstreken. Het is een belangrijke dimensie in het dashboard voor de ouderdom en status van achterstallige facturen. Zo zie je meteen wat de status van de factuurportefeuille is en kun je incassoactiviteiten prioriteren. Waarom dit belangrijk is Geeft snel inzicht in de huidige status van een factuur, zodat je incassoactiviteiten eenvoudig kunt filteren en prioriteren. Waar vind je dit? Meestal beschikbaar in de tabel AR_PAYMENT_SCHEDULES_ALL, in een veld met de naam STATUS. Voorbeelden OpenGeslotenBetwistIn incasso | |||
| Factuurvaluta InvoiceCurrency | De valuta waarin het factuurbedrag is uitgedrukt. | ||
| Beschrijving Dit attribuut geeft de valuta van de factuur aan, zoals USD, EUR of GBP. In internationale organisaties worden facturen vaak in verschillende valuta opgesteld. Data met meerdere valuta’s vraagt om zorgvuldige verwerking. Met dit attribuut kun je de procesweergave op valuta filteren of de juiste wisselkoersen toepassen voor geconsolideerde financiële rapportages. Zo worden geldbedragen correct geïnterpreteerd en vergelijk je bedragen op dezelfde basis. Waarom dit belangrijk is Nodig om financiële data in een omgeving met meerdere valuta’s correct te interpreteren en nauwkeurig te analyseren. Waar vind je dit? Staat meestal als INVOICE_CURRENCY_CODE in de tabel RA_CUSTOMER_TRX_ALL. Voorbeelden USDEURGBPJPY | |||
| Is achterstallig IsOverdue | Een booleaanse indicator die aangeeft of de vervaldatum van de factuur is verstreken. | ||
| Beschrijving Dit afgeleide attribuut geeft eenvoudig met waar of onwaar aan of een factuur achterstallig is. Meestal wordt dit berekend door de huidige datum (of de betaaldatum) te vergelijken met de vervaldatum van de factuur. Deze indicator is handig om analyses te filteren en groepen te maken. Analisten kunnen snel alle achterstallige facturen selecteren en hun procesverloop, de effectiviteit van incassoactiviteiten en andere kenmerken onderzoeken. Ook wordt het eenvoudiger om dashboards en KPI’s te maken voor het beheer van achterstallige schulden, zoals het dashboard voor de ouderdom en status van achterstallige facturen. Waarom dit belangrijk is Geeft een duidelijke indicator waarmee je alle achterstallige facturen kunt herkennen en analyseren. Dit is de belangrijkste focus van het incassoproces. Waar vind je dit? Dit is een berekend veld. De logica is: IF CurrentDate > DueDate AND Status != 'Paid' THEN True ELSE False. Voorbeelden truefalse | |||
| Is afgeboekt IsWrittenOff | Een booleaanse indicator die aangeeft of de factuur als oninbare vordering is afgeboekt. | ||
| Beschrijving Deze afgeleide indicator markeert facturen die het bedrijf als oninbaar beschouwt en uit de actieve vorderingen heeft verwijderd. Dit is meestal de laatste en ongewenste uitkomst voor een factuur. Dit attribuut is belangrijk voor het berekenen van de KPI voor het percentage afgeboekte facturen en voor de bijbehorende analyse. Analisten kunnen hiermee mislukte incasso’s afzonderlijk bekijken en zoeken naar gemeenschappelijke kenmerken, zoals klantsegment of factuurbedrag, die mogelijk samenhangen met een groter afboekingsrisico. Deze inzichten helpen het kredietbeleid en de incassostrategie te verbeteren. Waarom dit belangrijk is Maakt mislukte incasso’s duidelijk zichtbaar. Zo kun je de oorzaken van oninbare vorderingen analyseren en afboekingspercentages berekenen. Waar vind je dit? Dit is een berekend veld. De waarde wordt afgeleid door te controleren of er voor de case een activiteit ‘Factuur afgeboekt’ bestaat of dat de factuurstatus ‘Afgeboekt’ is. Voorbeelden truefalse | |||
| Kredietlimietbedrag CreditLimitAmount | Het maximale kredietbedrag dat voor de klant is goedgekeurd. | ||
| Beschrijving Het kredietlimietbedrag is het totale kredietrisico dat een bedrijf bij een bepaalde klant wil lopen. Dit bedrag wordt bepaald tijdens de kredietbeoordeling. Dit attribuut is belangrijk voor het dashboard over de impact van kredietlimietbeslissingen. Door de goedgekeurde kredietlimiet te vergelijken met later betaalgedrag en afboekingen, kan de bedrijfsvoering de effectiviteit van het kredietrisicobeleid beoordelen. Uit de analyse kan bijvoorbeeld blijken dat te hoge kredietlimieten leiden tot meer oninbare vorderingen. Die informatie helpt het goedkeuringsproces voor krediet te verbeteren. Waarom dit belangrijk is Helpt de effectiviteit van het kredietrisicobeleid te beoordelen door de goedgekeurde kredietlimiet te vergelijken met betaalresultaten en afboekingen. Waar vind je dit? Dit wordt beheerd in Oracle Credit Management en meestal opgeslagen in tabellen met klantkredietprofielen, zoals HZ_CUST_PROFILE_AMTS. Voorbeelden 10000.0050000.00250000.00 | |||
| Reden van betwisting DisputeReason | De reden die de klant opgeeft om een factuur te betwisten. | ||
| Beschrijving Als een klant een factuur betwist, geeft die meestal een reden op, zoals ‘Onjuiste prijs’, ‘Beschadigde goederen’ of ‘Dubbele factuur’. Dit attribuut legt die reden vast. Analyse van betwistingsredenen is belangrijk voor oorzaakanalyse. Zo kun je terugkerende problemen opsporen in eerdere processen, zoals orderbeheer of facturatie, die tot betalingsvertraging leiden. Door verschillende redenen in te delen en bij te houden hoe vaak ze voorkomen, kan de bedrijfsvoering gericht iets aan de oorzaken doen. Dat helpt de doorlooptijd van de afhandeling van betwistingen te verkorten. Waarom dit belangrijk is Helpt de oorzaken van factuurbetwistingen te vinden, zodat je eerdere processen kunt verbeteren en nieuwe betwistingen voorkomt. Waar vind je dit? Deze informatie wordt meestal vastgelegd in de Oracle Advanced Collections- of Oracle Channel Revenue Management-module als het beheer van betwistingen is ingericht. De data kan bijvoorbeeld in tabellen zoals AR_DISPUTE_HISTORY staan. Voorbeelden Onjuiste hoeveelheidPrijsverschilBeschadigde goederenDienst niet geleverd | |||
| Toegezegde betaaldatum PromiseToPayDate | De datum waarop een klant heeft toegezegd te betalen. | ||
| Beschrijving Tijdens incassoactiviteiten kan een klant toezeggen op een toekomstige datum te betalen. De toegezegde betaaldatum wordt vastgelegd om deze afspraak bij te houden. Dit attribuut helpt bij het beheren van incassoworkflows en het beoordelen van de betrouwbaarheid van betaaltoezeggingen. Door de toegezegde betaaldatum te vergelijken met de werkelijke ontvangstdatum, kunnen incassomedewerkers zien hoe vaak klanten hun toezegging nakomen. Dit helpt de kasstroom nauwkeuriger te voorspellen en te bepalen wanneer je de incasso opschaalt als een toezegging niet wordt nagekomen. Waarom dit belangrijk is Houdt betaaltoezeggingen van klanten bij. Zo kun je inkomende betalingen voorspellen en beoordelen hoe effectief incassoafspraken zijn. Waar vind je dit? Opgeslagen in de Oracle Advanced Collections-module, waarschijnlijk in tabellen zoals IEX_PROMISES_T. Voorbeelden 2023-06-102023-06-252023-07-05 | |||
Activiteiten voor kredietbeheer en incasso
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Aanmaningsprocedure gestart | Dit markeert de officiële start van het aanmaningsproces voor een achterstallige factuur. Vaak wordt dan de eerste officiële aanmaning verstuurd. Dit wordt meestal vastgelegd wanneer een aanmaningsbatch wordt uitgevoerd en de factuur daarin wordt opgenomen. | ||
| Waarom dit belangrijk is Door deze activiteit bij te houden, kun je de effectiviteit van aanmaningen en de naleving van het aanmaningsbeleid meten. Het geeft een uitgangspunt om te bepalen hoe lang het duurt voordat een aanmaning tot betaling leidt. Waar vind je dit? Vastgelegd in de module Oracle Advanced Collections. De aanmaakdatum van een aanmaningsrecord in bijvoorbeeld de tabel IEX_DUNNINGS, gekoppeld aan de transactie-ID, markeert deze gebeurtenis. Vastleggen Aanmaakdatum van het record in de tabel IEX_DUNNINGS dat bij de factuur hoort. Gebeurtenistype explicit | |||
| Betaling ontvangen | Dit markeert de ontvangst van geld van een klant. De betaling is mogelijk nog niet aan een specifieke factuur toegewezen. Dit wordt vastgelegd wanneer het systeem een ontvangsttransactie aanmaakt. | ||
| Waarom dit belangrijk is Dit is een belangrijk moment in het incassoproces: het geld is ontvangen. De tijd tussen dit moment en de verwerking van de betaling laat zien hoe efficiënt de interne verwerking verloopt. Waar vind je dit? Expliciet vastgelegd met RECEIPT_DATE in de tabel AR_CASH_RECEIPTS_ALL. Daarna kan de ontvangst via AR_RECEIVABLE_APPLICATIONS_ALL worden gekoppeld aan de factuur waarop de betaling is verwerkt. Vastleggen RECEIPT_DATE uit AR_CASH_RECEIPTS_ALL, gekoppeld via verwerkingstabellen. Gebeurtenistype explicit | |||
| Betaling verwerkt | Dit is het verwerken van een ontvangen betaling op een specifieke factuur, waardoor het openstaande saldo van de factuur daalt. In deze stap wordt de betaling officieel aan de factuur gekoppeld. | ||
| Waarom dit belangrijk is Deze activiteit bevestigt dat een factuur is betaald. Dit is het werkelijke eindpunt voor de berekening van Days Sales Outstanding (DSO) en de betalingsverwerking. Waar vind je dit? Dit is een expliciete gebeurtenis uit APPLY_DATE in de tabel AR_RECEIVABLE_APPLICATIONS_ALL. Deze tabel koppelt een ontvangst aan een klanttransactie (factuur). Vastleggen APPLY_DATE uit AR_RECEIVABLE_APPLICATIONS_ALL voor de betreffende factuur. Gebeurtenistype explicit | |||
| Factuur aangemaakt | Dit markeert het aanmaken van de factuurtransactie in Oracle Fusion Financials. Dit is het officiële begin van de levenscyclus van de factuur in de module voor debiteurenbeheer en het belangrijkste startpunt voor de analyse. | ||
| Waarom dit belangrijk is Dit is de belangrijkste startgebeurtenis voor het factuurtraject. Alle daaropvolgende berekeningen van doorlooptijden, zoals Days Sales Outstanding (DSO) en de betalingstermijn van de factuur, zijn afhankelijk van deze eerste timestamp. Waar vind je dit? Dit is een expliciete gebeurtenis uit de kolom CREATION_DATE of TRX_DATE in de tabel RA_CUSTOMER_TRX_ALL voor een specifieke TRX_NUMBER (factuurnummer). Vastleggen De timestamp van de gebeurtenis is de CREATION_DATE uit de tabel RA_CUSTOMER_TRX_ALL. Gebeurtenistype explicit | |||
| Factuur afgeschreven | Dit is de formele beslissing om te stoppen met incasseren en het factuurbedrag als oninbare vordering af te schrijven. Het gaat om een expliciete financiële transactie die het factuursaldo op nul zet. | ||
| Waarom dit belangrijk is Dit is een belangrijk eindpunt waarbij het incassoproces niet succesvol is afgerond. Door afschrijvingen per klantsegment, regio of kredietlimiet te analyseren, kun je kredietbeleid en incassostrategieën aanscherpen en verliezen beperken. Waar vind je dit? Expliciet vastgelegd bij het aanmaken van een correctie in de tabel AR_ADJUSTMENTS_ALL, met een RECEIVABLES_TRX_ID die verwijst naar een activiteit voor oninbare vorderingen of afschrijvingen. Vastleggen Aanmaakdatum van een record in AR_ADJUSTMENTS_ALL met een activiteitstype voor afschrijvingen. Gebeurtenistype explicit | |||
| Vervaldatum betaling verstreken | Dit is een berekende gebeurtenis die plaatsvindt wanneer de huidige datum na de vervaldatum van de factuur valt en de factuur nog niet volledig is betaald. De factuur verandert dan van de status ‘actueel’ naar ‘achterstallig’. | ||
| Waarom dit belangrijk is Dit is een belangrijk moment waarop incasso- en aanmaningsprocessen starten. Door het aantal en de waarde van facturen waarvan de vervaldatum is verstreken te analyseren, kun je het werkkapitaal beheren en kredietrisico’s beoordelen. Waar vind je dit? Deze gebeurtenis wordt berekend door de huidige systeemdatum te vergelijken met DUE_DATE in de tabel AR_PAYMENT_SCHEDULES_ALL voor facturen met de status ‘OP’ (Open). Vastleggen Berekende gebeurtenis: vindt plaats wanneer SYSDATE > AR_PAYMENT_SCHEDULES_ALL.DUE_DATE. Gebeurtenistype calculated | |||
| Actie incassomedewerker afgerond | Dit is een handmatige actie van een incassomedewerker, zoals bellen, een e-mail sturen of een notitie van een gesprek vastleggen. Deze acties worden in de incassomodule geregistreerd als ‘activiteiten’ of ‘interacties’. | ||
| Waarom dit belangrijk is Door acties van incassomedewerkers te volgen, kun je de efficiëntie en effectiviteit van het handmatige incassoproces meten. Zo analyseer je hoe vaak activiteiten plaatsvinden en hoe ze samenhangen met succesvolle betalingen. Waar vind je dit? Vastgelegd in tabellen met interactie- of activiteitengeschiedenis in Oracle Advanced Collections, zoals JTF_IH_ACTIVITIES, gekoppeld aan de klant en eventueel aan de specifieke factuur. Vastleggen Aanmaaktimestamp van records in JTF_IH_ACTIVITIES met een relevante uitkomst- of redencode. Gebeurtenistype explicit | |||
| Betalingsafspraak vastgelegd | Dit is een formele afspraak die in het systeem wordt vastgelegd: de klant belooft op een bepaalde datum te betalen. Dit is een belangrijke uitkomst van incassoactiviteiten. | ||
| Waarom dit belangrijk is Het bijhouden van betalingsafspraken en het percentage dat wordt nagekomen, is een belangrijke prestatie-indicator voor incassomedewerkers. Het helpt bij het voorspellen van de cashflow uit achterstallige vorderingen en bij het beoordelen van de effectiviteit van incassomedewerkers. Waar vind je dit? Expliciet aangemaakt in Oracle Advanced Collections. De aanmaakdatum komt uit de tabel IEX_PROMISE_DETAILS. Vastleggen Aanmaakdatum uit de tabel IEX_PROMISE_DETAILS voor de betreffende factuur. Gebeurtenistype explicit | |||
| Factuur gesloten | Dit gebeurt wanneer het openstaande saldo van de factuur nul wordt, door een betaling, een verwerkte creditnota of een correctie. Hiermee is de levenscyclus van de factuur succesvol afgerond. | ||
| Waarom dit belangrijk is Deze gebeurtenis is een belangrijk eindpunt voor een succesvol proces. Door te volgen wanneer facturen worden gesloten, krijg je inzicht in de algehele gezondheid van de debiteurenportefeuille. Waar vind je dit? Afgeleid uit een statuswijziging in de tabel AR_PAYMENT_SCHEDULES_ALL, waarbij STATUS verandert in ‘CL’ (Gesloten). De timestamp is de LAST_UPDATE_DATE van deze wijziging. Vastleggen Detecteer wanneer AR_PAYMENT_SCHEDULES_ALL.STATUS voor de factuur ‘CL’ wordt. Gebeurtenistype inferred | |||
| Factuur naar klant verzonden | Dit geeft aan dat de factuur officieel bij de klant is afgeleverd, digitaal of op papier. De gebeurtenis kan expliciet zijn vastgelegd in een aflevermodule of worden afgeleid van de afdrukdatum van de factuur. | ||
| Waarom dit belangrijk is Met deze activiteit begint de betalingstermijn van de klant. Door dit moment bij te houden, kun je het aantal dagen achterstand nauwkeurig berekenen en vertragingen tussen het aanmaken van de factuur en de melding aan de klant analyseren. Waar vind je dit? Dit kan worden vastgelegd met LAST_PRINTED_DATE in RA_CUSTOMER_TRX_ALL. Je kunt het ook afleiden uit integratielogs van e-mailbezorgsystemen of andere communicatieplatforms. Vastleggen Gebruik LAST_PRINTED_DATE uit RA_CUSTOMER_TRX_ALL of de status uit een afleverlog. Gebeurtenistype inferred | |||
| Geschil afgehandeld | Dit geeft aan dat een geregistreerd geschil is onderzocht en dat er een oplossing is gevonden. Dit wordt vastgelegd wanneer de betwiste status van de factuur wordt verwijderd. | ||
| Waarom dit belangrijk is Deze gebeurtenis markeert het einde van de afhandeling van het geschil. De tijd tussen ‘Geschil geregistreerd’ en deze gebeurtenis is een belangrijke KPI om de efficiëntie van de bedrijfsvoering en de invloed daarvan op de cashflow te meten. Waar vind je dit? Afgeleid wanneer STATUS in AR_PAYMENT_SCHEDULES_ALL verandert van ‘DS’ (Betwist) terug naar ‘OP’ (Open) of naar ‘CL’ (Gesloten) na een creditnota of correctie. Vastleggen Detecteer wanneer AR_PAYMENT_SCHEDULES_ALL.STATUS verandert van ‘DS’ naar een andere status. Gebeurtenistype inferred | |||
| Geschil geregistreerd | Dit geeft aan dat de klant de factuur formeel geheel of gedeeltelijk betwist. Dit wordt meestal vastgelegd als een statuswijziging in het betalingsschema van de factuur. | ||
| Waarom dit belangrijk is Deze activiteit markeert het begin van de afhandeling van het geschil. Door de tijd tussen registratie en afhandeling te analyseren, spoor je bottlenecks op die de inning vertragen. Waar vind je dit? Afgeleid uit een statuswijziging in de tabel AR_PAYMENT_SCHEDULES_ALL, waarbij het veld STATUS verandert in ‘DS’ (Betwist). De timestamp kan afkomstig zijn uit auditsporen of uit de datum van de laatste update. Vastleggen Detecteer wanneer AR_PAYMENT_SCHEDULES_ALL.STATUS voor de factuur verandert in ‘DS’. Gebeurtenistype inferred | |||
| Incassostrategie toegewezen | Dit gebeurt wanneer een geautomatiseerde incassostrategie wordt toegewezen aan een achterstallige factuur of klant. De strategie bepaalt welke stappen en activiteiten het systeem of de incassomedewerker volgt. | ||
| Waarom dit belangrijk is Deze gebeurtenis geeft inzicht in de automatisering van het incassoproces. Door te analyseren welke strategieën worden toegewezen en wat ze opleveren, kun je de incassoaanpak per klantsegment verbeteren. Waar vind je dit? Vastgelegd in de module Oracle Advanced Collections. Je vindt deze gebeurtenis meestal aan de hand van de aanmaakdatum van een strategietoewijzing in tabellen zoals IEX_STRATEGIES of gerelateerde objecten. Vastleggen Aanmaakdatum van het strategie-item in incassotabellen, gekoppeld aan de klant of transactie. Gebeurtenistype explicit | |||
| Kredietbeoordeling afgerond | Dit geeft aan dat de kredietbeoordeling is afgerond voor de klant die bij de factuur hoort. Deze gebeurtenis wordt meestal afgeleid door de factuurdatum te koppelen aan de meest recente datum waarop de kredietbeoordeling van de klantrekening is afgerond. Zo ontstaat een uitgangspunt voor kredietanalyses. | ||
| Waarom dit belangrijk is Door de tijd tussen de kredietbeoordeling en het plaatsen van de bestelling te analyseren, spoor je vertragingen in de eerste fasen van het order-to-cash-proces op. Dit vormt de basis voor het meten van de KPI Doorlooptijd kredietgoedkeuring en laat zien wat de invloed is van kredietbeslissingen. Waar vind je dit? Afgeleid door HZ_CREDIT_PROFILE.LAST_CREDIT_REVIEW_DATE op te vragen voor de klant op de factuur (RA_CUSTOMER_TRX_ALL.BILL_TO_CUSTOMER_ID). De timestamp van de gebeurtenis is de LAST_CREDIT_REVIEW_DATE die vóór de CREATION_DATE van de factuur valt. Vastleggen Koppel de factuur aan de meest recente kredietbeoordelingsdatum van de klant vóór het aanmaken van de factuur. Gebeurtenistype inferred | |||
Extractiegidsen
Stappen
- Open Oracle BI Publisher: Meld je aan bij je Oracle Fusion Financials-omgeving. Ga naar Reports and Analytics door op het Navigator-pictogram te klikken en vervolgens Tools > Reports and Analytics te kiezen.
- Maak een nieuw datamodel: Klik in het deelvenster Reports and Analytics op de knop 'Browse Catalog'. Klik in de catalogus op het vervolgkeuzemenu 'New' en kies 'Data Model'.
- Definieer de SQL-querydataset: Klik in de editor voor datamodellen op het pictogram '+' om een dataset toe te voegen en kies 'SQL Query'.
- Configureer de databron: Geef de nieuwe dataset een duidelijke naam, bijvoorbeeld 'CreditCollectionsEventLog'. Selecteer 'FSCM' of de juiste Oracle Fusion-applicatiedatabase als databron. Stel het SQL-type in op 'Standard SQL'.
- 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.
- Definieer queryparameters: De query gebruikt parameters zoals
:P_START_DATEen:P_END_DATEom de datums te filteren. BI Publisher herkent deze automatisch. Je kunt ze instellen als gebruikersprompts en het datatype op 'Date' zetten. - Sla het datamodel op en test het: Sla het datamodel op in een gedeelde of aangepaste map. Controleer of de query werkt door naar het tabblad 'Data' te gaan, voorbeeldwaarden voor de parameters in te voeren, bijvoorbeeld een recente periode, en op 'View' te klikken. Controleer of alle kolommen goed worden weergegeven.
- Maak een nieuw rapport: Ga terug naar de catalogus, klik op het vervolgkeuzemenu 'New' en kies 'Report'. Selecteer in het venster 'Create Report' de optie 'Use Data Model' en zoek het datamodel dat je zojuist hebt opgeslagen.
- Configureer de rapporteigenschappen: Voor data-extractie volstaat een eenvoudige tabelindeling in de rapporteditor. Stel het standaarduitvoerformaat in. Voor process mining is CSV het aanbevolen formaat. Klik hiervoor op 'View a List', zoek 'CSV' in de lijst 'Output Formats' en vink het vakje aan. Je kunt de andere formaten uitvinken om het gebruik eenvoudiger te maken.
- Sla het rapport op: Sla het rapport op in dezelfde map als het datamodel.
- Plan de extractie: Je kunt het rapport inplannen om de extractie te automatiseren. Open het rapport, klik op 'Actions' en kies 'Schedule'. Stel de frequentie in, bijvoorbeeld dagelijks, kies CSV als uitvoerformaat en geef de bestemming op, zoals een map op een contentserver of een externe server via FTP.
Configuratie
- Vereisten: De gebruiker die het rapport maakt en uitvoert, moet de juiste BI-rollen hebben, zoals 'BI Administrator' of 'BI Author', en toegangsrechten voor de onderliggende Financials-tabellen (AR, IEX, HZ, JTF).
- Databron: Voer de query uit op de hoofddatabase van de applicatie, doorgaans 'FSCM'.
- Parameters voor datumbereik: Gebruik de parameters
:P_START_DATEen:P_END_DATEom de hoeveelheid data te beperken. Begin bij het testen met een korte periode, bijvoorbeeld één maand. Voor productie is een voortschrijdende periode van 3 tot 6 maanden gebruikelijk. - Filters: Overweeg bij grote organisaties een parameter voor
BU_NAME(Business Unit Name) toe te voegen aan deWHERE-clausule in de common table expressioninvoices_base. Zo verwerk je telkens één bedrijfseenheid. - Aandachtspunten voor prestaties: De query koppelt meerdere grote transactietabellen. Bij een ruim datumbereik kan de uitvoering zonder filters lang duren of in BI Publisher een time-out veroorzaken. Plan het rapport buiten piekuren in.
- Uitvoerformaat: Controleer of het standaard- of geplande uitvoerformaat CSV is. Dit levert een overzichtelijk bestand met scheidingstekens op dat process mining-tools eenvoudig kunnen inlezen. Controleer bij de CSV-uitvoer of het scheidingsteken en de tekencodering goed zijn ingesteld.
Voorbeeldquery sql
WITH invoices_base AS (
SELECT
trx.customer_trx_id,
trx.trx_number AS InvoiceNumber,
hca.account_number AS CustomerNumber,
hcp.class_category || ':' || hcp.class_code AS CustomerSegment, -- Example of segment, may need adjustment
ps.amount_due_original AS InvoiceAmount,
coll.name AS Collector,
ps.due_date AS DueDate,
trx.creation_date AS InvoiceCreationDate,
trx.created_by AS InvoiceCreatedBy,
ps.payment_schedule_id
FROM
ra_customer_trx_all trx
JOIN ar_payment_schedules_all ps ON trx.customer_trx_id = ps.customer_trx_id
JOIN hz_cust_accounts hca ON trx.bill_to_customer_id = hca.cust_account_id
JOIN hz_customer_profiles hcp ON hca.cust_account_id = hcp.cust_account_id AND hcp.site_use_id IS NULL
LEFT JOIN iex_delinquencies_all del ON ps.payment_schedule_id = del.payment_schedule_id
LEFT JOIN JTF_RS_RESOURCE_EXTNS_VL coll ON del.collector_id = coll.resource_id
WHERE
trx.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')
AND trx.complete_flag = 'Y'
AND ps.class = 'INV'
)
-- 1. Credit Review Completed
SELECT
ib.InvoiceNumber AS "InvoiceNumber",
'Credit Review Completed' AS "ActivityName",
cr.review_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber AS "CustomerNumber",
ib.CustomerSegment AS "CustomerSegment",
ib.InvoiceAmount AS "InvoiceAmount",
ib.Collector AS "Collector",
NULL AS "DunningLevel",
ib.DueDate AS "DueDate",
cr.created_by AS "User"
FROM
invoices_base ib
JOIN
hz_credit_reviews cr ON ib.CustomerNumber = (SELECT hca.account_number FROM hz_cust_accounts hca WHERE hca.cust_account_id = cr.cust_account_id)
WHERE cr.review_date = (SELECT MAX(cr_inner.review_date) FROM hz_credit_reviews cr_inner WHERE cr_inner.cust_account_id = cr.cust_account_id AND cr_inner.review_date < ib.InvoiceCreationDate)
UNION ALL
-- 2. Invoice Generated
SELECT
ib.InvoiceNumber,
'Invoice Generated' AS "ActivityName",
trx.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.created_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
UNION ALL
-- 3. Invoice Sent To Customer
SELECT
ib.InvoiceNumber,
'Invoice Sent To Customer' AS "ActivityName",
trx.last_printed_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
WHERE trx.last_printed_date IS NOT NULL
UNION ALL
-- 4. Payment Due Date Passed
SELECT
ib.InvoiceNumber,
'Payment Due Date Passed' AS "ActivityName",
ps.due_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
'SYSTEM' AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.due_date < SYSDATE AND ps.status = 'OP'
UNION ALL
-- 5. Dunning Procedure Initiated
SELECT
ib.InvoiceNumber,
'Dunning Procedure Initiated' AS "ActivityName",
dunn.dunning_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
TO_CHAR(dunn.dunning_level) AS "DunningLevel",
ib.DueDate,
dunn.created_by AS "User"
FROM
invoices_base ib
JOIN iex_dunning_transactions dunt ON ib.customer_trx_id = dunt.transaction_id
JOIN iex_dunnings dunn ON dunt.dunning_id = dunn.dunning_id
UNION ALL
-- 6. Collection Strategy Assigned
SELECT
ib.InvoiceNumber,
'Collection Strategy Assigned' AS "ActivityName",
strat.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
strat.created_by AS "User"
FROM
invoices_base ib
JOIN iex_strategy_work_items swi ON ib.payment_schedule_id = swi.payment_schedule_id
JOIN iex_strategies_vl strat ON swi.strategy_id = strat.strategy_id
UNION ALL
-- 7. Collector Action Completed
SELECT
ib.InvoiceNumber,
task_type.name AS "ActivityName",
task.actual_end_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
res.source_name AS "User"
FROM
invoices_base ib
JOIN jtf_task_references_b ref ON ib.customer_trx_id = ref.object_id AND ref.object_type_code = 'OKC_K_HEADER'
JOIN jtf_tasks_b task ON ref.task_id = task.task_id
JOIN jtf_task_types_vl task_type ON task.task_type_id = task_type.task_type_id
JOIN jtf_rs_resource_extns_vl res ON task.owner_id = res.resource_id
WHERE task.actual_end_date IS NOT NULL
UNION ALL
-- 8. Promise To Pay Created
SELECT
ib.InvoiceNumber,
'Promise To Pay Created' AS "ActivityName",
prom.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
prom.created_by AS "User"
FROM
invoices_base ib
JOIN iex_promise_details prom ON ib.payment_schedule_id = prom.payment_schedule_id
UNION ALL
-- 9. Dispute Registered
SELECT
ib.InvoiceNumber,
'Dispute Registered' AS "ActivityName",
ps.dispute_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.amount_in_dispute IS NOT NULL AND ps.dispute_date IS NOT NULL
UNION ALL
-- 10. Dispute Resolved
SELECT
ib.InvoiceNumber,
'Dispute Resolved' AS "ActivityName",
disp.resolution_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
disp.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_disputes_all disp ON ib.payment_schedule_id = disp.payment_schedule_id
WHERE disp.status = 'CLOSED' AND disp.resolution_date IS NOT NULL
UNION ALL
-- 11. Payment Received
SELECT
ib.InvoiceNumber,
'Payment Received' AS "ActivityName",
cr.receipt_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
cr.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
JOIN ar_cash_receipts_all cr ON app.cash_receipt_id = cr.cash_receipt_id
WHERE app.status = 'APP'
UNION ALL
-- 12. Payment Applied
SELECT
ib.InvoiceNumber,
'Payment Applied' AS "ActivityName",
app.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
app.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
WHERE app.status = 'APP'
UNION ALL
-- 13. Invoice Closed
SELECT
ib.InvoiceNumber,
'Invoice Closed' AS "ActivityName",
ps.gl_date_closed AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.status = 'CL' AND ps.gl_date_closed IS NOT NULL
UNION ALL
-- 14. Invoice Written Off
SELECT
ib.InvoiceNumber,
'Invoice Written Off' AS "ActivityName",
adj.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
adj.created_by AS "User"
FROM
invoices_base ib
JOIN ar_adjustments_all adj ON ib.customer_trx_id = adj.customer_trx_id
JOIN ar_receivables_trx_all rt ON adj.receivables_trx_id = rt.receivables_trx_id
WHERE rt.name = '[Your Write-Off Activity Name]' -- Example: 'Bad Debt Write-off' Klaar om te beginnen?
Gebruik deze template om je data voor te bereiden op analyse en inzicht te krijgen in het proces voor kredietbeheer en incasso. Begin vandaag met het optimaliseren van je processen.
Optimaliseer vandaag nog kredietbeheer en incasso
Verkort de doorlooptijd met 30% en verbeter de financiële positie in Oracle Fusion.
Je hebt geen creditcard nodig. Je kunt binnen enkele minuten aan de slag.