Differences between revisions 9 and 10
Revision 9 as of 2013-12-09 11:37:52
Size: 3822
Editor: SamMoore
Comment: Stupid markdown.
Revision 10 as of 2014-03-22 00:41:09
Size: 6977
Editor: combtail
Comment: New ledger entry instructions for dispense update
Deletions are marked like this. Additions are marked like this.
Line 27: Line 27:
  * You can get cash counting notepads from Guild finance that will help you easily sum the cash (check if there's one already in the filing cabinet first though)
  * Sort the coins into the coin bags provided by the guild or westpac
  * After checking these amounts against dispense (see below), deposit amounts as you see fit into the Guild or Westpac accounts (Westpac is generally easier to manage the money with)
Line 28: Line 32:
  1. Record (in GNUCash) and zero all the sales accounts in dispense (`>sales:*`, `>donations`).
   * Lump the week's drink/snack sales into one entry in GNUCash, but read the cokelog and give sort out the `pseudo:` item sales. This includes usernames for memberships/shirts (and definitely for clue) and reasons for donations.
   * `dispense acct | grep internal`
  1. Compare the current dispense liability with the value in GNUCash, this is how much money was added to dispense in the last week.
   * Either use a script that sums all user balances, or use the -ve of `>countersum` after you've cleared the sales accounts.
   * If there is an imbalance, grep the cokelog for ': add', and find entries since you last balanced the books that are not the money going into the safe. (These may be reimbursements or westpac adds)
   * Actually, checking the log is always an idea, you never know when two imbalances will cancel themselves out.
  * Run {{{dispense acct | grep internal}}} on motsugo, mantis or mussel to get a list of the "accounting" accounts, which will look something like this:
{{{
>additions : $ -32.00 (internal)
>countersum : $-2724.68 (internal)
>donations : $ 0.00 (internal)
>sales:coke : $ 21.93 (internal)
>sales:door : $ 0.00 (internal)
>sales:pseudo : $ 5.00 (internal)
>sales:snack : $ 42.00 (internal)
}}}

  * '''>additions''' is the account which '''shows the negation''' of how much money has been added or taken out of dispense since the last time the additions account was zeroed. If somebody has somehow managed to withdraw money from dispense than has been added, the value will actually be positive. This figure is only affected by {{{dispense acct <user> [-+]<amount>}}}, but that could be cash in the safe, money added via EFT, or non-existent money that the system has created to give to new users. There are also occasional mismatches where somebody has misused adding money to an account instead of {{{dispense refund}}}. Once you subtract what has been added via EFT and created for new users, you will be able to tell how much money should be in the safe. If this figure doesn't match what's in the safe, you need to find out why. Sometimes it'll just be a donation of a coin that somebody found on the floor (woohoo), but if there's money missing you must bring this to the attention of committee.
  * '''>donations''' is fairly self explanatory - it gives a sum of any {{{dispense donate}}} transactions
  * '''>sales:door''' does nothing and will continue to do nothing unless we decide to charge people to open the door :)
  * '''>sales:coke, >sales:pseudo and >sales:snack''' represent the sum of any sales in each category
  * '''>countersum''' is the sum of all the user and internal accounts. When the other internal accounts have been zeroed this account reflects the current dispense liability

 What to do with the internal accounts (in order):
  1. Change the sign on the additions value and record that value in the "dispense liability" ledger. Split the transaction as necessary in the "transfer" column of gnucash to reflect what has gone into Westpac, in the safe, or new member expenses.
  1. Enter the value from the donations account in the "dispense liability" ledger with the transfer being to "gifts and donations received"
  1. Enter the value from the coke sales account in the "dispense liability" ledger with the transfer being to "drink sales"
  1. Enter the value from the snack sales account in the "dispense liability" ledger with the transfer being to "snack sales"
  1. Work out what the pseudo sales are for - they could be for items or at-cost services, and may come under revenue or expenses depending on what they are. "Telephone" for example, would get added as its own entry in the "dispense liability" ledger, with the transfer being to the "phone bill expenses" ledger. Look at the existing entries and use your head to work out where the others go.
  1. Use {{{dispense acct <account name> =0 "treasurer: reset"}}} to set the additions, donations and all the sales accounts to zero. Re-run {{{dispense acct | grep internal}}} and check the value of the countersum; if this value does not match the balance of the "dispense liability" ledger, something is wrong and you need to work out why and fix it.
  1. Run {{{dispense acct \<countersum =0 "logging"}}} . This causes the current dispense liability to be logged in the cokelog, and makes things much easier to track down at a later date should it be necessary. Don't worry, it doesn't actually affect the countersum value
 
Line 38: Line 61:
  1. Investigate and fix discrepencies   1. Investigate and fix discrepancies

Don't.

cat.svg

For those who do

Accounts Overview

  • Guild Account - Money held by Guild Finance for the club. Can have a good interest rate if > about $2000, but no EFT available.

  • Westpac Everyday - Nice general purpose account, with EFT but almost no interest rate.
  • Business Cash Reserve - High interest rate if no money withdrawn within that month (supposedly)
  • Term deposit - ~60k for 60 months at 6%, see investments policy (that seems like quite the evil figure)

Hints and things [TPG] will raeg about

  • Balance dispense every week during semester, means less work to balance it.
  • GNUCash has 'split transactions' (transactions involving more than two accounts). Use these when a single transaction in westpac is for multiple purposes.
  • A small positive safe inbalance (safe account goes negative in GNUCash) is not a really bad thing, but attempt to find the cause.
    • A negative safe imbalance (safe account has money in it once weekly deposit has been made) is a BAD thing. It means we've lost money that should have been in the safe.

Committee Meetings

  • Report account balances (please make sure these are up to date, if possible)
  • Preferably clearly communicated or in writing, for the benefit of the minutes and our obligations

  • Report any outstanding payments (reimbursements, things on order, etc.)
  • Spending is good, keep an operating capital, and the required re-investment, then spend the rest on new/upgraded hardware :)

Weekly Actions

  1. Count the safe
    • You can get cash counting notepads from Guild finance that will help you easily sum the cash (check if there's one already in the filing cabinet first though)
    • Sort the coins into the coin bags provided by the guild or westpac
    • After checking these amounts against dispense (see below), deposit amounts as you see fit into the Guild or Westpac accounts (Westpac is generally easier to manage the money with)
  2. Balance dispense
    • Run dispense acct | grep internal on motsugo, mantis or mussel to get a list of the "accounting" accounts, which will look something like this:

>additions     : $  -32.00 (internal)
>countersum    : $-2724.68 (internal)
>donations     : $    0.00 (internal)
>sales:coke    : $   21.93 (internal)
>sales:door    : $    0.00 (internal)
>sales:pseudo  : $    5.00 (internal)
>sales:snack   : $   42.00 (internal)
  • >additions is the account which shows the negation of how much money has been added or taken out of dispense since the last time the additions account was zeroed. If somebody has somehow managed to withdraw money from dispense than has been added, the value will actually be positive. This figure is only affected by dispense acct <user> [-+]<amount>, but that could be cash in the safe, money added via EFT, or non-existent money that the system has created to give to new users. There are also occasional mismatches where somebody has misused adding money to an account instead of dispense refund. Once you subtract what has been added via EFT and created for new users, you will be able to tell how much money should be in the safe. If this figure doesn't match what's in the safe, you need to find out why. Sometimes it'll just be a donation of a coin that somebody found on the floor (woohoo), but if there's money missing you must bring this to the attention of committee.

  • >donations is fairly self explanatory - it gives a sum of any dispense donate transactions

  • >sales:door does nothing and will continue to do nothing unless we decide to charge people to open the door :)

  • >sales:coke, >sales:pseudo and >sales:snack represent the sum of any sales in each category

  • >countersum is the sum of all the user and internal accounts. When the other internal accounts have been zeroed this account reflects the current dispense liability

  • What to do with the internal accounts (in order):
    1. Change the sign on the additions value and record that value in the "dispense liability" ledger. Split the transaction as necessary in the "transfer" column of gnucash to reflect what has gone into Westpac, in the safe, or new member expenses.
    2. Enter the value from the donations account in the "dispense liability" ledger with the transfer being to "gifts and donations received"
    3. Enter the value from the coke sales account in the "dispense liability" ledger with the transfer being to "drink sales"
    4. Enter the value from the snack sales account in the "dispense liability" ledger with the transfer being to "snack sales"
    5. Work out what the pseudo sales are for - they could be for items or at-cost services, and may come under revenue or expenses depending on what they are. "Telephone" for example, would get added as its own entry in the "dispense liability" ledger, with the transfer being to the "phone bill expenses" ledger. Look at the existing entries and use your head to work out where the others go.
    6. Use dispense acct <account name> =0 "treasurer: reset" to set the additions, donations and all the sales accounts to zero. Re-run dispense acct | grep internal and check the value of the countersum; if this value does not match the balance of the "dispense liability" ledger, something is wrong and you need to work out why and fix it.

    7. Run dispense acct \<countersum =0 "logging" . This causes the current dispense liability to be logged in the cokelog, and makes things much easier to track down at a later date should it be necessary. Don't worry, it doesn't actually affect the countersum value

  • Balance westpac/guild
    1. Get a statement from Guild Finance (usually while depositing the safe money)
    2. Compare the statement, and westpac online records, with GNUCash records.
    3. Investigate and fix discrepancies

Semester Grants

Either using Neon or a library scanner, scan all recipients from the semester to a PDF. Use the .odt template from committee docs instead of a printed coversheet. Using GIMP to number the receipts works nicely too.

Phone Bills

Pay phone bills from the Guild account. See previous entries in the withdrawals book for how to do it.

Where do the GNUCash records live?

 /home/other/committee/GNUCash . Try to keep them there.

You can use X forwarding from a server that mounts /home and has GNUCash.

Or you can use sshfs.

  1. Find a linux machine with GNUCash installed. Currently Clownfish works.

  2. (First time only) make an empty directory. mkdir GNUCash or whatever you want to call it.

  3. Run in terminal: sshfs ssh:/home/other/committee/GNUCash GNUCash

  4. Open GNUCash. Navigate to the directory. Do the accounting.