[ts-gen] Handling commissions and fees

R P Herrold herrold at owlriver.com
Tue Sep 15 11:54:47 EDT 2009

On Tue, 15 Sep 2009, Ken Feng wrote:

> Does commissions for trades and periodic fees (exchange, financing,
> etc...) show up anywhere in the trade responses (ShimText) or in the
> journaling tables?
> If not, is there a way to query for them?

Earlier TWS API versions did not, although I know that there 
have been 'vote for features' requests for it

>From a review of the Java sources in later TWS versions, I do 
NOT find it is yet supported in the API levels available to 
the shim (recall that, even if present in the TWS at a given 
API level, it may well not be available to the shim, as some 
parts of later version support is presently blocked [and 
indeed is probably a sub task in] pending version support 
rework and extensions, already on our roadmap)

EClientSocket.java (1400 lines) and EReader.java (750 lines) 
which are in ./java/com/ib/client/ have been mentioned before 
by Bill, and are at the end of the day the most authoritative 
'documentation' I know of

message code 11 (EXECUTION_DATA) of EReader.java seems the 
most likely place for such detail, and I do not see it

Ken -- I saw some expression of difficulty decoding messages 
without a dictionary from us.  Sadly, there is not much 
purpose for maintaining one as a deliverable as it is too fast 
a target, and the IB provided .java sources have much of what 
we know anyway (all we could add is non-authoritative 
secondary source commentary)

Reading EReader.java, and getting acquainted with the varying 
forms over versions a message might take would be time well 
spent -- I see as to EXECUTION_DATA that it has been through 
five versions so far as of today's TWS:
 	1 (implicitly) to start
 	2 adding exec.m_permId
 	3 adding exec.m_clientId
 	4 adding exec.m_liquidation
and is now at
 	5 adding contract.m_conId
and we of course follow form from IB's lead in our naming as 
our past archive has mentioned.

>From a design standpoint, it would be nice to KNOW the IB 
conID that a given execution report related to, in order to 
provide a cross on what was traded, but it also represents a 
denormalization to provide a convenience function by IB of 
what should be discerenble from the data already.

It may well be that Nils' issue on some missing intermediate 
state might become visible if we pushed support for the return 
detail line for
 	message 11, version 5
That string newly adds at offset position 3 (numbering from 1) 
a value for: contract.m_conId

If shim parse support were present (I suspect without looking 
that the shim does not presently support msg 11/v 5 because we 
trail IB's additon of new versions, and IB's push of conID 
values though its code is fairly recent), we would be able to 
match the ShimText logged values against those in his 
database, and to use that data to spot a variance.

We could spot just WHEN [that is at what TWS API version] that 
msg 11/v 5 appeared with a collection of versioned jarballs of 
older TWS and then the jts.jar within each, and diffing 
EReader.java looking for the first appearance -- my archive of 
compressed IB content is over 2.5 G at this point, and it is 
not immediately needful for me to know, or I'd do trawling. 

The IB website, and the TWS release notes tab (sorry -- no 
direct URL as their website is not well suited for producing 
such) is the first place I would look for authoritative 
answers.  Sadly I do not see such as a bullet item (API access 
to Fees / Commissions) called out in the 2009 or 2008 ones -- 
in the 2007 seies, I see that the data is extended for 
availibility to certain order types as a 'Commissions field' 
so the data are communicated to the GUI -- it may not be 
exposed in the API yet, however

I find the work 'Commission' in the Java sources thus:

[herrold at centos-5 client]$ grep Commission *
EReader.java:                   orderState.m_minCommission = readDoubleMax();
EReader.java:                   orderState.m_maxCommission = readDoubleMax();
EWrapperMsgGenerator.java:              + " minCommission=" + Util.DoubleMaxString(orderState.m_minCommission)
EWrapperMsgGenerator.java:              + " maxCommission=" + Util.DoubleMaxString(orderState.m_maxCommission)
OrderState.java:        public double m_minCommission;
OrderState.java:        public double m_maxCommission;
OrderState.java:                        String equityWithLoan, double commission, double minCommission,
OrderState.java:                        double maxCommission, String commissionCurrency, String warningText) {
OrderState.java:                m_minCommission = minCommission;
OrderState.java:                m_maxCommission = maxCommission;
OrderState.java:                m_minCommission != state.m_minCommission ||
OrderState.java:                m_maxCommission != state.m_maxCommission) {
[herrold at centos-5 client]$ pwd
[herrold at centos-5 client]$

in after version 16 on EReader, but these appear to relate to 
setting limits on commissions, rather than obtaining post 
execution such details

One assumes your goal is an allocation capability of the costs 
of entry (one of more execution transactions) and of exit 
(again one or more transactions) in a position.  There are 
also some 'flies in the ointment', as such as figuring out how 
to handle cancellation fees for an order submitted, optionally 
revised, and later cancelled, which never results in a 
position.  This may be something that IB is still trying to 
decide how to communicate

Additionally, we expressly avoid trying to support FA 
(Financial Advisor) complexity in the API within the shim.

Hope this helps

-- Russ herrold

More information about the ts-general mailing list