Feature Request: Datetime Fulfilled Column for Market Orders

[alexanderdarino]

For orders that have been fulfilled prior to expiration, I'd love for there to be a column indicating the datetime in which the order was completely (as opposed to partially) fulfilled.

Practical applications: determining recently fulfilled buy/sell orders so you can post a new one for the same item (as opposed to manually going through all the items to see if you have an order already up). I already do this with expired queries ("which orders expired in the past week?"), but it is not presently possible with date fulfilled.

I don't know if the "datetime fulfilled" is available via ESI, but if it isn't the information can be inferred from transactions: the datetime fulfilled is the datetime of the last transaction for that market order. (In the unlikely event it comes up, it is very easy to disambiguate multiple orders for the same item and price point)

[GoldenGnu]

The completed date is not included in ESI.

Calculating the data from the transaction is a can of worms, as each transaction can not be linked to a specific order, so, you have to guess and you won't always guess correctly AKA you can/will end up with wrong data.

I my opinion the best option is to link the completed date to when the order is moved from the active orders endpoint to the history orders endpoints. It not perfect either, it will only be precise'ish if you update regularly. But, it will work well for your use case, as you will be able to see what orders was closed since last update.

Would that work for you?

[alexanderdarino]

IIRC Datetimes are specific down to the second, and no two orders for the same item would have been placed at the exact same time, thus we have a way to disambiguate two orders for the same item, price point, and location.

[GoldenGnu]

The problem is matching each transaction to a specific order. There is no 100% reliable way to figure out what order a transaction was made to/from. You can guess, as I said, but, you can have situations where it's impossible to know. Also, it is a lot of work writing all the code ensuring you're getting right as often as possible. Whereas my suggested solution is a simple change.

[alexanderdarino]

Okay, now that I look at the ESI documentation I see what you mean; I incorrectly assumed certain information was available that is not.

Looking over what is available, this is what I think could be done to be as precise as possible:

1. If there is only one order of a given type (such as "Buy Personal" or "Sell Corporate") for a specific item, price point, and location, then there should be no ambiguity and a precise datetime can be provided because there is literally only one order the transaction could be paired to. (Obviously past terminated and future not-yet-posted-at-the-time orders would be disregarded). This is the most common case, so the vast majority of the time a precise datetime can be provided.

2. Else, ambiguity exists and your recommendation would be "better than nothing". Fortunately this rarely happens in practice - how often do you or anyone else place multiple orders of the same kind for the same item and location at the same price? It happens but it's not terribly common, and power users of jEVEAssets may differentiate the price points by .01ISK just to have a precise datetime made available to them.

Is this feasible? I hope so!

[GoldenGnu]

Yes, I can agree with that. Using the best available data sounds like a good plan. So, feature request accepted. But, without an ETA. It will be done at some point, but, I can not promise when.

[alexanderdarino]

Where do I donate ISK to push this up the list 😂 ?

[alexanderdarino]

You're involved in the CSM, right? Would it make sense to petition to include order_id in the transaction data on ESI?

[GoldenGnu]

Where do I donate ISK to push this up the list

To someone with more free time than me :D

You're involved in the CSM, right

The CSM member is Steve, not me.

Would it make sense to petition to include order_id in the transaction data on ESI?

It turns out there was already a ESI issue for adding order_id. However, it was close, so, after asking in #esi I have re-opened the issue: https://github.com/esi/esi-issues/issues/82