Executing and Scheduling the Reports in Oracle Fusion

 

Executing and Scheduling the Reports in Oracle Fusion

For reports that process large volumes of data, it is recommended to use the Schedule option instead of running them interactively. Scheduling reports helps avoid browser timeouts, improves system performance, and ensures that report outputs are delivered directly to users via email.

Follow the steps below to execute or schedule reports in Oracle Fusion.

1.      Select the Report and Click on ‘More’ option as shown below-

2.      Select the Report and Click on ‘More’ -> Schedule option as shown below-

3.      Enter the details as below-

General: Select the required Parameters

Output: Just click on Add Destination and enter the email address to whom the report output should be sent.

You can add multiple email IDs with coma separation.

 Schedule: For one time execution – Do not make any changes here.

Auto scheduling:

You can set the report to run automatically on daily or weekly as per the required schedule by selecting the frequency as shown below-

Specify the Start and End Dates

Notifications: You can specify your email address here for automatic notification on completion of the report.

 

Best Practices

• Use scheduled execution for reports containing large volumes of data.
• Configure email delivery to avoid downloading outputs manually.
• Set recurring schedules for reports that are required regularly.
• Monitor notifications to identify and resolve any execution issues promptly.
• Review report parameters carefully before scheduling recurring jobs.

---

Expected Outcome

Upon successful submission, Oracle Fusion will execute the report according to the defined schedule and automatically deliver the output to the designated recipients via email. Users will also receive status notifications, ensuring seamless monitoring and management of report execution.

 

Items LOV is Empty in Redwood UI for Inventory Transactions

 

Items LOV is Empty in Redwood UI for Inventory Transactions

Issue Description:

Sometime users intermittently report an issue across several Oracle Fusion Redwood pages, including:

·       Create Miscellaneous Transaction

·       Subinventory Transfer

·       Create Unordered Receipt

When attempting to search for an inventory item, the Item List of Values (LOV) sometimes returns no results, even though the item exists in the system with correct configurations and org assignments.

As a result, users are unable to select the required item and therefore cannot create or complete the corresponding inventory transactions. This issue can impact day-to-day warehouse and inventory operations and may lead to transaction processing delays.

Resolution:

To ensure that items are correctly displayed in the Item LOV on Redwood pages, perform the following configuration and validation steps.

1. Enable the Required Opt-In Feature

Verify that the Oracle Fusion opt-in feature "Search Items Using the New User Interface" is enabled.

• Enable this opt in to an offering in the Product Management > Items portion of the offerings.

2. Configure and Rebuild the Item Search Index

The Redwood item search functionality relies on the item index. Ensure that the index is properly configured for Inventory Management. This can be done by going to the Product Management heading in the navigator bar> Show More > Configure Application > Indexes.

1.      Click the Item Index

2.      Click the 3 Dots in the upper right -> Enable attribute sets

3.      Enable for Inventory Management.

4.      Once this is done, the Index needs to be rebuilt.

5.      Click Save

6.      Click the 3 Dots -> Rebuild -> Schedule for Now

This will generate a scheduled process.

Once the jobs are done, users need to log out and back in, and the items will be visible in the LOV.

 

Important Note:

To configure and rebuild the index, the user must have the privilege EGP_ACCESS_LANDING_PAGE_PRIV added to the role.

This privilege is available in the standard roles Product Manager and Product Data Steward. You can add these roles to the user ID and Run LDAP programs.

1.      Send Pending LDAP Requests

2.      Retrieve Latest LDAP Changes

3.      Import User and Role Application Security Data

 

Receipt Date at Header vs Line Level: What’s the Difference?

 

When creating receipts in Oracle Receiving, you may notice that the application asks for a Receipt Date at both the header and the line level. At first glance, this can seem redundant—but each date serves a different purpose.

Understanding this distinction is important, especially for accounting, invoicing, and period control.

Let’s break it down.

·       Receipt Date at the Line Level (The Critical One)

The receipt date at the line level is the most important from a financial perspective.

What is it used for?

This date becomes the transaction date of the receipt and is used by:

• Receipt Accounting
• Oracle Payables (Invoice Matching & Accounting)
• Cost Management

In other words, this is the date that determines:

• Which accounting period the receipt falls into
• When costs are recognized
• When supplier invoices can be matched and accounted

Where is it entered?

• Receive Lines page

Key Point

The application always uses the receipt date at the line level for accounting and invoicing, regardless of the header-level date.

---

Receipt Date at the Header Level (Informational)

The receipt date at the header level is more of a reference or informational date.

What is it used for?

• Currently, it has no impact on accounting or invoicing
• It may be used for analytics and reporting purposes in the future

Where is it entered?

• Create Receipt page
• Add to Receipt page

This date can be thought of as the overall receipt creation date, rather than a financial transaction date.

---

Why Does Oracle Ask for Both Dates?

When creating receipts in the UI:

• Both header and line receipt dates are mandatory
• Both default to the current system date
• The GL Date also defaults to the current date

However:

• You can change all three dates independently
• Only the line-level receipt date drives accounting and invoicing

This design allows flexibility while ensuring accurate financial control.

---

Practical Example:

Suppose:

• Accounting Period follows the calendar month
• Receipt Header Date = 30-Sep
• Receipt Line Date = 01-Oct
• GL Date = 01-Oct

What happens?

• The receipt is accounted in October
• Payables and Cost Management treat the receipt as an October transaction
• The header receipt date remains informational

---

Key Takeaways

• Line-level receipt date = Financial transaction date
• Header-level receipt date = Informational only
• Header date may support future analytics
• Receipt Accounting, Payables, and Cost Management rely only on the line-level date

---

Final Thoughts

If your organization has strict period controls or month-end cutoffs, always ensure users understand the importance of maintaining the receipt date at the line level. While the header date may look equally important in the UI, it does not influence accounting outcomes.

 

 

Users can enter a past date for a receive, inspect, put away, correct, or return transaction when the Transaction Date Validation Enabled profile option is set to No validation. Also, the value of the Maximum Number of Days Prior to Current Date in Which a Transaction Can Be Created profile option must be within your threshold.

Understanding Price Break Type Control in Blanket Purchase Agreements

 

Price Break Type Control in Blanket Purchase Agreements

In Oracle Procurement, Blanket Purchase Agreements (BPAs) are widely used to streamline purchasing and leverage negotiated pricing over a period of time. One important configuration that directly impacts pricing behavior is the Price Break Type attribute.

This attribute determines how the system applies price breaks when multiple purchase orders are released against a blanket agreement. Choosing the right option can significantly influence cost savings and pricing accuracy—especially when multiple business units buy from the same agreement.

Let’s break it down.

What Is the Price Break Type?

The Price Break Type is applicable only to Blanket Purchase Agreements and controls whether pricing discounts are calculated based on:

• Total cumulative purchases over time, or
• Each individual purchase order line

This flexibility allows organizations to align Oracle’s pricing logic with supplier contract terms.

The Price Break Type allows organizations to leverage cumulative pricing to achieve better discounts based on the total quantity purchased over time, potentially across multiple business units that use the same blanket agreement.

There are two available options:

1. Cumulative

When Cumulative is selected, the application determines the applicable price break by considering the total quantity released so far against the blanket line, including previous purchase order releases.

In simple terms:

• The system keeps track of the running total quantity purchased.
• As total consumption increases, better price breaks are automatically applied.
• This works across all business units that reference the same blanket agreement.

This option is particularly useful when suppliers offer volume-based discounts tied to overall usage rather than single orders.

 

2. Noncumulative

When Noncumulative is selected, the application determines the price break based only on the quantity of the current purchase order line, without considering past releases.

• Each PO release is priced independently.
• This option is suitable when pricing discounts apply per order rather than over time.
• No aggregation of quantities occurs.
• Previous purchases do not affect the current price.
• This option is ideal when supplier pricing is negotiated per order, not across total consumption.

Example Scenario:

Blanket Purchase Agreement – Item ABC

Quantity Range	Unit Price
1 – 100	$100
101 – 500	$90
501+	$80

Case 1: Cumulative Pricing

• PO Release 1: 80 units
• Cumulative quantity = 80
• Unit price = $100
• PO Release 2: 50 units
• Cumulative quantity = 130 (80 + 50)
• Unit price = $90 (price break achieved)
• PO Release 3: 400 units
• Cumulative quantity = 530
• Unit price = $80

In this case, the system automatically applies better pricing as cumulative purchase volumes increase.

 

Case 2: Noncumulative Pricing

• PO Release 1: 80 units
• Unit price = $100
• PO Release 2: 50 units
• Unit price = $100 (still in 1–100 range)
• PO Release 3: 400 units
• Unit price = $90

Here, each PO release is priced independently, and previous purchases do not influence the pricing.

Illustration of Business case scenario on volume discounts:

PO Schedule Quantity	% Discount
Up to 50,000	0
50,001 - 100,000	1
100,001 - 200,000	1.5
200,001 and above	2

Price Break setup in Oracle BPA:

Quantity	% Discount	Base Price	Discounted Price
50,001	1	18.84	18.6516
100,001	1.5	18.84	18.5574
200,001	2	18.84	18.4632

Cumulative	Non- Cumulative
Price break is applied by adding the current order schedule quantity to the total quantity already ordered against the blanket purchase agreement line.	Price break is applied by using the individual order line quantity.
The retroactive function with new price updates from BPA to open POs is not supported for cumulative price breaks.	The retroactive function with new price updates from BPA to open POs works only for non-cumulative price breaks.
Example: Item X with single BPA using the above-mentioned business case and setups: PO 1 Line 1 = 20, 000 Each PO 2 Line 1 = 20, 000 Each PO 3 Line 1 = 20, 000 Each PO 4 Line 1 = 20, 000 Each PO 5 Line 1 = 30, 000 Each     In this case, PO 1 and PO 2 – No discount in the price PO 3 – 1% discount on 10, 000 Qty PO 4 – 1% discount on 20, 000 Qty PO 5 – 1% discount on 20, 000 Qty & 1.5% discount on remaining 10, 000 Qty	Example: Item X with single BPA using the above-mentioned business case and setups: PO 1 Line 1 = 20, 000 Each PO 2 Line 1 = 20, 000 Each PO 3 Line 1 = 20, 000 Each PO 4 Line 1 = 20, 000 Each PO 5 Line 1 = 30, 000 Each PO 6 Line 1 = 60, 000 Each   In this case, PO 1 To PO 5 – No discount in the price PO 6 – 1% discount on 60, 000 Qty

Why This Matters for the Business

Selecting the correct Price Break Type is not just a technical choice—it’s a strategic one:

• Cumulative pricing helps organizations maximize supplier discounts and encourages consolidated buying.
• Noncumulative pricing offers simplicity and predictable per-order pricing.
• The right configuration ensures accurate pricing, contract compliance, and optimized procurement costs.

Final Thoughts

Understanding and correctly configuring the Price Break Type on Blanket Purchase Agreements ensures that Oracle Procurement behaves exactly as intended by your supplier contracts. Whether your goal is to drive cost savings through cumulative purchasing or maintain straightforward per-order pricing, this small setting plays a big role in procurement efficiency.

In-transit Inventory Ownership in Oracle Fusion

 

Understanding In-Transit Inventory Ownership in Oracle Fusion Internal Transfers

 

In Oracle Fusion Inventory Management, the ownership of material during an internal transfer depends on whether the transfer occurs within the same Business Unit (BU) or across different Business Units. The system uses predefined logic to determine when the ownership shifts from the shipping organization to the receiving organization.

1. Transfers Between Inventory Organizations Within the Same Business Unit

When two inventory organizations (Org A and Org B) belong to the same BU, Oracle Fusion always assumes that ownership transfers at the point of in-transit shipment.

How the ownership behaves:

• Org A ships the material.
• As soon as the shipment is confirmed, the material moves into an in-transit state.
• Even while the goods are physically in transit, the ownership belongs to Org B (the receiving organization).
• This means Org A no longer owns the inventory from the moment it is shipped.

Important Note

This ownership logic is system-driven and cannot be changed.
Oracle does not provide any configuration to override this behavior for same-BU transfers.

 

2. Transfers Between Inventory Organizations Across Different Business Units

When the transfer happens across BUs, Oracle provides more flexibility through Supply Chain Financial Orchestration (SCFO).

·       With SCFO

Using SCFO, customers can configure when the ownership changes:

• Ownership can change at Inter-Organization Shipment, or
• Ownership can change at Inter-Organization Receipt.

This allows organizations to align financial ownership with commercial, tax, compliance, or operational requirements.

·       Without SCFO

 

If a Financial Orchestration flow is not defined:

• Oracle defaults to the similar logic as Within-BU transfers.
• Ownership automatically transfers at the In-Transit Shipment, even when the transfer is across BUs.

This means SCFO is optional, but without it, the system applies the standard ownership transfer assumption.

 

Scenario	Ownership Transfer Point	Configurable?
Transfer within same BU	In-Transit Shipment	No (system default, cannot be overridden)
Transfer across BUs with SCFO	Configurable: Shipment or Receipt	Yes
Transfer across BUs without SCFO	In-Transit Shipment	No (same as intra-BU)