GL setup for multiple divisions

[Jacopo Cappellato]

What is the best way to implement the ability to setup default GL
settings for divisions for a certain company?

For example, in the OFBiz demo data, we have the "Company" company and
some division (internal organizations, part of Company): MARKETING,
ACCOUNTING, SALES, DEV, TESTING.

After that we setup the GL settings for the main company ("Company"),
what should we do to implement the GL settings for its divisions?
What are the data that we have to duplicate?
Recently David Jones suggested an interesting approach for the
PartyAcctgPreference entity: if the record is missing for a division,
then get the one of its parent; in this way we can define, in a central
place one Error Journal for all the divisions, one currency etc...
We could also share the same approach for all the Gl type/account
mappings... but here things get tricky: how can we know if we have to
look at the parent's settings? Can we use the existence of the
PartyAcctgPreference as a way to know if there are settings for the
division or not?
However there are records that simply need to be copied over:
GlAccountOrganization (and possibly others) is a good example; how
should we implement this? Automatically copy the record, when it is
created, to all the divisions?

There are many other similar issues and now I'm start wondering if it is
not simply better to just provide some import/export features that
facilitate the process of cloning an accounting setup from one
company/division to another one.

Hmmm... so many questions... please help.

Jacopo

[BJ Freeman]

I would like to mover the up one notch.

Parent Company========
                      Profit Center sub Corp===========
                                                      Division======
what i would like to see is that the GL main as we have it, is the
Parent Company.
that the numbers in the GL be appended with the partyid of the
Profit Center sub Corp.Division

so in final display of the GL you can have reports at each level.
so the PartyAcctgPreference would have a link to the parent PartyID
then a service that checks and generates the records at the proper level.
I believe we have a list of pre-assigned gl accounts, that the above
would act on.
the structure should allow for more pre-assigned accounts.


Jacopo Cappellato sent the following on 1/25/2008 2:59 AM:

> What is the best way to implement the ability to setup default GL
> settings for divisions for a certain company?
>
> For example, in the OFBiz demo data, we have the "Company" company and
> some division (internal organizations, part of Company): MARKETING,
> ACCOUNTING, SALES, DEV, TESTING.
>
> After that we setup the GL settings for the main company ("Company"),
> what should we do to implement the GL settings for its divisions?
> What are the data that we have to duplicate?
> Recently David Jones suggested an interesting approach for the
> PartyAcctgPreference entity: if the record is missing for a division,
> then get the one of its parent; in this way we can define, in a central
> place one Error Journal for all the divisions, one currency etc...
> We could also share the same approach for all the Gl type/account
> mappings... but here things get tricky: how can we know if we have to
> look at the parent's settings? Can we use the existence of the
> PartyAcctgPreference as a way to know if there are settings for the
> division or not?
> However there are records that simply need to be copied over:
> GlAccountOrganization (and possibly others) is a good example; how
> should we implement this? Automatically copy the record, when it is
> created, to all the divisions?
>
> There are many other similar issues and now I'm start wondering if it is
> not simply better to just provide some import/export features that
> facilitate the process of cloning an accounting setup from one
> company/division to another one.
>
> Hmmm... so many questions... please help.
>
> Jacopo
>
>
>
>

[Adrian Crum-2]

Jacopo,

I was talking to our accountant about this the other
day. He said in a manual system, each division would
be responsible for maintaining its own GL, and the
results of those division's GLs would be posted to the
parent company's GL.

In other words, the divisions would have all of the
journal detail, but only their ending balances, etc
would be posted to the parent company's GL.

-Adrian

--- Jacopo Cappellato <[hidden email]> wrote:

> What is the best way to implement the ability to
> setup default GL
> settings for divisions for a certain company?
>
> For example, in the OFBiz demo data, we have the
> "Company" company and
> some division (internal organizations, part of
> Company): MARKETING,
> ACCOUNTING, SALES, DEV, TESTING.
>
> After that we setup the GL settings for the main
> company ("Company"),
> what should we do to implement the GL settings for
> its divisions?
> What are the data that we have to duplicate?
> Recently David Jones suggested an interesting
> approach for the
> PartyAcctgPreference entity: if the record is
> missing for a division,
> then get the one of its parent; in this way we can
> define, in a central
> place one Error Journal for all the divisions, one
> currency etc...
> We could also share the same approach for all the Gl
> type/account
> mappings... but here things get tricky: how can we
> know if we have to
> look at the parent's settings? Can we use the
> existence of the
> PartyAcctgPreference as a way to know if there are
> settings for the
> division or not?
> However there are records that simply need to be
> copied over:
> GlAccountOrganization (and possibly others) is a
> good example; how
> should we implement this? Automatically copy the
> record, when it is
> created, to all the divisions?
>
> There are many other similar issues and now I'm
> start wondering if it is
> not simply better to just provide some import/export
> features that
> facilitate the process of cloning an accounting
> setup from one
> company/division to another one.
>
> Hmmm... so many questions... please help.
>
> Jacopo
>
>

      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

[Jacopo Cappellato]

Adrian,

thanks for your comments:

Adrian Crum wrote:
> Jacopo,
>
> I was talking to our accountant about this the other
> day. He said in a manual system, each division would
> be responsible for maintaining its own GL, and the
> results of those division's GLs would be posted to the
> parent company's GL.
>

Is this done when the financial time period is closed (e.g. at the end
of the year), right?

> In other words, the divisions would have all of the
> journal detail, but only their ending balances, etc
> would be posted to the parent company's GL.
>

Ok, this is helpful; however my question was more about the way to setup
the accounting setup (gl mappings, preferences etc...) for each divisions.

Jacopo

> -Adrian
>
> --- Jacopo Cappellato <[hidden email]> wrote:
>
>> What is the best way to implement the ability to
>> setup default GL
>> settings for divisions for a certain company?
>>
>> For example, in the OFBiz demo data, we have the
>> "Company" company and
>> some division (internal organizations, part of
>> Company): MARKETING,
>> ACCOUNTING, SALES, DEV, TESTING.
>>
>> After that we setup the GL settings for the main
>> company ("Company"),
>> what should we do to implement the GL settings for
>> its divisions?
>> What are the data that we have to duplicate?
>> Recently David Jones suggested an interesting
>> approach for the
>> PartyAcctgPreference entity: if the record is
>> missing for a division,
>> then get the one of its parent; in this way we can
>> define, in a central
>> place one Error Journal for all the divisions, one
>> currency etc...
>> We could also share the same approach for all the Gl
>> type/account
>> mappings... but here things get tricky: how can we
>> know if we have to
>> look at the parent's settings? Can we use the
>> existence of the
>> PartyAcctgPreference as a way to know if there are
>> settings for the
>> division or not?
>> However there are records that simply need to be
>> copied over:
>> GlAccountOrganization (and possibly others) is a
>> good example; how
>> should we implement this? Automatically copy the
>> record, when it is
>> created, to all the divisions?
>>
>> There are many other similar issues and now I'm
>> start wondering if it is
>> not simply better to just provide some import/export
>> features that
>> facilitate the process of cloning an accounting
>> setup from one
>> company/division to another one.
>>
>> Hmmm... so many questions... please help.
>>
>> Jacopo
>>
>>
>
>
>
>       ____________________________________________________________________________________
> Looking for last minute shopping deals?  
> Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

[David E Jones]

It sounds like Adrian's comments are a great scenario to address, but  
probably only one of various that we should target.

In general with this sort of thing (or designing anything really) I  
really like the idea of two goals:

1. make it as "fool-proof" as possible; fool-proof is kind of a funny  
term and actually I prefer to avoid the opposite, ie make it not-error-
prone

2. make it easy to do setup and maintain, including as much as  
possible having the system do the most obvious thing by default  
(that's obviously subjective, but narrowing the target audience can  
help significantly)

In this case this is why I would favor for most settings have child  
organizations use parent organization settings if that setting is not  
present for the child. These should be considered on a granular level,  
like fields on the PartyAcctgPreference entity rather than looking for  
the entire record.

Some things may not default very well, like the chart of accounts...  
but defaulting may help there too I guess. Let me think out loud...

The general idea for the pattern is that a single master chart of  
accounts is used for the entire "Company" and those would be  
associated with the top-level organization. Each sub-organization  
would have its own chart of accounts that is selected from the global  
one for the entire organization. Unless there are not sub-
organizations the "root" organization would generally not have  
transactions posted against it.

In that sense it would be nice to reduce maintenance and avoid run-
time errors to have some defaulting in place. In fact if some  
GlAccount were a default for the parent organization, but not mapped  
to the child org, then we'd have to do this sort of defaulting to  
avoid a run-time error.

I hope that makes sense...

-David


On Jan 25, 2008, at 9:06 AM, Jacopo Cappellato wrote:

> Adrian,
>
> thanks for your comments:
>
> Adrian Crum wrote:
>> Jacopo,
>> I was talking to our accountant about this the other
>> day. He said in a manual system, each division would
>> be responsible for maintaining its own GL, and the
>> results of those division's GLs would be posted to the
>> parent company's GL.
>
> Is this done when the financial time period is closed (e.g. at the  
> end of the year), right?
>
>> In other words, the divisions would have all of the
>> journal detail, but only their ending balances, etc
>> would be posted to the parent company's GL.
>
> Ok, this is helpful; however my question was more about the way to  
> setup the accounting setup (gl mappings, preferences etc...) for  
> each divisions.
>
> Jacopo
>
>> -Adrian
>> --- Jacopo Cappellato <[hidden email]> wrote:
>>> What is the best way to implement the ability to
>>> setup default GL settings for divisions for a certain company?
>>>
>>> For example, in the OFBiz demo data, we have the
>>> "Company" company and some division (internal organizations, part of
>>> Company): MARKETING, ACCOUNTING, SALES, DEV, TESTING.
>>>
>>> After that we setup the GL settings for the main
>>> company ("Company"), what should we do to implement the GL  
>>> settings for
>>> its divisions?
>>> What are the data that we have to duplicate?
>>> Recently David Jones suggested an interesting
>>> approach for the PartyAcctgPreference entity: if the record is
>>> missing for a division, then get the one of its parent; in this  
>>> way we can
>>> define, in a central place one Error Journal for all the  
>>> divisions, one
>>> currency etc...
>>> We could also share the same approach for all the Gl
>>> type/account mappings... but here things get tricky: how can we
>>> know if we have to look at the parent's settings? Can we use the
>>> existence of the PartyAcctgPreference as a way to know if there are
>>> settings for the division or not?
>>> However there are records that simply need to be
>>> copied over: GlAccountOrganization (and possibly others) is a
>>> good example; how should we implement this? Automatically copy the
>>> record, when it is created, to all the divisions?
>>>
>>> There are many other similar issues and now I'm
>>> start wondering if it is not simply better to just provide some  
>>> import/export
>>> features that facilitate the process of cloning an accounting
>>> setup from one company/division to another one.
>>>
>>> Hmmm... so many questions... please help.
>>>
>>> Jacopo
>>>
>>>
>>      
>> ____________________________________________________________________________________
>> Looking for last minute shopping deals?  Find them fast with Yahoo!  
>> Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping
>

[Jacopo Cappellato]

David,

thank you for your valuable feedback; please see my comments inline:

David E Jones wrote:

>
> It sounds like Adrian's comments are a great scenario to address, but
> probably only one of various that we should target.
>
> In general with this sort of thing (or designing anything really) I
> really like the idea of two goals:
>
> 1. make it as "fool-proof" as possible; fool-proof is kind of a funny
> term and actually I prefer to avoid the opposite, ie make it
> not-error-prone
>
> 2. make it easy to do setup and maintain, including as much as possible
> having the system do the most obvious thing by default (that's obviously
> subjective, but narrowing the target audience can help significantly)
>
> In this case this is why I would favor for most settings have child
> organizations use parent organization settings if that setting is not
> present for the child. These should be considered on a granular level,
> like fields on the PartyAcctgPreference entity rather than looking for
> the entire record.
>

We can (rather) easily implement this behavior for the
PartyAcctgPreference entity; but I fear that applying this in general to
all the GL settings is a rather complex task to implement and, at least
with the current status of the user interface, also difficult to
understand for the user.
I mean that there are already a lot of different entities (some of them
organization specific and some of them global) used to map account types
to real account ids. If, for each of the lookup (if it fails), we have
to lookup at the same parent organization setting, then in my opinion we
should "expose" this to the user interface as well: showing the division
specific setting if exists, the parent division setting, and the global
setting all in the same screen... not easy to implement.
Also, should we address trees with more than one level
(company->division->subdivision)?

Any ideas on how we can simplify this effort?

Jacopo

> Some things may not default very well, like the chart of accounts... but
> defaulting may help there too I guess. Let me think out loud...
>
> The general idea for the pattern is that a single master chart of
> accounts is used for the entire "Company" and those would be associated
> with the top-level organization. Each sub-organization would have its
> own chart of accounts that is selected from the global one for the
> entire organization. Unless there are not sub-organizations the "root"
> organization would generally not have transactions posted against it.
>
> In that sense it would be nice to reduce maintenance and avoid run-time
> errors to have some defaulting in place. In fact if some GlAccount were
> a default for the parent organization, but not mapped to the child org,
> then we'd have to do this sort of defaulting to avoid a run-time error.
>
> I hope that makes sense...
>
> -David
>
>
> On Jan 25, 2008, at 9:06 AM, Jacopo Cappellato wrote:
>
>> Adrian,
>>
>> thanks for your comments:
>>
>> Adrian Crum wrote:
>>> Jacopo,
>>> I was talking to our accountant about this the other
>>> day. He said in a manual system, each division would
>>> be responsible for maintaining its own GL, and the
>>> results of those division's GLs would be posted to the
>>> parent company's GL.
>>
>> Is this done when the financial time period is closed (e.g. at the end
>> of the year), right?
>>
>>> In other words, the divisions would have all of the
>>> journal detail, but only their ending balances, etc
>>> would be posted to the parent company's GL.
>>
>> Ok, this is helpful; however my question was more about the way to
>> setup the accounting setup (gl mappings, preferences etc...) for each
>> divisions.
>>
>> Jacopo
>>
>>> -Adrian
>>> --- Jacopo Cappellato <[hidden email]> wrote:
>>>> What is the best way to implement the ability to
>>>> setup default GL settings for divisions for a certain company?
>>>>
>>>> For example, in the OFBiz demo data, we have the
>>>> "Company" company and some division (internal organizations, part of
>>>> Company): MARKETING, ACCOUNTING, SALES, DEV, TESTING.
>>>>
>>>> After that we setup the GL settings for the main
>>>> company ("Company"), what should we do to implement the GL settings for
>>>> its divisions?
>>>> What are the data that we have to duplicate?
>>>> Recently David Jones suggested an interesting
>>>> approach for the PartyAcctgPreference entity: if the record is
>>>> missing for a division, then get the one of its parent; in this way
>>>> we can
>>>> define, in a central place one Error Journal for all the divisions, one
>>>> currency etc...
>>>> We could also share the same approach for all the Gl
>>>> type/account mappings... but here things get tricky: how can we
>>>> know if we have to look at the parent's settings? Can we use the
>>>> existence of the PartyAcctgPreference as a way to know if there are
>>>> settings for the division or not?
>>>> However there are records that simply need to be
>>>> copied over: GlAccountOrganization (and possibly others) is a
>>>> good example; how should we implement this? Automatically copy the
>>>> record, when it is created, to all the divisions?
>>>>
>>>> There are many other similar issues and now I'm
>>>> start wondering if it is not simply better to just provide some
>>>> import/export
>>>> features that facilitate the process of cloning an accounting
>>>> setup from one company/division to another one.
>>>>
>>>> Hmmm... so many questions... please help.
>>>>
>>>> Jacopo
>>>>
>>>>
>>>      
>>> ____________________________________________________________________________________
>>>
>>> Looking for last minute shopping deals?  Find them fast with Yahoo!
>>> Search.  
>>> http://tools.search.yahoo.com/newsearch/category.php?category=shopping
>>

[David E Jones]

On Feb 7, 2008, at 5:46 AM, Jacopo Cappellato wrote:

> David,
>
> thank you for your valuable feedback; please see my comments inline:
>
> David E Jones wrote:
>> It sounds like Adrian's comments are a great scenario to address,  
>> but probably only one of various that we should target.
>> In general with this sort of thing (or designing anything really) I  
>> really like the idea of two goals:
>> 1. make it as "fool-proof" as possible; fool-proof is kind of a  
>> funny term and actually I prefer to avoid the opposite, ie make it  
>> not-error-prone
>> 2. make it easy to do setup and maintain, including as much as  
>> possible having the system do the most obvious thing by default  
>> (that's obviously subjective, but narrowing the target audience can  
>> help significantly)
>> In this case this is why I would favor for most settings have child  
>> organizations use parent organization settings if that setting is  
>> not present for the child. These should be considered on a granular  
>> level, like fields on the PartyAcctgPreference entity rather than  
>> looking for the entire record.
>
> We can (rather) easily implement this behavior for the  
> PartyAcctgPreference entity; but I fear that applying this in  
> general to all the GL settings is a rather complex task to implement  
> and, at least with the current status of the user interface, also  
> difficult to understand for the user.
> I mean that there are already a lot of different entities (some of  
> them organization specific and some of them global) used to map  
> account types to real account ids. If, for each of the lookup (if it  
> fails), we have to lookup at the same parent organization setting,  
> then in my opinion we should "expose" this to the user interface as  
> well: showing the division specific setting if exists, the parent  
> division setting, and the global setting all in the same screen...  
> not easy to implement.
> Also, should we address trees with more than one level (company-
> >division->subdivision)?
>
> Any ideas on how we can simplify this effort?

The easiest simplification would be to start with the code that looks  
for parent and default settings, and not worry about the UI for a  
while. In the UI (would be in various places) we could simply have a  
note about this defaulting pattern.

We could eventually create a UI that made this more clear, with forms  
for the current Int. Org. and all parent IntOrgs and any other default  
structures or whatever is applicable. Would be nice, but maybe not  
necessary with a little documentation.

-David

>
>> Some things may not default very well, like the chart of  
>> accounts... but defaulting may help there too I guess. Let me think  
>> out loud...
>> The general idea for the pattern is that a single master chart of  
>> accounts is used for the entire "Company" and those would be  
>> associated with the top-level organization. Each sub-organization  
>> would have its own chart of accounts that is selected from the  
>> global one for the entire organization. Unless there are not sub-
>> organizations the "root" organization would generally not have  
>> transactions posted against it.
>> In that sense it would be nice to reduce maintenance and avoid run-
>> time errors to have some defaulting in place. In fact if some  
>> GlAccount were a default for the parent organization, but not  
>> mapped to the child org, then we'd have to do this sort of  
>> defaulting to avoid a run-time error.
>> I hope that makes sense...
>> -David
>> On Jan 25, 2008, at 9:06 AM, Jacopo Cappellato wrote:
>>> Adrian,
>>>
>>> thanks for your comments:
>>>
>>> Adrian Crum wrote:
>>>> Jacopo,
>>>> I was talking to our accountant about this the other
>>>> day. He said in a manual system, each division would
>>>> be responsible for maintaining its own GL, and the
>>>> results of those division's GLs would be posted to the
>>>> parent company's GL.
>>>
>>> Is this done when the financial time period is closed (e.g. at the  
>>> end of the year), right?
>>>
>>>> In other words, the divisions would have all of the
>>>> journal detail, but only their ending balances, etc
>>>> would be posted to the parent company's GL.
>>>
>>> Ok, this is helpful; however my question was more about the way to  
>>> setup the accounting setup (gl mappings, preferences etc...) for  
>>> each divisions.
>>>
>>> Jacopo
>>>
>>>> -Adrian
>>>> --- Jacopo Cappellato <[hidden email]> wrote:
>>>>> What is the best way to implement the ability to
>>>>> setup default GL settings for divisions for a certain company?
>>>>>
>>>>> For example, in the OFBiz demo data, we have the
>>>>> "Company" company and some division (internal organizations,  
>>>>> part of
>>>>> Company): MARKETING, ACCOUNTING, SALES, DEV, TESTING.
>>>>>
>>>>> After that we setup the GL settings for the main
>>>>> company ("Company"), what should we do to implement the GL  
>>>>> settings for
>>>>> its divisions?
>>>>> What are the data that we have to duplicate?
>>>>> Recently David Jones suggested an interesting
>>>>> approach for the PartyAcctgPreference entity: if the record is
>>>>> missing for a division, then get the one of its parent; in this  
>>>>> way we can
>>>>> define, in a central place one Error Journal for all the  
>>>>> divisions, one
>>>>> currency etc...
>>>>> We could also share the same approach for all the Gl
>>>>> type/account mappings... but here things get tricky: how can we
>>>>> know if we have to look at the parent's settings? Can we use the
>>>>> existence of the PartyAcctgPreference as a way to know if there  
>>>>> are
>>>>> settings for the division or not?
>>>>> However there are records that simply need to be
>>>>> copied over: GlAccountOrganization (and possibly others) is a
>>>>> good example; how should we implement this? Automatically copy the
>>>>> record, when it is created, to all the divisions?
>>>>>
>>>>> There are many other similar issues and now I'm
>>>>> start wondering if it is not simply better to just provide some  
>>>>> import/export
>>>>> features that facilitate the process of cloning an accounting
>>>>> setup from one company/division to another one.
>>>>>
>>>>> Hmmm... so many questions... please help.
>>>>>
>>>>> Jacopo
>>>>>
>>>>>
>>>>      
>>>> ____________________________________________________________________________________
>>>> Looking for last minute shopping deals?  Find them fast with  
>>>> Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping
>>>
>