Evaluation of SignedData in Script Logic v7.5 SQL

Hello everyone,
I'm noticing a problem in script logic at a client trying to upgrade to version 7.5 SQL.  This client has used its logic for around 5 years now through versions 4 and 5 but is now having a problem moving to version 7.5 and using this logic.
It appears that evaluation of signeddata doesn't work in version 7.5 in SQL.  For example, a statement like:
*WHEN ACCOUNT
*IS 1000
*WHEN SIGNEDDATA
*IS <>0
*REC...
*ENDWHEN
*ENDWHEN
*COMMIT
Doesn't appear to be working.  It's also possible that a reference to the TIMEID property is not working in something like:
*WHEN ACCONT
*IS 1000
*WHEN SIGNEDDATA
*IS >TIME.TIMEID
*REC...
*ENDWHEN
*ENDWHEN
*COMMIT
Does anyone have any experience using SIGNEDDATA references in logic in version 7.5?
Thank you,
Grant

Hello everyone,
I'm noticing a problem in script logic at a client trying to upgrade to version 7.5 SQL.  This client has used its logic for around 5 years now through versions 4 and 5 but is now having a problem moving to version 7.5 and using this logic.
It appears that evaluation of signeddata doesn't work in version 7.5 in SQL.  For example, a statement like:
*WHEN ACCOUNT
*IS 1000
*WHEN SIGNEDDATA
*IS <>0
*REC...
*ENDWHEN
*ENDWHEN
*COMMIT
Doesn't appear to be working.  It's also possible that a reference to the TIMEID property is not working in something like:
*WHEN ACCONT
*IS 1000
*WHEN SIGNEDDATA
*IS >TIME.TIMEID
*REC...
*ENDWHEN
*ENDWHEN
*COMMIT
Does anyone have any experience using SIGNEDDATA references in logic in version 7.5?
Thank you,
Grant

Similar Messages

  • 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

  • Script logic not working

    Hi all,
        we have been using this logic in versions 4.2 and 5.1.  just brought our apps over to  new 7.5  sql environment and the logic did not  work. Nothing changed in logic or in dimensionality. System seems to be ignoring any *WHEN IGNEDDATA   checks.
    It appears that evaluation of signeddata doesn't work in version 7.5 in  SQL. loaded multiple data templates and also run countless default  logic packages. Always fails to calculate the required accounts only when involving logic . Other script  logic packages work fine. 
    Regards,
    Srini

    Hi Srini,
    Can you please share the script, you are using?

  • 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.

  • Script logic error - Invalid object name 'tblStatus'

    Hi all,
    Running BPC 5.1 SP5 on SQL 2005.
    Has anyone ever seen this error message before? I only get the error message when choosing the run-time option in the package, to honor work status settings. This problem just appeared in the last few days, and I believe that a month or two ago, users were running the same logic (with the same yes-honor-work-status option selected).
    We did recently upgrade from 5.1 SP3 to 5.1 SP5, and I'm wondering if this may be a cause? That's just a hypothesis though.
    Invalid object name 'tblStatus'. in:
    select distinct d.VERSION,d.ENTITY,d.TIMEID
    from #RESULT_333729 d  where signeddata<>0
    and exists (select * from tblStatus s where [APP]='CONSOL' and d.VERSION=s.CATEGORY and d.ENTITY=s.ENTITY and d.TIMEID=s.TIME and [STATUS]>0)
    I understand what it means, and of course there is no table in the appset database tblStatus. Work status locks are kept in tblConsolLock (where Consol is my app name). And in that table, the field name is StatusCode, not Status. So it appears that this is some vestige of code from an earlier version of BPC / O'soft.
    This error occurs in a piece of script logic, that includes both basic SQL WHEN/IS/*REC's and also a *RUNALLOCATION. The error is thrown within the RUNALLOCATION code block. The complete run-up to the error message is shown below.
    -- Calculate difference
    insert into #DIFF_333729 ([ACCOUNT],[AFFILIATE],[CURRENCY],[DATASRC],[ENTITY],[PRODHIER],[TIMEID],[VERSION],signeddata)
    select [ACCOUNT],[AFFILIATE],[CURRENCY],[DATASRC],[ENTITY],[PRODHIER],[TIMEID],[VERSION],amtWHERE as signeddata
    from #WHERE2_333729
    select [ACCOUNT],[AFFILIATE],[CURRENCY],[DATASRC],[ENTITY],[PRODHIER],[TIMEID],[VERSION],sum(signeddata) as signeddata
    into #RESULT_333729 from #DIFF_333729
    group by [ACCOUNT],[AFFILIATE],[CURRENCY],[DATASRC],[ENTITY],[PRODHIER],[TIMEID],[VERSION]
    --Time to calculate and count differences (45459 found):2.5 sec.
    select distinct d.VERSION,d.ENTITY,d.TIMEID
    from #RESULT_333729 d  where signeddata<>0
    and exists (select * from tblStatus s where [APP]='CONSOL' and d.VERSION=s.CATEGORY and d.ENTITY=s.ENTITY and d.TIMEID=s.TIME and [STATUS]>0)
    call 1 completed and data posted in 23.6 sec.
    Run completed in 23.7 sec.
    End time --->11:01:05 AM  -  Date:1/16/2009
    Invalid object name 'tblStatus'. in:
    select distinct d.VERSION,d.ENTITY,d.TIMEID
    from #RESULT_333729 d  where signeddata<>0
    and exists (select * from tblStatus s where [APP]='CONSOL' and d.VERSION=s.CATEGORY and d.ENTITY=s.ENTITY and d.TIMEID=s.TIME and [STATUS]>0)
    Here is the original script logic (from the LGX file -- the LGF file has a whole bunch of variables in it that would only confuse the matter more). It works just fine when the
    *RUN_ALLOCATION @A_1||
    USING/TOTAL|
    ACCOUNT WHAT=659210,659310,659320,659410,659510,659610,659620,659630,659710,659810,659820,659910; WHERE=<<<; USING=PCAYTD510000; TOTAL=<<<|
    PRODHIER WHAT=PRODHIERL1A;WHERE=[PRODHIERLEVEL]='5'; USING=<<<; TOTAL=<<<|
    DATASRC WHAT=PCAASSESSSTAGE1,PCAASSESSSTAGE2; WHERE=PCAASSESSALLOC1; USING=INPUTCONSOL; TOTAL=<<<|
    ENTITY WHAT=[COMPANYCODE]='7470' AND [PCAASSESSDRIVERBP]='PCAYTD510000' AND
      ([PCAASSESSMETHODBP] = 'ALLOCAUTO' OR  [PCAASSESSMETHODBP] = 'ALLOCMANUAL');WHERE=<<<;USING=7470.BASE;TOTAL=<<<|
    Anyone experience this same error message? I searched for SAP support notes and found nothing to do with tblStatus or similar.
    Thanks for your help,
    Tim

    Hi Sorin,
    Thanks, you've confirmed what I suspected.
    Yes, we always process & save apps & dims on any upgrade.
    We've reproduced the problem in all 3 of the environments with the customer's appset. I haven't yet reproduced in ApShell, but will do so & report it as a bug.
    And just out of curiousity -- was the other message you saw here in this EPM forum? Before I posted my question, I searched both here, and in the support notes, for "tblStatus" and a few other terms about work status lock errors, etc., and came up with 0 results.
    Thanks again,
    Tim

  • 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

  • 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.

  • Confusing results from script logic

    hi,
      i have the following script logics :
    *lookup finance
    *dim valuesales:account="sales"
    *dim valuecost:account="cost"
    *endlookup
    *when lookup(valuesales)
    *is>=lookup(valuecost)
      *rec(factor=0,account="validation")
    *else
      *rec(account="validation")
    *endwhen
      however the results are completely opposite of what i expected. when i did a evsen of 20 to "sales" and 10 to "cost", the result is 30 in "validation"; and when i did a evsen of 10 to "sales" and 20 to "cost", the result is zero in "validation".
      any idea?
    cheers

    All the SQL logic is referencing the data as it's stored in the fact tables (signeddata).
    Check your acctype. If the signed value of the sales (INC) is negative, and the cost (EXP) is positive, it may explain this.

  • Transport Script Logic not posting zero's

    Hi Guys,
    I have a piece of transport logic that is supposed to transport data from the TRAVEL cube to the Finance cube. The problem is that in some months the users do not have people travelling and only a zero should be transported across to Finance and clear the data that is sitting there. Unfortunately the zero's are being transported across
    I even force the accounts to be zero before populating them, but that doesn't work
    Here follows my code, please let me know if you can spot anything:
    Edited by: Gert Andries van den Berg on May 29, 2009 3:37 PM

    In theory, *clear_destination should work across applications, and I've successfully used it that way once or twice. But it's always been a challenge for me to figure out exactly what scoping instructions are required. Plus, I've needed to play with the *calculate_difference option, not sure if it should = 0 or 1, to get the expected results.
    Plus, the behavior seems to have changed somewhere along the way, between versions 5.0 and 5.1 SP8.
    I may be wrong, but I don't think that the NOADD specifically is going to solve the problem where a zero value in the source app isn't being properly updated to a zero value in the destination app. I've found this problem is a lot easier to resolve if the transfer is being done in the source app's default logic, since that somehow includes the scoping of that zero-value account in the transfer logic. When the transfer logic is run as a batch process (after the value has already been set to zero), it's impossible sometimes to get the logic to generate that zero-value record.
    So instead, I've played around with ideas such as a script logic in the destination app, that just clears out the entire region of data that is to be transferred, and then re-transfer everything. I'm sure that this is horribly inefficient, and I'm not really happy with that design, but I haven't come across a better solution.
    Regarding the *select's: Correct, these are not "by commit". The commit clears the source data region that was scoped out and was read into memory from the fact tables, during the logic run-time.  The select, however, is evaluated at logic validation-time (along with any for/next loops), and the variables are replaced then.
    It's not possible to assign some variable %foo% one value "2009" in a select (on line 10), then use it (on line 15), and then assign the same variable a second value "2010" (on line 20), and use it (on line 25). I've never bothered to test this out, but I'm certain that both lines 15 and 25 will see the variable replaced with the same value. My guess is that both would have the value of 2010, the final select.

  • SAP BPC 5.1 Script Logic Issue

    Hi Guys,
    I have a problem with Inventory Days script logic at the moment. Basically what the logic should do is:
    1. Copy the required data across to a calculation category (SQL)
    2. Calculate the last 12 months Cost of Sales for every entity in the selection for 3 years (MDX)
    3. Use the Cost of Sales number and multiply it with the inventory days number (SQL)
    The calc works fine for some of my smaller brands (200 - 500 entities),  but when i run the logic for my big brand (2000 entities) the last step doesn't calculate correctly. I have done the following to try and fix the problem.
    1. Every step has it's own COMMIT
    2. I clear the data before writing anything
    3. I use XDIM_MAXMEMBERS Entity = 500
    Any ideas why the logic is acting like this? I don't know if I am allowed to post my code here, but if it will help i will
    Regards,
    Andries van den Berg

    Hi,
    I only sent you the step that is giving me a problem at the moment. I broke the logic up into different packages to check where the problem lies and narrowed it down to this one.
    It seems like the code didn't copy across correctly, it is supposed to be when EXTRAP.BRAND "<>" "". I'll just paste the code again, just so that we are all on the same page.
    Regarding the FAC2, the client was running the code a lot of times and the WB table was getting huge. So, i started posting the records to the FAC2 table and processing it in the SSIS package. And i did confirm that they are posting there.
    I just tried to run the script for half of the entities and it didn't work. I then tried to run is for 25 entities and it worked. Could the *XDIM_MaxMembers Entity =  50 be giving me the problem? This is all i get over and over in the formula log:
    RPTCURRENCY,ACCOUNT,CATEGORY,DATASRC,ENTITY,INTCO,TIME,SIGNEDDATA
    LC,80500,BUDGET,INPUT,P71559,NON_INTERCO,2010.AUG, 0
    The other thing that bugs me is that i have similar script that never gives me issues for the same client.
    Regards,
    AvdB
    //Step 4 -- Calculate the Inventory per month for all the entities selected
    *SELECT(%BUDGET_YEAR1%,"[BUDGET_YEAR1]","CATEGORY","[ID]='BUDGET'")
    *SELECT(%BUDGET_TIME_SET1%,"[ID]","TIME","[YEAR]=%BUDGET_YEAR1% AND [CALC] = 'N'")
    *SELECT(%BUDGET_YEAR2%,"[BUDGET_YEAR2]","CATEGORY","[ID]='BUDGET'")
    *SELECT(%BUDGET_TIME_SET2%,"[ID]","TIME","[YEAR]=%BUDGET_YEAR2% AND [CALC] = 'N'")
    *SELECT(%BUDGET_YEAR3%,"[BUDGET_YEAR3]","CATEGORY","[ID]='BUDGET'")
    *SELECT(%BUDGET_TIME_SET3%,"[ID]","TIME","[YEAR]=%BUDGET_YEAR3% AND [CALC] = 'N'")
    *XDIM_Memberset Time = %BUDGET_TIME_SET1%,%BUDGET_TIME_SET2%,%BUDGET_TIME_SET3%
    *XDIM_Memberset Category = TOPDOWN, BUDGET
    *XDIM_Memberset Entity = %Entity_Set%
    *XDIM_MaxMembers Entity =  50
    *XDIM_ADDMemberset ENTITY = CLKS,MUS,BS // Add global entities
    *XDIM_Memberset ACCOUNT = Last12FSCoS,Last12DispCoS, InventoryFSDays, InventoryDispDays  //Add the caculated CoS account from the previous step and the Global Driver for days
    *WHEN ENTITY.EXTRAP_BRAND
    *IS <> ""
    *WHEN CATEGORY
    *IS TOPDOWN
                       *REC(EXPRESSION=(GET(ACCOUNT="Last12FSCoS",CATEGORY="TOPDOWN")*GET(ACCOUNT="InventoryFSDays",ENTITY=ENTITY.EXTRAP_BRAND,CATEGORY="BUDGET")/365)*-1,NOADD,ACCOUNT="80500",CATEGORY="BUDGET")
                       *REC(EXPRESSION=(GET(ACCOUNT="Last12DispCoS",CATEGORY="TOPDOWN")*GET(ACCOUNT="InventoryDispDays",ENTITY=ENTITY.EXTRAP_BRAND,CATEGORY="BUDGET")/365)*-1,NOADD,ACCOUNT="80510",CATEGORY="BUDGET")
    *ENDWHEN
    *ENDWHEN
    *WRITE_TO_FAC2
    *COMMIT

  • 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

  • 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

Maybe you are looking for