Each time we update an configurator, all existing sales orders have to be reconfigured, or the jobs come out with no operations and no materials. Is this expected behavior? If so, how do you guys manage the headache it causes to update configurators?
Management wants a rapid development cycle for the configurators, but it causes sales and production pain each time we make a small change.
Hi @Evan_Purdy,
When you update a configurator it updates the PCStatus_ConfigVersion which causes a mismatch with existing Sales Order Lines or PcValueHead_ConfigVersion. You can update the Configurator Versions by running the Sales Management - Configurator Management - General Operations -
Verify Existing Configurations process:
We actually use the following BAQ to find all of the Orders that are out of Sync:
PcValueHead - PcStatus
-Company = Company
-ConfigVersion <> ConfigVersion
-ConfigID = ConfigID
PcValueHead - PcValueGrp
-Company = Company
-GroupSeq = GroupSeq
PcValueGrp - OrderDtl
-Company = Company
-RelatedToSysRowID = SysRowID
OrderDtl.OpenLine = True
Then based on the BAQ results we run the VEC process, using the Filter tab, for just those Configurator Parts that are out of sync. I hope that helps somehow. 
BTW, VEC Log files can be found in the EpicorData\Companies\WDI\Processes\UserName folder. It’s good to look through these because we’ve seen some errors and warnings in these logs that have helped us fix issues with our Configurators.
So the verify existing configurations repairs the configurations? Does it re-run the rules and stuff, or does it just restore the operations and methods that were created with the old version of the configurator?
Thanks for the fast response 
No problem! I hope that helps!
I hope this E10 Help file image helps to better answer your questions…(if you double-click or right-click to view image you can see it better.)
Excellent, thank you. I assume verifying alone isn’t enough to un-break the sales orders and jobs, you must also have the “Update Saved Input Values and Set Fields in Part Table” checked as well right?
Now that’s where I get a little hazy and I’m hoping someone else can chime in on this one.
I checked with our Configuru 
and she said we do check the “Update Saved Input Values…” and the “Verify Existing Order Configurations” when we want to update the Existing Order Lines that are out of sync.
All I can say is if you have a test environment then I would try the various options there to see what happens and if they give you the results you are looking for. And here is another E10 Help file on the Update Saved Input Values and Set Fields in Part Table option:
Hey, sorry to bother you, this is my first BAQ. I assume your final return value has to be Parts, but I can’t figure out from your screen shot how that is happening.
Edit: Seems like adding OrderDtl_PartNum To the display columns might be the right route?
I don’t see the field “RelatedToSysRowID” in the orderdtl table, is that the name of it?
My Apologies, it’s PcValueGrp.RelatedToSysRowID = ORderDtl.SysRowID. I’ll flip-flop that in my previous post. 
This BAQ gives a list of all Open OrderDtl Lines where the Configured Part on the line has a mismatched ConfigVersion from the Approved Configurator Version. It just shows you which OrderDtl Lines the VerifyExistingConfigurations process is going to update the ConfigVersion for…(or the OrderDtl Lines that would need to be manually reconfigured.) I hope that helps…?
I just figured it out haha, no problem!
This is an awesome tool, but unfortunately we use a smart string which is never an existing part in our database so we can’t filter by parts 
But doesn’t the VEC window only allow you to select parts on the filter window, not order lines? So I was wondering how you went from Order to part - which is when I guessed that adding OrderDtl_PartNum to the display columns in the BAQ could achieve that.
We only use smart strings as well - I was still able to get it to show outdated configurations, but it did not seem to automatically update them. I think “Save input values” needs to be checked for it to be able to update them, which requires creating actual parts, sadly.
Hey, I tried running this process as we changed up our operation rules up quite a bit, but no luck. Tried it with and without “save input values”.
To confirm, does this process change up the method of the configured part? If I ever try to re-configure the part via another quote it does not overwrite the existing part in the system, rather picks up the old configured part and pushes it through exempting any rules…
@Skapasi if you have access to Epicor support I would call them for clarification. Their experts have spoke to me in depth about running the process.
Unfortunately that was a year or so ago and I don’t have the notes anymore otherwise I would be able to answer this question with certainty.
I am interested in what you find out.
So I contacted Epicor support and they told me that the outgoing part (configured part) must be configurable and its inputs must be saved for Epicor to retain the connection.
If the part is already created as a non-configurable product and has transactions its locked in. I was advised to up-rev the top level part, copy rules and re-run it so the newer rev will create the missing link and thus be a reconfigurable product going forward (if your company uses only a limited amount of naming convention).
So part of the reason I could never get this to work right is VEC dies if you have any message boxes in UD methods (client side)
Vote for fix: https://epicor-manufacturing.ideas.aha.io/ideas/ERP-I-1627
Really??
VEC (Verify Existing Configs).
Yep, directly from support.
