Hi, Just wondering if anyone out there would be willing to share with us how they transferred their Configurators from E9 (Progress) to E10 and also share their knowledge of how best to build new configurators in E10. We are in the beginning process of building up our Demo E10 database that will be used to help us move to E10. Needing any help anyone is able to provide to us with regards to Configurators. Would be really nice if we could do an on site visit also. Please let me know.
Any responses would be much appreciated.
This is a fairly deep subject… and the answer really depends on multiple factors:
how complicated are your configurators.
how much progress code did you use?
did you use “.p” programs to extract data from Excel or comma delimited tables?
I have done conversions from e9 to e10 several different ways. I have made presentations at Insights on how to do this. There are two basic approaches:
Upgrade:
run the database through the update. The configurators will “update” but any ABL Code that could not be interpreted will be commented out, and you will need to rebuild in C#.
any excel files will need to be changed to lookup tables.
(the presentation goes on…)
some code needs to be changed for better logic. The new logic on fields is “ON CHANGE” vs “on Pass Through”… the old logic would run your code even if you didnt change a value.
Rebuild:
This option assumes that you want to review all the new capabilities, and simply will rebuild the configurator from scratch taking advantage of the new features instead of upgrading.
Hi Jill, I normally recommend creating new Config IDs in E10, since the Progress ABL code and likely the method rules need to be re-written anyway. Also, you may want to take advantage of the single-Config ID to multiple-Configurable Parts
structure of E10 to reduce your overall configurator count. However…it is also possible just to uplift the E9 DB to E10 and use the existing configurators. I remember working with you guys back on the E9 implementation and can definitely assist. Thanks,
Roger
Tim,
Here is the response from our configurator programmer (Guy Wolgamott):
The configurators themselves are fairly simple for what is actually in Epicor. We use external on leave statements that use a combination of looking at commonly used data in CSV files and a .p program that reads data from a UD table. So I expect the backend to be considered more complicated as while the front end is pretty vanilla. With that I’m sure the configurators will import but would have to re-write most of the code that manipulate the data regardless.
Roger,
Here is the response from our configurator programmer (Guy Wolgamott):
I’ve been of this mindset for a while that we may be better off starting from scratch and use the old ones as reference for building new ones… We have some configurators that make sense and we do use some custom setups specifically to use a single configurator that hits multiple configurators. Although some of our distinct product lines may not fit together well enough to have nothing but color and maybe some of the handle options in common and that is limited in some instances, so at the very least different product lines will still make sense to be separated.
My experience is similar to others you will get the best results by rebuilding. The screens will come across so that will save some effort but a lot of the on leave code will be commented out.
The routines that use the CSV and .p code will need to be rewritten. As others have said most of the code doesn’t come across and any that does will be a bit messy looking. The CSV files might tempt you to use Configurator lookup tables. I recommend that you fight that temptation and use User Defined tables instead. If you have a similar configurators you might be able to consolidate into fewer or one as Roger mentions.
Hi Jill, Definitely sounds like you could benefit from combining multiple config, and taking advantage of more dynamic nature of E10. I would strongly recommend re-examining the current design and optimizing. To be honest, apples-to-apples
may not even be a time saver. As suggested all on-Leave and .p code has to be re-written, .csv lookup files brought inside the database. If the backend is more complex, then the method rules could be updated handle more complex MoM build scenarios. In the
end, it will all a better solution. Take care.