Excerpt from What on Earth is an SAP IDoc?

Excerpt from Chapter 1 of What on Earth is an SAP IDoc? by Jelena Perfiljeva.

Every academic book begins with a rather long chapter on definitions and other important, but super boring stuff. I do not like that at all and always end up flipping past those pages to get to juicier parts with the screenshots. After all, as Alice once wisely noted: “…and what is the use of a book without pictures or conversations?” (“Alice’s Adventures in Wonderland”, by Lewis Carroll). Indeed. So why don’t I just show you an IDoc instead of talking about it?

Here it is (see Figure 1.1):

Figure 1.1: IDoc example

It probably looks unimpressive and somewhat confusing at the same time, so maybe skipping the definitions isn’t the best idea after all, huh? Let’s go over some basics then, shall we?

It is important to understand that IDoc is just a data container in SAP. It does not have any magical powers and cannot solve any issues with business process, or other technical interface challenges. But it can take data from point A to point B relatively consistently and does have some nice bonus features.

IDoc display
You can view IDoc using transaction codes WE02 and WE05. There is no significant difference between these two transactions and they both are assigned to the same
program.

With this in mind, it is reasonable to ask—if IDoc is just a container, how does it get into SAP and what does it do?

Great question! (That’s what people usually say when they have already prepared a very clever answer.) IDocs cannot do anything by themselves and usually they are part of some interface. What is the interface, you ask? Well, when two computer systems love each other very, very much… um… they might want to exchange some information.

For example, when a purchase order is created in System A, it might want to tell System B that a sales order needs to be created. And, to be nice, System B then sends a confirmation back to System A (“yep, got your order!”) and then later a shipping notification. So, when System A has some information, how does it send it to System B and vice versa? (Assume that in this example System B is an SAP system, so it is the
one we care about.) There are different ways to do that. To define how exactly these systems will communicate, in System B (SAP) we would create a port (Figure 1.2).

More detail on that later but, for example, a port could point to an XML file, or a remote connection (called “RFC connection” in SAP). Remote connection is a way for two systems to “talk” to each other.

Inbound and outbound interfaces
The interfaces can either be inbound or outbound depending on whether they bring data into the SAP system (inbound) or take it out of it (outbound).

Figure 1.2: Port example

The communication part is rather simple and now we arrive at more complex questions: how does System B know what System A is sending it and what to send back? Also, how does it create an order? Is there some kind of BAPI, or a Z program? How would it know Ship-to and Sold-to? And the material number—wouldn’t System A send its own? And how does it send a confirmation? Does it track changes in the sales order? Isn’t it very complicated? Okay, okay, hold your horses. This is just the definition section, there are over 100 pages to go. We will get there, I promise.

The next part of the interface in SAP is called the partner profile (see Figure 1.3). There are different types of partners available (customer, vendor, and logical system to name a few). For this example, we would either choose customer type (because we are dealing with a customer in System A), or logical system (because, well, it is a system). We will explore the differences in Chapter 2.
Transaction codes: port and partner profile
Port is defined in transaction WE21 and partner profile in transaction WE20. If you feel it would be more logical to have these transactions in reverse order (because port
is defined first) you are not alone.

In the newly created partner profile, we would specify that we expect to receive from this partner the sales orders and we will send back the order confirmations and shipment notifications.

Keep reading in What on Earth is an SAP IDoc?…

This book provides you with the essential knowledge you need to work with SAP IDoc interfaces successfully. Walk through the IDoc anatomy and different kinds of segments. Dive into inbound and outbound IDoc interfaces and learn how to create a port and logical system. Walk step by step through how to configure IDoc interfaces for various business scenarios including sending an invoice to an EDI partner, receiving a sales order from an EDI partner, and receiving material master data from an external system. Learn how to use output and change pointer techniques. Examine how to monitor and troubleshoot post-IDoc interface implementation activities and get a handle on archiving best practices. Navigate IDoc interface enhancement options including adding segments and user exits. By using detailed examples, tips, and screenshots, the author brings readers up to speed on the fundamentals of SAP IDocs.

– Fundamentals of inbound and outbound IDoc interfaces and configuration
– Learn how to implement interfaces with ALE and EDI
– Troubleshoot common post-implementation challenges
– Quick reference guide to common IDoc transaction codes and reports

Author Jelena Perfiljeva is a Technical SAP Analyst at Elster Solutions, LLC in North Carolina. Since her SAP career started by accident 10 years ago, she has worked as an ABAP programmer and general SAP problem solver in the wholesale, professional service, and manufacturing industries. Her duties include implementation and support of numerous EDI and IDoc interfaces.  Jelena’s lack of any official SAP credentials has not prevented her from becoming an SAP Mentor, an SCN blogger, and a speaker at international SAP events. She was SCN Member of the Month in April 2013.  When she is not debugging SAP or answering questions on SCN, she enjoys using Google for finding new food recipes to test on her unsuspecting family members.