Bug 5173 - Allow the discount to be editable
Summary: Allow the discount to be editable
Status: RESOLVED DUPLICATE of bug 5335
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: master
Hardware: All All
: PATCH-Sent (DO NOT USE) enhancement (vote)
Assignee: Robin Sheat
QA Contact: Bugs List
Depends on:
Reported: 2010-08-25 03:08 UTC by Robin Sheat
Modified: 2013-04-14 07:34 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:

First patch - UI changes only (3.91 KB, patch)
2010-08-26 05:36 UTC, Robin Sheat
Details | Diff | Splinter Review
Second patch - database update (2.74 KB, patch)
2010-08-26 05:37 UTC, Robin Sheat
Details | Diff | Splinter Review
proposed patch (4.71 KB, patch)
2010-08-30 00:30 UTC, Robin Sheat
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Robin Sheat 2010-08-25 03:08:27 UTC
We have a situation where a vendor gives a different discount depending on who the publisher is that you're getting the books from. As such, we need the discount to be changeable on a per-order basis.
Comment 1 Katrin Fischer 2010-08-25 08:02:55 UTC
When I did a presentation on acq some times ago, the librarians told me that the tax should be editable on a per-order or even per-item basis too, because we have different taxes for books, serials and online ressources. Using the tax field in the vendor only as standard value, that can be adjusted if necessary.
Comment 2 Robin Sheat 2010-08-25 22:34:19 UTC
Discount, or tax? It's discount I'm aiming for here, but otherwise it's pretty much what you say. It's actually per-item (or rather, per order of /n/ copies of a particular item) because that's how the interface works. A patch for this is underway.
Comment 3 Robin Sheat 2010-08-26 05:36:48 UTC Comment hidden (obsolete)
Comment 4 Robin Sheat 2010-08-26 05:37:55 UTC
Created attachment 2576 [details] [review]
Second patch - database update

This patch allows the discount value to be saved and recalled along with the order, so that viewing an order again will look a bit more sensible.
Comment 5 Robin Sheat 2010-08-26 05:40:01 UTC
I've added two patches to deal with this. The first one will likely be acceptable for 3.2.1 or thereabouts, the second one (which applies on top of the first) requires a db schema change, and so will have to wait for 3.4.

These are going to go through internal QA before I send them upstream, but feel free to test them out now.
Comment 6 Katrin Fischer 2010-08-26 05:43:01 UTC
I will try to test your patches, perhaps I can rewrite them to do the same for tax :)
Comment 7 Robin Sheat 2010-08-26 05:47:01 UTC
Awesome :) It should be fairly easy to go from this to allowing the tax to be configurable.
Comment 8 Colin Campbell 2010-08-26 15:05:58 UTC
For tax I wonder if what is needed is something like an 'order type' to drive it. At present its related to vendors but that does not seem the most logical relation. In the UK for instance books are 'zero-rated' for vat but other goods may have the full vat rate. It is not inconceivable that you might get books and sound-recordings from the same vendor so one is a book-type orderline the other a sound-recording-type and the tax rates differ even if we send them as one order/basket.
Comment 9 Robin Sheat 2010-08-30 00:30:31 UTC
Created attachment 2583 [details] [review]
proposed patch

This addresses an issue found by QA.
Comment 10 Robin Sheat 2010-08-30 00:31:56 UTC
Forgot to put a good description on that patch. Anyway, it just updates the functioning of the UI side of things so that the default value is correctly populated by the vendor default.
Comment 11 Katrin Fischer 2010-12-06 16:57:36 UTC
I applied both patches to HEAD and fixed some problems with kohaversion.pl and updatedatabase.pl. 

Not sure this is due to my changed, but the discount field in the order should be prepopulated with the discount value from the vendor. 

I think we are missing a statement in updatadatabase.pl to take the default value from the vendor into the column aqorders.discount.

I pushed the patches with my changes to a new branch in my public repo:
Comment 12 Katrin Fischer 2010-12-07 17:12:11 UTC

1) create new vendor with discount = 5
2) create new basket
3) create new order
4) !discount field is empty, budgeted cost says '(adjusted for 0.00% discount)'
5) !enter vendor price - discount is not calculated
6) enter value 5 in discount - discount is calculated correctly, budegeted cost says '(adjusted for 5.00% discount)' 
7) save
8) modify order - all values shown correctly.

Default value from vendor seems not to work.


1) search for vendor with discount rate - here 5
2) modify order from pre discount commits and database change
3) !discount field is empty, budgeted cost shows '(adjusted for 0.00% discount)', discount is not calculated into price at all

After you have entered something in the discount field and the column discount in aqorders was populated it seems to work ok.
Comment 13 Katrin Fischer 2011-05-03 08:18:04 UTC
I tested this patch a longer while ago and think that it might not apply now. 
I also found some problems that I think need to be fixed.
Comment 14 Katrin Fischer 2013-04-14 07:34:11 UTC

*** This bug has been marked as a duplicate of bug 5335 ***