This new feature will permit to update the tax rate on receiving. It has also been described on the wiki page (http://wiki.koha-community.org/wiki/GST_Rewrite_RFC).
Created attachment 33869 [details] [review] Bug 13323: Tax rate can change on receiving - DB changes This patch adds 4 new DB fields to the aqorders table: * tax_rate_on_ordering * tax_rate_on_receiving * tax_value_on_ordering * tax_value_on_receiving
Created attachment 33870 [details] [review] Bug 13323: Tax rate can change on receiving This commit permits to update the tax rate on receiving.
Created attachment 33871 [details] [review] Bug 13323: [DO NOT PUSH] Tax rate can change on receiving - DBIC changes
To test these patches, have a look at http://lists.koha-community.org/pipermail/koha-devel/2014-December/041024.html
I tested this patch on BibLibre's sandbox17. Here is what I did. I created 4 new vendors to test 4 different set ups : Set up 1 = List prices INCLUDE TAX + Invoice prices INCLUDE TAX Set up 2 = List prices EXCLUDE TAX + Invoice prices EXCLUDE TAX Set up 3 = List prices INCLUDE TAX + Invoice prices EXCLUDE TAX Set up 4 = List prices EXCLUDE TAX + Invoice prices INCLUDE TAX For each vendor, default tax rate is 5%. Then, for each vendor : * I add 1 basket with 1 item. Vendor price is 10 euros. Default tax rate is 5%. * I check the prices and tax caculation on the basket page. Everything is well calculated (prices tax included or excluded) * I close the basket and go to the receive page * I receive the item and change the tax rate to 10%. * I check the prices and tax calculation on the receive page. For the set ups 1 and 2, I have what I expected. Not for the set ups 3 and 4. Set up 1 (List prices INCLUDE TAX + Invoice prices INCLUDE TAX): Ordering : Vendor price (tax incl) = 10 euros <---- what I entered Vendor price (tax excl) = 9.52 euros Tax amount (5%) = 0.48 euros Total (tax excl) = 9.52 euros Total (tax incl) = 10 euros Receiving : Vendor price (tax incl) = 10 euros (= value in actual cost) Vendor price (tax excl) = 9.09 euros Tax amount (10%) = 0.91 euros Total (tax excl) = 9.09 euros Total (tax incl) = 10 euros Set up 2 (List prices EXCLUDE TAX + Invoice prices EXCLUDE TAX): Ordering : Vendor price (tax incl) = 10.5 euros Vendor price (tax excl) = 10 euros <---- what I entered Tax amount (5%) = 0.5 euros Total (tax excl) = 10 euros Total (tax incl) = 10.5 euros Receiving : Vendor price (tax incl) = 11 euros Vendor price (tax excl) = 10 euros (= value in actual cost) Tax amount (10%) = 1 euros Total (tax excl) = 10 euros Total (tax incl) = 11 euros Set up 3 (List prices INCLUDE TAX + Invoice prices EXCLUDE TAX): Ordering : Vendor price (tax incl) = 10 euros <---- what I entered Vendor price (tax excl) = 9.52 euros Tax amount (5%) = 0.48 euros Total (tax excl) = 9.52 euros Total (tax incl) = 10 euros Receiving (what we have now): Vendor price (tax incl) = 10.47 euros Vendor price (tax excl) = 9.52 euros (= value in actual cost) Tax amount (10%) = 0.95 euros Total (tax excl) = 9.52 euros Total (tax incl) = 10.47 euros Receiving (what I expected): Vendor price (tax incl) = 10 euros Vendor price (tax excl) = 9.09 euros (= value in actual cost) Tax amount (10%) = 0.91 euros Total (tax excl) = 9.09 euros Total (tax incl) = 10 euros Since I entered the price tax included and then changed the tax rate, I expected the actual cost, which is here the price tax excluded, to be recalculated. But here, the value in actual cost is the price tax excluded calculated on the price tax included with a 5% tax (but I changed it to 10%...) Set up 4 (List prices EXCLUDE TAX + Invoice prices INCLUDE TAX): Ordering : Vendor price (tax incl) = 10.5 euros Vendor price (tax excl) = 10 euros <---- what I entered Tax amount (5%) = 0.5 euros Total (tax excl) = 10 euros Total (tax incl) = 10.5 euros Receiving (what we have) : Vendor price (tax incl) = 10.50 euros (= value in actual cost) Vendor price (tax excl) = 9.55 euros Tax amount (10%) = 0.95 euros Total (tax excl) = 9.55 euros Total (tax incl) = 10.50 euros Receiving (what I expected) : Vendor price (tax incl) = 11 euros (= value in actual cost) Vendor price (tax excl) = 10 euros Tax amount (10%) = 1 euros Total (tax excl) = 10 euros Total (tax incl) = 11 euros Same logic than before. I expected the value in actual cost to be recalculated. In a few words, I expect the reference value on which calculation should be based to be the one I entered when I placed the order. So, if I change the tax rate during the receiving process, I expect the actual cost to be recalculated. Here, the actual cost calculation is always based on the tax rate we have when placing the order. To me, it's not logical. Jonathan, could you ask librarians in charge of acquisition what they think of this. I'll trust their judgment. If the logic in place is good. You can signed off these patches. If not, tell me when it's ready and I'll test it again. ;^)
Set up 3 (List prices INCLUDE TAX + Invoice prices EXCLUDE TAX): I think that Vendor price (tax excl) when receiving should be the same as calculated in Ordering. In my mind this price is kind of 'base' price for the item. So the following seems to be logical for me : Ordering : Vendor price (tax incl) = 10 euros <---- what I entered Vendor price (tax excl) = 9.52 euros Tax amount (5%) = 0.48 euros Total (tax excl) = 9.52 euros Total (tax incl) = 10 euros Receiving (what we have now): Vendor price (tax incl) = 10.47 euros Vendor price (tax excl) = 9.52 euros (= value in actual cost) Tax amount (10%) = 0.95 euros Total (tax excl) = 9.52 euros Total (tax incl) = 10.47 euros Set up 4 (List prices EXCLUDE TAX + Invoice prices INCLUDE TAX): is less evident : I wonder if Vendor price (tax excl) should be changed between order and reception. If it's not the case, François's proposition should be considered But we have no library examples of case where the way of using tax include/exclude changes between ordering and receiving, so I am not really for changing the calculation just now without more real experience of how it should be.
For the setup 3 (List prices INCLUDE TAX + Invoice prices EXCLUDE TAX), I would have the same analysis as Laurence : the change of tax between order and receipt should not change prices tax excl. that are the basis. So this patch introduce the right calculation. For the setup4 (List prices EXCLUDE TAX + Invoice prices INCLUDE TAX), It would be better that the price tax incl. was recalculated in the order receive page. But for me, it's not the most important. What really matters is that the calculation is right after the receipt was recorded. There's often a change of price between the order and the receipt and the calculation have to take into account the entered price. Sonia Bouis
In the end, about the set up 3, Laurence, Sonia, I agree with both of you. About the set up 4, I'll keep what we have now because it shares the same logic thabn the set up 3. I tested the patches on Biblibre's sandbox17. Jonathan, could you sign them off on my behalf? Thanks!
(In reply to Francois Charbonnier from comment #8) > I tested the patches on Biblibre's sandbox17. > > Jonathan, could you sign them off on my behalf? > > Thanks! Thanks François! I will add you signoff to the commit on the remote branch. Thanks for testing!
(In reply to Francois Charbonnier from comment #8) > Jonathan, could you sign them off on my behalf? Added on the remote branch :)
(In reply to Jonathan Druart from comment #10) > (In reply to Francois Charbonnier from comment #8) > > Jonathan, could you sign them off on my behalf? > > Added on the remote branch :) Jonathan, could you rebase your patches and attach them to this bug? I'd like to try to QA them!
Created attachment 47495 [details] [review] Bug 13323: Tax rate can change on receiving - DB changes Rebased on master
Created attachment 47496 [details] [review] Bug 13323: Tax rate can change on receiving Rebased on master
All patches rebased on master. Also, sandbox 17 has been updated with those patches: http://pro.test17.biblibre.com/
Created attachment 47499 [details] [review] Bug 13323: QA fix (trailing whitespace)
Created attachment 48874 [details] [review] Bug 13323: Tax rate can change on receiving - DB changes Rebased on master and added Signed-off-by lines that were lost in the process
Created attachment 48875 [details] [review] Bug 13323: Tax rate can change on receiving Rebased on master and added Signed-off-by lines that were lost in the process
Created attachment 48876 [details] [review] Bug 13323: QA fix (trailing whitespace)
Dependent bug 13321 is Failed QA. Please reset status once 13321 is ok.
Created attachment 51982 [details] [review] Bug 13323: Tax rate can change on receiving - DB changes This patch adds 4 new DB fields to the aqorders table: * tax_rate_on_ordering * tax_rate_on_receiving * tax_value_on_ordering * tax_value_on_receiving Signed-off-by: Laurence Rault <laurence.rault@biblibre.com> Signed-off-by: Francois Charbonnier <francois.charbonnier@inlibro.com> Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr>
Created attachment 51983 [details] [review] Bug 13323: Tax rate can change on receiving This commit permits to update the tax rate on receiving. Signed-off-by: Laurence Rault <laurence.rault@biblibre.com> Signed-off-by: Francois Charbonnier <francois.charbonnier@inlibro.com> Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr>
Created attachment 51984 [details] [review] Bug 13323: QA fix (trailing whitespace)
Created attachment 56096 [details] [review] Bug 13323: Tax rate can change on receiving - DB changes This patch adds 4 new DB fields to the aqorders table: * tax_rate_on_ordering * tax_rate_on_receiving * tax_value_on_ordering * tax_value_on_receiving Signed-off-by: Laurence Rault <laurence.rault@biblibre.com> Signed-off-by: Francois Charbonnier <francois.charbonnier@inlibro.com> Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr>
Created attachment 56097 [details] [review] Bug 13323: Tax rate can change on receiving This commit permits to update the tax rate on receiving. Signed-off-by: Laurence Rault <laurence.rault@biblibre.com> Signed-off-by: Francois Charbonnier <francois.charbonnier@inlibro.com> Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr>
Created attachment 56098 [details] [review] Bug 13323: QA fix (trailing whitespace)
Created attachment 56387 [details] [review] Bug 13323: Recalculate tax_value for partially received orders Test plan: 1. Create an order with at least 2 items 2. Receive only 1 item 3. Check that the tax value of the received order line is correct on the parcel and invoice pages 4. Check that the tax value of the original order line is correct (on the basket page for example) 5. Cancel the receipt 6. Check that the tax value of the original order line is correct
Created attachment 56433 [details] [review] Bug 13323: Tax rate can change on receiving - DB changes This patch adds 4 new DB fields to the aqorders table: * tax_rate_on_ordering * tax_rate_on_receiving * tax_value_on_ordering * tax_value_on_receiving Signed-off-by: Laurence Rault <laurence.rault@biblibre.com> Signed-off-by: Francois Charbonnier <francois.charbonnier@inlibro.com> Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr> Signed-off-by: Sonia Bouis <koha@univ-lyon3.fr>
Created attachment 56434 [details] [review] Bug 13323: Tax rate can change on receiving This commit permits to update the tax rate on receiving. Signed-off-by: Laurence Rault <laurence.rault@biblibre.com> Signed-off-by: Francois Charbonnier <francois.charbonnier@inlibro.com> Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr> Signed-off-by: Sonia Bouis <koha@univ-lyon3.fr>
Created attachment 56435 [details] [review] Bug 13323: QA fix (trailing whitespace) Signed-off-by: Sonia Bouis <koha@univ-lyon3.fr>
Created attachment 56436 [details] [review] Bug 13323: Recalculate tax_value for partially received orders Test plan: 1. Create an order with at least 2 items 2. Receive only 1 item 3. Check that the tax value of the received order line is correct on the parcel and invoice pages 4. Check that the tax value of the original order line is correct (on the basket page for example) 5. Cancel the receipt 6. Check that the tax value of the original order line is correct Signed-off-by: Sonia Bouis <koha@univ-lyon3.fr>
tested with all the configuration of vendor possible (GST include/exclude). I have tried to change the price / GST on receiving. I have tried partial receipt. All works as described.
Created attachment 56894 [details] [review] Bug 13323: Tax rate can change on receiving - DB changes This patch adds 4 new DB fields to the aqorders table: * tax_rate_on_ordering * tax_rate_on_receiving * tax_value_on_ordering * tax_value_on_receiving Signed-off-by: Laurence Rault <laurence.rault@biblibre.com> Signed-off-by: Francois Charbonnier <francois.charbonnier@inlibro.com> Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr> Signed-off-by: Sonia Bouis <koha@univ-lyon3.fr> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 56895 [details] [review] Bug 13323: Tax rate can change on receiving This commit permits to update the tax rate on receiving. Signed-off-by: Laurence Rault <laurence.rault@biblibre.com> Signed-off-by: Francois Charbonnier <francois.charbonnier@inlibro.com> Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr> Signed-off-by: Sonia Bouis <koha@univ-lyon3.fr> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 56896 [details] [review] Bug 13323: QA fix (trailing whitespace) Signed-off-by: Sonia Bouis <koha@univ-lyon3.fr> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 56897 [details] [review] Bug 13323: Recalculate tax_value for partially received orders Test plan: 1. Create an order with at least 2 items 2. Receive only 1 item 3. Check that the tax value of the received order line is correct on the parcel and invoice pages 4. Check that the tax value of the original order line is correct (on the basket page for example) 5. Cancel the receipt 6. Check that the tax value of the original order line is correct Signed-off-by: Sonia Bouis <koha@univ-lyon3.fr> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Pushed to master for 16.11, thanks Jonathan, Julian!