Mapping IDocs to X12 Transactions and EDIFACT Messages

While there’s no globally recognized standard cross-reference between SAP IDocs and EDI transaction sets and messages, there are some basic mappings that we can safely make.

The key thing to remember is that the business process drives your mapping.

On the inbound, that means you need to understand what the IDoc is going to do once it hits SAP. Is it creating a specific business document or posting to a particular data object such a customer or material master or an inventory update?

The key question is: what data does it need from the EDI message to post to its SAP business object?

On the outbound, the IDoc is generated with data from an SAP business document or other data object.

The key question for the outbound process is: what data does your trading partner need to receive in the EDI transmission?

The point I’m trying to make here is that literally anything can be mapped to just about anything. But your business process drives your data requirements and your data drives your processing flow, whether you’re dealing with standard or custom functionality.

There is, of course, a starting point. SAP sends and receives IDocs. But SAP is generally introduced into an environment where EDI is already being used. So the EDI transaction sets or messages have already been agreed to with the trading partners and are being used in legacy.

IDocs must therefore be selected that can carry the data in the EDI messages and then post them to a particular transaction in SAP, which is generally done through function modules. You need to understand the business process, but you also need to understand how SAP processes its IDocs in support of that business process.

And remember … if there’s no fit, you can always extend a standard IDoc with custom segments or build a completely new IDoc from scratch. And because the IDoc interface is an open, intelligent data processing API, you can always add your own code to user exits, BADIs, or build a custom function to meet any requirements demanded by the business process.

A Team Effort

The key take-away in all this is that it’s not just about about mapping messages and transactions. It’s about how the data being exchanged is processed and consumed in SAP and by the trading partner.

Selecting the correct IDoc to map to an EDI transaction or message is a team effort that requires both EDI and SAP skills and input.

If you understand the overall business process, and if you know what EDI transactions or messages are exchanged with your trading partner, you can make an intelligent decision about what IDocs to use or whether you need to do some customization.

There are some commonly accepted pairings between IDocs and EDI transaction sets and messages. OSS note 104606 maps IDocs to X12 transaction sets and 150009 lists IDocs that are commonly used in EDI.

Arvind Nagpal, in his excellent book ALE, EDI, & IDOC Technologies for SAP includes a basic mapping in Table A-2 of his Appendix (page 709 in my copy). But he’s dealing with an earlier version of SAP.

ERP Genie, which has a very useful SAP EDI portal, has published a number of spreadsheets that map IDocs to different EDI standards including EDIFACT, X12, and even VDA.

There have also been some spreadsheets kicking around for a few years from SAP that map IDocs to mostly X12 transactions.

These sources have one thing in common: they’re very basic and only include a handful of transactions. But there are literally hundreds of EDI transaction sets and messages, particularly when you consider all the different versions in use around the world.

It’s literally impossible to map everything. But we can map a lot more IDocs and understand that any mapping is only a beginning, that the business process in the end determines what we actually do.

So I’ve tried to expand on the existing cross-references and included suggested mappings based on IDoc tables and code in SAP and my own project experience and knowledge of EDI, such as it is, tweaked it a little here, and a little there, to come up with a mapping that some may find useful, at least as a starting point.

I used the most recent IDoc versions wherever appropriate. Some of these choices are arbitrary and some you may disagree with. Some pose design issues that you may not want to pursue. Message type TXTRAW, for example, can be mapped to any EDI text report. But would you really want to do it?

TXTRAW formats a text message that is distributed through SAPOffice email. I normally handle these kinds of interfaces in the EDI subsystem, by designing a report with a map and attaching it to an email sent through the regular email system. But you never know what process improvement opportunities circumstance will throw your way.

So without further ado, here is my IDoc to EDI mapping. Enjoy.

Inbound Interfaces

Outbound Interfaces