Committing PeopleSoft Supply Planning Updates

This chapter provides an overview of PeopleSoft Supply Planning planned order numbering schemes, and discusses how to:

Post PeopleSoft Supply Planning updates to the transaction system.
Create PeopleSoft Supply Planning Updates reports.
Display item useup information.
Reset the locks for the Post Updates process (PL_POST).

Understanding PeopleSoft Supply Planning Planned Order Numbering

This section discusses the numbering schemes that the system uses to keep planned orders in the planning instance synchronous with numbering schemes in the transaction system.

PeopleSoft Supply Planning retains two sets of order numbers for each planned order. The first number is unique for a planning instance. The second number is unique within the transaction system. Both numbers reside on the transaction system table and planning instance table, one number is a key, the other number is a reference.

Planning Instance Sequence Number

When you run the Load Planning Instance process (PL_LOAD_OPT) with a run type defined as Regenerative, the process sets the planned sequence number equal to the transaction system sequence number when it inserts these orders into the planning instance tables.

After the Load Planning Instance process inserts all of the orders into the planning instance tables, it updates the next available planning sequence number on the Planning Instance table to equal the last planning sequence number used, plus one, and increments this number each time that you add new planned orders to the planning instance tables.

Transaction System Sequence Number

In the planning instance tables, the system populates the transaction sequence number with the sequence number from the transaction system table record. The system populates this field with a zero for new orders created in the planning instance. Because multiple planning instances can post data back to the transaction system, it is possible that the same planning sequence number can exist in more than one planning instance. To keep orders unique in the transaction system, PeopleSoft Supply Planning also assigns a transaction sequence number.

When you run the Post Updates process, the transaction system stores the next available transaction sequence number by order type on the Installation - Planning table (INSTALLATION_PL). Existing planned orders retain the transaction sequence number assigned when they were first added into the transaction system.

Example 1: Regeneration

This example demonstrates how the system assigns order numbers for a simple case of regeneration only.

You plan for a group of items for the first time.

No planned orders exist in the transaction system.
You run the Load Planning Instance process with the run type defined as Regenerative, using these values:
- Planning Instance = MRP.
- Business Unit = US008.
- Next Available Planning Sequence Number = 1.
- Transaction System Next Available Transaction Sequence Number = 1.
You run a planning solver, which adds two planned orders:

Planning Instance Table

Planning Instance

Business Unit

Planning Sequence Number

Transaction Sequence Number

MRP

US008

1

0

MRP

US008

2

0

These are the next available sequence numbers in the Planning Instance table:
- Planning Instance Next Available Planning Sequence Number = 3.
- Transaction System Next Available Transaction Sequence Number = 1.
You commit the planning data, including the two planned orders, back to the transaction system.

The new planned orders do not have a transaction sequence number, so the system assigns each planned order a transaction sequence number:

Transaction System Table

Business Unit

Transaction Sequence Number

Planning Instance

Planning Sequence Number

US008

1

MRP

1

US008

2

MRP

2

These are the next available sequence numbers in the transaction system table:
- Planning Instance Next Available Planning Sequence Number = 3.
- Transaction System Next Available Transaction Sequence Number = 3.
You run Load Planning Instance process again with the run type defined as Regenerative.

Planning Instance Table

Planning Instance

Business Unit

Planning Sequence Number

Transaction Sequence Number

MRP

US008

1

1

MRP

US008

2

2

These are the next available sequence numbers in the Planning Instance table:
- Planning Instance Next Available Planning Sequence Number = 3.
- Transaction System Next Available Transaction Sequence Number = 3.
You commit the planning data, including the two planned orders, back to the transaction system immediately after the Load Planning Instance process.

Because each planned order has an assigned transaction sequence number, the system assigns no new numbers:

Transaction System Table

Business Unit

Transaction Sequence Number

Planning Instance

Planning Sequence Number

US008

1

MRP

1

US008

2

MRP

2

These are the next available sequence numbers in the transaction system table:
- Planning Instance Next Available Planning Sequence Number = 3.
- Transaction System Next Available Transaction Sequence Number = 3.

Planning Instance Table
MRP	US008	1	0
MRP	US008	2	0

Transaction System Table
US008	1	MRP	1
US008	2	MRP	2

Planning Instance Table
MRP	US008	1	1
MRP	US008	2	2

Transaction System Table
US008	1	MRP	1
US008	2	MRP	2

Example 2: Multiple Problem Instances, Exclusive Items, and Regeneration Only

This example demonstrates the order numbering assignment during a more complex scenario, with multiple planning instances, exclusive items, and a run type defined as Regenerative.

You plan for a group of items for the first time.

No planned orders exist in the transaction system.
You run the Load Planning Instance process with the run type defined as Regenerative, and use these values:
- Planning Instance = GROUP1.
- Business Unit = US008.
- Planning Instance Next Available Planning Sequence Number = 1.
- Transaction System Next Available Transaction Sequence Number = 1.
You run a planning solver, which adds two planned orders:

Planning Instance Table

Planning Instance

Business Unit

Planning Sequence Number

Transaction Sequence Number

GROUP1

US008

1

0

GROUP1

US008

2

0

These are the next available sequence numbers in the Planning Instance table:
- Planning Instance GROUP1 Next Available Planning Sequence Number = 3.
- Transaction System Next Available Transaction Sequence Number = 1.
You plan for a second group of items for the first time.

No planned orders exist in the transaction system.
You run the Load Planning Instance process with the run type defined as Regenerative, using these values:
- Planning Instance = GROUP2.
- Business Unit = US008.
- Planning Instance Next Available Planning Sequence Number = 1.
- Transaction System Next Available Transaction Sequence Number = 1.

Planning Instance Table
GROUP1	US008	1	0
GROUP1	US008	2	0

You run a solver, which adds three planned orders:

Planning Instance Table
Planning Instance	Business Unit	Planning Sequence Number	Transaction Sequence Number
GROUP1	US008	1	0
GROUP1	US008	2	0
GROUP2	US008	1	0
GROUP2	US008	2	0
GROUP2	US008	3	0

These are the next available sequence numbers in the Planning Instance table:

Planning Instance GROUP2 Next Available Planning Sequence Number = 4.
Transaction System Next Available Transaction Sequence Number = 1.

You commit the planning data for planning instance GROUP1, including the two planned orders, back to the transaction system.

The new planned orders do not have a transaction sequence number, so the system assigns each planned order a transaction sequence number:

Transaction System Table

Business Unit

Transaction Sequence Number

Planning Instance

Planning Sequence Number

US008

1

GROUP1

1

US008

2

GROUP1

2

The transaction system's next available Transaction Sequence Number is now = 3.

Transaction System Table
US008	1	GROUP1	1
US008	2	GROUP1	2

You commit the planning data for planning instance GROUP2, including the three planned orders, back to the transaction system.

The new planned orders do not have a transaction sequence number, so the system assigns each planned order a transaction sequence number:

Transaction System Table
Business Unit	Transaction Sequence Number	Planning Instance	Planning Sequence Number
US008	1	GROUP1	1
US008	2	GROUP1	2
US008	3	GROUP2	1
US008	4	GROUP2	2
US008	5	GROUP2	3

The transaction system's next available Transaction Sequence Number is now = 6.

You create a new planning instance that represents all of the items.
You run the Load Planning Instance process with the run type defined as Regenerative, using these values:
- Planning Instance = ALLITEMS.
- Business Unit = US008.
- Planning Instance Next Available Planning Sequence Number = 1.
- Transaction System Next Available Transaction Sequence Number = 6.

You run the Load Planning Instance process with the run type defined as Regenerative, which produces these results:

Planning Instance Table
Planning Instance	Business Unit	Planning Sequence Number	Transaction Sequence Number
GROUP1	US008	1	0
GROUP1	US008	2	0
GROUP2	US008	1	0
GROUP2	US008	2	0
GROUP2	US008	3	0
ALLITEMS	US008	1	1
ALLITEMS	US008	2	2
ALLITEMS	US008	3	3
ALLITEMS	US008	4	4
ALLITEMS	US008	5	5

These are the next available sequence numbers in the Planning Instance table:

Planning Instance ALLITEMS next available Planning Sequence Number = 6.
Transaction system next available Transaction Sequence Number = 6.

You freeze all of the orders in planning instance ALLITEMS, run a solver, and assume one additional order is added:

Planning Instance Table
Planning Instance	Business Unit	Planning Sequence Number	Transaction Sequence Number
GROUP1	US008	1	0
GROUP1	US008	2	0
GROUP2	US008	1	0
GROUP2	US008	2	0
GROUP2	US008	3	0
ALLITEMS	US008	1	1
ALLITEMS	US008	2	2
ALLITEMS	US008	3	3
ALLITEMS	US008	4	4
ALLITEMS	US008	5	5
ALLITEMS	US008	6	0

These are the next available sequence numbers in the Planning Instance table:

Planning Instance ALLITEMS next available Planning Sequence Number = 7.
Transaction system next available Transaction Sequence Number = 6.

You import the planning data for planning instance, ALLITEMS, back to the transaction system.

The ALLITEMS planning instance represents the items in GROUP1 and GROUP2; therefore, orders exist in this group that also exist in the transaction system. To distinguish between new planned purchase orders (POs) and existing planned POs in the transaction system, the system:

Deletes from the transaction system—on an item-by-item basis—any planned POs that do not exist in the imported planning instance.
Updates the transaction system records for existing planned POs with relevant data in the planning instance table records.

Inserts new planned POs—orders in the planning instance that have a transaction sequence number defined as zero—into the transaction system tables.

In this example, the system has previously assigned the first five orders transaction sequence numbers. The system updates these orders with any relevant changes.

For planned transfer and production orders, the system deletes all of the orders from the transaction system and inserts planned orders into the transaction system tables.

The last order does not have an assigned transaction sequence number. This new order is inserted into the transaction system table and assigned a transaction sequence number from the Installation - Planning table.

Transaction System Table
Business Unit	Transaction Sequence Number	Planning Instance	Planning Sequence Number
US008	1	ALLITEMS	1
US008	2	ALLITEMS	2
US008	3	ALLITEMS	3
US008	4	ALLITEMS	4
US008	5	ALLITEMS	5
US008	6	ALLITEMS	6

The transaction system's next available Transaction Sequence Number is now = 7.

Example 3: Net Change Example

A limited number of scenarios exist where you import planned order changes into the planning instance with a run type of Net Change. These include:

Converting a planned order into an actual order. The order is deleted from the planning instance.
Adding a planned PO within PeopleSoft Collaborative Supply Management (PeopleSoft CSM). Orders added by PeopleSoft CSM have a blank planning instance and a planning sequence number defined as zero.
Changing an existing planned PO within PeopleSoft CSM.

In this example, you are working with the data from example 2:

Planning Instance Table
Planning Instance	Business Unit	Planning Sequence Number	Transaction Sequence Number
GROUP1	US008	1	0
GROUP1	US008	2	0
GROUP2	US008	1	0
GROUP2	US008	2	0
GROUP2	US008	3	0
ALLITEMS	US008	1	1
ALLITEMS	US008	2	2
ALLITEMS	US008	3	3
ALLITEMS	US008	4	4
ALLITEMS	US008	5	5
ALLITEMS	US008	6	0

and:

Transaction System Table
Business Unit	Transaction Sequence Number	Planning Instance	Planning Sequence Number
US008	1	ALLITEMS	1
US008	2	ALLITEMS	2
US008	3	ALLITEMS	3
US008	4	ALLITEMS	4
US008	5	ALLITEMS	5
US008	6	ALLITEMS	6

You add a planned order in the transaction system:

Transaction System Table
Business Unit	Transaction Sequence Number	Planning Instance	Planning Sequence Number
US008	1	ALLITEMS	1
US008	2	ALLITEMS	2
US008	3	ALLITEMS	3
US008	4	ALLITEMS	4
US008	5	ALLITEMS	5
US008	6	ALLITEMS	6
US008	7	Blank	0

The transaction system's next available Transaction Sequence Number is now = 8.

You convert transaction sequence numbers 5 and 6 into actual POs and run the Load Planning Instance process with a run type of Net Change for problem instance ALLITEMS.

These actions occur:
- The Load Planning Instance process deletes all of the planning orders with a transaction sequence equal to zero.
- The order number ALLITEMS/US008/5 (planning instance/business unit/transaction sequence number) exists in the planning instance table. Therefore, the system deletes planned order ALLITEMS/US008/5 from the planning instance.
- The order number ALLITEMS/US008/ 6 does not exist in the planning instance table. No action occurs.
- The order number ALLITEMS/US008/ 7 does not exist in the planning instance table. In the transaction system, planned order US008/7 does not map to any planning instance order. Therefore, the system adds this new order as ALLITEMS/US008/7.
- Using the same logic for planning instance GROUP1, the system deletes all of the orders from the planning instance and adds transaction sequence numbers 1, 2, 3, 4, and 7; the system sets the next available planning sequence number to 8.
- Using the same logic for planning instance GROUP2, the system deletes all of the orders from the planning instance and adds transaction sequence numbers 1, 2, 3, 4, and 7; the system sets the next available planning sequence number to 8.

Posting PeopleSoft Supply Planning Updates to the Transaction System

Once you create a workable plan in PeopleSoft Supply Planning, create the recommendations into the PeopleSoft transactional system using the Post Updates process. There, the recommendations are distributed into the various components as planning updates, where you can review them. You can also select to have updates automatically approved, where applicable.

Understanding the Post Updates Process

The Post Updates process enables you to generate PeopleSoft Supply Planning updates for PeopleSoft Order Management, Inventory, Production Management, and Purchasing.

The Post Updates process performs these steps for the specified run control:

Locks the business unit for posting planning updates, as indicated by the business unit group associated with the planning instance.

Two posts cannot run concurrently for the same business unit and data type. If the business unit is locked by another process, the system displays an error in the message log.
Calculates the item horizons.
Processes all of the selected data types.

For each data type, the process:
1. Selects data for processing.
2. Initializes the staging and exception tables.
3. Validates changes.
4. Approves valid orders.
5. Updates staging and exception tables.
Unlocks the planning instance data type.

Multi-Process Post Update

You can post updates using the Post Updates process (PL_POST) or using the Plan Multi-Process Post job (PL_POSTM), which separates the Post Updates process into several child processes to enable concurrency. Multi-process post updates enables you to use multi-CPU servers or schedule child processes to occur on different servers.

PeopleSoft Supply Planning uses JobSet functionality to enable you to schedule a combination of serial and parallel jobs. When you select the Multi-Process Post Update job on the PeopleSoft Process Scheduler page, the system schedules the processes to run serially or parallel, as needed. If a process fails, the system determines which, if any, subsequent processes it should run. For example, if the Multi-Process Post Update Start process (PL_POST_MPS) process fails, the system does not run subsequent processes. However, if the Post Production Updates process (PL_POST_PR) fails, the system still runs the Post Sales Order Updates process (PL_POST_SO), as the remaining processes in the Multi-Process Post Update job can run independently of the others. If any single process fails, you can correct the situation, then rerun the Post Updates process for the corrected section.

Calculating Item Horizons

The process calculates these item-specific horizons:

Planning Time Fence Date = Current Date + Planning Time Fence.
Action Message Cutoff Date = Current Date + Action Message Cutoff Fence.
Released Order Fence Date = Current Date + Released Order Fence.
Firmed Order Fence Date = Current Date + Firmed Order Fence.

Released and firmed dates are used with planned production only.

Selecting Data for Processing

The Post Updates Process considers these options when selecting data for processing:

Planned Order Status

Planned orders must have a status of Planned or Firmed. Canceled planned POs are posted for vendor scheduled items, if the orders were previously posted to the transaction system.

Actual orders are not subject to this validation.

Actual Order Change

The Post Updates process selects only actual orders that have changed. The process compares the planning instance order against the actual order in the transaction system and selects only those orders where changes occurred.

Planned orders are not subject to this restriction.

Action Message Cutoff Date

If you did not select the Ignore Cutoff option on the Post Updates page, the process selects only those records where the planning-suggested due date or actual due order date are less than or equal to the item's action message cutoff date.

Planned orders do not have an actual order due date.

Initializing Staging and Exception Tables

The Post Updates process deletes records from the staging and exception tables based on the initialization options. If you selected All by Selected Planned By in the Items field on the Post Updates page, the process deletes all of the records if you also selected All Data Types in the Types field, or if you selected Posted Data Types in the Types field and the corresponding order types were selected for processing. The process deletes records for only those items matching the Planned By option criteria that you selected on the Post Updates page.

If you selected Selected by Planning Instance in the Items field on the Post Updates page, the process deletes all of the records for items that it locates in the PL_BU_ITEMS table, if you also selected All Data Types in the Types field, or if you selected Posted Data Types in the Types field and the corresponding order types were selected for processing. The process deletes records for only those items matching the Planned By option criteria that you selected on the Post Updates page.

Validating Changes

If the Post Updates process encounters an error while validating changes made in PeopleSoft Supply Planning, it writes the error to the Review Post Errors Inquiry for the data type. You must make the appropriate changes manually in the transaction system.

Note. If an order date change is less than the item defined reschedule in or reschedule out range, use the Post Updates page to define how the Post Updates process handles the order date change. The Post Updates process can mark the change in error, approve the order automatically, ignore the order, or accept the order change through standard approval and validation.

This table lists the Post Updates process validation rules for order types:

Order Type	Valid Changes	Exceptions
Actual Purchases	Cancel a schedule. Change a schedule due date.	Tolerance violation occurs and you request errors. Existing line or schedule status is Canceled or Closed. Existing PO header status is Canceled or Closed. Existing PO header is being held. PO schedule has been deleted. Order changes in the transaction system, denoted by checking the current transaction fields against the original fields stored on the optimization table. Order quantity changes in the planning engine.
Planned Purchases	Add a planned order.	Planned order created in a prior planning instance has been converted to a PO.
Actual Production	Cancel an order. Change the header start time, start date, end time, or end date. Freeze an order. Change an operation start time, start date, end time, or end date. Substitute a component.	Tolerance violation occurs, and you request errors. Item is a fast MRP item and the proposed header start date and time is not valid for the manufacturing calendar or five day work week. Item is a fast MRP item and the proposed header end date and time is not valid for the manufacturing calendar or five day work week. Order status is greater than in-process and a change is proposed to the header. Order changes in the transaction system, denoted by tracking original field values (date, frozen flag, and quantity). A pick plan is generated for the order. Order is deleted from the transaction system. Component substitute is not listed on the bill of materials (BOM) as a valid substitute. Operation start date and time or end date and time is invalid.
Planned Production	Add a planned order. Substitute a component.	Item is a fast MRP item and the proposed header start date and time is not valid for the manufacturing calendar or five day work week. Item is a fast MRP item and the proposed header end date and time is not valid for the manufacturing calendar or five day work week. Production area and item combination is invalid. Component substitute is not listed on the BOM as a valid substitute. Operation start date and time or end date and time is invalid. Operation does not exist on engineering routing. Component is invalid. Planned order created in a prior planning instance has been converted to a production order.
Actual Transfers	Cancel an order. Reschedule the scheduled arrival date and time. Change an order priority.	Tolerance violation occurs and you request errors. Order has been shipped, deleted, closed, or canceled. Order changes within the transaction system, denoted by checking the current transaction fields against the original fields stored on the optimization table. If the priority, frozen option, schedule dates, or quantity have been modified since the optimization tables were loaded, the Post Updates process writes an exception. Order quantity changed in the planning engine.
Planned Transfers	Add a planned order	Planned order created in a prior planning instance has been converted to a transfer order.
Sales Orders	Change the scheduled ship date and time.	Tolerance violation occurs and you request errors. Order does not exist. Order changes in the transaction system, denoted by checking the current transaction fields against the original fields stored on the optimization table. Order is not open. Order is canceled by the planning engine.
Quotes	Change the scheduled ship date and time.	Tolerance violation occurs and you request errors. Order does not exist. Order changes in the transaction system, denoted by checking the current transaction fields against the original fields stored on the optimization table. Quote is converted. Order is not open. Order canceled by the planning engine.
Buying Agreement	Change the requested ship date and time.	Tolerance violation occurs, and you request errors. Order does not exist. Agreement has been converted. Order is not open. Order canceled by the planning engine.
Material Stock Request	Change the scheduled ship date and time.	Tolerance violation occurs and you request errors. Order does not exist. Order changes in the transaction system, denoted by checking the current transaction fields against the original fields stored on the optimization table. Order is not open. Order canceled by the planning engine.

Updating Staging and Exception Tables

The Post Updates process inserts orders with errors into the appropriate exception table. These exceptions can be seen in the Review Post Errors Inquiry for the data type.

For valid planned orders, the process:

Updates the existing order, if the order header exists in the staging table.

Staging tables can be seen in the Approve Updates Workbench for the data type.
Inserts the header and all of the valid children into the staging table, if the order header did not exist in the staging table.

For valid actual orders, the process inserts the order into the staging table. For actual purchases, sales orders, quotes, buying agreements, the process inserts only one row per distinct schedule.

The Post Updates process assigns new records in the staging tables a sequence number from the INSTALLATION_PL table. Sequence numbers are reset to 1 after the process assigns the sequence number 999,999,999. The process reserves sequence numbers as blocks by counting the number of valid records, then updating the counter by the appropriate amount, noting the first and last order number reserved.

Projected Useup

For discontinued items, the Post Updates process publishes the last date that a supply or demand has occurred (the useup date) with the final inventory balance resulting from that change in inventory position (the useup quantity on hand). For configured items, the Post Updates process publishes this data for each configuration code.

Page Used to Run the Post Updates Process

Page Name	Object Name	Navigation	Usage
Post Updates	PL_POST_REQ	Supply Planning, Commit Plan, Planning, Post Updates	Extract new orders and changes to existing orders from the planning instance. Validate and stage orders for application to the transaction system.

Running the Post Updates Process

Access the Post Updates page.

Common Information

Planned By

Select any combination of distribution plan, material plan, or master plan items for posting. The selection determines what data is initialized and processed.

Initialize Data Types

Specify the data to include in the staging and exception tables after you run the Post Updates process. The data tables that you include are determined by the combination of values that you select in the Items and Types fields.

When you run the Post Updates process for a planning instance, you send the transaction system a set of recommended changes to the supply plan (written to the staging tables), as well as those changes that cannot be implemented due to validation errors (written to the exception tables). Use the Items and Types fields to specify how to delete the data from the previous Post Updates process. In the Items field, indicate whether you want to delete all of the prior data or delete only the data for items in the planning instance. In the Types field, indicate whether you want delete all of the prior data or only the data types that you intend to add back.

This table lists the valid combinations and the corresponding Post Updates process action:

Type Field Selection	Item Field Selection	Action
All Data Types	All by Selected Planned By	Initializes all of the data tables for all of the items that you included in the Planned By option criteria.
All Data Types	Selected by Planning Instance	Initializes all of the data tables that you included in the Planned By option criteria, but only for those items included within the corresponding planning instance.
Posted Data Types	All by Selected Planned By	Initializes all of the data tables selected for posting for all of the items that you included in the Planned By option criteria.
Posted Data Types	Selected by Planning Instance	Initializes all of the data tables selected for posting that you included in the Planned By option criteria, but only for those items included within the corresponding planning instance.

Select All	Click to include all of the data types that appear in the Posting Options group box for processing.
Clear All	Click to exclude all of the data types that appear in the Posting Options group box for processing.

Selection Criteria Tab

Select the Selection Criteria tab.

Select	Select to include the corresponding data type in the Post Updates processing.
Ignore Cutoff Fence	Select to ignore the item's cutoff fence for the corresponding data type. If you do not select this option, the Post Updates process includes only changes and new orders that occurred prior to the calculated cutoff date.
Inside Tolerance	If an order date change is less than the item defined reschedule in or reschedule out range, define the action that the Post Updates process is to take. Values are: Error: The order shows up in the Review Post Errors Inquiry for the data type. The order cannot be applied to the transaction system. Approve: The order can be applied to the transaction system. Approves the order change automatically, overriding other approval options. Ignore: The order is not posted to the transaction system and the order does not appear in the Review Post Errors Inquiry for the data type. Accept: The order can be applied to the transaction system. The change goes through standard approval and validation.
Pegged Approval Option	The Post Messages and Exceptions process will be updated with these options for approving changes to pegged orders: Accept This system will ignore that the order is pegged. The order can be applied to the transaction system. The change goes through standard approval and validation. Approve This system will ignore that the order is pegged. The order can be applied to the transaction system. Approves the order change automatically, overriding other approval options. Error The order shows up in the Review Post Errors Inquiry for the data type. The order cannot be applied to the transaction system. Ignore The order is not posted to the transaction system and the order does not appear in the Review Post Errors Inquiry for the data type. Note. These options will only apply to orders that can be flagged as pegged.

Validation Options Tab

Select the Validation Options tab.

Approval Options	Specify whether the Post Updates process can approve changes automatically. Values are: Manually Approve: Select to approve all of the updates manually in their applicable components. Auto Approve All: Select to approve all updates automatically from the planning engine. Auto Approve Within Horizon: Select to approve all updates automatically from the planning engine based on the criteria that you define in the From Days, To Days, and Based On fields.
From Offset,To Offset and Based On	Enter an offset from the current date for the horizon and indicate whether the horizon is based on the Start Date, End Date, or Both. These fields are available for entry only when you select Auto Approve Within Horizon in the Approval Options field.
Approve Schedules	Select if you want the Post Updates process to approve orders for supplier scheduled items automatically. If you define the corresponding Approval Option as automatic, but you do not select this option, the Post Updates process does not automatically approve supplier scheduled items. If you define the approval option as Manually Approve, the Post Updates process ignores this option.
Allow Violation Approval	Select if you want the Post Updates process to apply the corresponding Approval Option to planned production or transfer orders that have violations. If you want to exclude planned production or transfer orders with violations from the Post Updates approval process, you should run the Demand Violations Extract process prior to running the Post Updates process. The Demand Violations Extract process adds entries in the SPL_VIOLATIONS table for planned production and transfer orders that are pegged to a lower level supply order with a violation.

Creating PeopleSoft Supply Planning Updates Reports

After you run the Post Updates process, you can create a report to display a list of updates from the planning engine, based on the selection criteria. On the Planning Updates report, you can review the new and changed orders generated by the Post Updates process for PeopleSoft Purchasing, Production, Inventory, and Order Management.

Note. PLS4011.SQR generates the output for the Planning Updates report.

Pages Used to Create PeopleSoft Supply Planning Updates Reports

Page Name	Object Name	Navigation	Usage
Planning Updates	PL_MESS_RPT	Supply Planning, Commit Plan, Planning, Planning Updates Report	Define the search criteria for the Planning Updates report, which enables you to review a list of planning updates generated by PeopleSoft Supply Planning.
Production	PL_MESS_RPT2	Supply Planning, Commit Plan, Planning, Planning Updates Report, Production	Select the production update reporting options for the Planning Updates report.
Purchase/Sales	PL_MESS_RPT3	Supply Planning, Commit Plan, Planning, Planning Updates Report, Purchase/Sales	Select the purchasing and order management update reporting options for the Planning Updates report.
Transfers/Stock Requests	PL_MESS_RPT4	Supply Planning, Commit Plan, Planning, Planning Updates Report, Transfers/Stock Requests	Select the inventory update reporting options for the Planning Updates report.

Defining the Planning Updates Report Search Criteria

Access the Planning Updates page.

Plan Unit Group	Define the criteria to include only updates for a specific plan unit group code.
Planner Code	Define the criteria to include only updates for a specific planner.
Item ID	Define the criteria to include updates associated with specific items.
Run	Click to access the PeopleSoft Process Scheduler page, where you can initiate the process to generate the Planning Updates report.

Message Type

Planned	Select to include planned supply orders.
Reschedule	Select to include rescheduled orders.
Canceled	Select to include canceled orders.
Substitute	Select to include production updates for component substitutions.

Report Options

Production	Select to include production updates on the report.
Stock Requests	Select to include stock request updates on the report
Transfers	Select to include inventory transfer updates on the report.
Purchases	Select to include purchasing updates on the report.
Sales Orders	Select to include sales order updates on the report.
Quotations	Select to include quotation updates on the report.
Buying Agreements	Select to include buying agreement updates on the report.

Status

Unapproved	Select to include updates that were not approved in a previous review sessions or via the Post Updates process
Expedite	Select to include updates that are required before the planning time fence for the item.
Approved	Select to include updates that were previously approved but not processed.
Accepted	Select to include updates that are required after the planning time fence but before the action message cutoff fence for the item.
Processed	Select to include updates that were previously approved and applied to the transaction system
Cutoff	Select to include updates for items that have updates beyond the action message cutoff fence defined for the item.
Tolerance	Select to include reschedules that occur within an interval bound by the reschedule in and out factors defined for the item. The system reports all of the orders rescheduled outside of the tolerance. Select Within Tolerance to report orders which are inside of tolerance.
Open Pegs	Select to include updates to orders that are pegged to unfulfilled demand.
No Open Pegs	Select to include updates to orders that are not pegged to unfulfilled demand

Defining Production Updates Report Search Criteria

Access the Production page.

Order Status

Entered	Select to include updates for entered orders.
Firmed	Select to include updates for firmed orders.
Released	Select to include updates for released orders.
In Process	Select to include updates for orders in process.

Production Class

Schedules	Select to include production schedules.
Production IDs	Select to include production IDs.
From/To	Define the criteria to include only those updates within the specified date range.

Defining Purchase/Sales Update Report Search Criteria

Access the Purchase/Sales page.

Purchases

Release Date From/To	Define the criteria to include only those updates within the specified date range.
Due Date From/To	Define the criteria to include only those updates within the specified date range.

Sales Orders

Scheduled Ship Date From/To

Define the criteria to include only those updates within the specified date range.

Buying Agreements

Scheduled Ship Date From/To

Define the criteria to include only those updates within the specified date range.

Defining Transfers/Stock Requests Update Report Search Criteria

Access the Transfers/Stock Requests page.

Transfers

Destination Unit	Specify a destination business unit to include only updates from that unit.
Destination Planner Code	Specify a destination planner code to include only updates from a specific destination planner.
Scheduled Ship Date From/To	Define the criteria to include only those updates within the specified date range.
Scheduled Arrival Date From/To	Define the criteria to include only those updates within the specified date range.

Stock Requests

Scheduled Ship Date From/To

Define the criteria to include only those updates within the specified date range.

Displaying Item Useup Information

This section provides an overview of item useup, and discusses how to:

Generate a PeopleSoft Supply Planning Useup report.
Review item useup information.

Understanding Item Useup

PeopleSoft Supply Planning enables you to plan for the end life of components and the beginning of life for their replacement components. Engineering changes, technical upgrades, and cost can create a need to replace a component.

Using PeopleSoft Supply Planning, you can:

Specify the phase-out date of the component.
Use up the remaining stock of the old component before introducing the new component into production.
Plan to purchase the new component (using the effectivity date), while using the old stock, until you deplete the old component supply.

Use the Item Useup inquiry page and Planning Updates report to obtain planning information about discontinued items (including the last change in the inventory position for the item and the expected ending quantity on hand at that point) and substitute items available to fulfill remaining demand for the item.

Phase-Out Dates

PeopleSoft Supply Planning considers an item's discontinuation date to be its phase-out date. On the Define Business Unit Item - General page, select Discontinue in the Current or Future status fields for items that you want to phase-out. If you define the Current date field with the value Discontinue, the system uses the effective date of the status as the phase-out date. If you defined the Future date field with the value Discontinue, the system uses the effective date of the future status as the phase-out date.

PeopleSoft Supply Planning does not generate new supply nor does it replenish safety stock levels after an item's phase-out date. If the item is required as a component in a production ID after the phase-out date, solvers use substitutes defined on BOM to fulfill any unsatisfied demand. If no available quantity on hand exists for a substitute, the solvers create new supply for the substitute.

Post Updates Process

The Post Updates process writes useup information back to PeopleSoft SCM. For each discontinued item, the Post Updates process publishes the last date that a supply or demand has occurred (the useup date), as well as the final inventory balance resulting from that change in inventory position (the useup quantity on hand). For configured items, the process publishes this data for each configuration code.

Pages Used to Create Useup Reports

Page Name	Object Name	Navigation	Usage
Planning Useup Report	PL_USEUP_RPT	Supply Planning, Commit Plan, Planning, Planning Useup Report	Define business unit and item parameters to generate a report displaying useup items, their phase-out dates, and their substitute items.
Review Planning Useup (inquiry)	PL_USEUP_ITEMS	Supply Planning, Commit Plan, Planning, Review Planning Useup	Review item useup details, such as effectivity dates, quantity on hand at the useup date, and availability quantities of substitutes.

Reviewing Item Useup Information

Access the Review Planning Useup inquiry page.

Item ID	Displays the parent item for the item being queried.
Useup Date	Indicates the projected useup date based on the last change in inventory position for the item.
Phase-Out Date	Indicates when useup logic should go into effect for the original component. After the phase-out date, solvers use supplies but do not replenish the stock for the original component.
Useup Quantity On Hand	Displays the projected quantity on hand at the time of the projected useup date.
Quantity Available	Displays the current quantity available from PeopleSoft Inventory.
Planning Date and Time	Displays the date and time of the last Post Updates process.

Component Where Used

Component ID	Indicates the name of the component being used in the corresponding operation sequence.
BOM State	Specifies whether the BOM is an engineering BOM or a production BOM.
BOM Type	Only BOM types defined as Production are visible in PeopleSoft Supply Planning. For rework and teardown BOM types, PeopleSoft Supply Planning uses the production ID for component and operation lists.
BOM Code	Displays the BOM used to generate the initial component list for the order.
Operation Sequence	Indicates where in the manufacturing process you need the component. The operation sequence refers to an operation on the assembly item's routing. The default operation sequence is 0, which is the first operation of the manufacturing process. Define the operation sequence on the item's routing by using the Routing Definition Summary page. If you set the operation sequence for all of the items to 0, the system assumes that all of the component items are needed at the beginning of production and therefore must be issued at the start of the first operation.
Standard UOM (standard unit of measure)	Displays the item's standard UOM defined in the transaction system. The system displays all of the quantities in PeopleSoft Supply Planning in the item's UOM.
Effective Date and Obsolete Date	Displays the effective and obsolete dates for the components on a BOM.

Substitute Items

Priority	Displays the substitution item priority rank.
Substitute Item ID	Displays the unique substitute item for the item. When you define substitutes for items on the Manufacturing BOMs - Components: Substitutes page, PeopleSoft Supply Planning automatically selects these substitutes when the quantity on hand for discontinued items runs out. If you do not define substitutes for items designated as discontinued, a shortage of that item might occur if demand exceeds the existing quantity on hand.
From Date and To Date	Displays the start and end date to indicate when the substitution is valid.
Rate	Indicates the quantity of the substitute item required to replace the original item in the item's standard UOM. The conversion rate can be different at the setID, business unit, and BOM levels.
Quantity Available	Displays the current quantity available from PeopleSoft Inventory or the substitute item.

Resetting the Locks for the Post Updates Process

If the system encounters an error during processing for a specific update type, it locks the Post Updates process. You must reset the locks before any other request can post updates for the update type for the corresponding business unit.

This section discusses how to reset the locks for the Post Updates process.

Page Used to Reset the Locks for the Post Updates Process

Page Name	Object Name	Navigation	Usage
Reset Post Locks	PL_BU_LOCK_MAINT	Supply Planning, Commit Plan, Planning, Reset Post Locks	Select orders locked by the Post Updates process.

Selecting Locked Orders

Access the Reset Post Locks page.

Process Date Time	Indicates the date and time that the Post Updates process was initiated.
Lock Status	Indicates if a given update type for the specific business unit is currently locked. Update types are locked during the post update process and released if the process completes successfully.