Hierarchy
MDG_FND (Software Component) MDG Foundation⤷
CA-MDG-APP-BP (Application Component) MDG Business Partner (Central Part)⤷
MDG_BS_BP_GENIL_NO_TRANSL (Package) Master Data Governance: GENIL
Basic Data
| Data Element | SCPL_RELEASE |
| Short Description | Sequence of Releases |
Data Type
| Category of Dictionary Type | Direct Type Entry | |
| Type of Object Referenced | No Information | |
| Domain / Name of Reference Type | ||
| Data Type | NUMC | Character string with only digits |
| Length | 4 | |
| Decimal Places | 0 | |
| Output Length | 4 | |
| Value Table |
Further Characteristics
| Search Help: Name | ||
| Search Help: Parameters | ||
| Parameter ID | ||
| Default Component name | ||
| Change document | ||
| No Input History | ||
| Basic direction is set to LTR | ||
| No BIDI Filtering |
Field Label
| Length | Field Label | |
| Short | 10 | Release |
| Medium | 15 | Release |
| Long | 20 | Sequence of Release |
| Heading | 7 | Release |
Documentation
Definition
Remake after remake, remakes of remakes - keep an order of it by indexing all of them by their release. A release must only be maintained for a location that is a remake of another.
Use
If there are several remakes of an original they might interfere each other in the one or other way. To avoid contradictory influences on the original they will be considered in their order of release, the newest (having the highest release) overrides "earlier" releases.
Dependencies
It's getting interesting when suddenly remakes of remakes come into the game -suddenly there's a family tree of relations between all releases and their common root location. Starting at the highest level of that tree each release branch will be considered completely before going on to the next release branch having a higher release than the previous.
Example
History
| Last changed by/on | SAP | 20130604 |
| SAP Release Created in | 732 |
