Litium connect ERP 2.0 shipment API

Questions
1

We are trying to use the delivery endpoint but don’t understand how it is supposed to work or if we are doing something wrong.

We have a orders that is placed in litium with payment and a delivery.
We would like to create new deliveries via the api from ERP for the real deliveries that can be multiple.
The problem we have is that nothing happens when we post to the create shipment endpoint with a new delivery. The response code is always a 200 but the response message sometimes contain the original delivery delivery number and sometimes the response is an empty string.
Never is anything added or updated on the order or delivery. No error are logged at all.
Not sure if we are doing something wrong if the shipment endpoint are broken.

Trackingnumber
Is there no way of updating or fetching tracking number for at delivery via the shipment API? looks like the only thing you can add and get is additionaldeliveryinfo and addinitional order info is only possible to add when ytou create a shgipment and not when you use endpoint so sent delivered status.

Litium version: 7.6.1

2

This is under investigation, do you pass in the data as below?

{
    "Id": "c40b8ba1-f165-4546-994b-7b4dbe69de70",
    "OrderId": "{{externalOrderId}}",
    "ShippingMethod": "Expresspaket",
    "Rows": [
        {
            "Id": "c40b8ba1-f165-4546-994b-7b4dbe69de69",
            "ArticleNumber": "{{articleNumberToShipment1}}",
            "Quantity": 1
        }]
}

Otherwise it can not process the package.
This Api was created to move the delivery state from Processing to ReadyToShip and also supports partial shipment, this was not an update to delivery.
The input of this Api is a Shipment, which includes the number of items that are ready to ship

3

We pass the data as we interpret it in the swagger ui but we possibly interpreted it wrong. I see that you excluded lots of the properties. How do one know what is mandatory and not? For example is it necessary to pass orderid both in url and as payload?
id for the shipping also feel unnecessary. why isnt that just generated by litium when delivery is created?

What also cause some confusion is that deliveries now use the same naming convention as externalorderId but with a different counter. So order LS100063 have a delivery with LS100062 as deliveryId.

In you example you left out the address sompletely. What address will be used in that case?

We have tried with this payload for example and multiple variation with and without additionalinfo.

{
  "id": "8c77ecefa9444fcc87636b09fb46fc54",
  "orderId": "LS100063",
  "additionalInfo": {
    "additionalProp1": {},
    "additionalProp2": {},
    "additionalProp3": {}
  },
  "shippingMethod": "KSS",
  "address": {
					"id": "8c77ecefa9444fcc87636b09fb46fc54",
					"firstName": "Columbus",
					"lastName": "Global",
					"address1": "Sæffleberggate 56",
					"city": "Olso",
					"country": "no",
					"email": "email@columbusglobal.com",
					"mobilePhone": "+47 401 23 456",
					"phone": "+47 401 23 456",
					"zip": "0563"
				},
  "rows": [
					{
						"id": "45ec2fcc-5a52-4b62-8933-4f64f0f95e67",
						"articleNumber": "45312",
						"quantity": 1.0,
						"orderRowId": "45ec2fcc-5a52-4b62-8933-4f64f0f95e67"
					}
				]
}
4

Another test with payload more like yours. Still and empty 200Ok response.
Or are you saying that a shipment and a delivery are not the same thing? If so how do one see what is delivered and what not in litium?

image
image1508×721 43.1 KB

5

Ok we were able to reproduce this error and that is actually because you have not moved the order to processing state.
You can do that by calling OrderExportedToErp call.
Look at this documentation and you need to run step 2 before creating the shipment. (2: Order exported to ERP: …)

6

The expected result for trying to create shipment before exported would be an error not that order captured. Why is the api making up it own process instead of using the order, payment, delivery statebuilder? To trigger for exemple capture that would for a normal order require delivery to be in state delivered before it was triggered?

Even when you succeed with creating a new delivery it also behaves stranges since it automatically triggers capture for related payment for all new deliveries even if status is always readytoship on the delivery.

I reported my observations on docs.

7

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.