!--a11y-->
Consequences of Changing Sales
Orders 
The allocation function in sales order maintenance treats future receipts like normal stock. Allocation and deallocation processes are the same for all types of stock, including future receipts. So if the confirmed quantity is decreased, the corresponding assignments will be adjusted. If critical data is changed (material or size), the corresponding assignments will be deleted completely. Changes in the confirmed date can also cause a deallocation.
If the planned future receipt date runs out of scope due to one of the above changes, the corresponding assignments are deallocated.
When you deallocate a purchase order, all allocated sales orders will be locked. If one sales order cannot be locked, the system generates an error message. The purchase order can only be processed when the locked sales order is unlocked. If the quantity is reduced and a sales order cannot be locked, the next sales order will be deallocated.
Whenever a change is made to a material, size or plant in a sales order, the stock is always deallocated. However, in Customizing for Sales Orders, you can specify whether or not changes to the following fields in a sales order will automatically result in deallocation:
· Storage location
· Requirement category
· Batch
In addition you can define safety windows for each stock type for deallocation. If a schedule line delivery date changes so that the new confirmed date does not match the safety window of an allocated stock type, all corresponding assignments are deallocated.
In ARun Customizing for sales orders, you can define how the system sorts assigned stock when performing deallocations. For example, if you want to sort first by MRP status, then by stock type, then by schedule line confirmed date, you would make the following entries:
Sort field |
Priority |
Sort descending |
J_3ASTAT |
1 |
|
J_3ABSKZ |
2 |
|
EDATU |
3 |
|
By selecting Sort descending flag, you can reverse the sort order for a given field. For example, if you check this field for the allocation run number (ARUN), the system deallocates the most recent assignments first.
In Customizing for ARun handling of SD documents, you can assign certain release rules for different types of sales documents.
If you have an existing sales order schedule line to which future receipts have already been allocated, subsequent changes to the sales quantities can affect allocation status. To avoid this, the Release Rule field provides a second release rule check after changes have been made to a sales document. The system runs this check when the sales document is changed and saved. The field is not specific to future receipts only.
If you have assigned both an ARun type plus a special release rule to a sales document type, the special release rule always would overrule the release check rule of the ARun type.

Suppose you have a requirement for 100 pieces. The release rule for the customer is 80%. During an allocation run, the system finds batch stock of 80 pieces and it allocates them to the requirement. Because 80 pieces are sufficient, the allocation passes the release check and gets the Fixed MRP status (F).
Sometime after the allocation run, the sales quantity in the sales order is increased to 120 pieces. If there were no subsequent release rule checks, the order would be scheduled for delivery, even though 80 pieces is no longer sufficient to meet the 80% requirement. However, the system does check the release rule again and sees that 96 pieces are needed, not 80. This time it fails the release check and therefore the MRP status of the allocation changes to Reserved(R).