Scribd
Upload
528 views7 pages

Mapping A Customers EDI Field in and Out of SAP

1. The document describes a process for mapping customer-specific fields from an EDI 850 order into SAP and then back out to subsequent EDI documents like an 810 invoice. These fields are passed into and out of EDI technical text fields rather than standard SAP fields since SAP does not need the data for its own processes. 2. The process involves mapping the incoming 850 fields into EDI technical text on the sales order header and items. These texts then copy over to the invoice document and are available to map from the resulting INVOIC IDoc to the outgoing 810. 3. By using EDI technical text fields rather than custom SAP fields, no custom development is required and

Uploaded by

SOUMEN DAS
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
528 views7 pages

Mapping A Customers EDI Field in and Out of SAP

1. The document describes a process for mapping customer-specific fields from an EDI 850 order into SAP and then back out to subsequent EDI documents like an 810 invoice. These fields are passed into and out of EDI technical text fields rather than standard SAP fields since SAP does not need the data for its own processes. 2. The process involves mapping the incoming 850 fields into EDI technical text on the sales order header and items. These texts then copy over to the invoice document and are available to map from the resulting INVOIC IDoc to the outgoing 810. 3. By using EDI technical text fields rather than custom SAP fields, no custom development is required and

Uploaded by

SOUMEN DAS
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

Mapping a Customers EDI field in to and then out of SAP

Customers that transact Orders to you via an EDI X12 850 often need you to send certain, customer specific, fields back
to them on subsequent documents. This is often a requirement at both the header and item levels of the order. A common
example of a header field would be the department number. It makes sense for the customer to have the department
number returned on subsequent documents but we don't have any use for that number in our SAP system other than to
store the details and pass it to subsequent documents. 

In this example I am going to use the Internal Vendor number as my example at the header level and Customer's PO item
number as my example at the item level.
Note: Best practice is to map the Customer PO number to the "Purchase Order Item" field as shown in the diagram below.

Understanding the Overall Design


Any data that your customer want to be returned to them in subsequent EDI documents, that you don't have a use for, will
be passed in and out of sales order header and item text accordingly. You will need to configure an "EDI Technical Text"
for the sales order header and line as well as for the billing document header and line. You will then use text copy control
(shown in the diagram below) to copy the text from the sales order on to the billing document. This text will then
automatically appear in the corresponding INVOIC IDoc and thus available at mapping time.

The decision tree for customer required fields is as follows:


1. Is there a standard place for this in SAP
1. IF "YES" then map it there
2. IF "NO" then
1. Do you require this data for your own process?
1. IF "YES" then create and map to ZFIELD (custom append to VBAK, VBAP)
2. IF "NO" then map to text field described in this paper

Following the process


To describe the process let's refer to the process diagram below and follow the steps by number.
STEP 1: Understanding the 850 message
The ANSI X12 850 from the customer has the following 2 segments:
REF*IA*115~
…
PO1*20*5*EA*7.00**KB*17*VA*3234~
The REF segment is qualified by the 1st field (REF01) as "IA" which implies that the customer's internal vendor number
for us is "115". The customer would like for this number to be returned on the REF segment in the associated 810 Invoice.
We can achieve this by updating the external reference field for this customer in master data, but for the purposes of this
paper we will map it in and out of text.
The PO1 segment indicates that the customer's PO item number is "20". Once again the customer requires us to pass
back this number in subsequent EDI transactions. For the purposes of this paper we will map it in and out of text.
STEP 2: Mapping the 850 to the ORDERS IDoc
I have used Gentran Server NT's mapping tool to demonstrate what I am doing here. 
Header Mapping
Referring to the diagram below you can see that when I am mapping the REF segment I am looking at the first field (the
qualifying field for the segment). If I find the value to be "IA" then I know that I am dealing with the Internal Vendor number
so I need to map field REF02 to my EDI technical text with the prefix of "Internal Vendor:" (stored in temporary element
REF_IA). The prefix is important because we will be looking for this text exactly as is when we map the outbound INVOIC
IDoc to the 810 in STEP 7. Element REF_IA is mapped to TDLINE in the E1EDKT2 segment.
Item Mapping
Referring to the diagram below you can see that I am mapping the PO1 segment element 1 (Item number of the
customer) to my EDI technical text for the item, with the prefix of "PO101:". The prefix is important because we will be
looking for this text exactly as is when we map the outbound INVOIC IDoc to the 810 in STEP 7.

STEP 3: The ORDERS IDoc


The resulting ORDERS IDoc Header text segment looks like this:
And the resulting ORDERS IDoc item text segment looks like this:

STEP 4: The Sales Order


The resulting Sales Order EDI technical header text looks like this:

And the resulting Sales Order EDI Technical Item text looks like this:
STEP 5: Create the Invoice / Billing Document
Now it's time to create the subsequent document for the sales order, namely the billing document. Because of the Text
copy control from the sales order to the invoice we now have the following text on the billing document at the header level:

And the following text on the Invoice / Billing Document item level:

STEP 6: The INVOIC IDoc


The creation of the INVOIC IDoc is typically triggered through output determination. Once the INVOIC IDoc for the invoice
has been created the EDI Technical text for the header looks like this:

And the item text looks like this:


STEP 7: Mapping the INVOIC IDoc to the 810
Header Text Mapping
IF E1EDKT2-TDLINE(16) = “Internal Vendor:” then map the following:
REF01 = “IA”;
REF02 =  E1EDKT2-TDLINE+17(20); "Starting at position 17 read for 20 chars
Item Text Mapping
IF E1EDPT2-TDLINE(6) = “PO101:” then map the following:
IT101 = E1EDPT2-TDLINE+7(10); "Starting at position 7 read for 10 chars
STEP 8: Reviewing the 810 message
The resulting ANSI X12 810 message now has the data that was sent in via the 850 in STEP 1.

REF*IA*115~
…
IT1*20*5*EA*7.99*VA*3234~
Advantages of doing it this way?
With this technique you can do this for any fields that the customers needs back for any outbound EDI message to them
that come from SAP and linked to the Sales Order document flow. I.e. The requirement for an ASN 856 can be met the
same way. Advantages of this approach include:
 No custom fields required to store the data
 No custom code required to implement the solution
 Once the config of the EDI Technical text types are in place any further changes needed can be completely
handled by the EDI mapping team. This is desirable because it really is a pure EDI requirement to return a value to the
customer that we actually have no interest in

Other considerations
 Since the EDI technical text is really only utilized by the EDI mapping team and really should not be seen or at
least changed by anyone, consider implementing some change control or authorizations in order to ensure the integrity of
the text is maintained (i.e. it is not changed)
 You cannot allow for the manual creation of line items on EDI orders as they will not contain the EDI text - It is bad
practice to allow for the creation of line items on EDI orders so refrain from that practice.
If you have any comments or suggestions just leave a comment below.

You might also like