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.
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:
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?
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:
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…?
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…
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).