Fulfilment partner gets every half and whole hour extra updates from orders

PatrickvdHeijden

Hello team,

We experience something very strange since 2 weeks. Our fulfilment partner receives our new orders and orderstatus (paid, cancelled, on hold, etc.) exactly on the time they should receive it via the API.

However every half hour e.g. 09:30h-10:30h-11:30h and every whole hour 09:00h-10:00h-11:00h, they say they receive an update for almost every order to put it back on hold (as if the payment was not completed).

What could be the issue here?

I checked all orders and they have different paymentproviders, so they are coming from Sisow, MultiSafePay, Paypal and Stripe, they all behave the same.

Any idea what could trigger that 2nd statusupdate?

LucienVersendaal

Hi @PatrickvdHeijden,

Thank you for reaching out to us.

My first thought goes to the fulfilment partner doing this update. This because they have access to the API.

Do you have an example of an order so I can check?

PatrickvdHeijden

Hereby the messages we receive from the API:

The 2nd message whichs tells us that the order was paid:

[{"update_code":"UPDATE","sales_channel_reference":"SCENERYWORKSHOP.NL","on_hold":"0","order_reference":"ORD109947","order_reference_extra":165010720,"send_type_reference":"SCENERYWORKSHOP.NL-EXTERNAL","status":"OPEN","send_type_classification":{"st_agent_shipping_code":"default","st_class_description":"PostNL via Bpost (Belgi\u00eb)"},"customer":{"relation_type":"customer","reference":"ORD109947","name":".....,{"update_code":"UPDATE","order_line_reference":329487472,"product_reference":224450000,"order_line_quantity":1,"packaging_reference":"ITEM1","price":5.99,"properties":[]},{"update_code":"UPDATE","order_line_reference":329487473,"product_reference":11848267,"order_line_quantity":1,"packaging_reference":"ITEM1","price":12.95,"properties":[]}],"properties":[{"name":"status","value":"processing_awaiting_shipment"},{"name":"priceIncl","value":"226.04"},{"name":"weight","value":"375"},{"name":"memo","value":""},{"name":"comment","value":""}]}] 

The 3rd message whichs tells us that the order was NOT paid:

[{"update_code":"UPDATE","sales_channel_reference":"SCENERYWORKSHOP.NL","on_hold":"1","order_reference":"ORD109947","order_reference_extra":165010720,"send_type_reference":"SCENERYWORKSHOP.NL-EXTERNAL","status":"OPEN","send_type_classification":{"st_agent_shipping_code":"default","st_class_description":"PostNL via Bpost (Belgi\u00eb)"},"customer":{"relation_type":"customer","reference":"ORD109947","name":"Robin Van Lent","contact_name":"....."properties":[]},"order_lines":[{"update_code":"UPDATE","order_line_reference":329487469,"product_reference":171273815,"order_line_quantity":1,"packaging_reference":"ITEM1","price":197.5,"properties":[]},{"update_code":"UPDATE","order_line_reference":329487470,"product_reference":2833764,"order_line_quantity":1,"packaging_reference":"ITEM1","price":3.61,"properties":[]},{"update_code":"UPDATE","order_line_reference":329487471,"product_reference":108634976,"order_line_quantity":1,"packaging_reference":"ITEM1","price":5.99,"properties":[]},{"update_code":"UPDATE","order_line_reference":329487472,"product_reference":224450000,"order_line_quantity":1,"packaging_reference":"ITEM1","price":5.99,"properties":[]},{"update_code":"UPDATE","order_line_reference":329487473,"product_reference":11848267,"order_line_quantity":1,"packaging_reference":"ITEM1","price":12.95,"properties":[]}],"properties":[{"name":"status","value":"processing_awaiting_payment"},{"name":"priceIncl","value":"226.04"},{"name":"weight","value":"375"},{"name":"memo","value":""},{"name":"comment","value":""}]}] 

I took out the customer details...

LucienVersendaal

Hi @PatrickvdHeijden,

To logs you're sending are not our logs, but when I compare these I see a difference between the responses and that is why your order is set to on hold. Regarding the first response I see that "on_hold" is set to "0".

When I look at the second response I see that "on_hold" is set to "1".

So they are doing something that triggers this and set this on_hold from 0 to 1.

RealtimeSolutions

Hi @LucienVersendaal,

I am joining this conversation on behalf of Realtime Solutions, in order to be able to reach a solution. The messages that Patrick has included in his posts are the messages that arrive in our Warehouse Management System (WMS). I understand that those logs are different compared to the logs in your system, due to the fact that we translate those messages to our norms.

Based on our analyses, we already concluded that one of the differences between the messages was the on_hold status, switching from 0 to 1. However, this is something that our system does not change. We simply receive the messages from the Webshop and translate them into our system.

Another difference that we have found during our analyses, was the status of the properties between the two messages:

• The first message states: Message_awaiting_shipment
• The second message states: Message_awaiting_payment

Our assumption is that the second message causes the problems for putting the orders back on hold. Due to the fact that that our system does not alter the messages coming from Lightspeed, we assume that the wrong statuses are being sent to our WMS. We would expect a switch between the first and second message regarding the statuses, meaning we first receive a message with awaiting_payment, after which we receive a message with awaiting_shipment.

Is there a possibility that you can tell me what triggers the messages being sent to our system, including the differences between the statuses in the messages?

Kind regards,

Jelle Sanderse

Support Engineer

Hurksestraat 42 20

5652 AL Eindhoven

LucienVersendaal

Hi @RealtimeSolutions,

So are you saying that when the first message states:Message_awaiting_shipment the order is set to paid and shipment set to not_shipped?

After the second message state:Message_awaiting_payment the order is set from paid to not_paid and the shipment from not_shipped to shipped?

I assume you're using the update order? https://developers.lightspeedhq.com/ecom/endpoints/order/#put-update-an-order

RealtimeSolutions

Hi @LucienVersendaal

Indeed we are using the update order to change the statuses from the orders. The first message indicates our system that the order has been paid, and that the order can be prepared for shipment. This includes the picking and packing of the products.

The second message however, indicates that the order has not been paid, and therefore places the order back on hold. This means that the employees are not able to pick and pack the products, and that the order is not ready for shipment.

When an order is created in the Webshop, the order is sent to our system. We would expect the first update to state that the order is awaiting_payment, after which the last update should state that the order is awaiting_shipment.

Kind regards,

Jelle Sanderse

Support Engineer

PatrickvdHeijden

Just as an addition... We have been working with RTS and the WMS since november 2017 and since 2-3 weeks we are getting these strange updates.

LucienVersendaal

Hi @RealtimeSolutions,

Is it the case that this happens with orders that are created via the front end or also via the API. If it is also the case via the API, can we create a test order to see if we can reproduce it? Could you tell me the exact steps that you take when an order is coming in?

@PatrickvdHeijden,

Is it okay to create a test order via API?

What I do know is that 2-3 weeks ago we did an update regarding the shipment(curbside pick up) I am taking this into consideration that it could be that this could be related to it.

PatrickvdHeijden

@LucienVersendaal it is no problem if you do a test-order via API.

LucienVersendaal

Okay thanks.

@RealtimeSolutions can you tell me which exact steps you're taking, so I can reproduce it?

RealtimeSolutions

Hi @LucienVersendaal

I can take you through the steps that we are taking, however, this has nothing to do with the messages that are being sent from the webshop.

We simply receive the messages from the webshop, after which we are able to import the orders into our system. Based on the values in the message, an order is put into the system, after which the stock is assigned to the orders. By assigning the stock to the orders, the employees are able to pick the products.

So we do not take any specific steps, with which you will be able to reproduce it.

LucienVersendaal

@RealtimeSolutions Okay perfect.

@PatrickvdHeijden

One last question before I will do the test. The steps so I can get the same results.

1. Customer is making an order via webshop
2. Order is paid and will be prepared for shipment.
3. RTS is doing an order update? And set the shipmentStatus of the order to shipped?
4. because of that the order shipment is set to shipped, but the paymentStatus to not_paid?

Please correct me if I'm wrong, maybe you know the exact steps?

PatrickvdHeijden

@LucienVersendaal that is almost correct.

Step 3. The order is only set to shipped when they warehouse actually processed the order. Until that moment the order only remains on "paid".

Step 4. The last step is somehow triggered around the whole or half hour timestamp to be set to "not_paid" (the order still needs to be "not_shipped" though. However if the order is shipped, we don't see this "not_paid" issue occuring again)

PatrickvdHeijden

@LucienVersendaal any luck with the order?

LucienVersendaal

Hi @PatrickvdHeijden,

Sorry for delay, yesterday was a bit hectic. I've created an order now https://scenery-workshop.webshopapp.com/admin/orders/166512005 in the way you've told me. Now the order is set to paid, let's wait for a bit and see if it's set to on_hold now.

LucienVersendaal

Do you have an order where this behaviour happend before?

PatrickvdHeijden

@LucienVersendaal it happened with the order which was done directly after yours: ORD111260

We've have seen your order (ORD111259) which is "paid" in LightSpeed, was accepted like that in our warehouse management system and was just updated to "on_hold" again.

Both statusses changed after the whole hour: 09:00h

LucienVersendaal

@PatrickvdHeijden

In my test shop I did a test where I manually set the order on_hold, when I do that I see in the order events that this has been triggered.

When I do this via API(set order to on_hold) this message isn't shown in the order events.

So what I assume is that there is another trigger who change this status every whole and half hour.

I've checked the logs but I couldn't find any updates on my test order via API, where do you see this on_hold? Is this is Lightspeed or in your Warehouse management System?

PatrickvdHeijden

@LucienVersendaal we see this in the Warehousemanagement System. In lightspeed the order is still as it should.

@RealtimeSolutions can you please verify from your end?

RealtimeSolutions

@PatrickvdHeijden & @LucienVersendaal

In the warehouse management system we simply receive the messages from Lightspeed, from where we put the order on_hold, because that status was send to use via Lightspeed.

We also receive the two messages as seen in the picture in above. However, we also receive a third message which is stating that the order is (again) waiting for payment. And this third message is causing the order to be put back on hold.

LucienVersendaal

@RealtimeSolutions

I guess you're receiving a webhook if an order is created. So you do change the status to on_hold. Lightspeed isn't putting anything on_hold by itself.

At what time did you receive the webhook that the order is still waiting for payment. I guess something in your code is doing this update.

RealtimeSolutions

@LucienVersendaal

Analysis of ORD111259:

• 8:47, the order is made and sent to WMS. Here the order is put on_hold, because the order is awaiting payment (this is correct).
• 8:49, the order receives an update. Here the order is taken out on_hold, because the order is payed, and is now awaiting shipmnent (this is correct)
• 10:37, the order receives an update. Here the order is being canceled, which means that the order is closed.

Due to the order being canceled, I’ve not seen an update whereby the order is being placed back on_hold.

LucienVersendaal

@RealtimeSolutions,

I've created a new test order ORD111263. Can you do the analysis on that one?

PatrickvdHeijden

ORD111263

LightSpeed information

RTS - Warehousemanagement system

This is what I see, but I can't see the API calls.

@RealtimeSolutions can help on that.

(screenshots from 11:14u)

RealtimeSolutions

@LucienVersendaal

You’ve mentioned that you were thinking that we receive a webhook if an order is created. My developer has taken a look at this, and his assumption is the same. Can you tell me which webhooks are registered under the WMS of Scenery?

LucienVersendaal

@RealtimeSolutions,

You've 2 webhooks registered

1. Products https://p1.realtime.eu/rest/webhooks/13fe8f990d992f7f52f382ece0a14b72
2. Orders https://p1.realtime.eu/rest/webhooks/13fe8f990d992f7f52f382ece0a14b72

Your developer can see that as well when he hits the webhook endpoint.

PatrickvdHeijden

@RealtimeSolutions and @LucienVersendaal yesterday evening I received an email from LightSpeed that the "Webhook" was failing. Does this have to do with our issue?

LucienVersendaal

@PatrickvdHeijden,

Yesterday I did a test with the webhook, so you can ignore that one. I deleted the test webhook now. The test was about to check if the orders are getting the status on_hold. But since this is the status within your WMS this has nothing to do with Lightspeed order status.

PatrickvdHeijden

Thank you for the confirmation.

@RealtimeSolutions any update on your end?

RealtimeSolutions

@LucienVersendaal & @PatrickvdHeijden

We are currently working on an analysis regarding the test-orders that have been made by Lightspeed.

We see that our system is able to handle the initial imports that 'make' the order. However, the updates that are being sent to our system, regarding the order being payed, and that the order needs to placed out of hold, are not being processed.

We see that for ORD111263, that an update with a canceled status was sent to us last night, and this message was processed correctly. So it seems that the messages that contain the updates for the order being payed, are causing the problems.

We are currently checking why those problems exist, and where they occur.