Planning Manager Technical Workshop

Marc SloneOracle Corporation

Introduction

The Planning Manager is a concurrent programin Oracle Master Scheduling/MRP whichperforms several tasks, including shipment reliefof master demand schedules, production relief ofmaster production schedules, forecastconsumption, and the MRP open interfaceroutines. This paper will discuss the technicalaspects of the tasks addressed by the PlanningManager and the common support issuesencountered.

Note: This document is intended to be used asa reference document. Certain sections of textare intentionally repeated throughout thedocument, so that each section can be read andunderstood independently of one another.

MRP Manager (MRCLIB) andPlanning Manager (MRCRLF)

Do not confuse the MRP Manager with thePlanning Manager. The MRP Manager is aconcurrent manager, while the PlanningManager is an immediate concurrent programwhich runs under the control of the MRPManager.

MRP Manager

The MRP Manager is a concurrent managerwhich uses the Program Library MRCLIB. TheMRP Manager is used solely to run the PlanningManager. That is, the concurrent managershould have exactly one specialization rule, andthat rule should Allow execution of the PlanningManager program.

If you install Oracle Master Scheduling/MRP, theAutoInstall process will automatically create aconcurrent manager with this setup. Do NOTmodify this manager to run all MRP-relatedconcurrent programs. All MRP programs exceptthe Planning Manager run under the Standardconcurrent manager or an equivalent managerthat uses FNDLIBR as its program library.

In addition, the Target Processes for the MRPManager should be set to 1. Since the onlyprogram that runs under this manager is thePlanning Manager, and only one PlanningManager can run at the same time, then there isno need to have more than one MRCLIBprocess running.

Planning Manager

The Planning Manager is an immediateconcurrent program which runs under the MRPconcurrent manager. The short name for thePlanning Manager concurrent program isMRCRLF.

Note that you will not find an executable in theMRP executable directory called MRCRLF.Since the Planning Manager is an immediateconcurrent program, it is run as a subroutine ofits concurrent manager, in this case MRCLIB.Therefore the executable file associated with thePlanning Manager is MRCLIB.

In addition to the executable code, the PlanningManager uses database stored procedures andfunctions to perform much of its work. Theseare the database code objects used by thePlanning Manager:

• MRP_MANAGER_PK is a package ofprocedures and functions used by thePlanning Manager to perform various tasks.

• MRP_UPDATE_MRP_COLS is a procedureused during the MPS relief process.

• MRP_AUTO_REDUCE_MPS is a procedureused during the daily cleanup process.

We will discuss these procedures as appropriatethroughout the text of this paper.

Starting the Planning Manager

Use the Start Planning Manager form to start thePlanning Manager.

(character: \ Navigate Setup PlanningManager)

Figure 1. The character-mode Start Planning Managerform

(10SC: Setup, Planning Manager)

Figure 2. The 10SC Start Planning Manager form

When starting the Planning Manager, you mustspecify a Processing Interval to use. This is theamount of time after one Planning Managerrequest starts, until the next request issubmitted. If you specify a short processinginterval, for example 30 seconds, you areassured that your Planning Manager will runvirtually on a continuous basis.

Important note: the resubmission time of thenext Planning Manager run is calculated fromthe start time of the previous request rather thanthe end time. For example, let’s say your entirePlanning Manager cycle takes five minutes tocomplete, and your processing interval is set toone hour. If a Planning Manager request startsat 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 theprevious request.

If the Planning Manager cycle actually takes alonger period of time to run than the time

specified by the processing interval, then thenext request will be submitted exactly oneprocessing interval after the end of the previousrequest.

When you start the Planning Manager, the formwill give you the concurrent request id of thePlanning Manager concurrent request. Thisrequest id will be reused by each subsequentPlanning Manager run until the next calendarday. The Planning Manager will spawn a newrequest id each day.

From a system administrator’s point of view, thePlanning Manager presents one importantconsideration. The log file for the PlanningManager will contain information about each taskit performs. If you have the Planning Managerset up with a processing interval of 30 seconds,this log file may grow quite large over the courseof a day.

The factors which affect the size of the log fileare the processing interval and the setting of theprofile option MRP:Debug Mode (discussedlater).

As an example, let’s say the Planning Manageris set up with a 60 second processing interval,and MRP:Debug Mode is set to No. In addition,assume that one planning manager cyclecompletes in less than 60 seconds. During thecourse of a day, the Planning Manager wakes upevery 60 seconds, checks to see if there is anywork to do, does the work, and goes back tosleep. Assuming a 24 hour work shift for theMRP Manager, that means the PlanningManager will run approximately 1440 (24 hr * 60min/hr) times during the course of the day.

Also, as an approximation, assume that duringeach cycle the planning manager produces 8 KBof log file information. With these parameters,the planning manager log file will be over 11 MBeach day. If MRP:Debug Mode is set to Yes orthe Planning Manager cycle completes in lesstime than the example, the log file will be evenlarger.

For an example of a Planning Manager log file,see Appendix A. This is an actual log file fromone complete cycle of the Planning Manager.Some SQL statements which MRP prints in thelog file have been removed from the example filefor brevity.

How can I tell if my Planning Manager isactive?

There are several ways to find out informationabout the current status of the PlanningManager. Here are a few suggestions:

1. The Messages zone of the Start PlanningManager form shows the last time that theplanning manager started. See figures 1and 2 to see an example of this message inthe Messages zone.

2. At the operating system level, check for

processes associated with the MRCLIBexecutable.

For example, from UNIX, issue the followingcommand to check for a running MRCLIBprocess:

$ ps -ef | grep MRCLIB

If this does not show any MRCLIBprocesses, then the MRP concurrentmanager is not running and hence thePlanning Manager cannot be running.

If you see an MRCLIB process, that does notnecessarily mean that the Planning Manageris running, only that the MRP Manager isrunning. You will need to perform steps 1, 3or 4.

3. Using the System Administrator

responsibility, on the View ConcurrentRequests screen, query on the programname Planning Manager. If you have arequest either Running or Pending, then thePlanning Manager is active.

4. Attempt to start the planning manager using

the procedure described in the abovesection. The form will alert you that thePlanning Manager is already active if that isthe case.

How do I choose a processing interval?

A longer processing interval simply means thatusers may have to wait longer to see forecastconsumption, master schedule relief, etc.

For example, if the processing interval is set to10 minutes, then users may have to wait as longas 10 minutes to insure that they are seeing an

updated picture of their forecasts and masterschedules.

A shorter processing interval obviously lessensthis time but requires greater system resources.

How can I change the processing interval?

You cannot change the processing interval forthe Planning Manager while it is running orpending. Therefore, if you wish to change thisinterval, you should wait for the PlanningManager to get to a status of Pending, thencancel that pending request.

At this point you can restart the PlanningManager with the desired processing interval.

Planning Manager Tasks

The Planning Manager performs several taskscritical to the operation of Oracle MasterScheduling/MRP:

• Miscellaneous Cleanup Tasks• MDS Relief• MPS Relief• Forecast Consumption• Forecast Open Interface• Master Schedule Open Interface

We will now address the technical aspects ofeach of these tasks in detail.

Planning Manager Worker (once-a-day tasks)(MRCSCW1)

The once-a-day-tasks worker is launchedautomatically by the Planning Manager wheneach 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 Managerrequest 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 nameMRCSCW1. The executable associated withthis concurrent program is MRCSCW.

You can find the request id of the spawnedonce-a-day-tasks worker by looking in thePlanning Manager log file:

Figure 3. Planning Manager spawns once-a-day-tasksworker

Purges MRP Interface Tables

The following are seven of the tables which arepurged 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 ofthe profile option MRP:Interface Table HistoryDays. The once-a-day-tasks worker deletes allrows from these tables which have aPROCESS_STATUS = 5 (processedsuccessfully) and are older than the number ofdays specified by this profile option.

The once-a-day-tasks worker also deletesrecords from MRP_MESSAGES_TMP,MRP_FORM_QUERY, and (if CRP is installed)CRP_FORM_QUERY which have been in thetable for more than two days.

In addition to the above tables, the once-a-day-tasks worker purges records from the followingtables where there are no records in theappropriate foreign key table (shown inparenthesis):

• MRP_SCHEDULE_ITEMS(MRP_SCHEDULE_DATES)

• MRP_FORECAST_UPDATES(MRP_FORECAST_DATES)

• MRP_SCHEDULE_CONSUMPTIONS(MRP_SCHEDULE_DATES andMRP_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 ofmaster schedules so that it has no entry on anymaster schedule (these entries are stored in theMRP_SCHEDULE_DATES table), then theonce-a-day-tasks worker removes that item fromthe list of items on a master schedule (this is theMRP_SCHEDULE_ITEMS table).

In addition, the once-a-day-tasks workerperforms automatic MPS relief based on thesetting of the item attribute Reduce MPS. Thisfeature is used primarily if you do not haveOracle Work In Process and Oracle Purchasinginstalled.

Dividing Up The Work

For each task except the once-a-day-tasksworker, Oracle Master Scheduling/MRP providestwo profile options which govern how thePlanning Manager will divide up the rows in needof processing during any given cycle.

When performing a particular task, such asforecast consumption, the Planning Managerfirst calculates how many rows in the databaserequire processing. Then, the rows are assignedto individual workers according to the values ofthe profile options MRP:Planning ManagerBatch Size and MRP:Planning Manager MaxWorkers.

The batch size option indicates the number ofrows per worker to process. A larger value heremeans Planning Manager will be more efficientsince fewer workers will be spawned andtherefore you will have fewer processes hittingthe database. A smaller value indicates that anyparticular worker will have more rows to process,and will take longer to complete.

The max workers option indicates the maximumnumber of workers to be launched by thePlanning Manager. The Planning Manager willcontinue to spawn more workers until thenumber of workers running or pending equalsthe value of this profile option.

As a general rule do not set the number of maxworkers to a value higher than the number ofrequests that can run simultaneously in yourstandard concurrent managers.For example, let’s say there are 300 rows whichrequire forecast consumption. For this example,assume that the batch size is set to 100 and themax workers is set to 5. The Planning Manager

=====================================CONCURRENT MRP MRCSCW1 "OPERATION=7"Launched concurrent request 6824 for Daily cleanupworker=====================================

will spawn two Sales Order Consumptionworkers, each to process 100 rows, and thePlanning Manager itself will process theremaining 100 rows.

What are all these workers?

The worker that is spawned by the PlanningManager depends on which task the PlanningManager is performing. In the above example,forecast consumption required that two workersbe spawned, so the Planning Manager spawnedtwo Sales Order Consumption workers. Here isa complete list of workers that may be spawnedand their associated Planning Manager task:

• For Forecast Consumption, the PlanningManager will spawn Sales OrderConsumption Workers, short nameMRCSOW.

• For the Forecast Open Interface, thePlanning Manager will spawn Forecast LoadWorkers, short name MRCFLW.

• For the Master Schedule Open Interface, thePlanning Manager will spawn Schedule LoadWorkers, short name MRCSLW.

• For MDS relief, the Planning Manager willspawn MDS Relief Workers, short nameMRCMDW.

• For MPS relief, the Planning Manager willspawn MPS Relief Workers, short nameMRCMPW.

The executable associated with every one ofthese workers is MRCSCW. This executablecontains the code to perform any of theseoperations.

Master Schedule Relief

The Planning Manager is responsible for thefunction of master schedule relief. This includesshipment relief of master demand schedules(MDS) and production relief of master productionschedules (MPS).

One of the most common support issues forOracle Master Scheduling/MRP involvespurchase requisitions, purchase orders, andwork in process (WIP) jobs failing to relieve theappropriate master schedule. The followingsections describe the processes by which thisrelief works.

The master schedule relief process mainlyinvolves the flow of records in to and out of thetable MRP_RELIEF_INTERFACE. How theserecords are created and processed dependsentirely on the type of master schedule beingrelieved. Once processed, master schedulerelief records are stored in the tableMRP_SCHEDULE_CONSUMPTIONS.

MDS Relief

If you define your MDS with Relieve = Yes, andthe site-level profile option MRP:Consume MDSis set to Yes, then sales order shipments willrelieve the MDS.

When an order in Order Entry is demanded,records are inserted into MTL_DEMAND toexpress demand for that sales order. After ashipment is made, the Order Entry concurrentprogram Inventory Interface inserts records intoMTL_TRANSACTIONS_INTERFACE for thoseshipments.

In Oracle Inventory, the Transaction InterfaceManager processes those records out ofMTL_TRANSACTIONS_INTERFACE, and aftervalidation inserts material transactions intoMTL_MATERIAL_TRANSACTIONS. At thesame time it relieves the demand made by OrderEntry in MTL_DEMAND. At this point, when theTransaction Manager recognizes a particulartransaction as a sales order shipment, it invokesMRP routines to insert rows into the tableMRP_RELIEF_INTERFACE with aRELIEF_TYPE = 1 (MDS relief) and aPROCESS_STATUS = 2 (to be processed).

For MDS relief records in the tableMRP_RELIEF_INTERFACE, the columnDISPOSITION_ID will be the DEMAND_ID forthe corresponding demand record inMTL_DEMAND.

When the Planning Manager next runs, duringthe MDS Relief phase of the cycle, it will poll theMRP_RELIEF_INTERFACE table for records inthe above status (RELIEF_TYPE = 1,PROCESS_STATUS = 2) and will perform MDSRelief for those records.

See the Oracle Master Scheduling/MRPReference Manual for a functional description ofthe MDS Relief process.

MPS Relief

If you define your MPS with Relieve = Yes, andthe site-level profile option MRP:Consume MPSis set to Yes, then purchase requisitions,purchase orders, interorg shipments, and workin process jobs will relieve the MPS.

Oracle Inventory and Oracle Purchasing

When you create or modify an interorg shipmentusing Oracle Inventory or a purchase requisitionor purchase order in Oracle Purchasing, a recordis inserted into MTL_SUPPLY corresponding tothat source of supply. A trigger on theMTL_SUPPLY table, named MTL_SUPPLY_T,will then insert necessary rows into theMRP_RELIEF_INTERFACE table with aRELIEF_TYPE = 2 (MPS relief) and aPROCESS_STATUS = 2 (to be processed).

For MPS relief records inserted byMTL_SUPPLY_T into the tableMRP_RELIEF_INTERFACE, the columnDISPOSITION_ID will contain either aREQ_HEADER_ID, SHIPMENT_HEADER_ID,or PO_HEADER_ID depending on the source ofthe supply (purchase requisition, interorgshipment, or purchase order).

When the Planning Manager next runs, duringthe MPS Relief phase of the cycle, it will poll theMRP_RELIEF_INTERFACE table for records inthe above status (RELIEF_TYPE = 2,PROCESS_STATUS = 2) and will perform MPSRelief for those records.

Commonly Encountered Problem

Once the appropriate MPS entries have beenrelieved, the Planning Manager will invoke thestored procedure MRP_UPDATE_MRP_COLS.This will populate the MTL_SUPPLY columnsMRP_EXPECTED_DELIVERY_DATE,MRP_PRIMARY_QUANTITY,MRP_TO_ORGANIZATION_ID, andMRP_DESTINATION_TYPE_CODE.

If the profile option MRP:Consume MPS is setto Yes, it is these columns that drive futureoperations in Oracle Master Scheduling/MRP.

However, if the MTL_SUPPLY_T trigger wasmissing or disabled, or due to some other errorthe row in MRP_RELIEF_INTERFACE did notget created, the relief process would not havetaken place, and these columns would remain

NULL. As a result, the associated sources ofsupply would not show up in MRP.

Remember that you can query for the existenceand status of this trigger using the following SQLstatement (connect as MRP):

SELECT trigger_name, statusFROM all_triggersWHERE 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 WorkIn Process, a record is inserted intoWIP_DISCRETE_JOBS corresponding to thatdiscrete job. A trigger on theWIP_DISCRETE_JOBS table, namedWIP_DISCRETE_JOBS_BRI, will then insertnecessary row(s) into theMRP_RELIEF_INTERFACE with aRELIEF_TYPE = 2 (MPS relief) and aPROCESS_STATUS = 2 (to be processed).

In addition, if you modify an existing discrete job,then the database triggerWIP_DISCRETE_JOBS_BRU will insert a newrecord in MRP_RELIEF_INTERFACE. Similarly,the WIP_DISCRETE_JOBS_BRD trigger isinvoked when you delete a discrete job, tounrelieve the MPS..

For MPS relief records inserted by one of thesethree WIP triggers into the tableMRP_RELIEF_INTERFACE, the columnDISPOSITION_ID will contain theWIP_ENTITY_ID for the appropriate WIP job.

When the Planning Manager next runs, duringthe MPS Relief phase of the cycle, it will poll theMRP_RELIEF_INTERFACE table for records inthe above status (RELIEF_TYPE = 2,PROCESS_STATUS = 2) and will perform MPSRelief for those records.Commonly Encountered Problem

Once the appropriate MPS entries have beenrelieved, the Planning Manager will invoke thestored procedure MRP_UPDATE_MRP_COLS.This populates the WIP_DISCRETE_JOBS

columns MPS_NET_QUANTITY andMPS_SCHEDULED_COMPLETION_DATE.

If the profile option MRP:Consume MPS is setto Yes, it is these columns that drive futureoperations in Oracle Master Scheduling/MRP.

However, if the WIP triggers were missing ordisabled, or due to some other error the row inMRP_RELIEF_INTERFACE did not get created,the relief process would not have taken place,and these columns would remain NULL. As aresult, the associated discrete jobs would notshow up in MRP.

Remember that you can query for the existenceand status of these triggers using the followingSQL statement (connect as MRP):

SELECT trigger_name, statusFROM all_triggersWHERE trigger_name LIKE ‘WIP_DISCRETE_JOBS%’;

You should get these results:

TRIGGER_NAME STATUS----------------------------------------------------------------WIP_DISCRETE_JOBS_BRD ENABLEDWIP_DISCRETE_JOBS_BRI ENABLEDWIP_DISCRETE_JOBS_BRU ENABLED

Forecast Consumption

If you define your forecast with Consume = Yes,and the profile option MRP:Consume Forecastis set to Yes, then demanded sales orders willconsume your forecast entries.

When demand for a sales order is placed,records are inserted into MTL_DEMAND foreach sales order line. When originally inserted,these records have UPDATED_FLAG = 1 (Yes).An UPDATED_FLAG of 1 indicates that the rowrequires processing by MRP. After the PlanningManager completes processing this row,UPDATED_FLAG is set to 2 (No).

When the Planning Manager runs, the storedprocedureCOMPUTE_SALES_ORDER_CHANGES in thepackage MRP_MANAGER_PK is invoked. Thisprocedure operates on the set of records inMTL_DEMAND which have the columnUPDATED_FLAG = 1.

First, records for which any ofSHIP_TO_SITE_USE_ID,BILL_TO_SITE_USE_ID, or CUSTOMER_ID isNULL are updated with UPDATED_FLAG = 2(No). These records do not require processingin the forecast consumption process because inOracle Master Scheduling/MRP, in order to seeforecast consumption, on your order and orderline you must specify a customer as well as abill-to and ship-to site.

Next, the records in the set for which theattributes that affect forecast consumption havenot changed are also updated withUPDATED_FLAG = 2 (No). These attributes arethe 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 notrequire further processing by the PlanningManager.

For those records that are left, a row is eitherINSERTED or UPDATED inMRP_SALES_ORDER_UPDATES (MSOU) forthis demand row. If, for this sales order line, arecord has already been inserted into MSOU,then that record is updated with the informationfrom the MTL_DEMAND record. If a record hasnot already been inserted into MSOU, then therecord is inserted at this point. The procedurethen marks each of these records inMTL_DEMAND with UPDATED_FLAG = 2 (No).

Finally, any records in MSOU with aSCHEDULE_DATE which is outside theboundaries of the workday calendar are updatedso that the SCHEDULE_DATE is set to the lastvalid workday of the calendar.

At this point the records in MTL_DEMAND havebeen processed, in that you will seeUPDATED_FLAG = 2 (No). Any necessaryrecords have been inserted into MSOU. Nowthe process of forecast consumption takesplace.Once the proper forecast entries have beenconsumed, the procedureUPDATE_SALES_ORDERS in theMRP_MANAGER_PK package is invoked. Thisprocedure will update the MRP_DATE andMRP_QUANTITY columns in MTL_DEMAND forthe sales orders just processed.

If the profile option MRP:Consume Forecast isset to Yes, then these columns (MRP_DATE andMRP_QUANTITY) drive future operations doneby Oracle Master Scheduling/MRP. If the profileis set to No, then the columnsREQUIREMENT_DATE andPRIMARY_UOM_QUANTITY are used in MRP.

MRP Open Interfaces

Oracle Master Scheduling has two openinterfaces: the forecast open interface and themaster schedule open interface. From atechnical perspective, these open interfacesoperate in the same manner.

In the open interface tables, the columnPROCESS_STATUS is used to indicate thestatus of each record. The relevant values areas follows:

2 = To be processed3 = In process4 = Errored during processing5 = Processed successfully

The Planning Manager scans for rows with aPROCESS_STATUS = 2. These records arethen validated according to the rules in theImplementation manuals. If they aresuccessfully processed, then thePROCESS_STATUS is set to 5. If they containsome type of validation error, thenPROCESS_STATUS is set to 4, and theERROR_MESSAGE is populated appropriately.

The records with PROCESS_STATUS = 5 willremain in the interface table for the number ofdays specified by the profile optionMRP:Interface Table History Days.

Under normal circumstances, records shouldNOT remain in this table with aPROCESS_STATUS of 3. Records should onlyhave this status while a worker is processingthose records. After completion, the statusshould be reset to either 4 or 5 as above.

If it appears that records are stuck in this tablewith PROCESS_STATUS = 3, issue thefollowing query from SQL*Plus to determine therequest id of the process which left thoserecords in that status:

SELECT DISTINCT(request_id)FROM mrp_forecast_interface

WHERE process_status = 3;

This should only return request id’s of concurrentrequests that are pending or running. If arequest id returned by this query is completed orterminated, examine the log file of thatconcurrent request to see the manner in which itended. Most likely you will find that the requestwas aborted due to a database or system crash.

If that is the case, then it is safe to issue thefollowing update statement in SQL*Plus:

UPDATE mrp_forecast_interfaceSET process_status = 2,

request_id = NULL,error_message = NULL

WHERE process_status = 3AND request_id = <request id from previousquery>;

This will reset those records so that they arepicked up by the Planning Manager during itsnext cycle.

Other Useful Profile Options

Two other profile options that can be used whendiagnosing problems with the Planning Managerare MRP:Debug Mode and MRP:Trace Mode.Both of these profile options can be set at theuser level.

The Debug option will cause the PlanningManager to print more detailed information intothe log file. SQL statements being executed, aswell as information about specific sales orders,master schedules, etc. which are beingprocessed are included in the log file. When thisoption is set to Yes, the log file for the PlanningManager, which can already be quite large, cangrow at even a faster rate. When the profileoption is set to Yes, log files in the range of 30megabytes per day would be common.

The Trace option will generate database tracefiles for each Planning Manager run. The tracefiles will be located in the directory specified bythe init.ora parameter USER_DUMP_DEST. Youcan then run the tkprof utility on the trace file tosee every SQL statement executed by thePlanning Manager. In addition, enable the Traceoption if you wish to do an EXPLAIN PLAN onthe Planning Manager SQL for performancereasons.

Whether enabling or disabling these profileoptions, if you want the settings of these profileoptions to affect the behavior of the PlanningManager, you must restart the Planning Managerwhile signed on to the applications as the userwith the profile options set appropriately.

About The Author

Marc Slone is a Senior Technical Analyst forOracle Worldwide Customer Support in Orlando,Florida. He currently supports the entiremanufacturing suite of products including MasterScheduling/MRP, Work In Process, CostManagement, Bills Of Material, and Engineering.During his 1 1/2 years with Oracle, he supportedOracle Order Entry in addition to the aboveproducts.