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).

M3 Transportation Execution Interface (TEI) architecture

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 shall 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 call 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 shall be replaced but re-used.

  5. Optionally perform 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 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 analyses 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.

Note: The concept log should only be activated during analyses to minimize the workload.

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.

Related topics