Posting PeopleSoft Supply Planning Updates to the Transaction System

After 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.

Page Name	Definition Name	Usage
Post Updates Page	PL_POST_REQ	Extract new orders and changes to existing orders from the planning instance. Validate and stage orders for application to the transaction system.

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:

Term	Definition
Planned Order Status	Planned orders must have a status of Planned or Firmed. Canceled planned POs are posted for supplier 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.

Term

Definition

Planned Order Status

Planned orders must have a status of Planned or Firmed. Canceled planned POs are posted for supplier 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.

If you selected Selected by Planning Instance in the Items field on the Post Updates page and entered a business unit, the process deletes all of the records for items in the business unit that it locates in the PL_BU_ITEMS table.

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. Change a schedule quantity.	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. PO quantity is less than the received quantity.
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. Change the header start or end quantity.	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).

Use the Post Updates page (PL_POST_REQ) to extract new orders and changes to existing orders from the planning instance.

Validate and stage orders for application to the transaction system.

Navigation:

Supply Planning > Commit Plan > Planning > Post Updates

Common Information

Field or Control	Description
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:

Field or Control

Description

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.

Planning Engine

The system restarts the planning engine at the end of the process so that links that show supply and demand appear on approval pages.

Field or Control	Description
Pre-Post Auto-Shutdown	Select to stop the planning engine before running the Load Planning Instance process.
Post-Process Auto-Startup	Select to start the planning engine after you run the Load Planning Instance process.
URL (uniform resource locator)	Specify the location of a planning server where you want to start the planning engine after the Load Planning Instance has finished. If you do not specify a URL here, the system uses the default URL.
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.

Field or Control	Description
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.

Field or Control	Description
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.
Expedite Options	Select an option for the Post Update process to consider. Additionally, this process also checks supplier lead times. If planned or changed purchase order messages are within the supplier lead time, the system marks the message Expedite and you define the expedite option using the Expedite Options column. Values include: Planning Time Fence: Select to have the system consider the planning time fence and flag planning messages to be expedited that are within the time fence. If a change has occurred to a purchase order within the planning time fence, the system marks that change message as expedite in the Post Updates process. supplier Lead Time: Select to have the system consider supplier lead times and flag planning messages to be expedited that are within the lead time. If a change has occurred to a purchase order within the supplier's lead time, the system marks that change message as expedite in the Post Updates process.