Understanding the Fulfillment Engine

The fulfillment engine in PeopleSoft Inventory enables users to move orders from one fulfillment state to another fulfillment state with one easy user-defined process. The options for order fulfillment include:

Using run control pages.

All of the fulfillment processes, from the Reserve Materials process to the Shipping Requests process are designed to streamline the orders using the fulfillment engine.
Entering data on online pages.
The Fulfillment Workbench component and the Packing page enable you to enter requests to move stock orders and sales orders from one fulfillment status to another. Requests are placed in staging tables and then processed by the fulfillment engine using the Fulfillment Requests process.
Using external interfaces.

Data from external systems can be processed through the PeopleSoft Integration Broker. These requests are placed in staging tables and then processed by the fulfillment engine using the Fulfillment Requests process. These messages can:
- Request to move material stock orders and sales orders from one fulfillment status to another.
- Request to create new material stock requests or add new demand lines to an existing material stock request.

The fulfillment engine processes fulfillment transaction requests created by the online pages, external interfaces, and run control pages. These fulfillment requests identify the demand data to be changed; for example, moving material stock requests and sales orders from one fulfillment status to another. It is important to note that these fulfillment transaction requests are not orders but instructions to be applied to the Inventory demand tables. For example, you can enter a transaction request to create a new material stock request or enter another transaction request to move all orders to a shipped status with the carrier ID FEDEX and the scheduled ship date of today. The request is applied against the PeopleSoft Inventory demand tables by the fulfillment engine and the action is completed. The fulfillment transaction requests have this structure:

Level	Description
Header	Contains fulfillment transaction request header information.
Group	Contains fulfillment transaction request group level information. One request can contain one or more groups.
Detail	Contains fulfillment transaction request detail level information within a group.
LLS	Contains picking location, lot ID, serial ID, and staged-date information, plus staged date information.

Group Processing

The fulfillment engine is a PeopleSoft Application Engine program that uses a style of processing that works on groups of data as opposed to working on one row of data at a time. This technique maximizes performance when working with large quantities of data. Each fulfillment transaction request has one request header and at least one group record. When creating these group records, users have the added flexibility of defining exceptions and overrides to the group of demand lines. The main group selection information is defined at a group level on the fulfillment transaction request, while detail exceptions are defined at the detail level. The LLS level defines additional information about the request when exceptions have been defined at a detail level for a specific demand line.

Term	Definition
Group Level	Fulfillment requests consist of one or more groups. When creating the fulfillment request, you define the group. In its simplest form, the group level is an order and a detail level is a specific order line. However, flexibility exists to define a group as being just about any selection criteria used within the fulfillment system. Examples of a group include an order number, load ID, carrier ID, pick batch ID, or shipping container ID. It is important to note that when you define information at the group level, all demand lines meeting that selection criteria are processed. For example, if you want to ship all demand lines on a 1000 line order, then all you need to do is to create a group level containing that order number. If you want to exclude order lines or you want to process partial quantities on order lines, then you would add detail level entries to the fulfillment request only for those specific order lines in which you have exceptions. All other order lines are processed completely. Information overriding specific fields on the demand lines being processed can also be entered at the group level. For example, on a shipping request you may want to assign a specific pro-number. By entering this information at the group level, all demand lines processed within this group are assigned that pro-number. Note: Override information can be entered at the group level on fulfillment engine EIPs and the Fulfillment Workbench only. When using the run control requests process pages to initiate fulfillment requests, the override information applies to the full request.
Detail Level	The detail level enables you to further refine the group level selection by providing exceptions to demand lines within the group level definition. This level usually contains demand line level information; however, all group level selection criteria is available at the detail level. This flexibility enables you to define exceptions for individual demand lines or for groups of demand lines. The detail level can be used to: Include Enter individual demand lines or groups of demand lines at the detail level to add additional demand lines to the fulfillment request. For example, if you wanted to ship a full load ID but add an additional order at the last minute, you could enter the load ID at the group level and then enter the added order number at the detail level. This would allow the full shipment to be shipped under the same ship ID, and any override information entered at the group level would be applied to the added demand lines entered at the detail level. Exclude Enter individual demand lines or groups of demand lines to be excluded from the selection criteria entered at the group level. For example, if the group level is defined as a particular load ID, then the detail level can be used to exclude a specific order in that load. Demand lines being excluded at the detail level must exist within the selection criteria entered at the group level. Exclude is not a valid option when you are create new materials stock request demand lines. Process partial quantities Enter exceptions to process partial quantities on demand lines. For example, if order MSR0000100 is being shipped, but order line number 55 is being shipped short, then you would create a group level containing order number MSR0000100, and then add a detail level for line 55 containing the quantity that actually shipped on that line. Note: When entering exceptions referencing a specific demand line, the quantity and UOM provided at the detail level is used in place of the values that currently exist in the system for that demand line. The exception to this rule is when using the "exclude" option. Demand lines being excluded are always excluded completely, so the quantity and UOM fields are never used in this situation. Note: A detail level entry is referencing a specific demand line if one of four combinations of selection criteria is entered. The four combinations are the full demand key, pick batch ID and pick batch line number, external reference ID and external reference line number, and the TMS reference ID and TMS reference line number. Note: When the selection criteria is processing a group of demand lines, then the open order quantity on the demand lines in the demand tables is used when processing the demand lines. Fulfillment requests that define group information at the detail level are rejected if values are entered in the quantity and UOM fields.
LLS	The LLS entry is used to further identify instructions on how a transaction should be processed. Information such as material storage locations, lot ID, serial ID, staged dates, and storage containers are carried at this level. Note: Transactions shipping from an unfulfilled or releasable state that reference items under lot, serial, or staged date control must provide LLS level information.

Term

Definition

Group Level

Fulfillment requests consist of one or more groups. When creating the fulfillment request, you define the group. In its simplest form, the group level is an order and a detail level is a specific order line. However, flexibility exists to define a group as being just about any selection criteria used within the fulfillment system. Examples of a group include an order number, load ID, carrier ID, pick batch ID, or shipping container ID.

It is important to note that when you define information at the group level, all demand lines meeting that selection criteria are processed. For example, if you want to ship all demand lines on a 1000 line order, then all you need to do is to create a group level containing that order number. If you want to exclude order lines or you want to process partial quantities on order lines, then you would add detail level entries to the fulfillment request only for those specific order lines in which you have exceptions. All other order lines are processed completely.

Information overriding specific fields on the demand lines being processed can also be entered at the group level. For example, on a shipping request you may want to assign a specific pro-number. By entering this information at the group level, all demand lines processed within this group are assigned that pro-number.

Note: Override information can be entered at the group level on fulfillment engine EIPs and the Fulfillment Workbench only. When using the run control requests process pages to initiate fulfillment requests, the override information applies to the full request.

Detail Level

The detail level enables you to further refine the group level selection by providing exceptions to demand lines within the group level definition. This level usually contains demand line level information; however, all group level selection criteria is available at the detail level. This flexibility enables you to define exceptions for individual demand lines or for groups of demand lines. The detail level can be used to:

Include
Enter individual demand lines or groups of demand lines at the detail level to add additional demand lines to the fulfillment request. For example, if you wanted to ship a full load ID but add an additional order at the last minute, you could enter the load ID at the group level and then enter the added order number at the detail level. This would allow the full shipment to be shipped under the same ship ID, and any override information entered at the group level would be applied to the added demand lines entered at the detail level.
Exclude
Enter individual demand lines or groups of demand lines to be excluded from the selection criteria entered at the group level. For example, if the group level is defined as a particular load ID, then the detail level can be used to exclude a specific order in that load. Demand lines being excluded at the detail level must exist within the selection criteria entered at the group level. Exclude is not a valid option when you are create new materials stock request demand lines.
Process partial quantities

Enter exceptions to process partial quantities on demand lines. For example, if order MSR0000100 is being shipped, but order line number 55 is being shipped short, then you would create a group level containing order number MSR0000100, and then add a detail level for line 55 containing the quantity that actually shipped on that line.

Note: When entering exceptions referencing a specific demand line, the quantity and UOM provided at the detail level is used in place of the values that currently exist in the system for that demand line. The exception to this rule is when using the "exclude" option. Demand lines being excluded are always excluded completely, so the quantity and UOM fields are never used in this situation.

Note: A detail level entry is referencing a specific demand line if one of four combinations of selection criteria is entered. The four combinations are the full demand key, pick batch ID and pick batch line number, external reference ID and external reference line number, and the TMS reference ID and TMS reference line number.

Note: When the selection criteria is processing a group of demand lines, then the open order quantity on the demand lines in the demand tables is used when processing the demand lines. Fulfillment requests that define group information at the detail level are rejected if values are entered in the quantity and UOM fields.

LLS

The LLS entry is used to further identify instructions on how a transaction should be processed. Information such as material storage locations, lot ID, serial ID, staged dates, and storage containers are carried at this level.

Note: Transactions shipping from an unfulfilled or releasable state that reference items under lot, serial, or staged date control must provide LLS level information.

Transaction Based Requests vs Run Control Based Requests

The fulfillment engine can process run control based fulfillment requests or transaction based fulfillment requests. Each method has benefits in different procedural environments.

Term	Definition
Transaction Based Run Requests	When using transaction based fulfillment requests, each request is assigned a control ID that is tracked and controlled so that there is a history of the work being performed. If errors are found, the transaction request is rejected and users follow up by either reprocessing the transaction request after the error is fixed or by canceling the request. A series of staging tables and error handling pages are in place to manage this process. A fulfillment transaction request could be used when: Fulfillment transaction requests are fed from external systems. Higher volume shipping operations use the Fulfillment Workbench to generate shipping transaction requests. The Fulfillment Workbench can be configured for simple data entry of an order number at a shipping station. The order number is entered or scanned from a bar code label, and the transaction request is generated. From that point on, the transaction request is tracked to ensure that it is processed successfully. Shipping station personnel can immediately continue their work processing the next shipment, knowing that the system will provide an audit trail of the work performed on each transaction request. Processing large orders. When processing large orders, a transaction request can be used to enable processing in a background mode, freeing you up to work on the next transaction request. Because all fulfillment transaction requests are tracked in the staging tables, control is provided to ensure that all requests are processed successfully. Multiple group levels must be processed. You can use a transaction request when processing multiple group levels because the run control request allows processing of only a single group level. Exceptions must be entered. You can use a transaction request when entering exceptions because the run control request does not allow entry of detail level information.
Run Control Based Run Requests	When using run control based fulfillment requests, the transaction request record is created and passed on to PeopleSoft Process Scheduler. PeopleSoft Process Scheduler initiates the fulfillment engine and processes the data. If any errors are found, the appropriate error message is sent to the message log and can be viewed from the process monitor. When initiating the fulfillment engine from a run control request, you can enter only group level information. Only a single group can be processed at any one time. A run control fulfillment request could be used when: Processing work on a scheduled basis from PeopleSoft Process Scheduler. For example, if you must run reservations processing each night for a full business unit, then you can set up a reservations run control request using the Reserve Materials Process page. The request would be scheduled to run at the appropriate time each night using PeopleSoft Process Scheduler. Handling a low volume of fulfillment requests, where tracking and control of requests can be managed by viewing the process monitor. Processing large orders. When processing large orders, you can use the run control request to enable processing of the demand lines in a background mode. This frees you up to do other work.

Term

Definition

Transaction Based Run Requests

When using transaction based fulfillment requests, each request is assigned a control ID that is tracked and controlled so that there is a history of the work being performed. If errors are found, the transaction request is rejected and users follow up by either reprocessing the transaction request after the error is fixed or by canceling the request. A series of staging tables and error handling pages are in place to manage this process.

A fulfillment transaction request could be used when:

Fulfillment transaction requests are fed from external systems.
Higher volume shipping operations use the Fulfillment Workbench to generate shipping transaction requests.
The Fulfillment Workbench can be configured for simple data entry of an order number at a shipping station. The order number is entered or scanned from a bar code label, and the transaction request is generated. From that point on, the transaction request is tracked to ensure that it is processed successfully. Shipping station personnel can immediately continue their work processing the next shipment, knowing that the system will provide an audit trail of the work performed on each transaction request.
Processing large orders.

When processing large orders, a transaction request can be used to enable processing in a background mode, freeing you up to work on the next transaction request. Because all fulfillment transaction requests are tracked in the staging tables, control is provided to ensure that all requests are processed successfully.
Multiple group levels must be processed.
You can use a transaction request when processing multiple group levels because the run control request allows processing of only a single group level.
Exceptions must be entered.

You can use a transaction request when entering exceptions because the run control request does not allow entry of detail level information.

Run Control Based Run Requests

When using run control based fulfillment requests, the transaction request record is created and passed on to PeopleSoft Process Scheduler. PeopleSoft Process Scheduler initiates the fulfillment engine and processes the data. If any errors are found, the appropriate error message is sent to the message log and can be viewed from the process monitor. When initiating the fulfillment engine from a run control request, you can enter only group level information. Only a single group can be processed at any one time.

A run control fulfillment request could be used when:

Processing work on a scheduled basis from PeopleSoft Process Scheduler.
For example, if you must run reservations processing each night for a full business unit, then you can set up a reservations run control request using the Reserve Materials Process page. The request would be scheduled to run at the appropriate time each night using PeopleSoft Process Scheduler.
Handling a low volume of fulfillment requests, where tracking and control of requests can be managed by viewing the process monitor.
Processing large orders.

When processing large orders, you can use the run control request to enable processing of the demand lines in a background mode. This frees you up to do other work.

Transaction Based Requests and the Staging Tables

Processing fulfillment transaction requests using online pages, EIPs, and run controls

The Fulfillment Workbench and the Packing Sessions pages enable you to enter fulfillment transaction requests using online pages. The Fulfillment Workbench can move material stock orders and sales orders from an any fulfillment state to a downstream state. The Packing Sessions page can move an order from a confirmed state to a shipped state.

Data from external systems can be processed through the PeopleSoft Integration Broker. PeopleSoft delivers five asynchronous service operations: Inventory_Create_Stock_Request, Inventory_Reservation, Inventory_Pick_Confirm, Inventory_Front_End_Shipping, and Inventory_Shipping. These EIPs enable you to post data to the Integration Broker and receive a response indicating that the data has been received. These EIP messages can:

Request to move material stock orders and sales orders from one fulfillment status to another downstream fulfillment state.
Request to create new material stock requests or add new demand lines to an existing material stock request. This point applies only to the Inventory_Create_Stock_Request, Inventory_Front_End_Shipping, and Inventory_Shipping service operations.

Both the online pages and the external interfaces create fulfillment transaction requests. These requests identify the demand data to be changed. It is important to note that fulfillment transaction requests are not orders but instructions to be applied to the PeopleSoft Inventory demand tables. For example, you can enter a transaction request to create a new material stock request or enter another transaction request to move all orders to a shipped status with the carrier ID FEDEX and the scheduled ship date of today. The request is applied against the PeopleSoft Inventory demand tables by the fulfillment engine and the action is completed.

Fulfillment Request Handler, a PeopleTools application class, takes the requests entered on the online pages or sent through the external interfaces, formats them, and populates the staging tables. For each request, the Fulfillment Request Handler assigns a unique ID, EIP_CTL_ID, based on the BCT setup transaction number defined on Data Collection page for the business unit or generates an unique ID using instructions from the external message. If the Auto Schedule Processing check box has been selected on the Setup Fulfillment - Fulfillment Engine page or the Fulfillment Workbench, then the Fulfillment Request Handler also schedules the Fulfillment Requests process to run immediately against the fulfillment transaction requests.

Note: The Auto Schedule feature is not available on the Packing Session page.

Requests are stored in staging tables. These staging tables hold the initial fulfillment transaction requests and any errors encountered when the request is processed by the fulfillment engine.

The Fulfillment Requests process page retrieves the requests from the staging tables and applies them to the PeopleSoft Inventory demand tables. If the requests are successfully processed against the PeopleSoft Inventory demand tables, then the requests are set to a status of complete. If the requests are not processed successfully, they are given an error status, and the appropriate error message is provided.

The Maintain Transactions component enables you to view and correct requests that contain errors. Once corrected, you can relaunch the Fulfillment Requests process. This is an optional step, you can choose to have the request errors canceled automatically, and then you could recreate another request.

The Purge process (IN_BCT_PURGE ) for data exchanges can also remove fulfillment transaction requests marked as complete or confirmed from the staging tables based on criteria that you define.

Staging Tables Used for the Fulfillment Engine

The staging tables are designed to be a temporary holding area for unprocessed requests and those in error. The staging tables are:

Term	Definition
BCT_CTL	Contains control information identifying request source and status.
BCT_DTL	Contains fulfillment request transaction header information.
INV_FUL_GRP_EC	Contains fulfillment request group level information.
INV_FUL_DTL_EC	Contains fulfillment request detail level information. This record could contain demand line level information or data to be excluded from the request (for example, at the group level you could have defined a carrier, and then at the detail level you could enter a specific order number to exclude).
INV_FUL_LLS_EC	Contains picking location, lot ID, and serial ID information.
TSE_BCT_FLD	Contains any errors encountered when processing the fulfillment transaction request.

Each transaction written to the staging tables consists of the following hierarchy: a single BCT_CTL row, a single BCT_DTL row containing header level information, one or more INV_FUL_GRP_EC rows containing group level information, one or more INV_FUL_DTL_EC rows usually containing demand line information, and one or more INV_FUL_LLS_EC rows containing picking locations, lot IDs, and serial IDs.

Fulfillment requests are stored into the staging tables using these transaction codes:

Transaction Code	Descriptions	Used by
0360	Create Stock Request	The Inventory_Create_Stock_Request EIP from external systems.
0361	Reserve	The Fulfillment Workbench and the Inventory_Reservation EIP from external systems.
0363	Picking Feedback	The Fulfillment Workbench (action of Pick Confirm) and the Inventory_Pick_Confirm EIP from external systems.
0365	Front-end Ship	The Fulfillment Workbench and the Inventory_Front_End_Shipping EIP from external systems.
0366	Ship	The Fulfillment Workbench, Packing Session page, and Inventory_Shipping EIP from external systems.

Run Control Based Requests

All run control process pages in inventory order fulfillment initiate the fulfillment engine. For run control process pages, the fulfillment transaction requests are applied directly to the inventory demand tables; the staging tables are not used. Like all run controls, these processes can be scheduled to run one time or on a recurring basis. Any errors in the requests are placed in the Message Log for viewing. When initiating the fulfillment engine from a run control process page, only group level information can be provided. If detail information is required to include exceptions to the group level, then you must create a fulfillment transaction request using the Fulfillment Workbench or an fulfillment engine EIP.

Fulfillment Engine Error Handling

The fulfillment engine provides a number of alternatives for handling errors. This is necessary because many of the error conditions are not related to information entered on individual requests but are due to issues with demand lines that cannot be moved to the destination state defined in the fulfillment request. The fulfillment engine does identify errors; however, you'll need to correct these errors using pages in PeopleSoft Inventory.

Here are the components that you can use to view and, in most cases, correct errors found by the fulfillment engine:

Maintain Transactions
This component enables you to view and correct fulfillment transaction requests that contain errors. When a transaction is rejected due to errors, it is set to an error status. The transaction can then be viewed using the Maintain Transactions component. If the transaction has multiple group, detail, or loc/lot/serial segments, then only the segments in error and the parents of those segments are marked with an error status. Segments without errors or without children with errors remain in an open status. You can then search for only those segments in error to quickly find the error. Once corrected, you can relaunch the Fulfillment Requests process.

The Log Errors option on the Setup Fulfillment - Fulfillment Engine page provides an alternative for handling rejected transactions. When this option is set to Message Log, error messages are written to the message log and the transaction is canceled. This option would be used at sites that do not need to follow up on every transaction. As errors are found in the message log, fixes are made using online pages, such as the Shipping/Issues page, where the problem is not only resolved but also shipped complete at the same time. Because the transaction in the staging table has already been canceled, no additional follow up in the Maintain Transactions component is necessary.
Process Monitor Message Log
This component enables you to view messages that are inserted into the message log by the fulfillment engine. This page cannot be used to correct errors.
Correct Demand Errors
This component enables you to view and correct errors that occur when the fulfillment engine attempts to move unfulfilled orders to a releasable or shipped status.
Bar Code Transaction Errors Workflow
Select the worklist entry. When you do, the system transfers you to the Transaction Error page, where you can view and correct the errors in barcode transactions. This application engine workflow process checks for barcode transactions that have an error status and generates a worklist entry.