We are currently transitioning from Avante 9.7.5 to Kinetic 2021.2.7. We use the product configurator heavily in Avante. We are currently stuck trying to figure out how to do, what we call cascading(parent-child ) in Avante, multi level configurations in kinetic.
For example in Avante when in the Q and A session a separate configuration(child) Q and A is presented. These child configurations can occur multiple times during the parent session. Once that child session is completed the parent session resumes. Does anyone have any experience, insight, online training videos or examples on how to do this in kinetic?
@slitzau @jdewitt6029 @skhan and I built a configurator that used many parent child relationships, but I don’t recall if it entered subconfigurators and then went back to parent configurators after that. I don’t think it did.
Can you guys chime in?
I’m on the configurator team as James_Morris. We can’t find information, training, or someone that knows how to set up subconfigurators. Is there some information or training available? We are new to Epicor.
David, there is a configurator technical reference guide on EpicWeb.
The general rule with configurable subassemblies is that they must all be the same type of configurator as the parent part; typically all Product Configurators. I have not tested whether Product Configurators can mix with the new KBMax configurators. I know they cannot mix with No Inputs Configurators, with one important exception. If the material with the NIC is Plan As Assembly so it spawns a separate job, the NIC will run in its own configuration session on the job, so it works. The actual rule seems to be that different configurator types cannot run within the same configuration session.
The way subassembly Product Configurators chain together is pretty nice. The user can navigate to different pages within the current subassembly (if its configurator has more than one page, which mine don’t) but they can only navigate sequentially between subassemblies. So if one subassembly calculates a global that a later subassembly depends on, the later subassembly can count on it having been calculated. And if the user backs up and changes an input, you can count on later subassemblies recalculating based on that change. You can also have several optional subassemblies with keep-when rules defined in their parent. The parent runs first, the keep-whens are applied, and then you see the configurators for the kept subassemblies.
Take the tech ref with a grain of salt. There are many things in it that are just plain false. For example, it says that you can programmatically provide the inputs and skip (as opposed to cancel) a configuration from On Load or On Loaded. (The tech ref says one thing, the application help says the other.) I confirmed with support that neither is correct; this was a planned feature that was never actually implemented.
If I were starting fresh today and not already heavily invested in classic configurators, I’d at least investigate the new KBMax stuff. It just showed up as an option one day. AFAIK it’s as yet completely undocumented.
the later subassembly can count on it having been calculated. And if the user backs up and changes an input, you can count on later subassemblies recalculating based on that change. You can also have several optional subassemblies with keep-when rules defined in their parent. The parent runs first, the keep-whens are applied, and then you see the configurators for the kept subassemblies.
Can you have a subassembly switch back to the main parent’s configurator though, that is what I cannot recall. I think it is all sequential, so you finish the parent assembly and then move through the sub assembly configurators and then it’s over right?
I think what David and James are saying is that currently they do Asm 1 > Sub configurator > AsM 1 again > Sub config 2 > Back to ASM 1 and then sub config 3 or something like that.
I think you’re right. I’m not sure how it would work any other way. Configurators are presented top down, and peers appear in order of MtlSeq. So you couldn’t receive more inputs for the parent based on inputs for the sub.
Method rules run after receiving inputs for all the subassemblies. (And sometimes during input, for reasons I’m not clear on.) So I think you could conditionally do things to the parent’s MoM based on inputs for the sub.
There’s no question I think you can do things in the parent’s MoM based on the Sub, the only question is can you go back to configuring the top level in the designer after you have done a subconfigurator.
I don’t know what their product is, maybe @James_Morris and @ddefrancisco can give an example of what they would be doing on a child session and why they have to go back to the parent.
I know we used to go through the parent subassembly and then proceed to the children. I think that everything that was configurable at the parent level was done first and then you proceed with the subconfigurators.
We are a manufacturer of elevator components. Our configurator consists of a parent that asks what floors do the elevator serve. We then type the floors, (1,2,3,4,5). The configurator will then call the child configuration (the pushbuttons) and cycle through as many times based on the amount of commas used. This will allow us to configure each floor button as horizontal or vertical, and color of led. Once that is complete the parent moves on to the next questions which may be the braille tags. This is also a child and cycles through as many times as there are commas. Then again the parent moves onto the next series of questions which may or may not be another child “cascade”. Each time it builds the Bom as it cycles through the child.
So you would potentially have 100s of iterations if you had 100 floors?
yes sir. We have a “paragraph” that counts the commas, and runs though the child. Then removes the last one and runs through the child, removes the last one, etc, until it runs out of the commas.
Have you ran this past any Epicor consultants as to whether this is viable in the configurator?
When I hear, “hundreds of subconfigurators” I kind of shudder…
There are ways to build Super BOMs or there are template BOMs to try and achieve this. I just wonder which one is best for performance.
There are a bunch of ways you could approach this in Epicor. The heavy-handed way would be to create a huge ButtonPanel MoM with as many Button subassemblies as you can physically fit on the panel. Each subassembly would have a keep-when rule, and the rule for the nth button would test whether the number of buttons is >= n. The user would then see the product configurator for each Button that is kept. You might go this route if different button numbers are inventoried as different parts.
If buttons are made or purchased to order and have the same or similar costs, your MoM and configurator could be a lot simpler. You could just have a single Button subassembly and set QtyPer on it. Provide human-readable details like floor numbers in a description field.
Quick comment on Template vs Super BOMs. Unless your MOM is very simple, static, and short Super BOMs are a maintenance challenge. When discussing with clients I about 99.99% seriously tell them if they want to do a Super BOM they probably will need to find a different consultant. Working on numerous configurators over 10+ years I have yet to develop one using a super BOM.
That is a great point Jim, I would agree, they are a nightmare if your product is constantly changing or has a deep BOM structure.
I’d love to find out I’m wrong, but AFAIK, configurator rules can only change properties of subassemblies (template) or choose to keep or discard them (super), never add new subassemblies. So if you have a BOM with a variable number of subassemblies, and each is configured differently in ways that affect cost or inventory, then a super BOM is your only option. But you can combine the super and template approaches in the same BOM, or even the same subassembly.
We may be dealing with semantics/terminology. A MOM has to have the maximum number of material inputs the MOM could ever need. The configurator can’t add more parts. These don’t need to be the actual end part number but usually are placeholder part numbers if the part number can change. If the part number doesn’t change then the material input should be the actual desired part.
A super BOM would have all permutations of parts that are possible for example if the MOM could have a 1 HP or 2 HP or 3 HP motor all three of these would be on the MOM as material inputs. The configurator would keep one of the material inputs and discard the other two based on selection by user.
In a template MOM there would be a single placeholder for the motor and the appropriate part number would replace the placeholder based on selection by user.
A subassembly can be a placeholder part number and replaced with a dynamic part number by the configurator or it can be a static part number if it doesn’t change. So if there are 25 possible subassemblies we need 25 material inputs, if the part number is static then it would be the actual desired part number, if the part number can change it would be a placeholder part number. For static items you might still have a keep when rule on it but that would still be considered a template BOM.