Reservation and on-hand inventory in warehouse management

1. Inventory reservation hierarchy in Warehouse management

The reservation functionality can be used only for items that are enabled for warehouse management processes. However, if an item is itself enabled for warehouse management processes, it can be used both in warehouses that are enabled for warehouse management processes and warehouses that are not. The behavior in reservation scenarios is different, depending on the warehouse setup.

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

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

1.1 Reservation hierarchies

A typical reservation hierarchy for an item that uses the Site, Warehouse, Inventory status, Location, and License plate dimensions as physical inventory dimensions.

The level with the lowest value in the Reservation hierarchy level column is the least-specific level, in the example above this is the site level. The higher the value, the more details are required to make a reservation on that level.

1.2 Reservation hierarchies implementation

The definitions of reservation hierarchies are stored in the WHSReservationHierarchy and WHSReservationHierarchyElement tables. These are shared tables. A reservation hierarchy can be associated with one item within a company which presents by WHSReservationHierarchyItem. The WHSReservationHierarchyProvider class provides a large number of APIs that are useful when you work with and query the reservation hierarchy for an item.

1.3 Making reservations on different levels

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. This lets you postpone specific details, such as the location or license plate to make the reservation. The location to reserve items on can be determined later by the location directive.

As another example, you make reservations for a sales order created on site Site1 and warehouse WHS42, which is a warehouse that is enabled for WHS processes, and for the Available inventory status. For this example, the reservation is made only on the inventory status level.

Location Main006 will be specified when processing the work

2. Impact of the reservation hierarchy setup

For warehouses that are enabled for warehouse management processes, 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 should be below. The following table describes the effects of arranging dimensions either above or below the location level.

3. On-hand representation and calculations

3.1 On-hand for items that are using warehouse management processes

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

The 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 cannot be used directly for items that are using warehouse management processes.

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:

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

Example A

The following physical inventory exists for the item (some dimensions like site, inventory status, license plate are irrelevant and are omitted throughout the scenario):

• Warehouse: W1, Location: L1, Physical inventory: 6

A sales order with one line is created and reserved:

• Warehouse: W1, Quantity: 5

The sales order is released to warehouse. As a result warehouse work is created:

• Work type: Pick, Warehouse: W1, Location: L1, Quantity: 5
• Work type: Put, Warehouse: W1, Location: Baydoor, Quantity: 5

Now we have the following inventory transactions:

So once we roll up the transactions into the InventSum table the contents of the table will look like this

On hand quantities for warehouse W1 like we used to do it in versions prior to AX 2012 R3 (sum up InventSum quantities for warehouse W1)

We should have shipped 5 items and we have 6 items on stock, 1 item is available. This is exactly the reason why summing up available and reserved quantities from the InventSum table may produce incorrect results for items that use warehouse management processes.

The sales reservation was taken on the warehouse level of the reservation hierarchy to ensure that we keep enough on hand in the warehouse to ship the reserved quantity. The pick work reservation was taken on the location level and it ensures that the reserved quantity will still be physically available when the warehouse worker comes to the warehouse location to pick it. Work reservation does not affect physical availability on the warehouse level. This means that the new reservation engine will be able to figure out that we still have one item available on the warehouse level.

Example B

After the transactions are aggregated the InventSum table contains the following information

For each of the levels of the reservation hierarchy it stores available and reserved quantities in the WHSInventReserve table which allows the engine to calculate availability correctly.

To work with available quantities regardless of whether the item is using warehouse management processes or not the InventIAvailability interface was introduced. The following list contains the InventSum fields and methods that should not be used directly and the corresponding InventIAvailability methods that should be used instead:

3.2 Implementation of on-hand calculations

Three major APIs were introduced for retrieving item availability:

– InventAvailabilityProvider – InventAvailabilityFormCache – InventOnhand

• InventAvailabilityProvider

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

InventIAvailability  inventIAvailability = InventAvailabilityProvider::findByItemDim(
                                            InventTable::find(itemdId), dim).parmInventAvailability();

Info(strFmt("inventIAvailability, availPhysical %1, ordered %2, reservPhysical %3, reservOrdered %4", 
                inventIAvailability.availPhysical(), 
                inventIAvailability.ordered(), 
                inventIAvailability.reservPhysical(), 
                inventIAvailability.reservOrdered()));

InventAvailabilityByUnit inventAvailabilityByUnitSum = InventAvailabilityProvider::findByItemSumDim(
                                                        InventTable::find(itemdId), inventSum, dim);

Info(strFmt("inventAvailabilityByUnitSum, availPhysical %1, ordered %2, reservPhysical %3, reservOrdered %4", 
                inventAvailabilityByUnitSum.availPhysical().qty(false), 
                inventAvailabilityByUnitSum.ordered().qty(false), 
                inventAvailabilityByUnitSum.reservPhysical().qty(false), 
                inventAvailabilityByUnitSum.reservOrdered().qty(false)));

• InventAvailabilityFormCache

In scenarios where you want to display available quantities on a form you can use the InventAvailabilityFormCache class. It is responsible for retrieving and caching available on hand quantities per item per inventory dimension combination. To use it on a form you need to:

– Declare an InventAvailabilityFormCache field in classDeclaration of the form. – Initialize the cache field in the init method of the form:

1
2
3
4
5

public void init()
{
    super();
    inventAvailabilityFormCache = InventAvailabilityFormCache::construct();
}

– Flush the cache in the executeQuery method of the primary data source that the InventSum data source is joined to:

1
2
3
4
5

public void executeQuery()
{
    inventAvailabilityFormCache.refreshCache();
    super();
}

– Create display methods for available on hand fields that need to be displayed on the form. If InventDim is joined to InventSum then the display methods should be declared on the InventSum data source:

1
2
3
4

public display InventQtyReservPhysical reservPhysical(InventSum _inventSum)
{
    return inventAvailabilityFormCache.availabilityFromSumJoinedWithDim(_inventSum, inventDim_ds).reservPhysical();
}

Note that the availabilityFromSumJoinedWithDim method should be used. Otherwise, if InventSum is joined to InventDim then the display method should be declared on the InventDim data source:

1
2
3
4

public display InventQtyReservPhysical reservPhysical(InventDim _inventDim)
{
    return inventAvailabilityFormCache.availabilityFromDimJoinedWithSum(_inventDim, inventSum_ds).reservPhysical();
}

Note that the availabilityFromDimJoinedWithSum method should be used.

• InventOnhand

1
2

InventOnhand inventOnHand = InventOnhand::newParameters(itemdId, dim , dimParm);
Info(strFmt("inventOnHand, availPhysical %1, ordered %2, reservPhysical %3, reservOrdered %4", inventOnHand.availPhysical(), inventOnHand.ordered(), inventOnHand.reservPhysical(), inventOnHand.reservOrdered()));

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

Because many scenarios involve calculating on-hand quantities based on itemId, InventDim, or InventSum records for both WHS-enabled and non-WHS-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 WHSenabled and non-WHS-enabled items.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

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 the availability based on various types of input. The existing InventOnHandQty class has been updated so that it also provides correct results for items that are enabled for warehouse management processes.

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

4. Reservation strategies

To control the levels of the reservation hierarchy at which reservations are made, the system uses the concept of a reservation strategy. 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 are not 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 do not cover all the dimensions to the level 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 multiple factors, such as the following: • 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.

5. Details about the implementation of reservation strategies

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

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

6. Synchronization of dimensions between receipts and issues

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 items that are enabled for warehouse management processes, 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 cannot be created. Therefore, dimensions above the location level are not synchronized for all scenarios.

If the item and warehouse are enabled for warehouse management processes, and if the issue type is a type that can generate work, such as a sales line, only dimensions above the location level are synchronized. This means that if an item uses batch numbers, and the batch number is placed below the location in the reservation hierarchy, the batch number is not synchronized from receipt to issue transactions.

7. Details about the implementation of synchronization between receipts and issues

The logic that determines how the dimensions are synchronized is implemented in the following methods on the inventMovement class:

• getInventDimForReservedTransPhysChange
• getInventDimForIssueTransFromReceipt