Overview of TEI Architecture

Introduction

This document provides a detailed information about the current architecture of the M3 Transportation Execution Interface (TEI) solution.

TEI functionality

This figure illustrates the entire TEI functionality.

The M3 TEI 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 list provides a brief explanation of the events in the M3 TEI solution.

• Event triggers

  One way to trigger the creation of a TEI transfer is to use a predefined event. When this event occurs, the TEI transfer document can be triggered. Examples of events are the printing of a picking list or the issue of a delivery.

• Manual trigger per function

  Another way to trigger the creation of a TEI transfer is to use the manual triggering that is added in some functions. By selecting option 53 from 'Delivery. Open Toolbox' (MWS410) or 'Shipment. Open Toolbox' (DRS100), you can create a TEI transfer including delivery information. From 'Delivery. Connect Packages' (MWS423), you can select option '53' to trigger a TEI transfer including package information.

• Manual trigger per selected group – (MYS510)

  The third way to create a TEI transfer is to do a manual selection in a report version and let the system create one or more transfers from the selection. When creating a TEI transfer for an outbound transaction, selection objects from shipment and delivery are used. For an inbound transaction, selection objects from either the delivery (DO) or the purchase order or purchase order line are used.

• Event-based document control

  Event-based document control (EDC) is used to trigger a TEI transfer either from a system event (for example, a raise of status) or from a manual event (for example, using option 53 in the delivery toolbox). The EDC function is based on predefined events that are controlled by a selection table to detect when or whether a specific document should be printed. This function can be used for several documents and one specific document is the TEI transfer document.

• TEI transfer document

  The TEI transfer document is not a regular document but rather a trigger used to start the creation of a TEI transfer. This document will only contain basic information about either the event that triggered the creation or information from the selection made in a report version. The document number used for the TEI transfer document is 915. Only document variant 00 is standard but any value up to 99 can be used. It is recommended to use one combination of document number and document variant for each set of output information that will be used. For example, if package information should be sent to an external transportation system one document variant should be used but another document variant is used if delivery information is sent to a Transportation Execution Systems.

  • Manage TEI transfers - MYMNGTEI

    This program is central for managing TEI transfers. It will call other programs to trigger specific tasks. For example, when the program MYRTVTOC is called to retrieve an output control record and to create a TEI transfer header, then the program MTITHEPI will be called. When a TEI transfer is sent to an external system, it is done by this program which creates an MBM trigger and sends it to IEC.

  • Retrieve TEI output control data

    Certain data that should be added to a created TEI transfer is object controlled. This data is retrieved from the MDOCTI table. The external transportation system that should receive a specific TEI transfer is one of the parameters that is managed in this function. This program will be called for every event triggered TEI transfer.

  • Manage TEI transfer header – MTITHEPI

    When a TEI transfer header is checked, added, or changed, the function MTITHEPI is used. Every managing of a TEI transfer in the MTITHE table is managed by this function.

  • Manage TEI transfer details – MTITDEPI

    In the same way as MTITHEPI manages TEI transfer headers, this function manages TEI transfer details. When a TEI transfer detail in MTITDE should be processed in any way, it is done by the function MTITDEPI.

  • Work with TEI transfer header

    This function is used to manage TEI transfer headers that are already created. From here a TEI transfer header can be changed, added, and manually sent to the external system.

  • Work with TEI transfer details

    This function is used to manage TEI details that are created and connected to a transfer header. TEI details can be added, deleted, or changed in this function.

  • IEC Mapping

    When the TEI transfer has been sent to IEC, it will be used to trigger a predefined template, a IEC mapping. These templates will use several different APIs to retrieve transactional information from M3 in a sequence.

  • XML

    The output from the IEC mapping will always be in XML format. If the receiving system can manage XML files, there is no need for additional processing of the output file.

  • Flat file repository

    In those cases where the receiving system only can manage a flat file format, the XML file can be converted. This is done by using the flat file repository.

Mapping IEC to TEI

The following figure illustrates the principles for using IEC and the APIs to download transportation information from M3 BE. The counterpart to IEC can either be a Transportation Execution Systems or an external partner (such as a customer, supplier, or forwarder) that receives B2B messages (EDI, XML, and so on).

The M3 BE business logic and the APIs in the TEI interface are considered standard functionality that is delivered and supported according to normal routines. The mappings in IEC that are needed to pull information from M3 BE and create any kind of output file that will be sent to a Transportation Execution Systems follow a different routine. Since no universal standard (compare ANSI X12, EDICFACT, etc.) exists, Infor cannot supply a standard delivery for this purpose.

The template IEC mappings delivered by Infor produce both an XML file (supporting supports outbound logistics) and a flat file output (supporting inbound logistics). The XML file and flat file output is produced based on a Transportation Execution Systems system called EDICOM and its interface file standard "CEDITRAN." Each implementation can then use these templates and modify them into its own format based on which Transportation Execution Systems is used. If EDICOM is used, smaller adjustments might be needed since each EDICOM implementation is unique.

B2B mappings can also be produced in IEC to support B2B messages (EDIFACT, XML, ANSI X.12, and so on) to forwarders or customs. These implementation-unique formats and B2B messages are not a delivery from Infor.

General recommendations – Customized IEC mappings

Each customer unique IEC mapping must always consist of the following:

1. Initial API call to MYS500MI GetHead based on the MBM initiator sent containing the TEI Transfer ID.
2. API calls to MYS500MI ChgHead with field STAT = 15. Will update TEI Transfer ID in (MYS500) with status indicating IEC mapping has started.
3. API call to MYS500MI LstDetail to retrieve the list of detail records created in (MYS501). The nature of the details depend on the current event type and detail type.
4. Customized API calls based on what shall be produced as output from the current IEC mapping. Here IRDs template mapping solution must be replaced but re-used.
5. Optionally, perform an API call to MYS500MI ChgHead with field STAT = 19. Will update TEI Transfer ID in (MYS500) with status indicating IEC mapping has stopped processing before the planned end with an controlled error that should not create any output file.
6. Initial API call to the API MYS500MI ChgHead with field STAT = 20. Will update TEI Transfer ID in (MYS500) with status indicating IEC mapping has completed successfully.

Concept log

To support the analysis of the event triggering, concept logs can be activated in server view. The concept logs will display data used during the triggering event and TEI creation.

To activate the concept to log the event triggering, enable the concept:

mvx.sce.edc.EventTriggering

To activate the concept to log the creation of a TEI transfer, enable the concept:

mvx.sce.tei.TransferCreation

When the concepts are activated, information will be written to the JVM log during the process.

Configurations in (MYS015)

In (MYS015), a TEI partner can be connected to document number 915 and to a document variant. It is recommended to use one document variant for each purpose and each TEI partner. For example to send package information to an external system should one document variant be used while another document variant should be used if it is transportation information that is going to be sent to the external system.

Configurations in (MWS145)

It is possible to use several sequence numbers in (MWS145) to trigger a document several times. This functionality should be avoided in the case of triggering the TEI transfer document since it can result in several TEI transfers with the same details sent to the external system. If it is possible, use the TEI transfer document in only one sequence number or be careful when setting the controlling objects in MWS145 so the situation is avoided.

The event Release_Pick can as mentioned before only trigger package details in the TEI transfer. Since this event is triggered when each picking list suffix is printed packing report method = 4 (automatically when printing the picking list) is the most useful. However, there is a limitation in this functionality. When picking list suffix 1 is printed and the included picking list lines are packed in 2 full packages and a third half full package a TEI transfer is created with one detail record per package number. When picking list suffix 2 is printed there is a possibility to continue packing in the third, half full package. This will cause a second TEI transfer with one detail record (the third package) already existing on a TEI transfer. So depending on the receiving system, this can cause some problems. If the receiving system can manage that the same detail record is sent several times this is no problem but if the receiving system can't manage the same detail record twice, the parameter Allow duplicate details should be set to 0 which will prevent that the detail is not connected to the TEI transfer according to the printing of picking list suffix 2 above.

The solution to this problem can be either to use another automatic event such as Delivery_Issued or use the manual event Manual_Package. In the later example can each package be triggered individually when the package is fully packed.

Configurations in (MWS275)

The most important setting in (MWS275) is what TEI partner should receive a TEI transfer created from the TEI output control record. But the area where some extended explanations might be in place are the other fields in (MWS275) concerning TEI alias numbers. To each created TEI transfer header a TEI header alias can be connected and to each TEI detail a TEI detail alias can be connected. The main purpose of this functionality can be if the detail level is package number and if each package should have a unique number according to the receiver of the TEI transfer, for example a forwarder. Then TEI detail alias should be activated. Existing alias methods are 0 (no TEI detail alias), 1 (from number series) or 2 (from a user exit program). When method 2 is used, a customer modification program must be developed to fit the specific demands of that implementation.

TEI transfer entities overview

The TEI domain is oriented around the TEI transfer entity that is the result of a request for download of transportation related information. To each TEI transfer relations exist related to either outbound or inbound logistics with their respective entities.

Related entities such as shipments, deliveries, delivery lines, packages, purchase orders, and purchase order lines are created inside M3 based on the outbound and inbound process flow. The creation of the involved entities is configurable and has variations based on the flexibility when configuring the M3 product.

Event-based document triggers that are selected by the user automatically initiate a TEI transfer when an event occurs. Selected event triggers are chosen considering the normal processing activities inside M3. An example of such trigger is when a shipment is closed and no further deliveries will be added to the shipment. Another example is when a delivery is issued and all picking lists for a delivery number are issue reported. Alternatively, TEI transfers can be manually initiated allowing for user-defined grouping outside normal grouping identities such as shipments, deliveries, and purchase orders.

Entities outline

The following entities outline contains some simplifications regarding the connection between a package and a delivery line and the relations to the picking list entity.

TEI transfer entities description

TEI transfer events

Each event can be selected as the one that initiates the TEI transfer. All events except the manual TEI transfer are represented by a raised status on the entity.

Events for outbound logistics

Events for inbound logistics

TEI report versions

Instead of using an event to trigger the creation of a TEI transfer, a report version with a manual selection can be used. The selection can be cross functional, which means that it is possible to select, for example, deliveries that are connected to different shipments and still get them on one TEI transfer. Each report version can be used several times but the parameter Report version type cannot be changed after creation. A report version can have report version 1 (Outbound), 2 (Inbound), or 3 (Inbound DO).

• Type 1 (Outbound)

  This report version type should be used when creating TEI transfers including outbound transactions such as deliveries and shipments. Selection objects from delivery and shipment can be used to group deliveries into a TEI transfer. The detail level of the created TEI transfer from a report version with type 1 is always per delivery number.

• Type 2 (Inbound)

  This report version type should be used when creating TEI transfers including inbound transactions such as purchase orders. Selection objects from purchase order head and purchase order lines can be used to group purchase order lines into a TEI transfer. The detail level of the created TEI transfer from a report version with type 2 is always per purchase order line.

• Type 3 (Inbound DO)

  This report version type should be used when creating TEI transfers including inbound DO transactions such as delivery that is about to be goods receipt. Selection objects from delivery and shipment can be used to group inbound DO-deliveries into a TEI transfer. The detail level of the created TEI transfer from a report version with type 3 is always per delivery number.