# Order Change Matrix - Order of Messages

**URL:** <https://forum.fixtrading.org/t/order-change-matrix-order-of-messages/3946>\
**Category:** General Q&A\
**Tags:** xid\_167171, general-qa, imported\
**Created:** [September 24, 1999, 2:35pm UTC](https://forum.fixtrading.org/t/order-change-matrix-order-of-messages/3946 "1999-09-24T14:35:00Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\
**Post date:** [September 24, 1999, 2:35pm UTC](https://forum.fixtrading.org/t/order-change-matrix-order-of-messages/3946/1 "1999-09-24T14:35:00Z")

</div>

Imported from previous forum

---

<div class="post-metadata">

**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\
**Post date:** [September 24, 1999, 2:35pm UTC](https://forum.fixtrading.org/t/order-change-matrix-order-of-messages/3946/2 "1999-09-24T14:35:00Z")

</div>

[original email was from Witold Sames - [witold@javtech.com](mailto:witold@javtech.com) ]  
We came accross the following scenario:

1. Send order to sell side, like BUY 1000  
shares IBM at 100.

2. Receive ExecRpt, OrdStatus = new, and  
ExecTransType = new. This is the ack,  
and ok this way.

3. Send a cancel request for this order.

4. Now, we receive an ExecRpt with  
OrdStatus = pending cancel, ExecTransType  
= new, LastShares = 0, LastPx = 0.0,  
CumQty = 100, AvgPx = 100.

5. Following, ExecRpt with OrdStatus = Canceled,  
ExecTransType = new, other items the same  
as in 3).

6. Finally, here comes a partial fill,  
OrdStatus - part fill, LastShares = 100,  
LastPx = 100, CumQty = 100, AvgPx = 100,  
ExecTransType = 0.

In our opinion, the first execution report in this scenario should already be rejected, since  
there is a CumQty implied that we have no fill to account for. I would like to know what you think about this, if there’s better way to handle this maybe?

On the other hand, I think that receiving an execution report with a part fill AFTER receiving  
the cancel pending but before the canceled is legal and is being practised.

Thank you.

Witold  
[witold@javtech.com](mailto:witold@javtech.com)

---

<div class="post-metadata">

**Author:** ![scott.atwell](https://avatars.discourse-cdn.com/v4/letter/s/51bf81/32.png) [@scott.atwell](https://forum.fixtrading.org/u/scott.atwell)\
**Post date:** [September 24, 1999, 11:42pm UTC](https://forum.fixtrading.org/t/order-change-matrix-order-of-messages/3946/3 "1999-09-24T23:42:00Z")

</div>

I don’t think #4 should show CumQty of 100 and have an AvgPx without having previously provided the fill for 100. If #4 had CumQty and AvgPx of 0, then #6 could come between #4 and #5. For #4 to have CumQty of 100, then #6 should have been sent before #4. Does the MsgSeqNum order match the order you’re describing (i.e. are they being received out of order but sent in order)?

\> We came accross the following scenario:  
\>  
\> 1) Send order to sell side, like BUY 1000  
\> shares IBM at 100.  
\>  
\> 2) Receive ExecRpt, OrdStatus = new, and  
\> ExecTransType = new. This is the ack,  
\> and ok this way.  
\>  
\> 3) Send a cancel request for this order.  
\>  
\> 4) Now, we receive an ExecRpt with  
\> OrdStatus = pending cancel, ExecTransType  
\> = new, LastShares = 0, LastPx = 0.0,  
\> CumQty = 100, AvgPx = 100.  
\>  
\> 5) Following, ExecRpt with OrdStatus = Canceled,  
\> ExecTransType = new, other items the same  
\> as in 3).  
\>  
\> 6) Finally, here comes a partial fill,  
\> OrdStatus - part fill, LastShares = 100,  
\> LastPx = 100, CumQty = 100, AvgPx = 100,  
\> ExecTransType = 0.  
\>  
\> In our opinion, the first execution report in this scenario should already be rejected, since  
\> there is a CumQty implied that we have no fill to account for. I would like to know what you think about this, if there’s better way to handle this maybe?  
\>  
\> On the other hand, I think that receiving an execution report with a part fill AFTER receiving  
\> the cancel pending but before the canceled is legal and is being practised.  
\>  
\> Thank you.  
\>  
\> Witold  
\> [witold@javtech.com](mailto:witold@javtech.com)  
\>

---

<div class="post-metadata">

**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\
**Post date:** [September 27, 1999, 1:21pm UTC](https://forum.fixtrading.org/t/order-change-matrix-order-of-messages/3946/4 "1999-09-27T13:21:00Z")

</div>

[original email was from Witold Sames - [witold@javtech.com](mailto:witold@javtech.com) ]  
That’s the problem, sequence numbers are perfectly in order, it’s the system generating the application messages (or passing them through) that mixes up the order of messages.  
Thank you for the clarification.

\> I don’t think #4 should show CumQty of 100 and have an AvgPx without having previously provided the fill for 100. If #4 had CumQty and AvgPx of 0, then #6 could come between #4 and #5. For #4 to have CumQty of 100, then #6 should have been sent before #4. Does the MsgSeqNum order match the order you’re describing (i.e. are they being received out of order but sent in order)?  
\>  
\>  
\> \> We came accross the following scenario:  
\> \>  
\> \> 1) Send order to sell side, like BUY 1000  
\> \> shares IBM at 100.  
\> \>  
\> \> 2) Receive ExecRpt, OrdStatus = new, and  
\> \> ExecTransType = new. This is the ack,  
\> \> and ok this way.  
\> \>  
\> \> 3) Send a cancel request for this order.  
\> \>  
\> \> 4) Now, we receive an ExecRpt with  
\> \> OrdStatus = pending cancel, ExecTransType  
\> \> = new, LastShares = 0, LastPx = 0.0,  
\> \> CumQty = 100, AvgPx = 100.  
\> \>  
\> \> 5) Following, ExecRpt with OrdStatus = Canceled,  
\> \> ExecTransType = new, other items the same  
\> \> as in 3).  
\> \>  
\> \> 6) Finally, here comes a partial fill,  
\> \> OrdStatus - part fill, LastShares = 100,  
\> \> LastPx = 100, CumQty = 100, AvgPx = 100,  
\> \> ExecTransType = 0.  
\> \>  
\> \> In our opinion, the first execution report in this scenario should already be rejected, since  
\> \> there is a CumQty implied that we have no fill to account for. I would like to know what you think about this, if there’s better way to handle this maybe?  
\> \>  
\> \> On the other hand, I think that receiving an execution report with a part fill AFTER receiving  
\> \> the cancel pending but before the canceled is legal and is being practised.  
\> \>  
\> \> Thank you.  
\> \>  
\> \> Witold  
\> \> [witold@javtech.com](mailto:witold@javtech.com)  
\> \>  
\>
