mrp clean up before starting planning manager

23/6/2014 Document Display

https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=scvi9bre5_9 1/6

MRCRLF - Planning Manager Has Been Down For 3 Years - What Considerations Need To BeReviewed Before Turning It Back On? (Doc ID 1116155.1)

Modified: 20-May-2013 Type: HOWTO

In this Document

Goal

Solution

References

APPLIES TO:

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

Executable:MRCRLF - Planning Manager

GOAL

Users have concerns about old MRP data that exists in the tables since the Planning Manager - MRCRLF has not beenrun in several years. They note they have millions of records in the following tables some of which is very old andsome which is new. The following tables are under consideration:

MRP_SALES_ORDER_UPDATES MRP_RELIEF_INTERFACE MRP_FORECAST_DATES MRP_FORECAST_UPDATES MRP_SO_LINES_TEMP

Can we purge the old data from these tables and start running Planning Manager?

SOLUTION

More thank likely, you'll need to open a service request with MRP support to obtain help with your finalsolution as different users are performing different functions in MRP. Here are the considerations:

1. You need to purge all of the following that are applicable to your business requirements before thePlaning Manager was turned off. This will help get rid of old unnecessary data in the tables:

A. All old Forecasts and Forecast Sets - These can be purged from Material Planner/Forecast/Sets. You need topurge all the individual forecasts before purging the Forecast Set itself. These are setup by organization so be sure tocheck all organizations.

B. Purge all old MDS/MPS/MRP/DRP plans - this can be done in the appropriate names form for each type underMaterial Planner responsibility (eg Material Planner/MRP/Names). These are also organization specific so be sure tocheck all organizations

2. Just because the planning manager is down, doesn't mean there aren't table filling up with data.



Here are the tables that can continue to grow even though the planning manager is not running over aperiod of time:

A. MRP_SO_LINES_TEMP

B. MRP_RELIEF_INTERFACE

We will discuss these individually.

3. Table MRP_SO_LINES_TEMP - There is a good flow diagram of how sales orders flow to MRP in Note 414544.1and it's a good one to review as part of this note. Basically since the Planning Manager has been down and if you inputsales orders into the Order Management module, then data is just filling up in this table and not being processed. ThePlanning Manager processes records in this table that have process_status = 2 (ie Pending). So when it's down thistable can grow quite large. This table is only purged when records are in process_status = 5 (ie successful) after twodays. You can check this table with the following sql:

select count(*), process_statusfrom mrp_so_lines_temp

group by process_status;

Since these have never been processed, chances are 90% or more of these sales order lines have already been closedin Order Management, so it does not make sense to process this data with the Planning Manager and fill up the tableMRP_SALES_ORDER_UPDATES with unnecessary sales order data.

You'll also note that table MRP_SALES_ORDER_UPDATES, while not growing since the Planning Manager is down, has alot of old data. There is no automatic purging process for this table like there is for other MRP tables. More than likelythere are a million or more records in this table that are for old/closed sales orders. So is there a way to clean upboth MRP_SO_LINES_TEMP and MRP_SALES_ORDER_UPDATES as the same time?

Yes. Located in directory $MRP_TOP/patch/115/sql is a file called MRPCLNUP.sql - If you open up this file it shouldshow the following:

REM $Header: MRPCLNUP.sql 115.6 2004/04/13 02:19:35 skanta noship $

REM dbdrv: none

REM +======================================================================+REM | Copyright (c) 1998 Oracle Corporation |REM | |REM | Redwood Shores, California, USA |REM | |REM | All rights reserved. |REM | |REM +======================================================================+REMREM FILENAMEREM MRPCLNUP.sqlREMREM PURPOSEREM This file is to clean up the incorrect mrp tables whenREM upgrading from 10.7/11.0 to 11i. It also cleans up the REM forecast consumption data to avoid double consumptionREM by Planning Manager.REM --------------------------------------------------------------------------+



WHENEVER SQLERROR CONTINUE;

DROP TABLE mrp_sales_order_updates_old;DROP SYNONYM mrp_sales_order_updates_old;CREATE TABLE mrp_sales_order_updates_old AS(SELECT * FROM mrp_sales_order_updates);

DROP TABLE mrp_so_lines_temp_old ;DROP SYNONYM mrp_so_lines_temp_old;CREATE TABLE mrp_so_lines_temp_old AS(SELECT * FROM mrp_so_lines_temp);

DROP TABLE mrp_forecast_designators_old; DROP SYNONYM mrp_forecast_designators_old;CREATE TABLE mrp_forecast_designators_old AS(SELECT * FROM mrp_forecast_designators);

DROP TABLE mrp_forecast_dates_old ;DROP SYNONYM mrp_forecast_dates_old;CREATE TABLE mrp_forecast_dates_old AS(SELECT * FROM mrp_forecast_dates);

DROP TABLE mrp_forecast_items_old; DROP SYNONYM mrp_forecast_items_old;CREATE TABLE mrp_forecast_items_old AS(SELECT * FROM mrp_forecast_items);

DROP TABLE mrp_forecast_updates_old; DROP SYNONYM mrp_forecast_updates_old;CREATE TABLE mrp_forecast_updates_old AS(SELECT * FROM mrp_forecast_updates);

WHENEVER SQLERROR EXIT FAILURE ROLLBACK;accept mrp_schema_name prompt 'Enter MRP Schema Name : 'DECLAREl_dynamic_alter_sql VARCHAR2(2000);

BEGINl_dynamic_alter_sql := 'TRUNCATE TABLE '||'&mrp_schema_name'||'.mrp_sales_order_updates';EXECUTE IMMEDIATE l_dynamic_alter_sql;

l_dynamic_alter_sql := 'TRUNCATE TABLE '||'&mrp_schema_name'||'.mrp_so_lines_temp';EXECUTE IMMEDIATE l_dynamic_alter_sql;

INSERT INTO mrp_so_lines_temp(line_id, process_status, created_by, creation_date,last_updated_by, last_update_date, last_update_login)(select dem.line_id, 2, -1, sysdate, -1, sysdate, -1from oe_order_lines_all dem,mtl_system_items sys, mtl_parameters paramwhere param.calendar_code IS NOT NULLAND param.calendar_exception_set_id IS NOT NULLAND param.organization_id = dem.ship_from_org_idAND dem.SOLD_TO_ORG_ID IS NOT NULLAND dem.SHIP_TO_ORG_ID IS NOT NULLAND dem.INVOICE_TO_ORG_ID IS NOT NULLAND dem.inventory_item_id = sys.inventory_item_idand dem.ship_from_org_id = sys.organization_id



and DECODE(DECODE(visible_demand_flag,'Y',DECODE(sys.pick_components_flag, 'N',1,2),2),1,'Y','N') = 'Y'and nvl(dem.cancelled_flag,'N') = 'N'and dem.schedule_ship_date >=sysdate - nvl(fnd_profile.value('MRP_OLD_SO_CUTOFF_DAYS'),9999)and not exists(select 'x'FROM MSC_FORM_QUERY queryWHERE query.query_id = dem.line_id));

DELETE mrp_forecast_updatesWHERE (organization_id,forecast_designator) IN(SELECT set1.organization_id, set1.forecast_designatorFROM mrp_forecast_designators set1WHERE (set1.organization_id, NVL(set1.forecast_set,set1.forecast_designator) ) IN (SELECT sets.organization_id, sets.forecast_designatorFROM mrp_forecast_designators setsWHERE sets.forecast_set IS NULLAND sets.consume_forecast = 1AND NVL(sets.disable_date, sysdate + 1) > sysdate )AND NVL(set1.disable_date, sysdate + 1) > sysdate);

DELETE mrp_forecast_datesWHERE (organization_id,forecast_designator) IN (SELECT sets.organization_id, sets.forecast_designatorFROM mrp_forecast_designators setsWHERE sets.forecast_set IS NULLAND sets.consume_forecast = 1AND NVL(sets.disable_date, sysdate + 1) > sysdate);

DELETE mrp_forecast_itemsWHERE (organization_id,forecast_designator) IN (SELECT sets.organization_id, sets.forecast_designatorFROM mrp_forecast_designators setsWHERE sets.forecast_set IS NULLAND sets.consume_forecast = 1AND NVL(sets.disable_date, sysdate + 1) > sysdate);

UPDATE mrp_forecast_datesSET current_forecast_quantity = original_forecast_quantityWHERE (organization_id,forecast_designator) IN(SELECT set1.organization_id, set1.forecast_designatorFROM mrp_forecast_designators set1WHERE (set1.organization_id, set1.forecast_set) IN (SELECT sets.organization_id, sets.forecast_designatorFROM mrp_forecast_designators setsWHERE sets.forecast_set IS NULLAND sets.consume_forecast = 1AND NVL(sets.disable_date, sysdate + 1) > sysdate )AND NVL(set1.disable_date, sysdate + 1) > sysdate);

END;/COMMIT;

exit;

Because you've already purged old Forecast/Forecast Sets there should not be much work needing to be done in the



forecast tables as they should be empty. The real key in this sql is what it does for tables MRP_SO_LINES_TEMP andMRP_SALES_ORDER_UPDATES.

The real key to running this script is the fact that it takes the value of profile option MRP: Old Sales Order Cutoff Daysinto consideration.

A. The above script will first truncate the above two tables.

B. Then it will repopulate the table MRP_SO_LINES_TEMP based on the setting of the profile. It's going totake into account all sales orders lines with visible_demand_flag = Y (Yes) that have a schedule ship date greater thanSYSDATE - <Number of Days Specified in the profile option>. So if you set the profile option to 60 days and run theMRPCLNUP.sql, the sales orders that are going to be reinserted into table MRP_SO_LINES_TEMP are those withvisible_demand_flag = Y in table OE_ORDER_LINES_ALL and the schedule_date greater than SYSDATE - 60 days.

So you want to set this profile correctly based on your business need before running the MRPCLNUP.sql script. Oncethe Planning Manager is turned on, it will then process the rows in table MRP_SO_LINES_TEMP down to tableMRP_SALES_ORDER_UPDATES.

4. Table MRP_RELIEF_INTERFACE - Records in this table are only processed by the Planning Manager in this tablebased on the settings of two profile options:

A. MRP:Consume MPS - Yes/No - If the profile is set to No, then records with relief_type = 2 (MPS Relief) in theMRP_RELIEF_INTERFACE table will never be processed by the Planning Manager and will remain in this table withprocess_status = 2 even if the Planning Manager is running. These types of records are usually supplies like WIPDiscrete Jobs, Purchase Orders, etc.,...

B. MRP:Consume MDS - Yes/No - If the profile is set to No, then records with relief_type = 1 (MDS Relief) in theMRP_RELIEF_INTERFACE table will never be processed by the Planning Manager and will remain in this table withprocess_status = 2 even if the Planning Manager is running. An example of this type would be a sales order shipment.

The only reason users would need to set these profiles = Yes is if they run MDS/MPS/MRP/DRP Plans but only do soweekly or monthly. This is a capability along with a relief setting in the Plan Options for an MDS/MPS/MRP/DRP planthat show the users what has happened from a relief standpoint since the plan was last run. However most users nowrun plans on a daily basis so these profiles can be set to No. With the profiles set to No, this leaves the records inprocess_status = 2 in the MRP_RELIEF_INTERFACE table and they need to be truncated manually from time to time.

It is best that this table is truncated before turning on the Planning Manager but if you need the profiles set to Yes thenhelp is needed from support to get the table down to a reasonable level of data to be processed by the PlanningManager once it's turned back on. A script to check this table would be the following:

select count(*), relief_type, process_statusfrom mrp_relief_interface

group by relief_type, process_status;

5. Even with all the data cleaned up to what is considered reasonable levels for the planning manager towork with, there still could be a lot of work for it to perform. There's a couple of profile options thatneed to be reviewed:

A. MRP:Planning Manager Batch Size - The default value is 250 so this means it will only process 250 rows at onetime and keep pinging the database to continue processing. This can lead to I/O (input/output) performance problemswhen turning the Planning Manager back on. If you will still have a lot of records to process after cleaing up, look atsetting this profile to something like 20,000 or 40,000 to avoid I/O performance issues. It can be set back to a lowervalue once the Planning Manager finishes all the work.

B. MRP:Planning Manager Max Workers - Unless you are on MRP RUP#17 patch or higher (11.5.10 only - R12 and



higher should be fine) - See Note 353025.1 (Release 11i only) for a sql to check your current patching level), we'veseen many issues by having the Planning Manager spawn workers to process data in the different tables. The planningmanager is perfectly capabile of doing all the work by itself without the need to spawn workers, so look at setting thisprofile to 0 so it does not launch any workers. For users on higher patching/applications versions, setting this profile to

a value of 3 - 5 should be okay.

6. Make sure to test out all issues thoroughly in a TEST instance first before migrating to a PRODUCTIONenvironment. If there are any questions, log a Service Request with MRP support.

REFERENCES

NOTE:353025.1 - High Priority Patches for MRP Release 11i and R12NOTE:414544.1 - Sales Orders to MRP Data Flow Diagram

https://support.oracle.com/epmos/faces/DocumentDisplay?id=353025.1

https://support.oracle.com/epmos/faces/DocumentDisplay?id=414544.1

mrp clean up before starting planning manager

Documents