Price paid feature?

I'd like to be able to record what I paid for the books I buy, and to generate the total value of my library...
Lisa

Those are two separate requests.

The amount you paid for each book can be added in comments or private comments, but there is no current column that has any auto-calculation.

However, the total value of you library is a completely different matter.

There's really no way that LibraryThing can tell you the total value of your library. Such a figure has no connection to the price you paid for your books, but would need to take into account current demand, condition, etc. And, of course, whether you wanted the value for insurance, resale or estate purposes.

This is a regularly-requested feature, and there's really no reason some basic form of it can't be implemented.

There could easily be a numerical field called "price paid".
The sum could easily be calculated.

Would this reflect the true value of the library? No.
Would this take into account that people might buy books in different currencies? No.
Do these problems really matter? No. I'm guessing that at least half of the people who request something like this would be satisfied if they could enter what they paid for each book and see the total.

It certainly could be implemented, but it's more complex than you might think to get it right.

1. If there was a field, some members would immediately protest that it wasn't auto-filled. If we didn't auto-fill it the perception, frankly, would be that LibraryThing had a useless, broken feature. It is often worse to add such a feature than to not have the feature at all.
2. If it were auto-filled, the data would probably have to come from Amazon. Amazon is very strict about keeping pricing data up-to-date. We couldn't keep it always correct, because reloading data for millions of books every three days at no more than 1/second is impossible. Instead, I think we can display old data so long as we carefully label it with the time and date it was created. So we'd have to display that too.
3. Members would ask for price from other sources. I've long wanted to do something like this with BookFinder, so you could know what your book was "going for." But such things take time and add "weight" to the application.
4. Calculating the total would be hard.
5. For example, members would ask for prices in different units. It's a perennial cry that LibraryThing ignores international users. So, we'd be adding a whole currency layer to it. We might even end up having to track currency values for an aggregate price.
5. For example, members would ask for storing prices that don't work well as integers (eg., "About ten bucks back in 1960").
6. Between the units and the dates, we couldn't make it a simple click-to-edit in the catalog.

I'm not saying it's a good idea, but it's not trivial.

I think you're exaggerating the demand for auto-fill. There are people who want tags to auto-fill too, but you're not going to get rid of the tags field because of it. Likewise, some people want to auto-fill Date Acquired or Date Read with the current date. Too bad. That doesn't negate the value of the field or mean that it's "broken".

For your other points too, people sometimes want the date acquired/read fields to allow something like "about ten years ago". Again, that's too bad. I'd much rather have a purely numerical field than nothing.

Basically, yes, it could be complicated if you want it to be--so complicated that it doesn't happen at all. It could also be very simple: a plain numerical field. It doesn't have to auto-fill, it doesn't have to deal with different currencies. I'll pretend the field is in Canadian dollars and use it accordingly; you'll take it to mean US dollars and use it accordingly.

I'd much rather have a straightforward, easy-to-use field that actually exists than an imaginary, hard-to-use field that might come into existence a few years from now.

And for the record, editing in catalogue is a dealbreaker for me. Even if I had initially thought it was worth the time of developing a non-numerical price field, I'd have changed my mind as soon as you said it couldn't be edited in the catalogue. Now I actually think a plain numerical field is far superior to the other option. If you made an auto-filling field that dealt with multiple currencies but couldn't be edited from the catalogue, THEN I'd complain that it was broken.

A plain numerical field that I couldn't enter currency into would make it useless for me. I'm not about to translate the various currencies I buy books in into Euros. I would want to be able to label the number with the currency. I couldn't care less about a total.

The fact is that if 100 people want such a feature there are at least 90 different things they actually want from it, and each of those is a deal breaker for about 75 of the others.

If you don't care about the total, then why not just use comments? The comments field already lets you enter a number with a currency.

I'm not at all convinced that people want such different things, or that the things that actually are different can't be handled by other fields (like comments) already.

ETA: I don't feel strongly enough about this field to push for it. I'm all in favour of easy solutions that make a lot of people happy (note: "a lot" is different from "all"), and I thought this was a case where you could do that. But if it has to get at all complicated, I don't think it's worth the effort.

I don't really care if LT implements this feature. I'm not tracking prices here now, but if a field was started for it, I would want to be able to use it.

(And I would want to be able to enter the information not only from current currencies, but all the old information from pre-Euro days that I have on my computer.)

If you have a valuable library of rare books you should insure it for replacement value. In that case you should probably keep careful notes about the condition of each book. I don't know if the price you paid for it is relevant.

It seems like LT would prove a valuable resource if your house burns down or gets washed away by the rising sea level.

I use the comments field for another account, my "kairfa" account, to keep track of what postage I paid for the books I send out on bookmooch. I also use the private comments to record who got the book. I download the CSV file, put it into Excel, then sum the private comments field for the postage I've spent.

I personally don't care how much I paid for a book, even if I had all the prices I paid for all the books I've bought since I was about 9 years old and still have.

What's good enough for me is that I have an accurate representation of my library for insurance/replacement cost purposes.... think I'll download a new CSV now. I do it about every week or so.

if a field was started for it, I would want to be able to use it.

If it's something really basic that doesn't take much time, I'm not particularly concerned about whether I can use it; I still think the number of people satisfied for the effort spent would make it worthwhile. When there are massive new features like Collections that aren't implemented in a way I can use, then I'm extremely pissed off, but with something simple and minimally time consuming I don't really care.

A simple column (not autofilled) that accepted numbers and then calculated a total could be useful. People could use it for any number of reasons (e.g., price paid, total times read, total number of pages, etc.).

I'm not particularly interested in such a column any way, but if it weren't a designated-purpose column, perhaps people wouldn't expect so many features and autofill. However, it would still suit their purpose.

price paid, total times read, total number of pages

If adding columns is easy, I'd like separate ones for all of those ;)

Oh, and while I'm dreaming, what I'd ultimately like to use these for is monthly and yearly totals based on the date fields--pages read this month, money spent on books this month, etc.--and graphs thereof.

I want a page number column even if it's extremely difficult and time consuming to implement. :p

I would like a numeric field (or text field!) so I can put an estimated value of my books in there. I would not expect it to be autofilled since a book could be dog-eared, autographed, collectible, first edition, etc. So there's no point auto-filling.

We just had frozen pipe burst and water damage so having that data readily at hand would have been very handy for the claims adjustor.

Currently the only fields I can use for "VALUE" are already used for comments. So sharing a comment field with a price makes it impossible to sort or sum the values. If I were to download my library to CSV and there was 1 or more generic fields available, I could use them for whatever I like.

I think timspalding may be overthinking this idea. I develop software too. And I wouldn't have any problems telling users, "There's a new generic field there for you (why not three!) to store whatever you want: pages, price paid, current Amazon price, insured value, date read, name of person who is borrowing it, whatever..." User's choice. Not public. Not supported. Not even labeled anything other than User Field 1, User Field 2, etc... That's the extent of the support needed. Most databased apps have a set of "user-defined fields" available like this to handle all those special requests but make them the users problem to sort out...no customization by the developer needed.

Meanwhile, I'll download my data, write the script to peel "current lowest used" prices off Amazon based on ISBN and add to the list in Excel. Just would be nice to be able to keep that info in my online Library.

I'm not dying to have a new "price paid" field, but I think it possibile, as there already is on aNobii for example. Why should people want it to be auto-filled? You can buy a used book and pay less than the Amazon price for it, you can buy it from a different store, you can win it on eBay, you can get a discount of it, etc etc, so I'd definitely want this field to be filled MANUALLY.

Such a user-defined field would need to be sortable to be useful for location, which is one of the other big requests for another field.

There's also the question of whether to value them at market value or (ahem) book value.

Sorry, I'll just show myself out now.

Obviously having a numeric field is possible. It would involve a fair bit (4+ hours) of downtime. However as above it is decidedly non-trivial - some people want to record what they paid, some what a book is worth. When you look at what was paid it has to be multi-currency. How about old British currency? How would I record 2/6 (2 shillings 6 pence) - we weren't on decimal currency at the time.

Although it would seem a quick change it has hidden complexities for anything other than a quick and dirty solution and it would take focus away from more important changes - collections for example. Collections has had far more vocal and far more numerous boosters, and I gather that Tim and Chris are pretty close to finishing it (please say that it is so).

>6 _Zoe_: and >8 _Zoe_: and >17 DoryO:

I'm with _Zoe_ and DoryO on this. Giving users one to three simple numeric fields, each displaying a total, would be a terrific addition! Don't make it overly complicated.

Please consider any more complexity (various currencies, conversions, etc.) as an entirely different, lower priority feature request that will be considered in a future major release. Also, I can't imagine preferring auto-fill in any instance.

I have to admit, I have no interest in a price paid/value field, but a user-defined field of any kind would be great! Maybe one numerical so there can be an automated sum, and one text. If it's popular enough, additional ones could be added (though honestly, I think LT provides fields for almost everything).

I would want a text one just for sorting - most of the things I might want to put in there are already tags for me, but I don't want to go back and put my tags in a particular order so that they'll sort the way I want - so another field where I could duplicate that tag just for sorting would be fantastic.

23, I would LOVE having two fields such as you describe, timepiece!

Thirding #23. Great idea.

>18 Moloch:

The Anobii field is filled from Amazon. That we could do, although there's some doubt about whether it contravenes their terms to do it. To grind my own axe, I don't think Anobii gives a damn about licenses. Their Italian data is far too rich to come from anywhere but a book industry source--it's not library data, though--and they don't have any license notices posted, the way Muze, Bowker, Ingram or the others would require. I figure they basically stole it from someone and figured nobody would sue a Chinese company. Maybe I'm being cynical and they have a secret no-notice deal with someone.

I think we could get away with using Amazon if we put a time stamp on the amount. That's probably the thing to do.

I think auto-fill would be a terrible addition to such a feature... Just plain terrible. Three quarters of my books were purchased used. Amazon's data would be useless for any other users--and I would assume there are many--who shop around as much as I do.

Moreover, if one was using this field to record what one actually paid, it would be bad to find it changed to whatever the going rate on Amazon is at any given moment. In other discussions of this feature, I have seen people ask for that.

Auto fill from any source would be horrible for international members.

Agree with #23 and #29. Simple user-defined fields would be great. No auto-fill, I don't think there's really any way to satisfy everyone no matter how much work you do.

Personally, I wouldn't think totalling would even be necessary. (Would you just always show the total for all books in the user's library, or the current collection, or the current filtered view in the catalog? To show the total of the current catalog view, you'd have to retrieve all the records from the library, wouldn't you? Not worth it.) If people want a total they can export and import to OpenOffice.org Calc (or the spreadsheet of their choice).

I would like the fields sortable, though...

I think the only way to make both sets of people happy would be to have 1-3 number fields and 1 auto-fill field.

>26 timspalding: Tim - If I read correctly, the poster you responded to in #18 did not want autofill. It seems to me that a manually-entered price/number column would be very valuable to a lot of members. Don't go through the trouble and work of doing autofill, or currency, or whatever - certainly not to start. Just have a numerical column that goes out two decimal points. People could then use it as they wished and if there is a lot of outcry for autofill or currency, do it later - after collections are introduced. ;)

>26 timspalding:, 32

Yes, I do *not* want an autofill (I thought that was clear, but it's not always easy to follow these technical discussions!)... And I'm not sure if we're talking about the same thing, since on my aNobii library I always have to fill the price field *manually*, it's not generated by Amazon.

This new addition should be kept really simple, IMO, just a box where you write, let's say, 5.00 and select the currency (I've left out the "total value" request).
But anyway, as I said before, it's not that I care really much about it, so if Tim isn't enthusiastic, that's ok.

I LOVE the idea of user-defined fields, both numerical and text. In my own database of my antique children's book collection, I have several fields that are useful to me (copyright date, date published, illustrator, author birth year, death year, size of book...) that would not be useful to very many people. I'd love to do this with LT.

Of course, since I have a relational database set up to my own specifications, LT couldn't really ever replace it. But, it would be nice to add more functionality for those of us who collect rather obscure titles (some not even in the L of C).

LT already has fields for date published and illustrator (it's actually labeled Other Authors but you can specify a role for each name and illustrator is one of those).

And you can add Author Birth and Death Year on the author pages instead of the books.

35 and 36 - Thanks! I didn't know about the author pages - I haven't started to add my ancient collection (~800 children's books printed 1797-1899), so I haven't thoroughly researched it for that. I was just listing some of my database fields that I could use the user-defined fields for - some that other people might not care a lick about :-).

A user-defined numeric field would also work well for recording page counts.

Something reminded me of this thread recently. Boy, I would still love a field (user-defined or not) where I could get a total for numeric values easily. Personally, I would use such a field for page numbers. Sorting by page number would be such an interesting way to view my library!

I would love a field dedicated to price paid!

I know there are complications to this per this comment from the Founder of LibraryThing http://www.librarything.com/topic/53045#959628

However, I will say - even just a basic field that only allows numbers would be enough for me personally - as I can export my library and do any additional math I might need from there. (In theory, I am currently having issues exporting so cannot see the data included. - I have submitted a ticket).

>40 Littl3spr0ut: You can put it in private comments.

>17 DoryO: I know this is an old thread, but I can't help but say I, and apparently many others, am in favour of User Field 1, User Field 2, and User Field 3! I have SO many uses for these fields!!

Consider Comments to be User field 1 and Private Comments to be User field 2.

>43 MarthaJeanne: Alright, then, I am in support of User Field 3, User Field 4, and User Field 5, since I am already using those 2 fields and would have use for more.

>42 GraceCollection: Agree! to this and your other comment (44).

See the new feature from August 2025 "Collectors" information
https://www.librarything.com/topic/373413#n8955218
It includes four new fields—List Price, Purchase Price, Value and Condition