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
figurelli e All,
Parabéns pela iniciativa deste tópico e pela contribuição de todos! Tenho muito interesse no mesmo e vou acompanhar todos os posts.
Sobre o item 8 (Existe verificação e controle das ordens executadas e das situações de exceção na comunicação com o servidor da corretora?), gostaria de colocar o código que uso para verificação de execução de ordens para criticas e sugestões (ou para verificações adicionais, caso necessárias).
Quando submeto uma ordem, capturo o número do ticket através do campo 'order' da estrutura 'MqlTradeResult'. Para confirmação de execução uso o evento 'OnTradeTransaction'.
Exemplo do código:
void OnTradeTransaction (const MqlTradeTransaction &Transaction,const MqlTradeRequest &,const MqlTradeResult &)
{
if (Transaction.type==TRADE_TRANSACTION_DEAL_ADD && OrderTicket==Transaction.order)
{
if (Transaction.order_state==ORDER_STATE_FILLED)
{
Print ("Order Filled!");
FlagOrder=true;
}
else if (Transaction.order_state==ORDER_STATE_PARTIAL)
Print ("Order Partial!");
}
}
Espero estar contribuindo ao tópico e que esta questão seja do interesse de todos. Mais uma vez, excelente tópico de discussão!
Abraços,
André Barbisan.
barbisan,
o código oferece returns para os casos da ordem parcialmente e filled, entretanto e para os casos nos quais há a recusa de ordens? Ou as mesmas não se concretizam ou congelam? Como você irá saber o estado de fato de cada ordem emitida?
gostaria de adicionar um item 0. no checklist
leia todo o livro de engenharia de software do sommerville e compreenda oque esta fazendo , principalmente a ter de sistemas criticos (que envolve perda de vida, perda ambiental, ou perda de dinheiro)
https://lucathas.wordpress.com/2010/04/23/sistemas-sociotecnicos/
gostaria de adicionar um item 0. no checklist
leia todo o livro de engenharia de software do sommerville e compreenda oque esta fazendo , principalmente a ter de sistemas criticos (que envolve perda de vida, perda ambiental, ou perda de dinheiro)
https://lucathas.wordpress.com/2010/04/23/sistemas-sociotecnicos/
Olá Roberto, ótima contribuição.
Estamos em uma camada de abstração de riscos operacionais bem acima dessa, mas sem dúvida os fundamentos, muitas vezes esquecidos, são essenciais também.
Olá!!
Muito bom e principalmente muito útil este check-list. Está sendo quase o equivalente dos "10 Mandamentos Bíblicos" para os novatos como eu. Muito obrigado Rogério.
Preocupado com a latência do servidores, coloquei o comando "sleep" no meu EA, apesar das suas recomendações que dizem que esta não é a melhor opção. Contudo, usei esse comando por não encontrar instruções mais detalhadas de como nos defender dessas falhas por outros meios.
Com meus EAs usando o comando "sleep" notei que nada muda nos testes of-line e nas contas demo provavelmente não ajuda plenamente porque também pouco muda comparando-os com testes of-line.
Assim, poderia dar mais detalhes de como nos defender neste ponto?
Muito bom o check-list!
A maior parte dos traders que operam com robôs, tanto no mercado Forex, como no mercado BM&FBovespa, geralmente focam apenas no lado bom, que é o potencial de lucro que um bom Expert Advisor pode apresentar.
Isso conduz todo o foco da complexidade dos robôs nos algoritmos das estratégias, baseadas em boas experiências obtidas na operação manual.
Entretanto, nem tudo são flores e a falta de preocupação com a complexidade e problemas de operar em conta real com robôs, sem uma adequada análise dos riscos, pode levar a resultados totalmente diversos dos esperados.
A operação com sistemas automáticos é muito mais complexa e oferece muito mais riscos para o trader, que vão muito além da simples automação de uma estratégia.
Os riscos aumentam ainda mais no mercado BM&FBovespa, onde o MT5 é absolutamente novo e um projeto piloto.
Para facilitar esse entendimento, descrevo nesse tópico um checklist de verificação que considero mínimo para um Expert Advisor, antes de operar em conta real.
Essa lista não fecha o escopo para toda e qualquer situação de risco operando com robôs, mas acredito que já seja um bom começo.
Se você criou um robô para operar no mercado e a resposta não é um “sim” com segurança para todos os itens, recomendo você revisar novamente o código fonte de seu robô e ficar fora do mercado real, até estar totalmente adequado e confortável com esse checklist.
Ola Rogerio Figurelli
Qual a real importância do item 2? (O fechamento de posições é garantidamente realizado antes da abertura de uma nova posição contrária utilizando um mesmo lote?)
Olhando pelo lado de uma inversão de posição eu estando comprado com 1 contrato, vendo 2, resultando em ficar vendido no final. Existe a necessidade de realmente eu não poder vender 2 contratos e ter q vender 1 para fechar a posição depois outra para inverter?
Não sei se vc me entendeu.
Obrigado!
Ola Rogerio Figurelli
Qual a real importância do item 2? (O fechamento de posições é garantidamente realizado antes da abertura de uma nova posição contrária utilizando um mesmo lote?)
Olhando pelo lado de uma inversão de posição eu estando comprado com 1 contrato, vendo 2, resultando em ficar vendido no final. Existe a necessidade de realmente eu não poder vender 2 contratos e ter q vender 1 para fechar a posição depois outra para inverter?
Não sei se vc me entendeu.
Obrigado!
Olá Vitor, desculpe a demora na resposta, mas só agora (fazendo uma referência ao tópico) vi que estava pendente aqui.
Considero o item 2 (fechamento de posições garantidamente realizado antes da abertura de uma nova posição contrária utilizando um mesmo lote) como uma das principais causas de crashes dos robôs, principalmente no MT5.
Na prática esse item envolve a visibilidade de execução das operações, o que no fluxo de informações entre a plataforma cliente e a ponta final, na BM&FBovespa, nem sempre é tão claro.
Para melhor entendimento, o que se propõe é criar mecanismos seguros de fechamento de posições para não depender de erros/falhas/latência/etc de nenhum fabricante/fornecedor, em qualquer item que influencie de alguma forma as transações, visando evitar futuros crashes.
Melhores cumprimentos,
Rogério Figurelli