2/5/2016 9:07:36 PM

SAP Inbound IDoc step by step-This blog will gives 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


    E1BP2017_GM_ITEM_CREATE1       BAPI Communication Structure: 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

*"     VALUE(CALL_TRANSACTION_DONE) LIKE  BDWFAP_PAR-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_goodsmvt_code TYPE bapi2017_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[].

  LOOP AT idoc_data.

    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.

    ENDCASE.

  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'.

      PERFORM idoc_stat TABLES idoc_status

                        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.

*&---------------------------------------------------------------------*
*&      Form  IDOC_STAT
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*      -->P_IDOC_STATUS  text
*      -->P_IDOC_CONTRL_DOCNUM  text
*      -->P_LWA_RETURN  text
*      -->P_0181   text
*----------------------------------------------------------------------*
FORM IDOC_STAT TABLES   IDOC_STATUS STRUCTURE BDIDOCSTAT
                USING    P_DOC_NO
                         p_return TYPE bapiret2
                         p_status.
  CLEAR idoc_status.
  idoc_status-docnum   P_DOC_NO.
  idoc_status-msgty    p_return-type.
  idoc_status-msgid    p_return-id.
  idoc_status-msgno    p_return-number.
  idoc_status-appl_log p_return-log_no.
  idoc_status-msgv1    p_return-message_v1.
  idoc_status-msgv2    p_return-message_v2.
  idoc_status-msgv3    p_return-message_v3.
  idoc_status-msgv4    p_return-message_v4.
  idoc_status-repid    sy-repid.
  idoc_status-status   P_STATUS.
  APPEND idoc_statusclear idoc_status.

ENDFORM.                    " IDOC_STAT 


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

Note : Logical system and port creations are BASIS activity and its one 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).



Finally fill your business transaction details(MB1A) and click Inbound 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.

You can send comments to vadamalai.a@gmail.com also you can send general comments this same email id.

If you like this blog, please share (Facebook/LinkedIn/Google+) to click below links so it will reach to others.


COMMENTS

  • Prakash -9/13/2016 5:12:03 AM

    Very useful stuff.....thanku

  • Yogesh Khemani -5/19/2016 3:09:58 PM

    Detailed explanation of all the steps involved in Inbound IDOC Scenario and that too with screenshots. Good Job!!

  • Pavan -3/31/2016 5:51:37 PM

    Adhi,  Crisp and Clear.  wonderful work.

  • Amol -3/2/2016 2:59:07 PM

    Very good information. 

  • Vijay -2/17/2016 2:36:40 PM

    Fanstantic descriptive information. great job !!!!!

  • krishna -2/12/2016 8:54:40 PM

    Thanks for posting useful real time scenarios

  • it's very helpfull and good doucment -2/11/2016 1:31:53 PM


  • Malli -2/10/2016 8:52:14 AM

    Very usefull.. info... thanks for effort....

  • Ben -2/10/2016 1:32:46 AM

    Dear Sir,

    Great article. Would you be able to email me a specification for  the IDOC? I am looking for a specification of the IDOC payment type for a project I am working on. 


    Thanks

    Ben

  • RK -2/9/2016 2:05:53 PM

    Nice document , crisp and clean .... :)

  • Dana Hoffman -2/8/2016 8:44:14 PM

    Nicely done! Does anyone have a suggestion for preventing duplicate inbound deliveries from Vendor's ASN IDOCs?

  • Daquan Reinhardt -2/8/2016 3:17:19 PM

    Good stuff.  I am starting a job with Alstom on 2/15 where i will be responsible for learning and teaching SAP to warehouse workers.  Any ideas or tips would be greatly appreciated.  I have used SAP APO at Coca Cola from a Planning perspective but look very forward to learning the warehousing piece.  Again,  If the is any tutorials or white papers that can be furnished it would be greatly appreciated. 

  • Its too good -2/8/2016 10:19:27 AM


  • Nice one -2/8/2016 9:53:17 AM

    Very good information. 

  • Santosh -2/8/2016 9:33:17 AM

    Good Document