We are having an occasional issue where Epicor does not like having unassigned as the territory when it is taken from system select → get territory, and I am hoping that changing the default territory source to be synchronize with customer would stop this from happening.
Thanks, I was hoping for an easier way but if it has to be a BPM then oh well. I have never made a bpm before so thank you for posting the code for it!
I will be honest, I am completely confused too. I hit solution because I thought it would work but I gave up for a few months when it didn’t. I am also getting the message saying “XaSyst does not contain a definition” that Nick is getting.
So I get that sTerritoryselect is a new string variable created, but what exactly is Db.XaSyst and s.DefaultShipToTerritroySelect_c? Again, I have never made a BPM before so this is confusing. I do have some experience in Java which does help me understand some of the code.
Honestly if there was a way to just stop having the territory requirement that would be great.
I’m sure @klincecum is right about the vast superiority of BPMs. But if you don’t get what the code is doing, a relatively straightforward rule in application studio will set that field to what you want.
I added this and it is exactly what I wanted. Strangely, it comes up with an error only in the 2023 version, but the error can be ignored. Other than the annoying error that can be ignored it is perfect.
What did you enter for your Ship To ID, I think when I was testing this earlier the new ship to form loads with “(ne)” in the Ship To ID, if you put in a new ID there I think it avoids the error.
(nw) is the default no matter what customer I put in. Of course, there is no (nw) ship to for those customers, so I have no idea what the error is even talking about.
You probably want a Method Directive for GetNewShipTo, not Data Directive, and sometimes you need to access Custom UD Columns with DefaultShipToTerritory = s.UDField<string>("YourColumnName")
Think about this, you want to pull in a new default… but if the user changes the default to something else before creating the record you dont want to override them in Update, hence Method Directive is best.
Also why do it on a BPM not the UI… Because you want this logic to happen everywhere, DMT a new ShipTo? Updatable Dashboards creating new ShipTo? Rest API Creating a New ShipTo? Automation Studio? 3rd Party App? All of them fire BPM