Jouw datatemplate voor Order to Cash - verwerking van verkooporders
Jouw datatemplate voor Order to Cash - verwerking van verkooporders
- Aanbevolen attributen om te verzamelen
- Belangrijke activiteiten om te volgen
- Praktische richtlijnen voor data-extractie
Order to Cash - kenmerken van verkooporderverwerking
| Naam | Beschrijving | ||
|---|---|---|---|
| Verkooporder SalesOrder | De unieke identificatie van een verkooporder, die als primaire case voor het Order to Cash-proces dient. | ||
| Beschrijving Het nummer van de verkooporder identificeert elke klantorder gedurende de volledige levenscyclus. Het vormt de centrale verbinding tussen alle gerelateerde activiteiten, van de eerste aanmaak en bevestiging tot de afhandeling, facturatie en uiteindelijke betaling. In process mining is dit attribuut essentieel om alle gerelateerde events in één case te groeperen. Door het proces per verkooporder te analyseren, krijg je een volledig end-to-end-overzicht. Je kunt totale doorlooptijden berekenen, procesvarianten per order identificeren en de route van een order door verschillende afdelingen en systemen volgen. Waarom dit belangrijk is Dit is de Case ID. Deze koppelt alle procesevents aan elkaar, zodat je de end-to-end-route van één klantorder kunt volgen. Waar je het vindt Deze identificatie staat meestal in de headertabel voor verkooporders in Oracle Fusion, zoals DOO_HEADERS_ALL. Raadpleeg de documentatie van Oracle Fusion Financials. Voorbeelden SO-100567SO-100568SO-100569 | |||
| Activiteitsnaam ActivityName | De naam van het specifieke bedrijfsevent of de specifieke taak die binnen het verkooporderproces heeft plaatsgevonden. | ||
| Beschrijving Dit attribuut beschrijft de stap die op een bepaald moment voor een verkooporder is uitgevoerd, zoals 'Verkooporder aangemaakt', 'Goederen verzonden' of 'Betaling ontvangen'. De volgorde van deze activiteiten vormt de procesflow van elke case. Het analyseren van ActivityName is een basisfunctie van process mining. Hiermee kun je de proceskaart visualiseren, verschillende procesvarianten ontdekken en bottlenecks vinden waar cases zich ophopen. Het vormt de basis voor het berekenen van overgangstijden tussen stappen en het begrijpen van de operationele volgorde in het Order to Cash-proces. Waarom dit belangrijk is Dit attribuut bepaalt de stappen in de proceskaart, zodat je de procesflow kunt visualiseren en analyseren. Waar je het vindt Dit is een afgeleid attribuut. Het wordt samengesteld door transactiestatussen of eventtypen uit verschillende Oracle Fusion-tabellen, zoals orderstatus, verzendstatus en factuurstatus, te koppelen aan een gestandaardiseerde lijst met activiteitsnamen. Voorbeelden Verkooporder aangemaaktGoederen verzondenFactuur aangemaaktBetaling ontvangen | |||
| Eventtijd EventTime | De timestamp die aangeeft wanneer een specifieke activiteit of een specifiek event voor een verkooporder heeft plaatsgevonden. | ||
| Beschrijving Dit attribuut bevat de datum en tijd van elke activiteit in het proces en legt daarmee de chronologische volgorde van de events vast. Het vormt de temporele basis van de procesanalyse en registreert precies wanneer elke stap plaatsvond. In process mining is EventTime belangrijk voor het berekenen van doorlooptijden, de duur tussen activiteiten en de totale doorlooptijd per case. Hiermee kun je prestaties analyseren, bottlenecks opsporen op basis van wachttijden en compliance met service level agreements (SLA's) bewaken. Alle tijdgebaseerde KPI's en dashboards zijn afhankelijk van de nauwkeurigheid van dit attribuut. Waarom dit belangrijk is Deze timestamp is nodig om events chronologisch te ordenen en alle tijdgebaseerde metingen te berekenen, zoals doorlooptijden en tijdsduur. Waar je het vindt Dit is een afgeleid attribuut, afkomstig uit verschillende timestampvelden in verschillende Oracle Fusion-tabellen, zoals orderaanmaakdatum, verzenddatum, factuurdatum en betalingsdatum. Voorbeelden 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| Geautomatiseerd IsAutomated | Een vlag die aangeeft of een activiteit automatisch door het systeem of handmatig door een gebruiker is uitgevoerd. | ||
| Beschrijving Dit booleaanse attribuut maakt onderscheid tussen systeemgestuurde events, zoals een geautomatiseerde kredietcontrole of systeemgegenereerde factuur, en handmatige acties van gebruikers. Meestal wordt het afgeleid op basis van de gebruikersnaam die aan een activiteit is gekoppeld. Een generieke systeem-ID wijst dan op automatisering. Door dit attribuut te analyseren, meet je de automatiseringsgraad van het proces. Het is ook een directe invoer voor de KPI 'Percentage orders met handmatig herstelwerk'. Zo zie je welke handmatige stappen de meeste tijd kosten of de meeste fouten veroorzaken en waar verdere automatisering mogelijk is. Waarom dit belangrijk is Helpt de automatiseringsgraad van het proces te kwantificeren en mogelijkheden te vinden om kostbare handmatige interventies te verminderen. Waar je het vindt Dit is een afgeleid veld, meestal gebaseerd op een regel die op het attribuut UserName wordt toegepast. Als de gebruiker bijvoorbeeld 'SYSTEM' of 'BATCH' is, wordt deze vlag op true gezet. 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 de werklast en het volgen van standaardprocedures te analyseren. Door per gebruiker te analyseren, zie je welke training nodig is, welke medewerkers of teams goed presteren en welke afwijkingen door specifieke gebruikers worden veroorzaakt. Het is ook waardevol voor compliance en audits, omdat je kunt vastleggen wie welke actie heeft uitgevoerd. Waarom dit belangrijk is Maakt analyse van prestaties per gebruiker en werklastverdeling mogelijk. Ook zie je patronen in handmatig herstelwerk die aan individuele gebruikers zijn gekoppeld. Waar je het vindt Meestal afkomstig uit velden zoals CREATED_BY of LAST_UPDATED_BY in Oracle Fusion-transactietabellen, vaak gekoppeld aan een gebruikerstabel zoals FND_USER. Voorbeelden john.smithjane.doesystem_batch_user | |||
| Gewenste leverdatum RequestedDeliveryDate | De leverdatum die de klant voor de order heeft gevraagd. | ||
| Beschrijving Dit attribuut legt de datum vast waarop de klant de goederen wil ontvangen. Het is een belangrijke prestatiedoelstelling voor de afhandelingsfase van het Order to Cash-proces. Deze datum is nodig voor het berekenen van de KPI 'Percentage tijdige leveringen' en ondersteunt het dashboard 'Service level agreement voor levering (SLA)'. Door deze datum te vergelijken met ActualDeliveryDate, kan de organisatie meten in hoeverre ze aan de verwachtingen van klanten voldoet en de grondoorzaken van leveringsvertragingen vinden. Waarom dit belangrijk is Vormt de basis voor het meten van tijdige levering en compliance met het service level agreement (SLA) voor klanten. Waar je het vindt Meestal te vinden in de tabellen met orderregels 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 identificeert de wettelijke naam van de klantrekening die aan de verkooporder is gekoppeld. Het is een belangrijke dimensie om het proces vanuit klantperspectief te segmenteren en analyseren. Door per klant te analyseren, zie je of bepaalde klanten te maken hebben met langere doorlooptijden, meer herstelwerk of specifieke procesafwijkingen. Je kunt deze inzichten gebruiken om de klantenservice te verbeteren, processen voor belangrijke accounts aan te passen en problemen te onderzoeken die de klanttevredenheid beïnvloeden. Waarom dit belangrijk is Maakt klantgerichte analyse mogelijk om procesproblemen bij specifieke klanten te vinden en de klanttevredenheid te verbeteren. Waar je het vindt Afkomstig uit tabellen met klantstamgegevens, 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 staat voor het totale bedrag dat aan de klant wordt gefactureerd voor de volledige verkooporder. Het omvat de som van alle orderregels, belastingen en overige kosten, voordat kortingen worden toegepast. Bij procesanalyse is dit attribuut belangrijk voor waardegerichte process mining. Je kunt orders op waarde segmenteren, bijvoorbeeld in orders met een hoge en lage waarde, om te zien of ze verschillende procespaden of doorlooptijden volgen. Ook helpt het om procesverbeteringen te prioriteren voor cases met de grootste financiële impact. Waarom dit belangrijk is Maakt analyse van de financiële impact mogelijk. Zo kun je procesverbeteringen voor orders met een hoge waarde prioriteren en kostenfactoren beter begrijpen. Waar je het vindt Meestal te vinden in headertabellen voor verkooporders in Oracle Fusion. Raadpleeg de documentatie van Oracle Fusion Financials. Voorbeelden 5250.00125000.75980.50 | |||
| Uiterste betaaldatum PaymentDueDate | De datum waarop de klant uiterlijk voor de factuur moet betalen. | ||
| Beschrijving De uiterste betaaldatum wordt berekend op basis van de factuurdatum en de met de klant afgesproken betalingsvoorwaarden. Deze datum bepaalt de deadline voor tijdige inning. Dit attribuut is belangrijk voor de KPI 'Percentage tijdige betalingen'. Door PaymentDueDate te vergelijken met de werkelijke ontvangstdatum van de betaling, kan het systeem bepalen of een betaling op tijd of te laat was. Zo houd je zicht op de prestaties van Accounts Receivable en de kasstroom. Waarom dit belangrijk is Dient als deadline voor het berekenen van het percentage tijdige betalingen, een belangrijke maatstaf voor de efficiëntie van de kasstroom. Waar je het vindt Te vinden in tabellen voor debiteuren of facturen binnen 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 categoriseert de herkomst van de verkooporder, zoals 'Web', 'Directe verkoop', 'Partner' of 'EDI'. Het geeft context over de manier waarop de order de organisatie binnenkwam. Door het proces per verkoopkanaal te segmenteren, kun je het dashboard 'Overzicht prestaties verkoopkanalen' vullen. Je vergelijkt de efficiëntie, doorlooptijden en foutpercentages van verschillende kanalen om te zien welke het beste werken en waar procesverbetering of verdere automatisering nodig is. Waarom dit belangrijk is Ondersteunt prestatieanalyse per kanaal en helpt de efficiëntste en minst efficiënte kanalen voor orderverwerking te identificeren. Waar je het vindt Deze informatie kan in een speciaal veld op de verkooporderheader staan. Raadpleeg de documentatie van Oracle Fusion Financials. Voorbeelden Directe verkoopWebportaalEDIWederverkoper | |||
| Werkelijke leverdatum ActualDeliveryDate | De datum waarop de goederen daadwerkelijk bij de klant zijn geleverd. | ||
| Beschrijving Dit attribuut registreert de uiteindelijke leverdatum, die het einde van de afhandelingsfase markeert. Het is het werkelijke resultaat waarmee geplande of gewenste datums worden vergeleken. Deze datum wordt vergeleken met RequestedDeliveryDate om de prestaties van tijdige levering te berekenen. Het is een belangrijke invoer voor de KPI 'Percentage tijdige leveringen' en het dashboard 'Leverings-SLA'. Zo krijg je een helder beeld van de effectiviteit van logistiek en supply chain. Waarom dit belangrijk is Dit is de datum van het werkelijke resultaat. Je gebruikt deze om het percentage tijdige leveringen te berekenen en de afhandelingsprestaties te beoordelen ten opzichte van de klantvraag. Waar je het vindt Afkomstig uit transactie- en leveringstabellen 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 staat voor de specifieke divisie of bedrijfseenheid binnen de organisatie die eigenaar is van de transactie. Hiermee kun je prestaties tussen verschillende onderdelen van de organisatie vergelijken. Door het proces per bedrijfseenheid te segmenteren, zie je verschillen in efficiëntie, kosten en compliance binnen de organisatie. Je ontdekt best practices bij goed presterende eenheden die je kunt delen en ziet welke eenheden gerichte procesverbetering nodig hebben. Waarom dit belangrijk is Maakt prestatievergelijking en analyse van procesconsistentie tussen verschillende organisatie-eenheden mogelijk. Waar je het vindt Meestal beschikbaar op de verkooporderheader en gekoppeld aan de organisatiestructuur die in Oracle Fusion is gedefinieerd. Voorbeelden BU-Noord-AmerikaBU-EMEAGlobal Services | |||
| Betalingsvoorwaarden PaymentTerms | De afgesproken voorwaarden voor betaling door de klant. | ||
| Beschrijving Dit attribuut specificeert onder welke voorwaarden een klant de factuur moet betalen, bijvoorbeeld 'Net 30' of 'Net 60'. Deze voorwaarden vormen de basis voor het berekenen van PaymentDueDate. Door in de analyse op betalingsvoorwaarden te segmenteren, kun je verschillen in betalingsdoorlooptijden verklaren. Ze geven context aan de KPI 'On-Time Payment Rate', omdat verschillende voorwaarden vanzelf tot ander betaalgedrag leiden. Dit helpt bij het bepalen van kredietbeleid en het voorspellen van de kasstroom. Waarom dit belangrijk is Geeft belangrijke context voor de analyse van betaalgedrag en helpt verschillen in de doorlooptijd van factuur tot betaling te verklaren. Waar je het vindt Beschikbaar op het niveau van de verkooporder of klantrekening binnen Oracle Fusion. Raadpleeg de documentatie van Oracle Fusion Financials. Voorbeelden Betaling binnen 30 dagenBetaling binnen 60 dagenBetaling bij ontvangst | |||
| Bronsysteem SourceSystemIdentifier | Identificeert het bronsysteem waaruit de eventdata is geëxtraheerd. | ||
| Beschrijving Dit attribuut geeft de herkomst van de data aan. Dat is vooral nuttig in omgevingen waarin meerdere systemen betrokken zijn bij het Order to Cash-proces. Orderdata kan bijvoorbeeld uit Oracle Fusion komen, terwijl verzenddata afkomstig kan zijn uit een logistiek systeem van een derde partij. Bij analyses helpt dit om de dataherkomst te begrijpen. Je kunt het ook gebruiken om de procesweergave te filteren op events uit specifieke systemen. Het is belangrijk voor datavalidatie en voor het opsporen van procesfragmentatie over verschillende IT-omgevingen. Waarom dit belangrijk is Geeft context over de herkomst van de data. Dat is belangrijk voor datagovernance en probleemoplossing in omgevingen met meerdere systemen. Waar je het vindt Dit is meestal een statische waarde die tijdens het extraheren en transformeren van de data wordt toegevoegd om de herkomst van de dataset te labelen. Voorbeelden Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| Factuur gecorrigeerd IsInvoiceCorrected | Een vlag 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, wat blijkt uit de activiteit 'Invoice Corrected'. Het markeert cases waarin herstelwerk in de facturatiefase nodig was. Dit is een belangrijke invoer voor het dashboard 'Invoice Accuracy & Rework Analysis' en de KPI 'Invoice Rework Rate'. Het helpt de omvang van facturatiefouten te bepalen en de oorzaken van correcties te analyseren. Zo kun je handmatig werk en betalingsvertragingen verminderen. Waarom dit belangrijk is Identificeert herstelwerk aan facturen. Dit is een belangrijke indicator voor procesefficiëntie, problemen met datakwaliteit en mogelijke betalingsvertragingen. Waar je het vindt Dit is een berekend veld. Voor een case wordt het doorgaans op true gezet als het event log een activiteit 'Invoice Corrected' bevat. Voorbeelden falsetrue | |||
| Factuurnummer InvoiceNumber | De unieke identificatie van de klantfactuur. | ||
| Beschrijving Dit attribuut is het unieke nummer dat wordt toegewezen aan de factuur die vanuit de verkooporder wordt gegenereerd. Het verbindt de verkoop- en fulfillmentactiviteiten met het financiële afwikkelingsdeel van het proces. Hoewel de Sales Order de primaire case-ID is, is het factuurnummer belangrijk voor de analyse van facturatie- en betalingssubprocessen. Het is nodig om factuurcorrecties, geschillen en de betaalstatus te volgen. Ook ondersteunt het dashboards zoals 'Invoice Accuracy & Rework Analysis'. Waarom dit belangrijk is Legt de belangrijke verbinding met het debiteurenproces en is nodig om factuurherstel en betalingscycli te analyseren. Waar je het vindt Beschikbaar in de transactietabellen voor debiteuren 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 dit event voor het laatst vanuit het bronsysteem is vernieuwd. | ||
| Beschrijving Dit attribuut registreert wanneer de data voor het laatst is geëxtraheerd of bijgewerkt in de process mining-dataset. Het maakt zichtbaar hoe actueel de geanalyseerde data is. Deze informatie helpt je om de actualiteit van de procesanalyse goed in te schatten. Ook maakt het duidelijk wat je van de actualiteit van de data kunt verwachten en helpt het bij het instellen en bewaken van datarefreshschema's. Waarom dit belangrijk is Geeft aan hoe actueel de data is, zodat gebruikers weten hoe recent hun procesanalyse is. Waar je het vindt Deze waarde wordt tijdens elke cyclus voor data-extractie en -transformatie gegenereerd en aan de dataset toegevoegd. Voorbeelden 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Land van klant CustomerCountry | Het land waar de klant is gevestigd. | ||
| Beschrijving Dit attribuut bevat het land uit het verzend- of factuuradres van de klant. Het is een belangrijke dimensie voor geografische analyse. Door het proces per land te segmenteren, krijg je regionale verschillen in procesprestaties, doorlooptijden of betaalgedrag in beeld. Dit helpt om de invloed van lokale regelgeving, logistieke uitdagingen en marktomstandigheden op het Order to Cash-proces te begrijpen. Waarom dit belangrijk is Maakt geografische analyse mogelijk om regionale verschillen in procesefficiëntie, compliance en klantgedrag te identificeren. Waar je het vindt Afkomstig uit klantstamdatatabellen (HZ_LOCATIONS, HZ_PARTY_SITES) die aan de verkooporder zijn gekoppeld. Voorbeelden USADuitslandJapan | |||
| Op tijd geleverd IsOnTimeDelivery | Een berekende vlag die waar is als de werkelijke 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 een eenvoudige indicatie van de leverprestatie. Deze vlag vormt de basis voor het berekenen van de geaggregeerde KPI 'On-Time Delivery Rate'. Je kunt hiermee eenvoudig filteren en analyseren, bijvoorbeeld om alle te late orders te selecteren voor een oorzaakanalyse van de factoren die vertraging veroorzaken. Waarom dit belangrijk is Meet de fulfillmentprestatie rechtstreeks af tegen de verwachtingen van de klant en vereenvoudigt de analyse van te late orders. Waar je het vindt Dit is een berekend veld. De logica is: ActualDeliveryDate <= RequestedDeliveryDate. Voorbeelden truefalse | |||
| Ordertype OrderType | Een classificatie van de verkooporder, zoals 'Standard Order' of 'Return Order'. | ||
| Beschrijving Order Type wordt gebruikt om verkooporders op basis van hun bedrijfsdoel in te delen. Veelvoorkomende typen zijn standaardverkopen, serviceorders, retourautorisaties (RMA's) en interne orders. Het is belangrijk om het proces per ordertype te analyseren, omdat verschillende typen vaak hun eigen procesflows en prestatiedoelen hebben. Deze segmentatie helpt om procesvariaties te herkennen die bewust en verwacht zijn, zodat je ze niet ten onrechte als afwijkingen interpreteert. Waarom dit belangrijk is Maakt het mogelijk om verschillende legitieme procesflows, zoals standaardorders en retouren, apart te analyseren voor een eerlijke en nauwkeurige analyse. Waar je het vindt Meestal beschikbaar als veld in de tabel met verkooporderkoppen in Oracle Fusion. Raadpleeg de documentatie van Oracle Fusion Financials. Voorbeelden StandaardverkooporderRetourautorisatieServiceorder | |||
| Productnaam ProductName | De naam van het product of de dienst die wordt verkocht. | ||
| Beschrijving Dit attribuut specificeert het artikel op de orderregel. Als een order meerdere regels heeft, kan de case op regelniveau worden geanalyseerd of kan dit attribuut op headerniveau worden geaggregeerd. Door per product te analyseren, zie je of bepaalde producten samenhangen met complexere of problematische procesflows, zoals frequente leveringsvertragingen of betalingsproblemen. Dit kan helpen bij productmanagement en supplychainstrategieën. Waarom dit belangrijk is Maakt analyse van procesprestaties per product mogelijk en laat artikelen zien die mogelijk complexe afhandelings- of facturatiepaden hebben. Waar je het vindt Afkomstig uit tabellen met orderregels en gekoppeld aan een productstamtabel. Raadpleeg de documentatie van Oracle Fusion Financials. Voorbeelden Standard Widget X1Premium servicepakketComponent Y2-B | |||
| Te late betaling IsLatePayment | Een berekende vlag die waar is als de betaling na de vervaldatum is ontvangen. | ||
| Beschrijving Dit booleaanse attribuut wordt afgeleid door de werkelijke 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 'On-Time Payment Rate' te berekenen. Je kunt betalingen eenvoudig segmenteren in op tijd en te laat. Zo analyseer je kenmerken van laat betalende klanten, veelvoorkomende oorzaken van vertraging en de financiële impact op het werkkapitaal. Waarom dit belangrijk is Meet de effectiviteit van betalingsinning rechtstreeks en vereenvoudigt de analyse van achterstallige betalingen. Waar je het vindt Dit is een berekend veld. De logica is: PaymentReceivedDate > PaymentDueDate. Voorbeelden falsetrue | |||
| Verzendmethode ShippingMethod | De methode of vervoerder die wordt gebruikt om de goederen naar de klant te verzenden. | ||
| Beschrijving Dit attribuut beschrijft de logistieke vervoerder of het serviceniveau voor de levering, zoals 'Wegtransport', 'Luchtvracht' of 'Lokale koerier'. Deze informatie is nodig voor het dashboard 'Compliance van levering per verzendmethode'. Je kunt de prestaties van tijdige levering en verzendkosten per methode en vervoerder vergelijken. Zo onderbouw je keuzes voor de logistieke strategie en leveranciers. Waarom dit belangrijk is Ondersteunt logistieke analyse rechtstreeks door prestaties van verschillende vervoerders en verzendmethoden vergelijkbaar te maken. Waar je het vindt Beschikbaar in de verzend- en fulfillmenttabellen binnen Oracle Fusion. Raadpleeg de documentatie van Oracle Fusion Financials. Voorbeelden FedEx GroundUPS Next Day AirDHL International | |||
Order to Cash - activiteiten voor verkooporderverwerking
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Betaling ontvangen | Deze activiteit betekent dat de betaling van de klant is ontvangen en in Accounts Receivable aan de factuur is toegewezen. Dit wordt vastgelegd wanneer een kasontvangst aan een factuur wordt toegewezen. | ||
| Waarom dit belangrijk is Dit is een belangrijke mijlpaal voor het meten van de 'Totale doorlooptijd van order tot betaling' en het 'Percentage tijdige betalingen'. De verkoop wordt hiermee omgezet in geld. Waar je het vindt Dit is een expliciet event in Oracle Accounts Receivable. Het wordt vastgelegd in tabellen voor kasontvangsten, zoals AR_RECEIVABLE_APPLICATIONS_ALL, wanneer een ontvangst aan een factuur wordt toegewezen. Vastleggen Vastgelegd op basis van de timestamp 'apply date' van het record voor de kasontvangsttoewijzing in AR. Eventtype explicit | |||
| Factuur aangemaakt | Deze activiteit staat voor het aanmaken van de klantfactuur in de module Accounts Receivable, meestal gestart door het verzendbevestigingsevent. Er wordt een factuurrecord aangemaakt met een uniek nummer en een aanmaakdatum. | ||
| Waarom dit belangrijk is Dit markeert het officiële begin van de betalingsinningscyclus. Het vormt de basis voor het meten van de 'Tijd van factuur tot betaling' en de efficiëntie van de totale kasstroom. Waar je het vindt Dit is een expliciet event in Oracle Accounts Receivable (AR). In de tabel RA_CUSTOMER_TRX_ALL wordt een factuurrecord aangemaakt met een transactiedatum. Vastleggen Vastgelegd op basis van de aanmaakdatum van de factuurtransactie in de AR-module. Eventtype explicit | |||
| Goederen verzonden | Deze activiteit markeert het moment waarop de goederen het magazijn hebben verlaten en onderweg zijn naar de klant. Dit wordt vastgelegd wanneer een verzendbevestigingstransactie in Oracle Shipping wordt verwerkt. | ||
| Waarom dit belangrijk is Dit is een belangrijke mijlpaal. De afhandelingsfase van het proces is afgerond en de facturatie wordt gestart. De activiteit is nodig om tijdige verzending en levering te meten. Waar je het vindt Dit is een expliciet event in Oracle Shipping Execution. De verzendbevestiging maakt een record aan in verzendtabellen zoals WSH_DELIVERY_DETAILS, met een verzenddatum. Vastleggen Vastgelegd op basis van de timestamp 'actual ship date' in het delivery detail-record dat aan de orderregel is gekoppeld. Eventtype explicit | |||
| Order bevestigd | Deze belangrijke mijlpaal betekent dat de verkooporder alle eerste controles, waaronder kredietgoedkeuring, heeft doorlopen en klaarstaat voor afhandeling. Meestal wordt dit afgeleid wanneer de orderstatus verandert in bijvoorbeeld 'Wachten op verzending' of 'Gepland'. | ||
| Waarom dit belangrijk is Deze activiteit is een belangrijke mijlpaal voor het berekenen van de 'Gemiddelde tijd tot orderbevestiging' en markeert de overdracht van orderinvoer naar orderafhandeling. Waar je het vindt Afgeleid uit een wijziging van de status van de orderheader of orderregel naar een waarde die aangeeft dat de order klaar is voor afhandeling, bijvoorbeeld 'Wachten op verzending'. Controleer de statuskolommen in DOO_HEADERS_ALL of DOO_FULFILL_LINES_ALL. Vastleggen Afgeleid uit de timestamp waarop de orderstatus verandert in een bevestigde of geplande status. Eventtype inferred | |||
| Order gesloten | De laatste activiteit in het proces. Alle regels van de verkooporder zijn afgehandeld, gefactureerd en gesloten. De status van de orderheader wordt gewijzigd in 'Gesloten'. | ||
| Waarom dit belangrijk is Deze activiteit markeert het geslaagde einde van de levenscyclus van de verkooporder. Je hebt deze nodig om end-to-end-doorlooptijden te berekenen en zombie-orders op te sporen die nooit worden gesloten. Waar je het vindt Afgeleid uit de wijziging van de status van de verkooporderheader in 'Gesloten' in de tabel DOO_HEADERS_ALL. De timestamp van deze laatste statuswijziging geldt als eventtijd. Vastleggen Afgeleid uit de timestamp van de statuswijziging naar 'Gesloten' op de verkooporderheader. Eventtype inferred | |||
| Verkooporder aangemaakt | Deze activiteit markeert het begin van het verkooporderproces. Het is het moment waarop een nieuwe verkooporder in Oracle Fusion wordt ingevoerd. Meestal wordt dit 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 belangrijk voor het meten van de totale doorlooptijd van de Order to Cash-cyclus en het analyseren van het aantal binnenkomende orders. Waar je het vindt Wordt expliciet vastgelegd wanneer een verkooporderrecord wordt aangemaakt in Order Management Cloud. Zoek naar aanmaaktimestamps in de tabel DOO_HEADERS_ALL. Vastleggen Vastgelegd op basis van de aanmaaktimestamp van het verkooporderrecord in de orderheader. Eventtype explicit | |||
| Factuur gecorrigeerd | Dit gebeurt wanneer een eerder aangemaakte factuur wordt gewijzigd, opnieuw uitgegeven of gecrediteerd vanwege fouten of een klantgeschil. Meestal wordt dit vastgelegd door een creditnota of een nieuwe versie van de factuur aan te maken. | ||
| Waarom dit belangrijk is Door factuurcorrecties te volgen, kun je de KPI 'Percentage facturen met herstelwerk' meten. Zo zie je problemen in het facturatieproces die betalingen kunnen vertragen en administratieve kosten verhogen. Waar je het vindt Afgeleid uit het aanmaken van een creditnota die aan de oorspronkelijke factuur is gekoppeld, of van een volgende versie van dezelfde factuur in de tabel RA_CUSTOMER_TRX_ALL. Vastleggen Afgeleid door creditnota's of facturen te identificeren die naar een eerdere factuurtransactie verwijzen. Eventtype inferred | |||
| Goederen geleverd | Geeft aan dat de klant de zending heeft ontvangen. Deze informatie komt vaak van een externe vervoerder en wordt teruggeschreven naar Oracle Fusion. Je kunt de levering ook afleiden op basis van een standaardtransittijd vanaf de verzenddatum. | ||
| Waarom dit belangrijk is Deze activiteit is belangrijk voor het berekenen van de KPI 'Percentage tijdige leveringen' en het nauwkeurig meten van het serviceniveau voor klanten. Waar je het vindt Dit is vaak geen native Oracle-event. Je kunt het vastleggen als er een koppeling met de vervoerder is, of berekenen door een standaardtransittijd op te tellen bij de datum van 'Goederen verzonden'. Hiervoor is systeemanalyse nodig. Vastleggen Afgeleid uit datastromen van de vervoerder of berekend op basis van de verzenddatum plus een gemiddelde transittijd. Eventtype inferred | |||
| Goederen verzameld | Dit is het fysiek verzamelen van goederen uit 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 zicht op de magazijnprocessen. Vertraging tussen voorraadreservering en verzamelen kan wijzen op capaciteits- of procesknelpunten in het magazijn. Waar je het vindt Vastgelegd in de Oracle Fusion Cloud SCM-modules (Supply Chain Management). Je kunt het afleiden uit de statuswijziging van een pick wave of pick slip die aan de orderregel is gekoppeld. Vastleggen Afgeleid uit de voltooiingstimestamp van de picktransactie in de SCM-modules. Eventtype inferred | |||
| Kredietblokkade toegepast | Deze activiteit vindt plaats wanneer een verkooporder automatisch of handmatig wordt geblokkeerd na een mislukte kredietcontrole of een ander kredietgerelateerd probleem. Meestal wordt dit vastgelegd door een wijziging in de blokkeringsstatus van de order in het systeem. | ||
| Waarom dit belangrijk is Door kredietblokkades te volgen, zie je beter waarom orderverwerking vertraging oploopt en hoe efficiënt het proces voor het opheffen van kredietblokkades is. Waar je het vindt Afgeleid uit het toepassen van een blokkade op de verkooporder. Dit wordt meestal vastgelegd in blokkadegerelateerde tabellen, zoals DOO_HOLDS_ALL, die aan de verkooporder zijn gekoppeld. Vastleggen Afgeleid uit het aanmaken van een record in de orderblokkadetabel met het blokkadetype 'Krediet'. Eventtype inferred | |||
| Kredietcontrole uitgevoerd | Dit is de uitvoering van een kredietcontrole op de rekening van de klant om diens kredietwaardigheid te beoordelen. Dit is vaak een geautomatiseerde of handmatige stap in de orderverwerkingsworkflow. De afronding wordt meestal vastgelegd als een statuswijziging of voltooide taak. | ||
| Waarom dit belangrijk is Door de tijd voor kredietcontroles te analyseren, krijg je zicht op knelpunten in de ordergoedkeuring. Deze activiteit is belangrijk voor de KPI 'Tijd van kredietcontrole tot bevestiging'. Waar je het vindt Kan worden afgeleid uit statuswijzigingen van de verkooporder, bijvoorbeeld wanneer de status verandert in 'In afwachting van kredietgoedkeuring', of uit een expliciet event log in de kredietbeheerfunctie. Vastleggen Afgeleid uit orderstatuswijzigingen of timestamps die bij kredietbeoordelingstaken horen. Eventtype inferred | |||
| Order geannuleerd | Dit staat voor het annuleren van een verkooporder voordat deze volledig is verzonden. Dit kan verschillende oorzaken hebben en leidt tot de eindstatus 'Geannuleerd'. | ||
| Waarom dit belangrijk is Dit is een belangrijk uitzonderingspad. Door geannuleerde orders te analyseren, zie je grondoorzaken zoals voorraadtekorten, prijsproblemen of een gewijzigde klantbeslissing. Die informatie helpt bij procesverbetering. Waar je het vindt Afgeleid uit de wijziging van de status van de verkooporderheader of -regel naar 'Geannuleerd'. De timestamp van deze statuswijziging wordt gebruikt om het event vast te leggen. Vastleggen Afgeleid uit de timestamp van de statuswijziging naar 'Geannuleerd' op de orderheader of -regel. Eventtype inferred | |||
| Orderregel gesloten | Dit staat voor het definitief sluiten van een afzonderlijke orderregel. De regel is volledig verzonden en gefactureerd en er worden geen verdere transacties verwacht. Het systeem wijzigt de regelstatus in 'Gesloten'. | ||
| Waarom dit belangrijk is Het sluiten van orderregels betekent dat alle contractuele verplichtingen voor dat artikel zijn afgerond. Door dit te analyseren, zie je welke orders lang na afhandeling en betaling nog openstaan. Waar je het vindt Afgeleid uit de wijziging van de status van de afhandelingsregel in 'Gesloten' in de tabel DOO_FULFILL_LINES_ALL. De timestamp van deze statuswijziging markeert het event. Vastleggen Afgeleid uit de timestamp van de statuswijziging naar 'Gesloten' op de afhandelingsregel. Eventtype inferred | |||
| Voorraad gereserveerd | Deze activiteit staat voor het toewijzen of reserveren van fysieke voorraad voor de orderregel. Het systeem reserveert specifieke voorraad, zodat die beschikbaar is zodra de order kan worden verzameld. | ||
| Waarom dit belangrijk is Hiermee kun je de KPI 'Doorlooptijd van voorraadtoewijzing' analyseren en vertragingen tussen orderbevestiging en het veiligstellen van de goederen opsporen. Waar je het vindt Dit event wordt vaak vastgelegd in modules voor voorraadbeheer of supply chain execution. Je kunt het afleiden uit statusupdates op de afhandelingsregel die aangeven dat de voorraad is gespecificeerd of gereserveerd. Vastleggen Afgeleid uit statuswijzigingen van de afhandelingsregel die verband houden met voorraadreservering of planning. Eventtype inferred | |||
Extractiegidsen
Stappen
- Ga naar Oracle BI Publisher: Log in op je Oracle Fusion-omgeving met een gebruiker die BI Administrator- of BI Author-rechten heeft. Gebruik het Navigator-menu 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'.
- Definieer de SQL Query-dataset: 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 gegevensbron en kies 'Standard SQL' als SQL-type.
- Voer de SQL-query in: Kopieer de volledige SQL-query uit de sectie '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), die BI Publisher automatisch herkent.
- Configureer de eigenschappen van het datamodel: Klik na het plakken van de query op 'OK'. Ga in het linkerpaneel van de datamodel-editor naar de sectie '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 je gevraagd waarden voor de datumparameters in te voeren. Gebruik een kleine periode om te testen. Klik op 'View' om een voorbeeld van de data te bekijken. Als de data correct wordt weergegeven, sla je het datamodel op via het opslagpictogram en geef je het een duidelijke naam, bijvoorbeeld 'OrderToCash_EventLog_DM'.
- Maak een rapport vanuit het datamodel: Klik nadat je het datamodel hebt opgeslagen rechtsboven op de knop 'Create Report'. De wizard voor het maken van rapporten wordt geopend.
- Configureer het rapport: 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 bijvoorbeeld de naam 'OrderToCash_EventLog_Report'.
- Voer het rapport uit: Open het nieuwe rapport. Je wordt gevraagd 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 exportindeling. Hiermee download je het event-logbestand.
- 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 kan nu naar de process mining-tool worden geüpload.
Configuratie
- Gebruikersrechten: Je hebt een rol nodig met rechten om datamodellen en rapporten in BI Publisher te maken, zoals 'BI Administrator' of 'BI Author'.
- Gegevensbron: De query is ontworpen voor de standaardgegevensbron '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 om de data in beheersbare batches te extraheren, bijvoorbeeld telkens 3 tot 6 maanden, om time-outs en prestatieproblemen in rapporten te voorkomen.
- Filteren op bedrijfseenheid: Je kunt de extractie beperken door in de BaseOrders CTE van de query een WHERE-clausule toe te voegen die filtert op een specifieke Business Unit ID, bijvoorbeeld AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID]).
- Filteren op ordertype: Je kunt ook specifieke salesordertypen selecteren door in de BaseOrders CTE een voorwaarde toe te voegen voor dhead.SOURCE_ORDER_TYPE_CODE.
- Prestaties: Bij zeer grote datasets over meerdere jaren kan deze aanpak met één query traag zijn. Overweeg de query buiten piekuren uit te voeren of de extractie op te delen in kleinere maandelijkse batches. Controleer in het datamodel of de eigenschap 'Enable SQL Pruning' niet is geselecteerd, omdat deze complexe UNION-query's kan verstoren.
a 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: Log in op je Oracle Fusion Applications-instantie met een gebruiker die de rol BICC_ADMINISTRATOR heeft. Ga naar Tools en selecteer Business Intelligence Cloud Connector in het menu.
- Maak een nieuwe offering: Klik in de BICC-console op Configure External Storage om je doellocatie in te stellen. Dit kan Oracle Universal Content Management (UCM) of een OCI Object Storage-bucket zijn. Controleer of je verbindingsgegevens en inloggegevens kloppen.
- Start een nieuwe extractietaak: Ga naar de sectie 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 taakconfiguratie de Public View Objects (PVO's) die nodig zijn om de levenscyclus van de salesorder 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.
- Configureer de kolommen voor elke PVO: Klik voor elke geselecteerde PVO op het menu Actions en kies Select Columns. Selecteer zorgvuldig de kolommen die nodig zijn om het event log te maken, zoals HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate en gebruikers-ID's. Raadpleeg het querymanifest voor een volledige lijst met vereiste kolommen per PVO.
- Pas filters toe voor incrementele loads: Beperk de hoeveelheid data door elke PVO te filteren op de kolom LastUpdateDate. Voor de eerste run kun je een ruime periode selecteren. Voor geplande vervolgruns stel je het filter zo in dat alleen records worden geëxtraheerd die sinds de vorige taakuitvoering zijn bijgewerkt.
- Plan de extractietaak: Ga naar de sectie Manage Schedule. Maak een nieuw schema voor je taak. Het is aan te raden de taak buiten piekuren uit te voeren, bijvoorbeeld elke nacht, om de impact op de systeemprestaties te beperken.
- Dien de taak in en houd de voortgang bij: Dien de taak in zodra alles is geconfigureerd. Je kunt de voortgang volgen in het scherm Manage Extract Jobs. Na een succesvolle uitvoering staan de databestanden in gecomprimeerd CSV-formaat klaar op de geconfigureerde cloudopslaglocatie.
- Zet ruwe data om in een event log: Download de geëxtraheerde CSV-bestanden. BICC levert ruwe tabeldata, geen opgemaakt event log. Je moet deze bestanden verwerken met een externe tool, zoals Python, een databasescript of een ETL-platform. Dit houdt het volgende in:
- Data uit verschillende bestanden samenvoegen, bijvoorbeeld factuurdata koppelen aan de salesorderheader.
- Datumkolommen omzetten naar afzonderlijke activiteitenregels. Maak bijvoorbeeld vanuit het bestand FscmTopModelAM.DooTopAM.Header één regel voor Sales Order Created op basis van CreationDate en een andere voor Order Closed op basis van ClosedDate.
- Statuscodes of vlaggen 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 voor upload: Zorg dat het uiteindelijke bestand één CSV is met kolommen die overeenkomen met de vereiste en aanbevolen attributen. Het bestand kan nu naar ProcessMind worden geüpload.
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 verzendgebeurtenissen en FscmTopModelAM.ArTopAM.ReceivableInvoice voor facturatie.
- Incrementele extractie: Gebruik bij terugkerende extracties altijd het LastUpdateDate-filter. Dit is belangrijk voor de prestaties en voorkomt dat je dezelfde dataset van meerdere gigabytes steeds opnieuw extraheert. De eerste volledige load vormt de basis. Vervolgruns bevatten alleen wijzigingen.
- Periode: Extraheer voor de eerste historische load een representatieve periode, bijvoorbeeld de afgelopen 3 tot 6 maanden. Zo houd je de balans tussen volledigheid en een beheersbare hoeveelheid data. Vervolgruns zijn incrementeel.
- Opslagconfiguratie: BICC kan exporteren naar Oracle's UCM of OCI Object Storage. OCI Object Storage is meestal de beste keuze voor bulkscenario's en een eenvoudigere integratie met downstream ETL-tools.
- Taakplanning: Plan extractietaken buiten kantooruren om mogelijke prestatieproblemen in het transactionele Oracle Fusion Financials-systeem te voorkomen.
- Vereisten vooraf: Gebruikers die de taak configureren hebben de rol BICC_ADMINISTRATOR nodig. Ook moeten de inloggegevens voor cloudopslag vooraf zijn ingesteld en moet je goed begrijpen hoe de data na de extractie moet worden omgezet.
a 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 aan de slag te gaan?
Gebruik deze template om je dataverzameling efficiënter te maken en je process mining-traject te starten. Begin vandaag nog met het optimaliseren van je Order to Cash - salesorderverwerking.
Optimaliseer vandaag nog je Order to Cash - salesorderverwerking
Identificeer bottlenecks en verkort de Order to Cash-doorlooptijd eenvoudig met 30%.
Je hebt geen creditcard nodig. De gratis proefperiode duurt 14 dagen.