How Configurator Control Data Works with Epicor Kinetic Product Configurator
Practical uses for PcConData in Product Configurator option lists, pricing, validation, and manufacturing rules.
Epicor Configurator Control Data, stored in the PcConData table, holds reusable values that Epicor Kinetic Product Configurator can retrieve for option lists, pricing calculations, validation, and part mapping. Keeping these values in maintained records reduces the amount of business data embedded in configurator expressions and rules.
This approach is useful when product options, prices, or manufacturing mappings change more often than the configurator’s underlying logic. PcConData supplies the lookup values; configurator expressions and rules determine how those values affect the quote, order, or method of manufacture.
What Is PcConData in Epicor Kinetic?
PcConData is a data table used in conjunction with the Epicor Product Configurator. Its key fields can be organized to represent product families, option groups, selections, ranges, or other business-defined relationships. Configurator logic can query those records at runtime and use the returned values to control the user experience or influence the configured result. This separates frequently changing business data from the configurator’s core design and code.
The PcConData table includes nine key fields and a description field. The first two key fields are Configurator and Type Code; the remaining seven are Key1 through Key7. In a typical configurator-control-data setup, Configurator, Type Code, Key1, and Description provide the core identifying values, while Key2 through Key7 support additional grouping and lookup logic. As with other Kinetic tables, you can also add custom UD fields.
Common Uses of PcConData with Epicor Product Configurator
Populate dropdown and combo-box choices. PcConData can hold the valid values displayed in a configurator control. For example, a product family, model, finish, voltage, material, or accessory list can be retrieved dynamically rather than typed into the configurator itself.
Create dependent option lists. Selections made on one page can be used as keys to retrieve the valid choices for a later page. Choosing a product model, for example, can narrow the available motors, dimensions, or accessories so users only see compatible options.
Maintain pricing lookup tables. Designers can store option prices, adders, discounts, multipliers, or other pricing factors in PcConData. The configurator can look up the appropriate value from the user’s selections and use it in a pricing calculation, subject to the company’s quoting and pricing design.
Map selections to parts and assemblies. PcConData can translate a customer-facing choice into an Epicor part number, assembly, material, operation, or other internal value. Configurator rules can then use the returned identifiers when generating or modifying a method of manufacture.
Drive BOM and routing decisions. Lookup records can provide the data needed to include, exclude, or parameterize materials and operations. This is useful when many product variants share a common configurable structure.
Store product-specific constants and factors. Values such as conversion factors, dimensional limits, labor allowances, scrap percentages, capacities, or engineering constants can be maintained as data and retrieved when calculations run.
Support validation and compatibility rules. PcConData can store option combinations and return values that configurator rules use to identify incompatible selections. Those rules can then prevent users from completing configurations that cannot be sold, engineered, or manufactured.
Centralize reusable configurator data. Multiple configurators can reference common records, reducing duplicated lists and repeated hard-coded values. When a shared option changes, maintaining the record in one controlled location can simplify updates.
Why Use PcConData Instead of Hard-Coding Values?
Easier maintenance: Prices, option labels, mappings, and constants can be updated as data without rewriting every expression that uses them.
More consistent rules: Configurators can draw from the same controlled source instead of maintaining separate copies of identical values.
Cleaner configurator logic: Expressions focus on retrieving and applying data rather than containing long chains of embedded values.
Faster product changes: New options or revised mappings can often be introduced by adding or updating records, depending on the configurator design.
Better scalability: Structured keys make it practical to manage large option matrices and relationships between product selections.
Reduced configuration errors: Centralized, validated values help keep prompts, calculations, pricing, and manufacturing outputs aligned.
Example: Using PcConData to Drive a Configured Product
Consider a configurable machine with several base models. The first page asks the user to choose a model, and that value becomes a lookup key in PcConData. The returned records populate the valid frame sizes and power options on the next page. If the data is structured correctly, records in the same table can represent parent-and-child relationships. A model selection might populate one combo box with parent options; selecting a parent option can then populate another combo box—or another Epicor list control—with its valid child options. PcConData can also map those records to parts, store pricing and other properties, and use custom UD fields for additional application-specific values. Configurator expressions calculate the result, while document and method rules use the mapped values to create the appropriate descriptions, materials, assemblies, and operations. One structured data source can therefore support the user interface, commercial calculations, and manufacturing output.
Design and Governance Considerations
A successful PcConData design starts with a clear key strategy. Define what each key represents, how records are grouped, and which configurators are allowed to use them. Multiple configurators may share some records, while others need records unique to a particular configurator. The available key fields, together with the expressions and rules that consume PcConData, control those relationships. Use consistent naming, avoid ambiguous duplicate combinations, and document the meaning of stored values. Teams should also decide who owns pricing, engineering, and product-option data; how changes are tested; and how records move between development, test, and production environments. PcConData is most effective when it is treated as governed application data rather than an unrestricted collection of miscellaneous values.
Where PcConData Delivers the Most Value
PcConData is especially useful for configure-to-order and engineer-to-order businesses with extensive option lists, dependent selections, product-family variations, dynamic pricing, or complex BOM and routing rules. It is also valuable when product managers or configurator administrators need to update reference data more often than the underlying configurator logic should be changed.
Frequently Asked Questions
Is PcConData a separate product from Epicor Kinetic?
No. PcConData refers to Configurator Control Data used within the Epicor Product Configurator environment; it is not a separate product.
Can PcConData populate Product Configurator dropdowns?
Yes. A common use is to retrieve valid records for combo boxes or other selection controls, including lists that depend on a choice made earlier in the configuration.
Can PcConData be used for configurator pricing?
Yes. PcConData can store prices, adders, multipliers, and related values that configurator expressions retrieve for pricing calculations. How those values affect the final quote depends on the organization’s Product Configurator, quoting, and pricing design.
Can PcConData help build a BOM or method of manufacture?
Yes. PcConData can return part, assembly, material, operation, and parameter values that Product Configurator rules can use when generating or modifying a configured method. PcConData supplies the lookup values; the configurator’s document and method rules determine how those values affect the resulting bill of materials and routing.
Can I use a UD table instead of PcConData?
Yes, but make sure you have a good reason before taking that approach. One possible reason is that you already maintain significant related data in UD tables. If you are starting from scratch, I recommend using PcConData because it serves a role similar to a configurator-specific UD table and is designed for configurator control data.
Build More Maintainable Epicor Product Configurators
PcConData is most useful when option lists, prices, mappings, and manufacturing decisions change more often than the configurator logic itself. Moving that information into governed records keeps expressions and rules focused on how the configuration works, while PcConData controls the values those rules consume. For complex configure-to-order and engineer-to-order products, that separation can make the configurator easier to maintain without disconnecting the customer’s selections from the quote, order, or method of manufacture.
Thank you for reading. If your organization is planning a Kinetic Product Configurator project or looking to make an existing configurator easier to maintain, please contact us to discuss how we can help.
