Is there anyone here who uses Configurator in conjunction with “sales codes”? Looking for some experience and maybe a demo if you would be up for it.
I feel like I have a pretty good grasp of this, but I was asked to ask.
I explained, “There is no base Configurator. It is wide open - it’s whatever the user [me] feels like programming. You just need to supply the logic tree (this choice prohibits or demands these options, etc.).”
Our lead engineer doesn’t really like my explanation. He’s sure I am missing something and that there is an easier way. Or that we could learn from others who have gone before.
When I say “sales codes,” I think that’s common enough jargon, right? The customer or salesperson says what options they want for their truck (in our case) - orange grating, long wheelbase, cold-weather option package, etc. - and each selection has a code tied to it on an order form. Then the Epicor geek has to turn those codes into logic in the Configurator and make an indented BOM for it.
Nail on the head. It’s free-form, anything you want to make of it, and the data it supplies back ot the quote/order/job is as much or as little as you want (via Document rules). People have extended it using custom DLLs, the new Functions are available to use with it (in 700 I think) and others are doing some massive data calcs, but…
The term you’re looking for is Smart String. The configurator can be a simple Q&A service to create a smart string, that really is your part number for the orange grated, long bed, cold-weather ‘thing’ in your inventory. So at Order Entry time, you enter a generic part#, click the Configure button and on completion, the generic part # is removed and the real part# is inserted.
Yes, I think maybe I jumped over a step and confused you. A little bit of the problem is terminology, another is maybe thinking your codes and the configurator values are different - they may be, but they may be the same. Depends on the design.
Also, Smart Strings can be full part#'s or just data strings that can be used elsewhere down the line. My post was an assumption/example in simple form because it sounds like you are just beginning your path and we can’t really discuss all the variations possible here in this form. In my scenario, the Part #s exist for all variations of the manufactured part and it’s options, so the smart string will simply ‘pull’ the right part#, MOM and BOM into the order/job without having to bother with the document rules. But let’s take another perspective…
The “options they want” are the questions in the configurator - and now the answers are data in variables for use later.
This is the defined relationship, or data map, that you will use to build the logic in the document rules associated with the the configurator, that apply to the MOM/BOM for the part# being manufactured. These rules are basically the logical representation of the process you use to take the physical order form (selected options) and translate it into the BOM.
The Logic in the rules will substitute, alter, or change values in your BOM. Some folks have a BOM with just placeholders and the rules change the part#s, others have the right part#s and the ‘Keep When’ rules add or subtract part#s from the BOM based on the translation… And there are other variations of course…
That’s basically what I was expecting for an answer.
I spent the better part of 2019, 3 hours a week, doing a proof of concept of a configurator (for a different project) and had three days of training in 2018, and I had the same notion as you - the magical “sales codes” are just questions to be used for logical decisions later.
This is either something I have forgotten or was not aware of. I understand smart stings as part numbers. But what is the “data string” concept? Are you hinting at sub-configurators - or is this something else?
we don’t use smart strings, but it’s data, so there can be multiple uses. and once it exists as a data point, you can access it in various places (we do that with other CFG data points)
There are two ways to use them - as input into the configurator to set a bunch of values When the Smart String Configuration check box in the Configurator Designer > Status sheet has selected for the item being configured, the Epicor application displays a dialog box during the actual configuration session, prompting for entry of smart string value. It then attempts to process and load all associated configuration input values from the supplied string
or
As Output form the configurator as the new Part# When saving a configuration, the Epicor application processes all of the selections made in the Input Rules > Part > Smart String sheet. For example, if the Customer Part Number check box has been selected, it updates the Customer Part Number field in Order Entry or Quote Entry with the newly created part number.
Both of these are from the Config Tech ref from a few years back… so the text may be different now, but the idea is the same…