In this blog post, we will see in detail the concept of Edition Management in MDG. This blog post will help to configure editions for reference master data as well.
In MDG, we have two types of business objects which can be governed. One is Standard Business Object like Business Partner, Customer, Vendor which is not time dependent master data (though it has certain entities like addresses which can be time-dependent), which has only one instance of master data in the system and as soon as the changes are approved, the changes are replicated to the Reuse area / downstream systems. Other one is Edition based business objects, which are time-dependent in nature. For these business objects, the replication to reuse area / downstream systems can be configured based on an time interval.
Important criteria for using Edition management in MDG is, the data model should be an Flex model. By default, SAP Standard delivers MDG-F data model as edition dependent data model and you can also create data model for custom objects using editions.
Below figure shows the end-to-end process of governing edition based master data in MDG. In the figure you can see the two different processes of flexible edition management, where you can schedule the changes with an edition also you can directly replicate the changes, even if the business object is edition based. We will see this in detail in the below section, on how to configure replications for edition based objects.
Using Edition brings flexible ways to maintain the master data and also brings transparency about multiple changes made on the data.
In the above example, we have two objects Object A, Object B which is maintained across multiple editions E1, E2, E3, E4 with various statuses of those editions.
Below is the edition information with their validity period
In this example, the Object A is existing in all the editions, which is, in E1 & E2 it is existing as released status, but in E3 & E4 it is existing In-Process status. Whereas, the Object B is existing only in E1 and E3, with E1 as released status and E3 as In-Process status.
If you observe this example, we have only defined the Valid-from date for the editions. Which means, valid-to date is automatically calculated based on the next-change edition.
So, in our MDG system, Object A has 4 instances with various validity dates and Object B has 2 instances.
Edition Type should be created before the corresponding editions are created in MDG. Edition types are created through below settings in MDGIMG
You need to provide the Edition type (name of edition), data model which is associated with, Validity of Edition and a description. You need to define the Fiscal Year variant (FV column), in case you choose your edition validity as 'Period Specific'. It is also mandatory to choose at least one Entity type from the data model, otherwise you cannot save the Edition type.
After the edition type is created, we need to create the edition itself. For creating editions, there is a separate Webdynpro Application - USMD_EDITION available in the system. You can access it through multiple MDG-F role like below
This open a Webdynpro page, where you need to define the Edition along with the valid-from date and replication type
In the above screen, you need to provide Edition name, Description, Edition type (the one which is created in previous step), valid from Date (this is automatically choosed, beased on the validity of edition type configuration) and Replication timing. There are three ways you can define the replication of the changes with respect to editions
Generic functions of Editions like Display associated Change requests, changing status delivered through POWL application
Editions are having three status
Edition types has to be associated to CR types, in order to process the changes with respect to the editions. So, the edition types are linked during the CR type creation
Once this link is established, when you open the CR for any master data object, you will see an additional screen in the header 'Validity Data'. This has all the time-dependent information for that object in the system.
If the target system does not support time-dependent master data, you can schedule the changes to be sent to target system on a specific day, before the edition becomes valid. For this, you can use the standard report USMD_EDITION_REPLICATE.
Otherwise, you can choose one of the options as we discussed in previous section, to configure the replication of edition records.
Through this blogpost, we learned how to create, manage and replicate edition in an MDG system.
Please provide your valuable thoughts and feedback in the comments section below. Follow the tag SAP Master Data Governance for more updates on SAP MDG through blog posts and Q&A. You can also follow my profile to get notifications on more exciting blog posts on SAP MDG, next weeks.
Also, See related blogpost on Edition API class
Best Regards
Senthil.
Edition Management in MDG
In MDG, we have two types of business objects which can be governed. One is Standard Business Object like Business Partner, Customer, Vendor which is not time dependent master data (though it has certain entities like addresses which can be time-dependent), which has only one instance of master data in the system and as soon as the changes are approved, the changes are replicated to the Reuse area / downstream systems. Other one is Edition based business objects, which are time-dependent in nature. For these business objects, the replication to reuse area / downstream systems can be configured based on an time interval.
Important criteria for using Edition management in MDG is, the data model should be an Flex model. By default, SAP Standard delivers MDG-F data model as edition dependent data model and you can also create data model for custom objects using editions.
Below figure shows the end-to-end process of governing edition based master data in MDG. In the figure you can see the two different processes of flexible edition management, where you can schedule the changes with an edition also you can directly replicate the changes, even if the business object is edition based. We will see this in detail in the below section, on how to configure replications for edition based objects.
Using Edition brings flexible ways to maintain the master data and also brings transparency about multiple changes made on the data.
Using MDG Editions for Scheduling Changes to Master Data
In the above example, we have two objects Object A, Object B which is maintained across multiple editions E1, E2, E3, E4 with various statuses of those editions.
Below is the edition information with their validity period
| Edition | Valid-From | Status |
| E1 | 01-01-2020 | Released |
| E2 | 01-01-2021 | Released |
| E3 | 01-04-2021 | In-Process |
| E4 | 01-01-2022 | In-Process |
In this example, the Object A is existing in all the editions, which is, in E1 & E2 it is existing as released status, but in E3 & E4 it is existing In-Process status. Whereas, the Object B is existing only in E1 and E3, with E1 as released status and E3 as In-Process status.
If you observe this example, we have only defined the Valid-from date for the editions. Which means, valid-to date is automatically calculated based on the next-change edition.
- In case of Object A in E1, is valid from 01-01-2020 till valid-to 31-12-2020, because, the next change edition for object A is E2 which starting from 01-01-2021.
- This means, when an object is changed under next-edition, the valid-to date is calculated as next-change edition Valid-from date minus 1.
- In our case, Valid-from date of E2 is 01-01-2021
- So Valid-to date of Object A in E1 is (01-01-2021) - (1) = 31-12-2020.
So, in our MDG system, Object A has 4 instances with various validity dates and Object B has 2 instances.
How to maintain and manage editions
Edition Type should be created before the corresponding editions are created in MDG. Edition types are created through below settings in MDGIMG
You need to provide the Edition type (name of edition), data model which is associated with, Validity of Edition and a description. You need to define the Fiscal Year variant (FV column), in case you choose your edition validity as 'Period Specific'. It is also mandatory to choose at least one Entity type from the data model, otherwise you cannot save the Edition type.
After the edition type is created, we need to create the edition itself. For creating editions, there is a separate Webdynpro Application - USMD_EDITION available in the system. You can access it through multiple MDG-F role like below
This open a Webdynpro page, where you need to define the Edition along with the valid-from date and replication type
In the above screen, you need to provide Edition name, Description, Edition type (the one which is created in previous step), valid from Date (this is automatically choosed, beased on the validity of edition type configuration) and Replication timing. There are three ways you can define the replication of the changes with respect to editions
- Manually Started After Release of Edition - this means, you have to trigger the distribution of CR's manually after you release the Edition. This option is choosen, when you want to schedule the changes for an edition and distribute at once when edition is released
- On Final Approval of Change Request - This means, the replication is triggered immediately after the CR is final check approved. In this case, before the edition is changed to released status, there should not be any pending CR's. All the CR's should be approved and changes are replicated.
- Select in Each Change Request - This means, the above two options are shown for each CR and it becomes a mandatory field to be filled. User has to choose Option 1 or Option 2 during CR processing and the replication is planned accordingly. Check below screen
Generic functions of Editions like Display associated Change requests, changing status delivered through POWL application
Editions are having three status
- Set in progress - to make the edition in progress
- Mark for release - edition is in pre-released status, but can be reverted back to inprogress
- released - final state of edition, where further changes using this edition is not possible. We have note here that, you can only release edition if there are no pending change requests under that edition. If you have pending change requests, you can use the 'Reschedule' option and move the CR's to later editions. This can also be achieved using standard report USMD_EDITION_MOVE_CREQUEST
Edition types has to be associated to CR types, in order to process the changes with respect to the editions. So, the edition types are linked during the CR type creation
Once this link is established, when you open the CR for any master data object, you will see an additional screen in the header 'Validity Data'. This has all the time-dependent information for that object in the system.
Replication of Edition data:
If the target system does not support time-dependent master data, you can schedule the changes to be sent to target system on a specific day, before the edition becomes valid. For this, you can use the standard report USMD_EDITION_REPLICATE.
Otherwise, you can choose one of the options as we discussed in previous section, to configure the replication of edition records.
Summary:
Through this blogpost, we learned how to create, manage and replicate edition in an MDG system.
Please provide your valuable thoughts and feedback in the comments section below. Follow the tag SAP Master Data Governance for more updates on SAP MDG through blog posts and Q&A. You can also follow my profile to get notifications on more exciting blog posts on SAP MDG, next weeks.
Also, See related blogpost on Edition API class
Best Regards
Senthil.
- SAP Managed Tags:
12 Comments
