In my opinion Gordon's suggestion to build your own Position management is the best approach. We've been using that for almost a couple of decades now and it proves itself. I would recommend relying on order status (filled amount etc.) but I guess execDetails is appropriate as well. We chose to use order status call back as it is the most broker-agnostic approach - so if you one day decide to move to another broker, you can reuse your code.

The Position management is a very simple approach - just an in-memory dictionary of positions that you update on order status change.Just make sure the appropriate semaphores are in place. You may also periodically serialize it to a XML or something file which you can load whenever you restart your software.

On Fri, Dec 6, 2024 at 6:28 PM Gordon Eldest via groups.io <hymagik=yahoo.com@groups.io> wrote:

A "Position" amount could be the aggregated result of multiples orders from multiples strategies. (that is probably your issue)

Seems like you look for a specific "Position" for each strategies on same symbol

This is not a concept that I saw IBKR supporting nor that I see easy to manage from TWS side (TWS handle aggregation of Position)

 

What I do is listen to execDetails to trace how each order did executed (it may execute in slice)

and there you can use orderId to consolidate a "Position" increment/decrement for each strategies. (you can use orderRef too, I use orderId just a safer choice as an index, it avoid mistakes filling custom orderRef that I consider as a "for Human use")

 

execDetails  is pretty powerful, alas transient you have to listen to the call back and store them, and its nearly the only safe method I know to understand what is happening /happened

it work in tandem with completedOrder call back that also report the orderId to better understand your orders completion.

Recommended practice is to crosscheck your execDetails analysis from time to time by fetching your position.

 

If this is just for forensic analysis, take a look at Flex reports, it may allow you to rebuild what happened.

but IMHO I recommend you familiarize yourself with execDetails , you most probably will need it soon.

 

I didn't saw IBRK granulating the API to handle every cases there are too many, but gives all the tools needed to do it yourself.

 

Note:

To better understand why I doubt IBKR will ever handle "sub position" it's interesting to mention the taxes optimization system IBKR offer, that said to avoid looking pedantic.

The underlying mechanism of BUY is more complex than it looks because you become owner of shares (for stocks LONG) that have unique id and this is done at specific purchase dates.

when you SELL, for sake of the example I assume you are LONG, IBKR elegantly does sell starting using the older shares you purchased (you can influence that but default mechanism is tuned for taxes optimization)

This is a hidden level of complexity, that may be to manage as part of your multiple strategies case because as the case maybe, your profit after taxes may depend upon your holding period. (in North America)

So to make your own taxes report matching IBKR taxes report you need to understand that too.

Generally IBKR mechanism improve your work, bad surprise happen mainly when using pyramidal strategies over various period.