Palo Rules Issues

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Palo Rules Issues

      Still haven't lost all patience with Palo, but the issues with rules are driving me insane. See attached Test database - nothing tricky, except a few IF conditions and a "rolling" calculation from month to month. See the VALUE errors reflected on the view in the Excel spreadsheet. When removing the IF conditions, all is fine, so the index numbers are not causing any issues. When adding the simple IF, I end up with this issue.

      As rules similar to these are required regularly in any reasonable budgeting system, I'm sure there has to be a simple solution. Anyone able to assist here? Will be much appreciated
    • RE: Palo Rules Issues

      Snoozy,

      Can you please post the rule text here on the forum?


      I have extensive experience in TM1 and I expected the rules to work in the same way. Actually, Palo enterprise Rules are a completely different beast.


      ========================
      THE PALO RULE COMMANDMENTS
      ========================

      1.THOU SHALT BACK UP THY RULES FILE
      Palo rules can be fast, brutal and very unforgiving. You can easily crash your server, delete all your rules , etc by writing a dodgy rule. So always back up the rules by exporting them before you modify anything.

      2. THY MARKERS ARE NOT THY FEEDERS
      Markers are NOT TM1 Feeders. They operate in a different way to get a similar result. I am still working out what that difference is. For example, if you have an unmarked n level rule, you will find you will still be able to enter data in against that cell. If you do not want users to do that, ensure that the cell is marked.

      3. USE THY PALO ETL TO MANAGE THY RULES
      With large, complex models, always hard code rules where possible. Palo likes you to be specific.This is usually a no-no in enterprise systems, but with Palo ETL's ability to manage rules for you, it means you can let it manage your rules instead of having to use lots of tests (If statements) in your rules.

      For example the following could be a rule that the ETL writes into the rule file every month:,
      ['Current Forecast', 'Jul']=N: [['Actual']]
      ['Current Forecast', 'Aug']=N: [['Actual']], etc,etc,

      In my recent project, ended up with 1,000's of rules all managed by the ETL. This was light years faster (because obviously all the rules were super efficient) for the end user than using a 100 or so rules I had in the model originally,with each line testing with IF's, Attributes, hierarchies, etc.

      4. THOUGH SHALT STET CORRECTLY THY ROLLING RULE
      When doing any type of rolling calculation, always ensure you have a start point stetted in the rules. (Big thank you to Pommie for pointing this out.) For example, if you are rolling through months and you are looking at a prior month attribute for each month, make sure the first month is STET as there will be no 'prior' month for the first month in the system.

      5. UNDERSTAND THY PALO RULE FUNCTIONS
      Some Palo rule functions (and the IF in particular) are more inefficient than others. Test them all out. I generally find it better to look up attribute values where possible than to use a lot of functions in rules. Obviously, if you are using rules to calculate your attribute values, this will also add to the complexity/ slowness. Try to get your attribute values 'hardcoded' (eg via the ETL) where possible.


      6. THOU SHALT BE PRAGMATIC
      Be Pragmatic with your rules. Don't build a massively complex/heavy rule to be used in one report just because 'Palo should be able to do it'. If you have some very inefficient or heavy rules that will only be used or one report or by one or two people, consider building the calc into excel using palo data. A lot more efficient and your users will love you for keeping the models fast.

      7. THOU SHALT OPTIMIZE THY PLANNING MODEL
      As a very general maxim, Palo handles data far better than calculations. From my testing, Palo can scream through a very dense and large cube (> 10 GB csv file) but struggles with smaller cubes with more rules attached. This is not only a Palo rule - TM1 has the same issues. Therefore, use the ETL or Excel where you can to hardcode values in the model. Not always practicable in a Planning model but you would be surprised how many rule calcs you can replace if you think about it.


      Everyone, please feel free to add to these 'commandments', and edit where required.

      Cheers, Withnail

      The post was edited 4 times, last by Withnail ().

    • interesting post

      1.THOU SHALT BACK UP THY RULES FILE
      Palo rules can be fast, brutal and very unforgiving. You can easily crash your server, delete all your rules , etc by writing a dodgy rule {OR BY DELETING AN ELEMENT - AND IF YOU USE THE CLEAR PARAMETER ON A DIMENSION IMPORT VIA EXCEL EVEN RULES USING A !'dimension' REFERENCE WILL GET DELETED WITHOUT ANY WARNING AT ALL, WHICH CAN BE SERIOUSLY WORRYING IN A COMPLEX PLANNING MODEL}. CURIOUSLY RENAMING A DIMENSION DOES NOT RESULT IN THE DELETION OF ANY RULES.

      So always back up the rules by exporting them before you modify anything.
      Best wishes

      John Hobson
      The Planning Factory, Lytham, UK
      www.planfact.co.uk
    • Actual rules included in the model:

      ################################################
      ## Palo Rule Editor Export
      ## v3.0
      ## Active;Definition;Comment;Extern ID;Timestamp
      ################################################
      ['Jan','2009'] = N:STET();
      ['Jan','A'] = N:IF((PALO.DATA("Test","GL",PALO.EPREV("Test","Year",!'Year'),PALO.DATA("Test","#_Month","Prev element",!'Month'),!'Account') + ['B']) > 20,PALO.DATA("Test","GL",PALO.EPREV("Test","Year",!'Year'),PALO.DATA("Test","#_Month","Prev element",!'Month'),!'Account'),PALO.DATA("Test","GL",PALO.EPREV("Test","Year",!'Year'),PALO.DATA("Test","#_Month","Prev element",!'Month'),!'Account') + ['B']);
      ['A'] = N:IF((PALO.DATA("Test","GL",!'Year',PALO.DATA("Test","#_Month","Prev element",!'Month'),!'Account') + ['B']) > 20,PALO.DATA("Test","GL",!'Year',PALO.DATA("Test","#_Month","Prev element",!'Month'),!'Account'),PALO.DATA("Test","GL",!'Year',PALO.DATA("Test","#_Month","Prev element",!'Month'),!'Account') + ['B']);

      Sorry about the delay in posting these
    • Thanks for that Withnail, I have changed the rule to use attribute for both year and month, but the issue still exists...

      So herewith updated rule, still with same issue:

      ['Jan','2009'] = N:STET();

      ['Jan','A'] = N:IF((PALO.DATA("Test","GL",PALO.DATA("Test","#_Year","PrevYear",!'Year'),"Dec",!'Account') + ['B']) > 20,PALO.DATA("Test","GL",PALO.DATA("Test","#_Year","PrevYear",!'Year'),"Dec",!'Account'),PALO.DATA("Test","GL",PALO.DATA("Test","#_Year","PrevYear",!'Year'),"Dec",!'Account') + ['B']);

      ['A'] = N:IF((PALO.DATA("Test","GL",!'Year',PALO.DATA("Test","#_Month","Prev element",!'Month'),!'Account') + ['B']) > 20,PALO.DATA("Test","GL",!'Year',PALO.DATA("Test","#_Month","Prev element",!'Month'),!'Account'),PALO.DATA("Test","GL",!'Year',PALO.DATA("Test","#_Month","Prev element",!'Month'),!'Account') + ['B']);

      Please help anyone! Or is this simple item really an issue in Palo??

      The post was edited 1 time, last by snoozy ().

    • Have you tried marking the cell?

      Try with [] around ['B'] and then the PALO.MARKER function for the other parts of the equation as per the manual .

      So the second rule here should look like as follows:

      ['Jan','A'] = N:
      IF(
      (PALO.DATA("Test","GL", PALO.DATA("Test","#_Year","PrevYear",!'Year'),"
      Dec",!'Account') + ['B']) > 20,

      PALO.MARKER("Test","GL", PALO.DATA("Test","#_Year","PrevYear",!'Year'),"Dec
      ",!'Account'),

      PALO.MARKER("Test","GL",PALO.DATA("Test","#_Year","PrevYear",!'
      Year'),"Dec",!'Account') + [['B']]
      );

      The post was edited 1 time, last by Withnail ().

    • Hi Withnail
      Thanks for that - haven't tried yet, as I'm overseas on a business trip, but I doubt that I'll be able to use the Palo.Marker formula, as the reference includes a further Palo.Data function to an attribute cube, and Palo don't seem to be too fond of that...

      Any other ideas?

      Thanks for your help on this one - looks more and more like Palo just can't handle simple rolling calculations!!
    • Palo can handle rolling calculations - I am looking at one right now

      The basic syntax is to us a palo.data reference to a previous elemnt or an element defined by an attribute as previous element as Withnail has said.

      You do need to ensure that the first element is specified as STET() or it will fail all along the calculation.

      Here is a simplified example of a rule that does work:

      (First inventory Week is an parameter that allows me to specify a start week for the balance calculation.
      OSOH = Opening inventory
      CSOH = Closing inventory.
      Opening inventory Week x = Closing Inventory Week X -1)


      ['OSOH Units DC'] = N:IF(PALO.DATA("RP","Parameters","String","First Inventory Week") == (!'Time_w'),STET(),

      PALO.DATA("RP","FL",PALO.DATA("RP","#_Time_W","Last_Week",!'Time_w'),!'Product',"CSOH Units DC"))

      Hope this helps
      Best wishes

      John Hobson
      The Planning Factory, Lytham, UK
      www.planfact.co.uk