- Koha-devel - lists.koha-community.org

Koha 17.05 Release Notes - Draft 2 + Beta
by Kyle Hall 19 May '17

19 May '17

Hey all, Here is the second version of the Release Notes and the beta! The release notes have the same issues as before. I'll fix the character encodings by hand in the final release. https://github.com/kylemhall/Koha/blob/v17.05.00_RC1/misc/release_notes/rel… I've included the tarball in the repo rather than muck up the ftp server with it: https://github.com/kylemhall/Koha/tree/v17.05.00_RC1/releases Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org )

1 0

Re: [Koha-devel] [ByWater Partners] Acquisitions change in Koha 16.11 and forward
by Nick Clemens 19 May '17

19 May '17

Hi Sandre, The current replacement/rrp field is used for two things: 1 - passing through from the orders as the items.replacementprice field 2 - the basis for calculating prices (minus discount, plus tax, etc) Splitting the replacement cost out will allow proper discount/tax calculation while allowing manual edit to the replacement cost to add fees etc. I believe our proposal works for your workflow. -Nick On Tue, May 16, 2017 at 5:40 PM Sandre Cunha <cunha(a)monterey.org> wrote: > Before you add yet another price field to acquisitions, I would like to > understand the intended function of the "replacement/rrp" field. > > I realize that not all libraries operate the same and that they have a > variety of needs and restraints. For Monterey Public Library, the only > reason to even have replacement cost in the order screen is to streamline > processing when the item gets to cataloging, i.e., so they don't have to > enter it. > For us, the replacement cost is the price we charge the customer if they > lose or damage the item. Is this the intended purpose of this field? > > Our replacement cost used to be the list price plus $10 for processing, > but never included tax. > > Example 1: > Retail price: $27.99 Actual cost: $15.34 Sales tax:$1.34 In this > scenario, the replacement price = $37.99 [27.99 + $10.00 processing] > > Now, we use our actual cost [the price discounted from retail]; the only > time it is different is when the cost is less than our maximum fine, in > which case the maximum fine fee becomes the replacement price. > > Example 2: > Retail price: $27.99 Actual cost: $15.34 Sales tax: $1.34 > Replacement price = $15.34 > > Example 3: > > Retail price: $18.00 Actual cost: $9.86 Sales tax: $0.83 Replacement > price: $10.00 [our maximum late fine for this collection is $10.00, which > is more than 9.86] > > Other drawbacks to the new way "replacement/rrp" is handled: when you need > to create an order for which the cost is $0 (gift, credit allocation, or > pre-order for next fiscal year) but you want to have a replacement cost > recorded. > > Additionally, please note that we do not enter discounts in our vendor > records, as even with our largest two vendors the discount varies depending > on the type of material and source. With one vendor our contract specifies > a 42% discount for many items, but for some we get less, some no discount, > and every once in a while we pay more than retail due to a surcharge. > > I would be interested to know the methods acquisitions staff at other > libraries use. It would be useful to have a better understanding of usage > and needs before adding yet another field to the order details. > > ________________________ > Sandre Cunha > Technical Services Supervisor > Monterey Public Library > 625 Pacific Street > Monterey, CA 93940 > Tel. 831-646-3740 <(831)%20646-3740> > > “If you want to build a ship, don’t drum up your men to collect wood and > give orders and distribute the work. Instead, teach them to yearn for the > vast and endless sea." -- Antoine de Saint-Exupéry > > On Tue, May 9, 2017 at 1:44 PM, Nick Clemens <nick(a)bywatersolutions.com> > wrote: > >> Hello All, >> >> With the current versions of Koha there have been some changes in >> acquisitions and how prices are calculated and there seems to be some >> confusion in terms and how things are currently being used. >> >> We wanted to clarify what is happening, propose a change and get feedback >> on what needs to happen. >> >> When placing an order there are several price fields: >> Vendor price (listprice in db) >> -This is used to populate the Replacement cost and budgeted cost on the >> order page. It is not used against the budget >> >> Replacement cost (rrp in db) >> -This is used to calculate the 'budgeted cost/ecost' in the budget - it >> also populates the replacement price in the item created by the aqc process >> once received >> >> Budgeted cost (ecost in db) >> -This is the replacement/rpp minus any discount on the order - this is >> the value that will be encumbered when the order is placed >> >> Actual cost (unitprice) >> -This is the eventual 'price' of the item and is the encumbered amount >> once the item has been received. >> >> With the changes that were made one can no longer adjust the >> 'Replacement/RRP' once an order is placed - this is because this value is >> adjusted for tax in the db (rrp_tax_excluded, rrp_tax_included) and used >> for calculating the ecost tax adjusted (ecost_tax_excluded, >> ecost_tax_included) >> >> Some libraries have been having issues as they use 'Replacement' cost >> mostly for populating items and are not used to it being unable to be >> edited and/or affecting budgets. >> >> We are proposing to rename the current 'Replacement cost' field to match >> the db value - 'Recommended retail price' (RRP) and add a new 'Replacement >> cost' field, editable at any point, that is only used for populating the >> item field. >> >> We think this will clear up how the other values are being used and >> restore functionality that changed. >> >> Please let us know if this works or what other suggestions you have here. >> >> Thank you, >> Nick, Kyle, Jonathan >> >> _______________________________________________ >> Partners mailing list >> Partners(a)lists.bywatersolutions.com >> http://lists.bywatersolutions.com/mailman/listinfo/partners >> >>

1 0

Koha 17.05 Release Notes - Draft One ( 2nd attempt ; )
by Kyle Hall 18 May '17

18 May '17

I think my first attempt may be caught in mailing list moderation, so here is a link to the markdown version available on GitHub: https://github.com/kylemhall/Koha/blob/bc497cd58a874c4c10f214e7c2a8d5b35aa4… Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org )

5 6

Koha 17.05 Dates
by Kyle Hall 17 May '17

17 May '17

Here is my planned timeline for the Koha 17.05 release: May 5 - Feature Slush May 12 - 1st Draft of Release Notes May 19 - Feature Freeze, Release Beta, 2nd Draft of Release Notes May 26th - Final Release If anyone sees a need to modify this timeline, please let me know! Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org )

4 6

Call for News: May 2017 Newsletter
by kohanews 15 May '17

15 May '17

I'm collecting news for the May newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- ** For events **: - Please include dates for past events. If I can't find dates I may not add it. - Announcements for future events with dates T.B.A. are fine ...Eg., Kohacon - For past events , **** one month back is the cut-off ****. * News items can be of any length. * Images are fine * Anything and everything Koha. * Submit by the 26th of the month. If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section. -- Chad Roseburg Editor, Koha Community Newsletter -- Chad Roseburg Editor, Koha Community Newsletter

1 0

INSTALL KOHA 16 with database Postgresql9.4
by Wilfredo Felix Quispe Infantes 15 May '17

15 May '17

Hello, Some experience with Koha and postgresql, some steps for this to work correctly? Thank You

3 2

Packaging RDF::Trine (Hector Castro)
by Hector Castro 12 May '17

12 May '17

Hi David I remember that the issue found in RDF::Trine at that moment was the dependencies used by module especially because use Moose. The policy was not to use Moose about some problems with Koha. I don't know if this policy has been change since the introduction of Plack. Regards. > Message: 2 > Date: Thu, 11 May 2017 16:08:06 +1000 > From: "David Cook" <dcook(a)prosentient.com.au> > To: <koha-devel(a)lists.koha-community.org> > Subject: [Koha-devel] Packaging RDF::Trine > Message-ID: <025c01d2ca1c$f4da7be0$de8f73a0$(a)prosentient.com.au> > Content-Type: text/plain; charset="us-ascii" > > Hi all, > > > > Magnus and I have been working on a RDF project for Stockholm University > Library, and I've been using RDF::Trine for our prototype. It works great > overall, although I found a bug with RDF::Trine::Store::SPARQL version > 1.016 > (most current version on CPAN*). I sent in a pull request yesterday > (https://github.com/kasei/perlrdf/pull/147) and the author of the module > said that he's hoping to review it and merge it into master in the next few > days. But what this means is that we'll be wanting to use the latest > version > of RDF::Trine, and that's going to be much newer than what is in the Debian > repositories for Jessie and Wheezy. I've taken a peek at the code in those > repos, and it's buggy too. > > > > I seem to recall on > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13642 that there > were some issues packaging RDF libraries, but I think it may have mostly > related to RDF::Helper, of which we have no need. But Mirko if I could get > your input, that would be great. > > > > *Actually it seems the latest version in CPAN is newer than master in > Github. I'll have to talk to the maintainer about that too. > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Direct: 02 8005 0595 > > > >

2 1

Packaging RDF::Trine
by David Cook 12 May '17

12 May '17

Hi all, Magnus and I have been working on a RDF project for Stockholm University Library, and I've been using RDF::Trine for our prototype. It works great overall, although I found a bug with RDF::Trine::Store::SPARQL version 1.016 (most current version on CPAN*). I sent in a pull request yesterday (https://github.com/kasei/perlrdf/pull/147) and the author of the module said that he's hoping to review it and merge it into master in the next few days. But what this means is that we'll be wanting to use the latest version of RDF::Trine, and that's going to be much newer than what is in the Debian repositories for Jessie and Wheezy. I've taken a peek at the code in those repos, and it's buggy too. I seem to recall on https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13642 that there were some issues packaging RDF libraries, but I think it may have mostly related to RDF::Helper, of which we have no need. But Mirko if I could get your input, that would be great. *Actually it seems the latest version in CPAN is newer than master in Github. I'll have to talk to the maintainer about that too. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

2 3

Authenticate to use Webservices/ Koha API
by Paul Poulain 11 May '17

11 May '17

Hi all, Matthias is working on connecting Koha and Coral, and he's facing some problems with authentication. We need to authenticate and use a session cookie, that's not easy. Could we find another solution ? Should we revive bz 13920 ? (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13920) Suggestions/ideas welcomed ! -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

3 2

Acquisitions change in Koha 16.11 and forward
by Nick Clemens 10 May '17

10 May '17

Hello All, With the current versions of Koha there have been some changes in acquisitions and how prices are calculated and there seems to be some confusion in terms and how things are currently being used. We wanted to clarify what is happening, propose a change and get feedback on what needs to happen. When placing an order there are several price fields: Vendor price (listprice in db) -This is used to populate the Replacement cost and budgeted cost on the order page. It is not used against the budget Replacement cost (rrp in db) -This is used to calculate the 'budgeted cost/ecost' in the budget - it also populates the replacement price in the item created by the aqc process once received Budgeted cost (ecost in db) -This is the replacement/rpp minus any discount on the order - this is the value that will be encumbered when the order is placed Actual cost (unitprice) -This is the eventual 'price' of the item and is the encumbered amount once the item has been received. With the changes that were made one can no longer adjust the 'Replacement/RRP' once an order is placed - this is because this value is adjusted for tax in the db (rrp_tax_excluded, rrp_tax_included) and used for calculating the ecost tax adjusted (ecost_tax_excluded, ecost_tax_included) Some libraries have been having issues as they use 'Replacement' cost mostly for populating items and are not used to it being unable to be edited and/or affecting budgets. We are proposing to rename the current 'Replacement cost' field to match the db value - 'Recommended retail price' (RRP) and add a new 'Replacement cost' field, editable at any point, that is only used for populating the item field. We think this will clear up how the other values are being used and restore functionality that changed. Please let us know if this works or what other suggestions you have here. Thank you, Nick, Kyle, Jonathan

4 3