You are on page 1of 9

Planning Manager Technical Workshop

Marc Slone Oracle Corporation Introduction
The Planning Manager is a concurrent program in Oracle Master Scheduling/MRP which performs several tasks, including shipment relief of master demand schedules, production relief of master production schedules, forecast consumption, and the MRP open interface routines. This paper will discuss the technical aspects of the tasks addressed by the Planning Manager and the common support issues encountered. In addition, the Target Processes for the MRP Manager should be set to 1. Since the only program that runs under this manager is the Planning Manager, and only one Planning Manager can run at the same time, then there is no need to have more than one MRCLIB process running. Planning Manager The Planning Manager is an immediate concurrent program which runs under the MRP concurrent manager. The short name for the Planning Manager concurrent program is MRCRLF. Note that you will not find an executable in the MRP executable directory called MRCRLF. Since the Planning Manager is an immediate concurrent program, it is run as a subroutine of its concurrent manager, in this case MRCLIB. Therefore the executable file associated with the Planning Manager is MRCLIB. In addition to the executable code, the Planning Manager uses database stored procedures and functions to perform much of its work. These are the database code objects used by the Planning Manager: • • • MRP_MANAGER_PK is a package of procedures and functions used by the Planning Manager to perform various tasks. MRP_UPDATE_MRP_COLS is a procedure used during the MPS relief process. MRP_AUTO_REDUCE_MPS is a procedure used during the daily cleanup process.

Note: This document is intended to be used as a reference document. Certain sections of text are intentionally repeated throughout the document, so that each section can be read and understood independently of one another.

MRP Manager (MRCLIB) and Planning Manager (MRCRLF)
Do not confuse the MRP Manager with the Planning Manager. The MRP Manager is a concurrent manager, while the Planning Manager is an immediate concurrent program which runs under the control of the MRP Manager. MRP Manager The MRP Manager is a concurrent manager which uses the Program Library MRCLIB. The MRP Manager is used solely to run the Planning Manager. That is, the concurrent manager should have exactly one specialization rule, and that rule should Allow execution of the Planning Manager program. If you install Oracle Master Scheduling/MRP, the AutoInstall process will automatically create a concurrent manager with this setup. Do NOT modify this manager to run all MRP-related concurrent programs. All MRP programs except the Planning Manager run under the Standard concurrent manager or an equivalent manager that uses FNDLIBR as its program library.

We will discuss these procedures as appropriate throughout the text of this paper. Starting the Planning Manager Use the Start Planning Manager form to start the Planning Manager.

(character: \ Navigate Setup PlanningManager)

Also. checks to see if there is any work to do. The 10SC Start Planning Manager form When starting the Planning Manager. the planning manager log file will be over 11 MB each day. you are assured that your Planning Manager will run virtually on a continuous basis. If MRP:Debug Mode is set to Yes or the Planning Manager cycle completes in less time than the example. the log file will be even larger. let’s say your entire Planning Manager cycle takes five minutes to complete. and goes back to sleep. If the Planning Manager cycle actually takes a longer period of time to run than the time . Some SQL statements which MRP prints in the log file have been removed from the example file for brevity. Important note: the resubmission time of the next Planning Manager run is calculated from the start time of the previous request rather than the end time. The character-mode Start Planning Manager form (10SC: Setup. that means the Planning Manager will run approximately 1440 (24 hr * 60 min/hr) times during the course of the day. for example 30 seconds. Planning Manager) From a system administrator’s point of view. you must specify a Processing Interval to use. exactly one hour from the start time of the previous request. The Planning Manager will spawn a new request id each day. If a Planning Manager request starts at 9:00 AM. until the next request is submitted. With these parameters. this log file may grow quite large over the course of a day. assume that during each cycle the planning manager produces 8 KB of log file information. the Planning Manager presents one important consideration. The next request will be submitted at 10:00 AM. assume that one planning manager cycle completes in less than 60 seconds. This request id will be reused by each subsequent Planning Manager run until the next calendar day. This is the amount of time after one Planning Manager request starts.specified by the processing interval. For example. then the next request will be submitted exactly one processing interval after the end of the previous request. and your processing interval is set to one hour. Figure 1. the Planning Manager wakes up every 60 seconds. Assuming a 24 hour work shift for the MRP Manager. does the work. the form will give you the concurrent request id of the Planning Manager concurrent request. When you start the Planning Manager. The log file for the Planning Manager will contain information about each task it performs. For an example of a Planning Manager log file. as an approximation. If you have the Planning Manager set up with a processing interval of 30 seconds. This is an actual log file from one complete cycle of the Planning Manager. let’s say the Planning Manager is set up with a 60 second processing interval. and MRP:Debug Mode is set to No. see Appendix A. The factors which affect the size of the log file are the processing interval and the setting of the profile option MRP:Debug Mode (discussed later). If you specify a short processing interval. During the course of a day. Figure 2. then it will complete at 9:05 AM. As an example. In addition.

then users may have to wait as long as 10 minutes to insure that they are seeing an updated picture of their forecasts and master schedules. You will need to perform steps 1. See figures 1 and 2 to see an example of this message in the Messages zone. The executable associated with this concurrent program is MRCSCW. 2. Attempt to start the planning manager using the procedure described in the above section. You can find the request id of the spawned once-a-day-tasks worker by looking in the Planning Manager log file: . that does not necessarily mean that the Planning Manager is running. 4. At the operating system level.How can I tell if my Planning Manager is active? There are several ways to find out information about the current status of the Planning Manager. For example. issue the following command to check for a running MRCLIB process: $ ps -ef | grep MRCLIB If this does not show any MRCLIB processes. check for processes associated with the MRCLIB executable. when you start the Planning Manager. Using the System Administrator responsibility. 3 or 4. How do I choose a processing interval? A longer processing interval simply means that users may have to wait longer to see forecast consumption. master schedule relief. then the Planning Manager is active. each day when a new Planning Manager request id is generated. an additional once-aday-tasks-worker is spawned. Planning Manager Tasks The Planning Manager performs several tasks critical to the operation of Oracle Master Scheduling/MRP: • • • • • • Miscellaneous Cleanup Tasks MDS Relief MPS Relief Forecast Consumption Forecast Open Interface Master Schedule Open Interface We will now address the technical aspects of each of these tasks in detail. you should wait for the Planning Manager to get to a status of Pending. only that the MRP Manager is running. 3. The Messages zone of the Start Planning Manager form shows the last time that the planning manager started. If you see an MRCLIB process. if you wish to change this interval. if the processing interval is set to 10 minutes. Here are a few suggestions: 1. then the MRP concurrent manager is not running and hence the Planning Manager cannot be running. At this point you can restart the Planning Manager with the desired processing interval. Planning Manager Worker (once-a-day tasks) (MRCSCW1) The once-a-day-tasks worker is launched automatically by the Planning Manager when each Planning Manager request is first launched. etc. Then. from UNIX. then cancel that pending request. on the View Concurrent Requests screen. The Planning Manager Worker (once-a-daytasks) is a concurrent program with short name MRCSCW1. Therefore. a once-a-day-tasks-worker will be spawned. The form will alert you that the Planning Manager is already active if that is the case. A shorter processing interval obviously lessens this time but requires greater system resources. Therefore. query on the program name Planning Manager. If you have a request either Running or Pending. How can I change the processing interval? You cannot change the processing interval for the Planning Manager while it is running or pending. For example.

if you delete a certain item off of master schedules so that it has no entry on any master schedule (these entries are stored in the MRP_SCHEDULE_DATES table). For this example. In addition to the above tables. Dividing Up The Work For each task except the once-a-day-tasks worker. let’s say there are 300 rows which require forecast consumption. As a general rule do not set the number of max workers to a value higher than the number of requests that can run simultaneously in your standard concurrent managers. The Planning Manager Purges MRP Interface Tables The following are seven of the tables which are purged daily by the once-a-day-tasks worker: • • • • • • • MRP_FORECAST_INTERFACE MRP_SCHEDULE_INTERFACE MRP_RELIEF_INTERFACE MRP_FORM_QUERY MRP_WORKBENCH_CRITERIA MRP_WORKBENCH_QUERY MRP_LOAD_PARAMETERS These tables are purged based on the setting of the profile option MRP:Interface Table History Days. When performing a particular task. the once-a-daytasks worker purges records from the following tables where there are no records in the appropriate foreign key table (shown in parenthesis): • • • • • • MRP_SCHEDULE_ITEMS (MRP_SCHEDULE_DATES) MRP_FORECAST_UPDATES (MRP_FORECAST_DATES) MRP_SCHEDULE_CONSUMPTIONS (MRP_SCHEDULE_DATES and MRP_RECOMMENDATIONS) MRP_FORECAST_ITEMS (MRP_FORECAST_DATES) MRP_SCHEDULE_ITEMS (MRP_SCHEDULE_DATES) CRP_BILL_OF_RESOURCE_ITEMS (CRP_RESOURCE_HOURS) . The Planning Manager will continue to spawn more workers until the number of workers running or pending equals the value of this profile option. assume that the batch size is set to 100 and the max workers is set to 5. For example. Then. In addition. the Planning Manager first calculates how many rows in the database require processing. such as forecast consumption. the rows are assigned to individual workers according to the values of the profile options MRP:Planning Manager Batch Size and MRP:Planning Manager Max Workers. The once-a-day-tasks worker deletes all rows from these tables which have a PROCESS_STATUS = 5 (processed successfully) and are older than the number of days specified by this profile option. Oracle Master Scheduling/MRP provides two profile options which govern how the Planning Manager will divide up the rows in need of processing during any given cycle. and (if CRP is installed) CRP_FORM_QUERY which have been in the table for more than two days. A smaller value indicates that any particular worker will have more rows to process. Planning Manager spawns once-a-day-tasks worker For example. The max workers option indicates the maximum number of workers to be launched by the Planning Manager. then the once-a-day-tasks worker removes that item from the list of items on a master schedule (this is the MRP_SCHEDULE_ITEMS table). and will take longer to complete. A larger value here means Planning Manager will be more efficient since fewer workers will be spawned and therefore you will have fewer processes hitting the database. the once-a-day-tasks worker performs automatic MPS relief based on the setting of the item attribute Reduce MPS. This feature is used primarily if you do not have Oracle Work In Process and Oracle Purchasing installed.===================================== CONCURRENT MRP MRCSCW1 "OPERATION=7" Launched concurrent request 6824 for Daily cleanup worker ===================================== Figure 3. MRP_FORM_QUERY. The batch size option indicates the number of rows per worker to process. The once-a-day-tasks worker also deletes records from MRP_MESSAGES_TMP.

PROCESS_STATUS = 2) and will perform MDS Relief for those records. For the Forecast Open Interface.will spawn two Sales Order Consumption workers. when the Transaction Manager recognizes a particular transaction as a sales order shipment. short name MRCSLW. and the Planning Manager itself will process the remaining 100 rows. short name MRCMPW. each to process 100 rows. See the Oracle Master Scheduling/MRP Reference Manual for a functional description of the MDS Relief process. the Planning Manager will spawn Schedule Load Workers. so the Planning Manager spawned two Sales Order Consumption workers. For MDS relief records in the table MRP_RELIEF_INTERFACE. MPS Relief • • • • The executable associated with every one of these workers is MRCSCW. the Planning Manager will spawn Sales Order Consumption Workers. the Planning Manager will spawn MDS Relief Workers. This executable contains the code to perform any of these operations. Here is a complete list of workers that may be spawned and their associated Planning Manager task: • For Forecast Consumption. MDS Relief If you define your MDS with Relieve = Yes. it invokes MRP routines to insert rows into the table MRP_RELIEF_INTERFACE with a RELIEF_TYPE = 1 (MDS relief) and a PROCESS_STATUS = 2 (to be processed). . purchase orders. short name MRCMDW. and after validation inserts material transactions into MTL_MATERIAL_TRANSACTIONS. the Transaction Interface Manager processes those records out of MTL_TRANSACTIONS_INTERFACE. The master schedule relief process mainly involves the flow of records in to and out of the table MRP_RELIEF_INTERFACE. short name MRCSOW. master schedule relief records are stored in the table MRP_SCHEDULE_CONSUMPTIONS. The following sections describe the processes by which this relief works. This includes shipment relief of master demand schedules (MDS) and production relief of master production schedules (MPS). Once processed. records are inserted into MTL_DEMAND to express demand for that sales order. For MDS relief. In the above example. the Planning Manager will spawn Forecast Load Workers. the Planning Manager will spawn MPS Relief Workers. What are all these workers? The worker that is spawned by the Planning Manager depends on which task the Planning Manager is performing. At this point. For MPS relief. How these records are created and processed depends entirely on the type of master schedule being relieved. For the Master Schedule Open Interface. and the site-level profile option MRP:Consume MDS is set to Yes. Master Schedule Relief The Planning Manager is responsible for the function of master schedule relief. After a shipment is made. the column DISPOSITION_ID will be the DEMAND_ID for the corresponding demand record in MTL_DEMAND. the Order Entry concurrent program Inventory Interface inserts records into MTL_TRANSACTIONS_INTERFACE for those shipments. When the Planning Manager next runs. In Oracle Inventory. during the MDS Relief phase of the cycle. then sales order shipments will relieve the MDS. One of the most common support issues for Oracle Master Scheduling/MRP involves purchase requisitions. forecast consumption required that two workers be spawned. At the same time it relieves the demand made by Order Entry in MTL_DEMAND. short name MRCFLW. it will poll the MRP_RELIEF_INTERFACE table for records in the above status (RELIEF_TYPE = 1. and work in process (WIP) jobs failing to relieve the appropriate master schedule. When an order in Order Entry is demanded.

the associated sources of supply would not show up in MRP. SHIPMENT_HEADER_ID. interorg shipment. it is these columns that drive future operations in Oracle Master Scheduling/MRP. or purchase order). Similarly. For MPS relief records inserted by MTL_SUPPLY_T into the table MRP_RELIEF_INTERFACE. MRP_TO_ORGANIZATION_ID. during the MPS Relief phase of the cycle. This populates the WIP_DISCRETE_JOBS . a record is inserted into MTL_SUPPLY corresponding to that source of supply. interorg shipments. if the MTL_SUPPLY_T trigger was missing or disabled.. the column DISPOSITION_ID will contain either a REQ_HEADER_ID. or PO_HEADER_ID depending on the source of the supply (purchase requisition. You should get this result: TRIGGER_NAME STATUS ---------------------------------------------------------------MTL_SUPPLY_T ENABLED Oracle Inventory and Oracle Purchasing When you create or modify an interorg shipment using Oracle Inventory or a purchase requisition or purchase order in Oracle Purchasing. a record is inserted into WIP_DISCRETE_JOBS corresponding to that discrete job. As a result. the Planning Manager will invoke the stored procedure MRP_UPDATE_MRP_COLS. if you modify an existing discrete job. status FROM all_triggers WHERE trigger_name = ‘MTL_SUPPLY_T’. purchase orders. Commonly Encountered Problem Once the appropriate MPS entries have been relieved. during the MPS Relief phase of the cycle. it will poll the MRP_RELIEF_INTERFACE table for records in the above status (RELIEF_TYPE = 2. Commonly Encountered Problem Once the appropriate MPS entries have been relieved. then the database trigger WIP_DISCRETE_JOBS_BRU will insert a new record in MRP_RELIEF_INTERFACE. In addition. or due to some other error the row in MRP_RELIEF_INTERFACE did not get created. When the Planning Manager next runs. and MRP_DESTINATION_TYPE_CODE. Remember that you can query for the existence and status of this trigger using the following SQL statement (connect as MRP): SELECT trigger_name. However. then purchase requisitions. and the site-level profile option MRP:Consume MPS is set to Yes. the WIP_DISCRETE_JOBS_BRD trigger is invoked when you delete a discrete job. PROCESS_STATUS = 2) and will perform MPS Relief for those records.If you define your MPS with Relieve = Yes. PROCESS_STATUS = 2) and will perform MPS Relief for those records. will then insert necessary row(s) into the MRP_RELIEF_INTERFACE with a RELIEF_TYPE = 2 (MPS relief) and a PROCESS_STATUS = 2 (to be processed). This will populate the MTL_SUPPLY columns MRP_EXPECTED_DELIVERY_DATE. A trigger on the MTL_SUPPLY table. MRP_PRIMARY_QUANTITY. will then insert necessary rows into the MRP_RELIEF_INTERFACE table with a RELIEF_TYPE = 2 (MPS relief) and a PROCESS_STATUS = 2 (to be processed). and work in process jobs will relieve the MPS. it will poll the MRP_RELIEF_INTERFACE table for records in the above status (RELIEF_TYPE = 2. For MPS relief records inserted by one of these three WIP triggers into the table MRP_RELIEF_INTERFACE. and these columns would remain Oracle Work In Process When you create a discrete job in Oracle Work In Process. When the Planning Manager next runs. If the profile option MRP:Consume MPS is set to Yes. named MTL_SUPPLY_T. the column DISPOSITION_ID will contain the WIP_ENTITY_ID for the appropriate WIP job. the relief process would not have taken place. the Planning Manager will invoke the stored procedure MRP_UPDATE_MRP_COLS. NULL. to unrelieve the MPS. named WIP_DISCRETE_JOBS_BRI. A trigger on the WIP_DISCRETE_JOBS table.

You should get these results: TRIGGER_NAME STATUS ---------------------------------------------------------------WIP_DISCRETE_JOBS_BRD ENABLED WIP_DISCRETE_JOBS_BRI ENABLED WIP_DISCRETE_JOBS_BRU ENABLED Forecast Consumption If you define your forecast with Consume = Yes. Once the proper forecast entries have been consumed. and these columns would remain NULL. This procedure will update the MRP_DATE and MRP_QUANTITY columns in MTL_DEMAND for the sales orders just processed. SHIP_TO_SITE_USE_ID. First. These records do not require processing in the forecast consumption process because in Oracle Master Scheduling/MRP. these records have UPDATED_FLAG = 1 (Yes). After the Planning Manager completes processing this row. The procedure then marks each of these records in MTL_DEMAND with UPDATED_FLAG = 2 (No). then that record is updated with the information from the MTL_DEMAND record. a row is either INSERTED or UPDATED in MRP_SALES_ORDER_UPDATES (MSOU) for this demand row. If the profile option MRP:Consume MPS is set to Yes. the relief process would not have taken place. for this sales order line. they do not require further processing by the Planning Manager. and DEMAND_CLASS. and the profile option MRP:Consume Forecast is set to Yes. UPDATED_FLAG is set to 2 (No). If a record has not already been inserted into MSOU. in order to see forecast consumption. Finally. However. the associated discrete jobs would not show up in MRP. a record has already been inserted into MSOU. At this point the records in MTL_DEMAND have been processed. then the record is inserted at this point. any records in MSOU with a SCHEDULE_DATE which is outside the boundaries of the workday calendar are updated so that the SCHEDULE_DATE is set to the last valid workday of the calendar. When demand for a sales order is placed. An UPDATED_FLAG of 1 indicates that the row requires processing by MRP. If these attributes have not changed. As a result. records for which any of SHIP_TO_SITE_USE_ID. For those records that are left. When the Planning Manager runs. then demanded sales orders will consume your forecast entries. Now the process of forecast consumption takes place. Next. If. it is these columns that drive future operations in Oracle Master Scheduling/MRP. in that you will see UPDATED_FLAG = 2 (No). the stored procedure COMPUTE_SALES_ORDER_CHANGES in the package MRP_MANAGER_PK is invoked. the procedure UPDATE_SALES_ORDERS in the MRP_MANAGER_PK package is invoked. if the WIP triggers were missing or disabled. This procedure operates on the set of records in MTL_DEMAND which have the column UPDATED_FLAG = 1. or CUSTOMER_ID is NULL are updated with UPDATED_FLAG = 2 (No). When originally inserted. status FROM all_triggers WHERE trigger_name LIKE ‘WIP_DISCRETE_JOBS%’. the records in the set for which the attributes that affect forecast consumption have not changed are also updated with UPDATED_FLAG = 2 (No). AVAILABLE_TO_MRP. on your order and order line you must specify a customer as well as a bill-to and ship-to site. Any necessary records have been inserted into MSOU. BILL_TO_SITE_USE_ID.columns MPS_NET_QUANTITY and MPS_SCHEDULED_COMPLETION_DATE. These attributes are the REQUIREMENT_DATE. CUSTOMER_ID. records are inserted into MTL_DEMAND for each sales order line. Remember that you can query for the existence and status of these triggers using the following SQL statement (connect as MRP): SELECT trigger_name. or due to some other error the row in MRP_RELIEF_INTERFACE did not get created. BILL_TO_SITE_USE_ID. . PRIMARY_UOM_QUANTITY.

and the ERROR_MESSAGE is populated appropriately. error_message = NULL WHERE process_status = 3 AND request_id = <request id from previous query>. then these columns (MRP_DATE and MRP_QUANTITY) drive future operations done by Oracle Master Scheduling/MRP. master schedules. enable the Trace option if you wish to do an EXPLAIN PLAN on the Planning Manager SQL for performance reasons. SQL statements being executed. If it appears that records are stuck in this table with PROCESS_STATUS = 3. then the PROCESS_STATUS is set to 5. Other Useful Profile Options Two other profile options that can be used when diagnosing problems with the Planning Manager are MRP:Debug Mode and MRP:Trace Mode. If they are successfully processed. If that is the case. This should only return request id’s of concurrent requests that are pending or running. can grow at even a faster rate. Records should only have this status while a worker is processing those records. When the profile option is set to Yes. From a technical perspective. This will reset those records so that they are picked up by the Planning Manager during its next cycle. . then PROCESS_STATUS is set to 4. examine the log file of that concurrent request to see the manner in which it ended. You can then run the tkprof utility on the trace file to see every SQL statement executed by the Planning Manager. The relevant values are as follows: 2 = To be processed 3 = In process 4 = Errored during processing 5 = Processed successfully The Planning Manager scans for rows with a PROCESS_STATUS = 2. The Debug option will cause the Planning Manager to print more detailed information into the log file. Both of these profile options can be set at the user level. log files in the range of 30 megabytes per day would be common. When this option is set to Yes. Most likely you will find that the request was aborted due to a database or system crash. In the open interface tables. If a request id returned by this query is completed or terminated. etc. Under normal circumstances. The Trace option will generate database trace files for each Planning Manager run. the status should be reset to either 4 or 5 as above. The trace files will be located in the directory specified by the init.If the profile option MRP:Consume Forecast is set to Yes. the column PROCESS_STATUS is used to indicate the status of each record. MRP Open Interfaces Oracle Master Scheduling has two open interfaces: the forecast open interface and the master schedule open interface. The records with PROCESS_STATUS = 5 will remain in the interface table for the number of days specified by the profile option MRP:Interface Table History Days. records should NOT remain in this table with a PROCESS_STATUS of 3. In addition. If the profile is set to No. which can already be quite large. the log file for the Planning Manager. issue the following query from SQL*Plus to determine the request id of the process which left those records in that status: SELECT DISTINCT(request_id) FROM mrp_forecast_interface WHERE process_status = 3. then it is safe to issue the following update statement in SQL*Plus: UPDATE mrp_forecast_interface SET process_status = 2.ora parameter USER_DUMP_DEST. After completion. as well as information about specific sales orders. these open interfaces operate in the same manner. request_id = NULL. which are being processed are included in the log file. If they contain some type of validation error. These records are then validated according to the rules in the Implementation manuals. then the columns REQUIREMENT_DATE and PRIMARY_UOM_QUANTITY are used in MRP.

and Engineering. he supported Oracle Order Entry in addition to the above products. He currently supports the entire manufacturing suite of products including Master Scheduling/MRP. During his 1 1/2 years with Oracle. Florida. Bills Of Material. if you want the settings of these profile options to affect the behavior of the Planning Manager. About The Author Marc Slone is a Senior Technical Analyst for Oracle Worldwide Customer Support in Orlando. Work In Process. Cost Management. .Whether enabling or disabling these profile options. you must restart the Planning Manager while signed on to the applications as the user with the profile options set appropriately.