Can Configurator query the database?

Here’s what I want:

In Configurator, user picks a material (which is a part number) from a Dynamic List (a BAQ), then based on that choice, assign that part’s UOM class to a separate input.

Point is, I need to know what dimension to grab later on.

  • I want the user to always enter length, width and weight
  • If they pick plate steel, in the ensuing method I care about the weight for the quantity of material
  • But if they pick bar stock, I care about the length and not the weight.
  • So I need to grab the UOM class from the material they picked earlier. (And I need the part number, too.)

A dynamic list only returns one value AFAIK (I’m sticking with part number). Some kind of “on field changed” action doesn’t reference a BAQ, only lookup tables, but I don’t want to use a lookup table, because that’s static.

Is there some other way to do this?

My only thought was another BAQ dynamic list filtered to the same part number but returning a different field, then forcing its value to be the one and only list item (like this), but that seems excessive for what I need.

Server UD Methods would work for you.

3 Likes

You will have different options depending on how your Epicor is hosted. We are on Epicors cloud, so all server side functions are super locked down. However I was able to make a dynamic list be populated with dynamic params.

  • Make BAQ with appropriate parameters.
  • Make a client side UD function that returns a ~ delimited string.
  • Call your BAQ in UD method and pass the inputs as parameters
  • Create a dynamic list, and for the source select your client side UD method created above.
  • Make sure to Refresh() your dynamic list when any of the inputs used as parameters for the BAQ are updated.
1 Like

Evan is correct. If you’re Multi-Tenant, then you cannot use UD Methods. If you’re Dedicated Tenants then you can do Linq queries in your database.

1 Like

Another possible solution, on the lazy side would be to get your first BAQ to concatenate your PartNumber(or Description, etc) with the UOM, separated by any character of your choice like ~.

After that when you hit on the validated expression for the epiUltraCombobox you could simply split that concatenated string and assign to another inputs.

For example, I might want the user to see in the combobox the PartDescription, while saving the PartNumber on the input. But maybe I need other info, like you, like the thickness of the material(we work with glass). I could simply create the concatented string(Description+Thickness) as expressed before and then split it afterwards to save the thickness in another input.

The only caveat is that the concatenated string is being shown to the user, but if you don’t want that, you could add spaces so it doesn’t show in the combobox unless the hit the horizontal spacebar. Or if you really don’t want that, you could simply use the value member so it stays hidden and split that and save those two values in different inputs.

Well I don’t know which is “the solution,” but I like all the suggestions.

@GInclan You are speaking my language. This is attainable for me and what I will do. Nice thinking outside the box.

@Mark_Wonsil Very good to know the difference. I see now that “Add References” is grayed out in client UD methods. Putting that in the memory banks.

@Evan_Purdy Always good to have the cloud input. Honestly, I don’t know how you are doing Configurator on the cloud. “Super locked down” is an understatement. I think half of the tech ref is those yellow boxes that say, “If you are MT SaaS, you are out of luck; better pay someone at Epicor.”

For your particular situation @GInclan solution is fine - but if you are in a situation were the data may change often the solution by @Mark_Wonsil or my solution would probably be better, as you can update the data without rolling out a new configurator revision. Every time you roll out a configurator revision orders, jobs, etc have to be reconfigured. Can be a big pain in the butt.

2 Likes

I totally concur with this. Configurator changes are a complete pain(even changes that aren’t visible imply reconfigurations), so if you can avoid changes in them it is the best. It will depend in the situation you are handling and if the functionality that your are going to add is prone to be updated later.

@GInclan Are you saying the concatenated field in the BAQ is NOT future-proof? I don’t follow. I’d be concatenating PartNum and UOMclass. Those are database fields. That sounds pretty change-proof.

A lookup table is what I want to avoid because that would need to be updated separately.

Hi @JasonMcD, I think @GInclan idea is a great option and will work just fine for you. I had done something very similar recently so figured I would post it for you in case it’ll help.
You can see that I queried the DB and then put that value in a field on the configurator designer.

var partLookup = (from row in Db.Part
where row.Company==Context.CompanyID && row.PartNum == “010-05120”
select new {row.ClassID}).FirstOrDefault();

Inputs.epiPcTextBox1.Value=partLookup.ClassID;

classid

1 Like

No, I was just confirming the idea that changes in the configurators are a pain in general. So if some functionality can be set outside the configurator, you avoid that pain. I still think that my suggestion is painless, unless you have to change the splitting character, add spaces, etc. That is the logic on the concatenation/splitting.

@paulosborne I actually got a chance to try this. Worked like a charm.

Only snag I hit was if I entered a non-existent value to look up. I now know how to do a try-catch block. It was an educated guess that the error was NullReferenceException. Then I had to create another variable since you can’t return inside a try-catch block.

Alright, I’m dangerous now.

1 Like