Keyboard Shortcuts
Likes
Search
execDetails(...)+commissionReport(...) Callback different behaviour when not opening trade history
|
Hi all,
i noticed a difference in the behaviour of the execDetails(...)+commissionReport(...) Callback functions. When i start the tws and do not open the "trade history" dialog then all orders that are opened or closed from this point are only "returned" ONCE in the execDetails(...) + commissionReport(...). Furthermore i do not receive the previous trading history ( more precise all executions and commission reports that occured before the new start of tws). If i open the dialog shortly after the start of the tws i receive all the executions and it keeps sending them in a regular time intervall.
?
The reason why i am asking ( or created a topic), is that my trading system gets invalidated if i dont receive all the execution (i cant determined when a position is closed and the is no other way with this design). The problem is that the tws is restarting every day, so i get this set of conditions (after restart -> the dialog hasn't been opened, without intervening) and thus the callbacks are sending only once.?
?
Is it possible that a message is lost ( due to connection problems) ? If so, is there some mechanism to get the dialog open? automatically ? Or how can i enforce it that the callbacks are sending periodically ? How is this solved in the IB Gateway ?
?
regards,
Simon
?
? |
|
I can confirm that TWS 10.30.1p indeed sends unsolicited commission and execution reports upon client connection, if the "Trade History" window is open. But I cannot believe that this is intended behavior and I am not sure which other TWS versions show this behavior. The correct way to get commission and execution reports for recent orders is a call to If your client needs historical execution and commission reports, it should call reqExcutions. The only documented relationship between "Trade History" in TWS and calls is the time period for which trade details are available. The "" chapter says: Important: By default, only those executions occurring since midnight for that particular account will be delivered. If you want to request executions up to last 7 days, TWS's Trade Log setting "Show trades for ..." must be adjusted to your requirement. Please note, that IB Gateway would be unable to change the Trade Log's settings, thus limited to only executions since midnight to be delivered. ´³¨¹°ù²µ±ð²Ô PS. When my client called during startup while TWS had an open Trade History windows, all commission and execution reports as well as were received twice.
?
On Fri, Nov 15, 2024 at 04:37 PM, <simon.meier1987@...> wrote:
|
|
Quick update:
The unsolicited sending of execution and commission reports during a client connects while TWS has the "Trade History" window open was likely a bug in 10.30.1p that now has been fixed in 10.30.1q. ´³¨¹°ù²µ±ð²Ô
?
On Fri, Nov 15, 2024 at 08:24 PM, ´³¨¹°ù²µ±ð²Ô Reinold wrote:
|
|
Hi,
in my application there is already the request for the executions as you hinted and of course i am aware of the time limitation ( it is set to 7 days in my case ). I think there's a misunderstanding here, as i wasn't saying something about some "unsolicited" behaviour.
?
I only need a robust way to determine when a position is closed and i am relying on the execDetails(...) + commisionReport(...) callbacks for that purpose. Unfortunately i am experiencing that not all executions / commissions are sent, maybe so under a certain set of circumstances (the example i gave was, that it depends on whether the "trade history" was opened or not).?
?
1. Are you experiencing the same, by executing m_pClient->reqExecutions(...) (and not opening the trade history). In that case do you receive the completed trading history from execDetails() ?
2. What is the most robust way to determine if a position is closed / opened ? By using the position(..) + positionEnd(...) ? In my case it sends the close again and basically opens the symbol in the other direction. Its very frustrating
?
regards,
Simon |
|
Just to confirm that you are talking about historical tradeReports right after the call to reqExecutions and before the tradeReportEnd clall back. You are not talking about real-time reports right after order fills, right? I can confirm this behavior for when the markets were closed over the weekend, and today at 16:30 US/Central during the CME/CBOT daily trading pause hour (my trade reports were for various futures). But just before 17:00 US/Central on Sunday and today and during trading hours, historical trade reports were delivered right after reqExecutions calls regardless of whether the Trade History window was open or not. This is probably a question for IBKR, but there are other request types with a disclaimer in the documentation that they only work when exchanges are open. But coming back to your other questions. If I understand you correctly, you are trying to create a reliable "position" monitor within your client application. Both getting the an initial correct state when the client starts as well timely updates in real time when your orders fill. For my taste, historical trade reports are not well suited to do that, considering that they generally are only available for the time since midnight (IBGW and TWS default) and only manual configuration of the TWS Trade History windows give you a longer historical view. Also, when you look at the (simplified) data model below, trade reports are pretty far removed from the notion of "Position" and subscriptions that get you updatePortcolio, position, pnl, and order status callbacks give you better data for position monitoring. I did not understand your comment about position updates when you say "By using the position(..) + positionEnd(...) ? In my case it sends the close again and basically opens the symbol in the other direction". You would:
´³¨¹°ù²µ±ð²Ô ? ? On Sun, Nov 17, 2024 at 09:07 AM, <simon.meier1987@...> wrote:
|
|
I do not have the callback functions tradeReports(...) + tradeReportEnd(...) . When i make the request with reqExecutions(...), i receive the information through execDetails(...) and execDetailsEnd(...). How do i receive real-time reports ? Maybe i can use these functions in a java application? I program in c++ and i didn't find these in the documentation page. ?
?
The software behaves like i explained no matter what time. In my case it does not matter if the exchange is open or not.?
?
Exactly. A reliable working "position monitor" is what i need (for stocks and for futures). In my case for a symbol i have several trading rules and each of them manages a certain part of the aggregated position. Sometimes it happens that the statistic that a trading rule "contains" is not valid anymore and then it wants to close its part of the position. So i need the executions, because only then i can assign the closed order to the corresponding rule. As far as i know the position(...)-callback only delivers the aggregated position ( if so, -> not applicable). ?
?
With ---> "By using the position(..) + positionEnd(...) ? In my case it sends the close again and basically opens the symbol in the other direction" <--- I meant that if i do not receive the message that says "there was a execution of selling/buying 60 apple stocks" my system sends the request again, so that (sometimes) there will be another execution that either increments the postion to an unwanted amount (here 120 apple stock) or closes it again that this leads to selling short position. This is a critical error. ?
?
As a side note: i configured the tws in such a way to receive the 7 days of executions and i like to make use of that fact that there is always "enough time" (repeated sending) to complete the position monitor as the callback should send this information repeatedly. ?
But i will have a look at the position(...) and positionEnd(...) callback functions. Maybe they can solve at least a part of my problem
?
regards
Simon |
|
The Trade to Execution (Trade Report) relationship is definitely a "one to many". From the documentation: Note if a correction to an execution is published it will be received as an additional IBApi.EWrapper.execDetails callback with all parameters identical except for the execID in the Execution object. The execID will differ only in the digits after the final period.
As far as I know, Trade to CommissionReport is a "1 to 1" relation. I don't think that there are corrections for those. ´³¨¹°ù²µ±ð²Ô ? On Tue, Nov 19, 2024 at 06:16 AM, Brocksdorff wrote:
|
|
My apologies. I use a (pimped) version of the ApiController class that ships with the TWS API. It implements a "controller pattern" and hides a lot of unnecessary TWS API details from the client. But for some reason for the reqExecutions call, it renamed the execDetails() callback to tradeReport() and execDetailsEnd() to tradeReportEnd(). But their functions are identical. You should reach out to IBKR if your execDetails callbacks indeed only arrive, when the Trade History window is open in TWS. I still think that you need something more than Execution objects to properly implement your rules based trading. Keep in mind that a single order can be filled with multiple trades (causing multiple execDetails() callbacks and multiple Execution objects with different execIds) and that the total traded volume could be different from what your order asked for. Your rules logic needs to properly handle that. But you are correct that the position callbacks only provide you with aggregate quantities. Maybe you need a thin layer that related the rule instructions to the various order and execution events and that avoids the erroneous rule execution tiggered by certain execDetails call backs. You could probably use the orderRef field to tag orders so that you know which rule event it belongs to. orderRef is a string in the Order class that you can define as you like when you place the order, it is returned with all order related callbacks as well as in Execution objects you receive from execDetails callbacks. If the rule, for example, says "sell 120" but that takes place in three trades of 100 + 10 + 10, your logic knows that those three execDetails() callbacks and Execution objects relate to that one rule event. And it also would know in case the actually traded volume is different from what the rule asked for. ´³¨¹°ù²µ±ð²Ô ? On Tue, Nov 19, 2024 at 07:00 AM, <simon.meier1987@...> wrote:
|