Yes, as I said I noticed this. But this is the point at which payment was received (I assume), not the end of the sale for each Listing in the Order record. I could use this as an approximation, though it will involve scripting (1) finding the Order for the listing, (2) finding every other Listing in that Order, (3) copying the Order Date into a User Property of each of those Listings. As long as all that is scriptable, I can work with it.
I suppose I could be more accurate by asking: is the time a Listing changes from “Running” to “Ended Successfully” recorded in a scriptable place, or anywhere? We know it does change, because its state changes in the database. But is there a date+time associated with that?
This request reminds me a related matter I have in mind to ask here in the forum for a long time (so sorry for the partial OT… but I need it).
Further than the date of sale, which I also looked for a while in the order section but didn’t find, I need to know if the exact amount of the sale is somewhere reported in the tab @vjl indicated. If listing is fixed price and a lower offer is accepted, the amount shown is not realistic. I mean, when I highlight a bunch of sold items, I expect GS to show a sum of real sale prices, not the sum of original price of the listing. No problem with auctions, but it doesn’t work for fixed price items if I accept offers lower than the original price…
Staying it topic, why GS doesn’t show the exact date of sale in the right side column of order? That would be very important. As said, it is the payment date.
Well to be fair, if the item “sells” but is not paid for, it will remain in “Ended” status until somebody pays for it (either the original or Second Chance buyer). So arguably two Listings “bought” by the same person could end up in two different Orders, either by one buyer splitting or delaying them, or by not paying.
I’m going to guess that the state machine eBay uses for item status business logic is almost identical to what GS shows us. The events eBay tries to be accurate about are the ones where we pay them such as listing/autorelisting, payment received, and so on. There’s still a lot of slack in the “deciding the buyer isn’t going to pay” part, the shipping deadline (which we can still select as sellers), and conversations with buyers about returns afterwards.
Basically, a Listing is in a sort of status limbo when somebody agrees to buy it, but has not yet paid.
This won’t solve the problem now, but for the future for sure - require buyers to pay upon purchasing something. That’s how eBay.com is setup by default, I think. Both for offers I send to watchers, and buy it now items. And I do believe auctions work that way too as I’ve won auctions where I never had to have a 2nd step to pay for the item - I won the auction, and the amount I bid was charged to my account.
Like I said, this won’t work for stuff you have now that has different sold/purchase dates, but for the future, you could adjust your eBay seller prefs to require instant payment on all items you sell.
For each transaction/item in an order, eBay defines a created and a paid date. Not sure if these fields contain meaningful data that’s different from what’s transmitted on the order level.
We will expose those filed in the next beta through JavaScript.
To clarify the use case, I’m trying to collect enough data to count the number of times a Listing was launched, the very first launch date, and the time at which it ended successfully, in order to calculate a sort of aggregated life history.
We’re able to increment the “original launch date” and “launch counter” (both in a User Property) with the side-effect of a validation script. The missing piece was the final sale date, though I could have very roughly approximated it with the final Listing start date probably.