Imported from previous forum
Do OrigClientOrderId (Tag 41) is essential for order cancel/replace reject request? Especially, if exchange is communicating OrderId (Tag 37) on order confirmation.
If FIX engine internally works with OrderId only, can we work with CliOrderId (Tag 11) + OrderId (Tag 37) in order cancel/replace request and altogether elminate OrigClientOrderId (Tag 41)?
ClOrdID and OrigClOrdID are essential if you want to support order chaining, i.e. ClOrdID serves as a request identifier and OrigClOrdID serves as the entity identifier. ClOrdID becomes the new entity identifier upon successful completion of the request. Omitting OrigClOrdID from the Cancel/Replace request is simply non-FIX.
Many legacy exchange systems only know OrderID and have a dedicated field in the message header for the request identifier so that I can understand your reasoning. However, order chaining is one of the fundamental FIX concepts and your customers connecting to you with their (standard) FIX engines would struggle if you do not support it.
Do OrigClientOrderId (Tag 41) is essential for order cancel/replace reject request? Especially, if exchange is communicating OrderId (Tag 37) on order confirmation.
If FIX engine internally works with OrderId only, can we work with CliOrderId (Tag 11) + OrderId (Tag 37) in order cancel/replace request and altogether elminate OrigClientOrderId (Tag 41)?