Issue with an order dispatch status in Sage when sending back dispatch lines

[Dev Keymas]

Has anyone has this issue with the order not being marked as despatched when using the API to send the despatch lines: sop_confirm_despatch.

While our data shows that the order lines have been picked and dispatched, the order header does not reflect the despatched status and order is unable to be invoiced off. Could you help us understand why the order header isn't updating accordingly, despite the lines being fully despatched?

The way to fix it, is to open up in Sage and press save without doing anything else. Then the header shows despatched. So does anyone know if there is a step we are missing after we send back the order lines as despatched to update the order status. I cannot see anything in the API docs about despatching the order header level.

Thanks,

[Chris Burke]

I don't have an issue with this.  But I think that all you're seeing here is the fact that the desktop list in the Sage 200 client isn't refreshing (I don't think that the API will know how to trigger the auto-refresh). Try despatching an order via the API end point and then manually refreshing the desktop list - that's what works for me.

[Dev Keymas]

@Chris Burke Thank you for your reply. So from your experience you have had it where you have used the API to despatch the order lines and it doesn't show as done on the desktop but when you refreshed it had changed? We did try going out and back again on the order but it is still the same without anything in the despatched Part or Full.

[Nigel Smith]

@Chris Burke Thanks for the info. The issue sounds like the API end point is not updating the order header after updating the order line (after the "despatch" is done), so this is why the sage lists are showing the issue. The user can then amend the SOP order (amend order form) and on update the correct "despatch" status is set.  Is it possible that the Sage 200 API end point doesn't lock an order ? Could this cause the reported issue ?

 

[Chris Burke]

You can't really say that it's the API endpoint which is responsible for updating the order status - the SOPConfirmDespatchReceiptRepository used by the endpoint is responsible for mapping the POST request into a SOPDespatchReceiptAdjustment object, and that is what does the work, exactly the same as if it were invoked via some SDK code or in the Sage 200 client itself (including the use of its LockingCoordinator).  

In my case I have a sales order (ID 140860592) with two lines on it. If I construct a request body to completely despatch one of those lines (quantity of 2) then this is all I need:

{

  "sop_order_return_id": 140860592,

  "items": [

    {

      "id": 140860601,

      "quantity": 2

    }

  ]

}

....and if I POST that, then my order is updated to have a despatched status of 'Part' (and everything else you'd expect to happen, like entries in SOPDespatchReceipt etc also happens correctly).

I think I'm going to need to know exactly what versions of Sage 200 / API are being used here.

[Nigel Smith]

Thanks, that's useful to know. Perhaps the developer can try again to reproduce on a "DEMO" company using POSTman (and advise on results) ...

[Chris Burke]

I've also only just twigged that there's a 'Picked' column in the screenshot of the order quantities shown above. Unless that's been put there by some bespoke customisation, I'm going to assume that Sicon Barcoding and Warehousing is installed here. I don't *think* that that can intervene in the despatch process in any kind of detrimental way, but it's definitely an additional variable.

[Nigel Smith]

Any news on this issue? Is the application now in production (or still in development)? @Dev Keymas perhaps share how you currently use the Sage 200 API.

https://sage.az1.qualtrics.com/jfe/form/SV_9XfcJpNWRdERSN8