产品配置概览
“将产品配置为可满足特定要求”这一需求在“企业对企业”和“企业对消费者”关系中都正在成为规则而不是特例。
支持配置对订单方案的制造商拥有更仔细地贴近客户需求的机会。 此外，通过以通用组件（而不是成品）的形式贮存半成品，制造商可以减少与库存有关的成本本。
从制造到贮存理念到配置到订购理念的成功转变需要仔细分析产品结构、产品系列的标识以及组件化。 为了减少部件数和最大程度地减少处理中的货物数，您务必了解产品接口和基于可重用性进行设计。
有几个产品配置建模原则，例如基于规则、基于维度和基于约束的建模。 研究表明，与其他建模原则相比，基于约束的方法可在模型中减少大约 50% 的代码行数。 因此，此方法可降低总拥有成本 (TCO)。 通过从以 X++ 代码为基础的基于规则的模型转为基于约束的模型，您在维护产品模型时不再需要开发人员许可证。
产品配置
在工业化时代，人们在生产品质优良、功能丰富且价格实惠的产品方面取得了巨大成就。 规模经济使工业化世界内的大多数人都能购买我们视为日常生活中必不可少的一部分的汽车、电视、家用电器和其他商品。
随着很多产品变为日用品，人们需要将它们区分开来。 制造商对这一挑战的即时响应使得每个产品的变型也随之产生，以便让客户有更多替代选择。 此策略导致预测难题增加，并导致库存成本和过时的未售出产品增多。
通过采用配置到订购理念，制造商有机会满足客户对独有产品的需求，同时减少和消除过时的库存物料。 当制造到贮存理念转变为配置到订购理念时，随之而来的一个直接难题是必须平衡对较短的前置时间的需求与较低的库存水平。
对此，成功的关键在于仔细分析产品组合和寻找产品功能和流程中的模式。 目的是确定可由同一台设备制造并在所有变型中使用的通用组件。
产品配置功能集包括提供产品配置模型结构的视觉概览的用户界面 (UI)，并包括不必编译的描述性约束语法。 因此，希望支持配置实践的公司可以更轻松地上路。 如以下章节所述，产品设计人员不再需要开发人员的支持即可构建产品配置模型、测试该模型，然后将该模型发布到销售组织。
构建产品配置模型
用户可通过几种方法构建产品配置模型。 一种方法是执行一个顺序流 - 先创建所有引用数据（如基础产品、独特产品和运营资源），然后将这些数据作为组件、物料清单 (BOM) 行、工艺路线工序和产品配置模型的其他因素包含。 或者，您也可以通过先创建模型然后在需要时添加引用数据来选择更具迭代性的方法。
组件
产品配置模型包含通过子组件关系绑定在一起的一个或多个组件。 组件只需定义一次便能在一个或多个产品配置模型中多次使用。 组件是产品配置模型的主构建基块，几乎所有有关模型的信息都与组件相关。
属性
每个组件都有标识其属性的一个或多个属性。 属性是用户将在配置过程中选择的内容。 属性通过约束或计算中的包含来控制组件间或组件内关系。 通过应用于物料清单行的条件，属性可用于确定已配置产品所包含的实体部件。 此外，属性还可通过映射机制控制物料清单行的属性。 与包含和属性设置有关的工艺路线工序存在类似的功能。
注释
创建属性类型时，请避免为属性类型域创建大量的值。 这样做可能会导致产品配置器的速度降低。
表达式约束
基于约束的产品配置模型的使用暗示在用户为各种属性选择值时存在一些限制。 此类限制可借助优化建模语言 (OML) 作为表达式约束来实施。 或者，约束也可以表约束的形式实施。
表约束
表约束可以是用户定义的，也可以是系统定义的。
用户定义的表约束由用户构建。 用户选择用于表示表列的属性类型的组合，然后输入来自所选属性类型的域并用于在表约束中形成行的值。
系统定义的表约束通过以下方式定义：选择要用作引用的表，然后从此表中选择用于在约束中形成列的字段。 表约束的行是在配置时呈现的 Supply Chain Management 表的行。
可通过引用表约束定义并将模型中的相关属性映射到表约束中的列来将表约束包含在产品配置模型中。
计算
计算表示用于在配置模型中执行算术运算的机制。 例如，计算可确定某件特定原材料的长度或抛光工序的处理时间。 计算是必不可少的，请在包含在计算表达式中的所有属性值都变得可用后为目标属性设置值。
子组件
子组件表示产品配置模型结构中的节点。 对于每个子组件关系，必须指定一个引用，该引用针对的是将变型配置技术设置为基于约束的配置的基础产品。
用户要求
用户要求具有子组件的所有要素。 两者的唯一差别是用户要求不绑定到基础产品。 此差别的实际影响是在用户要求的上下文中定义的所有物料清单行或工艺路线工序都将折叠到父组件物料清单结构或工艺路线。 此行为类似于虚拟物料清单的行为。
物料清单行
包含物料清单行是为了标识每个组件的制造物料清单。 物料清单行必须引用物料，所有物料属性可设置为固定值或映射到某个属性。
工艺路线工序
包含工艺路线工序是为了标识制造工艺路线。 工艺路线工序必须引用已定义的操作，所有操作属性可设置为固定值。 除资源需求之外的所有属性均可映射到某个属性（而不是值）。
验证和测试产品配置模型
产品配置模型的验证可在模型内的几个级别进行，因此可覆盖不同的范围。 最低级别针对单个表达式约束。 在这种情况下，验证通常由产品设计人员执行，旨在确认表达式的语法的正确性。
同样，物料清单行的条件或者工艺路线工序可以孤立地验证。
验证还可对用户确定的表约束定义执行。 在这种情况下，用户可验证为每个字段输入的值是否位于对应的属性类型的域内。
最后，验证可对整个产品配置模型执行，以确认整个语法是否正确以及是否遵守了所有命名和建模约定。
正在测试
测试模型类似于运行实际配置会话。 用户可浏览配置页面并验证模型结构是否支持配置流程。 用户可验证属性值是否正确，以及属性描述是否指导用户选择了正确的值。 最后，在测试会话完成后，系统将尝试创建对应于所选属性值的物料清单和工艺路线，并在出现任何问题时显示错误消息。
管理页面
要在组件之间导航，选择下一个或选择产品配置模型树中的组件以将焦点设置在其上。
为配置完成模型
当产品配置模型已准备好在配置到订购方案中使用时，必须创建一个版本。 但是，有几个可改善建模经验的选项。
用户界面
配置 UI 可通过在一个或多个子组件中引入属性组来修改。 此类分组可突出显示特定属性之间的关系并帮助配置用户识别焦点当前在产品中的区域。
模板
可创建一个或多个配置模板以加快配置流程。 或者，也可以创建模板以推销特定属性组合，例如在销售市场活动侧重于一组特定的产品功能时。
翻译
如果产品将不同的国家/地区销售，则可以为显示在配置 UI 中的所有文本创建翻译。 此文本不仅包含名称和描述字段，还包含属性文本值。
版本
最终流程中的最后一个，也是最重要的一个步骤是为产品配置模型创建一个版本。 该版本表示基础产品之间的关系，您可为订单或报价单行上的配置选择该版本，也可为产品配置模型选择该版本。 版本必须经过审核和启用才能在配置会话中使用。
通过 API 扩展产品配置模型
已实施专门的应用程序编程接口 (API)，以便让合作伙伴和具有开发人员许可证的其他人员扩展产品配置模型的功能。 这样做的主要目的是建立一个机制，让使用现有产品生成器的合作伙伴和客户将在产品生成器模型中嵌入的代码迁移到 API。 这样，他们就可以将其模型从产品生成器迁移到产品配置。 但是，新合作伙伴和客户还可能受益于使用 API 扩展新产品配置模型。
API 是使用一组 PCAdaptor 类实施的，这些类可公开产品配置模型的数据结构。 必须为将扩展的每个模型创建 PCAdaptor 类的实例。 在配置会话完成后，系统将检查是否有此类的实例并在发现该实例后运行它。
以下 API 流程图概括了该流程。
配置产品
配置一个或多个产品
您可以从以下位置配置产品：
- 销售订单行
- 销售报价行
- 采购订单行
- 生产订单行
- 物料需求行（项目）
配置的目的是打造满足用户要求的产品的不同变型。 将为每个新配置创建一个唯一配置 ID。 此 ID 通过库存启用跟踪。
多个站点和内部公司注意事项
如果将对站点或者甚至是公司（不同于进行生产的站点或公司）执行配置，则会为供应公司内的供应商站点创建物料清单和工艺路线。 产品变型将在参与供应链的所有公司中发布。