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.

Introduction to the Core Mudule

Core Mudule.

The Core module contains the structures upon which the rest of the system sits. It defines the ledger layout, Tax system, Company structures and the analysis breakdown. It is divided into four sections:

• Internal Structure
• Internal Analysis
• Business Structures
• Business Analysis

Internal Structure

This section controls the operation of all transaction activity in the system. It defines what tax system the system works under, the ledgers type (Sales, Purchases, Nominal, etc.) and the transaction type used within the system.

Internal analysis

This section handles the global analysis for the system. T managers currencies and exchange rates, nominal ledgers accounts, tax rates (VAT) and analysis periods.

Business Structure

This system needs to be flexible so needs to accommodate a range of ‘companies’ from personal accounts to large company group accounts. The company structure section provides the basis for that gearing. There is one main company account with a sub-structure that can be tailored to suit the company’s needs. Access to the system will be made using ‘Entry Points’ which are related to points on the sub-structure.

Business Analysis

Analysis beyond nominal and company structure is required in most company situations. This includes Department analysis, Cost Centre analysis, Group tags for quick linking of transactions, and quick entry objects with default text and link analysis values.

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.