Integrate an Automated Storage and Retrieval System (ASRS)

An Automated Storage and Retrieval System (ASRS) is typically used to increase the picking speed and make better use of the available storage space in the warehouse. An ASRS can be based on many types of technologies. We list some technologies here. Some common examples used by customers of Ongoing includes vertical storage lifts and robotics storage automation (e.g. AutoStore).

The solution is based on software provided by another party (not Ongoing) using the Ongoing WMS Automation API.

Modeling the ASRS

An ASRS is a machine consisting of internal locations (typically thousands of them), and some mechanism which can automatically transfer goods between these internal locations and some designated input/output areas. To model this in Ongoing WMS, you have three locations:

  • Lift_In: represents the input area of the ASRS.
  • Lift: represents all the internal locations inside the ASRS.
  • Lift_Out: represents the output area of the ASRS.

(In the case of the ASRS being an AutoStore system the three locations are usually named AutoStore_In, AutoStore and AutoStore_Out.)

Integration workflow

The workflow can be illustrated as follows:


The workflow of an Automated Storage and Retrieval System connected to Ongoing WMS.

Storage process

Here is the recommended workflow for placing goods in the ASRS:

  1. Operator physically places goods in the ASRS's input area.
  2. In Ongoing WMS, the operator moves the goods to the Lift_In location.
  3. In the background, the ASRS continuously polls GetArticleItemsByQuery with the filter OnlyGetArticleItemsInLocationsToBeHandled = true, looking for article items in the Lift_In location which have not yet been handled by the ASRS.
  4. When the ASRS realizes that there are article items in Lift_In, it immediately calls ArticleItemInLocationHandled to mark them as having been handled. Note that there can exist multiple article items for the same article in the Lift_In location.
  5. The ASRS can now physically move them to its internal locations.
  6. After the physical move is done, the ASRS calls MoveArticleItem on all affected article items to move them to the Lift location in Ongoing WMS.

A basic example of placing goods in the ASRS:

  1. Operator physically places 5 pieces of article number AN1 to the ASRS's input area. In Ongoing WMS, those 5 pieces correspond to a single article item for ArticleDefId 1001 with OriginalArticleItemId 9001.
  2. In Ongoing WMS, the operator moves the article item to the Lift_In location.
  3. The ASRS finds the article item for ArticleDefId 1001 with OriginalArticleItemId 9001, NumberOfItems 5 and ArticleItemInLocationId 3001.
  4. The ASRS marks the article item in Ongoing as having been handled with ArticleItemInLocationHandled for ArticleItemInLocationId 3001 so that it doesn't poll for it again next time around.
  5. The ASRS can now physically move the goods to its internal location(s). The operator should see on a display connected to the ASRS that 5 pieces of article number AN1 should be stored into the ASRS. In case the ASRS does not already know what article number ArticleDefId 1001 corresponds to it can look up the article with GetArticlesByQuery.
  6. After the physical move is done, the ASRS calls MoveArticleItem with OriginalArticleItemId 9001 and NumberOfItems 5 to move them to the Lift location in Ongoing WMS. Note that at this point the state of the goods in Ongoing might have changed compared to step 1: The 5 pieces may no longer be a single article item. They might now have been split to two article items with NumberOfItems 2 and NumberOfItems 3. These two article items will have different ArticleItemId, but the same OriginalArticleItemId. Therefore, it is very important to use MoveArticleItem with OriginalArticleItemId and not ArticleItemId.

Retrieving process

Retrieve either because you want to move something out from the ASRS, or you want to pick an order directly at the gate of the ASRS. Here is the recommended way of retrieving goods from the ASRS:

  1. When the operator prepares orders for picking, Ongoing WMS will allocate goods from the Lift location and automatically generate movement orders from the location Lift to the location Lift_Out. If you are not picking an order and simply want to move out items from the ASRS these movement orders can be generated manually.
  2. In the background, the ASRS continuously polls GetMovementArticleItemsByQuery with the filter OnlyGetMovementArticleItemsToBeHandled = true, looking for movement orders between these two locations which have not yet been handled.
  3. When it encounters such movement orders, the ASRS immediately calls MovementArticleItemHandled on the movement article item IDs, to mark them as having been handled.
  4. The ASRS can now begin to move them physically to the output area.
  5. When the ASRS is done, it uses MoveArticleItem on all affected article items to move them to Lift_Out in Ongoing WMS. (Note that this call will also finish the movement orders at the same time. Thus, there is no need for a separate call to finish to the movement article items.)
  6. The operator can then physically pick the items from the ASRS gate.
  7. Optional: If the retrieving process is an order picking process and you want additional tasks to be performed once you have physically picked the items from the ASRS there are two alternatives:
    1. PickAllocated is performed one time per order and article picked. This alternative is useful if you want actions to be performed per item. For example, you want labels to be printed for each item.
    2. PalletItemComplete is performed one time per order and package. If an order is shipped in one package, it is performed once. However, if you have an order that needs to be shipped in multiple packages you need to perform this as many times as you have packages. This alternative is useful if you often pack an order into multiple packages and you perform the packing step at the gate of the ASRS. Then you can record in what package each item is packed and potentially on what pallet each package is placed. This information might be very useful for the receiver.

Ongoing does not require that the OriginalArticleItemId is used in the process of retrieving goods from the ASRS. It is although possible for the ASRS to use the OriginalArticleItemId to decide what goods to fetch in step 4. above. Since the OriginalArticleItemId represents all goods-specific attributes set during the inbound process (inbound date, expiry date, batch number, serial number, etc.), using the OriginalArticleItemId replaces the need to filter goods for each of these attributes. This can be useful if the ASRS system does not have the corresponding fields for all goods-specific attributes.

Note: For each API request it is very important to wait for the API response and handle potential errors before moving on to the next API request. For instance, if you do MoveArticleItem followed by PickAllocated you need to wait for the API response from MoveArticleItem before doing PickAllocated. This is to ensure that the operations happen in the right order (sequentially) in Ongoing WMS.

Inventory process

If an item needs to be scrapped, or if the stock balance in Ongoing WMS needs to adjust up or down for any other reason, it can be convenient to perform a stock-taking directly in the user interface of the ASRS. To minimize the double work of also having to do the same process in Ongoing WMS this process can be integrated.

This process can either be started directly in the user interface of the ASRS or initiated from Ongoing WMS. The choice depends on a combination of ease of implementing and the preferred process of the warehouse.

Inventory task process started from Ongoing WMS

  1. An inventory task is created in Ongoing WMS' user interface. You may read more about how to create inventory tasks in Ongoing WMS user interface here.
  2. A call is made from the ASRS software to the API endpoint GetInventoryTaskByQuery to fetch the inventory task. Using the filters LocationId set to Lift is preferred to find inventory tasks only involving the ASRS.
  3. Optional: If inventory tasks involve article item specific information such as batches, serial numbers or expiry dates you will need to call the API endpoint GetInventoryArticleItems to fetch that information.
  4. The stock corrections are performed in the ASRS
  5. The results are sent to the InventoryTaskCount API endpoint. This is per article and can either be done continuously after each count or in a batch job at the end of a finished inventory task.

Start the process from the ASRS without using inventory tasks

This process results in inventory adjustments in Ongoing WMS. Read more about using inventory adjustments without inventory tasks here.

  1. The stock-taking is performed in the ASRS by counting the occurrences of an article.
  2. The ASRS software sends the correct amount in the ASRS to Ongoing WMS. Depending on the data requirements one of the following methods can be used: