I've noticed in the current gamma version that when there is data from my last sale (due to Beancounter), it will default to that.
Let's say I sold this wand I can make, last time, for 15s. But on the last auction scan, everyone else is selling them for 30s. If I mouse-over my wand, it says that it would be posting it for 29s (undercutting by 1%). I go to post it and turns out it's about to sell it for 15s, because that's what I sold it for last time.
I'm all for using this data, but not in this manner. I don't think this is how beancounter should be used. Here's my suggestion:
A) Use the 'last sale' price OR the price based on the most recent scan, whichever is /higher/ (after all, we're supposed to be making money here). If the price has gone up since your last sale, you'd be using the most recent scan. If the price has gone down, you'd use what you last sold it for...beancounter would be able to detect if it doesn't sell this time (due to the price going lower) and then next time it would be based on the most recent scan because there wasn't a 'last sale'. This should be default behavior, though you should be able to set the behavior to either /that/, or always use last sale price (when present) or always use last scan price.
B) If beancounter detects that an item has not been sold using its current price, it should lower the price. This is for items that have 'no competition', when you posted it last time and still have no competition when you're going to post it again. Beancounter should be there to tell me either to lower the price, or give up, it's not selling. If I post an item every day for long enough that the price I'm trying to sell it for doesn't even cover the cost of all the times I reposted it, it's time to vendor it (or disenchant it, if applicable). If I post an item that has no competition but it doesn't sell, beancounter should lower the price a bit for the next time I post it, especially if it still doesn't have any competition to base the price off of. Basically 'undercutting myself', until the item gets sold.
C) If you ever are about to post an item for a price that you would get more money for vendoring it (Either from last sale price, last scan price, OR manually entered price), it should tell you to vendor it and (if a corresponding option is enabled), prevent you from posting it until you list it for a higher price. In short, if final sale minus deposit is not greater than what you'd get for vendoring it, it should balk.
Hopefully I was clear about my beancounter suggestions, if I was not, please let me know.
And a small little bug. Informant should really be able to pay attention to stuff like how much you can sell an item to vendors for, and how much money is required to deposit to auction it; it should record this data and edit its information file. It should give a little notification in chat when data like this has been updated in order to remind us to mail it in for the default data set. This would be better than you guys trying to compile all this data yourself.
Similarly, it'd be nice if Enchantrix was able to detect when my recorded data has varied from the default data enough that a merge would be a good thing. If my data is pretty much exactly the same as the default data, there's no need to send it in.
It's been a long while but all of my suggestions remain pretty much exactly the same.
I've stopped using Beancounter because it doesn't work how I described in A. It's more a hindrance than a help because it doesn't work like A.
I'll break it down, in case it was confusing.
Step one: Beancounter gets the price you actually sold it for from the mailbox. (Last Sold = true) Step two: If an item is returned as unsold, it gets marked as such. (Last Sold = false) Step three: When you go to post an auction, check if there is an auctioneer 'undercutting' price for the most recent scan. (undercut = true) Step four: If undercut = true, and Last Sold = true, then: Option A: Use undercutting price always, Option B: use Last Sold price always, Option C (default): use whichever of the two is higher. Step five: If only one of the two is true, use that price. Step six: If neither is true, use whichever price is lower. Option A: If Last sold = false, and undercut = false, lower price by X% (configurable) when reposting. Option B: Don't do option A.
This kind of incorporates part of suggestion B, too, near the end there. If you want to incorporate the rest:
Step Seven-A: If last sold = false, then multiply the auction posting fee times the amount of times you've posted the item since its last sale, and if that is greater than the vendor value of the item, suggest vendoring the item to break even. Option A: Include the disenchant value instead of vendor value: Option B (default if enchantrix is disabled): include vendor value only, Option C (default if enchantrix is enabled): include whichever value (vendor or disenchant) is higher. Step Seven-B: If last sold = false, then multiply the auction posting fee times the amount of times you've posted the item since its last sale, and if that is greater than the current attempted profit, balk, and suggest vendoring the item. This item is NOT going to sell on the AH, and even if it does, you've already lost money on it, unless you raise the price, which would make it even less likely to sell.
Step eight is very similar to seven and includes suggestion C from the original post of the thread.
Step eight: If current attempted price, minus auction posting fee, is less than vendor price, suggest vendoring the item. Options A-C are exact copies of Step 7's options.
Hopefully that's clear. If it isn't, sorry, I've been awake too long.
Hence why there's options. If you notice, if you choose the correct options, there's no change from the current mechanism. I suppose 7 and 8 need an 'off' option too.