Hi all,
I have been struggling with this problem for some time now and I can’t seem to find an answer, which makes me think I must be doing something wrong or everyone else just perseveres with it.
I have around 20 product configurators, all used for make-to-order. None are fixed BOM, and they all use the configurator rules to build the BOM.
My problem is that making even the slightest change creates a new version number for the respective configurator and any existing open quote or order lines do not create a BOM when the jobs are created because there is a version mismatch. I have an updatable dashboard where I can up rev all the existing lines to the new version, but it is time-consuming and does not feel like it is the right thing to do.
A simple example; I had to change the format of a numeric editor box on a configurator screen to show 3 decimal places instead of 2. I un-approve the configurator make the change and approve, simple, five-minute job. However, I now have 30,000 existing lines that are not going to create BOMs when jobs are created.
I am hoping someone else may have come across this problem and solved it, or maybe I am missing something obvious. Either way, I would really appreciate some guidance with this. TIA.
Your assessment about working around the issue is correct for us. When we made the move from version 9 to 10, we were able to consolidate about 3000 configurators into a single, data-driven one. We realized early on that we had to manage changes to insure nothing we did affected existing configurations, and then update versions on quotes and orders. Luckily for us, since even the numerous queries used are dynamic (they can be added and adjusted without changing the actual configurator), we the configurator itself never changes. However, our rules also use a dynamic, data-driven approach, and Epicor forces that code to live completely within each PCRuleSet. So we frequently have to push code updates and then do a configurator “re-save” version change to “publish” it.
We’ve documented the this to the engineering users as a two step process: turn the configurator off/on to bump the version, then run the applet we built to roll-up the versions on existing quotes and orders. It was a little difficult at first getting everyone to remember to do the second step, but three years in it’s become second nature.
It’s annoying, for sure, but I also understand it from Epicor’s perspective. They have no way to know if the configurator changes invalidate any or all of the existing configurations. Were it seen as a big enough issue, perhaps they would create a secondary system that would allow folks doing what we do to tell the configurator to not update the version.
It may be moot for us, as we’ve purchased the new CPQ configurator, and have finished stage one (the UI portion) of its design. We’re just starting the BOM rules conversion. It looks like this may alleviate this particular issue, but no doubt there will likely be a trade-off to some other annoyance. I’ll know more soon.
Hi Bob,
Thanks for your response, I feel a little better knowing that it is not just me who has had or is having this problem.
I fully agree that major changes, like configurator rules or the actual schema model, should require either a revision update or re-configuring (I always update the revision and let existing configurations go through the system until eventually, I un-approve the old revision).
I find that I can often change code in the UD methods while in test mode without having to approve / un-approve the configurator but this is not always the case so for peace of mind I always un-approve and re-approve when I’m done.
I like the idea of being able to choose whether or not to up the version number but I guess it is reliant on the guys like us making the changes knowing what the impact will be if we choose not to.
I have not come across the CPQ configurator before, I shall have to do some digging! Is it a big improvement on the current Epicor offering?
It’s a very different, modern platform, and cloud-based, but integrates with on-premise.
Obviously, the devil is in the details, and use-case impacts whether or not it is a better choice. We were just starting a search for a customer-facing configurator when Epicor announced this acquisition. Because it was created outside of the ERP environment and meant to be an integration, it has several advantages including speed and elegance. The Epicor integration will be the critical factor, and that’s still a work in process based on the digging I did at the most recent Insights. Hopefully, they’ll get that perfected soon. They seem to be providing significant resources to accomplish it.
I use a BAQ that tracks the version mismatched configurators. Changes are often done on our end and we have 20+ configurators all using parts on the fly. We then run the Verify Existing Configurators App. Note I am using classic view yet, so not sure what that looks likes with kinetic configurators. Haven’t moved to them just yet because of the large number of configurators that’d need to be re-worked for that move. But that fixes our mismatch problem usually in minutes with hitting what could be upwards of a 1000 configured lines but usually in the hundreds. Only issue we have is that if there is a change that it doesn’t update the configured line on the order only aligns the version so it will get a BOM, but doesn’t take into effect change unless you manually re-configure the order line. There is an active idea for this to be added with Epicor, as they ask me about it now and again so maybe that end will be fixed in future upgrade at some point as well.