> Continuous Process Improvement > Order to Cash Billing & Invoicing > Oracle Fusion Financials > Data Template

Your Order to Cash - Billing & Invoicing Data Template

Oracle Fusion Financials

Order to Cash - Billing & Invoicing Attributes (22) Order to Cash - Billing & Invoicing Activities (13) Extraction Guides (2)

Your Order to Cash - Billing & Invoicing Data Template

This template provides a comprehensive guide for extracting the data needed to analyze your Order to Cash - Billing & Invoicing process. It outlines the essential attributes to collect, the critical activities to track, and practical guidance for data extraction. By following this template, you can ensure a robust dataset for effective process mining and optimization.

Recommended attributes to collect
Key activities to track
Extraction guidance for Oracle Fusion Financials

New to event logs? Learn how to create a process mining event log.

Download Template

Order to Cash - Billing & Invoicing Attributes

These are the recommended data fields to include in your event log for comprehensive Order to Cash - Billing & Invoicing analysis.

3 Required 5 Recommended 14 Optional

	Name	Description
	Invoice Number InvoiceNumber	The unique identifier for each billing invoice, serving as the primary case ID for tracking all related activities.
Description The Invoice Number is the cornerstone of the billing process analysis. It functions as the Case ID, grouping all events from invoice creation to final payment and closure. This allows for a complete, end-to-end view of the lifecycle for a single billing document. In process mining, analyzing by Invoice Number enables the visualization of process variants, the calculation of cycle times for individual invoices, and the identification of bottlenecks or rework loops affecting specific transactions. It is essential for dashboards like 'Invoice End-to-End Cycle Time' and for calculating fundamental KPIs such as Days Sales Outstanding (DSO) on a per-invoice basis. Why it matters This attribute is critical as it connects all related billing and payment activities into a single case, enabling a complete and accurate analysis of the invoice lifecycle. Where to get This is typically the Transaction Number (TRX_NUMBER) from the RA_CUSTOMER_TRX_ALL table in Oracle Fusion Financials. Examples INV-1002345983451CM-55432
	Start Time EventTimestamp	The precise date and time when a specific activity or event occurred.
Description The Event Timestamp records the exact moment an activity happened. It provides the chronological order of events for each invoice, which is essential for constructing the process flow and performing any time-based analysis. This attribute is the basis for all duration and performance calculations. It is used to measure the time between activities, calculate end-to-end cycle times, determine if payments are on time, and analyze trends over time. KPIs such as 'Average Invoice Approval Time' and 'End-to-End Invoice Cycle Time' are directly calculated from these timestamps. Why it matters Timestamps are essential for calculating all performance metrics, including cycle times, delays, and adherence to deadlines, forming the basis of quantitative process analysis. Where to get This is sourced from various date fields across Oracle Fusion Financials tables, such as CREATION_DATE in RA_CUSTOMER_TRX_ALL or status update timestamps in workflow tables. Examples 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-20T11:25:10Z
	Activity Name ActivityName	The name of the specific business event or task that occurred at a point in time within the invoice lifecycle.
Description The Activity Name describes a step in the billing process, such as 'Invoice Created', 'Invoice Approved', or 'Customer Payment Received'. These events form the sequence of actions that constitute the process flow for each invoice. This attribute is fundamental for process discovery, allowing the mining tool to construct a visual map of how invoices are actually processed. It is used to analyze process variants, identify rework loops like multiple approval steps, and measure the frequency and duration of each stage. All dashboards and KPIs rely on this attribute to understand the process flow. Why it matters This attribute defines the steps in the process map, making it possible to visualize, analyze, and identify inefficiencies in the invoice workflow. Where to get This information is derived from various tables and status changes within Oracle Fusion Financials, such as workflow history tables (e.g., related to approvals) and transaction status fields. Examples Invoice CreatedInvoice ApprovedCustomer Payment ReceivedInvoice Closed
	Business Unit BusinessUnit	The specific business unit within the organization that issued the invoice.
Description The Business Unit represents the organizational entity responsible for the transaction. This is a key data element for financial segmentation and reporting in large enterprises. This attribute allows for comparing process performance across different parts of the company. For example, you can analyze if DSO varies significantly between business units or if one unit has a much higher billing rework rate. This helps target improvement initiatives where they are most needed. Why it matters Enables performance comparison across different organizational units, helping to identify best practices and areas needing improvement on a granular level. Where to get Available in transaction tables like RA_CUSTOMER_TRX_ALL, often as ORG_ID, which links to business unit definitions. Examples US ConsultingEMEA ManufacturingAPAC Services
	Customer Name CustomerName	The name of the customer or entity being billed.
Description This attribute identifies the customer associated with the invoice. It is a primary dimension for segmenting and filtering the process data. Analyzing the process by Customer Name helps identify which customers have the longest payment cycles, which are most likely to dispute invoices, and which consistently pay on time. This is crucial for the DSO Trend dashboard and for tailoring collection strategies to specific customer behaviors. Why it matters Allows for segmentation of the process by customer, revealing different behaviors, payment patterns, and potential relationship issues that affect cash flow. Where to get Derived by joining the transaction table (RA_CUSTOMER_TRX_ALL) with customer master data tables like HZ_PARTIES. Examples Global Tech Inc.Innovate Solutions LLCApex Manufacturing
	Due Date DueDate	The date by which the payment for the invoice is due.
Description The Due Date is a critical date attribute that defines the payment deadline for an invoice, as determined by the payment terms. This attribute is essential for monitoring collections and financial health. It is the baseline for calculating the On-Time Payment Rate KPI and for creating payment aging reports. In dashboards, it's used to forecast cash flow by showing when payments are expected and to identify overdue invoices that require collection activities. Why it matters This is the primary benchmark for measuring payment timeliness, calculating DSO, and managing accounts receivable aging. Where to get Located in the AR_PAYMENT_SCHEDULES_ALL table, typically in the DUE_DATE field. Examples 2023-05-302023-06-152023-07-01
	Invoice Amount InvoiceAmount	The total monetary value of the invoice.
Description This attribute represents the total amount due on the invoice. It is a critical financial metric for understanding the monetary value flowing through the billing process. In analysis, Invoice Amount is used to prioritize high-value transactions, calculate the total value of outstanding receivables, and weight KPIs like Days Sales Outstanding (DSO). It allows for segmenting the process based on financial impact, for instance, analyzing if high-value invoices follow a different approval path or take longer to get paid. Why it matters Provides the financial context for each case, enabling value-based analysis, prioritization of high-value invoices, and calculation of key financial KPIs. Where to get Found in the RA_CUSTOMER_TRX_ALL table, likely in a field such as INVOICE_AMOUNT or a related field representing the transaction total. Examples 5000.001250.75250000.00
	Invoice Status InvoiceStatus	The current status of the invoice in its lifecycle, such as 'Open', 'Closed', or 'Disputed'.
Description Invoice Status provides a snapshot of where an invoice is in the process. Common statuses include open (unpaid), closed (paid), disputed, or voided. This attribute is useful for high-level monitoring and filtering. For example, the Real-Time Cash Flow Forecast dashboard uses this status to categorize outstanding amounts. It helps in quickly identifying the population of invoices that are overdue, in dispute, or fully settled. Why it matters Provides a quick, high-level understanding of an invoice's current state, enabling efficient filtering and categorization for financial reporting and operational management. Where to get Derived from status fields in tables like RA_CUSTOMER_TRX_ALL or AR_PAYMENT_SCHEDULES_ALL (e.g., STATUS field). Examples OpenClosedDisputedPending Approval
	Billing Department BillingDepartment	The internal department or team responsible for creating and managing the invoice.
Description This attribute identifies the specific team or department within the organization that handled the billing process. It provides another layer of organizational context for analysis. By segmenting the process by Billing Department, a company can compare the efficiency and accuracy of different teams. It can help identify which departments have higher rework rates, longer approval cycles, or contribute more to high DSO, highlighting opportunities for targeted training or process standardization. Why it matters Enables performance comparison between internal teams, helping to identify best practices, resource needs, or areas requiring process improvement. Where to get This information might be derived from the user who created the invoice, by linking the user to their assigned department in the HR system (e.g., via PER_ALL_ASSIGNMENTS_F). Examples Corporate BillingServices Invoicing TeamProduct Sales Billing
	Days Sales Outstanding DaysSalesOutstanding	The number of days between the invoice date and the date the payment was received.
Description Days Sales Outstanding (DSO) is a critical financial metric that measures the average time it takes to collect payment after an invoice is issued. This attribute calculates it for each individual invoice. While the overall DSO is a key KPI, calculating it at the individual invoice level allows for much deeper analysis. It can be used to create trend dashboards, identify the characteristics of invoices with high DSO, and measure the financial impact of process delays. This granular calculation provides the data needed to understand the drivers behind the aggregate DSO KPI. Why it matters Calculates a critical cash flow metric at the individual invoice level, enabling detailed analysis of what drives collection times and financial performance. Where to get This is calculated by finding the difference between the timestamp of the 'Customer Payment Received' activity and the 'Invoice Date' attribute. Examples 356228
	Dispute Reason DisputeReason	The reason provided for an invoice being disputed by the customer.
Description When a customer disputes an invoice, the reason for the dispute is captured. This could relate to pricing, quantity, service quality, or other issues. Analyzing dispute reasons is a powerful way to perform root cause analysis. By understanding the most common reasons for disputes, the business can address underlying issues in pricing, order fulfillment, or data quality. This helps reduce the Avg Invoice Dispute Resolution Time and improves customer satisfaction. Why it matters Provides direct insight into the root causes of payment delays and customer dissatisfaction, allowing the business to address systemic problems. Where to get This information may be stored in Oracle Collections or a related dispute management module. It might be in a dedicated dispute table or as a reason code on the transaction itself. Examples Incorrect PricingQuantity MismatchDamaged GoodsDuplicate Invoice
	End Time EventEndTime	The precise date and time when a specific activity or event was completed.
Description The Event End Time records the moment an activity was finished. While many events are instantaneous, some activities like 'Invoice Approval' might have a duration, starting when submitted and ending when a decision is made. Having an end time allows for precise calculation of activity processing time. This is useful for analyzing how long users spend on specific tasks. It improves the accuracy of bottleneck analysis by distinguishing between waiting time and actual processing time. Why it matters Enables the precise calculation of activity processing times, distinguishing between active work time and idle waiting time, which is key for detailed bottleneck analysis. Where to get This is often derived by taking the Start Time of the subsequent activity in the process. For some activities, a dedicated end time field may exist in workflow logs. Examples 2023-04-15T09:05:12Z2023-04-18T15:00:00Z2023-05-20T11:25:45Z
	Invoice Cycle Time InvoiceCycleTime	The total time from when an invoice was first created to when it was closed.
Description This attribute measures the end-to-end duration of the entire invoice lifecycle for a single case. It is calculated as the time difference between the very first activity, typically 'Invoice Created', and the final activity, 'Invoice Closed'. This metric provides a high-level view of overall process efficiency. It is the primary measure for the 'End-to-End Invoice Cycle Time' dashboard. By analyzing this attribute across different dimensions like customer or business unit, organizations can identify which types of invoices take the longest to process and investigate the root causes. Why it matters Provides a single, crucial measure of overall process velocity, helping to quickly identify which invoices take the longest to complete from start to finish. Where to get This is a calculated metric, derived by taking the difference between the maximum and minimum EventTimestamp for each unique InvoiceNumber. Examples 45 days 8 hours32 days 2 hours90 days 12 hours
	Invoice Date InvoiceDate	The official date the invoice was issued.
Description The Invoice Date, also known as the transaction date, is the date recorded on the invoice document. It serves as the starting point for payment term calculations. This date is a critical component for calculating Days Sales Outstanding (DSO), as DSO measures the time from the Invoice Date to the payment date. It is distinct from the creation date in the system and represents the official start of the payment cycle from the customer's point of view. Why it matters Serves as the official start date for an invoice's lifecycle and is the baseline for calculating the Days Sales Outstanding (DSO) KPI. Where to get Located in the RA_CUSTOMER_TRX_ALL table, in the TRX_DATE field. Examples 2023-04-142023-05-182023-06-25
	Is Paid On Time IsPaidOnTime	A boolean flag indicating if the invoice was paid on or before its due date.
Description This calculated attribute provides a simple true or false indicator of payment timeliness. It is derived by comparing the date of the 'Customer Payment Received' activity with the 'Due Date' attribute of the invoice. This flag simplifies analysis and reporting for the On-Time Payment Rate KPI. It allows for easy filtering and segmentation to understand what factors, such as customer, region, or invoice amount, correlate with late payments. It is a key metric for evaluating collections effectiveness. Why it matters Simplifies the measurement of collections performance and allows for easy analysis of the factors that contribute to on-time versus late payments. Where to get Calculated by comparing the timestamp of the final payment activity against the DueDate attribute. The logic is: `PaymentTimestamp <= DueDate`. Examples truefalse
	Is Rework IsRework	A boolean flag indicating if an activity is considered rework, such as a repeated approval or correction.
Description This calculated attribute flags activities that represent unnecessary or redundant work. Examples include an invoice being rejected and then resubmitted for approval, or a correction being made after the initial creation. By flagging rework, it becomes easy to quantify its impact on the process. The Billing Rework Rate KPI is calculated directly from this attribute. Dashboards can visualize the frequency of rework and measure the extra cycle time it adds, helping to pinpoint the sources of inefficiency and errors. Why it matters Directly quantifies process inefficiency by flagging unnecessary or repeated work, making it simple to measure the cost and time impact of quality issues. Where to get This is calculated during data transformation based on the sequence of activities. For example, if an 'Invoice Approved' activity is preceded by an 'Invoice Rejected' activity for the same case, it's flagged as rework. Examples truefalse
	Last Data Update LastDataUpdate	The timestamp indicating the last time the data for this event was refreshed or extracted from the source system.
Description This attribute provides the timestamp of the most recent data extraction. It is a metadata field that is essential for understanding the freshness of the data being analyzed. Analysts use this information to confirm they are working with up-to-date information and to understand the data's recency. It is particularly important for dashboards that claim to be 'real-time' or near real-time, as it provides transparency about potential data lag. Why it matters Informs users about the freshness of the data, ensuring that analyses and conclusions are based on information with a known and acceptable level of recency. Where to get This is a metadata field generated during the data extraction, transformation, and loading (ETL) process. It typically corresponds to the execution time of the data pipeline. Examples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Payment Method PaymentMethod	The method used by the customer to make the payment, such as bank transfer or credit card.
Description This attribute specifies how a customer paid their invoice. This information can be useful for analyzing payment trends and costs. Different payment methods may have different processing times and transaction costs. Analyzing by payment method can help understand if certain methods are prone to reconciliation errors or delays. It can also inform strategies to encourage customers to use more efficient payment channels. Why it matters Helps in analyzing payment processing efficiency, transaction costs, and reconciliation error rates associated with different payment channels. Where to get Found in the cash receipt tables, such as AR_CASH_RECEIPTS_ALL, which would contain a field indicating the payment method. Examples ACHWire TransferCredit CardCheck
	Payment Terms PaymentTerms	The agreed-upon terms for invoice payment, such as 'Net 30' or '2% 10, Net 30'.
Description Payment Terms define the rules governing when and how an invoice should be paid, including any potential discounts for early payment. This information is critical for managing receivables and cash flow. This attribute is essential for calculating the correct due date and for identifying opportunities for early payment discounts. The Early Payment Discount Capture Rate KPI is directly dependent on this data to determine which invoices were eligible for a discount. Why it matters Defines the payment rules for an invoice, directly impacting due date calculations and the ability to track and optimize early payment discount capture. Where to get Located in the RA_TERMS table and linked to the transaction via a term_id in RA_CUSTOMER_TRX_ALL. Examples Net 30Net 602% 10, Net 30
	Region Region	The geographical region associated with the customer or transaction.
Description Region provides the geographic context for the invoice, typically based on the customer's location. This allows for spatial analysis of process performance. Analyzing by region can uncover variations caused by local regulations, market conditions, or regional team performance. Dashboards like DSO Trend and Invoice End-to-End Cycle Time can be segmented by region to see if certain areas are facing unique challenges in getting invoices paid. Why it matters Allows for geographical segmentation of the process, which can highlight regional differences in performance, customer behavior, or compliance. Where to get This is typically derived from the customer's address information stored in the TCA (HZ_LOCATIONS, HZ_PARTY_SITES). It is not a direct field on the invoice itself. Examples North AmericaEuropeAsia-Pacific
	Source System SourceSystem	The system of record from which the event data was extracted.
Description This attribute identifies the source application where the data originated. For this process, it will typically be Oracle Fusion Financials, but it could also specify a particular module within it, like Oracle Receivables (AR). In environments with multiple integrated systems, this field helps differentiate data sources and is crucial for data validation and governance. It ensures that the analysis is based on the correct and intended data set. Why it matters Identifies the origin of the data, which is critical for data governance, troubleshooting, and ensuring the analysis is based on the correct system of record. Where to get This is typically a static value ('Oracle Fusion Financials') added during the data extraction and transformation process. Examples Oracle Fusion FinancialsOracle AR CloudFusion Apps
	User User	The employee or system user who performed a given activity.
Description The User attribute identifies the person or automated agent responsible for executing a process step. This could be the user who created the invoice, the manager who approved it, or the collections agent who issued a reminder. Analyzing by user helps identify training opportunities, workload distribution, and performance differences between individuals or teams. It can reveal if certain users are associated with high error rates or if specific approvers are consistent bottlenecks. Why it matters Assigns accountability for process steps, enabling analysis of user performance, workload balancing, and identification of training needs. Where to get Sourced from user ID fields like CREATED_BY or LAST_UPDATED_BY in various transaction and workflow tables. This ID is then joined with user directory tables (e.g., PER_ALL_PEOPLE_F) to get the user's name. Examples john.smithjane.doeCollectionsBot

Required Recommended Optional

Order to Cash - Billing & Invoicing Activities

These are the key process steps and milestones to capture in your event log for accurate process discovery.

6 Recommended 7 Optional

	Activity	Description
	Customer Payment Received	A payment from a customer has been entered into the system as a cash receipt. At this stage, the payment may not yet be applied to a specific invoice.
Why it matters This is a crucial milestone representing cash inflow. The time gap between payment receipt and its application to an invoice is a key indicator of cash management efficiency. Where to get Explicitly recorded upon the creation of a record in the AR_CASH_RECEIPTS_ALL table. The receipt_date indicates when the payment was processed. Capture Use the creation_date or receipt_date from the AR_CASH_RECEIPTS_ALL table. Event type explicit
	Invoice Approved	The invoice has received all necessary approvals and is ready to be sent to the customer. This event is captured when the approval workflow concludes successfully, updating the invoice's status.
Why it matters This is a critical milestone that gates the invoice's delivery to the customer. Delays here directly impact when the payment clock starts, affecting Days Sales Outstanding (DSO). Where to get Inferred from the final approval status update in the invoice transaction record or the completion timestamp in the associated BPM workflow task. Capture Capture the timestamp when the invoice approval status is set to 'Approved'. Event type inferred
	Invoice Closed	The invoice is fully paid and reconciled, and its lifecycle is complete. This event is typically inferred when the outstanding balance on the invoice becomes zero and its status is updated.
Why it matters This is the final resolution of the invoice and marks the end of the process. The total time to reach this state is the end-to-end cycle time, a primary KPI for the billing process. Where to get Inferred from the AR_PAYMENT_SCHEDULES_ALL table when the status is updated to 'CLOSED' and the amount_due_remaining is zero. The 'gl_date_closed' field indicates the closure date. Capture Use the gl_date_closed from AR_PAYMENT_SCHEDULES_ALL for the specific invoice. Event type inferred
	Invoice Created	The initial creation of an invoice transaction in the system, often in a draft or incomplete status. This event is explicitly logged when a user saves a new invoice record for the first time in the Accounts Receivable module.
Why it matters This is the definitive start of the billing process. Analyzing the time from creation to completion helps identify front-end data entry delays or system performance issues. Where to get This event is captured from the creation date of the transaction record in the RA_CUSTOMER_TRX_ALL table. The initial status is often 'Incomplete'. Capture Use the creation_date from the RA_CUSTOMER_TRX_ALL table for the specific invoice number. Event type explicit
	Invoice Sent to Customer	The invoice has been delivered to the customer via their preferred method, such as email or print. The system often records the timestamp when the delivery action is executed.
Why it matters This activity officially starts the payment term period. Measuring the time from approval to delivery is key to understanding the efficiency of the invoice distribution process. Where to get This can be inferred from the 'last_printed_date' field in RA_CUSTOMER_TRX_ALL or from logs in Oracle Business Intelligence Publisher if electronic delivery is used. Capture Use the timestamp from the relevant delivery or printing log associated with the invoice. Event type inferred
	Payment Applied to Invoice	The received customer payment has been successfully matched and applied to the specific invoice, reducing its outstanding balance. This is a discrete transactional record.
Why it matters This activity confirms that cash has been properly allocated, which is critical for accurate aging reports and financial statements. It's the final step in recognizing the cash against the receivable. Where to get Explicitly recorded in the AR_RECEIVABLE_APPLICATIONS_ALL table. The apply_date and gl_date fields indicate when the application occurred. Capture Use the apply_date from the AR_RECEIVABLE_APPLICATIONS_ALL table linking the cash receipt to the invoice. Event type explicit
	Dispute Initiated	The customer has formally disputed the invoice, and a dispute case has been created in the system. This is typically recorded by changing a status flag on the invoice payment schedule.
Why it matters Disputes freeze the payment process and require manual effort to resolve. Analyzing dispute frequency and resolution time helps identify root causes, like pricing or shipping errors. Where to get This can be inferred from the status field in the AR_PAYMENT_SCHEDULES_ALL table being set to a dispute status, or from creation records in AR_DISPUTE_HISTORY. Capture Identify when the dispute flag or status is activated for the invoice's payment schedule. Event type inferred
	Invoice Adjusted	A modification, such as a write-off or credit, has been made to the invoice amount. This is an explicit transaction to alter the outstanding balance of the invoice.
Why it matters Adjustments often signify disputes, concessions, or corrections. Analyzing the frequency and value of adjustments can reveal underlying issues in the order-to-cash process. Where to get Explicitly recorded in the AR_ADJUSTMENTS_ALL table. The creation_date of the adjustment record marks the event. Capture Use the creation_date from the AR_ADJUSTMENTS_ALL table for the relevant invoice. Event type explicit
	Invoice Completed	Represents the point where the invoice data entry is finalized and the transaction is ready for validation and accounting. This is typically captured by observing the change of the invoice status from 'Incomplete' to 'Complete'.
Why it matters This milestone marks the end of the data entry phase. The time between creation and completion can indicate the efficiency of the billing department's data entry and review process. Where to get Inferred from a status change on the invoice transaction record in the RA_CUSTOMER_TRX_ALL table. Look for the timestamp associated with the status update to 'Complete'. Capture Track status history for the transaction in RA_CUSTOMER_TRX_ALL or related workflow tables. Event type inferred
	Invoice Rejected	An approver has rejected the invoice, typically due to errors in data like pricing or quantities. This event sends the invoice back for correction, creating a rework loop.
Why it matters Tracking rejections highlights issues with billing accuracy and internal controls. Analyzing the frequency and reasons for rejection can pinpoint areas for process improvement and training. Where to get Inferred from a status update on the invoice transaction record or the 'Rejected' outcome in the BPM workflow task. Capture Capture the timestamp when the invoice approval status is set to 'Rejected'. Event type inferred
	Invoice Submitted for Approval	The invoice is formally submitted into an approval workflow, if one is configured. This is captured when the invoice status is updated to a pending approval state, triggering notifications to designated approvers.
Why it matters Marks the beginning of the approval cycle. Tracking this activity is essential for measuring and analyzing the subsequent approval time, a key component of the overall invoice cycle time. Where to get Inferred from a status change on the invoice transaction, or captured from the Oracle Business Process Management (BPM) workflow tables that log the initiation of the approval task. Capture Identify the timestamp when the invoice's approval status changes to 'Pending' or a similar state. Event type inferred
	Payment Due Date Reached	The date on which payment for the invoice is contractually due has passed. This is not a transactional event but is calculated based on the invoice terms and the current date.
Why it matters This calculated event is fundamental for aging analysis and calculating DSO. It separates on-time invoices from overdue ones, enabling focused collections activities. Where to get This is a calculated event. It occurs when the current date is greater than the due_date field in the AR_PAYMENT_SCHEDULES_ALL table for a given invoice. Capture Calculated by comparing the current date with the due_date field in AR_PAYMENT_SCHEDULES_ALL. Event type calculated
	Payment Reminder Issued	A dunning letter or reminder notice has been sent to the customer for an overdue invoice. This is an explicit action logged by the collections module.
Why it matters Tracking reminders helps measure the effectiveness of the collections process. It allows for analysis of which reminder strategies lead to faster payments. Where to get Explicitly logged in the Oracle Advanced Collections module. Dunning history tables like IEX_DUNNINGS would record the date and level of the reminder sent. Capture Capture from dunning history tables, linking the dunning transaction to the invoice. Event type explicit

Recommended Optional

Extraction Guides

How to get your data from Oracle Fusion Financials

Steps

Navigate to BI Publisher: Log in to Oracle Fusion Applications and use the Navigator menu to go to Tools, then select Reports and Analytics. Click the Browse Catalog button to open the Business Intelligence Catalog.
Create a Data Model: In the catalog, click the New dropdown menu and select Data Model. This will open the data model editor.
Define the SQL Query Dataset: In the Data Model pane, click the plus icon next to Data Sets and select SQL Query. In the new dialog box, give your dataset a name, for example, AR_INVOICE_LIFECYCLE. Select the appropriate Data Source, which is typically ApplicationDB_FSCM.
Enter the SQL Query: Copy the complete SQL query provided in the query section of this document and paste it into the SQL Query text area. The query uses parameters like :P_START_DATE, :P_END_DATE, and :P_BUSINESS_UNIT which will be automatically recognized.
Configure Parameters and View Data: Go to the Parameters tab to set default values or configure display options for the user. Then, go to the Data tab, enter values for the parameters (e.g., a short date range), and click View to test the query and see a sample of the output data.
Save the Data Model: Once you confirm the data is correct, click the Save icon and store the data model in a suitable folder, for example, under Shared Folders/Custom/ProcessMining.
Create a Report: Navigate back to the catalog, click the New dropdown, and select Report. In the report creation wizard, select the 'Use Data Model' option and find the data model you just saved.
Configure the Report Layout: In the report layout editor, do not create a complex layout. Select the option to 'Create Table' and simply drag and drop all columns from the data set. The goal is a raw data export, not a formatted report.
Set Default Output to CSV: In the report's properties, configure the default output format to be CSV. This ensures that when the report is run, it generates a plain text file suitable for process mining.
Schedule the Report: From the catalog, find your report, click More, and select Schedule. Create a new job, configure the parameters (date range, business unit), and set the destination. A common destination is the Content Server (UCM) or an external SFTP server.
Retrieve the Event Log: Once the scheduled job completes, navigate to the specified destination (e.g., the UCM content repository) to download the generated CSV file. This file is your event log.
Prepare for Upload: Ensure the CSV file has the correct column headers as defined in the query (InvoiceNumber, ActivityName, EventTimestamp, etc.). The file is now ready to be uploaded to your process mining platform.

Configuration

BI Publisher Parameters: The query is designed with parameters to control the data scope. These will appear automatically when you create a report from the data model.
- :P_START_DATE: The start date for the extraction period (format YYYY-MM-DD). The query filters events based on their timestamp.
- :P_END_DATE: The end date for the extraction period (format YYYY-MM-DD).
- :P_BUSINESS_UNIT: The specific business unit name to filter the invoices. Use this to reduce data volume and focus the analysis.
Date Range: For initial testing and analysis, extract a limited period, such as 3 to 6 months of data. For a full-scale analysis, you might extract 12 to 18 months, depending on business needs.
Status Code Configuration: The query contains placeholders like '[Your Pending Approval Status]'. You must replace these with the actual status codes used in your Oracle Fusion implementation for invoice approval workflows. Consult with a functional analyst to identify these values in the RA_CUST_TRX_TYPES_ALL table or system lookups.
Performance: Extracting data for a long period or for all business units at once can be resource intensive. It is highly recommended to schedule the BI Publisher report to run during off-peak hours to avoid impacting system performance for other users.
Prerequisites: You need a user account with roles that grant permission to create data models and reports in BI Publisher, such as BI Administrator or a custom role with similar privileges. The user must also have data security profiles that allow access to the required receivables, customer, and business unit data.

a Sample Query sql

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

Steps

Prerequisites: Ensure you have Python 3.6+ installed along with the requests and pandas libraries. You can install them using pip: pip install requests pandas.
Oracle Fusion Credentials: Obtain the necessary credentials for accessing the Oracle Fusion REST APIs. This includes the base URL for your Fusion instance, a username, and a password for a user with sufficient privileges to read Receivables data.
Configure the Script: Open the provided Python script in an editor. Locate the configuration section at the top of the script and replace the placeholder values for FUSION_URL, USERNAME, PASSWORD, and any filtering parameters like start_date.
Understand API Endpoints: The script primarily uses the receivablesInvoices endpoint to fetch the main invoice data. It then makes subsequent calls to other endpoints like receivablesReceipts, receivablesReceiptApplications, receivablesAdjustments, and collectionsDelinquentTransactions to gather related events.
Pagination Handling: The script includes a helper function, get_paginated_data, which automatically handles API pagination by following the next link in the API response until all records for a given query are retrieved.
Data Fetching: The main part of the script first fetches a list of invoices within the specified date range. It then iterates through each invoice to gather its specific details and related events.
Event Generation: For each invoice, the script constructs different activity rows. Some activities, like 'Invoice Created', are derived directly from invoice fields (CreationDate). Others, like 'Payment Applied to Invoice', require calling separate APIs and linking the data back to the invoice number.
Handling Calculated Events: The 'Payment Due Date Reached' event is not a direct transaction. The script calculates this event by checking if the invoice's DueDate has passed and the invoice remains unpaid.
Execute the Script: Run the script from your terminal using python your_script_name.py. The script will print progress updates as it fetches data for each invoice.
Review the Output: Once execution is complete, a file named oracle_fusion_ar_event_log.csv will be created in the same directory. This file contains the extracted event log.
Prepare for Upload: Open the generated CSV file. Ensure the column headers are CaseId, ActivityName, and EventTimestamp for a basic process map, or map the generated columns (InvoiceNumber, ActivityName, EventTimestamp, InvoiceAmount, etc.) in your process mining tool during upload.

Configuration

API Base URL: The root URL for your Oracle Fusion Financials instance, e.g., https://[your-pod].fa.em2.oraclecloud.com/fscmRestApi/resources/11.13.18.05.
Authentication: The script uses Basic Authentication. Ensure the user account has roles like 'Accounts Receivable Manager' or a custom role with privileges to access the receivablesInvoices, receivablesReceipts, receivablesReceiptApplications, receivablesAdjustments, and collectionsDelinquentTransactions REST resources.
Date Range Filter: The script uses a q parameter with a filter on CreationDate to limit the initial set of invoices. It's recommended to start with a smaller range, like 3-6 months, to manage the extraction time and API load. Example: CreationDate between 'YYYY-MM-DD' and 'YYYY-MM-DD'.
Pagination Limit: The limit parameter in the API calls controls how many records are returned per request. A value between 100 and 500 is typically efficient. The script is configured with a default limit.
Business Unit Filter: You can add a filter for the Business Unit to the query parameter (q) to narrow the scope of the extraction, for example: BusinessUnitName = '[Your Business Unit Name]'.
Performance: Extracting data on an invoice-by-invoice basis can be slow for large volumes. The script makes multiple API calls per invoice. For datasets exceeding 100,000 invoices, consider running the script in batches or during off-peak hours to avoid performance degradation or API rate limiting.

a Sample Query python

import requests
import pandas as pd
import datetime
import os

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

Your Order to Cash - Billing & Invoicing Data Template

Your Order to Cash - Billing & Invoicing Data Template

Order to Cash - Billing & Invoicing Attributes

Order to Cash - Billing & Invoicing Activities

Extraction Guides

Oracle BI Publisher Report for Billing & Invoicing Data

Steps

Configuration

a Sample Query sql

Python Script Extraction via Oracle Fusion REST APIs

Steps

Configuration

a Sample Query python

Ready to Get Started?

Start Optimizing Oracle Billing & Invoicing Now

Your Order to Cash - Billing & Invoicing Data Template

Your Order to Cash - Billing & Invoicing Data Template

Order to Cash - Billing & Invoicing Attributes

Order to Cash - Billing & Invoicing Activities

Extraction Guides

Oracle BI Publisher Report for Billing & Invoicing Data

Steps

Configuration

a Sample Query sql

Python Script Extraction via Oracle Fusion REST APIs

Steps

Configuration

a Sample Query python

We value your privacy

Ready to Get Started?

Start Optimizing Oracle Billing & Invoicing Now