Inside Oracle Fusion: The Transfer Orders

 

Inside Oracle Fusion: The Transfer Orders

Transfer Orders in Oracle Fusion play a pivotal role in facilitating inter-organization or intra-organization movement of goods within an enterprise.

Transfer Orders (TOs) enable movement of goods between two inventory organizations OR between two subinventories within the same inventory organization.

For the process to function correctly, several setups must be configured in Oracle Fusion.
Below is an elaboration of each critical configuration point.

 

1.      Item Attributes – “Internally Transferrable” & “Transfer Orders Enabled”

Before an item can be used in a Transfer Order, it must be properly configured in the Product Information Management (PIM) module.
The following attributes play a vital role:

• Internally Transferrable:
• This attribute allows the item to be transferred between inventory organizations within the enterprise.
• If disabled, the item will not appear as eligible for Transfer Orders.
• Transfer Orders Enabled:
• This flag ensures the item can be included in transfer transactions that use the Transfer Order document type.
• It works in conjunction with the internal material transfer flow defined in Supply Chain Execution.

 

Note: Always ensure both attributes are enabled at the item master level and propagated to all associated inventory organizations.

2.      Item Assignment to Both Inventory Organizations

For the item to be shipped from one org and received into another, it must be assigned to both the source and destination inventory organizations.

• The system must recognize the same Item ID and definition across both orgs; otherwise, the Transfer Order creation or shipment process will fail.
• Additionally, costing and valuation attributes should align if both organizations belong to the same cost organization.
  This ensures consistency in item data, UOM conversions, and cost processing across the two organizations involved in the transfer.

 

3.      Manage Interorganization Parameters (Shipping Network)

This is the heart of Transfer Order configuration — it defines the relationship between the source and destination organizations.

Navigation:
Setup and Maintenance → Manufacturing and Supply Chain Materials Management → Manage Interorganization Parameters

Key configurations:

·       From Organization → To Organization (pairing)

·       Transfer Type: In-transit or Direct

·       Receipt Routing: Applicable for In-transit transfer types.

·       Expense or Inventory Destination: Determines if the goods will be received into inventory or charged as expense.

Impact:
These parameters control the logistics, costing, and accounting behaviour of the Transfer Order flow.

 

4.      Manage Transit Time with Default Ship Method Assignment

This setup defines the expected transit duration and shipping method between organizations.

Navigation:
Setup and Maintenance → Manufacturing and Supply Chain Materials Management → Manage Transit Times

Configurations:

·       Define Origin (Location associated with the Source Org) and Destination (Location associated with the Destination Org) pairing.

·       Assign Ship Method and Transit Time (in days or hours).

·       Specify Default Ship Method

Purpose:

·       Helps in calculating expected receipt dates in planning and execution modules.

·       Used by Supply Chain Orchestration and Order Management to schedule delivery and receiving operations.

 

5.      Shipping Parameters for Source Organization (Shipping Org)

The source organization acts as the shipping organization, and its shipping setup determines how shipments are executed.

Navigation:
Setup and Maintenance → Manufacturing and Supply Chain Materials Management → Manage Shipping Parameters

Key configurations:

·       Default Release Sequence Rule and Ship Confirm Rule.

·       Default Pick Slip Grouping Rules – determines grouping of shipments.

This ensures that the Transfer Order Shipment process (Pick → Ship Confirm) executes seamlessly from the source warehouse.

6.      Receiving Parameters for Destination Organization (Receiving Org)

The destination organization acts as the receiving organization, and its parameters define how incoming goods are processed.

Navigation:
Setup and Maintenance → Manufacturing and Supply Chain Materials Management → Manage Receiving Parameters

Key configurations:

·       Receipt Routing: Direct Delivery, Inspection Required, or Standard Receipt.

This controls the behaviour of receipt transactions, in-transit accounting, and inventory updates when goods arrive at the destination org.

 

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.