Replies: 11 comments
-
|
Hi! Thanks for filing this issue to detail your plans. The first reactions you've triggered:
With these first remarks off my chest, I'll come back later and see if we can figure out which steps would be required to realize your requirements in the software and which ones depend just on configuration. Then we can create a series of issues each of which can be implemented as stand-alone units -- where the implementation of the total of them would mean we've got sufficient functionality on board to support NFP accounting. |
Beta Was this translation helpful? Give feedback.
-
|
Re 3: By "split" I simply mean one line in the ledger, i.e. a single credit or debit on its own. (As opposed to an entry, which is a balanced collection of splits.) Re 4: Any guidance, or pointers to where I can find the guidance, on how to make the units in a Reporting Unit dimension into a hierarchical structure would be very welcome. Re 5: Using hierarchy nodes in the filters will of course be valuable. But it's not sufficient. The relevant structure is not a strict hierarchy. For example, every Fund is either Unrestricted or Restricted, and it's either Operating or Capital, but all four combinations are possible. So either a report on all Restricted Funds or all Capital Funds, both of which you routinely need to do, is going to slice across the hierarchy, no matter how you organize the hierarchy. That's why some systems have both tags and hierarchy. But I wasn't proposing that for LedgerSMB, at least not at the moment (unless you prefer tags to what I propose below). I was thinking of just encoding these aspects in the Control Code and allowing (in essence) simple "glob"-style patterns in the filter, e.g. Fund 1000 Unrestricted Operating (the so-called "General Fund" of 99% of US NFPs) could have control code "UO1000" and then I could report on "U*" or "?O*". But also I think it would be worthwhile to simply allow an arbitrary list of control codes and/or control code patterns (if that's an acceptable innovation to those who steer the project) to be included by a filter, because you never really know in advance just what grouping you might want to see in a statement, depending on the business need. For example, suppose a donor gave different grants all with different restrictions. Those would end up in potentially very disparate places in the Fund hierarchy, and it's unlikely the Control Codes will be articulated enough to encode the donor for each Fund, but yet you might well want to produce a consolidated financial statement for that donor accumulating all of the Funds donated to. Re 6: Indeed, I was absolutely planning to add a Function dimension. That's why NFPs absolutely require accounting packages that allow at least two arbitrary dimensions in addition to Account: Fund, and another one variously called Function or Purpose or Cost Center or whatever. And the Function dimension should only apply to Income and Expense splits (so there should not be an entry box for Function on the debit side of an A/R or be a valid filter for a Balance Sheet, which is why that needs to be an option as opposed to being simply the case for all dimensions). So yes, one of the items that brought LedgerSMB to the top of our list for a new general ledger system was the flexibility in organizing dimensions. Re your last paragraph:
I realize that overall these (and several others besides) are a lot of work, but I don't have to do them all at once, and I am quite dedicated to the idea of having a free as in both beer and speech out-of-the-box solution for NFPs, who I feel are currently very much exploited by FP accounting firms diverting precious public money that could be used for program. Whatever package we ultimately adopt, with LedgerSMB being currently the leading candidate, if I can get it there I will very definitely promote it as a free easy to use solution in the US not-for-profit community. |
Beta Was this translation helpful? Give feedback.
-
|
Some details as to how you can create a hierarchy in reporting units: when you define a unit (through System > Reporting units > Add Unit), you can select a Parent. That parent is a unit that was created in the same unit-dimension earlier. By adding the right children to the right parents, you can build up a hierarchy. |
Beta Was this translation helpful? Give feedback.
-
|
The code for the PNL is here https://github.com/ledgersmb/LedgerSMB/blob/master/sql/modules/PNL.sql#L161 ; for the balance sheet, the code is here : https://github.com/ledgersmb/LedgerSMB/blob/master/sql/modules/Report.sql#L652 . Does the above help? |
Beta Was this translation helpful? Give feedback.
-
|
BTW, the checkmarks next to the reporting unit dimensions can be used to select on which type of screens the dimension will be shown: AR, AP, GL, etc. There's currently no distinction between "Balance" or "PNL" accounts (which doesn't mean we can't add that, though). |
Beta Was this translation helpful? Give feedback.
-
Yes, I saw those checkmarks. And I have to admit that I was initially planning to just add a checkmark for "put the dimension everywhere" to add the dimension to the other sides of A/R and A/P entries. But you're right, it would be better to have two checkboxes, one for "Balance" accounts and one for "Delta" accounts ("PNL" being a dirty word in the NFP world ;-) ). But the logical consequence of that is in the GL screen (if the dimension is enabled there), then the dimension entry box has to start out greyed out before the Account is entered, and only be active if/when an appropriate type of account is entered. That should be doable, but are you/the design supervisors (if that's not just you) OK with that sort of change? |
Beta Was this translation helpful? Give feedback.
-
|
I'm proposing that we add 2 extensions to the reporting unit framework:
Yes, this adds complexity to the software and we should look at the consequences on a screen-by-screen basis to do a quick/initial assessment of the impact (before diving in). But in general I think these are very powerful additions to the reporting units framework. @ylavoie, @sbts, @freelock: what do you think? |
Beta Was this translation helpful? Give feedback.
-
|
Re 1) Yes, of course I would label the checkboxes as "PnL" and "Balance" (or "Bal" I suppose depending on real estate). I do understand that the bulk of users are not from the NFP accounting world, as it's a niche. But more seriously, just to be certain, the proposed behavior is that if "Balance" is checked, then that dimension's entry box would appear e.g. on the AR debit line, even though right now no dimension ever appears on that line? (That's what I would suggest, just want to make sure we are on the same page). And I am also assuming that
is also something you all are amenable to? In any case, I will start my efforts on (1) as that's the most critical for our adoption of LedgerSMB. [And the first bit of that effort will be to do the study you suggest of the screen-by-screen effects of the proposal (1) and post it here.] |
Beta Was this translation helpful? Give feedback.
-
|
Have made some effort to try to catalogue all of the ramifications of (1) as promised, but ran into #4754 while exploring the effects on the various AR screens. Will try to pick this up as feasible. |
Beta Was this translation helpful? Give feedback.
-
Generally accepted accounting procedures for US not-for-profit (NFP) entities require that all of the different accumulations of monies, assets, liabilities, etc., with distinct donor-imposed restrictions on their use be booked in what amount to separate completely self-contained ledgers, normally called Funds. And indeed, LedgerSMB has a default Reporting Unit dimension called Fund, apparently for that very purpose. However, the attributes of Reporting Units are not flexible enough to configure this dimension to serve all of the requirements of Fund accounting.
I am filing this issue report to identify the two initial most critical extensions needed to Reporting Units for US NFP accounting:
In A/R, when an entry is made, the receivable asset created must be credited to a Fund. Right now, even when all option boxes are checked for Fund, there is no field to enter the Fund for the debit side of an A/R entry. Similarly, there seems to be no way to enter the Fund for the credit side of an A/P entry. There needs to be an option under Reporting Units which allows you to specify that a dimension applies to all splits, regardless of the type of entry, type of account, or side.
It is critical for NFP reporting to be able to produce balance sheets of just the assets in a specific Fund or group of Funds. Currently, the Income Statement report allows Reporting Unit filters by selecting a single unit of a dimension. The Balance Sheet report needs to allow similar filters by those dimensions which apply to all splits, as in (1) above. Further, Reporting Unit filters need to allow for not just a single unit of a dimension, but reasonably arbitrary collections of included/excluded units. To this end, it should be possible to specify such filters by some sort of pattern on the Control Codes of the units, and/or have an explicit hierarchy or categorization among units of a dimension. (For example, Funds are either Unrestricted or Restricted, and they are also generally either Operating or Capital. NFP accounting also generally has a dimension applying to income/expenses only which might typically be called Function, and Functions are either Program or Support, and under Support they are divided into Fundraising and Administrative. It is also common for NFPs to have major divisions among Program Functions, e.g. Exhibitions, Education, Grants, etc.)
I will attempt to implement these extensions to the current Reporting Unit facilities.
Beta Was this translation helpful? Give feedback.
All reactions