Microsoft Dynamics AX 2012 R3 Reservations in Warehouse management White paper Microsoft Dynamics AX Warehouse management team May 2014 This white paper describes the functionality for reservations that is introduced in Warehouse management. www.microsoft.com/dynamics/ax Send feedback.
Contents 3 Reservation hierarchies 3 Details about the implementation of reservation hierarchies 3 Making reservations on different levels 4 Impact of the reservation hierarchy setup 4 On-hand representation and calculations 5 On-hand calculation algorithm 6 Details about the implementation of on-hand calculations 6 Reservation strategies 7 Details about the implementation of reservation strategies 8 Synchronization of dimensions between receipts and issues 9 Details about the implementation of synchronization between receipts and issues 9 2
The Warehouse management (WHS) solution introduces new functionality for reserving items and materials. The new 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. Later sections of this document will provide more details about the differences. 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 This document describes the new functionality and provides information about how it is implemented. Reservation hierarchies One of the key components of the reservation system in WHS is the reservation hierarchy. The reservation hierarchy defines the different levels on which reservations can be made. Each level represents a physical inventory dimension. The following illustration shows 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 illustration, this is the site level. The higher the value, the more details are required to make a reservation on that level. Information about on-hand inventory is stored separately for each level in the reservation hierarchy. For detailed information about how to set up reservation hierarchies, see Set up reservation hierarchies. Details about the implementation of reservation hierarchies The following illustration shows the data model for the setup of a reservation hierarchy and its relation to the inventtable table. 3
InventTable -ItemId -DataAreaId WHSReservationHierarchyItem -ItemId -ItemDataAreaId 1 0..1 -ReservationHierachy 0..* 1 WHSReservationHierarchy -Name -RecID 1 Information about the hierachy should be obtained through the provider WHSReservationHierarchyProvider 0..* WHSReservationHierarchyElement -ReservationHierarchy -DimensionFieldId -ReservationHierachyLevel 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. The WHSReservationHierarchyProvider class provides a large number of APIs that are useful when you work with and query the reservation hierarchy for an item. 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 on. The location to reserve items on can be determined later by the location directive. For example, 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. The following illustration shows how inventory transactions look when inventory is blocked. As the illustration shows, the reservation is physical but is made only on the site level. As another example, you make reservations for a sales order created on site 4 and warehouse 42, 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. The following illustration shows how the inventory transactions look when reservations are made at the inventory status level. As the illustration shows, the reservation is physical but is made only on the inventory status level. 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. 4
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. Dimension placement Dimension above location Description The inventory dimension above the location level must be determined before the Warehouse management functionality can be used. Therefore, this typically happens during order processing or by letting the reservation system determine the dimensions. Batch above location Dimensions below location If a dimension is above the location level, warehouse workers cannot change this dimension, because it is considered a strict picking requirement. For example, if the Batch number dimension is above the location level, a worker cannot pick a batch that is different from the one that he or she was instructed to pick. Process industry functionality for batches requires that the Batch number dimension be above the Location dimension in the reservation hierarchy. When this is the case, all functionality for First Expiry First Out (FEFO), same batch, batch disposition codes, and batch attributes is supported. WHS and warehouse workers can determine the Location dimension and the dimensions below it. The Location dimension and any dimensions below it should not be entered on sales and transfer lines if you expect work to be created. For example, if the Batch number dimension is below the Location dimension, it should not be specified on the sales line. Otherwise, WHS cannot create work to carry out the pick and pack operations. On-hand representation and calculations To support reservations on different levels, a new way of storing information about on-hand inventory is used for items that are enabled for warehouse management processes. 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 with 10 pieces available physical and 2 pieces reserved physical on the status level. Level Site Warehouse Inventory status Location License plate Available physical Available ordered Reserved physical Item 10 10 2 0 Site S1 10 10 2 0 Warehouse S1 WH1 10 10 2 0 Status S1 WH1 Good 10 10 2 0 Location S1 WH1 Good Bulk 12 12 0 0 License plate S1 WH1 Good Bulk LP1 12 12 0 0 Reserved ordered 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 5
InventSum table cannot be used directly for WHS-enabled items. For more information, see this blog post. On-hand calculation algorithm 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 is the lowest level in the hierarchy. 2. Determine the smallest available quantity from all levels above the level found in step 1. 3. Return the smaller of the quantities found in step 1 and step 2. This 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 is the quantity 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, which 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 lower. 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. Details about the implementation of on-hand calculations The on-hand information is stored in a new 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. 6
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 this.availphysicalcalculated this.reservphysical this.orderedsum = availability.availtotal(); = availability.availphysical(); = availability.reservphysical(); = 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. InventAvailabilityByUnit -InventIAvailabilty InventAvailabilityProvider +find() : InventAvailabilityByUnit InventAvailabilitySearch 0..1 «interface» InventIAvailability 0..* WHSInventReserveQty InventSumAvailability -InventSum InventOnHandQty 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 7
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. Reservation strategy None All Above location All not allowed blank Batch level Description The reservation is made on the dimensions that are passed, if possible. This strategy is used by inventory blocking, and lets you make reservations on, for example, the site level or the warehouse level. The reservation is made on all of the dimensions in the reservation hierarchy. This strategy is used, for example, for transfer journals, or for warehouses that have not been enabled for warehouse management processes. The reservation is made only on the locations above the location level. This strategy is used, for example, for sales and transfer orders when reservations are made in a warehouse that is enabled for warehouse management processes. The reservation is made on the first lowest level that does not allow for blank issue for the inventory dimensions. This strategy enables automatic reservations on non-licenseplate-controlled locations. This strategy is applied for items for which the Batch number dimension is selected and positioned above the Location dimension in the reservation hierarchy. This strategy is used when only reservations that are reserved ordered can be made. In that case, a reservation until the batch level is attempted. 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. 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. InventUpd_Reservation -inventmovement +whsupdatereservemore() 0..* 0..1 InventMovement +reservationhierarchylevelstrategylist() 1 1 WHSReserveHierarchyLvlStratAttribute WHSReservationHierarchyLevelStrategy +getlevel() +mustdeterminemissingdimensions() +onlyreserveorderedavailable() +onlyreservephysicalavailable() WhsReservationLevelStrategyAll WHSReservationLevelStrategyAboveLoc WHSReservationLevelStrategyNone WHSReservationLevelStrategyBatchLvl WHSReservationLevelStrategyAllNoBlnk 8
The implementation is easy to extend, because the instantiation uses the SysExtension framework. 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. 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 9
Send feedback. Microsoft Dynamics is a line of integrated, adaptable business management solutions that enables you and your people to make business decisions with greater confidence. Microsoft Dynamics works like and with familiar Microsoft software, automating and streamlining financial, customer relationship, and supply chain processes in a way that helps you drive business success. United States and Canada toll free: (888) 477-7989 Worldwide: (1) (701) 281-6500 www.microsoft.com/dynamics The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, this document should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in, or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. 2014 Microsoft. All rights reserved. Microsoft, Microsoft Dynamics, and the Microsoft Dynamics logo are trademarks of the Microsoft group of companies.