Skip to Content
0

RUNLOGIC_PH Script gives different answer to called Script Logic

Jul 12, 2017 at 02:38 PM

168

avatar image
Former Member

Hi,

We are upgrading from BPC 10.0 SP4 on BW 7.31 on MS-SQL --> BPC 10.1 on BW 7.51 on HANA.

I am finding a strange result in out RUNLOGIC_PH script (which worked before in BPC 10.0). I get a different results if I run the destination script from the calling Model than when I run the same script in the destination Model.

So, if I execute the RUNLOGIC_PH from the Consolidation Model, I get different figures than if I run the Script Logic directly in the ICMatching Model for the same Scope. (In the case of the specific data I am analysing, it's a factor of 9 times different).

I have a Consolidation Model executing the RUNLOGIC_PH

I have an ICMatching Model hosting the called code.

Calling Code from the Consolidation Model:

*START_BADI RUNLOGIC_PH
QUERY = OFF
WRITE = ON
APPSET = DD_BPC_IFRS
APP = ICMatching
DEBUG = ON
VALIDATION = ON
LOGIC = ALTERPC.LGF
DIMENSION ICACCOUNT = <ALL>
DIMENSION ICAUDITID = <ALL>
DIMENSION ACCOUNT = <NONE>
DIMENSION AUDITID = <NONE>
DIMENSION CCENTRE = <NONE>
DIMENSION CONSOSCOPE = <NONE>
DIMENSION LOB = <NONE>
DIMENSION SUPPACC = <NONE>
DIMENSION CATEGORY = %CATEGORY_SET%
DIMENSION CURRENCY = USD,ZAR
DIMENSION ENTITY = <ALL>
DIMENSION FLOW = <ALL>
DIMENSION INTERCO = <ALL>
DIMENSION PCENTRE = %PCENTRE_SET%
DIMENSION TIME = %TIME_SET%
*END_BADI

The ICMatching Model: ALTERPC.LGF (Called Code)

*XDIM_MEMBERSET CATEGORY = %CATEGORY_SET%
*XDIM_MEMBERSET CURRENCY = USD,ZAR
*XDIM_MEMBERSET ENTITY = BAS(LE_GDDHP)
*XDIM_MEMBERSET FLOW = <ALL>
*XDIM_MEMBERSET ICACCOUNT = <ALL>
*XDIM_MEMBERSET ICAUDITID = DEBIT1,CREDIT1,DEBIT2,CREDIT2
*XDIM_MEMBERSET INTERCO = <ALL>
*XDIM_MEMBERSET PCENTRE = %PCENTRE_SET%
*XDIM_MEMBERSET TIME = %TIME_SET%
*WHEN FLOW
*IS F99
*REC(FACTOR=1, FLOW="PL99",PCENTRE = ENTITY.COUNTRY)
*ENDWHEN
*COMMIT

Like I mentioned before, this used to work fine in BPC 10.0. Now I have to execute the code from the ICMatching Model for it to give the correct results. I do get results executing the RUNLOGIC, just that they are incorrect.

Anyone seen something like this before?

Kind Regards

Nick

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

3 Answers

Best Answer
Vadim Kalinin Jul 24, 2017 at 04:44 PM
1

Try to select only base members of dimension PCENTRE in VADIM_APC_INC:

*SELECT(%PC%,[ID],PCENTRE,[ID]=%PCENTRE_SET% AND [CALC]=N) // Select only base members from %PCENTRE_SET%
*XDIM_MEMBERSET PCENTRE=%PC%
*WHEN FLOW
*IS *
*REC(FACTOR=1, FLOW="PL99",PCENTRE = ENTITY.COUNTRY)
*ENDWHEN

"When I run the code from ICMatching, as you have mentioned, no records are written. Weird." - no comments, you are doing something wrong. It has to work!

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

P.S. The reason is that starting from some SP the WHEN/ENDWHEN loop logic was changed - now parent members are also processed by WHEN/ENDWHEN loop. Now using ALL is dangerous!

1
Former Member
Vadim Kalinin

Thanks for that update, Vadim. Good to know!

0
Vadim Kalinin Jul 12, 2017 at 04:07 PM
2

"Incorrect result" - means nothing! You have to test script on some narrow scope to demonstrate the different results for some clear set of members.

By the way the scripts can be reduced:

*START_BADI RUNLOGIC_PH
QUERY = OFF
WRITE = ON
// APPSET = DD_BPC_IFRS - will use current environment!
APP = ICMatching
DEBUG = ON
VALIDATION = ON
LOGIC = ALTERPC.LGF
//unused dimensions
DIMENSION ACCOUNT = <NONE>
DIMENSION AUDITID = <NONE>
DIMENSION CCENTRE = <NONE>
DIMENSION CONSOSCOPE = <NONE>
DIMENSION LOB = <NONE>
//used dimensions
DIMENSION ICACCOUNT = <ALL>
DIMENSION ICAUDITID = DEBIT1,CREDIT1,DEBIT2,CREDIT2 //!!!!!!!!!!!!!
DIMENSION SUPPACC = <NONE>
DIMENSION CATEGORY = %CATEGORY_SET%
DIMENSION CURRENCY = USD,ZAR
DIMENSION ENTITY = BAS(LE_GDDHP) //!!!!!!!!!!!
DIMENSION FLOW = F99 //!!!!!!!!!!!!!!!!!
DIMENSION INTERCO = <ALL>
DIMENSION PCENTRE = %PCENTRE_SET%
DIMENSION TIME = %TIME_SET%
*END_BADI

And the calling script:

*WHEN FLOW //or any other dimension name
*IS *
*REC(FACTOR=1, FLOW="PL99",PCENTRE = ENTITY.COUNTRY)
*ENDWHEN

the scope will be defined by RUNLOGIC_PH

Share
10 |10000 characters needed characters left characters exceeded
avatar image
Former Member Jul 12, 2017 at 06:48 PM
0

Hi Vadim,

Thanks for the reply and for the assistance to the code. Appreciated. I will make the necessary adjustments and revert.

I see that all the Scope is handled from the calling Script Logic, rather than in the destination Script Logic

By "incorrect result", I mean the result we see on the 10.0 system (which is correct) differs from the 10.1 server (which is incorrect). This is for a specific slice of data. Either way, let me make the changes and revert.

Thank you.

Kind Regards

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

"I mean the result we see on the 10.0 system (which is correct) differs from the 10.1 server (which is incorrect)." - unfortunately this statement will not help to understand the issue...

You have to perform tests with small scope, analyze values, etc...

You can run the script directly using another script to set scope:

*XDIM_MEMBERSET CATEGORY = %CATEGORY_SET%
*XDIM_MEMBERSET CURRENCY = USD,ZAR
*XDIM_MEMBERSET ENTITY = BAS(LE_GDDHP)
*XDIM_MEMBERSET FLOW = F99
*XDIM_MEMBERSET ICACCOUNT = <ALL>
*XDIM_MEMBERSET ICAUDITID = DEBIT1,CREDIT1,DEBIT2,CREDIT2
*XDIM_MEMBERSET INTERCO = <ALL>
*XDIM_MEMBERSET PCENTRE = %PCENTRE_SET%
*XDIM_MEMBERSET TIME = %TIME_SET%
*INCLUDE ALTERPC.LGF
0
Former Member

Hi Vadim,

Thanks for the response. I am still battling. I suspect it's my scoping somehow. I have tried both your options (the source scoping and the *INCLUDE in the destination.

Assume I have the following source record:

CATEGORY,CURRENCY,ENTITY,FLOW,ICACCOUNT,ICAUDITID,INTERCO,PCENTRE,TIME,SIGNEDDATA
ACTSTAT,USD,LE_ISDV,F99,A103000,DEBIT1,I_LE_ISMC,PC_ISDV,2017.JUN,10844111.67

Then the resultant record "should" be as per below (as in how it does it in BPC 10.0):

(Just the F99 changes in this case. In other cases I will "force" the PCENTRE). This is also the result if I run the ALTERPC.LGF directly in the ICMATCHING Model using UJKT.

CATEGORY,CURRENCY,ENTITY,FLOW,ICACCOUNT,ICAUDITID,INTERCO,PCENTRE,TIME,SIGNEDDATA
ACTSTAT,USD,LE_ISDV,PL99,A103000,DEBIT1,I_LE_ISMC,PC_ISDV,2017.JUN,10844111.67

However, If I run it from the Consolidation Model, I get:

CATEGORY,CURRENCY,ENTITY,FLOW,ICACCOUNT,ICAUDITID,INTERCO,PCENTRE,TIME,SIGNEDDATA
ACTSTAT,USD,LE_ISDV,PL99,A103000,DEBIT1,I_LE_ISMC,PC_ISDV,2017.JUN,97597005.03

This number, in this case, is 9 times the other.

Like I said, somehow I have something wrong in the scoping that seems to work in BPC 10.0 but gives a different result in BPC 10.1.

I am now trying a *FOR ... *NEXT loop across PCENTRE and ICAUDITID to see if that solves the problem. Initial indications are that it is working. I need to test some more. It's not ideal since it's a lot slower, but at least we get the correct figure.

I hope I am making sense and also answering your question.

Kind Regards

Nick

0

First - you have to provide logs - direct script run with include and runlogic script run.

"I am now trying a *FOR ... *NEXT loop across PCENTRE and ICAUDITID to see if that solves the problem." - absolutely incorrect approach! No reason to use FOR/NEXT!!!

0
Former Member

Hi Vadim,

Yip. I hear you on the *FOR ... *NEXT. 100% agree. Very bad idea, but it's working for now. Albeit slowly.

Can I submit the UJKT logs for you for each of *RUNLOGIC_PH and the direct run? Is that what you are after?

Thanks

Nick

0

Yes, please post logs!

0
Former Member

Hi Vadim,

Sorry for the delay.

OK, as requested, I have run the process. Once from the Consolidation Model (where I use RUNLOGIC_PH) and then the other direct in the ICMatching Mode, clearing, etc., between each run. I have run these through UJKT. I have then included two log files and the two spreadsheets screengrab results (EPM Reports) with the relevant names. The Reports make it easier to narrow down the data intersection.

Look in Rows 14 onwards (FLOW=PL99) where you can easily see the differences.

My Context that I am using in UJKT is

CATEGORY=ACTSTAT
PCENTRE=<ALL>
TIME=2017.JUN

Hope this makes sense.

Kind Regards

Nick

vadim-from-consol.txt

vadim-from-icmatching.txt

0
Former Member

Hi Vadim

Battling to upload the spreadsheet files (images).Will try from another browser.

BR

Nick

0
Former Member

Hi Vadim,

These will help a lot.

vadim-from-consol.jpg

vadim-from-icmatching.jpg

Kind Regards

Nick

0

Just text of

VADIM_APC.LGF

is missing!

0

And it's very hard to analyze difference with PCENTER=<ALL>

it's better to use some small subset...

0
Former Member

Hi Vadim,

Here is the code for VADIM_APC.LGF

*XDIM_MEMBERSET CATEGORY = %CATEGORY_SET%
*XDIM_MEMBERSET CURRENCY = USD,ZAR
*XDIM_MEMBERSET ENTITY = BAS(LE_GDDHP)
*XDIM_MEMBERSET FLOW = F99
*XDIM_MEMBERSET ICACCOUNT = 103000,103020,110270,201000,201010,205020,A103000,A103001,A110451,L201000,L201001,L205491
*XDIM_MEMBERSET ICAUDITID = DEBIT1,CREDIT1,DEBIT2,CREDIT2
*XDIM_MEMBERSET INTERCO = <ALL>
*XDIM_MEMBERSET PCENTRE = %PCENTRE_SET%
*XDIM_MEMBERSET TIME = %TIME_SET%

*INCLUDE VADIM_APC_INC.LGF

Here is the code for VADIM_APC_INC.LGF

*WHEN FLOW
*IS *
*REC(FACTOR=1, FLOW="PL99",PCENTRE = ENTITY.COUNTRY)
*ENDWHEN

*COMMIT

I will rerun with a reduced / limited %PCENTRE_SET% and add the results in the next comment.

Kind Regards

Nick

0

Sorry but I am lost on what you are doing:

I can see RUNLOGIC log with:

*START_BADI RUNLOGIC_PH
QUERY = OFF
WRITE = ON
APPSET = DD_BPC_IFRS
APP = ICMatching
DEBUG = ON
VALIDATION = ON
LOGIC = VADIM_APC.LGF
...

and you post:

Here is the code for VADIM_APC.LGF

*XDIM_MEMBERSET CATEGORY = %CATEGORY_SET%
*XDIM_MEMBERSET CURRENCY = USD,ZAR
*XDIM_MEMBERSET ENTITY = BAS(LE_GDDHP)
*XDIM_MEMBERSET FLOW = F99
*XDIM_MEMBERSET ICACCOUNT = 103000,103020,110270,201000,201010,205020,A103000,A103001,A110451,L201000,L201001,L205491
*XDIM_MEMBERSET ICAUDITID = DEBIT1,CREDIT1,DEBIT2,CREDIT2
*XDIM_MEMBERSET INTERCO = <ALL>
*XDIM_MEMBERSET PCENTRE = %PCENTRE_SET%
*XDIM_MEMBERSET TIME = %TIME_SET%

*INCLUDE VADIM_APC_INC.LGF

What is the reason????

In this case the code has to be:

LOGIC = VADIM_APC_INC.LGF
0
Former Member

Hi Vadim,

Perhaps I got confused with your earlier comment with the *INCLUDE in it. (Which did throw me a bit).

Let's try again ;-)

So you want two things for logging / tracing purposes, right?

  1. Scope defined in the calling program and just a "*WHEN FLOW *IS * ... etc ..." in the called program.
  2. No scope defined in the calling program and all the scope and the *WHEN in the called program. (No need for any *INCLUDE)?

Do I have this right?

Thanks

Nick

0

1. Scope is defined in the calling program with RUNLOGIC_PH and just a "*WHEN FLOW *IS * ... etc ..." in the called program (VADIM_APC_INC.LGF).

2. Direct script run with the script defining the scope VADIM_APC.LGF and include of the same script as in step 1 (VADIM_APC_INC.LGF).

0
Former Member

Hi Vadim.

Let me try an explain where I am at.

Running the code from the RUNLOGIC_PH and then using the VADIM_APC_INC.

  • When I restrict the Profit Centre (in UJKT) to PC_ISDV then the "correct" answer appears
  • When I have the Profit Centre to <ALL> then the "incorrect" answer appears.

When I run the code from ICMatching, as you have mentioned, no records are written. Weird.

I am not too much worried about the last bit (running from ICMatching), as that's not how I want to run it anyway. I am more concerned that limiting the calling the code (RUNLOGIC_PH) with a specified PCENTRE brings back the "correct" answer and using <ALL> doesn't.

All the different permutations of logging / screengrabs is going to get very complex to try and put here. Let's hope what I have got is sufficient.

These are the runs from the Consolidation model with the various PC_ISDV and <ALL> runs

vadim-pc-all.jpg

vadim-pc-isdv.jpg

This is the log from the RUNLOGIC_PH with the PCENTRE=PC_ISDV

vadim-pc-isdv-log-from-consolidation.txt

This is the UJKT from the IC_Matching run

vadim-from-ic-matching-no-records.jpg

This is the logfile from the IC_Matching run (no records)

vadim-pc-isdv-log-from-icmatching.txt

Like I said, I am not too much worried about the "no records" from the ICMatching (I might have done something wrong).

What is odd is the RUNLOGIC_PH using PC_ISDV (correct answer) and <ALL> incorrect answer.

As I mentioned, the current workaround is the *FOR ... *NEXT

I hope this has helped to explain. I know it's a bit tricky to line it all up and make it as simple to explain as possible.

Kind Regards

Nick

0
Former Member

Hi Vadim,

Thanks! That (the base members of Dimension PCENTRE) seems to have done the trick! Awesome!

(I am not really sure why that's different to <ALL>, but that's going to take me forever to figure out).

Much appreciated!

Kind Regards

Nick

(Now just I need to figure out where to mark your response as the answer (and add to your points?). I much preferred the old site).

0

Now it's an answer and you can mark it as accepted!

1