Looking for a bit of assistance. I have a workflow that generates sales orders and line, however in some instances the data is coming from a different site and the release lines need to reflect this.
I have had various attempts to resolve this, but the release plant value always stays at the primary plant that the user executing the workflow is in (that’s what I’m assuming is happening). base on the data in the activity output, I can see that the current plant in the ContextDataset-Client-CurrentPlant I can set the value, either I’m doing something incorrect (which is most likely) or the SalesOrderImpl.UpdateExt method is not respecting the ClientCurrentPlant value. I can trace the correct plant all the way until that method fires. When I look into the activity I see the value has changed back.
If anyone has come across this before? If so how did you resolve it.
Just curious, is your RowMod value set to ‘U’ or ‘A’ for the SalesOrderImpl.UpdateExt method in the section where the ClientCurrentPlant value is being set? I’ve noticed that sometimes if I don’t set that correctly the value doesn’t get saved…
We don’t use service connect to load sales orders, but we do use it to load quotes and then manually generate orders off of quotes. To control the plant of the releases, we manipulate the sales site (plant) on the product group table. I would check to see if the product group for the lines in question have a sales site defined. If so, you may need to do a secondary update or blank out this field.
Digging into things a bit further over the last few days it looks like the original solution never really catered for multi site. There was a subworkflow that processed nested quanities and lengths of each order line and that worked ok, it was were there where products that didn’t have the quantity and length attribute and were being processed in the main sales order lines workflow, from what I can tell when you get a new line and updated it the first release is automatically created (using the default or current plant for the user in our case it was 20)…even overriding the current plant in the current context didn’t appear to have any impact. It was not until I broke it out to a subworkflow could I get the value plant to update. There might be a more elegant way to do this.
Performance isn’t stellar, but I haven’t converted this to REST yet.
It has always been my hope to work through and create a library of templates for these types of scenarios, but like always, you get it it work, hopefully document, and then move on.
I think that templates is a feature that ESC could really benefit from, but then again if the direction is Jitterbit then I can’t see that happening in the near future. ESC PM…Are you out there…
As usual, doing something different makes you think of a better solution. Doing a trace with DMT for something else had me come across the SetPlant Method. I’m thinking that I might be able to incorporate that into the workflow early on and all of my trouble would go away…
Either of these to posts reference it
I have not tried that, but it would be worth a shot, and save a heap of hassle.
I actually did see that in the documentation and tried it. I couldn’t get it to function, but that should definitely be a way, just using a functoid to concatenate the string with the plant on the end…If I get time I might look at it, in more detail, what my thought is that the using the update_ext was only looking at the first release in the order dataset and not the newly created one, which explains why doing it in a subworkflow worked…I guess, but i could be wrong…
I’m sure you know more about this than I do but I have noticed that session context does not work well with service connect (or DMT for that matter) because it is user specific which seems to get overwritten as the user closes the client connection. Anyway I will be curious to see if you start using REST if that is a better way