FORTS: OnTradeTransaction() 반환 코드 - 페이지 5

새 코멘트
 

11.2. 잘못된 거래에 대한 수수료.

거래 실행 중 표 2에 표시된 오류 코드가 할당된 경우 거래는 잘못된 거래로 인식됩니다. 잘못된 거래를 판단하기 위해 거래는 주문 제출, 주문 철회, 주문 취소 다른 거래 조건과 함께 주문을 동시에 제출하는 주문, 다른 거래 조건을 가진 주문 쌍을 제출하여 동시에 주문 쌍을 철회하는 주문.

잘못된 거래 수수료는 현재 거래일 의 저녁 청산 세션(중단의 첫 번째 1초 포함)을 개최하기 위해 거래가 중단된 순간부터 거래가 중단되는 순간까지의 기간 동안 각 로그인에 대해 계산됩니다. 다음 거래일의 저녁 청산 세션(중단의 첫 번째 1초는 포함하지 않음)(이하 계산 기간이라고 함)을 개최하기 위해.

잘못된 거래에 대한 수수료는 다음 공식에 따라 계산됩니다.

 

 

어디:

TranFee2 - 결제 기간 동안 발생한 잘못된 거래에 대한 수수료 금액(VAT 포함 루블)

한도 - 기술 센터의 결정에 의해 설정되고 PJSC 모스크바 거래소 웹사이트에 게시된 잘못된 거래에 대한 수수료의 최대 한도

xi – 초당 계산된 값, 정수로 내림하고 공식에 의해 결정됨:

 

어디:

Qi - i 번째 초에 대한 모든 포인트의 합계(포인트는 표 2에 따라 결정됨);

L i 는 이 로그인의 한계로, 공식에 의해 계산되고 정수로 반올림됩니다.

 

 

어디:

용량 i – 이 부록의 단락 3.2에 제공된 방식으로 결정된 로그인 대역폭은 i 번째 초에 유효합니다.

 

표 2 :

 

유형   T 거래*

실행 결과(오류 코드)*

Q 점수

주문 추가

교차 거래 발생 (31)

Q1

고객 자금 부족(332)

2분기

증권사 자금 부족(333)

3분기

FOK 신청 실패(4103)

4분기

주문 취소

응용 프로그램을 찾을 수 없습니다 (14)

Q5 _

이동 지시

교차 거래 발생 (31)

Q6 _

애플리케이션   ~ 아니다   발견 (50)

Q7 _

H 는 충분하지 않다   자금   클라이언트 (332)

Q8 _

H 는 충분하지 않다   자금   중개   기업 (333)

Q9 _

DelUserOrders

거래가 성공적으로 완료되었습니다

삭제된 요청이 없습니다.

Q1 0

* Gateway FORTS Plaza-2의 설명에 따름.

Q1-Q10 포인트의 가치는 기술 센터의 결정에 따라 결정되며 PJSC 모스크바 거래소 웹사이트에 게시됩니다.

다음 조건이 충족되는 경우 잘못된 거래에 대한 수수료가 부과됩니다.

 

어디:

TranFee2 - 정산 기간 동안 발생한 잘못된 거래에 대한 수수료 금액(VAT 포함 루블)

상한선 – 기술 센터의 결정에 의해 설정되고 PJSC 모스크바 거래소 웹사이트에 게시된 오류 거래 수수료의 최소 금액 한도 ,

잘못된 거래에 대한 수수료는 잘못된 거래에 대한 수수료가 정의된 로그인이 연결된 청산 원장 섹션에서 청구됩니다.

 
불행히도 수식 만 삽입되지 않습니다.
 
Dmitriy Skub :
우리 자고 싶니?)) 숫자 쓰기가 그렇게 어려운가요?
Alexey Kozitsyn 은 이 조항의 일부 텍스트만 복사하여 붙여넣었습니다. 더 명확해 졌나요? )) 만약 당신이 그것을 알아내고 싶다면 당신이 여전히 자야 한다는 것이 두렵습니다. ))
 

이 오류의 반환 코드는 무엇입니까?

 2015.09 . 21 10 : 00 : 13      20845617         SBRF- 3.16        buy limit       2.00 / 0.00              7 303                    2015.09 . 21 10 : 00 : 13              rejected        Инструмент отсутствует в текуще
 

잘못된 요청 오류 코드로 돌아가기

주문 삭제 기능을 약간 수정했습니다.

 //+------------------------------------------------------------------+
// Remove order                                                      |
//+------------------------------------------------------------------+
void COrder::Remove()
{
   if ( ticket > 0 )
  {
     if ( OrderSelect ( ticket ) )
    {
       ENUM_ORDER_STATE ord_state = ENUM_ORDER_STATE ( OrderGetInteger ( ORDER_STATE ) );
       if ( ( ord_state == ORDER_STATE_REQUEST_MODIFY ) || ( ord_state == ORDER_STATE_REQUEST_CANCEL ) ) return ;
//---      
      mem_magic = ulong ( OrderGetInteger ( ORDER_MAGIC ) );
      mem_tick = GetTickCount ();
      req_id = 0 ;
       MqlTradeRequest request = { 0 };
       MqlTradeResult   result  = { 0 };
            
      request.action = TRADE_ACTION_REMOVE ;
      request.order = ticket;
          
       if ( OrderSendAsync ( request, result ) )
      {
         if ( result.retcode == TRADE_RETCODE_PLACED )
        { 
          req_id = result.request_id;
//---          
           switch ( order_status )
          {
             case BUY_ORDER:  state = ORD_BUY_DO_CANCEL;
                             break ;
                
             case SELL_ORDER: state = ORD_SELL_DO_CANCEL;
                             break ;           
          } 
          SetTransCount( true );
        }
         else
        {
          mem_magic = 0 ;
          mem_tick = 0 ;
          CheckError( result.retcode, "Remove: Ордер не удалён! Причина: " , order_status, ticket );
        }  
      }
       else
      {
        mem_magic = 0 ;
        mem_tick = 0 ;
        CheckError( result.retcode, "Remove: Ордер не отослан! Причина: " , order_status, ticket );
      }
    }
     else
    {
      ticket = 0 ;
      modify_count = 0 ;
    }
  }
   else
  {
    modify_count = 0 ;
  }
}

CheckError() 함수

 //+------------------------------------------------------------------+
// Expert Check Error function                                       |
//+------------------------------------------------------------------+
void CheckError( const uint ret_code, const string err_msg, const ENUM_ORD_STATUS ord_status, const ulong a_ticket )
{
   switch ( ret_code )
  {
    ........                              
     case TRADE_RETCODE_INVALID : Print ( err_msg + GetRetCode( ret_code ), "; Билет = " , a_ticket );
                                 break ;                                                       
                
     default : Print ( err_msg, GetRetCode( ret_code ), "; Билет = " , a_ticket );  
             break ;            
  }
}

주문하여: 

2015.11.25 15:07:30.773 Trades  'xxxxx': buy limit 5.00 SNGP-3.16 at 40718
2015.11.25 15:07:30.784 Trades  'xxxxx': buy limit 5.00 SNGP-3.16 at 40718 placed for execution in 10 ms

MT 5 서버는 응답을 보내지 않았고 CheckOrders() 함수가 작동했으며 주문 티켓이 수신되었습니다.

 2015.11 . 25 15 : 07 : 31.849 Forts_trader (SNGP- 12.15 ,H1)    CheckOrders: Buy ордер установлен. Билет = 23992887

그 후 주문 삭제 명령이 통과하지 못했습니다(EA).

 2015.11 . 25 15 : 07 : 31.865 Forts_trader (SNGP- 12.15 ,H1)    Remove: Ордер не отослан! Причина: Неправильный запрос Билет = 23992887

그리고 이것은 터미널에 의해 확인됩니다. 

2015.11.25 15:07:31.865 Trades  'xxxxx': failed cancel order #23992887 buy limit 5.00 SNGP-3.16 at 40718.00000 [Invalid request]

문제:

터미널 메모리 의 주문 상태는 무엇입니까?

왜 잘못된 요청입니까?

나는 터미널 환경에서 티켓을 받았는데, 이것은 터미널이 주문이 되었다는 것을 "알고 있다"는 것을 의미합니다 !

결국 동일한 기능이 동일한 티켓으로 이 주문을 삭제했습니다. 

2015.11.25 15:15:03.245 Trades  'ххххх': cancel order #23992887 buy limit 5.00 SNGP-3.16 at 40718
2015.11.25 15:15:03.254 Trades  'ххххх': cancel order #23992887 buy limit 5.00 SNGP-3.16 at 40718 placed for execution in 8 ms
 
Михаил :

잘못된 요청 오류 코드로 돌아가기

주문 삭제 기능을 약간 수정했습니다.

CheckError() 함수

주문하여:

MT 5 서버는 응답을 보내지 않았고 CheckOrders() 함수가 작동했으며 주문 티켓이 수신되었습니다.

그 후 주문을 삭제하는 명령이 통과하지 못했습니다(EA).

그리고 이것은 터미널에 의해 확인됩니다.

문제:

터미널 메모리 의 주문 상태는 무엇입니까?

왜 잘못된 요청입니까?

( 나는 터미널 환경에서 티켓을 받았는데, 이것은 터미널이 "주문이 이루어진 것을 안다"는 것을 의미한다 )!

다음도 있습니다.

 2015.11 . 24 17 : 07 : 15.020 FORTS (MXI- 12.15 ,M5)       ORDER_STATE = ORDER_STATE_REQUEST_ADD
 

다음과 같이 시도하십시오.

 if (!( OrderGetInteger ( ORDER_STATE )== ORDER_STATE_PARTIAL || OrderGetInteger ( ORDER_STATE )== ORDER_STATE_PLACED )) return ;
 
Sergey Chalyshev :

다음도 있습니다.

세르게이!

어떤 이유로 티켓이 있으면 (주문 후) 티켓이 없을 수 있습니다.

그의 상태:

 ORDER_STATE_REQUEST_ADD
 
Михаил :

세르게이!

어떤 이유로 티켓이 있으면 (주문 후) 티켓이 없을 수 있습니다.

그의 상태:

나도 그렇게 생각하지만, 이 오류는 작업 로그에서 나온 것입니다.

이 검사를 추가한 후 삭제 및 수정 전에 모든 상태를 기록했습니다. InvalidRequest가 더 이상 발생하지 않습니다.

이 질문은 서버 작업과 개발자를 위한 것입니다. ORDER_STATE_REQUEST_ADD는 어떻게 발생합니까?

 
Sergey Chalyshev :

나도 그렇게 생각하지만, 이 오류는 작업 로그에서 나온 것입니다.

이 검사를 추가한 후 삭제 및 수정하기 전에 모든 상태를 기록했습니다. InvalidRequest가 더 이상 발생하지 않습니다.

이 질문은 서버 작업과 개발자를 위한 것입니다. ORDER_STATE_REQUEST_ADD는 어떻게 발생합니까?

아마도 터미널에서 서버의 응답을 기다리는 시간 초과가 상당히 클 것입니다...
1234567891011
새 코멘트
사유: