Complete the implementation of the Accounting component - GL

This page is used to summarize the design decisions and collect other useful information for the implementation of the Accounting component.

The development effort is tracked in the Jira task (and subtasks): OFBIZ-1434

Main Goal 

Finish implementation of the OFBiz accounting component, both the auto-posting to GL services and a nice complete set of reports (the 4 standard accounting 101 type reports plus a complete set of financial metrics). Complete the user interfaces to manage AR/AP tasks etc...

Persons involved: David Jones, Jacopo Cappellato, Skip Dever, Scott Gray, Jim Barrows, Anil Patel

Here are some pointers provided by David E. Jones in a message on dev. ML. Those are good sources for understanding the whys and wherefores behind accounting in OFBiz, and a bit of history as well.

1. The Data Model Resource Book, Revised Edition, Volume 1   (accounting, party, and other related areas)
2. The OMG GL interface specification
3. Various books on accounting, including the accounting and supply chain books at https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Related+Books
4. The proposed OMG AR/AP interface specification, that lost backing  in 2003 http://ledgerism.net/ARAP/arapxml.htm

Current Status

Main navigation

In the Accounting applications the main menu items related to GL are:

• "Chart Of Accounts": this is where you define all the available GL Accounts; there is also a screen to associate the accounts to the organizations (this is a many-to-many relationship)
• "General Ledger": this is the entry point for all the GL operations; first of all you have to select the organization in which you want to work on GL tasks; once you have selected an organization you'll see new submenus:
  • Setup: this is where you setup the Account available to the organization, the accounting time periods, general accounting preferences, journals, transaction specific accounting preferences, etc. (there are submenu items for each of these tasks)
  • Accounting: this is where you operate your everyday GL activities: run accounting reports, view/edit/post accounting transactions and accounting transactions entries, etc...

How to setup and use a journal to group failed automatic accounting transactions

1. Go to the General Ledger>Setup>Journals menu and create a new journal using the form the screen: enter the journal name (e.g. "Error Journal")
2. Go to the General Ledger>Setup>Accounting Preferences menu and select the journal created at point 1 in the "error journal id" drop down field
3. You can filter the transactions/transaction entries in the error journal using the General Ledger>Accounting>Accounting Transactions or General Ledger>Accounting>Accounting Transaction Entries screens

Discussions about design decisions

Design notes for the screens under the "General Ledger" menu

All the screens under the Accounting>General Ledger menu are specific for one internal organization (the one you select from the list in the "General Ledger" menu). For this reason, when we implement new screens/forms/menu/links/etc... here we should always follow the following guidelines:

• the name of the variable that contains the id of the selected organization is: "organizationPartyId"
• all the links/menu etc,.. in this area should contain the "organizationPartyId" as a get/post attribute
• all the forms in this area should have the "organizationPartyId" as an hidden field
• all the links in this area should point to screens in the same area: if a user is working in the GL of an organization, the links should always point to screen in the same context
• if the screen's purpose is to setup the GL (configuration) then it should reside under the General Ledger>Setup menu; if the screen's purpose is to perform an operational (everyday) GL task (running reports, browsing accounting transactions, account balances, etc...) then it should reside under the General Ledger>Accounting menu

Should we create two new menu items under the General Ledger>Accounting menu: AR and AP ?

Then each one of the menu items will have its own submenu: AR (sales invoices, customer payments, reports etc...), AP (purchase invoices, etc...)
These organization specific screens will be similar to the existing generic screens ("Invoices", "Payments" etc...) and so this will introduce some redundancy; is this acceptable?

Available options:

• move and refactor the existing generic screens under the organization specific menus (General Ledger>Accounting) and...
• ... split them into screens focused on AR or AP tasks (for example the existing "New Payment" screen currently shows two forms for incoming/outgoing payments; we could split it into two independent screens)
• or keep the existing screens and create new ones (extending where possible the existing artifacts, forms/scripts) specific for one organization and task's class (AR/AP)
• other ideas?

Journal and transaction management

Some notes on journals (GlJournal), transactions (AcctgTrans), transaction entries (AcctgTransEntry), etc:

1. journals (GlJournal) are optional: transactions (AcctgTrans) do not have to be associated with a journal
2. a transaction (AcctgTrans) is not associated with a GL account and does not represent a debit or credit, each entry (AcctgTransEntry) in a transaction does
3. journals are not meant to be balanced, individual transactions are (checking to see whether or not an entire journal is balanced is simply a matter of seeing if each transaction is balanced
4. origin "documents" (detail records) are associated with the transaction

Initially, we will only use journals for error handling (to group together the failed GL transactions); see next paragraph for additional details.

Tips to setup an error journal and prevent errors caused by incomplete GL accounting setup

The quickest way to fix errors appearing in the operational environment (creating orders, shipments etc...) because of an incomplete setup of the GL accounting parameters is to define a error journal for the company: in this way, all the accounting transactions that cannot be posted (for example because there isn't a mapping defined) are moved to the error journal and no error is thrown.
You can create the error journal in this way:

1. go to Accounting>General Ledger>Setup>Journals and create a new journal: http://demo-trunk-ofbiz.apache.org/accounting/control/SetupGlJournals?organizationPartyId=Company
2. go to Accounting>General Ledger>Setup>Accounting Preferences and select the journal in the "Error Gl Journal Id": http://demo-trunk-ofbiz.apache.org/accounting/control/PartyAcctgPreference?organizationPartyId=Company

All the "incomplete" transactions will be visible here:
http://demo-trunk-ofbiz.apache.org/accounting/control/ListUnpostedAcctgTrans?organizationPartyId=Company

Tech details about how the GL accounting services will be called

The GL accounting transactions will be implemented using SECAs (aka OFBiz triggers on service calls): by default they will all call the services responsible for preparing and sending the accounting transaction as sync. However a customer may want to change them to async calls (in this way, an error in the GL service will not interfere with the operation that triggered it).

However, in general, if the GL posting fails for some reason the triggering operation (finalizing an invoice or payment or whatever) would NOT roll back, instead the partial GL post would be placed into an error journal (if that failed, then a general error resulting in rollback would be appropriate), if the error journal is defined in the accounting preferences of the organization.