Bruji

After setting up my library and entering the books into the program, the software applies the corresponding ISBN number in the appropriate box. When I scan my book for checkout with a barcode scanner, the program doesn't retrieve the book because the ISBN and the barcode number are different. Any suggestions for a quick check outsystem using Bookpedia?

The new standard as of January is not to change the EAN into an ISBN and we will be making that move soon now that Amazon lets us search via EAN as well. Scanning in the search field will work after that.

Conner,

WIll we still be able to have a field for ISBN? In other words will we have both the ISBN and the EAN field? Then we can search by either or manually as well.

And is that as of Jan 08?

Finally, will we have to go through our library and rescan the books to get the EAN number to reside in our database, or will there be some patch that we can use that will automatically get it for us?

Remember, some books, periodicals etc. do not have either a EAN or ISBN number because they are so old or limited run etc. and we have to create a barcode label for them! AN example is the collection of executive book summaries. I have over a thousand now and have had to create barcodes for them.

Thanks

These are the issues we are trying to decide. It's easier to let the big guys go first, like Amazon, and let them set the standard. It's true that in our case it more complicated as we have to be able to deal with older books that do not have an EAN. Luckily the use of EAN in the book world has been going on for quite a while now. Most ISBNs can become a 13 digit EAN by prefixing 978 (what is called bookland by some, as in regular EAN numbers the beginning section represents the country code) and recalculating the last digit (the check digit). So we might provide a function to change the ISBNs back to 13 digits using this information.

As of January 1, 2007 all ISBNs assigned have 13 digits instead of 10. The ISBN system will be encompassing two system for the time to come, since they are overlapping and backwards compatible we are leaning towards keeping one field that can hold either number type.