[jira] Created: (OFBIZ-1343) Experience for OFBiz to propertly support multicurrency accounting and autoposting

[Nicolas Malin (Jira)]

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: Release Branch 4.0
         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.

[Nicolas Malin (Jira)]

     [ 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.

[Nicolas Malin (Jira)]

     [ https://issues.apache.org/jira/browse/OFBIZ-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jacques Le Roux closed OFBIZ-1343.
----------------------------------

       Resolution: Fixed
    Fix Version/s: 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
>             Fix For: SVN trunk
>
>
> 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.