Imported from previous forum
[ original email was from Ainhoa Dewisme - ainhoa.dewisme@reuters.com ]
Hello again…
The use of ClOrdID in the OrderStatusRequest differs from the use of this tag in other ‘Request’ messages …
Typically ClOrdID will be set to a Unique ID that identifies the request. OrigClOrdID is used to reference ClOrdID of the previous non rejected order (the client order id the request will be made upon)
In OrderStatusRequest message ClOrdID includes the order id whose status is being requested (value other messages will set in OrigClOrdID)
What is the reason behind this logic? Is it because the status request will never change the state of the order, whereas cancel request or replace request will?
Thanks and Regards
Ainhoa
Order Status Request has its own message identifier, namely OrdStatusReqID, which is used in the Execution report to link back to the request. This is generally preferable to the usage of a field like ClOrdID as message and entity identifier at the same time. In the case of Order Status Request, the field ClOrdID and OrderID serve purely as entity identifiers.
I agree that FIX is not 100% consistent in this respect. However, it is also not easy to change usages without causing application breakage. Additions to the FIX spec will be checked to avoid an overlap in semantics.
Regards,
Hanno.
Hello again…
The use of ClOrdID in the OrderStatusRequest differs from the use of
this tag in other ‘Request’ messages …Typically ClOrdID will be set to a Unique ID that identifies the
request. OrigClOrdID is used to reference ClOrdID of the previous non
rejected order (the client order id the request will be made upon)In OrderStatusRequest message ClOrdID includes the order id whose status
is being requested (value other messages will set in OrigClOrdID)What is the reason behind this logic? Is it because the status request
will never change the state of the order, whereas cancel request or
replace request will?Thanks and Regards
Ainhoa