Datatemplate voor order-to-cash-verwerking van verkooporders
Datatemplate voor order-to-cash-verwerking van verkooporders
- Aanbevolen attributen om te verzamelen
- Belangrijke activiteiten om te volgen
- Praktische uitleg over data-extractie
Attributen voor order-to-cash-verwerking van verkooporders
| Naam | Beschrijving | ||
|---|---|---|---|
| Verkooporder SalesOrder | De unieke identificatie van een verkooporder. Deze vormt de primaire case voor het proces van order tot betaling. | ||
| Beschrijving Het verkoopordernummer identificeert elke klantorder uniek gedurende de hele levenscyclus. Het verbindt alle bijbehorende activiteiten, van het aanmaken en bevestigen van de order tot de fulfilment, facturatie en uiteindelijke betaling. Bij process mining gebruik je dit attribuut om alle bijbehorende gebeurtenissen in één case te groeperen. Door het proces per verkooporder te analyseren, krijg je een volledig beeld van begin tot eind. Zo kun je de totale doorlooptijden berekenen, procesvarianten per order vinden en volgen hoe een order door verschillende afdelingen en systemen gaat. Waarom dit belangrijk is Dit is de Case-ID. De ID verbindt alle procesgebeurtenissen, zodat je het volledige verloop van één klantorder kunt volgen. Waar vind je dit? Deze identificatie staat meestal in de tabel met verkooporderkoppen in Oracle Fusion, bijvoorbeeld DOO_HEADERS_ALL. Raadpleeg de documentatie van Oracle Fusion Financials. Voorbeelden SO-100567SO-100568SO-100569 | |||
| Activiteitsnaam ActivityName | De naam van de specifieke bedrijfsgebeurtenis of taak die tijdens het verkooporderproces heeft plaatsgevonden. | ||
| Beschrijving Dit attribuut beschrijft welke stap op een bepaald moment voor een verkooporder is uitgevoerd, zoals ‘Verkooporder aangemaakt’, ‘Goederen verzonden’ of ‘Betaling ontvangen’. De volgorde van deze activiteiten vormt de processtroom van elke case. Analyse van ActivityName is een belangrijk onderdeel van process mining. Hiermee kun je de proceskaart weergeven, verschillende procesvarianten ontdekken en bottlenecks vinden waar cases zich ophopen. Het attribuut vormt de basis voor het berekenen van de tijd tussen stappen en voor inzicht in de volgorde van activiteiten in het proces van order tot betaling. Waarom dit belangrijk is Dit attribuut bepaalt de stappen op de proceskaart en maakt het mogelijk de processtroom weer te geven en te analyseren. Waar vind je dit? Dit afgeleide attribuut wordt samengesteld door transactiestatussen of gebeurtenistypen uit verschillende Oracle Fusion-tabellen, zoals orderstatus, verzendstatus en factuurstatus, om te zetten naar een gestandaardiseerde lijst met activiteitsnamen. Voorbeelden Verkooporder aangemaaktGoederen verzondenFactuur aangemaaktBetaling ontvangen | |||
| Tijdstip van gebeurtenis EventTime | De timestamp die aangeeft wanneer een specifieke activiteit of gebeurtenis voor een verkooporder plaatsvond. | ||
| Beschrijving Dit attribuut bevat de datum en tijd van elke activiteit in het proces en legt zo de chronologische volgorde van gebeurtenissen vast. Het registreert precies wanneer elke stap plaatsvond en vormt daarmee de tijdsbasis voor de procesanalyse. Bij process mining is EventTime nodig om doorlooptijden, de tijd tussen activiteiten en de totale doorlooptijd per case te berekenen. Het maakt prestatieanalyses mogelijk, helpt bottlenecks op basis van wachttijden te vinden en laat zien of afspraken over serviceniveaus (SLA’s) op tijd worden nagekomen. Alle tijdgerelateerde KPI’s en dashboards zijn afhankelijk van de nauwkeurigheid van dit attribuut. Waarom dit belangrijk is Deze timestamp is nodig om gebeurtenissen chronologisch te ordenen en alle tijdgerelateerde metrieken te berekenen, zoals doorlooptijden en tijdsduur. Waar vind je dit? Dit afgeleide attribuut komt uit verschillende timestampvelden in Oracle Fusion-tabellen, zoals de aanmaakdatum van de order, verzenddatum, factuurdatum en betaaldatum. Voorbeelden 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| Geautomatiseerd IsAutomated | Een aanduiding die aangeeft of het systeem de activiteit automatisch heeft uitgevoerd of dat een gebruiker dit handmatig heeft gedaan. | ||
| Beschrijving Dit booleaanse attribuut maakt onderscheid tussen systeemgestuurde gebeurtenissen, zoals een automatische kredietcontrole of een door het systeem aangemaakte factuur, en handmatige acties van gebruikers. Meestal wordt het afgeleid van de gebruikersnaam bij een activiteit. Een generieke systeem-ID duidt dan op automatisering. Met dit attribuut kun je de mate van automatisering in het proces meten. Het is ook een directe invoer voor de KPI ‘Percentage handmatig herstelde orders’. Je ziet welke handmatige stappen de meeste tijd kosten of het vaakst fouten opleveren, en waar verdere automatisering mogelijk is. Waarom dit belangrijk is Helpt de mate van automatisering in het proces te meten en mogelijkheden te vinden om kostbare handmatige handelingen te verminderen. Waar vind je dit? Dit is een afgeleid veld, vaak gebaseerd op een regel voor het attribuut UserName. Als de gebruiker bijvoorbeeld ‘SYSTEM’ of ‘BATCH’ is, krijgt deze aanduiding de waarde true. Voorbeelden truefalse | |||
| Gebruikersnaam UserName | De naam of ID van de gebruiker die de activiteit heeft uitgevoerd. | ||
| Beschrijving Dit attribuut identificeert de medewerker of systeemgebruiker die verantwoordelijk is voor een specifieke processtap. Je kunt het gebruiken om prestaties per gebruiker, de verdeling van het werk en het volgen van standaardprocedures te analyseren. Met een analyse per gebruiker vind je opleidingsbehoeften, herken je goed presterende medewerkers of teams en onderzoek je afwijkingen die door specifieke gebruikers zijn veroorzaakt. Het attribuut is ook nuttig voor compliance en audits, omdat je kunt nagaan wie welke acties heeft uitgevoerd. Waarom dit belangrijk is Maakt analyse mogelijk van prestaties per gebruiker en de verdeling van het werk. Ook kun je patronen in handmatig herstelwerk vinden die aan individuele gebruikers zijn gekoppeld. Waar vind je dit? Meestal afkomstig uit velden zoals CREATED_BY of LAST_UPDATED_BY in Oracle Fusion-transactietabellen. Deze zijn vaak gekoppeld aan een gebruikerstabel zoals FND_USER. Voorbeelden john.smithjane.doesystem_batch_user | |||
| Gevraagde leverdatum RequestedDeliveryDate | De leverdatum waarop de klant de order wil ontvangen. | ||
| Beschrijving Dit attribuut registreert op welke datum de klant de goederen wil ontvangen. Het is een belangrijke prestatiedoelstelling voor het fulfilmentgedeelte van het proces van order tot betaling. Deze datum is nodig om de KPI ‘Percentage tijdige leveringen’ te berekenen en het dashboard ‘Serviceafspraak voor levering (SLA)’ te ondersteunen. Door deze datum te vergelijken met ActualDeliveryDate, kan de organisatie meten of ze aan de verwachtingen van klanten voldoet en de oorzaken van vertragingen vinden. Waarom dit belangrijk is Vormt de basis voor het meten van tijdige leveringen en het naleven van serviceafspraken (SLA’s) met klanten. Waar vind je dit? Meestal te vinden in de tabellen met verkooporderregels in Oracle Fusion. Raadpleeg de documentatie van Oracle Fusion Financials. Voorbeelden 2023-05-202023-06-012023-05-25 | |||
| Klantnaam CustomerName | De naam van de klant die de verkooporder heeft geplaatst. | ||
| Beschrijving Dit attribuut geeft de officiële naam van de klantaccount bij de verkooporder. Het is een belangrijke dimensie om het proces vanuit het perspectief van de klant in te delen en te analyseren. Met een analyse per klant zie je of bepaalde klanten langere doorlooptijden hebben, vaker herstelwerk nodig hebben of specifieke procesafwijkingen ervaren. Je kunt deze informatie gebruiken om de klantenservice te verbeteren, processen voor belangrijke klanten aan te passen en problemen te onderzoeken die de klanttevredenheid beïnvloeden. Waarom dit belangrijk is Maakt analyse vanuit het perspectief van de klant mogelijk. Zo vind je procesproblemen die specifieke klanten raken en kun je de klanttevredenheid verbeteren. Waar vind je dit? Afkomstig uit klantstamgegevenstabellen, zoals HZ_PARTIES, en via een klant-ID gekoppeld aan de verkooporder. Voorbeelden Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| Totaalbedrag verkooporder SalesOrderTotalAmount | De totale geldwaarde van de verkooporder. | ||
| Beschrijving Dit attribuut geeft het totale bedrag weer dat voor de volledige verkooporder aan de klant in rekening wordt gebracht. Het omvat de som van alle orderregels, belastingen en overige kosten, voordat kortingen worden toegepast. Bij procesanalyse is dit attribuut belangrijk voor process mining op basis van orderwaarde. Je kunt orders op waarde indelen, bijvoorbeeld in hoge en lage orderwaarden, en nagaan of ze verschillende procesroutes of doorlooptijden hebben. Ook helpt het om verbeteringen te richten op cases met de grootste financiële impact. Waarom dit belangrijk is Maakt analyse van de financiële impact mogelijk. Zo kun je verbeteringen prioriteren voor orders met een hoge waarde en inzicht krijgen in de kostenfactoren. Waar vind je dit? Meestal te vinden in tabellen met verkooporderkoppen in Oracle Fusion. Raadpleeg de documentatie van Oracle Fusion Financials. Voorbeelden 5250.00125000.75980.50 | |||
| Uiterste betaaldatum PaymentDueDate | De datum waarop de klant de factuur uiterlijk moet betalen. | ||
| Beschrijving De uiterste betaaldatum wordt berekend op basis van de factuurdatum en de betalingsvoorwaarden die met de klant zijn afgesproken. De datum bepaalt wanneer de betaling uiterlijk binnen moet zijn. Dit attribuut is belangrijk voor de KPI ‘Percentage tijdig geïnde betalingen’. Door PaymentDueDate te vergelijken met de daadwerkelijke ontvangstdatum van de betaling, kan het systeem bepalen of een betaling op tijd of te laat was. Zo kun je de prestaties van debiteurenbeheer volgen en de kasstroom beheren. Waarom dit belangrijk is Vormt de deadline voor het berekenen van het percentage tijdige betalingen, een belangrijke maatstaf voor de efficiëntie van de kasstroom. Waar vind je dit? Te vinden in tabellen voor debiteurenbeheer of facturen in Oracle Fusion, zoals AR_PAYMENT_SCHEDULES_ALL. Voorbeelden 2023-06-192023-07-012023-06-25 | |||
| Verkoopkanaal SalesChannel | Het kanaal waarlangs de verkooporder is ontvangen. | ||
| Beschrijving Dit attribuut geeft aan waar de verkooporder vandaan komt, bijvoorbeeld ‘Web’, ‘Directe verkoop’, ‘Partner’ of ‘EDI’. Zo zie je hoe de order bij de organisatie is binnengekomen. Een analyse per verkoopkanaal is belangrijk voor het dashboard ‘Overzicht prestaties verkoopkanalen’. Hiermee kun je de efficiëntie, doorlooptijden en foutpercentages van verschillende kanalen vergelijken. Zo zie je welke kanalen het beste werken en waar procesverbeteringen of verdere automatisering nodig zijn. Waarom dit belangrijk is Ondersteunt prestatieanalyse per kanaal en helpt de meest en minst efficiënte kanalen voor orderverwerking te vinden. Waar vind je dit? Deze informatie kan zijn opgeslagen in een apart veld op de verkooporderkop. Raadpleeg de documentatie van Oracle Fusion Financials. Voorbeelden Directe verkoopWebportaalEDIWederverkoper | |||
| Werkelijke leverdatum ActualDeliveryDate | De datum waarop de goederen daadwerkelijk bij de klant zijn afgeleverd. | ||
| Beschrijving Dit attribuut registreert de uiteindelijke leverdatum, die het einde van het fulfilmentgedeelte van het proces markeert. Het is de werkelijke uitkomst waarmee geplande of gevraagde datums worden vergeleken. Deze datum wordt vergeleken met RequestedDeliveryDate om de prestaties van tijdige leveringen te berekenen. De datum is een belangrijke invoer voor de KPI ‘Percentage tijdige leveringen’ en het dashboard ‘Leverings-SLA’. Zo krijg je een duidelijk beeld van de prestaties van logistiek en de toeleveringsketen. Waarom dit belangrijk is Dit is de datum van de daadwerkelijke levering. Je gebruikt deze om het percentage tijdige leveringen te berekenen en de fulfilmentprestaties te toetsen aan de klantverzoeken. Waar vind je dit? Afkomstig uit verzend- en leveringstransactietabellen in Oracle Fusion. Raadpleeg de documentatie van Oracle Fusion Financials. Voorbeelden 2023-05-202023-06-032023-05-25 | |||
| Bedrijfseenheid BusinessUnitName | De naam van de interne bedrijfseenheid die verantwoordelijk is voor de verkooporder. | ||
| Beschrijving Dit attribuut geeft de specifieke afdeling of bedrijfseenheid aan die verantwoordelijk is voor de transactie. Zo kun je de prestaties van verschillende onderdelen van de organisatie vergelijken. Door het proces per bedrijfseenheid in te delen, zie je verschillen in efficiëntie, kosten en compliance binnen de organisatie. De analyse kan goede werkwijzen in goed presterende eenheden aan het licht brengen, zodat andere eenheden daarvan kunnen leren. Ook kun je zien waar gerichte procesverbeteringen nodig zijn. Waarom dit belangrijk is Maakt het mogelijk prestaties en procesconsistentie tussen verschillende organisatie-eenheden te vergelijken. Waar vind je dit? Meestal beschikbaar op de verkooporderkop en gekoppeld aan de organisatiestructuur in Oracle Fusion. Voorbeelden BU-Noord-AmerikaBU-EMEAGlobal Services | |||
| Betaling te laat IsLatePayment | Een berekende aanduiding die true is als de betaling na de uiterste betaaldatum is ontvangen. | ||
| Beschrijving Dit booleaanse attribuut wordt afgeleid door de daadwerkelijke ontvangstdatum van de betaling te vergelijken met PaymentDueDate. Het geeft duidelijk aan of een factuur op tijd is betaald. Dit attribuut wordt gebruikt om de KPI ‘Percentage tijdige betalingen’ te berekenen. Je kunt tijdige en te late betalingen eenvoudig apart analyseren en zo kenmerken van klanten die laat betalen, veelvoorkomende oorzaken van vertragingen en de financiële gevolgen voor het werkkapitaal onderzoeken. Waarom dit belangrijk is Meet rechtstreeks hoe effectief betalingen worden geïnd en vereenvoudigt de analyse van achterstallige betalingen. Waar vind je dit? Dit is een berekend veld. De logica is: PaymentReceivedDate > PaymentDueDate. Voorbeelden falsetrue | |||
| Betalingsvoorwaarden PaymentTerms | De afgesproken voorwaarden voor betaling door de klant. | ||
| Beschrijving Dit attribuut geeft aan onder welke voorwaarden een klant de factuur moet betalen, bijvoorbeeld ‘Netto 30’ of ‘Netto 60’. Deze voorwaarden vormen de basis voor de berekening van PaymentDueDate. Door orders op betalingsvoorwaarden in te delen, kun je verschillen in betalingsdoorlooptijden verklaren. Het attribuut geeft context bij de KPI ‘Percentage tijdige betalingen’, omdat verschillende voorwaarden tot ander betalingsgedrag leiden. Deze informatie kan helpen bij het bepalen van het kredietbeleid en het voorspellen van de kasstroom. Waarom dit belangrijk is Geeft belangrijke context voor de analyse van betalingsgedrag en helpt verschillen in de doorlooptijd van factuur tot betaling te verklaren. Waar vind je dit? Beschikbaar op het niveau van de verkooporder of klantaccount in Oracle Fusion. Raadpleeg de documentatie van Oracle Fusion Financials. Voorbeelden Netto 30Netto 60Verschuldigd bij ontvangst | |||
| Bronsysteem SourceSystemIdentifier | Geeft aan uit welk bronsysteem de gebeurtenisdata zijn gehaald. | ||
| Beschrijving Dit attribuut geeft aan waar de data vandaan komen. Dat is vooral handig als meerdere systemen betrokken zijn bij het proces van order tot betaling. Orderdata kunnen bijvoorbeeld uit Oracle Fusion komen, terwijl verzenddata afkomstig zijn van een extern logistiek systeem. In de analyse helpt dit om de herkomst van data te begrijpen. Je kunt er ook de procesweergave mee filteren op gebeurtenissen uit specifieke systemen. Het attribuut is belangrijk voor datavalidatie en om te zien waar het proces over verschillende IT-systemen is verdeeld. Waarom dit belangrijk is Geeft inzicht in de herkomst van data. Dat is belangrijk voor datagovernance en het oplossen van problemen in omgevingen met meerdere systemen. Waar vind je dit? Dit is meestal een vaste waarde die tijdens de data-extractie en -transformatie wordt toegevoegd om de herkomst van de dataset aan te geven. Voorbeelden Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| Factuur gecorrigeerd IsInvoiceCorrected | Een indicator die aangeeft of een factuur na de eerste aanmaak is gecorrigeerd of aangepast. | ||
| Beschrijving Dit booleaanse attribuut is waar als een factuur een correctieronde heeft doorlopen, herkenbaar aan de activiteit 'Factuur gecorrigeerd'. Het markeert cases waarin herstelwerk nodig was tijdens de facturering. Dit is een belangrijke invoer voor het dashboard 'Analyse van factuurnauwkeurigheid en herhaalwerk' en de KPI 'Percentage facturen met herhaalwerk'. Hiermee kun je de omvang van factureringsfouten meten en met oorzaakanalyse achterhalen waarom correcties nodig zijn. Zo kun je handmatig werk en betalingsvertragingen verminderen. Waarom dit belangrijk is Brengt herstelwerk aan facturen in kaart, een belangrijke aanwijzing voor inefficiënte processen, problemen met de datakwaliteit en mogelijke betalingsvertragingen. Waar vind je dit? Dit is een berekend veld. Voor een case wordt het doorgaans op waar gezet als de activiteit 'Factuur gecorrigeerd' in het event log voorkomt. Voorbeelden falsetrue | |||
| Factuurnummer InvoiceNumber | De unieke identificatie van de klantfactuur. | ||
| Beschrijving Dit attribuut is het unieke nummer van de factuur die voor de verkooporder is aangemaakt. Het verbindt de verkoop- en fulfilmentactiviteiten met de financiële afhandeling van het proces. De verkooporder is de primaire Case-ID, maar het factuurnummer is belangrijk voor analyses van facturatie- en betalingsprocessen. Je hebt het nodig om factuurcorrecties, geschillen en de betalingsstatus te volgen. Het ondersteunt dashboards zoals ‘Factuurnauwkeurigheid en analyse van herstelwerk’. Waarom dit belangrijk is Verbindt het proces met debiteurenbeheer en is nodig om herstelwerk aan facturen en betalingscycli te analyseren. Waar vind je dit? Beschikbaar in de transactietabellen voor debiteurenbeheer in Oracle Fusion, zoals RA_CUSTOMER_TRX_ALL. Voorbeelden INV-93485INV-93486INV-93487 | |||
| Laatste data-update LastUpdateDate | De timestamp die aangeeft wanneer de data voor deze gebeurtenis voor het laatst vanuit het bronsysteem zijn vernieuwd. | ||
| Beschrijving Dit attribuut registreert wanneer de data voor het laatst zijn opgehaald of bijgewerkt in de process mining-dataset. Zo zie je hoe actueel de data in de analyse zijn. Met deze informatie weet je hoe recent de procesanalyse is. Je kunt verwachtingen over de actualiteit van de data beheren en data-verversingsschema’s instellen en controleren. Waarom dit belangrijk is Geeft aan hoe actueel de data zijn, zodat je weet hoe recent de procesanalyse is. Waar vind je dit? Deze waarde wordt bij elke data-extractie en -transformatie aan de dataset toegevoegd. Voorbeelden 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Land van de klant CustomerCountry | Het land waar de klant is gevestigd. | ||
| Beschrijving Dit attribuut geeft het land aan op basis van het verzend- of factuuradres van de klant. Het is een belangrijke dimensie voor geografische analyses. Door het proces per land in te delen, zie je regionale verschillen in procesprestaties, doorlooptijden en betalingsgedrag. Dit helpt om de invloed van lokale regelgeving, logistieke uitdagingen en marktomstandigheden op het proces van order tot betaling te begrijpen. Waarom dit belangrijk is Maakt geografische analyse mogelijk om regionale verschillen in procesefficiëntie, compliance en klantgedrag te vinden. Waar vind je dit? Afkomstig uit klantstamgegevenstabellen (HZ_LOCATIONS, HZ_PARTY_SITES) die aan de verkooporder zijn gekoppeld. Voorbeelden USADuitslandJapan | |||
| Op tijd geleverd IsOnTimeDelivery | Een berekende aanduiding die true is als de daadwerkelijke levering op of vóór de gevraagde leverdatum plaatsvond. | ||
| Beschrijving Dit booleaanse attribuut wordt afgeleid door ActualDeliveryDate te vergelijken met RequestedDeliveryDate. Het geeft per case eenvoudig aan hoe de levering heeft gepresteerd. Deze aanduiding vormt de basis voor de KPI ‘Percentage tijdige leveringen’. Je kunt er eenvoudig mee filteren en analyseren, bijvoorbeeld om alle te laat geleverde orders te vinden en de oorzaken van vertragingen te onderzoeken. Waarom dit belangrijk is Meet de fulfilmentprestaties ten opzichte van de verwachtingen van klanten en maakt het eenvoudiger om te late orders te analyseren. Waar vind je dit? Dit is een berekend veld. De logica is: ActualDeliveryDate <= RequestedDeliveryDate. Voorbeelden truefalse | |||
| Ordertype OrderType | Een indeling van de verkooporder, bijvoorbeeld ‘Standaardorder’ of ‘Retourorder’. | ||
| Beschrijving Ordertype wordt gebruikt om verkooporders in te delen op basis van hun zakelijke doel. Veelvoorkomende typen zijn standaardverkooporders, serviceorders, retourautorisaties (RMA’s) en interne orders. Het is belangrijk om het proces per ordertype te analyseren, omdat verschillende typen vaak een eigen processtroom en prestatiedoelen hebben. Door de orders zo in te delen, kun je bewuste en verwachte procesvarianten herkennen en voorkom je dat je ze ten onrechte als afwijkingen ziet. Waarom dit belangrijk is Maakt het mogelijk verschillende geldige processtromen, zoals standaardorders en retouren, apart te analyseren voor een eerlijke en nauwkeurige analyse. Waar vind je dit? Meestal beschikbaar als veld op de tabel met verkooporderkoppen in Oracle Fusion. Raadpleeg de documentatie van Oracle Fusion Financials. Voorbeelden StandaardverkooporderRetourautorisatieServiceorder | |||
| Productnaam ProductName | De naam van het verkochte product of de verkochte dienst. | ||
| Beschrijving Dit attribuut geeft het artikel op de verkooporderregel aan. Als een order meerdere regels heeft, kan de case op regelniveau worden geanalyseerd of kan dit attribuut op kopniveau worden samengevoegd. Met een analyse per product zie je of bepaalde producten samengaan met complexere of problematische processtromen, zoals regelmatige leveringsvertragingen of betalingsproblemen. Deze informatie kan helpen bij productbeheer en strategieën voor de toeleveringsketen. Waarom dit belangrijk is Maakt het mogelijk de procesprestaties van verschillende producten te analyseren en artikelen te vinden met complexe fulfilment- of facturatieroutes. Waar vind je dit? Afkomstig uit de tabellen met verkooporderregels en gekoppeld aan een productstamtabel. Raadpleeg de documentatie van Oracle Fusion Financials. Voorbeelden Standard Widget X1Premium Service PackageComponent Y2-B | |||
| Verzendmethode ShippingMethod | De methode of vervoerder die wordt gebruikt om de goederen naar de klant te verzenden. | ||
| Beschrijving Dit attribuut geeft de logistieke vervoerder of het serviceniveau voor de levering aan, bijvoorbeeld ‘Wegtransport’, ‘Luchtvracht’ of ‘Lokale koerier’. Deze informatie is belangrijk voor het dashboard ‘Naleving van leverafspraken per verzendmethode’. Hiermee kun je de prestaties van tijdige leveringen en de verzendkosten van verschillende methoden en vervoerders vergelijken. Zo kun je de logistieke strategie en de keuze van leveranciers verbeteren. Waarom dit belangrijk is Ondersteunt logistieke analyses doordat je de prestaties van verschillende vervoerders en verzendmethoden kunt vergelijken. Waar vind je dit? Beschikbaar in de verzend- en fulfilmenttabellen in Oracle Fusion. Raadpleeg de documentatie van Oracle Fusion Financials. Voorbeelden FedEx GroundUPS Next Day AirDHL International | |||
Activiteiten voor order-to-cash-verwerking van verkooporders
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Betaling ontvangen | Deze activiteit geeft aan dat de betaling van de klant is ontvangen en in Accounts Receivable aan de factuur is toegewezen. Dit wordt vastgelegd wanneer een ontvangstboeking wordt verwerkt. | ||
| Waarom dit belangrijk is Dit is een belangrijk meetpunt voor de ‘Totale doorlooptijd van order tot betaling’ en het ‘Percentage tijdige betalingen’. Het markeert het moment waarop de verkoop in geld wordt omgezet. Waar vind je dit? Dit is een expliciete gebeurtenis in Oracle Accounts Receivable. De gebeurtenis wordt vastgelegd in tabellen voor ontvangen betalingen, zoals AR_RECEIVABLE_APPLICATIONS_ALL, wanneer een betaling aan een factuur wordt toegewezen. Vastleggen Vastgelegd op basis van de timestamp van het veld ‘apply date’ in de registratie van de betalingstoewijzing in AR. Gebeurtenistype explicit | |||
| Factuur aangemaakt | Deze activiteit staat voor het aanmaken van de klantfactuur in de module Accounts Receivable. Dit gebeurt meestal na de verzendbevestiging. Het systeem maakt een factuurrecord aan met een uniek nummer en een aanmaakdatum. | ||
| Waarom dit belangrijk is Dit markeert het officiële begin van de betalingsinning. De activiteit vormt de basis voor het meten van ‘Invoice to Payment Time’ en de efficiëntie van de totale kasstroom. Waar vind je dit? Dit is een expliciete gebeurtenis in Oracle Accounts Receivable (AR). Er wordt een factuurrecord met een transactiedatum aangemaakt in de tabel RA_CUSTOMER_TRX_ALL. Vastleggen Afgeleid van de aanmaakdatum van de factuurtransactie in de AR-module. Gebeurtenistype explicit | |||
| Goederen verzonden | Deze activiteit markeert het moment waarop de goederen het magazijn verlaten en onderweg zijn naar de klant. De activiteit wordt vastgelegd wanneer een verzendbevestigingstransactie in Oracle Shipping wordt verwerkt. | ||
| Waarom dit belangrijk is Dit is een belangrijke mijlpaal: het afhandelingsdeel van het proces is afgerond en de facturering wordt gestart. De activiteit is nodig om verzendingen op tijd en levertijden te meten. Waar vind je dit? Dit is een expliciete gebeurtenis in Oracle Shipping Execution. De verzendbevestigingstransactie maakt een record aan in verzendtabellen zoals WSH_DELIVERY_DETAILS, met een verzenddatum. Vastleggen Afgeleid van de timestamp ‘actual ship date’ in het leveringsdetailrecord dat bij de orderregel hoort. Gebeurtenistype explicit | |||
| Order bevestigd | Deze belangrijke mijlpaal geeft aan dat de verkooporder alle eerste controles, waaronder de kredietgoedkeuring, heeft doorlopen en klaar is voor afhandeling. Meestal wordt dit afgeleid wanneer de orderstatus verandert in bijvoorbeeld ‘Awaiting Shipping’ of ‘Scheduled’. | ||
| Waarom dit belangrijk is Deze activiteit is een belangrijke mijlpaal voor het berekenen van de ‘Average Order Confirmation Time’. Ook markeert ze de overgang van orderinvoer naar orderafhandeling. Waar vind je dit? Af te leiden uit een statuswijziging van de verkooporderkop of orderregel naar een status die aangeeft dat de order klaar is voor afhandeling, bijvoorbeeld ‘Awaiting Shipping’. Controleer de statuskolommen in DOO_HEADERS_ALL of DOO_FULFILL_LINES_ALL. Vastleggen Afgeleid van de timestamp waarop de orderstatus verandert in bevestigd of ingepland. Gebeurtenistype inferred | |||
| Order gesloten | De laatste activiteit in het proces. Alle regels van de verkooporder zijn geleverd, gefactureerd en gesloten. De status van de orderkop wordt bijgewerkt naar ‘Closed’. | ||
| Waarom dit belangrijk is Deze activiteit markeert het succesvolle einde van de levenscyclus van de verkooporder. De activiteit is nodig om de totale doorlooptijd van het proces te berekenen en orders te vinden die nooit worden gesloten. Waar vind je dit? Af te leiden uit de statuswijziging van de verkooporderkop naar ‘Closed’ in de tabel DOO_HEADERS_ALL. De timestamp van deze laatste statuswijziging geldt als het tijdstip van de gebeurtenis. Vastleggen Af te leiden uit de timestamp van de statuswijziging naar ‘Closed’ op de verkooporderkop. Gebeurtenistype inferred | |||
| Verkooporder aangemaakt | Deze activiteit markeert het begin van het verkooporderproces: het moment waarop een nieuwe verkooporder in Oracle Fusion wordt ingevoerd. Meestal wordt deze gebeurtenis expliciet vastgelegd wanneer een gebruiker een nieuwe order opslaat in de module Order Management. | ||
| Waarom dit belangrijk is Als startpunt van het proces is deze activiteit nodig om de totale doorlooptijd van Order to Cash te meten en het aantal binnenkomende orders te analyseren. Waar vind je dit? Wordt expliciet vastgelegd wanneer een verkooporderrecord wordt aangemaakt in Order Management Cloud. Zoek naar aanmaaktimestamps in de tabel DOO_HEADERS_ALL. Vastleggen Afgeleid van de timestamp waarop de verkooporderkop wordt aangemaakt. Gebeurtenistype explicit | |||
| Factuur gecorrigeerd | Dit gebeurt wanneer een eerder aangemaakte factuur wordt aangepast, opnieuw wordt verstuurd of wordt gecrediteerd vanwege fouten of een geschil met de klant. Dit wordt meestal vastgelegd door een creditnota aan te maken of een nieuwe versie van de factuur te maken. | ||
| Waarom dit belangrijk is Het bijhouden van factuurcorrecties is belangrijk voor de KPI ‘Factuurherstelpercentage’. Deze KPI brengt problemen in het facturatieproces aan het licht die betalingen kunnen vertragen en de administratieve kosten verhogen. Waar vind je dit? Af te leiden uit het aanmaken van een creditnota die aan de oorspronkelijke factuur is gekoppeld, of uit een latere versie van dezelfde factuur in de tabel RA_CUSTOMER_TRX_ALL. Vastleggen Af te leiden door creditnota’s of facturen te vinden die verwijzen naar een eerdere factuurtransactie. Gebeurtenistype inferred | |||
| Goederen geleverd | Geeft aan dat de klant de zending heeft ontvangen. Deze informatie komt vaak van een externe vervoerder en wordt bijgewerkt in Oracle Fusion. Je kunt de levering ook afleiden op basis van een standaardtransittijd vanaf de verzenddatum. | ||
| Waarom dit belangrijk is Deze activiteit is nodig om de KPI ‘On-Time Delivery Rate’ te berekenen en het serviceniveau voor klanten goed te meten. Waar vind je dit? Dit is vaak geen standaardgebeurtenis in Oracle. De levering kan worden vastgelegd als er een koppeling met de vervoerder is, of worden berekend door een standaardtransittijd op te tellen bij de datum van ‘Goods Shipped’. Hiervoor is systeemanalyse nodig. Vastleggen Afgeleid van gegevens van de vervoerder of berekend op basis van de verzenddatum plus een gemiddelde transittijd. Gebeurtenistype inferred | |||
| Goederen verzameld | Dit is het fysiek verzamelen van goederen in het magazijn om de order af te handelen. Het is een belangrijke stap in het logistieke proces en wordt meestal vastgelegd in de magazijnbeheer- of verzendmodule. | ||
| Waarom dit belangrijk is Deze activiteit geeft inzicht in de magazijnprocessen. Vertraging tussen het reserveren van voorraad en het verzamelen van goederen kan wijzen op problemen met middelen of procesbottlenecks in het magazijn. Waar vind je dit? Wordt vastgelegd in de Oracle Fusion Cloud SCM-modules (Supply Chain Management). Je kunt de activiteit afleiden uit een statuswijziging van een pick wave of pick slip die bij de verkooporderregel hoort. Vastleggen Afgeleid van de timestamp waarop de verzameltransactie in de SCM-modules wordt afgerond. Gebeurtenistype inferred | |||
| Kredietblokkade ingesteld | Deze activiteit vindt plaats wanneer een verkooporder automatisch of handmatig wordt geblokkeerd vanwege een mislukte kredietcontrole of een ander kredietprobleem. Dit wordt meestal vastgelegd als een wijziging van de blokkeringsstatus van de order in het systeem. | ||
| Waarom dit belangrijk is Door kredietblokkades te volgen, kun je achterhalen waarom de orderverwerking vertraging oploopt en meten hoe efficiënt kredietblokkades worden opgeheven. Waar vind je dit? Af te leiden uit het instellen van een blokkade op de verkooporder. Dit wordt meestal vastgelegd in blokkeringstabellen zoals DOO_HOLDS_ALL, gekoppeld aan de verkooporder. Vastleggen Afgeleid van een record in de orderblokkeringstabel met het blokkeringstype ‘Credit’. Gebeurtenistype inferred | |||
| Kredietcontrole uitgevoerd | Dit is de kredietcontrole van de klantrekening om de kredietwaardigheid te beoordelen. Deze stap in de orderverwerking verloopt vaak automatisch of handmatig. De afronding wordt meestal vastgelegd als een statuswijziging of als een voltooide taak. | ||
| Waarom dit belangrijk is Door de tijd voor kredietcontroles te analyseren, kun je bottlenecks bij de ordergoedkeuring vinden. Deze meting is belangrijk voor de KPI ‘Credit Check to Confirmed Time’. Waar vind je dit? Af te leiden uit statuswijzigingen van de verkooporder, bijvoorbeeld wanneer de status verandert in ‘Pending Credit Approval’. De gebeurtenis kan ook expliciet worden vastgelegd in de kredietbeheerfunctie. Vastleggen Afgeleid van statuswijzigingen van de order of timestamps van kredietbeoordelingstaken. Gebeurtenistype inferred | |||
| Order geannuleerd | Dit is de annulering van een verkooporder voordat deze volledig is verzonden. Dat kan verschillende oorzaken hebben en leidt tot de eindstatus ‘Cancelled’. | ||
| Waarom dit belangrijk is Dit is een belangrijke uitzonderingsroute. Door geannuleerde orders te analyseren, vind je mogelijke oorzaken, zoals voorraadtekorten, prijsproblemen of een klant die van gedachten verandert. Die informatie kan helpen om het proces te verbeteren. Waar vind je dit? Af te leiden uit een statuswijziging naar ‘Cancelled’ op de verkooporderkop of -regel. De timestamp van deze statuswijziging wordt gebruikt om de gebeurtenis vast te leggen. Vastleggen Af te leiden uit de timestamp van de statuswijziging naar ‘Cancelled’ op de orderkop of -regel. Gebeurtenistype inferred | |||
| Orderregel gesloten | Dit is de definitieve afsluiting van een afzonderlijke verkooporderregel. De regel is volledig verzonden en gefactureerd en er worden geen verdere transacties verwacht. De status van de regel wordt bijgewerkt naar ‘Closed’. | ||
| Waarom dit belangrijk is Als een orderregel wordt gesloten, zijn alle contractuele verplichtingen voor dat artikel afgerond. Door dit te analyseren, vind je orders die lang na levering en betaling nog openstaan. Waar vind je dit? Af te leiden uit de statuswijziging van de fulfilmentregel naar ‘Closed’ in de tabel DOO_FULFILL_LINES_ALL. De timestamp van deze statuswijziging markeert de gebeurtenis. Vastleggen Af te leiden uit de timestamp van de statuswijziging naar ‘Closed’ op de fulfilmentregel. Gebeurtenistype inferred | |||
| Voorraad gereserveerd | Deze activiteit staat voor het toewijzen of reserveren van fysieke voorraad voor een verkooporderregel. Het systeem reserveert specifieke voorraad, zodat die beschikbaar is wanneer de order wordt verzameld. | ||
| Waarom dit belangrijk is Door deze activiteit te volgen, kun je de KPI ‘Inventory Allocation Lead Time’ analyseren en vertragingen tussen de orderbevestiging en het reserveren van goederen vinden. Waar vind je dit? Deze gebeurtenis wordt vaak vastgelegd in modules voor voorraadbeheer of supply chain-uitvoering. Je kunt haar afleiden uit statusupdates van de orderregel die aangeven dat de voorraad is toegewezen of gereserveerd. Vastleggen Afgeleid van statuswijzigingen van de orderregel die verband houden met voorraadreservering of planning. Gebeurtenistype inferred | |||
Extractiegidsen
Stappen
- Ga naar Oracle BI Publisher: Meld je aan bij je Oracle Fusion-omgeving met een gebruiker die BI Administrator- of BI Author-rechten heeft. Open het menu Navigator en ga naar Tools > Reports and Analytics. Klik op de knop 'Browse Catalog' om de Business Intelligence Catalog te openen.
- Maak een nieuw datamodel: Ga in de BI Catalog naar een geschikte map, bijvoorbeeld Shared Folders > Custom. Klik op het vervolgkeuzemenu 'New' en selecteer 'Data Model'.
- Stel de SQL Query-dataset in: Klik in de Data Model-editor op het pictogram '+' om een nieuwe dataset te maken en selecteer 'SQL Query'. Er verschijnt een dialoogvenster. Geef de dataset een naam, bijvoorbeeld 'OrderToCash_EventLog', selecteer 'Oracle BI EE' als databron en kies 'Standard SQL' als SQL-type.
- Voer de SQL-query in: Kopieer de volledige SQL-query uit het gedeelte 'query' van dit document en plak deze in het tekstvak SQL Query. De query bevat parameters voor de begin- en einddatum (:p_start_date en :p_end_date). BI Publisher herkent deze automatisch.
- Stel de eigenschappen van het datamodel in: Klik na het plakken van de query op 'OK'. Ga in het linkerpaneel van de Data Model-editor naar het gedeelte 'Properties'. Controleer of 'Include Parameter Tags' is aangevinkt. Je kunt desgewenst ook standaardwaarden voor de datumparameters instellen.
- Bekijk en sla het datamodel op: Klik op het tabblad 'Data'. Mogelijk wordt gevraagd om waarden voor de datumparameters in te voeren. Geef een korte periode op om de query te testen. Klik op 'View' om een voorbeeld van de data te bekijken. Ziet de data er goed uit, sla het datamodel dan op via het opslagpictogram en geef het een duidelijke naam, bijvoorbeeld 'OrderToCash_EventLog_DM'.
- Maak een rapport op basis van het datamodel: Klik na het opslaan van het datamodel rechtsboven op de knop 'Create Report'. De wizard voor het maken van rapporten wordt geopend.
- Stel het rapport in: Selecteer in de wizard de optie 'Use Data Model'. De wizard begeleidt je bij het instellen van de lay-out. Voor een eenvoudige CSV-export kun je de lay-out 'Table' kiezen. Sleep alle kolommen naar de tabel. Klik op 'Next' en schakel 'Show Grand Totals Row' uit. Klik op 'Finish' om het rapport op te slaan. Geef het een naam, bijvoorbeeld 'OrderToCash_EventLog_Report'.
- Voer het rapport uit: Open het nieuwe rapport. Je wordt gevraagd om de begin- en einddatum voor de extractie in te voeren. Geef de gewenste periode op.
- Exporteer de data: Klik zodra het rapport is uitgevoerd op het vervolgkeuzemenu 'View' en selecteer een andere weergaveoptie, zoals 'View Report'. Zoek vervolgens de link of het pictogram 'Export' en kies 'CSV' als exportformaat. Het event log wordt dan gedownload.
- Bereid de upload voor: Open het gedownloade CSV-bestand. Controleer of de kolomkoppen overeenkomen met de vereiste attributen: SalesOrder, ActivityName, EventTime, UserName, SalesOrderTotalAmount, CustomerName, SalesChannel, RequestedDeliveryDate, ActualDeliveryDate, PaymentDueDate en IsAutomated. Het bestand is nu klaar om te uploaden naar de process mining-tool.
Configuratie
- Gebruikersrechten: Je hebt een rol nodig met rechten om datamodellen en rapporten in BI Publisher te maken, zoals 'BI Administrator' of 'BI Author'.
- Databron: De query is bedoeld voor de standaarddatabron 'Oracle BI EE', die verbinding maakt met de transactionele database (Fusion Apps). Meestal is hiervoor geen speciale configuratie nodig.
- Parameters voor de periode: De query gebruikt twee parameters, :p_start_date en :p_end_date, om de data te filteren. Het is sterk aan te raden de data in behapbare batches op te halen, bijvoorbeeld per periode van 3 tot 6 maanden. Zo voorkom je time-outs en prestatieproblemen bij rapporten.
- Filteren op bedrijfseenheid: Je kunt de extractie beperken door in de query een WHERE-clausule toe te voegen aan de CTE BaseOrders. Daarmee filter je op een specifieke ID van een bedrijfseenheid, bijvoorbeeld AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID]).
- Filteren op ordertype: Je kunt ook specifieke typen verkooporders selecteren door in de CTE BaseOrders een voorwaarde toe te voegen voor dhead.SOURCE_ORDER_TYPE_CODE.
- Prestaties: Bij zeer grote datasets die meerdere jaren beslaan, kan deze queryaanpak traag zijn. Voer de query buiten piekuren uit of splits de extractie op in kleinere maandelijkse batches. Controleer in het datamodel of de eigenschap 'Enable SQL Pruning' is uitgeschakeld, omdat deze complexe UNION-query's kan verstoren.
Voorbeeldquery sql
WITH BaseOrders AS (
SELECT
dhead.HEADER_ID,
dhead.ORDER_NUMBER AS SalesOrder,
dhead.CREATION_DATE,
dhead.CREATED_BY,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.CREATED_BY AND ROWNUM = 1) AS UserName,
dhead.SUBMITTING_BU_ID,
dhead.AMOUNT AS SalesOrderTotalAmount,
hp_sold.PARTY_NAME AS CustomerName,
dhead.SALES_CHANNEL_CODE AS SalesChannel,
dfl.REQUEST_SHIP_DATE AS RequestedDeliveryDate
FROM
DOO_HEADERS_ALL dhead
JOIN
DOO_FULFILL_LINES_ALL dfl ON dhead.HEADER_ID = dfl.HEADER_ID
JOIN
HZ_CUST_ACCOUNTS hc_sold ON dhead.SOLD_TO_CUSTOMER_ID = hc_sold.CUST_ACCOUNT_ID
JOIN
HZ_PARTIES hp_sold ON hc_sold.PARTY_ID = hp_sold.PARTY_ID
WHERE
dhead.OBJECT_VERSION_NUMBER = 1
AND dfl.LINE_NUMBER = 1 -- To avoid duplicating header-level events for each line
AND dhead.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
)
-- 1. Sales Order Created
SELECT
bo.SalesOrder,
'Sales Order Created' AS ActivityName,
bo.CREATION_DATE AS EventTime,
bo.UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN bo.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM BaseOrders bo
UNION ALL
-- 2. Credit Check Performed (inferred from Credit Hold Release)
SELECT
bo.SalesOrder,
'Credit Check Performed' AS ActivityName,
dha.RELEASED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.RELEASED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.RELEASED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.RELEASED_FLAG = 'Y' AND dha.RELEASED_DATE IS NOT NULL
UNION ALL
-- 3. Credit Hold Applied
SELECT
bo.SalesOrder,
'Credit Hold Applied' AS ActivityName,
dha.APPLIED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.APPLIED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.APPLIED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.APPLIED_DATE IS NOT NULL
UNION ALL
-- 4. Order Confirmed (inferred from status 'Awaiting Shipping')
SELECT
bo.SalesOrder,
'Order Confirmed' AS ActivityName,
dfl.STATUS_CHANGE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'AWAIT_SHIP'
UNION ALL
-- 5. Inventory Reserved
SELECT
bo.SalesOrder,
'Inventory Reserved' AS ActivityName,
irl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = irl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN irl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM INV_RESERVATIONS irl
JOIN DOO_FULFILL_LINES_ALL dfl ON irl.DEMAND_SOURCE_LINE_ID = dfl.FULFILL_LINE_ID
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE irl.DEMAND_SOURCE_TYPE_ID = 2 -- Order Entry
UNION ALL
-- 6. Goods Picked (inferred from delivery detail status 'Staged')
SELECT
bo.SalesOrder,
'Goods Picked' AS ActivityName,
wdd.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wdd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wdd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_DELIVERY_DETAILS wdd
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wdd.RELEASED_STATUS = 'S' -- 'S' typically means Staged/Picked
UNION ALL
-- 7. Goods Shipped
SELECT
bo.SalesOrder,
'Goods Shipped' AS ActivityName,
wnd.INITIAL_PICKUP_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.STATUS_CODE = 'CL' -- Closed/Shipped
UNION ALL
-- 8. Goods Delivered
SELECT
bo.SalesOrder,
'Goods Delivered' AS ActivityName,
wnd.ULTIMATE_DROPOFF_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
wnd.ULTIMATE_DROPOFF_DATE AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.ULTIMATE_DROPOFF_DATE IS NOT NULL
UNION ALL
-- 9. Invoice Created
SELECT
bo.SalesOrder,
'Invoice Created' AS ActivityName,
rct.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
aps.DUE_DATE AS PaymentDueDate,
CASE WHEN rct.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.CUSTOMER_TRX_ID = aps.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 10. Invoice Corrected (Credit Memo)
SELECT
bo.SalesOrder,
'Invoice Corrected' AS ActivityName,
rct_cm.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct_cm.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN rct_cm.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct_cm
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_cm ON rct_cm.CUSTOMER_TRX_ID = rctl_cm.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_ALL rct_orig ON rct_cm.PREVIOUS_CUSTOMER_TRX_ID = rct_orig.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_orig ON rct_orig.CUSTOMER_TRX_ID = rctl_orig.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl_orig.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl_orig.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl_cm.LINE_TYPE = 'LINE'
UNION ALL
-- 11. Payment Received
SELECT
bo.SalesOrder,
'Payment Received' AS ActivityName,
araa.APPLY_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = araa.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN araa.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM AR_RECEIVABLE_APPLICATIONS_ALL araa
JOIN RA_CUSTOMER_TRX_ALL rct ON araa.APPLIED_CUSTOMER_TRX_ID = rct.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE araa.STATUS = 'APP' AND rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 12. Order Line Closed
SELECT
bo.SalesOrder,
'Order Line Closed' AS ActivityName,
dfl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'CLOSED'
UNION ALL
-- 13. Order Closed
SELECT
bo.SalesOrder,
'Order Closed' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CLOSED'
UNION ALL
-- 14. Order Cancelled
SELECT
bo.SalesOrder,
'Order Cancelled' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CANCELED'Stappen
- Open de BICC-console: Meld je aan bij je Oracle Fusion Applications-instantie met een gebruiker met de rol BICC_ADMINISTRATOR. Ga naar Tools en selecteer Business Intelligence Cloud Connector in het menu.
- Maak een nieuwe aanbieding: Klik in de BICC-console op Configure External Storage om de doellocatie in te stellen. Dit kan Oracle Universal Content Management (UCM) of een OCI Object Storage-bucket zijn. Controleer of de verbindingsgegevens en inloggegevens kloppen.
- Start een nieuwe extractietaak: Ga naar Manage Extract Jobs. Klik op het pictogram + om een nieuwe taak te maken. Geef de taak een duidelijke naam, bijvoorbeeld ProcessMind_O2C_SalesOrder_Extract.
- Selecteer datastores (PVO's): Zoek in de taakinstellingen naar de Public View Objects (PVO's) die nodig zijn om de levenscyclus van verkooporders vast te leggen en voeg ze toe. Je hebt meerdere PVO's nodig, waaronder FscmTopModelAM.DooTopAM.Header, FscmTopModelAM.DooTopAM.FulfillLine, FscmTopModelAM.DooTopAM.HoldInstance, FscmTopModelAM.ScmTopAM.ShipmentLine, FscmTopModelAM.ArTopAM.ReceivableInvoice en FscmTopModelAM.ArTopAM.CashReceiptApplication.
- Stel de kolommen per PVO in: Klik voor elke geselecteerde PVO op het menu Actions en kies Select Columns. Selecteer zorgvuldig de kolommen die nodig zijn voor het event log, zoals HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate en gebruikers-ID's. Raadpleeg het querymanifest voor een volledige lijst met vereiste kolommen per PVO.
- Stel filters in voor incrementeel laden: Beperk de hoeveelheid data door elke PVO te filteren op de kolom LastUpdateDate. Voor de eerste uitvoering kun je een ruime periode kiezen. Stel het filter voor volgende geplande uitvoeringen zo in dat alleen records worden opgehaald die sinds de vorige taak zijn bijgewerkt.
- Plan de extractietaak: Ga naar Manage Schedule en maak een planning voor de taak. Voer de taak bij voorkeur buiten piekuren uit, bijvoorbeeld elke nacht, om de invloed op de systeemprestaties te beperken.
- Verzend en volg de taak: Verzend de taak zodra deze is ingesteld. Je kunt de voortgang volgen op het scherm Manage Extract Jobs. Na een geslaagde uitvoering staan de databestanden in gecomprimeerd CSV-formaat op de ingestelde cloudopslaglocatie.
- Zet ruwe data om in een event log: Download de geëxtraheerde CSV-bestanden. BICC levert ruwe tabeldata, geen kant-en-klaar event log. Gebruik een externe tool, zoals Python, een databasescript of een ETL-platform, om de bestanden te verwerken. Dat houdt onder meer in:
- Data uit verschillende bestanden samenvoegen, bijvoorbeeld factuurdata koppelen aan de verkooporderkop.
- Datumkolommen omzetten in afzonderlijke activiteitenrijen. Maak bijvoorbeeld op basis van het bestand FscmTopModelAM.DooTopAM.Header één rij voor Sales Order Created met CreationDate en een andere voor Order Closed met ClosedDate.
- Statuscodes of indicatoren koppelen aan specifieke activiteiten, zoals Order Confirmed of Order Cancelled.
- Alle omgezette data samenvoegen in één bestand met de vereiste kolommen: SalesOrder, ActivityName en EventTime.
- Maak het bestand klaar om te uploaden: Zorg dat het uiteindelijke bestand één CSV-bestand is met kolommen die overeenkomen met de vereiste en aanbevolen attributen. Het bestand is nu klaar om te uploaden naar ProcessMind.
Configuratie
- PVO-selectie: De nauwkeurigheid van het event log hangt volledig af van de keuze van de juiste PVO's. Belangrijke PVO's zijn FscmTopModelAM.DooTopAM.Header (voor het aanmaken en sluiten van orders), FscmTopModelAM.ScmTopAM.ShipmentLine (voor verzendactiviteiten) en FscmTopModelAM.ArTopAM.ReceivableInvoice (voor facturering).
- Incrementele extractie: Gebruik bij terugkerende extracties altijd het filter LastUpdateDate. Dit is belangrijk voor de prestaties en voorkomt dat je telkens dezelfde dataset van meerdere gigabytes opnieuw ophaalt. De eerste volledige lading vormt de basis; daarna bevatten de extracties alleen wijzigingen.
- Periode: Haal voor de eerste historische lading een representatieve periode op, bijvoorbeeld de laatste 3 tot 6 maanden. Zo blijft de hoeveelheid data behapbaar en krijg je toch een volledig beeld. Volgende extracties zijn incrementeel.
- Opslag instellen: BICC kan data exporteren naar Oracle UCM of OCI Object Storage. Voor grote hoeveelheden data is OCI Object Storage doorgaans de beste keuze. Ook sluit deze opslag makkelijker aan op ETL-tools die de data verder verwerken.
- Taken plannen: Plan extractietaken buiten kantooruren om mogelijke vertragingen in het transactionele systeem van Oracle Fusion Financials te voorkomen.
- Vereisten vooraf: Gebruikers die de taak instellen, hebben de rol BICC_ADMINISTRATOR nodig. Ook moeten de inloggegevens voor cloudopslag vooraf zijn ingesteld en moet duidelijk zijn hoe je de data na extractie omzet.
Voorbeeldquery config
# BICC Data Store (PVO) and Column Selection Manifest
# This manifest outlines the PVOs and columns to select in the BICC UI for the extract job.
# PVO for Sales Order Header information (Created, Confirmed, Closed, Cancelled events)
PVO: FscmTopModelAM.DooTopAM.Header
Columns:
- HeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Sales Order Created')
- CreatedBy -> UserName (for 'Sales Order Created')
- LastUpdateDate # For incremental filtering
- StatusCode
- SubmittedDate -> EventTime (for 'Order Confirmed')
- SubmittedBy -> UserName (for 'Order Confirmed')
- OrderedTotal -> SalesOrderTotalAmount
- SoldToPartyName -> CustomerName
- SourceSalesChannelCode -> SalesChannel
- RequestShipDate -> RequestedDeliveryDate
- ClosedDate -> EventTime (for 'Order Closed')
- CanceledFlag
- CanceledDate -> EventTime (for 'Order Cancelled')
# PVO for Sales Order Lines (Line Closed event)
PVO: FscmTopModelAM.DooTopAM.FulfillLine
Columns:
- HeaderId -> SalesOrder
- ActualCompletionDate -> EventTime (for 'Order Line Closed')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
- StatusName # To confirm closed status
# PVO for Holds (Credit Hold Applied event)
PVO: FscmTopModelAM.DooTopAM.HoldInstance
Columns:
- SourceHeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Credit Hold Applied')
- CreatedBy -> UserName
- HoldName # To filter for credit-related holds
# PVO for Shipments (Picked, Shipped, Delivered events)
PVO: FscmTopModelAM.ScmTopAM.ShipmentLine
Columns:
- SourceHeaderNumber -> SalesOrder
- PickedDate -> EventTime (for 'Goods Picked')
- ShippedDate -> EventTime (for 'Goods Shipped')
- ActualDeliveryDate -> ActualDeliveryDate & EventTime (for 'Goods Delivered')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
# PVO for Invoices (Invoice Created, Invoice Corrected events)
PVO: FscmTopModelAM.ArTopAM.ReceivableInvoice
Columns:
- InterfaceHeaderAttribute1 -> SalesOrder # Link to SO via reference field
- TrxDate -> EventTime (for 'Invoice Created')
- CreatedBy -> UserName
- DueDate -> PaymentDueDate
- PreviousTrxNumber # If populated, indicates a correction
- CreationDate # Can be used for 'Invoice Corrected' if a new record is made
- LastUpdateDate # For incremental filtering
# PVO for Payments (Payment Received event)
PVO: FscmTopModelAM.ArTopAM.CashReceiptApplication
Columns:
- AppliedCustomerTrxId # ID to link back to the invoice
- ApplyDate -> EventTime (for 'Payment Received')
- CreatedBy -> UserName
- LastUpdateDate # For incremental filteringKlaar om te beginnen?
Gebruik deze template om data makkelijker te verzamelen en te beginnen met process mining. Ga vandaag nog aan de slag met het optimaliseren van de order-to-cash-verwerking van verkooporders.
Optimaliseer vandaag nog de order-to-cash-verwerking van verkooporders
Breng bottlenecks in kaart en verkort de order-to-cash-doorlooptijd eenvoudig met 30%.
Geen creditcard nodig. Je kunt 14 dagen gratis gebruikmaken van de proefperiode.