If you are serious about the book industry, you have heard all this before, so you can probably stop reading it now.
For the rest, please pick up a paperback or hardcover book. Now look at the back cover. You will see a 10-digit ISBN printed near the barcode. This ISBN has been around for over 35 years. As the last digit is a check digit, we have nine numbers. This is no small number, as a billion books can be listed using this. That is enough to cover every book ever published and every book that will be published for a long time. The problem is that these numbers have been divided into many different categories. Some categories are getting full.
A similar problem occurs if you go into a supermarket. Sometimes, what you see is some shelves empty and some packed. What has happened is that in one category, there is not enough stock to fill the shelf, but in the other category, there is too much, and it cannot fit. So some of the shelves are full, and some are empty.
The book industry decided, rather than spreading the numbers from the empty categories to the full ones, to use a barcode, turning a 10-digit code into a 13-digit code. They then looked at their current electronic data exchange standard, BISAC. They quickly saw that BISAC cannot handle a 13-digit number and should offer more information. Also, they noted that technology has moved in 35 years. The rest of the world is going XML, a format recommended by the World Wide Web Consortium, which is the closest body we have that governs the World Wide Web.
The book industry has always been progressive, so it decided to bite the bullet and fix many problems together. It would go to 13 numbers and modernise the BISAC file. So, it came up with the ONIX file, which is built with 21st-century technology.
They then turned around and gave everyone years of warning. The industry date set was January 1, 2007, which was years away at the time.
As many other software suppliers did, we booked industry meetings and discussed the proposed changes with them.
We brought up the details that many DOS users could not handle the ONIX files for those trying to understand what is involved in handling ONIX in our DOS system. First, we would have to write a link to the internet and XML. Something possible but not trivial, then significant file changes and probably almost every screen and report with stock. Changes of this extent would probably cause bugs for everyone who uses our system until we work them out. So it would have to be a new system separate from the newsagency system.
Many of the book suppliers stated they understood and that they would continue the BISAC file until mid-2008. To them, it is just another choice in their software, ONIX or BISAC.
For engaging PowerPoint presentations discussing what is happening, check out the following
<removed>
So well briefed, we worked on resolving these issues in our software. Our clients in the book industry helped us out considerably, and we got it working.
So what is the problem? Well, nothing and plenty, depending on what you want from the book and your retail software.
If you have a recent copy of our software, POS Browser, then it is not a problem.
If all you want to do is sell books, then there is no problem either. Just enter the stock as you do now and sell it. The retail systems can handle barcodes. If you want a special order, just quote the barcodes to the supplier.
In March 2007, if you want to use BISAC, I will get several different stories from book suppliers, some of which are saying,
1) We have a cutoff date for this data, and from this date, we only have ONIX
2) Our software has been updated, and we cannot send out the BISAC now.
3) We don’t know how to handle BISAC. (This is true with the frequent changes in staff and people invoicing in the book industry. New staff do not know the choices for BISAC, and it is too hard for them to remember who gets BISAC.)
4) Industry standard is ONIX, and BISAC cannot handle the new book codes. (This is not strictly true.)
Some book suppliers have stated that they are looking at the ECG committee DDO files, which are DOS-compatible. The problem here is that POS Solutions originally designed this standard for cigarettes. It was generalised for any stock item in a POS newsagency management system. Later, the ECG committee adapted it for their magazines and cards. It is not designed for books. More importantly, it is not an easy standard to use.
So what has happened is that a book supplier has a consultant look into it. The consultant gives a quote. The book company thinks about it. You ring up a month later, still thinking. Another month later, well, in one case, I rang up and expected to hear that they are still thinking about it. Still, now the company manager stated, “Now after so many years people are complaining. This proves the need for booksellers to keep upgrading their software and systems…... It is not our problem…..We are not picking up the tab”. I suppose it depends on how essential newsagents are to that supplier. The reality is that no book supplier has gone to DDO files.
So now what happens?
Well, for almost 90% of our users, probably nothing needs to happen. Most of those serious in-book problems are on Posbrowser. Years ago, they heard of the problem and started talking to us about it.
Overall, I suspect that only a few of our DOS users are affected. When I went over the list with some book suppliers, I found that very few are getting the BISAC now.
Some may seriously think of updating their system. If so, give us a call ASAP.
