Significance of Performing Initial Ingest in Redwood Receiving Process

Significance of Performing Initial Ingest in Redwood Receiving Process

 

Performing an initial ingest in the Redwood Receiving process builds the essential search indexes for the Oracle Search Cloud Service (OSCS). It is a vital prerequisite that translates existing back-end data into a format the modernized, search-driven Redwood pages require to function properly.

Initial Ingest is a one-time (or sometimes occasional) data synchronization process that populates Redwood Receiving with all eligible open receipt transactions. It improves performance, enables faster searches, validates receipt eligibility, and provides the data foundation required for the modern Redwood Receiving experience in Oracle Fusion.

 

Key Significance:

Initial Ingest is effectively the "data preparation" step that allows the Redwood Receiving pages to function efficiently.

Without the ingest, newly created or updated purchasing documents may not immediately appear in the Redwood Receiving workbench.

• Mandatory Prerequisite: The new Redwood Self-Service Receiving and Expected Shipment Lines pages depend entirely on OSCS. Without this initial step, the pages will appear blank or fail to populate expected receipts.
• Centralizes Expected Deliveries: The process gathers and synchronizes expected receipts across multiple channels, specifically pulling in:

o   Purchase orders

o   Transfer orders

o   Advanced Shipment Notices (ASNs)

o   Return Material Authorizations (RMAs)

• Enables Global Search: It indexes back-end data so users can leverage the advanced, type-ahead global search features inherent to the Redwood UI.

 

When is Initial Ingest Required?

Initial Ingest is typically required:

·       During the first-time setup of Redwood Receiving.

·       After enabling the Redwood Receiving experience.

·       To populate the initial backlog of expected receipts.

·       Whenever historical open receipts need to be made available to the Redwood receiving interface.

After the initial load, Oracle generally relies on incremental synchronization so that newly created or updated purchasing documents become available without requiring another full ingest, depending on the environment configuration and scheduled synchronization processes.

 

How to Perform the Ingest?

To generate the index and populate it with data, administrators must run a specific scheduled process:

A. ESS job to create index definition and perform initial ingest to OSCS.

1.      Log into the application and navigate to the Tools > Scheduled Processes menu.

2.      Click Schedule New Process.

3.      Search for the process name: ESS job to create index definition and perform initial ingest to OSCS.

4.      Specify the required index name in the parameters. Leaving this blank will process all predefined indexes.

Parameter values for index name to reingest:

·       fa-scm-rcv-expected-po-receipts

·       fa-scm-rcv-expected-asn-receipts

·       fa-scm-rcv-expected-to-receipts

·       fa-scm-rcv-expected-rma-receipts

·       fa-scm-rcv-transactions

 

5.      The indexing job needs to be executed only once during the transition from the classical UI to the Redwood UI. However, there are several scenarios where re-indexing is still required.

Once the initial ingest is complete, subsequent receipts processed through the standard application will ingest automatically, though periodic bulk runs can be scheduled to maintain data sync.

B. Ingest Receiving Search Indexes:

This ESS job is needed to ingest receipts performed outside of the Responsive Self-Service Receiving application.

1.      Navigate to the Tools > Scheduled Processes menu.

2.      Click Schedule New Process.

3.      Search for the process name: Ingest Receiving Search Indexes.

4.      The purpose of the schedule process is to ingest all inbound documents and receiving transactions that were created outside of Redwood Receiving pages since the last time this job ran.

5.      This job should be scheduled to run periodically.

6.      It's recommended to schedule this process to run every 30 minutes but can be scheduled to run more frequent as well.

 

Important Note:

As part of the transition from the classical Receiving pages to the Redwood Receiving experience, the initial search indexing process is expected to be executed only once to populate the Redwood search index with existing eligible receiving data.

However, there are scenarios in which the search index may require re-ingestion after the initial migration. These scenarios include, but are not limited to:

·       Objects created through web service integrations.

·       Objects created using the legacy classical user interface.

·       Objects created or updated by other SCM applications or background processes.

·       Data synchronization issues resulting from product defects or exceptional processing conditions.

When re-indexing is required, run the Ingest Receiving Search Index ESS job. This job replaces the legacy class-based indexing ESS job for the Redwood Receiving experience and should be used to refresh the Redwood search index whenever eligible receiving transactions are not available through the Redwood Receiving pages.

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.