Six EDI Hassles You Never Have to Face Again

Six EDI Hassles You Never Have to Face Again

By Howard W. Sabrin, executive vice president.

I recently got off a one hour call with an EDI (electronic data interchange) veteran, discussing his experiences with the venerable data sharing format.

EDI has been around since the ‘60s, and for some purposes it’s absolutely the way to go. But hearing the questions this EDI user asked made me realize how much extra work EDI customers are doing, especially if all they need to do is share relational databases. Folks who’ve been using EDI for years may not realize how much of the work that costs extra time and dollars in EDI is handled automatically by relational databases.

Here are six quick examples of EDI hassles you can avoid, without damage to your business, through direct database sharing.

  1. Converting data to a standardized EDI form on the sending end, and converting it back to a form the recipient’s systems can use. If you’re sharing relational databases, all both sides need to do is agree on a common database design (e.g. tables, columns, data types). Since all work is done within the database, there’s no need to get network, security, firewall, or software development staff involved. If any data must be pre- or post-processed, it can be done using standard database tools by your database staff.
  2. Avoiding duplicate entries and other data integrity issues. Database transaction processing capabilities prevents data from being written unless it can be written without error and repeat data writes until they are successful. Each data entry is tagged with a unique identifier set, preventing the same data from being entered repeatedly. No further coding or other work with specific EDI formats is required.
  3. Creating an audit trail to assure no loss or corruption of data. Using familiar database queries, the source and destination data can easily be compared to the last byte to assure integrity. Unlike EDI systems where transactions must be tracked through multiple components, the results of these simple queries serve as your audit trail.
  4. Integration with ERP and CRM systems. Since many of these systems are built on relational databases, business data from one partner’s database platform can be transferred directly and securely over the Web to another partner’s database. No integration or reformatting of data to match specific EDI formats work is required.
  5. Agreeing on, and implementing, common security protocols. DataPortal uses secure Web protocols (e.g. HTTPS) and has layers of password protection for access control. You therefore avoid the work and complexity of implementing other secure network protocols and coordinating with multiple network and security staffs.
  6. Arranging notifications of data arrival. In EDI systems. data can arrive in multiple ways and the receiving system must be notified so the data can be processed. With direct database transfer the data is sent directly to the destination system with no processing required. If notifications are required for some reason, they can be executed with a simple database trigger.

If your trading partner requires you to use EDI, you obviously have no choice but to continue using it. But if database transfer would work as well – or if you’re beginning to share data with a trading partner – consider whether direct database sharing might be far easier, faster and less expensive for you both. Our own Data Portal software provides a secure, point and click solution for database sharing over the Web. Learn more about Data Portal’s benefits compared with EDI, learn more about Data Portal or see how easy DataPortal is to use.

*image courtesy of zine.starkcrew.com

Comments are closed.