Too bad (I was hoping for an easy answer )
Even though I have TONs of experience with configurators, I have very little (except through Education materials) with multi-level configurators.
OH… one more thing to check.
Make sure that all levels of part/revs are approved. I have seen/heard of situations where it LOOKS like you have everything, but a lower level is unapproved, so it never actually gets those details, and therefore never runs the configurator.
just taking a swag here.
possibly its an undocumented feature? sort of like without APS you only get 2 scheduled resources
Maybe there is a single level/multi level application key without which you only get one level of multiconfig?
(please don’t laugh too hard)
This sounds like Part C is setup to not pull as assembly when used in Part B. This might explain why the rules work when it is by itself because it would be an assembly but would be a simple material when in Part B. Can you attach a screenshot of the method tracker for Part B showing how Part C is setup?
Are you configuring from an order and seeing all 3 configurators (A - C)?
Yes, I’ve had clients report similar issues, once the Cfgs get stuck, the solution, although not pretty, is to reset all the Appservers. The cascading logic is quite literally under the hood & if not compiled correctly in the regenerate configuration process, then it won’t work, even if you try to resequence in Configurator Entry.
Here’s the likely process to resolve:
Un-Approve all configurators then restart all Appservers including Task & Print services. Start by Approving the very lowest level Configurator, give it 1-2 mins & then review task agent & make sure the regenerate configuration process ran successfully. (I would recommend doing this after each Cfg approval, it’s imperative it runs successfully). Then go to next level up Configurator, before approving review Configurator Entry -> Sequence -> sheet, make sure you see the correct lower level Part Num(s) & Rev. (it’s imperative the correct Rev comes in as well as Part Num, I’ve seen cases where oddly the most current approved rev is not picked up, it won’t work if that’s the case). If lowel level sequences look good, then approve Cfg, wait 1-2 mins review Regen process in Task agent, if all looks good then repeat process all the way up.
Fyi, If you see errors during regenerate process, then you may need to clean up code or rules to regenerate successfully.
I am anxious to hear which solution succeeds; with, if possible, some description of a root cause.
I’ve experienced head-banging issues with enterprise configurations, where after using procedures similar to those @rbomford describes, the only effective solution was to rebuild from scratch.
After working with Epicor Support, they were able to dwindle it down to one flaw in our part set up.
Here is the story.
As I had posted above, Part A is a configurable part. What I failed to post was that inside Part A was a part called PH-Chair (Placeholder Chair). We were then using a method rule to replace Ph-Chair with Part B, a configurable part. The issue was that PH-Chair was set up as a non-configurable part. So what we were doing was replacing a non-configurable part, PH-Chair, with a configurable part, Part B. The reason why I said we couldn’t go more than 2 subconfigurators deep was because inside Part B, we had a part called PH-Seat (Placeholder Seat) which was also set up as a non-configurable part. Again, we used a method rule to replace PH-Seat with Part C which was yet another configurable part.
When we tested our configurator in job entry, Part A and Part B were pulling through their details, but Part C never executed its method rules and pulled its details. This is why I was saying the third level configurator was not working.
So, I decided, I’ll just move on and get the rest of the method rules written and test it in a Quote as well since the job entry side wasn’t working as expected. When I went to test our configurator in the quote I saw that Part A was not pulling its details. So now not even the second level subconfigurator was pulling details.
This is when I called Epicor. I was stumped. When the analyst took a look at it, he tried many of the things that you all posted above, but he did not restart any app servers because the regen configurator process was completing successfully. Thanks again everyone who pitched in here. Much appreciated. What he noticed was the fact that we were replacing a non-configurable part with a configurable part using a method rule. So he created a dummy configurator for the Ph-Chair part and BOOM, everything was pulling through. I then did the same for PH-Seat and now all of the lower level subconfigurators were pulling their method.
In short, do not replace a non-configurable part with a configurable part using a method method rule. Make sure that both are configurable even if the part that you are replacing isn’t a part you want to configure.
I hope all of that made sense, if not, please feel free to comment and I will try to clarify.
spectacular!
it is surely great news to hear the issue is resolved and even greater news to know the exact root cause and proper corrective action/item to avoid.
)