Sunday, June 21, 2015

HFM's Equity Pickup Module

One of the somewhat newer (well, a few years ago) and lesser used features is the equity pickup module. I've set it up twice and in the middle of a third time, so let's talk about what it does and how.

From an accounting standpoint, when one entity owns another, you want to pull the net income from the owned entity into the owner. During consolidation, when the two entities meet (first common parent) the entries need to eliminate. That part is easy - standard intercompany elimination. But how to do the equity entry?

Before EPU, we'd do a few different things that all had problems. One, you could build the hierarchy where the owned entity is a child of a parent that is also the parent of the owner and use a consolidation rule to just consolidate the net income into the investment. But it was a really weird looking hierarchy. Two, the other approach is using GetCell formulas to pull the numbers around. The problem was order of execution - how to get each entity to calc in the correct order.

What you really want to do is push data to another entity. But HFM is great at pulling but almost never pushes - the exception is during a consolidation rule where you push data from [Parent Total] to [Proportion] and [Elimination].

So, the equity pickup module comes in to fit the bill. It handles both key pieces that are normally missing: order of execution and push. Technically, HFM is still pulling, but it looks like a push.

So, what happens?

For the setup, we'll need some metadata, data, and rules. The metadata is nothing special, other than having the owned and owner entities flagged as intercompany. For data, load in, using the system accounts, for shares outstanding and shares owned by owner. Note: this data comes in by the OWNED entity and says who OWNS them. TIP - assume shares outstanding is 100, so that everything can be loaded on a percentage basis.

For rules, there is a special subroutine (EquityPickup) that gets executed during the process. The rules basically pull data from the owned entity, apply the percentage to it, and put it in the owner entity. This last part uses standard HS.Exp.

After that, go to the EPU screen. The software figures out who owns who and, more importantly, the order in which everything should execute. After that, it's push a button to run the EPU calcs. When it runs, the module will look at the owned entity and first calculate/consolidate/translate as needed, so standard calculate subroutine runs, of course. Then it goes to the owner entity and runs the EPU subroutine to pull the appropriate data over.

There are some quirks to this, like a data load will change the EPU status but a force calc doesn't, but generally it does work and is in production.


  1. thanks for this, do you have any tips for a case where you have alternate hierarchies (eg Guarantor/NonGuarantor) where an entity is moved from the nonguarantor legal structure to the guarantor?

    1. Hi. From what I've seen (and I checked a presentation given at KScope this year by Keith Berry about EPU and G/NG) there doesn't appear to be anything different. What did you want to happen?

  2. Hi Eric,
    I was wondering if you've ever seen an error after migrating from an older version like to .2.4 on the EPU module, it looks like somewhere between the maintenance release something doesn't get updated.

    Every time I try to open the EPU an "unknown error" shows up and the log has this lines

    getRowCount() can not be called ViewDefEPUVO1920_136179

    However if I do an installation from scratch I don't get the error, maybe a .jar didn't get updated

    I already filed an SR with this but things hasn't really progressed

    Thanks in advanced and keep up the good work with your blogspot

  3. Hi. Sorry, I have not seen this but it sounds like a bug to me. Keep asking for an update on the SR and escalate if there isn't any activity.


  4. Thanks Eric for your post. Helps a lot!