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.
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.
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.
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.
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:
The sorting order is:
The functionality for perform putaway can be triggered in the following functional flows:
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.
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.
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.