https://www.homeworkping.com/,homework help,online homework help,online tutors,online tutoring,research paper help,do my homework,

1. Get Homework/Assignment Done
Homeworkping.com
Homework Help
https://www.homeworkping.com/
Research Paper help
https://www.homeworkping.com/
Online Tutoring
https://www.homeworkping.com/
click here for freelancing tutoring sites
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 exchange documents. EDI allows
companies using different systems to achieve computer-to-computer electronic exchange of business documents.
• Lowers personnel needs: EDI can help companies reduce the need for personnel involved in paper business transaction
processing.
• Accelerates information exchange: The lead time between start and completion of order processing is greatly reduced. By
timeous scheduling companies can plan production more accurately and thus reduce stock inventories.
History
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. Lateron some industry groups began a cooperative effort to
develop industry EDI standards for purchasing, transportation, and financial applications. Many of these standards
supported only intra-industry trading, which led to a large number of EDI formats.
In 1979, the Accredited Standards Committee (ASC) X12 was formed to develop a generic EDI standard. In 1993, Version
3, Release 4 contained 192 standards. There are over 100 additional standards in development. In the U.S., the most
commonly used standard is ANSI X12, coordinated by the American National Standards Institute (ANSI). While in Europe,
it is the Electronic Data Interchange for Administration, Commerce, and Transportation (EDIFACT) standard. SAP maps it
message types by EDIFACT naming conventions.

2. An EDI implementation methodology
There are basically 5 phases of the project that need to be completed sequentially:
Phase 1: The Assessment and Project strategy phase
Look at the business needs, map these to EDI, determine gap and implications, prototype if necessary, agree and
sign-off scope
Phase 2: The Design phase
Naming standards, interface design, future flexibility, audit requirements and technical impact, DRP and archiving
strategies
Phase 3: The Configuration phase
Confirm business requirements, basis config, functional config, mapping, QA and testing and sign-off
Phase 4: The Development phase
When non-standard SAP functions need to be implemented. Functional specifications, technical specifications,
develop and configure, QA and testing and sign-off.
Phase 5: The Operations phase
Define support roles, capacity planning, job monitoring, failure recovery and problem resolution
Install EDI mapping tool
The selected EDI mapping tool has to be installed and tested for technical correctness.
Environment control
The selected EDI mapping tool should be set up to allow users to log onto and use the system. This steps also includes the
configuration that has to be done on the EDI mapping tool for each trading partner. This step will be repeated when new trading
partners are added.
EDI mapping
This step is dependent on the actual EDI mapping tool selected, but certain concepts has to be considered and followed nevertheless.
Mapping defines the relationship between an application data set and a target EDI standard, and vice versa. Mapping is usually
divided into two phases: application definition and transaction mapping. In application definition, you determine what your
application data set looks like. In transaction mapping, you tell the mapping tool how to map the data from application to EDI
standards (and vice versa). Transaction mapping defines the relationship between data fields in your application and EDI data
elements.
Generic templates or mapping tool specific templates should be used for this task.
Communication
Communication involves the actual sending and receiving of data to and from your trading partners. The way communication works is
dependent on the EDI mapping tool and the communication technicalities selected.

3. Prepare Scheduling
The scheduling requirements for EDI communication and processing as defined during the planning/design phase of the
implementation should be implemented. The tools selected and the functionality they provide will determine the implementation
details. This includes things like scheduling communications sessions and mapping jobs.
Documents
• EDI configuration guide - Details the steps to set up the stock transfer scenario in SAP. (ORDERS, ORDCHG, INVOIC,
ORDRSP)
• Detailed configuration guide
• Partner configuration - How to configure certain partner scenarios
• Output determination - Short document briefly describing a few options for output determination configuration
"To do EDI IDoc development your scenario designer will need in-depth knowledge of IDoc scenario development and EDI
configuration. A handy knowledge of ABAP is also required..."
INCLUDEPICTURE d "http://www.sapgenie.com/sapgenie/images/processdev.gif"
1. Functional specifications need to be drawn up, by the business, describing exactly what is required by them, that is not
available in the standard EDI scenarios.
2. A technical specification can then be drawn up by the EDI team. In this technical specifications the following needs to be
addressed:
• New IDocs, segments, message types, process codes required;
• New fields added to existing IDocs;
• Program user exits message control for populating the fields;
• Inbound functional module details;
• EDI configuration set up requirements; and
• Error handling.
Once the specification is completed and confirmed by the business, programming can begin.
3. Developing an EDI scenario will include the following steps:
OUTBOUND:
• Create Segments and IDoc type;
• Create Message Type and link to IDoc type;
• Populate IDoc using message control user exit or program (ABAP);
• Distribute IDoc using MASTER_IDOC_DISTRIBUTE;

4. • Create object type if required;
• Generate outbound partner profiles;
INBOUND:
• Write inbound function module (FM) to process inbound IDoc (ABAP);
• Create process code and link to FM;
• Generate inbound partner profiles; and
• Link object type to FM for error handling.
4. QA & Testing - Including unit and string testing. Ensure a quality solution. QA done by the EDI team leader and testing done
by the business owner and EDI scenario developer.
5. Sign-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 which allows the exchange of EDI
messages between the SAP system and the EDI Subsystem. This document should be read in conjunction with the “EDI SAP Setup
Guide”. The “EDI Partner Setup” guide should also be read if problems related to EDI Trading Partner Configuration are
encountered, and this role is not being performed separately.
1.1. Roles using this Procedure
Name of Role
EDI SAP Configurer
This role is not defined since it will not be performed as a routine exercise.
1.2. Assumptions
Various assumptions are made in this guide regarding the architecture, platforms and software used in EDI interfacing. These include:
• The configuration of the EDI component of SAP is consistent across all platforms.
• The functionality of the version of SAP used is identical to the version used for system development and testing (version
3.1H). This document will have to be updated whenever upgrades are performed, after any required changes and testing are
completed.
• The EDI Subsystem refers to the hardware, Translation software and communications to an external Value-added Network
(VAN).
• The EDI Translation software is assumed to be GENTRAN Director, and is referred to as “GENTRAN” in this document.
• The EDI subsystem complies with the data exchange interface defined between the systems.
• The scheduling of the GENTRAN and the SAP EDI component is sufficiently flexible to ensure that one system has
completed file operations before another system attempts to use this file. This is a consequence of using a limited
functionality subsystem with batch scheduling.
• The EDI process is monitored after every scheduled message transfer to ensure that system failures are dealt with promptly
and correctly.

5. 2. AN Overview of SAP/EDI
2.1. The SAP/EDI Process
Electronic Data Interchange (EDI) eliminates the need for paper-intensive procedures when interacting with suppliers or customers, as
well as avoiding physical distribution methods such as postal or courier delivery, duplicate capturing of information by operators and
the associated errors.
The purpose of the SAP/EDI interface is to allow business transaction details (such as purchase orders, and invoices) to be exchanged
electronically with vendors. In order to ensure interaction with a range of vendors, SAP does not supply the EDI subsystem required to
distribute EDI documents to vendors. Therefore, a mechanism is required to allow business documents (such as purchase orders)
generated in SAP to be transferred to this external EDI subsystem which will deliver the documents to vendors. Similarly, the EDI
subsystem will receive business documents from vendors, which will then be transferred to the SAP system before they can be
processed.
Another factor which should be considered is that the format of the documents generated by SAP is different to the format required by
the EDI subsystem. Therefore the interface has to ensure that SAP documents (in IDoc format) are converted to an EDI subsystem

6. format (the EDIFACT format) before delivery to vendors. The opposite conversion occurs when EDI documents are received by the
SAP system.
Since the EDI subsystem is located on a different host to the SAP system, it is necessary to use a remote access method in order to
transfer the EDI documents. The method chosen, for ease of understanding and usage is the Network File Service (NFS). This permits
both systems to access the same directory structure in order to exchange information.
The interaction between the systems is controlled by using two schedulers running batch jobs, one for the SAP transfers, and another
for EDI subsystem transfers. This allows flexibility, since the frequency of EDI transfers between 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.
2.2. The EDI Process
All sections of this document will make reference to the following stages of the process.
2.2.1. Incoming EDI
• EDI messages are received by EDI subsystem.
• EDI messages are translated from EDIFACT format to IDoc format.
• (This requires a GENTRAN/Director script to invoke a translation script)
• EDI messages (IDoc format) are stored in NFS shared directory.
• SAP scheduler starts a batch process to retrieve all new inbound EDI messages (IDoc format) from NFS shared directory.
• All EDI messages in IDoc format are processed by SAP inbound processing.
2.2.2. Outgoing EDI
• SAP Transaction (Purchase Order Form etc. ) generates IDoc messages for EDI.
• SAP scheduler starts a batch process to send all new outbound EDI messages (IDoc format) to NFS shared directory.
• The EDI messages are stored in NFS shared directory.
• GENTRAN scheduler starts a DIRECTOR script to retrieve all new EDI messages and convert them to EDIFACT format.
• EDI messages (now in EDIFACT format) are delivered to vendors over value-added network.
3. OVERVIEW OF CONFIGURATION
PROCEDURE
The following sections describe the major steps involved in configuring SAP for EDI, and ensuring that an interface to the EDI
subsystem has been put in place. These steps are outlined in the following diagram (with corresponding section alongside). These
steps put core EDI functionality in place. Trading partner profiles still need to be set up on each production system for each vendor
that will be involved in trading via EDI.
Set up
NFS server
Define Data Exchange Interface
Schedule EDI Batch Transactions
Configure SAP for EDI
5
6
7

7. 4. Setting up the Network File Service (NFS)
Each Group system should have a common directory called /home/edi/ which has been set up by the Basis administrators for this
Group system. All inbound and outbound files to be exchanged with the EDI subsystem should reside in a subdirectory corresponding
to the SAP system and client which they are associated. The subdirectory structure should be accessible by an NFS client using the
correct user id and password.
For further information, read the NFS Setup Guide.
5. Data exchange interface
The data exchange interface will consist of a single file, used for each direction of exchange (inbound and outbound). The outbound
file is overwritten by the SAP system when another file is created, and the inbound file will be deleted once SAP has successfully
processed it. This means that the correct operation between SAP and the subsystem will need to be verified after each exchange. This
administration responsibility is further discussed in the EDI Administration operations documents.
• Exchange directory name: /home/edi/<portname>
where <portname> consists of:
edi<system name><client number><id char>
<system name> is the name of system on which port exists eg. F01, PG1 etc.;
<client number> is name of client on system which will use this port; and
<id char> is a single alphabetical character such as ‘a’,’b’ etc. typically, ‘a’ will denote dynamic outbound file naming (used for
testing) whereas ‘b’ will denote static outbound file naming. All ports will use static inbound filenames.
For example, the exchange directory for a port using dynamic file naming on system F01, client 610 would be named edif01610a.
• Outbound Idoc Message File (Static): edi_out
• Inbound IDoc Message File (Static): edi_in

8. 6. CONFIGURING SAP FOR EDI
Each SAP client needs to be configured for EDI. Please read and follow the procedures outlined in the EDI SAP Setup Guide.
Port definitions (WE21) need to be created for each client enabled for EDI using the following naming convention:
• <Portname> which consists of:
EDI<system name><client number><id char>
<system name> is the name of system on which port exists eg. F01, PG1 etc.;
<client number> is name of client on system which will use this port; and
<id char> is a single alphabetical character such as ‘a’,’b’ etc. typically,
‘a’ will denote dynamic outbound file naming (used for testing) whereas
‘b’ will denote static outbound file naming. All ports will use static
inbound filenames.
For example, the port name using dynamic file naming on system F01, client 610 would be named EDIF01610A. Similarly, the port
name using static outbound file naming on system PG1, client 600 would be EDIPG1600B.
• The inbound file names (including path) should be /home/edi/<portname>/edi_in (note lower case). The outbound function
used for dynamic EDI file naming should be EDI_PATH_CREATE_USERNAME_DT_TM and should include path
/home/edi/<portname>. The static outbound filename should be /home/edi/<portname>/edi_out. Note that the <portname>
used as a directory is lower case, compared to the SAP <portname> which is in upper-case.
Note that for each portname, there should be a corresponding subdirectory in /home/edi/ with the same name (in lower case) which has
been created by the Basis administrator responsible for EDI NFS setup.
Partner Profiles for each trading partner should be setup on SAP by the person responsible for this role. The procedures are
documented in the EDI Partner Setup Guide.
7. Scheduling EDI Transactions
7.1. Configuring and Operating the SAP scheduler
In order for the EDI transactions to be captured by the SAP system, inbound and outbound processes are run on a regular schedule to
transfer EDI messages to and from the SAP system respectively. The mechanism for executing these processes is the SAP scheduler,
formally known as the “background processing server”. The frequency of the scheduled jobs is entirely dependent on the volume of
transactions required to be transferred and the scheduling requirements for the EDI subsystem. The jobs to be scheduled are programs
RSEOUT00 for outbound processing (with a variant defining the correct EDI port and document type) , and RSEINB00 for inbound
processing (with a variant describing the correct EDI path and input file i.e. /home/edi/edi_in).
7.1.1. Outbound Jobs
Naming convention for outbound jobs is:
Z_EDI_OUT_<Client Number>_<Job Number>
where:
• <Client Number> is the number of the client on which the job is created and should be executed.
• <Job Number> is a 3 digit sequential number which is one higher than the previous job that was created eg. 001, 002 etc.
Job Class: A
Times for SAP outbound job processing: 05h00, 12h00.
Time for GENTRAN inbound processing: 1 hour after SAP outbound
Name of ABAP Program: RSEOUT00
A variant should be created in transaction WE14. The variant name for the outbound job is :
Z_EDI_OUT_<client number>,
where
• client number is the number of the client where the job is to be executed
The variant should include: port name, logical message type ORDERS and ORDCHG, and output mode 4 (Collect Idocs).
7.1.2. Inbound Jobs
Naming convention for inbound jobs is:
Z_EDI_IN _<Client Number>_<Job Number>

9. where:
• <Client Number> is the number of the client on which the job is created and should be executed.
• <Job Number> is a 3 digit sequential number which is one higher than the previous job that was created eg. 001, 002 etc.
Job Class: A
Time for inbound job processing: 17h00.
Name of ABAP program: RSEINB00
A variant should be created in transaction SE38, using program name RSEINB00. The variant name for the inbound job is :
Z_EDI_IN_<client number>,
where
• client number is the number of the client where the job is to be executed
The variant should include: path /home/edi/<portname>/edi_in
where <portname> is used to define the directory name, with details of the naming convention described in section 6,
“CONFIGURING SAP FOR EDI”.
7.1.3. Defining Jobs
• To define a job, use the interactive SAP transaction SM36.
7.1.4. Executing Jobs
To make a job executable, it must first be released.
7.1.5. Checking the status of jobs
To check the status of a job, use interactive SAP transaction SM37.
7.1.6. Viewing the job log
If a job has been aborted, you should view the job log for the cause of the failure. To view the job log, use interactive SAP transaction
SM37.
7.1.7. Deleting jobs
Some time after a job has been processed, it should be deleted to release system resources. There are two options to delete a job:
• manually, job by job
• automatically, using a reorganization program that deletes jobs that older than a certain date.
7.2. Active Monitoring
This section is only applicable if more extensive IDoc monitoring is required.
This is a special report which informs the agent in charge in critical situations (e.g. if there are too many erroneous IDoc
transmissions).
7.2.1. Active Monitoring: How It Works
To perform the analysis the 'RSEIDOCM' program must either be started or scheduled for a later start. The selection phase requires
valid entries to be supplied for at least the following fields: recipient, recipient type, status group and critical number of IDocs. There
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. The 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 'critical'. The 'number of critical IDocs' counter is incremented if any of the status values allocated to the status
groups occurs. If the number of critical IDocs counted exceeds the specified limit, the situation is classified as a 'problem' and a
notification is sent to the specified recipient.
The notification appears to the recipient as a task in his integrated inbox. When the task is executed, a mask with the IDoc statistics is
displayed showing the values holding at the time the analysis was performed. The 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. The 'Refresh' function allows the person
executing the task to display the current status of the IDocs. This renewed analysis is based on the same selection criteria already used
for the notification.

10. 7.2.2. Active Monitoring: Configuration
The following configurations must be made one time for 'active monitoring':
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 'TS3200108' standard task. The task must be maintained as a 'general task'. This can be done
using the automatic workflow customizing or the task maintenance in the processor assignment function. An alternative in the task
maintenance is to specify an organizational unit in the processor assignment. However, this is not recommended because of the
problem of the intersection of the two sets, since the result for the set of possible processors of the task could be an empty set.
The 'RSEIDOCM' program can either be started interactively or scheduled for periodic monitoring using batch scheduling with
different variants.
Batch scheduling is done using the 'Define job' function. This allows continuous periodic monitoring of the IDoc processing to be
configured and automated. Job scheduling can be found by following the menu path Tools -> Administration -> Jobs -> Define job.
7.2.3. Active Monitoring: Parameters
The recipient and recipient type fields specify who or what should be notified in the case that notification becomes necessary. This can
be a work center, a job, a position, an organizational unit or a user. The recipient must be maintained in the organizational model of
the PD-ORG. Analysis is only possible if a valid value has been entered here.
When the batch run is actually executed, 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.
The number of critical IDocs defines the threshold (a 'strictly greater than' condition), beyond which a notification should be
dispatched. This parameter can also take the value zero.
Status groups are used to group together possible status values of IDocs. The allocation of a status value to a status group is known as
a qualification. SAP supplies a standard qualification, but this may be changed. The set of IDocs that has been determined for analysis
by a set of further selection criteria (see below) is examined to ascertain its current status. If this status is one that has been allocated to
one of status groups specified in the selection, the 'number of critical IDocs' counter is incremented.
Status group F (inbox: error in application) is supplied as standard by SAP with the status values:
• 51 (application document not posted)
• 52 (application document not fully posted) and
• 57 (error when checking the application).
For each IDoc in the set of IDocs selected that has a current status of 51, 52 or 57, the 'number of critical IDocs' counter is
incremented by one. If this counter reaches or exceeds the threshold specified (in this case 1), a notification is sent to the specified
recipient. This would therefore be the case here if just one IDoc currently has a status value of 51, 52 or 57.
By specifying the following parameters :
• logical type, variant and function of the message,
• sender's port,
• partner type, partner function and partner number of sender
• recipient's port,
• partner type, partner function and partner number of recipient
the set of IDocs to be analysed can be restricted further.
Thus, the following parameters have to be set:
• Logical message 'ORDERS'
• Customer '2400004'
• Batch run time 08:00 on the day of delivery
To that end, the variant MY_VAR is created for the report RSEIDOCM:
1. In the abap/4 editor, select "variant" for the report RSEIDOCM and push the "Display" button. In the next screen, create the variant
'MY_VAR'.
2. In the following screen, select, in particular, "1 day" and "0 days 14:00:00h" for start and end before batch run, respectively. The
batch job itself is started at 08:00h. Status group F (inbox: error in application) is supplied as standard by SAP with the status values
51 (application document not posted), 52 (application document not fully posted) and 57 (error when checking the application).
3. In the daily batch run all the IDocs are selected that arrived the previous day between 00:00 and 18:00 and that have the logical
message type 'ORDERS' and were sent by the sender '4711'. If the current status of at least two of these IDocs is allocated to the status
group F, a notification is sent to the user 'MYUSER', since the 'number of critical IDocs' threshold value is set to 1.

11. Documents
• SAP EDI Administrator role definition
• EDI Subsystem administrator role definition
SAP XML – EDI
Advantages of including Electronic Data Interchange (EDI) entities with eXtensible Markup Language
(XML)
The advantages of including Electronic Data Interchange (EDI) entities with eXtensible Markup Language (XML) differs for
each camp.
• For the EDI camp the unification means making application implementation easier, allowing for quicker reach into
vertical markets, reduced message stores when processing transactions, and most importantly enabling
document-centric tools such as search engines and Internet "push" products to supplement database
mechanisms.
• By assuring EDI compatibility, the XML camp gains almost instance use among thousands of companies. XML
will gain a common extensible data entity definition which has under gone the test of time.
The bottom line: the XML camp gains Fortune 1000 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?
The attempt to combine structured presentation with structured data for transactions is not new. The last attempt ended a
little over a year ago. At that time the researchers of the Joint Electronic Document Interchange (JEDI) project which were
managed through the Division of Learning Development Research Group at De Monfort University Leicester, the
Computer Science at University College London, and the Document Interchange project at UKERNA completed their
study. The project's intent was to analyze the current international and industry de facto standards that are in use for
electronic document creation, transfer and presentation. The project was to identify the set of common elements that
would allow the conversion of both logical and layout aspects of a document. The documents would then be viewed using
a WWW type browser that was available for common computer platforms. The JEDI project concluded that SGML is
ideally suited for EDI as it is text based and is independent of platform and operating system. The actual results were a
little disappointing in that the world was and is still not ready for an SGML/DSSSL implementation.
What 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 WWW browser-based applications - the eXtensible Markup Language (XML). The intent is
to make the rather rich HTTP protocol even richer. It is a scaled down simpler version of SGML, in fact the one of the
goals of the specification is to "...be straightforwardly usable over the Internet." The key here is "straightforwardly usable."
This flavor in the design of XML which is why the specification will succeed for transactions where the SGML/DSSSL
failed. This is not to say that SGML/DSSSL wouldn't work, but more a reflection on us accepting change. Change
sometimes needs to be taken in a series of steps - XML is the next step.
What about the momentum with XML?
XML, managed by the World Wide Web Consortium (W3C) working group, will no doubt become the next significant
enabling technology for the Web. XML will provide Web publishers and consumers with unprecedented power, flexibility
and control over the creation of and access to Internet and intranet content. To date the XML specification is backed by
SoftQuad, Adobe, IBM, HP, Microsoft, Netscape, Lockheed Martin, NCSA, Novell, Sun, Boston University, Oxford
University, and the Universities of Illinois and Waterloo. In addition to the authors of the specification, about 30 companies
already support the CDF; Channel Definition Format, an XML application which brings to the Internet various "push"
operations.
Netscape and Microsoft and have already pledged XML support in their future WWW browser releases. And many
corporations are being added to the list as they learn of the specification's existence and capability.

12. What could the EDI entities look like?
The general format of the transaction would be described in HTML. The EDI segments and elements could go something
where attributes identify certain elements as holding EDI information. That way, the EDI information is explicitly labelled,
and an XML processor can be asked to return it to an application using standard API calls.
This approach means that the EDI information forms part of the logical structure of the XML document, rather than being a
CDATA '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.
Furthermore, it allows them to use XML's built-in validation facilities to check for structurally valid input, e.g.: in the DTD:
< !ELEMENT N1-GROUP (N101, N102?, N103, N104) >
< !ATTLIST N1-GROUP EDI-TYPE CDATA #FIXED "ANALYSED CONTACT">
< !ELEMENT N101 (#PCDATA) >
< !ATTLIST N101 EDI-TYPE CDATA #FIXED "QUAL PREFIX">
........
in the document:
.........
< N1-GROUP>
< N101>FR< /N101>< N103>1< /N103>< N104>123456< /N104>
< /N1-GROUP>
Note that the EDI-TYPE information is declared once and once only, in the DTD, and does not add to the markup
overhead in the actual document.
The above items are just food for thought. Hopefully, when both camps view the above lines, they see only a slight
modification to the methods implemented today. To include the right hooks, CDATA or other XML entities might have to
include some specific syntax for EDI. The details, though not many, can be ironed out by the excellent authors of both
camps.
So then XML documents are really just EDI templates, Right?
Yes and no. Yes the documents can be used as templates. But in addition to this application, the XML document can also
be a transaction itself. XML/EDI would allow in a non-proprietary way, for structured presentation format to be included
now in the transaction. Combined effort in template or application form creation and development is estimated in the
thousands of man-years, not hundreds. Soon there will be a standard which to share the work others have done,
applications need only to simply access WWW browser objects. This object-based approach to applications will make
document transaction exchange even easier. Bottom line: The EDI camp could leverage XML 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. By adding defined data entities, these tools can be enhanced to make 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. XML/EDI will give the EDI administrator more choices.
If presentation elements are included in the transaction what happens to our transmission bandwidth?
The transaction would certainly require more bandwidth as compared to EDI specification today. The additional strain on a
corporation's infrastructure must be weighed with those advantages gained by the use of XML/EDI on a case by case
basis. It is estimated that the XML/EDI-based transactions would add about 35% to the size of the current transactions. In
the cases where this increase is significant, the XML/EDI standard documents can replace proprietary templates, which
would still allow for use of document-based tools internal to the organization.
Where do we go from here?
• Introduction of the two camps - XML and EDI
• Education of both camps of the others existence, tools and implementation methods
• Assure that the proper hooks are in XML to support EDI
• Create an EDI application for the Extensible Markup Language (XML)
• EDI "mappers" must add XML parsing to their front-end logic.

13. F A Q - EDI
• What is EDI?
• The computer-to-computer electronic exchange of machine-processable business documents in a standard format.
• An electronic alternative to paper, fax, and phone-based transactions used by companies to communicate with one
another.
• What are EDI Drivers?
• Ability to strengthen partnerships
• Improve business processes
• A communication tool to allow new ways to do business
• A preferred way of doing business among Fortune 500 companies
• A business basic for the industry
• How is EDI Used?
• EDI is used as a strategic tool to reduce expenses, streamline business procedures, and create a competitive
advantage.
• How is EDI Started?
Usually Reactive or Proactive.
REACTIVE PROACTIVE
• Lack of understanding
• No direction
• Lack of regulated program
• "Jury Rig" third-party solution
• Clearly defined business need
• Defined Corporate direction
• Controlled program
• "Selected" trading partners
• Impartial "third-party" input
• How does EDI Work?
Purchase Ordering Example
1. The buyer enters order information into the production database, which generates a purchase order on the computer.
The order information is then channeled through a number of interface programs.
2. The interface software programs perform edits and checks on the document and direct the order data into predefined
EDI intermediate files.
3. The EDI intermediate files contain information in a form that the EDI translation software can read.
4. The translation software is a set of programs that translates the interface file data into a document formatted
according to EDI standards that the supplier's computer can recognize.
5. The electronic document now consists of a file that contains the order data in a predefined, recognizable order.
6. The communications software adds appropriate communications protocols to the EDI document in preparation for
transmission via telephone lines.
7. Using a modem and telephone line, the buyer transmits the EDI purchase order to a VAN (Value added network).
Think of this as a mailbox.
8. The communications software on the supplier's computer picks up the document from the VAN, interprets and/or
converts the communications protocols to open the electronic document.
9. The purchase order is now in a standard, recognizable format in a file and is available to the supplier's computer.
10. The supplier's translation software interprets the documents from the EDI format and places the order information in
EDI intermediate file(s).
11. The EDI intermediate files contain the translated purchase order information.
12. The interface programs perform edits and checks before the data is integrated with the supplier's production
database.
13. The application software on the supplier's computer can now process the buyer's order.
• What is the most common EDI cycle?
• Customer transmits EDI 850 (purchase order)
• Supplier transmits EDI 997 (functional acknowledgement)
• Supplier transmits EDI 856 (advance ship notice)
• Customer transmits EDI 997 (functional acknowledgement)
• Supplier transmits EDI 810 (electronic invoice)

14. • Customer transmits EDI 997 (functional acknowledgement)
• Customer transmits EFT (Electronic Funds Transfer) Payment
• What are EDI Benefits?
• Builds closer business partnerships
• Reduces/eliminates manual handling of data, errors and rework
• Transfers information faster and more accurately
• Automates routine transactions
• Improves productivity and business controls
• Reduces costs
• Shortens transaction processing cycles
• Enhances data accuracy
• Lowers inventory levels
• Contributes to better in-stock positions
• Lowers freight costs
• Provides Quick Response capability
• Improves cash-flow management
• Creates a competitive advantage
• What are EDI Benefits Summary/Requirements?
Benefits Requires
Business Process
Examples
1. Operational EDI transactions
Ordering - Purchase
Order
Purchase Order
Acknowledgement
2. Tactical
Internal Process
Re-engineering
Forecasting - based on
SIT
- Availability
- Increased inventory
turns
3. Strategic
Internal and External
Process Re-engineering
Quick Response -
Market Share
Supply Chain Mgmt -
Sustained
Profits
• What is the Link between EDI and Profits?
EDI the tool EDI the features EDI the benefits
Shared forecasts Inventory turns increase Cut costs!
Transaction automation Reduced labor Cut costs!
Integration with systems
Fewer errors, rework,
less paper
Cut costs!
Electronic payments Better cash flow Cut costs!
Shared sales and
inventory data
Improved availability Increase sales!
Integration and high
speed data transfer
Access to quality
information
Increase sales!
Transaction automation People add value Increase sales!
• Why move to EDI?
• Allow machines to process business transactions while people develop and enhance business relationships
• Strengthen internal and external business relationships through "information partnering"
• Promote Electronic Commerce through EDI and other information solutions

15. • Improve the supply chain by making accurate information available quickly and inexpensively
• Reduce operating costs by re-designing business processes and automating routine tasks
• We created an EDI Vendor and created all required output conditions. However no IDOC is generated when PO is
printed. Why?
Go to Header->output for the PO. The output type shall be '6'. The status shall be '1'. If the status is '0' check the timing. If the
status is '2' , go to 'GOTO->Processing Log' and the explanation for non-generation of IDOC can be seen.
• How can we create / upload IDOC's from legacy system to SAP?
Third party tools like Mercator and Gentran may be used to convert Legacy files to Idoc format. These tools provide an
IDOC tree import facility, SAP provides the export facility. You can transfer the Idoc layouts from SAP to these tools
automatically and then map.
• We want to receive an outbound EDI 855 IDOC only if E2EDP20 -scheduling confirmation segment is present. Else
get an "error" status preventing triggering the EDI subsystem.
User exit logic has to be added in function IDOC_INPUT_ORDRSP.
# Set up a test flag and set it off when the IDOC header is read.
# Turn the flag ON when the EDP20 segment is read.
# Interrogate this flag when the next segment after EDP20 in the same IDOC comes in. If it is on ,you have an EDP20
coming in.
# Issue an error status 51 with suitable message for whichever condition you don't want the IDOC to be processed, This will
stop the IDOC from posting.
• Where ever PO is sent to the vendor via EDI, we want an acknowledgement of the PO by vendor. Which fields are
updated and what should be my procedure?
Execute Program: IDOC_INPUT_ORDRSP
Process code: ORDR
Message type: ORDRSP
IDOC: ORDERS01
The confirmation process allows the supplier to return an acknowledgment. Only Dates and quantities can be changed The
information is stored in the PO and can be viewed via Item->Confirmation->Overview. The PO can be flagged as
'confirmation required' so that Pos without acknowledgement receipt can be monitored. Control keys and tolerances (days
and quantities) have to be customized.