Many Business-to-Business (B2B) relationships choose to initiate transaction exchanges at the point a buyer sends an electronic purchase order to a supplier. This Purchase Order is often in the form of an EDI 850 document. This Purchase Order often then triggers the supplier to send the buyer an electronic Invoice (EDI 810) and an electronic Ship Notice (EDI 856), for the goods ordered. This “business process” represents the minimum number of transactions required to maintain this successful model. Moreover, there exists an abundance of data in support of this process, although it may often fail to be included in the production model. The cost of integration may exceed the return and, as a result, this data either isn’t shared between the two organizations or it fails to be integrated to a usable state.
For example, at the suppliers’ front end is Catalog data (EDI 832). This provides an opportunity for a supplier to identify the attributes of their products to the buyer, creating a more-efficient ordering process. At the buyers’ backend is Product Activity / Point of Sale data (EDI 852). This provides an opportunity for buyers to report their sales activity, aiding in the ability to forecast the production of goods. While this data is not essential to the “Purchase Order <-> Invoice” model, it provides the ability to “enhance” production processes. Additional transactions, such as Purchase Order Acknowledgment (EDI 855), Purchase Order Change (EDI 860), and Payment Advice (EDI 820), are a few of the many electronic formats capable of improving and furthering the overall business process integration. Continue reading →
The Healthcare industry is being mandated by the Government and HIPAA legislation to convert from X12 version 4010 to version 5010. Most companies aren’t being mandated by the government to switch versions, but by their strongly influential Trading Partners.
I think back to the late nineties when version 4010 came out and what a struggle it was for many Trading Partners to convert to that version. Most EDI Coordinators are fearful of those same struggles when going from 4010 to 5010 or any other version. Converting from one version to another version doesn’t have to be a major headache.
There are two main areas of consideration during your Version Conversion project: translation support and application support. Continue reading →
While considering enhancements for the next version of EXTOL’s AS2 product a while ago, I was presented with what I initially thought was a curious, if not paranoid, enhancement request: a customer wanted to be able to restrict outgoing traffic to specific ports.
My first question was: “Why bother?” Indeed, the vast majority of our customers had no restrictions on their outgoing source, or egress, ports and the concern of network administrators has traditionally been on restricting who and what can come into the network from outside. While the threat from viruses, worms, denial-of-service attacks targeted at a company’s internet infrastructure from the outside is obvious, the perils from inside the network are not so readily apparent. Nevertheless, they are worthy of a security conscious IT professional’s close consideration.
So what can a company gain by restricting the traffic over its egress ports? Continue reading →
Enterprise Service Busses (ESBs) offer an interesting communications layer that enables an enterprise to expose data to interested parties (i.e. applications, data-feeds, etc.) with a Publish/Subscribe model. The Pub/Sub model originated in the printed media world, utilized as a distribution model for newspapers and magazines. It has evolved with modern times into the electronic age in the form of email-subscribed newsletters, and more recently, RSS feeds such as blogs.
In the enterprise, there is a growing need to share data among systems, both internally (A2A) and externally (B2B). However, as new demands for sharing data surface, we need a way to “bolt in” the new requestors without impacting our current implementations.
ESBs commonly implement a variant of the GoF Observer Pattern. This exposes a Publication/Subscription model allowing information sources (publisher) to expose data (message) on a queue. One or more interested parties (subscriber) consume the data. The key benefit of loose coupling in a Publication/Subscription model is that the Publisher does not need to know, or care, about “who” is subscribing. The data is published and downstream subscribers use the data as they see fit.
For my inaugural post on this blog, I want to revisit one of those “solved problems” that still dogs many of the companies we talk with, namely, how to handle B2B integration requirements that don’t involve standard EDI. Companies still find it difficult to cope with the full range of B2B connections and content types needed to integrate with large and small trading partners, including:
Standard EDI (and in some cases, EDI that does not fully conform to standards)
“Standard” XML, which ranges from well-developed, horizontal standards like RosettaNet to hundreds of loosely-defined vertical transaction sets
EDI-like flat file standards (most of these are older, vertically-focused cases)
EDI-based web forms
Proprietary, partner-defined flat files
Proprietary, partner-defined spreadsheets
Proprietary, partner-defined web portals
Proprietary, partner-defined documents sent by email or fax
Did I miss any? Probably. But the point is that standard EDI is just one of numerous conventions used for B2B integration. Of course, standard X12 and EDIFACT EDI are still the mainstay of B2B integration. And there is little evidence to suggest that companies are ready to invest in replacing all of their EDI connections with something “better”. In fact, EDI adoption is increasing.