Quick Guide – EDI/IDoc Interfacing to SAP ECC from...

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com

© 2010 SAP AG 1

Quick Guide – EDI/IDoc Interfacing

to SAP ECC from External System

Applies to:

Up to ECC 6.0. For more information, visit the ABAP homepage.

Summary

IDoc Interface: EDI Application Scenario

The application scenarios describe business processes in which EDI can be implemented. Consequently, two partners are always involved in these processes: The sender and the recipient of the EDI message. The scenarios should describe a business process as simply as possible, while remaining realistic. The process described here in this document can serve as templates or starting points for customer-defined business processes.

The scenario covered in this guide involves the IDoc interface, wherein, the data is received from an external system and the subsequent processing in the R/3 system is done. This processing of the data in the R/3 system is called Inbound Processing or also Inbound

Author: Rohit Khan

Company: SAP India GD

Created on: 15 Nov 2010

Author Bio

Rohit is working as a SAP Netweaver Consultant at SAP India GD. He is based out of Gurgaon facility.

[email protected].

https://www.sdn.sap.com/irj/sdn/abap

mailto:[email protected]

Quick Guide – EDI/IDoc Interfacing to SAP ECC from External System


© 2010 SAP AG 2

Table of Contents

Introduction ......................................................................................................................................................... 3

Dependencies/Pre-requisites.............................................................................................................................. 3

Technical Process steps ..................................................................................................................................... 4

Customizing Steps .............................................................................................................................................. 5

Demonstration .................................................................................................................................................... 5

Related Content ................................................................................................................................................ 15

Copyright........................................................................................................................................................... 16



© 2010 SAP AG 3

Introduction

This short ‘How to Guide’ will guide the SAP Technical Consultants to bridge the interface between an R/3 and External System. This scenario is based on an EDI scenario.

Example: The following figure shows the creation of DEBMAS and ADRMAS IDoc in the R/3 from an External System through flat file

Dependencies/Pre-requisites

Basic ABAP knowledge

Knowledge of IDoc interface

Knowledge of EDI process



© 2010 SAP AG 4

Technical Process steps

The scenario covered in this guide involves the IDoc interface and the corresponding EDI settings, wherein, the data is received from an external system and the subsequent processing in the R/3 system is done. This processing of the data in the R/3 system is called Inbound Processing or Inbound

Inbound Process Flow: Receiving Data from External System

Let us now understand some basic concepts about Inbound Processing,

Inbound processing includes:

Receiving IDoc data from an External System through flat files

Creating the Inbound IDoc

Finding the correct processing type via Partner Profile

Creating the Application Document

For the above process to work, we must maintain the IDoc interface for Inbound processing:

In the Partner Profile (WE20), the receiving system must be maintained as the partner for inbound processing and the Message Types should be maintained

The IDoc is passed directly to the Application Function Module according to the Partner Profile settings and processed according to Process Code

An Application IDoc is created in the database

Along with the above settings, we need to write an Interface Program. This interface program will pick the data file that is dumped into the Application Server

External System

R/3 System

Send data to R/3 System Transfer

Check port & partner, generate IDoc

Post document

Error Handling

Yes

No

No



© 2010 SAP AG 5

We need to define this flat file as Logical File using the T-Code FILE

We need to assign Physical Path to the Logical Path created above

In the program we also need to take care of the mapping. This will involve mapping the source fields from the file to the respective fields in the segments of the corresponding Message Types

Finally we will call the respective function module for IDoc processing

Customizing Steps

Following customizing need to be taken care:

Creation of Logical File path

Creation of Partner Profile, involving the following

Defining the Partner Type - Logical System

Defining the Inbound parameters

Assigning the corresponding Process Code (Process code identifies the type of data processing for inbound processing. The IDoc interface uses the process code to find the business process which controls the conversion of the IDoc into the SAP document)

Choosing the Mode of Processing

Trigger by background program

Trigger immediately

Demonstration

Now we will see the Demo of all the steps involved as discussed above:

1. Create a Logical File name using T-Code - FILE. Click on the ‘New Entries’ button to

create new entry



© 2010 SAP AG 6

2. Define a Logical file path. Click on ‘New Entries’ button after you place the cursor on the Folder 'Logical File Path Definition'. Enter the required values and save

3. Assign the Physical Path to the Logical Path in the similar fashion as done above, after you place the cursor on the folder 'Assignment of Physical Path to Logical Path'



© 2010 SAP AG 7

To get the Physical file name from the Logical file path created above, we will use the standard function module 'FILE_GET_NAME'.

This function module converts a logical file name to the corresponding physical file name and path for the hardware platform concerned.

The below example is for demo:-

DATA lv_filename TYPE localfile.

CALL FUNCTION 'FILE_GET_NAME'

EXPORTING

client = sy-mandt logical_filename = p_file operating_system = sy-opsys IMPORTING

file_name = lv_filename EXCEPTIONS

file_not_found = 1

OTHERS = 2.

IF sy-subrc <> 0.

MESSAGE e048(/asu/general) WITH lv_filename.

ELSE.

OPEN DATASET lv_filename FOR INPUT IN TEXT MODE ENCODING NON-UNICODE IGNORING CONVERSION ERRORS.

IF sy-subrc <> 0.

MESSAGE e004(/asu/general) WITH lv_filename.

ELSE.

ASSIGN w_data TO <fs_data>.

DO.

READ DATASET lv_filename INTO <fs_data>.

IF sy-subrc EQ 0.

MOVE-CORRESPONDING <fs_data> TO w_data.

APPEND w_data TO t_data.

CLEAR w_data. ELSE.

EXIT.

ENDIF.

ENDDO.

CLOSE DATASET lv_filename. ENDIF.

ENDIF.

Note: -

Here t_data is nothing but the internal table which we will populate with the file data and w_data is the work area, and, <fs_data> is the field symbol of type of the structure of t_data

With OPEN DATASET you can use ENCODING (NON-UNICODE or DEFAULT) statement

depending upon the character representation in which the content of the file is handled



© 2010 SAP AG 8

4. The system will prompt you for the transport request. Save it. After we have defined a logical file path, the next step is to create a Partner

5. Define Partner Profile using T-Code - WE20

a. In the Inbound Parameters, make entries for the Message Type. In our example, we have entered DEBMAS and ADRMAS

Note: You must maintain the Partners with whom you communicate via IDoc in the Partner Profiles: choose the

message to be sent to the partner and define the path to be used, as well as how inbound messages are processed



© 2010 SAP AG 9

b. Select the Message Type ADRMAS/DEBMAS (Ex. below) and click on ‘Detail’ screen button to further specify the attributes like Process code and Inbound options



© 2010 SAP AG 10

Let us see, what the above settings stand for

o Process Code - A process code identifies the type of data processing for inbound

processing

o Use - The IDoc interface uses the process code to find the business process which controls the conversion of the IDoc into the SAP document. You can also change the ALE option and processing type in the Process Code. See below.



© 2010 SAP AG 11

Ex. DEBM - EDI Customer master. This process code contains FM to process the inbound IDoc

Process by Function Module - Using this option in the Partner profile we can determine the

processing of IDoc. There are two options available for this

o Trigger by Background program - This option can be chosen if you want your interface program to create the IDoc when the program is run in background mode. This will create the IDoc with status 64 (IDoc ready to be transferred to the application)

o Trigger immediately - This will immediately create the application IDoc and post it in the system, with the relevant status 53 (IF successfully posted)

After all these settings are done, we need to write the interface program for populating the IDoc structure EDI_DC40 and EDI_DD40 and call the relevant FM for generating and IDoc

The following figure will explain the process in more detail



© 2010 SAP AG 12

The EDI_DC40 structure needs to be populated with the fields, MSGTYP, IDOCTYP, DIRECT, SNDPOR (SAP+SY-SYSID), SNDPRN, SNDPRT, RCVPOR (SAP+SY-SYSID), RCVPRN, RCVPRT. See example below...

Flat Files from Application

layer

ABAP to create and Post IDoc

Fill structure: EDI_DC40

&

Fill Tables: EDI_DD40

Call FM

IDOC_INBOUND_SINGLE

Legacy

System

*&---------------------------------------------------------------------* *& Form FILL_IDOC_HEADER *&---------------------------------------------------------------------* * text *----------------------------------------------------------------------* * --> p1 text * <-- p2 text *----------------------------------------------------------------------*

FORM fill_idoc_header.

DATA:

lv_port TYPE c LENGTH 10, "Port (SAP System, EDI subsystem)

lv_rcvprn TYPE bdaledc-rcvprn. " Partner details

*Select the receiving partner details

SELECT SINGLE logsys INTO lv_rcvprn

FROM t000

WHERE mandt EQ sy-mandt.

w_idoc_header-mestyp = 'DEBMAS'.

w_idoc_header-idoctyp = 'DEBMAS06'.

w_idoc_header-direct = '2'. "Direction for IDoc transmission

CONCATENATE 'SAP' sy-sysid INTO lv_port.

w_idoc_header-sndpor = lv_port. "Sender port (SAP System, EDI subsystem)

w_idoc_header-sndprn = 'LEGACY'. "Partner Number of Sender

w_idoc_header-sndprt = 'LS'. "Partner type of sender

w_idoc_header-rcvpor = lv_port. "Receiver port (SAP System, EDI subsystem)

w_idoc_header-rcvprn = lv_rcvprn. "Partner Number of Receiver

w_idoc_header-rcvprt = 'LS'. "Partner Type of Receiver

ENDFORM.



© 2010 SAP AG 13

The EDI_DD40 Tables Structure needs to be filled with the corresponding required segments in the program. We need to map the fields from the flat file to the corresponding segments and its fields in the program. Also we need to pass the other information required for the strcture EDI_DD40 like, EDI_DD40-SEGNAM, EDI_DD40-MANDT and EDI_DD40-SDATA = data from the mapped fields of the segment. Check the below code for how do we do the same.

*&---------------------------------------------------------------------*

*& Form FILL_IDOC_SEGMENT

*&---------------------------------------------------------------------*

* text

*----------------------------------------------------------------------*

* --> p1 text

* <-- p2 text

*----------------------------------------------------------------------*

FORM fill_idoc_segment .

DATA w_e1kna1m TYPE e1kna1m. " Master customer master basic data (KNA1)

DATA: t_idoc_segment TYPE TABLE OF edi_dd40,

w_idoc_segment TYPE edi_dd.

DATA t_data TYPE TABLE OF file_data_str. “ Strcture for file data records

LOOP AT t_data INTO w_data.

*===============================================*

* Fill Segment E1KNA1M

w_e1kna1m-kunnr = w_data-customer.

w_e1kna1m-anred = w_data-title_medi.

w_e1kna1m-ktokd = w_data-groupe_cpt.

w_e1kna1m-land1 = w_data-pays.

w_e1kna1m-name1 = w_data-nom_1.

w_e1kna1m-name2 = w_data-nom_2.

w_e1kna1m-ort01 = w_data-ville.

w_e1kna1m-pstlz = w_data-code_post.

w_e1kna1m-sortl = w_data-anc_numcpt.

w_e1kna1m-spras = w_data-spras.

w_e1kna1m-stcd1 = w_data-siret.

w_e1kna1m-stcd2 = w_data-siren.

w_e1kna1m-stras = w_data-adresse_1.

w_e1kna1m-telf1 = w_data-telephone.

w_e1kna1m-telfx = w_data-telecopie.

w_e1kna1m-stceg = w_data-id_tva_cee.

* Other fields of EDI_DD40

w_idoc_segment-segnam = ‘E1KNA1M’.

w_idoc_segment-mandt = sy-mandt.

w_idoc_segment-sdata = w_e1kna1m.

APPEND w_idoc_segment TO t_idoc_segment.

ENDLOOP.

ENDFORM. " FILL_IDOC_SEGMENT

After filling all the required strctures, we call the FM IDOC_INBOUND_SINGLE to post the IDoc in SAP as we can see from the above figure.



© 2010 SAP AG 14

After all the mapping and rules (if any - customer specific) is done, we will call the function module and pass the header and segment information. It should generate an IDoc with the some status. We can go and check the status of the IDoc generated using the T-Code: WE02.

Note: We need to make sure that the parameter PI_DO_COMMIT in 'IDOC_INBOUND_SINGLE' is checked. The

parameter PI_DO_COMMIT controls whether the function module sends a 'COMMIT WORK'. If no COMMIT command is sent and the application carries out rollback if an error occurs, the IDoc is deleted from the database, i.e. there is no longer an IDoc in which the error could be documented and the user will see IDOC: Error EA613

with FM IDOC_INBOUND_SINGLE



© 2010 SAP AG 15

Related Content

http://help.sap.com/saphelp_nw70/helpdata/en/78/2174b051ce11d189570000e829fbbd/frameset.htm

http://help.sap.com/saphelp_nw70/helpdata/en/78/2174b051ce11d189570000e829fbbd/frameset.htm



© 2010 SAP AG 16

Copyright

© Copyright 2010 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company.

All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

Quick Guide – EDI/IDoc Interfacing to SAP ECC from...

Documents

Transcript of Quick Guide – EDI/IDoc Interfacing to SAP ECC from...