We have a product that is highly configurator-reliant and time consuming for data input. The bean-counters here have been looking for ways to pass this data input over to our wholesalers and customers for a while. I’m sure we’re not breaking new ground here, others must have tackled this problem before.
I’m just at the exploratory stage of this project but I can foresee it becoming a higher priority down the track. What I’d like to know is, has anyone else here been down this path, and if so, how did you approach this?
I’ve had thoughts of creating an interface through our web portal that our wholesales can use to do their own data input and saving this either in a DB or XML-type file which we can load into our configurator rather than having to re-key orders. Is there a better way though? Has anyone tried to write a program that would bypass the configurator and write this input directly to the tables? From what I see, the configurator stores its data in multiple tables and uses some pretty funky methods to do so. How difficult would it be to write this info in using the likes of rest?
Just interested to know if/how others have approached this.
I haven’t gotten past the exploratory stage, got too busy plus COVID messed stuff up. My current plan is to make the configurators external web apps that talk to Epicor via REST. You could make a little buffer DB if you don’t want your website to go down with Epicor. We are low enough volume orders and we are dead in the water without Epicor as it is, so I think I will forgo this complexity myself.
I’ve gotten to the point were someone can configure a product internally from a website without touching Epicors configurator but all the rest of the ecommerce stuff is lacking still. We looked into ECC and found that it was extremely expensive and wouldn’t meet our needs without excessive customizing.
I’d love to hear what other people are doing, but I think the number of people with complex configurators is actually pretty low.
It’s best to avoid direct table updating for various reasons from Epicor employees listed on this site.
Have you looked at the No Input Configurator? I believe it is available on 10.1.600. If you’re able to put your options in the Part Number, then the No Inputs configurator can parse the Context.PartNum field and run the Get Details, etc.
You can do a similar thing with a single input configurator where you pass it a smart string/json string/whatever and then populate other hidden inputs to reduce the amount of manual entry.
A third option is the use REST to populate a UD Table with a smart string and then have the Configurator read that value, parse, lather, repeat as above.
Yes, if you go this route build your MOM via the proper REST BO’s and set pricing via the right quote / order BO’s. Very good point. I forget on premise people can even do direct data access like that.
Epicor’s ECC does support running the product configurator directly through an EWA Deployed configurator. This makes it so your customer specifies the part # on ECC, and then they can press “Configure” and answer the configurator questions. These answers are then used just like Epicor configurator run from the epicor client. In fact, you can “reconfigure” an order later.
We have multiple Epicor customers who are running EWA configurators. One has over 150 configurators running in Epicor Commerce Connect.
Thanks @Mark_Wonsil. My first thoughts were somewhere in line with your third option. I haven’t heard of the No Input Configurator option and will look into this a bit more. I’m not sure if I could get this to work because our 250+ materials build from rules that rely on the current inputs. You’ve got me thinking about hidden inputs though, I’m guessing this is what you’re talking about with your single input config. Would it be possible to have ALL inputs hidden and populated by the OnLoad using context to look up the relevant set of data from a UD Table? This UD Table could be populated by REST as you’ve suggested.
You’ve got the wheels turning in my head on this one. A bit more research required and some experimentation but it could be a viable solution.
