FORTS: OnTradeTransaction() return codes - page 4
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Probably no one needs...
A necessary one, actually.
Retcodes on FORTS are trouble in every sense.
I don't know who sets it up (the broker or the MQ developers), but there are questions for the developers too.
The returns don't match the description in the documentation at all! None of the code corresponds in fact! =)
Dear developers!
Please answer, when will you finally pay
attention to the RETURN CODES of the trading server?
When an MT5 server "glitches" or an exchange crashes, the following happens:
The Expert Advisor sends orders to delete an EXISTING order, but the response comes back
"Invalid request" !!!! And the Expert Advisor keeps "pounding" the server with orders to delete
order.
How can there be a wrong request if the order is ACTIVE?
We have already figured out that this code comes if the order is in intermediate status.
The code is retarded. I agree. It's not the request that's wrong, it's "the order cannot be deleted at this time".
And the question is poignant: why is this most critical trade action periodically unavailable?
In any architecture, the "cancel mission" command (delete order) should be executed immediately without question at any stage other than the fact of the trade.
If this is not the case, then the error is structural.
I have been in a long fight with the Broker to have the fines imposed by the Exchange removed, which I incurred because the Exchange had a malfunction. Below is the verdict of the broker. ))
We reiterate to you that the transactions submitted from your terminal on 21.09.2015 were determined to be ineffective in accordance with the conditions and parameters for calculating fees for ineffective transactions according to Moscow Exchange rules.
Based on the above, the Broker is forced to refuse to waive your penalty for inefficient transactions.
The number of transactions falling under the definition of inefficient has nothing to do with the failure of the Exchange, but with the settings of your robot, for which neither the Exchange nor the Broker is responsible.
The Exchange's press release states that the Exchange recognised all transactions carried out on the trading day of 21.09.2015 as valid.
Gentlemen developers!
I raised this topic on the forum last November. At the same time, I was told by the SD that this problem will be resolved during 2015. Please confirm your readiness to fulfill your promise!
I had a long 'fight' with the Broker to have the Exchange fines removed, which I had incurred because the Exchange had had a failure. Below is the Broker's verdict. ))
Penalty for exceeding 2,000 transactions? What is the fine, if not a secret?
The rates are on the exchange's website
Penalty for exceeding 2,000 transactions? And what's the fine, if it's not a secret?
It's no secret. http://fs. moex.com/files/4266 The link has it all, but you can't figure it out without half a litre. By the way, it doesn't just penalise you for over-transactions, it penalises you for a lot of other things.
It's no secret. http://fs. moex.com/files/4266 The link has it all, but you can't figure it out without half a litre. By the way, it's not just over-transaction penalties, but a lot of other things too.
Do you want us to get drunk?)) Is it that hard to write a figure?
This really needs to be calculated... here's what I found:
11. Transaction processing conditions
11.1 Charge for ineffective Transactions.
For the purpose of defining ineffective Transactions, a Transaction shall mean declaration of an Application, deletion of an Application, deletion of an Application with simultaneous declaration of an Application with other Transaction conditions, deletion of a pair of Applications with simultaneous declaration of a pair of Applications with other Transaction conditions.
The fee for inefficient Transactions is determined each Trading Day in aggregate by sections of clearing registers with the same TIN (or code substituting it) of this Brokerage Firm of this Settlement Firm (hereinafter referred to as the Sections) in respect of the Derivatives Market of PJSC Moscow Exchange.
The Fee for inefficient Transactions is not charged if the number of Transactions executed with the indication of the Sections for which the said Fee is determined is less than or equal to the relevant threshold value. The threshold value is set by decision of the Technical Centre and is published on the Moscow Exchange website.
The calculation of the Fee for inefficient Transactions is made according to the formula:
where:
TranFee1 - the value of the Fee for inefficient Transactions made during the Trading Day (in rubles, including VAT);
k - the point for the Transaction executed with the respective Sections (determined bythe type of Transaction according to Table 1);
f - the amount of exchange and clearing fees payable for the conclusion of Trades with the indication of Sections, for the relevant Trading Day;
l - score for a Trade concluded with indication of one of the Sections (determined according to the type of Trade according to Table 1).
Transactions are deemed ineffective if the condition is met:
Table 1.
The type of Transaction or Deal is determined by combining features 1-3:
Type of Transaction or Transaction
The point value for the Transaction
Score for the Transaction
Feature 1
Feature 2
Feature 3
0
0
0
k_1
l_1
0
0
1
k_2
l_2
0
1
0
k_3
l_3
0
1
1
k_4
l_4
1
0
0
k_5
l_5
1
0
1
k_6
l_6
1
1
0
k_7
l_7
1
1
1
k_8
l_8
The meaning of the attributes of the Transaction or Transaction type is determined in the following order:
Characteristic 1: 1 - the Transaction or Transaction is executed with a Section specified in the Market Maker's Obligation Execution Agreement for this Instrument; 0 - the Transaction or Transaction is executed with a Section not specified in the Market Maker's Obligation Execution Agreement for this Instrument.
Characteristic 2: 0 - futures contract (and also Application "Calendar spread" - when accounting Transactions); 1 - option contract.
Feature 3: 1 - low-liquid instrument, 0 - other instrument. The instrument's liquidity is determined on the basis of the List of Low-Liquid Instruments established by Moscow Exchange and published on Moscow Exchange's website.
Point values for Transactions or Deals (k_1-k_8 and l_1-l_8) are set by decision of the Technical Centre and published on the Moscow Exchange PJSC website.
The fee for ineffective transactions is charged to Sections in proportion to the number of Transactions made from each Section.