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.
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.
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.
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)

Figure 1. The character-mode Start Planning Manager
form
(10SC: Setup, Planning Manager)
Figure 2. The 10SC Start Planning Manager form
When starting the Planning Manager, you must
specify a Processing Interval to use. This is the
amount of time after one Planning Manager
request starts, until the next request is
submitted. If you specify a short processing
interval, for example 30 seconds, you are
assured that your Planning Manager will run
virtually on a continuous basis.
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. For example, let’s say your entire
Planning Manager cycle takes five minutes to
complete, and your processing interval is set to
one hour. If a Planning Manager request starts
at 9:00 AM, then it will complete at 9:05 AM.
The next request will be submitted at 10:00 AM,
exactly one hour from the start time of the
previous request.
If the Planning Manager cycle actually takes a
longer period of time to run than the time
specified by the processing interval, then the
next request will be submitted exactly one
processing interval after the end of the previous
request.
When you start the Planning Manager, the form
will give you the concurrent request id of the
Planning Manager concurrent request. This
request id will be reused by each subsequent
Planning Manager run until the next calendar
day. The Planning Manager will spawn a new
request id each day.
From a system administrator’s point of view, the
Planning Manager presents one important
consideration. The log file for the Planning
Manager will contain information about each task
it performs. If you have the Planning Manager
set up with a processing interval of 30 seconds,
this log file may grow quite large over the course
of a day.
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).
As an example, let’s say the Planning Manager
is set up with a 60 second processing interval,
and MRP:Debug Mode is set to No. In addition,
assume that one planning manager cycle
completes in less than 60 seconds. During the
course of a day, the Planning Manager wakes up
every 60 seconds, checks to see if there is any
work to do, does the work, and goes back to
sleep. Assuming a 24 hour work shift for the
MRP Manager, that means the Planning
Manager will run approximately 1440 (24 hr * 60
min/hr) times during the course of the day.
Also, as an approximation, assume that during
each cycle the planning manager produces 8 KB
of log file information. With these parameters,
the planning manager log file will be over 11 MB
each day. 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.
For an example of a Planning Manager log file,
see Appendix A. This is an actual log file from
one complete cycle of the Planning Manager.
Some SQL statements which MRP prints in the
log file have been removed from the example file
for brevity.
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. Here are a few suggestions:
1. The Messages zone of the Start Planning
Manager form shows the last time that the
planning manager started. See figures 1
and 2 to see an example of this message in
the Messages zone.
2. At the operating system level, check for
processes associated with the MRCLIB
executable.
For example, from UNIX, issue the following
command to check for a running MRCLIB
process:
$ ps -ef | grep MRCLIB
If this does not show any MRCLIB
processes, then the MRP concurrent
manager is not running and hence the
Planning Manager cannot be running.
If you see an MRCLIB process, that does not
necessarily mean that the Planning Manager
is running, only that the MRP Manager is
running. You will need to perform steps 1, 3
or 4.
3. Using the System Administrator
responsibility, on the View Concurrent
Requests screen, query on the program
name Planning Manager. If you have a
request either Running or Pending, then the
Planning Manager is active.
4. Attempt to start the planning manager using
the procedure described in the above
section. The form will alert you that the
Planning Manager is already active if that is
the case.
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, etc.
For example, if the processing interval is set to
10 minutes, 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.
A shorter processing interval obviously lessens
this time but requires greater system resources.
How can I change the processing interval?
You cannot change the processing interval for
the Planning Manager while it is running or
pending. Therefore, if you wish to change this
interval, you should wait for the Planning
Manager to get to a status of Pending, then
cancel that pending request.
At this point you can restart the Planning
Manager with the desired processing interval.
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.
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.
Therefore, when you start the Planning Manager,
a once-a-day-tasks-worker will be spawned.
Then, each day when a new Planning Manager
request id is generated, an additional once-a-
day-tasks-worker is spawned.
The Planning Manager Worker (once-a-day-
tasks) is a concurrent program with short name
MRCSCW1. The executable associated with
this concurrent program is MRCSCW.
You can find the request id of the spawned
once-a-day-tasks worker by looking in the
Planning Manager log file:
=====================================
CONCURRENT MRP MRCSCW1 "OPERATION=7"
Launched concurrent request 6824 for Daily cleanup
worker
=====================================
Figure 3. Planning Manager spawns once-a-day-tasks
worker
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. 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.
The once-a-day-tasks worker also deletes
records from MRP_MESSAGES_TMP,
MRP_FORM_QUERY, and (if CRP is installed)
CRP_FORM_QUERY which have been in the
table for more than two days.
In addition to the above tables, the once-a-day-
tasks 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)
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), 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).
In addition, 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.
Dividing Up The Work
For each task except the once-a-day-tasks
worker, 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.
When performing a particular task, such as
forecast consumption, the Planning Manager
first calculates how many rows in the database
require processing. Then, 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 batch size option indicates the number of
rows per worker to process. 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. A smaller value indicates that any
particular worker will have more rows to process,
and will take longer to complete.
The max workers option indicates the maximum
number of workers to be launched by the
Planning Manager. The Planning Manager will
continue to spawn more workers until the
number of workers running or pending equals
the value of this profile option.
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.
For example, let’s say there are 300 rows which
require forecast consumption. For this example,
assume that the batch size is set to 100 and the
max workers is set to 5. The Planning Manager
will spawn two Sales Order Consumption
workers, each to process 100 rows, and the
Planning Manager itself will process the
remaining 100 rows.
What are all these workers?
The worker that is spawned by the Planning
Manager depends on which task the Planning
Manager is performing. In the above example,
forecast consumption required that two workers
be spawned, so the Planning Manager spawned
two Sales Order Consumption workers. Here is
a complete list of workers that may be spawned
and their associated Planning Manager task:
• For Forecast Consumption, the Planning
Manager will spawn Sales Order
Consumption Workers, short name
MRCSOW.
• For the Forecast Open Interface, the
Planning Manager will spawn Forecast Load
Workers, short name MRCFLW.
• For the Master Schedule Open Interface, the
Planning Manager will spawn Schedule Load
Workers, short name MRCSLW.
• For MDS relief, the Planning Manager will
spawn MDS Relief Workers, short name
MRCMDW.
• For MPS relief, the Planning Manager will
spawn MPS Relief Workers, short name
MRCMPW.
The executable associated with every one of
these workers is MRCSCW. This executable
contains the code to perform any of these
operations.
Master Schedule Relief
The Planning Manager is responsible for the
function of master schedule relief. This includes
shipment relief of master demand schedules
(MDS) and production relief of master production
schedules (MPS).
One of the most common support issues for
Oracle Master Scheduling/MRP involves
purchase requisitions, purchase orders, and
work in process (WIP) jobs failing to relieve the
appropriate master schedule. The following
sections describe the processes by which this
relief works.
The master schedule relief process mainly
involves the flow of records in to and out of the
table MRP_RELIEF_INTERFACE. How these
records are created and processed depends
entirely on the type of master schedule being
relieved. Once processed, master schedule
relief records are stored in the table
MRP_SCHEDULE_CONSUMPTIONS.
MDS Relief
If you define your MDS with Relieve = Yes, and
the site-level profile option MRP:Consume MDS
is set to Yes, then sales order shipments will
relieve the MDS.
When an order in Order Entry is demanded,
records are inserted into MTL_DEMAND to
express demand for that sales order. After a
shipment is made, the Order Entry concurrent
program Inventory Interface inserts records into
MTL_TRANSACTIONS_INTERFACE for those
shipments.
In Oracle Inventory, the Transaction Interface
Manager processes those records out of
MTL_TRANSACTIONS_INTERFACE, and after
validation inserts material transactions into
MTL_MATERIAL_TRANSACTIONS. At the
same time it relieves the demand made by Order
Entry in MTL_DEMAND. At this point, when the
Transaction Manager recognizes a particular
transaction as a sales order shipment, 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).
For MDS relief records in the table
MRP_RELIEF_INTERFACE, the column
DISPOSITION_ID will be the DEMAND_ID for
the corresponding demand record in
MTL_DEMAND.
When the Planning Manager next runs, during
the MDS Relief phase of the cycle, it will poll the
MRP_RELIEF_INTERFACE table for records in
the above status (RELIEF_TYPE = 1,
PROCESS_STATUS = 2) and will perform MDS
Relief for those records.
See the Oracle Master Scheduling/MRP
Reference Manual for a functional description of
the MDS Relief process.
MPS Relief

If you define your MPS with Relieve = Yes, and
the site-level profile option MRP:Consume MPS
is set to Yes, then purchase requisitions,
purchase orders, interorg shipments, and work
in process jobs will relieve the MPS.
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 MTL_SUPPLY corresponding to
that source of supply. A trigger on the
MTL_SUPPLY table, named MTL_SUPPLY_T,
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).
For MPS relief records inserted by
MTL_SUPPLY_T into the table
MRP_RELIEF_INTERFACE, the column
DISPOSITION_ID will contain either a
REQ_HEADER_ID, SHIPMENT_HEADER_ID,
or PO_HEADER_ID depending on the source of
the supply (purchase requisition, interorg
shipment, or purchase order).
When the Planning Manager next runs, 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,
PROCESS_STATUS = 2) and will perform MPS
Relief for those records.
Commonly Encountered Problem
Once the appropriate MPS entries have been
relieved, the Planning Manager will invoke the
stored procedure MRP_UPDATE_MRP_COLS.
This will populate the MTL_SUPPLY columns
MRP_EXPECTED_DELIVERY_DATE,
MRP_PRIMARY_QUANTITY,
MRP_TO_ORGANIZATION_ID, and
MRP_DESTINATION_TYPE_CODE.
If the profile option MRP:Consume MPS is set
to Yes, it is these columns that drive future
operations in Oracle Master Scheduling/MRP.
However, if the MTL_SUPPLY_T trigger was
missing or disabled, or due to some other error
the row in MRP_RELIEF_INTERFACE did not
get created, the relief process would not have
taken place, and these columns would remain
NULL. As a result, the associated sources of
supply would not show up in MRP.
Remember that you can query for the existence
and status of this trigger using the following SQL
statement (connect as MRP):
SELECT trigger_name, status
FROM all_triggers
WHERE trigger_name = ‘MTL_SUPPLY_T’;
You should get this result:
TRIGGER_NAME STATUS
----------------------------------------------------------------
MTL_SUPPLY_T ENABLED
Oracle Work In Process
When you create a discrete job in Oracle Work
In Process, a record is inserted into
WIP_DISCRETE_JOBS corresponding to that
discrete job. A trigger on the
WIP_DISCRETE_JOBS table, named
WIP_DISCRETE_JOBS_BRI, 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).
In addition, if you modify an existing discrete job,
then the database trigger
WIP_DISCRETE_JOBS_BRU will insert a new
record in MRP_RELIEF_INTERFACE. Similarly,
the WIP_DISCRETE_JOBS_BRD trigger is
invoked when you delete a discrete job, to
unrelieve the MPS..
For MPS relief records inserted by one of these
three WIP triggers into the table
MRP_RELIEF_INTERFACE, the column
DISPOSITION_ID will contain the
WIP_ENTITY_ID for the appropriate WIP job.
When the Planning Manager next runs, 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,
PROCESS_STATUS = 2) and will perform MPS
Relief for those records.
Commonly Encountered Problem
Once the appropriate MPS entries have been
relieved, the Planning Manager will invoke the
stored procedure MRP_UPDATE_MRP_COLS.
This populates the WIP_DISCRETE_JOBS
columns MPS_NET_QUANTITY and
MPS_SCHEDULED_COMPLETION_DATE.
If the profile option MRP:Consume MPS is set
to Yes, it is these columns that drive future
operations in Oracle Master Scheduling/MRP.
However, if the WIP triggers were missing or
disabled, or due to some other error the row in
MRP_RELIEF_INTERFACE did not get created,
the relief process would not have taken place,
and these columns would remain NULL. As a
result, the associated discrete jobs would not
show up in MRP.
Remember that you can query for the existence
and status of these triggers using the following
SQL statement (connect as MRP):
SELECT trigger_name, status
FROM all_triggers
WHERE trigger_name
LIKE ‘WIP_DISCRETE_JOBS%’;
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,
and the profile option MRP:Consume Forecast
is set to Yes, then demanded sales orders will
consume your forecast entries.
When demand for a sales order is placed,
records are inserted into MTL_DEMAND for
each sales order line. When originally inserted,
these records have UPDATED_FLAG = 1 (Yes).
An UPDATED_FLAG of 1 indicates that the row
requires processing by MRP. After the Planning
Manager completes processing this row,
UPDATED_FLAG is set to 2 (No).
When the Planning Manager runs, the stored
procedure
COMPUTE_SALES_ORDER_CHANGES in the
package MRP_MANAGER_PK is invoked. This
procedure operates on the set of records in
MTL_DEMAND which have the column
UPDATED_FLAG = 1.
First, records for which any of
SHIP_TO_SITE_USE_ID,
BILL_TO_SITE_USE_ID, or CUSTOMER_ID is
NULL are updated with UPDATED_FLAG = 2
(No). These records do not require processing
in the forecast consumption process because in
Oracle Master Scheduling/MRP, in order to see
forecast consumption, on your order and order
line you must specify a customer as well as a
bill-to and ship-to site.
Next, the records in the set for which the
attributes that affect forecast consumption have
not changed are also updated with
UPDATED_FLAG = 2 (No). These attributes are
the REQUIREMENT_DATE,
PRIMARY_UOM_QUANTITY, CUSTOMER_ID,
SHIP_TO_SITE_USE_ID,
BILL_TO_SITE_USE_ID,
AVAILABLE_TO_MRP, and DEMAND_CLASS.
If these attributes have not changed, they do not
require further processing by the Planning
Manager.
For those records that are left, a row is either
INSERTED or UPDATED in
MRP_SALES_ORDER_UPDATES (MSOU) for
this demand row. If, for this sales order line, a
record has already been inserted into MSOU,
then that record is updated with the information
from the MTL_DEMAND record. If a record has
not already been inserted into MSOU, then the
record is inserted at this point. The procedure
then marks each of these records in
MTL_DEMAND with UPDATED_FLAG = 2 (No).
Finally, 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.
At this point the records in MTL_DEMAND have
been processed, in that you will see
UPDATED_FLAG = 2 (No). Any necessary
records have been inserted into MSOU. Now
the process of forecast consumption takes
place.
Once the proper forecast entries have been
consumed, the procedure
UPDATE_SALES_ORDERS in the
MRP_MANAGER_PK package is invoked. This
procedure will update the MRP_DATE and
MRP_QUANTITY columns in MTL_DEMAND for
the sales orders just processed.
If the profile option MRP:Consume Forecast is
set to Yes, then these columns (MRP_DATE and
MRP_QUANTITY) drive future operations done
by Oracle Master Scheduling/MRP. If the profile
is set to No, then the columns
REQUIREMENT_DATE and
PRIMARY_UOM_QUANTITY are used in MRP.
MRP Open Interfaces
Oracle Master Scheduling has two open
interfaces: the forecast open interface and the
master schedule open interface. From a
technical perspective, these open interfaces
operate in the same manner.
In the open interface tables, the column
PROCESS_STATUS is used to indicate the
status of each record. 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. These records are
then validated according to the rules in the
Implementation manuals. If they are
successfully processed, then the
PROCESS_STATUS is set to 5. If they contain
some type of validation error, then
PROCESS_STATUS is set to 4, and the
ERROR_MESSAGE is populated appropriately.
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.
Under normal circumstances, records should
NOT remain in this table with a
PROCESS_STATUS of 3. Records should only
have this status while a worker is processing
those records. After completion, the status
should be reset to either 4 or 5 as above.
If it appears that records are stuck in this table
with PROCESS_STATUS = 3, 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;
This should only return request id’s of concurrent
requests that are pending or running. If a
request id returned by this query is completed or
terminated, examine the log file of that
concurrent request to see the manner in which it
ended. Most likely you will find that the request
was aborted due to a database or system crash.
If that is the case, then it is safe to issue the
following update statement in SQL*Plus:
UPDATE mrp_forecast_interface
SET process_status = 2,
request_id = NULL,
error_message = NULL
WHERE process_status = 3
AND request_id = <request id from previous
query>;
This will reset those records so that they are
picked up by the Planning Manager during its
next cycle.
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.
Both of these profile options can be set at the
user level.
The Debug option will cause the Planning
Manager to print more detailed information into
the log file. SQL statements being executed, as
well as information about specific sales orders,
master schedules, etc. which are being
processed are included in the log file. When this
option is set to Yes, the log file for the Planning
Manager, which can already be quite large, can
grow at even a faster rate. When the profile
option is set to Yes, log files in the range of 30
megabytes per day would be common.
The Trace option will generate database trace
files for each Planning Manager run. The trace
files will be located in the directory specified by
the init.ora parameter USER_DUMP_DEST. You
can then run the tkprof utility on the trace file to
see every SQL statement executed by the
Planning Manager. In addition, enable the Trace
option if you wish to do an EXPLAIN PLAN on
the Planning Manager SQL for performance
reasons.
Whether enabling or disabling these profile
options, if you want the settings of these profile
options to affect the behavior of the Planning
Manager, you must restart the Planning Manager
while signed on to the applications as the user
with the profile options set appropriately.

About The Author

Marc Slone is a Senior Technical Analyst for

Oracle Worldwide Customer Support in Orlando,
Florida. He currently supports the entire
manufacturing suite of products including Master
Scheduling/MRP, Work In Process, Cost
Management, Bills Of Material, and Engineering.
During his 1 1/2 years with Oracle, he supported
Oracle Order Entry in addition to the above
products.