bullet

SoftCare Home

bullet

Industry Home

bullet

Solutions

bullet

Contact Us

 
 

Introduction to Electronic Data Interchange

   

EDI industry links

   
 

 

EDI (Electronic Data Interchange) is simply the means to communicate between companies from one computer to another. For many years companies have been using computers to send business documents instead of mailing paper documents (i.e. most of our pay checks are directly deposited into our bank accounts). This transfer of funds is accomplished by the use of an electronic file being sent form your company to your bank). The problem was that the all efforts employed proprietary or unique formats. The absence of a standard format led to the condition where computers could not longer "talk" to one another without a great deal of effort by programmers. For example, Supplier X could recognize an electronic Purchase Order from Retailer A but not from Retailer B.  

In 1979 the American National Standards Institute (ANSI) formed the Accredited Standards Committee (ASC) X12 to rectify this situation. This committee was to standardize the format of electronic documents to allow for easy movement of information between computers. From this humble beginning has led to the establishment of standards for over 400 business documents.

In the late 1980's there was a drive to standardize file formats in the rest of the world. This drive resulted in the UN/EDIFACT standard being adopted. For most transactions outside of North America, the UN/EDIFACT standards are used.

Overview of a "typical" EDI Transaction vs. a Traditional Transaction:

A typical EDI transaction involves the following processes (this example is using a Purchase Order being created by a retailer and the vendor receiving the Purchase Order and sending an Acknowledgement document back to the retailer):

EDI Transaction

Pre-EDI Transaction 

Purchase Order is entered into your Purchase Order system.

Purchase Order is entered into your Purchase Order system.

Purchase Order is reformatted into an interim flat file that the TradeLink EDI Management Software can read.

A Purchase Order is printed and signed by your buyer.

TradeLink EDI Management Software will import the interim flat file, verify the contents of the file, combine the file together in an EDI Envelope and send the file to your Trading Partner (either directly or through a network). 

The Purchase Order is Mailed, Faxed, Phoned or handed in person to your Trading Partner.

Your Trading Partners EDI Software interprets the EDI Purchase Order and the file is electronically entered into their Order Management Software.

A clerk receives the Purchase Order, tries to interpret it and then enter it into their Order Management Software. (if the transaction is lost in the mail, the Purchase Order never gets entered into their Order Management Software.

Your Trading Partner's EDI Software Package verifies that it has received the Purchase Order by sending back a Functional Acknowledgement

 

Comment: Let's gets something straight, EDI is not some incredibly difficult process. All it is doing is taking something that is already existing (in our example the issuance of a Purchase Order and changing the method of transfer from paper-based to electronically based).

The use of EDI allows for the following benefits:

  • Reduced manual data entry

  • Reduced postage and handling costs

  • Reduced labor processing costs

  • Reduced order cycle

  • Increased customer service

  • Improved accuracy of data

  • Reduced lead times

  • Reduced paper handling

  • Reduced inventory carrying costs

 

EDI Document Standards

EDI was originally designed to formalize the electronic transfer of information from one trading partner to another. This idea is not new, companies have been transferring information via mail, and phone, in-person or using proprietary electronic formats for years.

Industry groups pushed the standardization of business documents into electronic format. Individual companies realized that they were sending similar documents to their trading partners. It is this fact that spurred companies in the same industry to meet to create formalized EDI standards. In many cases the standards that were developed met the needs of that group of companies. Over time each committee added various codes and documents to meet their industries needs. Each committee designed slightly different formats for their "flavor" of EDI.

By the late 1980's these industry-based committees realized that to increase the use of EDI throughout the whole of industry, these committee's standards would have to be amalgamated. By 1994, all industry committee's EDI standards were to be incorporated in one North American standard. This was accomplished but what resulted wasn't a rationalization of the standard it was simply an accumulated of all of the industry committee's EDI standards. The North American Standard (ANSI) has over 400 documents defined.

It is important to note that no one wanted to eliminate any transactions from the standard as companies had developed  their interfaces to match the various documents. In addition that umbrella organization (ANSI) have kept all of the committee (it seems to have a lot to do with everyone in the Committee wants to go to Washington D.C. to drink). In any case it is important to note that in the rest of the world there are 40 transactions defined (the rest of the World uses a standard called UN/EDIFACT that was created much later that the North American standards), whereas in North America there are over 400 transactions. In fact there are 9 different Invoices (all slightly different) and 10 different Purchase Orders. The Key thing to note when people refer to EDI, what "flavor" of EDI is used will be important. (Its also worth noting that TradeLink EDI has the ability to handle any "flavor" of EDI and the majority of old Proprietary standards without an issue.)

EDI Envelopes:

EDI is really just taking existing business practices and putting them into an electronic format. An EDI Envelope is analogous to a Paper Envelope.

Lets now review our completed EDI Envelope and compare it to our paper document:

Paper Envelope

EDI Envelope (ISA, BG or UNB)

 

Mailing Address

 

Receiver ID

Return Address

Sender ID

 

 

 

Control Number  (not on a Paper Envelope)

  

 

Paper Group Envelope

 

EDI Group Envelope (GS or UNG)

What documents are in the Envelope

What is in the EDI Group Envelope

 

Your vendors name (just in case the small envelope for the Invoices gets lost)

Receiver ID

Your companies name (just in case main envelope gets separated).

Sender ID

 

Group Control Number

 

 

 

Paper Set Envelope

EDI Set Envelope (ST or UNx)

 

 

Control Number

 

Invoice Beginning Information, (has all of the data on different lines in any format you want)

Invoice Beginning Segment(s) (with data elements in a standardized format)

 

Invoice Detail Information (all free form text)

Invoice Detail Segment(s) (available in standardized format so that your trading partner can import it without re-keying)

 

Invoice Summary Information (all free form text)

Invoice Summary Segment(s) (all information is available in standardized format.

 

 

EDI Set Trailer (SE or UNx)

 

 

Set Control Number

 

 

Number of Segments in this Set

 

 

EDI Group Trailer (GE or UNx)

 

 

Number of Sets in this Group

 

 

EDI Group Control Number

 

 

EDI Envelope Trailer (ISA, BE or UNx)

 

 

Number of Groups in this Envelope

 

 

EDI Envelope Control Number

 

The key is to realize that the structure of EDI is to mimic paper processes. In addition, the transferring of EDI data is standardized so that computer to computer exchange of data can be accomplished.

EDI Envelope (generic) (basic comment to make it easier to understand):

ISA (or BG or UNA)   (address information, header control info.)

GS (UNG)

  (type of files, group control information)

ST

 

(specific set starting info)

  Segments

(like EDI information)

 

Elements

(specific pieces of data)
  Segments (like EDI information)
 

Elements

(specific pieces of data)
  Segments (like EDI information)
 

Elements

(specific pieces of data)
  Segments (like EDI information)
 

Elements

(specific pieces of data)

SE

  (specific set ending info)

ST

  (specific set starting info)
  Segments (like EDI information)
 

Elements

(specific pieces of data)
  Segments (like EDI information)
 

Elements

(specific pieces of data)
  Segments (like EDI information)
 

Elements

(specific pieces of data)
  Segments (like EDI information)
 

Elements

(specific pieces of data)

SE

  (specific set ending info)

GE (or UNx)

  (number of files, group control information)
IEA (or EG or UNZ)   (number of groups, trailer control info)

Now lets review the structure of an EDI transmission. To ensure that information is not lost in the electronic Mailbox, an EDI Batch Envelope is created.  This EDI Batch Envelope is similar to a courier envelope. If you were to courier important documents to a trading partner, you require certain pieces of information on the outside of the courier envelope. On the courier you enter:

  • The name of who it is to go to,

  • their address,

  • their unique telephone number

  • your name

  • your address

  • and your phone number.

This is required by the Courier Company to ensure that the documents are sent to the correct person. In EDI, the same approach is used. Instead of a name, address and phone number, you specify:

  • An Unique Identification  for your company

  • An Unique Identification for your Trading Partner

This information  allows the information to electronically be mailed to your Trading Partner. In addition there are control numbers sent with the EDI Batch Envelope to ensure that the complete information is received by your trading partner (this is similar to gluing the courier envelope shut to ensure that none of your documents are lost in the mail).

The following is a representation of this envelope structure:

Courier Envelope

EDI Batch Envelope

 

Mailing Address

 

Receiver ID

Return Address

Sender ID

 

 

 

Control Number  (not on a Paper Envelope)

Glued Envelope

 

EDI Envelope Trailer

 

Number of Groups Sent

 

 

Control Numbers

 

There are many types of EDI Envelopes but they all contain the same type of information carried on a Paper Envelope. The main piece of additional information kept on an EDI Envelope is a control number. This control number ensures that if the EDI Envelope was lost or somehow  ripped up, that there would be a record of the envelope. The structure of EDI always has checks and balances to ensure that information are not "Lost in the Mail". A further check that EDI uses is a trailer record that keeps a record of the number of documents in the EDI Envelope and the control number (to ensure that all documents sent were received by your trading partner. It's very important that if your company sends out an Invoice that your Trading Partner receives that Invoice or you don't get paid !!!!).

Group Envelope

A group envelope is a method to Group documents together. For example, when a number of business documents are to be couriered together, a clerk will group the Invoices together and then group the Monthly Sales Records together etc. This allows your trading partner to send:

  • Invoices to their internal accounting department and

  • Send Monthly Sales Records to the Sales tracking department.

In EDI, the Electronic Invoices are grouped together and the Electronic Sales Records are grouped together. This allows your trading partner to send:

  • EDI Invoices to their Accounting Application;

  • EDI Electronic Sales Records to their Sales Tracking Application.

Lets review the structure of the Courier Envelope with Invoices vs. the EDI Envelope:

Paper Envelope

EDI Envelope

 

Mailing Address

 

Receiver ID

Return Address

Sender ID

 

 

 

Control Number  (not on a Paper Envelope)

Paper Group Envelope

 

EDI Group Envelope

What documents are in the Envelope

An identifier

 

Your vendors name (just in case the small envelope for the Invoices gets lost)

 

Sender Application ID

Your companies name (just in case main envelope gets separated).

 

Receiver Application  ID

 

Group Control Number

 

 

EDI Group Trailer

 

 

Number of Invoices

 

 

EDI Group Control Number

 

 

EDI Envelope Trailer

 

 

Number of Groups

 

 

EDI Envelope Control Number

 

There are two types of EDI Envelopes but they both contain the same type of information carried on a Paper Envelope. The main piece of additional information kept on an EDI Group Envelope is a control number. This control number ensures that if the EDI Group Envelope was lost or somehow ripped up, that there would be a record of the envelope. The structure of EDI always has checks and balances to ensure that information is not "Lost in the Mail".

Set/Message Structure

A set envelope is just how each Invoice is structured. In our paper example an Invoice has a statement that this is an Invoice, an Invoice number and then the actual invoice. With EDI, the same concepts are kept except that of course there is an extra control number just in case the document is lost or mangled. Let's review the structure of the Envelope now:

Paper Envelope

EDI Envelope (ISA, BG or UNB)

 

Mailing Address

 

Receiver ID

Return Address

Sender ID

 

 

 

Control Number  (not on a Paper Envelope)

Paper Group Envelope

 

EDI Group Envelope (GS or UNG)

What documents are in the Envelope

What is in the EDI Group Envelope

 

Your vendors name (just in case the small envelope for the Invoices gets lost)

Receiver ID

Your companies name (just in case main envelope gets separated).

Sender ID

 

Group Control Number

 

Paper Set Envelope

EDI Set/Message Envelope (ST or UNH)

 

 

Control Number

 

Invoice Beginning Information, (has all of the data on different lines in any format you want)

Invoice Beginning Segment(s) (with data elements in a standardized format)

 

Invoice Detail Information (all free form text)

Invoice Detail Segment(s) (available in standardized format so that your trading partner can import it without re-keying) 
 

Invoice Summary Information (all free form text)

Invoice Summary Segment(s) (all information is available in standardized format.

 

 

EDI Set/Message Trailer (SE or UNT)

 

 

Set Control Number

 

 

Number of Segments in this Set

 

 

EDI Group Trailer (GE or UNE)

 

 

Number of Sets in this Group

 

 

EDI Group Control Number

 

 

EDI Envelope Trailer (ISA, BE or UNZ)

 

 

Number of Groups in this Envelope

 

 

EDI Envelope Control Number

 

Within a Paper Invoice, there is Header, Detail and Summary level information. In an Electronic Invoice, the information is grouped into data elements and these are grouped into Data segments. A data element is just like a piece of the Invoice. The Invoice Date would be one element, the Invoice Number would be another. The elements, which normally go together on a paper document, are also grouped in an EDI Document. For example the Terms of Sale are all grouped on an Invoice as say:

1 % 10 Net 30

Within EDI, Terms of Sale information is grouped into one Segment. This segment contains the same information. The difference is that the information is structured to ensure that a person is not required to translate it.

 

EDI Partnerships

Now that we all know the concept of EDI, lets look at reality. The following is a standard checklist when starting any EDI program. Lets do a quick review of it (if you are EDI experienced or already has been working on this, ignore the checklist and go to EDI  THE EASY WAY):

The following is a generalized list of major points for consideration when undertaking an EDI project:

1. Obtain commitment from all areas of management

Involvement from all impacted departments is essential. Each department should be included in the analysis, testing and implementation to validate the testing and to ensure that the resulting system meets the objectives. I know that you have already obtained this but it is good to emphasize it again.

2. Establish a plan

Develop a work plan, which identifies the tasks required and provides initial time estimates. This plan should also provide a direction of what type of documents you wish to trade.

3. Establish a Project team

The team should establish a responsibility list for each identified task. The deliverables from each task should be defined.  The team should consist of representatives from all affected areas.

4. Establish EDI Business Contacts

These people are essential when working with other companies to ensure that the business needs are met.

5. Establish EDI Technical Contacts

These people will work in concert with the EDI Business Contacts and your Trading Partners to ensure that the stated process flows as expected.

6. Review Internal Systems and Business Procedures

A through current system analysis should be done. The present process that creates the business documents and the flow of the documents should be recorded. The next step is to determine how EDI should be integrated into existing systems.

7. Conduct a Trading Partner Survey

This survey will provide you with a listing of your potential trading partners:

  • EDI Experience and knowledge

  • Network providers

  • Documents traded or planned

  • Degree of integration of EDI into their applications.

This point is critical if possible you want to start your EDI program with a trading partner who has as much as experience as possible with EDI, documents that you are sending and have a commitment to continued working with you in the future. (Its is similar to your first kiss, make sure you aren't kissing a toad.)

8. Decide on EDI Translation Software

If you have chosen TradeLink, this is a fully featured EDI Management System.

9. Review data contained in the documents to be exchanged

A review of the data to be transmitted and received is essential to ensure that integration will proceed normally.

10. Decide on a Network Provider

Suppliers of these services have standard contracts and commercial price lists. The timing of this decision should be made early as it will influence many of the future decisions that you will make. As there are various services available from Network providers it is important to determine what services are to be purchased.

11. Code and Test Interface to in-house systems

The maximum benefit of EDI is derived from integration of information so that information can flow directly in/out of in-house systems without human intervention. TradeLink has many tools to help you with this interface.

12. Implementation of your Translation software

If you have already installed TradeLink, in the next few days you will be configuring it to send and receive data to/from your pilot-trading partner.

13. Implement and test the network connection with the translation software

This process will test the connection to the network provider from the translation software's scripts.

14. Conduct  system testing with the "pilot" Vendor

The purpose of this is to verify the sending and receiving of transmissions from your "pilot" vendor. This allows data to be processed to determine if any changes are necessary. Extensive testing should be done prior to implementation. Most company's conduct parallel testing with EDI and paper documents until they are sure that the information received meets their needs.

15. Decide on a production cutover date

Develop a signoff document that includes all the participants in the project.

16. Implementation

It is recommended that you collect data during the first few months to use to access what savings/costs your company is experiencing. This information  is useful for your management and future trading partners.

17. Post Implementation Review

Review the results after six months to determine if the planned benefits/costs meet the actual benefits/costs.

 

EDI THE EASY WAY

Now that we have looked the theoretical models of EDI, lets look at the way to make it easy:

1. When choosing a pilot-trading partner try to pick one with the following "perfect" profile:

a) experienced in the use of EDI

It is critical to make your job easier to pick a vendor who has gone through the issues of EDI before. EDI is tough enough without having to worry about your trading partner's learning curve.

b) experienced in the documents that you want to trade

Your job becomes much easier if a trading partner has already traded the documents that you want to trade.

c) a trading partner that you will "do business with" in the future

EDI is a long term relationship, do not pick trading partners that you do not have a long-term relationship with or will be "doing business with" in the future. Try to get a firm commitment from management on both sides (you and your trading partner) to do this pilot. Your trading partner's technical contact may have many priorities, it is important to have commitment from management if it is required to solve "issues" in the future.

d) a trading partner who is willing to work with you on the EDI pilot and realize that you are just starting out

This may sound silly but it is important to realize that the "pilot" process will have issues that you didn't anticipate. Be honest with your trading partner about your expertise. In most cases your lack of experience will work in your favor as your trading partner will give you the benefit of the doubt.

e) use the same Network Provider that you use

It is easiest to track "lost" transactions to go through the same network. It's not critical, but it will help in case of problems.

The bottom line is to try to get as "perfect" a vendor as possible. It is all trade-offs. Experience has taught the KISS (Keep It Simple Stupid) is critical.

 

2. Don't re-invent the wheel.

When you are deciding on what data to send and receive, use existing sources. If you have been mandated by a major customer to do EDI, 9 times out of 10 they are going to give you their implementation guide. Depending on your relationship with that partner you may or may not change the information exchanged. If you are controlling what is to be sent, Do Not Re-Invent the Wheel. The best implementations of EDI have used existing implementation guidelines and slightly modified them for their use. If in your industry most people use one standard and follow an implementation guideline use it. If you don't you may force your poor trading  partner to create a new interface just for you. If you want to find implementation guidelines, try your trading partners, contact local EDI Users groups, the ANSI X12 committee have published guidelines their numbering the United States  is 1-800-334-4912 or Internationally 1 - 216 - 974 - 7650. In addition if you belong to industry groups they may have implementation guidelines.

3. Decide on your Network ID's and Mailbox numbers as soon as possible.

Make sure that your Network communications set-ups are understood. If you do not understand the network requirements ask the network to explain it to you. There is no shame in asking the experts.

4. Once you have implemented your "pilot" transaction, decide if you want to horizontally integrate or vertically integrate EDI.

When you horizontally integrate EDI, you add documents with a limited number of pilot vendors. In vertical integration you are trying to expand the use of one or two "key" documents. If one customer is 90 % of your business it would be advantageous to add as many documents as you can with that customer. If you have a multitude of partners, the advantage swings to integrating a few documents with a lot of partners.

5. 80/20 Rule

As a rule of thumb in business 80 % of your business is done with 20 % of your customers. Try to focus in on the big win for your business.

6. Never Argue or Complain and ALWAYS document.

As EDI is cross organizational, you will have the occasional problems, always consult the experts, know what the problem, document it and keep everyone informed. If you have a network problem, call the network first and explain in a rational way what the problem is and what you know. If you know nothing, explain that, people will always help you out if they feel you are trying. No one has ever solved a problem by arguing !

7. EDI is not rocket science.

As you go through the process, you will find that once you have a little experience in EDI, the problems will become routine. At one major retailer, they found that the first trading partner  of a pilot takes up to 10 times longer than subsequent vendors. It will get easier. It is very important to learn the basics and then EDI becomes a snap.

 

For more information about SoftCare, TradeLink EDI Management System,
and the SoftCare Solutions Group please contact us at:

Web: www.softcare.com

Tel : 1-888-SoftCare   (604) 983-8083

email: info@softcare.com

 

 

 
 

 

Customer Case Studies

Retailer

    London Drugs

Manufacturing

    Listo Products

    Premium Brands

    Howell Metals

    Whitney Design

    Accent Home Products

Distribution

    Bartle & Gibson

 

Logistics

    Tennessee Commercial
        Warehouse

Healthcare

    Employers Direct Health

Financial Services

    Credit Union Central of
    British Columbia

Public Utilities

    BC Hydro

 

Glossary of Terms:

* EDI - Electronic Data Interchange. The transfer of "standardized" data between Trading Partners.

* EDI Envelope (Interchange Batch). An EDI Envelope consists of EDI documents (commonly refereed to as either Transaction sets or Messages) grouped together. The EDI Envelope contains information used to identify the sender and receiver of the transmission as well as control numbers and other information required to audit the transfer of information between the sender and receiver.

* Functional Group. This is a sub-set of the EDI Envelope. It was designed to cause related transaction sets (i.e. All Invoices) to be bundled together for transmission.

* Segment - is a group of related data elements.

* Transaction Set - is a standard coded representation of a single business document (in UN/EDIFACT this is called a Message).

* Element - is a single piece of information (i.e. a Purchase Order Number).

* Trading Partner - is simply an entity that you do business with.

* VAN - Value Added Network. Typically a Valued Added Network is used to store messages to and from you to your trading partner (In TradeLink you typically use Communications Scripts to send/receive to/from the VAN).

A VAN : 

  • Allows you to send a receive documents according to your own schedule, without worrying about when you should dial into a Trading Partners computer.

  • Allows you to dial a local number rather than long distance (since most VAN have local numbers in larger cities).

  • Provides built-in security since a Trading Partner never has direct access to your computer system.

  • Provides for activity and audit log reports.

 

Committees

TDCC - Transportation Industries Committee. This is the first formalized EDI standard.

WINS - Warehouse Industry Committee.

UCS - Grocery Industry Committee. It is interesting to note that the TDCC, WINS and UCS standard even developed their own EDI envelope standard different from the ASC.

ANSI X12 cross industry group. Although they have all amalgamated into one standard there are many Translators and applications that are still geared to only accepting this standard only. As luck would have it you can chose TradeLink which can accept and create all major EDI Envelope standards.

VICS - Retail Industry Sub-Committee. This sub-committee tries to develop a sub-set of the EDI standards for implementation within the Retail industry. This committee was developed to work within the Cross Industry standard (ASC ANSI X12) and create implementation sub-set for the retail industry. This type of sub-committee has become much more prevalent as EDI has matured. This type of sub-committee has also been started in the Metals, Chemicals, Automotive and various industries.

ASC ANSI X12

Amalgamation of committees occurred under the umbrella of ASC ANSI X12. This group is used to be the keeper of the standard (within North America). There is a move towards amalgamation with UN/EDIFACT but that it still a ways away. It is very important to remember that although all of the committees are now under ANSI X12, there are thousands of companies, which are still using old standards. The main reason for the use of the old standards is that an official version change may not add anything functionality that a company needs. Why change the standard (and possibly all of your trading partner's files) when there is no benefit for them? Companies wrote their applications based on the old standards and didn't see the need to make changes. 

UN/EDIFACT

UN/EDIFACT is an EDI Standard created in the late 1980's to standardize EDI in the rest of the world. Although the format is different, the concept of a standardized set of files is the same.  This committee has had less "empire building" so that there are only 40 transactions defined for it. The governments of Canada and US have started the use of this standard (in particular for customs documents).

 

EDI Software

EDI Software can be broken down into two basic categories:

Simple EDI Translators which validate EDI Mailbags received from external trading partners, separate the Mailbag into individual business documents and exported in the translators format as a flat file. For outbound documents, a flat file is validated by the translator, combined into appropriate EDI Mailbags for each trading partner. Simple translators may or may not contain integrated communications software or mapping tools to integrate the movement of business documents into a company’s back-end applications.

Full featured business document brokers which centrally manages Multi-Enterprise (B2B) interactions between a company and its external business partners. They are used to consolidate and centralize data, and business processes used to translate, validate, integrate, and exchange business documents within an organizations trading community no matter what the format.

For more information, click here.

 

EDI Communications

"I would like to move all of our EDI business documents, which represent 90% of our business, from our reliable EDI VAN for communications to communicating these business documents using the Internet?" In 1999, if an MIS Director had gone to his executive with such a proposal, he would have been laughed at or more likely fired. In the year 2007, many large EDI Hubs such as Wal-Mart, Hyundai, Covisint, GMAC Lowes, Meijers, Michaels, Food Lion, Kohls, Winn-Dixie etc. have switched from VAN communications to using the Internet for the transmission of business critical documents. "Internet EDI transaction volume has been increasing steadily during the past six quarters at a 50%-60% growth rate," said Carl Lehmann, vice president of technology research services at META Group.

For more information, click here.

 

EDI Integration

SoftCare’s uses a methodology for document integration that has been designed based on hundreds of EDI implementations over the past 18 years. The steps include:

Step One – Define and Register Source, Target and Cross Reference File Formats required for the integration.

Step Two – Create and register the XSLT Transformations which convert the source file to the appropriate target file format.

Step Three – Create and Test Conversions (Maps). This step defines where the source files reside, where the target file should be placed and which transformation(s) should be executed to complete the conversion of source files to target files. Once created and registered, the conversions are tested prior to being implemented in a production environment.

Step Four – Register the conversion as a task within a business process and schedule the automatic processing of the business process.

For a detailed presentation on EDI integration, click here.

 

Why Web Services for Integration


Business customers today have more choices than ever. Using new technologies such as the Internet, they can research, negotiate, and switch suppliers from anywhere in the world in an instant. As a result, businesses must continuously anticipate customer needs and provide solutions to quickly seize new opportunities. Companies need a comprehensive understanding of the market needs as well as their business processes drive sales, product delivery, and ultimately customer service.

For more information, click here.

 

Why Service-Oriented Architecture (SOA)?


Organizations that can combine its IT applications with their business goals will achieve a competitive advantage in the marketplace. Using a Service Oriented Architecture (SOA) through open standards allows an organization to achieve this by driving compatibility across the application infrastructure.

For more information, click here.

 

 

INDUSTRY LINKS

 

EDI Standards - Data Interchange Standards Association

 

OASIS e-Business Standards

 

XML and Web Services Standards

 

ebXML - The Electronic Business XML Standard

 

US DOD Federal Government e- Business and EDI Standards

 

HIPAA - Healthcare Industry Standard

 

HL7 - Healthcare Industry Standard

 

NACHA - The Electronic Payments Association

 

ANSI X9B Sub-Committee of Financial Industry Standards

 

Canadian Payment Association

 

UCCNET - Retail Supply Chain e- business standards

 

EPC Global RFID Electonic Product Code (EPS)Standards

 

 
 
Home       Products       Solutions       Contact Us  
© SoftCare EC Solutions Inc 1989-2012