Inbound EDI Route

Business Use

Suppose you have 2 trading partners. One trading partner sends invoices in X12 format. The other trading partner sends purchase orders in X12 format. These are different business documents and most likely they will be integrated differently into your back-end systems. You will want to ensure that when the documents are received they are handled appropriately: 1) the invoice will be handled by a process that knows how to deal with invoices; 2) the purchase order will be handled by a process that knows how to deal with purchase orders.

In order to associate your business documents with your business processes, you will use an Inbound EDI Route. It identifies who the document comes from, what kind of document it is, and what business process should handle it.

Now suppose your company grows and you need to bring on another trading partner who also wants to send purchase orders to you. You still need to identify who the purchase order came from, but you'll want to leverage your established processes for handling purchase orders. Typically, processes don't change based on who the document comes from; they simply become just another trading partner that follows your normal purchase order process. In this case, you will still need to create an Inbound EDI Route, but you can leverage your previously developed processes. You don't have to create a new business process for each trading partner.

You may also experience a situation where a new trading partner dictates special business practices in order to accommodate their business. For efficiency purposes, you may want to treat the new practices as an exception to your standard processes. You need to have the flexibility to preserve your standard processes while handling your new trading partner as an exception. In this case, you need to be able to identify documents from the trading partner and route them to the partner's special process.

All of these situations can be handled easily within Clarify using Inbound EDI Routes.

How the Object Works

Inbound EDI Routes are used as part of the EDI processing in Clarify. Since X12, EDIFACT, and TRADACOMS documents are supported by large governing bodies and have been broadly accepted, it is possible for Clarify to handle much of the tedious parsing and processing commonly associated with these documents. The processes for examining and identifying the envelope sections of the EDI document are supplied by Clarify. After Clarify has successfully examined the envelope information, it begins to look at the configuration you supply to direct the integration activity for a document. The work of identifying the parts of an EDI document are routine and automatable, so Clarify provides that for you. What ultimately happens to the document (the integration into your back-end systems), is provided by you.

The first step is for Clarify to search Inbound EDI Routes that match the information in the EDI envelope. When a match is found, Clarify will execute the Business Process associated with the Inbound EDI Route. If a match is not found, you can optionally configure Clarify to send alerts to your EDI staff/coordinators that a document was received from an unknown trading partner.

The EDI envelope information Clarify uses to search Inbound EDI Routes exists in the following segments (for X12: ISA, GS, ST; for EDIFACT:UNA/UNB,UNG, UNH; for TRADACOMS: STX and MHD). These segments identify who the document is from (your trading partner), who it is going to (typically you), and what kind of document it is (invoice, purchase order, etc.).

Since an EDI document can consist of one set of envelope segments (ISA and GS) and multiple sets of business document segments (ST), Clarify executes a business process for each business document (ST) in the EDI document. For example, suppose your trading partner sends to you an EDI document with 5 purchase orders in it. Clarify will discover the presence of 5 purchase orders. For each purchase order document, Clarify will search the Inbound EDI Routes for matches. When a match is found, a business process is executed for each business document - 5 times in this case. This allows each purchase order to be treated as a single, solitary document that needs to be integrated to your back-end systems.

Additionally, you may direct Clarify to send an EDI Acknowledgement to your trading partner. Acknowledgements are considered "good EDI form" and are usually mandated by you and your trading partner. When Clarify processes an inbound EDI document, it will validate the document against the specific standards. The amount of compliance (or non-compliance) is communicated back to your trading partner inside the Acknowledgement EDI document. You can configure how much information is returned. Non-compliance (or errors) may occur at various levels - within the envelope segments or within the business document. The types of errors can be data errors (length, data type, missing, required, etc.) or they can be structural (for example, order details appear in the document before the "header" information). These errors can be reported back to the trading partner in the Acknowledgement. These validation errors can also prohibit the document from being integrated into your systems. However, the Acknowledgement configuration is flexible enough for you to ignore certain errors and allow the document to be processed.

Inbound EDI Routes are used in the context of the overall inbound Clarify function. They provide the vital link between an EDI document received from your trading partner and the integration activity you require for the document to be integrated into your back-end systems. Inbound EDI Routes do not technically "do" anything. However, they are used to identify EDI documents and to connect them to the business processes that operate on them.

Process Summary

Clarify will use the Inbound EDI Route when an inbound EDI (X12/EDIFACT/TRADACOMS) document is received.