0% found this document useful (0 votes)
229 views9 pages

SAP ERP Functionality For EDI Processing Material

The document discusses how SAP determines material numbers during automated sales order creation based on EDI messages. It describes using customer material numbers, vendor material numbers, and EAN/UPC codes to identify materials. Standard SAP IDOC processing first tries the vendor number, then customer number, and finally EAN. Flexible options include using substitutions and customizing the IDOC logic.

Uploaded by

E-learning
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
229 views9 pages

SAP ERP Functionality For EDI Processing Material

The document discusses how SAP determines material numbers during automated sales order creation based on EDI messages. It describes using customer material numbers, vendor material numbers, and EAN/UPC codes to identify materials. Standard SAP IDOC processing first tries the vendor number, then customer number, and finally EAN. Flexible options include using substitutions and customizing the IDOC logic.

Uploaded by

E-learning
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

SAP ERP Functionality for EDI Processing: Material...

community.sap.com/t5/enterprise-resource-planning-blogs-by-members/sap-erp-functionality-for-edi-processing-
material-determination-for-inbound/ba-p/13626321

Creating Sales orders based on EDIFACT ORDERS or X12 850 messages is considered
a usual task for SAP SD implementation and support. However, both the SAP and EDI
worlds are quite broad and varied, and there are plenty of requirements at the intersection
of these worlds, as well as numerous options to meet them. Working as an SD consultant
since 2013 and focusing on EDI tasks, I have encountered and implemented various
techniques and am now eager to share my knowledge, based on my experience in
Consumer Products and Wholesale Distribution areas. I aim to provide a comprehensive
view of typical requirements and SAP-standard options, including benefits and
drawbacks.

In this post, I want to explore one topic: how to determine the SAP material number
based on customer order data during the creation of a sales order.

The material number is essential information for creating a sales order, and during
manual processing, a user can determine a number and enter it in the proper field.
However, it's not as straightforward for automated sales order creation based on an EDI
message. In most cases, customers do not know our material numbers. Let's see what
they usually use (and the order will become clear later):

Customer material number (CMIR) - every customer has their own ERP system
and therefore their own material number, as well as any other coding created by the
customer.
Vendor material number - a customer may consider placing this number on the
order. However, it might be related to some outdated, incorrect, or reference
material.
EAN/UPC - a barcode and a number used internationally for marking products.

The European Article Number (also known as International Article Number or EAN) is a
standard numbering system used in global trade to identify a specific retail product type,
in a specific packaging configuration, from a specific manufacturer. The most widely used
variant is EAN-13 (13 digits, the last digit is the check digit). The Universal Product Code

1/9
(UPC) is a standard numbering system mostly used in the USA and related markets. UPC
(UPC-A) consists of 12 digits that are uniquely assigned to each trade item. The last digit
is the check digit. With the addition of a leading 0, UPC is compatible with EAN.

I can distinguish two approaches depending on industry and company types: Contracts
and Catalogues.

Contract means a predefined ordering scope: customer and vendor approve a list
of saleable items with identifiers for ordering. The most common way in this case is
CMIR, mapping for a certain customer according to the contract. Also, Vendor
numbers or EAN might be used, sometimes as additional information. This
approach is preferred for FMCG and some DIY markets, for customers with a
complicated listing procedure.

Catalogue means a more flexible approach: the vendor publishes a product


catalogue with identifiers, and customers send orders using identifiers from the
catalogue. Therefore, CMIR is not applicable here, and vendor internal or catalogue
numbers or EAN/UPC are used in such cases. This approach is preferable for
Trading platforms, Construction as well as some DIY and FMCG working with SMB
Retail.

A challenge that must be considered for EAN/UPC numbers: while this number clearly
identifies a trading item for the customer, it might be related to several material numbers
on the vendor side. E.g., a different SAP number might be used for items packed in 6 or
in 12; with regular and seasonal label design; with some promotional co-packed free item
or produced in different plants, however, the EAN will be the same, so a special
selection/substitution technique must be anticipated.

Let's imagine that our customer ordes an item with EAN 8427324815226, customer
number ACME-1521 and vendor number 1521 and includes all this data to the message.
Depending on EDI standard it might look like following:

EDIFACT ORDERS

X12 850 Purchase Order

an EDI-provider XML

2/9
EDI interchange using the IDOC-based approach is still widely spread in the SAP world,
even during the transition to new S/4 systems. SAP standard IDOC processing provides
very useful ready-made solutions. There is a segment, E1EDP19 Document Item Object
Identification, dedicated to material determination and qualifiers for identifiers in question:

001 Material number used by customer


002 Material number used by vendor
003 International Article Number(EAN)

As result all three examples above are mapped in the same IDOC data as following:

If the SAP standard FM IDOC_INPUT_ORDERS is assigned for processing inbound


orders, the sequence of determination steps will be as follows:

1. SAP material number, Qualf = 002. If the value is wrong, IDOC fails regardles of
other qualifiers
2. CMIR, Qualf = 001. If the value is wrong, the system tries EAN or fails if EAN isn’t
provided
3. EAN, Qualf = 003. If the value is wrong, the IDOC fails

Let's examine this logic in more detail. The FM IDOC_INPUT_ORDERS processes IDOC
data into a structure and then creates a sales order through batch processing. As a result,
order creation is almost the same as manual entry. Based on this, it's easier to
understand the opportunities and limitations of the processing.

First of all, the vendor number is considered. If the value with qualifier 002 exists in the
message, the system tries to use this value for the Material field of the sales order. The
value will be accepted in two cases: if it's a correct SAP material number or if a material
substitution record is created for this value (t-codes VB11, VB12, VB13) and a correct
SAP material is provided by the substitution. However, if a correct SAP number is not
determined, sales order creation fails regardless of other material information in the
IDOC.

3/9
At first glance, it looks great for the vendor that a customer sends an SAP number.
However, it's my least favorite option, especially if the vendor doesn't use substitution.
First of all, the existence of a vendor number blocks the use of CMIR, along with its
flexibility and transparency. Moreover, a customer might send a wrong or outdated
number, causing the IDOC to fail even if other material identifiers are correct. Additionally,
a customer might use a catalog vendor number that corresponds to several SAP numbers
on the vendor side. On top of that, it's a headache during the go-live of a new ERP.
Coordinating the replacement of outdated vendor numbers with new ones is quite
challenging, especially if new materials have been created a couple of weeks before go-
live. To sum up, using vendor material numbers is the simplest but not flexible enough
approach. To mitigate these drawbacks, I usually use the following methods:

Be prepared to use VB12 for error handling and understand the limitations for CMIR
usage.
If the CMIR technique is the preferred approach, but some customers provide only
the vendor number, it may be reasonable to map the vendor number to the CMIR
segment and process it as CMIR.
If we have reliable CMIR or EAN, it may be reasonable to exclude the vendor
number from the logic by changing the IDOC mapping. Vendor material might be
stored in the sales text or as E1EDP19 with a custom qualifier to bypass the
standard step.
Custom extension of IDOC processing to adjust system logic (though I consider this
a last resort).

If the vendor number is not provided (fortunately, as you now understand), the next step is
CMIR determination.

SAP standard CMIR determination is based on customer-material info record functionality


(transaction codes VD51, VD52, VD53). In the manual sales order creation process, a
user may fill in the customer material field, and the material field will be populated if a
relevant record exists. Similarly, during IDOC processing, the customer material field is
populated by the value from the E1EDP19 Qualf = 001 segment, and then the material
might be determined. If no CMIR record is found, IDOC processing moves to the next
step, EAN-based determination, which is a flexible and reliable approach.

Also, you can gain additional flexibility by combining the CMIR technique (VD52) with
Material Substitution (VB12). Technically, CMIR replaces the customer material number
with the so-called "material entered," which is subject to replacement by Material
Substitution. So, just remember the correct sequence: VD51 is the first step, followed by
VB12.

The CMIR technique is simple, clear, and robust, directly meeting widely spread customer
requirements. However, it entails some trade-offs and limitations.

4/9
The main trade-off of this approach is the effort required for the maintenance of customer-
material info records. However, this might also be an advantage if it reflects contractual
conditions and provides the required control of ordered materials.

Another limitation is that validity dates functionality is not provided for CMIR. It's not
possible to change material mapping in advance or use different mappings at the same
time for different delivery dates. A partial solution to this limitation is combining CMIR with
Material Substitution, which supports validity dates. It's possible to keep CMIR unchanged
and add date-dependent logic to VB12.

Also, Unit of Measure (UoM) determination isn't supported by CMIR. If a customer sends
orders with definite UoMs, it's not an issue, but sometimes more flexible logic is required.
In any case, UoM determination is a pretty interesting topic and is worth a separate post.

If Vendor material and Customer material haven't been provided, or if CMIR hasn't been
recognized, the third step is applied: EAN-based determination. This step is fairly simple;
a value from segment E1EDP19 Qualf = 003 is used as entered material, and the related
SAP material might be determined if a Material Substitution record (VB12) exists. Or if the
EAN equals the SAP material number, but it's supposed that nobody uses EANs as
system material numbers. The most important thing to know is that there is no connection
with the Material Master. EANs are usually maintained in a related field of material master
records, assigned to certain UoMs. But standard IDOC Orders processing doesn't use
this information; only Material Substitution records are considered. There are two
important consequences of this. Firstly, extra effort is needed to maintain and keep
consistent EANs for order processing and master data EANs. And a more distant
consequence is related to outbound messages, like ORDRSP (X12 85), DESADV (X12
856), and INVOIC (X12 810). While Order creation ignores material master data,
outbound messages use EAN from the material master only. It may cause an issue if a
customer needs the same EAN in ORDERS and in outbound messages.

Let me provide you with some examples to clarify the description provided above. These
examples are individual steps, and you can imagine how they work in combination, as
previously described

1. Customer material info record

Item 10: E1EDP19 QUALF = 001, IDTNR = ACME-1521

Customer-material info record exists, ACME-1521 is mapped to material number 1521


(VD52):

5/9
In this case, material 1521 will be used for order creation.

2. Customer material info record + Material substitution

Item 20: E1EDP19 QUALF = 001, IDTNR = ACME-1531

Customer-material info record exists, ACME-1531 is mapped to material number 1531


(VD52):

Also material substitution record exists and is valid for the delivery date (VB12): 1531 ->
1561

6/9
In this case, material 1561 will be used for order creation.

3. Vendor material number

Item 30: E1EDP19 QUALF = 002, IDTNR = 1521

In this case, material 1521 will be directly used for order creation.

4. Reference vendor material number

Item 40: E1EDP19 QUALF = 002, IDTNR = 1500-000

Material substitution record exists and is valid for the delivery date (VB12): 15000-000 ->
1521

7/9
In this case, material 1521 will be used for order creation.

5. EAN-based determination

Item 50: E1EDP19 QUALF = 003, IDTNR = 8427324815219

Material substitution record exists and is valid for the delivery date (VB12):
8427324815219 -> 1521

In this case, material 1521 will be used for order creation.

In conclusion, I believe that consultants need a deep understanding of the outcomes and
trade-offs of standard techniques. This often helps to meet customer requirements
without any development or to reveal complicated scenarios at the early stage of a

8/9
project.

I hope you find this material informative. Please share your comments and any other
interesting techniques in the EDI area.

Acknowledgements and System Overview


Thanks to my colleagues at Capgemini and others who explored this topic with me across
numerous projects. Also, thanks to Capgemini for providing me with a sandbox system,
which was S4HANA ON PREMISE Release 2022 SP 01 (02/2023) FPS, SAP S/4HANA
2022.

9/9

You might also like