开云体育

• ERROR 2001 320 Error reading request. Missing parent order: server: 0 order: 2001 parent: 2000 hedge:[P]

• Child must have the same contract as parent order

• The last order in a series of orders with transmit=false must have transmit=true or all orders of the series are held in TWS and are not transmitted to IBKR for processing (as you experience with the transmit button).
• The IBKR APi documentation mentions in a couple places that TWS may need a brief period of time to process parent orders and that "missing parent order" errors may occur. when child orders are placed too quickly. IBKR suggests pacing the first child order by 50ms in these cases, but I would expect error code 10006, not error 320 that you receive.
• How would you place the kind of orders you are looking for manually in TWS? You should be able to model that process via the API.
• You mentioned a couple approaches you tried, but how about , , or for the second order?

Came across this behaviour and find it equally perplexing.

Essentially

- Parent orders cannot have child orders on different contracts
- Hedging orders do not allow you to specify quantity
- It doesn't seem to allow children of children orders (at least not in my tests, i might not have been thorough enough here)

This basically means that if you want to do any kind of custom hedging with different contracts or currencies you have to have an IB server locally to respond to all the incoming order updates, vs. just setting up all of the order trees and just forgetting about it.

Quick follow up, it is possible to have parent, child and grandchild (and so on) orders when submitted via the API.

• Bracket orders are limited to one symbol but they are linked together very closely so that IBKR even adjusts quantities should the entry order fill only partially.
• OCA have the least limitations and you can wrap orders for different instruments, brackets, BUY and SELL orders for the same instrument, ...

You can combine Bracket, OCA, and Hedge orders to model quite complex order constructs that are active r pending within the IBKR system regardless of your TWS/IBGW and client application status.

• The parent order is a limit entry order
• It has three child orders in the bracket: profit taker, stop loss, and an auto position close order for 15 min before market close.
• The profit taker and stop loss orders each are parents for the same construct (profit, loss, auto close)

This was just an example and may not make sense in real trading.

闯ü谤驳别苍

Thanks for the explanation of the different order types and the example.

Building on your example, I've tried to construct a similar tree of orders by linking parent and child limit orders for the same contract using the parentId attribute:

?ib_order = IBLimitOrder(self.action, self.quantity, limit_price_magnified, orderId=ib.client.getReqId(), transmit=transmit, outsideRth=outsideRth, parentId=parentId)

Here's a visual representation of the order tree I aimed for:

sell 100 @ $20

? |___ sell 125 @ $25

?

? |___ buy 75 @ $15?

However, I've encountered an issue. Even though the orders are submitted to TWS and appear as described in the tree, once they are eventually "transmitted" in the UI, all child order quantities get changed to 100 units (the same value as the parent).

Is there a specific setting or option within the TWS or IBKR API that might be causing this change in order quantities? I'm trying to ensure that the child order quantities remain as defined.

------

Semi-unrelated but it seems like another possible limitation in the TWS API is that you can only attach one hedge order per parent order. At least this appears to be the case via the UI, still need to write a proper code based test case for this.

• The order quantity for the high and low side bracket orders matches the original order quantity.

When you place the bracket order, IBKR adjusts quantities for all attached child orders to match the parent order (desired) quantity. Once the parent order starts filling, IBKR automatically adjusts quantities for all child orders to match the actual filled quantity of the parent until the parent order is considered filled (partially or completely) and becomes inactive.

I say "all child orders" since you are not limited just to a profit taker and stop loss order and you can attach additional child orders to the parent in the bracket. One that comes to mind is a "close position at the end of the session" order that sells the position at some point should neither profit nor loss orders have not triggered yet.

Thanks again for the very informative message.

This highlights a couple of points of confusion with the TWS API.

• The API doc describes the order attaching mechanism of bracket and hedge orders. It's implied they are just two order types that happen to make use of the parent-child relationship made available through attaching.
• When an order is marked as a hedge order quantity must be 0. However, as you say a bracket order also should default to 0 since it matches the parent quantity, so specifying the quantity is irrelevant. Yet they do not show any errors or warnings about setting quantity like they do with hedging.

This implies there's a mechanism by which an order can just be "attached" without being a bracket or a hedge order, and without having its quantities automatically modified.

Maybe there's some way to tell the TWS API that an order is not a bracket order but rather an attached order that should simply execute when the parent executes.

Edit: Actually, I originally misread your screenshot, I mistook different prices on each order to be quantities but now see that the quantity on all child orders is the same, 10 units.

That's too bad anyway if that really is the case. Back to building a function that responds appropriately to incoming events.

order.HedgeType = "P";
order.HedgeParam = quantityRatio.ToString("F3", CultureInfo.InvariantCulture);