Next-day orders

When a run ends on the last day of your data, the orders its strategy would place in the next session are its next-day orders. Rearview lists them and writes them to a file for your broker. It never places an order.

Every list and file carries the same warning as the reports: *Hypothetical results, based on hindsight, not actual trading. Orders come from your script and your data. Verify before placing.*

Where the orders come from

A backtest ends with orders it couldn't fill, because the next day isn't in the data yet. Those are the next-day orders:

• The last day's signals: entries and exits as market-on-open, market-on-close, limit or stop orders, as the script says. Entries were ranked and sized on the last close, exactly as on every other day of the run. So are adds and scale-outs, and when the last day is a rebalance day, the rebalance's sells, trims, top-ups and new entries.
• Protective orders of open positions: each position with a stop, trailing stop, partial target or profit target gets a stop or limit order at its level for the next session. A partial target's order is for the share it sells. With a ladder only the next step has an order; the one after follows once it fills.

Same-close orders are not next-day orders. A strategy that fills at the close of the day it signals already filled them in the backtest, at a close you can't trade after the fact. The list shows them as excluded.

Quantities are in the steps the run trades in: whole shares by default, with decimals for steps finer than a share, and for coins. A futures order is in contracts and names the contract the chain holds, such as ESZ2025, and its point value. Rolls aren't next-day orders: when your data rolls a chain you hold, roll it at your broker. An order for a security priced in another currency than US dollars names its currency, and its prices and value are in it; the market totals are left out when the orders on a side are in more than one. Each order is for its security's next session on its own exchange, so after an ASX holiday an ASX order waits a day while a US one doesn't. The quantities come from the backtest's account, not yours. If your account holds other positions or a different amount of cash, they won't fit it: see below.

From your account

Once you trade a strategy, a live account makes the orders from your real positions and cash instead. Each day you import your broker's file. Rearview then replays your fills and lists the next session's orders on the live account's Orders tab, sized from your equity, with sells for the positions you hold. A sell you missed stays on the list, marked with the session it was first due, until you make it. Export works as it does for a run, and the files carry the live account's line in place of the backtest warning.

Runs with no orders

Two kinds of run make none, and say so instead of listing an empty day:

• A run on intraday data (INTRADAY_NO_ORDERS). Its orders are for the next bar, too soon to place from a file.
• A strategy that's flat at close (FLAT_AT_CLOSE_NO_ORDERS), on daily data too. It exits at each session's close, which an order for the next session can't do.

When orders are offered

Orders are only due when the run ended on the data's last day. Rearview compares the run with the data and says which case applies:

Limit and stop prices are rounded to the tick, a cent (a hundredth of a cent below $1) unless the run says otherwise. Stops round away from the market (a sell stop down, a buy stop up), so they never trigger earlier than the strategy's level. Limits round in your favour (a buy limit down, a sell limit up), so they never fill at a worse price.

Each day, update the data ("Keeping your data up to date" in the import guide), run again, then export. With the run's own data, or data updated since that only added days, each order also gets an estimated price: its limit or stop, or else the last close as traded. The estimated value is the quantity times that price. The totals for buying and selling count market orders only, since limit and stop orders may not fill.

In the app

Select a run and open its Orders tab (⌘8). It shows the session the orders are for, each order with its estimated value, the excluded orders, and the totals. Export writes the orders with a built-in template or a template file you choose; Copy as CSV puts the default list on the clipboard.

Under the orders, Candidates at the last close lists every security the strategy could have entered at that close, best ranked first, with the free slots and what became of each: ordered, no free slot, held already and the rest (see The day's choices). The entries in the orders are the ordered ones. To list them for a day before you run, scan the strategy with Run ▸ Scan Candidates: it lists the same candidates. Only a run knows its slots and what it holds, so a scan's places count the stocks it held already, which the run's leave out.

From the command line

rvw orders --run <run folder> --store <store>
rvw orders --run <run folder> --store <store> --template ibkr-basket --out basket.csv

The first prints the list as JSON. The second also writes the file. --template takes default, ibkr-basket or the path of a template file.

Templates

A template is a small text file that says how to write each order. Each line starts with a word:

• header <text>: the line written before the orders, usually column names.
• row <text>: the line written for each order. {field} is replaced by the order's value, written as a CSV field (quoted when it holds a comma or a quote). Text from your script, your data or the run's name (the strategy, ticker, name, reason, contract, currency and run, and maps of them) that starts with =, +, - or @ gets a ' before it, so a spreadsheet shows it rather than running it as a formula.
• map <name> <field> <VALUE>=<text>; <VALUE>=<text>: a new field made by translating another one. Values not listed pass through unchanged.
• section <TYPE> <TYPE>: the header and row that follow apply only to orders of those types (MARKET_OPEN, MARKET_CLOSE, LIMIT, STOP). Each section with orders writes its header, then its rows. With sections, every order type in the list needs one.
• footer <prefix>: the file starts with the prefix and the warning above, such as # Hypothetical results….

Blank lines and lines starting with // are ignored. A field the template doesn't know is an error, and so is an order type without a row, so a template can't silently drop an order.

Fields

Built-in templates

default

// Rearview's own list: one row per order, for reading or a spreadsheet.
footer #
map order type MARKET_OPEN=Market on open; MARKET_CLOSE=Market on close; LIMIT=Limit; STOP=Stop
header session_after,strategy,ticker,name,action,quantity,order,limit,stop,estimated_price,estimated_value,reason
row {after},{strategy},{ticker},{name},{action},{quantity},{order},{limit},{stop},{estimate},{value},{reason}

ibkr-basket

// Interactive Brokers BasketTrader (in TWS: Trade, Basket Trader, then load the file).
// BasketTrader takes no blank field under a header, so each order type has its own header
// row. Its actions are BUY and SELL: a short is a SELL and a cover a BUY. Market-on-open
// orders are MKT with time in force OPG; stops are STP with the stop in AuxPrice.
// There is no comment line, so this file can't carry the footer: check every order.
// Coins, futures and forex pairs are left out, since their BasketTrader fields aren't
// confirmed. Quantities finer than a share are written with their decimals: check one such
// basket in TWS first.
leave out coins
leave out futures
leave out forex
map ib_action action BUY=BUY; SELL=SELL; SHORT=SELL; COVER=BUY
section MARKET_OPEN
header Action,Quantity,Symbol,SecType,Exchange,Currency,TimeInForce,OrderType,BasketTag
row {ib_action},{quantity},{ticker},STK,SMART,{currency},OPG,MKT,{tag}
section MARKET_CLOSE
header Action,Quantity,Symbol,SecType,Exchange,Currency,TimeInForce,OrderType,BasketTag
row {ib_action},{quantity},{ticker},STK,SMART,{currency},DAY,MOC,{tag}
section LIMIT
header Action,Quantity,Symbol,SecType,Exchange,Currency,TimeInForce,OrderType,LmtPrice,BasketTag
row {ib_action},{quantity},{ticker},STK,SMART,{currency},DAY,LMT,{limit},{tag}
section STOP
header Action,Quantity,Symbol,SecType,Exchange,Currency,TimeInForce,OrderType,AuxPrice,BasketTag
row {ib_action},{quantity},{ticker},STK,SMART,{currency},DAY,STP,{stop},{tag}

Interactive Brokers

The ibkr-basket template writes a file for TWS BasketTrader. Before you rely on it, check one basket against your own TWS. In BasketTrader, build a small basket by hand and save it, then compare its columns and values with Rearview's file. In particular:

• BasketTrader's actions are BUY and SELL, so a short is written as SELL and a cover as BUY. Make sure your account treats them as you expect.
• Market-on-open orders are MKT with time in force OPG; stops are STP with the stop price in AuxPrice.
• Tickers are written as your data spells them. Interactive Brokers spells some differently, such as share classes (BRK B, not BRK.B).
• Quantities with decimals are written as they are. Check that a fractional order in your basket is one your account can place.
• Coins, futures and forex pairs are left out, because a basket's fields for them haven't been checked; the export says how many it left out. Place those orders at your exchange or broker. The Currency column takes each order's currency.
• A basket file has no comment line, so it can't carry the warning. Check every order before you transmit it.

Writing your own

Copy a built-in template into a file and change it. For example, a plain list of market orders for a broker that wants B and S:

// Market orders only; any stop or limit order is an error, not a silent omission.
footer #
map side action BUY=B; SELL=S; SHORT=SS; COVER=B
section MARKET_OPEN MARKET_CLOSE
header Side,Symbol,Shares
row {side},{ticker},{quantity}