|
|
|
|
A configurable product is a product that offers a number of different options from which a customer can select before buying the product. The choice of options or available combinations of options may be constrained by technical or marketing concerns so that customers can only choose certain combinations of options in configuring their purchase.
In the Comergent eBusiness System, a product is made configurable by marking it as configurable in the product catalog and by associating with it a model that provides the information about options and the possible combinations of options.
Configurable products enable a customer to start with a basic model, then move through a series of selections, option items, to configure the product to their specific needs. You create configurable products using C3 Product Manager, but before you can do that, a product modeler must use the Visual Modeler to create a corresponding model.
An option class group is a collection of option classes or nested option class groups that represent entities that can be reused without change in any number of models and option classes. See Groups and Sub-Models for more information. |
|
A model, with its option classes, option items, option class groups, and option item groups, represents all of the possible valid configurations for a single saleable product. Every model created in the Visual Modeler belongs to a model group.
A model group is a way of grouping similar model groups, models, option class groups, and option item groups. At the top-level of the model group hierarchy is the root model group. Each model group belongs to a parent model group, except for the top-level, root model group which has no parent. Figure 9 shows an example of the model group hierarchy.
Using the Visual Modeler, you can select a product, created with C3 Product Manager, and associate it with a model, an option class, or option item. You do this to associate the entity with the price determined for the product using the price lists created with C3 Pricing. As the end-user configures the product, C3 Configurator uses either the price of the product associated with the model or the accumulated prices of the products associated with the option classes or option items.
You might have an option item that represents a saleable product. For example, you might have an option class that represents a selection of graphics cards. Each option item represents a different graphics card. When you modify each option item (in this case, each graphics card), you can associate each graphics card with a product. In this way, you can associate a price with each graphics card (through the price lists created with C3 Pricing).
Note that if you do associate a product with an option item, then end-users will see this option item only if the associated product is on one of the price lists assigned to their partner.
See Setting Prices for Products for information about pricing. For information on associating a product with a model, see To Associate a Product with a Model, Option Class, or Option Item.
Properties define the characteristics of models, option classes, and option items. Rules are defined using properties to constrain customer selections and determine whether or not a configuration is valid. The C3 Configurator uses the model to guide customers choices so that they can configure a Build-to-Order (BTO) product. When an end-user chooses an option item, a rule can be subsequently triggered by a property attached to that option item.
For example, a Mountain Bike model may consist of the following option classes: frame, forks, and wheels. Weight is a property defined for the model and attached to every option item in the model. Each item in each Mountain Bike option class is assigned a weight property value; that is, each frame has a weight, each fork has a weight, and each wheel has a weight. After the customer makes choices about a frame, fork, and a wheel, the sum of all the individual weights total the entire weight of the bike.
By defining a weight rule the modeler can specify that the entire weight of the Mountain Bike should not be over 15 kilograms. The modeler can also specify in the rule a message that will be displayed to the customer if the weight is exceeded.
Therefore, in C3 Configurator, when a customer chooses an option item such as a frame, fork, or wheel, the C3 Configurator uses the rule to determine the total weight value by adding the weights of all chosen option items associated with the weight property. If the total weight of all the option item(s) is over 15 kilograms, then the customer is presented with a message stating the recommended weight is exceeded and the customer should choose another option item in one or more of the option classes.
In Release 6.3 and higher, you can arrange your end-user interface in the form of a series of tabs. First you enable a tab-based UI by selecting the Tab-based UI display template when you set the display properties for the model. Once you have enabled the tab-based UI, you create the top-level option classes or option class groups that make up your model. Next you access the Tabs tab within your selected model and create the tabs. As you create the tabs, you populate them with the one or more of the top-level option classes or option class groups that you have created.
An option class can be attached to zero or more tabs. See Working with a Tabbed User Interface for step-by-step instructions on creating a tabbed user interface.
An option class is a configurable part of a model consisting of option items and nested option classes that have a common purpose.
An option item is a member of an option class. The option item can either be an orderable part or an intermediate selection in the process of determining an orderable part. Typically, properties are associated with option items.
For example, if a car is a configurable product, then an engine is a configurable part of the car. Thus, you could create a model called "car", and "engine" would be an option class in the model. The option items in the engine option class are 4-cylinder, 6-cylinder, and 8-cylinder.
A option class group or an option item group enables you to re-use option classes and option items in more than one place in a model group without having to recreate the same items over and over again as you need them. You can create a single group (created at the model group level), add option classes (with their option items) to the group and then "attach" the group, as needed in the required locations. For example, several models might have the same support choices (the same warranty selections, the same hardware support choices). Rather than create these new for each model as two option classes, the same two option classes, you could create these option classes once as part of an option class group, then attach the group to each model that requires these option classes.
If the elements of a group (option classes, option items) need new properties attached to them, or if the elements need existing properties modified, then you need only modify the group in the place where you originally created it. The modifications will be reflected in the group throughout its "attached" locations. Figure 10 shows different examples of groups. As illustrated in that example, you can also nest groups within other groups.
A model can be used both as stand-alone and as part of another model. When used as part of another model, the model is referred to as a sub-model.
The following table shows which groups can be attached to which elements in the Comergent eBusiness System.
A property is a characteristic that in some way describes a model, option class, or option item.
When you define a property, you can define it either as a part of a model group or as part of a specific model. In the case of a property defined for a model group, the property is then available to be attached to any model, option class, or option item in the hierarchy beneath the model group for which it was created. In the case of a property defined for a model, the property is available exclusively to the model itself, as well as option classes and option items within the model hierarchy.
For example, in Figure 11, property X is defined in Model Group A and property Y is defined in Model A1. Property X can be attached to Model A1 and Model A2, as well as any models in Model Group B, such as Model B1. However, the property cannot be attached to Model C which is not a child of Model Group A. Property Y is defined in Model A1 and therefore cannot be attached to either Models B1, A2, or C.
When you define a property, the name you give it should be descriptive of the property being represented. The property name must be unique within the model group.
As a modeler, you determine the value of a property when the property is attached. When you create a property, you can also define a default value for that property. Then, when you assign that property to a model, option class, or option item, the property has the default value unless you choose to override it. For example, you can assign the value of 8 when assigning the weight property to one of the bike forks but assign the value of 10 when assigning the weight property to a different bike fork.
In another example, a model for a configurable computer requires a different amount of RAM for different types of software. Thus, this model needs to have a property called "memory_required". When you attach this property to different software option items in the model, you determine the value of RAM memory required for the individual software. At the same time, RAM itself is an option class, and the amounts of RAM that the customer can order are the option items in that class. Therefore, there needs to be a corollary property called "memory_ordered". You may set a value for this property or it may be a calculated value triggered by a rule based on a quantity input by the customer.
Take care to name properties so that you avoid confusing properties that should be kept distinct. For example, if you use Weight as a property name, then there may be situations in which you need to distinguish between the weight of items from two different option classes.
The option item to which a property is attached may be any component of an orderable item that has the characteristic represented by the property. For example, as a modeler, you can attach the weight property to a frame since the frame has a specific, defined weight. The property value must be consistent with the property type entered when the property was defined. In other words, you cannot assign a value of "blue" to a property with the type Number. The property must be of type String in order to assign the value "blue". Depending on the property type, the value may represent either the quantity of the property represented (numeric), a specific instance of the property (character), or a list of many instances of the property.
As a modeler, you use display properties to control the model elements on the HTML page displayed to the customer by the Configurator Engine. See Working with Display Properties.
You use a list to enter and maintain lists of property values for a specific property. It is possible to define multiple choices by using a list. By comparison, number and string property types define a single value.
You use lists in the C3 Configurator when you have a property with multiple values. For example, a modeler can use a list property type for a property called days of the month. The values in this property list are 1, 2, 3, and so on, with the last value 31. For this particular property, the list is the appropriate property type.
You can also use lists to define the selection of option items during product configuration. You do this by creating a list of items and then creating a rule stating that an item is either valid or invalid with the items on the list.
For example, we have three bike models: Mountain Bike, Racing Bike, and Dirt Bike.
The same rule is attached to three different models, but the value of the WheelsAllowed property is specific for each model. That is, for the Mountain Bike model, the MtnBikeWheelsAllowed list is used, whereas for the Racing Bike model, the RacingBikeWheelsAllowed list is used. Similarly, the DirtBikeWheelsAllowed list is used for the Dirt Bike model.
Rules are essential to the Visual Modeler. They determine which instances of a model are valid. By defining and attaching rules to appropriate places in the model hierarchy, you ensure that customers may select only combinations of options items that are compatible or suitable. In doing so, you ensure that customers are offered the best shopping experience possible.
Each time a model is validated (for example, each time a user make a pick of an option item), the rules are fired. Some rules may evaluate to false: these are said to fail, whereas if a rule evaluates to true, then it is said to succeed.
A rule consists of one or more fragments and an action. The action can consist of either message actions (messages that will be displayed), an expansion action (items that will be added), or an assignment action (properties that will be assigned).
Rules enable the Configurator Engine to guide a customer through the configuration experience by offering additional explanations and checking the selected options to ensure a correctly built product. The rule can also check when certain conditions will provide expansion, that is, provide a customer with additional option items in the configured solution.
Rules can be simple: a particular option item must not weigh more than 100 grams. Rules can be complex: one option item must not weight more than 100 grams OR another option item must not weigh more than 50 grams AND the material must be steel.
Rules result in some kind of action being performed. A rule can check to see if some condition prevails and then display a message action as a result. An example of this would be a check on the total weight of a bike resulting in a warning message that the bike is over a weight limit.
Rules can result in expansion actions. Based on a rule, additional selections can be provided for a customer. For example, a rule can decide if additional memory is needed and how much.
Rules can result in assignment actions. Based on the calculations in a rule, a value can be assigned to a designated property.
You can choose to design rules that display messages when a model instance fails to satisfy a rule or when a model instance satisfies the rule. You can also adjust the severity of the message.
You define rules at the model group level or the model level depending on how the rules will be used. For example, if you want to attach the rule to any element in the model group hierarchy, then you define the rule at the root model group level. If you want to limit the use of a rule only to elements within a certain model group (or to elements in sub-groups within that group), then you define the rule only at that model group level. Likewise, if you want a rule for localized use by the elements in a particular model, then you define the rule at the particular model level.
Once you have defined a rule, you attach the rule to some level in the model (or group) structure. Where you attach the rule in the structure determines when the rule is fired (see Rule Firing). By attaching a rule to a model, you ensure that the rule is processed to validate the model. A rule may be attached to any number of models (including sub-models). You can also attach rules at the option class and option item level, if the rule is specific to that level.
The point at which you attach a rule determines where messages will be displayed to end-users as they configure the product, and it determines when, in the order of rule-firing, the rule is fired.
A rule fragment is a component of a rule and comprises a function and property joined by an operator to another function and property (or sometimes a literal value). The function determines a value for a property. Table 12 lists the functions supported by the Visual Modeler.
Operators tie rule fragments together and define the fragments' relationship within the rule. Table 13 lists the operators supported by the Visual Modeler.
For example, the rule "value(wheels selected) >= max (wheels required)" states in conversational English, "the number of wheels selected in the configuration must be greater than or equal to the maximum number of wheels required by the configuration; otherwise this rule fails".
A single fragment can consist of either of the following:
For example, a rule that has a single fragment might read: Quantity of wheels ordered = Quantity of wheels required. In this example, Quantity of wheels ordered is the first half of the fragment with the property, wheels ordered, and the function, count (quantity). The second half of the fragment, Quantity of wheels required, has the property, wheels required, and the function is also count (quantity). The operator is equals ("=").
Single fragments can be linked together to form multiple fragments using Boolean operators, AND, OR, ANDNOT, ORNOT.
For example, we can use the preceding single fragment and add another single fragment to form a rule with multiple fragments (multiple lines in the Visual Modeler):
Quantity of wheels ordered = Quantity of wheels required
Type of front wheels = Type of rear wheels
You can build complex rules such as:
(FragmentA AND (FragmentB OR FragmentC))
See Fragments for examples of simple levels of fragments and nested levels of fragments.
A property can have an unspecified value. If a property is not assigned to an object which is part of the current configuration (a valid option item is not selected), then the value for that property is defined as "not specified".
When creating a rule, you can select from four results for a fragment when the property is not specified:
When you create a rule, you can specify whether action results if the rule succeeds or fails. For example, you can specify that the rule will be triggered on "failure". In this case, if the rule evaluates to "true", then nothing is done. No message is displayed; if the rule involves expansion, no expansion occurs.
Messages are used to help guide a user toward correct configuration choices. The rule message text may be up to 2000 characters in length.
For each message action, you can specify one of three types of messages.
Expansion means that, based on a rule formula, additional items are added to the model configuration. The result of a rule formula is the starting point to determine which option item(s) is expanded and included in the product configuration.
The modeler can use rule formulas to create rules that calculate or determine the result of a rule. In general, rule formulas are based on values associated with properties. For example, a modeler can use a rule formula to compare the property quantity ordered by a customer with the quantity required for the model. The rule formula calculates the difference, if there is one, and can automatically expand the model to include the option items that are needed to match the required quantity.
Numerical rule formulas must be valid mathematical expressions. A rule formula combines mathematical notation with Comergent functions, operators, properties, and literal values to produce a value that is then measured against a minimum and maximum value to determine what and how much should be expanded. (Ranges are used only if a rule formula has been entered.)
The following example illustrates a business situation where creating an expansion rule formula is useful. A customer orders a workstation. The first fragment of the rule references a property called MX75_Mem_Auto_Select and is set to YES. The second fragment references two properties: MX75_Mem_Ordered and MX75_Mem_Required. If the MX75_Mem_Auto_Select is set to YES, and if the customer orders less memory (MX75_Mem_Ordered) than required (MX75_Mem_Required), then the rule formula result is used to expand the configuration to include the right amount of necessary memory. The customer is prevented from ordering an invalid workstation.
In this rule, a rule formula would be written as in Figure 12. If the customer orders 64 MB of memory and the memory required is 128 MB, then the rule formula returns a result of 64. This result is evaluated against the min/max ranges for results and finds that 64 falls within the range of a minimum of 64 and a maximum of 128. According to the table, when this happens, a quantity of 128MB of memory is selected (expanded).
Another type of action that can result from a rule is Assignment. In this case, the Modeler can define a rule that results in a value (based on the rule formula) being assigned to a property designated by the modeler.
The C3 Configurator processes rules by a two step process. Within each level in a model hierarchy, it processes rules according to the order defined by the modeler when rules are attached to that level. See To Modify a Rule for the steps to sequencing rules.
Within the model hierarchy itself, C3 Configurator follows a process called "depth first traversal". At any node in the structure, C3 Configurator traverses down through that node's children to the lowest level, then traverses back, firing rules as it goes.
For example, in Figure 13, C3 Configurator starts at the top and checks for any children, then traverses down to the first node. At this first node (Option Class 1), C3 Configurator checks for children. Since none are found, C3 Configurator fires any rules attached to this option class, in this case only one (1).
C3 Configurator proceeds to the next node (Submodel A) and finds two children (Option Class 2 and Option Class 4). Option Class 2 has a child (Option Class 3) so C3 Configurator traverses to that node. Since Option Class 3 has no children, C3 Configurator fires the rules attached to Option Class 3 (2), then traverses back up the structure to the parent, Option Class 2, and fires the rule (3) attached at that node.
C3 Configurator traverses to the next child of SubModel A, Option Class 4. Finding no children there, the rule attached to Option Class 4 (4) is fired. At this point, C3 Configurator traverses to the parent, Submodel A, and fires the rules attached to that level (5 and 6).
Now, C3 Configurator moves to the next node (Option Class 5) and, finding no children, fires the rule attached to Option Class 5 (7). Having fired all the rules attached to the children, C3 Configurator now traverses back to the parent (Model B) and fires the rules attached to the parent (8 and 9).
When customers select certain option items, you might want to prohibit them from making other selections. For example, a car dealer might want to constrain certain interior colors of a car from being sold with certain exterior colors. Likewise, combinations of option items might constrain the selection of other option items. For example, if Option A and Option B are selected, then Option C is not a valid choice.
You can create these constraints by creating a constraint table for a particular model. The constraint table consists of two or more columns each of which represents an option class containing choices (option items) which may or may not be valid with the choices in the other columns. The constraints are defined by one or more constraint rows in the table. When you create the table, you can include a message (error, warning, or suggestion) that is displayed.
The above figure shows a set of option constraints for the car example. When translated into a model for the customer, this table means that the customer's choices for Exterior Color and Interior Color must match a set of choices in one of the constraint rows: for example, Black and Silver, or Red and Green are valid choices, but not Black and Green.
You can also define a constraint row so that the choices for one column are not valid with the other columns. In this case, you want to constrain the customer's choices from matching any combination of items in an invalid row.
See Option Constraints for more information about constraint tables.
As you create your model, you can test the model as you go along. Once you have created the model, you can easily click a button to compile the model into an XML file.
In Release 7.0.1, you can copy or embed entities in the model group hierarchy. To copy an entity (model group, model, and so on) means to make a duplicate of a single entity (in the case of an option item) or of an entity and its structure (in the case of a model group, model, or option class group or option item group) within another location in the hierarchy. To embed an entity is to make a duplicate of the structure of an entity. For example, to embed a model is to take the model's structure and duplicate that structure (option classes, groups, and so on) within a destination in the model group hierarchy. Copying or embedding is performed at different location in the Visual Modeler interface. See the individual tasks related to copying or embedding in CHAPTER 14, Using the Visual Modeler for more information.
When you are copying or embedding, attached properties follow certain rules:
Figure 15 shows a model group hierarchy before and after embedding. In this example, you are embedding Option Class Group 1 (OCG1) under Model 1 (MOD1). In OCG1, Property P1 (defined in Model Group 1 as INT) is attached to Option Class 1 (OC1). After embedding, a conflict will exist since, In MOD1, Option Class 3 (OC3) also has a Property P1 (defined in MG2.1 as STRING). Visual Modeler resolves the conflict by dropping the P1 attachment to the newly embedded OC1.
You can import or export model groups or models in the form of XML files. When you import, you can choose to import a model group or model to a specific destination or you can import the model group or model with its structure relative to its original root model group. This means that, rather than choosing a destination model group, the model group or model will be placed relative to the destination root model group in the same position relative to its original root model group without compromising the integrity of the destination (existing paths, and so on).
For example, in Figure 16, Model MOD1 (located in Model Group MG2.1 which is located in MG2) is being imported into MG2 on the right. It is being imported relative to the root model group. In the destination hierarchy, there is indeed a Model Group MG2. However, there is no Model Group MG2.1 within the destination MG2. During import, the process will recreate the original structure relative to the root by creating a new Model Group, MG2.1, in the destination. This is correct since it will not compromise any models already existing under MG2.
In Figure 17, Model MOD1 (located in Model Group MG2.1 which is located in MG2) is being imported into MG2 on the right. It is being imported relative to its original root under MG2.1. In the destination hierarchy, there is indeed a Model Group MG2. However, there is no Model Group MG1A. To create MG1A above the existing MG2 would compromise the integrity of any entities within MG2. In this case, therefore, the process satisfies the import requirements by creating a new branch: MG1A, MG2, MG2.1, and the imported MOD1 with OC3.
When you import entities, the process handles properties, rules, lists, and option groups differently, depending on whether you are importing a structure as relative to its original root, or whether you are importing to a specific location without regard to its original root.
When you import a structure relative to its original root, the process handles these items in the following manner:
The process examines the ancestral chain of the destination for the definitions of the entities. If they are found, then you are prompted as to whether you want to overwrite or not overwrite the entities with the definitions of the attached entities. The entities need not be defined in the same location as in the imported structure. If the definitions are not found in the destination, then the process creates them in the same location in the destination as in the original.
At the destination, the process examines the path in the destination:
When you import a structure to a specific destination, the process handles properties, rules, lists, and groups in the following manner:
The process examines the ancestral chain of the destination for the definitions of the entities. If the definitions are found, then you are prompted as to whether you want to overwrite or not overwrite the entities with the definitions of the attached entities. The entities need not be defined in the same locations in the destination as in the imported structure. If the definitions are not found in the destination, and if the structure does exist, then the entity is created at the same location in the structure as in the original. If the location does not exist, then the entity is created as part of the immediate parent to the structure being imported.
At the destination, the process examines the path in the destination:
In Release 7.0.1, you can search the model hierarchy for entities that contain property names or property values that you specify as parameters for the search. You can use the entire hierarchy for your search, or you can limit your search to model groups, models, option classes, option items, or rules. You can also limit your search to the currently selected model group, model, option class group, or option item group. See Searching for more information.
In Release 7.0.1, you can run a report on any of the models created with the Visual Modeler. You define the criteria that the report will include:
|
|
|
