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 Be
Reviewed 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 been
run in several years. They note they have millions of records in the following tables some of which is very old and
some 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 final
solution 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 the
Planing 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 to
purge all the individual forecasts before purging the Forecast Set itself. These are setup by organization so be sure to
check all organizations.
B. Purge all old MDS/MPS/MRP/DRP plans - this can be done in the appropriate names form for each type under
Material Planner responsibility (eg Material Planner/MRP/Names). These are also organization specific so be sure to
check all organizations
2. Just because the planning manager is down, doesn't mean there aren't table filling up with data.
23/6/2014 Document Display
https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=scvi9bre5_9 2/6
Here are the tables that can continue to grow even though the planning manager is not running over a
period 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.1
and it's a good one to review as part of this note. Basically since the Planning Manager has been down and if you input
sales orders into the Order Management module, then data is just filling up in this table and not being processed. The
Planning Manager processes records in this table that have process_status = 2 (ie Pending). So when it's down this
table can grow quite large. This table is only purged when records are in process_status = 5 (ie successful) after two
days. You can check this table with the following sql:
select count(*), process_status
from 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 closed
in Order Management, so it does not make sense to process this data with the Planning Manager and fill up the table
MRP_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 a
lot of old data. There is no automatic purging process for this table like there is for other MRP tables. More than likely
there are a million or more records in this table that are for old/closed sales orders. So is there a way to clean up
both 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 should
show 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 +======================================================================+
REM
REM FILENAME
REM MRPCLNUP.sql
REM
REM PURPOSE
REM This file is to clean up the incorrect mrp tables when
REM upgrading from 10.7/11.0 to 11i. It also cleans up the
REM forecast consumption data to avoid double consumption
REM by Planning Manager.
REM --------------------------------------------------------------------------+
23/6/2014 Document Display
https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=scvi9bre5_9 3/6
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 : '
DECLARE
l_dynamic_alter_sql VARCHAR2(2000);
BEGIN
l_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, -1
from oe_order_lines_all dem,
mtl_system_items sys, mtl_parameters param
where param.calendar_code IS NOT NULL
AND param.calendar_exception_set_id IS NOT NULL
AND param.organization_id = dem.ship_from_org_id
AND dem.SOLD_TO_ORG_ID IS NOT NULL
AND dem.SHIP_TO_ORG_ID IS NOT NULL
AND dem.INVOICE_TO_ORG_ID IS NOT NULL
AND dem.inventory_item_id = sys.inventory_item_id
and dem.ship_from_org_id = sys.organization_id
23/6/2014 Document Display
https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=scvi9bre5_9 4/6
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 query
WHERE query.query_id = dem.line_id));
DELETE mrp_forecast_updates
WHERE (organization_id,forecast_designator) IN
(SELECT set1.organization_id, set1.forecast_designator
FROM mrp_forecast_designators set1
WHERE (set1.organization_id,
NVL(set1.forecast_set,set1.forecast_designator) ) IN (
SELECT sets.organization_id, sets.forecast_designator
FROM mrp_forecast_designators sets
WHERE sets.forecast_set IS NULL
AND sets.consume_forecast = 1
AND NVL(sets.disable_date, sysdate + 1) > sysdate )
AND NVL(set1.disable_date, sysdate + 1) > sysdate);
DELETE mrp_forecast_dates
WHERE (organization_id,forecast_designator) IN (
SELECT sets.organization_id, sets.forecast_designator
FROM mrp_forecast_designators sets
WHERE sets.forecast_set IS NULL
AND sets.consume_forecast = 1
AND NVL(sets.disable_date, sysdate + 1) > sysdate);
DELETE mrp_forecast_items
WHERE (organization_id,forecast_designator) IN (
SELECT sets.organization_id, sets.forecast_designator
FROM mrp_forecast_designators sets
WHERE sets.forecast_set IS NULL
AND sets.consume_forecast = 1
AND NVL(sets.disable_date, sysdate + 1) > sysdate);
UPDATE mrp_forecast_dates
SET current_forecast_quantity = original_forecast_quantity
WHERE (organization_id,forecast_designator) IN
(SELECT set1.organization_id, set1.forecast_designator
FROM mrp_forecast_designators set1
WHERE (set1.organization_id, set1.forecast_set) IN (
SELECT sets.organization_id, sets.forecast_designator
FROM mrp_forecast_designators sets
WHERE sets.forecast_set IS NULL
AND sets.consume_forecast = 1
AND 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
23/6/2014 Document Display
https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=scvi9bre5_9 5/6
forecast tables as they should be empty. The real key in this sql is what it does for tables MRP_SO_LINES_TEMP and
MRP_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 Days
into 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 to
take into account all sales orders lines with visible_demand_flag = Y (Yes) that have a schedule ship date greater than
SYSDATE - <Number of Days Specified in the profile option>. So if you set the profile option to 60 days and run the
MRPCLNUP.sql, the sales orders that are going to be reinserted into table MRP_SO_LINES_TEMP are those with
visible_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. Once
the Planning Manager is turned on, it will then process the rows in table MRP_SO_LINES_TEMP down to table
MRP_SALES_ORDER_UPDATES.
4. Table MRP_RELIEF_INTERFACE - Records in this table are only processed by the Planning Manager in this table
based 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 the
MRP_RELIEF_INTERFACE table will never be processed by the Planning Manager and will remain in this table with
process_status = 2 even if the Planning Manager is running. These types of records are usually supplies like WIP
Discrete 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 the
MRP_RELIEF_INTERFACE table will never be processed by the Planning Manager and will remain in this table with
process_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 so
weekly or monthly. This is a capability along with a relief setting in the Plan Options for an MDS/MPS/MRP/DRP plan
that show the users what has happened from a relief standpoint since the plan was last run. However most users now
run plans on a daily basis so these profiles can be set to No. With the profiles set to No, this leaves the records in
process_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 then
help is needed from support to get the table down to a reasonable level of data to be processed by the Planning
Manager once it's turned back on. A script to check this table would be the following:
select count(*), relief_type, process_status
from 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 to
work with, there still could be a lot of work for it to perform. There's a couple of profile options that
need to be reviewed:
A. MRP:Planning Manager Batch Size - The default value is 250 so this means it will only process 250 rows at one
time and keep pinging the database to continue processing. This can lead to I/O (input/output) performance problems
when turning the Planning Manager back on. If you will still have a lot of records to process after cleaing up, look at
setting this profile to something like 20,000 or 40,000 to avoid I/O performance issues. It can be set back to a lower
value 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
23/6/2014 Document Display
https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=scvi9bre5_9 6/6
higher should be fine) - See Note 353025.1 (Release 11i only) for a sql to check your current patching level), we've
seen many issues by having the Planning Manager spawn workers to process data in the different tables. The planning
manager is perfectly capabile of doing all the work by itself without the need to spawn workers, so look at setting this
profile 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 PRODUCTION
environment. If there are any questions, log a Service Request with MRP support.
REFERENCES
NOTE:353025.1 - High Priority Patches for MRP Release 11i and R12
NOTE:414544.1 - Sales Orders to MRP Data Flow Diagram