canceled

CTP：各种错误的测试（补充和修改中）

⼀直想总结⼀下,CTP对各种错误的反馈和机制，由各种原因，总没完成。现开个头，希望慢慢总结，不断测试，不断整理。

⼀、CTP的报单流程

根据CTP的介绍，CTP的报单流程如下：

CTP终端报单指令（ReqOrderInrt）报⼊CTP后台，⾸先要经过数据同步状态、会话、报单字段、合约、经纪公司、投资者、是否

确认结算单、交易权限、持仓资⾦检查和冻结、只能平仓权限检查及交易所会话检查等，CTP报单检查失败则通过OnRspOrderInrt返回

报单错误（CTP打回的错单），根据CTP介绍，OnRspOrderInrt属于对话通讯模式，即普通的客户/服务器模式，也就是说服务器只会

将此类返回信息发送给对应的客户会话，通讯故障发⽣时，此类数据流也存在丢失的可能。

通过报单检查的报单指令（ReqOrderInrt），CTP后台会向客户端返回OnRtnOrder消息，其中OrderSubmitStatus为“已经提

交”，OrderStatus为“未知”。同时CTP后台将该报单指令转发⾄对应的交易所系统。交易所系统同样会对报单进⾏相应的检查，如价格

是否超出涨跌停板、报单指令是否试⽤等等，未通过交易所系统检查的报单，CTP收到交易所系统响应后也会向客户端返回OnRtnOrder消

息，其中OrderSubmitStatus为“报单已经被拒绝”，OrderStatus为“撤单”。

通过交易所系统检查的报单，交易所系统会将对应的报单插⼊报单薄，并通知CTP后台，CTP收到交易所系统响应后也会向客户端返回

OnRtnOrder消息，其OrderSubmitStatus为“已经接受”，OrderStatus为“未成交还在队列中”。

当成交发⽣后（全部成交或部分成交），CTP后台将向客户端返回OnRtnTrade消息，同时也会返回OnRtnOrder消息，其中

OrderSubmitStatus为“已经接受”，OrderStatus为“全部成交”或“部分成交还在队列中”。

⼆、CTP对错误的反馈机制的特点

我个⼈看，客户端报单要经过三个层次流程，来对报单进⾏判断。（1）CTP表层判断->（2）CTP深层判断->（3）交易所层次判断.

按正常理解，Rsp只作表层判断,Err进⾏深层判断。但CTP有些并⾮如此。有些感觉应从Rsp或Err类型的返回的错误，它却从Order层

次的状态的变化来表达，⽽这种“告诉”往往让你感觉有点奇怪，或摸不着头脑。也许CTP有其不得⾔的苦衷吧。

三、CTP和错误反馈机制相关的主要回调函数：

1、OnRspOrderInrt：报单录⼊回调，CTP表层判断即报单参数基本的校验，如校验不通过，会收到回调信息。

（1）典型错误：报单引⽤是否⾃增

（2）典型错误：报单引⽤是否重复

（3）典型错误：报单数量错误，如报卖量不⾜。有“平仓量超过持仓量”等。

具体信息会在sg中给出详细的描述。

2、OnErrOrderInrt：报单录⼊错误回调。

3、OnRtnOrder：报单回调。进⾏CTP深层判断和交易所层次判断.

需要说明的是，在这个回调函数中，事实上，只有报单状态的变化信息，没有错误信息。

（1）典型错误：⾮交易时段报单录⼊。

Inrt阶段告知成功，但CTP会对这种报单进⾏⾃动撤单，我个⼈认为，这个单根本就没有进⼊交易所层次。还是在CTP层次被拦截

了。

（2）典型错误：报单的价格超过涨停价或跌停价。

本来应在OnRspOrderInrt反应，但CTP并⾮如此。CTP认为，它不进⾏涨跌停价的判断，这个由交易所层次来进⾏识别。但与此同

时，CTP,在OnRtnOrder中，把交易所的传回来的错误反馈在OnRtnOrder中以报单的状态（有⼆个状态，见下说明）进⾏调整来表达，

但并不传出相应的错误。此时，TFtdcOrderSubmitStatusType的状态为InrtRejected，EnumOrderStatusType的状态为

Canceled。

关于Order中的状态，主要有⼆个枚举类型，需要我们关注其中可能隐含的错误信息。

（1）关于报单状态：TFtdcOrderStatusType

publicenumEnumOrderStatusType

{

AllTraded=48,//全部成交。--->最终状态

PartTradedQueueing=49,//部分成交，且还在队列中。说明，部分成交，部分在等待成交。

PartTradedNotQueueing=50,//部分成交，不在队列中，说明：部成部撤。--->最终状态。

NoTradeQueueing=51,//未成交，在交易队列中。说明：报单在市场中，但没有成交

NoTradeNotQueueing=52,//没有交易且不在队列中，说明：报单被CTP拒绝。--->最终状态

Canceled=53,//报单被取消--->最终状态

Unknown=97,//未知。说明：报单已经被CTP接收，但还没发往交易所。

NotTouched=98,//预埋单未触发

Touched=99,//预埋单已触发

}

需要注意的是，上⾯有四种报单状态是最终状态(即这种状态不会发⽣变化)，其中，NoTradeNotQueueing是⽐较特别，我们不常见。

（2）关于提交状态：TFtdcOrderSubmitStatusType

publicenumEnumOrderSubmitStatusType

{

InrtSubmitted=48,//报单已提交

CancelSubmitted=49,//撤单已提交

ModifySubmitted=50,//报价修改单已提交

Accepted=51,//已收

InrtRejected=52,//报单录⼊拒绝

CancelRejected=53,//撤单拒绝

ModifyRejected=54,//报价修改单已拒绝

}

这个是针对不同类型的报单（⼀般报单，撤单，改价单）的⼏种状态，要么是被提交，要么被接收，要不就是被拒绝三种情况。

资料引⽤：见综合交易平台API开发FAQ⽂档。

39.如果发送⼀个报单委托价格在停板之外。按道理如果CTP校验失败，那么应该从OnRspOrderInrt返回错误；如果是交易所校

验失败，那么应该从OnErrRtnOrder来返

回错误。现在情况是这两个地⽅都不返回错误，⽽是从OnRtnOrder返回。然⽽OnRtnOrder却没有错误代码，仅是状态改变，没法

捕捉异常。其实⽤户报单后，如果正确根本不会“马上收到报单响应OnRspOrderInrt”，只有报单被CTP拒绝才会收到。

答：超出涨跌停板的判断是在交易所处理，所以，CTP收到报单就新增⼀条记录，然后收到交易所的OnErrRtnOrder后，修改委托表

⾥的记录，触发OnRtnOrder。OnErrRtnOrder的作⽤是：CTP在检查委托发现错误时，会给发出委托的投资者发出

OnRspInrtOrder，同时发出OnErrRtnOrder给相关的交易员，所以，作为投资者可以不关⼼OnErrRtnOrder。

4、OnRspOrderAction：撤单回调

（1）

5、OnErrRtnOrderAction：报单错误回调，听说⽤到很少。

从实际操作上看，onRspInrt和OnRtnOrder最需关注的⼆个回调函数。绝⼤多数错误在这⾥⾯来进⾏表达。

以上是个⼈看法，还需待证实。