Complex Script logic

Hello
I have a comple script logic and I know there are some errors with it. How can I step through line by line / debug that logic to make sure / fix that issues ?
Similarly how do I step through line by line / debug logic in Script / Stroed Procedures / Transformation files / conversion Files etc..
Thanks for your help
BI

Hi BI,
hmm i guess there is no tools to debug line by line is SAP BPC.. guys is there any third party software that can do this??
Thanks, hope helps

Similar Messages

Help required: Splitting up complex script logic via *LOGIC_BY

Hello experts,
I have a very long and complex logic which I am trying to split up into different sections. I am using *LOGIC_BY within the default logic whereas the ACCOUNT dimension is my trigger. Hence I have created a new property called "LOGIC" for every base level account.
I am using BPC MS 7.0 (release 7.0.110)
Simple example to explain:
ACCOUNT description - LOGIC property
PRICE1 - LOGIC_DEMAND
PRICE2 - LOGIC_DEMAND
AMOUNT1 - LOGIC_DEMAND
AMOUNT2 - LOGIC_DEMAND
REVENUE1 - LOGIC_DUMMY (is calculated via LOGIC_DEMAND by =PRICE1 * AMOUNT1)
REVENUE2 - LOGIC_DUMMY (is calculated via LOGIC_DEMAND by =PRICE2 * AMOUNT2)
REVENUE_PL - LOGIC_DUMMY (is calculated via LOGIC_DEMAND by =REVENUE1 + REVENUE2)
Default logic (default.lgf) just contains the following:
*LOGIC_MODE = 2
*LOGIC_BY = ACCOUNT
Data entry:
PRICE1 = 10
PRICE2 = 20
AMOUNT1 = 10
AMOUNT2 = 20
REVENUE1 (to be calculated/expected) = 100
REVENUE2 (to be calculated/expected) = 400
REVENUE_PL (to be calculated/expected) = 500
Result:
As I am sending data, all revenue accounts are calculated to ZERO.
If I change my default logic manually to
*INCLUDE LOGIC_DEMAND
then everything works. REVENUE1 and REVENUE2 are calculated to 100 / 400, and REVENUE_PL is 500.
What did I do wrong? Can anybody help? If there is someone who can post a short example, I would be very grateful.
Best regards,
Stefan

Hi BI,
hmm i guess there is no tools to debug line by line is SAP BPC.. guys is there any third party software that can do this??
Thanks, hope helps

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

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

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

Can we run script logic at the time of preparing reports.

Helo Everybody!
I am new to SAP BPC.
Can we run script logic at the time of preparing reports.
Thanks & Regards,
Satish.

If you mean, "Can we run script logic at the time of preparing reports" is equivalent to entering data into the report and sending it to the database, then yes, you may run logic as Marcel indicates. Defualt logic is ALWAYS run for ANY and EVERY set of data that is sent via an input template from the field. You may also run logic when posting a jOURNAL entry as well. But be careful....if default logic attempts to perform to MANY or COMPLEX calculations, the time it takes to complete the process may not be in expectations with the users plans. There is a fine design balance required when planning to run logic at the time of input, as opposed to running in a package or at specific times during the day.
Hope this helps.

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

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

How to auto-update of script logics after adding new dimension members?

Hi Experts,
Just wanna ask if BPC has a functionality that would automatically update/validate and save my script logic whenever I add new dimension members. I've added new PL accounts but they are not automatically added to my calculated BS Net Income. I had to re-validate and save my logic for it to be included in my logic and for the amounts to be computed correctly.
Thanks,
Marvin

Hi Marvin,
There is no functionality as such. we need to configure the script as and when we make any changes in the dimension members.
Regards
Raman

Use of LEFT in Script Logic

I am having one doubt reagrding usage of excel function like LEFT, MID, RIGHT in script logic of SELECT Statement.
Let me know with example if its possible.
I tried the below statement:
*SELECT(%EQACC%,"ID","ACCOUNT","LEFT(ID,6)='BE9001' AND CALC='N' AND ID<>'BE9001010'")
But it throw the error as "invalid select statement"
Anurodh

Anurodh,
what you are trying to do is not supported. As a workaround you can try to create a new property in the dimension (for example IDSHORT), putting in this filed just the first 6 characters of the ID and you can filter on it like in the following example:
*SELECT(%EQACC%,"ID","P_ACCT","IDSHORT='CE0004' AND CALC='N'")
Regards,
Simmaco

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

SQL functions in Script Logic

I want to build a script logic but the dimensions that I am testing do not have the fields I want in the format I want. In my case I would like to test the "Start" property in the Employee dimension. The property represents the employee start date but is a var char in the format dd.mm.yyyy rather thna a date field. I want to test whether it is five years prior to the date being processed.
My time dimension has a year property and a monthnum property. Each of these are varchar. I can write SQL that would convert these to a date and compare them with the start property on the employee dimension.
Can I do iinsert SQL functions in the When statement. An example would be
*When convert(datetime, substring(employee.start,4,2) + '/' + substring(employee.start,1,2) + '/' + substring(employee.start,7,4))
Can I use SQL functions in the Is statement? An example would be
*Is <DateAdd(YY,-5 , convert(datetime, Time.Monthnum + '/01/'' + time.year)
Finally when I use such techniques and look at the log by using "show log" in the logic debugger I see no reference to the SQL I used. It is as if the generated SQL has not made use of my functions. Instead all I seee are the extract statements from the three fact tables. Is this normal? Is there a way to see what SQL is really being generated and run?
At the moment it seems my only option is to make changes, try running it and hope I get an output. If no records are written I can't be sure whether it is because embedding SQL function is not supported or because I have made some other error.

No, the "BPC SQL" script logic doesn't allow for this extensive use of real SQL within the scripting syntax. As a concept, it's best to think of "BPC SQL" script logic as, "this unique BPC logic syntax will generate real SQL code when it's executed."
There's very little real SQL that you can use within the syntax itself, and definitely not within the WHEN or IF statements. Nothing like cast, convert, substring, etc. (Except you CAN use these, a little bit, in a *SELECT statement. But I don't see how that will solve your current problem.)
Plus, when you consider how the logic engine processes a set of data, it's helpful to think of it in terms of selects & reading through a recordset. So in that regard, a SQL background can be helpful, in understanding the concepts. (Sort of helpful, except when it confuses you, or frustrates you since you don't have all the power you want.)
Anyway, to solve your problem, you might be able to restate the problem, and then use something like this code, which is valid syntax:
*WHEN TIME.TIMEID
*IS >= VERSION.FirstPlanMonthTimeID
In this case, FirstPlanMonthTimeID is set up in the version dimension as, for example, 20090400 (representing 2009.APR). This timeID is set by BPC automatically when processing the time dimension, and I need to ensure that my Version property value is set to match it.
A key point is that in BPC fact tables, the time dimension is stored as TIMEID (not ID, unlike all the other dimensions), and can be used for comparative evaluation in script logic WHEN/IF. The comparison property needs to be stored as an 8-digit integer value. If your time dimension has days in it (along with months), check the TIMEID after processing, and you should see the pattern for assigning values to TIMEID for days and months, etc.
Normally, TIMEID is assigned pretty sensible and stable values. If it doesn't meet your logic requirements, you can create another property (be careful of USERTIMEID, since that has a specific purpose in the system which I've never fully understood) and assign that whatever (integer) values make sense.

BPC 7.5 MS SP5 wrong numbers multiplying GET (A)*GET(B) in script logic

Hi experts,
We are migrating from BPC 5.1 MS to 7.5 MS SP5 and there have some scripts that are using GET function that retrieve wrong numbers. Particularly, it does not record the decimals figures.
Example1 (multiply): when A=2,3 and B=4,4, then AB=10,12. But doing this in script logic GET(A)GET(B)=10. It does not write the decimal figures.
Example2 (addition): when A=2,3 and B=4,4, then AB=6,7. But doing this in script logic GET(A)GET(B)=6. It does not write the decimal figures.
Particularly, the script we are executing is the following. This script worked ok at 5.1 but not at 7.5:
*XDIM_MEMBERSET ACCOUNTL= INFLA_AUX,INFLA_ACUM
*XDIM_NOSCAN ACCOUNTL = INFLA_ACUM
*XDIM_MEMBERSET CATEGORY=%CATEGORY_SET%
*XDIM_MEMBERSET CURRENCY=LC
*XDIM_MEMBERSET TECHNOLOGY = %TECHNOLOGY_SET%
*XDIM_MEMBERSET PEM=DESCENDANTS([PEM].[PEMTOT],999,LEAVES)
*XDIM_MEMBERSET TIME=DESCENDANTS([TIME].[XXXX.TOT],999,LEAVES)
*CALC_EACH_PERIOD
*WHEN ACCOUNTL
*IS INFLA_AUX
     *WHEN TIME.YEAR
     *IS = PEM.YEAR
*REC(EXPRESSION=1,NOADD,ACCOUNTL=INFLA_ACUM)
            *IS < PEM.YEAR
*REC(EXPRESSION=0,NOADD,ACCOUNTL=INFLA_ACUM)
            *IS > PEM.YEAR
*REC(ACCOUNTL=INFLA_ACUM,NOADD,EXPRESSION=GET(ACCOUNTL="INFLA_ACUM",TIME=PRIOR) * GET(ACCOUNTL="INFLA_AUX",TIME=PRIOR))     //in this sentence!!!!!!
          *ENDWHEN
*ENDWHEN
*COMMIT
We have SIGNED_DATA_FORMAT (25,10) in the application parameters.
Many thanks for your attention.
Best regards,
Arkaitz
Edited by: arkaitz_orozko81 on Apr 28, 2011 4:31 PM
Edited by: arkaitz_orozko81 on Apr 28, 2011 4:33 PM

Hello,
We have solved this issue.
First, we have change the script:
*SELECT(%PEM_APLICA%,[ID],PEM,"APLICA='Y'")
*XDIM_MEMBERSET ACCOUNTL=PROD_AUX,DISP_INP,HORA_AUX,CAPAC_AUX
*XDIM_NOSCAN ACCOUNTL= PROD_AUX
*XDIM_MEMBERSET CATEGORY=%CATEGORY_SET%
*XDIM_MEMBERSET CURRENCY=LC
*XDIM_MEMBERSET TECHNOLOGY=DESCENDANTS([TECHNOLOGY].[RENOVABLES],999,LEAVES)
*XDIM_MEMBERSET PEM=%PEM_APLICA%
*XDIM_MEMBERSET TIME=<ALL>
*WHEN ACCOUNTL
*IS CAPAC_AUX
//*IS *
     *WHEN SIGNEDDATA
     *IS <> 0
REC(ACCOUNTL="PROD_AUX",NOADD,EXPRESSION=GET(ACCOUNTL="CAPAC_AUX")* GET(ACCOUNTL="DISP_INP")* GET(ACCOUNTL="HORA_AUX"))
     *ELSE
*REC(ACCOUNTL="PROD_AUX",NOADD,EXPRESSION=0)
*ENDWHEN
*ENDWHEN
*COMMIT
And we have change the regional settings to "English (United States)".
Many thanks for your answer.

Use of comments in script logic / BADI

Hi,
Does anyone knows whether one can read the comments entered in an input schedule in a script logic or BADI? Depending on the text entered in a comment, a certain planfunction has to be executed during save ...
the user should be able to easily change a dimension value in an input schedule:
Product    Product group    Key figure 1     Key figure 2
A             A1                     10                       30
-> the user easily needs to change the product group from A1 into B1 . When doing so the values of key figure 1 and 2 need to be copied to the new product group and the original values on A1 have to be removed. we cannot set up the product group as a propoerty since one should be able to compare multiple versions with different assignments ... So we were thinking to add an additional comment column in which the new value can be assigned to. When save, it should read the comment and perform the planfunction ... Would this be possible?
D

HI D-
Possible, but you would probably need to create a Badi to accomplish all the logic...
For a start, you would need to be able to find the comments...the naming convention for the dynamic comment table is:
/1CPMB/application_set_prefixapplication_prefixCMT
The two character application_set_prefix can be identified from the table UJA_APPSET_INFO, and the two character application_prefix can be identified from the UJA_APPL table.
Once the comment table is identified you could create a custom Badi to look up comment information to direct processing of specific records.
Regards,
Sheldon Edelstein

Logical Error in Script Logic

Hello Experts,
Please provide your guidance for the following scenario.
I need to calculate the 'Accumulated Depreciation' for every month, based on the amounts in the 'AccumDep' and the 'Depreciation' accounts.
In other words, the value of the Accumulated Depreciation for the month of Feb should be equal to (Accumulated Depreciation in Jan + Depreciation in Jan), and so on.
To accomplish this, I have written the following script logic.
*WHEN ACCOUNT
*IS AccumDep, Depreciation
     *FOR %MON% = 2009.FEB,2009.MAR,2009.APR
          *REC(FACTOR=1, ACCOUNT=AccumDep, TIME=%MON%)
     *NEXT
*ENDWHEN
*COMMIT
The above logic was validated without any 'syntax' errors. However, I do not see the desired results, as the Accumulated Depreciation is not getting updated every month. The amount from FEB appears for MAR & APR also.
Therefore, could you please review the above script and let me know if there are any 'logical' errors?
All your guidance is greatly appreciated. Thanks...

Hi,
You are not getting the desired result because you are trying to aggregate the depreciation and the accumulated depreciation of the same month and post the result again in the same month. Lets say the code is working for 2009.MAR. You are trying to add the depreciation and accumulated depreciation of 2009.MAR. However, you still dont have the acc depreciation of 2009.MAR. You basically need to take the acc depreciation of the previous month.
You can try something like:
*WHEN ACCOUNT
*IS Depreciation
     *FOR %MON% = 2009.FEB,2009.MAR,2009.APR
          *REC(EXPRESSION = %VALUE% + ([ACCOUNT].[AccumDep],[TIME].Previous), ACCOUNT=AccumDep)
     *NEXT
*ENDWHEN
*COMMIT
You can have a property called Previous to store the previous month of each period in the time dimension.
Hope you got the idea.

Complex Script logic

Similar Messages

Maybe you are looking for