E D I

Why implement EDI?

Improves data accuracy: You can eliminate the need to re-enter data from paper documents and thus prevent potential data
entry errors. It is estimated to be one-tenth the cost of handling its paper equivalent.
Reduces technical complexity: With EDI, companies use standardized data formats to echange documents. EDI allo!s
companies using different systems to achieve computer-to-computer electronic echange of business documents.
Lowers personnel needs: EDI can help companies reduce the need for personnel involved in paper business transaction
processing.
Accelerates information exchange: "he lead time bet!een start and completion of order processing is greatly reduced. #y
timeous scheduling companies can plan production more accurately and thus reduce stoc$ inventories.
istory
EDI technologies have evolved as a data carrier replacing the paper document. It is not a new concept or a new practice.
EDI has existed for more than 2 decades in Europe and North America.
Early electronic interchanges used proprietary formats agreed upon between two trading partners requiring new programs
each time a new partner was added to the existing system. ateron some industry groups began a cooperative effort to
develop industry EDI standards for purchasing! transportation! and financial applications. "any of these standards
supported only intra#industry trading! which led to a large number of EDI formats.
In $%&%! the Accredited 'tandards (ommittee )A'(* +$2 was formed to develop a generic EDI standard. In $%%,! -ersion
,! .elease / contained $%2 standards. 0here are over $11 additional standards in development. In the 2.'.! the most
commonly used standard is AN'I +$2! coordinated by the American National 'tandards Institute )AN'I*. 3hile in Europe!
it is the Electronic Data Interchange for Administration! (ommerce! and 0ransportation )EDI4A(0* standard. 'A5 maps it
message types by EDI4A(0 naming conventions.
An EDI implementation methodology
There are basically 5 phases of the project that need to be completed sequentially:
!hase ": #he Assessment and !ro$ect strategy phase
Look at the business needs, map these to EDI, determine gap and implications, prototype if necessary, agree and
sign-off scope
!hase %: #he Design phase
Naming standards, interface design, future flexibility, audit requirements and technical impact, DR and archi!ing
strategies
!hase &: #he 'onfiguration phase
"onfirm business requirements, basis config, functional config, mapping, #$ and testing and sign-off
!hase (: #he Development phase
%hen non-standard &$ functions need to be implemented' (unctional specifications, technical specifications,
de!elop and configure, #$ and testing and sign-off'
!hase ): #he *perations phase
Define support roles, capacity planning, )ob monitoring, failure reco!ery and problem resolution
Install EDI mapping tool
"he selected EDI mapping tool has to be installed and tested for technical correctness.
Environment control
"he selected EDI mapping tool should be set up to allo! users to log onto and use the system. "his steps also includes the
configuration that has to be done on the EDI mapping tool for each trading partner. "his step !ill be repeated !hen ne! trading
partners are added.
EDI mapping
"his step is dependent on the actual EDI mapping tool selected, but certain concepts has to be considered and follo!ed nevertheless.
%apping defines the relationship bet!een an application data set and a target EDI standard, and vice versa. %apping is usually
divided into t!o phases& application definition and transaction mapping. In application definition, you determine !hat your
application data set loo$s li$e. In transaction mapping, you tell the mapping tool ho! to map the data from application to EDI
standards 'and vice versa(. "ransaction mapping defines the relationship bet!een data fields in your application and EDI data
elements.
)eneric templates or mapping tool specific templates should be used for this tas$.
'ommunication
*ommunication involves the actual sending and receiving of data to and from your trading partners. "he !ay communication !or$s is
dependent on the EDI mapping tool and the communication technicalities selected.
!repare +cheduling
"he scheduling requirements for EDI communication and processing as defined during the planning+design phase of the
implementation should be implemented. "he tools selected and the functionality they provide !ill determine the implementation
details. "his includes things li$e scheduling communications sessions and mapping ,obs.
Documents
EDI configuration guide - Details the steps to set up the stoc$ transfer scenario in -./. '01DE1-, 01D*2), I340I*,
01D1-/(
Detailed configuration guide
/artner configuration - 2o! to configure certain partner scenarios
0utput determination - -hort document briefly describing a fe! options for output determination configuration
,#o do EDI IDoc development your scenario designer will need in-depth .nowledge of IDoc scenario development and EDI
configuration/ A handy .nowledge of A0A! is also re1uired///,
I3*56DE/I*"61E 7d 8http&++!!!.sapgenie.com+sapgenie+images+processdev.gif8

9. Functional specifications need to be dra!n up, by the business, describing eactly !hat is required by them, that is not
available in the standard EDI scenarios.
:. A technical specification can then be dra!n up by the EDI team. In this technical specifications the follo!ing needs to be
addressed&
3e! IDocs, segments, message types, process codes required;
3e! fields added to eisting IDocs;
/rogram 7 user eits 7 message control for populating the fields;
Inbound functional module details;
EDI configuration set up requirements; and
Error handling.
0nce the specification is completed and confirmed by the business, programming can begin.
<. Developing an EDI scenario ill include the folloing steps:
OUTBOUND:
*reate -egments and IDoc type;
*reate %essage "ype and lin$ to IDoc type;
/opulate IDoc using message control 7 user eit or program '.#./(;
Distribute IDoc using %.-"E1=ID0*=DI-"1I#6"E;
*reate ob,ect type if required;
)enerate outbound partner profiles;
I20*32D:
Write inbound function module '>%( to process inbound IDoc '.#./(;
*reate process code and lin$ to >%;
)enerate inbound partner profiles; and
5in$ ob,ect type to >% for error handling.
?. !A " Testing - Including unit and string testing. Ensure a quality solution. @. done by the EDI team leader and testing done
by the business o!ner and EDI scenario developer.
A. #ign$off by the business - Ensure the development is thoroughly tested and comprehensively documented prior to sign-off
against the functional specification.
This guide is intended for those responsible for the setting up and maintenance of the EDI interface hich allos the e%change of EDI
messages beteen the #A& system and the EDI #ubsystem' This document should be read in conjunction ith the (EDI #A& #etup
)uide*' The (EDI &artner #etup* guide should also be read if problems related to EDI Trading &artner +onfiguration are
encountered, and this role is not being performed separately'
"/"/ Roles using this !rocedure
3ame of 1ole
EDI -./ *onfigurer
"his role is not defined since it !ill not be performed as a routine eercise.
"/%/ Assumptions
4arious assumptions are made in this guide regarding the architecture, platforms and soft!are used in EDI interfacing. "hese include&
"he configuration of the EDI component of -./ is consistent across all platforms.
"he functionality of the version of -./ used is identical to the version used for system development and testing 'version
<.92(. "his document !ill have to be updated !henever upgrades are performed, after any required changes and testing are
completed.
"he EDI -ubsystem refers to the hard!are, "ranslation soft!are and communications to an eternal 4alue-added 3et!or$
'4.3(.
"he EDI "ranslation soft!are is assumed to be )E3"1.3 Director, and is referred to as B)E3"1.3C in this document.
"he EDI subsystem complies !ith the data echange interface defined bet!een the systems.
"he scheduling of the )E3"1.3 and the -./ EDI component is sufficiently fleible to ensure that one system has
completed file operations before another system attempts to use this file. "his is a consequence of using a limited
functionality subsystem !ith batch scheduling.
"he EDI process is monitored after every scheduled message transfer to ensure that system failures are dealt !ith promptly
and correctly.
%/ A2 *verview of +A!4EDI
%/"/ #he +A!4EDI !rocess
Electronic Data Interchange 'EDI( eliminates the need for paper-intensive procedures !hen interacting !ith suppliers or customers, as
!ell as avoiding physical distribution methods such as postal or courier delivery, duplicate capturing of information by operators and
the associated errors.
"he purpose of the -./+EDI interface is to allo! business transaction details 'such as purchase orders, and invoices( to be echanged
electronically !ith vendors. In order to ensure interaction !ith a range of vendors, -./ does not supply the EDI subsystem required to
distribute EDI documents to vendors. "herefore, a mechanism is required to allo! business documents 'such as purchase orders(
generated in -./ to be transferred to this eternal EDI subsystem !hich !ill deliver the documents to vendors. -imilarly, the EDI
subsystem !ill receive business documents from vendors, !hich !ill then be transferred to the -./ system before they can be
processed.
.nother factor !hich should be considered is that the format of the documents generated by -./ is different to the format required by
the EDI subsystem. "herefore the interface has to ensure that -./ documents 'in IDoc format( are converted to an EDI subsystem
format 'the EDI>.*" format( before delivery to vendors. "he opposite conversion occurs !hen EDI documents are received by the
-./ system.
-ince the EDI subsystem is located on a different host to the -./ system, it is necessary to use a remote access method in order to
transfer the EDI documents. "he method chosen, for ease of understanding and usage is the 3et!or$ >ile -ervice '3>-(. "his permits
both systems to access the same directory structure in order to echange information.
"he interaction bet!een the systems is controlled by using t!o schedulers running batch ,obs, one for the -./ transfers, and another
for EDI subsystem transfers. "his allo!s fleibility, since the frequency of EDI transfers bet!een the systems can be modified, and
each component can be isolated via loose coupling. In addition, the stages of processing are clearly separated for simplicity.
%/%/ #he EDI !rocess
.ll sections of this document !ill ma$e reference to the follo!ing stages of the process.
%/%/"/ Incoming EDI
EDI messages are received by EDI subsystem.
EDI messages are translated from EDI>.*" format to IDoc format.
'"his requires a )E3"1.3+Director script to invo$e a translation script(
EDI messages 'IDoc format( are stored in 3>- shared directory.
-./ scheduler starts a batch process to retrieve all ne! inbound EDI messages 'IDoc format( from 3>- shared directory.
.ll EDI messages in IDoc format are processed by -./ inbound processing.
%/%/%/ *utgoing EDI
-./ "ransaction '/urchase 0rder >orm etc. ( generates IDoc messages for EDI.
-./ scheduler starts a batch process to send all ne! outbound EDI messages 'IDoc format( to 3>- shared directory.
"he EDI messages are stored in 3>- shared directory.
)E3"1.3 scheduler starts a DI1E*"01 script to retrieve all ne! EDI messages and convert them to EDI>.*" format.
EDI messages 'no! in EDI>.*" format( are delivered to vendors over value-added net!or$.
&/ *5ER5IEW *6 '*26I73RA#I*2
!R*'ED3RE
"he follo!ing sections describe the ma,or steps involved in configuring -./ for EDI, and ensuring that an interface to the EDI
subsystem has been put in place. "hese steps are outlined in the follo!ing diagram '!ith corresponding section alongside(. "hese
steps put core EDI functionality in place. "rading partner profiles still need to be set up on each production system for each vendor
that !ill be involved in trading via EDI.
-et up
3>- server
Define Data Echange Interface
-chedule EDI #atch "ransactions
*onfigure -./ for EDI
A
D
E
(/ +etting up the 2etwor. 6ile +ervice 826+9
Each )roup system should have a common directory called +home+edi+ !hich has been set up by the #asis administrators for this
)roup system. .ll inbound and outbound files to be echanged !ith the EDI subsystem should reside in a subdirectory corresponding
to the -./ system and client !hich they are associated. "he subdirectory structure should be accessible by an 3>- client using the
correct user id and pass!ord.
>or further information, read the 3>- -etup )uide.
)/ Data exchange interface
"he data echange interface !ill consist of a single file, used for each direction of echange 'inbound and outbound(. "he outbound
file is over!ritten by the -./ system !hen another file is created, and the inbound file !ill be deleted once -./ has successfully
processed it. "his means that the correct operation bet!een -./ and the subsystem !ill need to be verified after each echange. "his
administration responsibility is further discussed in the EDI .dministration operations documents.
Echange directory name& +home+edi+FportnameG
!here FportnameG consists of&
ediFsystem nameGFclient numberGFid charG
Fsystem nameG is the name of system on !hich port eists eg. >H9, /)9 etc.;
Fclient numberG is name of client on system !hich !ill use this port; and
Fid charG is a single alphabetical character such as IaJ,JbJ etc. typically, IaJ !ill denote dynamic outbound file naming 'used for
testing( !hereas IbJ !ill denote static outbound file naming. .ll ports !ill use static inbound filenames.
>or eample, the echange directory for a port using dynamic file naming on system >H9, client D9H !ould be named edifH9D9Ha.
0utbound Idoc %essage >ile '-tatic(& edi=out
Inbound IDoc %essage >ile '-tatic(& edi=in
:/ '*26I73RI27 +A! 6*R EDI
Each -./ client needs to be configured for EDI. /lease read and follo! the procedures outlined in the EDI -./ -etup )uide.
/ort definitions 'WE:9( need to be created for each client enabled for EDI using the follo!ing naming convention&
F/ortnameG !hich consists of&
EDIFsystem nameGFclient numberGFid charG
Fsystem nameG is the name of system on !hich port eists eg. >H9, /)9 etc.;
Fclient numberG is name of client on system !hich !ill use this port; and
Fid charG is a single alphabetical character such as IaJ,JbJ etc. typically,
IaJ !ill denote dynamic outbound file naming 'used for testing( !hereas
IbJ !ill denote static outbound file naming. .ll ports !ill use static
inbound filenames.
>or eample, the port name using dynamic file naming on system >H9, client D9H !ould be named EDI>H9D9H.. -imilarly, the port
name using static outbound file naming on system /)9, client DHH !ould be EDI/)9DHH#.
"he inbound file names 'including path( should be +home+edi+FportnameG+edi=in 'note lo!er case(. "he outbound function
used for dynamic EDI file naming should be EDI=/."2=*1E."E=6-E13.%E=D"="% and should include path
+home+edi+FportnameG. "he static outbound filename should be +home+edi+FportnameG+edi=out. 3ote that the FportnameG
used as a directory is lo!er case, compared to the -./ FportnameG !hich is in upper-case.
3ote that for each portname, there should be a corresponding subdirectory in +home+edi+ !ith the same name 'in lo!er case( !hich has
been created by the #asis administrator responsible for EDI 3>- setup.
/artner /rofiles for each trading partner should be setup on -./ by the person responsible for this role. "he procedures are
documented in the EDI /artner -etup )uide.
;/ +cheduling EDI #ransactions
;/"/ 'onfiguring and *perating the +A! scheduler
In order for the EDI transactions to be captured by the -./ system, inbound and outbound processes are run on a regular schedule to
transfer EDI messages to and from the -./ system respectively. "he mechanism for eecuting these processes is the -./ scheduler,
formally $no!n as the Bbac$ground processing serverC. "he frequency of the scheduled ,obs is entirely dependent on the volume of
transactions required to be transferred and the scheduling requirements for the EDI subsystem. "he ,obs to be scheduled are programs
1-E06"HH for outbound processing '!ith a variant defining the correct EDI port and document type( , and 1-EI3#HH for inbound
processing '!ith a variant describing the correct EDI path and input file i.e. +home+edi+edi=in(.
;/"/"/ *ut<ound =o<s
3aming convention for outbound ,obs is&
K=EDI=06"=F*lient 3umberG=FLob 3umberG
!here&
F*lient 3umberG is the number of the client on !hich the ,ob is created and should be eecuted.
FLob 3umberG is a < digit sequential number !hich is one higher than the previous ,ob that !as created eg. HH9, HH: etc.
Lob *lass& .
"imes for -./ outbound ,ob processing& HAhHH, 9:hHH.
"ime for )E3"1.3 inbound processing& 9 hour after -./ outbound
3ame of .#./ /rogram& 1-E06"HH
. variant should be created in transaction WE9?. "he variant name for the outbound ,ob is &
K=EDI=06"=Fclient numberG,
!here
client number is the number of the client !here the ,ob is to be eecuted
"he variant should include& port name, logical message type 01DE1- and 01D*2), and output mode ? '*ollect Idocs(.
;/"/%/ In<ound =o<s
3aming convention for inbound ,obs is&
K=EDI=I3 =F*lient 3umberG=FLob 3umberG
!here&
F*lient 3umberG is the number of the client on !hich the ,ob is created and should be eecuted.
FLob 3umberG is a < digit sequential number !hich is one higher than the previous ,ob that !as created eg. HH9, HH: etc.
Lob *lass& .
"ime for inbound ,ob processing& 9EhHH.
3ame of .#./ program& 1-EI3#HH
. variant should be created in transaction -E<M, using program name 1-EI3#HH. "he variant name for the inbound ,ob is &
K=EDI=I3=Fclient numberG,
!here
client number is the number of the client !here the ,ob is to be eecuted
"he variant should include& path +home+edi+FportnameG+edi=in
!here FportnameG is used to define the directory name, !ith details of the naming convention described in section D,
B*03>I)61I3) -./ >01 EDIC.
;/"/&/ Defining =o<s
"o define a ,ob, use the interactive -./ transaction -%<D.
;/"/(/ Executing =o<s
"o ma$e a ,ob eecutable, it must first be released.
;/"/)/ 'hec.ing the status of $o<s
"o chec$ the status of a ,ob, use interactive -./ transaction -%<E.
;/"/:/ 5iewing the $o< log
If a ,ob has been aborted, you should vie! the ,ob log for the cause of the failure. "o vie! the ,ob log, use interactive -./ transaction
-%<E.
;/"/;/ Deleting $o<s
-ome time after a ,ob has been processed, it should be deleted to release system resources. "here are t!o options to delete a ,ob&
manually, ,ob by ,ob
automatically, using a reorganization program that deletes ,obs that older than a certain date.
;/%/ Active >onitoring
"his section is only applicable if more etensive IDoc monitoring is required.
"his is a special report !hich informs the agent in charge in critical situations 'e.g. if there are too many erroneous IDoc
transmissions(.
;/%/"/ Active >onitoring: ow It Wor.s
"o perform the analysis the N1-EID0*%N program must either be started or scheduled for a later start. "he selection phase requires
valid entries to be supplied for at least the follo!ing fields& recipient, recipient type, status group and critical number of IDocs. "here
are also some other parameters that can be used to further restrict the IDoc selection.
During the selection phase all IDocs are analyzed that meet the selection criteria. "he possible status values of the IDocs are allocated
to status groups. If the status value of the current IDoc is allocated to one of the status groups specified in the report parameters, this
IDoc is counted as NcriticalN. "he Nnumber of critical IDocsN counter is incremented if any of the status values allocated to the status
groups occurs. If the number of critical IDocs counted eceeds the specified limit, the situation is classified as a NproblemN and a
notification is sent to the specified recipient.
"he notification appears to the recipient as a tas$ in his integrated inbo. When the tas$ is eecuted, a mas$ !ith the IDoc statistics is
displayed sho!ing the values holding at the time the analysis !as performed. "he status groups selected for the analysis are
highlighted in the statistics display in color if the value in this status group is larger than zero. "he N1efreshN function allo!s the person
eecuting the tas$ to display the current status of the IDocs. "his rene!ed analysis is based on the same selection criteria already used
for the notification.
;/%/%/ Active >onitoring: 'onfiguration
"he follo!ing configurations must be made one time for Nactive monitoringN&
If required, it may be a good idea to set up an organizational unit specially for the notification.
Event coupling must be activated for the N"-<:HH9HMN standard tas$. "he tas$ must be maintained as a Ngeneral tas$N. "his can be done
using the automatic !or$flo! customizing or the tas$ maintenance in the processor assignment function. .n alternative in the tas$
maintenance is to specify an organizational unit in the processor assignment. 2o!ever, this is not recommended because of the
problem of the intersection of the t!o sets, since the result for the set of possible processors of the tas$ could be an empty set.
"he N1-EID0*%N program can either be started interactively or scheduled for periodic monitoring using batch scheduling !ith
different variants.
#atch scheduling is done using the NDefine ,obN function. "his allo!s continuous periodic monitoring of the IDoc processing to be
configured and automated. Lob scheduling can be found by follo!ing the menu path "ools -G .dministration -G Lobs -G Define ,ob.
;/%/&/ Active >onitoring: !arameters
"he recipient and recipient type fields specify !ho or !hat should be notified in the case that notification becomes necessary. "his can
be a !or$ center, a ,ob, a position, an organizational unit or a user. "he recipient must be maintained in the organizational model of the
/D-01). .nalysis is only possible if a valid value has been entered here.
When the batch run is actually eecuted, the specified start time before batch run and end time before batch run are used to calculate
the time interval to be used for selecting the IDocs based on their creation time.
"he number of critical IDocs defines the threshold 'a Nstrictly greater thanN condition(, beyond !hich a notification should be
dispatched. "his parameter can also ta$e the value zero.
-tatus groups are used to group together possible status values of IDocs. "he allocation of a status value to a status group is $no!n as
a qualification. -./ supplies a standard qualification, but this may be changed. "he set of IDocs that has been determined for analysis
by a set of further selection criteria 'see belo!( is eamined to ascertain its current status. If this status is one that has been allocated to
one of status groups specified in the selection, the Nnumber of critical IDocsN counter is incremented.
-tatus group > 'inbo& error in application( is supplied as standard by -./ !ith the status values&
A9 'application document not posted(
A: 'application document not fully posted( and
AE 'error !hen chec$ing the application(.
>or each IDoc in the set of IDocs selected that has a current status of A9, A: or AE, the Nnumber of critical IDocsN counter is
incremented by one. If this counter reaches or eceeds the threshold specified 'in this case 9(, a notification is sent to the specified
recipient. "his !ould therefore be the case here if ,ust one IDoc currently has a status value of A9, A: or AE.
#y specifying the follo!ing parameters &
logical type, variant and function of the message,
senderNs port,
partner type, partner function and partner number of sender
recipientNs port,
partner type, partner function and partner number of recipient
the set of IDocs to be analysed can be restricted further.
"hus, the follo!ing parameters have to be set&
5ogical message N01DE1-N
*ustomer N:?HHHH?N
#atch run time HM&HH on the day of delivery
"o that end, the variant %Y=4.1 is created for the report 1-EID0*%&
9. In the abap+? editor, select 8variant8 for the report 1-EID0*% and push the 8Display8 button. In the net screen, create the variant
N%Y=4.1N.
:. In the follo!ing screen, select, in particular, 89 day8 and 8H days 9?&HH&HHh8 for start and end before batch run, respectively. "he
batch ,ob itself is started at HM&HHh. -tatus group > 'inbo& error in application( is supplied as standard by -./ !ith the status values
A9 'application document not posted(, A: 'application document not fully posted( and AE 'error !hen chec$ing the application(.
<. In the daily batch run all the IDocs are selected that arrived the previous day bet!een HH&HH and 9M&HH and that have the logical
message type N01DE1-N and !ere sent by the sender N?E99N. If the current status of at least t!o of these IDocs is allocated to the status
group >, a notification is sent to the user N%Y6-E1N, since the Nnumber of critical IDocsN threshold value is set to 9.
Documents
-./ EDI .dministrator role definition
EDI -ubsystem administrator role definition
+A! ?>L @ EDI
Advantages of including Electronic Data Interchange )EDI* entities with e+tensible "ar6up anguage
)+"*
0he advantages of including Electronic Data Interchange )EDI* entities with e+tensible "ar6up anguage )+"* differs for
each camp.
4or the EDI camp the unification means ma6ing application implementation easier! allowing for quic6er reach into
vertical mar6ets! reduced message stores when processing transactions! and most importantly enabling
document#centric tools such as search engines and Internet 7push7 products to supplement database
mechanisms.
8y assuring EDI compatibility! the +" camp gains almost instance use among thousands of companies. +" will
gain a common extensible data entity definition which has under gone the test of time.
0he bottom line9 the *+L camp gains (ortune ,--- support and the EDI camp gains a common presentation protocol'
If the combination can bring this much to the table why hasn:t it been done before now;
0he attempt to combine structured presentation with structured data for transactions is not new. 0he last attempt ended a
little over a year ago. At that time the researchers of the <oint Electronic Document Interchange )<EDI* pro=ect which were
managed through the Division of earning Development .esearch >roup at De "onfort 2niversity eicester! the
(omputer 'cience at 2niversity (ollege ondon! and the Document Interchange pro=ect at 2?E.NA completed their
study. 0he pro=ect:s intent was to analy@e the current international and industry de facto standards that are in use for
electronic document creation! transfer and presentation. 0he pro=ect was to identify the set of common elements that
would allow the conversion of both logical and layout aspects of a document. 0he documents would then be viewed using
a 333 type browser that was available for common computer platforms. 0he <EDI pro=ect concluded that '>" is
ideally suited for EDI as it is text based and is independent of platform and operating system. 0he actual results were a
little disappointing in that the world was and is still not ready for an '>"AD''' implementation.
3hat has changed! for us to try again;
It is a year later! and in the Internet timeframe this is plenty for momentum to shift. Due for release sometime this summer
is an important specification to 333 browser#based applications # the e+tensible "ar6up anguage )+"*. 0he intent is
to ma6e the rather rich B005 protocol even richer. It is a scaled down simpler version of '>"! in fact the one of the
goals of the specification is to 7...be straightforwardly usable over the Internet.7 0he 6ey here is 7straightforwardly usable.7
0his flavor in the design of +" which is why the specification will succeed for transactions where the '>"AD'''
failed. 0his is not to say that '>"AD''' wouldn:t wor6! but more a reflection on us accepting change. (hange
sometimes needs to be ta6en in a series of steps # *+L is the next step'
3hat about the momentum with +";
+"! managed by the 3orld 3ide 3eb (onsortium )3,(* wor6ing group! will no doubt become the next significant
enabling technology for the 3eb. +" will provide 3eb publishers and consumers with unprecedented power! flexibility
and control over the creation of and access to Internet and intranet content. 0o date the +" specification is bac6ed by
'oftCuad! Adobe! I8"! B5! "icrosoft! Netscape! oc6heed "artin! N('A! Novell! 'un! 8oston 2niversity! Dxford
2niversity! and the 2niversities of Illinois and 3aterloo. In addition to the authors of the specification! about ,1 companies
already support the (D4E (hannel Definition 4ormat! an +" application which brings to the Internet various 7push7
operations.
Netscape and "icrosoft and have already pledged *+L support in their future %%% bro.ser releases. And many
corporations are being added to the list as they learn of the specification:s existence and capability.
3hat could the EDI entities loo6 li6e;
0he general format of the transaction would be described in B0". 0he EDI segments and elements could go something
where attributes identify certain elements as holding EDI information. 0hat way! the EDI information is explicitly labelled!
and an +" processor can be as6ed to return it to an application using standard A5I calls.
0his approach means that the EDI information forms part of the logical structure of the +" document! rather than being a
(DA0A :implant:. It also means that users can define their own element types to hold EDI information! so long as they
label them with the agreed attributes.
4urthermore! it allows them to use +":s built#in validation facilities to chec6 for structurally valid input! e.g.9 in the D0D9
< !ELEMENT N1-GROUP (N101, N102?, N103, N104) >
< !ATTLIST N1-GROUP EDI-TYPE CDATA #I!ED "ANALYSED CONTACT">
< !ELEMENT N101 (#PCDATA) >
< !ATTLIST N101 EDI-TYPE CDATA #I!ED "#UAL PREI!">
$$$$$$$$
in the document9
$$$$$$$$$
< N1-GROUP>
< N101>R< %N101>< N103>1< %N103>< N104>1234&'< %N104>
< %N1-GROUP>
Note that the EDI#0F5E information is declared once and once only! in the D0D! and does not add to the mar6up
overhead in the actual document.
0he above items are =ust food for thought. Bopefully! when both camps view the above lines! they see only a slight
modification to the methods implemented today. 0o include the right hoo6s! (DA0A or other +" entities might have to
include some specific syntax for EDI. 0he details! though not many! can be ironed out by the excellent authors of both
camps.
'o then +" documents are really =ust EDI templates! .ight;
Fes and no. Fes the documents can be used as templates. 8ut in addition to this application! the +" document can also
be a transaction itself. +"AEDI would allow in a non#proprietary way! for structured presentation format to be included
now in the transaction. (ombined effort in template or application form creation and development is estimated in the
thousands of man-years, not hundreds. 'oon there will be a standard which to share the wor6 others have done!
applications need only to simply access 333 browser ob=ects. 0his ob=ect#based approach to applications will ma6e
document transaction exchange even easier. 8ottom line9 0he EDI camp could leverage +" to aid in lowering
implementation costs.
In addition to templates! and transactions! tools are available today to store! search! route! narrowcast and maintain
information in document#form. 8y adding defined data entities! these tools can be enhanced to ma6e EDI processing and
integration much easier. Database! EDI specific! and application programming tools were for the longest time the only
choices! the only options for EDI administrators. +"AEDI will give the EDI administrator more choices.
If presentation elements are included in the transaction what happens to our transmission bandwidth;
0he transaction would certainly require more bandwidth as compared to EDI specification today. 0he additional strain on a
corporation:s infrastructure must be weighed with those advantages gained by the use of +"AEDI on a case by case
basis. It is estimated that the +"AEDI#based transactions would add about ,GH to the si@e of the current transactions. In
the cases where this increase is significant! the +"AEDI standard documents can replace proprietary templates! which
would still allow for use of document#based tools internal to the organi@ation.
3here do we go from here;
Introduction of the two camps # +" and EDI
Education of both camps of the others existence! tools and implementation methods
Assure that the proper hoo6s are in +" to support EDI
(reate an EDI application for the Extensible "ar6up anguage )+"*
EDI 7mappers7 must add +" parsing to their front#end logic.
6 A A - EDI
What is EDI?
"he computer-to-computer electronic echange of machine-processable business documents in a standard format.
.n electronic alternative to paper, fa, and phone-based transactions used by companies to communicate !ith one
another.
What are EDI Drivers?
.bility to strengthen partnerships
Improve business processes
. communication tool to allo! ne! !ays to do business
. preferred !ay of doing business among >ortune AHH companies
. business basic for the industry
ow is EDI 3sed?
EDI is used as a strategic tool to reduce epenses, streamline business procedures, and create a competitive
advantage.
ow is EDI +tarted?
6sually 1eactive or /roactive.
REA'#I5E !R*A'#I5E
5ac$ of understanding
3o direction
5ac$ of regulated program
8Lury 1ig8 third-party solution
*learly defined business need
Defined *orporate direction
*ontrolled program
8-elected8 trading partners
Impartial 8third-party8 input
ow does EDI Wor.?
!urchase *rdering Example
9. "he buyer enters order information into the production database, !hich generates a purchase order on the computer.
"he order information is then channeled through a number of interface programs.
:. "he interface soft!are programs perform edits and chec$s on the document and direct the order data into predefined
EDI intermediate files.
<. "he EDI intermediate files contain information in a form that the EDI translation soft!are can read.
?. "he translation soft!are is a set of programs that translates the interface file data into a document formatted
according to EDI standards that the supplierNs computer can recognize.
A. "he electronic document no! consists of a file that contains the order data in a predefined, recognizable order.
D. "he communications soft!are adds appropriate communications protocols to the EDI document in preparation for
transmission via telephone lines.
E. 6sing a modem and telephone line, the buyer transmits the EDI purchase order to a 4.3 '4alue added net!or$(.
"hin$ of this as a mailbo.
M. "he communications soft!are on the supplierNs computer pic$s up the document from the 4.3, interprets and+or
converts the communications protocols to open the electronic document.
O. "he purchase order is no! in a standard, recognizable format in a file and is available to the supplierNs computer.
9H. "he supplierNs translation soft!are interprets the documents from the EDI format and places the order information in
EDI intermediate file's(.
99. "he EDI intermediate files contain the translated purchase order information.
9:. "he interface programs perform edits and chec$s before the data is integrated !ith the supplierNs production
database.
9<. "he application soft!are on the supplierNs computer can no! process the buyerNs order.
What is the most common EDI cycle?
*ustomer transmits EDI MAH 'purchase order(
-upplier transmits EDI OOE 'functional ac$no!ledgement(
-upplier transmits EDI MAD 'advance ship notice(
*ustomer transmits EDI OOE 'functional ac$no!ledgement(
-upplier transmits EDI M9H 'electronic invoice(
*ustomer transmits EDI OOE 'functional ac$no!ledgement(
*ustomer transmits E>" 'Electronic >unds "ransfer( /ayment
What are EDI 0enefits?
#uilds closer business partnerships
1educes+eliminates manual handling of data, errors and re!or$
"ransfers information faster and more accurately
.utomates routine transactions
Improves productivity and business controls
1educes costs
-hortens transaction processing cycles
Enhances data accuracy
5o!ers inventory levels
*ontributes to better in-stoc$ positions
5o!ers freight costs
/rovides @uic$ 1esponse capability
Improves cash-flo! management
*reates a competitive advantage
What are EDI 0enefits +ummary4Re1uirements?
0enefits Re1uires
0usiness !rocess
Examples
9. 0perational EDI transactions
0rdering - /urchase
0rder
/urchase 0rder
.c$no!ledgement
:. "actical
Internal /rocess
1e-engineering
>orecasting - based on
-I"
- .vailability
- Increased inventory
turns
<. -trategic
Internal and Eternal
/rocess 1e-engineering
@uic$ 1esponse -
%ar$et -hare
-upply *hain %gmt -
-ustained
/rofits
What is the Lin. <etween EDI and !rofits?
EDI the tool EDI the features EDI the <enefits
-hared forecasts Inventory turns increase *ut costsP
"ransaction automation 1educed labor *ut costsP
Integration !ith systems
>e!er errors, re!or$,
less paper
*ut costsP
Electronic payments #etter cash flo! *ut costsP
-hared sales and
inventory data
Improved availability Increase salesP
Integration and high
speed data transfer
.ccess to quality
information
Increase salesP
"ransaction automation /eople add value Increase salesP
Why move to EDI?
.llo! machines to process business transactions !hile people develop and enhance business relationships
-trengthen internal and eternal business relationships through 8information partnering8
/romote Electronic *ommerce through EDI and other information solutions
Improve the supply chain by ma$ing accurate information available quic$ly and inepensively
1educe operating costs by re-designing business processes and automating routine tas$s
We created an EDI 5endor and created all re1uired output conditions/ owever no ID*' is generated when !* is
printed/ Why?
)o to 2eader-Goutput for the /0. "he output type shall be NDN. "he status shall be N9N. If the status is NHN chec$ the timing. If the
status is N:N , go to N)0"0-G/rocessing 5ogN and the eplanation for non-generation of ID0* can be seen.
ow can we create 4 upload ID*'Bs from legacy system to +A!?
"hird party tools li$e %ercator and )entran may be used to convert 5egacy files to Idoc format. "hese tools provide an
ID0* tree import facility, -./ provides the eport facility. You can transfer the Idoc layouts from -./ to these tools
automatically and then map.
We want to receive an out<ound EDI C)) ID*' only if E%ED!%D -scheduling confirmation segment is present/ Else
get an ,error, status preventing triggering the EDI su<system/
6ser eit logic has to be added in function ID0*=I3/6"=01D1-/.
Q -et up a test flag and set it off !hen the ID0* header is read.
Q "urn the flag 03 !hen the ED/:H segment is read.
Q Interrogate this flag !hen the net segment after ED/:H in the same ID0* comes in. If it is on ,you have an ED/:H
coming in.
Q Issue an error status A9 !ith suitable message for !hichever condition you donNt !ant the ID0* to be processed, "his !ill
stop the ID0* from posting.
Where ever !* is sent to the vendor via EDIE we want an ac.nowledgement of the !* <y vendor/ Which fields are
updated and what should <e my procedure?
Eecute /rogram& ID0*=I3/6"=01D1-/
/rocess code& 01D1
%essage type& 01D1-/
ID0*& 01DE1-H9
"he confirmation process allo!s the supplier to return an ac$no!ledgment. 0nly Dates and quantities can be changed "he
information is stored in the /0 and can be vie!ed via Item-G*onfirmation-G0vervie!. "he /0 can be flagged as
Nconfirmation requiredN so that /os !ithout ac$no!ledgement receipt can be monitored. *ontrol $eys and tolerances 'days
and quantities( have to be customized.