Classification Datasource (CTBW) - Different characteristic onfig. in R/3

[Former Member]

I generated a material classification datasource (1CL_*) in development with CTBW transaction and then include it in a transport and move it to quality. But we are facing the issue that on R/3 side the master data team did not define the characteristics (CT04 transaction) exactly in the same way in all environments (specifically I am talking about different lengths u2013 for example a characteristic being 30 chars in Dev/ Qal and 10 in Prod). The MD team said that this is not transportable in R/3 since it is considered master data u2013 so, it is manual configuration in each environment.

How is this 'flexibility' managed in BI?. Is the generation of the datasource using CTBW transaction something that should be done in each environment? If the response is yes, the issue is the system should have to open for modifications (customizing). And this is something that will need to be done (open system, regenerate CTBW) everytime they decide to change a characteristic definition.

Also, this is not something that they can replicate in dev, since it is not allowed by the system to shorten the length of the characteristic (only to expand it). So, even if we want to replicate the case in dev., regenerate the datasource and transport, it is not possible. And also, how to avoid this being done directly in production at any time (since R/3 standard gives this flexibility when considering this as master data)?.

Did anyone have / hear any similar scenario?. Thanks!

[Former Member · Accepted solution]

Claudia,

you're right. Definitions of characteristics are master data not customizing.

Characteristics use internal keys. The same characteristic probably will have different internal keys in different clients. Transporting characteristics so probably would create inconsistencies in the target client. The intended method is distribution via ALE. See please message type CHRMAS.

If you take care that characteristics used in CTBW are available in all relevant clients and they are defined in the same way (that's necessary because fields in generated extract structure depend on these definitions) you won't need to generate such datasources again in quality or production system.

Regards,

Rolf

[Former Member · Accepted solution]

Thank you for your answers. But, what you are pointing out is exactly the issue I have. The config. team in R/3 want to have different definitions for some of the characteristics in the different environments. And I am talking about having different lengths even in the production system. So, I think I will not have other alternative than manually re-generating my datasource in each of the environments (having previously opened the system for customizing).Correct?

If they have defined longer lengths in development than in quality and production, would that be an issue?. I wonder that, cause I would be extracting a value and moving it to a longer field in the extraction structure.

[Former Member · Accepted solution]

Claudia,

I had understood that you're looking for a way how to align characteristics in the different systems.

You're right. If you need different definitions of characteristics you will have to generate the datsources again.

The demand to have different definitions for the same characteristic used in CTBW datasources is very unusual. How can you guarantee quality, if already tested objects are changed again when they are transferred to production?

I would recommend to use identical characteristic defintions. If you need deviating defintions, additional characteristics should be created therefore.

Regards,

Rolf