Error occurs when writing to cube; Keyfigure must be less than 14 digits

[Former Member]

Hello everyone!

This message is just to know if someone of you have seen this kind of error when running the consolidation package, the error says:

u201CError occurs when writing to cube; Keyfigure must be less than 14 digitsu201D

Does somebody knows how to solve this error?

Thanks.

[Former Member]

Hi,

We are facing exactly the same issue.

Any idea how to fix this?

Thanks in advance

Kind regards

Begonia

[Former Member]

Hi Experts,

I heard this problem exactly one year ago, it was 7.0, does anybody know this is fixed in the new version of BPC NW such as 7.5 or EPM 10?

1. What happen we inteface data(over 14 digits) from system to system?

2. Is this a problem only related to client interface such as EXCEL?

3. If the limit is as same as data size of key figure, why we cannot increase it to a certain data size such as Decimal(25,10)?

We are using the currency as WON(Korean) and it is bigger then Dollar and Euro, $1 is around 1,100 Won and 1Euro is around 1,200 Won, therefore 14 digits limitation is more serious than others. If we need to have scale function whenever we write and read data, it might affect performance I think.

Regards,

YH Seo

[former_member200327]

Hi YH Seo,

This is not a BPC problem, same issue exist in ECC (R/3). So, yens are stored there in 100s and Wons are stored in 1,000s. System divides all incoming values in that currency and stores it that way and multiplies just when value is needed for output.

I don't think this could cause any performance issues; at least I haven't heard in ECC (R/3) related to those conversions.

BPC doesn't have that automation, so you'll have to do this manually.

Regards,

Gersh

[Former Member]

Hi YH Seo,

This is not a BPC problem, same issue exist in ECC (R/3). So, yens are stored there in 100s and Wons are stored in 1,000s. System divides all incoming values in that currency and stores it that way and multiplies just when value is needed for output.

I don't think this could cause any performance issues; at least I haven't heard in ECC (R/3) related to those conversions.

BPC doesn't have that automation, so you'll have to do this manually.

Regards,

Gersh

===================================================================================================

Hi Gersh,

Thanks for your explaination.

To summarize, the workaround is to have conversion function anyway. My client shows over 14 digits without decimal for a year budget, therefore I need to know what I exactly do for the conversion.

1. BW cannot get keyfigure what exceeds 14 digits, does it mean aggregation value also cannot exceeds 14 digits?

2. Is there a feature to introduce scale before output the result of query in BW?

3. DTP(Data Transfer Package) should scale the input and Report should multiply the scale, what is BPC NW feature for the scaling? In case of DTP we can implement with ABAP, but how we can deal with Report of BPC?

Looking forward hearing any suggestion.

Regards,

YH Seo

Edited by: YHSeo_KR on May 31, 2011 3:46 AM

Edited by: YHSeo_KR on Jun 2, 2011 8:46 AM

Edited by: YHSeo_KR on Jun 2, 2011 8:47 AM

[Former Member]

Hi Miguel,

the error says exactly what is happening, that happened to me once when I was starting to use script logic, by default BPC can store no more than 14 digits of transactional data, it seems that you are trying to do an operation that exceeds that limit.

hope it helps,

[Former Member]

Hi Guillermo,

Do you know if exists a way to increase the value for the keyfigure, and make it accept the values that the program is generating?

Thanks

[Former Member]

Hi Miguel,

I don't know if it is possible, at list it is not posible at the front end interface, and i think it not a good practice to do it.

hope it helps,

[former_member200327]

Hi Miguel,

No, it's impossible to change type of the Amount and I doubt that you need result with this many digits. There is a lot of ways to get around that issue. If for example, you summarizing amounts to calculate a ratio then first divide numerator and denominator by 10 or 100 and then summarize. Loss of precision will be insignificant.

I bet you can came up with similar ideas for the calculation you are actually doing.

Regards,

Gersh