You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

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

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

Current Status

User Interface

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)
  • "Companies": 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, 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...

Discussions about design decisions

Design notes for the screens under the "Companies" menu

All the screens under the Accounting-->Companies menu are specific for one internal organization (the one you select from the list in the "companies" 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 the 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 "Companies">"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 "Companies">"Accounting" menu

Should we create two new menu items under the Companies-->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 ("Companies"-->"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.

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