You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ja...@hotwaxmedia.com> on 2009/07/22 14:53:07 UTC
Question about GlAccountGroupMember
I think there is an error in the entity definition for the
GlAccountGroupMember, its primary key is defined as:
glAccountId
glAccountGroupTypeId
instead of:
glAccountId
glAccountGroupId
I really think that the field should be removed from the pk but also
from the entity; it doesn't make sense to me to have it this entity
since it is already in the GlAccountGroup entity.
Any comments/objections?
Jacopo
Re: Question about GlAccountGroupMember
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Jul 24, 2009, at 9:37 AM, David E Jones wrote:
>
> On Jul 23, 2009, at 11:43 AM, Jacopo Cappellato wrote:
>
>>
>> On Jul 22, 2009, at 11:37 PM, David E Jones wrote:
>>
>>>
>>> Why to do that might be more clear based on the initial "use case"
>>> for this as shown in the demo data for it (ie the tax form stuff).
>>
>> I had another look at the demo data, and I must confess it is not
>> 100% clear to me, but this is probably due to my lack of knowledge
>> of the US tax system.
>> By the way, if for the tax setup there is the need to constrain one
>> gl account to one group of type TAX_FIELD_US, wouldn't be better to
>> implement in the business logic instead of a constraint on the db?
>
> It doesn't really have anything to do with USA tax law, it is just
> organized around the general idea that the totals from certain sets
> of accounts are used to populate certain lines on tax forms. A
> common practice to facilitate tax preparation is to organize a chart
> of accounts such that no account is taken into account for multiple
> tax purposes so that you know how much should be allocated for what.
> Actually, half of the reason many companies maintain books is for
> government compliance.
>
Got it, thanks for the explanation. Wouldn't have been better to use a
name more specific to tax purposes instead of GlAccountGroup?
Something like GlAccountTaxForm or TaxForm? BTW, it is not so
important to me know since we will probably add two more generic
entities and not use the existing stuff.
Jacopo
> -David
>
Re: Question about GlAccountGroupMember
Posted by David E Jones <de...@me.com>.
On Jul 23, 2009, at 11:43 AM, Jacopo Cappellato wrote:
>
> On Jul 22, 2009, at 11:37 PM, David E Jones wrote:
>
>>
>> Why to do that might be more clear based on the initial "use case"
>> for this as shown in the demo data for it (ie the tax form stuff).
>
> I had another look at the demo data, and I must confess it is not
> 100% clear to me, but this is probably due to my lack of knowledge
> of the US tax system.
> By the way, if for the tax setup there is the need to constrain one
> gl account to one group of type TAX_FIELD_US, wouldn't be better to
> implement in the business logic instead of a constraint on the db?
It doesn't really have anything to do with USA tax law, it is just
organized around the general idea that the totals from certain sets of
accounts are used to populate certain lines on tax forms. A common
practice to facilitate tax preparation is to organize a chart of
accounts such that no account is taken into account for multiple tax
purposes so that you know how much should be allocated for what.
Actually, half of the reason many companies maintain books is for
government compliance.
-David
Re: Question about GlAccountGroupMember
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Jul 22, 2009, at 11:37 PM, David E Jones wrote:
>
> Why to do that might be more clear based on the initial "use case"
> for this as shown in the demo data for it (ie the tax form stuff).
I had another look at the demo data, and I must confess it is not 100%
clear to me, but this is probably due to my lack of knowledge of the
US tax system.
By the way, if for the tax setup there is the need to constrain one gl
account to one group of type TAX_FIELD_US, wouldn't be better to
implement in the business logic instead of a constraint on the db?
Jacopo
Re: Question about GlAccountGroupMember
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Jul 24, 2009, at 9:34 AM, David E Jones wrote:
>
> On Jul 23, 2009, at 11:20 AM, Jacopo Cappellato wrote:
>
>> Ah I understand now, thank you.
>> Well, this means that this entity as is doesn't work for the use
>> case I want to implement ("defining groups of gl accounts, where a
>> gl account could be in more than one group, of the same group type").
>
> That sounds like a design based on a use case. For what you want to
> support, which actor is trying to do what?
>
We are implementing some reports based on the concept of "cost
centers"... I am sure you know what I mean since we discussed this
together some time ago :-)
> And yes, for that particular design it sounds like it explicitly
> differs from what the current GlAccountGroup stuff.
>
Understood. The best solution available without modifying the existing
entity seems to me to add two new entities:
GlAccountCategory
GlAccountCategoryMember
Jacopo
> -David
>
>
>> I see two possible options:
>> 1) add the glAccountGroupId to the pk of the GlAccountGroupMember or
>> 2) create a new entity... but what name should we use? And: is it
>> ok to define another new entity to define group membership for
>> GlAccountGroup?
>>
>> Jacopo
>>
>> On Jul 22, 2009, at 11:37 PM, David E Jones wrote:
>>
>>>
>>> Is that an error or just a different design?
>>>
>>> The way the entity is setup constrains the group membership to one
>>> GlAccountGroup per GlAccountGroupType for each GlAccount. In other
>>> words, it is setup so that if you have a GlAccount and the desired
>>> GlAccountGroupType you can find out which group it is in.
>>>
>>> Why to do that might be more clear based on the initial "use case"
>>> for this as shown in the demo data for it (ie the tax form stuff).
>>>
>>> -David
>>>
>>>
>>> On Jul 22, 2009, at 6:53 AM, Jacopo Cappellato wrote:
>>>
>>>> I think there is an error in the entity definition for the
>>>> GlAccountGroupMember, its primary key is defined as:
>>>> glAccountId
>>>> glAccountGroupTypeId
>>>>
>>>> instead of:
>>>> glAccountId
>>>> glAccountGroupId
>>>>
>>>> I really think that the field should be removed from the pk but
>>>> also from the entity; it doesn't make sense to me to have it this
>>>> entity since it is already in the GlAccountGroup entity.
>>>>
>>>> Any comments/objections?
>>>>
>>>> Jacopo
>>>>
>>>
>>
>
Re: Question about GlAccountGroupMember
Posted by David E Jones <de...@me.com>.
On Jul 23, 2009, at 11:20 AM, Jacopo Cappellato wrote:
> Ah I understand now, thank you.
> Well, this means that this entity as is doesn't work for the use
> case I want to implement ("defining groups of gl accounts, where a
> gl account could be in more than one group, of the same group type").
That sounds like a design based on a use case. For what you want to
support, which actor is trying to do what?
And yes, for that particular design it sounds like it explicitly
differs from what the current GlAccountGroup stuff.
-David
> I see two possible options:
> 1) add the glAccountGroupId to the pk of the GlAccountGroupMember or
> 2) create a new entity... but what name should we use? And: is it ok
> to define another new entity to define group membership for
> GlAccountGroup?
>
> Jacopo
>
> On Jul 22, 2009, at 11:37 PM, David E Jones wrote:
>
>>
>> Is that an error or just a different design?
>>
>> The way the entity is setup constrains the group membership to one
>> GlAccountGroup per GlAccountGroupType for each GlAccount. In other
>> words, it is setup so that if you have a GlAccount and the desired
>> GlAccountGroupType you can find out which group it is in.
>>
>> Why to do that might be more clear based on the initial "use case"
>> for this as shown in the demo data for it (ie the tax form stuff).
>>
>> -David
>>
>>
>> On Jul 22, 2009, at 6:53 AM, Jacopo Cappellato wrote:
>>
>>> I think there is an error in the entity definition for the
>>> GlAccountGroupMember, its primary key is defined as:
>>> glAccountId
>>> glAccountGroupTypeId
>>>
>>> instead of:
>>> glAccountId
>>> glAccountGroupId
>>>
>>> I really think that the field should be removed from the pk but
>>> also from the entity; it doesn't make sense to me to have it this
>>> entity since it is already in the GlAccountGroup entity.
>>>
>>> Any comments/objections?
>>>
>>> Jacopo
>>>
>>
>
Re: Question about GlAccountGroupMember
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Ah I understand now, thank you.
Well, this means that this entity as is doesn't work for the use case
I want to implement ("defining groups of gl accounts, where a gl
account could be in more than one group, of the same group type").
I see two possible options:
1) add the glAccountGroupId to the pk of the GlAccountGroupMember or
2) create a new entity... but what name should we use? And: is it ok
to define another new entity to define group membership for
GlAccountGroup?
Jacopo
On Jul 22, 2009, at 11:37 PM, David E Jones wrote:
>
> Is that an error or just a different design?
>
> The way the entity is setup constrains the group membership to one
> GlAccountGroup per GlAccountGroupType for each GlAccount. In other
> words, it is setup so that if you have a GlAccount and the desired
> GlAccountGroupType you can find out which group it is in.
>
> Why to do that might be more clear based on the initial "use case"
> for this as shown in the demo data for it (ie the tax form stuff).
>
> -David
>
>
> On Jul 22, 2009, at 6:53 AM, Jacopo Cappellato wrote:
>
>> I think there is an error in the entity definition for the
>> GlAccountGroupMember, its primary key is defined as:
>> glAccountId
>> glAccountGroupTypeId
>>
>> instead of:
>> glAccountId
>> glAccountGroupId
>>
>> I really think that the field should be removed from the pk but
>> also from the entity; it doesn't make sense to me to have it this
>> entity since it is already in the GlAccountGroup entity.
>>
>> Any comments/objections?
>>
>> Jacopo
>>
>
Re: Question about GlAccountGroupMember
Posted by BJ Freeman <bj...@free-man.net>.
+1 for business logic, especially since we are internationalized.
Jacopo Cappellato sent the following on 7/23/2009 10:43 AM:
>
> On Jul 22, 2009, at 11:37 PM, David E Jones wrote:
>
>>
>> Why to do that might be more clear based on the initial "use case" for
>> this as shown in the demo data for it (ie the tax form stuff).
>
> I had another look at the demo data, and I must confess it is not 100%
> clear to me, but this is probably due to my lack of knowledge of the US
> tax system.
> By the way, if for the tax setup there is the need to constrain one gl
> account to one group of type TAX_FIELD_US, wouldn't be better to
> implement in the business logic instead of a constraint on the db?
>
> Jacopo
>
>
--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.
Re: Question about GlAccountGroupMember
Posted by David E Jones <de...@me.com>.
Is that an error or just a different design?
The way the entity is setup constrains the group membership to one
GlAccountGroup per GlAccountGroupType for each GlAccount. In other
words, it is setup so that if you have a GlAccount and the desired
GlAccountGroupType you can find out which group it is in.
Why to do that might be more clear based on the initial "use case" for
this as shown in the demo data for it (ie the tax form stuff).
-David
On Jul 22, 2009, at 6:53 AM, Jacopo Cappellato wrote:
> I think there is an error in the entity definition for the
> GlAccountGroupMember, its primary key is defined as:
> glAccountId
> glAccountGroupTypeId
>
> instead of:
> glAccountId
> glAccountGroupId
>
> I really think that the field should be removed from the pk but also
> from the entity; it doesn't make sense to me to have it this entity
> since it is already in the GlAccountGroup entity.
>
> Any comments/objections?
>
> Jacopo
>