EDI Requirements

I am currently working on an EDI project with one of our clients. A few clients have asked about EDI capabilities in the past. So, I have invested some time and development in this area--which put me in a good position to help on this current project.

First of all, many people may not realize that EDI is an abbreviation for "Electronic Data Interchange". That's a pretty generic term. However, more recently, it is generally used to refer to the exchange of order, pricing, and shipping information between trading partners. More specifically, most implementations focus on the ASC (Acredited Standards Committee) X12 Standard.

See www.x12.org for more information

Furthermore, when people refer to EDI services, they are referring to technical services and Value Added Networks, such as PubNet, that act as message services between trading partners. A buyer may place a purchase order in your PubNet mailbox for you to retrieve and respond to with an acknowledgement transaction. Some major buyers are insisting that you must subscribe to an approved EDI service before they will do business with you.

The problem I see with all of these EDI services is that they really don't add much value for the price they charge for their service. Sure, they may be a foot in the door with some major buyers, but what they offer seems to be little more than a glorified mailbox. They do nothing to help get information into or out of your accounting system.

Enter Publishers' Assistant...

Needless to say, these issues can be a daunting prospect for independent publishers and distributors. We would like to help publishers take the mystery out of this requirement and make it easy to exchange EDI transactions with your trading partners.

In this current project, we are working on EDI requirements from Books-A-Million. We are focused on the following transaction from the X12 standard:

  1. 850 transaction - A purchase order
  2. 855 transaction - a purchase order acknowledgement
  3. 810 transaction - an invoice
  4. 977 transaction - a general acknowledgement (Work on this transaction has been tabled.)

The implementation is focused in Couplet. Couplet is our Import and Export tool for Publishers' Assistant. Handling EDI transactions is just another variation of importing and exporting data.

Status

As of this writing, support for the 850 (P.O.) transaction has been added to the Invoice Import Wizard. The Purchase Order is imported as a PubAssist customer order. Just like importing orders from other sources--like your web site--the imported order is placed on hold until a person can review it, check the pricing, and make any changes that are appropriate. This is all done in PubAssist like editing any other customer order.

Support for the 855, and 810 transactions have been added to the Invoice Export Wizard. This wizard will export selected customer orders in a variety of formats--including the 855 and 810 transactions. Once an 850 transaction has been imported and reviewed, this wizard can be used to export the 855 transaction to notify your buyer and acknowledge the order details. After the order has been shipped, the 810 transaction can be exported to invoice the buyer.

The Invoice Import and Export Wizards have been added to Couplet. The new version of Couplet will most likely be released with PubAssist Version 5.0b.

Phase 2 -- Web Service Deployment

With the current implementation, the PubAssist user has to check either their email, or an ftp site, for the existence of new EDI transactions. Once we have confidence in these EDI import and export routines, the plan is to make them available through PAWeb Services. That means that your buyers can make an HTTP request to your web service--something they can automate. Your web site can then automatically respond to their Purchase Order request.

I mention above that the 970 acknowledgement transaction has been postponed. That's because it doesn't make much sense in the manual scenario described above. By the time you've taken the trouble to import an 850 transaction, you might as well generate the 855 acknowledgement right away.

However, in this automated setting, it makes sense to provide a general acknowledgement (the 970 transaction) immediately and automatically. Then when you download and review these EDI orders, along with all of your other web orders, you can generate the detailed 855 acknowledgement through Couplet.

Discussion

Phase 2 is still in the proposal stage; but I stress once again, this is a service that will become part of PAWeb Services--which includes an e-commerce solution (an online shopping cart and payment processing). If you're in publishing, you undoubtedly already have a web site. So, once again, this offering presents the possibility of accepting and responding to EDI transactions, without having to pay for a third-party EDI service. What's more, this service adds real value by moving data into and out of your Publishers' Assistant database.

As with other development efforts, I know there are Pub`Assist users that have a need for these services. It's difficult for most of our users to shoulder the development costs on their own. If you are interested in these services, I hope you will add your thoughts to the discussion pages for this article. And, if you are able, investing in this development will insure that your needs are prioritized.


Back to UserForum

EDI (last edited 2010-01-20 19:43:47 by 150)