Reg:MDX in Script Logic

Hi Experts,
I have a scenerio is that i have to collect selected basemembers and store in a variable and use that one in allocation.
Can anyone give me idea how to use MDX in grouping all members to a variable
Some thing like this.
*SELECT(%NOPLAN%,"[ID]","PROFIT_CTR","[ DONTPLAN = 'Y']" )
*FOR %NOPLAN1% = %NOPLAN%
[#MEMBERS] = %NOPLAN1%
*NEXT
Is there any variable concept in nw 7.5
i need all the members to be present in #members and i can use it in allocation.
Regards
Vinoth

Hi nilanjan,
                  Thanks for you reply .
                  My scenerio is a bit more complex,which i explained above is a small part .
                 The exact scenerio what i am trying to achive is that the allocation is done by Profit center groups individually.
                 They maintain some profit center property as DONTPLAN so that they are not needed for planning.
                so in the datamanager package they will select on top hier node for their individual profit center group and run.
                I have to get all the base memeres of the particular group and omit all the profit centers which has 'Y' in the profit center property DONTPLAN. Collect all the members and use only those members in allocation.
               i tried script code but i cant any clue of achieving this scenerio so i am trying to use MDX or any other way..
Regards
Vinoth

Similar Messages

Reg: Selectively Commenting Script Logic

Dear Experts,
I have a situation where in the Default Logic file comprises of Allocation Logic and Currency Translation Logic, and it works fine.
But for just one of my reports I have created an Data manager package for Allocation as it uses a different Dimension (Datasource dim instead of Product dim) when compared with the others (which are allocated based on Product).
The allocation logic works fine if and only if i comment the Allocation Logic present in the Default logic file but this will prohibit the allocation in the remaining reports.
Is there a way i can restrict the Allocation present in default logic and run only the manually triggered allocation without commenting in default logic so that it works fine for other reports as well.
Please advice.
Rgds,
Rizwan

I'm a little confused by your use of the word "reports." In BPC, I use the word "report" to mean something very simple -- a view into the data that is stored in the database.
Any script logic that calculates values (for example, allocations or currency conversion) will post its results to the database. Once those results are in the database, any and all reports which point to those values will retrieve the same result. So it's not possible to have one report retrieve values that are impacted by a data manager package, while other reports ignore that data manager package.
(However, as soon as I say that, I'll disagree with myself and say, yes of course it's possible -- in the most extreme case, create separate applications for the different business requirements. Or more frequently, use different members in datasrc or some other dimension to isolate the different values.)
To solve your problem, you need to approach it in terms of the cube (OLAP) data structure, and then your final reports need to either include or exclude, as appropriate, the allocation results. I would recommend you not think in terms of making the code branch in different directions (based on some or other reports). Instead, the logic runs all the time, and the question should be, where do the logic results post to?
For a very simple example, the currency conversion results always post to USD, EUR, etc. members of the RptCurrency dimension. This logic will never change the original (LC) values.
For your allocation logic, the same approach can apply. Obviously you wouldn't use the RptCurrency dimension to differentiate the results, but perhaps a datasrc dimension (or something similar) can achieve the result you need.
For instance think of a datasrc dimension which looks like this, one parent and two children:
AllDatasrc
-- InputData
-- AllocResult
The allocation logic only considers data in InputData, and posts the results to AllocResult. The other reports (which should not reflect the allocation) are focused on InputData, while the allocation report looks at AllDatasrc, or possibly even all 3 members to show the "before and after"
Once you make that change, you need to decide how it impacts everything else in the application. The currency conversion logic, perhaps should now include both InputData and AllocResult. That's up to you to decide.

Script Logic error when trying to Calculate P*Q

I am new to MDX and Script Logic and need some help.
I am trying to calculate Price * Qty. Prices are stored in an Account called Unit_Price, and Qtys are stored in Accounts as well. We have a Service property called "DRIVER" that points to the Account that holds the Q for that Service, but I can't seem to refer to it in Script Logic. So, for each Service, I want to find the corresponding Unit_Price, lookup the Driver for that service and then use that to find the corresponding Quantity. However, I'm having trouble with the portion that points to the Quantity.
Can someone please help?
This is the error that I get when I try to run it in the Logic Debugger:
"Warning no. -2147467259 reading cell 0; The hierarchy '[SERVICE.DRIVER]' was not found in the cube when the string, [ACCOUNT].[SERVICE.DRIVER],was parsed. "
Here is my Script Logic:
*MEMBERSET(%BILL_ENTITY%,FILTER(DESCENDANTS([ENTITY].[547],99,LEAVES), [ENTITY].CurrentMember.Properties("BILLED_ENTITY")="X") )
*XDIM_MEMBERSET ENTITY = %BILL_ENTITY%
*MEMBERSET(%PQ_SERVICE%,FILTER(DESCENDANTS([SERVICE].[TOTAL_SERVICE],99,LEAVES), [SERVICE].CurrentMember.Properties("ALLOC_METHOD")<>"") )
*XDIM_MEMBERSET SERVICE=%PQ_SERVICE%
*XDIM_MEMBERSET CATEGORY = %CATEGORY_SET%
*XDIM_MEMBERSET TIME = %TIME_SET%
*XDIM_MEMBERSET DATASRC = INPUT
*FOR SERVICE.ALLOC_METHOD = "PQ"
[ACCOUNT].[#16404ZZZ] = ( [ACCOUNT].[UNIT_PRICE], [TIME].currentmember) * ([ACCOUNT].[SERVICE.DRIVER], TIME].currentmember)
*NEXT
*COMMIT

1. completely uninstall all the nokia PC Suite products with this http://nds1.nokia.com/files/support/global/phones/software/Nokia_PC_Suite_Cleaner_7_1_1.exe, and also uninstall all OVI Suite products
2. reboot pc
3. download & Install a fresh copy of PC Suite
4. it will then have you download and install a new version of the software installer after you connect your e90
it should be fine after that. i had to do the same thing a while back.
re: no able to sync the calendar with ovi suite:
go to the Sync drop down and then select Sync Calendar.
hope that helps

Script Logic: Using a property in MDX *REC statement (BPC NW)

Hi,
Is it possible to use a Property in an MDX statement without using *LOOKUP() function? I have script successfully working but it takes 15 minutes to execute and would like to speed it up.
I understand that [DIMENSION].[MEMBER].Property is not valid syntax, and do not believe NW has any other functions to resolve the issue, except *LOOKUP which takes a long time.
Specific Example is below:
I have a piece of script that successfully splits JV Expense by customers. A Profit Share planning driver determines the percentage that each customer is entitled to. Typically this will be 100%, but could be 50% between two customers.
The PROFIT SHARE planning drivers records, and PARTNER_INCOME transactional records are below:
ACCOUNT
ENTITY
PARTNER
SIGNED DATA
PROFIT_SHARE
UK_001
PARTNER_A
0.5
PROFIT_SHARE
UK_001
PARTNER_B
0.5
PROFIT_SHARE
UK_002_PLANNING_DRIVERS
PARTNER_B
1.00
PARTNER_INCOME
UK_001
NO_PARTNER
$5,000
PARTNER_INCOME
UK_002
NO_PARTNER
$5,000
UK_001 has two partners that are each entitled to 50% of the $5,000 NET PROFIT.
For UK_002, one one single Partner is entitled to 100% of the $5,000 NET PROFIT.
Using script logic, you can scope the Profit Share account (PROFIT_SHARE) - , and use a *REC statement to multiply this by the driver. It would look like:
*XDIM_MEMBERSET ACCOUNT = PROFIT_SHARE
*WHEN ACCOUNT
IS *
*REC (EXPRESSION = %VALUE% * ([ACCOUNT].[PROFIT_SHARE],[PARTNER].[NO_PARTNER]), ACCOUNT = PARTNER_PROFIT_SHARE)
*ENDWHEN
This wouldn't be a problem if the Planning Driver is always stored on the same Entity that the Income is stored on, but for UK_002, the planning driver is stored on another Entity - which is stored in a the PLAN_DRIVER_REF property of the entity. It should use UK_002_PLAN_DRIVERS
ID (Entity)
PLAN_DRIVER_REF
UK_001
UK_002
UK_002_PLAN_DRIVERS
UK_002_PLANNING_DRIVERS
In this scenario, we need to switch out the Entity used in the MDX, however I do not believe you can use a property in MDX - can anyone confirm?
I have currently implemented the *LOOKUP functionality to loop through, changing each *LOOKUP partner for each loop.
Lookup:
*LOOKUP PLANNING_JV_US
*FOR %LOOP_ASLS% = %ASL_LOOKUP_LOOP_VARIABLE%
*DIM LOOK_%LOOP_PARTNERS%:ACCOUNT = "PROFIT_SHARE"
*DIM LOOK_%LOOP_PARTNERS%:PARTNER= %LOOP_PARTNERS%
*NEXT
*DIM ENTITY = ENTITY.PLAN_DRIVER_REF                   //   Use PLAN_DRIVER_REF Property of Entity
*ENDLOOKUP
Scope and *REC:
*XDIM_MEMBERSET ACCOUNT = PROFIT_SHARE
*WHEN ACCOUNT
IS *
*FOR %LOOP_PARTNERS% = %PARTNER_LOOKUP_LOOP_VARIABLE%      // 1000 Partners
*REC(EXPRESSION = %VALUE% * LOOKUP(LOOK_%LOOP_PARTNERS%), PARTNER= %LOOP_PARTNERS%, ACCOUNT = TCOJVSHAR_CALC, AUDIT_ID = PP_EXPENSE_BY_PARTNER)
*NEXT
*ENDWHEN
The problem with the above, is that because the Lookup is being generated for every single Partner, there are significant numbers of loops.
Does anyone know of another way this can be implemented in Script Logic? Otherwise we'll need to explore BAdI route.
Thanks,
Nick

Hi Nick,
Use property in LOOKUP - will dramatically speed up the calculation without FOR/NEXT.
Vadim

Script Logic choice SQL or MDX in NW release?

Hi experts,
I have encountered some opposite arguments in forum. Please can you clarify NW release script logic choice should be as MS release?
In [Script Logic BPC MS (SQL) vs. NW (ABAP); Tim Klem states
- "Write the logic using BPC SQL script logic syntax (not MDX) for performance reasons" but this opinion based on MS version. How about NW release is it really smarter to select SQL Script rather than MDX.
There is another statement in [Re: BPC 7 NW; Deppak mentions that:
- "In BPC 5.1 the script formula approach suggests to use SQL based logic instead of MDX.
Whereas in Teched,08, I learnt that MDX & ABAP (using BADIs) would be used for it. Thats why I am slightly confused...."
But second statement is far beyond NW relase date and I am sure this is not true but I would like you to confirm that.
If you were a project responsible and want that all scripts will be held in one language, what would you choose??
Thanks in advance,
ergin ozturk

Hi Ergin,
I can understand your approach not to use ABAP hence you miss the skills witin your project team.
However, you (or you client) has chosen the NetWeaver version for whatever reason. I'm sure a thorough decisions process has lead to this decision. In choosing the NetWeaver version with SAP BI you will sooner or later come to the point that you will have to use ABAP if you like it or not. Especially when you start using further capabilities within NetWeaver and the BI solutions. So from my point of view ABAP knowledge is an essential skill you need in a project based on SAP NetWeaver anyway.
Additionally I heared some statements that MDX is causing some performance issues on the NetWeaver version. This may have been fixed in the meantime with some SPs.
As the SQL within the NetWeaver verison does not have the full functionality than it has in MS Version SQL is not an option for me.
I do also not see the cost impact hence someone need to do the support anyway. In case of MDX you need an MDX developer, in case of ABAP and ABAP developer. Or a technical BPC consultant able to do the development (which I would recommend you should have in your project team anyway).
So coming back to your original question, I would recommend to do as much as possible using ABAP BADIs.
Cheers,
Steffen

Reg: Script Logic - REC Statement Variable usage

hi friends
Pl find enclosed the following code:
*WHEN TIME
*IS TMVL(-1,2011.04)
*WHEN ACCOUNT
*IS "EXP01"
*REC(EXPRESSION = [TIME].[2011.04]-%VALUE%,TIME = 2011.04,ACCOUNT = EXP01A)
*ENDWHEN
*ENDWHEN
The above code is working fine and result is extracted but i have hardcoded , ACCOUNT=EXP01A;
My Query is follows:
I have used
*WHEN ACCOUNT
*IS "EXP01"
In REC i want to use concatenation of "A" To account like EXP01&"A"
i know accunt & i want to concatenate "A" and use in REC statement like assign to variable
var1="EXP01" & "A" and use var1 in REC
*REC(EXPRESSION = [TIME].[2011.04]-%VALUE%,TIME = 2011.04,ACCOUNT = var1)
i am not sure the syntax (Whether we need to put in strings)
Also if EXP02 then var1="EXP02"&"A" and so on
In fact i want to make this for all members in Account Dimenstion as generalised.
Pl. verify and suggest best possibility
Thanx & Rgds
Srinath

Hi Krishna
*XDIM_MEMBERSET ACCOUNT AS %ACC% = EXP01
*WHEN ACCOUNT
*IS %ACC%
REC(EXPRESSION = %VALUE%2,TIME = 2011.04,ACCOUNT = %ACC%A)
*ENDWHEN
Is it required to add EXP01A as below?
XDIM_MEMBERSET ACCOUNT AS %ACC% = EXP01, EXP01A
Also In Generalized code you have mentioned:
Instead of Hard Coding EXP01, EXP02 can i have hierarchy of all EXP , so that if any new account added in dimension, there will be no change in script logic. Pl. can you share how to use the same.
If above code needs to be generalised, *FOR *NEXT can be used .
*XDIM_MEMBERSET ACCOUNT AS %ACC_LIST% = EXP01,EXP02,EXP03,EXP04
*FOR %ACC_MBR% = %ACC_LIST%
*WHEN ACCOUNT
*IS %ACC_MBR%
REC(EXPRESSION = %VALUE%2,TIME = 2011.04,ACCOUNT = %ACC_MBR%A)
*ENDWHEN
*NEXT
Rgds
Srinath

Custom Measure in Script logic

Hi,
We have a custom measure created which is more or less the same as the YTD, but it starts not at the beginning of the year, but instead it starts at a given month.
The measure creation was ok and we can use it perfectly well in reports and input shedules and the cumulation of data is ok.
However, if we want to use this measure in a script logic it does not work.
- Validating the script in the admin console goes fine
- Executing the script gives the error:
- Root element is missing
- validating in UJKT gives the erro:
- UJK_VALIDATION_EXCEPTION:Invalid Measures value: "T_232"
The script we try to use is below. If we change the LTD (our custom measure) by YTD it works perfectly fine:
*XDIM_MEMBERSET BUILDSTATE=NABS
*XDIM_MEMBERSET BUSAREA=V1
*XDIM_MEMBERSET CATEGORY=FCSTCUR
*XDIM_MEMBERSET DATASRC=INPUT
*XDIM_MEMBERSET ENTITY=201
*XDIM_MEMBERSET MARKSEGM=NAMS
*XDIM_MEMBERSET ORIGIN=OBOOK
*XDIM_MEMBERSET PRODUCT=ELEVATORS
*XDIM_MEMBERSET PROFCENT=201251
*XDIM_MEMBERSET RPTCURRENCY=LC
*XDIM_MEMBERSET SALESORG=SO_201
*XDIM_MEMBERSET TECHPLATF=NATP
*XDIM_MEMBERSET TIME=2010.OCT
*XDIM_MEMBERSET TYPE=T_PLAN0
*XDIM_MEMBERSET NEBACCOUNT =BAS(T_232)
*XDIM_MEMBERSET MEASURES=PERIODIC
[NEBACCOUNT].[#A232]=([MEASURES].[LTD],[NEBACCOUNT].[T_232])
*COMMIT
Thanks for any input on this. We want to avoid going via a BADI!
Kind regards,
Christophe Posson

Hi Christophe,
I'm in a similar position to you and wish to avoid use of a BAdI if we can - despite the MDX parser engine being pretty pathetic at handling YTD or custom measures.
Did you get a resolution to this? If so, could you please share it with everyone?
As much information as possible would be apprecaited. Our next move is to contact SAP for confirmation that there is no possibility of using custom measures in Script Logic.
Many thanks,
Nick

Handling Ranges in Script Logic

Hi Experts
Is it possible to put logic to check a range of values in Script Logic.
For example, if I need to check if the value in Quantity Account is between 200 and 800, then only some Quantity Discount is calculated against this.
What command should one use for this
Any input would be very helpful.
Regards
Krishnendu

Hi Krishnendu,
I believe that you can use MDX or a BADI to do this. Using MDX, for example, the following should write 100 to the QUANT_DISC account in the event that QUANTITY is greater than 200 and less than 800:
[ACCOUNT].[QUANT_DISC] = IFF(([ACCOUNT].[QUANTITY]) > 200,IIF(([ACCOUNT].[QUANTITY])<800,100,0),0)
This is just example MDX code - you'll have to adapt and test yourself. I suggest using the script logic tester to speed the process. Performance may be less than ideal, and you can certainly implement this in a BADI in that event.
It would be nice if it were possible to do this using WHEN/IS statements in script logic, but at present conditional logic based on measure values is not supported in that context.
Ethan

Syntax in script logic

Hi Friends,
I have input schedule in below format.
Product   Rate/2011.INP Packing/2011.INP QTY/2011.APR AMOUNT/2011.APR QTY/2011.MAY AMOUNT/2011.MAY
PM         3                 3              3               27            4         36
PN        5            2          2          20     3 30
Here Amount= Rate*Packing*QTY. Pls correct below script logic and make it generic for all months.
*XDIMMEMBERSET TIME=2011.APR,2011.MAY,2011.INP
*XDIMMEMBERSET ACCT=QTY,RATE,PACK,AMOUNT
*WHEN ACCT
*IS QTY
*WHEN TIME
*IS 2011.APR,2011.MAY,2011.INP
*REC(EXPRESSION=%VALUE% * ([ACCT].[RATE],[TIME].[2011.INP])
                         * ([ACCT].[PACK],[TIME].[2011.INP]),
                             [ACCT]=AMOUNT,[TIME].[2011.APR])
*ENDWHEN
*ENDWHEN
*COMMIT
Thanks,
Naresh

Hi,
You can simply write this using MDX formula,
[ACCT].[#AMOUNT]=[ACCT].[PACK]*([ACCT].[RATE],[TIME].[2011.INP])*([ACCT].[QTY],[TIME].[2011.INP])
Run this code with required months from DM package it gets executed for defined time periods.
Hope this helps,
Regards,
G.Vijaya Kumar

Math power function in script logic

Hello all!
Can anybody help me how I can do math "power" function in BPC 5.1 Script Logic?
Thanks

Let's say you have a source account FOO and you want to calculate FOO to the 5th power, posting the result to FOOFIVE.
In BPC SQL scripting, there are no mathematical functions to play with (powers, roots, sine, cosine, etc.) except for add, subtract, multiply and divide -- plus you can round results in your Factor or Expression. So that means, we must use multiplication.
You could certainly do this using a bunch of intermediate accounts, one each for foo squared, foo cubed, foo to the 4th, and foo to the 5th. That would require *GO in between each *WHEN/REC block, and could be slow.
I haven't tried this, but I think this should work, all in one statement:
*XDIM_ACCOUNT = FOO
*WHEN *
*IS *
REC(Factor=GET(Account="FOO")GET(Account="FOO")GET(Account="FOO")GET(Account="FOO")*GET(Account="FOO"),Account=FOOFIVE)
*ENDWHEN
If you want FOO to the 50th power, copy & paste.
If you want square root of FOO, that could be a real challenge. I think to use straight BPC SQL logic it wouldn't be possible. I would probably write a stored procedure using SQL's SQRT(), and call that from the BPC logic file. Likewise for any other geometric functions, complex algebra, etc.
There also may be a way to calculate powers in MDX -- that's more mathematically straightforward -- but as a BPC on MS person, I really never ever use MDX due to performance.
Regards,
Tim

Referring to SQL comment table in Script Logic

Dear all,
If i have the following combination of dimensions, i.e. "DimA, DimB and DimC", and they will point to a comment in the comment table in SQL, how do i grab the [Comment] from the comment table to be used in my script logic.
I was adviced to use *select statement, but i can't seem to get it to work.
Any help is much appreciated.
Cheers,
Lip Chean

Hi,
*Select allows you to retrieve a list of elements from a dimension or table and save it in a user-defined variable for later use anywhere else in the logic.
For example, with this instruction:
*SELECT(%REPORTING_CURRENCIES%, u201CIDu201D, u201CCURRENCYu201D, u201C[GROUP] = 'REP'u201D)
In this case, you retrieve the ID of all members in the CURRENCY dimension where the property GROUP has the value REP. Running this example fills the variable %REPORTING_CURRENCIES% with the list of reporting currencies defined in the current application.
Important information
xxx The SELECT statement generates a SQL query, and NOT an MDX query. This implies that it can be executed against any SQL table existing in the application set database, and not just against the properties of a dimension in the cube. The prefix "mbr" is automatically added to any name entered in the table parameter. Otherwise, the name of the table is taken as is. If
you want to select a list of elements from a dimension using an MDX query use *MEMBERSET statement.
xxx In case any parameter contains embedded commas the entire parameter must be enclosed in an extra set of double quotes.
xxx The *SELECT statement is executed at the time the logic is validated, and the expanded result is written in the LGX file. This means that if the related dimension is modified, it may be necessary to re-validate the logic.
xxx Statements returning no members do not necessarily cause the validation of the logic to fail. In this case a warning is entered in the validation log.
xxx These instructions are not specific to a given logic section, but they can be written once anywhere in the logic and used across multiple commit sections.
Hope this helps.
Badrish

BPC Script Logic - XDIM_FILTER results in error

I am writing a Script Logic in BPC and I need it to include all records where the DESTINATION dimension member has the Dimension Property of PLANDEST = "Y"
This approach works:
*SELECT(%DestinationMbrs%,"[ID]","Destination","[PlanDest] = 'Y'")
*XDIM_MEMBERSET DESTINATION = %DestinationMbrs%
This approach does not work:
*XDIM_MEMBERSET DESTINATION = <ALL>
*XDIM_FILTER DESTINATION=[DESTINATION].PROPERTIES("PlanDest")="Y"
It results in the error message at runtime:
Error in step 1 of QueryCubeAndDebug: -2147467259 Query (1,156) The PLANDEST dimension attribute was not found.
The reason I would like to use the second approach is that the first approach relies on the SELECT statement. The documentation on the SELECT statement says:
The *SELECT statement is executed at the time the logic is validated, and the expanded result is
written in the LGX file. This means that if the related dimension is modified, it may be necessary
to re-validate the rules.
So if I change the DESTINATION dimension members PLANDEST flags, I need to re-validate the script logic. That is a maintenance nightmare and a problem waiting to happen.
How do I solve this so that the dimension attribute is evaluated at runtime, not at logic validation time?

As Yuan Said, if you are using MDX logic and want to use property, you should check Inapp at the 'manage property' menu of admin console.
Usually, InApp sholud not be selected for better performance of MDX query. (SAP recommendation)
But. Here are two cases that you should select.
1. MDX logic in the logic script.
2. Dimension formula.
I hope it will make clear for all.
James Lim

ADDITION USING SCRIPT LOGIC

Hi All,
Under 'INCOME' i have 3 accounts.
account1
account2
account3
i want to add the value of these 3 account then i want to multiply with 3
the result i want to display in "account4"
What is the required script logic for this?
Regards,
Phanikumar.

Hi Phani Kumar,
BPC 7.0 NW doesnt support GET, so you cannot have the script as
*WHEN ACCOUNT
*IS "ACCOUNT1"
*REC(EXPRESSION=(%VALUE% + GET(ACCOUNT="ACCOUNT2") + GET(ACCOUNT="ACCOUNT3"),ACCOUNT="ACCOUNT4")
*ENDWHEN
Instead you can modify the script to
*WHEN ACCOUNT
*IS "ACCOUNT1","ACCOUNT2","ACCOUNT3"
*REC(FACTOR = 3, ACCOUNT="ACCOUNT4")
*ENDWHEN
If you want to go with MDX, then you can use as suggested earlier
[ACCOUNT].[#account4]=([ACCOUNT].[account1]+[ACCOUNT].[account2]+[ACCOUNT].[account3])*3
Hope this helps.

MDX in DIM Logic

I heard that using MDX is not ok in Dim Logic...could someone please explain why that is? Thanks.

I'm speaking here regarding BPC on MS in particular; I'm not sure if the exact same situation exists on NW.
The other concern with dimension logic (as opposed to script logic) is that the formula must be evaluated whenever the user queries for that calculated member (i.e., runs the report). Each subsequent time the member is queried, it must be re-calculated. The result is only stored in the OLAP memory, which may be cleared for other purposes by Analysis Services, depending on many different factors outside your control.
Script logic, on the other hand, runs the calculation once ( when the data first changes, or when the batch logic command is given), and stores the result to the database. This normally makes data retrieval much faster, and allows you to schedule complex or long calculations during off-peak times.
Within script logic, there's still an option to use MDX syntax, but the performance is very poor compared to other scripting options.

Getting an error message while running FX script logic

We are getting the following error message, while running the FX script logic - RUN_LOGIC:MDX statement error:"Value (Entity value) for characteristic /CPMB/U8D5FIT". Any help is truly appreciated. We are using the standard FX logic scrip *RUN_PROGRAM CURR_CONVERSION

Hi,
Hope all the required currency configuration settings are followed in Entity, Input currency, Category, Account correctly. Also reporting currency indicates the right reporting currency with the 'Reporting' propert set to 'Y' to the currency that you want to report in.
For the period that you are running the currency trans, could you also maintain rates for the reporting currency as 1.
Check your rate data. And please post your currency conversion script here.
Thanks,
Sreeni

Reg:MDX in Script Logic

Similar Messages

Maybe you are looking for