Announcement

Collapse

Looking for a User App or Add-On built by the NinjaTrader community?

Visit NinjaTrader EcoSystem and our free User App Share!

Have a question for the NinjaScript developer community? Open a new thread in our NinjaScript File Sharing Discussion Forum!
See more
See less

Partner 728x90

Collapse

Can I check whether OCO string is reused?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Can I check whether OCO string is reused?

    Hello.

    1.
    Is there a way to check whether OCO string is reused?
    Or the Dictionary<string, bool> that filled in OnExecutionUpdate() is one only way?

    2.
    When OCO string become reused?
    Does it happened after one of orders became Filled or OverFilled?

    3.
    Say, I have a working order. It was submitted 100 bars ago, partial filled 50 bars ago.
    May I read it OCO string and submit another order in this bracket?

    4.
    Strategy have 100 contracts position and 2 OCO Unmanaged protective orders ("stop loss" and "take profit") on InteractiveBrokers account.
    Than connection lost.
    Than "take profit" partial filled with 30 contracts.
    Than "stop loss" partial filled with 70 contracts.

    What will remain on account?
    Position will be flat, but what about orders?
    Does IB automatically adjust OCO brackets quantity?
    And what if "stop loss" and "take profit" initially had different quantity?

    Thank you.
    fx.practic
    NinjaTrader Ecosystem Vendor - fx.practic

    #2
    Hello fx.practic,

    Thanks for your post.

    RE 1: Order objects have an OCO string property that tells you the OCO ID associated with the order. I would however suggest focusing your approach to create a unique OCO ID whenever you need to submit both orders for the OCO pair. I.E. a bracketed entry or target/stop. This would ensure that a unique ID is generated for each instance an OCO pair is needed.

    RE 2: OCO ID's generally become invalid when the order starts to fill. Taking the approach above will avoid situations like this because you are creating a unique ID whenever a pair needs to be submitted, and then you can generate a new unique ID for any future pairs. Some brokers like TDA will require submitting an OCO pair at the same time and will not allow you to submit an order at a later time.

    RE 3: I would not expect the OCO to be valid because it is already filling. You could consider taking an approach to logically check some conditions, cancel the existing order/orders, and then to submit new orders in OnOrderUpdate when you see the cancellation come back.

    RE 4: The stop and target should be fully cancelled at this point because they are OCO'd and their quantities should be reduced by their fills.

    As a tip with Interactive Brokers, you can use a paper trading account to observe their specific dynamics with OCO handling.

    As another tip, Order events and Execution events may come in a different order than 1. Order update 2. Execution update 3. Position update where Execution updates may be seen first. I have attached a Managed Approach strategy that handles OnExecutionUpdate related events in a private method triggered from OnPositionUpdate. This could be used to help guarantee ExecutionUpdate related events happen after OrderUpdate events. The technique can be adopted for Unmanaged Approach as well.

    Let us know if you have any questions.
    Attached Files
    JimNinjaTrader Customer Service

    Comment


      #3
      Great example, thank you, Jim.

      In general case order needs multiple tick to be completely filled.
      Ever more:

      Say, entry long orders with quantity 100 submitted.
      It was filled with quantity 40.
      Then price reversed and touch stop loss order; and filled stop loss with 20 contracts.
      At this time connection interrupted.
      And then price falls down forever.

      What is the best way to submit unmanaged OCO protective orders to be prepared for this situation?

      At the moment, the strategy doesn't use OCO.
      Once entry order partially filled the first time, the strategy submits Sl and Tp.
      After each next execution, the strategy submitting ChangerOrders() to make Sl and Tp quantity same to Position quantity.
      This is reliable while connection established.

      But connection may be interrupted. That's why I thinking about server-side OCO.

      But what is the best way to submit them?
      Can use the same algorithm with OCO-bracket? I mean, can strategy multiple times change quantity for OCO paired orders?
      Last edited by fx.practic; 01-20-2020, 03:45 PM.
      fx.practic
      NinjaTrader Ecosystem Vendor - fx.practic

      Comment


        #4
        Hello fx.practic,

        It would be best to submit OCO protective orders based on the quantity of the entry order's quantity. When the order is filling, the OCO orders for target and stop would be updated with ChangeOrder to reflect the new quantity. I have responded to your other thread with an example that is based on our SampleOnOrderUpdate strategy. I'll link this thread for the forum's reference.

        Hello. Unmanaged approach. Say, I have working order, let it have the name &quot;Tp&quot;. When &quot;Tp&quot; was submitted, it had OCO paired order with &quot;Sl&quot; name. And then something strange and frighten happened, and now we have one only working &quot;Tp&quot; order. &quot;Sl&quot; is in a terminal state, or


        NinjaTrader will need to be running to see the execution of the entry order to adequately place full targets and stops in this fashion. If this situation happens, the person running the strategy should call their Order's desk and intervene immediately because further fills on the entry order will not have the protective orders managing this quantity. (NinjaTrader will not see the addition entry order fills and will not be able to amend the protective orders with a new quantity.)

        Please let me know if I can be of further assistance.
        JimNinjaTrader Customer Service

        Comment


          #5
          Thanks a lot, Jim. It is clear now.
          fx.practic
          NinjaTrader Ecosystem Vendor - fx.practic

          Comment

          Latest Posts

          Collapse

          Topics Statistics Last Post
          Started by jaybedreamin, Today, 05:56 PM
          0 responses
          3 views
          0 likes
          Last Post jaybedreamin  
          Started by DJ888, 04-16-2024, 06:09 PM
          6 responses
          18 views
          0 likes
          Last Post DJ888
          by DJ888
           
          Started by Jon17, Today, 04:33 PM
          0 responses
          1 view
          0 likes
          Last Post Jon17
          by Jon17
           
          Started by Javierw.ok, Today, 04:12 PM
          0 responses
          6 views
          0 likes
          Last Post Javierw.ok  
          Started by timmbbo, Today, 08:59 AM
          2 responses
          10 views
          0 likes
          Last Post bltdavid  
          Working...
          X