Depecuniae: Modules and Layers

In order to tackle a big project I like to have a clear picture of what I’m trying to achieve. I won’t get too hung up on what’s missing or what’s in the wrong place at the moment.

This picture shows coloured layers with module assigned to each layer. In general I’ll try to work outwards and complete one layer before moving on to the next. This picture will change over time as the system develops.

Within each module I will produce an overview and break it down into a series of user stories.

The System layer is required to hang the rest of the system on.

The Analysis layer contains the system’s central data management logic. All other ledgers revolve around the nominal ledger, the cashbook and the analysis engine.

The Transaction layer will define the interfaces into the nominal ledger and cashbook; input processing, control and reporting will be covered here.

The Business layer contains the non-accounting sections of the system. They are more about business processes and there may be alternative version of each module required to suit given situations.

I will start on the System layer.

Accounting standards

In manual bookkeeping values are entered into columns labelled DR (debit) or CR (credit). In a database it is much easier and more efficient to store the values as positive and negative (DR = +, CR = –), and display the appropriate bookkeeping term on the screen and in reports.

I will use the DR/CR notation discussing processing though I may occasionally display data as +/-.

You'll find more about these bookkeeping terms here.

Zero Sum

All transaction should balance to zero. By this I mean that the values saved to the accounts for a transaction should add up to zero. The debit(DR) values will match the credit(CR) values. See here for more on DR/CR.

A sales transaction for €121.00 can be broken down as €100.00 for the value of goods sold and €21.00 tax. The customer owes €121.00.

In accounting terms this will be recorded as

Detail	DR	CR
Value of Sales		100.00
Tax due by you		21.00
Value of Customer	121.00
Total-Both sides match	121.00	121.00

All transactions will follow this principle. It also acts as a built-in integrity check. If the DR is positive and the CR negative, at any stage the entire set of transactions will add up to zero.

This is the plan.

I’m going to develop a browser based book-keeping and financial accounting system from scratch and document the development here.
I’ll make to work in progress and the completed system freely available.
My hope is to learn more about web/application application development, open-source and the development community online.
The working title for my app is Depecuniae (Late night, coffee, Babelfish, don’t ask).
Ok let’s go.
Book keeping
I’m not an accountant; I’m a developer with a lot of experience in financial systems in Ireland and the United Kingdom. I hope to fill in any gaps in my knowledge with the help of professionals.

In theory, financial accounting systems are quite simple. Record transaction data, process it, store it, and generate report information. It has rules and built in checking already decided over centuries. The user experience is the greatest challenge, and takes the lion’s share of the development time.
It’s important to bear this in mind. The data processing will be quite rigid and the interface will be a moving target.
Here’s a quick wanted list in two parts to get us started. It will be amended, extended, reduced and possibly replaced entirely over time.
The processing part of the system:
• must support accounting standards.
• must accept transaction input.
• must maintain balances.
• must generating reports.
• must produce periodic analysis including financial accounting reports.
• must be coherent. It must have traceability.
• must be secure.
• should be highly configurable.
• should support multiple companies, branches and locations.
• should support multiple currencies and exchange rates.

The interface part of the system:
• must be pleasing and easy to use.
• should be multi user and employ agile user control.
• should be accessible to users with special needs.
• should support multiple languages.
• should accept electronic as well as manual input.
• should generate electronic output.

Like any list it is incomplete and lacking in detail. Also, many of the list requirements overlap with others.