I'm also experimenting with ways of using gnucash for a member organisation, in my case a local football club with 27 teams across different age groups. We have around 450 current members each year, with a fair amount of churn (about 100 members leave and 100 new members join each year as players switch between clubs in the area, or stop playing and new players start). Each member pays monthly subs so I have a lot of transactions to deal with.
At the moment I have members as assets accounts, e.g. assets:members:david and transactions to income:subs. When members pay, ideally directly into the club current (checking) account, I have the transaction go from the bank account to the appropriate member account, e.g. assets:current assets:current account -> assets:members:david. This way the asset:member accounts show me the transactions for a given member and the income:subs account shows me how much I (should) have received in subs. If members have not paid-up then there will be a balance owed in their asset account. You could have separate income accounts for each destination. So, with the following accounts: Assets:members:member1 Assets:members:member2 Assets:members:memberN Income:destination1 Income:destination2 Income:destinationN And the following transactions: Assets:members:member1 -> Income:destination2 $10 Assets:current assets:checking account -> Assets:members:member1 $10 Assets:members:member1 -> Income:destination3 $20 you would be able to see how much each member has contributed (or at least committed to contributing) to each destination and easily see how much each member owes. I've created a demo gnucash file to demonstrate this and uploaded it here: https://www.dropbox.com/s/ccf3ugufp79miht/membership%20example.gnucash?dl=0 In this example you can see that member 1 has committed to contributing £10 to destination 1 and £20 to destination 2, but has only paid £10 so far, so owes £20. If you look at income:destinations:destination 1 you can see that £25 has been committed in total, and so on. I have no accounting training whatsoever (this is the careful application of brute force and ignorance) so this could be really bad practice, but it does seem to me to be transparent and allows me to easily track where the money is and who I need to chase for subs payments (a significant part of my life now!). David On Fri, 23 Aug 2019 at 18:39, Michael Hendry <hendry.mich...@gmail.com> wrote: > > On 23 Aug 2019, at 14:48, Adrien Monteleone < > adrien.montele...@lusfiber.net> wrote: > > > > The business features certainly offer some perks with respect to > reporting, reminders and info lookups. > > > > I’d probably take that approach in some fashion if I had to tackle the > problem myself. > > > > However, if the only reason you are considering using them is simply to > handle multi-dimensional reporting, consider this: > > > > The Transaction Report (as well as some other reports) can be filtered > (with regular expressions, not just with other accounts) and that report in > particular can have 2 sorting dimensions with sub-totals. One could also > apply a view filter to an account or run a search and then run an ‘Account > Report’ from the result. > > > > For multi-dimensional issues, I’d solve those by using the ‘Description’ > field as one dimension, and the ’Notes’ and/or ‘Memo’ fields as additional > dimensions. (the Action fields might also be useful here) This would be in > addition to the regular ‘Account’ field as the primary dimension. > > > > You might even be able to keep all donations in a single account or a > small handful of accounts, greatly simplifying your CoA and other > organization reports. > > > > Consider booking the donations using the member name as the Description > and putting the destination in the Notes or other fields. You could also > track the sources such as ‘Foundation Dinners’ if you’ll have more than > one, and the need to do so, in any other unused fields. > > > > As long as you are consistent in where the information appears, a > semi-custom filtered report could be achieved. > > > > The drawback to regular transactions would be issuing reminders, but > that could be accomplished by employing a ‘receivables’ type account that > would be filled with scheduled transactions for each member, and then the > actual payments would reduce those balances as transfers to some other > account to accumulate donations YTD. (this would be a second layer of > transaction info, not the tracking of actual funds moving around) You could > then run a report based on such accounts. > > > > The only drawback to this approach would be if you also needed GnuCash > to double as a member ‘database’ with address, contact info, etc. In that > case, making all members ‘customers’ might be the better route because such > information already has a place to be stored without having to shoe-horn it > into individual transactions. (but even that would be possible, and > auto-fill will greatly assist with data entry) > > > > > > Regards, > > Adrien > > Thanks, Adrien. > > Plenty of food for thought there! > > I’m not desperately keen on using free text in the Description and Notes > fields because minor variations in spelling might well cause a transaction > to be missed, but I can see that this would greatly speed up data entry. > > I’ve already set up an Asset account called “Members’ Commitments”, which > will be populated (e.g.) as members commit to being paying guests at a > Foundation Dinner, and then reduced to zero once a suitable date has been > negotiated, the meal eaten and payment received. > > I can foresee a lot of revisions going on until I settle down on a > workable method. > > Regards, > > Michael > > _______________________________________________ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > If you are using Nabble or Gmane, please see > https://wiki.gnucash.org/wiki/Mailing_Lists for more information. > ----- > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. > -- David Whiting _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.