ERP 2.50:Functional Documentation/Financial Management/Accounting
According to Wikipedia an Enterprise Resource Planning (ERP) is a system “that attempts to integrate all data and processes of an organization into a unified system”. In Openbravo, as an ERP, the financial management of the application is related with the rest of the application modules.
Accounting in Openbravo is led through the documents. Some examples of documents in Openbravo are: purchase order, sales invoice, settlement and cash journal. Most part of the documents can generate an accounting entry in the general ledger journal.
Let's imagine that a company working with Openbravo needs to change some parameters of its accounting and apply them to all the accounting entries. As the accounting is generated through the documents, it is possible to remove all the accounting entries -documents remain intact, so no data is lost-, change any accounting parameters, and re-build automatically the general ledger journal, and so, all the accounting data of the company.
When a document is posted, each line of the created accounting entry is recorded as a new line in the table Fact_Acct of the database. So in this table, every accounting operation done in the application is registered. And from this table, all the accounting information is generated, like for example, balance sheet or general ledger journal.
A new purchase invoice is created. Some lines added, with a total amount of $5,000. It has a 20% tax associated, so when posting the invoice the next accounting entry should be created:
So three new rows will be created in the Fact_Acct table, one for each line of the accounting entry.
There are some concepts related to the accounting process in Openbravo that must be explained.
There are two possibilities of performing accounting in Openbravo:
- To manually generate the accounting entries of each document. This action is called posting the document. This option is not usually used. It can be useful for studying the created accounting entry for a concrete document, for example.
- To let Openbravo automatically post all the documents. This automatic accounting is done through a background process that can be scheduled to work only at certain hours (usually at night).
Accounting time periods in a company are divided into years. Openbravo's calendar feature divides years into periods and periods into months. Additionally, each period reacts in a particular way to the document types (e.g., Bank Statement, Cash Journal, GL Document, etc.) which can be posted in a given period.
Each document type of each period will be in one of these states:
- Open: Posting is allowed in the period.
- Closed: Posting is not allowed in the period, but could be allowed again in the future.
- Never Opened: Initial state of a document type in a period. Posting is not allowed until it changes to the Open state.
- Permanently Closed: Posting is not allowed in the period now and will not be allowed again. This is the case, for example, when the period or year has been closed and the accounting entries sent to the Trade Registry.
On January 1st 2012, Company A creates the year 2012 in Openbravo's calendar. Twelve periods (from January to December) are also created inside.
On February 1st, Company A obtains a bank statement for the activity of the month of January via electronic bank statement, reconciles the bank statement lines with those not already present in Openbravo ERP, and permanently closes the document type bank statement in the period January.
On February 5th, Company A permanently closes the next document types: purchase orders, sales orders and sales invoices, and closes (but not permanently) the document type purchase invoices.
On February 10th, a new purchase invoice arrives from the supplier S1, dated January 30th. January's invoices document is reopened, the invoice posted and the period closed again.
On March 1st, January's period is permanently closed.
As Wikipedia explains, "an Account, (in bookkeeping), refers to assets, liabilities, income, expenses, and equity, as represented by individual ledger pages [i.e. an "account" page] to which debit and credit entries are chronologically posted to record changes in value." An account may report a quantity of almost anything. Most often it is a record of an amount of money, owed to or owed by a particular person or entity, or allocated to a particular purpose. Various accounting systems and rules exist. Most, if not all, of them organize their system in trees of accounts. A chart of accounts is a ”list of all accounts tracked by a single accounting system” (Wikipedia), so a chart of accounts (AKA Accounting Schema in Openbravo terminology) describes the accounting tree used in a specific country or accounting system. In Openbravo, the charts of accounts are implemented in a text file in csv format.
Some of the accounts of the chart of accounts are marked up as default accounts. These are accounts that are specific to a concrete operation of a document. When building a chart of accounts, the accounts representing this default values must be located, for that accounting system.
Although each chart of accounts is different, all of them will have, for example, one account used for the expenses from purchase invoices. This default expense account may be named P_EXPENSE_ACCT in one country, while in the US it may be named 512: Service costs. Similarly, in France, the account would be 60710: Marchandise (ou groupe), and in Spain 60000: Compras de mercaderías.
A chart of accounts is needed to initialize the accounting in Openbravo. When this chart is loaded through the csv file, the account tree represented in that chart of accounts, is built in the application. Also the default accounts are filled in.
The accounts are arranged hierarchically in the chart of accounts file, through the “Parent” column. This structure provides the way of obtaining the balance report and income statement report. For creating these reports, the root elements of the reports are selected (i.e.: assets, liabilities and owner's equity, for the balance report), and all the sub-accounts below it are covered to build the report.
Once the account tree is built, new accounts can be added to the tree.
Openbravo allows one to analyse client accounting by “dimensions”. This means that, for example, an income statement can be generated for the whole client, or for a specific project, or a specific business partner.
Some dimensions are mandatory (for example, the organization) while others are optional, such as business partners, products, projects, campaigns and sales regions. When a new client is created, its dimensions can be selected. After creation, one may continue to adjust the client's accounting dimensions.
Once the client has an accounting dimension defined, accounting results can be obtained either for the whole client, or for a specific organization, business partner, etc.
Company A creates a new client, and checks the “project” dimension, amongst others. At the end of the year, the income statement is obtained: one with the whole client accounting data, and one for each project, so that profitability can be analysed for not only the whole company but of each project.
A G/L Journal Entry is a manually created entry in the general ledger journal. It means, an accounting entry that does not correspond to any document.
Not all the accounting entries are associated to a document. For example, the opening entry does not correspond to any document in Openbravo. A provision of funds made to a notary's office is an example of a general ledger journal entry that does not belong to any document, and is done through a G/L Journal entry.
Annual Financial Statements
The general ledger journal is built grouping the registers of the Fact_Acct database's table by date. The general ledger report is also built from the Fact_Acct registers, grouped by account. Actually, all the accounting reports, such as balance sheet, the income statement and the balance report, are built from the Fact_Acct data.
The budgets are managed in Openbravo in this way: Openbravo automatically creates a spreadsheet with a specific format. This spreadsheet is edited externally and filled in with the budget data. Once finished, it is imported to a database table through the import file loader.
It is also possible to generate the budgets through the application, but is usually such a huge amount of data, that it is more comfortable to use a spreadsheet.
Negative accounting affects the way that reversals are accounted, and is set up as part of the accounting schema. When you reverse a transaction you can use either negative or positive values. For example, if a sales invoice document generates the following transactions lines:
If the Allow Negative option is selected, when the transaction is reversed, the system will allow the creation of the following negative transaction lines. Using negative lines for reversals is sometimes called storno accounting.
However, in some countries, negative entries are not accepted by auditors, in which case the correct way to reverse the transaction would be as follows:
Negative transaction lines are considered best practice in some countries, particularly in Central and Eastern Europe. These include (but are not limited to):
- Czech Republic
In most countries negative transaction lines are not looked upon favorably by auditors and the expectation is that transactions are reversed using contra accounting. These countries include (but are not limited to):
- United Kingdom
- United States
Because both types of transaction reversal are legitimate (in the correct accounting context), you can configure Openbravo ERP to suit your locale and preference.
The default behavior of reversing transactions is controlled by the accounting schema. For countries where transaction reversal using negative values is not normally used, make sure that the Allow negative option in Financial Management > Accounting > Setup > Accounting Schema not selected.
However, you can also override the schema behaviour at document type level, for example to allow negative accounting for particular accounting documents. This gives complete control to the implementer in defining the transaction reversal behaviour for each combination of schema and document type.
Note: in earlier versions of Openbravo ERP negative transactions were enabled by default.Users upgrading to Openbravo 2.50 from earlier versions will find the Allow negative option selected. It is recommended that you consider reconfiguring their systems to take advantage of the increased options for managing transaction reversals. In Openbravo ERP 2.50 the default behavior is to not allow negative transactions. In new implementations of Openbravo ERP, the Allow Negative option is deselected by default. This means that the default behavior for transaction reversal will be to use contra accounting, i.e., to disallow negative transactions unless they are specifically enabled at a schema or document level.