However, we’re not seeing that this field affects anything; it doesn’t go onto SOA or pack slip.
That in order to ship an order somewhere else, we have to go to each Sales Order Release and change the Destination there. That is what shows up on the SOA and pack slip.
Destination doesn’t auto-update OOTB, and there is nothing in help that I can see…
I believe that when you create a new sales order, if you set the shipto at the header level, then when you make new lines/releases the shipto will pull that information in. Once your sales order has been created, you can’t go back and update the header shipto and have it update the existing releases. However, new releases added after the header shipto was populated should default to that shipto.
OK thanks that sort of makes sense. But if I have a SO with 150 lines, and our customer asks to change the shipping address, that is pretty tedious to fix.
So followup question -
Anyone aware of someone implementing a BPM that updates all the release destination addresses to match? Similar to how if you change the Header NeedByDate, it gives you the option to push that date to all the lines and releases?
Totally! It is very tedious. Unfortunately, it does happen from time to time. You could try a DMT update to push new ship tos into your releases. (If you have DMT).
A BPM might work for this. That sounds like a cool idea!
Good call, Nancy! I thought you maybe had a directive triggering that, but it works on my side too. Just click shipto to change the header level shipto, then save the sales order and you get that popup to fix the rest of the lines. Cool!
We put together an embedded dashboard to change the ship to and contact on releases because it’s a pain to change them if you don’t want to change all the lines to the same thing. Basically it’s a list view of the releases with only a few fields that can be changed. You might want to do something similar?
Since you asked, Ideally yes it would be great if Epicor was good enough to make all the decisions. Leaving us having to make as few decisions as possible.
If our PM updates the ship-to address to a new address, the intuitive outcome would be that Epicor change the ship-to address for the items. But it didn’t, and didn’t ask anything. We almost shipped the parts to the wrong country…! It’s looking like it had something to do with lines coming from a quote. I’m still looking into it.
That pop-up asking to update releases has always appeared in systems I’ve worked on. I wonder if there’s a setting somewhere suppressing it for @TerryR
This attached a BPM should replicate that pop-up that you’re missing. I left notes on each widget to explain what it’s doing. Should be pretty straightforward.
I’m not 100% on the last widget custom code. @klincecum might be able to check my work, the code is below:
// This is the bit I'm not sure of. Does the ds.OrderRel have any rows if only the header has an updated field? If not, you might need to use the commented line below instead.
var AllRels = ds.OrderRel.Where( x => x.OrderNum == iOrderNum );
//var AllRels = ds.OrderRel.Where( x => x.OrderNum == iOrderNum );
if ( AllRels == null || AllRels.Count() <= 0 ) return;
string newShipTo = ds.OrderHed.FirstOrDefault( x => x.Updated() ).ShipToNum;
foreach ( var Rel in AllRels )
{
Rel.ShipToNum = newShipTo;
}
Issue was that when we change the ship to in the classic form, it doesn’t take until you hit the save button. Even though it looks like it did, like all other fields. So when I tested it in the live environment, I didn’t know I needed to hit save, hence no dialog. And then @NateS sent me down a rabbit hole lol.
I’m pretty sure they were asked to “refresh the releases”, but they said no. In their defense, the words in the dialog aren’t clear.
It should say “change the destination for all releases”.