Item based allocation

The Item Based Allocation transaction allocates unpromised and promised demands of existing orders to more suitable supplies based upon inventory items and nodes which have been triggered for the Item Based Allocation process in the YFS_IBA_TRIGGER table.

Note: When the Promising server is being used, this functionality is not supported on either the Order server or Promising server.

The Item Based Allocation agent obtains and processes all Item Based Allocation triggers from the YFS_IBA_TRIGGER table that meet the following conditions:

  • IBA_RUN_REQUIRED = "Y"
  • LAST_IBA_PROCESSED_TS was 'x' hours before current time, where 'x' is from the ‘Item Based Allocation Agent Execution Interval (in hours)' rule in the Installation rules. For more information about installation rules, refer to the topic "System Administration Components: Defining Installation Rules" in the Organization and Participant Modeling Concepts topic. This rule is used to indicate the interval that the Item Based Allocation agent should not reprocess the triggers in the YFS_IBA_TRIGGER table, which were processed earlier. This prevents the IBA agent from over-processing the item and node combination in the given time interval to avoid any high loads on the system.
  • PROCESSING_BY_AGENT="N" or PROCESS_OVER_BY_TS is before the current timestamp. The PROCESSING_BY_AGENT field is used to prevent the picking up of the IBA trigger which is being processed by another instance of the agent.

If InventoryOrganizationCode is specified in the agent criteria, only the IBA trigger with inventory items of that inventory organization is retrieved.

For each triggered item and node combination, the agent finds all of the applicable order lines or order line reservations that contain the item and node and tries to move their unpromised and promised demands to more suitable available supplies based on user-configured IBA selection rules or FIFO (First-In-First-Out) IBA selection rules.

Sterling™ Order Management System creates new positive order line reservations with the matched supply's first ship date and negative order line reservations for the existing demand ship date. Once all orders are processed, they are placed on hold to be rescheduled if changes are detected in the order line reservations.

The following configuration is required for the Item Based Allocation process:

  • The Use Item Based Allocation rule needs to be enabled.
  • Item and node need to have Item Based Allocation Allowed enabled.
  • A hold type is required to be set up for the change order line reservations modification type so that the order can be placed on hold for rescheduling. For more information, refer to the IBM Sterling Order Management: Javadoc.

The ‘When a line is backordered, backorder against the highest priority ship node' rule should be checked in order to reallocate backordered demand. For more information, see the Fulfillment Rules section in the Configuring Distributed Order Management topic.

Before processing the Item Based Allocation logic, the Item Based Allocation agent updates the following fields on the Item Based Allocation trigger:

  • PROCESSING_BY_AGENT = “Y�?. This indicates that an instance of the agent is currently processing this trigger.
  • PROCESS_OVER_BY_TS = current time + 1 hr. This indicates the expected time that the agent should finish with processing this IBA trigger. One hour is the fixed window and cannot be changed. Sterling Order Management System treats the PROCESSING_BY_AGENT flag as “N�? regardless of the actual value when current timestamp is after this timestamp.
  • IBA_RUN_REQUIRED = �?N�?. This resets the IBA_RUN_REQUIRED flag back to “N�?.

Obtaining a list of demands based on applicable order release statuses and order line reservations to be allocated

A list of demands is derived from applicable order release statuses and order line reservations, which have the item and node in the IBA trigger. The following types of demands are retrieved:

  • Demands of chained orders
  • Demands of orders with chained order already created
  • Demands of orders with procurement node but chained order creation is not yet created
  • Demands of orders without procurement node
  • Demands from order line reservations

The demand quantity is derived based on the order release status quantity with the status from the Status Inventory Type configuration that has a demand type, which considers the supply type with ‘Use Consider Demand Type for Item Based Allocation' enabled. For more information, refer to the Configuring Sterling Global Inventory Visibility topic.

Obtaining a list of available supplies for allocation

Sterling Order Management System obtains the available supply based on the availability of the item at the node by ignoring unpromised and promised demands. If the inventory organization maintains its inventory externally, the external availability can be read by the YFSGetExternalInventoryUE user exit. Only the availability of supplies that consider the ‘Demand Type Look for Availability during Item Based Allocation' are used in the allocation logic. For more information, refer to the Configuring Sterling Global Inventory Visibility topic.

Allocated demands should be matched with the same supplies as "Demand to look for during release".

Matching demands against supplies in FIFO (First-in-first-out) order

sorts the list of available supplies in the order of the first shippable date (ETA), and matches the obtained list of demands using the top-down logic (unlike the normal matching logic for obtaining availability, where matches are based on the closest ETA). Demands are allocated in the following orders: sorts the list of available supplies in the order of the first shippable date (ETA), and matches the obtained list of demands using the top-down logic (unlike the normal matching logic for obtaining availability, where matches are based on the closest ETA). Demands are allocated in the following orders:

  • Demands of chained orders - first based on user-configured sequencing rules, and then in ascending order of order creation date. (These types of demands are matched based on the closest ETA to avoid any changes in the chained orders).
  • Demands of orders with a chained order already created - first based on user-configured sequencing rules, then in ascending order of product availability date. (These types of demands are matched based on the closest ETA to avoid any changes in the orders).
  • Demands of orders for which procurement node and chained order creation is imminent (within the advanced notification time window) - first based on user-configured sequencing rules, then in order of order creation date.
  • Demands of orders without a procurement node and within the release window (advanced notification time window) - first based on user-configured sequencing rules, then in order of order creation date.
  • Demands from order line reservations on the order lines in the order of requested reservation date, and leftover demands (outside of the advanced notification time window) of orders with or without a procurement node, first based on user-configured sequencing rules and then in the order of order creation date.
  • Demands from inventory reservations in the order of ship date.

Notice that different types of demands are given different priorities based on their significance. The demands of chained orders or orders related to chained orders are treated with a higher priority than the demands of normal orders. Furthermore, the demands with a ship date within the advanced notification time window also have a higher priority than the demands with a date outside of the advanced notification time window.

Updating order reservations for the matched demands

After matching the available supply and demand in user-configured sequencing and then in FIFO order, the system builds up a list of order line reservation changes and inventory demand changes (corresponding to the order line reservation changes) and summarize them to optimize the number of order reservation updates and inventory updates. Negative order line reservations are added for the matched demands. Positive order reservations are added for the matched demands with the product availability date set to the matched supplies' first ship date.

After the Item Based Allocation agent completes its tasks for an Item Based Allocation trigger, it updates the fields of the trigger with the following values:

  • IBA_REQUIRED = "N"
  • LAST_IBA_PROCESSED_TS = current timestamp.
  • PROCESS_OVER_BY_TS = current timestamp.
  • PROCESSING_BY_AGENT = "N"

The Item Based Allocation agent should be used in conjunction with the rescheduling process as the rescheduling process reschedules the affected orders by utilizing the order line reservations created by the Item Based Allocation process.

Attributes

The following are the attributes for this time-triggered transaction:

Table 1. Item based allocation attributes
Attribute Value
Base Transaction ID ITEM_BASED_ALLOCATION
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called changeOrder – for updating the order line reservations created as part of the Item Based Allocation process.
User Exits Called None

Criteria parameters

The following are the criteria parameters for this transaction:

Table 2. Item based allocation criteria parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to Get, the only valid value.
Number of Records To Buffer Optional. Number of records to retrieve and process at one time. If left blank or specified as 0 (zero), it defaults to 5000.
InventoryOrganization
Code
 The inventory organization code of the inventory items which are processed by the Item Based Allocation agent. If provided, only the IBA triggers with the inventory item that belongs to this inventory organization are processed.
ColonyID Required in a multischema deployment where the YFS_IBA_TRIGGER table may exist in multiple schemas. Runs the agent for the colony.

Statistics tracked

The following statistics are tracked for this transaction:

Table 3. Item based allocation statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed by the Item Based Allocation agent.
NumOrdersRequiredReschedule Number of orders required rescheduling as the result of Item Based Allocation process.

Pending job count

None.

Events raised

This transaction raises events as specified under the changeOrder API in the IBM Sterling Order Management: Javadoc.