!--a11y-->
Comparison of SCE and R/3 Variant
Configuration 
When you want to use master data from the R/3 variant configuration for product configuration with the Sales Configuration Engine (SCE), you must observe some structural and functional differences and fulfill a few modeling prerequisites.
The following data is used by IPC and by R/3:
· A product model built from the same objects (materials, classes, characteristics, classification, and bills of material)
· Dependencies and variant tables
· Value assignment for the interactive configuration process
· The same criteria for completeness and consistency
· The same IDoc structure (content) for the configuration result
You maintain your master data in the SAP R/3 Variant Configuration and use it for product configuration with the IPC.
The document contains the following subjects:
· General Differences Between the SCE and the R/3 System
· Bills of Material
· Classification System Objects
|
Short Description |
SCE |
R/3 |
|
Master data meintenance |
Master data in the SCE knowledge base (or CRM consolidated database) is read only. |
Master data is maintained in the R/3 database. |
|
Used reference characteristic types |
Which master data tables and fields are available by default, depends on the integration environment. For more information, see Reference Characteristics. |
R/3 master data tables contain data that is relevant to all application areas. |
|
Configurable objects (BOMs, task lists) |
Only configurable materials in the form of material BOMs are configured. |
A range of objects can be configured, including different BOM categories and task list types. |
|
Configuration profile |
The configuration profile of each material you want to configure must have the setting for a nested KMAT, SET or order BOM. These settings differ in the individual releases of R/3. For more information, see the R/3 Library Variant Configuration (LO-VC). |
All available settings in the configuration profile are supported. |
|
BOM explosion |
For the BOM explosion, the configuration profile of configurable materials must have the setting Multi-level or None. There is no BOM explosion for KMAT. You can assign values only to the root instance. You can use OSS Note 496105 to explode the items relevant to sales of non-configurable materials in the knowledge base of the BOM. BOM explosion takes place after the customer order has been transferred to R/3 in a separate processing step. |
For the BOM explosion, the configuration profile of configurable materials can have any of the settings Single-level, Multi-level or None. |
|
Integrated applications |
Usually, the SCE is integrated in a sales scenario. Depending on the environment, certain external functions are available. |
R/3 Variant Configuration is fully integrated with all R/3 applications, meaning that related functions are supported. |
|
Product or material variants |
When searching for product variants, for numeric characteristics a string comparison is used. Special customizing settings are required for the variant search to achieve a behavior similar to SAP R/3 VC. For more information, see Product Variants. |
When searching for material variants, for numeric characteristics a tolerant comparison is used. |
|
Entry product of the configuration |
The knowledge base profiles for a product define which materials in a structure you can use to start configuration. |
You can start the configuration process from any material in the structure, provided that its configuration profile allows this. |
|
Conflict Handling |
Individual conflict handling depending on the user interface: · JSP UI: Detailed conflict solution help for casual users. See also: Conflict Handling · Swing UI: Technical conflict handling, resembling R/3. |
Technical conflict handling for modelers and experts. |
|
Trace function |
JSP UI: No trace function available. Swing UI: A limited trace function is available. |
Transactions cu50 and va01 provide a trace function. |
|
Short Description |
SCE |
R/3 |
|
Number of BOMs per material |
Each material has at most one BOM. |
A material can have several alternative BOMs for different lot sizes. |
|
BOM items |
The following objects can be BOM items: · Materials · Classes |
The following objects can be BOM items: · Materials · Classes · Documents · No object (text only) |
|
Data for BOM items |
A BOM item contains: · Component quantity · Flag for relevance to sales Other BOM item data is not downloaded. |
A BOM item contains data that is relevant to all application areas. |
|
Combination of BOM item number and component number |
Each combination of BOM item number and component number (material or class) can occur only once in a BOM. |
You can use the same combination of BOM item number and component number more than once in a BOM, because R/3 uses an internal number to identify items internally. |
|
Manual selection or deselection of BOM items |
Only in Advanced Mode, you can select or deselect items. |
You can create new BOM items and delete items by processing an order BOM. In the ‘Set’ scenario that allows manual changes, you can deselect items manually. |
|
BOMs available in the system |
Only the BOMs of configurable materials are available in the system. |
All BOMs are in the system. |
|
Configuration: Class nodes with several materials matching the assigned values |
If a class node has multiple classified materials matching the assigned values, the class node is not automatically replaced by one of the materials – the class node remains as it is. |
If a class node has multiple classified materials matching the assigned values, the first matching classified material is automatically used. |
|
Mandatory and non-mandatory class nodes |
A material must always be specialized, because class nodes are always mandatory. |
You can flag a class node as mandatory. If a class node is not specialized in a multi-level configuration, the configuration is only incomplete when the class node is flagged as mandatory. If several hits are found, the first one is adopted. |
|
Accumulating quantities |
Conversion and accumulation of quantities in multilevel BOMS is not supported. In the configuration result, the instance quantity is displayed for each quantity unit of the superior object. |
You can trigger quantity conversions and accumulations. In the configuration result, instance quantities in a multilevel BOM are multiplied. |
|
Non-whole-numbered quantities |
Items with non-whole-numbered quantities are not supported. See OSS Note 365866. |
There are no restrictions for non-whole-numbered quantities.
You can enter a quantity of 1.674 liters in the BOM. |
|
Component selection by classification of materials |
You cannot use the classification of materials to select components. |
You can use the classification of materials to select components. |
|
Short Description |
SCE |
R/3 |
|
Class assignment of characteristics: Reference characteristics |
All characteristics must be assigned to classes. Characteristics that are not assigned to a particular class, are automatically assigned to all classes. |
All characteristics except reference characteristics must be assigned to classes. |
|
Inheritance: Uniquely assigning classes |
Class networks must allow a unique precedence list to be calculated. The precedence list is used to define the inheritance logic for default values of characteristics. If, in exceptional cases, it may not be possible to calculate the class precedence list, you receive an error message when you generate the runtime version of the knowledge base.
CLASS_01 is assigned to CLASS_02, which is itself assigned to CLASS_03. In addition, CLASS_01 is assigned directly to CLASS_03. The second link is redundant and inconsistent. |
Class networks are totally flexible. The system does not recognize the example as being inconsistent. |
|
Using the DATUM (date), WÄHRUNG (currency), and ZEIT (time) data types in dependencies |
With the OSS Note 451697, you can use characteristics with the data types DATUM (date) and WÄHRUNG (currency) in dependencies. Characteristics with the ZEIT (time) data type are not supported at present. |
You can use characteristics with all data types in dependencies. |
|
User-defined data types |
You cannot use characteristics with the data type UDEF. |
You can use characteristics with the user-defined data type UDEF. |
|
Value hierarchies |
You cannot use value hierarchies in characteristics. |
You can use value hierarchies in characteristics. |
|
Intervals |
Enter intervals as allowed value ranges of numeric characteristics. These value ranges are used to check the validity of the assigned value. However, you can only assign one value (and no interval) to a numeric characteristic during configuration. |
You can maintain intervals as values for numeric characteristics and assign interval values during configuration. |
|
Dispay-relevant characteristic groups, assignment of characteristics |
A characteristic can be assigned to no more than one display-relevant group of characteristics. If more than one assignment exists, the configuration UI ignores the other assignments. |
A characteristic can be assigned to several display-relevant characteristic groups. |
|
Changing the facets of a characteristic |
Characteristic facets (attributes and allowed values) can be changed dynamically using the extended syntax available in Advanced Mode. |
Characteristic facets can be changed dynamically by using an additional characteristic. |
|
Reference Characteristics |
You can create reference characteristics only to certain fields: · writing: STPO-MENGE, SDCOM-VKOND · reading: see table under Reference Characteristics You can refer only to one table field with a maximum of one characteristic per knowledge base runtime version (see OSS Note 352815). A relaxation of this restriction may be added for selected reference characteristics via other OSS notes. The content of fields in the tables VBAK and VBAP must be downloaded by the sales application, because they are not included in the SCE knowledge base. For more information about how to use reference characteristics, see Reference Characteristics. |
You can use reference characteristics for a range of fields in STPO and SDCOM. You can have an arbitrary number of characteristics referring to the same table field. |
|
Changing reference characteristics |
In CRM, you have read-only access to input parameters for reference characteristics. However, the CRM system cannot interpret the changed values. You can subsequently interpret these changed values in your R/3 system by making the modification described in OSS Note 359180. |
A standard set of reference characteristics (structures SDCOM and VCSD_UPDATE for sales) can be changed. |
|
Assigning documents (graphics) to characteristics and values and storing them |
As of R/3 release 4.6C, graphics that are stored in the mySAP PLM document management system and assigned to characteristics and characteristic values in the class system, are copied into the knowledge base runtime version and replicated with it. For more information, refer to Visualising Configuration Objects |
You can use the mySAP PLM document management system to link the graphics to characteristics or values in your knowledge base. |
|
Class-specifically overwriting certain characteristic attributes |
The attributes Not ready for input, No display, and Additional values allowed are always maintained in the characteristic itself. |
Class-specifically, you can overwrite the characteristic attributes Not ready for input, No display, and Additional values allowed. |
|
Class-specifically overwriting characteristic value names |
Characteristic value names are always maintained in the characteristic itself. |
Class-specifically, you can overwrite characteristic value names. |
|
Organizational areas |
Swing UI (Desktop UI): With the OSS Note 535658, you can use organizational areas. JSP UI (Web UI): Organizational areas are ignored. |
You can use organizational areas to influence which characteristics appear on the user interface. |
|
Manually specifying class nodes |
Swing UI (Desktop UI): You can specify a class node manually. JSP UI (Web UI): You cannot specify a class node manually. This reduces conflicts between values, because all options are selected according to the characteristic values assigned and the object dependencies that they trigger. |
You can specify a class node manually. |
|
External value check |
You cannot use a table or a function module for an external value check. |
You can use a table or a function module to define an external value check. |
|
Directly assigning variant condition keys to a value (reference characteristic SDCOM-VKOND) |
If you want to assign the variant condition key directly in the configuration simulation (transaction CU50) or by using procedures, you must assign a reference characteristic for table field SDCOM-VKOND to the variant class. This is checked during generation of the knowledge base. |
In the configuration simulation, you can directly assign a variant condition key to a characteristic value, without a reference characteristic referring to table field SDCOM-VKOND and the variant class. |
|
Presentation of numeric characteristics |
Values and value ranges are sorted numerically ascending. Long texts for values and value ranges are not supported. Exponential representation is not supported. |
Values and value ranges are sorted as maintained. Long texts for values and value ranges are supported. Exponential representation is possible. |
|
Characteristic templates |
Templates for characteristic values are supported only in parts; especially value templates defined using IMG are not supported. For numeric characteristics with format specifications (and automatically derived value template), language-dependent decimal separators and the number of predecimal and decimal places are checked during keyboard input. |
During interactive configuration, only those characteristic values can be entered via keyboard that exactly match the value template specified in the master characteristic. |
|
Variant tables |
You can access variant tables or database tables only, if you refer to them in the dependency. |
You can access variant tables and database tables via function modules, without explicitly using dependencies. |
|
Short Description |
SCE |
R/3 |
|
Assigning object dependencies to characteristics and characteristic values |
All procedures (and actions) must be assigned to a configuration profile or a BOM item. |
Procedures (and actions) can be assigned to characteristics and characteristic values, as well as configuration profiles and BOM items. |
|
Actions |
You can use actions only if you automatically convert them into procedures. If you select this option, all actions are converted to procedures with position number 0 and processed as procedures in the SCE (they are processed once every time you confirm during configuration). |
Actions are declarative (not procedural) and are processed every time you confirm, as many times as it takes, until no more values can be inferred from the information available. |
|
Loading constraint nets |
All constraint nets are loaded at the beginning of a configuration session. |
Constraint nets that are assigned to a configuration profile are only loaded if the corresponding material is selected in the configuration. |
|
Programming language for variant functions and user exits |
Variant functions and user exits must be written in Java, or written in C and called from a Java application. You can use the Java Native Interface (JNI) to implement the second option. A Java library of functions covers the functions in the R/3 function group CUPR. For more information, see User-Defined Variant Functions. |
Variant functions and user exits can be written in ABAP (standard) or in C. |
|
Normalized variant table |
Each line of a variant table must contain one value for each characteristic. Intervals are not possible. As of a particular R/3 Service Package, several values are allowed (see OSS Note 427644). |
A line of a variant table can contain multiple values, no values or interval values for a characteristic, unless the variant table is connected to a database table. |
|
Duplicate entries in variant tables |
Duplicate entries in variant tables are not allowed. |
Duplicate entries in variant tables are possible. |
|
Reference characteristic SCREEN_DEP-INVISIBLE |
You can use procedures to dynamically change this attribute. OSS Note 311479 must be implemented in order to generate a knowledge base containing this function. OSS Note 579721 allows you to use constraints with references to SCREEN_DEP-INVISIBLE. |
You can dynamically change the reference characteristics visible in the configuration user interface by formulating procedures for the reference characteristic SCREEN_DEP-INVISIBLE. |
|
Reference characteristic SCREEN_DEP-NO_INPUT |
You can use procedures to dynamically change this attribute. Note 375632 must be implemented in order to generate a knowledge base containing this function. Using constraints with references to SCREEN_DEP-NO_INPUT is not possible. |
You can dynamically change the characteristics that allow user input by formulating procedures for the reference characteristic SCREEN_DEP-NO_INPUT. |
|
Preconditions for values |
You cannot use value preconditions if the characteristic is defined as restrictable or as additional values allowed. |
You can use value preconditions if the characteristic is defined as restrictable or as additional values allowed. |
|
Restrictability of the allowed values of a class |
You cannot restrict the allowed values for a specific class if the characteristic is defined as having additional values allowed. |
You can restrict the allowed values for a specific class if the characteristic is defined as having additional values allowed. |
Note the following differences if you want to use the R/3 Engineering Change Management to monitor changes to the objects of your configuration model.
|
Short Description |
SCE |
R/3 |
|
Validity of change numbers |
Use change numbers with a valid-from date. |
You can use change numbers with a valid-from date or change numbers effectively. |
|
Version validity date |
The date specified for a runtime version determines (together with the plant and BOM application) which version of an object is valid. |
The date you enter when you configure your material determines which version of each object is valid. |
|
Number of versions of an object per unit |
A runtime version of a knowledge base contains one version of each object. |
The database contains several versions of any object that has been changed with engineering change management. |
When the documentation was created, no other differences were known. Check OSS for differences that became known after the documentation deadline (search term: SCE: Additions to SCE-VC Delta List).
