I’m finding some inconsistencies/questions as I analyze the profits of my zipline live trades. These may seem like small details, but I’m trying to do a pretty straightforward thing (getting the exact return of each trade) without much success.
last_sale_datefields of the zipline
Positionobject are different from the price/date data revealed when executions are queried with
quantrocket.blotter.download_executions(). This is easy to reproduce if you place a couple trades in a live algorithm, print out the entire
context.portfolioobject, and then compare with the executions query. The difference is small for some trades, and larger for others (e.g. stop orders that trigger later).
last_sale_price does not exactly match the
cost_basis field, even when there’s only been a single opening transaction (as opposed to piecemeal executions).
OrderIdof a stop order execution will sometimes be different than the one originally placed (and returned by
zipline.api.order()). I think this is because IBKR will hold the stop order as ‘pre-submitted’ and then create a separate order when it’s actually given to an exchange to execute. How do you handle this internally in zipline - are the two orderIds linked in a way readable by user?
The reason I ask is because querying executions is the only way I can find to accurately access the execution price of an order. If I want to access the execution price of a stop order, I need to query executions and filter with the orderId that was actually executed (not the one that IBKR discarded).
- I have also tried using
context.blotter.get_transactions(data)to access execution prices from within the algo, but this returns empty lists when the algorithm is live. Is this working as intended?
If there’s an easier way to get the exact return of a trade that was exited via stop order, please do share!