This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Page tree
Skip to end of metadata
Go to start of metadata

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
  4. The proposed OMG AR/AP interface specification, that lost backing  in 2003

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:
  2. go to Accounting>General Ledger>Setup>Accounting Preferences and select the journal in the "Error Gl Journal Id":

All the "incomplete" transactions will be visible here:

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.

  • No labels


  1. Unknown User (

    I am hands are itching to write some Ajax in UI.

  2. Unknown User (skipdever)


    In case everyone forgets to say it (me included).  Thanks for all the work that you do, both here and elsewhere.

  3. Unknown User (

    Regarding the "Error Journal" - in my experience, those are called "Suspense Accounts" - meaning the transactions they contain are "in suspense" until they are resolved.

  4. Unknown User (

    Regarding separate screens for AR and AP - this would be preferable because in many companies those two tasks are handled by different departments. Giving a single person access to both screens is frowned upon in many companies because it introduces a cash control problem.

  5. Unknown User (

    I'm sure the developers working on the accounting component know this, but I would like to state it so we're all on the same page: Accounting transactions and journal entries should NEVER be deleted. Accounting transactions should be voided, and journal entries are corrected with offsetting entries. In both cases there must be an audit trail of who did it and why.

     Any time you give anyone the ability to delete a transaction or journal entry, you open the door to fraud.

    1. Adrian, yes this is what we are doing: accounting transactions that are *posted* are not editable.

  6. Unknown User (

    Is it OFBiz's long-term goal to replicate/deprecate all of the functionality in the opentaps financials module? Or do you picture opentap's financials as always being a superset?

    1. The long-term goal for OFBiz is to provide a complete accounting component - and as Opentaps is GPL/HPL licensed we can't use it  and therefore have to implement it all by ourselves.

    2. I'd say that the *short-term* goal is to provide a simple but completegl accounting/financial module; right now the OFBiz component, that is in 'alpha', is feature rich and has some features that are not available in Opentaps.

      This is the official financial component for OFBiz, but it is not correct to say that we will "deprecate" the Opentaps financial component: we have no control over Opentaps (and of course we don't want to control it!), it is an independent and separate project... and I'm pretty sure that they (Open Source Startegies, the creators of Opentaps) will continue to use their component, because they have more knowledge over it, they have invested a lot of resources etc... instead of the official OFBiz component.

       I think that the most natural thing is that, if a user will choose OFBiz, then will use the integrated OFBiz financial component; if the user will choose Opentaps then will use the Opentaps financial component.

      But time will tell.