Check the below requirement of the customer
The putaway and handling units were not efficiently developed and as a consequence there is a delay to putaway. Customer accepted that this would take up to 15 seconds a pallet, however in line with recent changes this has increased.
In the customer’s scenario, there are 36 bays in the warehouse which have space at the end for 4 pallets. Each Bay has approximately 260 locations, each for a single pallet.
The access to the end of the bay is via a standard pallet truck, or manual move. The movements in the bays are with VNA (very narrow aisle) specific devices, which due to their nature and size, need to work within a Bay as much as possible.
To achieve the design, customer has worked with drop off locations at the end of each Bay, so a transport task on putaway would first go to the end of the bay, before a second task used by the VNA trucks would be used to locate the pallet in the racking.
These trucks typically put one pallet away, then get another pallet from the store for picking or replenishment, then putaway, then retrieve etc.
4 pallets can be queued to putaway, and 4 pallets queued to pick at the end of every Bay.
IFS putaway logic had to be specifically tailored to prevent overcrowding at the end of the aisle, customer has it set in their TRN environment to split into 3 pallet groups, so an order is putaway by scattering across the locations which prevents trying to put too many into one drop off location at a time.
Putaway generation has increased to 6-18 minutes, per pallet which clearly is unacceptable.
Serialization or lot batches are not an option.
How the customer is supposed to use IFS correctly in this case without this unworkable delay?
