Ongoing Warehouse Developer

The automation API

Table of contents

Introduction

Apart from the regular API, Ongoing also exposes a more advanced API called the automation API. This API allows an external system to perform certain internal warehouse operations, like moving goods from one location to another.

Most API users will never need this functionality, but it is crucial when integrating with automation equipment. Because of the custom nature of such equipment, you may have to consult with Ongoing before beginning implementing your integration.

Differences between the regular API and the automation API

Ongoing object ids

As mentioned above, the automation API mainly operates in terms of Ongoing's various internal ids. To use the automation API, it is necessary to understand these ids. All of the various internal ids are integers.

GoodsOwnerId

The goods owners are the customers of the warehouse, i.e. the companies which the 3PL warehouse provides services for. Each goods owner is represented by a unique GoodsOwner .

ArticleDefId

An ArticleDefId is Ongoing's internal id for an article, i.e. the basic article data such as article number, barcode, dimensions. When you use ProcessArticle to create an article, it will automatically be assigned an ArticleDefId.

ArticleItemId

An article item is an instance of an article. When the warehouse receives a quantity of an article, a new ArticleItemId will be created for that particular goods reception. On the article item, the warehouse may also record some other data, such as a serial number.

OriginalArticleItemId

Let's say you have an article item with id 1978, representing 40 pieces of something. In the Ongoing WMS, it is possible to split an item. For instance, you may split off 10 pieces of 1978. This will result in item 1978 now representing 30 pieces, and a totally new article item (with id, say, 3789) which represents 10 pieces.

In this case we say that the original article item id of 3789 is 1978.

ArticleItemInLocationId

Whenever an article item is placed in a location, a new ArticleItemInLocationId is generated for that combination of article item and location.

MovementArticleItemId

The warehouse may create a movement order for an article item, signaling that they intend to move the article item from its current location to some other location. The MovementArticleItemId is the id of the movement order.

InvoiceId

The system allows for the creation of invoices for each goods owner. Each invoice has a unique InvoiceId.

InvoiceArticleId

Before a charge can be added to an invoice, the warehouse must first create an invoice article for that type of charge. Each invoice article has a unique InvoiceArticleId.

Possible ways to use the API

Here we list some possible ways to use the API together with automation equipment.

Vertical storage lift

A vertical storage lift is a machine consisting of several internal locations, and some mechanism which can automatically transfer goods between these internal locations and some designated input/output areas. To model this in Ongoing, you have three locations:

Here is a possible workflow for placing goods in the lift:

  1. Operator physically places goods in the lift's input area.
  2. In Ongoing, the operator moves the goods to the Lift_In location.
  3. In the background, the lift 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 lift.
  4. When the lift realizes that there are article items in Lift_In, it immediately calls ArticleItemInLocationHandled to mark them as having been handled.
  5. The lift can now physically move them to its internal locations.
  6. After the physical move is done, the lift calls MoveArticleItem on all affected article items to move them to the Lift location in Ongoing.

Retrieving goods from the lift works in a similar manner:

  1. When the operator prepares orders for picking, Ongoing will allocate goods from the Lift location and automatically generate movement orders from Lift to Lift_Out.
  2. In the background, the lift 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 lift immediately calls MovementArticleItemHandled on the movement article item ids, to mark them as having been handled.
  4. The lift can now begin to move them physically to the output area.
  5. When the lift is done, it uses MoveArticleItem on all affected article items to move them to Lift_Out in Ongoing. (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 phyiscally pick the items and also mark them as picked in Ongoing.

Conveyor belt

A conveyor belt is used to transport objects from one place to another. There conveyor belt may have the ability to move objects to different places depending on the object itself. For instance, in a warehouse you may wish to have the conveyor belt move all packages going to Sweden to one location, which all packages going to Norway should be moved to another location altogether.

One possible way of integrating a conveyor belt with the Ongoing Warehouse Management System, is the following:

  1. An operator picks an order in the warehouse and places the goods in a package.
  2. A label with the order number (or some other identifier) is affixed to the package.
  3. The operator places the package on a conveyor belt.
  4. The conveyor belt scans the package and makes a call to GetOrderArticleItemsByQuery.
  5. Using the information which the Ongoing WMS returned to the conveyor belt, it can make an intelligent decision on where the package must be routed to (for instance based on country).