If I update code in rules on a configurator whether its UI, method rules, or UDF code and then try to re-configure a line from a past quote or order, it does not recognize the current code changes. However, when I create a new line, it does pick up the current code.
I did look at the ConfigVersion inside PcValueHead, and it appears both lines have the same version number.
Any ideas on how I can get previously created lines to recognize the latest code changes in a configurator when re-configuring?
I’m not doing anything with the smart string part creation. The problem exists when I get details from Quote Entry or generating a job.
Here is a screen shot on the BOM difference between a new line I created today, and a previous line that I re-configured with the latest configurator code.
Any ideas as to why the BOM would be so different between the two?
Both appear to configure with the same speed so I think both are utilizing the same code.
Old post but just wondering if found work around? This does it to my configurators as well, as I would then need something to change that will trigger code. Say for our purposes a paint code, once cahnged or null then put proper color in it would then pick up the changes due to a field value changing causing the entire code to execute. So by doing that it does the reconfigure rules.
Many times, even today I typically end up adding a completely new line instead of using the old configurator. It seems past configurators don’t are somehow “cached” with the old configurator code. Even the latest versions of Epicor still behave this way. To me, it seems like it should be an Epicor error, but I haven’t pursued it any further since I just create new lines instead.
Ah, yes there is a cached old version that remains unless you run the verify existing configurations. That would update your changes, not update the part you still need to manually re-configure on the line level deleting any attached jobs that happen to exist to get the part to truly update. But it should give you the ability to actually take the changes if you re-configure the order line, may need to do something like change a field that triggers the new rules/parts/etc… I actually have a BAQ I got from on here someplace I don’t remember whom created it or what the topic was but this BAQ will display any configured part that is not on the same version. Version being created every time you change a configurator, in that if this is the cache issue you are running into it would show with that BAQ and then you’d know you’d need to run the verify program.
FYI for anyone coming to this later, did find the topic where I got that baq from. Worth reading to understand what the verify does and doesn’t do. Also to give credit to who created this baq to begin with.
Oh hey, one of my threads. Very sad that they don’t warn you about having messagebox’s in UD methods. Would require practically a whole configurator rewrite. We waste so much time reconfiguring it might be worth it though. Probably wait and rewrite them as kinetic configurators.
My problem is that I don’t create physical parts, all out configured parts are part on the fly creations, building office furniture with several options that change the part number. So basically a base part configured pulls then builds new part on fly to create part based on the selected options. So even though I never used the messagebox in the UD methods nothing would update for me, as it still didn’t update the background data for the configurator on order line level. Fortunately our changes tend to be running changes, so its future orders entered to get the changes and I don’t need to worry most of the time unless a bug is found then it’s a mess dealing with changes to parts that need changed.
There was an idea to actually allow it to update the configuration on the order line and not just reset the versions. It went into future work status but haven’t heard anything new on it in a long while.
