To reproduce:
1- create a basket
2- add more of 20 orders with uncertain price
3- click on uncertain price button
4- on page 1 of list, uncheck uncertain box of an order
5- click on save button
6- orders who were on page 2 are not display anymore in page uncertainprice.pl
7- return to basket view acqui/basket.pl
8- orders who were on page 2 have "rvcd" label and quantity is null
The data in page 2 and beyond is not transmitted, but the code doesn't
handle that. This patch makes sure that all that (empty) data is not (wrongly) processed.
Sponsored by: CCSR
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 5bc36cd672)
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
(cherry picked from commit 794229750f)
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
At the moment there are several cases, when closing a basket is not
possible:
- when there are no order lines in it
- when there are order lines with uncertain prices
- when the basket is marked as a standing order
The first case wasn't checked correctly as only pending/received
orders would be counted, but not cancelled orders.
To test:
- Create a basket
- Create an order line
- Verify the "close this basket" button shows
- Cancel the order line - the button disappears
- Apply the patch
- Verify the button appears and works now
- Create another basket - make sure you cannot close it
without order lines
- Create an order line with uncertain price checked
- you cannot close it
- Resolve the uncertain price - you can now close the basket.
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 2d6595a1bf)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 87cbd07be8)
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
We don't allow editing of orders that are part of a closed basket, but
we don't enforce the rule in the controller file.
This patch use output_and_exit to stop the script and display an error
to the end user.
Test plan:
Create a basket, add an order
On the basket view you see the "Modify" link, open it in a separate tab
=> You can edit the basket
Keep this tab open, get back to the other one and close the basket
Reload the tab with the order edition form
=> You cannot longer edit the basket
QA: Do we need a check in addorder.pl as well?
Signed-off-by: Henry Bolshaw <bolshawh@parliament.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 0310e973a4)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit deffb12491)
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
If 'Actual cost' has not been set then it has the value of 0.00 which
Perl evaluates to true so this patchset resets it to 0, so the fallback
to ecost_tax_included/ecost_tax_excluded happens.
Test plan:
1. Add item to acquisition basket (make sure the vendor has: tax rate: 15%, 'List prices: Include tax', 'Invoice prices: Include tax')
2. Set 'Vendor price' = 10 and do not set 'Actual cost'
3. Save order
4. Observe basket.pl shows 'Total tax exc.' has a value of 0.00 and GST
column has value of -8.70
5. Jump into the database:
select tax_value_on_ordering from aqorders where
ordernumber=<ordernumber>;
[You can get the ordernumber from clicking on the 'Modify' line the item
is listed in]
6. Observe a negative value: -8.70
7. Apply patch and restart plack
8. Add a second item to the basket
9. Set 'Vendor price' = 10 and don't set 'Actual cost'
10. Save order
11. Observe basket.pl shows 'Total tax exc' has value of 8.70 and GST
has value of 1.30
12. Repeat step 5 and observe tax_value_on_ordering = 1.30
13. Run t/Prices.t unit test:
sudo koha-shell <instancename>
prove t/Prices.t
Sponsored-by: Horowhenua District Council, NZ
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 7b66b90fe7)
(cherry picked from commit 3bbf638449)
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
It defaults to 0 in get_template_and_user
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
The feature was there but a condition disabled it.
Test plan:
- modify the default value for 008@ or another subfield in the ACQ framework using one or more of the placeholders above
- activate UseACQFrameworkForBiblioRecords
- create a basket
- create an order from a new record
- verify the values have been replaced
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit b16e463173)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 34b5cd5267)
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
We did not take into account the vendor selected.
Test plan:
1. Choose Vendor
2. Create Basket
3. Assign a new vendor
Without the patch this new vendor is not changed
With the patch applied the vendor is changed
4. Edit the basket, change the vendor
Reported-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Rhonda Kuiper <rkuiper@roundrocktexas.gov>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit cd716269a7)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit b2514759bc)
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
This is simply a SQL change that makes things a bit easier to read
and also prevents too much data being returned in a large system
To test:
1 - Have some orders in your system in the ordered status
2 - Click the 'Ordered' amount for your budget from Acquisitions home
3 - Note the view of orders, possibly screen shot
4 - Apply patch
5 - Restart all the things
6 - Reload the ordered page
7 - Confirm nothing has changed
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Joy Nelson <joy@bywatersolutions.com>
We allow for the user to add multiple users to this field, and the
search function expects and array. We have been treating it as a scalar
TO test:
1 - Have an open basket in acquisitions
2 - Add to basket - from an existing order (copy)
3 - Enter a name in the 'Basket created by' field and select a user
4 - Hit search
5 - ISE (Can't use string ("1") as an ARRAY ref while "strict refs" in use at /usr/share/koha/lib/C4/Acquisition.pm line 2482.)
6 - Apply patch
7 - Repeat 1-4
8 - Success!
9 - Test with mutiple 'created by' entries as well
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
A successful message says that the email has been sent and the order has
been claimed, but nothing happened.
Test plan:
0. Do not apply this patch
1. Create a new vendor, does not create a contact
2. Create some orders, close the basket
3. Go to the late orders page and claims some orders
=> You get a successful message, but the claim has not been done!
4. Apply this patch
5. Claim the orders
=> You get an error
6. Set a contact for the vendor
7. Claim the orders
=> Success
In the docker container, you may need to:
% apt install postfix
% postfix start
Edit /etc/hosts
127.0.0.1 localhost localhost.localdomain
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Joy Nelson <joy@bywatersolutions.com>
and remove 'scalar' keyword in calls where it's not needed.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Joy Nelson <joy@bywatersolutions.com>
This patch modifies basketgroups.pl so that existing data about a basket
group's billing and delivery place are correctly preselected in the edit
form. These fields shouldn't reset to the logged-in user's home branch
just because they have an empty value.
To test, apply the patch and go to Acquisitions -> Vendor -> Basket
groups.
When adding or editing a basket group the pre-selected value for
"Billing place" and "Delivery place" should be correct:
- When creating a new basket group: The logged-in user's library
should be pre-selected.
- When editing a basket group which has a library defined for either
the billing or delivery places, the correct library should be
pre-selected.
- When editing a basket group which has no library defined for either
the billing or delivery place there should be no library
pre-selected (the "--" option should be pre-selected).
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Joy Nelson <joy@bywatersolutions.com>
Bug 8417 added the ability to edit the date received, but a merge
conflict was wrongly resolved during a rebase of
commit 20d9ed618f
Bug 13321: Rename variables
Test plan:
Create an order
Receive it
Set a date (different from today)
=> The date you picked should have been set in DB for the order
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Joy Nelson <joy@bywatersolutions.com>
When exporting a basket group, the names of the files are different:
* pdf => aqbasketgroup.name(.pdf)
* csv => aqbasketgroup.id(.csv)
Better to use basketgroup's name for consistency and readability
Test plan:
Create a basketgroup and export it in pdf and CSV. The name of the
generated file must be the basketgroup's name suffixed by the extension.
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch modifies two pages so that the "Uncertain price" information
is shown by the template rather than the Perl script, making the text
translatable.
To test, apply the patch and go to Acquisitions.
- Locate or create an order in a basket which has an uncertain price.
- When viewing the contents of that basket the order which was marked
as having an uncertain price should be labeled "Uncertain."
- The same should be true for the invoice page. If you don't have an
existing invoice with an "uncertain" order,
- Go to "Receive shipments" for the vendor your "uncertain" order is
with.
- Create a new invoice.
- Receive one or more orders which has an uncertain price.
- Press the "finish receiving" button.
- In the "Invoice details" section of the invoice page you should
see the "Uncertain" label on the correct order.
Signed-off-by: Christophe Croullebois <christophe.croullebois@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
For the invoice view: close, receive, reopen, mark prices uncertain, go
to the invoice page (not sure it's expected however)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
1 - Create a new basket in acq, mark it as 'standing'
2 - Add an item, leave the RRP and Vendor price as 0
3 - Receive shipments for the vendor
4 - Select the title from this basket
5 - On receipt enter an actual cost
6 - Finsih receiving
7 - Go to the basket
8 - Note the total for the order and the basket are 0, keep this browser tab open
9 - Open a new browser tab and create a new non standing basket
10 - Add to basket, again with no RRP or vendor price
11 - Close the basket, receive the item
12 - Enter an actual cost on receipt
13 - Return to view the basket
14 - Total and order are $0
15 - Apply patch
16 - Refresh the basket in both tabs
17 - You now see the actual price for the orders
Signed-off-by: Rhonda Kuiper <rkuiper@roundrocktexas.gov>
Signed-off-by: Bouzid Fergani <bouzid.fergani@inlibro.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test Plan:
1) Create a basket with a non-default value for aqbasket.create_items
2) Click Edit from basket.pl
3) Click Save without changing anything
4) Note that aqbasket.create_items is no longer set
5) Apply this patch
6) Restart all the things!
7) Repeat steps 1-3
8) Note create_items is unchanged!
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Currently the order search can't be limited by managing library.
The patch adds the search option to the order history search form
and a column for the managing library to the search results table.
To test:
- Create some baskets with orders
- Set managing library for some, but also have some without
- Apply patch
- prove t/db_dependent/Acquisition.t
- Go to Aquisition > Orders search tab on top > Advanced search link
- Search for orders without limiting
Orders with and without managing library set should show up
- Limit search to a specific managing library
- Verify results match expectations
Signed-off-by: Alex Sassmannshausen <alex@komputilo.eu>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
1 - Add to basket
2 - Note the options on the page
3 - Add &close=1 to the url
4 - Note some inputs are disabled
5 - Save anyway, note it is a regular order
6 - Add another order to basket
7 - Save it
8 - Modify
9 - Add close to the url again
10 - Save changes
11 - No functional change
12 - Apply patch
13 - Note close parameter has no effect now
14 - Confirm you can place and confirm orders as before
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
On Nov 3rd 2019, Brazil will skip from 00:00 to 1:00 (http://www.currenttimeonline.com/dst/dst.do?tz=America/Sao_Paulo), DateTime consider it as an invalid date.
It is a problem when we are playing with dates without the time part (always 00:00).
When we instantiate a DateTime (from dt_from_string) we are already handling this issue, and use the floating timezone (since bug 12669).
The problem remains when we generate a DateTime then add or subtract a duration, which will result in an invalid date:
DateTime->new(year => 2019, month => 12, day => 3, time_zone => 'America/Sao_Paulo')->subtract(days => 30);
=> Nov 3rd 2019, kaboom.
We should replace all the problematic occurrences of dt_from_string->subtract (or ->add)
with dt_from_string(undef, undef, 'floating'), to use the floating timezone and avoid the error.
Actually there are not many of them, I have found only 3 that could
produce real problems.
The other occurrences are:
- in tests => Not a big deal (for now)
- called on a datetime, so it will explode if called at midnight
00:00:00 (and nobody should work at that time).
Test plan:
0/ Define the timezone to 'America/Sao_Paulo' (in your koha-conf.xml file), restart_all
1/ Set a patron's expiry date to Dec 3rd 2019, and
NotifyBorrowerDeparture to 30 (default value)
2/ See the checkouts page for this user
=> Without this patch you get "Invalid local time for date in time zone:
America/Sao_Paulo"
=> With this patch apply the page displays correctly
QA will review the 2 other occurrences.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 21622 attempted to fix some grouping for strict mode, however, it failed to take into account that single order can have multiple item types.
To recreate:
1 - Place an order for 4 copies of a title in acq
2 - Make sure you are creating orders when ordering (AcqCreateItems syspref and/or when creating basket)
3 - Set three items to one type, and one to another
4 - Go to Acqui-Home and click 'ordered' for the used budget
5 - Note the line is duplicated for each itemtype in the order
6 - Recieve the items and note the same issue on 'Spent'
7 - Place another order as before so you have the problem in both ordered.pl and spent/pl
8 - Apply patch
9 - Note orders are no longer duplicated
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
1 - Have a basket
2 - Add an order
3 - Modify the order, note you cannot see the unitprice/Actual cost
4 - Apply patch
5 - Note it is there
6 - Add to IntranetUserCSS:
.ordering_unitprice{ display:none; }
7 - Reload
8 - Note it is hidden
Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
0 - Clear MarcFieldsToOrder and MarcItemFieldsToOrder preferences
1 - Have a budget/fund/vendor in acquisitions
2 - Create or find a basket for vendor
3 - Add to basket from a file or staged batch (can use any record)
4 - Note there is no option for replacement price
5 - Add the order
6 - Replacement price is 0 - you must modify order or set upon receiving
7 - Apply patch
8 - Repeat
9 - Disable matchign check during add to basket
10 - Note you can specify a replacement price
11 - Do so
12 - Note it is saved in order
Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
1 - Hit neworderbiblio with a query and no vendor
http://localhost:8081/cgi-bin/koha/acqui/neworderbiblio.pl?q=cat
Or, add to basket from existing record with a search
Refresh the page (url has no parameters)
2 - Get an internal server error
3 - Add bookseller
http://localhost:8081/cgi-bin/koha/acqui/neworderbiblio.pl?q=cat&booksellerid=1
4 - Click 'Order' on a result
5 - Internal server error
6 - Apply patch
7 - Repeat 1-4, you get 'Vendor not found' or 'Basket not found'
Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Unify and clean up subtitle usage so that it's always used as a simple array and not the old hash structure.
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
On the fund detail page, have some shipment costs associated with a fund
an example would be cgi-bin/koha/acqui/spent.pl?fund=<your fund>&fund_code=<your
code>
Click the link for the fund, without this patch it will give an internal
server error.
With this patch, the shipment invoice will be loaded.
Signed-off-by: Jason DeShaw <JDeShaw@fargolibrary.org>
Signed-off-by: Laurel Moran <lmoran@sdlawlibrary.org>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
- Turn UseACQFrameworkForBiblioRecords on
- Add 003@ to the ACQ framework
- Create an order from an existing record
=> The 003 value will be displayed!
It fixes the following error:
Control fields (generally, just tags below 010) do not have subfields,
use data() at /home/vagrant/kohaclone/acqui/neworderempty.pl line 293.
Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds the budgetname to the return of SearchSuggestion
to improve performance.
To test:
- Same test plan as for the first patch
- Verify fund names show in the table
- Run t/db_dependent/Suggestions.t
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
When adding an order line to a basket using the 'from a suggestion'
feature, the list of accepted suggestions doesn't show any information
from the acquisition are of the suggestions.
This patch adds new columns to the list for:
- library
- fund
- price
- quantity
- total
To test:
- Create several suggestions with
- Empty acq values
- A specific library, any library
- Set acq values (fund, price, quantity)
- Accept your suggestions
- Create a new basket/order
- Add an order line from accepted suggestions
- Verify the list displays nicely with the new columns
- Verify filters etc. still work ok
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Mistakenly, we were looking at listincgst in the templates but using
invoiceincgst in the scripts. This patch rectifies that by switching to
use invoiceincgst in the templates too.
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
To test:
1 - Have AcqCreateItems set to 'On ordering' (or set in a basket)
2 - Define MARCItemFieldsToOrder
homebranch: 975$a
holdingbranch: 975$b
itype: 975$y
nonpublic_note: 975$x
public_note: 975$z
loc: 975$c
ccode: 970$c
notforloan: 975$7
uri: 975$u
copyno: 975$n
quantity: 975$q
budget_code: 975$h
price: 975$g
replacementprice: 975$p
3 - Have a marc record with some order info defined as above, including a replacementprice
4 - Add to basket - > from a new file
5 - Don't check for duplicates, add the order
6 - Note the order has no replacementprice, but the item does
7 - Close basket, receive order, do not enter a new replacement price
8 - Note the items replacement price is clear
9 - Apply patch
10 - Repeat
11 - Note when order added to basket it has a replacement price
12 - Note when order is received the replacement price is populated and passed into item correctly
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
To test:
1 - Enable order price rounding
2 - Order an example with 8 * 16,99 and 42% discount, 19.45% tax.
3 - Check ordered page - 94.17 is total
4 - Check aqui-home - 94.16 is total
5 - Apply patch
6 - Verify numbers now match
Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Caused by
commit 31c29fd31f
Bug 21206: Replace C4::Items::GetItem
The log says: The method Koha::Item->collection is not covered by tests!
It has highlighted an older problem:
Since
commit bb1e9c500c
Bug 17248 - Koha::AuthorisedValues - Remove GetKohaAuthorisedValueLib
the "Collection code" is not filled correctly (items.collection vs items.ccode).
Test plan:
- Set acqcreateitem to "when placing an order"
- Receive an order with items
=> The "Collection code" column must be filled with the items.ccode value
- Edit an item (You may need the patches on bug 22669)
- Change the collection code value
=> The "Collection code" column must be filled with the new value
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
To test:
1 - Find a vendor in acquisitions
2 - Click 'receive shipment'
3 - Create an invoice
4 - Click 'Finish receiving'
5 - Add an adjustment that encumbers while open and update adjustments
6 - Go to acqui-home and click on the ordered total for the fund with the adjustment
7 - Note the invoice adjustment shows the invoice id and does not link
8 - Add another invoice and another adjustment, but close the invoice this time
9 - Go to acqui-home and click on the spent total for the fund with the adjustment
10 - Note the invoice adjustment shows the invoice id and does not link
11 - Apply patch
12 - Visit the spent and ordered pages and note the adjustments show invoicenumber and are links
13 - prove -v t/db_dependent/Koha/Acquisition/Invoice/Adjustments.t
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Marcel's comments pointed out that while I tried to avoid storing
rounded values it is required for tax generation.
This patch makes that change and adds test coverage and POD for
populate_order_with_prices
To test:
Follow plan on other patches, ensure that orders and totals match on the
basket, invoice, and budget pages
prove -v t/db_dependent/Acquisition/populate_order_with_prices.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch:
Adds a missing use
Uses 'Koha::Number::Price->round()' instead of 'format()' to ensure numeric
returns
Ensures too big numbers don't crash round()
Uses syspref in 'GetBudgetHierarchy'
To test:
Follow previous test plan
Check values on admin/aqbudgets.pl are affected by syspref
Ensure values throughout acquisitions are correctly calculated/displayed
(even when greater than 1,000)
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
To test:
Place an order (no tax just for simplicity)
listprice/rrp = 16.99
discount = 42%
quantity = 8
estimated calculated at 9.85
but order total is 78.83, but 8 times 9.85 = 78.80
Apply patches, set OrderPriceRounding syspref to 'Nearest cent'
Not order total is now as expected
View ordered.pl and confirm values are correct
Complete order, view invoice and confirm values
View spent.pl and confirm values
Go through acquisitions module and confirm prices throughout are
correct.
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
A lot of code can be removed just by using Koha::Object
It also makes fetching and updating additional field values easier.
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Blou
Katrin Fischer
Jonathan Druart
Alex Buckley
Aleisha Amohia
Nick Clemens
Julian Maurice
Owen Leonard
Martin Renvoize
Kyle M Hall
Ere Maijala
Josef Moravec
Liz Rea