DAS Orders, Fills and Protective Orders Are Separate States
Reason about acknowledgements, partial fills and linked orders.
Follow the external evidence
A script can request an action; the broker and platform determine subsequent states. Treat these as separate checkpoints: request created, acknowledgement observed, filled quantity observed, and any protective order observed. A local success message does not establish all four.
Walk through a partial fill
Suppose a fictional simulator order requests 120 shares and the reported filled quantity is 45. There are 75 shares remaining on that order. This arithmetic does not establish the total account position: earlier positions or other orders may exist.
| Observation | What it proves | What it does not prove |
|---|---|---|
| Ticket populated | Intended fields loaded | Submission |
| Accepted order record | Request accepted | Full fill |
| Filled quantity = 45 | That execution quantity reported | No other exposure |
| Cancel requested | A cancellation was requested | Remaining quantity is canceled |
| Child order visible | A follow-up exists | Correct quantity, linkage or acceptance |
Trigger and OCO relationships
DAS documents Trigger Orders as secondary orders sent following execution of a primary order. Its wizard assembles the secondary portion and then the primary portion. Consult the applicable trigger documentation for full-fill requirements and verify partial fills explicitly in your build.
OCO relates two orders through cancellation behavior. A pair of independent orders is not automatically an OCO pair. Verify the relationship and broker acknowledgement; do not infer protection from two lines of script.
Lab: write an observation log
For a simulator test, collect order identifiers, requested/filled/remaining quantities, acknowledgements and timestamps. Cover partial fill, rejection, cancel pending and missing secondary order. State the observation that would make you stop for manual review. This is a lifecycle test design, not an executable order recipe.
Read WithTrigger field by field
The official Trigger Order Guide documents WithTrigger and describes the secondary order triggering after the primary is fully executed. These hypothetical prices illustrate the structure. Reading only: every command is commented, with no submission path. Verify any real template against the target build, simulator account and route.
// ROUTE=LIMIT;
// Price=195;
// Share=30;
// TIF=DAY+;
// WithTrigger=RT:LIMIT PX:200 ACT:SELL QTY:POS TIF:DAY+;
// BUY=Send;
| Field | Role in this structure |
|---|---|
| First four lines | Primary route, price, quantity and TIF |
RT:LIMIT |
Secondary route |
PX:200 |
Secondary price |
ACT:SELL |
Secondary side |
QTY:POS |
Position-based quantity, not fixed primary Share |
Secondary TIF:DAY+ |
The secondary's own TIF |
BUY=Send |
Submission of the primary with the attached relationship |
Secondary subfields use colons; primary assignments use equals signs. Account and symbol still depend on Montage context. This reads one documented example rather than deriving a universal grammar for every order type. Do not substitute the word TriggerOrder from a concept or another template merely because it sounds similar.
POS and partial-fill quantity traps
Suppose there are already 20 shares and the primary requests another 30. QTY:POS is not the literal 30; it involves position semantics at trigger time. Test zero and nonzero initial positions separately, then inspect secondary existence on partial fill and its quantity on full fill. A written WithTrigger clause does not establish coverage while the primary remains partially filled.
Create and verify an OCO relationship
Official UI paths include selecting the OCO linkage checkbox in Montage OCO style, or selecting existing orders in Orders and choosing Create OCO. Entering two tickets without establishing linkage may leave independent orders. The Hotkey Wizard's Order Cancel Order category generates its template; this lesson does not invent unchecked OCO fields.
Record both order identities, linkage evidence, the event on one side, and cancellation acknowledgement on the other. Fills can race a cancellation request. The OCO label cannot replace acceptance and final-state checks.
Worked answer
For 120 requested and 45 filled, the arithmetic unfilled portion is 75. Do not set it to zero merely because cancellation was requested; update classifications from the corresponding terminal evidence. On rejection, identify the specific rejected request before choosing a next step rather than replaying a whole script containing primary submission.