> For the complete documentation index, see [llms.txt](https://smart-connected-supplier-network.gitbook.io/processmanual/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://smart-connected-supplier-network.gitbook.io/processmanual/use-cases/handle-order-deviations.md).
# Handle Order deviations
As is described in the Simple Order Process, an order can be confirmed by the seller by setting the *Order Line Status Code* to *Accepted*. However, the seller might also use other codes as is shown in the [Order Line Status Codes codelist](https://smartconnected.semantic-treehouse.nl/#/Codelist/Codelist_1570797904_00712297). Another scenario is that the buyer can request changes for a confirmed order line. The following sections describe the usage of these status codes.
See also [Order changes and line statuses](/processmanual/usage-notes/order-changes-and-line-statuses.md) for usage notes on what status code to use for the different scenario's.
| [Code](https://smartconnected.semantic-treehouse.nl/) | [Description](https://smartconnected.semantic-treehouse.nl/) |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| disputed | The order line is disputed, and should therefore not be processed yet. |
| revised | The order line is revised and is thus waiting for approval. |
| cancelled | The order line is cancelled.
This can be requested by the buyer or by the seller for a confirmed order line.
|
| added | The order line is added.
This can be requested by the buyer or by the seller for a confirmed order line.
|
| rejected | The order line is rejected. |
| accepted | The order line is accepted. |
## Proposing other delivery times
It is a rather common scenario that a Buyer might propose a delivery date for an item which is not feasible for a Seller. The Seller could simply *reject* the order line, but instead the Seller could also propose another date by using a *revised* order line status code. In this case, it is important that the Buyer confirms this new date. The figure below illustrates the workflow which is used in this case.
### Order message (Buyer -> Seller)
The following example shows a simplification of an order message with a singe line item and one specific delivery date.
Example XML Order message
```markup
1
50
175
1234
50
5790001398644
Warehoues
Antoon Coolenlaan
1 B
Eindhoven
5644RX
Inkoopafdeling
NL
2019-10-11
[Free-form text instructions for delivery]
[Description of the item]
[Item name]
[Identifier of the item issued by the BuyerCustomer]
AN0000123456
A1
Length
220
```
### Order response message (Seller -> Buyer)
The following example shows a simplification of an order response message, where the Seller proposes a new delivery date. This is indicated by the *revised*-Orderline status code and by the changed *RequestedDeliveryPeriod*.
Example XML Order response message
```markup
1
50
175
revised
1234
50
5790001398644
Warehoues
Antoon Coolenlaan
1 B
Eindhoven
5644RX
Inkoopafdeling
NL
2019-10-15
[Free-form text instructions for delivery]
[Description of the item]
[Item name]
[Identifier of the item issued by the BuyerCustomer]
AN0000123456
A1
Length
220
```
### Order message confirmation (Buyer -> Seller)
The following example shows a simplification of an order message as response on the changed delivery date.
Example XML Order message confirmation
```markup
1
50
175
accepted
1234
50
5790001398644
Warehoues
Antoon Coolenlaan
1 B
Eindhoven
5644RX
Inkoopafdeling
NL
2019-10-15
[Free-form text instructions for delivery]
[Description of the item]
[Item name]
[Identifier of the item issued by the BuyerCustomer]
AN0000123456
A1
Length
220
```
### Order message deny change (Buyer -> Seller)
Instead of accepting the change, the change might also be rejected. In many cases, the Buyer will reach out to the seller manually (i.e. via phone) in order to come to an agreement. If an order has many order lines, where there is a dispute about only a subset of these order lines, the Buyer might want to indicate that he agrees with some of the lines (and wants that these lines are delivered) but there is no agreement for some of the other lines (so these should be on-hold). This can be indicated using the *disputed*-orderline status code, as is shown in the simplified order message example below.
In the case of an agreement, the Seller can send a new Order response message which should be accepted by the Seller via the previously mentioned flow.
Example XML Order message deny change
```markup
1
50
175
disputed
1234
50
5790001398644
Warehoues
Antoon Coolenlaan
1 B
Eindhoven
5644RX
Inkoopafdeling
NL
2019-10-15
[Free-form text instructions for delivery]
[Description of the item]
[Item name]
[Identifier of the item issued by the BuyerCustomer]
AN0000123456
A1
Length
220
```
## Requesting Order changes
In some cases, the Buyer might want to request changes to its order, for example: adding/revising/cancelling order lines. It should be noted that the Buyer can always request such changed, but the Seller should decide whether to accept/reject the changes. In order to request changes to an existing order, the original Order-message should be send with the following three changes:
* Note that the message ID of the order should equal to the original order message
* Order type should be set to *Changed*.
* The changes itself, e.g. a cancelled line.
### Original Order Message (Buyer -> Seller)
The buyer requests 50 items with ID 1234 on 2019-10-15 in a new order.
Example XML Original Order Message
```markup
123
New
1
50
175
1234
50
5790001398644
Warehoues
Antoon Coolenlaan
1 B
Eindhoven
5644RX
Inkoopafdeling
NL
2019-10-15
[Free-form text instructions for delivery]
[Description of the item]
[Item name]
[Identifier of the item issued by the BuyerCustomer]
AN0000123456
A1
Length
220
```
### Change-request to the previous Order (Buyer -> Seller)
The buyer wants to change the original order by ordering 100 instead of 50 items with ID 1234, all with a changed delivery date: 2019-10-14 instead of 2019-10-15. Note that the *ID* is equal to the original order, the *OrderTypeCode* is set to *Changed*, and the *Quantity* and *RequestedDeliveryPeriod* is changed.
The Buyer can request new items by creating a new orderline with status *added*, cancel an existing orderline with status *cancelled*, and change delivery dates/quantities of an existing lines with status *revised*.
Example XML Change-request to the previous Order
```markup
123
Changed
1
100
175
revised
1234
50
5790001398644
Warehoues
Antoon Coolenlaan
1 B
Eindhoven
5644RX
Inkoopafdeling
NL
2019-10-14
[Free-form text instructions for delivery]
[Description of the item]
[Item name]
[Identifier of the item issued by the BuyerCustomer]
AN0000123456
A1
Length
220
```
### Confirm/Reject the order change (Seller -> Buyer)
The order change can be accepted by the Seller in the same way a new order can be accepted, namely by sending an order response which contains the same information as the order message including *accepted*-OrderLineStatusCodes.
An orderline might also be rejected, this means that the order change of this line has been rejected, the original orderline is still valid! This can be done by simply replacing the *accepted* OrderLineStatusCode with *rejected*.
Example XML Confirm the order change
```markup
678
123
1
100
175
accepted
1234
50
5790001398644
Warehoues
Antoon Coolenlaan
1 B
Eindhoven
5644RX
Inkoopafdeling
NL
2019-10-14
2019-10-14
[Free-form text instructions for delivery]
[Description of the item]
[Item name]
[Identifier of the item issued by the BuyerCustomer]
AN0000123456
A1
Length
220
```
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://smart-connected-supplier-network.gitbook.io/processmanual/use-cases/handle-order-deviations.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.