Business Requirements and Solutions for M3 Transportation Execution Interface

Transportation Documents

Often a Transportation Execution Systems is required when transportation documents vary between different forwarders, resulting in numerous layout requirements. Another deciding factor is that a company's export is directed to different countries, all requiring different sets of documents.

The Transportation Execution Systems is used in one of two ways: as a black box with no user intervention where documents are printed automatically via the Transportation Execution Systems, or it is used to send available information from M3 and then manually add the missing information in the Transportation Execution Systems before requesting a printout manually.

The characteristics of the major Transportation Execution Systems are that they are linked to the forwarders used on the local market and have knowledge and functionality to produce all types of forwarder documents.

By using event triggers in M3 TEI, you can select the event that suits the implementation and trigger a push of information to the Transportation Execution Systems at the right moment. If the event triggers do not work for you, use the manual events or the manual TEI creation function.

• Label Documents

  Labels can be printed by M3 Supply Chain Execution, but you can also print them from the Transportation Execution Systems.

  Depending on when you perform the packing operation in M3 and when you want to print package labels, different events can be used. The earliest step is when the picking list is released and the event RELEASE_PICK occurs. However, this event requires that the packing operation is performed automatically based on the pick release. Any subsequent event in the Supply Chain Execution process can also be used to trigger the transfer of label information.

  To supply the Transportation Execution Systems with package information, you can use a variety of APIs that retrieve package and label information.

  The IEC mapping needed to support the transfer of label information is fairly simple. Based on the available delivery of the outbound logistics template IEC mapping, a label map is created with minimal customization.

  Note:  Configuration Requirements

  It is highly recommended that M3 shall control the business logic for creating the packages. If this is done inside the Transportation Execution Systems additional integration requirements arise that is currently not supported by M3 TEI.

  If you use the RELEASE_PICK event to send label information, that event requires though that the packing operation is performed automatically based on the pick release. Any following event in the Supply Chain Execution process can also be used to trigger transfer of label information as long as the packing operation is performed.

  The recommended APIs used to supply the Transportation Execution Systems with package information are:

  • MYS500MI Transaction LstPackages
  • MWS423MI Transaction LstPackages
  • MWS410MI GetPackage

  Which API transaction to use from the list above depends on the event that triggers the TEI Transfer. If event RELEASE_PICK or MANUAL_PACKAGE is the trigger, 'TEI Transfer. Open Details' (MYS501) will contain a list of package numbers to transfer. In that case MYS500MI LstDetail will return this package list and the transaction to use is MWS410MI GetPackage for each detail record returned by MYS500MI LstDetail.

  Any other event or manual creation should use either MWS423MI LstPackages or MYS500MI LstPackages. If the TEI transfer potentially consists of more than one delivery number, MYS500MI must be used. If a TEI Transfer ID always equals one Delivery number then MWS423Mi should be used.

• Freight Documents

  Different types of freight documents, such as the SIS freight document or the CMR freight document, can be produced from M3 Supply Chain Execution.

  If the export volume is high and shipments are sent to different countries with different document requirements, a Transportation Execution Systems is needed to manage this.

  In contrast to labels, the trigger point for freight documents is normally later in the Supply Chain Execution process. The deciding factor is normally the earliest point when you are sure of the content of a delivery or shipment. This is most often near the departure of the physical vehicle. All delivery-based or shipment-based events can be used. It is not recommended to use events related to picking lists or packages.

  If you want to create freight documents designated to a party other than the final consignee, this is possible by using the ship-via function. Examples of such parties are a customer distribution center, a grouping center, or an importer operating on behalf of the final consignee.

  You can use a variety of APIs to supply the Transportation Execution Systems with freight document information.

  The IEC mapping needed to support the transfer of freight document information should combine APIs that retrieve delivery information and grouped package information. Based on the IEC mapping deliverable for outbound logistics template, a freight document map is usually created with minimal customization.

  Note:  Configuration Requirements

  Depending on which documents and how many different freight documents that are needed, the best option currently is to create the document identities in the Transportation Execution Systems system. Some possibilities exist to create document IDs inside M3 and then transfer the identity together with the rest of the document information. This requires that a single freight document is used per Delivery. Also no upload of identities is currently supported.

  If you need the Ship-via functionality, configure so that the Ship-via address is connected to each delivery when the delivery number is created. The TEI Transfer ID in 'TEI Transfer. Open' (MYS500) will then automatically be grouped per Ship-via address when it is created. Then use API transactions that summarize information per TEI Transfer ID (MYS500MI) to get summaries per Ship-via. Refer to the template IEC mappings and the consignment level information for a reference to a Ship-via summary. Also use the Companion document Settings for Ship-via address to determine how you want to retrieve ship-via address.

  The recommended APIs used to supply the Transportation Execution Systems with freight document information are:

  • MWS410MI GetHead
  • MWS410MI GetAdr
  • CRS610MI GetBasicData, GetFinancial
  • CRS175MI LstGeneralCode
  • CRS045MI GetBasicData
  • MYS500MI Transaction LstPackGrp
  • MWS423MI Transaction LstPackGrp

  Which API transaction to use from the list above depends on the information required for the specific freight documents used. The level of detail in 'TEI Transfer. Open Details' (MYS501) will most commonly contain a list of Delivery numbers. If a joint document for several Delivery numbers grouped by one TEI Transfer ID is requested, MYS500MI I LstPackGrp should be used. If one document per Delivery is requested, MWS423MI LstPackGrp should be used.

• Customs Documents

  When exporting goods to a third country (for example, a country outside the European Union), specific customs documentation is required. The most commonly used customs document is the Single Administrative Document (SAD) also called the ED document or the unit document. An export invoice is also mandatory that supports the SAD document with details. The export invoice can be in the form of a pro forma invoice. In certain cases additional customs documents such as movement certificates and certificates of origin are needed depending on the circumstances.

  If your business needs to produce any of these documents, some Transportation Execution Systems manage the customs documents for the specific markets. Customs regulations are in most cases very specific for the importing country and a Transportation Execution Systems application must be able to support the local requirements.

  In contrast to freight documents, the trigger point for customs documents is normally at the same point or later in the Supply Chain Execution or SLS process. The deciding factor is when all financial values can be calculated, such as prices and discounts, since customs documents must contain amounts in order to calculate correct customs fees. All delivery-based or shipment-based events can be used. It is not recommended to use events related to picking lists or packages.

  If you want to create customs documents designated to a party other than the final consignee, this is possible by using the ship-via function. An example of such a party is an importer operating on behalf of the final consignee.

  You can use a variety of APIs to supply the Transportation Execution Systems with customs document information. The IEC mapping needed to support the transfer of customs document information should combine APIs that retrieve delivery information and grouped item information with price information. Based on the IEC mapping deliverable for outbound logistics template, a customs document map is usually created with minimal customization.

  Note:  Configuration Requirements

  The specifics regarding customs documents is normally the grouping criteria's required and the additional price information compared to freight documents. It's important that the setup in M3 regarding Customs statistical number, Country of origin and Customs procedure is analyzed and properly defined. The complexity of pricing is also an important t issue as M3 TEI does not present all levels of detail as done for an SLS invoice.

  The Ship-via functionality, as stated above for freight documents, can also be applicable for customs documents. Hence a case with an importer receiving goods for a number of final consignees inside a specific country, you might need to produce a SAD document for the importer instead of each final consignee. Configure Ship-via as stated above and use API transactions on the grouped level. The template IEC mapping on the consignment level as delivered already contains a SAD summary enabled by the MI MYS500MI and transaction LstStatNo.

  The recommended APIs used to supply the Transportation Execution Systems with customs document information are:

  • MWS410MI GetHead
  • MWS410MI GetAdr
  • CRS610MI GetBasicData, GetFinancial
  • CRS175MI LstGeneralCode
  • CRS045MI GetBasicData
  • MYS500MI Transaction LstPackGrp

  Which API transaction to use from the list above depends on the information required for the specific customs documents used. The level of detail in 'TEI Transfer. Open Details' (MYS501) will most commonly contain a list of Delivery numbers. If a joint document for several Delivery numbers grouped by one TEI Transfer ID is requested, MYS500MI I LstStatNo should be used.

Hauler Integration

Hauler integration involves activities that occur before, during, and after the actual transport assignment occurs. Often B2B messaging is used to integrate consignor, hauler, and consignee.

A possible scenario for the transportation process and the information exchanged between consignor, hauler, and consignee:

• Booking
• Booking Confirmation
• Transport Label
• Transport Instruction
• Status Inquiry
• Deviation Report
• Receipt Advice
• Scan Transport Label
• Delivery Confirmation
• Debit Confirmation
• Invoice / Self-bill

The process described above covers a wide area where the Transportation Execution Systems on the market covers some or all activities. Some information flows are managed solely inside the Transportation Execution Systems and some are managed in the Transportation Execution Systems combined with interfaces to the backbone ERP.

The list below gives an overview of what you can achieve with M3 TEI combined with a Transportation Execution Systems that has such function built in.

• Freight Booking and Booking Confirmation

  The freight booking process can be advanced, and in that case includes freight shopping and tendering where criteria such as cost and delivery time are considered. Such processing is regarded as a delivery planning activity and is not included in a TEI scenario. The TEI process assumes that the response from the hauler does not affect the planning of deliveries. Please refer to the Transportation Operational Interface (TOI) for delivery planning capabilities.

  The activity of booking transport is used when no fixed booking routine exists. Usually, the consignor asks the hauler if transport can be carried out and when, where and what should be transported. The hauler then responds with NOK or OK combined with booking references.

  The trigger point for freight booking and confirmation is early in the Supply Chain Execution process. When the content of a shipment or delivery is known, you can start the booking activities. The Supply Chain Execution event triggers in general are not sufficient since they occur too late in the process. Use the manual TEI transfer function to imitate a push to a Transportation Execution Systems when the booking should be made.

  If you want to book freight designated to a party other than the final consignee, this is possible by using the ship-via function. Examples of such parties are a customer distribution center, a grouping center, or an importer operating on behalf of the final consignee.

  To supply the Transportation Execution Systems with freight booking information before the packing operation is performed, you need to produce such API transactions on demand. No suitable standard APIs exists in IAS 5.2US. If the booking takes place after the packing operations, the standard API capability can be used.

  The IEC mapping needed to support the transfer of freight booking information should combine APIs that retrieve delivery or shipment information and grouped weight and volume information. Based on the standard Infor delivery of the outbound logistics template IEC mapping, a freight booking map needs to be created requiring some changes to the template.

  Note:  Configuration Requirements

  The booking and confirmation process should be configured so that M3 TEI downloads booking information at a suitable occasion. The Transportation Execution Systems then manages the booking B2B communication with the hauler, both regarding the booking and the confirmation.

  Instead of events, use the manual TEI Transfer option (Option 53) in 'Delivery. Open Toolbox' (MWS410) or 'Shipment. Open Toolbox' (DRS100). If that does not work, use 'TEI Transfer. Manually Create' (MYS510).

  The Ship-via functionality, as stated above for freight documents, can also be applicable for freight booking. Configure ship-via as stated above and use API transactions on the grouped level. The template IEC mapping on the consignment level as delivered already contains a Package group summary enabled by the MI MYS500MI and transaction LstPackGrp.

  The recommended APIs used to supply the Transportation Execution Systems with freight booking information are:

  • MWS410MI GetHead
  • MWS410MI GetAdr
  • CRS610MI GetBasicData, GetFinancial
  • CRS175MI LstGeneralCode
  • CRS045MI GetBasicData
  • MYS500MI Transaction LstPackGrp (If packages exists)
  • MWS423MI Transaction LstPackGrp (If packages exists)

  Which API transaction to use from the list above depends on the information required. The level of detail in 'TEI Transfer. Open Details' (MYS501) will most commonly contain a list of Delivery numbers. If you book transport before the pack operation is performed, the last two transactions above should not be used. Instead you need to develop a new API transaction that summarizes weights, volumes etc. on the level that you want to book on.

• Electronic Freight Documents

  Electronic freight documents are managed before the actual transport occurs. The B2B freight document message is transferred from the consignor to the hauler to inform of the exact content of a transport assignment. If a fixed booking routine is used, this is the first B2B message exchanged. If no fixed routine is used, the B2B freight document details the previous booking.

  The electronic variant of the freight document is a replacement of the paper-based variant. If the hauler prefers B2B messaging, the electronic variant is preferable for both parties.

  For Configuration Requirements, refer to Freight Booking and Booking Confirmation.

• Transportation Process Monitoring

  Transportation process monitoring includes the activities that occur after the vehicle leaves the warehouse.

  Different activities can be performed to monitor the progress of the transport and any deviations. Theses activities are normally performed inside the Transportation Execution Systems application, and no new information download is needed from M3 TEI.

  As most of the activities occur in the Transportation Execution Systems to monitor the transportation process, no additional configuration is needed in M3 TEI.

Customs Integration

Customs integration involves activities that occur before the actual export or import assignment occurs. Often B2B messaging is used to integrate consignor and customs authorities.

Support for customs processing is part of some Transportation Execution Systems, but not all. Quite often the functional requirement is specific to the markets to which you export or import.

The list below gives an overview of what you can achieve with M3 TEI combined with a Transportation Execution Systems that has such a function built in.

• Export and Import Declarations and Response

  The activity of declaring an export or import occurs when such an activity is required. This depends on the relation between the consignor's country and the consignee's country. In many cases, such as intra-EU trade, customs declaration is no longer required. But in other cases when, for example, an EU country is exporting to a non-EU country a customs declaration is required.

  The declaration is done prior to the export or import in order to declare the content of the shipment and calculate the customs fees to be paid. Moreover, you save time so that the vehicle can travel directly to the border without stopping at the nearest customs office. Usually, the consignor produces an electronic B2B variant of the SAD document as described above. The customs authorities then respond if the declaration is approved with a returning B2B message.

  For Configuration requirements, see Customs Integration.

• Bonded Warehouses

  A customs procedure exists for bonded warehouses whereby you can delay payment of customs fees and VAT for imported goods until the point of time when the products are used or sold to another party.

  Note: A bonded warehouse solution is specific to each implementation. The solution described here is one building block that must be combined with implementation specific solutions.

  Some Transportation Execution Systems applications have support built in to manage bonded warehouses. Such support includes the following:

  • Inventory management and control of the bonded warehouse items and goods receipts involved
  • Import declaration of goods that resides in the customs trade union after consumption or sales
  • Cost control of imported goods being sold to a third country outside the trade union

  To enable a bonded warehouse solution, M3 TEI includes events that can trigger a download based on the receipt of goods for both purchase orders and distribution orders.

  An API capability is also available that can retrieve inventory information for the specific goods receipts so that the bonded warehouse inventory balance can be increased.

  As described in the previous sections, the issue of the delivery can be downloaded to manage sales to parties outside the trade union.

  The IEC mappings needed to support a bonded warehouse solution should manage:

  1. The goods receipts to the bonded warehouse

  2. The issue from the bonded warehouse

  The first mapping should use APIs that retrieve goods receipt transactions. The second mapping should use APIs that retrieve delivery information.

  Note:  Configuration requirements

  The bonded warehouse process should be configured so that M3 TEI downloads goods receipts to start with. For POs the event PO_GOODS_REC can be used as it occurs for every goods receipt transaction. For DOs the event PO_GOODS_REC should be used.

  Combine these events with a IEC mapping for POs uses the API PPS200MI GetLineTrans or LstLineTrans. For DOs MWS410MI and LstItem can be used. By creating these maps the bonded warehouse inventory balance is increased when goods are reported as received. The standard APIs might need to be modified so that only items included in the bonded warehouse solution is downloaded to the Transportation Execution Systems.

  The second integration point is more or less equal to any of the ones described above when an issued outbound delivery is downloaded with the purpose to create freight documents. The purpose of the transaction is to decrease the bonded warehouse inventory balance and serve as basis for the calculation of customs fees and VAT. The same situation applies here that the standard APIs might need to be enhanced to filter or identify the items unique for the bonded warehouse solution.

Track & Trace

Track & Trace is a collection of features that enable different parties such as consignor, hauler, consignee, and final consignee to monitor a shipment and its present status.

When the transportation process has started, it is vital to be able to track where a certain parcel or shipment is located. Such a process requires both tracing capabilities and detailed reporting. The use of RFID, bar code scanning, and so on is important for enabling a track and trace process.

• Shipment and Delivery Tracking

  Tracking of entire shipments or deliveries is more common in B2B scenarios where full truck loads must be possible to monitor. If deviations occur, the tracking can of course be done on the parcel level.

  A tracking scenario with M3 TEI and a Transportation Execution Systems initially requires built-in functionality in the Transportation Execution Systems. M3 TEI performs a download of a shipment or delivery to produce a freight document as described earlier. The Transportation Execution Systems then stores this document and manages the integration with the hauler in order to track the delivery. The tracking can be done using B2B messaging or by using Internet tracing features supplied by the hauler.

  M3 TEI plays no active role in the tracking process. This is managed by the Transportation Execution Systems.

  Note:  Configuration requirements

  The integration between M3 TEI and the Transportation Execution Systems is managed when the used documents, normally freight documents, are downloaded.

  The additional information that can be needed regarding tracking is to download additional identities. Controlled by 'TEI Output Control. Open' (MWS275) several methods exists to retrieve a TEI Header alias ID. This ID can then be downloaded together with the document information and used as an additional tracking ID. Moreover the External tracking number defined in 'Delivery. Open Toolbox' (MWS410) can also be used.

• Parcel Tracking

  Tracking of single parcels or packages is common in both B2B and B2C scenarios. All involved parties must be able to track individual parcels.

  A parcel tracking scenario with M3 TEI and a Transportation Execution Systems initially requires built-in functionality in the Transportation Execution Systems. M3 TEI performs a download of packages as described earlier. The Transportation Execution Systems then stores this label document and manages the integration with the hauler in order to track down the parcel. The tracking is most often done by using Internet tracing features supplied by the hauler.

  M3 TEI plays no active role in the tracking process. This is managed by the Transportation Execution Systems.

  Note:  Configuration requirements

  The integration between M3 TEI and the Transportation Execution Systems is managed when the used documents, normally the label, is downloaded.

  The additional information that can be needed regarding tracking is to download additional identities. Controlled by 'TEI Output Control. Open' (MWS275) several methods exists to retrieve a TEI Detail alias ID. This ID can then be downloaded together with the label information and used as an additional tracking ID. Moreover the External tracking number defined in 'Delivery. Connect Packages' (MWS423) can also be used.