Understanding Configuration Models

This chapter provides an overview of configuration processes and models and discusses:

• Configuration models.

• Configuration rules.

• Syntax expressions.

• Configuration binds.

• Language sensitivity in Product Configurator.

Configuration Models

Product Configurator is a rules-based system that enables you to order and manufacture complex items and products. You can define custom order-entry pages for entering and validating configuration information. The configuration information that you enter determines the specific options, components, and operations that are used to create the end product.

Configuration rules contain elements such as processing filters and rule actions, which are tied in with conditional expressions, validation methods, and variables to enable complex, yet flexible, product configurations. These rules are organized into configuration models to determine when and how the system processes them.

Configuration rules work in a logical tree structure that determines the order in which the system processes them. While each rule is a grammatical statement that performs an action, the configuration model dictates the context of the statement. You can use a rule more than once within a model, and you can nest submodels with a model in order to streamline the overall configuration solution.

Configuration rules are executed based on the tree hierarchy that you define in the configuration model. If the condition of a rule is met (that is, if the condition syntax for the rule is evaluated as true), then the action of the rule is performed. The system processes all of the rules in the order of their configuration model placement unless a true child or a false child exists that satisfies a condition within the model. In that case, the system branches to the designated child and processes the rules that are in that level. The system follows the configuration model down through the hierarchy, from the parents down through the children, before returning to the top logical level.

See Also

Creating Configuration Models

Configuration Rules

The combination of setID, functional area (distribution or production), and rule number uniquely identify each configuration rule. Some of the rule actions in Product Configurator are specific to distribution functions, such as creating a sales order, calculating prices, assigning costs, or to production functions, such as manufacturing processes. The rules that apply to both distribution and production functions are called common rules.

Because the configuration models for the distribution and production areas are independent of each other, an individual rule works in only one of the two functional areas. In addition, many rule actions, by their nature, apply to only one functional area.

Rule Filters

You can use effective dating and rule processing modes to filter rule processing.

Effective Dating

In addition to a rule number, each rule must have an effective date and an obsolete date. For each model, the system processes only the rules that are in effect, based on these dates.

Effective dates enable different sets of rules for the same model to be maintained simultaneously. As features and options change, the configuration can also change (without losing the original configuration rules). By changing the effective dates on the rules, you can process different sets of rules. Effective dates are not part of the key, but you can use them as a selection filter for retrieving rules.

For order entry, the default effective date is the order date. For direct production and direct requisition, the default effective date is today’s date. For production rules, the default effective date is the production start date estimate—that is, the scheduled ship date minus the estimated lead time.

For example, if the effective date is August 6, 2000, and the obsolete date is August 10, 2000, based on a sales order date, the following occurs:

Rule Processing Modes

Rule processing modes are designated as you create rules. They are filters for rule selection during processing. They specify whether a rule processes in order entry, direct production, or requisition generation.

See Also

Creating and Maintaining Basic Rule Characteristics

Rule Actions

Product Configurator provides predefined rule actions. Actions are applied to rule definitions to determine the processing that the rule invokes. Each rule has only one rule action, although many different rules within a model might perform the same action.

Product Configurator includes the following rule actions:

Common

These rules are used in both distribution and production models:

• Condition.

• Secondary Variable.

• Global Variable.

• Option Variable.

• Internal Variable Override.

• Create Parameter.

• Configuration Detail.

• Start Trace.

• End Trace.

Distribution

These rules are used in distribution models:

• Page Generation.

• Page Validation.

• Configured Component.

• Purchase Item.

• Finalized Price.

• Finalized Cost.

• Finalized Date.

• Finalized Volume.

• Finalized Weight.

• Availability Date.

• Workflow.

• Kit Component.

• Kit Generation.

• Product Selector.

Production

These rules are used in production models:

• Component List.

• Operation Sequence.

See Also

Setting Up Configuration Model Elements

Using Configuration Rule Actions

Rule Conditions

A rule condition is a fundamental part of the grammar of every rule. Don't confuse the rule condition with the condition rule, which is used in logical sequence with other complete rules. The rule condition is a syntax expression.

• When the rule condition is true, the rule is executed, and control passes to any existing true child.

• When the rule condition is false, control passes directly to any existing false child. If a child does not exist for the result of the condition (true or false), there is no further action with the rule after the rule is processed.

See Also

Using Configuration Rule Actions

Syntax Expressions

Each rule that you define features syntactic components that make up a syntax expression. Product Configurator processing interprets these syntax expressions to produce a result. Depending on the expression, this result can be a numeric, or a character value.

Syntax Expression Composition

Syntax expressions consist of one or more independent, simple expressions that are logically connected. A simple syntax expression consists of two variables and an operand that links them.

The system interprets syntax expressions based on their grouping within parentheses. The parentheses make complicated expressions possible, but even simple expressions require them. You can negate an expression by using a negation character prefacing the expression.

Syntax Expression Format

This is the general syntax expression format:

1. (optional) Negation character (“N”)

2. Opening parenthesis

3. First variable

4. Operand

5. Second variable

6. Closing parenthesis

Note. Variables 1 and 2 are abbreviated as V1 and V2 in the examples that follow.

Variable Names Syntax

The syntax for variable names consists of three parts:

1. A letter to indicate the type of variable. For example, O-FRAME is an option variable, M-COLORS is a multiple option variable, and so forth.

2. A hyphen as a separator (“-“).

3. The user-defined name (cannot include a hyphen).

For example, to create an expression that means the Frame option is equal to Y for this field, write:

(O-FRAME,=,"Y")

The expression returns “1” (true) when the option variable FRAME is equal to the literal character “Y” and “0” (false) when the option variable FRAME is not equal to the literal character “Y”. For the opposite—the expression can be negated to validate when O-FRAME is not equal to Y—write:

N(O-FRAME,=,"Y")

You can combine syntax expressions to make a more complex statement by ordering the parts of the expressions within parentheses. Either or both of the variables in a syntax statement can be defined by syntax statements within the larger one. It is valid to construct a statement in this format:

((V1,operand1,V2),operand2,V3)

The system always processes an entire simple expression within parentheses before applying its value to the next level. And it processes expressions in the order that they occur.

For example, the expression:

((V1,operand1,V2), operand3,(V3,operand2,V4))

processes as:

(V1,operand1,V2) = A
(V3,operand2,V4) = B

(A,operand3,B)

Note. Option, Secondary, and Global variables are populated by the configuration engine during syntax evaluation with default values—a zero value (0) for numerics and a zero-length string value (“”) for characters—if the variable does not contain a value.

Operands

Product Configurator delivers predefined operands for use in composing syntax expressions.

The system interprets operands within expressions to produce resulting values—either a numerical value or a character string. Each operand requires a specific type of value in the rule syntax.

Resulting Value Types

The following are value types:

Operand Types

The following table lists the operand types:

(100,IF,(O-COLOR,=,"RED"))

("CLEMENTINE",SA,7)

"TINE"

("CLEMENTINE",SB,7)

"CLEMENT"

("YELLOW",EM,M-COLORS)

FRAMECOLOR
WHEELSCOLOR

Note. You cannot enter true or false as a value for use in syntax expressions when using the following operands: If, Or, And. Instead, use “1” (True) and “0” (False).

Configuration Variable Types

Product Configurator is designed to make syntax expressions as uncomplicated as possible by providing a variety of variable types. Configuration variable types can be used to:

• Retrieve information about a product that already exists in any PeopleSoft application without any special rule logic by using internal variables.

• Validate a value against a value list, or check for the occurrence of a single value in any of a number of option variables.

• Use a matrix to predefine result values for up to five variables. Using a matrix saves labor and potential for error in defining combinations through calculating them in each rule model. When you want to change the result values, you just change the matrix—not the many rules that reference it.

Product Configurator delivers the following variable types.

Option Variable

Variable code for syntax = O.

An option variable stores attribute information about a configuration and contains a value that is either:

• Entered on a page generation rule.

• Created by an option variable rule.

Option variables apply to only one configured level of processing (the same as secondary variables), but they can be referenced across functional areas. Use the Option Variable page to view or create a new option variable.

See Setting Up Configuration Variables.

Secondary Variable

Variable code for syntax = S.

A temporary working storage variable within a model that applies locally within the model. Create a secondary variable when you want the variable to apply locally—that is, only to the single configured component.

You create secondary variables by using the Secondary Variable page containing a value from secondary variable, internal variable override, or availability date rules.

See Setting Up Configuration Variables.

Global Variable

Variable code for syntax = G.

A temporary working storage field within a model that applies globally within the entire model to all configured levels of processing and can be referenced across functional areas. You can share variable information between:

• A parent item and its configured components.

• A child item and any other child items that follow it in rule processing.

• A distribution model and a production model.

You create global variables by using the Global Variable page containing values from global variable rules.

See Setting Up Configuration Variables.

Matrix Variable

Variable code for syntax = X.

Invokes result values from a predefined matrix of up to five user-defined variable value keys.

See Using Matrices.

Internal Variable

Variable code for syntax = I.

Retrieves static or dynamically derived values from PeopleSoft application tables and views. This enables you to use existing business information, such as customer IDs, order numbers, business unit definitions, or pricing, without defining it within rules or in separate configurator tables.

See Setting Up Internal Variables.

Multiple Option Variable

Variable code for syntax = M.

Groups option variables together to examine them as a whole, and determine whether a particular value exists in that grouping.

See Maintaining Multiple Option Variables.

Value List

Variable code for syntax = U.

Validates option selection (such as sizes or colors of an item) during configuration.

See Using Value Lists and Constraints.

Constraints

Variable code for syntax = R.

One or more conditions that limit the valid options within a static value list (dynamically generated value lists cannot use constraints).

External Program Variable

Variable code for syntax = P.

Used with the create parameter rule, external program variables enable the system to call a custom-developed PeopleCode program to perform specific user-defined logic and return a value to use in configuration processing. After the external program runs, the parameters that are created by the create parameter rule are cleared.

External program variables are only used in syntax expression. P-EXAMPLE calls an external program called EXAMPLE.

You can create custom PeopleCode programs in the following self-documented PeopleCode Function Library:

FUNCLIB_CPINFR.CP_EXT_PGM.FieldFormula

See Defining Create External Parameter Rules.

Literal

Variable code for syntax = L.

Inserts a character string of static information into configuration logic. You can enter literals on internal variables or use them to insert a string of characters into a configuration code template definition. For example, a literal is used when adding a hyphen as a separator between other variables in a configuration code.

Note. Quotation marks are not needed around literals on internal variables.

Constant

Variable code for syntax = C.

The constant references static system information during the configuration process. A constant value does not change during processing.

PeopleSoft delivers the following constants for the current configuration unless noted otherwise:

• BILL_TO_CUST (bill to customer ID) *

• BUSINESS_UNIT_IN (Inventory business unit)

• BUSINESS_UNIT_OM (Order Management business unit) *

• CAPTURE_ID [Customer Relationship Management (CRM) Order Capture ID] **

• CP_MODE (configurator processing mode)

  • S = order management sales order

  • M = direct production order

  • R = direct requisition order

  • W = CRM external order

  • A = CRM internal order

• CURRENT_DATE (current system date in YYYYMMDD date format)

• DYNAMIC_PRICE (value of the dynamic pricing field from the last page generation rule with dynamic pricing syntax)

• ITEM_ID (item ID)

• LINE_NBR (CRM order capture line number) **

• OM_MODE (sales order mode) *

  • S = configuration within order management sales order / quote

  • E = configuration within order management express order / self service

  • “” = configuration within all other components.

• ORDER_LINE (sales order line number) *

• ORDER_NUMBER (sales order number) *

• PRODUCT_ID (product ID)

• QTY_ORDERED (quantity ordered) *

• SETID (product setID)

• SETID_CFG (configurator rule setID)

• SHIP_TO_CUST (ship to customer ID) *

• SOLD_TO_CUST (sold to customer ID) *

Use the Constant page to view existing constant definitions or add new constants.

* These constants are not used by Customer Relationship Management (CRM) applications.

** These constants are used exclusively by CRM applications.

Configuration Binds

You can use configuration binds in a configuration model to personalize configuration messages and enable configuration variable substitution in custom value lists and internal variables.

The case-sensitive syntax looks like this:

%BIND({configuration variable}).

For example:

%BIND(O-COLOR)

Product Configurator supports configuration binds in the following areas:

• Dynamic internal variables.

• Dynamic value lists.

• Custom messages.

• Custom HTML and option description on page generation rules.

• Page titles for page generation and kit generation rules.

Language Sensitivity in PeopleSoft Product Configurator

You can use nonbase language data on Product Configurator’s order entry pages by using PeopleTools globalization functionality.

To use a nonbase language, set up a language-specific user logon. A user in France might have a logon of FR1 to use the system in French, and a user in Brazil might have a logon of BR1 to use Brazilian Portuguese.

When these users log on, the system uses related language tables to display the configured order entry page’s fields, messages, and value lists in the specified language.

PeopleSoft delivers the following related language tables for this purpose:

See Also

Enterprise PeopleTools 8.46 PeopleBook: Global Technology