API Support Forum
OEC API > API Support > Order rejected: Invalid tick size
Author Topic: Order rejected: Invalid tick size
(2 messages, Page 1 of 1)
Moderators: VPfau
CWeber984
Posts: 226
Joined: Apr 24, 2012


Posted: Sep 10, 2012 @ 07:51 PM             Msg. 1 of 2
Within OEC Trader Demo
- incrementing OESU2 C1435 LIMIT 12.50 GTC order to 12.55
- using the up/down control
- produces a rejected order and invalid tick size error
- where 12.50 was the initial value given in the limit edit box.
- (E-Mini S&P September '12 Option)

Using the api, we obtain the tick size for an options symbol:
- OECAPICOM::IContractPtr con = OECAPI()->Contracts->Item((LPCSTR)sym);
- double dMinMove = con->TickSize;
- where sym = "OES"
- returns .05.
- the same value as the amount by which the Trader demo increments/decrements the limit price.

However, by documentation for OES at:
http://www.openecry.com/trading/specifications.cfm?CurrentAssetType=Options&ViewBy=MarketGroup

The tick size for OES is .25.

By CME documentation for OES at:
http://www.cmegroup.com/trading/equity-index/us-index/e-mini-sandp500_contractSpecs_options.html

The tick size for OES is:
*.25 if > $5.00
*.05 if <= $5.00

We would like to prevent rejection of new/modified options orders
- that are incrementing/decrementing their limit price
- based on the return value from con->TickSize;

Do you have any suggestions?

We are considering hard-coding for these symbols that have different tick sizes based on their current edited limit price.
- con->TickSize only has one of, not all the tick sizes for these symbols
- OAUD, OCAD, OJPY, OEN, OES, OLE
- these symbols all produce invalid tick size rejections in the Trader Demo using the up/down control
- there are other options that have multiple tick sizes as well, but we have not fully tested them yet

Is there a better solution?

Thanks for your assistance,


CHW
Edited by CWeber984 on Sep 10, 2012 at 19:53:13
VictorV
Posts: 746
Joined: May 08, 2007


Posted: Sep 18, 2012 @ 03:17 PM             Msg. 2 of 2
Unfortunately, we have no better solution for this problem right now.

Victor Vins
Lead Software Developer