Skip to Content
0

SAP BPC 10.1 NW - Script logic decimal issue

Jul 11, 2017 at 09:50 AM

125

avatar image
Former Member

Dear expert,

I am working on BPC 10.1 NW on HANA (version CPMBC81008 with HANA accellerator on BW 740) and I have the following issue on script logic.

Basically I am trying to write a very simle script, just to copy a value from an Account to another one. The script is:

*XDIM_MEMBERSET CATEGORY = Actual
*XDIM_MEMBERSET RPTCURRENCY = LC
*XDIM_MEMBERSET AUDITTRAIL = Input
*WHEN ACCOUNT
*IS BS111
*REC(FACTOR=1,ACCOUNT=BS121)
*ENDWHEN

When I run it for an integer, it works correctly

However if I run it with a number with decimal positions, it works very strangely:

It's like the system is copying only the decimal digits (after the comma) and not the integer part. I guess this may be related to some Language settings or a Bug.

Do you have any opinions about this?

Thanks a lot for your valuable feedback

Best regards

Francesco

cattura.png (10.6 kB)
cattura2.png (10.1 kB)
10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

4 Answers

Best Answer
avatar image
Former Member Jul 31, 2017 at 04:43 PM
1

Dear all,

the problem is solved and the solution was provided by SAP, after opening an incident.

The issue was related to a flag in table T005X

For LAND=US, XDEZP had to be set to X (initially was set to blank).

After this, the script logic worked fine

Thanks anyway for your support

Rgds


cattura.png (16.5 kB)
Share
10 |10000 characters needed characters left characters exceeded
avatar image
Former Member Jul 11, 2017 at 03:32 PM
0

I have run the script in UJKT and this is the result:

LGX: *XDIM_MEMBERSET CATEGORY =Actual
*XDIM_MEMBERSET RPTCURRENCY = LC
*XDIM_MEMBERSET AUDITTRAIL = Input
*WHEN ACCOUNT
*IS BS111
*REC(FACTOR=1,ACCOUNT=BS121)
*ENDWHEN -------------------------------------------------------------------------------------------------------------------------------------
LOG: LOG BEGIN TIME:2017-07-11 17:30:06
FILE:\ROOT\WEBFOLDERS\TEST_ALIMCO \ADMINAPP\Consolidation\TEST.LGF
USER:SAPGARAVINI
APPSET:TEST_ALIMCO
APPLICATION:Consolidation
[INFO] GET_DIM_LIST(): I_APPL_ID="Consolidation", #dimensions=10
ACCOUNT,AUDITTRAIL,CATEGORY,ENTITY,FLOW,INTERCO,MEASURES,RPTCURRENCY,SCOPE,TIME #dim_memberset=3
CATEGORY:Actual,1 in total.
RPTCURRENCY:LC,1 in total.
AUDITTRAIL:Input,1 in total. REC :%value%*(1) CALCULATION BEGIN:
QUERY PROCESSING DATA
QUERY TIME : 0.00 ms. 1 RECORDS QUERIED OUT.
QUERY REFERENCE DATA
CALCULATION TIME IN TOTAL :0.00 ms.
1 RECORDS ARE GENERATED.
CALCULATION END. ENDWHEN ACCUMULATION: 1 RECORDS ARE GENERATED. DATA TO WRITE BACK:
ACCOUNT AUDITTRAIL CATEGORY ENTITY FLOW INTERCO RPTCURRENCY SCOPE TIME SIGNEDDATA
BS121 Input Actual DE Balance ThirdParty LC S_None 2014.01 13.00
1 RECORDS HAVE BEEN WRITTEN BACK.
WRITING TIME :1.00 ms. SCRIPT RUNNING TIME IN TOTAL:1.00 s.
LOG END TIME:2017-07-11 17:30:06

Show 17 Share
10 |10000 characters needed characters left characters exceeded

Interesting:

BS121 Input Actual DE Balance ThirdParty LC S_None 2014.01 13.00

May be you have some strange write back badi in the system?

0
Former Member

Well I don't think so..it's a brand new system so I guess there is no enanchement there. I discovered this issue while I was doing some functional test on the system! My concern is that there is an installation issue or a Language setting problem (but actually I have no clue)

How could I check if there's a write back logic?

Thanks a lot

rgds

0

Just perform another test with the script:

*XDIM_MEMBERSET CATEGORY =Actual
*XDIM_MEMBERSET RPTCURRENCY = LC
*XDIM_MEMBERSET AUDITTRAIL = Input
*WHEN ACCOUNT
*IS BS111
*REC(EXPRESSION=%VALUE%,ACCOUNT=BS121)
*ENDWHEN

This script is equivalent of the FACTOR=1

0
Former Member

I nave done it and I get the same result !

0

What about if you have more decimals in the original value?

30.1345

0
Former Member

Hi Vladim,

if I put 1000,345 the result is 345

if I put 1000,1345 the result is 1345

Always the 'after comma' part

Thanks

0

Something unbelievable :)

Please check for write back badi - is it implemented?

Then perform ABAP debug of script execution...

0
Former Member

There are no implementations in

UJR_WRITE_BACK

What do you mean by ABAP debug?

Thanks

0

Script is processed by ABAP code:

1. SELECT's are calculated, all variables are replaced by values, for/next are replaced by text repetitions.

2. WHEN/ENDWHEN is processed and each line is finally calculated by JavaScript call.

3. The result is saved using ABAP

You can analyze this process using ABAP debug - takes time, but you will find the reason for the issue!

0

P.S. Look on Gersh comments here:

https://archive.sap.com/discussions/thread/2033536

0
Former Member

I found another behavior:

if I run the following script

*XDIM_MEMBERSET CATEGORY =Actual
*XDIM_MEMBERSET RPTCURRENCY = LC
*XDIM_MEMBERSET AUDITTRAIL = Input
*WHEN ACCOUNT
*IS BS111
*REC(EXPRESSION=100/3,ACCOUNT=BS121)
*ENDWHEN

I get the following result:

DATA TO WRITE BACK:
ACCOUNT AUDITTRAIL CATEGORY ENTITY FLOW INTERCO RPTCURRENCY SCOPE TIME SIGNEDDATA
BS121 Input Actual DE Balance ThirdParty LC S_None 2014.01 33.33
1 RECORDS HAVE BEEN WRITTEN BACK.
WRITING TIME :0.00 ms.

I get only two decimals: it is normal? SIGNEDDATA is supposed to have 7 digits after comma.

By the way: if I make the same copy through DM Copy or business rules it works fine.

Rgds

0

"I get only two decimals: it is normal? SIGNEDDATA is supposed to have 7 digits after comma." - in the log you will always see only 2 decimals. Check in report!

0
Former Member

Yes you are right..in report I see all the decimals.

However it looks there is something wrong when it turns to read a FACTOR or a %VALUE%, because if I force the amount in the script there is no problem.

I really have no clue..I asked for a basis team support. let's see if they can figure out something.

thanks and rgds

0

Basis team? Better to ask ABAP developer...

0
Former Member

Well I asked to whom I could ask! If I could get some ABAP developer support, I would certainly ask him Thanks anyway for your help

0

Without the person able to perform abap debugging you can do nothing...

0
Former Member

I guess you are right..I will look for it and let you know.

thanks for your valuable suggestions

0
Vadim Kalinin Jul 11, 2017 at 02:23 PM
0

Looks very strange!

But I have to ask a lot of questions - please read:

https://blogs.sap.com/2014/01/31/how-to-ask-questions-about-script-logic-issues/

and provide required info!

If it's default.lgf please test it in UJKT with the fixed scope like in your report!

Share
10 |10000 characters needed characters left characters exceeded
avatar image
Former Member Jul 11, 2017 at 03:11 PM
0

Hi Vladim,

thanks for your reply and please find the required info:

  1. Version: BPC 10.1 NW on HANA (version CPMBC81008 with HANA accellerator on BW 740)
  2. Engine shold be Javascript, as UJKT validated correctly the test script with MATH
  3. Environment is a copy of ENVIRONMENTSHELL with no customizations. Model consolidation. Dimensions are ACCOUNT, AUDITTRAIL, CATEGORY, ENTITY, FLOW, INTERCO, RPTCURRENCY, SCOPE, TIME. Account type I used for my testing are AST but I guess it's not relevant for my problem. I had the same issue in another environment of the same installation (so it looks like something general of the system and not related to a specific environment/model)
  4. The script has to be run through a DM package
  5. The script is the most basic one I could imagine to reproduce the issue. It's just copying a value from an Account to another one
  6. *XDIM_MEMBERSET CATEGORY =Actual
    *XDIM_MEMBERSET RPTCURRENCY = LC
    *XDIM_MEMBERSET AUDITTRAIL = Input
    *WHEN ACCOUNT
    *IS BS111
    *REC(FACTOR=1,ACCOUNT=BS121)
    *ENDWHEN
  7. No prompts are needed
  8. There is no data region or param to set in UJKT
  9. Report is the following one:
cattura.png


cattura.png (10.6 kB)
cattura2.png (10.1 kB)
Show 1 Share
10 |10000 characters needed characters left characters exceeded

Please run this script in UJKT and post the log here!

0