Reservations in Warehouse management

This article describes the reservation functionality in Warehouse management and provides information about how it's implemented.

The Warehouse management module introduces functionality for reserving items and materials. The reservation functionality can be used only for items that are enabled for warehouse management processes (WMS). However, an item that is enabled for WMS can be used in both warehouses that are enabled for WMS and warehouses that aren't enabled for WMS.

The behavior in reservation scenarios varies, depending on the warehouse setup. Later sections of this article provide more details about the differences.

The reservation functionality is built on reservation hierarchies and is intended to support the following cases:

• Flexible warehouse operations
• Postponement of reservation details
• Clear separation of which inventory dimensions can be specified, and when they can be specified

A key component of the reservation system in the Warehouse management module is the reservation hierarchy. The reservation hierarchy defines the different levels where reservations can be made. Each level represents a physical inventory dimension.

The following illustration shows an example of a reservation hierarchy on the Inventory reservation hierarchies page. Default is a typical reservation hierarchy for an item that uses the Site, Warehouse, Inventory status, Location, and License plate dimensions as physical inventory dimensions.

The lower the value in the Reservation hierarchy level column of the grid, the less specific the level is. The higher the value, the more details are required to make a reservation on the level. In the previous illustration, the Site level has the lowest value (1) and is therefore the least specific level. The License plate level has the highest value (5) and is therefore the most specific level.

Information about on-hand inventory is stored separately for each level in the reservation hierarchy.

The following illustration shows the data model for the setup of a reservation hierarchy and its relation to the inventTable table.

The definitions of reservation hierarchies are stored in the WHSReservationHierarchy and WHSReservationHierarchyElement tables. These tables are shared tables. A reservation hierarchy can be associated with one item within a company.

The WHSReservationHierarchyProvider class provides a large number of APIs that are useful when you work with and query the reservation hierarchy for an item.

Based on the reservation hierarchy, you can make reservations on different levels without providing details about where to reserve and what dimensions to reserve on. In this way, you can postpone specific details, such as the location or license plate to make the reservation on. The location to reserve on can be determined later by the location directive.

Here are some examples:

• You make a reservation only on the site level. In this case, inventory blocking can be used to block a quantity of an item on a given site.
• You make reservations for a sales order that was created on site 4 and warehouse 42, and for the Available inventory status. Warehouse 42 is enabled for WMS. In this case, the reservation is made only on the inventory status level.

For WMS-enabled warehouses, the setup of reservation hierarchies greatly affects the processes for outbound orders, such as sales orders and transfer orders.

When you set up a reservation hierarchy, the key is to determine which dimensions should be positioned above the location level in the hierarchy, and which dimensions should be positioned below the location level. The following table describes the effects of arranging dimensions either above or below the location level.

To support reservations on different levels, a new method is used to store information about on-hand inventory for WMS-enabled items. Each level in the hierarchy corresponds to a set of physical inventory dimensions. For each level in the reservation hierarchy, the following information is stored:

• The quantity that is available physical
• The quantity that is available ordered
• The quantity that is reserved physical
• The quantity that is reserved ordered

The following table shows how the data might look for an item that has 10 pieces available physical and 2 pieces reserved physical on the status level.

As the table shows, reservations are tracked only on the levels that are affected by the reservation.

Because of the way that information about availability and reservations is stored, the corresponding values from the InventSum table can't be used directly for WHS-enabled items.

The following steps provide a high-level overview of the algorithm that determines the available on-hand quantity for an item and a set of inventory dimensions:

1. Determine the available on-hand quantity based on the exact dimensions. This level is the lowest level in the hierarchy.
2. Determine the smallest available quantity from all levels above the level that was found in step 1.
3. Return the smaller of the quantities that were found in steps 1 and 2. This quantity is the available quantity.

For example, based on the data in the previous table, the available physical quantity is calculated for the following dimensions:

• Site: Site1
• Warehouse: WH1
• Inventory status: Good
• Location: Bulk

In step 1 of the algorithm, the quantity is 12, because that quantity is the one that is available on the location level. However, in step 2, the smallest quantity from the levels above the location level is 10. Therefore, in step 3, the available physical quantity is 10, because that quantity is the smaller of 12 and 10.

Calculations of on-hand quantity for work transactions are done differently. The on-hand quantity is determined only up to the location level, because work affects reservations only on the location level and below. For example, based on the data in the previous table, the available physical quantity is calculated for work on the following dimensions:

• Site: Site1
• Warehouse: WH1
• Inventory status: Good
• Location: Bulk

In this case, the available physical quantity is 12, because the quantity is determined only up to the location level.

The on-hand information is stored in a new table that is named WHSInventReserve. The WHSInventReserveDelta table is used to track changes that the current transaction causes in the on-hand quantity. When the final commit occurs, the WHSInventReserve table is updated based on the changes in the WHSInventReserveDelta table.

Because many scenarios involve the calculation of on-hand quantities based on itemId, InventDim, or InventSum records for both WMS-enabled and non-WMS-enabled items, APIs are provided to support the calculations in a seamless way.

The following example shows how to instantiate the class that can be used to calculate availability for both WMS-enabled and non-WMS-enabled items.

InventAvailabilitySearch availabilitySearch;
InventIAvailability availability;

availabilitySearch = InventAvailabilitySearch::construct();
availabilitySearch.setItemId(_itemId);
availabilitySearch.setInventDimCriteria(_inventDimCriteria, _inventDimCriteriaParm);
availabilitySearch.setInventSum(_inventSum);
availability = InventAvailabilityProvider::construct().find(availabilitySearch).parmInventAvailability();

this.AvailOrderedCalculated = availability.availTotal();
this.AvailPhysicalCalculated = availability.availPhysical();
this.ReservPhysical = availability.reservPhysical();
this.OrderedSum = availability.orderedSum();

The InventAvailabilityProvider class provides numerous other APIs that are used to determine availability based on various types of input. The existing InventOnHandQty class was updated so that it also provides correct results for WMS-enabled items.

The following illustration shows the various classes and interfaces that are used to provide and encapsulate the calculations. For the sake of simplicity, some details are omitted.

To control the levels of the reservation hierarchy that reservations are made on, the system uses the concept of reservation strategies. A reservation strategy determines the outcome of a reservation, and the dimensions that are used to make the reservation. Reservation strategies are implemented in the code and aren't currently user configurable.

Each reservation strategy determines the level that the reservation should be made on. If the dimensions that are passed to the reservation system don't cover all the dimensions to the level that is defined by the strategy, the reservation system queries the on-hand availability until the required level. Then, based on the results of this query, it does the reservation so that it covers all the required dimensions.

The reservation strategies that are chosen for a reservation depend on the following factors, among others:

• Warehouse setup
• Order type

The following table describes the reservation strategies that the reservation system uses.

The reservation system supports multiple reservation strategies in sequential order when reservations are made. For example, the system uses the All and All not allowed blank strategies to make reservations for transfer journals.

The following illustration shows the classes that are used to implement reservation strategies, and the main consumers of those classes. For the sake of simplicity, some details are omitted.

The implementation is easy to extend, because the instantiation uses the SysExtension framework.

When an inventory transaction is marked or reserved ordered, the inventory dimensions are typically synchronized between receipts and issues. For example, when a purchase order that was created based on a sales order is modified or received, the dimensions are transferred to the inventory transactions for the sales line.

For WMS-enabled items, the synchronization differs from the standard behavior. When work must be created, the source line transactions can be reserved only until the level above the location level. If all dimensions are synchronized, work can't be created. Therefore, dimensions above the location level aren't synchronized for all scenarios.

If both the item and the warehouse are enabled for WMS, and if the issue type is one that can generate work, such as a sales line, only dimensions above the location level are synchronized. Therefore, if an item uses batch numbers, and the Batch number dimension is below the location level in the reservation hierarchy, the batch number isn't synchronized from receipt to issue transactions.

The logic that determines how dimensions are synchronized is implemented in the following methods on the inventMovement class. (However, new methods that are added might also require consideration.)

• getInventDimForReservedTransPhysChange
• getInventDimForIssueTransFromReceipt