Following my recent blog on Subcontracting components in an inbound delivery via DESADV IDoc here is another eccentricity of DESADV IDocs processing.
Automatic Packing allows unattended handling units creation both for inbound and outbound deliveries. That works at the delivery creation or can be triggered latter on. This way, fully packed deliveries can be built, even if handling units are not provided explicitly.
That is of utmost importance in Decentralized Warehouse Management (LE-IDW) where goods receipts Link to Quality Management Through Handling Units. In other words a fully packed inbound delivery is a prerequisite for QM inspection lot creation:
The automatic packing can be driven either:
The latter gives unlimited possibilities to build any packing algorithm required.
Recently, I have been implementing an inbound interface with DESADV / DELVRY07 IDocs. Due to LE-IDW integration, the requirement was to have deliveries fully packed. Automatic packing was the obvious choice. To my surprise however it works only partially:
I ran the problem through SAP support. They confirmed my findings – it works with main items; it does not work with batch split items. They also explained why is that so. The culprit is the patchwork design of DESADV IDoc processing. Actually, it creates an inbound delivery in two internal steps:
That is confirmed with the note resulting from my OSS incident: 3067211 – No automatic packing for inbound delivery batch split items
I suggested to add one more step to the DESADV ALE message processing to trigger automatic packing after batch split items are created. That was rejected on the grounds that the current implementation is already complex and fragile enough and the of risk adding yet another piece to the puzzle is too big. I can understand that from the technical stand point. However, I was still disappointed as an SAP user.
The note suggests at least two possible workarounds.
One is to build DESADV / DELVRY07 IDoc, so it does not contain any batch split items. That is perfectly doable as all necessary information about batches being delivered can be provided with main items. Batch split items are a bit superfluous here. The solution is implementable if you have control over how DESADV / DELVRY07 IDocs are constructed and sent to your system. For instance in case of an integration with an external vendor. That can be handled either in the middleware layer that builds the IDocs or with the IDoc processing BAdI enhancement.
This solution may prove difficult to implement however in the scenarios where the middleware is not available or where you do not really want to interfere with the IDoc structure – for instance in the Stock Transfer Between Distributed Systems (SD, MM) process that spans two SAP ERP or S/4HANA instances:
Here, an outbound delivery (7) possibly containing batch split items is sent with DESADV IDoc (8) and creates an inbound delivery (9). As both sending and receiving SAP systems use standard IDoc messages, translating batch split items to main items is counter intuitive.
Thus, the second workaround can be used in this case. The solution is to call automatic packaging of the inbound delivery once it is already created by SAP standard DESADV IDoc processing. Even though there is no BAPI function to trigger automatic packing, it is fairly easy to implement it with a simple BDC call to the VL32N transaction – I know, BDCs are out of fashion now, but it is still better than nothing. The BDC call can be wrapped in a custom function module or procedure and called once the inbound delivery is created by the IDoc.
The drawback of this approach is that the creation and the automatic packing of an inbound delivery are not executed as one atomic operation, in one logical unit of work. Therefore, it requires a bit of monitoring to ensure all the inbound deliveries are indeed packed automatically.
Soon, I am going to explain how to implement the second workaround with a custom output type automation.
Stay tuned – my blogs
Okumaya devam et...
Context
Automatic Packing allows unattended handling units creation both for inbound and outbound deliveries. That works at the delivery creation or can be triggered latter on. This way, fully packed deliveries can be built, even if handling units are not provided explicitly.
That is of utmost importance in Decentralized Warehouse Management (LE-IDW) where goods receipts Link to Quality Management Through Handling Units. In other words a fully packed inbound delivery is a prerequisite for QM inspection lot creation:
LE-IDW goods receipt with QM integration. Source: SAP Help
The automatic packing can be driven either:
- by packing instructions and packing instructions determination conditions or
- by a custom logic implemented with BADI_HU_AUTOPACK enhancement.
The latter gives unlimited possibilities to build any packing algorithm required.
Problem statement
Recently, I have been implementing an inbound interface with DESADV / DELVRY07 IDocs. Due to LE-IDW integration, the requirement was to have deliveries fully packed. Automatic packing was the obvious choice. To my surprise however it works only partially:
- If an inbound delivery contains main items only i.e. items numbered 10, 20, 30 etc., automatic packing works perfectly.
- However if an inbound delivery contains also batch split items i.e. items numbered 900001, 900002, 900003, it does not work.
I ran the problem through SAP support. They confirmed my findings – it works with main items; it does not work with batch split items. They also explained why is that so. The culprit is the patchwork design of DESADV IDoc processing. Actually, it creates an inbound delivery in two internal steps:
- The first step calls the GN_DELIVERY_CREATE function to create an inbound delivery and its main items. The function supports automatic packing, which is why it works fine if batch split items are not provided in the IDoc.
- The second step adds batch split items with the WS_DELIVERY_UPDATE function. It does not provide automatic packing. So, DESADV IDoc with batch split items, no automatic packing.
That is confirmed with the note resulting from my OSS incident: 3067211 – No automatic packing for inbound delivery batch split items
I suggested to add one more step to the DESADV ALE message processing to trigger automatic packing after batch split items are created. That was rejected on the grounds that the current implementation is already complex and fragile enough and the of risk adding yet another piece to the puzzle is too big. I can understand that from the technical stand point. However, I was still disappointed as an SAP user.
Possible Workarounds
The note suggests at least two possible workarounds.
One is to build DESADV / DELVRY07 IDoc, so it does not contain any batch split items. That is perfectly doable as all necessary information about batches being delivered can be provided with main items. Batch split items are a bit superfluous here. The solution is implementable if you have control over how DESADV / DELVRY07 IDocs are constructed and sent to your system. For instance in case of an integration with an external vendor. That can be handled either in the middleware layer that builds the IDocs or with the IDoc processing BAdI enhancement.
This solution may prove difficult to implement however in the scenarios where the middleware is not available or where you do not really want to interfere with the IDoc structure – for instance in the Stock Transfer Between Distributed Systems (SD, MM) process that spans two SAP ERP or S/4HANA instances:
Distributed stock transfer process. Source: SAP Help
Here, an outbound delivery (7) possibly containing batch split items is sent with DESADV IDoc (8) and creates an inbound delivery (9). As both sending and receiving SAP systems use standard IDoc messages, translating batch split items to main items is counter intuitive.
Thus, the second workaround can be used in this case. The solution is to call automatic packaging of the inbound delivery once it is already created by SAP standard DESADV IDoc processing. Even though there is no BAPI function to trigger automatic packing, it is fairly easy to implement it with a simple BDC call to the VL32N transaction – I know, BDCs are out of fashion now, but it is still better than nothing. The BDC call can be wrapped in a custom function module or procedure and called once the inbound delivery is created by the IDoc.
The drawback of this approach is that the creation and the automatic packing of an inbound delivery are not executed as one atomic operation, in one logical unit of work. Therefore, it requires a bit of monitoring to ensure all the inbound deliveries are indeed packed automatically.
Soon, I am going to explain how to implement the second workaround with a custom output type automation.
Stay tuned – my blogs
Okumaya devam et...