Yes indeed, the issue that Juergen touched here would make OrderId's pretty much useless?even if IB kept them because reqCompletedOrders returns indiscriminately, and inescapably, all today's completed orders in TWS, at least for all API clients and if asked properly, all manual orders too. So there would be no way to guarantee unique identification for completed orders using OrderIds anyway. (If there were an intention to maintain some symmetry between different order managing request branches, this call should perhaps have been called reqAllCompletedOrders or reqGlobalCompletedOrders in accord with reqAllOpenOrders or reqGlobalCancel, but apparently there's none such, so we have the most simple name here irrespective of the function it serves, simply because there are no other request methods for completed orders to differentiate).
Depending on your needs, there are a few methods to uniquely identify IBKR orders which are discussed in this group from time to time, so you might check out the search function to get a?grasp of prior art.
пн, 17 февр. 2025?г. в 20:26, 闯ü谤驳别苍 Reinold via <TwsApiOnGroupsIo=[email protected]>:
As @ds-avatar indicated, orderIDs have a limited shelf life. They are only meaningful as long as the order is active and only for the client (as in clientID) that created the order. Keep in mind that each clientID has its own (permanent) sequence of orderIDs, that orderIDs must strictly increase for each new order placed, and that orderIDs might have to be adjusted ("bound") when one client gets in contact with an active order of a different client.
?
That is why each order also has a permID. IBKR assigns it when the order is accepted and returns properly adjusted Order objects with the openOrder() callbacks. That is where you'd get the permID from )or anz other aspect of the order that was changed by IBKR or the exchange)
?
The permID is also used to relate execution and commission reports to an order.