I know changes are always hard. But they are also an opportunity to think through what could be even better. If you never used the Specification Management from SAP before, this is not your article (but consider looking into the new capability within SAP EPD, it’s worth it). However, if you’re familiar with the Specification Management solution within SAP ERP or SAP S/4HANA, I may have a few useful details for you.
I won’t explain the part where the users are set up, I’m only covering the business configuration part.
I'm abbreviating the product names for the sake of being shorter. I'm talking about the following:
In ERP and S/4H, almost everything is modelled as a specification.
In EPD, different business objects have their separate apps where you can define them. A key to successful business configuration is to define your properties well, because almost all other objects are used there.
You can have a look at the data model in EPD here.
So what was previously modelled as a specification, for example nutrients or nutrient groups, are now composition items and composition item groups of the same composition item type.
Let me show you in a table format:
Specification types in ERP and S/4H were used to differentiate between business objects (as shown above). In EPD, it rather defines the specification’s place in the company’s overall product structure hierarchy. There can be different levels where having a specification makes sense (for example unpackaged product, packaged product, etc.), but each level requires different information.
Specification types in ERP and S/4HANA also affected which property trees are visible for the given object (with the Specify Specification Types activity). This functionality is there in EPD as well: for each property tree, you can assign one specification type, and when you create a specification with the given specification type, the respective properties will be shown with the defined tree structure.
As an addition, specification types in EPD are also responsible for which status profile the specification will use.
In ERP and S/4H, the definition of different properties of a property tree was a multi-step process. You created characteristics, which you had to include in classes, and then you defined value assignment types that used them. The value assignment types had to be configured if you wanted them to be table-based. And last but not least, you had to assign the value assignment types to property trees.
In EPD, you have the Properties app for creating properties, and the Property Trees app for creating the tree hierarchy. That simple.
When creating a new property, you can decide if it is a composition property (a type of property that contains a list of properties sourced from composition configuration or specification) or an attribute property (a type of property where you can precisely define and fine-tune attribute fields of Boolean, character-based, date-time, or key figure type), or both.
So all of the previously mentioned settings are included inside one app as options.
In ERP and S/4H, phrases were also characteristics, although special ones. You had to classify them as well into phrase sets (technically classes).
In EPD, these are two separate apps: the Phrases app where you can define the phrase, and the Phrase Collections app where you can group them based on your need.
These phrases are then taken over by the Properties app, when you define a character-based attribute property and you specify which phrase group to use with it.
In ERP and S/4H, exception values were used for a number of things, from for example allergen statements to test result documentation, based on your configuration. Composition types were also used in two levels: once as a marker for within a quantitative composition of a raw substance, and secondly within a real substance, marking the role of the item in the product.
In EPD, we decided to make the 3 most important value sets easy to define and use: we have 3 different apps and their grouping pairs for that.
These can be used when you define a composition property.
In this blogpost, you’ve learned what are the differences between the Specification Management solution in the SAP product compliance applications within SAP ERP and SAP S/4HANA, and the new Specification Management solution within SAP Enterprise Product Development.
Feel free to provide feedback in the comments section, and I would like to encourage you to follow the “SAP Enterprise Product Development” and “Specification Management” tags and post your questions under the “PLM” tag.
If you are interested in Specification Management specifically, you can also follow my profile as I’m planning on informing you about the latest news.
Zsofia is a senior user assistance developer in SAP, working in the PLM area for 10+ years.
Disclaimer
I won’t explain the part where the users are set up, I’m only covering the business configuration part.
I'm abbreviating the product names for the sake of being shorter. I'm talking about the following:
- ERP and S/4H: Specification Management within the SAP product compliance applications (SAP Product Safety for ERP and Product Compliance for SAP S/4HANA)
- EPD: Specification Management capability within SAP Enterprise Product Development
Data Model
In ERP and S/4H, almost everything is modelled as a specification.
S/4H Specifications
In EPD, different business objects have their separate apps where you can define them. A key to successful business configuration is to define your properties well, because almost all other objects are used there.
You can have a look at the data model in EPD here.
So what was previously modelled as a specification, for example nutrients or nutrient groups, are now composition items and composition item groups of the same composition item type.
Let me show you in a table format:
| Object | ERP and S/4H | EPD |
| Allergen, Diet, Genetically modified ingredient, Nutrient, Religious certificate | Specification type | Composition item |
| Allergen group, Diet group, Genetically modified ingredient group, Nutrient group, Religious certificate group | Specification type | Composition item group |
| Raw substance | Specification type | Specification |
| Listed substance | Specification type | Listed substance (planned) |
| Pure substance | Specification type | Listed substance (planned) |
| Real substance | Specification type | Specification |
Specification Type
Specification types in ERP and S/4H were used to differentiate between business objects (as shown above). In EPD, it rather defines the specification’s place in the company’s overall product structure hierarchy. There can be different levels where having a specification makes sense (for example unpackaged product, packaged product, etc.), but each level requires different information.
Specification types in ERP and S/4HANA also affected which property trees are visible for the given object (with the Specify Specification Types activity). This functionality is there in EPD as well: for each property tree, you can assign one specification type, and when you create a specification with the given specification type, the respective properties will be shown with the defined tree structure.
As an addition, specification types in EPD are also responsible for which status profile the specification will use.
New Specification Type in EPD
Value Assignment Types, Classes, Characteristics
In ERP and S/4H, the definition of different properties of a property tree was a multi-step process. You created characteristics, which you had to include in classes, and then you defined value assignment types that used them. The value assignment types had to be configured if you wanted them to be table-based. And last but not least, you had to assign the value assignment types to property trees.
Customizing Activity for VAT
In EPD, you have the Properties app for creating properties, and the Property Trees app for creating the tree hierarchy. That simple.
When creating a new property, you can decide if it is a composition property (a type of property that contains a list of properties sourced from composition configuration or specification) or an attribute property (a type of property where you can precisely define and fine-tune attribute fields of Boolean, character-based, date-time, or key figure type), or both.
New Property in EPD
So all of the previously mentioned settings are included inside one app as options.
Property settings in EPD
Phrases
In ERP and S/4H, phrases were also characteristics, although special ones. You had to classify them as well into phrase sets (technically classes).
In EPD, these are two separate apps: the Phrases app where you can define the phrase, and the Phrase Collections app where you can group them based on your need.
These phrases are then taken over by the Properties app, when you define a character-based attribute property and you specify which phrase group to use with it.
Using Phrases in EPD
Exception Values and Composition Types
In ERP and S/4H, exception values were used for a number of things, from for example allergen statements to test result documentation, based on your configuration. Composition types were also used in two levels: once as a marker for within a quantitative composition of a raw substance, and secondly within a real substance, marking the role of the item in the product.
In EPD, we decided to make the 3 most important value sets easy to define and use: we have 3 different apps and their grouping pairs for that.
- Roles in Composition: A value that indicates the role of the substance in the standard composition of a specification, for example: active ingredient or impurity. This classification is used mostly for compliance purposes.
- Qualitative Statements: A declared value that indicates whether a specification contains a certain substance, for example: trace elements, contains, does not contain, unknown.
- Value Qualifiers: A collection of values that are used as qualifiers for composition items within a specification, for example: measured, certified, warning.
These can be used when you define a composition property.
Composition Property Settings in EPD
Summary
In this blogpost, you’ve learned what are the differences between the Specification Management solution in the SAP product compliance applications within SAP ERP and SAP S/4HANA, and the new Specification Management solution within SAP Enterprise Product Development.
Feel free to provide feedback in the comments section, and I would like to encourage you to follow the “SAP Enterprise Product Development” and “Specification Management” tags and post your questions under the “PLM” tag.
If you are interested in Specification Management specifically, you can also follow my profile as I’m planning on informing you about the latest news.
About the author
Zsofia is a senior user assistance developer in SAP, working in the PLM area for 10+ years.
- SAP Managed Tags:
1 Comment
