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

Similar Messages

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

  • 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

  • Calc Previous YTD periods in SQL script logic

    Hi, experts!
    I need help in writing SQL script logic. I want to calculate such logic
    (Account = Acc3, TIME = 2009.FEB ) = (Account = Acc1, SUM(TIME = (2009.JAN; 2009.FEB))) - (Account = Acc2, SUM(TIME = (2009.JAN)))
    (Account = Acc3, TIME = 2009.MAR ) = (Account = Acc1, SUM(TIME = (2009.JAN; 2009.FEB; 2009.MAR))) - (Account = Acc2, SUM(TIME = (2009.JAN; 2009.FEB)))
    ..... and so on
    Thanks all for help.

    Hi Petar,
    Thanks for your advice.
    Legalapp in my Apshell do not have any account transformation rules. But looking at the account transformation table, I can see it requires dimension type datasrc and subtable for datasource and flow fields. But currently my application is similar to the Finance application from Apshell and do not have these dimension types.
    Still I created a rule in account transformation table by having these fields blank and the validation was successful. Then I used SPRUNCALCACCOUNT in default.LGL file to trigger this rule but I don't see this working.
    Can you help me on below questions:
    1. Is it necessary to have datasrc and subtable dimensions to create account transformation rule?
    2. Will SPRUNCALCACCOUNT write the values to WB table or should I use COMMIT or any other command along with his to have the values written?
    3. Is there any way/place where I can get the examples of Account Transformation rules ?
    Thanks
    Sharath

  • Drop tables // sqlplus scripts comments // synonyms

    Hello,
    I'm several question:
    1) I've created three tables just as you can look bellow-->
    CREATE TABLE IDIOMA_FABRICANT (
    IDIOMA NUMBER(38) NOT NULL,
    FABRICANT NUMBER(38) NOT NULL,
    WEB VARCHAR(35),
    DESCRIPCIO VARCHAR(100),
    CONSTRAINT idioma_fabricant_pk PRIMARY KEY (IDIOMA,FABRICANT),
    CONSTRAINT idioma_fabricant_fk FOREIGN KEY (IDIOMA) REFERENCES IDIOMA(CODI) ON DELETE CASCADE,
    CONSTRAINT fabricant_fabricant_fk FOREIGN KEY (FABRICANT) REFERENCES FABRICANT(CODI) ON DELETE CASCADE
    CREATE TABLE IDIOMA (
    CODI NUMBER(38),
    DESCRIPCIO VARCHAR(15),
    CONSTRAINT codi_idioma_pk PRIMARY KEY (CODI)
    CREATE TABLE FABRICANT (
    CODI NUMBER(38),
    NOM VARCHAR(30),
    ALIAS VARCHAR(30),
    CONSTRAINT codi_fabricant_pk PRIMARY KEY (CODI)
    question: If I want drop these tables, Do I Must drop firstly the CONSTRAINTS?
    What should the commands to drop these tables are?
    2) I've read that to set comments in my PL/SQL scripts I must type /* ... */ or --. But It doesn't work. The lines inside these characters are performed by SQLPlus. What are the correct characters to establish a comment in my scripts?
    3) While somebody is creating a database tables for your application, he usually executes this sentence "SELECT TABLE_NAME FROM USER_TABLES" to get the tables that he has created. How can I create a synonym to do it more quickly?
    Thanks for all in advance.

    Hi
    We can create Synonym only for giving alternative name for tables, view, sequence, procedure, stored function, package etc.. not like that you said.
    Synonyms are used to hide the name and owner of an object and for providing location transparency for remote objects.
    for example
    Let EMP be the table name.
    If you execute the query given below, then the synonym EMPS will be created for the table name EMP.
    Create synonym EmpS for Emp;
    So now, you can use the synonym name in DML instead of the table name.
    select * from Emps;
    Regards
    Basheer

  • 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

  • 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: 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 VS Data Transformation File

    Hi all,
       I'm new to SAP BPC. I have knowledge of SAP BW.
       I can see conversion file, which we are referring in data transformation file. which we can use for mapping and conversion of external data into internal data.
      How data transformation file different form script logic? Are we going to refer script logis in Data transformation file for each required dimension?
      Can any of you give me clarity on how to place script logic and data transformation file in BPC data management flow.
      I will really applicate all your help!!!
    Thanks
    Ben.

    Nilanjan,
       I have a another quick question...
      suppose my bpc application has 5 dimensions. Out of the 5 dimensions, 4 dimensions data i'm getting directly from SAP BW. assume 1 dim, i need to extract by doing look up at different table which also reside in BW.
       how to populate data for DIM 5.
       I got your point that data transformation file purely for field mapping. suppose DIM5 if i want to populate from script logic, wht do i need map in Transformation file. I hope you got my point.
       My question if how to populate a DIM in BPC using lookup approach.
    Thanks,
    Ben.

  • 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

  • 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

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

  • 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

  • Changing Work Status using data package or script logic

    Is it possible to set Work Status using Script logic, or an SSIS package.
    I know status is kept is an SQL table, is it possible to just update the locking table with a new record, or is there more to changing the work status.
    Thanks for you help

    Thanks for your reply. This would be a nice enhancement.
    Although the work status does help with the audit trail of who and what locks the data, doing it automatically will allow the system to automatically unlock the period when it is opened before auto-loading the current closing balances. It will need to be carefully used in order to maintain proper audit trail of the data. When done automatically, the system userid would be used in the lock table witha  timestamp.
    I am needing to know if there are anyother steps involved in locking data other than writing to the SQL lock table. Is usppose this is especailly relevant when locking a parent and pushing the status to the children.

Maybe you are looking for