On Thu, 30 Apr 2020 at 05:02, Adrien Monteleone <adrien.montele...@lusfiber.net> wrote: > > That’s another valid and safe option. > > The OP noted 1000+ accounts to migrate though. So even 1 transaction per > account would not be fun. > > On the upside, I discovered that accounts with zero transactions can have > their type changed. So if the OP had some empty accounts, those could be done > rather painlessly. (if slowly via GUI) > > I’d recommend not to retain individual A/R accounts per customer. While there > are some advantages to doing so, I’m not sure GnuCash *needs* this treatment. > It would be wise to investigate the ‘why’ of the individual accounts before > the OP proceeds with a change. > > Some apps (and certainly paper books) almost necessitate sub-accounts per > customer. (and per Vendor under A/P) But GnuCash does not and can handle > tracking amounts owed or owed to with a single A/R and A/P account. One can > always employ special or other A/R or A/P, but they may not be as necessary > as one might think. > > Regards, > Adrien >
The "why" has two components: 1) what I am trying to model, and 2) the circumstances and context around when I set things up. 1) What I'm trying to model These are the accounts for a local football club that consists of about 450 members playing for 25 teams. Each members pays annual subs, the amount of which is different for each team because there are some costs that are generic across the club and others that are options selected by the different teams. Members pay a (re)sign-on fee at the beginning of the season, then six monthly payments. I then spend the rest of the season chasing those who have not kept up with payments. Most members now pay by bank transfer. Each year about 100 members leave (they stop playing or join another club) and about 100 new members join. Each team seeks sponsorship and has its own account within the accounts and can spend that money how it likes (more kit, equipment, BBQ, whatever). I have placed these accounts in Liabilities. I need to be able to produce statements (transaction reports) for each member each month and for each team, so each member needs to be associated with a team. Grouping members by team in the chart of accounts makes it easier to find the relevant accounts quickly because I normally need to deal with issues team by team. 2) The context The context for when I set this up was: I had just taken over as treasurer after a year when the accounts had been managed very poorly. There were many disagreements about what had been paid (at that time many transactions were in cash, collected by team managers and passed on to the treasurer). There was no formal list of members so it was hard to know who should be paying. This was after six years where the previous treasurer had produced no balance sheet or profit and loss statement, just an annual listing of all cheques written and the bank balance. I needed to set something up quickly to restore confidence. I knew of gnucash but have no training in accounts. I met with the parent of one player who was an accountant one evening over a few beers and we talked about how to set things up (I suspect this is not the standard way that accountants are trained). I made notes, and read (some of) the gnucash manual but there were clearly many things I did not fully understand, one of which was the correct way to set up the members in gnucash. I recognise now that the members are effectively customers, but I don't think I could make gnucash work for me to deal with so many customers each month. If I have to process payments for each customer it would take too long. I need to be able to produce member and team statements and I don't think I can do that for batch of customers. Treating them as people who owe money and simply creating asset accounts works because the import matching works well for matching payments to members and I can create a transaction report that I can then post-process into individual statements with a script. So my fundamental mistake was creating these accounts under A/R when I should have created them under assets. Getting them out is now my mission. David _______________________________________________ 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.
