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.
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.
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.
Created attachment 2575 [details] [review]
First patch - UI changes only
This patch allows the discount value to be edited on the order page, however the discount itself isn't saved, so you don't get it back if you view the order again. Note that the prices will still remain correct.
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.
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.
I will try to test your patches, perhaps I can rewrite them to do the same for tax :)
Awesome :) It should be fairly easy to go from this to allowing the tax to be configurable.
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.
Created attachment 2583 [details] [review]
This addresses an issue found by QA.
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.
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:
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)'
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.
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.
*** This bug has been marked as a duplicate of bug 5335 ***