Hi, Curious on everyone’s opinions regarding the setup and sales of parts and the best approach.
Scenario Example:
Company manufactures cars, there are a few different car base options then the buyer can completely customise the rest, there will almost always be at least one modification with the maximum modification amount being approximately 20. One customer may just buy a car base with 3 additional modifications whereas another might have several additional modification. Each modification has several choices for the customer to select from.
Is the product configurator the best option to do this or is there a better way? With this is there the option to list each modification on the sales order?
It sounds to me like your use case is exactly what the product configurator is designed for. You create a configurable “Base Part”, and create a user interface with inputs (text fields, drop downs, numeric fields, etc.). So if one of your modifications is “Paint Color”, you could have a drop down with options “White, Black, Silver, Red, etc”.
You can choose which (if any) are required.
The other possibility would be to create alternate parts and/or alternate revisions for each combination. From what it sounds like, configurator might be your best bet.
Yes, there are a few options for this. I’ve seen companies create UD Fields on the Sales Order Detail table (OrderDtl) to store the values, then add those values to Order Acknowledgment. I’ve also seen where a company will just build the Line Description based on the selected inputs. I’ve also seen them save all the inputs in a JSON string, so that they could put them in a table on reports. It all depends on what all you need to save and where you need to save it.
The product configurator is really powerful and will be exactly the tool that you need. You build a base method containing all possible materials and operations and then the configurator rules remove the bits you don’t need.
Once a part has been configured, it can be re-configured from within sales order entry (or quote entry if you use quotes).
The only thing to be careful about it potential to publish the configurator on-line to external customers. It does work through EPICOR commerce, but it is not great so if this is a requirement, or even on the roadmap for the future I would avoid it and have a look at some of the CPQ options on the market, EPICORs tool (Kbmax) looks good, but there is also PartTrap One and I think Silk have an offering in this space too, there are likely one or two others too.
As part of the migration from classic to kinetic, I ditched the configurator module and just made my configurators in application studio and the code with Epicor functions. No regrets.
If you have a lot of variability in the number of columns, I suppose the lookup tables can be nice. I didn’t have that, so I just took some UD tables and added the columns I needed. Much faster and easier to use throughout Epicor.
If I did need something that dynamic, I would probably stuff JSON blobs into fields. That is essentially what the lookup tables are doing, but with XML I believe. Its why they are so slow.
I no longer use any part of the configurator system - its off our bill
Right, I wasn’t replacing the configurator entirely, but supplementing it. The configurator values determined a lot of the scheduling / ship & promised dates, which was fine. But if something was configured then put on / taken off hold, I needed to recreate the logic so that it would update dates on the same rules. Since I already had everything in Product Configurator / Lookup tables, it was easier not to recreate them and deal with double maintenance.
Its engineered at the quote level, so primarily the BO QuoteAsm. I just did one by hand with a trace going and then copied the BO calls from that. We don’t save any configurations to the part master, way too many permutations.
Ahhh that makes sense. We didn’t use quoting, just configured from Sales Orders. I wanted to do something similar to what you were describing, but every time I got to Job Engineering I decided it wasn’t worth it lol.
Does your custom solution still build jobs from the data entered in the configuration, like how the rules work in the standard configurators? We’re considering our options to replace our old unreliable configurators, and I’m curious if this could cover our use case.
I could make it build jobs directly, but we always work from quotes anyway, so when the order job wizard is run it takes the BOM from the quote and puts it on the job (standard base epicor functionality)
Evan - I’d love to pick your brain on this at some point.
We use a lot of our PC data for reporting purposes instead of storing it again as UD table data. So, we’re discussing doing this, or going 100% external with it, but doing basically the same thing - store the data inside Kinetic and using functions to do the heavy work.
But we’re torn on using the original BOs and PCRules versus replicating the QuoteAsm data manually because it would require writing the PC inputs data back as multiple XML blobs into the table. Are you storing any of the PC data in the original PC data tables?
No, I’m not touching any aspect of it, and we stopped paying for the module and removed it.
I found that generally I was adding no columns (inputs) or only a few a year, so I ditched a dynamic data structure (xml) and went to a static structure (UD columns). No data manipulation required.
Used one UD table to replace constants/settings, and then a few UD tables in a one to many setup.
Thanks everyone! This is helpful. How does the costing work for this? If there is this configurable part and it can have anything from 5 materials to 60 depending on the selected configuration and additional times and operations as well what does the part cost go in as into the system? Can configurable parts be used for cost trending and production time KPIs?
Assuming you’re not using Standard Costing, the cost should come directly from the cost of materials / material burden + labor costs based on the configurator results.
As far as KPIs on production time, since it sounds like it can be wildly different from one configuration to another, that’s going to be a little difficult if operations are so different. When we were doing something similar, we compared the ProdStandard (estimated time) to the actual labor time. It was a little extra work to adjust ProdStandard times based on configuration, but worth it for reporting.
I wonder how far one could go modeling inputs for MFG parts with Dynamic Attribute Classes. I believe the base functionality is there even without AUOM and PC licenses to model inputs and possibly calculated attributes. There’s no relation to BOM and BOO but one could possibly have preconfigured ‘template methods’ from which the new config could match on Attribute Set then get details.
