Characteristic Value Mismatch

[Former Member]

Hello Experts,

1. When I check the item-Configuration details for a line item in a contract in VA42, I get the characteristic values related to that item. There is a characteristic called EVOLVE which has a corresponding value 'NOT COVERED'.

2. When I try to get the characteristic value using FM VC_I_GET_CONFIGURATION, I get the characteristic value for EVOLVE characteristic as 'COVERED'.

3. Similarly, I tried the FM CE_C_PROCESSING, it displays a screen (same as in step 1) and characteristic EVOLVE has a characteristic value as 'NOT COVERED'. But this FM does not return any internal table so that I can track this value.

Why am I getting difference in the values in step 1 and step 2? I need to find the reason for this mismatch because we want to design a new report in which we need the characteristic values and we are using FM VC_I_GET_CONFIGURATION for the same but we are getting a wrong value.

It would be great if you experts can help me understand the reason or cause of this mis match.

Thanks,

Jiten

[Former Member]

Hello Experts,

1. When I check the item-Configuration details for a line item in a contract in VA42, I get the characteristic values related to that item. There is a characteristic called EVOLVE which has a corresponding value 'NOT COVERED'.

2. When I try to get the characteristic value using FM VC_I_GET_CONFIGURATION, I get the characteristic value for EVOLVE characteristic as 'COVERED'.

3. Similarly, I tried the FM CE_C_PROCESSING, it displays a screen (same as in step 1) and characteristic EVOLVE has a characteristic value as 'NOT COVERED'. But this FM does not return any internal table so that I can track this value.

Why am I getting difference in the values in step 1 and step 2? I need to find the reason for this mismatch because we want to design a new report in which we need the characteristic values and we are using FM VC_I_GET_CONFIGURATION for the same but we are getting a wrong value.

It would be great if you experts can help me understand the reason or cause of this mis match.

Thanks,

Jiten

[Former Member]

When I check the item-Configuration details for a line item in a contract in VA42

I'd personally stick to the display transactions when reading/checking data. So please give VA43 a try and check if the result looks different than in VA42. Have you run a consistency check on the configuration? Are there possibly any object dependencies involved which might update the characteristic you're looking at? (If you're not sure about this one talk to somebody in your company who is maintaining contracts or has setup contracts...)

[Former Member]

Hi Harald,

Checked VA43... it shows the same data as VA42... I found out from the functional consultant of our team that they have made some changes to the characteristic values for characteristic named EVOLVED. They had swapped the values 'COVERED' and 'NOT COVERED'. and after these changes there is an inconsistency in the characteristic values of item VA42/VA43 and characteristic values retrieved by using FM VC_I_GET_CONFIGURATION.

Please guide me.... how can this inconsistency be resolved....

Thanks,

Jiten

[Former Member]

They had swapped the values 'COVERED' and 'NOT COVERED'. and after these changes there is an inconsistency in the characteristic values of item VA42/VA43 and characteristic values retrieved by using FM VC_I_GET_CONFIGURATION.

As far as I know it should be possible to swap values, because the contract stores the actual characteristic value instead of some internal key references. I did a quick test in an ECC 6.0 system for a sales order (not a contract, but should behave the same), where I swapped some values in a characteristic; configuration displayed in VA03/VA02 and via function module was the same.

I suggest that you do some further investigation in your system; pull in the functional guy, because they should be able to tell you what scenarios the business has and what they do. One thing that I've seen a couple of times are oddball cases that appeared in a development or test system, that nobody could replicate later. You should make sure that you're example is actually representing a real problem that has to be solved.

Just for the heck of it, try what happens when you use function module VC_I_GET_CONFIGURATION_IBASE (but see note [460106|https://service.sap.com/sap/support/notes/460106] on restrictions). Also, I'd do a check what is actually stored on database level (e.g. go from identify ibin-recno by plugging in vbap-cuobj in ibin-instance and look-up the corresponding values via v_ibin_syval). That should give you some idea. There's other function modules (like external API CAVC_DB_READ_CFG_IN_CBASE), but it doesn't make much sense to try lots of other functions without understanding why you see the difference.

And as always I'd head over to OSS and check for any bugs that might be applicable.

Cheers, harald