Wstęp

Konta jest urządzeniem ewidencyjnym w Księdze Głównej służące do ujmowania wszystkich zdarzeń gospodarczych: każda Operacja księgowa w Księdze głównej, opisana tutuj dotyczy zapisu na dwóch lub więcej kontach księgowych. In fact each Nominal Ledger Transaction can be defined by which Accounts these are. The organisation of these Accounts is known as a 'Chart of Accounts': a systematic list of how assets, liabilities, income and expenses are to be classified and thus the basis for your accounting reports. The logic used in the classification determines the usefulness of your reports, and the drawing up of a satisfactory Chart of Accounts requires careful consideration.

In designing a Chart of Accounts, it is usual practice to group Accounts together according to type. For example, all Sales Accounts should have similar codes, different Bank Accounts should have similar codes and so on. This will ensure that they appear together in reports. Room should be left so that new Accounts, the need for which is currently unforeseen, can be inserted in the right place. If your business develops into new products, for example, you should be able to create Sales Accounts for those new products with similar codes to the existing Sales Accounts.

In traditional accounting systems, the Chart is divided into account classes, following a decimal classification. Two or three classes are reserved for Balance Sheet Accounts, one class is normally reserved for internal accounting and year-end operations, and the remaining five or six classes are used for revenue and cost classification.

Typical Charts of Accounts, including that supplied as a template with Hansa, follow the model illustrated below. The Accounts are usually divided into two groups, named after the report in which they appear.

Profit & Loss
This report shows the trading profit or loss of your business, usually at the end of a month or year.

Balance Sheet
This report shows the assets, liabilities and capital of your business at the moment of printing.

!

Your Chart of Accounts should be drawn up in consultation with your accountant or financial adviser.

Objects

In traditional cost accounting, the classification of expenditure and the allocation of different expenses to departments, products, regions etc. is a well known problem area. In essence, there is a need to present management reports in several different views or dimensions. Normally, there are three basic dimensions used in the accounting of any business:
In some businesses, there is a requirement to add further dimensions that are not subdivisions of the above, such as geographical areas.

Conceptually, the accounting situation can be described as a three-dimensional table:

In traditional accounting systems, the classification is done with the help of the Chart of Accounts. The Chart is divided into account classes, following a decimal classification. Two or three classes are reserved for Balance Sheet Accounts, one class is normally reserved for internal accounting and year-end operations, and the remaining five or six classes are used for revenue and cost classification.

A Chart of Accounts is a list of Accounts. By definition it is one-dimensional. Through various means, the Accounts are divided into sub-classes down one or more levels, and the result is a hierarchical tree structure of classifications.

A result of the hierarchical tree structure classification is inevitably that cost type, profit centre and cost bearer classifications are scattered all over the Chart of Accounts. This makes the description of reports complicated and cumbersome, since data will have to be picked up individually from many different Accounts, in order to produce different types of "Functional" result reports.

To simplify the structure many accounting systems subdivide the "account string" into different parts, each indicating cost type, department, project, product etc. This is only a half-way solution. The only logically viable solution to truly multi-dimensional accounting is to use an "Object" classification in each accounting transaction. With this method, the Chart of Accounts contains account specifications for the kind of revenue, expenditure, asset, liability or equity. Each accounting transaction consists of an Account Number, an amount, a date, and one or more Object classifications. In the example above, a wages payment for trucks in Unit C would contain the following information:

Number    970001
Date    010198
Account    5102 Wages
Text     "Any written description"
Amount    Debit 15420.25
Objects    Unit C, Trucks

With this classification, it will be simple to show all transactions entered for a separate product, unit and cost type, or to show a profit and loss statement for a particular section of the business.

Click here for a description of how Hansa deals with this task.

Objects - in Hansa

Hansa supports the use of Objects, to allow your accounts to be classified and reported in several different categories or dimensions. Up to 30 Objects can be assigned to a row in a transaction: the Object field can contain up to 60 characters. When entering Objects, each Object Code is separated by a comma. It is recommended that Object Codes with at least two characters are used, placing a more usual limit of 20 Objects on each transaction row.

You can assign default Objects to Customers, Items, Suppliers, individual Invoices and Nominal Ledger entries. When an Object is assigned to a Customer, for example, Hansa will automatically assign that Object to all Nominal Ledger Transactions generated by Invoices made out to that Customer. This gives you excellent possibilities to report for example sales per Object. In general, Objects are tools to improve the internal cost accounting capabilities in your business. You can use Objects in Autotransactions to create automatic cost distributions to products or profit centres for certain cost types.

Objects may be used as selection criteria in many reports. For example, if you have several profit centres in your business, and use Objects to separate income and expenditure for each of these, you may produce separate profit and loss statements for each profit centre. You can also print a Nominal Ledger report that is restricted to a particular Object. The report will then only show the transactions for each Account that have been classified with the selected Object.

All objects in Hansa can span several years. This is a consequence of Hansa's continuous database, where the end of year is simply a user-defined reporting interval. The Object balances are thus automatically transferred from one fiscal year to the next. This gives you the ability to keep track of the budget and results of an Object (e.g. a building project) for several years.

An Object can also be closed, to prevent further postings to it. Working in the Object register (in the Nominal Ledger or the System module), switch on the Closed check box to close it. If you want to open the Object again later, you simply click in the box again to remove the check.

It is a good idea to experiment with the Objects, Object Types and the various reports.

Examples
The following Nominal Ledger Transaction shows the result of a Sales Invoice, where the Customer belongs to the "Unit A" Object and the Items belong to the "Cars" and "Trucks" Objects respectively. Each Item and Customer have thus been assigned an Object reflecting their position in the table illustrated at the beginning of this section.

The following two Profit & Loss reports show the Income Statement for two of the journal postings: those with the Object combinations "Unit A & Cars" and "Unit A & Trucks", respectively. Some cost transactions have been added to make the example more complete.

With a careful use of Object and Account definitions, Hansa allows you to allocate revenues and expenses in a logical way, in order to reveal the profitability pattern in the business. Most of the assigning of Objects is done automatically. Objects assigned to Customers, Suppliers and Items are automatically transferred to the Nominal Ledger Transactions.

Object Types
Objects that belong to the same type, e.g. departments or products, can be grouped together as Object Types. Several reports in Hansa can be produced for an Object Type.

In our example we have created the Object Types "PRODS" and "UNITS" (using the Object Types setting in the Nominal Ledger).

The following Objects are defined for the three Object Types:

All invoiced sales are recorded with an Object of the "LAND" Object Type (representing their country of origin). Here, we produce a Profit & Loss report for the "LAND" Object Type:

Similarly, ordering a report for an individual Account (the Nominal Ledger Report) and for one Object Type will list only Transactions for that Object Type. The Balance Sheet for the "LAND" Object Type will summarise the accounts receivable per country.

Objects - Hierarchical Objects

In order to simplify the assigning of Objects, hierarchical Objects can be used. It is possible to define a new Object that consists of a string or sequence of Objects as in the following example:

When you enter a Nominal Ledger Transaction using the "STRA" Object, it will be replaced by the string of Objects in the Hier. Objects field. In the example below, the "STRA" Object has just been entered.

As soon as you press the Tab key, the string of Objects from the definition will replace the Object typed:

This expansion of the hierarchical Object does not take place on screen when assigning Objects to a particular Invoice, Customer or Item, but it does take place when a Nominal Ledger Transaction is generated using that Invoice, Customer or Item. Therefore, whenever you look at the Invoice, you will see "STRA" in the example above, but when you look at the consequent Nominal Ledger Transaction you will see the full Object string. Note that the hierarchical "STRA" Object is listed in the Object string, a useful feature that allows you to work with several levels in your analysis.

Hierarchical Objects can be nested. i.e. one hierarchical definition can contain another:

When the "STRB" Object is used, it will expand to the combined contents of "STRA" and "STRB":