Discussions
Categories
- 17.9K All Categories
- 3.4K Industry Applications
- 3.3K Intelligent Advisor
- 63 Insurance
- 536.4K On-Premises Infrastructure
- 138.3K Analytics Software
- 38.6K Application Development Software
- 5.8K Cloud Platform
- 109.5K Database Software
- 17.5K Enterprise Manager
- 8.8K Hardware
- 71.1K Infrastructure Software
- 105.3K Integration
- 41.6K Security Software
MemberList based on Account Entry

Hi fellow HFM Admins,
I have following question regarding creating a memberlist:
I would like to have a Entity MemberList based off of what an Entitiy has as a value in a certain account.
e.g. Account is called StrucCheck
So, if this account has a value of 3 for the specific Year / Period, than it should appear in the Entitly Member List.
I need this for a Report creation to suppress certain entities.
Thanks for much for your help
Best Answer
-
Jeo123: this could be the first time I disagree with you in years! Don't take it personally because I'm a fan of your contributions, but in this case I'll offer different advice.
Member lists are populated during execution. (you can confirm this by applying WriteToFile approach to member lists and you'll see this). When you open a list and examine its contents, HFM generates the list's members for you. Given that some lists can vary by POV, each user can get their own version during run-time.
Member lists can use HS.GetCell and HS.GetCellText functions. Again, they would look at the contents of a very specific cell, and return results based on that cell. The member list definition must include the full cell POV.
Back to Jeo123: you may be thinking of Sub NoInput and Sub Input which populate during the HFM application startup. Even those subroutines can use GetCell, but the problem is if the cell's contents change after the application starts up, the only way to get Sub NoInput and Sub Input to recognize them is to either restart the application or re-load the rules. Member lists on the other hand don't have this restriction because they execute when a user opens them either directly, or indirectly by using form, report, task flow, or rule, or any other action that uses a member list.
I agree that Financial Reports can use conditional formatting based on cell values too, but the problem with FR is that it has to pull the entity into the report server's memory first before it can suppress the entity. A member list would return to FR only those entities which meet the criteria from the HFM server perspective, so performance might be better.
Also, FR does a poor job managing POV based member lists (ones that use @POV in the member list definition).
- Chris
Answers
-
Unfortunately that's not going to be possible.
Memberlists are populated on data source startup. At it's most basic level, that's going to be your problem. So if you change a 2 to a 3 in that account, the memberlist wouldn't be repopulated until the data source was restarted because it was a 2 when the list was populated.
In general, you can't use things like HS.GetCell in the memberlist routine. Creative work arounds can be found(again subject to the start up limitation) but even if you could get through that issue, you'll ultimately be faced with the fact that member lists aren't specific to certain dimension. For example, imagine your memberlist going down the rows of a grid with your periods going across the columns. It wouldn't make sense if each period had it's own memberlist.
Your best bet if you're trying to use this for just a report is probably to bring the data value into the report and link the entire rows suppression to the column pulling in the value.
-
Jeo123: this could be the first time I disagree with you in years! Don't take it personally because I'm a fan of your contributions, but in this case I'll offer different advice.
Member lists are populated during execution. (you can confirm this by applying WriteToFile approach to member lists and you'll see this). When you open a list and examine its contents, HFM generates the list's members for you. Given that some lists can vary by POV, each user can get their own version during run-time.
Member lists can use HS.GetCell and HS.GetCellText functions. Again, they would look at the contents of a very specific cell, and return results based on that cell. The member list definition must include the full cell POV.
Back to Jeo123: you may be thinking of Sub NoInput and Sub Input which populate during the HFM application startup. Even those subroutines can use GetCell, but the problem is if the cell's contents change after the application starts up, the only way to get Sub NoInput and Sub Input to recognize them is to either restart the application or re-load the rules. Member lists on the other hand don't have this restriction because they execute when a user opens them either directly, or indirectly by using form, report, task flow, or rule, or any other action that uses a member list.
I agree that Financial Reports can use conditional formatting based on cell values too, but the problem with FR is that it has to pull the entity into the report server's memory first before it can suppress the entity. A member list would return to FR only those entities which meet the criteria from the HFM server perspective, so performance might be better.
Also, FR does a poor job managing POV based member lists (ones that use @POV in the member list definition).
- Chris
-
No offense taken, you're completely right. I was thinking about the NoInput routines. Quarantine has definitely melted my brain a little.
-
Thanks both for your help !
-
There are two routines in the member list file: EnumMemberLists and EnumMembersInList. EnumMemberLists is executed once when the file is loaded. EnumMembersInList is executed each time a member is selected.