Skip navigation

Forecast Consumption by Customer enhances the ability of a supplier to meet the requirements from large customers.

 

When working with large customers, you might want to consider the demand for each customer separately and plan production quantities accordingly.

 

You can set up the system to net forecasts and sales orders for a particular customer separately, so that you can plan more accurately for the specific demand coming from individual customers.

 

If you do not use the forecast consumption by customer functionality, you compare total sales with total forecast for a particular time period without considering individual customers.

 

Calculating the difference between total forecast and sales yields a different result than calculating the difference between forecast and sales for an individual customer.

 

To use forecast consumption by customer, you have to enter a forecast for a specific customer.

 

In this case, the forecast record has a customer number in the Customer Number field.

 

Based on the customer number, the system can search for sales orders with matching customer numbers in the ship-to or sold-to field to calculate the remaining demand for the customer.

 

You specify whether the system uses to the ship-to or sold-to field from the sales order by setting a processing option or by defining a customer address relationship.

 

When you run the MRP/MPS Requirements Planning program, you can set up the program to use forecast consumption by customer.

 

You can use this functionality for items that are defined with planning fence rule C, G or H. You cannot use forecast consumption logic for process items.

 

When you run the MRP/MPS Requirements Planning program and have activated the Forecast Consumption by Customer functionality, the program calculates the net difference between forecast and sales orders for a period for individual customers.

 

The process consists of these steps:

  • Check the Item Branch record for the item to see that the time fence rule is set to C, G or H.
  • Read the Forecast File table (F3460) and the Sales Order Header File table (F4201) record for each customer.
  • Compare sales orders and forecast for each customer to determine which is greater.
  • The greater value of the two is written to the F3460 as a new forecast record with a forecast type that indicates that it is the result of a Forecast Consumption by Customer calculation

 

You can use the MPS Time Series program (P3413) to review the results of the calculation. The net forecast that results from the Forecast Consumption by Customer calculation is displayed as the adjusted forecast quantity (-FCST).

 

Forecast Consumption by Customer Calculation these tables illustrate the different results that are reached, depending on whether you differentiate by customer. The first table demonstrates the results of a calculation that does not differentiate by customer:

 

CustomerSales OrderForecastGreater of Forecast and Sales Order
A10080
B400375
C700750
Total120012051205

In this calculation, you aggregate all of the sales orders and all of the forecasts for an item and compare the totals with each other. In this case, the total forecast is greater than the total sales order quantity. Therefore, the forecast becomes the total demand.

 

This table demonstrates the results of a calculation that nets each individual sales order against a forecast with matching customer number:

CustomerSales OrderForecastGreater of Forecast and Sales Order
A10080100
B400375400
C700750750
Total1250

In this calculation, the sales order and forecast quantities are not totaled. Instead, each sales order is compared to a matching forecast. The greater quantity in each comparison is added to the total demand. In this case, the total demand is greater than if the first method had been used.

 

Forecast Consumption by Customer Considerations

In order to use Forecast Consumption by Customer, you need to consider:

  • Set up a forecast type for forecast consumption by customer in the UDC table 34/DF (Forecast Type).
  • Set up a version of the MRP/MPS Requirements Planning program by using these processing options:
    • Set the Forecast Consumption Logic processing option for using forecast consumption by customer.
    • Specify the forecast type to be used for forecast consumption by customer.
    • Specify whether the system uses the sold-to or the ship-to number on the sales order when searching for sales orders to net against a forecast.

 

    If you use multi facility planning, set up a version of the Master Planning Schedule - Multiple Plant by using these processing options:

  •         Set the Forecast Consumption Logic processing option for using forecast consumption by customer.
  •         Specify the forecast type to be used for forecast consumption by customer.
  •         Specify whether the system uses the sold-to or the ship-to number on the sales order when searching for sales orders to net against a forecast.
  •         Specify whether the system treats inter plant demand as customer demand consumes the forecast.
  •         Ensure that the items for which you are creating a requirements plan are defined with planning fence rule C, G or H.

 

For more information on Forecast Consumption Logic by Customer please see Forecast Consumption for EnterpriseOne (Doc ID 625964.1).

Do you know that MRP will not create decrease (L type) messages for an item with the order policy code - 4. Ever wondered why?

 

Order Policy Code 4 was designed to be used with high-use/low-cost items, that have stable demand.  Periods of Supply is also used for longer lead-time items for which the user is not concerned about carrying excess inventory.

 

The Period of supply horizon is constantly moving as demand dates and quantities fluctuate and the point where demand/stock is unsatisfied, can get pushed backward or moved forward, resulting in action messages.  MRP will not suggest Decrease messages.  The only supported action messages, then are Expedite, Defer, Cancel and Increase messages.  In the case where demand increases, G increase messages will be  created for Firm unfrozen Orders that can satisfy the the unmet demand.

 

The Period of Supply horizon is only applicable to planned orders(PLO), i.e. MRP looks to the next unsatisfied demand point and counts out the Value Order Policy (VOP) days taking into consideration firm orders inside the VOP, and suggests any necessary PLOs.

 

If an item has an Order Policy Code (OPC) of 4, MRP will generate a order message for either a work order or purchase order using the days entered in the Order Policy Value field (OPV).

 

An order that is created by MRP for a Period of Supply part is usually for a quantity more than is necessary on the required date. If decrease messages were created for a period of supply part a subsequent MRP run with an effective date of before the required date of the order would give an unnecessary Decrease (D) message. It would tell you to decrease the size of the order that it originally ordered for the period in question.

 

For more information on Setup, Use of Period of Supply Functionality , please review the below KM Docs:

  • Periods of Supply Logic - Order Policy Code 4 (Doc ID 853361.1)
  • MRP Order Policy Code and Item Branch Quantities in the Planning System (P41026) (Doc ID 627236.1)

BOM Integrity Report

The Integrity Analysis program (R30601) generates a report that identifies any processes or Bill of Material (BOM) structures that must be corrected to properly generate production costs (R30812) and successfully obtain MRP output (R3482/R3483).  If the report indicates errors, correct the processes or BOMs and run the Integrity Analysis program again.  When the program does not find errors in the processes, it updates the low-level codes (IMLLX) in both the Item Master (F4101/LL CD column) and the Item Branch File (IBLLX- F4102).  Low-level codes are commonly referred to as LLX, IMLLX, IBLLX, or lower level codes.

 

Purpose of BOM Integrity Report

To assign correct low-level codes, run the Bill of Material Structure Analysis program (R30601) with the processing option that is set to consider items in projects. Run the BOM Integrity (R30601) regularly to check for recursive BOMs, missing item branch records and to set low level codes.  Correct any errors.

 

Troubleshooting Integrity Analysis Output and Errors (Doc ID 639397.1)

BOM Integrity Performance (Doc ID 625986.1)

 

How to run BOM Integrity Report

Set all low level codes (LLX) to 0.  The file must be backed up, and the R30601 must  be run after setting to zeros.  This process is necessary as the Low Level Codes for an item (LLX) may have become misaligned between the F4101 and F4102. This process is documented in Low Level Code LLX is Different Between Branch Plants (Doc ID 828438.1).

 

Output from BOM Integrity Report

If all LLXs are correctly set between branches, there is no output from this SQL script.  If the integrity of  LLX is questioned, SQL F4102.IBLLX to '0' and then re-run R30601 followed by the SQL script again.

 

MRP (R3482 or R3483) and LLX

Low level codes provide MRP direction when exploding parent demand down to component demand, across all branch plants. Items which are at top level (Level 0 at BOM) across branches are planned first and each level is planned sequentially. When low level codes are not set up correctly, MRP will not create proper pegging records (P3412) or generate Detailed Messages (P3411).

 

The Low Level Code LLX should never be different between various Branch Plants in the same instance of EnterpriseOne, for details see Low Level Code LLX is Different Between Branch Plants (Doc ID 828438.1).

 

Not having correct low level codes will prevent parallel processing from completing correctly, for details see Parallel Processing for MRP R3482/R3483 (Doc ID 626115.1).

 

PRP and LLX

Project is for ETO, specifically when using Project Requirements Planning (PRP). PRP uses the low-level code to identify the lowest level at which an item resides in a bill of material structure. The low-level code is assigned to an item when the item is added to a manufacturing BOM. An item can reside on a manufacturing BOM, the project work breakdown structure, or both. Because the work breakdown structure is similar to a BOM structure but is not a BOM, the system requires a way to assign an item's low-level code when you use it on a given project.

 

Parallel Processing and LLX

Without parallel processing, MRP reads each record in the F4102 and processes them one by one, according to data selection and low-level code.

 

With parallel processing, multiple items can be processed at the same time.  Items within the same low-level code(LLX) can be planned concurrently, since they do not depend on one another. The master UBE is called, which will in turn submit as many child UBEs as the number entered in the 'Number of Processors' processing option on the Parallel tab of R3482/R3483 minus one. The reason for 'minus one' is that the parent job counts as one of the jobs being Each UBE will submit an entry in the Job Control Status Master table (F986110).

When viewing submitted jobs, note the Parent + Child Subsystem UBEs.  Each of these UBEs will write to, process and delete records from the Subsystem Job Master table (F986113).

Filter Blog

By date: By tag:

Welcome to the My Oracle Support Community! We highly encourage you to personalize your community display name to make your activity more memorable. Please see https://community.oracle.com/docs/DOC-1022508 for instructions.