EDI AND ERP

Godwin Mathew Rock

Roll no:12School of Management studies

CUSAT, Cochin 22Email id:godwinmathewrock@yahoo.co.in

Abstract: ERP systems often use EDI technology to facilitate communication between businesses. EDI, a technology released in the 1980s, was used to transmit electronic documents both inside and between businesses. ERP works to manage internal and external resources of an organization, helping enhance communication and decision making by consolidating business process and operations. ERP and EDI work together to make programs more efficient by adding potential communication facility and supply chain management technologies to businesses. EDI replaced traditional methods of business communication, i.e. telephone and fax, with electronic means of document transmission. Using computers to electronically exchange communication and documents has greatly decreased administrative costs. Although ERP and EDI systems can work together to integrate all members of a business to the same communication and database system, EDI does not require ERP. EDI can run simply with a computer and access to the Internet.

Key Words: ERP, implementation, EDI, integration, mapping, database, redeploy.

1.0 INTRODUCTION

1.1. General InformationERP systems are designed to be a ‘total solution’ to enterprise resource planning across multiple business units with each component having an impact on every other component.  The components are typically grouped into ‘subsets’ that direct their functionality at different business operations:

Finance & Accounting Supply & Purchase Manufacturing Warehouse & Distribution Marketing & Sales Planning & Analysis Human resources & personnel management

Each of these basic business components has direct impact on each other component.  The ERP system attempts to balance the impact and make information transfer more efficient and standardized.  This is designed to reduce the ‘foreign’ system interfaces; but never entirely eliminates them. No system yet conceived will meet any corporations ‘total’ system requirements.  In every case, there are ‘auxiliary’ and other support systems that will have to be interfaced to the ERP system.  Furthermore, many companies cannot live with the delivered functionality of the ERP system that was chosen and decide to ‘modify’ it to meet on-going business requirements.

For these reasons and just plain ‘good business’ it is extremely critical to plan these deployments, considering the different impacts on each business unit.  In the past with multiple vendor-supplied systems, the interfaces were known, controlled and understood by the indigenous staff.   Now with ERP systems, these interfaces are embedded in the system and no longer completely understood by the company technicians or applications support groups.ie. technicalities gets reduced for the ERP usage.

Because the ERP systems component interfaces are embedded and controlled by ‘setup tables’ or other control systems which are defined during the installation process, when the system is configured the ‘setup’ process selects different program components to ‘load’ as part of the installed ERP system base.  These selected components will determine the inventory method and how it is valued, counted, warehoused; how accounting entries are posted and at what level of detail (defined by the Chart of Accounts).  Component selections will determine the manufacturing process control, warehouse management and distribution control processes to be utilized.  All these business unit control systems will be linked by embedded system processes necessary to control the vast array of components encompassed by the ERP system. 

It is for this reason that the planning process is so critical.   Every business unit in the company will be directly affected by the operation of the ERP system.  Subsequent changes in any business unit function or process can and will affect every other component.

If for example, a company chooses to implement EDI or other electronic communication transaction system at a later date, many of the operational components of the system will be impacted.  If in

the future, instead of hard copy purchase orders, the company decides to utilize a fax based system, the simple concept of ‘send method’ for the purchase order comes into play.   Based on the original configuration, if this was not planned, the component required to format a fax instead of print the purchase order may not have been installed.  This becomes more complex if electronic data interchange (EDI) is chosen at a later date.  A whole set of tables, files and parameters come into play that may not have been configured during the initial installation of the ERP system.

Not only may the purchase order process be impacted, but the purchase order response cycle, change management, backorder system, manufacturing, lead time, distribution and accounting discount management systems will come into play.  This does not even consider the legal impact of the company and its business partners agreeing to accept a facsimile instead of hard copy; an electronic transaction instead of a fax.

When the electronic business application comes into play, whole new sets of components are added.  Instead of ‘data entry’ processing the purchase order or invoice, now it is electronically entering the system.  The oversight that many companies relay on, the clerical purchase order desk or invoice-processing desk, are no longer a part of the transaction process.  The manual correction prior to data entry that the clerical staff ‘always’ did is no longer present.  The simple change of ‘e’ to ‘ea’ for order quantity in ‘eaches’ that the data entry clerk automatically made, is no longer ‘automatic’ but must be planned/programmed to be handle.

This has a ‘ripple’ effect across each and every business unit.  Activities that used to be ‘handled’ by indigenous staff now must be ‘handled’ and processed by the ERP system interfaces.  Now the people that used to perform the mundane task of ‘paper handling’ can be better utilized as ‘error handlers’; tackling the inbound/outbound transaction flow that falls outside the capability of the ERP system to process.

ERP transaction interfaces (IDOC’s for SAP, F47-files for JD Edwards, EDI Gateway for Oracle, etc.) are designed to process these electronic transactions into and out of the ERP application system business unit modules.  These transactions have both accounting and financial impact as well as operational impact on the day-to-day operation of the business.  They have ‘ripple effects’ across business units.  Without the proper planning and understanding of these ‘gateway’ interface operations, companies may fail to plan for the impact that electronic transaction processing through an ERP system will have.  Attempting to implement an electronic transaction interface (weather it’s EDI, MQ-Series, MS-MQ, Internet access, or another mode), after the ERP system has been fully implemented may be extremely costly.   Many of the required components may not have been installed during the ‘configuration process’ if certain electronic interface options (such as EDI) were not selected during the initial criteria and business rules selection process.  Retrofitting these components over existing operational ERP system components may be difficult.  More so if any customization was done to any business unit module; due to the inter-linkage ‘ripple’ effect of how the ERP system processes transactions.

In addition to this 'ripple' effect, many of these transaction interfaces in today's ERP systems do not have sufficient data elements to contain and manage many of the new data requirements present in today's electronic business and EDI transactions.   Current sophisticated shipping and transport systems require complex dating and specific packaging instructions.  In addition, with many 'drop shipment' orders, third party shipping addresses and instructions often are not captured in the basic

ERP system data base structure.   Further complicating the situation is RFID (Radio Frequency Identification) tagging and specifications will soon become a standard practice in most industry segments (wholesale, retail and government).  This will add identification tagging components to many shipping transactions that are not currently supported within the most common data base structures of today's ERP systems.  It is therefore necessary to implement auxiliary data structures that will support and maintain these additional data components of today's business transactions.  The data flow methodology encompassed by EBFM (Electronic Business Flow Management) design provides the data analysis and structure to support these and forthcoming data requirements.

In the end, it is always better to plan than to spend.  Careful consideration of the ERP system’s impact on on-going business operations must take priority over the ‘need to implement’.  At the same time, it is paramount that companies don’t ‘plan’ instead of ‘do’.  There is a critical balance that is often gained by the old KISS principle.  The more complex the operation, the more detailed the planning.  The simpler the process, the easier to implement.

Evaluation of business rules is necessary prior to any ERP system implementation.  The concept of an Enterprise Resource Planning system is after all based upon the concept that the business has adopted a common set of business rules that have been (or are to be) applied across all affected business units of the organization.

2.0. THE IDEAL ERP SYSTEM

An ERP system would qualify as the best model for enterprise wide solution architecture, if it chains all the below organizational processes together with a central database repository and a fused computing platform

ManufacturingEngineering, resource & capacity planning, material planning, workflow management, shop floor management, quality control, bills of material, manufacturing process, etc.

FinancialsAccounts payable, accounts receivable, fixed assets, general ledger, cash management, and billing (contract/service)

Human ResourceRecruitment, benefits, compensations, training, payroll, time and attendance, labour rules, people management.

Supply Chain Management Inventory management, supply chain planning, supplier scheduling, claim processing, sales order administration, procurement planning, transportation and distribution.

ProjectsCosting, billing, activity management, time and expense.

Customer Relationship ManagementSales and marketing, service, commissions, customer contact and after sales support

Data WarehouseGenerally, this is an information storehouse that can be accessed by organizations, customers, suppliers and employees for their learning and orientation

Fig.1 Enterprise Resource Planning

3.0. EDI SYSTEM

An EDI document is the electronic equivalent of a paper document such as a purchase order or invoice. Standards govern how EDI documents are structured, and define the rules for their use. North American companies follow the X.12 standard, while other parts of the world follow the EDIFACT standard. The X.12 standard is made up of hundreds of documents called ‘Transaction Sets.’ Transaction sets are made up of ‘Data Segments’ and ‘Data Elements,’ of which there are hundreds, and thousands respectively, in the standards dictionary. By putting various combinations of data segments and data elements together in a structured format, you end up with a transaction set that has meaning.

Transaction SetsThe following table shows a portion of X.12 transaction sets from the 800 and 900 series

4.0. WORKING OF EDI

Sender (Outbound) and Receiver (Inbound)EDI is a batch process in which transactions are grouped together into one or more files and all transmitted at the same time. One trading partner is the sender (outbound) and one trading partner is the receiver (inbound). Both trading partners become senders and receivers throughout the relationship. In most situations one trading partner is the driver of the EC/EDI relationship and the other trading partner is the follower. The driver can be a customer, industry association or government department, while the follower is a supplier, member of an association, or an organization that deals with the government. The driver will publish an implementation guide, companion guide or web site that describes its EDI program, procedures and expectations. Someone who is a supplier or deals with the government must become compliant by following the instructions set out in the guide. Members of an industry association are not mandated to use EDI, but they must follow the guide if they a going to implement EDI.

Data Transport It is the process of electronically transferring files to/from your trading partners. Traditionally a Value Added Network (VAN) is used as the go-between for trading partners. The sender’s

computer dials-up and drops off a file to the VAN, which in turn stores the file in an electronic mailbox. When the receiver’s computer is ready, it dials-up the VAN to pick up the files from the mailbox. Protocols such as Async and Bisync are used to securely transmit files to/from the VAN. Nowadays the Internet is used to make the connection to the VAN. It is also used to connect Point to-Point to a trading partner, thus bypassing the VAN entirely. The computer dial-up step isn’t necessary if the Internet connection is always active, although some small businesses still use a dial-up Internet connection.

These are the most common protocols used to transmit files to/from a VAN or Point-to-Point:

File Transfer Protocol (FTP) it is initiated by either trading partner to transfer files to/from the VAN’s computer, or Point-to-Point on the trading partner’s computer. It usually requires a log-in to gain access, but it is not fully secure because files are sent in clear text and could be intercepted and deciphered. File Transfer Protocol Secure (FTP/S) solves the problem by adding a level of security to thwart eavesdropping.

Hyper Text Transfer Protocol (HTTP) it is initiated by one trading partner to request files to be transferred from the VAN’s computer, or Point-to-Point from the trading partner’s computer. The receiver’s computer must acknowledge the request before sending the file.

Hyper Text Transfer Protocol Secure (HTTP/S) It is the same as HTTP, with an added level of security to encrypt files.

EDI-INT It is a set of standards for transferring EDI files through the Internet more securely than e-mail, FTP/S or HTTP/S. Applicability Statement 1 (AS1) defines the standards for using e-mail to transfer files, Applicability Statement 2 (AS2) defines the standards for using HTTP to transfer files and Applicability Statement 3 (AS3) defines the standards for using FTP to transfer files. While FTP/S and HTTP/S offer security, EDI-INT adds another layer of security involving public and private keys.

There are various factors surrounding cost, security and compliancy that will determine which Data Transport method should use. If you are the follower in a trading relationship, the Data Transport method will most often be determined by the driver. Followers have little say in the matter, and will have to bear any added costs to comply. If your trading partner is indifferent to the Data Transport method, choose a protocol that offers an acceptable level security for your data. FTP and HTTP would not be considered secure, FTP/S and HTTP/S are considered secure, and EDI-INT is considered very secure. Taking into account all your trading partners, it is likely that will end up using a mix of Data Transport methods.

Data TranslationIf you look at an EDI transaction in its raw format, most of the data is meaningless until it is passed through an EDI translator. Data Translation is the process of interpreting EDI data to ensure it conforms to the EDI standards (X.12 or EDIFACT), as well as performing checks and balances before the data reaches the intended business application.

An EDI translator performs the following functions:

Compliance CheckingEach EDI transaction is checked against the EDI standards dictionary to ensure it conforms to formatting rules. The term for this is called ‘compliance checking.’ If an EDI transaction does not comply with the rules, the translation fails and the transaction should not reach the business application. The following are some examples that would cause a transaction to fail EDI translation:a) A line item on a purchase order has no number in the ‘Qty Ordered’ fieldb) The date on an invoice is formatted as ‘DDMMYYYY’ when it should be ‘YYYYMMDD’c) A shipping manifest is missing the ‘Total Weight’ fieldd) A trading partner’s accounting / ERP software underwent an upgrade and caused a fieldto be formatted incorrectly

Control Number CheckingThe purpose of control number checking is to track the transmission of EDI documents, to ensure duplicates are not sent or received. Sequential numbers are assigned to each transmission (ISA segment), each group of documents (GS Segment) and each transaction set (ST segment). When a transmission is sent or received and a control number is duplicated or out of sequence, it indicates a problem that requires immediate action. This safeguard ensures that missing transmissions are noticed, and duplicate transactions don’t reach the accounting / ERP application.

Trading Partner ManagementIt would be difficult to manage EDI trading relationships without a trading partner management function. This function keeps track of the attributes that differ from one trading partner to the next. The following are some examples:• Contact information for the business person responsible for EDI.• Contact information for the technical person responsible for EDI.• Data transport method used, and account information to connect to a VAN or Point-to-Point.• The severity level (critical or warning) if control numbers are out of sequence.• E-mail address of the person to alert when errors are found.• EDI standards version number being used.

Tracking and AuditingProblems will arise no matter which form of electronic commerce is used. With EDI, trading partners need the ability to track the whereabouts of an EDI transaction that did not make it to the accounting / ERP application. EDI translation software provides various logs and reports to trace a transaction throughout the process. An inherent audit feature in EDI translation software is the functional acknowledgement, which is known as the 997 transaction. Every EDI transaction that is sent by a trading partner requires an acknowledgment of receipt from the other trading partner via the 997. A positive 997 means the original transaction was received and passed EDI translation. A negative 997 means the original transaction failed translation. Not receiving a 997 means there was a transmission problem between the two trading partners.

Document RepositoryA document repository is a place to store all incoming and outgoing EDI and non-EDI transactions. Transactions are stored in a database in their original form, and all activity against each transaction is logged. This makes is possible to trace a transaction from all points between Data Transport and

Data Integration into the business application. When it becomes necessary to re-send a transaction due to operational problems, the original can be retrieved from the repository. Another function of the document repository is to facilitate an EDI document ‘turnaround.’ Many accounting / ERP applications do not have a home in their database for fields that arrive on an incoming EDI document. The trading partner expects the data in those fields to later be sent back in another EDI document. An example is a purchase order (850) that is ‘turned around’ into a purchase order acknowledgement (855). Since the accounting / ERP application does not store some of the EDI data, the original 850 document can be retrieved from the repository to select data to place into the 855.

5.0. DATA INTEGRATION

Why should Integrate EDIIntegrating EDI increases productivity, which means it costs you less to run your business. This has a positive effect on customers, and fends off competitors. These are the reasons you should integrate EDI, most of which relate to productivity:

Penalties imposed by customers. In the supply chain process, for example, manufacturers and distributors must follow strict rules imposed by their customers. Failure to do so will result in unilateral fines being assessed for errors or missed schedules. The following are some

Examples of errors which will result in fines:• Keying errors• Incorrectly formatting an EDI transaction• Data missing on a transaction• Failing to acknowledge a transaction (997)• Sending a duplicate document• Not adhering to Data Transport schedules

Save time. EDI will always be faster than re-keying data. The greater the activity through integration, the less it will cost compared to manual processes.

Handle data only once.The fewer number of times a person has to handle a piece of data, the better. Integration reduces the likelihood of costly errors.

Adding new trading partners becomes easier.Once the integration infrastructure is in place, it becomes easier to add new trading partners to the process. The productivity benefits multiply with each new trading partner added.

How Integrating EDI WorksFew, if any, accounting / ERP systems will accept an EDI transaction in its raw format for processing. This means there has to be integration software in the middle that will map the EDI transaction into the format that the accounting / ERP software will accept This diagram below

illustrates the integration process using a doorway analogy. The accounting / ERP software will provide the ‘doorway’ to allow a transaction to ‘enter’ in one of two ways: 1) the integration software will ‘walk through the door’ and interact with the application directly; 2) the integration software will hand off the transaction at the ‘door’, and the accounting / ERP software will take over. Both methods are acceptable, but the accounting / ERP software ultimately decides which one must be used.

Methods for Integrating EDIThis section describes the different methods that the accounting / ERP publishers will accept for integrating EDI. It may seem overly technical, but it illustrates the disparity among the software publishers and integration software vendors.

Method 1: Application Program Interface (API) An API is a program provided by the accounting / ERP publisher that controls an external program’s access to their system. It enables the two programs, the integration software and the accounting / ERP software, to communicate with each other using the API as the go-between. The

integration software ‘calls’ the API and passes the data to the accounting / ERP software. If the data is incomplete or contains errors, the API will not allow the data to be written to the database, and an error message is returned to the integration software. An API is a two-way process that allows the integration software to both read and write data to the accounting / ERP system’s database.

Method 2: Open Data Base Connectivity (ODBC)This method is a combination of an API (method #1) and SQL (method #2). ODBC is a standard way for accessing a database from a Microsoft program. (JDBC is the equivalent from a Java program.) ODBC contains a set of APIs written in SQL that define how to move data in and out of a database that supports ODBC. When integration software uses ODBC, it bypasses the accounting / ERP software altogether and goes right to the database to read and write data.

Method 3: Intermediate FileWith this method, the integration software will map an EDI transaction to a format specified by the accounting / ERP software, and create an intermediate file on the server. The intermediate file could be a text file or a separate database belonging to the application. The accounting / ERP software ‘polls’ the server regularly to see if there are any transactions waiting. If so, a process is initiated to import those transactions into the accounting / ERP software. The application will edit the transactions and reject any that contain errors. This process is automated, without the need for a user to intervene.

Method 4: Import / Export (I / E)With this method, the accounting / ERP software provides an option to import data using a predefined format. The integration software will map an EDI transaction to the format required, and create a text file containing the transactions. A user of the accounting / ERP software must go into their software, choose the ‘Import’ function on one of the menus, and select the location of the text file to be imported. During the import, the application will edit the transactions and reject any that contain errors. The export function is the opposite of the import function, in that it takes data from the database and writes it to a text file.

6.0. CONCLUSION

ERP systems often use EDI technology to facilitate communication between businesses. EDI, a technology released in the 1980s, was used to transmit electronic documents both inside and between businesses. ERP works to manage internal and external resources of an organization, helping enhance communication and decision making by consolidating business process and operations. ERP and EDI work together to make programs more efficient by adding potential communication facility and supply chain management technologies to businesses. EDI replaced traditional methods of business communication, i.e. telephone and fax, with electronic means of document transmission. Using computers to electronically exchange communication and documents has greatly decreased administrative costs. Although ERP and EDI systems can work together to integrate all members of a business to the same communication and database system, EDI does not require ERP. EDI can run simply with a computer and access to the Internet.

ERP systems coordinate supply chain management with EDI communication exchange across organizations to streamline administrative tasks. ERP systems can reduce human error, make the business more cost efficient, and aid in communication, essentially amplifying the original benefits that EDI brought to traditional business. ERP and EDI systems together reduce the amount of paperwork needed to communicate between businesses.

Within supply chain management, EDI is the technology that focuses on the delivery of electronic communication between businesses. This communication can include orders, payment notices, and shipment verification. Since many companies use a form of EDI, many ERP systems include EDI technology in their programs. Together, ERP and EDI systems ensure that these documents are standardized based on industry and legal standards.

Consulting firms and organizations often have ERP and EDI specialists to help them handle system requirements. EDI specialists handle translation methodologies and interfacing techniques and support EDI partnership systems. ERP specialists understand the organization's needs and processes and work to construct an ERP system to meet these needs. Both ERP and EDI specialists may also work to train users to best take advantage of the systems operating within a business.

Extensible Markup Language, or XML, is argued by some to be a replacement for EDI in some organizations. While XML is similar in nature to EDI, it is considered different because of the way each technology structures the data it contains. Currently, XML format is too large and lacks standards to implement it on as wide of an industrial scale as EDI technology. XML is not a threat

to EDI, however, as all forms of e-commerce support additional advancements in e-communication, thus supporting EDI technology

7.0. REFERENCES

1. Anonymous , 2004, EDI impact on ERP System Implementation, http://msc-inc.net/documents/edi_erp.html

2. Vladimira Vlckova , 2006, EDI and ERP as Tools for Integrated Logistical management support , http://www.leidykla.vu.lt/fileadmin/Vadyba/10/Vladimira_Vlckova.pdf

3. JohnSimmons ,October 2007, ERP/ EDI Integration Methodologies , http://www.dicentral.com/downloads/EDI%20Integration%20Methods%20White%20Paper.pdf

4. Joseph Woodside , journal ,http://dl.acm.org/citation.cfm?id=12722865. Anonymous , EDI for ERP, www.focussed-ec.com6. Lee Markonjic , April 2008 , Integrating EDI into ERP systems,

http://www.ec-edi.biz/content/download/whit-999-20080415-Integrating-EDI.pdf7. http://www.covalentworks.com/internet-edi.asp8. Anonymous , October 3- 2011, EDI and ERP- general information,

http://www.scc-co.com 9. Woodside JM, June 31-2007, EDI and ERP, www.ncbi.nlm.nih.gov/pubmed/1762202010. Anonymous , 2002, EDI vs ERP , http://www.retailedi.com/index.php/business-intelligence-a-

analytics/31111. Ray Atia , 2004 , EDI integration , www.amosoft.com/articles/Documents-Exchange-Between-EDI-and-

ERP-Systems.html12. Ray Atia , EDI Pros and Cons, www.amosoft.com/articles/Documents-Exchange-Between-EDI-and-

ERP-Systems.html13. Anonymous, Difference between ERP and e- SCM, http://www.eresourceerp.com14. Anonymous , August 2007, http://en.wikipedia.org/wiki/Electronic_data_interchange15. Anonymous , January 2010, http://en.wikipedia.org/wiki/Enterprise_resource_planning16. Anonymous, EDI ERP/WMS Integration , http://www.tangentia.com/EDIERP-WMSintegration.html17. http://www.iqms.com/products/erp/financial_mgmt/edi_translator.html18. http://www.ec-bp.org/index.php?option=com_content&view=article&id=5068:edi-and-erp-

&catid=53:blogs&Itemid=7819. http://erpcloudnews.com/2011/08/connecting-erp-clouds-through-edi/20. http://www.wisegeek.com/what-is-the-connection-between-erp-and-edi.htm