SAP Inbound IDoc step by step

This blog will give complete overview about Inbound IDocs in SAP step by

step. Middleware can be anything like PI, BizTalk and so on. SAP Inbound

IDoc will cover end to end IDoc type, Message type, Process code, Posting

function module and so on. SAP Inbound ALE IDoc step by step.

This blog will cover real time scenario on transaction Transfer

Posting(MB1A).

1) Before getting into IDoc level we need to understand the source from

external system let us take our external system is BizTalk server. So our

communication will be BizTalk to SAP. First we need map the BizTalk fields

and with our BAPI or Posting function module.

2) To identify if any standard IDoc type or Basic type exist

3) To identify any Posting function module exist

4) To identify any BAPI/Function module exist

5) If there is no BAPI/Function module exist then we can go for BDC or

LSMW.
Below the step will give complete step by step in custom inbound IDoc

implementation.

Step 1) Create segment using transaction code WE31

In our scenario I have used existing segments which is given below

E1BP2017_GM_HEAD_01 BAPI Communication Structure:

Material Document Header Data BAPI2017_GM_HEAD_01

E1BP2017_GM_CODE MMIM: New Key Assignment

GM_CODE to Transaction of Inv. Mgmt BAPI2017_GM_CODE

/CWM/E1BP2017_GM_ITEM_CREAT BAPI Communication Structure:

Create Item Data for CW /CWM/BAPI2017_GM_ITEM_CREATE

E1BP2017_GM_SERIALNUMBER BAPI Communication Structure:

Create Mat. Doc., Serial No. BAPI2017_GM_SERIALNUMBER

E1BP2017_GM_ITEM_CREATE BAPI Communication Structure:

Create Material Document Item BAPI2017_GM_ITEM_CREATE

Create Material Document Item BAPI2017_GM_ITEM_CREATE

Note : We need to release the custom segment otherwise our external

system unable to read this segment

Step 2) Create segment using transaction code WE30

Note : We need to release the custom IDoc type otherwise our external

system unable to read this segment

Step 3) Create message type using transaction code WE81

Step 4) Linking message type with IDoc typeusing transaction code

WE82
Step 5) Registering inbound function module using transaction code

BD51

Before linking we need to create IDoc posting function module. Please

find below the Posting function module along with signature.

FUNCTION zfmidocgrn.

*"--------------------------------------------------------------------

*"*"Local Interface:

*" IMPORTING

*" VALUE(INPUT_METHOD) LIKE BDWFAP_PAR-INPUTMETHD

*" VALUE(MASS_PROCESSING) LIKE BDWFAP_PAR-MASS_PROC

*" EXPORTING

*" VALUE(WORKFLOW_RESULT) LIKE BDWF_PARAM-RESULT

*" VALUE(APPLICATION_VARIABLE) LIKE BDWF_PARAM-APPL_VAR

*" VALUE(IN_UPDATE_TASK) LIKE BDWFAP_PAR-UPDATETASK

CALLTRANS

*" TABLES

*" IDOC_CONTRL STRUCTURE EDIDC

*" IDOC_DATA STRUCTURE EDIDD

*" IDOC_STATUS STRUCTURE BDIDOCSTAT

*" RETURN_VARIABLES STRUCTURE BDWFRETVAR

*" SERIALIZATION_INFO STRUCTURE BDI_SER

*" EXCEPTIONS

*" WRONG_FUNCTION_CALLED

*"--------------------------------------------------------------------

DATA : lwa_gm_item TYPE e1bp2017_gm_item_create,

lwa_gm_code TYPE e1bp2017_gm_code,

goodsmvt_code TYPE e1bp2017_gm_code,

lwa_gm_header TYPE bapi2017_gm_head_01,

gm_item TYPE bapi2017_gm_item_create,

gt_item TYPE TABLE OF bapi2017_gm_item_create,

gm_header TYPE bapi2017_gm_head_01,

return TYPE TABLE OF bapiret2,

lwa_return TYPE bapiret2,

head_ret TYPE bapi2017_gm_head_ret.

DATA : lwa_ekpo TYPE ekpo.

DATA : lv_do_process TYPE char1.

DATA : lwa_mara TYPE mara.

CONSTANTS : c_x TYPE char1 VALUE 'X'.

CLEAR : gm_header, goodsmvt_code.

REFRESH : gt_item[], return[].

CASE idoc_data-segnam.

WHEN 'E1BP2017_GM_CODE'.

lwa_gm_code = idoc_data-sdata.

MOVE-CORRESPONDING lwa_gm_code TO goodsmvt_code.

WHEN 'E1BP2017_GM_HEAD_01'.

lwa_gm_header = idoc_data-sdata.

MOVE-CORRESPONDING lwa_gm_header TO gm_header.

gm_header-PSTNG_DATE = sy-datum.

WHEN 'E1BP2017_GM_ITEM_CREATE'.

lwa_gm_item = idoc_data-sdata.

MOVE-CORRESPONDING lwa_gm_item TO gm_item.

APPEND gm_item TO gt_item.

ENDLOOP.

CALL FUNCTION 'BAPI_GOODSMVT_CREATE'

EXPORTING

goodsmvt_header = gm_header

goodsmvt_code = goodsmvt_code

IMPORTING

goodsmvt_headret = head_ret

TABLES

goodsmvt_item = gt_item

return = return.

IF head_ret IS INITIAL.

LOOP AT return INTO lwa_return WHERE type = 'E'.

USING idoc_contrl-docnum lwa_return '51'.

ENDLOOP.

CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.

EXIT.

ELSE.

READ TABLE return INTO lwa_return INDEX 1.

PERFORM idoc_stat TABLES idoc_status USING idoc_contrl-docnum

lwa_return '53'.

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'

EXPORTING

wait = 'X'.
 ENDIF.

ENDFUNCTION.

Input type can be like below

0 Mass processing

1 Individual input

2 Individual input with IDoc lock in CALL TRANSACTION

Step 6) Linking Message type, IDoc type and Posting function module

using transaction code WE57

Direction can be Outbound or Inbound but our scenario is Inbound

Step 7) Create Process code and assign the posting function module

using transaction code WE42

Step 8) Create Partner Profiles using transaction code WE20

time activity and I will not cover in this topic

Expand the Partner type LS tree

Select your respective Partner name

Goto Inbound parmtrs and click add inbound parameter icon

Step 9) Test your IDoc using transaction code WE19

 There are many ways to replicate your IDocs

 Access using existing IDoc as model

 Access using IDoc type as model

 Access using message type

 Access using existing IDoc as model(File as template)

 Access without model

We could see now the screen with Control records and data

records(segments)
Click control record section and fill the necessary details

Receiver port (SAP System, EDI subsystem)

This field defines which system receives the IDoc. RCVPOR is a mandatory

field.

The receiving system can be either an EDI subsystem or another SAP

System (R/2 from 5.0F, SAP system from 2.1).

Partner Number of Receiver

This field contains the partner number of the receiver. The partner

number and partner type uniquely identify the receiver.

The partner number can be alphanumeric and is a mandatory field.

Partner Type of Receiver

Code which identifies the commercial relationship between the sender

and receiver.
Using this code, the IDoc interface determines the function module which

checks whether the basic data of a partner exists. The check is carried out

in partner profile maintenance.

Sender port (SAP System, EDI subsystem)

This field defines which system has sent the IDoc. SNDPOR is a mandatory

field.

The sending system can be an EDI subsystem or another SAP System (R/2

from 5.0F, SAP system from 2.1).

Partner Number of Sender

The field contains the partner number of the sender. The partner number

and the partner type uniquely identify the sender.

The partner number can be alphanumeric and is a mandatory field.

Partner Type of Sender

Code which identifies the commercial relationship between the sender

and receiver.
Using this code, the IDoc interface determines the function module which

checks whether the basic data of a partner exists. The check is carried out

in partner profile maintenance.

Message Type

An IDoc type can be implemented for various "logical" messages; one

message can also be assigned to different IDoc types (m:n relationship).

The message is defined by the values for message type (required),

message code (optional) and message function (optional). These three

fields belong to the key fields in the partner profiles, which are used, for

example, to determine inbound processing. If the 'Message type' field is

not maintained (e.g. in the case of a control record from Release 2.1, in

which MESTYP did not exist), the IDoc Interface uses the value from

STDMES (EDI message type).

function module button

Now click continue and press enter

Step 9) Check your IDoc status using transaction code WE02

We could see the IDoc control records, IDoc data records and IDoc status

records.

I hope you all are understood the concept of end to end Inbound IDoc

posting.

- See more at: http://www.sappractical.com/home/blogd/sap-inbound-

idoc-step-by-step/#sthash.UwSNnDqo.dpuf