Commit graph

256 commits

Author SHA1 Message Date
Stefan Weil
64925f7522 Bug 14383: C4: Fix some typos (mostly in comments and documentation)
Most of them were found and fixed using codespell.
Fix also some related grammar issues.

In C4/Serials.pm a variable was renamed to make future codespelling
checks easier.

Signed-off-by: Stefan Weil <sw@weilnetz.de>

http://bugs.koha-community.org/show_bug.cgi?id=14383
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>

Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2015-06-22 17:34:45 -03:00
Amit Gupta
a810b1cf59 Bug 13993: (3) Transfer order leaves incorrect orderstatus
11) Apply patch (3)
12) Log in to staff client
13) Acquisitions
14) Create a basket for two different vendors
15) Place an order in one vendor's basket.
16) Transfer the order to the other vendor's basket.
17) prove -v t/db_dependent/Acquisition/TransferOrder.t
    -- This should succeed without intervention.
18) Run koha qa test tools for the last 3 commits.

Signed-off-by: Indranil Das Gupta <indradg@gmail.com>

Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com>

Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
2015-06-19 11:45:11 -03:00
Jonathan Druart
88537974e3 Bug 12743: ACQ: default values for catalogue records
At the moment, it is possible to create records in acquisitions, but the
ACQ framework is only used for items created in this module.

This patch allows to defined default values in the ACQ framework for
records created on the acquisition module.

Test plan:
1/ Make sure you have the ACQ framework created (otherwise create it
from the default framework).
2/ Define a default value for a field (for instance 099$z=1).
3/ Go in the acquisition module and create a new order from a new
record.
4/ Fill mandatory information and save.
5/ Go on the detail page of this record and verify the default value
exist.

Signed-off-by: Gaetan Boisson <gaetan.boisson@biblibre.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-05-11 10:10:41 -03:00
Jonathan Druart
a6c9bd0eb5 Bug 9978: Replace license header with the correct license (GPLv3+)
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>

http://bugs.koha-community.org/show_bug.cgi?id=9987

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-04-20 09:59:38 -03:00
Jonathan Druart
1d78670f0c Bug 13244: (follow-up) fix mixup to and from in the sql query
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-04-13 11:08:47 -03:00
Jonathan Druart
9fb422bb9f Bug 13244: Merge GetOrders and GetCancelledOrders
These two subroutines did the same job (same select, same join, etc.)

Test plan:
Go on the basket list page and verify you see the pending and the
cancelled baskets.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Two small things are adjusted in separate follow-ups.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-04-13 11:08:40 -03:00
Jonathan Druart
a111ffb92e Bug 12648: (QA followup) Rename aqorderusers to aqorder_users
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Thanks Jonathan
2015-03-11 11:48:28 -03:00
Jonathan Druart
519c273643 Bug 12648: Link patrons to an order
This patch is the main patch.

This feature adds the ability to link patrons to an order.
On that way, they will be notified when the order is completely
received.

Test plan:
1/ Execute the updatedb entry and verify you have a new notification template in your table (tools/letter.pl).
code: ACQ_NOTIF_ON_RECEIV, module: acquisition
2/ You can edit it if you want
3/ Create a basket and create an order with 1 or more items
4/ Link 1+ patrons to this order
5/ Close the basket and receive the order
6/ When you have received all items for this order, all patrons attached
will be notified. Check the message_queue table to check if the letters
have correctly been added to the queue.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-03-11 11:47:30 -03:00
Jonathan Druart
aed056a636 Bug 12976: Fix some comment in tests
Previous comments were wrong.
Actually the main part of price values is correct.
Only some rounding and tax values are badly calculated.

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-02-19 09:46:44 -03:00
Jonathan Druart
4318eeef5f Bug 12976: Use the centralize VAT and prices calculation - invoice.pl
Bug 12969 introduces a subroutine to centralize VAT and prices
calculation.
It should be use in the acqui/invoice.pl script.

Test plan:
0/ Don't apply the patch
1/ Create 4 suppliers with the different configurations
2/ Create a basket and create several orders
3/ Receive the items and create an invoice
4/ Go on the invoice page acqui/invoice.pl?invoiceid=XXX
5/ Verify you don't see any difference before and after applying the
patch on the invoice details table.
Note: The only different you should see is the price formating for
"Total tax exc.". Before this patch "432.10" was displayed "432.1".

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-02-19 09:46:26 -03:00
Jonathan Druart
2df541712f Bug 13675: Do not set aqorders.budget_id to NULL
C4::Acquisition::ModReceiveOrder updates the aqorders with
budget_id=NULL if no budget_id given in parameter.
Actually the same budget_id should be used.
In tests (especially t/db_dependent/Acquisition/TransferOrder.t),
ModReceiveOrder is not called with a budget_id param and set to NULL the
budget_id value.

test plan:
  prove t/db_dependent/Acquisition/TransferOrder.t
should return green

Note that this bug should not appear using the interface.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The fix makes sense, and running
 $ prove t/db_dependent/Acq*
returns all green. koha-qa.pl also likes it.

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-02-10 08:45:44 -03:00
d8710b4feb Bug 12944: (QA followup) fix POD errors from koha-qa.pl
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-02-09 15:48:18 -03:00
Jonathan Druart
ff7c87d345 Bug 12944: Search orders by basket creator
This patch adds the ability to search orders using the basket creator.

Test plan:
- go on the order advanced search form (acqui/histsearch.pl)
- use the autocomplete input to search patrons
- launch the search and verify the results are consistent with the
  values you have filled.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-02-09 15:48:12 -03:00
Jonathan Druart
74640683f0 Bug 13333: Fix Display basket group for already received orders
Bug 11111 adds a basket group column on the parcel page.
But it seems that the already received orders never contain the value
(always 'no basket group').

Test plan:
Receive an order which is in a basket group and verify the basket group
column is correctly filled.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-02-05 14:51:34 -03:00
Jonathan Druart
b454e1a894 Bug 13318: Delete C4::Acq::GetParcel
Test plan:
  git grep GetParcel
should not return use of this subroutine.

Signed-off-by: wajasu <matted@34813.mypacks.net>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-01-10 16:14:23 -03:00
Jonathan Druart
a19958ee2c Bug 12969: Add a subroutine to calculate VAT and prices
This patch adds a new subroutine populate_order_with_prices in the
C4::Acquisition module.

Its goal is to refactore the VAT and prices calculation into Koha.
All scripts will use this subroutine.

Test plan:
Verify that the prices in t/Prices.t are consistent with the values
listed in the file "Prices and VAT calculation - before" submit on bug
12964.
Verify that
  prove t/Prices.t
returns green

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-01-04 12:45:18 -03:00
Jonathan Druart
469f36d38f Bug 12896: Move the bookseller-related code into Koha::Acquisition::Bookseller
The C4::Acquisition module should be exploded in order to add
readability and maintainability to this part of the code.

This patch is a POC, it introduces a new Koha::Acquisition::Bookseller module and put in
it the code from GetBookSeller and GetBookSellerFromId.

Test plan:
1/ Create a bookseller, modify it.
2/ Add contacts for this bookseller
3/ Create an order, receive it, transfer it
4/ Launch the prove command on all unit tests modified by this patch and
verify that all pass.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-12-31 14:15:58 -03:00
Jonathan Druart
bf681e28ba Bug 12059: Prefer to list fields in the query
To avoir further issue, it's better to explicitely list the fields we
want to retrieve.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-12-17 20:17:16 -03:00
Katrin Fischer
d9c99b6f5e Bug 12059: Publisher column on invoice page always empty
This patch moves the publisher information out of its own
always empty column into the Summary column below the title,
as it is on other acq pages.

The information was never displaying, as publishercode is in
biblioitems and that table was not selected by GetInvoiceDetails.

Also modified the code to take into account that UNIMARC uses
biblioitems.publicationyear and MARC21/NORMARC use bibio.copyrightdate
for the copyright year.

To test:
- create an invoice for records that
  - have a publication year
  - have no publication year
  - have a publisher...
- 'finish receiving' and check the invoice summary page
   ...acqui/invoice.pl?invoiceid=?
- Make sure all the information displays now but didn't witout the patch.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-12-17 20:17:10 -03:00
Jonathan Druart
46e3f8169c Bug 12980: GetHistory does useless processing
GetHistory iterated on the orders to calculate the quantity and price.
These values are never used by the called.
It can be removed.

Test plan:
Verify there is no regression on acqui/histsearch.pl and
catalogue/detail.pl
Actually you just have to check that the total quantity and price are
not displayed on these views.

QA: note that 'count' and 'toggle' are never used in the template.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-12-03 11:42:48 -03:00
Julian Maurice
d3b2c85df8 Bug 7162; Factorize code for order cancellation (QA fixes)
* Remove tab characters in acqui/addorder.pl
* Remove FIXME in acqui/cancelorder.pl
* Fix typos: "canceled" -> "cancelled", "occured" -> "occurred"
* Replace "Click here" link by "OK"
* Add a column to aqorders to store cancellation reason instead of
  having it in aqorders.notes, to avoid having untranslatable strings in
    database

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-10-30 00:44:11 -03:00
Julian Maurice
c4aaca9496 Bug 7162: Factorize code for order cancellation
Some code was duplicated, all is now in cancelorder.pl
Added possibility to provide a reason for cancellation (or other things,
this is saved in aqorders.notes)

Signed-off-by: Corinne Bulac <corinne.hayet@bulac.fr>
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-10-30 00:44:04 -03:00
Jonathan Druart
3d61550e22 Bug 12830: Move the order-related code into Koha::Acquisition::Order
The C4::Acquisition module should be exploded in order to add
readability and maintainability to this part of the code.

This patch is a POC, it introduces a new Koha::Acquisition::Order module and put in
it the code from NewOrder and NewOrderItem.

Test plan:
1/ Create an order, modify it, receive it, cancel the receipt.
2/ Launch the prove command on all unit tests modified by this patch and
verify that all pass.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-10-28 11:10:36 -03:00
Jonathan Druart
5af96e0f78 Bug 12827: NewOrder needs more unit tests
NewOrder should be more tested!

This patch moves the existing unit tests into a new file and adds some
unit tests.

Note that there is no DB field aqorders.subscription, so the test in
NewOrder can be removed.

Test plan:
  prove t/db_dependent/Acquisition/NewOrder.t
and
  prove t/db_dependent/Acquisition.t
should return green.

Signed-off-by: Zeno Tajoli <z.tajoli@cineca.it>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-09-17 21:22:56 -03:00
Jonathan Druart
2217f98b7c Bug 12827: NewOrder should not return basketno
Since the basketno parameter is needed to insert an order, it is useless
to return it.

This patch changes the prototype for the C4::Acquisition::NewOrder
subroutine. The return value is now a scalar containing the ordernumber
created.

Test plan:
Verify there is no regression on an acquisition workflow:
1/ Create an order with several items
2/ Modify the order
3/ Receive some items
4/ Cancel the receipt
4/ Receive some items
5/ Receive all remaining items
6/ Cancel the receipt

Signed-off-by: Zeno Tajoli <z.tajoli@cineca.it>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-09-17 21:22:26 -03:00
Jonathan Druart
55e5c82ab5 Bug 12891: NewOrder does not return ordernumber if ordernumber is defined
The behavior is quite weird, but
  $schema->resultset('Table')->create($data)->id
does not return the id inserted if $data contains the key.

To be more clear, in this case
  $schema->resultset('Aqorder')->create($new_order)->id
returns an empty string because $new_order->{ordernumber} is an empty
string!

This was not caught by the unit tests, I added one.

Test plan:
- AcqCreateItem set to ordering
- Create an order with items and verify items are correctly linked to the
  order.

Signed-off-by: Dobrica Pavlinusic <dpavlin@rot13.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Confirmed that without the patch the created item is not linked to the
order (entry in aqorders_items). With the patch, it works as expected.
Passes tests and Koha QA script.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-09-17 21:19:35 -03:00
Jonathan Druart
a2786c6de7 Bug 12557: Partially received - the change should affect the new order
If the receipt in not on the whole order but only on a part of it, the
change should be done on the itemnumber linked to the "new order", the
one we are reverting.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-09-09 10:10:22 -03:00
Jonathan Druart
55ca3c5581 Bug 12557: Add a way to revert the changes made on items on receving
Bug 8307 introduces the AcqItemSetSubfieldsWhenReceived pref.
You can now update an item field on receiving (if you create items on
ordering).
But if the receipt is cancel, there is no way to revert these changes.

This patch adds a new pref AcqItemSetSubfieldsWhenReceiptIsCancelled to
allow to revert changes previously done on receiving

Test plan:
0/ Set the AcqCreateItems to 'ordering'
1/ Fill AcqItemSetSubfieldsWhenReceived with o=1 (UNIMARC) or 7=1
(MARC21).
2/ Fill AcqItemSetSubfieldsWhenReceiptIsCancelled with o=2 (UNIMARC) or
7=2 (MARC21)
3/ Create an order with some items
4/ Receive the order and verify the notforloan value is set to 1
5/ Cancel the receipt and verify the notforloan value is set to 2

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-09-09 10:10:07 -03:00
Yohann Dufour
05b261595c Bug 12626: SQLHelper replacement - C4::Acquisition
With this patch, the subroutine NewOrder uses DBIx::Class instead of C4::SQLHelper.

Test plan:
1) Apply the patch

2) Execute the unit tests by launching :
prove t/db_dependent/Acquisition.t

3) The result has to be a success without error or warning :
t/db_dependent/Acquisition.t .. ok
All tests successful.
Files=1, Tests=79,  2 wallclock secs ( 0.04 usr  0.01 sys +  1.80 cusr  0.09 csys =  1.94 CPU)
Result: PASS

4) Log in the koha intranet and create a new order in the acquition module

5) The creation has to be a success

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>

Test pass, new order created without problem, no koha-qa errors

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested creating a new order from a subscription, no problems found.
Passes tests and QA script.
2014-08-26 15:44:32 -03:00
Yohann Dufour
3ed1d0bf7e Bug 12493 : moving the subroutines GetContract and GetContracts from C4::Acquisition.pm to C4::Contract.pm
Fix in order to respect the coding guidelines

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-07-30 10:40:20 -03:00
Yohann Dufour
0247b6741e Bug 12493: moving the subroutines GetContract and GetContracts from C4::Acquisition.pm to C4::Contract.pm
This patch includes:
- the subroutines GetContract and GetContracts has been moved from C4::Acquisition.pm to C4::Contract.pm and adapted for a general use
- adaptation of acqui/basket.pl, acqui/basketheader.pl, acqui/neworderempty.pl, acqui/supplier.pl and admin/aqcontract.pl
- the unit tests for the module C4::Contract.pm

Test plan:
1) Apply the patch
2) Execute the unit tests by launching:
prove t/db_dependent/Contract.t t/Acquisition/ t/db_dependent/Acquisition/ t/db_dependent/Acquisition.t
3) The command has to be a success :
t/db_dependent/Contract.t ................................. ok
t/Acquisition/CanUserManageBasket.t ....................... ok
t/Acquisition/Invoice.t ................................... ok
t/db_dependent/Acquisition/GetBasketsInfosByBookseller.t .. ok
t/db_dependent/Acquisition/GetOrdersByBiblionumber.t ...... ok
t/db_dependent/Acquisition/Invoices.t ..................... ok
t/db_dependent/Acquisition/OrderFromSubscription.t ........ ok
t/db_dependent/Acquisition/TransferOrder.t ................ 1/11 # Transfering order to basket2
t/db_dependent/Acquisition/TransferOrder.t ................ ok
t/db_dependent/Acquisition/close_reopen_basket.t .......... ok
t/db_dependent/Acquisition.t .............................. ok
All tests successful.
Files=10, Tests=284, 15 wallclock secs ( 0.11 usr  0.02 sys + 12.88 cusr  0.77 csys = 13.78 CPU)
Result: PASS

4) Log on with a superlibrarian permission
5) Go on the page acqui/supplier.pl (Acquisitions > Button "New vendor")
6) Record a vendor with a nonzero "name"
7) Go on the page admin/aqcontract.pl (click on the "Contracts" item in the menu)
8) Click on the button "New" > "Contract" and record a new one
9) Verify the displayed data are correct about the contract
10) "Edit" the contract with different values and verify the data are updated
11) Click on "Delete" in order to delete the contract, verify the displayed data are correct but cancel the operation
12) Click on "New" > "Basket" and verify there is the created contract in field "Contract", then record a basket by selectioning the created contract
13) Verify the contract name displayed is correct
14) Record an active budget and a fund linked to this budget
15) Go on the new basket (Home > Acquisitions > Search the created vendor)
16) Click on "Add to basket" then "From a new (empty) record" and verify the displayed contract name is correct

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Tested with both patches applied.
Works as described following test plan, all points (I did 14 first)
All test pass
No koha-qa errors

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-07-30 10:40:06 -03:00
Jonathan Druart
ba81cdcdb2 Bug 12583: DelItem prototype - prefer hashref
To delete an item, only the itemnumber should be mandatory. The DelItem
routine can retrieve the biblionumber from the itemnumber.

Test plan:
Verify that t/db_dependent/Items/DelItem.t passes

Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-07-25 19:06:12 -03:00
Jonathan Druart
7c809faba9 Bug 12583: DelItem prototype - Remove $dbh
Since C4::Context->dbh shares the DB handler, it's useless to pass it to
routines.

Test plan:
Try to remove an item from the Koha interface.
Verify that unit tests pass.

Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-07-25 19:06:03 -03:00
Jonathan Druart
110c665a4b Bug 12164: Close a budget period (budget)
This is the main patch.

On closing a budget period, all unreceived orders are moved from the
old/previous fiscal year into the new fiscal year.

You can rollover funds unused in the previous fiscal year to the new
fiscal year.

This patch set is based on bug 12168 (bugfix) and can be tested on top
of bug 11578 (easier to see the fund structure).

The patch set is cut in 6 main patches:

- Move the budget period clone logic into C4::Budgets
  The code is moved from the pl to Budgets.pm and unit tests are provided.
  The original code should certainly be buggy since a typo existed.
- On cloning budget period, mark original budget as inactive
  Cloning a budget period is already possible in Koha, this patch adds a
  checkbox to mark as inactive the original budget. That avoids to edit
  the budget and click the "inactive" checkbox. Both do the same action.
- On cloning budget periods, add a "reset all funds" option
  Same as before, a new checkbox is added on cloning a budget period. If
  you check it, all fund amounts will be set to 0. Otherwise, no change
  compared to the existing behavior.
- Close a budget period (budget)
  The goal of this patch set is to move unreceived orders from a budget to
  another. This patch adds a C4::Budgets::MoveOrders routine which does
  this job.
  This action is only possible if the fund structure is the same for both
  budgets, the budget_code field should be the same.
- On closing budget period, move unspent amount
  Unspent amount will be move from the previous budget structure to the
  new one.
- Add UI report
  This patch only adds a report when closing a budget is done.

Test plan:
Wording: below, budget is a "budget period" and fund is a "budget".
Prerequisite: Having 1 active budget with some funds (with different
levels and different amounts). Order and receive some orders (not all).
1/ Go on the budgets administration page (admin/aqbudgetperiods.pl) and
duplicate the structure of this budget ("Duplicate" link in the
"Actions" column).
2/ Enter start and end date for this budget and mark the original budget
as inactive.
3/ Note that a new budget is created, with the same fund structures (and
same value) and that the old one is marked as inactive (see
admin/aqbudgets.pl page with patches from bug 11578).
4/ Try to close the new budget: it is not possible, there is no
unreceived orders for this budget.
5/ You can close the inactive budget ("Close" link in the "Actions"
column).
6/ Verify the number of "Unreceived orders" is correct and select the
new budget in the budget list. Click on the "Move remaining unspent
funds" if you want to move unspent amounts.
7/ A report view is displayed and show you the ordernumber which have
been impacted (grouped by fund).
8/ Try different configuration, depending on the selected checkboxes.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-07-24 14:17:15 -03:00
afd2418d73 Bug 11349: Change .tmpl -> .tt in scripts using templates
Since we switched to Template Toolkit we don't need to stick with the
sufix we used for HTML::Template::Pro.

This patch changes the occurences of '.tmpl' in favour of '.tt'.

To test:
- Apply the patch
- Install koha, and verify that every page can be accesed

Regards
To+

P.S. a followup will remove the glue code.

Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-07-17 11:05:49 -03:00
9fe36e0c70 Bug 12438 - Bad encoding in acquisition basket
We noticed a bad encoding (diacritics replaced by <?>) in acquisition basket when updating a server to Debian Wheezy.
We found it comes from a query containing biblio.title twice.
Maybe the mysql newer version creates this side-effect.

Test plan :
- Create an order on a record containing a diacritic in title
- Look at the basket : cgi-bin/koha/acqui/basket.pl?basketno=x
=> Without the patch the record title is bad encoded (with <?>)
=> With this patch the record title is well encoded
- Check also basket CSV export

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Good catch!
Works as expected, passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Duplicated biblio.title is a (minor) bug, and should be removed.

The side-effect of it solving an encoding problem might be seen
as problematic: it hides a real problem.
The efforts on 11944 actually solve this encoding problem (11944
merged into master actually fixes this), so I'm pushing it, for
a short term solution for stable, with the hope that we will soon
have 11944 pushed.
BTW, non-diacritic but non-ASCII characters are not broken either.
2014-07-15 18:55:11 -03:00
Jonathan Druart
6803dc6bf5 Bug 11744: Cancel a receipt does not delete items created on receiving
If items is created on receiving, cancel a receipt should delete them.
The code only manage the case if the order is a child of another order
(partial).

To reproduce:
1/ Set AcqCreateItem to receiving
2/ Order one or more item(s)
3/ Receive the order and verify the item is created
4/ Cancel the receipt
5/ The item is not deleted

Test plan:
1/ Apply this patch and do again previous steps. The item should not be
deleted at step 5.
2/ Set AcqCreateItem to ordering and verify the item is not deleted.

Signed-off-by: marjorie barry-vila <marjorie.barry-vila@ccsr.qc.ca>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-07-14 11:17:34 -03:00
Jonathan Druart
e330b4672d Bug 11169: Display acquisition details in the OPAC
This patch adds a new system preference 'OPACAcquisitionDetail'.
If it is enabled, information about items on order will be displayed on
the OPAC detail page.

Test plan:
- switch on the OPACAcquisitionDetails pref.
- set the AcqCreateItems pref to 'receiving'.
- create some orders on 1 or more items.
- go to the opac detail page and verify the "Holdings" tab contains the
  line "X item are on order." (at the bottom of the table containing the
  item list).
- receive the items.
- verify the number of items has decreased.
- set the AcqCreateItems pref to 'ordering'.
- create some orders on 1 or more items.
- go to the opac detail page and verify the item list contains the items
  with the "on order" status.
- receive the items.
- verify the received items no longer have the the "on order" status.

To test completely this feature, you should verify there is no
regression on the pref OpacMaxItemsToDisplay, OpacSeparateHoldings and
OpacSeparateHoldingsBranch.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>

Also removed some blank lines from the original patch and bumped up
the DBRev.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-06-15 11:12:24 -03:00
Mathieu Saby
2dab2cc223 Bug 12110: Display the order vendor note in basket and basketgroup CSV and PDF
This bug adds the "vendor note" for each order in the PDF for
basketgroups.  The note is displayed only if it exists, just under the
bibliographic information.

I added a separation line "--------" between bibliographic information
and the note, so that it could be visible at 1st glance.

It also replaces the internal note with the vendor in the CSV for basket
and basketgroup.  It is more logical and useful for libraries to export
the note made for vendor, as those files are destined to be sent to the
vendor.

Test plan :
- fill a basket with some orders, some with internal notes, some with
  vendor notes
- export the basket in CSV : only the vendor notes should be present
- put the basket in a basketgroup
- export the basketgroup in CSV : only the vendor notes should be
  present
- Select "English-2 pages" template for basketgroups in Sysprefs
- export the basket in PDF : the vendor notes should be present under
  the bibliographic information
- Select "English-3 pages" template for basketgroups in Sysprefs
- export the basket in PDF : the vendor notes should be present under
  the bibliographic information

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-05-25 15:21:22 +00:00
7fba4e3ef8 Bug 12089: Remove use of dt_add_type_uk_date() - Acquisitions
This patch removes instances of dt_add_type_uk_date() from acquisitions
templates and updates sorting configurations according to current
guidelines.

In cases where a formatted date was passed from a Perl script, the
script has been modified to pass an unformatted date.

Several instances of the no longer valid align attribute have been
removed from <td> tags in favor of an existing "data" class which is
suitable for display of currency values.

To test, view the following pages in Acquisitions. Columns containing
dates should sort correctly regardless of dateformat system preference
setting. Columns containing bibliographic titles should ignore articles
when sorting.

- Add to an order from a staged file: The table of staged files should
  sort correctly. After clicking "add orders" for one of the staged
  files, the table of titles in that staged file should also be sorted
  correctly.

- Add to an order from a subscription. The table of subscription search
  results should sort correctly.

- Orders search results should sort correctly.

- Late orders should sort correctly.

- Search for a vendor. Click on the vendor name to view the vendor
  detail page. The table of contracts on this page should sort
  correctly.

- From the Acquisitions home page click a number in the "spent" column
  of the table of available funds. The table of orders should sort
  correctly.

- From the Acquisitions home page click a number in the "ordered" column
  of the table of available funds. The table of orders should sort
  correctly.

- From a vendor detail page, click the "Receive shipments" button. On
  the receive shipments page the table of shipments should be sorted
  correctly.

Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-04-28 18:41:28 +00:00
Galen Charlton
afa6a33449 Bug 7288: (follow-up) various fixes
- Fix syntax error in supplied test
- remove subscriptionid as a field returned by GetInvoices(), as
  the is_linked_to_subscriptions Boolean takes its place.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-04-21 05:07:37 +00:00
Jonathan Druart
c2461cf171 Bug 7288: (follow-up) set a boolean if the invoice if linked to subscriptions
If an invoice is linked to subscription, we need to set a boolean to
true in order to filter them in the interface.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-04-21 05:02:48 +00:00
Jonathan Druart
56c7332067 Bug 7288: add filter on subscriptions in the invoices table
This patch adds a checkbox "Show only subscriptions" in the invoices
table.

If this checkbox is checked, only invoices that contain at least one
order linked to a subscription are displayed.

To test:
- Test in a database with multiple existing invoices
- Create an order from a subscription, close basket, receive
- Test that the result table of the invoice search shows
  the new checkbox and that it works correctly

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-04-21 05:00:47 +00:00
Mathieu Saby
4d80cc0ec7 Bug 11027: Add a column for basketgroups in late orders table and improve other columns
This patch makes 4 changes in late orders page :
- adding a new column for basketgroup, displaying
  the name and number of the basketgroup
- displaying the name of the basket as well as its
  number, with a hyperlink to this basket
- displaying fund in a separate column to make
  sorting easier, and renaming it from "budget" to
  "fund" (the confusion can be found elsewhere in Koha...)
- displaying branch in a separate column to make
  sorting easier (this column could be improved later,
  by getting branch from basketgroup if there is one)

For that, in Aquisition.pm, I made some changes to GetLateOrders:
- 3 new columns in SELECT
- 1 new join

To test :
1. Display the list of late orders of your instance.
2. Check you have 3 new columns for basketgroups, fund and branch
3. In basketgroup column you should have "name of basket group (number)"
4. In basket column you should have "name of basket (number)"
5. Check the links for basketgroups. They should send you to the
   page displaying information for each basketgroup
   (without possibiliy of editing them if they are closed)

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Patches pass QA script and all tests.
Works as described. Also checked sorting and orders which
are not in a basketgroup display correctly.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-04-21 04:33:00 +00:00
Julian Maurice
65748d05b5 Bug 11551: Allow to search on parent ordernumber in histsearch.pl
It is now possible to search on the order number on the order search
page.

Also searching on parent_ordernumber is possible, allowing one to
search to search children for a given order number.

Test plan:
1/ create a basket and 1 order with at least 2 items.
2/ receive partialy the order (receive only 1 item).
3/ note that a new ordernumber is created for item not received.
4/ go on the order search form and search for the original ordernumber
without checking the new checkbox "Display children too." => only 1
order (the parent) is displayed.
5/ now check the checkbox and search again => the parent order is
displayed but children too.

Signed-off-by: remy juliette <juliette.levast@iepg.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works nicely, passes all tests and QA script.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-04-21 04:23:09 +00:00
Galen Charlton
123f07cc8a Bug 11552: (follow-up) fix a typo in a comment
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-04-21 03:50:37 +00:00
Jonathan Druart
6eb69ed3ec Bug 11552: allow searching on original order number after a transfer
If an order is transferred from one basket to another, it should be
possible to retrieve it with the original order number (AKA order
line).  This patch makes it so.

Test plan:
- transfer an order
- note the original order number and the new one
- receive the order and, on the parcel page, try to find your order with
  the original order number and the new one.

Signed-off-by: sonia bouis <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>

RM note: this works only for the most recent transfer, so if an order
gets transferred multiple times, earlier order numbers won't retrieve
it.
2014-04-21 03:48:31 +00:00
Jonathan Druart
7ca9168385 Bug 11243: update vendor list to also display canceled bib counts
Same as previous patch but for the biblios count.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-04-20 15:18:51 +00:00
Jonathan Druart
b62a793580 Bug 11243: make vendor list distinguish between active and canceled items
On the vendor result list, the "Item count" columns contain the sum of
all items ordered for a basket. But if an order is canceled, the item
count is not really meaningful.

This patch just adds, in parenthesis, the number of items canceled.

Test plan:
- create a basket and 3 orders with different number of items
- cancel 1 order
- verify on the supplier list that the number of items is correct and
  the number of canceled items is correct too.

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.

Note: In case the biblio was deleted when the order was cancelled,
the number of biblios will be off.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-04-20 15:17:31 +00:00
Galen Charlton
58b5b384f6 Bug 9416: (follow-up) reconcile with work done on bug 11699
This patch teaches the ordering receiving process how to
set vendor and internal order notes.

One observation: I'm not sure it's entirely useful to set
a note to communicate to the vendor during receiving --
how is it to be sent to them, and why?

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-04-19 15:55:38 +00:00