cancel
Showing results for 
Search instead for 
Did you mean: 

Error in automatic conv of time char of Stock Cube/Inventory cube

Former Member
0 Kudos

Hi all,

I am mapping 0calday(posting date) to time char like 0calmonth, 0calyear, 0fiscper, 0fiscyear and when I do, they get automatically mapped to "Reference Time characteristic" and when I load data I am getting the following error

"Time conversion from 0CALDAY to 0FISCYEAR (fiscalyear) failed with value 20060210" with message id RSAU and no 896.

I found snotes 608896, 619851(which says only for 3.0B version) relating to the error but I am on 3.5, Level 12 and highest support package SAPKW35012.

thanks,

Sabrina.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Buongiorno Sabrina,

map them in Transfer Rules of your Infosource, when you're mapping DataSource ---> Infosource.

For Fiscyear write a routine that takes only first 4 digit:

result = calday(0)+4. (or something similar,... I'm not near a SAP BW now)

For fiscper.....it's strange your mapping fiscal period could be more than 12 (as number of months)... SAP arrives up to 16....

But if you want to map month--->fiscper use the same method of fiscyear and take only 2 digit:

result = calday(3)+2.

ciao.

claudio

If it'useful, please take me reward points

Former Member
0 Kudos

Hi Claudio - thanks for your reply, but why should I map in transfer rules when SAP provides automatic conversion in update rules? I feel I should install a support package or may an Snote to solve this.

please let me know....

thanks

Sabrina.

Former Member
0 Kudos

The Transfer Rules changes are simply and immediate, even if custom and not standard.

OSS note, with support package or other 'standard' solutions, are possible and good to apply >if they exists,< or are immediately ready for use ...

...code is the same ...why are you waiting for :)?

ciao

Former Member
0 Kudos

I am sorry Claudio, I am not able to understand your response. Can you please tell me again....

I will assign you points but I am getting an error while doing so.

thanks,

Sabrina.

Former Member
0 Kudos

Hi all - did anyone face the same problem? Any OSS note or any suggestion why this is happening...

Claudio - just wanted to see if anyone else is facing the same problem.

please let me know.

thanks,

Sabrina.

Former Member
0 Kudos

Hi Sabrina,

I know this ca be not so easy, but why don't you try to simulate the update in debug mode ?

In this way you will be able to directly verify WHERE in the code of the update rules this error arises and check if you need to upload your time references in BW (in source system, right-click on it, upload source system settings...), for example, or if something doesn't work in a specific record ?

Are you receiving the same error also for other similar records (for the same year...)

Bye,

Roberto

Former Member
0 Kudos

I will try that. Actually I did not check for the other records.

thanks,

Roberto.

Former Member
0 Kudos

Hi Roberto - what exactly are these global settings, especially for fiscal variant. Please let me know.

I am able to fix the problem, fiscal variant was not populating so I assigned a constant in Update rules.

thanks again Roberto.

Sabrina.

Former Member
0 Kudos

I think that Roberto gave optimal suggestions as everytime..

..but my doubt isn't only technical but accountant....

1)you make automatic conversion, 0CALDAY>0FISCYEAR in Update Rules..... (I suppose also 0CALDAY>0FISCPER &FISCPER3)... It's audacious....

2)Fiscal Variant indicates Special Fiscal Periods .

EX- K4 --> 12 Months + 4 Special Periods

How you can hardcode as constant?

In your country or better, in company account 'way' there aren't 'Fiscal Periods'..... It's not a tech problem!

Former Member
0 Kudos

Claudio - I wish I knew what the problem was. I mapped the Fiscal Variant in the update rules to a constant and I did not get any errors. May be Roberto can explain...........

I tried to debug the update rules, but I did not completely understood the system defined functions/subroutines for conversion.......

thanks

Sabrina.

Former Member
0 Kudos

Problem is not technical... but of management

bye

Answers (0)