Accounting - Tax Authorities - GL Accounts

[Jonatan Soto <se...@gmail.com>]

Hi list,

I'm wonder why is not possible to define more GL Accounts for the same
PartyID (in that case a Company) using the same Tax Authority. There are a
few GL Accounts in the spanish accounting used by the Tax Authority so I
must do that.

There is a note in
https://cwiki.apache.org/confluence/display/OFBENDUSER/08.4+GL+Accountsregarding
to this w/o a finally answer, so is there any side-effect if I
change the DDL of TAX_AUTHORITY_GL_ACCOUNT in order to define a primary key
including the GL_ACCOUNT_ID?

Regards.

Re: Accounting - Tax Authorities - GL Accounts

[Bob Morley <rm...@emforium.com>]

jonatan soto wrote:
> 
> In Spain (and I think other countries of EU) uses a predefined
> hierarchical
> GL. If I create subaccounts will vulnerate the integrity of the PGC (Plan
> general contable) so I don't think that is the solution but I understand
> your comment. It will work for US with no doubt.
> In fact, it was impossible to understand what I wanted to say because I
> didn't put it in context. I continued an old topic last week talking about
> the integration of the spanish PGC to Ofbiz and this time I created a new
> one w/o a reference to the other.
> 
> Anyway I appreciate your input.
> 

Right now Ofbiz supports binding a particular tax authority in a specific
geographical region for an internal organization to a specific GL Account
(as you have indicated).  The short-coming as I see it is that you could not
have multiple rates supported by that tax authority go to different GL
accounts.  The use case here would be having a tax authority that charges
AST ("A" sales tax) and BST ("B" sales tax) but wants the taxes collected
and remitted to different accounts / on different schedules.

If this in any way resembles your problem then I think the solution may be
to provide an override gl account on the tax_authority_rate_product table
(similar to other override gl account fields in the system).  The idea would
be when an order adjustment that is related to the "AST" sales tax is posted
it would first check this override gl account and (if not set) fall back on
the standard gl account for that tax authority / geo.  In the end you could
have separate GL accounts for each tax rate associated with the tax
authority in the system.

Then again it is likely I missed the point too.  :)
-- 
View this message in context: http://ofbiz.135035.n4.nabble.com/Accounting-Tax-Authorities-GL-Accounts-tp2134359p2135585.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: Accounting - Tax Authorities - GL Accounts

[BJ Freeman <bj...@free-man.net>]

Bob defining what to charge is done by the method you describe, OOTB.
In accounting though you need a GL number assigned to put in the right
reporting category.

jonatan:
i could not find a english description so I am of no help.

=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
Specialtymarket.com <http://www.specialtymarket.com/>

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>


Bob Morley sent the following on 5/7/2010 12:51 PM:
> 
> jonatan soto wrote:
>> In Spain (and I think other countries of EU) uses a predefined
>> hierarchical
>> GL. If I create subaccounts will vulnerate the integrity of the PGC (Plan
>> general contable) so I don't think that is the solution but I understand
>> your comment. It will work for US with no doubt.
>> In fact, it was impossible to understand what I wanted to say because I
>> didn't put it in context. I continued an old topic last week talking about
>> the integration of the spanish PGC to Ofbiz and this time I created a new
>> one w/o a reference to the other.
>>
>> Anyway I appreciate your input.
>>
> 
> Right now Ofbiz supports binding a particular tax authority in a specific
> geographical region for an internal organization to a specific GL Account
> (as you have indicated).  The short-coming as I see it is that you could not
> have multiple rates supported by that tax authority go to different GL
> accounts.  The use case here would be having a tax authority that charges
> AST ("A" sales tax) and BST ("B" sales tax) but wants the taxes collected
> and remitted to different accounts / on different schedules.
> 
> If this in any way resembles your problem then I think the solution may be
> to provide an override gl account on the tax_authority_rate_product table
> (similar to other override gl account fields in the system).  The idea would
> be when an order adjustment that is related to the "AST" sales tax is posted
> it would first check this override gl account and (if not set) fall back on
> the standard gl account for that tax authority / geo.  In the end you could
> have separate GL accounts for each tax rate associated with the tax
> authority in the system.
> 
> Then again it is likely I missed the point too.  :)