http://www.edibasics.co.

uk/

EDI Messages
1.1

Other Pictures: source doc Edi General presentation

Edi Messages to sap Idocs:

EDI
SAP
message
Standard Message

SAP Idoc

Delfor In

EDIFACT

DELINS

DELFOR01

Deljit In

EDIFACT

SEQJIT

SEQJIT01

Deljit In

EDIFACT

DELINS

if kanban or transport number

If no kanban or transport
DELFOR01 number

Desadv Out EDIFACT

DESADV

DELVRY03

Invoic In

EDIFACT

INVOIC

INVOIC01

Delins In

ODETTE

DELINS

DELFOR01

Caldel In

ODETTE

SEQJIT

SEQJIT01

Aviexp Out

ODETTE

DESADV

DELVRY03

Invoic out

ODETTE

INVOIC

INVOIC01

4905 In

VDA

DELINS

DELFOR01

4915 In

VDA

SEQJIT

SEQJIT01

4913 In

VDA

DESADV

DELVRY03

Comments

Integrate customer demand

EDI
message

Standard

SAP
Message

SAP Idoc

Delfor In

EDIFACT

DELINS

DELFOR01

Deljit In

EDIFACT

SEQJIT

SEQJIT01

Deljit In

EDIFACT

DELINS

if kanban or transport number

If no kanban or transport
DELFOR01 number

Desadv Out EDIFACT

DESADV

DELVRY03

Invoic In

EDIFACT

INVOIC

INVOIC01

Delins In

ODETTE

DELINS

DELFOR01

Caldel In

ODETTE

SEQJIT

SEQJIT01

Aviexp Out

ODETTE

DESADV

DELVRY03

Invoic out

ODETTE

INVOIC

INVOIC01

4905 In

VDA

DELINS

DELFOR01

4915 In

VDA

SEQJIT

SEQJIT01

4913 In

VDA

DESADV

DELVRY03

Comments

In this case, customer sends only idoc delfor :

In case of LZJ, the customer send edi message converted in idoc DELINS for the forecast.

VDA develops standards and best practices to serve the needs of companies within the German automotive industry. The VDA has developed
over thirty messages to meet the need of companies such as VW, Audi, Bosch, Continental and Daimler AG.

A list of VDA document standards is provided below:

4902

Transport Label Barcode-enabled incl. VDA 4913

4905

Call of

4905/2 Call of Delivery Instruction (Odette Message DELINS)

4906

Invoice

4907

Remittance Advice

4908

Credit Advice

4911

Prices

4912

Delivery Note incl. VDA 4913

4913

Delivery Note

4914

Odette specification for file transfer

4915

Detailed Call Of (JIT)

4916

Call Of Just-in-sequence

4918

Vehicle Identification and Transport Data

4919

Vehicle Arrival and Departure Notification

4920

Forwarding Instruction

4921

Delivery Data

4922

Forwarding Instruction incl. VDA 4913

4923

Enquiry (Odette Message ENQIRY)

4924

Ofer/Quotation (Odette Message OFFERR)

4925

Purchase Order

4926

Acknowledgement of Order (Odette Message REPORD)

4927

Equipment Statement and Equipment Movement

4929

Delivery Note (Odette Message AVIEXP)

4932

Invoice (Odette-Nachricht INVOIC)

4951

Engineering Data Message (ENGDAT)

4970

Delivery Forecast

4971

Collection Order

4972

Dispatch Note ex Works/Plant

4973

Vehicle Arrival

4974

Vehicle Departure

4975

Change / Information Note

4976

Change / Information Confirmation

4977

Damage Note

4978

Repair Start / End Note

4979

Ready for Dispatch Note

4980

Loading Instructions

Mapping ANSI X12 to SAP Message Type and IDoc Type:

204 Motor carrier shipment information

The logical message is SHPMNT or IFTMIN, the IDoc type SHPMNT03.

214 Transportation carrier shipment status message

The logical message is TRXSTA, the IDoc type TRXSTA01. Inbound processing is supported.

304 Shipping instructions

The logical message is SHPMNT or IFTMIN, the IDoc type SHPMNT03.

810 Invoice or billing document (also 880), EDI - Inbound INVOIC posting configuration
The logical message is INVOIC, the IDoc type INVOIC01.

812 Credit and debit advice

The logical messages are CREADV or DEBADV, the IDoc types PEXR2001 and PEXR2002.

820 Payment order and credit advice

For the payment order, the logical message is PAYEXT (REMADV), the IDoc types PEXR2001 and
PEXR2002.
For the credit advice (ERS - Evaluated Receipt Settlement), the logical message is GSVERF, the IDoc
type GSVERF01.

823 Lockbox
The logical message is LOCKBX, the IDoc type FINSTA01. Inbound processing is supported.

830 Delivery schedule (LAB)

The logical message is DELINS (from the EDI standard ODETTE) or DELFOR, the IDoc type is
DELFOR01.

832 Price catalog (also 879, 888, 889)

The logical message is PRICAT, the IDoc type PRICAT01. Outbound processing is supported.

834 Benefit enrollment and maintenance

The logical message is BENREP, the IDoc type BENEFIT1. Outbound processing is supported.

840 Request
The logical message is REQOTE, the IDoc types ORDERS01 to ORDERS04.

843 Quotation
The logical message is QUOTES, the IDoc types ORDERS01 to ORDERS04. Outbound processing is
supported.

850 Purchase order or order (also 875)

The logical message is ORDERS, the IDoc types ORDERS01 to ORDERS04.

852 Stock and sale data

The logical message is PROACT, the IDoc type PROACT01.

855 Ordering or order response (also 865)

The logical message is ORDRSP, the IDoc types ORDERS01 to ORDERS04.

856 Transport and shipping notification (ASN - Advanced Ship Notification)

For transport in the SAP application, the logical message is SHPMNT or SHPADV, the IDoc types
SHPMNT01 to SHPMNT03.
For delivery in the SAP application, the logical message is DESADV, the IDoc types are DESADV01
(expires) or DELVRY01 and DELVRY02.

860 Ordering or order modification (also 876)

The logical message is ORDCHG, the IDoc types ORDERS01 to ORDERS04.

861 Credit advice (ERS - Evaluated Receipt Settlement)

The logical message is GSVERF, the IDoc type GSVERF01.

862 delivery schedule (FAB)

The logical message is DELINS (from the EDI standard ODETTE) or DELJIT, the IDoc type is DELFOR01.

864 Text message

The logical message is TXTRAW, the IDoc type TXTRAW01. Inbound processing is supported.

940 Shipping order and stock order

The logical message is SHPORD or WHSORD, the IDOC type DELVRY01.

945 Shipping confirmation and stock confirmation

The logical message is SHPCON or WHSCON, the IDoc type DELVRY01.

997 Functional Acknowledgment

This is a technical confirmation. This is not exchanged via an individual message but the status report for
IDoc processing. The status values used are:

"22" Shipping OK, acknowledgment has yet to come

"16" Functional Acknowledgment positive
"17" Functional Acknowledgment negative
The status values "14" and "15" are available for the Interchange Acknowledgment accordingly.

Please check these some mapping EDIFACT -> Message Type/IDoc Type.
EDIFACT
CREADV
CREEXT
CREMUL
CUSDEC
CUSRES
DEBADV
DEBMUL
DELFOR
DELJIT
DESADV

Description
Credit Advice Message
Extended Credit Advice
Multiple Credit Advice
Customs Declaration Message
Customs Response Message
Debit Advice Message
Multiple Debit Advice
Delivery Schedule Message
(LAB/FAB)
Just In Time Message
(LAB/FAB)
Despatch Advice

DIRDEB
FINSTA
FUNACK

Direct Debit Message

Financial Satement
Functional Acknowledgement

GENRAL

General Message

Message/IDoc Type
CREADV/PEXR2001
CREADV/PEXR2001
CREADV/PEXR2001
EXPINV/IMPINV
EXPINV01/IMPINV01
TXTRAW/TXTRAW01
DEBADV/PEXR2001
DEBADV/PEXR2002
DELINS/DELFOR01
DELFOR/DELFOR01
DELINS/DELFOR01
DELFOR/DELFOR01
DESADV/DESADV01
DELVRY/DELVRY01
SHPMNT/SHPMNT02
DIRDEB/FINSTA01
FINSTA/FINSTA01
Status report/EDIDS
STATUS/SYSTAT01
TXTRAW/TXTRAW01

IFTMIN
IMPDEF

IFTMIN/DELVRY01
IFTMIN/SHPMNT02
EDI Implementation Guideline
SYRECD/SYRECD01
Definition Message
SYIDOC/SYIDOC01

INVOIC
INVRPT
ORDCHG
ORDERS
ORDRSP
PARTIN
PAYEXT
PAYMUL
PAYORD
PRICAT
PRODAT
QUOTES
REMADV
REQOTE
SLSFCT
SLSRPT

Transport Instructions

Invoice
INVOIC/INVOIC01
Inventory Report
PROACT/PROACT01
Purchase Order Change Request
ORDCHG/ORDERS01
Purchase Order
ORDERS/ORDERS01
Purchase Order Response
ORDRSP/ORDERS01
Party Information Message
CREMAS/CREMAS01
DEBMAS/DEBMAS01
Extended Payment Order
PAYEXT/PEXR2001
Multiple Payment Order
PAYEXT/PEXR2001
Payment Order Message
PAYEXT/PEXR2001
Price/Sales Catalogue Message
PRICAT/PRICAT01
Product Data Message
PRICAT/PRICAT01
Quotation Message
QUOTES/ORDERS01
Remittance Advice
REMADV/PEXR2001
Request For Quotation
REQOTE/ORDERS01
Sales Forecast Message
PROACT/PROACT01
Sales Data Report
PROACT/PROACT01

ODETTE
The Organisation for Data Exchange by Tele Transmission in Europe is a
group that represents the interests of the automotive industry in Europe.
They are the equivalent of the Automotive Industry Action Group (AIAG)
in North America.
The organisation develops tools and recommendations that improve the flow of goods,
services product data and business information across the whole automotive value chain.
ODETTE has been responsible for developing communications standards such as OFTP
and OFTP2.0, constant improvement processes such as Materials Management
Operations Guideline / Logistics Evaluation (MMOG/LE) and automotive specific document
standards as defined below:
DELINS

Delivery Forecast / Delivery

EXHAND

For Delivery Schedule Exception Handling

CALDEL

JIT Delivery

SYNCRO

Sequenced Delivery

KANBAN

KANBAN Delivery

FORDIS

Ready for Dispatch Advice

AVIEXP

Dispatch Advice

INVOIC

Invoice

STOACT

Inventory Report

TRINAD

Forwarding Instruction

CONSUM

Consignment Consolidation

ORDERR

Purchase Order

ORDCHG

Order Change

REPORD

Order Response

PRILST

Price List Based

REMADV

Remittance Advice

STATAC

Account Statement

Key points
Depending of the customer edi standard, the edi application will convert the customer
message in sap standard idoc DELINS.

Following rules must be analysed or discussed with the customer to interpret

the content of the idoc and to find the way to parameter the schedule agreement which
will store the content of it.

1. Which are the rules to identify the concerning schedule agreement..

2. Which is the frequency of the transmission for each type of message.
3. Which type of message will contain which type of information : forecast,
firm,mixed,jit(4=forecast,1=firm)

4. What is the rule of update the existing schedules lines : modification between to
given dates or cancel and replace. (field labkey in idoc: 1= modif 2 = cancel/r)
5. Do we receive cumulative qtys or should we calculated them.
After this analyse, we should be able to attribute a type of schedule agreement
and the right parameters.
6. Are the schedule dates expressed in arrival date or departure dates.
After this analyse, we should be able to attribute a type of schedule agreement
and the right parameters.

EDI Document Standard

http://www.edibasics.com/edi-resources/document-standards/
There are many EDI document standards but what do they all mean and where are they
used?
ANSI ASC X12
In 1979, the American National Standards Institute (ANSI) chartered the
Accredited Standards Committee (ASC) X12 to develop uniform standards for
inter-industry electronic exchange of business transactions, namely electronic
data interchange. ANSI X12 was originally conceived to support companies
across diferent industry sectors in North America however today there are
more than 300,000 companies worldwide using X12 EDI standards in daily
business transactions. ASC X12 also contributes to UN/EDIFACT messages that
are used widely outside of the United States.

Further information about ANSI X12 can be found here

Further information about the ANSI X12 document types can be

found here

EANCOM
This standard was originally conceived in 1987 by the EAN General Assembly
and was to be developed on the then emerging international UN/EDIFACT
standard. The EANCOM messages, maintained by GS1, are more detailed in
nature compared to the TRADACOMS message set. EANCOM was originally
developed for the retail sector and has subsequently grown to become the most
widely used UN/EDIFACT subset and is now found in a variety of other industry
sectors such as healthcare, construction and publishing.

Further information about EANCOM can be found here

UN/EDIFACT
United Nations/Electronic Data Interchange for Administration, Commerce and
Transport is the international standard that was developed by the United
Nations. The work of maintenance and further development of this standard is
done through the United Nations Centre for Trade Facilitation and Electronic
Business (UN/CEFACT) under the UN Economic Commission for Europe. The
EDIFACT standard provides a set of syntax rules to structure, an interactive
exchange protocol and provides a set of standard messages which allow multicountry and multi-industry exchange of electronic business documents. EDIFACT
is widely used across Europe, mainly due to the fact that many companies
adopted it very early on. EDIFACT has seen some adoption in the ASPAC region,
however, there are currently more XML-based standards being used in this
particular region today.

Further information about EDIFACT can be found here

Further information about the EDIFACT document types can be

found here

HIPAA
The Health Insurance Portability and Accountability Act was enacted by the U.S
congress in 1996. A key component of HIPAA is the establishment of national
standards for electronic health care transactions and national identifiers for
providers, health insurance plans and employers. The standards are meant to
improve the efficiency and efectiveness of the North American health care
system by encouraging the widespread use of EDI in the U.S health care
system. The HIPAA EDI transaction sets are based on X12 and the key message
types are described below.

Further information about HIPAA can be found here

Further information about the HIPAA document types can be found here

ODETTE
The Organization for Data Exchange by Tele Transmission in Europe is a group
that represents the interests of the automotive industry in Europe. They are the
equivalent of the Automotive Industry Action Group (AIAG) in North America.
The organization develops tools and recommendations that improve the flow of
goods, services product data and business information across the whole
automotive value chain. ODETTE has been responsible for developing
communications standards such as OFTP and OFTP2.0, constant improvement

processes such as Materials Management Operations Guideline / Logistics

Evaluation (MMOG/LE) and automotive-specific document standards as defined
via the link below.

Further information about ODETTE can be found here

Further information about the ODETTE document types can be

found here

RosettaNet
This consists of a consortium of major computer, consumer electronics, semiconductor manufacturers, telecommunications and logistics companies working
together to create and implement industry-wide, open e-business process
standards. These standards form a common e-business language, aligning
processes between supply chain partners on a global basis. The RosettaNet
document standard is based on XML and defines message guidelines, business
processes interface and implementation frameworks for interactions between
companies. Using RosettaNet Partner Interface Processes (PIPs), business
partners of all sizes can connect electronically to process transactions and move
information within their extended supply chains. Further information about
RosettaNet PIP documents can be found from the link below.

Further information about RosettaNet can be found here

Further information about the RosettaNet document types can be

found here

SWIFT
The Society of Worldwide Interbank Financial Telecommunication was formed in
1973 and is headquartered in Brussels. SWIFT operates a worldwide financial
messaging network which exchanges messages between banks and financial
institutions. SWIFT also markets software and services to financial institutions,
much of it for use on the SWIFTNet Network. SWIFTNet is the infrastructure used
to exchange these documents and FIN, InterAct and FileAct are used to encode
the SWIFT documents for transmission. The majority of interbank messages use
the SWIFT network. As of November 2008, SWIFT linked 8740 financial
institutions across 209 countries. The SWIFT document standard is split into four
areas, Payments, Trade Services, Securities and Trading.

Further information about SWIFT can be found here

Further information about the SWIFT document types can be found here

Tradacoms

This is an early standard for EDI and was primarily used in the UK retail sector. It
was originally introduced in 1982 as an implementation of the UN/GTDI syntax,
one of the precursors of EDIFACT, and was maintained and extended by the UK
Article Numbering Association, now called GS1 UK. The standard is more or less
obsolescent since the development of it efectively ceased in 1995 in favor of
the EDIFACT EANCOM subsets. Despite this it has proved durable and the
majority of the retail EDI traffic in the UK still uses it today.

Further information about Tradacoms can be found here

Further information about the Tradacoms document types can be

found here

VDA
This organization develops standards and best practices to serve the needs of
companies within the German automotive industry. The VDA has developed over
thirty messages to meet the need of companies such as VW, Audi, Bosch,
Continental and Daimler AG. Further information about these messages can be
found via the link below.

Further information about VDA can be found here

Further information about the VDA document types can be found here

VICS
The Voluntary Inter-industry Commerce Standard is used by the general
merchandise retail industry across North America. It is a subset of the ANSI ASC
X12 national standard. VICS EDI is being utilized by thousands of companies,
department and specialty retail stores, mass merchandisers and their
respective suppliers. In 1988 GS1 US became the management and
administrative body for VICS EDI. GS1 US also manages the ASC X12 derived
Uniform Communication Standard (UCS) for the grocery industry and
Industrial/Commercial Standard (I/C) for the industrial sector.

OFTP (ODETTE File Transfer Protocol) fornece uma maneira padro para sistemas de
computador heterogneos para se comunicar uns com os outros.

OFTP (recomendao da Associao da Indstria Automvel (VDA) no. 4914/2) a definio

do File Transfer Protocol (FTP) a ODETTE Grupo IV para as camadas ISO / OSI 4 a 7. Ele
permite transferncias de dados de diferentes tipos de arquivos. OFTP usado na indstria
automvel europeia e os seus fornecedores como o protocolo padro. Ele tambm usado
pela indstria qumica e apenas introduzido por outros setores (bancos, transportes).

EDI Messaging Protocols

http://www.edibasics.co.uk/edi-resources/messaging-protocols/

OFTP
http://www.jscape.com/blog/oftp-odette-file-transfer-protocol
AS2
http://www.jscape.com/blog/bid/100435/AS2-Simplified

AS2, FTP, OFTP, HTTP to name just a few EDI Messaging Protocols
but what are they and what do they mean?

1.2 AS1
Applicability Statement (AS) 1 was developed by the IETF (Internet Engineering Task
Force) to implement secure and reliable messaging over SMTP and S/MIME. It was the
first AS protocol to be developed and uses signing, encryption and MDN conventions.
(MDN refers to Message Disposition Notifications or the ability to provide Return
Receipts). As with any AS file transfer, AS1 file transfers typically require both sides of the
exchange to trade SSL certificates and specific trading partner" names before any
transfers can take place.

1.3 AS2
Applicability Statement (AS) 2 uses the same signing, encryption, and MDN
conventions used in the original AS1 protocol. AS2 messages are usually sent across the
internet using the HTTP or HTTPS protocol. AS2 has been widely deployed as a point to
point connectivity method. AS2 offers many advantages over standard HTTP, including
increased verification, and security achieved through the use of receipts and digital
signatures. AS2 transactions and acknowledgements also occur in real-time, increasing the
efficiency of document exchanges. The U.S company Walmart was one of the first
companies to help drive the adoption of AS2 across the retail sector.

1.3.1 AS3
Applicability Statement (AS) 3 was developed by the IETF to implement secure and
reliable messaging over FTP. AS3 is based upon the secure version of the FTP protocol,
rather than HTTP. AS3 transport is S/MIME over FTP and operates a client/server model
like FTP, as opposed to the peer-to-peer approach used by AS2. AS3 also uses MDNs
(receipt notifications) like AS2. AS3 is a push/pull protocol and the client side AS3 does not
require a listener to be always aware of inbound traffic (whereas AS2 always requires a
persistent connection for the listener). AS3 may be especially well suited for banking and
other industries where there are heavy investments in FTP scripting, applications and
security.

1.4 AS4
Applicability Statement (AS) 4 offers secure B2B document exchange using web
services and was developed by the sub-committee of the OASIS ebXML messaging
services technical committee. AS4 is still in its draft definition format. The AS4 profile
provides the market place with an entry level solution that allows companies to begin
utilising their internal SOA based platforms for external B2B messaging while at the same
time taking on some of the more complicated aspects of web services. The European
Aerospace industry is proposing to use AS4 as its communication standard for sending
ebXML related B2B documents between trading partners. Further information about AS4
can be found on the Drummond Group site,here.

1.5 ebMS
ebXML Messaging Service offers a secure and reliable SOAP/Web Services based
packaging, routing and transport protocol as defined by the ebXML specifications. The
ebMS is an open standard and as such is communication protocol neutral although the
most common underlying protocols are HTTP and SMTP. ebMS essentially offers a way to
exchange ebXML based B2B documents between different business applications using
SOAP/Web services.

1.6 FTP
File Transfer Protocol is a standard network protocol used to exchange and manipulate
files over a TCP/IP based network such as the internet. FTP is built on a client-server
architecture and utilises separate control and data connections between the client and
server applications. FTP is also often used as an application component to automatically

transfer files for internal functions within programs. FTP can be used with user-based
password authentication or with anonymous user access.

1.7 FTPS
File Transfer Secure Protocol is an extension of FTP which adds support for the
Transport Layer Security (TLS) and the Secure Sockets Layer (SSL) cryptographic
protocols. FTPS should not be confused with SFTP, an incompatible secure file transfer
subsystem for the Secure Shell (SSH) protocol. It is also different from Secure FTP, the
practice of tunneling FTP through an SSH connection

1.8 HTTP
HyperText Transfer Protocol is used to request and transmit files, especially web pages
and web page components, over the internet or other computer networks. In HTTP, web
browsers typically act as clients, while an application running on the computer hosting the
web site acts as a server. HTTP is typically implemented across TCP/IP however it can be
implemented on top of any other protocol on the internet, or on other networks.

1.9 HTTPS
HyperText Transfer Protocol Secure is a combination of the Hypertext Transfer Protocol
with the SSL/TLS protocol to provide encryption and secure identification of the server.
HTTPS connections are often used for payment type transactions across the internet and
for the exchange of sensitive information between corporate business systems.

1.10 OFTP
Odette File Transfer Protocol was developed to offer a standard communication
platform for the European automotive industry and has been in use since the mid-1980s.
OFTP has also seen adoption across the retail, white goods, manufacturing, government,
transport, insurance and banking industries to name but a few. The OFTP protocol is very
simple to use, consisting of only fourteen commands. The protocol is extremely efficient,
allowing large transmission windows to be utilised whilst incorporating file restart, data
compression and security. OFTP has been designed to allow companies to communicate
easily via point to point connections.

1.11 OFTP 2.0

Odette File Transfer Protocol version 2.0 is the latest version of the OFTP standard
and has been designed from the outset to be used across the internet. OFTP2 offers a

number of benefits over OFTP including data compression, exchange of digital certificates
(to improve security of transmissions) between trading partners, it allows the handling of
very large files (over 500Gb) and offers support for additional character sets such as
Chinese and Japanese. To date, OFTP has mainly been used in Europe however as
OFTP2 has been designed to operate across the internet it can help trading partners
connect to one another all over the world. Many automotive manufacturers in Europe have
been running OFTP2 pilot projects since 2008 and it is expected to be widely deployed
across production projects during 2010.

1.12 SFTP
Secure File Transfer Protocol is a network protocol that provides file access, file transfer
and file management functionality over any reliable data stream. It was designed as an
extension to the Secure Shell protocol (SSH) version 2.0 to provide secure file transfer
capability, but it is also intended to be usable with other protocols as well. SFTP can be
used in a number of different applications such as secure transfer over Transport Layer
Security (TLS) and transfer of management information within VPN applications. This
protocol assumes that it is run over a secure channel, such as SSH, that the server has
already authenticated the client and that the identity of the client user is available to the
protocol.