Routine not performing calculation

[Former Member]

Hi gurus,

I have written a code but its not performing calculations and bringing 'ZERO' values for key figure.

Its pretty long I am just putting here part of it.

DATA: result_pkg_temp TYPE STANDARD TABLE OF tys_tg_1

WITH NON-UNIQUE DEFAULT KEY.

DATA: lv_totamnt TYPE /bic/oiyactcogma.

CONSTANTS: lc_pct1 TYPE f VALUE '0.6687',

lc_pct2 TYPE f VALUE '0.1667',

lc_pct3 TYPE f VALUE '0.4333',

lc_pct4 TYPE f VALUE '0.1083',

lc_cc1 TYPE /bi0/oicostcenter VALUE 'ZTE64350',

lc_cc2 TYPE /bi0/oicostcenter VALUE 'MUS80900'.

LOOP AT RESULT_PACKAGE ASSIGNING <result_fields>.

lv_totamnt = <result_fields>-/bic/yactcogma.

CASE <result_fields>-costcenter.

WHEN lc_cc1

or lc_cc2

CLEAR : <result_fields>-/bic/yactcogma,

<result_fields>-record.

<result_fields>-/bic/yactcogma = lv_totamnt * lc_pct1.

APPEND <result_fields> TO result_pkg_temp.

CLEAR :<result_fields>-/bic/yactcogma, <result_fields>-record.

<result_fields>-/bic/yactcogma = lv_totamnt * lc_pct2.

APPEND <result_fields> TO result_pkg_temp.

CLEAR :<result_fields>-/bic/yactcogma, <result_fields>-record.

<result_fields>-/bic/yactcogma = lv_totamnt * lc_pct2.

APPEND <result_fields> TO result_pkg_temp.

CLEAR :<result_fields>-/bic/yactcogma, <result_fields>-record.

WHEN lc_cc2.

CLEAR :<result_fields>-/bic/yactcogma, <result_fields>-record.

<result_fields>-/bic/yactcogma = lv_totamnt * lc_pct4.

APPEND <result_fields> TO result_pkg_temp.

CLEAR :<result_fields>-/bic/yactcogma, <result_fields>-record.

<result_fields>-/bic/yactcogma = lv_totamnt * lc_pct4.

APPEND <result_fields> TO result_pkg_temp.

CLEAR :<result_fields>-/bic/yactcogma, <result_fields>-record.

WHEN OTHERS.

CLEAR <result_fields>-record.

APPEND <result_fields> TO result_pkg_temp.

ENDCASE.

ENDLOOP.

REFRESH RESULT_PACKAGE.

RESULT_PACKAGE[] = result_pkg_temp[].

REFRESH result_pkg_temp.

Can anyone please help.

[Former Member · Accepted solution]

This is pretty long actually as lc_pct goes to till LC_pct12

and lc_cc1 goes to lc_cc19.

The logic is same. I don't know why its bringing '0' values.

We have data in the source Cube pertaining to all those cost center selections.

Thanks for the help.

[Former Member · Accepted solution]

Hi Shalini,

You can debug this code to find out where it is going wrong.

Thanks,

Krishnan

[Former Member · Accepted solution]

hi,

in your code you have written an or statement for a case statement which will not work.

CASE <result_fields>-costcenter.

WHEN lc_cc1

or lc_cc2

CLEAR : <result_fields>-/bic/yactcogma,

Also check on icostcenter object, is it alpha appended object if yes then you need to append zeros to constant such that the length matches with the costcenter object length.

regards,

Arvind.

Edited by: Arvind Tekra on Jul 18, 2011 6:00 PM

[Former Member · Accepted solution]

Thanks Arvind,

how can I change Case statement so that 'or' can work?

Thanks

[Former Member · Accepted solution]

Hi Arvind,

Even after removing 'Or' it didn't work.

Thanks

[Former Member · Accepted solution]

hi,

you cannot, the case statement is designed to compare only 1 value.

the OR part write in another when 'XYZ' and copy the existing code.

also check the infoobject costcenter and provide details of its type (char,lenght,conversion type).

regards,

Arvind.

[Former Member · Accepted solution]

Hi Arvind,

It didn't work. I removed all cases except lc_cc1. But result is same '0' values for keyfigure.

I don't think Alpha Conversion is an issue as same code ( as I copied it from another transformations) is running just fine without putting '00' to satisfy Alpha Conversion as CostCenter length is '10'.

Thanks

[Former Member · Accepted solution]

hi,

The issue might lie with your definition

lc_cc1 TYPE /bi0/oicostcenter VALUE 'ZTE64350',

lc_cc2 TYPE /bi0/oicostcenter VALUE 'MUS80900'.

debug the program and see if it matches at the case statement,

regards,

Arvind.

[Former Member · Accepted solution]

In that case it should not work for another transformations.

Well..I will debug and see whats going wrong.

Thanks for your response though.

Appreciate.