[
https://issues.apache.org/jira/browse/OFBIZ-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacopo Cappellato updated OFBIZ-1343:
-------------------------------------
Affects Version/s: (was: Release Branch 4.0)
SVN trunk
> Experience for OFBiz to propertly support multicurrency accounting and
> autoposting
> ----------------------------------------------------------------------------------
>
> Key: OFBIZ-1343
> URL: https://issues.apache.org/jira/browse/OFBIZ-1343
> Project: OFBiz
> Issue Type: Wish
> Components: accounting
> Affects Versions: SVN trunk
> Environment: Any.
> This discussion was prompted by David's mention that core OFBiz accounting is
> being worked on again.
> Reporter: Cameron Smith
>
> Here are our experiences of the changes we had to make to OFBiz accounting,
> in order to support a working multicompany system (that is, with one
> installation of OFBiz, you can manage the accounts of multiple separate
> organizations). Note that within one user company it is quite common to have
> several different firms with different legal identities but sharing the same
> office and public image. For instance a holding company, a consulting
> company, and an investment company.
> We use these alterations, successfully, in our local branch of OFBiz. Our
> experience may be of use to David and other committers. Please note that our
> focus is on SMEs so some of what I say below, may not be relevant if you are
> focussing on large firms.
> MultiCompany changes
> The basic changes are that ALL relevant entities need to have an
> organizationPartyId, to refer to the organization whose accounting is being
> recorded. Core OFBiz currently only has this in some places and not in
> others. We found it necessary to add in the following entities, in some
> cases altering the PK to include this:
> GlAccountOrganization - this already has organizationPartyId but we added
> orgAccountName, allowing an account to have a per-company title
> GlAccountRole - the role a certain party has with regards to a certain
> account varies according to which companies we are accounting for. For
> instance the same external firm could be a supplier to one company and client
> of another.
> CustomTimePeriod - a fiscal month or year could be closed for one company and
> open for another.
> UomConversionDated - each company has its own accounting policy for dealing
> with foreign currency exchange rates
> General changes
> 1. We altered postAcctgTrans to permit transactions to be posted in virtual
> accounting months, as well as simply calendar months. this allows the
> account to clearly demonstrate the work steps performed at year opening and
> year end, which normally have to follow a certain sequence.
> 2. We use GlXbrlClass to separate between "off the shelf" accounts which the
> system creates automatically (you could have one XML import file for each
> country's GAAP), and accounts created by a specific firm.
> 3. We altered Facility to have a geoId so you can break down where the
> facilities which hold your fixed assets are located.
> Autoposting changes
> We found the Opentaps approach very limiting here, in terms of deciding what
> accounts to post to when. In terms of core OFBiz we did not need to do
> anything special, however one interesting general point to consider is: what
> length will your glAccountIds be? It is very useful if you enforce a
> standard length. We use two digits at the start to leave space for multiple
> GAAP's accounts to coexist, and the rest are a codification of the account
> code.
> If your max. length is too short obviously you can run out of space to create
> subaccounts!
> More interestingly, it can be useful for the client's ID number in the system
> (or some part of it) to match the last element of the account code. This
> helps with any manual verification of transactions. However it requires you
> to have a long enough glAccountId to fit this many accounts.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.