开云体育

When I ask TWS API for a list of the orders that I have placed recently, I get back a number of attributes of each order (PermId, Action, LmtPrice, etc.)

https://interactivebrokers.github.io/tws-api/classIBApi_1_1Order.html

However, the order placement time does not appear to be here, which seems odd. Am I correct in thinking that TWS API is not able to tell me the time at which I placed orders, and thus it is up to me to keep track of those times? Or am I missing something? It seems odd that time of order placement would not be among the order attributes that TWS API reports to me.

I guess when you think about it, “time of order placement” is not really an Order attribute, so I would not expect to find such a field in the Order class. Just like “time of order execution” is not an Order? attribute but that of one or more Executions. Consequently, order execution times are recorded and reported in Execution objects.

TWS API has no equivalent to Execution for order placement and I am not sure that there needs to be one. Your client application can easily record the time of order placement, either when it makes the placeOrder request or, probably more appropriately, when it receives the first OrderState/OrderStatus update callbacks from TWS/IBGW. That way you can also record order placement times for orders placed through TWS or other means.

That way, you could also record other order related events such as when orders actually become active (like child orders in brackets or conditional orders), when orders change (such as trailing price orders), or when any other relevant order state changes take place.

You may be able to get Order Time from FlexQueries, but I have not tried this and the approach resembles more batch processing than a quick request/response call.

And finally, you could use the OrderRef string field, to tag your order with any custom information and in any format you’d prefer. I know that some of our members tag their orders with comprehensive context information, and order placement time could be one those context items. This approach has the advantage that your custom OrderRef string is reported back to your client application by any and all TWS API callbacks that have an Order parameter.

闯ü谤驳别苍

?

Thanks very much for this information. That makes sense. I just wanted to be sure I was not missing something.

It appears that the total number of shares of the order is missing also? There is "TotalQuantity", but that appears to be the shares remaining to be filled, rather than the total requested, and it drops to zero if the order is cancelled, such that one cannot recover the original number of shares requested from the information provided. I guess I need to keep track of all such quantities myself, but please let me know if my understanding of "TotalQuantity" is not correct. Thanks again very much for your help.

You are correct. A better name for the Order quantity field would probably be "current quantity" or "remaining quantity". IBKR automatically decrements the field value after each partial fill. Or in case of child orders in a Bracket Order, IBKR will automatically sets quantities for all child orders to the actual fill quantity of the parent . And your client application can adjust the value at any point in time, too (up or down).

If you need the original order quantity for orders at time of placement, you need to persist that information within the scope of your client application. Or if you want to avoid having to save state, you can use the OrderRef field as I had pointed out before. It is perfectly fine if you define a few context fields, encode them, for example, as a Json string, and store that string in the OrderRef field of the order. The OrderRef field description is best summarized in the Execution class as:

• The OrderRef is a user-customizable string that can be set from the API or TWS and will be associated with an order for its lifetime

For the special case where your client applications do not change the order quantity after order placement, you can reconstruct the original order quantity from the orderStatus() callback. Each time you receive an orderStatus() update, it provides the actual "filled" and "remaining" quantities at that point in time.

闯ü谤驳别苍

?

?