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 > On Aug 23, 2019 w34d235, at 3:24 AM, Michael Hendry > <[email protected]> wrote: > > As previously mentioned on the list, I’ve just become Treasurer of our local > Rotary Club, which has two sets of books, one relating to the business of > running the club (annual subs, insurance, secretarial support, etc) and the > other to the club’s charitable activities. > > The club part is straightforward, and has no need for the business features. > > The charity accounts are different in that although the bulk of the income > comes from the general public, some of it is extracted from members with > particular charitable destinations in mind. > > For example, the price of the meals at meetings is rounded up to the nearest > pound, and the remainder is earmarked for “Charity Choice”. Not all members > attend every meeting, and some members skip the meal and make a token payment > to Charity Choice. There are several such income headings to deal with. > > The difficulty is that it must be possible to document each individual > member’s contributions over the year in order to make a Gift Aid claim to Her > Majesty’s Revenue and Customs (HMRC), which tops up the members’ > contributions by 25%. > > I have set up a series of accounts of the form: > > Income:Destination1:member1 … Income:Destination1:memberN > > … > > Income:DestinationX:member1 … Income:DestinationX:memberN > > which allows me to report on the total income for each destination easily, > but makes it harder to pick out individual members’ contributions. > > Changing the hierarchy to Income:memberN:DestinationnX would make it easy to > pick out the Gift Aid detail per member, but harder to report on the total > raised for each destination. > > It occurs to me that it might be easier to treat members as customers, who > would “purchase” Gift-Aid-Claimable (as well as non-claimable) items. In the > case of “Foundation Dinners”, members commit in advance to pay for a meal at > another member’s home - this commitment would be equivalent to an order > payable on delivery of the goods. I wouldn’t anticipate issuing invoices, but > a monthly list of defaulters would allow me to issue gentle reminders. > > It might well be easier to deal with some of these reporting tasks using > spreadsheets, but I’d much prefer to have a single point of entry for each > transaction. > > It’s been the usual practice for Treasurers to serve for five years, so > slow-but-sure is preferable to fast-and-dirty. > > I’d appreciate the advice of the list - especially from anyone with practical > experience of my situation. > > Regards, > > Michael _______________________________________________ gnucash-user mailing list [email protected] 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.
