Forum Stats

  • 3,855,327 Users
  • 2,264,499 Discussions
  • 7,905,970 Comments

Discussions

Check digit in HFM

User_SI7F5
User_SI7F5 Member Posts: 9 Blue Ribbon
edited Aug 8, 2019 4:26AM in Financial Consolidation

Has anyone experience with the use of check digits in HFM? Currently we are comparing printed and singed reporting packages manually with HFM inputs (account for account). We want to automate that process by using check digits which change if modifications in HFM are made (e.g entity was rejected, regroupings were made and entity was promoted again).

 

Tagged:
USER1211

Answers

  • ericerikson
    ericerikson Member Posts: 608 Bronze Trophy
    edited Jun 3, 2016 8:09AM

    Hi. Pretty sure this isn't going to work.

    Eric

    ericerikson.blogspot.com

    User_SI7F5
  • User_SI7F5
    User_SI7F5 Member Posts: 9 Blue Ribbon
    edited Jun 6, 2016 2:11AM

    Hi Eric,

    Why do you think that it isn't going to work?

     

    My idea was having one account calculating a modulus 10/11 (or any other) check digit by multiplying/dividing all accounts with inputs. That account/result I want to print on the bottom of each page of the reporting package.

     

  • user10767728
    user10767728 Member Posts: 85
    edited Jun 15, 2016 8:49AM

    Hi,

    I'm not sure if this would help your situation, but we have a counter account setup in the rules to increase by 1 every time the entity is calculated. One of the controls before closing the period for reporting is to see that all the active entities are in at Review Level 3 in Process Control and that their calculation status is OK. This report also shows the counter values. Then admin submits and publishes the entities and the report is ran again to show that status is still OK and the counter values did not change. Any change in data would trigger the status to change from OK to Need calculation and calculation would trigger the counter value to increase.

    Please note that this works only if you don't consolidate the data afterwards because a re-consolidation of history would trigger the values to change unless you build some kind of mechanism to stop the counter value from growing in history.

    I'd believe that merely using HFM's means, tracking somehow the changes in process control (rejection, promotion etc.) is not going to work. Such might be possible using some database magic...

    Hope this helps.

    User_SI7F5
  • Thanos A
    Thanos A Consolidation System Manager Member Posts: 1,443 Silver Trophy
    edited Jun 15, 2016 9:01AM

    Hi @user10767728

    Why don't you use the Data audit functionality to track if anyone is changing data in HFM?

    The key is to extract the data of the Data audit table in another database on a monthly basis in order to make sure that the perfromance of HFM is also the expected one.

    Cheers,

    Thanos

    USER1211User_SI7F5
  • Jeo123
    Jeo123 Member Posts: 515 Gold Badge
    edited Jun 15, 2016 4:31PM

    To make the counter stop increasing, I would just add in a check for Review Level and/or tie it into the counter.

    So let's say right now the counter goes up every time it's calculated and that you use Review Level 1, 2, 3, and then Publish.

    Select Case HS.ReviewStatus("")

         Case "First Pass","Review Level 1"

              CounterFactor = 1

         Case "Review Level 2"

              CounterFactor - 100

         Case "Review Level 3"

              CounterFactor = 10000

         Case "Published"

              CounterFactor = 1000000

    End Select

    Then instead of adding 1, add CounterFactor, and as long as you don't calculate an entity more than 100 times a close, you'll wind up with a number like 1020516 which would indicate that it was calculated 16 times at either First Pass or Review Level 1, 5 times at review level 2, twice at review level 3, and once after it was published.

    As for a hash to check the integrity of the data itself... you would have to some how combine not only the amounts in the account, but also the id of the members in the POV, otherwise someone could have a journal that was originally $1000 cash/$1000 revenue, move it to $1000 payables/$1000 expense, and come out with the same check number.  You'd also have to worry about reclasses by all the other custom's in theory.

    Off hand you could try to factor both the data and the result of the IDFromMember function(which returns the unique ID for each member), so HS.Account.IDFromMember("Sales") would give you a number you could multiply as you wanted.  So you could open a data unit, hash the combination of the POV items along with the data.

    I've never done it or seen it done, but there's nothing stopping you I suppose.  Performance might take a big hit though.

  • Thanos A
    Thanos A Consolidation System Manager Member Posts: 1,443 Silver Trophy
    edited Jun 15, 2016 5:03PM

    Hi,

    I cannot understand this logic.

    If you have an application that supports the translation with not only actual rates but also budget and forecast rates and if the company's requirement is to re-translate all years with the same budget rate, this counter will be count false signals, no?

  • Jeo123
    Jeo123 Member Posts: 515 Gold Badge
    edited Jun 15, 2016 6:31PM

    It would be false counters, except with the select case above those would presumably all be admin counters which could then be ignored.  As long as the only numbers to change were the ones 1000000 and higher, you know it was an admin who recalculated.  You could also actually just change the "Published" factor to 0 if you wanted.

    Personally, if a user needs to calculate their entity 50 times, I don't see that as being worth tracking.  But if you have that number in a report and you expected data to be at Review level 3, if 1020516 suddenly goes to 1020517, that would indicate the entity was rejected to Review level 1 and recalculated.  Some people might find that valuable.

    The same data is available in the process flow history, but most reports don't show that.

    I don't think this would work well for the higher entity levels though.  Part of why I wouldn't really implement something like this.  But if I had to because it was a business requirement though, I'm just saying I would split it by review level calculations.

  • Thanos A
    Thanos A Consolidation System Manager Member Posts: 1,443 Silver Trophy
    edited Jun 16, 2016 7:49AM

    Ah ok... this makes sense that way.

    I think that the best approach is to lock the entities at Entity Currency because even in "Published" the data can be changed by the admin.

  • User_SI7F5
    User_SI7F5 Member Posts: 9 Blue Ribbon
    edited Oct 13, 2016 1:27AM

    We have a solution on this issue. Our consultant did write a code for a check digit which is dependent on changes, Review Level and numbers of calculations.

This discussion has been closed.