No love for this thread, huh?
@Josh Weinberg @Clement Marlin @David Cornfield @Christine Sawyer are any of you willing to share your coding dimensions or comment on mine? Any general thoughts on how you decide what information is actually worth collecting? Has anyone found time to reflect and ask yourself this question?
There are other codes that are extremely relevant for subledgers and other systems, like vendor and payroll records.I'd never differentiate payroll by employee in the GL, but of course then you need a payroll system with good information/analytics platform so that you can dig into detail by head. I've considered bringing in actual payroll data in my Vena personnel cube, to do variance analysis there. The obstacle for us is that we do a great job modeling payroll on an accrual basis by month, but variance analysis of accrual basis budget to cash basis payroll is a great way to waste a lot of time for little benefit. We haven't yet found a very good way to model the budget on a biweekly cash basis to match our payroll cycle. I guess we could create an alternate period hierarchy and use that for the cash basis budget...So, my first thought is you could look at your list to see what you can and maybe should combine. Then I'd look at what is in subledgers/other systems, and can be kept out of the GL but analyzed elsewhere. Personnel is a great example. I have an employee dimension in my personnel cube in Vena, but that employee dimension is most emphatically not in the financial reporting cube, and never will be. I don't know if this is any help at all. I hope it is!
Thanks for not digging in deep here ;) But actually this is very helpful!I think you're totally right that we should look to use a single code for multiple purposes rather than having separate codes where one is helpful for some, but not all teams. Also good call on reducing the GL/Natural accounting code list! We actually went through an exercise to do this about 4 years ago and reduced our Expense GL's from ~200 down to about 60. I think we've since crept back up to about 70, but we have more guidance in place to decide when a new GL is truly necessary and a culture that values keeping a smaller list for ease of use across our tools. Budgeting and expensing at an Employee level is also something that we're open to re-thinking. We often need this to make sure we're charging the right people/effort/amount to a grant, but we also have ~40-50% of our staff that are solely funded from unrestricted resources so there isn't a ton of benefit to keeping their information at such a detailed level.Plenty to think about from your response. Hope others are able to share their perspective as well!
This dimension carries the P&L ("Net Income" parent below), Balance Sheet and Other Account roll-ups used in the templates and reports from the Foundation library.
This dimension carries the Entity roll up, used to differentiate the client legal entities ("ABC corp Canada", "ABC corp US", "ABC corp consolidated", etc)
This dimension carries the Department roll up, used to differentiate the different departments / operating units
Those dimensions are placeholders and can be re-used to carry other client dimensions required to support the implementation ("customer", "product", "project", etc.)
Grant, Project, Restriction are common NFP dimensions which can be changed as required
This dimension carries the calendar year roll up (flat list of years)
This dimension carries the Full Year and Year-to-Date monthly roll ups
This dimension carries the different scenarios used to differentiate Actuals versus Plan versus Archive Scenarios (i.e versionning of the Plan scenario for closed periods).
This dimension supports the currency conversion module (Currency). It will carry by default a "Local" member.
This dimension carries all the measures used across the templates and reports of the [Foundation] library
Plan To GrowVena Academy