M3 TEI Transfer Triggers

Settings for Automatic Triggering of TEI Transfer

The outlined settings are divided into the following parts:

• Basic Settings for TEI Event Control

  The trigger control manages the basic settings needed to select a specific event and trigger a TEI request based on a variety of objects.

  • MNMNGDOC

    When you generate M3 documents in 'M3 Document. Open' (CRS928) by using F14 or F15, document 915 with standard variant 00 is created.

    Regardless of the document variant used, the object used for partner reference control is always TEI partner (TETIPI).

  • Document Objects – Partner Reference (CRS947)

    This function replaces a hard-coded internal table that manages the objects that can be used to control the partner references in 'Std Document. Connect Media Ctrl Object' (CRS945). The standard setup is generated when the standard documents are created by using F14 or F15 in (CRS928). For manually added combinations of document numbers and variants, a record must be manually entered in this function.

  • M3 Documents (CRS928)

    When you generate the standard documents in M3 automatically (by using F14 or F15), document 915 and document variant 00 must exist in a table in the program MNMNGDOC.

    The TEI transfer document is created in the CSYDOC table.

    If any other document variant will be used for document 915, it must be manually created in (CRS928).

    Note: The object value for partner reference is set to TEI Partner in object field 1. This establishes a connection for the partners that are allowed to use this document number and document variant. If this is not done, no partner can be connected in (CRS945).
  • Standard Documents. Connect Media Control Objects (CRS945)

    All partners that will use a TEI document and a specific variant must be connected by using option 12 and entered in (CRS945). The setup in (CRS945) is done by entering the TEI partner and connecting the communication media that this partner uses.

  • TEI Partners – MYS015

    You need to enter the TEI in 'TEI Partner. Open' (MYS015) to be able to connect a specific document number and document variant to the partner in (CRS945).

    Data from this program is used for several purposes, first when the partner references are set up in (CRS945). The last example is when a record is found in TEI output control program 'TEI Output Control. Open' (MWS275) and the used combination of partner, document number, and document variant is known for a specific TEI transfer request.

    When a TEI partner setting is retrieved from this table it will first try to find the record with the most detailed information, for example, in this case if the information in all three key fields is correct. If no record is found with the full key a search is done on the next level and so on.

  • Standard Documents per Company (CRS027)

    When you generate the standard documents per company in M3 BE (by using F14), document 915 and document variant 00 must exist in the program MNMNGDOC and in CSYDOC.

    The TEI transfer document will be created in the ODEDOC table.

    If any other document variant will be used for document 915, it must be manually entered in (CRS928) to be created automatically with function F14 in (CRS027).

    It is also possible to manually create a record for document 915 with any document variant in (CRS027) without using F14. This is done with option 1 (Create) or 3 (Copy). However, the document and document variant must always be created in (CRS928) so the partner reference objects are set correctly.

  • Field Groups (CRS108 / CRS109)

    Field groups are created to provide a workflow in the setup of the object control table for the event trigger control.

    Using field groups depend on the type of event. Objects from a delivery level cannot be used to select triggering or output data for any event on shipment number.

    The TEI trigger control field groups are only valid for a specific event.

    To manage the dependency between valid field group and event, use 'Event. Open' (CRS019).

  • Events (CRS019)

    This function is used to maintain the CREVNT table. If the CREVNT table is empty when 'Generic Object Control Table. Open' (CMS017) is run for the first time, a new file will be created.

    Since the automatic triggering of a TEI transfer is controlled via a specific document number and the triggering is controlled by selectable objects, this information is maintained per event in (CRS019).

  • Generic Object Control (CMS016/CMS017)

    By using the existing program 'Delivery Process Document Control. Open' (MWS145) through 'Available Object Ctrl Parameters. Open' (CMS016), you can set up a selection table that controls the event that will automatically trigger the TEI transfer request.

    The two key values used in the program (MWS145) are Event and Sequence Number. These can be used to obtain different document variants of the same document (915) controlled by different objects for the same event. The document variant can then be used as a key in IEC to select the information that should be retrieved from M3 BE and sent to the external Transportation Execution Systems.

• Basic Settings for TEI Output Control

  Output control manages what the TEI transfer request will look like. The following chapters explain these different parts in more detail.

  • Number Series (CRS165)

    In order for the TEI document output control to work, you must first define the number series that will be used.

    A number series type T2 must be created to manage the transfer alias ID. This number series can be used if the number series for the TEI transfer ID should be within a specific number series for specific objects that are defined, for example, for a specific forwarder or delivery method.

    A number series type T3 must be created to manage the package alias ID. This package alias can be used if there are specific demands on the number series for the package numbers that are sent to the external Transportation Execution Systems for specific objects that are defined, for example forwarder or delivery method.

    The number series type and number series be managed from blank division and created manually.

  • Field Groups to Control TEI Output Control Selection (CRS108/CRS109)

    The TEI output control selection is object controlled using program (CMS017). Available objects to use are controlled by TEI field groups that are connected to each event in (CRS019) by the field TEI field group.

  • TEI Document Output Selection (CMS016/CMS017)

    A generic object parameter, TEI output control, is created to manage TEI document output data and since the key to MWS275 will be event, document number and document variant it is possible to use the TEI field groups from (CRS019) when prompting in (CMS017).

The entire workflow for creating the settings for automatic is done the same way regardless of the automatic trigger points that are used in the inbound or outbound flow.

Automatic Triggering of TEI Transfer

• Trigger Events, Outbound

  The following outbound events are included in the TEI solution. Some of these events already exist and are used in the EDC functionality, but since these events will be changed they are covered in this section.

  RELEASE_PICK	This event is used to trigger to retrieve package data from M3 to the Transportation Execution Systems. This is used if the Transportation Execution Systems should print any kind of package labels and packing reporting method = 4 (Automatic when picking list is created) is used. The event RELEASE_PICK occurs in program MMMNGDST immediately after delivery have gone to status >=40. The event occurs after auto-pack has been performed. This Is also applicable when pick resource planning is used. When this event occurs, the event (RELEASE_PICK) and the event key (Delivery number + range of picking list suffix) must be passed to the TEI transfer request.
  DELIVERY_CLOSED	The purpose of this event is to trigger a TEI transfer request that can be used to send delivery or transport information per delivery to the Transportation Execution Systems before the issue has been made. The user must although be aware of the possibility that changes might occur to the content of a delivery after that it has been closed and before the issue is done that is not sent to the Transportation Execution Systems. If very few shortages in stock and few other changes to the delivery after it has been closed this might be a very useful event. A delivery can be closed from several different functions. For example it can be manually closed by option 37 in 'Delivery. Open Toolbox' (MWS410) or automatically when a delivery is going to be closed according to parameter 300 in 'Dispatch Policy. Open' (MWS010) (Closing point). What happens is that delivery lines or part of line is removed from the delivery and either connected to an open existing delivery or a new delivery number is created. When this event occurs, the event (DELIVERY_CLOSED) and the event key (Delivery number) must be passed to the TEI transfer request. A new TEI transfer will be created if it is the first time this event occurs for this combination of document number, document variant, event and event key. This event can only occur once since it is not possible to reopen a delivery number.
  SHIPMENT_CLOSED	The purpose of this event is to make it possible to send package and/or transport information per shipment to a Transportation Execution Systems before the actual issue has been made. When the time to get information to a Transportation Execution Systems is crucial this is a good alternative. Also when the customer has few stock shortages and there are few changes to deliveries and shipments after the shipment has been closed. The event SHIPMENT_CLOSED is handled in program DRMNGCON. Since this event can happen more than once, it is controlled by the parameter Allow duplicate TEI details from TEI partner settings. This parameter is managing how the creation of transfers with an event key that already exists on another transfer would be done. Since every Transportation Execution Systems has different way of managing transactions, it is up to each implementation to decide how this parameter would be set to handle information in an appropriate way according to the receiving system. When this event occurs, the event (SHIPMENT_CLOSED) and the event key (Shipment number) must be passed to the TEI transfer.
  DELIVERY_ISSUED	This event is one of the most natural to use because at this point all details to a delivery is known. It is only if the time gap between the actual issue and until the information must be used is to short that this event might not be useful. Can be used both for package and transportation information. In function MMMNGDIS, a delivery is flagged as issued and it gets the status >=60. When this event occurs, the event (DELIVERY_ISSUED) and the event key (Delivery number) must be passed to the TEI transfer request.
  SHIPMENT_ISSUED	This event has the roughly the same characteristics as the event DELIVERY_ISSUED. The shipment is considered issued when it's lower status >= 60 and the field CONSI.MANC =2. If the status was < 60 and now >= 60 the event has occurred. This is done in function DRMNGCON. If this happens a record is written into a work file to be processed by the auto job DRS901. This auto job will trigger the event when the deadline or departure date has passed. When this event occurs, the event (SHIPMENT_ISSUED) and the event key (Shipment number) must be passed to the TEI transfer.
  DELIVERY_INV	This event can be used if the requirements of the package and/or transportation information is high and if it should have any information concerning invoicing. The accuracy of the information is very high since this event is done so late in the outbound delivery flow. When a delivery get invoiced status = 2 for the first time. This occurs in MMMNGINV when HDISH.IVSS is set to 2. This event is only valid for customer orders. When this event occurs, the event (DELIVERY_INV) and the event key (Delivery number) must be passed to the TEI transfer request.
  SHIPMENT_INV	This event has the same characteristics as the event DELIVERY_INV except that it manages all deliveries that are connected to a shipment. When a shipment get invoiced status = 2 for the first time and the deadline has passed. This occurs in DRMNGCON when CONSI.IVSS is changed from <2 to =2. And this event is only applicable on customer orders. When this event occurs, the event (SHIPMENT_INV) and the event key (Shipment number) must be passed to the TEI transfer.

• Trigger Events, Inbound

  The following inbound events are included in the TEI solution.

  DO_GOODS_REC

  When sending transport information to a third part supplier (for example a forwarder) about what has been received at a warehouse coming from another warehouse, this might be a useful event. This might also be used if importing goods and customs integration is needed. When a distribution delivery is fully goods received in program MMMNGDOR the delivery get status 90 from a lower status. It is at this point the event will be triggered. When this event occurs, the event (DO_GOODS_REC) and the event key (Delivery number) must be passed to the TEI transfer request. This event can only occur once per delivery number.

  PO_GOODS_REC

  This can be useful when information about purchased goods that is received should be sent to a forwarder or a supplier. Another case when this event is useful is when the customer is using bonded warehouse to reduce the cost of paying customs taxes in advance. By reporting the goods receiving when the goods actually is taken from the bonded warehouse and at that point send information to the customs, the customs taxes can be paid at the right time. This event is triggered when a receiving number has been created due to a purchase order line or a part of a PO line has been goods received. This event will create one TEI transfer detail per reporting number. To be able to create one TEI transfer detail per PO-line, the manual creation of TEI transfers should be used. In this case the TEI transfer will contain the event (PO_GOODS_REC) and the event key (Receiving number) should event key receiving number be sent to the TEI transfer.

• TEI Transfer Document

  After an event has occurred and every condition is fulfilled for a creation of a TEI transfer, a batch job will be trigged to start the TEI transfer creation. The batch job is started by a printout of the TEI transfer document. This document is never printed as an actual document but rather used to make use of existing functionality of event based trigger points.

  Document number 915 is the document number that controls the creation of a transfer ID and triggering IEC to retrieving data from M3 BE using APIs.

  Document number 915 is first handled by programs (MYS625) and MYS625S1 then by the actually TEI managing function MYMNGTEI. Here is a short schedule of the functions of these programs. This will give a rough picture of the functionality of these programs.

  By using the operation codes from the sending program, the next step is known. The following operation codes are handled in MYMNGTEI:

  *CRT	*CRT will handle the creation of the transfer header and details when the creation is triggered by an event First the TEI document output control data according to the settings in MWS275 is retrieved. This is done by a call to MYRTVTOC to get info from table MDOCTI After that a check of number series and parameters from the table MTIPPR in MYS015 is done. From here the TEI internal number series and the parameter DUDE (that controls if it is allowed to resend detail info) is retrieved. If it is not allowed, and it already exist one combination of document number, document variant and the detail identity (for example delivery number) on a transfer ID then no transfer will be created. If re-sending event keys and detail information is allowed, then mark the transfer header that it is a complementary TEI transfer (parameter on transfer header). If every check is passed the TEI transfer header and details will be created and the transfer header status is set to 01. For every transfer creation, a check must be performed if the transfer alias number or the package alias number should be retrieved from a specific number series or a specific program. These parameters are retrieved from MDOCTI.
  *CRTRPTH	This operation code will manage the creation of a TEI header from a report version in 'TEI Transfer. Manually Create' (MYS510). In this case the first thing to do is to check what report type is used to define the kind of detail type to use when create a TEI transfer detail. Then parameters from the TEI Partner will be retrieved before the TEI header is created.
  *CRTRPTD	This operation code will be used to create TEI transfer details to a TEI header triggered from a report version in MYS510. Here will the transactional data be retrieved.
  *RPTEND	When a TEI transfer triggered from a report version should be closed this operation code is used. Here will the TEI header status be raised and the TEI transfer will be sent to the external system if the parameter Send TEI aut = 1.

Manual Triggering of TEI Transfer per Function

You can print the TEI transfer document manually, if needed, from 'Delivery. Open Toolbox' (MWS410), 'Shipment. Open Toolbox' (DRS100) and 'Delivery. Connect Packages' (MWS423). To retrieve both the triggering control data to know what document number and variant to use, and the correct output control data to know which TEI partner to be used in each specific case, you need to enter the same settings as for automatic triggering.

This functionality can primarily be seen as a back up to an automatic trigger. But it can also be used to print, for example, package labels via an external Transportation Execution Systems on demand.