Inventory Putaway

The functionality for inventory putaway is intended to supply the user with the best available location(s) when receiving parts into a stock location. There can be different settings used to decide the best locations and it should be possible to define different rules depending on different groupings of part or locations to help with the administration of the setup.

In general terms, the process for finding the best location(s) can be described as, to first identify the possible locations (meaning locations where a part can be placed due to capacity, conditions and capabilities defined per location and parts) and then find the optimal location(s) amongst these possible locations.

Regarding places where putaway can be triggered, it is limited to the following functional flows:

The move of parts to the locations found in the putaway process will be executed using the transport task. To enable the use of the putaway functionality in these flows, one needs to setup some basic data both for inventory locations and inventory parts.

Basic data for putaway in inventory locations:

In the warehouse navigator, it is possible to set specific values for capacities, conditions and capabilities together with rules regarding receipt control and if it is possible to mix the same parts, conditions or lot batch number on one location. With capacities, we mean the actual dimensions of a bin in a warehouse as well as the volume and weight limitations. Note that for example, if the height is left without a value, the location will be considered to have unlimited height (height is not a problem when it comes to storing parts). The volume of a location is retrieved by regarding the width, height and depth as a part of a cubic volume but it is also possible to define a manual value for volume. A manually entered volume could be used to define the actual usable volume of a location rather than using the calculated volume given by the dimensions of the location. Regarding weight limitations, they can be set for different levels of the warehouse. There can be a weight limitation for the specific bin, row, tier or bay. For example, you could have a weight limitation of 100kg for each bin together with a total weight limitation on 1000kg per bay. This would mean that it will not be possible to store more parts on a bay that has exceeded its weight limitation on bay even if there still exists empty bins for that bay.

With conditions, we mean the temperature and humidity conditions of a bin in a warehouse. For temperature, it is possible to define a minimum and a maximum temperature interval that describes the temperature interval which the temperature could vary between for that location. If one (or both) of the minimum or maximum temperature fields is left empty, it is considered as an open interval – meaning that there is no limit on how warm or cold it could be on that location (depending which of the minimum and maximum values that are empty). For humidity, it is possible to define a minimum and a maximum humidity interval that describes the humidity interval which the humidity could vary between for that location. If one (or both) of the minimum or maximum humidity fields is left empty, it is considered as an open interval – meaning that the humidity could be down to 0% or up to 100% depending on if the open interval is for the minimum or maximum humidity.

With capabilities, we mean user defined abilities that a location in a warehouse can handle. Capabilities are a user defined basic data that describes capabilities that are of interest when it comes to storing parts in an inventory. It could be, for example, some kind of security class or hazard rating, meaning that one wants to store parts with a certain hazard on specific locations that fit to handle that hazard. It is possible to define that locations handle one or more of these capabilities and when performing putaway those parts that require certain capabilities will only look at locations that can handle all capabilities required for that part. Note that parts without requirement for storage capabilities can be stored on locations that can handle one or more capabilities but there is a sorting that tries to avoid unnecessary use of locations that handle capabilities. For parts without capability requirements the putaway algorithm will first try to find locations without capabilities defined.

For open intervals mentioned above, it could be worth noting that in order to store parts that for example have an empty value in height, it will only be possible to use locations also having an empty value in height. This is due to the fact that an empty value is considered as an unlimited value, which in the height example means that only a part having unlimited height can be stored on locations having the same setting. So if there are dimensions defined for all locations but not for parts, the putaway algorithm will not be able to find an available location.

Other more general restrictions/rules on locations that affect putaway are:

Note that all the mix blocked restrictions can be set independently, so for example, if you want to have only a specific condition for a specific part stored per location, you need to have both a mix of parts and conditions blocked at the same time. Also note that when setting a mix of lot batch numbers to blocked, it means that it is not allowed to mix lot batch numbers for a specific part on that location. If the mix of blocked part numbers is unblocked, it is allowed to store different parts on that location but each part stored can only have one lot batch number at that location.

The capacities, conditions and capabilities together with the other rules are all set in the warehouse navigator. This means that it is possible to define values on a higher level in the warehouse structure that then is inherited to all locations belonging to that level, unless exceptions are defined lower in the structure. This means, for example, that if the dimensions of a location are the same for all bins in a bay, you can define the dimensions on bay level and these values are then inherited to all bins in the bay. If there are, for example, deviating widths on all bins on tier1 in that bay, one could update the width value for tier1 in that bay and it will be applied to all bins in that tier.

Basic data for putaway in inventory part:

For an inventory part, it is possible to set specific values for capacities, conditions and capabilities regarding the storage requirement for the part. Note that the values set relate to the storage of one unit of the inventory unit of measure used for the part. The storage requirements for an inventory part can be set on the specific inventory part but can also be defined for a part catalog record (valid for all sites where part is used) or for a group of parts. With storage requirement for capacities, we mean the actual dimensions of a part as well as the volume and weight limitations. Note that for example, if the height field is left without a value, the part will be considered to have unlimited height. This means that the part can be stored only in locations also having unlimited height. Also note that it is important to consider the orientation of locations as well as parts when defining these values; the putaway algorithm will not be able to rotate parts to get a “best fit” of a location. The storage requirement for volume of an inventory part is defined in a different way than for locations. For an inventory part, the width, height and depth are only used as a filter to find locations that have sufficient width, height and depth to store the part. The volume requirement for an inventory part is instead defined by stating how many parts that can fit into one piece of the specified volume unit of measure. This is displayed as a quantity per volume. This value can be entered either directly in the field for quantity per volume or can be defined using a dialogue where one states how many pieces that can fit into an identified location. When a part is stored in other locations, the quantity per volume is adapted to the differing volumes on these locations. For example, if one states that 200 pcs of a certain part can be stored on location XX which has a volume of 2 m2, the quantity per volume will be set to 100 pcs/m2. This means that if the part then is stored on location YY with a free volume of 3 m2 it could carry 300 pcs of that part. Also note that if there are undefined dimensions (width, height, depth) for a part when defining quantity per volume, the undefined dimensions will be set to 0. The reason for this is the fact in order to have volume on a location one has to define dimensions. And this means that if a part has undefined dimensions it will be considered as having unlimited dimension and will not fit into a location with a dimension restriction (or volume).

Regarding storage weight requirements for an inventory part, it represents the weight of the part as stored in a location. With storage conditions requirement, we mean the temperature and humidity intervals that a part require when stored in a location. For storage requirement for temperature, it is possible to define a minimum and a maximum temperature interval that describes the temperature interval which the temperature is allowed to vary between for that inventory part. If one (or both) of the minimum or maximum temperature fields is left empty, it is considered as an open interval – meaning that a part can be stored in unlimited warm or cold temperatures (depending on which of the minimum and maximum values was empty). For storage requirement for humidity, it is possible to define a minimum and a maximum humidity interval that describes the humidity interval which the humidity is allowed to vary between for that inventory part. If one (or both) of the minimum and maximum humidity fields is left empty, it is considered as an open interval – meaning that the humidity could be down to 0% or up to 100% depending on if the open interval is for the minimum or maximum humidity.

With capabilities, we mean user defined abilities that an inventory part require when stored in a location. Capabilities are a user defined basic data that describes capabilities that are of interest when it comes to storing parts in an inventory. It could be, for example, some kind of security class or hazard rating, meaning that one wants to store parts with a certain hazard on specific locations that fit to handle that hazard. It is possible to define that parts require one or more of these capabilities when stored and when performing putaway. Those parts that require certain capabilities will only look at locations that can handle all capabilities required for that part. Note that parts without capabilities can be stored in locations that can handle one or more capabilities but there is a sorting that will avoid unnecessary use of locations that handle capabilities. For parts without capability requirements, the putaway algorithm will first try to find locations without capabilities defined.

The values for capacities, conditions and capabilities can be set for a group of parts, for a part catalog record (valid for all sites where part is used) or for a specific inventory part on a site. The three different storage requirement groups that can be used for setting up values and that are common for several parts are:

The usage of these different groups for a specific part is defined on the part catalog record. These values are inherited from the requirement group to the part catalog and to the inventory part. It is possible to enter exceptions on lower levels. For capabilities, it will be the sum of capabilities from the different levels that are displayed on the inventory part. On the inventory part it is then possible to remove unwanted capabilities for a specific inventory part. Note that if different units of measure are used in the inventory part record and the part catalog record, the values for storage requirements for width, height, depth, volume and weight are not inherited from the part catalog to inventory part as there is no easy way to convert these values. Values for storage requirements regarding temperature, humidity and capabilities are still inherited as they are not dependent on the unit of measure used. In the inventory part, it is also possible to define a standard putaway quantity. This is used during the putaway algorithm to keep the quantities received from being unnecessarily split. For example, it could be used to make sure that a standard package is not broken as a part of a putaway. Also note that if parts are pallet-handled, the standard putaway quantity represents the quantity stored per pallet for that part.

The priority in which the putaway algorithm searches through the inventory is defined via so called putaway zones:

A putaway zone represents an inventory location area within the site where the part could be stored. It is possible to define one or several zones for a part and they can be differentiated via a ranking which decides the order in which the putaway algorithm will go through the inventory. Each zone is defined using the different levels as found in the warehouse navigator:

The user can freely decide the level of detail on each zone. A putaway zone defined down to bay level will include all locations within that bay. If, for example, two bays within the warehouse should be seen as a zone, it should be entered as two putaway zones having the same ranking. For each zone it is also possible to define a maximum number of bins to be used for the specific part. This means that the putaway algorithm will only allocate the number of bins that has been defined as the maximum number of bins within that zone. The use of a maximum number of bins makes most sense when having a capacity restriction (weight or volume) on locations within the zone. If there are no capacity restrictions on locations, all parts received via the putaway algorithm will be directed to one location that is considered to be able to handle an unlimited quantity.

When setting up a putaway zone, it is also possible to use special symbols to define a specific putaway zone more freely. The special symbols that can be used are:

Symbol Condition Example
= Equal to Enter New York for the City attribute to retrieve all customers located in "New York".
! = Not Equal to Enter !=New York for the City attribute to retrieve all customers located outside of "New York".
% Any value

Zero or more characters without limitations

Enter New% for the City attribute to retrieve all customers located in a city beginning with "New" (New York, New Orleans etc.).
_ Any character Single character without limitations. Enter _e% for the City attribute to retrieve all customers located in a city with an "e" as the second character.
> Larger than Enter >100 for the Customer ID attribute to retrieve all customers with an ID greater than "100".
< Less than Enter <100 for the Customer ID attribute to retrieve all customers with an ID less than "100".
>= Larger or equal to Enter >=100 for the Customer ID attribute to retrieve all customers with an ID greater than or equal to "100".
<= Less or equal to Enter <=100 for the Customer ID attribute to retrieve all customers with an ID less than or equal to "100".
.. Between If you want to include values 5, 6, 7, 8, 9, 10, the condition would be 5..10.
; Or Specify New York; Philadelphia for the City attribute to retrieve all customers located either in "New York" or "Philadelphia".

When entering putaway zones, there is a separate column that displays the SQL expression that will be used based on the values entered in the columns for warehouse levels.

The dynamic setup of putaway zones can, for example, be used to define a maximum number of bins over a number of bays. This would be setup using, for example, % or ; symbols when defining which bays should be included in the specific putaway zone.

The setup of putaway zones for inventory parts can be done for different groups of parts to avoid setting it up for each and every part manually. The different group levels for which it is possible to setup putaway zones are:

Note that when setting up putaway zones, there will be validations to avoid redundant data but there are no validations outside the group level in question (for example, there will be no validations of zones manually set on inventory part when setting up zones on site).
An example of setting up zones could be to set up a buffer warehouse as a putaway zone on the site level, and then there could be specific picking zones defined for a combination of asset class and frequency class. Such a setup would mean that if a part changes frequency class (due to changed demands) there could be an automatic change of the suggested putaway zone for the part. When receiving parts, the putaway process will first try to fill the pick locations if required. Remaining quantities will then be received into the buffer locations.

General setup recommendations/hints

When setting up the rules for putaway from scratch it is a good idea to plan the setup to be done in a proper order. A general suggestion for setting up inventory putaway is as follows:

In general, if values for capacities, conditions and capabilities are set up on grouped levels for both locations and parts, it means the administration for keeping values set up to date is highly reduced. If there is a requirement that parts that are received within a package/pallet etc are kept intact, you should use the standard putaway quantity. The putaway algorithm will then make sure that the quantity to be received into one location is a multiple of the standard putaway quantity. If a whole standard putaway quantity does not fit into the location considered, the putaway algorithm will move on to find a location that does. For pallet handled parts, it is mandatory to define the standard putaway quantity.

General description of putaway algorithm:

When performing putaway, it will trigger an algorithm that will go through the inventory on the current site and evaluate which locations can store the parts regarding requirements for capacities, conditions and capabilities. The algorithm will search through the inventory in the order defined via the putaway zone ranking and in that way find one or several locations that could be considered as the best available location(s) for the part. Here follows a more detailed description of the putaway algorithm:

  1. Look at the putaway zone with the highest ranking. Select all locations within that zone.
     
    1. Initial filtering per putaway zone:
      1. If the part has any storage requirements regarding capabilities, only locations that fulfill these storage requirements for capabilities should be considered.
      2. If the part has a storage requirement for dimensions, only locations that fulfill those dimension requirements (width, height depth) should be considered. Storage requirement for dimensions set to NULL means that only locations that have that dimension set to NULL will be considered.
      3. If the part has a storage requirement for minimum and/or maximum temperature, only locations that fulfill that minimum and/or maximum temperature should be considered. Storage requirement for minimum and/or maximum temperature set to NULL means that only locations that have minimum and/or maximum temperature set to NULL will be considered.
      4. If the part has a storage requirement for minimum and/or maximum humidity, only locations that fulfill that minimum and/or maximum humidity should be considered. Storage requirement for minimum and/or maximum humidity set to NULL means that only locations that have minimum and/or maximum humidity set to NULL will be considered.
      5. This first filtering of available locations within a zone should also exclude locations set as receipt blocked and also consider which location types that could be available to the putaway in question. Note that for pallet handled parts this means including pallet locations as well.
         
    2. Sorting of locations remaining after initial filtering:

      Preferably locations found should be sorted so that locations with exactly the same capabilities as defined by the requirement, should be considered first. An example could be parts that do not have any storage requirements for capabilities defined, for those parts we should first try to find locations that don’t have any capabilities defined. This way we could avoid unnecessary use of locations with a certain capability (there could be a limited number of those locations and therefore they should not be used for just any part).

      It would also be necessary to sort locations based on if a certain capacity or condition has a storage requirement for the part that is planned for putaway. Meaning that one first should look at locations that have for example width and temperature range defined if the part that is to be putaway actually has storage requirements for width and range. And vice versa, if no storage requirement is defined for example height and humidity for the part to be putaway, we should first look at locations without height and humidity defined. So this sorting need to be based on if the specific storage requirement for the part has a value or not.

      The sorting order is:

      1. Ascending number of capabilities
      2. Descending (MAX temp - MIN temp)
      3. Descending (MAX RF - MIN RF)
      4. Ascending height
      5. Ascending width
      6. Ascending depth
      7. Prefer locations where the part is already stored (avoid unnecessary use of new locations)
         
    3. Based on the sorted list received (as described above), check location by location regarding the storage requirements regarding the capacity and conditions. If there is a maximum number of locations defined for the zone, there need to be checks on how many locations the part already is stored at (if any) within this zone. At all times there must be checks so that this maximum number of locations is not exceeded by using additional locations. If the part is already stored in some locations, those locations should be the first to be checked as there might be remaining capacity on those locations. For each location, perform the following checks:
       
      1. Check if mix of parts is blocked in the location in question.
      2. Check if mix of condition codes is blocked in the location in question.
      3. Check if mix of lot batch (per part) numbers is blocked in the location in question.
      4. Is there remaining carrying capacity on bay level?
      5. Is there remaining carrying capacity on row level?
      6. Is there remaining carrying capacity on tier level?
      7. Is there remaining carrying capacity on bin level?
      8. Is the remaining volume in the location sufficient for parts being stored?
         
    4. If all checks mentioned above under section c. are fulfilled, this location can be used for putaway. The quantity to put away into a location will be divided into standard putaway quantities. Note that there could be remaining quantity that still needs to be putaway. For those quantities, the checks should continue from section c. as long as the maximum number of locations is not exceeded.
       
    5. When all locations for a zone have been evaluated and there still remains quantity to put away, the process should continue from section 1 with the next putaway zone as defined by ranking.
       
    6. When locations have been found for the entire putaway quantity, the putaway process is complete.
       
    7. If all locations for all putaway zones have been evaluated and there still remains quantities left to put away, an information message appears informing the user of the status.

Funtional flows where perform putaway can be triggered

The functionality for perform putaway can be triggered in the following functional flows:

Execution of move triggered via perform putaway

The perform putaway execution will find the best available location(s) for a part and then create a transport task in order to execute the actual move. On the transport task, you can for example, search for tasks created for a certain receipt or for all transport tasks due for transport from a certain bay. Quantities to be moved will be reserved for the transport task until the transport task has been executed. Execution of the transport task can be done directly on the transport task or via warehouse tasks.

Validation of storage requirements for manual increase of quantity on hand

The storage requirements for an inventory part is mainly used for the putaway process, but it is also possible to setup the system so that the storage requirements are validated whenever the quantity on hand is increased for a location. If the storage requirements are to be validated and the requirements for the inventory part are not fulfilled by the location in question, then it would not be possible to execute that transaction. Whether the validation of storage requirements should be done or not is defined per level in the warehouse navigator. For example, it is possible to have a general setting for storage requirements to be validated for a site but there could be exceptions to not validate storage requirements for a certain bay. The validations of storage requirements can also be applied for locations within the arrival flow.

Limitations for putaway rules

As mentioned above, the functionality to perform putaway is limited to some prioritized functional flows:

In other receipt flows within the application, there is no support to use the perform putaway functionality.