Ongoing Warehouse Developer

Guidelines for integrating an external system

Table of contents

Introduction

Ongoing’s open API allows external developers to connect a system, such as your customer's ERP system or web shop, to Ongoing. This means that the external IT partner is responsible for the development, set up and maintenance of the integration. All you need from Ongoing are the API keys, allowing the external system to interact with Ongoing through the integration. We will charge accordioning to our hourly rate for giving support or assistance during the set up.

Ongoing has also developed a few integrations ourselves to commonly used web shop platforms and some Scandinavian ERP systems. Those integrations have a standard set up that is easy to set up and start running. A set of settings allows some customization of the integrations. If you need a more tailored integration then the settings provide, you should find an external developer to set up the integration towards our API according to you needs. Please see our page about our own integrations for more information. Note that using one of our integrations is not part of your monthly fee, and set up, trouble shooting and maintenance of integrations are charged by the hourly rate specified in your contract with Ongoing.

In this document, we have pointed out a few things to consider when an external developer is building an integration to your Ongoing system. Your contact person at Ongoing can support you through the process, but it is a good idea to go through this document with your customer up front and consider what information the integration must contain, what reports you want to extract from Ongoing and what information is required to pass on to other systems along the supply chain e.g. the transport administration system. Ongoing itself requires very little information for an integration to work. For example, you only need an article number to create an article. It is the work processes at the warehouse or legal reasons which will determine the information required (e.g. scanning requires barcodes and customs requires statistic numbers, country of origin and product prices).

This document also contains a few references to where to read/write data in our API. Those are written in italic and are aimed for the developer building the integration. Depending on your system set up, deviations may occur.

A standard set-up

Below is a standard integration set-up.

The integration set up differs depending on the system to which the integration is built. E.g. a web shop integration does not normally contain inorders. Further messages may be needed for e.g. handling returns or tracking numbers.

Articles and stock values

Article numbers

Article numbers are normally used as a unique identifier in Ongoing and need to be matched to a unique identifier, or unique combination, in the external system. The article number can contain letters, numbers and characters. The characters ! % _ ^ \ are used as special search values in Ongoing and should not be part of the article number.

Scanning

If the warehouse intends to use scanning, a barcode (or another code that is used in the warehouse scanning module) should be specified on each article definition. Barcodes are placed at ArticleDefinition - BarCode. This field refers to the barcode for the stock keeping unit (SKU), if other barcodes are used per package, those can be set at ArticleDefinition - BarCodePackage.

Customs information

If you wish to extract proformas from Ongoing, or if custom information needs to be forwarded to another system, e.g. a TA-system, at least the following information should be sent to Ongoing. Make sure this information is available in the system.

Synchronizing stock values

Please see our page about Inventory for thorough information about how stock values are handled in the API.

Inorders and orders

Inorder

Inorders (advising an inbound delivery) can be used in an integration, but it is not mandatory. Inorders make it easier to report received goods back to the external system than if the goods are received without an inorder.

Tracking number

If tracking numbers are reported to Ongoing from a transporter or a TA system, then those can be sent to the external system. It may take some time from sending the order to the transporter / TA system until the tracking number is available in Ongoing. Normally the tracking number can be found at OrderInfo - WayBill.

Customer information

The customer name and address must be set in Ongoing, either by posting the full name and address per order or by finding the address based on the customer number. If you are identifying the address based on the customer number, it is important that the customer register is synchronized, and that all changes in the external system have been updated in Ongoing. The customer number must be unique in Ongoing. To avoid errors due to not fully synchronized customer register you can identify the customer on the full name and address to make sure the proper address is set on the order.

The address must be split up in name, address row, zip code, city and country. It cannot be sent in as one text string.

Set transporter and transporter service

The transporter and transporter service can be set on the order though the integration. The codes sent to Ongoing must match the codes listed in Ongoing. Make sure the external developer setting up the integration has access to those codes. They can also be fetched using the API function GetTransporterContracts.

Partial deliveries

Discuss with your customer how to work with partial deliveries, and who should have control of the partial deliveries. Some integrations are set up in such way, that orders should not be able to contain goods out of stock. However, due to missing goods, or errors at in- or outbound deliveries, damaged goods, or missing goods, it might still occur that the warehouse receives orders which they cannot satisfy fully.

Even if you do not plan to use partial deliveries it is good to have discussed the procedure. Below are some common ways to handle partial deliveries.

Returns

Returns can be handled in different ways in Ongoing: it can be returned on a specific outbound order, as an inbound order marked as return or as a return order. If the return should be advised upfront, then return orders or return inorders are used. If the return should be tracked to a specific order, the return is done on the outbound order. Discuss with your contact at Ongoing to decide which way is most suitable for your process.

To get returns connected to an outbound order you can use the API function GetOrdersByQuery and filter by LastReturnedFrom. For returns as inorders, you can fetch the return with the API function GetInorderByQuery and filter by IsReturnType and LastReceiveTimeFrom. For return orders, use ProcessReturnOrder and GetReturnOrdersByQuery.

Delivery notes and other reports

Go through the delivery notes and reports your customer wants to extract from Ongoing and make sure the integration will contain all this information. E.g. if the delivery note will contain invoicing address, this must be passed on to Ongoing.