Re: [Koha] Printing of individual double-sided library cards with Koha

[Marc Véron]

Hi Sybille,

- What kind of printer do you use? Dedicated card printer? Model?
- Do you need as output a PDF document where the card front is on uneven 
pages and the back on even pages?


Kind regards

Marc Véron
Koha Support Schweiz
www.koha-support.ch

Am 20.04.2017 um 06:52 schrieb Deselaers, Sybille:

Dear all,

We have recently introduced Koha in our library and now we want to print 
individual double-sided library cards with Koha.
We have already created the necessary layouts for the front and back and a 
template for an individual card.

Unfortunately, it seems that it is not possible to print a card in one go on 
both sides (front and back).
So, we have to print the card from one side first with the layout for the front 
and then with the layout for the back.

If anybody knows of a solution or possibility for printing the card in one go 
on both sides, we would very much appreciate if you could contact us.

Best regards

Sybille Deselaers

Chief librarian
Goethe-Institut / Max Mueller Bhavan
3, Kasturba Gandhi Marg
New Delhi 110 001
Phone +91-11-23 47 11 49
sybille.desela...@delhi.goethe.org
www.goethe.de/newdelhi
www.goethe.de/india
www.facebook.com/maxmuellerbhavan.newdelhi
Follow us on twitter: @GI_MMB_Delhi


___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha


___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Printing of individual double-sided library cards with Koha

[Deselaers, Sybille]

Dear all,

We have recently introduced Koha in our library and now we want to print 
individual double-sided library cards with Koha.
We have already created the necessary layouts for the front and back and a 
template for an individual card.

Unfortunately, it seems that it is not possible to print a card in one go on 
both sides (front and back).
So, we have to print the card from one side first with the layout for the front 
and then with the layout for the back.

If anybody knows of a solution or possibility for printing the card in one go 
on both sides, we would very much appreciate if you could contact us.

Best regards

Sybille Deselaers

Chief librarian
Goethe-Institut / Max Mueller Bhavan
3, Kasturba Gandhi Marg
New Delhi 110 001
Phone +91-11-23 47 11 49
sybille.desela...@delhi.goethe.org
www.goethe.de/newdelhi
www.goethe.de/india
www.facebook.com/maxmuellerbhavan.newdelhi
Follow us on twitter: @GI_MMB_Delhi


___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Placing items on hold

[Daniel Owens]

Thanks for that tip. It was not the cause, in our case.

On 4/20/17 10:31 AM, Barton Chittenden wrote:

Another thing to look at is the marc record -- duplicate 999 tags can mess
up holds. We've seen it happen; we're not really sure how. If this is the
case, the only remedy is to delete the bib and re-catalog it.

On Wed, Apr 19, 2017 at 1:27 AM, Katrin  wrote:


Hi Daniel,

this sounds all quite good, 2 other things you can try:

- Make sure the system preference maxreserves is set to a positive value

- Enter a circulation condition for All libraries - All patron categories
- All item types, where holds are allowed

Hope this helps,

Katrin



On 19.04.2017 03:21, Daniel Owens wrote:


On 4/17/17 7:09 PM, Owen Leonard wrote:


Our librarian discovered that our patrons are not allowed to place holds

on
items, even though the feature is enabled.


Is this true of ALL items?

Do you have "On shelf holds allowed" enabled for the item types in
question? This setting might be in system preferences or in
Circulation and Fine Rules depending on your Koha version.

   -- Owen

I am still having this problem. Just in case it matter, we are using

Koha 3.22 .04.000.

For my patron type (teacher), I have the following settings:

Circulation rules:
Holds allowed (count) = 5
On shelf holds allowed = Yes
Item level holds = Allow

Default checkout, hold and return policy
Hold policy = From any library

Default holds policy by item type
Books: Hold policy = From any library

 From the staff interface, when I try to place the hold, a dialog opens
with the following:

 None of these items can normally be put on hold for this patron.
 Place hold?

And of course in the OPAC holds are not permitted.

Does anyone have any idea how to solve this?

Daniel

___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha


___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha


___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha


___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Placing items on hold

[Barton Chittenden]

Another thing to look at is the marc record -- duplicate 999 tags can mess
up holds. We've seen it happen; we're not really sure how. If this is the
case, the only remedy is to delete the bib and re-catalog it.

On Wed, Apr 19, 2017 at 1:27 AM, Katrin  wrote:

> Hi Daniel,
>
> this sounds all quite good, 2 other things you can try:
>
> - Make sure the system preference maxreserves is set to a positive value
>
> - Enter a circulation condition for All libraries - All patron categories
> - All item types, where holds are allowed
>
> Hope this helps,
>
> Katrin
>
>
>
> On 19.04.2017 03:21, Daniel Owens wrote:
>
>>
>> On 4/17/17 7:09 PM, Owen Leonard wrote:
>>
>>> Our librarian discovered that our patrons are not allowed to place holds
 on
 items, even though the feature is enabled.

>>> Is this true of ALL items?
>>>
>>> Do you have "On shelf holds allowed" enabled for the item types in
>>> question? This setting might be in system preferences or in
>>> Circulation and Fine Rules depending on your Koha version.
>>>
>>>   -- Owen
>>>
>>> I am still having this problem. Just in case it matter, we are using
>> Koha 3.22 .04.000.
>>
>> For my patron type (teacher), I have the following settings:
>>
>> Circulation rules:
>> Holds allowed (count) = 5
>> On shelf holds allowed = Yes
>> Item level holds = Allow
>>
>> Default checkout, hold and return policy
>> Hold policy = From any library
>>
>> Default holds policy by item type
>> Books: Hold policy = From any library
>>
>> From the staff interface, when I try to place the hold, a dialog opens
>> with the following:
>>
>> None of these items can normally be put on hold for this patron.
>> Place hold?
>>
>> And of course in the OPAC holds are not permitted.
>>
>> Does anyone have any idea how to solve this?
>>
>> Daniel
>>
>> ___
>> Koha mailing list  http://koha-community.org
>> Koha@lists.katipo.co.nz
>> https://lists.katipo.co.nz/mailman/listinfo/koha
>>
>
> ___
> Koha mailing list  http://koha-community.org
> Koha@lists.katipo.co.nz
> https://lists.katipo.co.nz/mailman/listinfo/koha
>
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] zebra - item-level_itypes errors

[Pedro Amorim]

Hello Tom,

Well that sys pref will basically set the way the application retrieves the
type of an item, whenever it needs that information (like circulation
rules, filtering search results by type, etc).
I don't think it's irreversal and you can switch it back and forth without
any database permanent 'damage'.

If you go to Koha Marc Mappings, you'll see there's an *itype* mapping
pointing to a MARC field in *items*, and an *itemtype* mapping pointing to
another MARC field in *biblioitems*. It's a bit confusing at start,
especially if you're an outside, but basically Koha will look in the first
mapping if the sys pref is set to "specific item" and in the second if
"biblio record".

What you should make sure is to check your data and verify what MARC field
the information (item type) is actually in, see if it's mapped correctly
(it's no use having the information in a MARC field if it isn't actually
mapped), and set the sys pref accordingly.

GL,

Pedro Amorim




2017-04-19 19:50 GMT+00:00 Tom Hanstra :

> Since I'm not a cataloger at all, can you (or others) give me a bit of
> information about what I might gain or lose by changing the system
> preference:
>
> item_level_itypes
>
> from "specific item"
> to "biblio record"
>
> in the global settings?
>
> That does seem to address the indexing errors.  But what might I be losing
> in the process?
>
> Thanks,
> Tom
>
> On Wed, Apr 19, 2017 at 12:37 PM, Pedro Amorim 
> wrote:
>
>> Hey Tom,
>>
>> This is caused by the system preference item-level-itypes being set to
>> "specific item".
>> In our case, it happened because upon importing data, this information
>> was set at the record level, not the item level, so we changed it back to
>> "record level".
>> AFAIK this is harmless database-wise, however, it can cause problems in
>> circulation when checking the type of the item being checked out or in
>> searching records by type.
>>
>> Here are my findings while messing with ElasticSearch not a long time ago
>> (it's somewhat related to this):
>> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18163
>>
>> What I advise to do is to keep the syspref according to your data, if you
>> have the information at the record level, set it back.
>>
>> Good luck,
>>
>> Pedro Amorim
>>
>>
>>
>>
>>
>>
>>
>> 2017-04-19 16:13 GMT+00:00 Tom Hanstra :
>>
>>> I'm installing Koha 16.11 and picked up the 06 release.
>>>
>>> Installation went fine, however when indexing with Zebra, I'm getting a
>>> number of records which give the error:
>>>
>>> item-level_itypes set but no itemtype set for item (item#) at
>>> /usr/share/koha/lib/Koha/Schema/Result/Item.pm line 698
>>>
>>> I saw a thread suggesting that these types of records might have the
>>> onloan
>>> value not set to NULL, but I checked and all of my records have onloan
>>> either set to NULL or to a valid date value.
>>>
>>> I also saw that some of these problems might have been fixed by bug
>>> 17502.
>>> It is not clear to me if that bug fix was included in the 16.11.06 tar
>>> package.
>>>
>>> Do I have database problems with these records? If so, what should I be
>>> looking for?
>>>
>>> Or is there something else that can cause this problem?
>>>
>>> Or is the patch missing from this download?
>>>
>>> Thanks in advance for any pointers I can get.
>>>
>>> Tom
>>>
>>> --
>>> *Tom Hanstra*
>>> *Sr. Systems Administrator*
>>> hans...@nd.edu
>>>
>>> 
>>> ___
>>> Koha mailing list  http://koha-community.org
>>> Koha@lists.katipo.co.nz
>>> https://lists.katipo.co.nz/mailman/listinfo/koha
>>>
>>
>>
>
>
> --
> *Tom Hanstra*
> *Sr. Systems Administrator*
> hans...@nd.edu
>
> 
>
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] zebra - item-level_itypes errors

[Tom Hanstra]

Since I'm not a cataloger at all, can you (or others) give me a bit of
information about what I might gain or lose by changing the system
preference:

item_level_itypes

from "specific item"
to "biblio record"

in the global settings?

That does seem to address the indexing errors.  But what might I be losing
in the process?

Thanks,
Tom

On Wed, Apr 19, 2017 at 12:37 PM, Pedro Amorim  wrote:

> Hey Tom,
>
> This is caused by the system preference item-level-itypes being set to
> "specific item".
> In our case, it happened because upon importing data, this information was
> set at the record level, not the item level, so we changed it back to
> "record level".
> AFAIK this is harmless database-wise, however, it can cause problems in
> circulation when checking the type of the item being checked out or in
> searching records by type.
>
> Here are my findings while messing with ElasticSearch not a long time ago
> (it's somewhat related to this):
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18163
>
> What I advise to do is to keep the syspref according to your data, if you
> have the information at the record level, set it back.
>
> Good luck,
>
> Pedro Amorim
>
>
>
>
>
>
>
> 2017-04-19 16:13 GMT+00:00 Tom Hanstra :
>
>> I'm installing Koha 16.11 and picked up the 06 release.
>>
>> Installation went fine, however when indexing with Zebra, I'm getting a
>> number of records which give the error:
>>
>> item-level_itypes set but no itemtype set for item (item#) at
>> /usr/share/koha/lib/Koha/Schema/Result/Item.pm line 698
>>
>> I saw a thread suggesting that these types of records might have the
>> onloan
>> value not set to NULL, but I checked and all of my records have onloan
>> either set to NULL or to a valid date value.
>>
>> I also saw that some of these problems might have been fixed by bug 17502.
>> It is not clear to me if that bug fix was included in the 16.11.06 tar
>> package.
>>
>> Do I have database problems with these records? If so, what should I be
>> looking for?
>>
>> Or is there something else that can cause this problem?
>>
>> Or is the patch missing from this download?
>>
>> Thanks in advance for any pointers I can get.
>>
>> Tom
>>
>> --
>> *Tom Hanstra*
>> *Sr. Systems Administrator*
>> hans...@nd.edu
>>
>> 
>> ___
>> Koha mailing list  http://koha-community.org
>> Koha@lists.katipo.co.nz
>> https://lists.katipo.co.nz/mailman/listinfo/koha
>>
>
>


-- 
*Tom Hanstra*
*Sr. Systems Administrator*
hans...@nd.edu


___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] zebra - item-level_itypes errors

[Mark Alexander]

Excerpts from Tom Hanstra's message of 2017-04-19 12:13:30 -0400:
> item-level_itypes set but no itemtype set for item (item#) at
> /usr/share/koha/lib/Koha/Schema/Result/Item.pm line 698

Our installation has item-level_itypes enabled, but all of our item
records (imported from another ILS) have the itype set to a non-NULL
value.  When I manually set the itype of an item to NULL, I see the
above warning in /var/log/koha/INSTANCE/indexer-output.log. 
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] zebra - item-level_itypes errors

[Pedro Amorim]

Hey Tom,

This is caused by the system preference item-level-itypes being set to
"specific item".
In our case, it happened because upon importing data, this information was
set at the record level, not the item level, so we changed it back to
"record level".
AFAIK this is harmless database-wise, however, it can cause problems in
circulation when checking the type of the item being checked out or in
searching records by type.

Here are my findings while messing with ElasticSearch not a long time ago
(it's somewhat related to this):
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18163

What I advise to do is to keep the syspref according to your data, if you
have the information at the record level, set it back.

Good luck,

Pedro Amorim







2017-04-19 16:13 GMT+00:00 Tom Hanstra :

> I'm installing Koha 16.11 and picked up the 06 release.
>
> Installation went fine, however when indexing with Zebra, I'm getting a
> number of records which give the error:
>
> item-level_itypes set but no itemtype set for item (item#) at
> /usr/share/koha/lib/Koha/Schema/Result/Item.pm line 698
>
> I saw a thread suggesting that these types of records might have the onloan
> value not set to NULL, but I checked and all of my records have onloan
> either set to NULL or to a valid date value.
>
> I also saw that some of these problems might have been fixed by bug 17502.
> It is not clear to me if that bug fix was included in the 16.11.06 tar
> package.
>
> Do I have database problems with these records? If so, what should I be
> looking for?
>
> Or is there something else that can cause this problem?
>
> Or is the patch missing from this download?
>
> Thanks in advance for any pointers I can get.
>
> Tom
>
> --
> *Tom Hanstra*
> *Sr. Systems Administrator*
> hans...@nd.edu
>
> 
> ___
> Koha mailing list  http://koha-community.org
> Koha@lists.katipo.co.nz
> https://lists.katipo.co.nz/mailman/listinfo/koha
>
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] zebra - item-level_itypes errors

[Tom Hanstra]

I'm installing Koha 16.11 and picked up the 06 release.

Installation went fine, however when indexing with Zebra, I'm getting a
number of records which give the error:

item-level_itypes set but no itemtype set for item (item#) at
/usr/share/koha/lib/Koha/Schema/Result/Item.pm line 698

I saw a thread suggesting that these types of records might have the onloan
value not set to NULL, but I checked and all of my records have onloan
either set to NULL or to a valid date value.

I also saw that some of these problems might have been fixed by bug 17502.
It is not clear to me if that bug fix was included in the 16.11.06 tar
package.

Do I have database problems with these records? If so, what should I be
looking for?

Or is there something else that can cause this problem?

Or is the patch missing from this download?

Thanks in advance for any pointers I can get.

Tom

-- 
*Tom Hanstra*
*Sr. Systems Administrator*
hans...@nd.edu


___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha upgrade from 3.16 to 16.11

[Jonathan Druart]

Nicolas, what you describe can be ok, if the tax rate is 0.
You need to provide ALL the price values from aqorders (quantity,
listprice, unitprice, unitprice_tax_excluded, unitprice_tax_included,
quantityreceived, rrp, rrp_tax_excluded, rrp_tax_included, ecost,
ecost_tax_excluded, ecost_tax_included, tax_rate_bak, tax_rate_on_ordering,
tax_rate_on_receiving, tax_value_bak, tax_value_on_ordering,
tax_value_on_receiving, discount, uncertainprice).


On Wed, 19 Apr 2017 at 12:16 Nicolas Legrand 
wrote:

> Hey Jonathan, Hey Hugo,
>
> we also have trouble in 16.11 with tax calculation :
>
> mysql> select unitprice_tax_excluded, unitprice_tax_included from
> aqorders join aqinvoices on aqinvoices.invoiceid = aqorders.invoiceid
> where aqinvoices.invoiceid = 2674 limit 10;
> +++
> | unitprice_tax_excluded | unitprice_tax_included |
> +++
> |  80.40 |  80.40 |
> |  32.76 |  32.76 |
> | 110.70 | 110.70 |
> |  87.41 |  87.41 |
> |  23.29 |  23.29 |
> | 127.32 | 127.32 |
> |  28.94 |  28.94 |
> |  72.24 |  72.24 |
> | 205.67 | 205.67 |
> |  18.59 |  18.59 |
> +++
> 10 rows in set (0.00 sec)
>
> We had a lot of errors while upgrading we unfortunately didn't pay
> attention to:
>
> Use of uninitialized value in multiplication (*) at
> ./installer/data/mysql/updatedatabase.pl line 13614.
> [A LOT MORE OF THE SAME THING]
> Use of uninitialized value in multiplication (*) at
> ./installer/data/mysql/updatedatabase.pl line 13619.
> Upgrade to 16.06.00.043 done (Bug 13323 - Change the tax rate on receiving)
>
>
> I'm going to investigate this, if someone as good ideas I'm eager to
> hear from them :).
>
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha upgrade from 3.16 to 16.11

[Nicolas Legrand]

Sorry, it seems to be a problem with our conf, we avec a 0 taxes rate,
since we buy from the whole world.

2017-04-19 17:16 GMT+02:00 Nicolas Legrand :
> Hey Jonathan, Hey Hugo,
>
> we also have trouble in 16.11 with tax calculation :
>
> mysql> select unitprice_tax_excluded, unitprice_tax_included from
> aqorders join aqinvoices on aqinvoices.invoiceid = aqorders.invoiceid
> where aqinvoices.invoiceid = 2674 limit 10;
> +++
> | unitprice_tax_excluded | unitprice_tax_included |
> +++
> |  80.40 |  80.40 |
> |  32.76 |  32.76 |
> | 110.70 | 110.70 |
> |  87.41 |  87.41 |
> |  23.29 |  23.29 |
> | 127.32 | 127.32 |
> |  28.94 |  28.94 |
> |  72.24 |  72.24 |
> | 205.67 | 205.67 |
> |  18.59 |  18.59 |
> +++
> 10 rows in set (0.00 sec)
>
> We had a lot of errors while upgrading we unfortunately didn't pay attention 
> to:
>
> Use of uninitialized value in multiplication (*) at
> ./installer/data/mysql/updatedatabase.pl line 13614.
> [A LOT MORE OF THE SAME THING]
> Use of uninitialized value in multiplication (*) at
> ./installer/data/mysql/updatedatabase.pl line 13619.
> Upgrade to 16.06.00.043 done (Bug 13323 - Change the tax rate on receiving)
>
>
> I'm going to investigate this, if someone as good ideas I'm eager to
> hear from them :).



-- 

Nicolas Legrand
Administration technique et développements du système de gestion de la
bibliothèque


Bibliothèque universitaire
des langues et civilisations

65 rue des Grands Moulins
F-75013 PARIS
T +33 1 81 69 18 22
www.bulac.fr
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha