https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doc...

Common MRP Issues - A Review [ID 461112.1] Modified 19-APR-2012 In this Document Purpose Questions and Answers Scope Details 1.Top-Level Assemblies Or Sub-assemblies Or Phantom Items Not Getting Exploded.(Supplies And Demands Not Getting Calculated) 2.MRP Not Honoring Sourcing Rule Split 3.Newly Added Item To A Discrete Job Is Not Getting Planned.The Component Is Not There In The BOM 4.In Planners Workbench All The Buttons Are Greyed Out 5.Reservations Are Not Considered in MRP 6.Partial Cancellation Of Supplies 7.Requisitions Group By Option In MRP 8.The Dates On The Workbench Is Not Matching With The Discrete Job Dates Once They Are Released 9.Handling Performance Issues In MRP 10.Supplies Not Considered By MRP 11.MPS Relief Not Happening 12.PO In Receiving Is Not Getting Rescheduled 13.Many Planned Orders are created on the same date though the demand dates are different.The planned orders are getting created in future and the demands are delayed 14.Allocation in MRP Type FAQ Status PUBLISHED

Applies to:
Oracle Materials Requirement Planning - Version 11.5.2 to 12.1.3 [Release 11.5 to 12.1] Rate this document Information in this document applies to any platform.

Purpose
The purpose of the document is to handle the functional issues that are related to MRP.The issues that have been listed in the document are the commonly faced issues in MRP and this document describes in detail about and the solution of the issues.

Questions and Answers

Scope

Generic

Details

1.Top-Level Assemblies Or Sub-assemblies Or Phantom Items Not Getting Exploded.(Supplies And Demands Not Getting Calculated)
Please check the following setups a. Check whether the item is set as a buy item under the General Planning Tab under the Organizations Item Window. Navigation: Inventory > Items > Master Items > Organization Items > (T) General Planning

Check the field Make or Buy.Ensure that the component is defined as a make item and not buy item b. Check the profile MRP: Explode Demand Through Phantom Component This profile needs to be set to yes for the phantom items to get exploded. This does not apply for standard items. c. Check if there are any Buy sourcing rule assigned to the items

The easiest way of checking this is buy selecting the planned order for release that has got created for the top assembly or the sub assembly or the phantom in the planners workbench .(Note setting the profile MRP: N Planner Backward Compatibility will create planned order for the phantom item also.)

1 of 8

5/7/2012 11:34 PM

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doc...

Check the field Implement as. If MRP is recommending for a Purchase Requisition then any one of the following could be the reason. The item might have been set as a buy item as discussed earlier or A buy-sourcing rule might have been attached to the item. See the value of the profile MRP: Default Sourcing Assignment Set Navigate to Purchasing > Supply Base > Assign Sourcing Rules Query for the assignment set and the item.See if there is any sourcing rule attached to that item. If yes, see what is the type of sourcing rule. Navigate to Purchasing > Supply Base > Sourcing Rules. Query for the sourcing rule and see the type of sourcing rule.If the sourcing rule is a buy sourcing rule then remove the assignment from the Assignment set and rerun the MRP d. Check if there is an ECO existing on this item

In most of the cases one of the components get missed out from the plan. The most possible reason could be that an ECO might have been made for that item but it might not have been transferred to manufacturing. Or th implementation may be for disabling the item. This may occur due to user mistakes where the item might have been disabled wrongly. e. See if the item is set as planned item Navigation: Inventory > Items > Organization Items > MPS / MRP Planning

Check the field Planning method. It should not be as Not planned as mentioned above.

2.MRP Not Honoring Sourcing Rule Split

Say for example you have a sourcing rule where the split is defined as follows Supplier 1 Rank 1 50 % Supplier 2 Rank 1 50% Taking the case where the item has got a demand of 100 the planned order should get created as follows Planned Order 1 Supplier 1 50 Planned Order 2 Supplier 2 50 But if this is not being seen this could be because of the historical allocation, which MRP decided based on the profile MRP: Cutoff History Days If suppose earlier if the following supplies were made for a demand quantity of 100 Supplier 1 70 Supplier 2 30 When MRP runs it tries to honour the sourcing rule for the entire history.So what it does is as follows for a demand quantity of 100. Supplier 1 30 Supplier 2 70 So if you take net Demand 1 + Demand 2 = 100 + 100 = 200 Supply 1 + Supply 2 on supplier 1 = 70 + 30 = 100 Supply 1 + Supply 2 on supplier 2 = 30 + 70 = 100 Which satisfies the sourcing rule split of 50 % and 50 % This is based on the profile MRP: Cutoff History Days.If this profile is set to 100 then for the last 100 days of history MRP will try to honour the sourcing rule. So if you want the MRP to honour the sourcing rule always set MRP: Cutoff History Days to 0. Please check the following note for more information Note.309425.1 MRP Is Not Honoring Allocation Percentages In Sourcing Rule Note : The profile option works only for history.If there are any open PRs and POs then the planned orders created will consider the open POs and PRs as well.

For example : If in the case as above if there is an open PO with supplier 1 that already contributes to 100 numbers and if there is a fresh demand for 200 numbers MRP will create two planned orders with 40 for Supplier 1 and 60 for s

2 of 8

5/7/2012 11:34 PM

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doc...

So the net supplier 1 quantity will be 140 and supplier 2 will be 60 which is equal to 70% and 30%

3.Newly Added Item To A Discrete Job Is Not Getting Planned.The Component Is Not There In The BOM
Cause: The plan might have been launched with the option Demand Schedule Items Navigation: Material Planning > MRP > Options

Solution: The plan needs to be launched with All planned items and it should not be set as Demand Schedule Items as mentioned above. Explanation:

When the plan is launched with Demand Schedule Items during the snapshot process only the items that are there in the demand schedule MDS and their components gets snapshotted which happens only at the BOM leve the added component is not available in BOM it would not have been snapshotted. So when the plan is run with all planned items all the items, which are planned in that organization will get planned.

4.In Planners Workbench All The Buttons Are Greyed Out

1.Cause: The calendar might have been rebuilt. Solution: Relaunch the MRP Explanation: When the calendar is rebuilt the following happens. 1. First it obtains the starting and ending date of the calendar .

2. Checks if the date range given in calendar covers the current dates in mrp_forecast_dates and mrp_schedule_dates. Otherwise, it will not complete the calendar build and will error out and log file will indicate the rea Invalid schedules or Invalid forecast accordingly. 3. Then we update the schedule_work_date in mrp_schedule_dates to next valid working date for MPS or prev. valid working date for an MDS. 4. Similarly it sets valid dates for forecasts too based on the bucket type (daily, weekly,monthly). 5. Then it updates your snapshot , plan completion dates to NULL. This is the reason, everything is greyed out . It is logical , since when the calendar is changed , the work dates available in mrp_schedule_date, mrp_forecast_dates may not be valid and cannot be used and have to be reset to a valid work date. Once this is set , it means that , we need to relaunch MRP to see the changes . We cannot just update the tables alone and leave the rest of the MRP with OLD data . It will be inconsistent. Hence the reason of setting the completion dates to NULL. This will ensure that plan has to be relaunched to see the new changes. 2.Cause The associated MDS was purged after the plan is run Solution Create a new MDS attach it to the plan and relaunch the plan

5.Reservations Are Not Considered in MRP

MRP considers only hard reservations. It will not consider any soft reservations or supply order reservations. A hard reservation is basically a reservation that is made against a Sales Order with an on-hand quantity. Example of Soft reservation is reserving a quantity on-hand against a sub-inventory. Supply order reservation is nothing but a reservation made against a supply. For example reserving a sales order against a discrete job.

So the normal expectations when a reservation is made is, after running MRP the reserved quantity should not be considered by the MRP for meeting other demands. But MRP uses the reserved quantity to meet any dem unless the reservation is made against a sales order with an on-hand quantity.

This is how reservations work. If a hard reservation is placed on material in inventory then that material will not be considered as supply to fulfill further demand. If you do not choose net reservations, the planning process recognizes all salesorder demand as soft reservations only. The planning process always plans to satisfy hard reservations before soft reservations. By definition, sales order demand is a soft reservation. A hard reservatio sales order demand that you firm by reserving selected inventory for the purposes of material planning, available to promise calculations and customer service issues. As per the above, MRP recognizes reservations again orders only, that too the sales order to which the on-hand is reserved should be present in the MDS.

MRP will ensure that every sales order that has been reserved to on-hand gets satisfied out of the reserved on-hand. For example if you had two sales order demand entries, one for Day 1 for 10 units and the second for 10 units and you had reserved material for the sales order for Day 2. Let's say that you have on-hand of 10 units only. In this scenario MRP will satisfy the demand for the sales order for Day 2 with the on-hand and recom planned order for Day 1 for 10 units. If you set Net Reservations to No then MRP would ignore sales order reservations and in the above scenario use the On-hand to satisfy demand for day 1 and create a planned order for day 2. To find out whether the type of reservation is hard or soft or supply order please run the following sqls select lookup_code,lookup_type,meaning from mfg_lookups where lookup_type = 'MTL_RESERVATION'; The above sql returns the look_up_code and its corresponding meaning. The output is
Lookup_Code Lookup_type Meaning

3 of 8

5/7/2012 11:34 PM

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doc...

Soft Reservation 1 MTL_RESERVATION Hard Reservation 2 MTL_RESERVATION Supply Order Reservation 3 MTL_RESERVATION

With the above values check for the corresponding reservation type for your reservation and see your reservation falls under which category.

6.Partial Cancellation Of Supplies

Consider the following example. Demand Quantity = 100 Existing Supply (Approved Purchase Order) = 100 You have on-hand of 50

So after running MRP the demand quantity of 100 will be satisfied by 50 on-hand and 50 from Purchase Order. Also the recommendation for either reschedule in or reschedule out will also be for only 100 numbers. Expect be like MRP should use 50 on-hand and then suggest 50 to be used from existing PO supply and the remaining quantity of 50 should be cancelled. MRP cannot split supplies. It considers the whole quantity only. It will not s 100 numbers of PO as 50 + 50 suggesting to buy 50 and cancelling the remaining 50.The suggestion will be purely on the entire PO quantity.

7.Requisitions Group By Option In MRP

How requisitions are grouped in MRP?

The profile MRP: Requisition load group by is the one that decides how you want your requisitions to be grouped. Remember this profile has nothing to with your planned order generation. The profile comes into picture on you release the orders from the workbench. The default value of the profile will be set to Vendor.So when the requisitions are released from the workbench the requisitions are grouped by Vendor. Similarly if you set the profile to One Each, each Planned order will be converted to one requisition.

If you set it to Item one requisition will get created for one item no matter whether the vendor is different or not. If you set the profile to All then all the planned orders will get converted into a single requisition no matter if th are different or the vendors are different.

Normally the expectation may arise if the profile is set to One each MRP should create only planned order for every demand. But that will not happen. MRP clubs all the demands that are falling on a single day or based on attribute Fixed days supply and creates planned order and the profile will not play a role in this case.

8.The Dates On The Workbench Is Not Matching With The Discrete Job Dates Once They Are Released
Example: Demand Date 19th September After running MRP you can see that a planned order getting created which has got a date of 18th September Once the planned order is released the start date on the discrete job is not coming as 18th say it is coming as 16th. The expectation is that both the dates should be same the date in MRP as well as in the discrete job. This can happen because of three things. A. The lead time is not rolled up from the routings B. The lead times for the items are manually entered. C. You do not have sufficient time between the demand date and the plan run date.

MRP looks into item attributes to create planned order dates. But when the WIP mass load runs it calculates the lead-time from the routings directly and populates the start date and completion date field in discrete job win

Also MRP has got an option of compressing the supply dates. Say for example you have a lead-time required for an item quantity of 1000 is 5 days. The plan is being launched today and the demand date is today itself. S suggest a planned order on the same date that is today compressing all the 5 days because the MRP basically looks only into demand satisfaction no matter whether the order can be met or not it makes the supply date f the demand date compressing the lag in making the order. But when WIP mass load runs it cannot compress the order and it a schedule based on the routings and populates the start date and completion date that comes out to be 5 days. The following white paper gives a very good explanation on the lead-time calculations and MRP flow. Note:230439.1 - Balancing Demand & Supply: A Brief Guide to MRP logic: An Oracle White Paper Feb 2003

9.Handling Performance Issues In MRP

Foremost thing is to check whether the Gather Schema Statistics has been run frequently or not. Problem with MPS Relief Worker and MDS Relief Worker Either the MPS Relief Worker or MDS Relief Worker is running continuously or more relief workers are spawned. So basically we have to check in the MRP_RELIEF_INTERFACE the statuses of the records. About MRP_RELIEF_INTERFACE MRP_RELIEF_INTERFACE is the table, which is used by the planning manager for performing supply relief and demand relief. Will discuss more in detail about how the supply records gets in their and how they are being processed by the planning manager in later sections. Presently we discuss about the columns relief_type and process_status. Relief_type 1 indicates MDS Relief records Relief_type 2 indicates MPS Relief records

Process_status 2 indicates records are waiting to be processed, 3 indicates records are being considered by the planning manager for process, 4 indicates that the records are errored out and 5 indicates records are successfully processed. So the concern is records with process_status 4.There should not be any record with process_status 4 in this table. If so then the records needs to be resubmitted for processing. Please check the following note to know about resubmitting of records NOTE.103037.1 - Issues with the MRP_RELIEF_INTERFACE TABLE If the following profiles are set to yes then the records will be taken for process by the planning manager. MRP: Consume MDS MRP: Consume MPS And also the relief check box in MDS names window and the MPS names window should have been checked. If the above said profiles are set to No then the records gets into MRP_RELIEF_INTERFACE table but will not be processed by the planning manager.

4 of 8

5/7/2012 11:34 PM

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doc...

Problem with Planning Manager or Planning Manager Once a Day Task worker If the planning manager is running for a longer time then the case mentioned for MPS relief Worker could also be one reason. Check the following profiles a ) MRP: Purge Batch Size Setting this profile to a low or high value will cause performance issues. Default is 75000 b ) MRP: Planning Manager perform function in Loads Set this profile to No c ) MRP: Planning Manager Batch Size A high value will make the planning manager to run for a longer time.Default is 500 which is recommended and it can be set to 1000 max. Problem with Memory Based Snapshot, Snapshot Monitor, Snapshot Workers. Check the following profile MRP: Snapshot Workers. Lets say that the profile has been set to a value of 5. A ) Check the standard manager process defined. Navigation: System Administrator > Concurrent > Manager > Define Query for the standard manager and the click on the work-shifts and check the field Processes.

The basic idea is that this should be set to a value based on the following formula Number of standard Manager processes = 4 + (2 * profile option value). So in the above case it will be 4 + (2*5) = 14. So minimum of 14 processes are required. The recommended setting is 15 to 20 processes. B ) Check the profile Concurrent: Active Request Limit. This setup determines how many requests that can be active at a time. This should also follow the same formula as above and by default the profile is set to Null, which is recommended C) Set the profile Concurrent: Sequential Requests to No D) If you are able to see the following message in the log files LOCKS MTL_MATERIAL_TRANSACTIONS_TEMP TABLE This indicates the fact that the MTL_MATERIAL_TRANSACTIONS_TEMP is locked and the processes are waiting for the lock to get released.This can happen if the plan option Snapshot Lock Tables is checked. Navigation: Material Planning > MRP > Options

If it is checked then uncheck the option and rerun the MRP to see if it completes successfully. E) If everything is fine as mentioned above then it may be a bug which might have been fixed or need a fix so please generate trace and tkprof to find out which is the sql that is causing the issue. To find out the current running sql use the following sql. SELECT r.request_id, sq.sql_text, ss.SID, ss.SERIAL# FROM fnd_concurrent_requests r, v$process p, v$session ss, V$SQLAREA sq WHERE r.request_id IN (&request_id1, &request_id2, ...) AND p.spid = r.oracle_process_id AND ss.paddr = p.addr AND sq.ADDRESS = ss.SQL_ADDRESS; Check the locks on the above objects, which the requests are accessing at the moment and see if removing locks is making the plan to complete successful. F) In some cases the following sql may be the one that is causing the issue. DECLARE ret_code NUMBER := 0; snp_exception EXCEPTION;

5 of 8

5/7/2012 11:34 PM

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doc...

snp_timed_out EXCEPTION; BEGIN ret_code := dbms_pipe.receive_message(:ipname, 10); IF ret_code = 1 THEN RAISE snp_timed_out; END IF; IF ret_code <> 0 THEN RAISE snp_exception; END IF; dbms_pipe.unpack_message(:opname); dbms_pipe.unpack_message(:request_id); dbms_pipe.unpack_message(:msg_type); dbms_pipe.unpack_message(:file_type); IF dbms_pipe.next_item_type = 9 THEN dbms_pipe.unpack_message(:dat); dbms_pipe.unpack_message(:ctl); dbms_pipe.unpack_message(:dis); dbms_pipe.unpack_message(:bad); END IF; EXCEPTION WHEN snp_timed_out THEN :time_out := 1; WHEN others THEN :err_msg := '( ' || to_char(ret_code) || ') ' || sqlerrm; :err_code := SQLCODE; END; In this case bouncing the database will help. Performance Issue with Memory Based Planner

Remember Memory based planner works in memory and it will not work in sqls.So if the MBP is running for a longer time then taking a trace on that will never help to identify the cause.So taking a trace on MBP is not r It may be due to huge amount of data which is the first reason to be suspected.Some setups which can cause the MBP to run for a longer time. 1.Launching the plan with All Planned Items 2.Launching a supply chain plan with more organizations 3.Launching with Pegging turned on

So check if launching the plan with demand schedule items only is making the plan to complete faster. If supply chain plan, then reduce the number of organizations and break the existing plan into 2 or more plans. Disab pegging for all non-critical items. These are generic recommendations, which can be tried to see if the issue is happening because of volume of data or some other thing

10.Supplies Not Considered By MRP

MTL_SUPPLY table and trigger MTL_SUPPLY_T The following are the supplies that will be considered by MTL_SUPPLY. Purchase Orders, Purchase Requisitions, Items in receiving and items in in-transit shipments. The following are the valid supply type codes that can exist in mtl_supply

S.NO 1 2 3 4 PO

SUPPLY_TYPE_CODE

MEANING Purchase Order In-Transit Shipment Items In Receiving Requisition

SHIPMENT RECEIVING REQ

MRP considers the WIP supply from WIP discrete jobs directly. In MTL_SUPPLY we can find two types of columns one starting with MRP like MRP_PRIMARY_QUANTITY, MRP_PRIMARY_UOM and others do not starting with MRP like TO_ORG_PRIMARY_QUANTITY TO_ORG_PRIMARY_UOM Flow of records:

Purchase Orders, Purchase Requisitions, Items in receiving and items in in-transit shipments from PO module gets into mtl_supply and the columns that does not get started with MRP gets populated. Once the records get inserted into mtl_supply the trigger mtl_supply_t on the table mtl_supply gets triggered and the records gets inserted into mrp_relief_interface with process_status 2. The planning manager process records from mrp_relief_interface and then repopulates the records into MRP columns of the mtl_supply. The records, which have their MRP columns populated, will be the only records that will be considered by the planni the issue is that the supplies are not being considered by the MRP firstly the MRP_* columns might not have been populated.Check the following. a).Planning Manager should be active Navigation: Material Planning > Setup > Planning Manager

The active check box should have been checked as above. If not start the planning manager by clicking on the start button and wait till the planning manager is completing one cycle. If the planning manager is already activ it is successfully completing its cycles and it is not erroring out. b).The MTL_SUPPLY_T trigger should have been enabled

6 of 8

5/7/2012 11:34 PM

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doc...

Run the following sql to ensure this select status from all_triggers where trigger_name = 'MTL_SUPPLY_T'; c).Check if the profile MRP:Consume MPS is set to Yes If it is set to No then the planning manager will not process these records though they get into MRP_RELIEF_INTERFACE d).Check the records are not erroring out in MRP_RELIEF_INTERFACE

If either the planning manager is not active or the trigger is disabled and even after correcting the records are not considered by MRP then just resubmit the PO for approval by changing the need by date or quantity and is considered by MRP More details can be found in the following note NOTE.1017409.102Worksheet - Verification Of Purchasing Supply To MRP e).Check if the plan option Net Purchases is checked Navigation: Material Planning > MRP > Options

WIP_DISCRETE_JOBS The above section deals on PO supply. If the WIP supplies are not considered by MRP then check the following a).The plan option Net WIP should be checked Navigation: Material Planning > MRP > Options

b).The profile MRP: Consume MPS should be set to Yes and the planning manager should be active c).The following triggers should have been enabled WIP_DISCRETE_JOBS_BRI WIP_DISCRETE_JOBS_BRU WIP_DISCRETE_JOBS_BRD Run the following sql to check this select status from all_triggers where trigger_name in ('WIP_DISCRETE_JOBS_BRI','WIP_DISCRETE_JOBS_BRU', 'WIP_DISCRETE_JOBS_BRD');

This are the triggers that populate the discrete job supplies into MRP_RELIEF_INTERFACE.The planning manager processes those records and updates the column MPS_NET_QUANTITY in WIP_DISCRETE_JOBS w the column that will be looked by MRP for considering the supply. d).Check the MRP Net quantity field in Discrete Jobs Window

The MRP Net quantity field in WIP Discrete JOBS Window is the quantity that will be looked up by the planning. Even if the start quantity is 100 if you have specified the MRP Net quantity to 0 no supplies from that disc will be considered by MRP. For more information refer to the following Note NOTE.101079.1 - Verifying Discrete WIP Supply to MRP

11.MPS Relief Not Happening

a).Check if the relief check box is checked in MPS Names window Navigation: Material Planning > MPS > Names

7 of 8

5/7/2012 11:34 PM

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doc...

b).Check if the planning manager is active Have explained this in previous sections c).Check if the triggers MTL_SUPPLY_T, WIP_DISCRETE_JOBS_BRI, WIP_DISCRETE_JOBS_BRU, WIP_DISCRETE_JOBS_BRD are enabled. select status from all_triggers where trigger_name in ('WIP_DISCRETE_JOBS_BRI','WIP_DISCRETE_JOBS_BRU', 'WIP_DISCRETE_JOBS_BRD','MTL_SUPPLY_T'); 4.Check if the records are not struck in MRP_RELIEF_INTERFACE Have explained this in previous sections

12.PO In Receiving Is Not Getting Rescheduled

Example: Demand on day 3 for quantity 100 PO in receipt for quantity 100 After launching the plan the system is suggesting to release a Planned Order for a quantity of 100 numbers instead of rescheduling out the existing PO in receipt

Explanation: This is intended. A PO in receipt is a firmed supply. MRP cannot do give reschedule recommendations on firmed supplies. So the PO in receipt is not getting pegged to the demand on day 3 and a new supply is getting cre Workarounds: This can be worked around in two ways

1.Set the profile MRP:Create Time Fence to Yes Once this profile is set then an automatic planning time fence will get created around the firmed supply.Hence MRP will not create any planned orders inside the time fence ends up in pegging the PO in receipt to the dema Disadvantage: Since the profile is being set this applies for all the items hence you will have the natural time fence getting created for all the items which does have a firmed supply. And also if there is any other demand which actually needs a planned order that also gets delayed due to the time fence

2.Set the Planning time fence of the item equals to the post processing lead time Post processing lead-time is basically the time required after the material is received into dock. After receiving and till the item gets stocked is termed out to be the post processing lead time which involves receiving, inspe So since the planning time fence is set as post processing lead-time the planned orders will not created within the time fence end up in using the supplies PO in receipt Disadvantage: If there is any other demand which actually needs a planned order that also gets delayed due to the time fence

13.Many Planned Orders are created on the same date though the demand dates are different.The planned orders are getting created in future and the demands are delayed
Check if there any supplies for this item that are firmed. (E.g : A firmed Discrete job or a firmed Purchase Order).See if the profile MRP:Create Time Fence is set to Yes.

If both the conditions are satisfied then the problem could be because of the fact that natural time fence getting created.When the profile MRP:Create Time Fence is set to Yes then a time fence gets created around the la supply.Within that supplies won't get created or the supplies can be rescheduled.So all the supplies gets created on the next day after the planning time fence gets over. To avoid this the profile MRP:Create time Fence should be set to No

14.Allocation in MRP

How does allocation happens in MRP ? Does it always goes by Demand Due Date or order priority.For example if we have discrete job demands and planned order demands and also some onhand quantity and if the plan demands are earlier than discrete job demands the onhand gets allocated to which demand ? Can we change this behavior ?

This behavior cannot be changed.MRP always pegs by demand due date.It checks the supply available and the demand due date and start allocation the supplies to the demands based on the due dates.You cannot hav onhand getting pegged to discrete job demand.

Attachments I1 (24.02 KB) I10 (20.78 KB) I2 (21.11 KB) I3 (19.61 KB) I4 (17.46 KB) I5 (19.49 KB) I6 (10.18 KB) I7 (18.18 KB) I8 (10.57 KB) I9 (10.98 KB)

Related Products More Applications > Value Chain Planning > Supply Chain Planning > Oracle Materials Requirement Planning Keywords INVENTORY ITEMS; MDS; MRP; MRP PLAN; MRP_RELIEF_INTERFACE; PLANNER; SNAPSHOT MONITOR; SOURCING RULE

Back to top Copyright (c) 2007, 2010, Oracle. All rights reserved. Legal Notices and Terms of Use | Privacy Statement

8 of 8

5/7/2012 11:34 PM