Min-Max Planning - Unleash the Knowledge

 

Min-Max Planning – Introduction:

Min-Max Planning is an inventory replenishment method in Oracle Fusion Supply Chain Management (SCM) that helps maintain optimal inventory levels by automatically recommending replenishment when available inventory falls below a predefined minimum threshold.

The planning process is executed at the individual inventory organization level or at specific subinventory level within a given inventory org.

This can be run for all items or a selected set of items within the scope of planning level. For each item, minimum and maximum inventory levels must be defined.

When the Min-Max Planning Report is executed, Oracle Fusion evaluates the item's inventory position by considering both on-hand quantity and eligible on-order supply & demand. If the total available quantity is less than the defined minimum level, the application automatically recommends replenishment to restore inventory up to the specified maximum level.

Depending on the item's replenishment source and supply configuration, the process generates one of the following replenishment documents:

·       Purchase Requisition for externally sourced items.

·       Transfer Order for inventory sourced from another inventory organization.

·       Movement Request for replenishment within the same inventory organization (for example, between subinventories).

Min-Max Planning provides a simple and efficient replenishment mechanism that helps maintain inventory availability, reduce stock shortages, and minimize excess inventory by ordering only the quantity required to replenish stock up to the defined maximum level.

This planning method helps ensure adequate inventory availability while minimizing the risk of stock shortages and excess inventory.

While the Min-Max Planning process is straightforward to execute, it is important to understand the underlying replenishment logic, including how Oracle Fusion determines when to trigger replenishment and how it calculates the quantity to replenish.

The objective of this blog is to explain the decision-making logic behind the Min-Max Planning process and the significance of the key parameters available when running the Min-Max Planning Report. Understanding these parameters enables organizations to configure the process effectively and generate replenishment recommendations that align with their inventory planning policies

 

The Basics: How the Logic Works?

The formula calculates replenishment based on a very straightforward logic:

  • Total Available = (Quantity on Hand + Supply) – Demand
  • Trigger -> When to order?

If Total Available < Minimum Quantity, an order is suggested.

  • How much to Order?

Order Quantity = Maximum Quantity - Total Available

Significance of input parameters:

The Min-Max Planning Report provides several parameters that influence how the planning process evaluates inventory and generates replenishment recommendations. Each parameter plays a specific role in determining the planning scope, inventory calculations, and replenishment logic.

Understanding the purpose and impact of these parameters is essential for configuring the planning process to meet an organization's inventory management requirements. The following sections explain some of the key parameters and their significance in the Min-Max Planning process.

 

·       Restock

1.       This is a required parameters with the default value as No.

2.       This parameter controls the generation of new supply for the planning recommended quantities.

3.       The value entered should be No if the user wants to execute the report just for the sake of understanding the recommended supply quantities by the planning process without creating the actual supply orders.

4.       When this option is selected as No, system will not create supply.

         

 

·       Item Selection

1.       All min-max planned items

The planning process will be executed for all the items which are setup for Min-Max planning in the given inventory organization / subinventory as per the planning level selected for the report execution.

 

2.       Items over maximum quantity

The planning process will be executed only for those items which are setup for Min-Max planning in the given inventory organization / subinventory and the available quantity is

over the maximum quantity.

 

3.       Items under minimum quantity

The planning process will be executed only for those items which are setup for Min-Max planning in the given inventory organization / subinventory and the available quantity is

under the minimum quantity.

 

 

Significance of Item Selection Options:

The Items Under Minimum Quantity and Items Over Maximum Quantity options serve as valuable inventory exception reports by identifying items whose inventory levels are outside the configured Min-Max thresholds.

  • Items reported under Items Under Minimum Quantity indicate that the available inventory has dropped below the minimum threshold. Under normal operating conditions, regular execution of the Min-Max Planning process should generate replenishment recommendations to restore inventory to the configured maximum level. If the same items continue to appear in this report over an extended period, it may indicate that the Min-Max Planning process has not been executed regularly or that the recommended replenishment documents were not created or fulfilled.
  • Items reported under Items Over Maximum Quantity indicate that the available inventory exceeds the configured maximum threshold. This situation may occur due to excess receipts, manual inventory adjustments, unexpected demand fluctuations, or other business-specific scenarios. Such items should be reviewed to determine the cause of overstocking and to assess whether inventory parameters or replenishment practices require adjustment.

These options enable inventory planners to proactively monitor inventory exceptions, validate the effectiveness of the Min-Max Planning process, and ensure that inventory levels remain within the organization's defined planning thresholds.

 

·       Demand Cutoff Date / Demand Cutoff Date Offset / Supply Cutoff Date / Supply Cutoff Date Offset

1.       A Supply Cutoff Date Offset is a critical parameter (although optional) which extends the timeframe for considering open supply orders (such as purchase orders or work orders) by adding a specific number of days to the current date or a base cutoff date.

2.       System doesn’t create a duplicate supply for the item if we execute the Min-Max planning program with correct parameters to include the existing POs with future delivery date as open supply.

3.       But if this program is executed with no values mentioned in either Supply Cutoff Date or the Supply Cutoff Date Offset parameters as shown in the screenshot below then the future dated open POs would not be considered as available supply, and system will trigger new Requisition-> PO to meet the Min-Max quantities.

A screenshot of a computer

Description automatically generated

4.       A Demand Cutoff Date Offset is a critical parameter (although optional) which extends the timeframe for considering open supply orders (such as purchase orders or work orders) by adding a specific number of days to the current date or a base cutoff date.

5.       The Cut-Off Date and Offset Days work in conjunction to derive the Final Cut-Off Date for Demand/Supply.

6.       If we enter both the parameters, then the offset will be done on top of the Cut-Off Date entered.

7.       If we enter only the Cut-Off Date and leave the Off-set days blank, then the offset will not be done.

8.       If we enter only the Off-Set Days and leave the Cut-Off Date blank, then the offset will be done on top of the SYSDATE (Report Date).

Here is the table illustrating the behaviour for better understanding.

Report Date

Demand/Supply Cut-Off Date Entered

Demand Cutoff Date Offset (Number of days)

Final Demand/Supply Cut-Off Date Calculated by the System

21-Sep-22

26-Sep-22

2

28-Sep-22

21-Sep-22

26-Sep-22

4

30-Sep-22

21-Sep-22

-

4

25-Sep-22

21-Sep-22

15-Sep-22

2

17-Sep-22

21-Sep-22

26-Sep-22

-

26-Sep-22

 

·       Include Interface Supply

Enter Yes or No to indicate whether to include interface supply in the open supply quantities.

 

o   It is common for valid supply transactions to remain temporarily in interface tables, such as the Purchase Requisition Interface or Work Order Interface, while awaiting processing into the corresponding application base tables. During this period, the supply has been initiated but is not yet reflected as an available supply transaction in Oracle Fusion.

o   In such scenarios, the Include Interface Supply parameter plays a significant role. When enabled, the Min-Max Planning process considers these pending interface records as existing supply while calculating the available inventory position. This prevents the generation of duplicate replenishment recommendations for the same demand, thereby avoiding unnecessary purchase requisitions, transfer orders, or work orders.

o   Enabling this parameter is particularly beneficial in environments where interface processing occurs asynchronously or where a processing delay exists between the creation of interface records and their successful import into the application base tables.

 

Process Steps Summarised:

 

1.       Run “Print Min-Max Planning Report”

2.       Run “Process Supply Chain Orchestration Interface”

3.       Review the supply order for the item in “Manage Supply Lines” in Supply Chain Orchestration work area

4.       Note the supply document created as per the source and process it

o   If it is a Purchase Requisition -> Convert it into PO or if BPA exists PO gets auto created. Receive the PO to get the supply.

o   If it is Work Order -> Note down the WO# and complete the same to get the supply.

o   If it is a Transfer Order -> Note the TO# and complete the transfer from Source Org to Destination Org to get the supply

 

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.


Min-Max Planning - Unleash the Knowledge

  Min-Max Planning – Introduction: Min-Max Planning is an inventory replenishment method in Oracle Fusion Supply Chain Management (SCM) th...