订单#

“Cerebro” 是 “backtrader” 中的关键控制系统，而 “Strategy”（一个子类）是最终用户的关键控制点。后者需要一种链式方法来连接系统的其他部分，这就是 订单 发挥关键作用的地方。

*订单*将“Strategy”中的逻辑决策转化为适合“Broker”执行操作的消息。这是通过以下方式实现的：

  • 创建

    通过Strategy的方法：`buy`, `sell` 和 `close` (策略)，这些方法将以引用的方式返回一个订单实例

  • 取消

    通过Strategy的方法：`cancel` (策略)，该方法接受一个订单实例进行操作

订单还作为与用户进行交流的一种方式，以通知经纪人的运行情况。

  • 通知

    给Strategy方法：`notify_order` (策略)，该方法报告一个订单实例订单创建

在调用 buy 、 sell 和 close 时，以下参数用于创建订单：

  • data （默认值： None ）

    指定要为哪个数据创建订单。如果为 None ，则使用系统中的第一个数据，即 self.datas[0] or self.data0 （也就是 self.data ）

  • size （默认值： None ）

    指定要使用的单位数据的大小（正数）。

    如果为 None ，则会使用通过 getsizer 获取的 sizer 实例来确定大小。

  • price （默认值： None ）

    指定要使用的价格（如果格式不符合最小交易单位的要求，则实时经纪商可能会对其进行限制）。

    Market 和 Close 订单可以为 None （市场来决定价格）。对于“Limit”，“Stop”和“StopLimit”订单，这个值确定触发点（在“Limit”订单的情况下，触发点显然是订单应匹配的价格）。

  • “plimit”（默认值：“None”）

    只适用于“StopLimit”订单。这是在触发“Stop”（使用“price”）之后设置隐式“Limit”订单的价格。

  • “exectype”（默认值：“None”）

    可能的值：

    • “Order.Market”或“None”。市价订单将以下一个可用价格执行。在回测中，它将是下一个柱的开盘价。

    • “Order.Limit”。只能以给定的价格或更好的价格执行的订单

    • “Order.Stop”。在“price”处触发的订单，像“Order.Market”订单一样执行

    • “Order.StopLimit”。在“price”处触发的订单，并作为隐式“Limit”订单执行，价格由“pricelimit”给出

  • “valid”（默认值：“None”）可能的取值：

  • None ：这将生成一个不会过期的订单（也称为“直到取消”），并且将一直保持在市场上直到匹配或取消。实际上，券商往往会设置一个时间限制，但通常时间距离较长，可以视作不会过期。

  • datetime.datetime 或 datetime.date 实例：将使用该日期生成一个订单，直到给定的日期时间有效（也称为“直到指定日期”）。

  • Order.DAY 或 0 或 timedelta() ：将生成一个到 会话结束 （也称为*日内*订单）为止的当日有效订单。

  • 数字值 ：假设它是对应于 matplotlib 编码中的日期时间值（ backtrader 中使用的编码），并将用于生成一个直到该时间为止的订单（ 直到指定日期 ）。

  • tradeid （默认值： 0 ）

    这是 backtrader 内部应用的值，用于跟踪同一资产上的重叠交易。当订单状态发生变化时，此 tradeid 将发送回*策略*。

  • **kwargs ：其他经纪人实现可能支持额外的参数。 backtrader 将把 kwargs 传递给创建的订单对象。

    例如：如果 backtrader 直接支持的4种订单执行类型不足够，在例如 Interactive Brokers 的情况下，可以将以下内容作为 kwargs 传递：

    orderType=’LIT’, lmtPrice=10.0, auxPrice=9.8订单通知

为了接收通知，必须在用户子类的“策略”中覆盖“notify_order”方法（默认行为是不进行任何操作）。以下内容适用于这些通知：

  • 在调用策略的“next”方法之前发出

  • 可能（并且将）在同一“next”周期内针对相同的 order 发生多次，可以具有相同或不同的状态。

    order 可能已提交给 broker 并已在“next”再次调用之前完成执行。

    在这种情况下，至少会有3个通知，具有以下“status”值：

    • “Order.Submitted”表示订单已发送给 broker

    • “Order.Accepted”表示订单已被 broker 接受并等待可能的执行- “Order.Completed” 是因为在示例中它被快速匹配并完全填满（这可能通常是“市场”订单的情况）

  • 在“Order.Partial”情况下，通知可能会发生多次，即使是对于相同的状态。在*回测*模拟器中，这个状态不会被看到（因为它不考虑成交量），但是在真实的交易所中，它肯定会被设置。

  • 在更新持仓之前，真实的交易所可能发布一个或多个执行记录，这个执行记录将组成一个“Order.Partial”通知。

  • 实际的执行数据存储在属性“order.executed”中，它是一个“OrderData”类型的对象（请参阅下面的参考资料），具有如“size”和“price”等常规字段。

  • 创建时的值存储在“order.created”中，在“order”生命周期中保持不变。

订单状态值#

定义了以下状态：

  • “Order.Created”：在创建“Order”实例时设置。除非手动创建“order”实例，而不是通过“buy”，“sell”和“close”，否则不会被最终用户看到。

  • “Order.Submitted”：在“order”实例已传输到“broker”时设置。这只是意味着它已经被“发送”了。在“回测”模式下，这将是一个立即执行的操作，但对于真实的经纪人来说，可能需要实际的“时间”，因为它可能仅在将订单转发到交易所后才通知。

  • “Order.Accepted”：经纪人已接受订单，并且该订单已经进入系统（或已经在交易所中），等待根据设置的参数执行，如执行类型、大小、价格和有效性。- Order.Partial : 订单已部分执行。 order.executed 包含当前成交的 size 和平均价格。

    order.executed.exbits 包含了一个完整的 ExecutionBits 列表，详细记录了部分成交的情况。

  • Order.Complete : 订单已完全执行，平均价格。

  • Order.Rejected : 经纪人拒绝了订单。经纪人可能不接受某个参数（例如 valid 来确定订单的有效期），因此无法接受该订单。

    拒绝的原因将通过 strategy 的`notify_store 方法通知。尽管这看起来有些奇怪，但原因在于实际中的经纪人会通过事件通知，该事件可能与订单直接相关也可能不直接相关。但经纪人的通知仍然可以在 notify_store`中看到。

    这个状态在*回测*经纪人中不会出现。

  • Order.Margin : 订单执行将导致保证金调用，并且之前接受的订单已从系统中删除。

  • Order.Cancelled （或 Order.Canceled ）: 用户请求取消的确认。

    必须注意，通过策略的 cancel 方法请求*取消*订单并不能保证取消成功。订单可能已经执行，但该执行可能尚未由经纪人通知，或者通知尚未传递给策略。

  • Order.Expired : 之前接受的具有时效性的*订单*已过期并已从系统中删除。参考资料：订单和关联类

这些对象是 backtrader 生态系统中的通用类。它们可以被扩展和/或在与其他经纪人进行操作时包含额外的嵌入信息。请参阅适当经纪人的参考文档。