Accounting - Tax Authorities - GL Accounts

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Accounting - Tax Authorities - GL Accounts

jonatan soto
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.
Reply | Threaded
Open this post in threaded view
|

Re: Accounting - Tax Authorities - GL Accounts

BJ Freeman
use a subaccount under the mains Tax Authority account, unless I don't
clearly understand your situation.

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


Jonatan Soto sent the following on 5/7/2010 8:11 AM:

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


Reply | Threaded
Open this post in threaded view
|

Re: Accounting - Tax Authorities - GL Accounts

jonatan soto
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.



On Fri, May 7, 2010 at 7:49 PM, BJ Freeman <[hidden email]> wrote:

> use a subaccount under the mains Tax Authority account, unless I don't
> clearly understand your situation.
>
> =========================
> 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
> >
>
>
> Jonatan Soto sent the following on 5/7/2010 8:11 AM:
> > 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.
> >
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Accounting - Tax Authorities - GL Accounts

Bob Morley
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.  :)
Reply | Threaded
Open this post in threaded view
|

Re: Accounting - Tax Authorities - GL Accounts

BJ Freeman
In reply to this post by jonatan soto
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.  :)