This segment will give a short functional overview of how to use the Ceyenne WMS API for a succesful implementation. The actual details of the functionality necessary will depend on each customers specific situation, so don't hessitate to contact your interface consultant for any in-depth questions that aren't mentioned here.
If you're just interested in the technical overview, please reference the per-topic technical overview below.
Companies
A Company in the WMS describes a stock keeping organisation under which products and their stock is administrated in the WMS. It most commonly reflects an organization/warehouse/administration in an ERP, but this depends on the situation of the customer.
A company has both an identifier (referred to as the CompanyIdentifier) and an API key (used as the Sender in the Messageheader of each request) to respectively identify the company and to check
Assortment
Each implementation with the Ceyenne WMS revolves around reliably being able to synchronise the assortment.
The assortment will be identified during Incoming Goods using its barcode, put on stock in the most optimal location based on the dimensions of the product and will be ordered, packed and shipped to the customer, all based on the properties of the SKU itself.
You can Add/Update the assortment of the WMS by calling the POST method on Assortment. After adding both a messageheader and a footer, you can add one or multiple SKU's to the body.
Each SKU (Stock Keeping Unit) is identified using the ProductIdentifier on the CompanyMapping of the product. Calling the POST method on assortment for a SKU that has a ProductIdentifier that already exists will cause an update on said product.
A product is most often identified using the article number of the product under which it is known in the external ERP/PIM system.
Purchase Orders
A Purchase Order (also known as a Shipment/DESADV/PreAlert) is a collection of products, identified under a common PurchaseOrderIdentifier, that are expected to be received at a warehouse at a certain date.
The most important properties in a purchase order are:
| Property | Description |
|---|---|
| PurchaseOrderIdentifier | Physicially identifies the Purchase Order. It is scanned by the user during Goods Receival to identify the Purchase Order that will be received. |
| WarehouseIdentifier | Identifies the warehouse under which the received stock will be booked. |
| CompanyIdentifier | Identifies the Company under which the received stock will be added. |
Each Purchase Order consists of 1 or more Purchase Order Lines. The status of these lines (as detailed in the PurchaseOrderLineStatus type) dictates what a user in the WMS is allowed to with the lines.
- Ready For Receipt means that a Purchase Order can be Pre-received, after which it can be received at Inbound
- Ready For Process means that a Purchase Order can be received at Inbound.
- Closed means that a Purchase Order can not be altered anymore. It is most commonly used to 'Cancel' a purchase order. A user can also 'Close' a Purchase Order in WMS Management, this means that the PO has been completely received.
Sales Orders
A Sales Order is a collection of products, identified under a common SalesOrderIdentifier that need to be delivered to a specific address (relation) on a specific date.
Similarly to a Purchase Order, the Sales Order has a few important properties:
| Property | Description |
|---|---|
| SalesOrderIdentifier | Unique identification for a Sales Order that should be picked/shipped to the customer. Either identifies the end-order number, or a pick-ordernumber in case the ERP itself makes deliveries based on the available stock. |
| WarehouseIdentifier | Identifies the warehouse from which the Sales Order will be sent. |
| CompanyIdentifier | Identifies the Company from which the order will be booked. |
| PromisedDeliveryDate | This is the Date the customer should receive their order on. A Sales Order (by default) should be picked 1 business day before the Promised Delivery Date. |
| ShipmentMethodIdentifier | Identifies what Shipment Method the Sales Order should be mapped to. These identifiers are configured per company. Consult your interface consultant for further explanation. |
Each Sales Order consists of 1 or more Sales Order Lines. The status of these lines (as detailed in the SalesOrderLineStatus type) dictates what the WMS will do with the lines.
- New means that a Sales Order is ready to be picked, and can be picked as soon as the deliverydate requires it and the stock is available on pickable locations.
- PendingPayment means that a Sales Order is not yet ready to be picked. The WMS can be configured to create Replenishment jobs to make sure that the order can be picked immediately when it is made definitive (and thus updated to status "New").
- Cancelled means that the line should no longer be picked.
Every other status is set by the WMS itself. Updating Sales Order Lines to these statusses via the REST API will not have any functional benefits.
Transactions
Every important action that a User/the system makes in the WMS is registered through a Transaction. These Transactions contain a multitude of information.
It details when something was done, who did it, what kind of action it was and if applicable what the amount of products are that have been picked/counted/received/moved.
These Transactions have been segmented in their own controllers so that when calling that controller, you will only retrieve transactions that are applicable for that specific area of the WMS.
We know the following types of Transactions:
- Purchase Order Transactions: Everything related to Receiving Goods and Purchase Orders.
- Sales Order Transactions: Everything related to Sales Orders.
- Return Order Transactions: Everything related to RMA processing. This is only applicable for customers that use the Ceyenne Returns Application.
- Stock Transactions: Every stock booking that is not related to either a Purchase Order, Sales Order or Return Order is a Stock Transaction. Stock differences counted during Cycle Counts but also during manual stock corrections are communicated here.
- Assortment Transactions: Everything related to Product changes.
Each Transaction Controller has a specific list of types, detailing what the Transactions are and what they signify. Translating these Transactions into an actual action during processing should be discussed with your interface consultant, as each customer and their needs are different.
When retrieving Transactions through the given GET methods on each controller you will (after processing) make it known to the Ceyenne WMS that those received Transactions have been processed.
Do this by calling the accompanying "POST" method on said controller with a list of the TransactionIdentifiers of the Transactions that have been processed. By doing this you will stop the subsequent GET calls on those methods returning those same TransactionIdentifiers another time, making sure that only new information gets processed.
Shipments
Resulting from a Sales Order that has been picked successfully is a Shipment, a reference to one or multiple collo or pallets that are going to be sent/picked up to/by a customer.
These shipments can be retrieved by calling the Shipment POST method for a specific company, with a body containing the OrderIdentifiers of the orders that you want to retrieve Shipment Updates from.
If there's anything known about said orders you will receive a list of one or more SalesOrderShippedItem, containing the shipment details of said order. It will display if the entire order has been shipped (through FullOrderIsShipped) and both the Shipment Information on a Sales Order Line basis, but also on a Shipment unit basis.
Said otherwise, The SalesOrderLinesShipped object details what Orderlines have been shipped in what ShippingItem, while the ShippingItems detail what Sales Order Lines are shipped in what Shipping item. They display the same information, just presented differently. A single Sales Order Line can be shipped in multiple ShippingItems, and one ShippingItem can contain multiple Sales Order Lines.
There is also the possibility to POST a SalesOrder Put message to the ShipmentController. Instead of creating a Sales Order, this will virtually pack the order given the same rules/validation as the actual WMS will when creating pick jobs, although without doing any stock checks. This will enable you to determine a suitable shipment method for the size of the shipment. We advise to only request a shipping proposal for the shipment method "Pickup", to give the widest range of possible options.