A Day in the Life of EDI

at

What is EDI?

Electronic Data Interchange (EDI) is direct

computer-to-computer (requiring NO manual

or human intervention) transfer of business

information.

It was created to be used as an expedient

method for communicating and processing

data electronically.

Benefits of using EDI

By implementing EDI as part of your

business strategy, your company will benefit

in the following ways:

• Facilitate ‘Just in Time’ processes

• Speeds communication and data exchange with

ALL tiers

• Increased revenue by expanding your

geographical market

• Preserve existing revenue by forming stronger

relationships with existing suppliers and

customers

Benefits of using EDI (cont.)

Reduces costs by reducing or eliminating

paper-based documents, storage costs, and

retrieval costs.

Reduces paper consumption

Eliminates data entry errors

Expedites transfer of business information

EDI Conventions

The two most commonly used formats to

transfer EDI documents today are:

• ANSI X12, which is used mainly in North

America

• UN/edifact, which is used worldwide

NOTE: There are older standards still in use

by other companies

EDI Conventions (cont.)

There is one emerging format to transfer EDI

documents:

• XML

NOTE:

• XML standards are plentiful

• Until one standard is accepted and adopted,

there will be many versions of XML to support

• Ford Motor Company has settled on OAG

(Open Applications Group)

• The auto industry as a whole has yet to agree

on one standard

EDI @ Ford

Ford utilizes EDI to transfer many

documents or messages to and from trading

partners in standard formats on a daily basis

These messages include, but not limited to:

• Planning Schedules (830/DELFOR)

• Shipping Schedules (862/DELJIT)

• Advance Ship Notices (856/DESADV)

• Purchase Orders (850/ORDERS)

• Functional Acknowledgements (997/CNTL)

EDI Systems

Data is

sent/received

By Ford

applications.

(CMMS,

CPARS,

MSIII,

eVEREST,

CMMSIII,

Health Care,

etc.)

Data is

received

by supplier.

Supplier then

Acknowledges

Receipt.

Data received

by the

GEC Hub

Data received

by SOLMIS

Data Warehouse

Ford Internal resources

Access data, metrics, etc.

Via website

External sites with

FSN id and password

Access data, metrics, etc.

Outbound Data Processing @ Ford

1. All Ford internal data is compiled in a Ford

proprietary format called CIF (Common

Internal Format)

2. All CIF from an application, outbound to a

trading partner (supplier, carrier, LLP,

customer, etc.) is translated to one of the

industry standard formats (X12 or

UN/edifact)

3. The trading partners system (ERP, etc.)

retrieves the data and then integrates it into

their system for processing

CMMS,

ACSG,

CPARS,

ETC.

GEC Hub

or

SOLMIS

Trading

Partner

Inbound Data Processing @ Ford

1. The trading partners system (ERP, etc.)

processes their response to our data, and

sends it to our EDI system in one of the

industry standard formats

2. All data from the trading partners is received

by the EDI system at FMC and translated

from the industry format into the Ford CIF

format

3. Data from the trading partner, now in CIF

format, is passed to the appropriate Ford

internal application in CIF format

CMMS,

ACSG,

CPARS,

ETC.

GEC Hub

or

SOLMIS

Trading

Partner

Complexities of EDI @ Ford

Specific to the CIF:

• All internal applications (CMMS, MSIII, ACSG,

etc.) use the same CIF format for a given

message (i.e. 830, 862, etc.)

• Any change to the CIF could impact the other

applications and their ability to send/receive the

CIF

• All changes to the CIF need to be

communicated and coordinated across the

enterprise of Ford Motor Company

Complexities of EDI @ Ford (cont.)

Specific to the translator:

• Any change to the CIF where the application is

expecting the trading partner to receive and

process new or additional data requires a

change to the translation code (which changes

the CIF to X12, or the X12 to CIF)

• Any change to the message where the

application and trading partner expect to share

the information requires a change to the

translation code

Complexities of EDI @ Ford (cont.)

Specific to the translator:

• Any change to the translation code requires

communication to ALL other application teams

• All other application teams must be allowed to

test in order to assure they are not adversely

impacted. (At least one other application in FMC

is using the same translation code)

• NOTE: The GSEC team has coordinated

translation and specification changes, along with

the communications regarding those changes to

the other applications via the EDI coordinators

meetings

Complexities of EDI @ Ford (cont.)

Specific to the trading partners:

• Changes to the formal “EDI Specification”

documents that Ford publishes for it’s trading

partners benefit are required with any change to

the translation code! (inbound to Ford or

outbound from Ford)

Complexities of EDI @ Ford (cont.)

Specific to the trading partners:

• These changes need to be communicated to all

trading partners:

• Trading partners need to be given time to react:

Making changes in their internal code

Contracting with their software vendor to make the

necessary changes

Contracting with an outside consultant to make the

necessary changes

• NOTE: The GSEC team coordinates

specification changes and communications

regarding those changes to the trading partners

Complexities of EDI @ Ford (cont.)

Specific to the trading partners:

• Trading partners and application teams need to

perform end-to-end testing

• Which involves:

Data validation must occur at both points of the

message flow (sender and receiver)

Assuring the recipient is able to process (i.e.

translate and integrate the new or additional data to

the ERP system)

Validating the sender is able to generate and

transmit the data correctly