+1 888 340 6572 GET STARTED
MultiCharts Project Management
previous_open_issue.png
Go to the previous open issue
previous_issue.png
Go to the previous issue (open or closed)
star_faded.png
Please log in to bookmark issues
feature_request_small.png
Open Feature request MC-1497 » Open Feature request MC-454

Automated Strategy always submits multiple orders as OCO orders - compared to DOM

action_vote_minus_faded.png
23
Votes
action_vote_plus_faded.png
next_issue.png
Go to the next issue (open or closed)
next_open_issue.png
Go to the next open issue
Description

Hello MC Team,
  I was demonstrating this issue to Dave/Katrina and in the end they have asked me to open this PM request.
 in automated trading - all the orders are entered as OCO order. As soon as the first position is filled - it cancels the other orders in the queue ( though the condition for them to stay in the queue are still valid)  and then places the order again at the same quantity/price. In this mode - I would lose the position in the order queue. However in the DOM - using master exit strategy with multiple exits - it would give me the ability to stay in the queue.
Would like to have the ability to disable OCO submission of the orders - if the conditions are valid for specific order - they need to remain in the queue - rather than getting cancelled - due to other events ( like first target is filled or other means).
Thanks

Steps to reproduce this issue
  • buy 10 contracts
  • as soon as the position is filled - enter 3 orders at the same tick
       - sell 4 contracts at averageentryprice + 2 ticks;
       - sell 3 contracts at averageentryprice + 4 ticks;
       - sell 3 contracts at averageentryprice + 6 ticks;
    I see all the 3 orders in the queue to start with - which is fine. However as soon as the first target is filled - other 2 orders gets cancelled and then goes to the queue again.
    I have tried the workarounds suggested by Dave/Katrina as well. Based on analysis of the logs - they mentioned - this is not possible with automated strategy as it always places the orders as OCO and have asked me to open this PM request to see if it is possible to provide this option to stay in the queue ( with DOM - manual trading - it works great - they don't get submitted as OCO orders - they remain in the queue - irrespective of the other even like first target is filled). Would like to have the same DOM feature available with automated trading as well or atleast an option to be made available to users.
    Thanks
Comments (17)
#0
user-offline.png  Dave (Dave)
Sep 06, 2011 - 13:04

vking,
 
Please describe how do you want this feature to be implemented: do you want to have an option to not to send orders in OCO group? Should it be implemented separately for entry and exit orders?

#0
user-offline.png  vking (vking)
Sep 06, 2011 - 14:01

I am not sure - all I wanted is to have the behavior of the orders to be same whether the multiple target orders are submitted through strategy or through the DOM using master exit strategy.
With DOM:
- When multi-target orders are submitted through Master strategy with multi-target as soon as the order is filled - they remain in the queue irrespective of whether the orders are filled for the prior target or not
With Auto trading:
- When multi-target orders are submitted at the same tick - with certain conditions - when the first target is filled - it also cancels the other higher target orders in queue(though the entry condition for those orders still being valid) and then resubmits again
All I want is to have some way of keeping the order active - if the condition for it is still valid ( should be treated an independent exit ) and the other events like lower target being filled shouldn't have an impact on this order.
If this would cause any issues with current way of handling the orders - if you can provide a flag or something to get the desired behavior - it should solve my problem. This is the only thing stopping me from using automated strategies in MC ( as manual DOM based exits - I can't mimic in automated strategies).
Thanks

#0
user-offline.png  Dave (Dave)
Sep 13, 2011 - 11:57

vking,
We have some additional questions:
1) What broker do you use?
2) Do you use a single signal for auto trading or several signals combined in one strategy?
3) Could you send us an example of your script for testing purposes?

#0
user-offline.png  GB (Id2)
Sep 16, 2011 - 14:41

Dave - Please see my reply below:
1) What broker do you use?
- I would assume the solution won't be broker specific but for argument sake - you can pick OEC.
2) Do you use a single signal for auto trading or several signals combined in one strategy?
- I would have multiple "entry" based signals - they would control ONLY the entries.
-
One exit based strategy would be running on the chart - it's job is to
check the position and close out the positions and nothing more than
that.

3) Could you send us an example of your script for testing purposes?

This is the simple example code I could think of : with properties set
to : "Allow unlimited entries and exits per bar" to take care of the
multiple exits.
As demonstrated - though the exits enter the
queue as mentioned - as soon as the first target is filled second/third
target contract orders gets cancelled and resubmitted again though the
condition for them to stay in the queue are still valid.
Thanks.
Code:
[IntrabarOrderGeneration = true]
Vars: intrabarpersist MktPosition(0);
Vars: intrabarpersist AEP(0);
Vars: intrabarpersist CC(0);
Vars: OneTick(MinMove/PriceScale);

MktPosition=Marketposition;
if LastBarOnChart_s and barstatus(1)=2 and MktPosition=0 then begin
  buy 3 contracts next bar market;
end else begin
  CC=CurrentContracts;
  AEP=AvgEntryPrice;
  if CC>=1 then sell 1 contract next bar at AEP+(6OneTick) limit; // Third Target
  if CC>=2 then sell 1 contract next bar at AEP+(4
OneTick) limit; // Second Target
  if CC>=3 then sell 1 contract next bar at AEP+(2*OneTick) limit; // First Target
end;

#0
user-offline.png  vking (vking)
Sep 16, 2011 - 16:10

[IntrabarOrderGeneration = true]
Vars: intrabarpersist MktPosition(0);
Vars: intrabarpersist AEP(0);
Vars: intrabarpersist CC(0);
Vars: OneTick(MinMove/PriceScale);

MktPosition=Marketposition;
if LastBarOnChart_s and barstatus(1)=2 and MktPosition=0 then begin
  buy ("LE") 3 contracts next bar market;
end else begin
  CC=CurrentContracts;
  AEP=AvgEntryPrice;
  if CC>=1 then sell ("TT") 1 contract next bar at AEP+(6OneTick) limit; // Third Target
  if CC>=2 then sell ("ST") 1 contract next bar at AEP+(4
OneTick) limit; // Second Target
  if CC>=3 then sell ("FT") 1 contract next bar at AEP+(2*OneTick) limit; // First Target
end;

#0
user-offline.png  Dave (Dave)
Sep 16, 2011 - 17:08

Thank you for the info. I have discussed it with the developers and here is their verdict: we will most likely implement this feature in the future, however there is no ETA at the moment.

#0
user-offline.png  vking (vking)
Sep 24, 2011 - 14:41

I am not sure why this got post-poned as this functionality currently exists with DOM based master strategy but can't be replicated in power language. In other words this is not really an additional feature request but replicating the functionality of DOM/master strategy through power language - which gives much more flexibility to users. Appreciate if you can consider implementing this as early as possible.
Thanks.

#0
user-offline.png  Dave (Dave)
Oct 10, 2011 - 11:43

vking,
 
We will consider your feature request. However, we do not plan to implement it in the nearest future. Thank you for understanding.

#0
user-offline.png  vking (vking)
Oct 28, 2011 - 13:54

Dave - In my opinion this is not really a feature request but a "bug" with order management and is very important for me.
Imagine - you would like to exit the second target at 5 tick profit - you enter the queue when the number of contracts at that price were 50 contracts. By the time the first target is filled - you would cancel the second target order and re-enter again at that price - assume there are 3000 contracts at that price. What are the chances of getting the second target filled at that price as you are going to be placed at the end of 3000.
I would think this to be a serious bug rather than feature request.
Thanks.

#0
user-offline.png  atsui (atsui)
Nov 12, 2011 - 05:15

I agree that exit orders treated as OCO is a bug based on the fact in backtesting multiple exit orders with different tags can be transacted in the same bar but in real time trading exit orders with different tags are treated as OCO. therefore only one exit order can be transacted in one bar in actual trading. The result is that the backtesting result will not be the same as actual result, espeically for strategy that doesn't use IOG, because the exit locations between the two is different. It seems to me that the way that currently the OCO is handled defeats the purpose of having exit tags because they don't serve any purpose other than printing the signal name on the chart.
 
 

#0
user-offline.png  vking (vking)
Nov 12, 2011 - 10:27

Thanks atsuri. Have been trying to convince MC team to accept this as a serious bug - as it would impact the auto-trading functionality. As there is no work-around for this issue - wanted to get this implemented as soon as possible. Initially this was agreed to be implemented for 7.1 but so far not implemented.
MC Team - Would you please review this again for implementation as this is really a core component of the software?

#0
user-offline.png  atsui (atsui)
Nov 15, 2011 - 11:36

Hi Vking,
 
I just reviewed your code. i was wondering if assigning tags to your entry orders may help. Have you tried this?
 
if LastBarOnChart_s and barstatus(1)=2 and MktPosition=0 then begin
buy ("LE1") 1 contract next bar market;
buy ("LE2") 1 contract next bar market;
buy ("LE3") 1 contract next bar market;
end else begin
CC=CurrentContracts;
AEP=AvgEntryPrice;
if CC=1 then sell ("TT") 1 contract from entry ("LE1") next bar at AEP+(6OneTick) limit; // Third Target
if CC=2 then sell ("ST") 1 contract from entry ("LE2")  next bar at AEP+(4
OneTick) limit; // Second Target
if CC=3 then sell ("FT") 1 contract from entry ("LE3")  next bar at AEP+(2*OneTick) limit; // First Target
end;
 
 
Also, the exit order conditions in your example are not mutual exclusive and may lead to overfill so i delete the > sign.  
 
Hope it achieve what you'd like to achieve.
 
The issue that I am facing is a little bit different in that if IOG is turned off, the exit orders are placed as OCO even thought they relate to different entry order names and there is no option to allow unlimited entries and exits per bar, therefore I can only exit my position once per bar even the conditions for all exit orders are true.

#0
user-offline.png  vking (vking)
Nov 15, 2011 - 11:53

Atsui - Thanks for the reply.
- Yes - I have tried assigning different tags(for entries/exits) and it didn't help either. Has the code worked for you as expected with IOG=true?
thread - http://www.multicharts.com/discussion/viewtopic.php?f=1&t=9222&p=43769&hilit=OCO#p43769
- I can't use "=" sign as this won't place multiple exits. My intention is to exit at different targets and go into the queue immediately after a fill.
- This won't cause an overfill as I am being specific about the condition and the number of contracts.
- I have tried with many possibilities with coding and it didn't help.
Thanks.

#0
user-offline.png  vking (vking)
Nov 15, 2011 - 13:41

To elaborate further:
- I don't see a reason to wait for the first target to be filled to enter the second target and second target to be filled to enter the third target and so on.
- I would think it would be a very basic requirement to support scale-out with automated systems
- Ninja/Sierra already support this functionality and even tradestation which is based on easy language supports this through a work around - allowing "limit based place order functionality" thought easy language.
- in MC there are no work arounds and though there is "place order" function - it is limited to "market order" only and doesn't allow "limit orders".
- not really sure why this issue is not taking priority over few cosmetic changes in other areas as this is supposed to be a core functionality.
Thanks.

#0
user-offline.png  atsui (atsui)
Nov 15, 2011 - 14:56

vking you are right, it seems that there is no way to get around the OCO order status.

#0
user-offline.png  MultiCharts Support (MultiCharts)
Jan 04, 2012 - 17:19

Dear Vking and other customers,
We do understand that this feature is very important for you and we are going to implement it. However, there is no eta when it is going to be released. Currently we are focused on other features. Once we start working on it, the status of this feature request will be changed to "Confirmed" and it will be assigned to a particular milestone of MC. 
Thank you for your understanding.

#0
user-offline.png  MultiCharts Support (MultiCharts)
Oct 15, 2013 - 17:40
History
Issue basics
  • Type of issue
    Feature request
  • Category
    Usability
  • Targeted for
    Not determined
  • Status
    Postponed
User pain
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
Affected by this issue (3)
People involved
Times and dates
  • Posted at
  • Last updated
Issue details
  • Resolution
    Not determined
  • Severity
    Normal
Attachments (3)
  • /pm/public/files/show/246
    As you can see from the attachment - as soon as the first target(FT) is filled second(ST) and Third(TT) orders first gets cancelled and then resubmitted again - which would make the order to go to the uploaded Sep 16, 2011 by vking (vking)
  • /pm/public/files/show/247
    As you can see from the attachment - as soon as the first target(FT) is filled second(ST) and Third(TT) orders first gets cancelled and then resubmitted again - which would make the order to go to the uploaded Sep 16, 2011 by vking (vking)
  • /pm/public/files/show/248
    As you can see from the attachment - as soon as the first target(FT) is filled second(ST) and Third(TT) orders first gets cancelled and then resubmitted again - which would make the order to go to the uploaded Sep 16, 2011 by vking (vking)
Commits (0)
There are no code checkins for this issue
Duplicate issues (0)
This issue does not have any duplicates