Cataloguing requirements for Booksellers

October 20, 2006 at 11:02 am 4 comments

The developer of Beanbag, and a friend of his, have both posted comments on my blog entry on this cataloguing application. Both of them are interested in the general requirements that booksellers have for their cataloguing applications. This is a positive step forward for two reasons. Firstly, they both claim to be open source developers, which means that if this application gets off the ground it can be modified by booksellers as they see fit. Secondly, if they’re interested in modifying their application to meet bookseller requirements, we could see another worthy piece of software hitting the industry.

In response to their request for requirements, I can provide some very brief remarks that are general enough to apply to most rare bookdealers, but it would be handy if any other readers could add to these in the comments area to encourage more development work in the field. As I’m strapped for time these are the first things that I can think of off the top of my head.

General Requirements:

  • Invoicing – Any bookseller needs this as a facility tied to the cataloguing application, so that for a single sale multiple books in the cataloguing application can be marked as sold (archived) and then added to an invoice which can be issued to the customer and stored for reference.
  • Customer database – This is usually tied to invoicing. Certainly in the rare book trade you get a lot of repeat business and you need to be able to quickly create invoices for particular customers regularly. This is also handy for keeping a “Wants” list so that you can mail customers who have particular wants when relevant new stock comes into the shop.
  • Export facilities – Any cataloguing software for a bookdealer needs to cater for a range of export requirements. Most dealers nowadays upload catalogues of books to various portal sites like ABE, Bibliopoly, Alibris etc. Dealers need to be able to select the fields that they wish to export and the order in which they would like to export them. Usually, this is fine as a delimited text file.
  • Purchase Details – For every book in stock, dealers usually require a purchase history which should include where the book was purchased from, when, and the cost at which the book was purchased.
  • Sales Details – the cataloguing software must include Pricing information etc
  • Shares and Approvals – some dealers partner up to buy books and sell them, as a result, it is useful to provide a facility to mark a book as a Shared item and to include share details. Obviously, this affects Purchase details and Sales details accordingly. In the rare trade, books are frequently sent out for approval before sale. This is similar to a loan, the book is sent to a potential customer for them to decide whether they want it or not. Books that are sent out like this need to be marked as out on approval, and it would be useful to have a reporting/reminder facility to follow up on books that are currently in this state.
  • Multiple images – with rare books, a pretty generic picture of the cover doesn’t help much. Dealers need to be able to take multiple images of a book and store these to indicate actual condition of the stock.
  • Catalogues – Nearly all dealers release regular catalogues of selected stock. The books database needs to facilitate groupings of stock that can be stored and exported in a variety of formats for use to build print or web catalogues of items of interest.

The above list is pretty random and eclectic, if you’re really serious about developing for the rare trade try and get your hands on some of the other software out there, or simply browse a couple of the rare book dealer websites to get an idea of how they stock their items and the sorts of facilities that they’re likely to require.

Advertisements

Entry filed under: Uncategorized.

Sotherans Launches A New Website Antarctica and rare exploration books up for auction

4 Comments Add your own

  • 1. Ankur  |  October 20, 2006 at 2:19 pm

    Thanx for this very relevant insight that u provided … I hv fwd the same to my friend … I hope he does complete the software along with these features too .. and btw I dont know Manasys … Thanx once again 🙂

    Reply
  • 2. Paul Romaine  |  October 20, 2006 at 7:42 pm

    Most cataloging software relying on AMZ and similar sources has trouble differentiating between editions, issues and reprints (a bibliographic nightmare of sorts). And edition priority is often key to value for many books.

    The greatest need (IMO) for rare books is what librarians call “copy-specific” information–in other words, information about your copy of a book which is true of only your copy. Copy-specific information might include, but is not limited to:
    * Condition
    * Previous owner (signature, bookplate; inscription)
    * Additional parts (e.g. added illustrations)
    * Missing parts
    * Numeration (with limited editions, what number it received from the printer or publisher)
    * Signed copies, when signed by author, artist or maker
    * Binding, particularly for bindings before 19th C cloth publishers’ binding

    You often want to add special indexing for data such as previous owners. Some genre term creation might also be useful (e.g., Graingerized books, Association copies,

    Basically, all the 59x note fields in the MARC format. (A “9” anywhere in a MARC tag usually indicates that it contains local, copy-specific information.

    You got to remember that cataloging and descriptive bibliography (and a lot of textual editing) rely on a notion of an ideal copy (text) from which ideal particular copies will depart/vary. Sounds vaguely platonic, doesn’t it?

    BTW, I imagine “Catalogues” might be implemented via some tagging system and the ability to run reports using multiple tags (“Dickens, Charles” + “Trollope” + “Victorian novel” etc.)

    Great blog.
    Paul

    Reply
  • 3. Peter Reynolds  |  October 21, 2006 at 10:32 am

    We use ABE’s Homebase software, which is free to download from abebooks.com . Any new software would need to be able to import our entire database of sold and for sale books, and operate in a similar way. There are quite a number of improvements that could be made to HomeBase, but most of its existing features are pretty essential.

    Reply
  • 4. Waxing Gibbous Books  |  November 1, 2006 at 12:36 am

    Some marketing database functions would be extremely helpful because, after all, if a customer has had a rewarding and pleasant experience with you once, he’s more likely to come back again and purchase again. Not all purchasing decisions are based on price; most, after the initial purchase, are based on intangibles. And you’d certainly like to know at a glance who those purchasers have been, perhaps sorted by purchase history and…well, I’m certain you get the idea…this is just something I’d like to see for my own benefit and perhaps many others would like it as well. Thanks for your effort, intelligence, and time.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Subscribe to the comments via RSS Feed


Recent Posts

RSS New books at Shapero’s

  • An error has occurred; the feed is probably down. Try again later.

RSS New Books at Maggs

  • An error has occurred; the feed is probably down. Try again later.

%d bloggers like this: