Idoc in Delivery Processing
Skip to end of metadata
Created by Harry Wu, last modified on Dec 06, 2011
Go to start of metadata
Idoc in Delivery Processing
Standard Outbound IDOCs in Delivery Processing
RSNAST00 processes existing NAST record.
RSNASTED, FORM EDI_PROCESSING called for medium EDI.
Read outbound parameters from partner profile for receiving partner and output type (WE20).
Read outbound process code (WE41) from partner profile (message control).
Call corresponding application function module.
(e.g. IDOC_OUTPUT_DELVRY)
EDI/ ALE layer creates and dispatches IDoc using port definition
Standard Inbound IDOCs in Delivery Processing
IDoc received, saved and checked by EDI/ ALE layer.
IDoc processed immediately or later by RBDAPP01
Read inbound parameters from partner profile for sending partner (WE20)
Read inbound process code from partner profile (WE42)
Call application function, e.g. IDOC_INPUT_DELVRY
Error handling via workflow triggered by EDI/ ALE layer
DESADV IDoc / Basic type DELVRY0*
WHSCON / SHPCON IDoc (inbound)
Raghavendran Venkatesan
Posted onMay 2, 2017 2 minute read
Outbound IDOC for Post Goods Movements using message type MBGMCR
FollowRSS feedLike
2 Likes 13,752 Views 2 Comments
Outbound IDOC for Post Goods Movements using message type MBGMCR.
MBGMCR message type is a SAP provided message type for Post goods movements, we get the data from external systems and the Material document number is generated in S4 system.
But we don’t have any specific message type to send the Material document information when a Post goods movement is done in S/4 HANA 1511 system.
Hence we use the message type MBGMCR for sending material document information to external systems using IDOCs.
In our scenario we use BRF+ application to get the partner profile and partner function details, which in turn used to send the IDOC to external systems.
We are using the FM MASTER_IDOC_DISTRIBUTE to trigger the IDOC manually from the S/4 HANA 1511 system while Post goods movement.
We need to create an implementation for the following BADI.
BADI: MB_DOCUMENT_BADI
Method: MB_DOCUMENT_BEFORE_UPDATE
Basic type: MBGMCR
IDOC type: MBGMCR03
BADI implementation: FM to send IDOC
Build the IDOC structure and transfer it using the following FM.
The following is an example for triggering an outbound IDOC during PGM in MIGO
Document posted successfully and the Material Document number is 4900008344
The same Material number 4900008344 which has been created in MIGO is passed as a Reference document number to the external systems.
The Data records of the IDOCS.
The data records are depends upon our requirement.
Hence material document details are transferred from S/4HANA 1511 system to external systems through outbound IDOCs.
Alert Moderator
Assigned tags
SAP Application Interface Framework
idoc
mbgmcr
mbgmcr03
migo
View more...
Related Blog Posts
SAP AIF- Simple Outbound Scenario Part-1
By Hemant Negi, Aug 14, 2015
Michal’s Tips: SXMB_MONI vs FEH/ECH vs AIF
By Michal Krawczyk, Jan 22, 2014
Michal’s tips: Application Interface Framework (AIF) 2.0 – PO/PI’s message ID from IDOC’s adapter in AIF log
By Michal Krawczyk, May 23, 2013
Related Questions
Outbound Interface Tracking in AIF
By Former Member, Mar 29, 2018
What will be the advantages using AIF over Idoc ? Ans plz
By Former Member, Apr 14, 2017
AIF-New interface variant for Outbound interfaces
By solen dogan, Feb 19, 2015
2 Comments
You must be Logged on to comment or reply to a post.
Raghava Garre
April 26, 2019 at 11:57 am
Hello Friend,
We have maintained the settings(NACE, BD64, WE20 etc..) to create MBGMCR IDOC for transfer posting in MIGO. Initially we used to get 2 outbound IDOCs for every successful 309 movement. One IDOC for reducing the stock from one material and other IDOC to increase the stock of other material. Since few days we are getting only 1 IDOC for this 309, which is for increasing the stock of second material.
Request for suggestions to get 2 IDOCS for this movement type, if you have faced any such kind of situation.
Thanks,
Raghava
Like(0)
Rock Huang
December 30, 2019 at 1:22 am
Hi Raghava,
2 IDOCs be genereted, my thinking is your settings be triggered twice, so NACE + BD64 might be the wrong solution, regarding the method to identify the issue, what I thought is set break point at FM:”MASTER_IDOC_DISTRIBUTE”, and set up update task and backgroud debugging mode, then you should know the root cause.
I suggest you simply use enhancement to send material document idoc via Badi that mentioned this article,
BADI: MB_DOCUMENT_BADI
Method: MB_DOCUMENT_BEFORE_UPDATE
hope helps
Best wishes,
R
Like(0)
Message Type | Basic Type | Process Code | IDoc Processing Function Module | Output Type
Message Type | Basic Type | Process Code | IDoc Processing Function Module | Output Type
DESADV | DESADV01 | SD05 | IDOC_OUTPUT_DESADV01 | LAVA
DESADV | DELVRY0* | DELV | IDOC_OUTPUT_DELVRY | LAVA
PICKSD | SDPIOD01 | None | SD_IDOC_OUTPUT_PICKING | EKSU
SHPORD | DELVRY0* | DELV | IDOC_OUTPUT_DELVRY | SHOR
WHSORD | DELVRY0* | DELV | IDOC_OUTPUT_DELVRY | WSOR
CARNOT | DELVRY0* | DELV | IDOC_OUTPUT_DELVRY | CANO
Message Type | Basic Type | Process Code | IDoc Processing Function Module | Delivery Creation/Updating Function Module
DESADV | DESADV01 | DESA | IDOC_INPUT_DESADV | GN_DELIVERY_CREATE
DESADV | DELVRY0* | DELS | IDOC_INPUT_DESADV1 | GN_DELIVERY_CREATE
SDPICK | SDPIID01 | SDPI | SD_IDOC_INPUT_PICKING | SD_DELIVERY_UPDATE_PICKING
SDPACK | SDPAID01 | SDPA | SD_IDOC_INPUT_PACKING | SD_DELIVERY_UPDATE_PACKING
SHPCON | DELVRY0* | DELV | IDOC_INPUT_DELVRY | WS_DELIVERY_UPDATE_2
WHSCON | DELVRY0* | DELV | IDOC_INPUT_DELVRY | WS_DELIVERY_UPDATE_2