cancel
Showing results for 
Search instead for 
Did you mean: 

Extension definition not updating in QA environment

0 Kudos

Hi,

We are moving from the development environment to QA environment. We have transported extension definition from DEV to QA however extension definitions for cost centre (626) are not reflecting on the cost center in QA and we cannot make changes to them.


They seem to not have picked up values from the database attribute table. Could you please assist with this problem.

We are on SAP Sourcing 10.0.08.01.


Regards,

Thembi Sihlongonyane

Accepted Solutions (1)

Accepted Solutions (1)

ginodw2014
Explorer
0 Kudos


Hi Thembi,

I don't think you can transport extension definitions, you will have to create the extension in each environment manually.

Kind Regards

Gino

0 Kudos

Hi Gino,

We have tried doing that however it does not allow us to make changes to the cost centre extension.

Regards,

Thembi Sihlongonyane 

ginodw2014
Explorer
0 Kudos

Hi Thembi,

Check your accesses if it allows you too make changes to extensions tables. You can try with the enterprise user.

Regards

Gino

former_member89217
Contributor
0 Kudos

Extension definitions can be transported under certain circumstances. There are also a couple different ways to deal with extension definitions. The first is just using the transport system (AKA object migration) as you have seemed to try. This has a couple downfalls. 1) it will transport BOTH active and inactive extensions. 2) you have to ONLY use the transports. manual creation or imports can cause issues. The second way to deal with extension definitions is to use the import functionality and keep spreadsheets containg the the current active list of extensions this can be applied to subsequent landscapes as needed. The advantage is you dont have to propogate inactive extensions. The downside is manual maintanenenace of the import spreadsheet. Your current issue sounds like it could use some assitnace form support try to collect the logs when the transport was done. if this is  not available, work with support to try to recreate the issue.

gary

former_member190023
Contributor
0 Kudos

This issue is all to general when transporting extension definitions via standard or custom OML queries.

The problems can range from:

- incorrectly created OML query

- extension reference type missing in TARGET system

- master data object set as default - cannot be found in target sys because of different business system

- extra extension definitions contained in TARGET system (either from a manual creation or from running the inactive removal on the SOURCE system before export)

All of the above will lead to a misalignment between FCI_DOC_EXT*** tables and FCI_SYS_DYN*** tables and this is a really bad situation. The general solution is to actually rollback the target system to a DB backup; or to find a really good consultant that knows both DB and CLM and manually do the DB correction.

As Gary said... transporting extensions can get very complex if their impact is not correctly understood. So make sure you follow only one process and always keep all your systems ALIGNED.

Regards,

Bogdan

former_member207877
Active Participant
0 Kudos

Hello Thembi,

As Gary and Bogdan said great care has to be taken while transporting extensions.

Transporting extensions through OMA is bad practice especially in case of extensions of types object references, VLV's...

VLV internal Id may be different in source and target systems(few cases), and when you transport extension through OMA it will not be able to find the VLV reference, in this case you will not be even able to open the extension definition and the documents associated to it.

Best practice is to transport through workbook taken care all the dependents are accurate and in place.

Regards,

Raj

Answers (0)