![MQL5 - Linguagem para estratégias de negociação inseridas no terminal do cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
11.2Cobrança por transações errôneas.
As transações serão reconhecidas como errôneas se durante o curso da transação tiver sido atribuído um código de erro, conforme indicado na Tabela 2. Para determinar transações errôneas, entende-se por transação a apresentação de uma Ordem, retirada de uma Ordem, retirada de uma Ordem com apresentação simultânea de uma Ordem com condições de Transação diferentes, retirada de um par de Ordens com apresentação simultânea de um par de Ordens com condições de Transação diferentes.
O cálculo da Taxa para Transações Erradas deve ser feito para cada Login para o período desde a suspensão de negociação para a sessão de compensação noturna do Dia de Negociação atual (incluindo o primeiro segundo de suspensão) até a suspensão de negociação para a sessão de compensação noturna do Dia de Negociação seguinte (não incluindo o primeiro segundo de suspensão) (doravante - o Período de Cálculo).
O cálculo do valor da Taxa para transações errôneas será feito de acordo com a fórmula:
onde:
TranFee2 - o valor da Taxa para transações erradas feitas durante o Período de Liquidação (em rublos incluindo o IVA);
Cap - um limite para o valor máximo da Taxa para transações erradas estabelecido pelo Centro Técnico e publicado no site da Bolsa de Valores de Moscou;
xi- valor calculado por segundo, arredondado para baixo para números inteiros e determinado pela fórmula:
onde:
Qi- a soma de todos os pontos para o i-ésimo segundo (os pontos são determinados de acordo com a Tabela 2);
Li- o limite do login dado, que é calculado de acordo com a fórmula e arredondado para números inteiros:
Onde:
Capacityi- capacidade do login, determinada de acordo com o procedimento estipulado no ponto 3.2 deste anexo, válida para o i-ésimo segundo.
Tabela 2:
Tipo de transação*
Resultado da execução (código de erro)*
Pontuação Q
AddOrder
Ocorreu uma transação cruzada (31)
Q1
Insuficiência de fundos do cliente (332)
Q2
Insuficiência de fundos da corretora (333)
Q3
Oferta FOK não consolidada (4103)
Q4
DelOrder
Ordem não encontrada (14)
Q5
MoveOrder
Ocorreram trapaças (31)
Q6
Nenhumaordem foiencontrada (50)
Q7
Insuficiência de fundosdo cliente (332)
Q8
Fundosinsuficientesdaempresa decorretagem(333)
Q9
DelUserOrders
A transação foi concluída com sucesso,
e nenhuma ordem é excluída
Q10
* de acordo com a descrição do FORTS Plaza-2 Gateway.
Os valores dos pontos Q1-Q10 são estabelecidos por uma decisão do Centro Técnico e são publicados no site da Bolsa de Valores de Moscou.
Uma taxa para Transações errôneas será cobrada se a condição for cumprida:
onde:
TranFee2 - o valor da Taxa por Transações errôneas feitas durante o Período de Liquidação (em rublos incluindo o IVA);
Capmin- uma restrição ao valor mínimo da Taxa para Transações errôneas estabelecida pelo Centro Técnico e publicada no site da Bolsa de Valores de Moscou,
A taxa para Transações errôneas é cobrada a partir da seção de registro de compensação à qual o login para o qual a taxa para Transações errôneas é determinada está vinculada.
Você quer que fiquemos bêbados?)) É tão difícil escrever uma figura?
Qual é o código de retorno para este erro?
Retornando ao código de erro de solicitação inválida
Mudei a função para apagar um pouco o pedido:
Função CheckError().
Após fazer o pedido:
O servidor MT 5 não enviou nenhuma resposta, a função CheckOrders() foi acionada e um ticket de pedido foi recebido:
Depois disso, o comando para apagar a ordem (EA) NÃO foi aprovado:
E isto também foi confirmado pelo terminal:
Pergunta:
Qual é a situação da ordem na memória do terminal ?
Por que um pedido inválido?
Recebi um bilhete do ambiente do terminal, então o terminal "sabe" que o pedido está feito!
Afinal, mais tarde, a mesma função eliminou esta ordem com o mesmo bilhete:
Retornando ao código de erro de solicitação inválida
Mudei a função para apagar um pouco o pedido:
Função CheckError().
Após fazer o pedido:
O servidor MT 5 não enviou nenhuma resposta, a função CheckOrders() foi acionada e um ticket de pedido foi recebido:
Depois disso, o comando para apagar a ordem (EA) NÃO foi aprovado:
E isto também foi confirmado pelo terminal:
Pergunta:
Qual é a situação do pedido na memória do terminal ?
Por que um pedido inválido?
(recebi o bilhete do ambiente do terminal, então o terminal "sabe que o pedido foi feito")!
Há também isto:
Tente desta forma:
Há mais destes:
Sergei!
Por alguma razão me parece que se houver um bilhete (após a emissão de um mandado), não pode haver
seu estado:
ORDER_STATE_REQUEST_ADD
Sergei!
De alguma forma me parece que, se houver um bilhete (após a emissão de um mandado), não pode haver
Seu status:
Eu também penso assim, mas não é minha idéia, este erro é do diário de transações.
Após adicionar esta verificação, colocar todos os estados, antes de apagar e modificar, no registro. O InvalidRequest não ocorre mais.
Esta pergunta é mais para as operações do servidor e para os desenvolvedores comoORDER_STATE_REQUEST_ADD aparece.
Eu também acho que sim, mas não foi minha idéia, este erro é do registro da operação.
Após adicionar esta verificação, colocar todos os estados, antes de apagar e modificar, no registro. O InvalidRequest não ocorre mais.
Esta pergunta é mais para as operações do servidor e para os desenvolvedores comoORDER_STATE_REQUEST_ADD aparece.