Inbound EDI Route

Inbound EDI Routes identify inbound EDI documents and match them up to a Business Process that performs some type of integration activity.

Inbound EDI documents adhere to widely accepted standards, which allows them to be handled in a uniform, predictable fashion. They have standard "envelope" information that indicates who the document has come from and to whom it is intended (similar in concept to mail handled by the US Postal Service). Because the envelope information has been standardized, the CIC Studio can examine the envelope, determine who it is from, what kind of document is within, and direct it to one or more Business Processes that handle the integration activity.

Inbound EDI Routes associate an EDI document's "envelope" information with a corresponding Business Process. When an EDI document is received, the Studio will parse the EDI envelope segments, search the Inbound EDI Routes for one or more that match the envelope information, and then call all the Business Processes that are attached to the Inbound EDI Route.

Additionally, you can respond to your trading partner's EDI document with an Acknowledgement that you have received their document that is (or isn't) acceptable to you. An Acknowledgement is a separate EDI document (997) that is returned to the trading partner that originally sent you the EDI document.
You configure to whom the Acknowledgement is sent, and the information contained within the Inbound EDI Route editor.

Business Use

Consider this scenario: 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 the following:

• the source of the document (sender)
• the type of document
• the specific Business Process to process it

If you need to onboard a new trading partner who also wants to send purchase orders, you still need to identify who the purchase order came from, but you can leverage an existing process 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.

A trading partner may dictate special business practices. For efficiency purposes, you may want 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 the above scenarios can be managed using Inbound EDI Routes.

How the Object Works

Inbound EDI Routes are used as part of the EDI processing in the Cleo Integration Cloud (CIC). The Studio examines and identifies the envelope sections of the EDI document. After the envelope information has been successfully examined,  the Studio then 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, and provided to you. What ultimately happens to the document (the integration into your back-end systems), is provided by you.

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

The EDI envelope information used 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), a Business Process is executed for each business document (ST) in the document. For example, suppose your trading partner sends to you an EDI document with 5 purchase orders in it. CIC will discover the presence of 5 purchase orders. For each purchase order document, it 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.

Functional Acknowledgements: Additionally, you may also configure the object to generate an EDI Acknowledgement to your trading partner. Acknowledgements are considered "good EDI form" and are usually mandated by you and the trading partner. When the Studio 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 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

To use this object, you must:

• Create the object.
• Define the object by setting up back-end integration details.

Inbound EDI Routes are used when CIC receives inbound EDI (X12/EDIFACT/TRADACOMS) documents.