The primary reasons for EDI “enveloping” are to manage EDI Interchange routing, and to enable your EDI system know how to process inbound transmissions (this also applies to the enveloping data you send to your trading partners). Your EDI software needs to know where a transaction (message) begins and ends. It also needs to determine which trading partner transmitted the data and what type of transactions were received, for example, Purchase Orders or Invoices.
When transmitting EDI data to trading partners, it is necessary to “wrap” the individual transactions using “envelopes”. There are various envelope types and each representing different levels. Each “envelope” has one beginning and one ending segment that carries certain control information. Continue reading
For this discussion, a “Staging Database” refers to any intermediate database that would fill the gap between Electronic Data Interchange (EDI) transactions and the backend business application. Whether obtained through a third party or developed in-house, some applications provide interface files that are “EDI Intelligent” and support the required EDI transactions. For applications that do not, the Staging Database should be considered for the following reasons and with the following purposes:
Data Grouping/Restructuring: Spreadsheet-type (SDQ) orders, where a single purchase order describes multiple ship-to destinations, might not be supported in the application because many applications define an order as a single ship-to destination. In this case, the single spreadsheet order needs to be broken down into separate orders by ship-to destination prior to insertion into the application. A multi-line order could have the same ship-to destination repeated several times. Therefore, data grouping would be required for later reorganization of all lines (for each ship-to) and transforming into a single order within the application.
The Staging Database would provide sorting/grouping functionality to support such reorganization. For example, an order with two lines, each having three SDQ pairs (defines the “ship-to location” and “quantity” breakdowns), and where one location is repeated on both lines, might result in six orders instead of five without such grouping.
The problem: Often, EDI data elements of the same type may occur multiple times. One common example is “Dates”. The number of Dates needed (or sent) is generally limited [only] to the number of Dates required by the business application of the party who “calls the shots”. If the customer expects to retain a trading partner’s business, they will make every attempt to comply with that trading partner’s requirements. The trading partner might send the supplier Dates such as “Scheduled Shipment Date”, “Expected Delivery Date”, “Cancel Date”, or a host of other possible dates. The same is true for Reference Numbers, Notes/Comments, Product Item Numbers, Addresses, and so on…they all represent EDI data that could be sent in abundance. The question is, “what is the most efficient way to configure the EDI system to accommodate these repeating (and sometimes redundant) pieces of data?” Continue reading
It is often a common practice of organizations to develop new EDI trading partners and transaction sets from within the same environment where production EDI trading partners and transaction sets already exist.
While this is possible, it can often be disruptive and dangerous as the results of test and modifications could inadvertently result in problems with production data.
Employing multiple EDI environments will make it possible for a single EDI translator to have access to (and use) two or more “EDI configuration areas”; for example, to separate all production configurations and data from development (or production division 1 from production division 2). Continue reading
Recently, I was having dinner with some old friends and the conversation centered on our respective fields that we work in. When the conversation turned to me, I chatted up how I worked in commercial software, particularly the Integration space. I received some curious looks, like my friends were trying to get a grasp on what I was talking about. Then it hit me….What does Integration mean to someone unfamiliar with the discipline? Why does it matter? What are the benefits, and the risks? How much of a problem is this? So, I decided to write a blog, from my perspective, on why Integration is important.
First, let’s think about the meta-types of challenges that businesses face today. Two flavors emerge quickly; problems of the moment (tactical) and visions of where they want to go (strategic). Continue reading