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
