Performing Deliveries Using Unchecked
Deliveries 
Use
When you save a sales order, the system requests a delivery item with an open quantity to be delivered for each schedule line. The date and quantity are copied from the schedule line into the interface to create a delivery item, and to supplement shipping-relevant data for the item and the order. Delivery quantities from unchecked delivery items count as open quantities to be delivered.
When you save the order you have created, the system simultaneously (but not asynchronously) creates an unchecked delivery item for each delivery date. The delivery item is created for order items with confirmed quantities using the confirmed quantity at the confirmed delivery date. This does not involve a new transaction. In fact, the unchecked delivery is created in the background.
In the two-system case, the unchecked delivery replaces the shipping due date index. In APO it takes on the requirements from the sales order.
Process Flow
...
1. The IDoc Deliveryprocessing_execute, including the data from the sales order, is sent by the selling system to the shipping system.
2. The IDoc is processed in the shipping system according to your settings in ALE Customizing.
3. An unchecked delivery is created in the shipping system according to the delivery date set in the sales order. As in the integrated scenario, where you can create several deliveries for a sales order, in this scenario you can also create several unchecked deliveries for a sales order (split criteria). No unchecked deliveries are created for unconfirmed remaining quantities.
4. The unchecked delivery is transmitted to the APO system using the integration model (APO Core Interface). The APO system receives the number of the corresponding sales order item for each delivery item as a reference. The system then creates requirements for the unchecked delivery in the order network of the APO system. Additionally, the requirements for the referenced sales order item are deleted.
5. The system also creates a requirement for the unchecked delivery in the shipping system. The requirement in the unchecked delivery has a different MRP indicator than the requirement in the delivery (see Category in APO). Therefore, the unchecked delivery in the shipping system and in the availability check in the APO system are displayed separately in the requirements overview. The system does not perform an availability check for the unchecked delivery. The ATP check can also differentiate unchecked deliveries from deliveries. The unchecked delivery is included in the Checking Rule as a sales requirement. In the APO system, the unchecked delivery offsets itself against the sales order requirement.
6. The requirement in the unchecked delivery allows for local MRP in the shipping system.
7. You convert the unchecked delivery into a delivery in the shipping system. Use either Collective Processing of Unchecked Deliveries (VL06U) or Collective Processing of Documents Due for Shipment for Cross-System Deliveries (VL10U). The same checks are run as for conventional delivery creation.
In this scenario, the shipping system possesses the following limitations in contrast to the integrated scenario:
¡ No discounts in kind.
¡ No credit limit check in the delivery.
¡ Statistics updates of order data using the delivery are not realized.
¡ A complete delivery does not take place because of the complete delivery indicator. A complete delivery must be processed using delivery groups and the partial delivery arrangement C (no partial deliveries permitted).
¡ You cannot reschedule or backorder process items and unchecked deliveries.
8. An ATP check is performed in APO for the delivery. Any relevant changes are saved in the APO system. Depending on the available quantity reported by APO to the shipping system, the following processes can result in the delivery:
¡ Everything available
¡ Reduced quantity
The delivery writes a delivery requirement in both the shipping and APO systems. The requirements in the unchecked delivery are deleted from both the shipping and APO systems. Depending on your settings in the Completion Rule (see below), the system creates new unchecked deliveries for the remaining quantities.
9. The delivery confirms the delivery quantities to the sales order. The system then updates the status and document flow for the sales order.
10. You can perform all the follow-on functions, such as picking, packing, and goods issue as you would in the integrated scenario. All changes to the delivery are automatically reported to the ordering system.
Order:
Item 1 |
Material 4711 1. Schedule line delivery date 6.1 2. Schedule line delivery date 15.6 |
Item 2 |
Material 4712 1. Schedule line delivery date 6.1 |
The transition to an unchecked delivery is as follows:
1. Unchecked Delivery |
Item 1 Item 2 |
Material 4711 1.6. Material 4712 1.6. |
2. Unchecked Delivery |
Item 2 |
Material 4711 15.6. |
If any unconfirmed remaining quantities are left in the order after Rule-Based ATP Check (for example, location determination), and if these are displayed as sub-items without confirmed quantities in the order, then you can make Customizing settings to place these remaining quantities in the original plant requested. If the requested plant in the ordering system also has a shipping processing, then no cross-system delivery is created for the unconfirmed remaining quantity. If the item is a cross-system item, then the system does not create an unchecked delivery in APO for the unconfirmed remaining quantity from location determination.
The unchecked delivery writes requirements. This allows for local MRP in the delivering ERP system. MRP in APO is also based on the requirements from the unchecked delivery.
Clearing with the Corresponding Sales Order
Because no requirements clearing takes place in the delivering ERP system between the unchecked delivery and the order, the ERP system does not transmit any cleared order requirements to the APO during updating of the unchecked delivery, as it would otherwise do in the integrated scenario with only one ERP system. Instead, the data transmitted to APO contains the requirements from the unchecked delivery with unique information about the referenced order item. As a result of this previous information, the APO system is able to offset the requirement from the referenced item in the liveCache.
The planned independent requirement clearing in the multi-system scenario is different from the integrated scenario involving one ERP system (here, the system also makes offsetting postings against the original customer requirement element after the delivery is created. The customer requirement element contains the requirement quantity for offsetting against the planned independent requirement). This is realized using the standard delivery for category QTY. In other words, billing for the planned assignment required quantity in the sales order. If, for example, you want to perform planning in PP/DS for confirmed quantities, you must delete category QTY. In addition, by deleting this category in the SAP APO system, you can define that deliveries from the category ULIEF can also flow into independent requirements clearing.
Converting Unchecked Deliveries into Checked Deliveries
Converting the unchecked delivery into a checked delivery involves changing a delivery with regards to its scope of check and does not involve creating a new delivery. The systems performs any missing checks that were explicitly switched off when you were creating the unchecked deliveries.
These are as follows:
· Delivery block at goods recipient
· Availability
· Delivery qty.
¡ Quantity 0 permitted
¡ Minimum quantity
¡ Size
¡ Delivery tolerance against the requested quantity for this item
¡ Partial delivery agreements against the requested quantity for this item
· Dangerous goods check
· Maximum weight for the means of transport type exceeded
A status indicator in the document marks the difference between the unchecked delivery and the checked delivery. There are no other differences. In particular, there is no new document.
You cannot convert only some of the items in a document whilst leaving others with the status Unchecked. Any non-convertible items are deleted. Where necessary after confirmation of the delivery, the order creates new unchecked deliveries for the missing quantities (when the order item is not ‘completed’ using the completion rules). Communication with the order takes place using ALE (IDoc SALESORDER_CONFIRMDELIVERY).
You can perform conversion of unchecked deliveries to deliveries using the Collective Processing of Unchecked Deliveries (VL06U) or using Collective Processing of Documents Due for Shipment for Cross-System Deliveries (VL10U).
The conversion also changes the requirement type. The delivery created writes a delivery requirement in the delivering system. When you save the delivery, the requirement from the unchecked delivery in the delivering system (and/or in APO) is completely deleted, and the requirement is replaced by a requirement for the available quantity. The system only performs another requirements allocation when requested by the corresponding order item, when this item receives confirmation of the checked and delivered quantity, and when the item uses the delivery tolerances and completion rules to decide whether there is an open remaining quantity.
Whilst you are converting the delivery into an outbound delivery, you can simultaneously perform automatic batch determination in the delivery.
Partial Delivery Agreements
If, when you create an order item, it has already been decided that several partial deliveries should be created (more than one delivery line), then the system creates an unchecked delivery item for each partial quantity. This decision must be consistent with the partial delivery agreements (for example, there must not be more schedule lines than the maximum number of permitted partial deliveries).
The current mixed functions for partial delivery agreements in integrated systems (including a partial delivery/deleting the delivery requirement for a remaining quantity) will be split into parts. The quantity of a material that should be delivered on a certain date is marked as the requested quantity in the delivery item. The partial delivery agreements in the delivery check the actual delivery quantity against this requested quantity. Partial delivery agreements that affect more than one delivery (for example, the number of partial deliveries for an order item), are not checked during processing of the delivery. The agreements are evaluated in the order after confirmation of the delivered quantities.
In detail: Completion rule:
Integrated
Space |
Any partial quantities. Completed with total delivery quantity = Requested quantity |
‘A’ |
A delivery item with a quantity greater than zero completes the order item |
‘B’ |
A delivery item completes the order item |
‘C’ |
The order item receives a delivery for the total quantity of one item. |
‘D’ |
Any subsequent delivery |
Cross-System, New Procedure
Condition for the outbound delivery of this item:
Space ‘B’ ‘D’ |
The delivered quantity can vary as much as you want from the requested quantity. The order decides whether there is an open quantity to be delivered after confirmation of the delivered quantity. The order triggers this delivery in the same manner as when you create or change an order. Differences in the delivered quantity are only permitted within the delivery tolerances, where required (see below). |
‘A’ |
The delivered quantity must be greater than 0. Example available quantity = 0: When converting an unchecked delivery item into a checked delivery item, the unchecked delivery item is deleted. The system does not create a checked delivery item. After confirmation, the order sends another request for delivery of this item. |
‘C’ |
The delivered quantity must not be less than the requested quantity |
Closing after confirmation in the order:
Space ‘D’ |
The difference from the requested quantity in the schedule line and the delivered quantity is delivered again on the schedule line date. |
‘A’ ‘B’ ‘C’ |
A created delivery item completes the order item. No new availability check. No requirements. There cannot be any other unchecked delivery items, because there was only one schedule line. |
· Underdelivery tolerance
Checks at completion as before in the order. The system performs the checks of delivered quantity against requested quantity when converting unchecked deliveries into checked deliveries. The system outputs a controllable error message when the quantity falls short of the underdelivery tolerance. This check is not performed when changes are made, since this can result in inconsistencies.
· Overdelivery tolerance:
No overdeliveries can occur during conversion.
· Delivery groups
The system checks whether all items in a delivery group are included, and if the quantity relationships correspond correctly to the bill of materials. These checks occur when the delivery is converted, as well as when it is changed.
· Maximum number of partial deliveries:
Evaluation only in the order. If the maximum number of partial deliveries has been reached for a delivery item and there are still unchecked delivery items remaining, then after confirmation the order informs the LES that all unchecked delivery items for the completed order item should be deleted.
Quantity Correlation
You can perform quantity correlation of BOMs during conversion of unchecked deliveries into deliveries, when the BOM is contained within a delivery group and the component relationship for each BOM item is also specified (the component relationship is the quantity relationship in the base unit of measure of the sub-item to the main item in the order).
Availability Check for the Delivery
Availability checks on the delivery are performed in the supplying system using the ATP controller. The ATP controller calls the APO server (in the supplying system) to perform the check.
When converting the unchecked delivery, the ATP check is performed for all items using the checking rule from the delivery. When checking the item, the system calculates the requirement belonging to the unchecked delivery item.
The new availability check for existing deliveries is performed using the standard functions.
No scheduling takes place within the availability check for the delivery. However, if scheduling is required within the delivery availability check for customer-specific enhancements (for example, checks for complete delivery with reschedulung), then the rescheduling should also run in the APO system during an ATP check in APO.
Changing Unchecked Deliveries:
An unchecked delivery item can only be changed using the corresponding preceding document (here, the sales order, see Changing Deliveries). Otherwise, the conversion to a delivery constitutes a change.
Writing the Changes to the APO System
When the unchecked delivery has been converted and you save the checked delivery, the requirements from the unchecked delivery to be deleted and the requirements generated from the delivery are transmitted to APO. The APO system can then comprehend the requirements postings in the delivering ERP system.
Delivery Confirmation to the Corresponding Sales Order
When you save a checked delivery, the system sends a confirmation to the order.The order then recognizes the delivery date and quantity of each item from any checked deliveries created with reference to an item from the order. The order is then able to update its document flow, calculate its status with reference to the delivery, and perform closing. If, during this process, the system recognizes that order items with open quantities are present and are planned for delivery, then it triggers creation of an unchecked delivery and/or increases the quantity in an existing unchecked delivery. If the system recognizes that an order item is already complete, but that an unchecked delivery still exists, then the system deletes this unchecked delivery.
Communication with the Billing Document
Customer billing documents are generated from the ordering system with reference to orders. You use the new transaction VF08. The billing index is written if you have set the relevant indicator in the document flow for the order. Billing documents are created based on this index. The necessary data from the delivery is read in the supplying system (mass processing, therefore only one call for each system).
The process of transferring the cost of sales from the internal billing document is described in Process from the Accounting Point of View.
You cancel the billing document as in the current standard system.
The index for the internal billing document in third-party business is already written as a standard in the supplying system. Internal billing documents are created as standard.
In both the standard and integrated scenarios, the billing document print does not read any delivery data. The structure made available for customer-specific enhancements will be extended to make available the delivery number, the delivery item, and the logical system of the delivery. Accordingly, you can then read the delivery in the supplying system.