Inbound Delivery : Automatic Creation from Outbound Delivery
Introduction: This Document purviews various approaches to setup inbound delivery in SAP. Inbound delivery is delivery pertaining to incoming good. It’s Different from Outbound delivery in sense that outbound delivery encompasses scenario when goods move out of a plant, whereas inbound delivery is about receipt of goods. Thus inbound delivery is created at receiving entity.
Problem Statement: If Purchase order is created by receiving party, then for that corresponding outbound delivery is created by supplying party. But receiving party doesn’t get much visibility of shipment of goods till they actually receive it. This Situation becomes more difficult when there is long distance shipment involve across countries or continents. In such long journey, there can be delays/issues due to any reasons. Receiving party remains oblivious of up to date situation of goods transit. Receiving party would like to ensure that they always have real time updates of goods movement.
Solution: To overcome this requirement a concept of inbound delivery can be used. An inbound delivery can be triggered automatically once post goods issue is done for outbound delivery. Thus outbound delivery serves as a reference document for inbound delivery and details can be seen in Purchase order through confirmation controls. Also any update in outbound delivery, would be updated in inbound delivery.
Solution Approach:
There could be two approaches to create inbound delivery from outbound delivery automatically, once Post Goods Issue is done.
1) Use standard SAP output type – SPED.
2) Use iDOC through EDI medium
Features |
SPED |
IDOC |
|
|
|
Same system / cross system |
SPED output type is used when both entity are using the same SAP system. |
IDOC Approach can be used within same system and cross systems as well. |
Document flow updated |
SPED output type automatically updates document flow of outbound delivery with inbound delivery information. |
IDOC automatically updates document flow of outbound delivery with inbound delivery information. |
Approach 1: – SPED
Step 1)If your system doesn’t contains output type SPED, then manually create it.
SPRO > Logistic Execution > Shipping > Basic Shipping Functions > Output Control > Output Determination > Maintain Output Determination for Outbound Deliveries > Maintain Output Types
T.Code – V/34
Step 2)Assign SPED to Output Determination Procedure
SPRO > Logistic Execution > Shipping > Basic Shipping Functions > Output Control > Output Determination > Maintain Output Determination for Outbound Deliveries -> Maintain Output Determination Procedure
Step 3) Create Condition Record for SPED
Logistics > Logistics Execution > Master Data > Output > Shipping > Outbound Deliveries > Create
T.Code – VV21/22/23
Step 4) Confirmation Control
SPRO > Material Management > Purchasing > Confirmations > Set up confirmation control
Confirmation Control key must be selected on the confirmation control tab at item level in Purchase Order. Make sure to check GR-Relevant and GR Assignment key for control key.
To ensure automatic selection of confirmation control in Purchase order, maintain relevant entry in purchase info record, otherwise manually select it in Purchase Order.
Logistics > Materials Management > Purchasing > Master Data > Info Record > Create
T.Code – ME11/12/13
Step 5) Assign Goods Receiving Points for Inbound Deliveries
SPRO -> Logistics Execution -> Shipping -> Basic Shipping Functions -> Shipping Point and Goods Receiving Point Determination -> Assign Goods Receiving Points for Inbound Deliveries
Assign shipping point as a good receiving point for combination of plant and storage location.
Approach 2: – iDOC
Step 1) Output Type for Delivery
Create new output type or modify the existing one
SPRO > Logistic Execution > Shipping > Basic Shipping Functions > Output Control > Output Determination > Maintain Output Determination for Outbound Deliveries > Maintain Output Types
T.Code – V/34
Assign output type to Output Determination Procedure
SPRO > Logistic Execution > Shipping > Basic Shipping Functions > Output Control > Output Determination > Maintain Output Determination for Outbound Deliveries -> Maintain Output Determination Procedure
Maintain Requirement as “1”, so that output is triggered only when Post Good Issue is done.
Create Condition Record for Output Type
Logistics > Logistics Execution > Master Data > Output > Shipping > Outbound Deliveries > Create
T.Code – VV21/22/23
Step 2) Confirmation Control
SPRO > Material Management > Purchasing > Confirmations > Set up confirmation control
Confirmation Control key must be selected on the confirmation control tab at item level in Purchase Order.
Make sure to check GR-Relevant and GR Assignment key for control key.
Step 3) Setting of Outbound iDOc
IDoc type – DELVRY03
Tools > ALE > ALE Development > IDoc > IDoc Type Development > IDoc Types
T.Code – WE30
Message Type – DESADV
Tools > ALE > ALE Development > IDoc > IDoc Type Development >Logical Messages
T.Code – WE81
Process Code – DELV
Tools > ALE > ALE Development > IDoc > Outbound Processing > Define Process Code
T.Code – WE41
Function Module – IDOC_OUTPUT_DELVRY
Maintain partner profile for outbound parameter
SPRO > Materials Management > Purchasing > Messages > EDI > Set Up Partner Profile
T.Code – WE20
Partner Type – KU (Customer)
Partner Role – SH
Step 4)Setting of Inbound IDoc
IDoc type – DELVRY03
Message Type – DESADV
Process Code – DELS
Tools > ALE > ALE Development > IDoc > Inbound Processing > Define Process Code
T.Code – WE42
Function Module – IDOC_INPUT_DESADV1
Maintain partner profile for inbound parameter
Partner Type – LS (Logical System)
Actual Process Flow:
The Process flow to generate inbound delivery remains the same in both approaches.
1) Create Purchase Order.T.Code – ME21N
2) Create Outbound Delivery for Purchase Order.T.Code – VL10B
3) Do Pick, pack and Post Good Issue for Outbound Delivery from supplying plant.
4) Output will be automatically triggered.
5) Confirmation control of Purchase Order will be updated with inbound Delivery.
Hi,
Intersting blog post but I have one doubt:
If you use same system shouldn't this be done by cross-company delivery process?? In this kind of case you do not need inbound delivery as you will have your supplier assigned to plant and in MRP transactions in receiving plant outbound deliveries are visible as confirmations either against PO or Scheduling Agreement schedule lines. Also GR is done directly against the outbound delivery.
Did I miss something here?
Best Regards,
Tomek
Hi,
Thanks for your comment.
Yes Cross-company delivery also helps in case of same system.
Inbound Delivery provides additional benefits-
- Inbound Delivery number gets updated in Purchase Order under confirmation control. So all information can be accessed through one document (PO), rather than finding out documents through various transactions.
-Receiving entity would normally not have complete access/authorization to check details in outbound delivery created by supplying entity.This is because access could be restricted at sales entity level.
-Solution can be further enhanced by Supplying entity regularly updating Outbound delivery with timely updates like some text or custom tabs showing Arrival time. Same would flow to inbound delivery. Thus receiving site will always have latest information without having to check MRP transactions
-Definitely in different system setup, the EDI solution is good option to track updates. I have mentioned same in my document also.
Hi,
I strongly agree with EDI solution for different systems, but still I find inb del usage in same system not too convincing - the outbound delivery also gets updated in PO if it is cross-company or inter-company code (from what i remember, this was scenario I implemented 3 years ago, so I can't recall all details). It is visible in PO history together with goods issue and it just simplifies the scenario by reducing number of flowing documents.
But access problem is a relevant argument as this is often restricted as you describe. So if Company employees have restricted authorization per plant / CC this might be a good alternative.
Anyway - very good description of step-by-step Idoc-based flow, I appreciate it!
Best Regards,
Tomek
I have to admit that I also struggle with this inbound delivery concept.
It is certainly technically needed if you use decentralized WM or EWM.
But I have not yet seen any real benefit to use inbound deliveries in a normal ERP environment, especially as it adds extra work and a lot restrictions. We never used it before we started with EWM, and still using it only where EWM is used. And even there is used just in time and automatically created. No user will ever create a manual inbound delivery, and this is actually good so, since many users have difficulties to know when they should create inbound deliveries and when normal goods receipts.
We have implemented this (SPED) solution (outbound to inbound) in one plant as in that plant we are using SAP mobile scanning for our goods receipt process and since our vendors are sending ASN's (automotive industry) it gives our shop floor users a uniform way of performing goods receipt independent from if goods are coming from an external party or internal (ICY).
Also the SPED message can transfer the handling unit into which the goods are packed in the outbound delivery to the inbound delivery.This allows us to scan in SAP mobile the bar code that is added to the goods in the shipping plant which avoids relabeling of the goods upon arrival and storage into the warehouse.
Hi Peter,
Good to see your comment to substantiate usage of effective Inbound Delivery solution.
Thats good advantage of Handling Unit that you have pointed out in your comment.
Hi Jurgen,
Thanks for your comment.
Realization of Inbound delivery can be really felt in different connected system.
Consider long distance shipments across continents. In such case this is helpful solution to get up to date track. And if solution is completly automated, then definitely it wont be additional effort.
This long distance thing does not convince me, it is quite regular business to ship from Germany to Singapore or Australia, or from Japan to USA, nobody ever complaint about to less visibility. We are using order acknowledgement, the dates are accurate, people can trust purchasing reports and MD04.
As I said, the automatic process works well, no doubt.
I just looking for arguments pro inbound deliveries that could really convince someone to make use of it, especially if one would need to maintain those inbound deliveries manually if the vendor is not able to send it by Idoc. Peter's example is good. And this document too as it explains well how to automate this inbound delivery creation.
Thanks Tomsaz for your encouraging comments
Hi Vishal Mehra ,
Nice presentation. Keep it up.
Also you can add KBA or OSS Notes your document.
M.Ozgur Unal
The automatic transfer of data from Outbound to Inbound Delivery is useful if you have batch and/or serial number management active. Or if that data is provided by external supplier. Compared to manually transcribing that info. from a physical Delivery Note into your system. (I've done very little work with acknowledgements).
Hi Mehra,
Very useful document,
But here, if we need to print inbound delivery number in any out put form, triggered when PGI done. Can this Inbound number can be printed, why I am asking this because, The triggering point for the both SPED and the one used to create the output is same.
If not, can you please suggest alternative solution for this.
Thanks in Advance.
Hi Vishal,
One question: using the SPED output type soltution, where can I define which delivery type will be used by the Inbound Delivery?
Thanks,
Jacare
Here you can point a delivery type for SPED-IBD and not only for STO, but for all kind of returns:
Materials Management – Purchasing – Confirmations -- Define Internal Confirmation Categories
I all
A need a similar solution to send a inboound delivery to other system using IDOC.
Basicaly in ECC side I will create the PO, Create the Inbound delivery ( VL31N ) , after save that one, I need send to a external system using IDOC.
That external system will send to me a confirmation e only after that i will can perform the goods receipt.
Can you guys help me with how I can start and send this IDOC when a save the VL31N?
Good post . I tried the same way you mentioned for SPED . But I am getting this error in output processing analysis when OBD is saved " Message no. VL383 , Enter a material or an item category" . Could you please help me what is missing
thanks
Manoj
Hi,
Thank you for the document very good staff. However, I have followed the procedure and the SPED output type comes with an error message of incompleteness
Account Number of Vendor or Creditor (VBPA-LIFNR), error group: 08
Message no. VU014
Do you have any ideas about it?
BR
I have tried with approach 2 but it didn't work for me.
The outbound delivery idoc successfully generated with status 02 and the inbound delivery idoc generated with status 51 with following errors:
Essential transfer parameters are missing in record: 00800XXXXX 000010
Data of preceding document was not transmitted
The following settings are used:
Partner No. - Vendor Code
Partner Type - LI
Outbound parameter:
Partner Role - VN
Message Type - DESADV
Receiver Port - A000000025
Pack.Size - 1
Basic Type - DELVRY07 (tried with DELVRY01 to DELVRY07)
Message Control - Application V2 / Message type ZIBD / Process Code DELV
Inbound Parameter:
Partner No. - Vendor Code
Partner Type - LI
Message Type - DESADV
Process Code DELS (tried with DESA, DELV also)
Am I using the correct message type and basic type?
Please help me to fix the issue.
I also meet this kind of error msg for related Inbound IDoc...
These days I am working on the investigation for this error msg...
can anyone demo Actual Process this scenario?
Than you & Very nice knowledge doc.
very good document. Nicely explained.Thanks !!!