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

PatrickvdHeijdenPatrickvdHeijden Member, Beta tester Posts: 184 ✭

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?

Groet,
Patrick van der Heijden
www.sceneryworkshop.nl
<1

42 comments

  • LucienVersendaalLucienVersendaal Moderator, Lightspeed Staff Posts: 604 moderator

    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?

  • PatrickvdHeijdenPatrickvdHeijden Member, Beta tester Posts: 184 ✭
    edited November 2020

    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...

    Groet,
    Patrick van der Heijden
    www.sceneryworkshop.nl
  • LucienVersendaalLucienVersendaal Moderator, Lightspeed Staff Posts: 604 moderator

    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.

  • RealtimeSolutionsRealtimeSolutions Member Posts: 13

    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

  • LucienVersendaalLucienVersendaal Moderator, Lightspeed Staff Posts: 604 moderator

    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

  • RealtimeSolutionsRealtimeSolutions Member Posts: 13

    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

  • PatrickvdHeijdenPatrickvdHeijden Member, Beta tester Posts: 184 ✭

    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.

    Groet,
    Patrick van der Heijden
    www.sceneryworkshop.nl
  • LucienVersendaalLucienVersendaal Moderator, Lightspeed Staff Posts: 604 moderator

    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.

  • PatrickvdHeijdenPatrickvdHeijden Member, Beta tester Posts: 184 ✭

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

    Groet,
    Patrick van der Heijden
    www.sceneryworkshop.nl
  • LucienVersendaalLucienVersendaal Moderator, Lightspeed Staff Posts: 604 moderator

    Okay thanks.

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

  • RealtimeSolutionsRealtimeSolutions Member Posts: 13

    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.

  • LucienVersendaalLucienVersendaal Moderator, Lightspeed Staff Posts: 604 moderator

    @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?

  • PatrickvdHeijdenPatrickvdHeijden Member, Beta tester Posts: 184 ✭

    @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)

    Groet,
    Patrick van der Heijden
    www.sceneryworkshop.nl
  • PatrickvdHeijdenPatrickvdHeijden Member, Beta tester Posts: 184 ✭

    @LucienVersendaal any luck with the order?

    Groet,
    Patrick van der Heijden
    www.sceneryworkshop.nl
  • LucienVersendaalLucienVersendaal Moderator, Lightspeed Staff Posts: 604 moderator

    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.

  • LucienVersendaalLucienVersendaal Moderator, Lightspeed Staff Posts: 604 moderator

    Do you have an order where this behaviour happend before?

  • PatrickvdHeijdenPatrickvdHeijden Member, Beta tester Posts: 184 ✭
    edited November 2020

    @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

    Groet,
    Patrick van der Heijden
    www.sceneryworkshop.nl
  • LucienVersendaalLucienVersendaal Moderator, Lightspeed Staff Posts: 604 moderator

    @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?

  • PatrickvdHeijdenPatrickvdHeijden Member, Beta tester Posts: 184 ✭

    @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?

    Groet,
    Patrick van der Heijden
    www.sceneryworkshop.nl
  • RealtimeSolutionsRealtimeSolutions Member Posts: 13

    @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.

  • LucienVersendaalLucienVersendaal Moderator, Lightspeed Staff Posts: 604 moderator

    @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.

  • RealtimeSolutionsRealtimeSolutions Member Posts: 13

    @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.

  • LucienVersendaalLucienVersendaal Moderator, Lightspeed Staff Posts: 604 moderator

    @RealtimeSolutions,

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

  • PatrickvdHeijdenPatrickvdHeijden Member, Beta tester Posts: 184 ✭

    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)

    Groet,
    Patrick van der Heijden
    www.sceneryworkshop.nl
  • RealtimeSolutionsRealtimeSolutions Member Posts: 13

    @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?

  • LucienVersendaalLucienVersendaal Moderator, Lightspeed Staff Posts: 604 moderator

    @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.

  • PatrickvdHeijdenPatrickvdHeijden Member, Beta tester Posts: 184 ✭

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

    Groet,
    Patrick van der Heijden
    www.sceneryworkshop.nl
  • LucienVersendaalLucienVersendaal Moderator, Lightspeed Staff Posts: 604 moderator

    @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.

  • PatrickvdHeijdenPatrickvdHeijden Member, Beta tester Posts: 184 ✭

    Thank you for the confirmation.

    @RealtimeSolutions any update on your end?

    Groet,
    Patrick van der Heijden
    www.sceneryworkshop.nl
  • RealtimeSolutionsRealtimeSolutions Member Posts: 13

    @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.

Sign In or Register to comment.