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.
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.
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.
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();
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.
I’m looking over this post and need to do something similar. I don’t think a concatenated field would be good for my situation. the code here I haven’t gotten it to work. where did you put it? The UD Method doesn’t like looking up the DB.Part or any table from what I’ve tried.
Also maybe someone can explain the Dynamic List. I see I can add a second list but how do I access it.
His code would have to go in a sever side UD method.
You can have multiple dynamic lists, but it only shows whichever has a condition that evaluates to true. If multiple evaluate to true than I think it picks the first in the list.
