Author Message
TriPack
Unregistered guest
Posted on Friday, June 07, 2002 - 11:16 am:
----------------------------------------------------------------------
----------
I agree alanm, and am glad you spoke out in favor of the transaction
history. I would like to see it too. It personally makes more sense
to me to provide a actual fills prices rather than an average price
history. It takes the rounding problems out of mix.
alanm
Unregistered guest
Posted on Thursday, June 06, 2002 - 11:40 pm:
----------------------------------------------------------------------
----------
Why not report the actual fill prices instead, since these will be
exactly correct, instead of having to extrapolate it from the
average?
TriPack
Unregistered guest
Posted on Thursday, June 06, 2002 - 10:45 am:
----------------------------------------------------------------------
----------
It appears that this request takes the form of a request for a bug
fix. We need the precision improved for the average prices reported
via the orderstatus event (and other events that report average fill
prices). Regardless of whether a full transaction history is
provided, the average price precision needs to be improved from two
rounded decimal places so that we can calculate fill prices
accurately.
Bart Gelens
Unregistered guest
Posted on Wednesday, June 05, 2002 - 12:56 pm:
----------------------------------------------------------------------
----------
Problem: Twice a "filled order" confirmation with different average
prices?
I am using the TWS stand alone version (build 765) (ActiveX API).
Sometimes, when I place an order like Id=10382 NQM2 BUY 1 4818.50
LIMIT
I get 2 OrderStatus events:
OnOrderStatus: Id=10382 Status=Filled Filled=1 Remain=0 price=4818.50
OnOrderStatus: Id=10382 Status=Filled Filled=1 Remain=0 price=9635.00
The first (average) price is exactly the same as the requested price.
The second price is multiplied by (almost) 2!
This only happens while using the official account. If I log in as
cdemo user, it seems to be working fine. Did anyone have a similar
experience?
Regards,
Bart.
TriPack
Unregistered guest
Posted on Wednesday, June 05, 2002 - 10:41 am:
----------------------------------------------------------------------
----------
"The API is always reporting the average price. "
Marcus, thanks for the clarification in your post. Well that is good
to know. I can make up a formula to account for the averages. My
original impression was that only the last fill reported was an
average. I should be able to solve for rounding (at least in my case
with the EMINIs) because they have a set .25 or .5 tick price for ES
and NQ. Stocks will be more difficult because of the one cent and sub-
one cent prices (in some cases).
Yes, giving us an unrounded average would make it easier. Giving us
full transaction history would also do the trick.
Marcus Jellinghaus
Unregistered guest
Posted on Wednesday, June 05, 2002 - 09:58 am:
----------------------------------------------------------------------
----------
The API is always reporting the average price. The advantage of that
is, that we do not have to calculate the average price, the
disadvantage is, that we have to calculate the part fills. Of course,
the API could return the values the other way round or both.
I think since we program anyway, the calculation of the part filles
shouldn?t be a big problem.
From my calculations, the price of the second part fill should be
((20*1043.44)-(15*1043.5))/5 = 10.26.
You are right with the rounding errors. But the API users can
calculate exactly, the problem is that the API gives rounded numbers
which leads to wrong prices:
Yesterday I bought 600 stocks in 3 part-fills:
100 x 5.9200 Average Price: 5.92
286 x 5.9160 Average Price: 5.917036
214 x 5.9200 Average Price: 5.918141
I have the first 2 numbers from the account statement and calculated
from that the average price. The API always returned 5.92 as average
price, which is rounded. If the API would give the correct number, we
could calculate correct partfills.
So the partfill prices may be wrong in the area smaller a cent.
The fill prices are also sometimes different because IB rounds the
turnover to full cents and so charges other prices than the tick was
at the exchange. But I guess the reason is that most exchanges also
round the turnover to full cents.
TriPack
Unregistered guest
Posted on Tuesday, June 04, 2002 - 03:40 pm:
----------------------------------------------------------------------
----------
Let me use an acutal example from my debug window. I place a limit
order to sell 20 ES @ 1043.25 Limit and the following is my initial
feedback.
Tws1_orderStatus 224 PendingSubmit 15 5 1043.5
Tws1_orderStatus 224 Submitted 15 5 1043.5
Tws1_orderStatus 224 Filled 20 0 1043.44
So from this I *infer* (are fills reported on "PendingSubmit"
and "Submit" events reliable?) that the first lot of 15 was filled at
1043.5 but we have to deduce that the 2nd lot of 5 was filled at
1043.25. Is it just me or is it strange that we have to either
mathematically figure or use some other method to get the last fill
price when you have a partial fill? In this case you can infer that
it was filled at 1043.25 on the last 5 cars because of the limit
price. In other cases it isn't so clear cut. When mathematically
figuring, we have to deal with the rounding errors.
I request executions, and after a delay of about 20 seconds I get the
following information:
Tws1_openOrder1 225 ES FUT 200206 0 ? GLOBEX USD
Tws1_openOrder2 225 SELL 15 LMT 1043.25 0 DAY F92 O 2
Tws1_orderStatus 225 Filled 15 0 1043.5
Tws1_openOrder1 226 ES FUT 200206 0 ? GLOBEX USD
Tws1_openOrder2 226 SELL 5 LMT 1043.25 0 DAY F92 O 2
Tws1_orderStatus 226 Filled 5 0 1043.44
Why isn't the price on the 5 contract fill reported as 1043.25
instead of reporting the average price for the whole lot? This seems
like a bug to me. If it was intentionally programmed this way then
perhaps it needs to be rethought because it makes it unnecessarily
difficult to compare the fills listed in the TWS vs the ones reported
via the TWS API. Also, why does it take so long for the execution
report to come out? I'm not really asking for new features, just
wondering why the current reporting mechanism makes no sense. Why
don't they just give us our transaction history? It seems to me that
people who are using this successfully now must have done something
to compensate for the fact that the API is giving average price
instead of just reporting each fill.
Marcus Jellinghaus
Unregistered guest
Posted on Tuesday, June 04, 2002 - 01:54 pm:
----------------------------------------------------------------------
----------
I do not really get your point. To take your example, I first get an
orderstatus event where 30 are filled and 70 are remaining. So it is
easy to see that it is just part fill. I also know the filled price.
After that I get a second orderstatus event which says 100 filled, 0
remaining. So I know that the order is filled, I know average price,
from that and the first part fill I know the data of the second part
fill etc.
I would prefer it if IB would solve the existing problems with the
API rather than adding new functionality, which is not really
necessary.
Best regards,
Marcus
TriPack
Unregistered guest
Posted on Tuesday, June 04, 2002 - 11:15 am:
----------------------------------------------------------------------
----------
I like the TWS API a lot. It works well for all but partial fills,
which become a pain to manage. It would be nice to push a PartialFill
status update through the "orderstatus" event. I'm using the TWS Ax
OCX.
Probably the best way to implement this would be to have the
PartialFill status in the orderstatus event fire off whenever there
is either a partial or full fill. For example if you put in an order
for 100 shares and are filled on 30 then 70, you would receive two
orderstatus events with the PartialFill for 30 filled with 70
remaining and then 70 filled with 0 remaining. This would leave the
Filled status unchanged - it would continue to just report when the
full position has filled. If you put in an order for 100 shares and
it was filled all at once, you would receive both the PartialFill
event for 100 shares filled 0 outstanding and the same event for
Filled shares (so as not to mess up legacy systems that other
programmers have implemented).
