Please consider the following scenario: I have a book in my hands that bears ISBN-13 9780553507065, and wish to make a biblio entry in koha. I go to Home > Cataloging and perform a "Cataloging search" i.e. "Search the catalog and the reservoir" with the ISBN on the book. Failing to find it, I then perform a Z39.50 search, select a fitting entry and try to import it in my koha, only to find that the book already exists there. Odd... Correct me if I'm wrong, but koha staff client cataloging search at /cgi-bin/koha/cataloguing/addbooks.pl seems to look for specific strings of characters. Therefore, when one enters an ISBN number of 9780006483113 as a search string for example, koha fails to find entries bearing ISBN numbers of 978-0-553-50706-5 0-553-50706-0 0553507060 i.e. the alternate forms of the same ISMB number. I also remember reading here in the list, that when performing Z39.50 searches koha first "translates" the ISBN-13 user input to ISBN-10 before querying Z39.50 targets. Thus, should one select a Z39.50 result with ISBN-10 and fail to "correct" it before saving the new entry, is prone to the problem described above. Furthermore, should that be the case, if one chooses to use the ISBN-13 form only when editing his own entries, they would fail to appear on other people's searches on his own koha installation, if their own system was koha too (or preformed along similar lines). Questions: If one wishes to enter all four alternate forms of the same ISBN, is it better to use multiple 020a entries (in USMARC) or to use multiple occurrences within the same 020a entry? Do other libraries/systems use the notion "A | B | C | D" I see in their Z39.50 results, or is it simply a convention used to display in one line values kept as discrete entries in the originating system? Suggestion: I guess there is some valid reasoning behind the behaviour described above, resolved when these koha modules were created, I wonder however if it would be useful that koha would automatically populate the bibliographical entries with the missing alternate 020a entries (in USMARC), either at the time of user input, or by some batch procedure, that would also take care of existing entries. This could well be controlled by two new options/preferences, one that would enable such behaviour and one that would instruct koha to use one 020a entry to keep all four forms, or four discrete entries. kind regards, Manos PETRIDIS Athens, Greece