9 Replies Latest reply: Mar 19, 2012 5:00 PM by KostasN. RSS

    Clearing the Validation numbers


      Although we have offsetting numbers at <Entity Currency> and <Entity Curr Adjs> Value dimension but still some ghost number is coming on overall <Entity Currency Total> value dimension. Can anybody advise how to get rid of this number due to which i am not able to promote my numbers as the validation account is not clearing.

      for example <Entity currency> 523,256,.02
      < Entity Curr Adjs> -523,256,.02

      Ideally <Entity Currency total> should have been 0. But it has some 0.00000065128932 value due to which validation account is not clearing off.

      also any idea what is benchmark amount which is used as benchmark to clear off validation when promoting/submitting the numbers.

      rahul kumar jha
        • 1. Re: Clearing the Validation numbers

          Normally, you would not directly link your accounts calculating differences to the validation account which controls promotion. Rather you should copy values from differences accounts to the validation account (using calculation rules) depending on the difference being within a tolerance set by your client. Because if you don't, you will have the same problem when there is a normal rounding difference, rather than the exotic value that you mention. In other words I would not worry about how this 0.000000065 comes into place because a normal 0.1 rounding difference would do the same damage, therefore in any case you have to solve this by providing with a mechanism testing against a tolerance. Then if your difference is within the tolerance you should clear the validation account using Hs.Clear "A#myValidation".

          • 2. Re: Clearing the Validation numbers
            Raul Rodriguez
            Have you tried using the IsAlmostEqual Function:

            Checks to see if the passed in values are equal based on a predefined Financial Management epsilon. This function can be used in all types of rules.
            A difference of -0.0000000000001 to 0.0000000000001 is considered zero difference
            BooleanValue = HS.IsAlmostEqual(Value1, Value2)
            Return Value
            A Boolean expression that is True if the passed in values are equal ; False if they are not equal.
            • 3. Re: Clearing the Validation numbers

              Thanks for your valuable input....but the issue is that we have managed to bring down the difference value to zero at entity currency total but when it is promoted to Parent currency some ghost value sits at the top level...and the constraint is that we cannot have a rule at the parent level values...now the challenge is how to eliminate that amount so that we can promote the numbers to next level...

              So in nutshell how to eliminate out any insignificant value at parent currency dimension as rule doesnt work at that level..

              • 4. Re: Clearing the Validation numbers
                Dear Kostas,

                Thanks for your valuable inputs...but the issue which we are facing out here is that at entity level we dont have any value arising for the validations account but when the same gets translated to parent currency some insignificant value goes and sits there so we are ending up having that number at the validation account of the parent currency total dimension. So we are unable to promote the same. Adding to the woes is the fact that we cant have any rule at the parent level. Now how to tackle this situation

                • 5. Re: Clearing the Validation numbers
                  First of all, in fact you CAN have calculation rules running at the <Parent Currency> and <Parent Curr Adjs> level. You can control this using the statements below:
                  If HS.Value.IsTransCur = TRUE or HS.Vale.IsTRansCurAdjs = TRUE Then
                  End If
                  Second, to my experience there are no unexplainable values in HFM. It is very easy though to miss a condition which makes some piece of code run where you do not expect it.

                  Finally, in any case you should use some tolerance code to control the value of your validation accounts.

                  • 6. Re: Clearing the Validation numbers
                    Dear Kostas,

                    Thanks for your reply which was of great help to bring some more insight.

                    Now the issue is at the parent node of the validations account.

                    We have phased submissions enabled with 2 phases to be submitted but when we are about to promote first phase to second level it is not allowing due to presence of the insignificant values at top level validation account.

                    In nutshell ghost numbers are appearing at <entity currency> value dimension for the validation account when it is rolling upto the parent level.

                    to make it more clear with help of example say we have Validation account 01 at top level and it has two sub child (V abcd and V xyz) and in turn they have sub childs(V01,02.....07) ...so structure is:

                    Validation Account01 (main parent validation account) 0.000000100 (because of incorrect rolling up)
                    V abcd --- 3741.20000100 (ideally the value should add as 3741.20000000 here)
                    V01 12836.59000000
                    V02 -12596.62000000
                    V03 3501.23000000
                    We have V abcd validation adjustment entry for -3741.200000000 to offset, since the amount is not correctly flowing it is not offsetting correctly.
                    so the value is not correctly rolling up in this case so how to ensure correct rolling up of this

                    V xyz --> 0.0000000000031
                    V05 0.0000000000000
                    V06 0.0000000000034
                    We have V xyz validation adjsutemnt entry for amount -0.000000000031 to offset the amount here.
                    in this case it is correctly rolling up
                    Validation account is the top level validation account with V abcd and V xyz as its immediate child and in turn both having sub childs
                    So as you can see the number is not adding up correctly which in turn rolling upto Validation account level and is not allowing to promote it to the next level. So we have an issue with Validation account dimension here, totals not flowing correctly from base account. So the challenge here is how to ensure correct rolling up of the values in the same value dimension

                    Edited by: rj_700 on Mar 19, 2012 6:22 PM
                    • 7. Re: Clearing the Validation numbers
                      what I am suggesting here (and I believe that Raul's posting is in the same direction as well), is that you should not set your validation account to be the parent of all your validations, but rather to use some other account which you will fill in by rules, say account "Lock1". Then you can control whether you will clear Lock1 or set it to Validation1, depending on whether it is less than a tolerance you have agreed with your client or not. Another reason you should want to control this value by rules is that you may not want to fire all the validations in every period, but rather to fire them conditionally.

                      • 8. Re: Clearing the Validation numbers
                        Raul Rodriguez
                        While it is hard to retrofit stuff, it is better to start a new. The idea is that should have a tri-account approach for any type of validation. The matching accounts and the result of the matching should be use in conjunction with the is almost equal function. We kow you already have a method in place, however, you should reconsider it. Switch the validation account to a new validation account that stores a value larger than your threshold.
                        • 9. Re: Clearing the Validation numbers
                          Hi Raul,
                          Yes, you are absolutely right to address the transition of methodology, for our friend in this thread. I'm writting again, only because I could not resist mentioning a technique created by a very creative consultant and dear friend of mine, who goes the validation threshold one step further: all validations exceeding the predefined tolerance, count +1 to the validation account. There is a second level tolerance there which checks if this count exceeds a second level threshold to decide if the validation is fired or not depending on the number of errors counted. Another technique I've also encountered, is to use override accounts, whereby if the overide account is manually set by the user, the validation will not fire.

                          Yet I feel that we may leave our friend unsatisfied, because he is very curious and persistent about the tiny differences generated by HFM. I must confess that I am not ready to answer this one, but I'll give it a shot if somebody has not a ready answer in the meantime.

                          Edited by: Kostas N. on Mar 19, 2012 11:55 PM