I’m trying to evaluate the epicor configurator to replace our current one, and because we have a very customized product I was hoping to get my hands on it at Insights to do some small testing of things that we feel may be issues. As that was not possible, I’ve been trying to go through our account rep at Epicor but he said that they don’t give licenses for the demo database. Hoping to get some feedback about how to test this thing properly. Don’t really want to spend thousands of dollars on this just to come to the conclusion that it won’t really fit for our needs.
Well, one of the potential issues is part number generation. We have about 20ish different options which combined come up with millions of combinations. We have our own external code that generates part IDs in Epicor for these, so I want to make sure we can still reuse it for generating the part number.
The 2nd part is BOM generation. Going through demo it felt like most of it is putting all the parts in the BOM and then having rules to remove them if not needed. That would be probably hundreds or thousands of parts in our case, and a lot of duplication where parts go together. We also have intelligent parts that are pretty much made to order that would be subassemblies and I’m not sure how that could be dealt with.
We’ve been slowly extracting some of the functionality from the current configurator into external dlls so we can reuse it, and would be nice to know if there’s any limitations to this. Our experience with both client customizations and bpms is pretty positive with this, being able to use c# code, but I’m not sure if it’s also available for the configurator in all its different aspects.
Edit: We’re on prem btw, so we wouldn’t be as restricted as the saas folks.
If you have the programming skills to create these DLL’s I would just go the whole hog and make your configurators C# programs that build BOM’s via the REST API. I feel like the configurators get very little love or attention from Epicor, don’t don’t really provide much value of their own. Since you have to do the vast majority yourself anyway, you might as well save some money and roll your own with REST. You’ll be able to reuse the REST skills do other projects in Epicor as well later.
Also Epicor hasn’t made it super clear how the configurators are going to fit in with this whole Kentic direction, but its clear the REST API as one of their more modern additions is still getting love and attention, and is here to stay.
I’m a bit of a grouch with unreasonable expectations though, other people should chime in too.
Hmm… wish I wasn’t such a lazy bugger, I bet it would be possible to make a tool that converts a standard configurator to a standalone c# library that uses the Epicor REST api…
Hi Pedro, I’m quite sure you can utilize any existing part num generation code inside configurator. If you create Config Type = Product Configurator, ie. for internal ERP use, then C# is the default programming language. Also, you can
also use the Template BOM approach instead of Super BOM which means you don’t need to create a with every imaginable part on the Configurable MoM. The smart part num convention you currently have will likely make the method rules much simpler and much easier
to create and manage.
Other than it is simple to demo the Super BOM approach isn’t one in typical usage in my experience. Usually you have placeholder part numbers for items that the configurator will replace and then using lookup logic the configurator replaces the part with the option chosen. So in a drop down/combo you might have three choices of lighting options, when they pick one that part number associated with it is used to replace the placeholder. If they don’t pick an option the lighting placeholder is deleted…
The current Epicor configurator isn’t very web friendly, they do have a typescript based one but it is new and I believe only available with the Dealer Portal. My first go around with it wasn’t fun and for now the client is using the standard configurator.
There are a number of third party configurators that you can use. Because Epicor does a decent job of allowing access via Rest and other avenues you can bring the data in from the external configurator and work it as needed. For example using a no-inputs Epicor configurator you can take the data and build a BOM/BOO (aka MOM) for parts on the fly.
You could also roll your own data entry form and push the data into Epicor.
Any of the roll your own or external configurator does need to have some sort of “get details” functionality when the job is created to build the MOM. As mentioned above one approach is using a no-inputs configurator to build the MOM. Otherwise you have to roll your own custom “Get Details” routine that takes the data from the external configurator and builds the MOM. Not super complicated but still some work is involved.
Right. Quite familiar with that as we do currently use another configurator that we integrated with Epicor (using BOs as REST was not available back then). It’s getting long in the tooth and we’re looking at replacing it, and the advantage of using the epicor one is that we wouldn’t have to do the integration with Epicor and make sure that nothing breaks when upgrading Epicor. We could potentially just build our own configurator from scratch, but would take more time and resources, plus the maintenance afterwards.
If you are mainly going to use it in house (not on the web) the Epicor configurator works quite well and as you mention it has all the integration done for you. The level of programming skills needed isn’t that high. The key is building a table driven configurator so that there is minimal hard coding in the configurator. Since you already have a configurator much of your design may already be done.
My stock warning is stay away from the configurator lookup tables, you may have seen them as part of a demo but they take more work than they are worth and not very efficient. Use the generic user defined tables.
@Jkinneman has some good comments, agree with what he says for the most part.
I’ve had my configurators break on Epicor updates several times, and the story is REST integrations should be a lot less brittle than direct BO integrations.
Still, if securing funding isn’t a nightmare at your company the Epicor configurators are good enough for simple configurators and consultants will be more familiar with them vs some homemade solution.
Generate a smart P/N. we don’t actually use the configurator’s “Smart P/N” functionality, but build the desired P/N in the configurator then assign that to the PartNumber.
Have some that use SUPER BOM’s - these are the ones that start with a BOM that has every possible part your final product could possibly use. And then use “Keep When” rules to exclude an of the parts we don’t want. If your widget was available in Red, White or Blue, you’d need three Mtl Seq’s in the BOM. one for each color paint. Then rules would be used to discard two of them.
Have some that use Template BOM’s - these are ones with a generic BOM, with place holders for the parts you would need. Then code updates the component part number to be the one you want. If your widget was available in Red, White or Blue, you’d just put one Mtl Seq in the BOM. one for White paint. Then code would change the P/N of that Mtl Seq, based on the user input.
Don’t have the Cfg’r create a Part table entry for every Cfg’d part. Only when it needs to go through inventory. Otherwise leave it as a Make To Order only “part”
Might be a little late, but here are my two cents.
We do use Configurator extensively, all our products are configured and we have nested configurators(3 levels). Also, our quotes are several lines most of the time, with small changes between them.
Regarding the part numbering, configurator will likely be able to support your needs.
But…
As Evan said, configurators are prone to break. Any change as simple as it might seem requires unapproving the configurator and aprroving again, and old quotes/orders get bashed… There are some utilities to fix them, but still they might require to re-configure each product on your quotes pending to convert to order.
Complex configurators are slow(either to open or save), so if you need to re-configure your products as expressed in the first point, it might be a nightmare.
The configurators save a lot of data into Erp.PcValueSet table, and I mean a lot. Back in 2017 we had several GB in that table which forced us to only capture our actual orders in Epicor and quote everything on our quotation system. This was reported but was only fixed until 10.2.500. Still after that fix, and the fact we deleted old configurations this table is still the biggest in the database. In a 15GB database in 2018 10GB were solely this table after just a few months running, to illustrate this.
As said before, our quotes are several lines long and all our products are configured, so we had to customize the quote screen a lot, in order to make the process more efficient, still a quote of 50 lines takes a lot of minutes to process.
So, Product Configurator is nice, also a great way to configure products with no technical background needed. Great for companies with product engineering area and great at allowing customer service to enter what might be a complex product without technical expertise from them.
If you expect several changes on your product engineering or configurator rules, have an abundance of this products and the speed of your quotations and variations of the products in them are a must. Maybe it is not the best tool, when you have a working configurator of your own.
As we are today, we are going to create an interface from our quotation software(which was to be killed and now it will be renewed) into Epicor. Still looking if REST or customization inside will be the best option for us.
Ohh man, and boy are people pissed to have to reconfigure a billion orders with many lines
Its hard to get configurators to go fast, but as @Jkinneman stated, avoid the configurator lookup tables, keep as much code as possible out of input-value-changed type events as its very easy to create chain re-actions…
Like anything else, Configurator has its quirks and it’s not going to be able to do everything you could possibly do in your custom DLL. But overall it is a great piece of functionality IMHO.
To me the best part is you can get Product Designers / Production folks building their own configurators with zero c# or programming experience. As long as you understand Methods of Manufacturing and basic logic it’s easy to build a semi-complex configurator by referencing a handful of code snippets. This was huge for us because it allowed us to take most of Configurator development out of our IT dept and put it in the hands of the people who know our products the best.
Wow, I’m jealous. I spent significant effort evolving the configurator design to prevent misuse, mistakes, and make it more clear how to use. Users making their own configurators
Lol, to be fair I am mostly talking about an exec w/ an MBA who likely could have been a programmer had he chosen it for a career path… not a typical user. But still, it was easier for him to learn the programming than it was for programmers to learn our products / methods of manufacturing.
100% agree It is a pain if you make a change to the configurator code and have a bunch of quotes/orders that have to be verified. With a well designed table driven configurator most of these changes can be avoided.
A part number change or adding or removing an answer is done to the supporting table and the configurator won’t trigger the need to verify existing quotes and orders. Then most of the time a configurator should only need touching is if you need to add a new question or remove an existing one. If that is happening on a regular basis I’d suggest a pause while things are stabilized.
Another big red flag is when there are a lot of IF statements that reference the answer value. If Inputs.FrontBumperPartNumber.Value == “Chrome”… This usually means if there is a new type of bumper the code has to change to account for it.
The first piece of advice I give clients is don’t even think about a configurator until you have stabilized how you want to use Epicor to build your product. You can model everything the configurator can do using standard functionality such as adjusting part numbers, production standards, whether to use a sub-assembly etc. Once that is done you can start building your list of questions you will ask the customer, what possible answers are allowed and what affect the answers have on the MOM.
When I get a solid requirement document with a solid MOM, configurator development goes quickly and the need to circle back to tweak the configurator is greatly diminished.
