With the subsequent outbound delivery split, you have a new function at your disposal with which you can split a delivery into several new deliveries in only one step. As soon as you have entered the required split criteria, the system performs the reduction of the delivery quantity in the original delivery and the distribution of the split items or quantities into the new deliveries.

You can execute this delivery split also in a decentrally managed Warehouse Management system and afterwards have the changes to the delivery posted in the ERP system using the BAPI "OutboundDelivery.SplitDecentral". This BAPI is called up before the outbound delivery is verified from the WM system.

If you wish to implement the subsequent outbound delivery split in a decentralized WMS, you must configure the following settings in the Customizing application:

With the function for subsequent outbound delivery split, it is possible to split existing deliveries into several other deliveries. Here, too, new outbound deliveries can occur in a decentralized system that will need to be created in the central ERP system also when processing is complete. The newly assigned delivery numbers must not yet be assigned in the central system. You must ensure, with the help of appropriate settings for the number range intervals in IMG, that all the delivery numbers that communicate in all the decentralized systems with an ERP system are unique numbers. You can decide per delivery type that the new delivery numbers are taken from a separate number range interval. Here you can set the number range intervals per warehouse number and per delivery type (see above). Or you can use the number range intervals that you have set in the ERP system in the decentralized systems if you maintain the upper and lower limits as not overlapping.

To verify the split outbound deliveries or the original outbound deliveries (from which new deliveries have been created using the split procedure), the system searches for a reference delivery that is used in the central system for reposting the split. The system also blocks this reference delivery when posting the goods issue of a split delivery to keep data consistent. You can prevent this block from being set if it causes limitations in parallel processing of the deliveries (for example, when confirming transfer orders). You must then ensure, from an organizational point of view, that deliveries are not posted for goods issue in parallel or changed in any other way the same time.

When you post the goods issue for an outbound delivery, the system checks whether the delivery is involved in a split process. This is the case whenever the original delivery is the delivery that was created already in the ERP system or whenever a "split delivery" was created first in the WM system by the split. Here it is not important whether you did the split from the original delivery or from a delivery that itself was already split. If a split delivery has been posted for goods issue, the new delivery is created using the BAPI "OutboundDelivery SplitDecentral" from the original delivery (or "reference delivery", see below). If the original delivery has been posted for goods issue, already now the system creates in the ERP system through the BAPI "OutboundDelivery SplitDecentral" – for all further calls -- one of the new deliveries that were split in the WM system Once the original delivery is posted for goods issue in the ERP system, this delivery will adopt its role and serve as the reference delivery for all further delivery splits so that further outbound deliveries are split from it. This reference delivery contains all the items that the original delivery contains, even if the delivery in the decentralized system only contains some of them. After verification of the reference delivery has taken place, the quantity of all items that do not contain this delivery in the decentralized system is set to 0.

Serialization of output (IDocs) for outbound deliveries that are transmitted from a WM system to the ERP system make sure that the outbound delivery split is executed before the goods issue posting. For this purpose, the delivery numbers must be represented by a four-digit channel number. It can happen that the system does not process a delivery output because another output in the same channel is not yet processed fully, although the deliveries in the output are not connected (by a delivery split) and can be processed independently of one another. You can call up an overview of the serialized outputs in the inbox via the SAP menu path: Tools ® ALE ® ALE administration ® Services ® Serialization ® Serialization using Business Objects ® Display Serialized IDocs..

• Item numbers re-assigned in new delivery
• Delete ordinary items with quantity 0 (in the decentralized systems, no items can be deleted generally)
• Delete items from delivery groups if quantity 0
• Check number of partial deliveries during delivery split
• Splitting delivery groups not allowed

• Check for full delivery during delivery split
• Control during split of correlated bills of material
• Automatic copy of text item with quantity 0
• No 1->1 split