Here in the company I work for, we have several major products that are heavily reliant on the Product Configurator. We also have a list of additional products that management want configurators written for, some simple and others quite complex.
I’m reading lots about Epicor’s transition to Kinetic, trying to garner the feasibility of continuing development along our current path. I’m sure the questions have been asked but I’m finding it difficult to find any concrete answers. What are the continued plans for the Product Configurator in an ERP with a heavy Kinetic/HTML based front end?
Are tools being developed that will supersede the configurator? Will the C# based tool become unusable as Epicor moves further down the browser-based path? We have a lot of time and energy invested into our current setup and we’re getting a little nervous with the thought of continuing to develop with tools that may soon become obsolete.
Are any of you (many) people who are cleverer than me doing configurator-like things with REST? I feel like this is where I should be investing my efforts rather than writing new C# based configs, but I haven’t heard of anyone doing this sort of thing. Is there a better way forward that I haven’t come across yet?
Configurators aren’t going away. Looks like they are going to provide a conversion tool of some kind. I wouldn’t expect it to work great. So you will be able to use your classic configurators for however long it takes you to port them. I think all your UD methods will be fine, but your event code will probably need a lot of work since they are trying to take all the logic out of the UI.
Yep. Unfortunately it was a sloppy proof-of-concept that I intended to get done more properly, but since it works we’ve been using it and I’ve been working on other fires. But its pretty simple. Doesn’t take many rest calls to build a simple MOM & set the price.
That idea make me very curious as we live and die by the CFG and have a long list of optional parts and operations per MOM. Count us in for a demo too, please!
configurator is being redesigned for Kinetic. This will then better support the configurator both in Kinetic as well as when you want to run it in Epicor Commerce Connect (ECC).
I personally have not had a chance to see it yet, but once I have a chance, I will be taking a full tour. I believe that all your server side UD Methods will be unaffected. Client side should still support C# code. BUT if you do some fancy things with screens (moving fields around, field sizes, changing colors, etc) you will probably need to reconsider this because Kinetic handles screens and fields so differently. basically anything done with winforms/infragistics will need to be examined. I have demonstrated some of those fancy things in the past, and I believe that I will need to come up with new examples of how to do these things in the future.
@Evan_Purdy, add me to the list of people who would love to see a demo of what you’ve managed to get up and running via REST. You’ve got me intrigued.
The thought of having to rewrite our configurators is a bit daunting. We have some rather complex multi-page configs with quite a bit of client-side code. I’ve been wanting to go back and rework some of these for a while to help speed them up (they run terribly slowly) but like Evan, there always seem to be other fires that take the focus.
@timshuwy thanks for the advice. I’ll be holding off with any major interface updates for now until we make our imminent transition to Kinetic. I’ll keep in mind whether my code is client/server side too. I’ve already moved a lot of my code to UD Methods so hopefully that helps us transition easier too.
Am I correct in assuming that UDMs will still be C# driven?
As we just purchased configurator and are slated to start implementing over the next few months; would we be better off waiting until the dust settles, or can we design and start building now, keeping the near future in mind? The intended use is primarily as an internal quoting tool only; although I can see our service dept running with the concept of customer being able to order frequently used service items.
Dang Paul, wild time to start with the configurator given the timing of Kinetic.
If it is a simple configurator I bet you’d be just fine starting now.
I would bet that the nuts and bolts of it stay the same, but who knows… @timshuwy do you believe that the changes to the configurator will be mostly UI or are they going to change the underlying architecture of how we relate it to parts, etc.?
Changes are mostly UI changes. I have not seen any functionality changes. @psiebers, I would go ahead and start learning, especially how the Method Rules are applied, as that is where a lot of time is spent, and very little (if any) changes happen there. Also learn how to build User Defined Methods. Those are one of the tools that you will consistently use.
as @utaylor said, the tech ref guide is a really good source.
SOME of us learn by doing… my favorite way is to create a mini-configurator that is only for testing purposes… i add a few fields, and start calling UD Methods from the “on-field-Change” section to see how they work, passing different data, etc. It took me a few tests to get my head wrapped around “parameters” and passing/returning data.
@psiebers feel free to email me if you like. ryan[at]bartlett.net.au
Happy to share some knowledge and code to help you get up and running. Can let you know the things that have worked well for us and the things we’d do differently if we were starting over again.
My biggest piece of advice would be to spend the time setting up your BOM/MOM before you begin, especially if you have a lot of parts associated with your configured item. If you’re like us and you have lots of parts in your BOM, spending the time setting up phantom BOMs and subassemblies can save you HEAPS of time coding your method rules and make your configurator much easier to maintain. Epicor can also be a bit temperamental when adding additional parts afterwards, especially if you’re changing part sequence numbers. Familiarity with your parts is key as far as I’m concerned. Everything else is just finding the right syntax to make Epicor do what you want it to do.
A tip: use the guide to version 10.1.500 (or earlier) to see the “configurator in action” section.
They removed it along the way, and I put in a ticket about that years ago, but clearly they are not bringing it back.
That’s the 10.2.700 guide in the pic. It’s in the TOC but not in the actual document. Seven times it says “refer to the [something] example in the Configurator in Action section.”
For years this company has used only portions of Epicor and the interpretation of the functionality of the modules has been left to the individual. Operations have not really been used in Methods, and only to facilitate labor collection. With a large engineering department and being ETO, we have years of designs, yet keep reinventing the wheel with every project.
So now is our time to get it right and develop strict guidelines on how to structure our Methods right, so we can use tools like Product Configurator and EWB Workflows. I have been scouring this group and other sources. Feel free to keep passing along any words of wisdom…
