Change Default Territory Source to be Synchronize to Customer

Is there an easy way to make Territory Source in Customer default to Synchronize to Customer instead of System Select?

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.

I thought I could just go into application studio and change the default there, but the combo box doesn’t show anything in column or list.

BPM

Let me look real quick.

Example of what I have done in the past

var ttShipToRows = ttShipTo.Where(w => w.Added()).ToList();

foreach (var row in ttShipToRows)
{
	// Get TerritorySelect Setting
	string sTerritorySelect = Db.XaSyst.Where(w => w.Company == row.Company)
										.Select(s => s.DefaultShipToTerritorySelect_c)
										.DefaultIfEmpty("SYST")
										.First();

	row.TerritorySelect = !string.IsNullOrEmpty(sTerritorySelect) ? sTerritorySelect : "SYST";

	// If the TerritorySelect is not SYST we need to get the TerritoryID from Customer
	if (sTerritorySelect == "SYNC")
	{
		row.TerritoryID = Db.Customer.Where(w => w.Company == row.Company && w.CustNum == row.CustNum)
									 .Select(s => s.TerritoryID)
									 .DefaultIfEmpty("")
									 .First();
	}
}
2 Likes

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!

This IS the easiest way. Don’t be messing with those crappy screens. :rofl:

Post processing BPM on Erp.BO.Customer.GetNewShipTo

ds.ShipTo.FirstOrDefault().TerrSelectFlag = "SYNC"; //Sync to Customer
3 Likes

Hi @klincecum ! I tried to implement this and got a couple of errors. Specifically:
image

I feel like we’re close, but something isn’t defined properly. Any idea how to resolve these two errors?

1 Like

Been a minute, break it down for me in detail.

What you want, what you got, reason, etc.

Oh I see.

Probably looking for ds.ShipTo.

The other one in @hkeric.wci code is a ud field he added.

Which leads me to believe you don’t really understand what it’s doing. (sorry) :sheep:

So anyway, lay it all out as you see it, and we’ll see if we can help.

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.

This is what I am seeing

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.

Do you have this DefaultShipToTerritroySelect_c field in the database for XaSyst table?

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.

4 Likes

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.
image

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

Just leaving this here for reference. If anyone is curious about the flow and Epicor’s recommendations.

image

Method Directives:

  • Pre, Post and Base processing logic
  • Access to BOs
  • Ideal place for Validations / Exceptions / Data Changes

In-Tran:

  • Executes after standard Entity Framework data triggers
  • Executes within a transaction, as a part of the trigger pipeline
  • Immediately processes affected row
  • Processes one row at a time (two rows for update operation (RowMod = “” is old row)
  • Can change data on save
  • — The In-Tran should never if it can throw an exception, it is very very expensive rollback.
  • You shouldnt access BOs in here!

Standard:

  • Executes when service method call has completed
  • Executes only if service method completes without exception
  • Processes batch of affected rows at once
  • Does not affect data save
  • Ideal place for integration operations (Audits, Email, Logging, Notifications, API)

Method Directive GetNew… will always be a just a POST Directive.

4 Likes

I get a bit giddy every time I see that word.

Happy Gavin Free GIF by Rooster Teeth

2 Likes