Finance¶

Introduction¶

The budger and spending are stored in Git repositories containing various YAML files describing invidiual budget lines.

Budgeting¶

The SR budget is a high-level description of how our money is allocated, including that which has already been spent.

The budget consists of a hierarchy of entries. Each entry allocates a specified amount of money to some specified purpose. Each entry contains a description of what these funds are for, along with some justification for the value of the entry.

See also Purchasing for a description of how we operate on the budget.

Embracing Change¶

Our budgeting processes embrace the fact that our plans are going to change. Unspent budget can be reallocated to new purposes through defined, and transparent procedures.

The Future and the Past¶

Our approach to budgeting is somewhat different to the approach that some people use. Instead of our budget just being a document that at some point in time was the plan for spending, our budget is always consistent with our spending plans. Our budget is updated throughout the year: before a spend can be made, there must be a suitable entry in the budget from which it can be made.

Furthermore, spent budget entries don’t ever disappear. They stay around for the rest of time. This means that budgeting in the future can be grounded on a solid base of real data from the past. It also means that our databases of spends never refer to budget entries that no longer exist.

So, as well as being a plan, the budget is also a historical database.

Implementation¶

The SR budget is stored as a git repo that contains a collection of .yaml files. This allows each item to be provided in great detail, and it is abundantly clear who created what things.

Out income and bank balance at the start of the plan are stored as a couple of lines in check in the root directory.

Folder Shape¶

The budget.git repo contains individual budget items (or services) in files whose path describes them. Each folder represents a grouping of things. Thus, we have:

sr2012/
    clothing.yaml
    competition/
        arena/
        cable-ties.yaml
        prizes.yaml
        trophies.yaml
        etc.
    kickstart/
    kits/
    mentor-travel.yaml
    etc.
sr2013/
    etc.

File Shape¶

Each of these YAML files must be formed in the same manner, and must have certain elements. For instance, this is one revision of clothing.yaml:

summary: T-shirt and other forms of clothing we might buy

# Cost of the item
cost: 400

# Long description
description: >-
  We spent £480 on t-shirts last year. We still have a few left over so if
  we do get some more this year we won't need as many.

# Whether the item/service can only be used once
consumable: false

summary

This should be a brief summary of the item. Don’t include “Cost of”, which is pointless.

cost

The cost of the item, including delivery and VAT. Ideally you should find a supplier that we can use, and use their normal price for the number we need—don’t expect that we’ll be able to order the item on the special deal you’ve found (but do mention that this is possible in the description).

description

Detailed description of:

The item, including a part code.
Why we need it.
How you reached the cost you’ve assigned. You should include links to the supplier’s website and/or other contact details if they’re not a web-based company.

consumable

Whether the item can only be used once. This is mostly aimed at use in the budgets that we send to sponsors, but also has value outside this context.

Purchasing¶

If you wish to get a product or service ordered then please follow the procedure outlined on this page. This procedure is designed to maximise the transparency of purchasing and also to ensure that we have control over our spending at all times.

Request an order/service through trac by creating a ticket with the component set to Purchasing. See the Purchasing Tickets section for more information.
1. If the requested purchase does not go over the specified budget line by more than 10% then it can continue. Go to step 2.
2. If the request purchase does go over the specified budget line by more than 10% the request is put on hold. A change the budget must be made if this purchase is to continue. This involves getting the steering committee to vote for the change. See Budget Modifications for further details on this.
3. The new budget has to be accepted by the steering committee. If it is not accepted then the requester/treasurers can revise the changes and try again. The purchase request will be denied if this stage cannot be passed.
The treasurers agree the request is valid (by at least two treasurers “ACK”ing the ticket).
Purchase occurs. Purchasing ticket updated with relevant information.
If physical assets are being purchased they are now added to the inventory.
Receipts are added to the purchasing ticket.
1. If the receipts contain any sensitive data (your credit card number, for instance), then you may (you probably should, since trac is public) encrypt the attachments using the treasurers’ PGP key.
The inventory is updated once the assets are delivered.

Purchasing Tickets¶

When requesting a purchase a trac ticket must be created outlining all of the details of the request. This ticket must state the following things:

The items/service to be purchased
Where the items/service are to be purchased from
The cost of the items/service
The associated budget line for the items/service
A delivery address (This can just be XXXX’s house and the actual address can be sent privately to treasurer@…)
If any of these details are missing then the request will be delayed while all of the information is collected and recorded on the ticket.

The ticket is also used to track the status of the order: order numbers/parcel tracking numbers are to be added to the ticket as comments. Any quotes/invoices/receipts are to be attached to the ticket, they can be encrypted using the treasurer public key (attached). All data relating to the order should be attached to the ticket; for example, if PCBs are being ordered the gerber files should be attached.

Budget Modifications¶

Sometimes the budget has to be modified. To get a change to the budget through, the following must happen:

Make sure you’re familiar with how our Budgeting works.
Push a patch against budget.git into gerrit.
Wait for a majority of the steering committee to review your patch. If a steering committee member is proposing the change, they cannot participate in the vote. If this happens it will be merged.

Spending¶

spending.git contains details of all of the spends that we have done throughout the last year.