Core - Ledgers and Transactions

Ledgers

In simple bookkeeping, there are usually three ledgers:

1. Sales Ledger
2. Purchases Ledger
3. Nominal (General) Ledger

Transaction in the sales and purchases ledgers are the normal transactions of a business. The business sells goods to a customer, the customer pays for the goods either straight away, or at a later date. Similarly the business buys the goods or raw materials to sell, and pays the supplier.
Transactions in the sales and purchase ledgers will be mirrored in the Nominal ledger. The Nominal ledger is a balancing accumulation of all the transactions of a business. As well as transactions from the other ledgers, the Nominal ledger will contain some its own transactions; each one moving value from one place to another, increasing or decreasing value.

There are some other ledgers which we will need to include:

1. Client / Customer Ledger
2. Stock book
3. Cashbook

The Client ledger and Stock book are non-nominal updating ledgers. They may be used by transactions in the Sales or purchasing ledgers, or the cash book, but they do not directly affect the Nominal Ledger.
A Client Ledger is normally used when the service you supply the customer involves handling financial transactions on behalf of the customer. Agents (Estate, talent, etc) and solicitors would hold funds belonging to the customer, use those funds on the customer’s behalf, but keep them separate to internal finances.
The stock book maintains an up-to-date statement of goods in stock. Orders, receipts, dispatches will affect stock levels but only affect the Nominal ledger when invoices are entered into the Sales or Purchase ledgers, or a value adjustment for stock is written directly to the nominal ledger.
The Cashbook is a statement of cash payments and receipt for a business. These will affect the Nominal ledger, plus other ledgers they are associated with.

Transactions

Each ledger has a number of transactions types associated with it (Sales invoices are associated with the sales ledger, Nominal journals with the Nominal ledger).
Some other transactions affect multiple ledgers. (Cash receipts)

Most transactions has very similar content and behave in a standard fashion. Fee invoice and credit notes (Sales and purchase), and debit and credit journals (again Sales and Purchases) all behave in a standard fashion.
The main things that between these transaction type are:

1. the ledger and analysis accounts they affect,
2. whether the transaction is a debit or credit transaction, and
3. should taxes be levied against the transaction

Other transaction are more complicated and require:

1. multiple ledgers (Cash receipts, cash invoice, Stock invoice),
2. special structures (bank lodgement), or
3. non-recource to other ledgers.

Requirements for Ledgers and Transaction types

A user should be able to define their set of ledgers and transaction, or use a standard template set. They should be able to add new Ledgers and transaction type to the existing layout.

The Nominal Ledger if not present in this context only means that Nominal Ledger transaction cannot be entered. Reporting would not be affected.

Some setting would be Ledger-wide:

1. Updates Nominal ledger,
2. default control accounts,
3. default Analysis accounts,
4. tax area (Purchase or Sales)

Some would be set at a transaction level:

1. Use ledger Account (customer, supplier, cash account)
2. Transaction default analysis account
3. Inter Account transfer (Bank lodgement)
4. Inter Ledger transfer (Customer receipts)
5. Posting transaction (yes / no)
6. Period basis
7. Subject to tax (is VAT to be applied to this transaction)
8. Use stock (if this transaction is no a Stock book,can it stock items?)
9. Interacts with other transactions ( Invoice reads orders, Receipt reads invoices)

With these settings we can build 80-90% of transaction types required for a simple bookkeeping system. For the remaining transaction types predefined templates need to be available to the user. An example Cash receipt transactions my be performed against a ledger account, or the transactions within that account. The former transaction could be handled normally, but a specific “Ledger transaction allocation” template would support the latter.

Core - Internal Structure - Country and tax system support

Different country and indeed, different states within some countries, have have very different transaction tax systems.

Value Added Tax

In Ireland the system for VAT (Value Added Tax) is quite simple:
There are a number of tax rates for different products or services.
Each product or service has one rate for sales and purchases.
In each transaction the VAT is calculated on the Nett transaction value.
A VAT registered business will pay VAT on purchases, charge VAT on sales and pay the difference on a monthly basis to Revenue.
Good bought from or sold to VAT registered business in other European countries have a 0% rate.

Some small business can pay tax due based on the date of receipt of payment; all others must pay based on date of transaction.
Some organisations are not VAT registered(Government, educational). These must pay VAT on purchases but cannot claim back that VAT.

Sales Tax

Sales tax is levied only on the final purchaser of a product or service. Several taxes may be levied on a single transaction, each on the Nett value of the transaction.

Excise

This is a flat value tax on a unit of product or service. Examples of this are petrol, tobacco and alcohol. VAT and Sales Tax may be charged on the Nett + Excise.

Tariff

These are taxes on international transactions. There are no tariffs on transactions within the EU.

System Requirements

This system therefore requires the following abilities:

1. A single transaction item may have zero, one or more taxes applied to it.
2. Each tax can have different rules for:
• Purchases,
• sales,
• customer and supplier types,
• local,
• inter-state and
• international transactions.
3. Each tax can be any one of the allowed types.
4. Each tax can be levied on the Nett value of the cumulative gross value.

Other Country related settings

Other country setting would include currency,decimal and triad notation, state specific reports, post-code/zip code settings, and other required company details.

Core - Internal Structures - Multilingual support

The Symfony framework supports "internationalization". Rather than writing strings directly we abstract the text we wish to display through a translator and display the result for the locale or language in use. This translator is not automatic but built up by the developer, by building up message catalogues for each language.

In simple terms this means that instead of:

echo "Welcome" ;

we will do something like this:

echo $this->get('translator')->trans('Welcome');

For each locale supported we will have entries to display the translation of 'Welcome':

# messages.fr.yml
'Welcome': Bienvenue

Though the initial system locale will be in English; I hope, that with help, I can expand to include Irish and other languages.

Development Environment

It’s a new year and I’ve been away from this project for quite a while; too long.

I’ve made a couple of decisions about development of the system.

I’ll be mainly PHP for the server-side scripting using Symfony 2.x framework. This is something I’ve started working with recently and given that I’m still on a learning curve with it I think it will give me more impetus to keep going to this project. A framework like Symfony provides built-in support for Languages, User control and Application security.

While Symfony supports Database Independence my development will use MySQL.

Currently I develop on a Windows XP machine using Netbeans 7 for coding and running XAMPP 3 to manage the Apache and MySQL. For this project I'll be using CentOS 6.x as a virtual machine from Thought Police.

On the client side I haven’t decided what Javascript framework mix to use. I hope to separate the client and server coding as much as possible. I’d like the system to support multiple front-ends.

All my code will be available on Git-hub.

That done, back to the design.