Question about GlAccountGroupMember

[Jacopo Cappellato-4]

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

[David E. Jones-2]

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
>

[Jacopo Cappellato-4]

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

[Jacopo Cappellato-4]

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]

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

[David E. Jones-2]

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

[David E. Jones-2]

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

[Jacopo Cappellato-4]

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

[Jacopo Cappellato-4]

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
>