[Koha-bugs] [Bug 18736] Problems in order calculations (rounding errors)

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18736

Nick Clemens <nick at bywatersolutions.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Failed QA                   |In Discussion

--- Comment #162 from Nick Clemens <nick at bywatersolutions.com> ---
(In reply to Marcel de Rooy from comment #161)
> Test pass. QA pass.
> Hmm. Not wanting to be too precise, but we still have some subtle
> differences in some lines of the last patch. The first line rounds at the
> unit; with a whole quantity, it will be rounded. The second line is not
> rounded since you multiply with tax rate. The algorithm of tax = incl - excl
> is only used in the first line.
> The third line shows rounding at final stage.
> +            $order->{tax_value_on_ordering} = (
> get_rounded_price($order->{ecost_tax_included}) -
> get_rounded_price($order->{ecost_tax_excluded}) ) * $order->{quantity};
> +            $order->{tax_value_on_ordering} = $order->{quantity} *
> get_rounded_price($order->{ecost_tax_excluded}) *
> $order->{tax_rate_on_ordering};
> 
> +        my $subtotal = get_rounded_price( $left *
> $data->{'ecost_tax_included'} );
> 
> Please explain why you do what you do.

The first line is when the user entered prices including tax - so we have to
calculate excluding tax(In reply to Marcel de Rooy from comment #161)
> Test pass. QA pass.
> Hmm. Not wanting to be too precise, but we still have some subtle
> differences in some lines of the last patch. The first line rounds at the
> unit; with a whole quantity, it will be rounded. The second line is not
> rounded since you multiply with tax rate. The algorithm of tax = incl - excl
> is only used in the first line.
> The third line shows rounding at final stage.
> +            $order->{tax_value_on_ordering} = (
> get_rounded_price($order->{ecost_tax_included}) -
> get_rounded_price($order->{ecost_tax_excluded}) ) * $order->{quantity};
> +            $order->{tax_value_on_ordering} = $order->{quantity} *
> get_rounded_price($order->{ecost_tax_excluded}) *
> $order->{tax_rate_on_ordering};
> 
> +        my $subtotal = get_rounded_price( $left *
> $data->{'ecost_tax_included'} );
> 
> Please explain why you do what you do.

In the first line we are looking at prices supplied including tax - I assumed
we get a rounded number from the vendor - I also assume they charge the tax to
a single item then round - so we need to back calculate the tax, not knowing
the unrounded end product - then charge this same amount per item

In the second case (lines 2 and 3) we are given prices without tax, so we can
calculate it on our own - and I assume they would perform the same caulcation -
round discounted price, apply quantity and tax

The issue is really that when getting a price including tax I assume we don't
have full info, so do my best to calculate what I expect.

Can you explain how you would expect to calculate that and what numbers you
would expect to see?

The tests illustrate that I do expect different numbers in the different
scenarios, I honestly don't know what the vendors or librarians expect and
would accept any quidance

-- 
You are receiving this mail because:
You are watching all bug changes.