M3 Business Engine Administrator's Guide for Transportation Execution Interface (TEI)

Purpose

The purpose of the M3 Transportation Execution Interface (TEI) is to enable an interface where transportation and customs information can be exchanged with third-party best-of-breed applications or external partners using B2B messaging.

The reasons for using a Transportation Execution Systems vary, but are normally caused by variability or high volumes in one or more of the areas above. In some cases, the focus is on outbound logistics while other companies encounter variability and high volumes for inbound logistics. Requirements for customs declarations are stipulated by suppliers or customers in countries and trade unions that require customs procedures.

A Transportation Execution Systems can be provided as a standalone product or can be included as one part of a Transportation Management System (TMS). A Transportation Management System covers a wider scope than a Transportation Execution Systems. The following table describes a Transportation Management System.

Audience

This document provides general tips and advice. The primary target group is Infor consultants and customer "super users". Some M3 experience and knowledge is important to fully understand the concepts in this document.

Limitations

These listed items are known limitations:

• Currently, there is no support to receive information in 'TEI Transfer. Open' (MYS500) with Message direction I=Input.
• No package information can be downloaded for inbound logistics. The requirement is limited and not analyzed in detail. The limitation currently is based on the assumption that package information is more useful for outbound logistics. Inbound transports are normally produced by the counterpart, the external supplier in this case.
• Transaction type 30, Customer returns, is not supported currently regarding inbound logistics.
• Using the event RELEASE_PICK is only applicable for dispatch policies with Auto level 3 (Issue made automatically when picking list reported).
• Manual creation of TEI transfers in 'TEI Transfer. Open' (MYS500) is only applicable for TEI transfers with connection to an event.
• When using a report version to create one or several TEI transfers from 'TEI Transfer. Manually Create' (MYS510) only detail levels of delivery number (outbound or inbound DO) or purchase order line (inbound) can be used. The reason for this limitation is that the manual triggering functionality aims to group deliveries or purchase order lines into groups based on a number of selection criteria. This means that it is not possible to create a TEI transfer from a report version with detail level of package number.
• Note: The parameters in Closing point and Packing reporting method fields for the dispatch policy control when some events will be triggered.
• Some of the events can be triggered multiple times which can result in sending several TEI transfer including the same information. To avoid this, use the parameter Allow duplicate details = 0 in 'TEI Partner. Open' (MYS015). This gives the result that the event is triggered and a TEI transfer is created but details that already exists on another TEI transfer will not be connected to the new TEI transfer. An example can be the event SHIPMENT_CLOSED. Since the shipment can be closed and reopened several times the event is triggered every time the shipment is closed. But if the parameter Allow duplicate details = 0, a delivery that already has been created on a TEI transfer with the same detail type (1=Delivery) will not be created on the second TEI transfer created.

Introduction to Transportation Management Systems

Transportation Management System consisting of Transportation Planning Systems, Transportation Execution Systems, and a Transportation Reconciliation Systems. Each area is divided into the functional content included. The Transportation Execution Systems is put into a wider perspective:

Scenarios for using TEI

The major ERP systems on the market do not normally provide the depth of functionality as the Transportation Execution Systems do. To do so, the ERP vendors need to invest time and knowledge in a wide variety of market requirements. This situation leads us to the reasons to invest in ERP and Transportation Execution Systems integration. The information to exchange between M3 and the Transportation Execution Systems is related to transactional information that is exchanged in the latter part of the supply chain execution process. The Transportation Execution Systems should normally not have the possibility to reschedule orders, shipments, or deliveries. Planning capabilities are related to strategic or operative planning as described earlier. The initial integration point is established after the proactive shipment and delivery planning is finalized in M3. The final point of integration is placed when all documentation required for a physical delivery is produced. Integration capabilities related to post-processing is not a part of the TEI interface.

The figure displays business transactions that can be exchanged between M3 and a Transportation Execution Systems. The transactions in italics (upload) are currently not included in TEI solution.

For more detailed information on the available inbound and outbound logistics, refer to Scenarios for Using M3 Transportation Execution Interface.

Business requirements and solutions

The primary goal of M3 TEI is to offer M3 customers the possibility to use third-party Transportation Execution Systems (TES) that manage the following:

• Transportation documents
  • Label documents
  • Freight documents
  • Customs documents
• Hauler integration
  • Freight booking and response
  • Electronic freight documents
  • Transportation process monitoring
• Customs integration
  • Export and import declarations and response
  • Bonded warehouses
• Track & Trace
  • Shipment and delivery tracking
  • Parcel tracking

For more details and configuration recommendations, refer to Business Requirements and Solutions for M3 Transportation Execution Interface.

TEI architecture

The current solution is push-oriented, which means that the information is created within M3 and can be processed, viewed, and changed before it is sent to the external system. This solution enables a flexible, pull-oriented information flow of transportation information together with Infor Enterprise Collaborator (IEC). This means that the integration is more flexible and the data sent to a TEI system will be pulled from M3 via IEC by using M3 APIs.

The following figure illustrates the entire functionality.

For more details, refer to Overview of TEI Architecture.

TEI Transfer triggers

The current solution offers the following TEI Transfer Triggers:

• Settings for Automatic Triggering of TEI Transfer
• Automatic Triggering of TEI Transfer
• Manual Triggering of TEI Transfer per Function

For more details on Transfer Trigger settings, refer to M3 TEI Transfer Triggers.

API overview for the TEI solution

The following figure illustrates the most common APIs involved when TEI is implemented.

The different API transactions available for the Transportation Execution Interface (TEI) are described in detail in this document: API Overview of M3 Transportation Execution Interface

For detailed description about M3 Interface programs and their transactions, refer to the API Repository in (MRS001), (MRS002), and (MRS003).

M3 BE 15.1 Java

The following program flow charts illustrate the main functions, functional components, and tables involved when performing any of the four workflows.

The first two flow charts details the master data functions and their relations. The third flow chart describes workflow that involves transaction management.

Master data program flow – TEI Trigger Control

Master data program flow – TEI Output Control

Transactional program data flow

Data model

The data model contains key fields to describe the key relationships for basic understanding.