제한 및 시장 주문이 있습니다. 이러한 개념은 모스크바 거래소의 공식입니다. 기술 구현 문제는 부차적입니다. 즉시 구매/판매할 수 없다는 것은 분명합니다. 이 모든 것은 특정 주파수와의 혼합을 통해 발생합니다.
다른 모든 변형은 브로커 서버의 터미널을 통해 구현되며 특정 조건이 발생하면 지정가 또는 시장가 주문이 발생합니다.
주소 지정 주문, 비개인화 주문, 지정가 주문, 빙산 지정가 주문, 지정가 지정가 주문, 지정가 지정가 지정이 지정이 지정이 지정되지 않은 지정이 있습니다. 모두 ! 시장가 주문이 없습니다! 구매 시장 주문(속어로 읽음)은 제안 이상의 구매 제한으로 실행됩니다. 판매 시장 주문(속어로 읽음)은 입찰가 아래의 판매 제한으로 실행됩니다. 이에 따르면 스탑 오더(속어)는 시장 오더이지만 한도로서 거래소의 핵심으로 보내집니다. 그리고 거래소는 이를 제한으로 보기 때문에 GO가 스톱 오더에 필요한 이유입니다(귀하의 경우 이것은 스톱로스 , 다시 속어입니다). 거래소가 매뉴얼에 기재한 내용은 거래소 속어를 사용합니다! 교환의 핵심은 다르게 작동하며 이를 이해해야 합니다. 알고리즘 프로그램을 사용하는 경우 기술 구현의 문제가 가장 중요합니다.
논리적으로, 동일한 성공으로 정지는 반대 순서로 대체될 수 있습니다(실제로 일어나는 일입니다). 실행 우선 순위 문제 - 와우.
따라서 지정가 주문은 이미 거래소에 있으며 모든 종류의 중지는 브로커와 함께 서면에만 있습니다. 분명히 GO가 이미 한도에 의해 0으로 고려되었다는 사실 때문에 (구체적으로 확인했습니다-터미널에서 여백이 변경되지 않음(MT5에서는 GO)) 정지 구현은 불가능합니다 , 시장 주문에 따라 실행되기 때문입니다. 여기서 단말기는 테이크를 허용하지 않거나 실행되지 않는 위험에 대해 최소한 경고하거나 더 정확하게는 계산된 위험 평가 및 GO가 있어야 거래 시점이 아니라 거래 후 완료됩니다. 발생하지 않는 거래의 결과에 대한 계산이 있습니다! 그러나 그것은 브로커와 그 소프트웨어의 잘못으로, 또는 규칙 / 규정의 잘못으로 인해 발생하지 않습니다. 이해할 수 없습니다.
지정가 주문, 빙산 지정가 주문, 정지 주문 및 지정가 지정가 주문이 있습니다. 모두 ! 시장가 주문이 없습니다! 거래소가 매뉴얼에 기재한 내용은 거래소 속어를 사용합니다! 교환의 핵심은 다르게 작동하며 이를 이해해야 합니다. 알고리즘 프로그램을 작성하는 경우 기술 구현의 문제가 가장 중요합니다.
진정하세요 :) 법적 문제가 우선입니다. 메시지 - 그들이하고 싶었던 것, 구현은 2 차적이며 메시지와 일치하지 않으면 구현이 올바르지 않고 변경 될 수 있습니다. 이것은 역 프로세스를 제외하고 인간 활동의 모든 영역에 있습니다. - 필드 과학 연구의.
빙산은 소프트웨어로 구현되며 내가 아는 한 Plaza2 프로토콜에서 제공하지 않습니다.
교환은 소프트웨어의 고객이며 설명서를 인용하는 것이 아니라 법적으로 중요한 문서를 인용하는 것입니다. 법원에서 우선권을 가진 사람은 그 사람이며 교환이 실제로 그에 따라 작동하지 않으면 이것은 규정 위반입니다. 부분.
그리고 여기에는 용어를 제외하고는 불일치가 없습니다. 본질은 변경되지 않습니다. 주문에는 실행 우선 순위에 대한 플래그가 있고 마켓 메이커 주문이 먼저 실행된다는 것을 아는 것이 훨씬 더 중요합니다.
진정하세요 :) 법적 문제가 우선입니다. 메시지 - 그들이하고 싶었던 것, 구현은 2 차적이며 메시지와 일치하지 않으면 구현이 올바르지 않고 변경 될 수 있습니다. 이것은 역 프로세스를 제외하고 인간 활동의 모든 영역에 있습니다. - 필드 과학 연구의.
빙산은 소프트웨어로 구현되며 내가 아는 한 Plaza2 프로토콜에서 제공하지 않습니다.
교환은 소프트웨어의 고객이며 설명서를 인용하는 것이 아니라 법적으로 중요한 문서를 인용하는 것입니다. 법원에서 우선권을 가진 사람은 그 사람이며 교환이 실제로 그에 따라 작동하지 않으면 이것은 규정 위반입니다. 부분.
그리고 여기에는 용어를 제외하고는 불일치가 없습니다. 본질은 변경되지 않습니다. 주문에는 실행 우선 순위에 대한 플래그가 있고 마켓 메이커 주문이 먼저 실행된다는 것을 아는 것이 훨씬 더 중요합니다.
그건 그렇고, 기술적 구현 측면에서 나는 이 인용문을 더 믿습니다.
그건 그렇고, 헤지 필드가 여기에 제공된다는 점에 유의하십시오. 분명히 GO를 증가시키지 않도록 허용하는 것입니다.
예, 법적 메시지에 대해 이해했습니다. 거래소에서 애플리케이션 작업을 더 자세히 설명하고 싶었을 뿐입니다. 많은 사람들이 Forex 이후에 이해하지 못하기 때문에 많은 사람들이 이 주제를 읽습니다.
소프트웨어의 우선 순위와 구현에 대해 이미 MQ 서버에 대한 개선 사항이 아니라고 말했는데 왜 검사가 없습니까? 경고 등
화면이나 종류는 다 맞는데 그냥 써져있는게 늘 그렇듯이 불명확함(일부러) 견적 주문은 주문서(유동성)의 지정가 주문입니다. 카운터 오더는 유동성이 필요한 주문입니다. FOK all or nothing - 이것이 애플리케이션의 조건입니다. 그러나 이러한 모든 주문은 본질적으로 거래소의 핵심에서 제한으로 실행됩니다)) 시장 주문은 관찰되지 않습니다))
모스크바 교환은 끊임없이 변화하는 규정과 함께 여전히 그 부엌입니다. 헤지 필드를 사용하면 하나의 상품에서 청산될 때까지 다방향 포지션을 유지할 수 있습니다. 볼륨 주문 측면에서 반대 방향과 등가는 GO에 의해 겹칩니다. 즉, 0으로 재설정됩니다. 즉, 이것은 Forex에서 와 같은 헤지 입니다))
Quik 터미널에서 이 헤지는 주문에 대한 주석을 사용하여 생성할 수 있습니다. MQL 요청을 보내는 구조에도 주석 필드가 있지만 이것이 있는지 여부는 명확하지 않습니다.
소프트웨어의 우선 순위와 구현에 대해 이미 MQ 서버에 대한 개선 사항이 아니라고 말했는데 왜 검사가 없습니까? 경고 등
검증이 브로커 또는 청산 센터에서 수행되는 위치가 완전히 명확하지 않고 브로커에서라면 청산 센터 규칙의 구현에 오류가 있기 때문에 우선 순위가 아직 명확하지 않습니다. 그리고 클라이언트의 서버(브로커)로부터 정보가 없다는 사실은 재앙이다. 그녀가 Quik에 있는지 궁금합니다.
로만 :
화면이나 종류는 다 맞는데 그냥 써져있는게 늘 그렇듯이 불명확함(일부러)
견적 주문은 주문서의 지정가 주문입니다.
카운터 주문은 GO에서 귀하의 위치와 겹치는 주문입니다. FOK all or nothing - 이것이 애플리케이션의 조건입니다. 시장 주문은 관찰되지 않습니다))
카운터 오더가 정확히 GI를 줄이는 것인지 확실하지 않습니다. 왜냐하면 경매 후 제거되고 경매는 정보의 순간이고 지정가 주문은 계속 매달려 있기 때문입니다. 왜냐하면 우리는 마감을 위한 두 가지 옵션이 있기 때문입니다 GI를 증가시키지 않고 - 시장별(SL/TP 경유 포함) 또는 주문장에 지정가 주문을 넣습니다. 시장 주문과 비슷합니다.
로만 :
헤지 필드를 사용하면 하나의 상품에서 청산될 때까지 다방향 포지션을 유지할 수 있습니다. 동일한 볼륨의 카운터 주문은 GO에 의해 겹칩니다. 즉, 0으로 재설정됩니다. 즉, 이것은 Forex에서 와 같은 헤지 입니다))
Quik 터미널에서 이 헤지는 주문에 대한 주석을 사용하여 생성할 수 있습니다. MQL 요청을 보내는 구조에도 주석 필드가 있지만 이것이 있는지 여부는 명확하지 않습니다.
신청서에 구체적으로 어떤 코멘트를 작성해야 합니까? 그리고 이 경우에 GO는 어떻게 될까요?
검증이 브로커 또는 청산 센터에서 수행되는 위치가 완전히 명확하지 않고 브로커에서라면 청산 센터 규칙의 구현에 오류가 있기 때문에 우선 순위가 아직 명확하지 않습니다. 그리고 클라이언트의 서버(브로커)로부터 정보가 없다는 사실은 재앙이다. 그녀가 Quik에 있는지 궁금합니다.
카운터 오더가 정확히 GI를 줄이는 것인지 확실하지 않습니다. 왜냐하면 경매 후 제거되고 경매는 정보의 순간이고 지정가 주문은 계속 매달려 있기 때문입니다. 왜냐하면 우리는 마감을 위한 두 가지 옵션이 있기 때문입니다 GI를 증가시키지 않고 - 시장별(SL/TP 경유 포함) 또는 주문장에 지정가 주문을 넣습니다.
신청서에 구체적으로 어떤 코멘트를 작성해야 합니까? 그리고 이 경우에 GO는 어떻게 될까요?
아마도 브로커에서 청산은 수표에 신경 쓰지 않고 세션의 결과를 줄이고 선동합니다. 예, Quik은 GO의 부족에 대해 알려주고 스크린샷에서 mt5도 돈이 없다고 알렸습니다. 그러나 폐쇄 손절매에 대한 마니는 없으며 이것은 개발자가 변경해야 할 재앙일 뿐입니다.
카운터 오더와 GO에 대해, 예, 제가 착각했습니다. 헤지 포지션을 의도한 것입니다. 포지션의 헤지가 거래량면에서 동일하다면 두 주문의 GI가 서로 겹칠 것입니다. 즉, 0으로 재설정됩니다. 50% 오버랩에서 50% 등으로 재설정됩니다. 즉, GO의 부하를 관리할 수 있습니다(예: 시장에서 멀리 떨어진 주문 제한 및 열지 않을 예정). Quik 응용 프로그램 제출 창에는 주석 필드가 있습니다. 무엇이든 작성할 수 있습니다. 마치 mql의 마술과 같습니다. 하지만 댓글과 함께 설정 한 포지션이나 한도를 닫으 려면 같은 댓글을 작성해야 합니다. 그리고 헤지포지션은 청산 전까지만 존속하는데 일일청산이 통했는지 히든인지 기억이 안나네요. 내 생각에 그는 주요 저녁까지 산다.
더 정확하게 찾는 방법은 아직 명확하지 않습니다. 문서에서 아직 알아낼 수 없습니다. 이 문제에 대해 중개인이나 거래소, 또는 청산 센터에 글을 쓸 수도 있습니다.
로만 :
예, Quik은 GO의 부족에 대해 알리고 스크린샷에서 mt5도 돈이 없다고 알렸습니다.
Quik에서 상황을 재현하려고 노력해야 하겠지만 거기에서 TP/SL을 설정하는 방법을 몰랐던 것으로 기억합니다.
중개인이 스크린샷을 나에게 보냈고 해당 서버에서 볼 수 있으며 내 로그도 게시했지만 그 중 아무 것도 볼 수 없습니다. 마진 부족(GO)에 대한 알림이 없습니다!
로만 :
그러나 폐쇄 손절매에 대한 마니는 없으며 이것은 개발자가 변경해야 하는 재앙일 뿐입니다.
모든 것이 규정에 따라 발생하고 오류가 없으면 SL이 트리거될 때 카운터 제한을 제거한 다음 즉시 다시 넣어야 합니다. 아니면 아예 설치하지 마세요. 그렇지 않으면 GO의 30%가 TP가 아닌 지정가 주문에 의해 폐쇄되는 경우 동결해야 합니다. 그렇지 않으면 중지가 작동하지 않습니다.
로만 :
포지션의 헤지가 거래량면에서 동일하다면 두 주문의 GI가 서로 겹칠 것입니다. 즉, 0으로 재설정됩니다. Quik 응용 프로그램 제출 창에는 주석 필드가 있습니다. 무엇이든 작성할 수 있습니다. 마치 mql의 마술과 같습니다. 하지만 댓글과 함께 설정 한 포지션이나 한도를 닫으 려면 같은 댓글을 작성해야 합니다. 그리고 헤지포지션은 청산 전까지만 살아있고, 일일청산이 통했는지 히든인지 기억이 안나네요. 내 생각에 그는 주요 저녁까지 산다.
그건 그렇고, 왠지 Quik이 청산하기 전에 돈을 동결 시켰던 기억이 납니다. 오픈/클로즈 후 차익이 있더라도... 아직 세션에서 사용하지 않은 GO에서만 오픈이 가능했고, 짜증나네요... 흠, 아니면 주식용인가요 - 깜빡했네요 - 네, 아직 켜보지 않았습니다.
더 정확하게 찾는 방법은 아직 명확하지 않습니다. 문서에서 아직 알아낼 수 없습니다. 이 문제에 대해 중개인이나 거래소, 또는 청산 센터에 글을 쓸 수도 있습니다.
Quik에서 상황을 재현하려고 노력해야 하지만 거기에서 TP/SL을 설정하는 방법을 몰랐던 것으로 기억합니다.
중개인이 스크린샷을 나에게 보냈고 해당 서버에서 볼 수 있으며 내 로그도 게시했지만 그 중 아무 것도 볼 수 없습니다. 마진 부족(GO)에 대한 알림이 없습니다!
모든 것이 규정에 따라 발생하고 오류가 없으면 SL이 트리거될 때 카운터 제한을 제거한 다음 즉시 다시 넣어야 합니다. 아니면 아예 설치하지 마세요. 그렇지 않으면 GO의 30%가 TP가 아닌 지정가 주문에 의해 폐쇄되는 경우 동결해야 합니다. 그렇지 않으면 중지가 작동하지 않습니다.
그건 그렇고, 왠지 Quik이 청산하기 전에 돈을 동결 시켰던 기억이 납니다. 오픈/클로즈 후 차익이 있더라도... 아직 세션에서 사용하지 않은 GO에서만 오픈이 가능했고, 짜증나네요... 흠, 아니면 주식용인가요 - 깜빡했네요 - 네, 아직 켜보지 않았습니다.
이것은 본질적으로 시스템이 상황을 어떻게 인식했는지에 대한 스크린샷입니다. 이 메시지는 원으로 표시됩니다.
문제는 6504.45의 이 추정 마진은 어디에서 왔습니까? 무엇으로 만들었을까? 매도 지정가 주문은 매수 지정가 주문과 동일한 마진을 가감하여 - 4500으로 하되, 그 마진은 마치 현재 시장에 오픈할 계획인 것처럼 여겨졌던 것으로 밝혀졌습니다! 계획 마진이 그렇게 고려된 이유는 무엇입니까?
그러나 이것이 클라이언트에서 발생하지 않는다는 사실은 재앙이며 매우 심각한 것입니다. 개발자나 중재자가 이 주제를 읽고 이것이 심각한 터미널 문제임을 이해하기를 바랍니다. 그리고 주제의 버그와 오류를 보고하는 것이 더 나을 것입니다.
TP/SL 속어를 잊어버리고 항상 주문을 제한 및 정지로 취급하십시오.
"단말 손절매"에 대한 GO가 충분하지 않은 경우 설정한 지정가 주문을 확인해야 하며 존재하는 경우 삭제해야 한다고 앞서 썼습니다.
아마도 동결은 이전 회기부터였을 것이고, 정산 회기가 저녁 청산 이후에 시작되어 다음날로 넘어가기 때문에 많은 분들이 헷갈려 하십니다. 사실 오늘의 모든 정산은 어제 저녁 정산 이후에 시작됩니다)) 세 세션 모두에 대한 새로운 화폐 계산이 시작됩니다. 그리고 많은 사람들이 생각하는 10시 개장부터가 아니다. 일반적으로 나는 10시가 아니라 저녁 정리 후에 시장이 열리는 것으로 해석할 것입니다. 실제로 많은 사람들이 이것을 이해하지 못하고 10:00에도 거래가 계속되지만 낮 세션에 있습니다. 이런 교활한 모스 거래소가 있습니다.
제한 및 시장 주문이 있습니다. 이러한 개념은 모스크바 거래소의 공식입니다. 기술 구현 문제는 부차적입니다. 즉시 구매/판매할 수 없다는 것은 분명합니다. 이 모든 것은 특정 주파수와의 혼합을 통해 발생합니다.
다른 모든 변형은 브로커 서버의 터미널을 통해 구현되며 특정 조건이 발생하면 지정가 또는 시장가 주문이 발생합니다.주소 지정 주문, 비개인화 주문, 지정가 주문, 빙산 지정가 주문, 지정가 지정가 주문, 지정가 지정가 지정이 지정이 지정이 지정되지 않은 지정이 있습니다. 모두 !
시장가 주문이 없습니다!
구매 시장 주문(속어로 읽음)은 제안 이상의 구매 제한으로 실행됩니다.
판매 시장 주문(속어로 읽음)은 입찰가 아래의 판매 제한으로 실행됩니다.
이에 따르면 스탑 오더(속어)는 시장 오더이지만 한도로서 거래소의 핵심으로 보내집니다.
그리고 거래소는 이를 제한으로 보기 때문에 GO가 스톱 오더에 필요한 이유입니다(귀하의 경우 이것은 스톱로스 , 다시 속어입니다).
거래소가 매뉴얼에 기재한 내용은 거래소 속어를 사용합니다!
교환의 핵심은 다르게 작동하며 이를 이해해야 합니다.
알고리즘 프로그램을 사용하는 경우 기술 구현의 문제가 가장 중요합니다.
제 생각에는 그 주장이 부적절합니다. TERMS에 대한 명확한 개념이 없기 때문입니다.
논리적으로, 동일한 성공으로 정지는 반대 순서로 대체될 수 있습니다(실제로 일어나는 일입니다). 실행 우선 순위 문제 - 와우.
따라서 지정가 주문은 이미 거래소에 있으며 모든 종류의 중지는 브로커와 함께 서면에만 있습니다. 분명히 GO가 이미 한도에 의해 0으로 고려되었다는 사실 때문에 (구체적으로 확인했습니다-터미널에서 여백이 변경되지 않음(MT5에서는 GO)) 정지 구현은 불가능합니다 , 시장 주문에 따라 실행되기 때문입니다. 여기서 단말기는 테이크를 허용하지 않거나 실행되지 않는 위험에 대해 최소한 경고하거나 더 정확하게는 계산된 위험 평가 및 GO가 있어야 거래 시점이 아니라 거래 후 완료됩니다. 발생하지 않는 거래의 결과에 대한 계산이 있습니다! 그러나 그것은 브로커와 그 소프트웨어의 잘못으로, 또는 규칙 / 규정의 잘못으로 인해 발생하지 않습니다. 이해할 수 없습니다.
지정가 주문, 빙산 지정가 주문, 정지 주문 및 지정가 지정가 주문이 있습니다. 모두 !
시장가 주문이 없습니다!
거래소가 매뉴얼에 기재한 내용은 거래소 속어를 사용합니다!
교환의 핵심은 다르게 작동하며 이를 이해해야 합니다.
알고리즘 프로그램을 작성하는 경우 기술 구현의 문제가 가장 중요합니다.
진정하세요 :) 법적 문제가 우선입니다. 메시지 - 그들이하고 싶었던 것, 구현은 2 차적이며 메시지와 일치하지 않으면 구현이 올바르지 않고 변경 될 수 있습니다. 이것은 역 프로세스를 제외하고 인간 활동의 모든 영역에 있습니다. - 필드 과학 연구의.
빙산은 소프트웨어로 구현되며 내가 아는 한 Plaza2 프로토콜에서 제공하지 않습니다.
교환은 소프트웨어의 고객이며 설명서를 인용하는 것이 아니라 법적으로 중요한 문서를 인용하는 것입니다. 법원에서 우선권을 가진 사람은 그 사람이며 교환이 실제로 그에 따라 작동하지 않으면 이것은 규정 위반입니다. 부분.
그리고 여기에는 용어를 제외하고는 불일치가 없습니다. 본질은 변경되지 않습니다. 주문에는 실행 우선 순위에 대한 플래그가 있고 마켓 메이커 주문이 먼저 실행된다는 것을 아는 것이 훨씬 더 중요합니다.
그건 그렇고, 기술적 구현 측면에서 나는 이 인용문을 더 믿습니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
Tricks in the glass - 진드기에 의해 일어난 일을 이해하려는 시도
2019.04.19 19:31
그리고 FORTS에는 실제로 3 가지 유형의 응용 프로그램이 있다고 말합니다.
그러나 그들은 시장 또는 제한이 아닙니다(유형 필드 참조).
진정하세요 :) 법적 문제가 우선입니다. 메시지 - 그들이하고 싶었던 것, 구현은 2 차적이며 메시지와 일치하지 않으면 구현이 올바르지 않고 변경 될 수 있습니다. 이것은 역 프로세스를 제외하고 인간 활동의 모든 영역에 있습니다. - 필드 과학 연구의.
빙산은 소프트웨어로 구현되며 내가 아는 한 Plaza2 프로토콜에서 제공하지 않습니다.
교환은 소프트웨어의 고객이며 설명서를 인용하는 것이 아니라 법적으로 중요한 문서를 인용하는 것입니다. 법원에서 우선권을 가진 사람은 그 사람이며 교환이 실제로 그에 따라 작동하지 않으면 이것은 규정 위반입니다. 부분.
그리고 여기에는 용어를 제외하고는 불일치가 없습니다. 본질은 변경되지 않습니다. 주문에는 실행 우선 순위에 대한 플래그가 있고 마켓 메이커 주문이 먼저 실행된다는 것을 아는 것이 훨씬 더 중요합니다.
그건 그렇고, 기술적 구현 측면에서 나는 이 인용문을 더 믿습니다.
예, 법적 메시지에 대해 이해했습니다. 거래소에서 애플리케이션 작업을 더 자세히 설명하고 싶었을 뿐입니다.
많은 사람들이 Forex 이후에 이해하지 못하기 때문에 많은 사람들이 이 주제를 읽습니다.
소프트웨어의 우선 순위와 구현에 대해 이미 MQ 서버에 대한 개선 사항이 아니라고 말했는데 왜 검사가 없습니까? 경고 등
화면이나 종류는 다 맞는데 그냥 써져있는게 늘 그렇듯이 불명확함(일부러)
견적 주문은 주문서(유동성)의 지정가 주문입니다.
카운터 오더는 유동성이 필요한 주문입니다.
FOK all or nothing - 이것이 애플리케이션의 조건입니다.
그러나 이러한 모든 주문은 본질적으로 거래소의 핵심에서 제한으로 실행됩니다))
시장 주문은 관찰되지 않습니다))
모스크바 교환은 끊임없이 변화하는 규정과 함께 여전히 그 부엌입니다.
헤지 필드를 사용하면 하나의 상품에서 청산될 때까지 다방향 포지션을 유지할 수 있습니다.
볼륨 주문 측면에서 반대 방향과 등가는 GO에 의해 겹칩니다. 즉, 0으로 재설정됩니다.
즉, 이것은 Forex에서 와 같은 헤지 입니다))
Quik 터미널에서 이 헤지는 주문에 대한 주석을 사용하여 생성할 수 있습니다.
MQL 요청을 보내는 구조에도 주석 필드가 있지만 이것이 있는지 여부는 명확하지 않습니다.
소프트웨어의 우선 순위와 구현에 대해 이미 MQ 서버에 대한 개선 사항이 아니라고 말했는데 왜 검사가 없습니까? 경고 등
검증이 브로커 또는 청산 센터에서 수행되는 위치가 완전히 명확하지 않고 브로커에서라면 청산 센터 규칙의 구현에 오류가 있기 때문에 우선 순위가 아직 명확하지 않습니다. 그리고 클라이언트의 서버(브로커)로부터 정보가 없다는 사실은 재앙이다. 그녀가 Quik에 있는지 궁금합니다.
화면이나 종류는 다 맞는데 그냥 써져있는게 늘 그렇듯이 불명확함(일부러)
견적 주문은 주문서의 지정가 주문입니다.
카운터 주문은 GO에서 귀하의 위치와 겹치는 주문입니다.
FOK all or nothing - 이것이 애플리케이션의 조건입니다.
시장 주문은 관찰되지 않습니다))
카운터 오더가 정확히 GI를 줄이는 것인지 확실하지 않습니다. 왜냐하면 경매 후 제거되고 경매는 정보의 순간이고 지정가 주문은 계속 매달려 있기 때문입니다. 왜냐하면 우리는 마감을 위한 두 가지 옵션이 있기 때문입니다 GI를 증가시키지 않고 - 시장별(SL/TP 경유 포함) 또는 주문장에 지정가 주문을 넣습니다. 시장 주문과 비슷합니다.
헤지 필드를 사용하면 하나의 상품에서 청산될 때까지 다방향 포지션을 유지할 수 있습니다.
동일한 볼륨의 카운터 주문은 GO에 의해 겹칩니다. 즉, 0으로 재설정됩니다.
즉, 이것은 Forex에서 와 같은 헤지 입니다))
Quik 터미널에서 이 헤지는 주문에 대한 주석을 사용하여 생성할 수 있습니다.
MQL 요청을 보내는 구조에도 주석 필드가 있지만 이것이 있는지 여부는 명확하지 않습니다.
신청서에 구체적으로 어떤 코멘트를 작성해야 합니까? 그리고 이 경우에 GO는 어떻게 될까요?
검증이 브로커 또는 청산 센터에서 수행되는 위치가 완전히 명확하지 않고 브로커에서라면 청산 센터 규칙의 구현에 오류가 있기 때문에 우선 순위가 아직 명확하지 않습니다. 그리고 클라이언트의 서버(브로커)로부터 정보가 없다는 사실은 재앙이다. 그녀가 Quik에 있는지 궁금합니다.
카운터 오더가 정확히 GI를 줄이는 것인지 확실하지 않습니다. 왜냐하면 경매 후 제거되고 경매는 정보의 순간이고 지정가 주문은 계속 매달려 있기 때문입니다. 왜냐하면 우리는 마감을 위한 두 가지 옵션이 있기 때문입니다 GI를 증가시키지 않고 - 시장별(SL/TP 경유 포함) 또는 주문장에 지정가 주문을 넣습니다.
신청서에 구체적으로 어떤 코멘트를 작성해야 합니까? 그리고 이 경우에 GO는 어떻게 될까요?
아마도 브로커에서 청산은 수표에 신경 쓰지 않고 세션의 결과를 줄이고 선동합니다.
예, Quik은 GO의 부족에 대해 알려주고 스크린샷에서 mt5도 돈이 없다고 알렸습니다.
그러나 폐쇄 손절매에 대한 마니는 없으며 이것은 개발자가 변경해야 할 재앙일 뿐입니다.
카운터 오더와 GO에 대해, 예, 제가 착각했습니다. 헤지 포지션을 의도한 것입니다.
포지션의 헤지가 거래량면에서 동일하다면 두 주문의 GI가 서로 겹칠 것입니다. 즉, 0으로 재설정됩니다.
50% 오버랩에서 50% 등으로 재설정됩니다.
즉, GO의 부하를 관리할 수 있습니다(예: 시장에서 멀리 떨어진 주문 제한 및 열지 않을 예정).
Quik 응용 프로그램 제출 창에는 주석 필드가 있습니다. 무엇이든 작성할 수 있습니다. 마치 mql의 마술과 같습니다.
하지만 댓글과 함께 설정 한 포지션이나 한도를 닫으 려면 같은 댓글을 작성해야 합니다.
그리고 헤지포지션은 청산 전까지만 존속하는데 일일청산이 통했는지 히든인지 기억이 안나네요. 내 생각에 그는 주요 저녁까지 산다.
아마도 브로커에서 청산은 수표에 신경 쓰지 않고 세션의 결과를 줄이고 선동합니다.
더 정확하게 찾는 방법은 아직 명확하지 않습니다. 문서에서 아직 알아낼 수 없습니다. 이 문제에 대해 중개인이나 거래소, 또는 청산 센터에 글을 쓸 수도 있습니다.
예, Quik은 GO의 부족에 대해 알리고 스크린샷에서 mt5도 돈이 없다고 알렸습니다.
Quik에서 상황을 재현하려고 노력해야 하겠지만 거기에서 TP/SL을 설정하는 방법을 몰랐던 것으로 기억합니다.
중개인이 스크린샷을 나에게 보냈고 해당 서버에서 볼 수 있으며 내 로그도 게시했지만 그 중 아무 것도 볼 수 없습니다. 마진 부족(GO)에 대한 알림이 없습니다!
그러나 폐쇄 손절매에 대한 마니는 없으며 이것은 개발자가 변경해야 하는 재앙일 뿐입니다.
모든 것이 규정에 따라 발생하고 오류가 없으면 SL이 트리거될 때 카운터 제한을 제거한 다음 즉시 다시 넣어야 합니다. 아니면 아예 설치하지 마세요. 그렇지 않으면 GO의 30%가 TP가 아닌 지정가 주문에 의해 폐쇄되는 경우 동결해야 합니다. 그렇지 않으면 중지가 작동하지 않습니다.
포지션의 헤지가 거래량면에서 동일하다면 두 주문의 GI가 서로 겹칠 것입니다. 즉, 0으로 재설정됩니다.
Quik 응용 프로그램 제출 창에는 주석 필드가 있습니다. 무엇이든 작성할 수 있습니다. 마치 mql의 마술과 같습니다.
하지만 댓글과 함께 설정 한 포지션이나 한도를 닫으 려면 같은 댓글을 작성해야 합니다.
그리고 헤지포지션은 청산 전까지만 살아있고, 일일청산이 통했는지 히든인지 기억이 안나네요. 내 생각에 그는 주요 저녁까지 산다.
그건 그렇고, 왠지 Quik이 청산하기 전에 돈을 동결 시켰던 기억이 납니다. 오픈/클로즈 후 차익이 있더라도... 아직 세션에서 사용하지 않은 GO에서만 오픈이 가능했고, 짜증나네요... 흠, 아니면 주식용인가요 - 깜빡했네요 - 네, 아직 켜보지 않았습니다.
더 정확하게 찾는 방법은 아직 명확하지 않습니다. 문서에서 아직 알아낼 수 없습니다. 이 문제에 대해 중개인이나 거래소, 또는 청산 센터에 글을 쓸 수도 있습니다.
Quik에서 상황을 재현하려고 노력해야 하지만 거기에서 TP/SL을 설정하는 방법을 몰랐던 것으로 기억합니다.
중개인이 스크린샷을 나에게 보냈고 해당 서버에서 볼 수 있으며 내 로그도 게시했지만 그 중 아무 것도 볼 수 없습니다. 마진 부족(GO)에 대한 알림이 없습니다!
모든 것이 규정에 따라 발생하고 오류가 없으면 SL이 트리거될 때 카운터 제한을 제거한 다음 즉시 다시 넣어야 합니다. 아니면 아예 설치하지 마세요. 그렇지 않으면 GO의 30%가 TP가 아닌 지정가 주문에 의해 폐쇄되는 경우 동결해야 합니다. 그렇지 않으면 중지가 작동하지 않습니다.
그건 그렇고, 왠지 Quik이 청산하기 전에 돈을 동결 시켰던 기억이 납니다. 오픈/클로즈 후 차익이 있더라도... 아직 세션에서 사용하지 않은 GO에서만 오픈이 가능했고, 짜증나네요... 흠, 아니면 주식용인가요 - 깜빡했네요 - 네, 아직 켜보지 않았습니다.
아, 알겠습니다. 브로커의 화면 로그인데, 단말기를 생각해보니 간단해 보이네요.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
손절매는 더 이상 작동하지 않습니다. 병합하십시오.
Aleksey Vyazmikin , 2019.09.07 16:17
이것은 본질적으로 시스템이 상황을 어떻게 인식했는지에 대한 스크린샷입니다. 이 메시지는 원으로 표시됩니다.
문제는 6504.45의 이 추정 마진은 어디에서 왔습니까? 무엇으로 만들었을까? 매도 지정가 주문은 매수 지정가 주문과 동일한 마진을 가감하여 - 4500으로 하되, 그 마진은 마치 현재 시장에 오픈할 계획인 것처럼 여겨졌던 것으로 밝혀졌습니다! 계획 마진이 그렇게 고려된 이유는 무엇입니까?
그러나 이것이 클라이언트에서 발생하지 않는다는 사실은 재앙이며 매우 심각한 것입니다.
개발자나 중재자가 이 주제를 읽고 이것이 심각한 터미널 문제임을 이해하기를 바랍니다.
그리고 주제의 버그와 오류를 보고하는 것이 더 나을 것입니다.
TP/SL 속어를 잊어버리고 항상 주문을 제한 및 정지로 취급하십시오.
"단말 손절매"에 대한 GO가 충분하지 않은 경우 설정한 지정가 주문을 확인해야 하며 존재하는 경우 삭제해야 한다고 앞서 썼습니다.
아마도 동결은 이전 회기부터였을 것이고, 정산 회기가 저녁 청산 이후에 시작되어 다음날로 넘어가기 때문에 많은 분들이 헷갈려 하십니다.
사실 오늘의 모든 정산은 어제 저녁 정산 이후에 시작됩니다))
세 세션 모두에 대한 새로운 화폐 계산이 시작됩니다.
그리고 많은 사람들이 생각하는 10시 개장부터가 아니다.
일반적으로 나는 10시가 아니라 저녁 정리 후에 시장이 열리는 것으로 해석할 것입니다.
실제로 많은 사람들이 이것을 이해하지 못하고 10:00에도 거래가 계속되지만 낮 세션에 있습니다.
이런 교활한 모스 거래소가 있습니다.