Solved

Workwave Route Manager Integration forces Pickup and Delivery steps in Workwave

  • 28 July 2022
  • 6 replies
  • 264 views
R
Rank
Userlevel 6
Badge +5

I have been prototyping the Workwave integration with Acumatica. In the carrier settings for Workwave, there is an option for “Route Type”. Workwave has the option for routes to be Pickup routes, Delivery routes, or both Pickup and Delivery.

The problem is that when a Shipment is created in Acumatica, using the “Create Workwave Order” button in the shipments tab, it automatically creates both a pickup and delivery order in Workwave. And there doesn’t appear to be any way to stop this from the Acumatica side.

Does anyone know how to fix this, so that a shipment from Acumatica only schedules a delivery in Workwave, and not a pickup as well? This problem creates a lot of noise in the Workwave application that then has to be dealt with manually (deleting all the unnecessary pickup orders).

 

This pickup and dropoff setting isn’t really the key issue. It appears that under the hood, both the pickup and dropoff order steps in Workwave are being populated via the API, even though in most cases we only want to do a delivery step. So this is something that should be fixed in the underlying code (unless I am completely missing a setting somewhere in Acumatica where we can control this??)...

 

Maybe @Doug Johnson could give this a look with the people responsible for this integration?

 

On the Workwave side (screenshots below)… this is a single order sent from Acumatica, where we have two steps in Workwave, one for dropoff, and the other for pickup.

You can see we have the same order id 00018 (two entries in the left column), which has a pickup step and a dropoff step. So in effect we have doubled the steps for every single order. This also creates issues with the routing, where sometimes the route manager will think you want to go back and forth back to the warehouse for every pickup and dropoff (I’m not sure why this happens yet).

Anyway, this adds up to a lot of additional work to manage the deletion of all the unnecessary pickup steps, so please fix this.

 

Pickup step:

 

Dropoff steps:

Thanks,

 

Jonathan

 

 

icon

Best answer by rosenjon 9 August 2022, 01:57

View original

6 replies

Doug Johnson
Rank
Userlevel 7
Badge +3

@rosenjon I configured a site and got the same result. The API (https://wwrm.workwave.com/api/#add-orders) appears to support creating an order with pickup = Null. The default integration populates the pickup with the warehouse address because it creates a starting location for the driver. We will investigate adding this as a future enhancement. 

R
Rank
Userlevel 6
Badge +5

Thanks @Doug Johnson. I’m also talking to Workwave about this, so let me go a little deeper with them to understand if we can easily satisfy our use case via some tweaks to the way we use their product on the Workwave side. I’ll post back here once I more fully understand the way the product does things.

R
Rank
Userlevel 6
Badge +5

Hi @Doug Johnson -

I am working through some issues with the included webhook customization for the Workwave integration. This is also a more general issue with Acumatica webhooks as well.

The Acumatica webhook feature generates urls based on the name of the company. if there is a space in the name of the company, then there is a space in the url for the webhook (see example below...full url redacted).

This Workwave integration uses callbacks in order for the integration to send data back to the Acumatica webhook when things happen in Workwave. One of the things the carrier integration form does is set the callback url on the Workwave side via an API call. If there is a space in the callback url, this call will fail and the url will not be set on the Workwave side. Spaces in urls are also a violation of the formal RFC 1808 spec: webserver - does HTTP protocol require space be encoded in file path? - Stack Overflow

Spaces are dealt with by IIS automatically, but not always by other systems (it seems to break the Workwave API). I have tried fixing this by replacing with %20, and this does solve the problem in terms of setting it with Workwave, but the webhook still doesn’t work with this change, so I have some more digging to do. There may be some other programming issues with this webhook as well. For example, it returns http 400 for pretty much every request sent to it. I think this has to do with some issues it has with checking the url signature and nonce. In any case, the webhook should return more helpful error messages than just a blank http 400 response when there are issues.

 

Thanks,

 

Jonathan

 

R
Rank
Userlevel 6
Badge +5

Hi @Doug Johnson -

I talked to our Account Manager on the Workwave side, who also has some knowledge of their technicals as well. His feedback was that the Acumatica integration only does a pull from Workwave when the user hits the “Get Delivery Status” button on a Workwave Shipment, or uses the bulk synchronization feature for Workwave orders.

So it’s unclear to me what the purpose of the “Callback Url” field is in the current Carrier configuration, or the provided webhook that comes with the integration. The Workwave API is setup to register a callback url, so that the API can send information on demand back to the callback url when deliveries are made. It was my thought that the included Webhook project with the Workwave carrier integration would accept these callbacks and then log the delivery information into Acumatica.

However, if we post data to the Acumatica webhook endpoint, it always returns an HTTP 400 bad request...it doesn't seem to matter what data we post (i.e. signed Workwave HTTP request or not).

Can I get some more clarity on whether the webhook provided by Acumatica is currently configured to accept webhook requests from Workwave and log them into Acumatica? There really isn't any technical documentation on the design of this solution or how it is supposed to operate currently, so it’s hard to say if it’s behaving properly or not. Maybe it would be possible to get some feedback from whoever is involved in building this integration, so we can work out what it is supposed to do at present and what its current limitations are?

Thanks,

Jonathan

R
Rank
Userlevel 6
Badge +5

Hi @Doug Johnson -

I have written a post about the Acuamtica Workwave integration and why it is bugged for companies that have a space in their name (there is no way to solve this at present due to certain restrictions of the Workwave API and a bug in the Acumatica Workwave webhook that will strip %20 encoding from the function that authenticates the callback from Workwave.

I am happy to help your engineering team fix this if they need it. There are a few other things in that webhook project that could also be cleaned up (unnecessary looping over the url attributes passed back from Workwave, etc). The callback from this API is pre-defined, so it should be trivial to just parse the url and grab the correct properties.

Thanks,

 

Jonathan

J
Rank

@Doug Johnson @rosenjon I have had the same exact problem for over a year as well and curious how this is marked as resolved? Is there a recent update that has expanded this optionality to just have a “Drop Off” Route type?

Reply


Terms & ConditionsCookie settings
About Acumatica ERP system
Acumatica Cloud ERP provides the best business management solution for transforming your company to thrive in the new digital economy. Built on a future-proof platform with open architecture for rapid integrations, scalability, and ease of use, Acumatica delivers unparalleled value to small and midmarket organizations. Connected Business. Delivered.
© 2008 — 2024  Acumatica, Inc. All rights reserved