Technical Articles
Subcontracting components in an inbound delivery via DESADV IDoc
Context
Subcontracting purchasing with inbound deliveries used to be a paint due to problems with components provided to vendor processing – see the notes:
- 645119 – Problems for subcontracting using delivery
- 338119 – Goods receipt in inbound delivery for SC order
That was mostly for batch managed components as their consumption is not executed in a dialog mode during goods receipt posting to a subcontracting inbound delivery. Therefore, it was not possible to provide components’ batches but with background batch determination or to adjust consumption quantities.
One of the workarounds was to decouple subcontracting goods receipt and components consumption with the modification from the note 654613 – Batches and goods receipt for inbound delivery for provision of materials for subcontract order. Not the perfect solution but better than nothing.
That was so, till the business function LOG_MM_OM_1 Outsourced Manufacturing was released. It brought:
Subcontracting Components in Inbound Deliveries
You can use this business function to enter subcontracting components in the inbound delivery, or you can fill the subcontracting components using a shipping notification from the supplier. This enables you to assign information about the batches used and the component quantities in the inbound delivery. Subsequent goods entry is booked automatically with these entries. Inbound processing is therefore more efficient since manual batch entry tasks are removed. This improves batch tracking for the sold-to party.
Subsequently, the IDoc inbound scenario DESADV / DELVRY07 was enhanced to support subcontracting components in inbound deliveries communicated electronically – the note 1397948 – Subcontracting: Components cannot be provided using IDoc /SPE/IDOC_INPUT_DESADV1
So far so good…
Problem statement
The problem with the above solution is that subcontracting components quantities transferred with DESADV / DELVRY07 message get fixed in the inbound delivery. That is confirmed by the note 1397948 – Subcontracting: Components cannot be provided using IDoc /SPE/IDOC_INPUT_DESADV1
The fixed quantity indicator is always set automatically for all components, so that no correlation occurs for the component quantities when changes are made to the inbound delivery quantity.
Why is that a problem…
Business impacts
Imagine the following, quite typical scenario.
A subcontractor provides a product on pallets and they notify a shipment of a full truck load, of say 30 pallets. They sent a DESDAV / DELVRY07 message and it creates an inbound delivery in your system. Now, during unloading you realize that 3 pallets are missing. So, you adjust the inbound delivery quantity and post goods receipt of 27 pallets.
As the components quantities are fixed by SAP standard DESADV processing logic, the goods receipt of 27 pallets consumes the components of the entire 30 pallets!!!
That has the following effects:
- The stock of the components provided to vendor is reduced as if the entire 30 pallets are shipped. Depending on the case it may be correct or not. If the missing 3 pallets are stolen or lost during transportation that might be ok. However if they have never been shipped due to a loading problem on the subcontractor side, that is definitely not ok.
- A subcontracting product is valued with the price of the service plus the cost of the components. Therefore the 27 pallets received will be 10% more expensive than planned. Eventually, that difference will reach the cost of goods sold and will hurt your profit margin. Again, that is not necessarily bad, depending on your accounting policies and the specific case. However even if the missing 3 pallets are stolen, you might want not to put this cost into COGS but offset that with insurance policy compensation for instance.
Conclusion
In my opinion the business life is richer and more complex than the simplistic approach of SAP standard here. But SAP does not give here any flexibility. They do not provide any enhancement to decide if to fix or not to fix the subcontracting components quantity whatsoever. Again that is confirmed by the note 1397948 – Subcontracting: Components cannot be provided using IDoc /SPE/IDOC_INPUT_DESADV1:
If, contrary to the standard design, you want an automatic correlation, this is only possible by making a modification in the class CL_SHP_LECOMP_CONTROL, method IF_EX_SHP_DESADV_IN~PROCESS_SEGMENT. (ls_comp-fmeng = abap_true)
It would have been nice if SAP had provided a BAdI enhancement here. Unfortunately they did not.
Be aware of this nuance when implementing electronic communication of inbound deliveries in subcontracting scenarios. It is likely to slip through tests and bite you only down the road. Also it might be quite hard to spot at the first glance.
Read my other blogs here
Good Morning Master!
It's a very good blog - thank you! I'm looking forward for the next ones 🙂
Best Regards,
Marek
Thanks for sharing. Very useful content 🙂
BR,
Jakub
Thanks for sharing with us. Really its very useful for content
Hi
Can we send Serialized component details as well in DESADV?
Prasanna
Yes, you can - see Delivery Interface:
Source: SAP Help
Best regards
Dominik Tylczynski
Thanks , My scenario is as below
Is this possible? if yes do you have example idoc
Prasanna
My previous response was more about serial numbers on inbound delivery item level, not on subcontracting component level.
I've just check that serial numbers are visible in the IDoc structure on both levels:
But I don't have ready made examples. Try to test the IDocs with WE19 transaction.
Make sure to implement the note 1397948 - Subcontracting: Components cannot be provided using IDoc /SPE/IDOC_INPUT_DESADV1 if you work with subcontracting components in DESADV IDocs.
Thanks , will test this
Prasanna
Hi
Created a OSS message for the same and SAP confirmed that Serial number can't be added through IDOC for Inbound delivery created for sub-con PO , only Batches can be added.
Prasanna
Hello Dominik,
Your post is very nice and helpful for anyone dealing with a subcontracting scenario.
However, I'm currently facing an issue with the DESADV IDoc in a subcontracting scenario.
We are attempting to implement DESADV IDoc to transmit inbound delivery information to the external system using the basic type DELVRY01. However, since this basic type does not support the subcontracting component, we have switched from DELVRY01 to DELVRY07 to include the component details. Despite this change, the E1EDL58 segment is still not appearing in the parent segment E1EDL24.
The segment E1EDL58 is available when creating an IDoc through WE19, but it is not present when triggered from an inbound delivery.
Additionally, when attempting to implement note 1397948 through SNOTE, it shows an error stating that it cannot be implemented due to being in a higher version.
Could you please provide some insights into this situation? I'm wondering if there is something I may be overlooking.
Regards,
Suresh
Hello Suresh S
The article is about the inbound DESADV IDoc scenario, i.e. when an inbound delivery is created by a DESADV IDoc. Also the 1397948 - Subcontracting: Components cannot be provided using IDoc /SPE/IDOC_INPUT_DESADV1 note is about the inbound scenario.
Your question is however about an outbound IDocs, i.e. an inbound delivery already exists and it is transmitted to an external system with DESADV messages. The DELVRY07 IDoc type does contain subcontracting components segments. However they may not be filled as it depends entirely on the program that creates an outbound DESADV message from an inbound delivery.
Therefore the basic question is how you created DESADV IDocs from inbound deliveries. Without knowing that it is all but impossible to help you.
Best regards
Dominik Tylczynski
Hello Dominik,
Thanks for your response..
The outbound IDocs are triggered through output type configured for Inbound deliveries. The following are the settings we have made in our system.
WE20 Settings:
Message Type: DESADV
Basic Type: DELVRY07
Receiver Port: WMESB
Message Control - Application: E1
Message Control - Message Type: Z015
Message Control - Process Code: DELV
Please let me know if you need more information.
Regards,
Suresh
Hello Suresh S
So you are using the DELV process code that calls the IDOC_OUTPUT_DELVRY function to build DESADV messages:
That is predominantly used for outbound deliveries, which is why the function does not handle subcontracting components and does not build E1EDL58 / E1EDL59 segments in standard.
However you can easily enhance the process and build the segments with EXIT_SAPLV56K_002 user exit.
Best regards
Dominik Tylczynski
Hello Dominik,
Thank you so much for analyzing and providing the solution. We will seek the assistance of an ABAP developer to enhance the basic type and construct the E1EDL58 segment.
Regards,
Suresh
Hello Dominik,
Thank you for the explanation. We are using DESADV with baisc type DELVRY07. Process code used is DELS and we updated the FM to be IDOC_INPUT_DESADV1. At the moment, in the IDOC we see segment E1EDL58 with fields KDMAT, CHARG_KU ERFMG, ERFME. When we pass the Idoc, it only takes the Main material as the input and posts the IBD. The IBD contains component materials as well. However, our requirement is to pass the component materials as well in the Idoc and make changes to their quantity. Please let us know how we can achieve this. Do we still need to implement the note you have mentioned?
Thank you and regards,
Pranav Patil
Hello Swapneel Shetkar
You definitely need to implement the note 1397948 - Subcontracting: Components cannot be provided using IDoc /SPE/IDOC_INPUT_DESADV1 and use the /SPE/IDOC_INPUT_DESADV1 function to process the IDocs. I don't think the function IDOC_INPUT_DESADV1 supports subcontracting components.
Hello Dominik,
Thank you for the assistance. We will check with our development team on your solution.
Hello Dominik,
This is not related to the Sub-Contracting process, but I still need your advice on this.
Message Type: DESADV
Basic Type: DELVRY07
The IDocs are triggered from inbound deliveries created from an account-assigned purchase order (Account assignment - M) and sent to an external system. The account assignment details (Sales order) are not available in the DESADV IDoc. Is it not part of the standard IDoc structure? Do we need to include an enhancement to insert a custom segment to capture sales order details?
Please advise.
Regards,
Suresh
Hello Suresh S
First, you need to understand that IDoc type is just a data structure definition. The fact that an IDoc type features a segment or a field in the segment, does not necessarily mean that this segment will be populated when an IDoc is generated. It all depends on the program generating IDocs, how the IDoc segments are populated.
Second, inbound delivery is a logistics document, so I don't think that it transfers accounting information e.g. account assignment data.
Third, outbound DELVRY07 and DESADV are used mainly for outbound deliveries. Typically an inbound delivery is received (an inbound IDoc) not sent (an outbound IDoc).
Nevertheless I think you can transfer sales order information in your DESADV message for inbound deliveries, with a little help of a custom enhancement. There is a E1EDL43 segment on the item level that can transfer delivery items references:
Reference type is designed by the QUALF field. You have the following values there:
The value C is for a sales order.
So you can send required information in this segment. Most probably the segment is not populated by the standard IDoc program. So you'd need to build a custom logic here with the EXIT_SAPLV56K_002 enhancement.
Make sure to align with recipients of the message, how they know how to extract purchase orders from the IDocs.