I am not an accountant. I don't think about the money going in and out of my business in the same way as an accountant would. Sadly my accounts package (and most others) were designed to be operated by people who do think like accountants. The myriad forms from Whitehall are designed to be easy to process by HMG, rather than easy for non-experts to fill in. In addition to the complexity of these forms, the same (to me) items are called different things on different forms and indeed aren't necessarily the same thing even if two different forms call them the same thing.
I, like many other small businesses, think about the items I spend money on in terms of those items. I buy tyres for my motorbike, I don't place an item on the transport/maintenance folio.
This paper discusses a way of structuring an Open Source accounts package to present itself in plain terms to the end user, while breaking those numbers down into the correct boxes for both audit (if required) and more importantly into the plethora of different views and subtle shades of meaning required for Government forms.
When I buy something, I either do so as an addition to an existing piece of inventory, like new tyres, or as a new item in it's own right. The package should reflect this. When I buy a printer cartridge, this would be 'Given' to the existing 'Downstairs Printer' item. Tyres would be given to the 'Motorcycle' item. When the bank statement turns up, I would reconcile the entries and confirm the expenditure in the normal way.
The act of creating a Motorcycle item of a given cost at a given date would bring in a set of configurable behaviour that ensures the input numbers (petrol, services etc) get assigned to the right slots.
The trick here is, of course, the magic configuration behind these items; the process that takes tyres and petrol and assigns them to the relevant slots ready for the forms and the audit. The first stage would be to define the language used to configure the objects, such that they behave properly with respect to income tax, VAT, NI, Corporation Tax etc etc etc. The second would be to write the definitions for a set of standard objects used by small businesses.
All the subjects that have been discussed so far are in the realm of the software engineer, with one notable exception; the actual configuration of these standard objects. The language used to define them will have to be structured to take account of the what will have to happen to the input numbers of course, but the actual definitions themselves will be the most complex job of all.
This is where the Government themselves could and probably should step in. The configurations are attempting to encapsulate the needs of their systems. The best people to distil out the object behaviours, are those that understand those behaviours.
The fact that the definition language is defined though an open, royalty free standard, reusable by any other package (whether open or closed source) ensures that the Government can't be accused of favouring one company over another. The fact the accounts package is also Open Source, policed by the General Public License ensures that it is freely available to anyone who wants to use it, at no cost.
Linux is an operating system used to run a rapidly increasing percentage of business systems. It is also subject to the General Public License. Linux has been in the ascendant for a number of years now. In addition to it's strong position in the server room, it is seeing recent rapid gains on the desktop as well. A number of correspondents have reported that the biggest block to it's adoption in the small business market is that a central piece of functionality is missing; an open source accounts package. Such functions as web browsing, email and office suite are already covered by high quality open source products.
Does this make sense to you?
This short page is a request for comment from those that might be interested in such a package. Please send your comments to:
Andrew Meredith <andrew@anvil.org>