Keep in mind that “Costing Method” in Epicor REALLY means “Inventory Valuation Method”. If your configured part is shipped directly from the job that built it, there is no “costing” applied. Your cost of sales will be the actual cost from the job itself. Only parts that are received to inventory have “costing method” applied to them.
2 Likes
Interesting idea - I see the potential. If it’s all code looking at mom/bom/boo templates then I guess anything is possible. but I think the idea of pre-configured combinations to match with would be product dependent. If those attribute combinations were limited enough, then I agree this would work nicely, if I’m correctly understanding what you are proposing.
Our issue is that so many combinations exist including over 1000 unique belt width values, that the templates would immediately be some numerical factorial of acceptable individual input values. So we built the mom/boo template with minimal ‘keep when’ rules and use the PCfg code/logic to do all the other variation handling. Technically speaking, we have a ‘seed’ table of acceptable individual input values (and which inputs are required) so the PCfg reads the table based on Mfg’d part number and then renders the input screen accordingly - like the “accordions” in the new kinetic interface.
1 Like
Yeah I was thinking of at least modeling the inputs so you didn’t have recreate the wheel in terms of doing a bunch of cascading drop downs on ud tables, for example. Attributes/Options and unique combinations being built-in to Dynamic Attribute Maintenance.
I’d think the method mapping may become more powerful with AUOM license as, for exmaple, your belt width could be a dynamic attribute on the mtl part as well.
1 Like