IDOC_FOR_PO

(1)

Avidypta Guha IDocs Training, SAP Practice Enterprise Solutions, Mangalore

(2)

(3)

Agenda

• • • • What is an IDOC? IDOC Structure

IDOC Type Documentation IDOC Components

– Basic IDOC Type – Segments

• IDOC Run-Time Components

– – – Control Records Data Records Status Records • • • • • • •

Where and How an IDOC is created? Process Code

Partner Proﬁle

Summary: IDOC Workﬂow Inbound processing of IDOC EDI

(4)

Agenda

– – – Control Records Data Records Status Records • • • • •

Partner Proﬁle

Summary: IDOC Workﬂow Inbound processing of IDOC

(5)

What is an IDOC?

• IDOC = Intermediate Document

• information between any two processes that can

understand the syntax and semantics of the data.

IDOC is simply a data container used to exchange

• When we execute an

outbound

ALE or EDI Process, an

IDOC is created

• In an

inbound

ALE or EDI process, an IDOC serves as

input to create an application document.

•

• In the SAP System, IDOCs are stored in

database

.

Every IDOC has an

unique number

(within a client).

(6)

What is an IDOC? (contd)

• IDOCs are independent of the sending and receiving

systems.(SAP-to-SAP as well as Non-SAP)

• IDOCs are based on EDI standards, ANSI ASC X12 and

EDIFACT. In case of any conflict in data size, it adopts

one with greater length

• exchange e.g. ORDERS01 : Purchasing module : Inbound

and Outbound

IDOCs are

independent of the direction

of data

• IDOCs can be viewed in a

text editor

. Data is tored in

(7)

Agenda

Partner Proﬁle

(8)

(9)

Agenda

Partner Proﬁle

(10)

IDOC Type Documentation

(11)

IDOC Components :

Basic IDOC Type (we30)

• Basic IDOC Type defines the structure and format of the business document that is to be exchanged.

• – – – – –

IDOC Type has a speciﬁc name

list of permitted segments hierarchy of segments

mandatory/optional segments

(12)

(13)

(14)

Agenda

Partner Proﬁle

(15)

IDOC Components :

Segments

• Segment defines the format and structure of a data record.

Segments are reusable components.

• –

–

For each segment SAP creates

Segment Type (version independent)

Segment Deﬁnition (version dependent)

Segment Documentation

• The last 3 characters is the version of the segment

• Definitions keep changing as per the version but the segment

type remains the same

(16)

(17)

Agenda

Partner Proﬁle

(18)

IDOC Run-Time Components

• An IDOC is an instance of an IDOC Type • At run time the following events occur

– – – – –

A unique IDOC no. is allocated by SAP One control record is attached to the IDOC Segments translate into data records

Status records are attached Syntax rules are checked.

• Each IDOC has 3 parts

– – – Control Record Data Record Status Record • We02 or We05

(19)

(20)

IDOC Runtime components (Contd)

Control Record

• All control record data is stored in EDIDC table. The key to this table is the IDOC Number

• It contains information like IDOC number, sender, recipient information, channel it is using, which port it is using etc.

Data Record

• Data record contains application data like employee header info, weekly details, client details etc

• All data record data is stored in EDI_DD40 table and EDI_DD Status Record

• Status record are attached to an IDOC at every milestone or when it encounter errors.

(21)

(22)

Agenda

Partner Proﬁle

(23)

Where and How an IDOC is created?

• Lets take an example to understand this:

• Whenever a Purchase Order (PO) is created we want to send the IDOC to a vendor.

•

partner has to be EDI enabled in that system.. SAP should realize that it could send doc to this vendor electronically. (Creating a vendor is not sufficient). Partner Profile should be EDI enabledi.e. A partner profile should exist in the sap system.

The PO is sent in the form of an IDOC to the vendor (partner). That

• Quotation, RFQ, PO, SO, Invoice, delivery challan etc are some of the commonly exchanged documents through IDOCs

• •

We create only one proﬁle for both inbound and outbound IDOCs. Partner proﬁle should contain message type……to be able to

exchange the IDOC. •

distinguish if an IDOC is being sent to same person in same function for diﬀerent reason e.g. SO)

(24)

(25)

(26)

(27)

Agenda

Partner Proﬁle

(28)

Creating Outbound Process Code (WE41)

• What is Process Code ?

Process of ﬁlling the IDOC with application data is done by Function Module. But, function module is not assigned to a Partner. It is encapsulated by a Process Code and this Process Code is assigned to a Partner in Partner Proﬁle.

•

- Go to Transaction WE41.

- Switch to “Change” Mode and click “New Entries”.

- Enter Process Code Name and assign the Function Module created. Assigning Function Module to Process Code

Function Module

Process Code

(29)

(30)

(31)

(32)

Agenda

Partner Proﬁle

(33)

Creating Partner Proﬁle (WE20)

• What is Partner Profile ?

We must maintain the business partners with whom we communicate via IDocs, in Partner Proﬁles.

•

- Goto Transaction WE20. - Click on Create Button.

- Enter the Number of Vendor Created in Partner No. and ‘LI’ in Partner Type ﬁelds.

- Save the Data.

- For Outbound Partner Proﬁle we have to create Outbound Parameters

- Specify Partner Function, Message type created, Port (create a port in WE21),Basic Type and Output Mode.

- Goto “Message Control” Tab and link the Message Type and Process Steps to create Partner Proﬁle

Code created. - Save.

(34)

(35)

Change Application Data to be Transmitted

• Change Purchase Order Created using transaction ME22n for the Vendor to which partner proﬁle has been created.

• Goto “Messages” , add the new “Message Type” to the list and Save the Purchase Order.

• An IDOC will be created for the purchase order and will be dispatched to PORT mentioned.

Check the status of IDOC (WE02)

• The IDOC status can checked using transaction WE02 • If the status is ’03’ , it implies that IDOC is passed to Port.

(36)

Agenda

Partner Proﬁle

(37)

Summary: IDOC Workﬂow

The sequence:

2. Checks whether Partner proﬁle exists or not 3. Whether that PP has a outbound parameter

4. Whether NEU message type is there or not (message control) 5. Checks the process code (gives the name of Function module) 6. Checks immediate transfer or batch transfer

7. Based on that it checks the receiver port 8. Then it will trigger the RFC destination

9. Then it triggers the event on subsystem/customer system

10.Transfer the IDOC to a port and transfer the Idoc in terms of ﬁle and it triggers the customer system

11.Customer knows from where it should pick up the ﬁle ….it picks up the ﬁle.

(38)

(39)

(40)

(41)

(42)

Extending an Existing IDOC Type

• Used in cases where some additional information is required in addition to that supplied by the Standard IDOC Type.

• In Transaction WE30 we create the IDOC as an Extension and specify the basic type for which it is an extension.

• We add the segments needed as children to existing ones.

• None of the Reference Segments can be deleted or changed.

Extension Child Segs

Basic Type(ORDERS01)

F1 F2 F3

(43)

Agenda

Partner Proﬁle

(44)

Inbound v/s Outbound processing -- Similarities

• • • • • •

The basic Idoc type Partner proﬁle

Message type

Idoc type – Message type association Deﬁning Inbound function module Process code

(45)

Inbound v/s Outbound processing -- Diﬀerences

• Partner profile – is maintained for inbound parameters • Idoc type - Message type association – has fewer details

(46)

Steps

• • • • • • • •

Creation of basic Idoc type (Transaction we30) Creating message type (Transaction we81)

Associating the Message type to basic Idoc type (Transaction we82) Creation of partner (Transaction xd01)

Associating the partners (Transaction voe2) Creation of partner proﬁle (Transaction we20) Deﬁning process code (Transaction we42)

Maintain an entry for the material in customer-material info records (Transaction vd51)

(47)

Creating a partner -- customer

• The customer is the receiver of the idoc in this scenario

– – – – – – – Transaction xd01

Enter sales organization – 1000 Sales division – 12

Distribution Channel – 00 Account group – ship-to-party

Enter all required data -- sales area data and billing data Note the customer number

(48)

Associating the partners

• • •

The customer and vendor need to be associated Goto transaction ve02

Create a new entry

– – – – – –

Enter customer number Enter vendor number Enter sales area - 1000 Enter sales division - 12

Enter distribution channel - 00 Enter standard order type - ZTA

(49)

Create a Inbound process code

• The inbound process code is the process that needs to be triggered in order to post the idoc that is sent by the subsystem.

• The steps in developing a process code

– – – –

Develop a function module

Deﬁne inbound characteristics of the function module – bd51 Assign idoc type and message type – we57

(50)

Function module

• This function has a basic functionality of posting the document into its respective format from the idoc

• • It is basically a bdc The functionality is to – – –

Read control record and data records Fill bdc table, call transaction

(51)

Assign Idoc type – Message type (Transaction we57)

• • • •

Module name – function module developed Basic idoc type eg: orders01

Message type eg:orders Object type – bus2032

(52)

Deﬁning the process code – we42

• • •

Enter the process code – any name

Identiﬁcation is the name of the function module Processing type is processiong by function module

(53)

Creating a partner proﬁle -- Tcode we20

• • • •

Enter partner function – ship-to-party Message type – orders

Process code – orde

Note that no other details are needed unlike partner proﬁle for outbound process

(54)

Testing the inbound function module – we19

• • •

The idoc created has to be posted Change the control record

Post the idoc

– Use inbound function module or – Standard inbound function module

(55)

Agenda

Partner Proﬁle

(56)

EDI

Contents • • • • •

Evolution and Need of EDI What is EDI ?

EDI Architecture Advantages of EDI

The Two Types of EDI Processes - Outbound Process

- Inbound Process

(57)

Disadvantages of Conventional Business Documents Exchange

• • • • •

Highly Ineﬀicient & Laborious No proper Tracking Mechanism No visibility into the Process Long Lead Time

(58)

Evolution of EDI

Data Exchanged through Floppy Disk

Adoption of Standard Formats

ANSI Committee Formation

X.12 – 1975

•One-to-one correspondence between paper-based document and an EDI Message •North America , New Zealand and Australia

UN/EDIFACT

(United Nations EDI for Administration, Commerce and Transport) 1985

(59)

What is EDI ?

• EDI, stands for Electronic Data Interchange, is the electronic exchange of structured business data between diﬀerent applications. The EDI architecture consists of

• EDI-enabled applications :They support the automatic processing of business transactions.

• The IDoc interface: This was designed as an open interface. The IDoc interface consists of IDoc types and function modules that form the interface to the application.

• The EDI subsystem: This converts the IDoc types into EDI message types and vice versa. This component of the EDI architecture is not supplied by SAP.

(60)

EDI Architecture

MM

(Customer) (V ndor)eSD

IDOC

EDI subsystem E I subsystemD IDOC

(61)

Advantages of the EDI Process

• • • • • • • • •

Reduced data Entry Errors

Reduced Processing cycle time Availability of data electronic form Reduced Paper Work

Reduced Cost

Reduced Inventories and Better Planning Standard Means of Communicating

Better Business Processes Competitive Advantage

(62)

Data Flow Process Flow

Outbound EDI Process

EDI-Enabled

Application

Selection

Program

Outbound

Trigger

Program

Database

Repository

Application Document IDoc IDoc File

EDI

VAN

Value added Network

(63)

Inbound EDI Process

Data Flow Process Flow

EDI-Enabled

Application

Posting

Program

Inbound

Trigger

Program

Database

Repository

Application Document IDoc IDoc File

EDI

Subsystem

EDI Document

VAN

Value added Network

Operating

(64)

Agenda

Partner Proﬁle

(65)

Purpose And Implementation Considerations

PURPOSE

ALE supports the distribution of the business functions and process across loosely coupled R/3 systems. Connections from R/2 and non SAP systems is also supported.

IMPLEMENTATION CONSIDERATIONS

• Distributing business applications and at the same time ensuring data consistency is practical because:

– The increasing globalization of markets has led to the physical division of organizational units.

– Business processes are not restricted to one organization only and an increasing number of customers and vendors are involved.

– The performance of an R/3 System can be improved by distributing the business applications.

(66)

Features

• ALE supports:

– Distribution of applications between different releases of R/3 Systems – Continued data exchange after a release upgrade without requiring special

maintenance –

– –

Customer-speciﬁc extensions.

Communication interfaces that allow connections to non-SAP systems. Coupling of R/3 and R/2 Systems.

ALE has functions for controlling messages ﬂows (Audit) and for eliminating malfunctions.

(67)

(68)

Steps Involved in the Conﬁguration of ALE

• • • • • • • • •

Setting up the Clients

Deﬁning Logical Systems for the Clients Deﬁning the Communication Parameters Modeling the Distribution

Generating Partner Proﬁle in the Sending system Distributing the Distribution Model

Generating Partner Proﬁle in the Receiving system Creating Master Data

(69)

Setting Up The Client

• First of all, you have to set up two clients to enable communication between the logical systems. The two clients may be located in the same R/3 System or in separate systems or servers.

• You can either use existing clients or you can create new clients by making copies of existing ones.

• •

To set up a new client, from the SAP standard menu choose: Tools Administration Administration Client administration Client maintenance

•

administrators. So this step really is not the part of ALE Conﬁguration, but as an ALE Consultant one should know how to Create and maintain the clients.

(70)

Deﬁning Logical Systems

•

distributed environment must have the unique ID. The name of the logical system is used as the unique ID. This name is assigned

explicitly to one client in an R/3 System at a time.

To overcome any confusion, the communicating systems in a

• You can find the functions required for this in the R/3 Implementation Guide under:

• Sale Distribution (ALE) Sending and Receiving Systems Logical Systems

• To define the logical systems in the distribution environment, choose Deﬁne Logical System.

• Execute the function and enter a logical system (LOG. SYSTEM) and a short text for each of your clients and save your settings.

(71)

Logical Systems Contd…

•

settings are the same in both systems. When using two clients in one physical R/3 System, you only have to make the settings once, since the entries are client-independent.

If you are using two clients in diﬀerent systems, make sure your

• Assign the respective logical system to both the clients. Choose Assign Logical System to Client.

• Execute the function in both clients (Fig 1.1).

• To display the client maintenance screen (Fig 1.2), double-click on a client.

• In the Logical system field, enter the logical system to be assigned to the individual client and save your entry.

(72)

(73)

(74)

Deﬁning the Communication Parameters

• For the two logical systems to be able to communicate with one another, they must know how to connect to each other. The RFC (Remote Function Call) destination provides this information.

• In each of the two clients, you must assign the RFC destination for the other logical system. In Customizing for ALE choose:

• Sending and Receiving Systems Configure Systems in Network Deﬁne RFC Destination.

• • •

Execute the function (Fig 1.3). Choose Create.

Enter the RFC destination. Use the name of the logical system that is to be the destination (use UPPERCASE letters only). Enter ‘3’ as the

(75)

(76)

RFC Destinations Contd…

• As logon parameters, enter the logon language (for example, EN ), the

logon client and the logon user (user ID with target system password). •

Destination Types Screen e.g. Choose R/3 Connections. It will display a list of RFC Destinations. If you choose any one of them, then you have to enter Target Host and the system number either for the Remote Log-On or for Testing the current connection. Target Host is nothing but the application server to which you intend to connect. This name can be given either in the form of an IP address mode or just in the form of application server name. You can see the list of application servers

using the transaction code . The screen can be seen as following

(Fig 1.4).

Once the RFC Destination is created, it is visible in one of the RFC

(77)

(78)

Modeling The Distribution

•

messages are getting transferred from where to where. This information is stored in the distribution model. The distribution is based on the

distribution model and is directly controlled by distribution model. The systems involved in the communication, must know which

• From the R/3 Implementation Guide screen, choose:

• Sale Distribution (ALE) Modeling and Implementing Business Processes Maintain Distribution Model

• Create the model view. Select Create model view. Enter the technical name and a description for it.

•

Position the cursor on Technical name and select

A dialog box appears. Enter the logical system name of the sender and

the receiver and the message type e.g. . For your reference,

Deﬁne the sending and receiving systems and the message type. Add message type. M AT M AS

(79)

(80)

Generating Partner Proﬁles for Sending System

• After creating the model view, go to Environment Menu and click Generate Partner Proﬁles.

•

changing any parameter execute the function and generate the partner proﬁle.

According to the Technical name of the model view and without • For your reference, please see the screen shot Fig 1.6.

(81)

(82)

Distributing the Distribution Model

•

must distribute all the messages in the respective distributed

environment. This is possible only when you transport your distribution view to the receiving system. So we need to distribute the model

distribution view.

To generate the partner proﬁles in the receiving system, this system

• To achieve this choose:

• Distribution (ALE) Modeling and Implementing Business Processes Maintain Distribution Model Edit Model View Di s trib ute • Actually after this step is successfully over, we get a message saying

(83)

Conﬁguration In Receiving System

•

the receiving system. Which is very much similar to the procedure as that of Generating the partner proﬁle in the Sending system (The

Partner proﬁle must be generated for inbound parameters) .

The next step after this is, we have to generate the partner proﬁle for

•

create a material or a purchase order or a sales order or any entry for that matter and send that particular entry to the receiving system

through the newly conﬁgured ALE Conﬁguration Model.

(84)

Distribution of material

• Go to the respective master data transaction and then send the data in this case BD10.

•

IDOC which is generated to be changed to 12 i.e. •

Go to SE 38 and run the program RBDMO IND for the status of the Dispatch OK The IDOC with the status 53 have to posted in the target service.

(85)

(86)

Change Pointers

•

technique which tracks changes made to the key document in SAP ,such as material master, customer master and sales order.

The change pointer technique is based on the change document • Changes are recorded in the database tables

– – –

CDHDR – Change document header table CDPOS – Change document detail information BDCP -- changes relevant to ALE

•

model to determine whether a receiver is interested in the object which is changed, then it is logged in BDCP table.

The shared Master data (SMD) tool write change Pointers i.e. it consults ALE distribution

– The ALE programs analyze change pointers and generate IDocs

• These programs are designed to ignore multiple changes and create only one IDocs

• The function module are invoked by a standard report, RBDMI DO C,selection screen allow you to specify the message type.

(87)

Master Data Distribution through Change Pointers

Communication _{To destination system}

Outbound Ale Processing Program RBDMIDOC

• • •

Analyze change Pointers Generate Idocs

Update Status of Change Pointers

Change Pointers Change Document Master Data Analyze Changes Create change Document Create or Change Master data ALE Distribution Model

(88)

Conﬁguration

• Enable Change Pointers globally

– Transaction: BD61

• This option enables the change Pointers to process Globally

• Enable Change Pointer for Message type

• This potion activate the change pointer for specific message type i.e. if the message type MATMAS is checked then only it can allow the master data distribution

• Specify fields for which change pointers are to be written

(89)

(90)

(91)

Conﬁguration – BD52

Change a ﬁeld in the master data and then execute program RBDMOIND To process the change pointers

(92)

Points Of Failure in the Outbound Process

• • • •

An error in the change pointer process An error in Ale/EDI interface Layer

An error in the IDOC structure (syntax error, conversion problem and so on)

An error in sending the IDoc to a remote SAP system

Syntax error in IDoc: status code 26

(93)

Filtering

•

object’s views are filtered out, based on the filters specified in the distribution model.

Filtering at the IDoc level creates a communication IDoc in which an • Business Scenario

• Filtering at IDoc level

– Master IDoc consults Distribution model checks filter objects values checked in ﬁlter object and master IDoc values mismatch data record dropped

(94)

Questions?

(95)