January 2019 - OrderId remains the same for partially filled orders which are held over night - Potentially breaking
In january we will introduce a change whereby an order will retain the same order id, even if the order is filled over several exchange sessions. This change will make it easier to keep track of an order and the position or positions created as the result of the order being filled.
Example
Consider the scenario where a conditional order is filled over several exchange sessions. The tables below illustrates the difference between the current implementation and the to-be released implementation.
Day 1:
A limit order (orderId 101) for the amount of 200 has been placed. During the day, there has been a partial fill of 10, hence the filled amount on the order is 10 and a position (10001) with SourceOrder=101 and amount=10 is created.
This is the same in the old and the new implementation.
| Old implementation | New Implementation | |||||||
|---|---|---|---|---|---|---|---|---|
| Order | Order | |||||||
| OrderId | Order Type | Amount | FilledAmount | OrderId | OrderType | Amount | FilledAmount | |
| 101 | Limit | 200 | 10 | 101 | Limit | 200 | 10 | |
| Position | Position | |||||||
| PositionId | SourceOrderId | Amount | PositionId | SourceOrderId | Amount | |||
| 10001 | 101 | 10 | 10001 | 101 | 10 | |||
Day 1: Session Closed
In the old implementation, the original partially filled order is cancelled and a new order with a new order id (102) on the remaining 190 is created.
In the new implementation, no new order is created.
| Old implementation | New Implementation | |||||||
|---|---|---|---|---|---|---|---|---|
| Order | Order | |||||||
| OrderId | Order Type | Amount | FilledAmount | OrderId | OrderType | Amount | FilledAmount | |
| 101 | Limit | 200 | 10 | |||||
| 102 | Limit | 190 | ||||||
| Position | Position | |||||||
| PositionId | SourceOrderId | Amount | PositionId | SourceOrderId | Amount | |||
| 10001 | 101 | 10 | 10001 | 101 | 10 | |||
Day 2: Further partial fill
During the second day there is another partial fill of 20. A new position is created in both the old and the new implementation.
Notice that in the new implementation the order being partially filled is still order 101. Therefore the FillledAmount on Order 101 is increased from 10 to 30. Also the SourceOrderId on the new position is also still 101.
| Old implementation | New Implementation | |||||||
|---|---|---|---|---|---|---|---|---|
| Order | Order | |||||||
| OrderId | Order Type | Amount | FilledAmount | OrderId | OrderType | Amount | FilledAmount | |
| 101 | Limit | 200 | 30 | |||||
| 102 | Limit | 190 | 20 | |||||
| Position | Position | |||||||
| PositionId | SourceOrderId | Amount | PositionId | SourceOrderId | Amount | |||
| 10001 | 101 | 10 | 10001 | 101 | 10 | |||
| 10002 | 102 | 20 | 10002 | 101 | 20 | |||
Implications for developers
Unless you are keeping your own records between orders places and positions created, this change should not have any implications for you. In most situations you should not need to do this, as you should be able to trust that Saxos list of open orders (port/v1/orders) and positions (port/v1/positions) are consistent and correct.
If however, you are keeping your own records, you will hopefully enjoy the improved ability to keep a connection between the order and the position(s) being created as a result of an order fill, even when the order fill happens over several exchange sessions.
Another benefit is the improved experience for a user, who will be looking at an open order showing the original order amount and the total filled amount, rather than a new order on a smaller amount.
The only potential impact could be if somehow today your application expects that two positions cannot have the same SourceOrderId. Please verify this!