Description Usage Arguments Details See Also
When an order gets filled, it should have its status moved to 'closed'.
1 2 3 |
portfolio |
text name of the portfolio to associate the order book with |
symbol |
identfier of the instrument to find orders for. The name of any associated price objects (xts prices, usually OHLC) should match these |
timespan |
xts-style character timespan to be the period to find orders of the given status and ordertype |
ordertype |
one of NULL, "market","limit","stoplimit" or "stoptrailing" default NULL |
side |
one of NULL, "long" or "short", default NULL |
qtysign |
one of NULL, -1,0,1 ; could be useful when all qty's are reported as positive numbers and need to be identified other ways, default NULL |
orderset |
set a tag identifying the orderset |
oldstatus |
one of NULL, "open", "closed", "canceled", "revoked", or "replaced", default "open" |
newstatus |
one of "open", "closed", "canceled", "revoked", or "replaced" |
statustimestamp |
timestamp of a status update, will be blank when order is initiated |
When an order is updated with a new order, the order status should change to 'replaced' with a StatusTime that is the same as the one for the new order. This could happen in the case of a traditional Cancel/Replace, because of a trailing stop, or in the case of a partial fill that needs to enter a replaced order for the remainder.
When a risk event or over-limit event happens, typically open orders will be 'revoked'. Possibly new orders will be added to close open positions. Many models will also want to run a process at the close of market that will cancel all open orders.
If orderset is passed to updateOrders, all orders with oldstatus for the orderset will be updated, regardless of their other parameters.
addOrder
getOrders
getOrderBook
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.