Simple Script Logic

Hi all,
Is it possible execute a script logic when i execute the import package? i added in the DEFAULT.LGF the code:
WHEN *
is *
REC(Expression=get(account="ccp0001")*get(account="ccq0001"), account="ccv0001")
endwhen
commit
The idea is calculate value = price * quantity and put in a new rec when i load the data.
value =ccv0001
price = ccp0001
quantity = ccq0001
i dont know whats wrong but thats calculate nothing.

Unfortunately you really don't exactly know if a scope is exactly right, unless you work out the tuples specific to each calculation and the define independent script calcs for each tuple set. A fancy way of saying, breaking down the calculation to each basic account by all the other dimension members that are to get together in a calculation.
There is a way of testing the script starting in version 7.0SP4 ithink, called the logic debugger. This process actually has you define some form of scope in order to test the calculations as a dry run, but not run based on an import, rather based on your request to run.
There are also various rules used during the logic calculation process, such as the engine will query all Accounts for values in the DB that match your inbound data set, or scope. Category, Time and Entity play an critical role in any caluclation, and the processing of values. And remember that logic that works in default may not look the same as when data is loaded, based onthe sets of data that are used during the passing of inbound detals to the engine for the logic processing.
hope this helps.

Similar Messages

Simple Script Logic Help - Unit Conversion

Hello Gurus, I am trying to prove some capability of BPC and need to write a Logic for doing it:
The scenario is like this:
I have a cube that will host Sales forecast information :
   Product: A
   Month:     MM01
   Unit :       X
   Signed Data :10
I have a property in the Product y that contains the conversion rate for converting values to another unit. In this case 0.5
What I need is :
1. Read Product Dimension and get the Conversion Rate.
2. Multiply Signed Data by COnversion Rate-
3. Generate a new record :
   Product: A
   Month:     MM01
   Unit :       Z
   Signed Data :(10 * Conversion Rate )
Could you provide a Sample code for this?
Thanks in Advance.
Sergio

Try:
*WHEN *
*IS *
REC(EXPRESSION=%VALUE%FLD(PRODUCT.Y), UNIT="Z")
*ENDWHEN
*COMMIT
You will have to make sure the correct records have been scoped.
Thanks,
John

Greater Than Function in Script Logic File

BPC Experts,
I've got a pretty simple script logic file to calculate salary amounts, overtime, etc. The purpose of this logic is for forecasting. I have two referenced dimensions, TIME and SCENARIO, where TIME.MONTHNUM is equal to its relative month number (eg: Jan monthnum = 1), and SCENARIO.CURRMONTH is equal to the relative amount of actual months data, (eg Jan currmonth = 0, Feb = 1) because if you are completing a February forecast, you have one month of actual.
The ACTUAL scenario is never touched, but after a month closes, we copy the ACTUAL data to, for example, FEB_FCST. So, after January closes, its actuals are copied to the FEB_FCST scenario so we can complete an actual/forecast (one month actual, 11 months forecast).
Currently, the default logic skips anything in the ACTUAL scenario, by stating "*WHEN SCENARIO, *IS <> "ACTUAL" yada yada yada.
However, when the default logic runs on the forecast scenarios, it takes the same inputs from the months that are copied over from the ACTUAL scenario and adds to the original amount, essentially doubling the value--ultimately causing an incorrect actuals number in the forecast scenario.
My script right now looks like this:
*XDIM_MEMBERSET DATASRC=INPUT
*XDIM_MEMBERSET PRODUCT=NO_PRODUCT
*XDIM_MEMBERSET SHIFT=NO_SHIFTS
*XDIM_MEMBERSET MEASURES=PERIODIC
*WHEN SCENARIO
*IS <> "ACTUAL"
     *WHEN TIME.MONTHNUM
     *IS > SCENARIO.CURRENTMNTH
          *WHEN ACCOUNT
          *IS "SALARIED_MANPOWER"
               *REC(EXPRESSION=((([ACCOUNT].[SALARIED_AVG_WAGE] * (1 + [ACCOUNT].[SALARY_TIMEAHALF]))* [ACCOUNT].[SALARIED_MANPOWER])),ACCOUNT="01100")
          *ENDWHEN
*ENDWHEN
*ENDWHEN
*COMMIT
When it hits line 9 (*IS > SCENARIO.CURRENTMNTH) during validation, it errors. How can I use a "greater than" function to dictate whether or not a given scenario should run default logic on a specific month?
If not, is there a different/better way to do it?
Thank you!
ABF

Hi Alex
Take this sample logic, check the properties in your Time dimension to trouble shoot your issue.
*SELECT(%CAT_VAR%, "ID", CATEGORY, ID= PLAN_APRIL)
*XDIM_MEMBERSET CATEGORY = ACTUAL, PLAN, %CAT_VAR%
*SELECT(%CATMTH%, "STARTMTH", CATEGORY, ID= %CAT_VAR%)
*SELECT(%ACT_PERIOD%, "ID", TIME, MONTHNUM < %CATMTH% AND LEVEL = MONTH AND YEAR = 2010)
*SELECT(%PLAN_PERIOD%, "ID", TIME, MONTHNUM >= %CATMTH% AND LEVEL = MONTH AND YEAR = 2010)
*XDIM_MEMBERSET TIME= %ACT_PERIOD%
*XDIM_MEMBERSET CATEGORY=ACTUAL
*WHEN CATEGORY
*IS ACTUAL
*REC(EXPRESSION=%VALUE%, CATEGORY = %CAT_VAR%)
*ENDWHEN
*XDIM_MEMBERSET TIME= %PLAN_PERIOD%
*XDIM_MEMBERSET CATEGORY=PLAN
*WHEN CATEGORY
*IS PLAN
*REC(EXPRESSION=%VALUE%, CATEGORY = %CAT_VAR%)
*ENDWHEN
Thanks

Package with script logic CANCELLED

Hi everybody,
I am trying to implement a very simple script logic that removes negative values from the Units account.
*XDIM_MEMBERSET C_CATEGORY=%C_CATEGORY_SET%
*XDIM_MEMBERSET TIEMPO=%TIEMPO_SET%
*XDIM_MEMBERSET MERCADO=%MERCADO_SET%
*XDIM_MEMBERSET ORG_VENTAS=%ORG_VENTAS_SET%
*XDIM_MEMBERSET CUSTOMER=BAS(TOTALCUSTOMERS)
*XDIM_MEMBERSET PRODUCT=BAS(00001)
*XDIM_MEMBERSET P_DATASRC=DRIVER
*XDIM_MEMBERSET ACCOUNT_SIM=Unit
*XDIM_MEMBERSET TIPO_CLIENTE=BAS(TOTAL_TOP)
[ACCOUNT_SIM].[#Unit]=IIF(([ACCOUNT_SIM].[Unit])*(-1)<0, 0, [ACCOUNT_SIM].[Unit])
*COMMIT
When I execute it with the Data Manager the result of the package is "Cancelled". I have one large dimension ("Customer" with more than 2000 elements) but there are not too many records in the database now. However, when I restrict the number of elements, the package works fine. It seems like a memory issue, I don't know... We are using SAP BPC NW 7.0 SP5
Any idea out there? Is our logic not 'optimized' for BPC?
Thanks a lot,
Mr. Albert Mas

Hi Albert,
I think you're running into a dimensionality limit. I believe this was fixed in SP06.
In any case, it's easy to fix. Just add
*XDIM_MAXMEMBERS CUSTOMER = 1
after your other *XDIM statements.
You should be able to up this number a fair amount, depending on the number of members in other dimensions. In the script logic evaluation, there is code that multiplies the number of members in your memberset in each dimension and then attempts to assign the result to an INT datatype. I don't remember the size of the INT, but if you look at the short dump in ST22 of the SAP GUI, you'll see the code.
Hopefully that helps.
Ethan

Use BADI or LGF script logic? Which is good in performance

Hello,
I have a situation wherein a choice is to be made among the "BADI" or "script logic" having DESTINATION_APP which is along with WHEN clause.
Below is the code in which WHEN clause is used:
Code Starts****
XDIM_MEMBERSET CATEGORY=FC_CUR
*DESTINATION_APP=GROSSMARGIN
*SKIP_DIM =WEEK
*ADD_DIM PLAN_PARTNER = PP_NA, RPTCURRENCY = LC
*WHEN CATEGORY
    *IS "FC_CUR"
              *REC(EXPRESSION=%VALUE%)
*ENDWHEN
*****Code Ends****
The business requirement could be changing as we are at initial stage, wherein i may have to incorporate some data mapping logic which can also be handled through scripts instead of using BADI.
The major concern is if BADI would be most prefferable over script logic having WHEN clause to acheive the optimal performance considering large no. of records that needs to be written to the target APPLICATION
from the source application?
OR
The script with WHEN statement is fine if the data mapping is pretty simple and would not have much impact on performance compared to using of BADI even if the records to be moved is huge.

If data mapping is simple you can opt for script logic . If requirement is complex then you can go for BADI . You can check this [How-to|http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/70187b3e-d5ce-2d10-d780-bb8b1a5b0bdc?QuickLink=index&overridelayout=true] 6 th page on performance considerations of BADI .
A well designed BADI implementation is faster than script logic

Use of prompted hierarchy's base members in Script Logic

Hello all,
I have a data manager package which prompts the user for a dimension called P_BUDGET_MODEL. The prompt is SELECT hence the user selects a hierarchy node on this dimension.
In the relevant Script Logic I have a variable %P_BUDGET_MODEL_SET%, which is automatically created by the system. I would like to run the logic for the basemembers of the hierarchy node.
Please note - the basemembers are not direct children of the selected hierarchy node (i.e. the selected node is the "grandparent" of the basemembers).
I tried the following simple logic command:
*XDIM_MEMBERSET P_BUDGET_MODEL = BAS(%P_BUDGET_MODEL_SET%)
It yielded a message that "Member BAS() does not exist".
I have also noticed the following thread:
[BPC 7.5 NW - HIER NODE in PROMPT using Formule in Package ?;
If I understood properly it is not relevant to my case because the hierarchy is more that 2 levels deep.
Any ideas?
TIA
Avihay

Hi,
As it seems after further investigation the problem is that I use "_" in the dimension names and variable names. This creates a problem to BPC in some cases.
For example here there is no problem:
*SELECT(%MODEL%,ID,P_BUDGET_MODEL,ID="%P_BUDGET_MODEL_SET%")
Here there is a problem hence the use of [ ]
*XDIM_MEMBERSET P_MONTH = BAS([%P_VERSION_SET%.YEAR].TOTAL)
Here there is not "_" so the code is fine:
*XDIM_MEMBERSET P_BUDGET_MODEL = BAS(%MODEL%)
Strange yet seems that this was the problem...
Avihay

From where i can run script logic file.

Dear All,
I am new to BPC.
I have a code for currency translation in my Script logic (Default.lgf).
From where i should run this file. Can any help me.
thanks a lot in advance,
Regards,
Satish.

Typically the Currency rates are stored in the "RATE" application. This application is what the script logic or Business rule will call during the conversion process. The rates are only stored by MONTH and by TYPE in a typical planning application. If you need more granular rate details, then you may need to make you time dimension by weeks or days, or add more "TYPES" that are assigned to ACCOUNTs in th ecorressponding account dimension.
But in a simple planning world, most companies will use a monthly rate, one for an AVG and one for END account types, enter this into the RATE application, and run the Defualt logic on submission of data to compile the FX value. Whne you wish to view the results, make certain that you select the correct REPORTING CURRENCY in the report. Many time users forget that data is "normally" entered to an ENTITY,, the ENTITY defines the currency it assumes data is entered, so the plan is loaded to the "LC" member, and converted to USD; or entered in LC, and converted to RS.
But the RATE application will store all the rates required and you may need to open the INPUT template in that application to load the data at the correct intersections.
Hope this helps.

Calculating sum in script logic

Dear all.
I am having a script which should be moving values from one parent account to another base account in default logic, but only if posted on certain other dimension, that is when not posted on a certain Brand in my brand dimension.
Sounds pretty much simple..
*WHEN CATEGORY
*IS ACTUAL
*WHEN BRAND
*IS <> B_2600
*WHEN ACCOUNT
*IS BAS(GROSS_PREORDER)
*REC(EXPRESSION=([ACCOUNT].[GROSS_PREORDER]) ,ACCOUNT=GROSS_PREORDER_NOST)
*ENDWHEN
*ENDWHEN
*ENDWHEN
So if any values are posted on a base member of "GROSS PREORDER"-account, then put it onto GROSS_PREODRE_NOST, but only if CATEGORY = ACTUAL and BRAND different from B_2600.
The above script works fine, as long as I only post one record at a time, but that's not realistic. The users necessarily need to be able to input data on all base members of GROSS_PREORDER and then send data.
When you post eg. on three separate accounts below GROSS_PREORDER the result is posted three times onto GROSS_PREORDER_NOST.
I cannot seem to find a good solution for this, but I don't think I'm the first facing this issue..?
Best regards
Mogens
PS. I am using BPC NW 7.5 SP05

Hi Nilanjan.
That works.
I don't really see why it should work compared to my first script, but isn't that just the irony of script logic..?
In order to not put every and all data into my sum account I modified
*WHEN ACCOUNT
*IS *
to
*WHEN ACCOUNT
*IS BAS(GROSS_PREORDER)
Thank you very much for your help..
Br.
Mogens

Dimension Formula versus Script Logic that runs on default

Hi Experts,
Which is better to use dimension formula or script logic that runs on default? We have a lot of dimension formulas and when noticed that it has a huge impact in the performance of our AppSet. When we try to remove them, the performance seems better. We we're thinking of transforming these dimension formulas into script logic which will run by default instead. Right now I'm hesitant with two things, 1.) Will there be improvement in performance if I all these formulas are run at default via script logic? 2.) The maintenance seems to be much more complex for the user if we use script logic.
Thanks,
Marvin

Hi Marvin,
Actually you pointed very well the advantage and disantavage regarding dimension formula.
Dimension formula are executed into run time which means that value are not calculated. Of course this will have an impact regarding performances.
Usually our recommendation is to use dimension formula just when yoiu have KPI's to calculate which will be very difficult to be implemented into SQL scrip logic or when you have very simple calculation like Account A = Account B+ Account C.
For other calculation we advice our customer to use script logic.
But attention:
Default formula should not become very heavy because you will arrive into other issue with performances.
When you will send data if default formula script will be heavy you will arrive into situation to wait may be minutes just to send one figure and of course this will be not acceptable for users.
So you have to use script logic but you have to run into batch mode (schedule package) that script logic.
Into default formula you have to keep just minimum (you have to calculate just figures which have importance for user imediat, real time).
Also you have to be aware that moving dimension formula into scrip logic actually your fact table will grow a lot because the number of records generated will be probably 3-4 times bigger than number of records from fact table with dimension formula.
Maintenance of script logic is more complex than dimension formula and you pointed very well this.
So it is a balance and I tried o provide you suggestions or best practice when you have to use dimesnion formula and you have to avoid dimension formula.
I hope this will help you to arrive to best combination for your application.
Kind Regards
Sorin Radulescu

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.

Probable Script Logic error

Hi,
I am trying to create a simple demo with the following business process:
sales unit * sales price = total sales
salesunit + inventory unit = produced unit
produced unit * labor per unit = total hours
for "sales unit x sales price = total sales", i have created a script logic called "sales.lgf" as follow:
*xdim_memberset account = salesunit,salesprice
*when account
*is salesunit
rec(account="totalsales",factor=-1(get(account="salesprice")))
*endwhen
*commit
for "salesunit + inventory unit = produced unit", i am using dimension logic of salesunit + inventory unit in the formula column of produced unit
for "produced unit x labor per unit = total hours", i have created another script logic called "production.lgf" as follow:
*xdim_memberset account = producedunit,laborperunit
*when account
*is producedunit
*rec(account="totalhrs",factor=(get(account="laborperunit")))
*endwhen
*commit
in my default.lgf, i have *include sales and *include production
The results are satisfactory for all of "totalsales" and "producedunit".
But for "totalhrs", it appears as if some results are correct for some but wrong for the others.
any idea on this?
cheers

Dimension formulas are evaluated in the cube, when you query that particular member on which you placed the formula. Aggregated members (parents) are pretty much the same story. (MSAS does some caching & pre-aggregation of things but don't get hung up on this; it's DB technical stuff.) The key point is, the result of a member formula isn't stored in the fact tables.
The big performance gains come from minimizing the number of unnecessary commits -- not so much by minimizing the # of members in your xdim_memberset.
In your first example, this still can be written in one commit. Think of the algebra in the second commit, and break down the components until you get to the source data that you have available before you start the calc.
*xdim_memberset account = salesunit,salesprice,inventoryunit, laborperunit,laborcostperhour
*when account
*is salesprice
*rec(account="totalsales",factor=-1*(get(account="salesunit")))
*is salesunit, inventoryunit
*rec(account="totalhrs",factor=-1*(get(account="laborperunit")))
// not exactly intuitive, but it should work
*rec(account="totallaborcost",factor=-1*(get(account="laborperunit")) * (get(account="laborcostperhr"))
*endwhen
*commit
I wouldn't go through the effort of doing this when you first start writing SQL logic, because it makes it very hard to follow, and debug. If the logic takes 15 seconds to run with 2 commits, and it is legible, that's fine. Only if you find your logic takes 5 minutes or 30 minutes to run, then it's worth getting into this kind of optimization.
It's also key to consider everything that you want to calculate in one batch, from start to finish. Sometimes by organizing things in certain orders, you can minimize the total number of commits, by expanding the source data region to include an extra 5% or 10 or 50% of records, beyond what you need in your calcs -- but this may be acceptable. The only real way to know is to test a few different approaches (on a reasonable set of production data, not dummy data in dev) and see which works better.

Automate excel circular references - script logic - BPC

Hi,
I need to automate in BPC the calculation of financial debt that contains excel circular references, so you have to enable the calculation Automatic iterations properly to work.
I would like to automate the process through a script logic.
I appreciate any help or suggestions.
Regards,
Fernando Chávez.

Dear Fernando Chávez,
I just want to give you simple suggestions because I don't know your case exactly. The script logic is similiar with SQL script. You could put your logic script in default.lgf or make new file .lgf through BPC Administration Console. If you put it in default.lgf, the SAP BPC will execute it when user sent values through BPC Excel. You also could run the script logic through Data Manager Packages, its runs depend on user execution.
If we are talking about circular and complex formulas in Ms.Excel, I suggest you put your calculation in another worksheet and send values through BPC Excel. Before you define a script logic, the number one is you should to consider performance because its really critical.
Kind Regards,
Wandi Sutandi

Question on script logic

Have a property for the category dimension, u201CFX_SOURCE_CATEGORYu201D. The values for this property is another category dimension member. For example FCST01_P_FR have property value as FCST01 and FCST02_P_FR have property value as FCST02 and so on.
Using a dynamic script logic, want to copy the data in FCST01 to FCST01_P_FR if I choose FCST01_P_R in the selection while running the script. Simiarly FCST02 to FCST02_P_FR if I choose FCST01_P_R in the selection while running the script.
Again the script should dynamic to get the data from category property value member and write to the category member that is chosen during the script run.
I tried the following scripts and it is not working
Script 1:
*WHEN RPTCURRENCY
*IS LC
*WHEN ACCOUNT
*IS BAS(EXPENSES)
*WHEN CATEGORY
*IS CATEGORY.FX_SOURCE_CATEGORY
     *REC(FACTOR=1)
     *ENDWHEN
*ENDWHEN
*ENDWHEN
*COMMIT
Script 2:
*WHEN RPTCURRENCY
*IS LC
*WHEN ACCOUNT
*IS BAS(EXPENSES)
     *REC(EXPRESSION = ([CATEGORY].[CATEGORY.FX_SOURCE_CATEGORY]))
     *ENDWHEN
*ENDWHEN
*ENDWHEN
*COMMIT
Edited by: Al Sathappan on Oct 11, 2011 9:03 PM
Edited by: Al Sathappan on Oct 11, 2011 9:04 PM
Edited by: Al Sathappan on Oct 11, 2011 9:04 PM
Edited by: Al Sathappan on Oct 11, 2011 9:07 PM

You have data in FCST01. It means that this member will appear in WHEN-ENWHEN loop. You have to define property of THIS member like "FX_TARGET_CATEGORY" and assign this property value FCST01_P_FR.
Then you will have simple REC:
*REC(EXPRESSION=%VALUE%, CATEGORY=[CATEGORY].[FX_TARGET_CATEGORY])

Error while executing a simple script....

Hi,
I am trying to run the following simple script in Oracle 8i:
UPDATE
vcad_ocorrencias
set tipo_situa_solic = 'E', desc_obs_atendente = 'ACERTO DE BASE -
18/10/2004'
where cod_solicitacao = 7
and tipo_situa_solic in ('N', 'P')
and cod_contrato_Inter not in ( 2247,2295,2296,2297,2278,2269,2168)
and dthora_geracao < '07/10/2004'
order by cod_contrato_inter;
And it is returning the following message error:
ERRO na linha 8:
ORA-00933: SQL command not properly ended
Well this script was made by a developer and now I have to run it in production environment...
Does someone know why it is failing?

Get rid of your 'order by statement'.
order by cod_contrato_inter;
Also make certain that the 'NLS_DATE_FORMAT' is set to 'DD/MM/YYYY' or change
and dthora_geracao < '07/10/2004'
to
and dthora_geracao < to_date('07/10/2004','DD/MM/YYYY')
UPDATE
vcad_ocorrencias
set tipo_situa_solic = 'E',
desc_obs_atendente = 'ACERTO DE BASE - 18/10/2004' -- not sure if it is a date column
where cod_solicitacao = 7
and tipo_situa_solic in ('N', 'P')
and cod_contrato_Inter not in ( 2247,2295,2296,2297,2278,2269,2168)
and dthora_geracao < to_date('07/10/2004','DD/MM/YYYY')

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

Simple Script Logic

Similar Messages

Maybe you are looking for