What are Processing Options for Fulfillment?
(Doc ID 2484686.1)
Last updated on JANUARY 24, 2020
Applies to:PeopleSoft Enterprise SCM Inventory - Version 9.2 and later
Information in this document applies to any platform.
What are Processing Options for Fulfillment?
The processing options are to group fulfillment processing into smaller processing blocks as to not over burden a DB with a single larger number of commits.
Setting Up the Fulfillment Engine Processing Options
Enter the number of lines that can be processed together by the fulfillment engine; in other words, define the size of the processing group. The processing count is used to tune an inventory environment that is running into database contention issues. A processing group should be defined to be smaller than the large fulfillment transaction requests of your environment. If the Processing Count field is blank or zero, then all the data identified by the transaction request is included in one processing group.
A processing group breaks up the request into smaller chunks for processing, consequently reducing table locks and contention issues. For example, with a processing count of 500, the system processes rows in groups of 500. If the transaction request includes 1,050 rows of data, the system process the data in 3 processing groups, 2 groups of 500 rows, and 1 group of 50 rows at the end of the process.
Note: If the fulfillment engine receives a commit count greater than the specified processing count and the processing level is the same as the commit level, then the processing count is set to the commit count. Also, if the pass through level field is greater than the value specified in the Processing Level field, then the processing group is expanded to include all data at the pass through level.
Determines how the system counts rows to reach the number entered in the Processing Count field. For example, with a processing count of 500 and a processing level of Order, the process would create a processing group per every 500 order numbers. You can create processing groups based on:
Request: The number of separate fulfillment transaction requests.
Order: The number of separate orders (material stock requests and sales orders).
The system reorganizes the demand lines by order number and then processes each group separately. This reorganization of the data rows before processing could change the processing results. For example, if insufficient supply exists to fulfill the demand, the Reserve Materials process could change the allocation of stock and even override demand prioritization rules.
Line: The number of demand lines.
Note: When the Processing Count field is not blank or zero, the Processing Level must be greater than or equal to the Commit Level field.
Enter the number of lines that can be committed to the database together by the fulfillment engine; in other words, define the size of the commit group. The commit count is used to tune an inventory environment that is running into database contention issues. A commit group is a subset of the processing group; therefore, the Commit Count field should be the same as or smaller than the value in the Processing Count field. If the Commit Count field is blank or zero, then all the data rows identified in the processing group are committed to the database together.
A commit group should break up the processing group into smaller chunks for committing to the database. For example, if you use a processing count of 500 and a commit count of 100, the system breaks up the transaction request of 1,050 data rows into 3 processing groups: 2 groups of 500 rows and 1 group of 50 rows. Each processing group is then broken up into commit groups of 100 rows each. The first 2 processing groups are divided into 5 commit groups each and the last processing group of 50 rows is 1 commit group. The system then commits the data to the database using 11 commit groups in total.
Note: If the fulfillment engine receives a pass through level field that is greater than the value specified in the Commit Level field, then the commit group is expanded to include all data at the pass through level.
Determines how the system counts rows to reach the number entered in the Commit Count field. For example, with a commit count of 100 and a commit level of Item, the system issues a commit to the database for every 100 item IDs. You can issue commits based on:
Request: The number of separate fulfillment transaction requests processed.
Order: The number of separate orders (material stock requests and sales orders) processed.
Line: The number of demand lines processed.
Item: The number of item IDs processed.
Note: When the Commit Count field is not blank or zero, the commit level must be less than or equal to the processing level.
These options have default values in setup >>>
Each run control can override with the processing options link in deplete run control
There are several processing options to be defined for the fulfillment engine. These options are defined in a default hierarchy. At each level, you can define processing options for the run control pages, the online pages, and the external interfaces. When the fulfillment engine needs to process transactions, it finds the necessary processing options by using the following default hierarchy:
The system looks to the run control page or online pages for overrides to the fulfillment engine default options. If overrides are not allowed or no entries are made, then the system looks to the business unit level.
Business unit level
The system looks to the Setup Fulfillment - Fulfillment Engine Options component defined for the PeopleSoft Inventory business unit. If a default is not defined at this level for a particular option, then the system looks to the set ID level.
Set ID level
The system looks to the Fulfillment Engine Options component defined by set ID. This is linked to one or more PeopleSoft Inventory business units on the TableSet Control - Record Group page using the record group, IN_17, Fulfillment Engine Options. If a default is not defined at this level for a particular option, then the system uses the system-defined options.
If any of the processing options are not found, then the system-defined options are used.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document