I think there is a bug in Tax Authority ,Please anyone check ?

[kunal aggarwal <ku...@gmail.com>]

Hi all

When we create tax authority, in that when we add product rates, we add the
type of tax like sales tax,export tax,income tax etc and enter the
corresponding rate.
Ofbiz take these taxes as adjustments , right.


So when we create sales order,  these adjustments are added into
*order_adjustment
*table . When we see the contents of this table, then adjustment_type is
stored as "*SALES_TAX*" . I think it should be added as the type of tax we
configure in tax authority ( *export,sales,income tax *etc).


I think this is a bug.

Can please anyone look for this.
Would be of great help

Regards
Kunal

Re: I think there is a bug in Tax Authority ,Please anyone check ?

[kunal aggarwal <ku...@gmail.com>]

Hi Scott

Thanks for spending time for my query. I will do this and will share the
results soon.

Kunal


On Tue, Aug 12, 2008 at 2:48 PM, Scott Gray <le...@gmail.com> wrote:

> Hi Kunal
>
> I am fairly confident in that what I have told you is correct, I guess
> you have three options:
> 1. Trust that what I have said is accurate and be prepared to do the
> extra work required
> 2.  Run a search on the order component for "SALES_TAX" so that you
> can see how that adjustment type is treated differently from other
> adjustments
> 3.  Make the change that you think is required and see what happens
>
> Best of luck
> Scott
>
> 2008/8/12 kunal aggarwal <ku...@gmail.com>:
> > Hi Scott
> >
> > I have analysed the things and came to the conclusion that
> >
> > 1. When we create orders , then after selecting shipments , mode of
> > payments  we finalise the order for final review .
> >    That screen shows all the items we add to the cart and also show the
> > taxes applied on products. , RITE?
> > 2. At this point only ,  insert into table is triggered . This table
> > is "*order_adjustment"
> > .* You can see the various contents and fields of     this table . It
> > contains the adjustments type as "*SALES_TAX"* and also contains various
> > other fields like oder_ID,amount etc.
> >    That means that tax has been calculated first and then this insert
> into
> > this table is done. So the bug is in the insertion of this table. I think
> > editing this insert query wont effect the tax calculation , since tax has
> > been calculated first and then insert is done. So OFBIZ's  3 decimal
> > precision rule wont be effected if we can edit that insert query .
> >
> > DONT know i am correct or not. You better tell for this.
> >
> > Please look into this.
> >
> >
> > KUNAL *
> > *
> > On Mon, Aug 11, 2008 at 1:22 PM, Scott Gray <le...@gmail.com> wrote:
> >
> >> Hi Kunal
> >>
> >> I think you're underestimating the issue, a lot more work would need
> >> to be done other than just making sure the correct type is copied
> >> over.  All of the order total calculations relating to tax look for
> >> adjustments of type SALES_TAX only which means other types are going
> >> to be rounded to 2 decimal places at the adjustment level (tax is
> >> rounded to 3) which will lead to inaccuracies and they'll probably all
> >> end up lumped in "other adjustments" when displayed on screen or in
> >> order confirmations.
> >>
> >> That's why I say rather than being a bug, the support for other tax
> >> types just isn't really there at the moment.
> >>
> >> Regards
> >> Scott
> >>
> >> 2008/8/11 kunal aggarwal <ku...@gmail.com>:
> >> > Hi Scott
> >> >
> >> > When we create sales order for abroad , then custom tax , export taxes
> >> are
> >> > charged
> >> > However , Ofbiz always shows "SALES_TAX" . Though ofbiz is picking all
> >> taxe
> >> > authorities correctly , but i think it should show the type of tax
> that
> >> we
> >> > create. Ofbiz is inserting
> >> > "SALES_TAX" in table *order_adjustment. *I think ofbiz should insert
> the
> >> > type of tax that we create in tax authority into this table.However
> ofbiz
> >> is
> >> > inserting only *SALES_TAX * as tax type .
> >> >
> >> > I think its a bug. I will try to resolve too if i find in which file
> this
> >> > part of coding is done. Otherwise Can please anyone look into this.
> >> >
> >> >
> >> > Please try doing this
> >> >
> >> > 1. Create tax authority and add tax type top be export tax , sales tax
> >> both
> >> > 2. create sales order
> >> > 3. check enteries in *order_adjustment* table. You will see the two
> >> enteries
> >> > having adjustments type as SALES_TAX for both. I think one entry
> should
> >> show
> >> > EXPORT_TAX and other SALES_TAX
> >> >
> >> >
> >> > Kunal
> >> >
> >> >
> >> > On Mon, Aug 11, 2008 at 11:43 AM, Scott Gray <le...@gmail.com>
> wrote:
> >> >
> >> >> I doubt it should be considered a bug but more like sales tax being
> >> >> the only tax type currently supported for sales orders.
> >> >> But I guess if it is taking an export tax and marking it as a sales
> >> >> tax then that it is a problem.
> >> >>
> >> >> I think if a tax is not marked as sales tax then it should be ignored
> >> >> by the system, I don't think it is wise just assume that these other
> >> >> tax types require the exact same calculation methods as is used for
> >> >> sales taxes.
> >> >>
> >> >> Regards
> >> >> Scott
> >> >>
> >> >> 2008/8/11 kunal aggarwal <ku...@gmail.com>:
> >> >> > Hi all
> >> >> >
> >> >> > When we create tax authority, in that when we add product rates, we
> >> add
> >> >> the
> >> >> > type of tax like sales tax,export tax,income tax etc and enter the
> >> >> > corresponding rate.
> >> >> > Ofbiz take these taxes as adjustments , right.
> >> >> >
> >> >> >
> >> >> > So when we create sales order,  these adjustments are added into
> >> >> > *order_adjustment
> >> >> > *table . When we see the contents of this table, then
> adjustment_type
> >> is
> >> >> > stored as "*SALES_TAX*" . I think it should be added as the type of
> >> tax
> >> >> we
> >> >> > configure in tax authority ( *export,sales,income tax *etc).
> >> >> >
> >> >> >
> >> >> > I think this is a bug.
> >> >> >
> >> >> > Can please anyone look for this.
> >> >> > Would be of great help
> >> >> >
> >> >> > Regards
> >> >> > Kunal
> >> >> >
> >> >>
> >> >
> >>
> >
>

Re: I think there is a bug in Tax Authority ,Please anyone check ?

[Scott Gray <le...@gmail.com>]

Hi Kunal

I am fairly confident in that what I have told you is correct, I guess
you have three options:
1. Trust that what I have said is accurate and be prepared to do the
extra work required
2.  Run a search on the order component for "SALES_TAX" so that you
can see how that adjustment type is treated differently from other
adjustments
3.  Make the change that you think is required and see what happens

Best of luck
Scott

2008/8/12 kunal aggarwal <ku...@gmail.com>:
> Hi Scott
>
> I have analysed the things and came to the conclusion that
>
> 1. When we create orders , then after selecting shipments , mode of
> payments  we finalise the order for final review .
>    That screen shows all the items we add to the cart and also show the
> taxes applied on products. , RITE?
> 2. At this point only ,  insert into table is triggered . This table
> is "*order_adjustment"
> .* You can see the various contents and fields of     this table . It
> contains the adjustments type as "*SALES_TAX"* and also contains various
> other fields like oder_ID,amount etc.
>    That means that tax has been calculated first and then this insert into
> this table is done. So the bug is in the insertion of this table. I think
> editing this insert query wont effect the tax calculation , since tax has
> been calculated first and then insert is done. So OFBIZ's  3 decimal
> precision rule wont be effected if we can edit that insert query .
>
> DONT know i am correct or not. You better tell for this.
>
> Please look into this.
>
>
> KUNAL *
> *
> On Mon, Aug 11, 2008 at 1:22 PM, Scott Gray <le...@gmail.com> wrote:
>
>> Hi Kunal
>>
>> I think you're underestimating the issue, a lot more work would need
>> to be done other than just making sure the correct type is copied
>> over.  All of the order total calculations relating to tax look for
>> adjustments of type SALES_TAX only which means other types are going
>> to be rounded to 2 decimal places at the adjustment level (tax is
>> rounded to 3) which will lead to inaccuracies and they'll probably all
>> end up lumped in "other adjustments" when displayed on screen or in
>> order confirmations.
>>
>> That's why I say rather than being a bug, the support for other tax
>> types just isn't really there at the moment.
>>
>> Regards
>> Scott
>>
>> 2008/8/11 kunal aggarwal <ku...@gmail.com>:
>> > Hi Scott
>> >
>> > When we create sales order for abroad , then custom tax , export taxes
>> are
>> > charged
>> > However , Ofbiz always shows "SALES_TAX" . Though ofbiz is picking all
>> taxe
>> > authorities correctly , but i think it should show the type of tax that
>> we
>> > create. Ofbiz is inserting
>> > "SALES_TAX" in table *order_adjustment. *I think ofbiz should insert the
>> > type of tax that we create in tax authority into this table.However ofbiz
>> is
>> > inserting only *SALES_TAX * as tax type .
>> >
>> > I think its a bug. I will try to resolve too if i find in which file this
>> > part of coding is done. Otherwise Can please anyone look into this.
>> >
>> >
>> > Please try doing this
>> >
>> > 1. Create tax authority and add tax type top be export tax , sales tax
>> both
>> > 2. create sales order
>> > 3. check enteries in *order_adjustment* table. You will see the two
>> enteries
>> > having adjustments type as SALES_TAX for both. I think one entry should
>> show
>> > EXPORT_TAX and other SALES_TAX
>> >
>> >
>> > Kunal
>> >
>> >
>> > On Mon, Aug 11, 2008 at 11:43 AM, Scott Gray <le...@gmail.com> wrote:
>> >
>> >> I doubt it should be considered a bug but more like sales tax being
>> >> the only tax type currently supported for sales orders.
>> >> But I guess if it is taking an export tax and marking it as a sales
>> >> tax then that it is a problem.
>> >>
>> >> I think if a tax is not marked as sales tax then it should be ignored
>> >> by the system, I don't think it is wise just assume that these other
>> >> tax types require the exact same calculation methods as is used for
>> >> sales taxes.
>> >>
>> >> Regards
>> >> Scott
>> >>
>> >> 2008/8/11 kunal aggarwal <ku...@gmail.com>:
>> >> > Hi all
>> >> >
>> >> > When we create tax authority, in that when we add product rates, we
>> add
>> >> the
>> >> > type of tax like sales tax,export tax,income tax etc and enter the
>> >> > corresponding rate.
>> >> > Ofbiz take these taxes as adjustments , right.
>> >> >
>> >> >
>> >> > So when we create sales order,  these adjustments are added into
>> >> > *order_adjustment
>> >> > *table . When we see the contents of this table, then adjustment_type
>> is
>> >> > stored as "*SALES_TAX*" . I think it should be added as the type of
>> tax
>> >> we
>> >> > configure in tax authority ( *export,sales,income tax *etc).
>> >> >
>> >> >
>> >> > I think this is a bug.
>> >> >
>> >> > Can please anyone look for this.
>> >> > Would be of great help
>> >> >
>> >> > Regards
>> >> > Kunal
>> >> >
>> >>
>> >
>>
>

Re: I think there is a bug in Tax Authority ,Please anyone check ?

[kunal aggarwal <ku...@gmail.com>]

Hi Scott

I have analysed the things and came to the conclusion that

1. When we create orders , then after selecting shipments , mode of
payments  we finalise the order for final review .
    That screen shows all the items we add to the cart and also show the
taxes applied on products. , RITE?
2. At this point only ,  insert into table is triggered . This table
is "*order_adjustment"
.* You can see the various contents and fields of     this table . It
contains the adjustments type as "*SALES_TAX"* and also contains various
other fields like oder_ID,amount etc.
    That means that tax has been calculated first and then this insert into
this table is done. So the bug is in the insertion of this table. I think
editing this insert query wont effect the tax calculation , since tax has
been calculated first and then insert is done. So OFBIZ's  3 decimal
precision rule wont be effected if we can edit that insert query .

DONT know i am correct or not. You better tell for this.

Please look into this.


KUNAL *
*
On Mon, Aug 11, 2008 at 1:22 PM, Scott Gray <le...@gmail.com> wrote:

> Hi Kunal
>
> I think you're underestimating the issue, a lot more work would need
> to be done other than just making sure the correct type is copied
> over.  All of the order total calculations relating to tax look for
> adjustments of type SALES_TAX only which means other types are going
> to be rounded to 2 decimal places at the adjustment level (tax is
> rounded to 3) which will lead to inaccuracies and they'll probably all
> end up lumped in "other adjustments" when displayed on screen or in
> order confirmations.
>
> That's why I say rather than being a bug, the support for other tax
> types just isn't really there at the moment.
>
> Regards
> Scott
>
> 2008/8/11 kunal aggarwal <ku...@gmail.com>:
> > Hi Scott
> >
> > When we create sales order for abroad , then custom tax , export taxes
> are
> > charged
> > However , Ofbiz always shows "SALES_TAX" . Though ofbiz is picking all
> taxe
> > authorities correctly , but i think it should show the type of tax that
> we
> > create. Ofbiz is inserting
> > "SALES_TAX" in table *order_adjustment. *I think ofbiz should insert the
> > type of tax that we create in tax authority into this table.However ofbiz
> is
> > inserting only *SALES_TAX * as tax type .
> >
> > I think its a bug. I will try to resolve too if i find in which file this
> > part of coding is done. Otherwise Can please anyone look into this.
> >
> >
> > Please try doing this
> >
> > 1. Create tax authority and add tax type top be export tax , sales tax
> both
> > 2. create sales order
> > 3. check enteries in *order_adjustment* table. You will see the two
> enteries
> > having adjustments type as SALES_TAX for both. I think one entry should
> show
> > EXPORT_TAX and other SALES_TAX
> >
> >
> > Kunal
> >
> >
> > On Mon, Aug 11, 2008 at 11:43 AM, Scott Gray <le...@gmail.com> wrote:
> >
> >> I doubt it should be considered a bug but more like sales tax being
> >> the only tax type currently supported for sales orders.
> >> But I guess if it is taking an export tax and marking it as a sales
> >> tax then that it is a problem.
> >>
> >> I think if a tax is not marked as sales tax then it should be ignored
> >> by the system, I don't think it is wise just assume that these other
> >> tax types require the exact same calculation methods as is used for
> >> sales taxes.
> >>
> >> Regards
> >> Scott
> >>
> >> 2008/8/11 kunal aggarwal <ku...@gmail.com>:
> >> > Hi all
> >> >
> >> > When we create tax authority, in that when we add product rates, we
> add
> >> the
> >> > type of tax like sales tax,export tax,income tax etc and enter the
> >> > corresponding rate.
> >> > Ofbiz take these taxes as adjustments , right.
> >> >
> >> >
> >> > So when we create sales order,  these adjustments are added into
> >> > *order_adjustment
> >> > *table . When we see the contents of this table, then adjustment_type
> is
> >> > stored as "*SALES_TAX*" . I think it should be added as the type of
> tax
> >> we
> >> > configure in tax authority ( *export,sales,income tax *etc).
> >> >
> >> >
> >> > I think this is a bug.
> >> >
> >> > Can please anyone look for this.
> >> > Would be of great help
> >> >
> >> > Regards
> >> > Kunal
> >> >
> >>
> >
>

Re: I think there is a bug in Tax Authority ,Please anyone check ?

[Scott Gray <le...@gmail.com>]

Hi Kunal

I think you're underestimating the issue, a lot more work would need
to be done other than just making sure the correct type is copied
over.  All of the order total calculations relating to tax look for
adjustments of type SALES_TAX only which means other types are going
to be rounded to 2 decimal places at the adjustment level (tax is
rounded to 3) which will lead to inaccuracies and they'll probably all
end up lumped in "other adjustments" when displayed on screen or in
order confirmations.

That's why I say rather than being a bug, the support for other tax
types just isn't really there at the moment.

Regards
Scott

2008/8/11 kunal aggarwal <ku...@gmail.com>:
> Hi Scott
>
> When we create sales order for abroad , then custom tax , export taxes are
> charged
> However , Ofbiz always shows "SALES_TAX" . Though ofbiz is picking all taxe
> authorities correctly , but i think it should show the type of tax that we
> create. Ofbiz is inserting
> "SALES_TAX" in table *order_adjustment. *I think ofbiz should insert the
> type of tax that we create in tax authority into this table.However ofbiz is
> inserting only *SALES_TAX * as tax type .
>
> I think its a bug. I will try to resolve too if i find in which file this
> part of coding is done. Otherwise Can please anyone look into this.
>
>
> Please try doing this
>
> 1. Create tax authority and add tax type top be export tax , sales tax both
> 2. create sales order
> 3. check enteries in *order_adjustment* table. You will see the two enteries
> having adjustments type as SALES_TAX for both. I think one entry should show
> EXPORT_TAX and other SALES_TAX
>
>
> Kunal
>
>
> On Mon, Aug 11, 2008 at 11:43 AM, Scott Gray <le...@gmail.com> wrote:
>
>> I doubt it should be considered a bug but more like sales tax being
>> the only tax type currently supported for sales orders.
>> But I guess if it is taking an export tax and marking it as a sales
>> tax then that it is a problem.
>>
>> I think if a tax is not marked as sales tax then it should be ignored
>> by the system, I don't think it is wise just assume that these other
>> tax types require the exact same calculation methods as is used for
>> sales taxes.
>>
>> Regards
>> Scott
>>
>> 2008/8/11 kunal aggarwal <ku...@gmail.com>:
>> > Hi all
>> >
>> > When we create tax authority, in that when we add product rates, we add
>> the
>> > type of tax like sales tax,export tax,income tax etc and enter the
>> > corresponding rate.
>> > Ofbiz take these taxes as adjustments , right.
>> >
>> >
>> > So when we create sales order,  these adjustments are added into
>> > *order_adjustment
>> > *table . When we see the contents of this table, then adjustment_type is
>> > stored as "*SALES_TAX*" . I think it should be added as the type of tax
>> we
>> > configure in tax authority ( *export,sales,income tax *etc).
>> >
>> >
>> > I think this is a bug.
>> >
>> > Can please anyone look for this.
>> > Would be of great help
>> >
>> > Regards
>> > Kunal
>> >
>>
>

Re: I think there is a bug in Tax Authority ,Please anyone check ?

[kunal aggarwal <ku...@gmail.com>]

Hi Scott

When we create sales order for abroad , then custom tax , export taxes are
charged
However , Ofbiz always shows "SALES_TAX" . Though ofbiz is picking all taxe
authorities correctly , but i think it should show the type of tax that we
create. Ofbiz is inserting
"SALES_TAX" in table *order_adjustment. *I think ofbiz should insert the
type of tax that we create in tax authority into this table.However ofbiz is
inserting only *SALES_TAX * as tax type .

I think its a bug. I will try to resolve too if i find in which file this
part of coding is done. Otherwise Can please anyone look into this.


Please try doing this

1. Create tax authority and add tax type top be export tax , sales tax both
2. create sales order
3. check enteries in *order_adjustment* table. You will see the two enteries
having adjustments type as SALES_TAX for both. I think one entry should show
EXPORT_TAX and other SALES_TAX


Kunal


On Mon, Aug 11, 2008 at 11:43 AM, Scott Gray <le...@gmail.com> wrote:

> I doubt it should be considered a bug but more like sales tax being
> the only tax type currently supported for sales orders.
> But I guess if it is taking an export tax and marking it as a sales
> tax then that it is a problem.
>
> I think if a tax is not marked as sales tax then it should be ignored
> by the system, I don't think it is wise just assume that these other
> tax types require the exact same calculation methods as is used for
> sales taxes.
>
> Regards
> Scott
>
> 2008/8/11 kunal aggarwal <ku...@gmail.com>:
> > Hi all
> >
> > When we create tax authority, in that when we add product rates, we add
> the
> > type of tax like sales tax,export tax,income tax etc and enter the
> > corresponding rate.
> > Ofbiz take these taxes as adjustments , right.
> >
> >
> > So when we create sales order,  these adjustments are added into
> > *order_adjustment
> > *table . When we see the contents of this table, then adjustment_type is
> > stored as "*SALES_TAX*" . I think it should be added as the type of tax
> we
> > configure in tax authority ( *export,sales,income tax *etc).
> >
> >
> > I think this is a bug.
> >
> > Can please anyone look for this.
> > Would be of great help
> >
> > Regards
> > Kunal
> >
>

Re: I think there is a bug in Tax Authority ,Please anyone check ?

[Scott Gray <le...@gmail.com>]

I doubt it should be considered a bug but more like sales tax being
the only tax type currently supported for sales orders.
But I guess if it is taking an export tax and marking it as a sales
tax then that it is a problem.

I think if a tax is not marked as sales tax then it should be ignored
by the system, I don't think it is wise just assume that these other
tax types require the exact same calculation methods as is used for
sales taxes.

Regards
Scott

2008/8/11 kunal aggarwal <ku...@gmail.com>:
> Hi all
>
> When we create tax authority, in that when we add product rates, we add the
> type of tax like sales tax,export tax,income tax etc and enter the
> corresponding rate.
> Ofbiz take these taxes as adjustments , right.
>
>
> So when we create sales order,  these adjustments are added into
> *order_adjustment
> *table . When we see the contents of this table, then adjustment_type is
> stored as "*SALES_TAX*" . I think it should be added as the type of tax we
> configure in tax authority ( *export,sales,income tax *etc).
>
>
> I think this is a bug.
>
> Can please anyone look for this.
> Would be of great help
>
> Regards
> Kunal
>