Structure of the documentation
API functions which deal with the same kind of underlying object have been grouped together. Below we describe the kinds of objects which our API supports.
The articles are the stock-keeping units of the warehouse. An article may contain various data such as article number, article name, unit and weight. Not all data is required for all cases.
An article itself doesn't contain any info about location or stock. The stock is built up by instances of the article which are called article items.
The order is arguably the most important object in a warehouse integration. Among other things, orders define:
- The customer address.
- Which articles should be sent to the customer.
- Which transporter should be used.
The order object is referred to as a "sales order" in many systems.
The customer defines the end-customer (or consignee) who will receive an order. A customer mainly contains address information.
Most integrations will not need to make a separate call to ProcessCustomer. Instead, the customer information can be included in the call to ProcessOrder. This way you can create both the order and customer using a single request.
The inventory describes which articles are in stock. See more in this separate article.
The purpose of an inorder is to pre-advice arrival of goods to the warehouse. An inorder generally contains a planned inbound date and how many of each article are planned to arrive.
Inorders are also referred to as purchase orders in some other systems.
A return order can be used if a return is known in advance. The external system may create a return order using the ProcessReturnOrder function. The warehouse receives the goods and reports this on the return order. The external system then reads the result using the GetReturnOrdersByQuery function.
A production order can be used to produce stock of an article by consuming existing stock of other articles. The external system creates a production order using the ProcessProductionOrder operation. The warehouse produces the goods and reports this on the production order. The external system reads the result using the GetProductionOrdersByQuery operation.
Ongoing WMS has an invoicing module which the warehouse can use to create invoices for its customers. The API exposes the function GetInvoicesByQuery which can be used to read invoices from Ongoing WMS. The intended use-case is for an accounting package to be able to integrate with Ongoing WMS, so that the invoices can be easily transferred automatically from Ongoing WMS to the accounting package.
Shipments are a way of organizing outgoing and inbound deliveries.
Note: The word "shipment" here refers to Ongoing WMS' own concept of a shipment. It has no relation to the "shipments" which a carrier (such as DHL or UPS) deals with. The vast majority of warehouses do not use Ongoing WMS' own shipment functionality, and therefore most integrations will never have to deal with this kind of shipment.
Arbitrary files can be stored in Ongoing WMS. They can be attached to orders and articles by using UploadOrderFile and UploadArticleDefFile, respectively. If you wish to read back the files, you can use GetFileList and GetFile.
These functions can be used to store the time when you last ran your integration process. See more at SetTimeOfLastSync.