Get all Revenue Accounts using XFBR
Guys , Any idea on how to write a business rule that retrieves a list of all Revenue Accounts .Thanks
Forum Discussion
Do you really need a rule for this...? It can be done with a simple expansion: A#Root.Base.Where(AccountType Contains Revenue). If you really want a rule, just wrap that in a Brapi.Finance.Metadata.GetMembersUsingFilter call.
When the documentation fails to provide enough information, yes.
3 people from my team worked on this and were unable to come up with working syntax for a member filter. 3 more experienced people in this thread failed to find your solution. How many more experienced people in this forum read this and said "I don't know"?
The syntax you provided follows no standard and looks like a sentence. Who would guess that?
We don't want to write rules to do simple tasks. We have no choice in situations like this. Documentation and examples are at the top of my toolbag. If I coded it where code isn't necessary, its because I couldn't find an example nor documentation that covers the specific requirement closely enough to be interpolated into an answer.
Hey Robb,
Sorry, my post didn't mean to criticize your approach, and I apologize unreservedly if it came off like that in any way.
I agree wholeheartedly that the docs are all but complete. The company has been focused for so long on ruthlessly delivering features, release after release, that docs have often struggled to keep up; we try to fix that every day (here, in Navigator, on the blog, in the books, etc) but there is always more to be done. Also, the platform is so big and flexible, I typically joke that "in OneStream, there are always 2 ways to do anything, and often way more"; so people come to similar problems from multiple angles, and that's totally fine.
Going back to the problem at hand: as you might have realized, I love coding. My original background is in webdev, I used to run a Python user group, and my first instinct when trying to solve a problem is to reach for a text editor. OneStream is great for that; as you know, it's really hackable in so many ways, so chances are you can solve everything with a sprinkle of code.
However, a large amount of our users are not coders, and would rather stay that way. We try hard to cater to them, making things easier and more maintainable by non-coders. This is why the team built Member Filters that are as powerful as they are: they knew that older products forced accountants to write VBScript simply to define fairly straightforward lists, and that was a pain point for a lot of people. In an ideal world, users should not need to write code just to build a list and look at some numbers in a CubeView; and where we fall short of that vision, there is work to be done.
This is why we try to promote Member Filters where possible. They are easier for non-geeks to grok, tend to be more maintainable by admins, and their performance is more predictable than most custom code. They also read almost like English, yes; for non-coders out there, that's a feature, even if it can be a bit surprising for the likes of us.
Unfortunately, as you say they are clearly not as extensibly documented, in their advanced configurations, as they should be. There are a few examples in the Sample tab of Member Filter Builder but that's just scratching the surface. This thread is an indication that there is space for better communication of these features, and I'll take that on board; keep an eye on our channels (blog and Navigator) for something related to this, sometime in the future.
I hope this makes sense. All the best,
JackThanks Jack. I particularly like the Heinlein reference. Yes, please keep on keepn' on. There's always going to be pain points. They're relative. OS is now so feature rich, its docs & examples have become a pain point. Its a classy problem.