Setting Up the Fulfillment Engine Processing Options

Auto Schedule Processing

Select to immediately process the requests. The Fulfillment Requests process is launched when the requests are posted to the staging tables. This option is used when processing EIP messages and Fulfillment Workbench requests.

Release Additional Locks

Select to instruct the fulfillment engine to release any locks not identified by the first processing group of data determined at run time. If this option is cleared, then all fulfillment transaction requests and demand lines meeting those requests are soft locked until they are finished processing. When the locks are released using this option, both fulfillment transaction requests and demand lines that were not included in the initial processing group are released to be processed by concurrent fulfillment engine processes.

Perform Validation

Select to have the fulfillment engine validate data loaded into the demand table (IN_DEMAND) by external applications.

Log Errors Option

There are two options:

• Transaction Error Log: Transaction request errors are kept in the staging tables and set to a status of error.

  Use the Transaction Maintenance page to view and correct these requests for resubmitting to the fulfillment engine.

• Message Log: Transaction request errors should be logged to the message log and the status of those transactions changed to cancel.

  This prevents fulfillment transactions from ever being set to error status in the staging tables.

Allow Processing Overrides

Select to enable the user to override the Processing Level, Processing Count, Commit Level, and Commit Count fields where provided on the Fulfillment Workbench, fulfillment process pages, and external messages.

Processing Count

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.

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

Commit Count

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.

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

Allow Pass-through Overrides

Select to enable the user to override the pass through level on the Fulfillment Workbench, fulfillment process pages, and the fulfillment engine EIPs.

Pass-through Level

Provides the ability to pass good transactions through the system while holding up transactions that need additional review. On the request pages and on the transactions, the pass through level can have these values:

• Request: Any errors in the transaction request prevent the entire request from being processed

• Order: Any errors on any line in the order prevent the whole order from being processed.

• Line: Errors prevent only the line with the error from being processed.

From a processing standpoint, the pass through level must be less than or equal to the processing level and commit level. If the fulfillment engine receives a pass through level greater than the specified commit level or processing level, the commit group or processing group is expanded to include all data at the pass through level.

Allow State Overrides

Select to enable the user to override the from fulfillment status of the orders in the group. This applies to the Order Release Request process, Front-end Shipping Requests process, Shipping Requests process, and the fulfillment engine EIPs for front-end shipping and shipping.

Allow Auto-Processing Override

Select to enable the user to override the auto-processing option on process page, Fulfillment Workbench, or request transactions from an EIP.

Auto Processing Option

Select the auto processing option to move your orders downstream to the desired state. Options include:

• No Auto-Processing: Select to have the system only complete the process or action that you are initiating on the current page.

  No additional processing will be launched.

• Advance to Released: Select to automatically process the orders to the released state from the Reserve Materials process, Create/Update Stock Request component, the Fulfillment Workbench (when using the reserve action), and Inventory Reservation EIP.

  The parameters defined on the Auto Release Run Control are used to process the orders through the Order Release Request process. These parameters could release the orders further downstream based on the Auto-Processing Option field.

• Advance to Confirmed: Select to automatically process the orders to the picking confirmed state from the Order Release Request process page, Material Picking Feedback page, the Fulfillment Workbench (when using the pick confirm action), and the Pick Confirm EIP.

• Advance to Shipped: Select to automatically process the orders to the shipped state from the Order Release Request process page, Material Picking Feedback page, the Fulfillment Workbench (when using the pick confirm action), and the Pick Confirm EIP.

• Advance to Depleted: Select to automatically process the orders to the depleted state from the Order Release Request process page, Material Picking Feedback page, Picking Confirmation process, Front-end Shipping Request process, Shipping Request process, the Fulfillment Workbench (when using any action except reserve), and all of the fulfillment engine EIPs except reserve.

Auto Release User ID

Enter any user IDs that has created a run control for the Order Release Request process page.

Auto Release Run Control

Select any run control for the Order Release Request process page defined by the user entered in the Auto Release User ID field to the left. This run control contains the parameters to be used when auto-processing orders from an unfulfilled state to another downstream state. The Auto-Processing Option field on the Order Release Request determines how far downstream the orders will be sent.

To find the correct value for this field and the Auto Release User ID field, the system first looks for a value on:

1. The current run control. If these fields are blank, then the system looks to:

2. The Auto-Processing Options tab of the Setup Fulfillment-Fulfillment Task Options page. If these fields are blank, then the system looks to:

3. The Setup Fulfillment page. If these fields are blank, then the system looks to:

4. The Auto-Processing Options tab of the Fulfillment Engine Options page. If these fields are blank, then no auto release is done.

Auto Process at Save

Select this check box to launch the auto-processing option when the online page is saved. The online pages include Create/Update Stock Request component, Material Picking Feedback page, Express Issue page, and the Shipping/Issues page.

Complete Flag

Choose a Complete Flag option to automatically performing picking functionality on demand lines that have no previous picking activity reported against them. The LLS segment and the override location are applied prior to implementing the complete flag logic. Using the Complete Flag, the line can be moved to different sub-states within the Released state, or, with auto-processing, moved downstream to the shipped or depleted states. The complete flag is used for run control pages, fulfillment engine transaction requests, the Fulfillment Workbench, and the Inventory Picking EIP. The Complete Flag options are:

• No Action: Takes no action on demand lines that have no previous picking activity reported against them.

• Complete Pick- Dft Ship Loc: Uses the default shipping location as the pick location for demand lines that do not already have the Confirm Flag set.

  The default shipping location is stored at both the business unit and business unit/item levels.

• Complete Pick- Leave Alone: With this option any lines within the selection criteria that do not have the Confirm Flag set are left alone.

  The Confirm Flag is not set on these demand lines.

• Complete Pick- Zero Quantity: Sets the zero picked flag for every line within the selection criteria if they do not already have the Confirm Flag set. Also removes and deallocates any current allocations.

• Pick Batch Complete: Removes every line within the selection criteria from the pick batch ID if they do not already have the Confirm Flag set.

• Pick Batch as Planned: Sets the Confirm Flag on any line that has had picking activity.

  In this situation picking activity is assumed to be satisfied if there are any allocations as well as if the demand line is a zero picked demand line. An error is generated for any lines that have not had any picking activity when using this option.

• Pick Line Complete: Removes the line from the pick batch ID if the Confirm Flag is not already set. It is only valid when referencing an individual pick/batch line at the group or detail level.

• Pick Line as Planned: Sets the Confirm Flag on any line that has had picking activity.

  In this situation picking activity is assumed to be satisfied if there are any allocations as well as if the demand line is a zero picked demand line. An error is generated for any lines that have not had any picking activity when using this option. This option is only valid when referencing a pick/batch line at the group or detail level.

Allow Kit Re-Explode Overrides

Select to enable the user to override the default settings for the Execution Mode and the Kit Effective Date on the Kit Re-Explode process page.

Execution Mode

Choose the action to be performed by the Kit Re-Explode process. The option are:

• Report Only: Generates a listing the differences between the kit components on the order to the current product kit definition.

  This listing can be viewed on the Kit Re-Explode Results inquiry page.

• Report and Re-Explode: This option:

  • Generates a listing the differences between the kit components on the order to the current product kit definition to be viewed on the Kit Re-Explode Results inquiry page.

  • Changes the order to match the current product kit definition by adding or deleting demand lines containing kit components.

Kit Effective Date

Select the date of the component kit demand lines to be compared to the date range (effective date and obsolete date) on the Product Kit Summary page. The demand line dates are:

• Order Date

• Schedule Date

• Ship Early Date

• Today's Date

Auto Schedule Processing

Yes

Yes

Yes

Release Additional Locks

Yes

Yes

Perform Validation

Yes

Log Errors Option

Yes

Allow Processing Overrides

Yes

Yes

Yes

No

Processing Count

Yes

Yes

Yes

Yes

Processing Level

Yes

Yes

Yes

Yes

Commit Count

Yes

Yes

Yes

Yes

Commit Level

Yes

Yes

Yes

Yes

Allow Pass through Overrides

Yes

Yes

Yes

No

Pass through Level

Yes

Yes

Yes

Yes

Allow State Overrides

Yes

Yes

Yes

No

Allow Auto-Processing Override

Yes

Yes

Yes

No

Auto Processing Option

Yes

Yes

Yes

Yes

Auto Release User ID

No

Yes

Yes

No

Auto Release Run Control

No

Yes

Yes

Yes

Auto Process at Save

Yes

Yes

Yes

No

Allow Kit Re-Explode Overrides

Yes

Yes

Yes

Execution Mode

Yes

Yes

Yes

Yes

Kit Effective Date

Yes

Yes

Yes

Yes

Auto Schedule Processing

The system-defined value is No.

Release Additional Locks

The system-defined value is No.

Allow Processing Overrides

The system-defined value is No.

Processing Count

The system-defined value is zero.

Processing Level

The system-defined value is Line.

Commit Count

The system-defined value is zero.

Commit Level

The system-defined value is Line.

Allow Pass-through Overrides

The system-defined value is No.

Pass-through Level

The system-defined value is Demand Line for reserve transactions and Request for shipping transactions.

Allow State Overrides

The system-defined value is No. The following states are set:

• For reservations, the only from state is Unfulfilled.

• For Order Release, the default from state is Releasable.

• For Picking Confirmation, the default from state is Released.

• For front end shipping, the default from state is Unfulfilled and Releasable.

• For shipping, the default from state is Confirmed.

Allow Auto-Processing Override

The system-defined value is No.

Auto Processing Option

The system-defined value is No Auto-Processing.

Auto Process at Save

The system-defined value is No.