MOSS POC Exercise 1

By Donald Anderson,2014-06-17 01:33
11 views 0
MOSS POC Exercise 1 ...

    1MOSS POC Exercise 1 Narrative


    ۰Executive Summary

    ۰Exercise 1 Messages

    ۰Exercise 1 Narrative

    ۰Exercise 1 Data

    ۰Guidance on Performing Exercise 1

    ۰eDoc Invoice (attachment)

Executive Summary

The goal of MOSS is to define a recommended best practice for the management of the information driving long-distance

    supply chains. To this end, MOSS will:

    ۰standardize the messages employed in long-distance supply chains,

    ۰standardize or communize the data tags and codes employed by the various entities,

    ۰standardize required documentation (with hard copy document production on demand)

     utilizing the UNeDoc platform.

Exercise 1 is the first exercise of the MOSS Proof of Concept (PoC). It is intended to give technology providers an

    opportunity to evaluate a portion of the draft recommendation in the context of their software systems. The tools

    provided on the NIST MOSS worksite assist in the task of implementing the recommendation, and in the assessment of

    conformance to the recommendation.

Specifically, Exercise 1 concerns the ability of technology provider tools to read the MOSS DELJIT message and produce

    MOSS DESADV and INVOIC messages, and an Invoice eDocument. This exercise will be followed by Exercise 2 which

    will address the remaining PoC messages: 204, IFTMBF, IFTMIN, IFTMCS, IFTMAN, CUSCAR, and IFTSTA.

The MOSS PoC will be followed by a comprehensive MOSS Pilot which will demonstrate interoperability testing across

    stakeholders in the intercontinental supply chain.

     1 EX1040408.doc

Exercise 1 Messages

    In this section, we describe the roles of MOSS DELJIT message, and the roles of DESADV and INVOIC messages produced as part of the exercise. We then describe the exercise scenario, which provides additional information required to complete some fields of the messages to be produced in the exercise.


    The message is normally sent from the buyer (or agent) to the seller and gives information regarding shipment details for manufacturing environments that are requirements-based, consumption-based, or sequenced. The message conveys to the supplier precise shipment authorization and delivery sequence information. Essentially the DELJIT informs the recipient of:

    ۰What material is to be shipped,

    ۰Where the material is to be shipped or delivered, and

    ۰When the material is to be shipped or delivered.


    The process of generating and transmitting information regarding the movement of finished goods is called the dispatch process. The MOSS DESADV is based on that of the AIAG Global message set. The message is normally sent from the Seller (or Ship-From) to the Buyer and or Ship-To, messaging recipients also may include Material Issuer and Ultimate Customer as well as third parties to the transaction including carrier, freight forwarder, consolidation center and customs broker or service provider. The DESADV informs the recipient of the detailed contents of a consignment. The message relates to one seller and one buyer or their respective agents. The message relates to a single dispatch point and single or multiple destination points and it may cover a number of different items or packages. Essentially the DESADV informs the recipient of:

    ۰When the material has been despatched or will be ready for despatch,

    ۰The precise details of the consignment (what was shipped),

    ۰Take initial steps towards Customs clearance in the case of international


    ۰Enable matching between despatched goods and the following invoice.


    The standard interpretation of the INVOIC is a message claiming payment for goods or services supplied under conditions agreed between the seller and the buyer. The INVOIC may also serve as the specification for Debit Note and Credit Note messages. The INVOIC may either correspond to a single shipment of goods from a supplier to customer, or it may cover a number of shipments made during a particular period. And an Invoice may have different formats for different purposes such as: commercial invoice, self-billed invoice, pro-forma invoice, consular (export) invoice, and customs invoice.

    An INVOIC message may be sent as an original invoice with the same significance as the corresponding paper document or it may be sent as an electronic copy of a paper original.

    As you may know, the Scope of MOSS excludes financials (e.g. freight payments, insurance, etc) thus when we recommend the use of the INVOIC the principle under the auspices of MOSS is to provide the Invoice data and when necessary the hard copy Invoice required for the cross border / international transportation movement.

    Notwithstanding the myriad of potential uses of the INVOIC message, the MOSS recommendation is to use the INVOIC to supply the invoice for cross border transactions and may contain additional information for customs and/or statistical purposes/services. Additionally the invoice may contain transport details. And because the MOSS recommended Invoice is for cross-border international transportation movements specifically for customs and other government agency requirements, the INVOIC will be generated at the shipment level and represent a one-to-one relationship with the DESADV.

    Essentially the INVOIC will provide the required data for cross-border movements and the eDOC hard copy Invoice. The message will normally be sent from the Seller to the Buyer and other authorized parties to the shipment transaction to include the freight forwarder, customs broker, and logistics provider (similar to the current state parties who receive and handle hard copy shipment level Invoices in the cross border international trade environment).


    MOSS is recommending use of a standardized e-Invoice for automotive industry shipments. In the cross-border movement of goods an Invoice is required; current state discovery found the lack of or deficient Invoices to be a major reason for delays in the movement of goods. The resultant best practice recommendation will have the Ship-From party (supplier) generating the DESADV and an INVOIC EDIFACT message. The DESADV is currently required; the INVOIC is a new requirement and will enable generation of an e-Invoice in a standardized format without need for re-keying data. The information contained in the e-Invoice is a subset of that contained in the MOSS invoice message. The mapping of INVOIC content to the form is described in the file example-data/moss-invoice.xsl in the NIST MOSS Repository. Note that despite the name and the general form of this file, it is not an XSLT file -- it is a file similar in

    structure to an XSLT Formatting Object file, but with EDIPath values replacing the XPath values that would be used in a similar XSLT file. Note also that this file is not a UNeDocs file.

Exercise 1 Narrative

    Exercise 1 describes a door-to-door shipment of auto parts from Germany to a GM location in the United States. The transport company used in this shipment is ABC Line The shipment was assigned booking confirmation number 706026315 and export reference number 732697. Consignee reference number VLU-1175007 and transportation reference number 2178883 (MTI) were also assigned. The shipment consists of 22 pieces (smallest handling unit) of auto parts with a gross weight of 8628 kg’s. There is one line item in the shipment. Line Item 1 describes 22 boxes of cylinder heads containing 352 individual pieces. The goods were stuffed into container ABCL-3011360 at the Ship-From Party in Kaiserslautern. This party has DUNS code 498994573. The container was sealed with seal number 690545. The shipment departed the Ship-From location on July 07, 2007. At that time, the Shipper (SF) sent the DESADV message, reference number 19296. The container was delivered to the export port of lading, Rotterdam, code 42157, and laden on the USA flag vessel ABC Europa, carrier code ABCL. The vessel is a transport mode 11 container vessel. The vessel departed Rotterdam on 07202007 (20, July 2007) and arrived at the Port of Charleston, USA at 08032007. Customs clearance was effected and the goods were delivered to the ship-to-party.

    The following table describes the data to be used in PoC testing. In this snapshot of a goods movement, I = Introduced Data, information made available by this message; C = Changed Data, data that changes from message to message; and NC = unchanged Data, that which was introduced in a previous message and is re-used here (without re-keying or transformation). Production of an e-Invoice requires no re-keying of data.

In the current-state intercontinental environment, approximately 80% of all data is re-keyed at least once. In the MOSS

    solution, re-keying has been significantly reduced. In the following table, you’ll find 57 lines of data (noting that some

    values are stacked in the same row for this Narrative e.g. Buyer name and address and Buyer code are separate data line(s)

    in the Data Matrix and mapping structures), as the data moves electronically from message to message and the e-invoice

    we have 126 instances of data field population. Of these 125 instances only 4 require re-keying after initial input.

MOSS Exercise 1 Data

    Property Name Value Ancillary Value DELJIT DESADV INVOIC e-Invoice Message Number 19296 I C NC NC Message date 20070709120000 I C NC NC Buyer Party General Motors Corp 007656615 I NC NC NC Manufacturer Party Acme Auto Supplier GMBH DEADAOPE19AAE I NC NC Port of Discharge Port of Charleston 1601 USCHS I NC NC NC Port of Loading Rotterdam 42157 I NC NC Ship From Party Acme Auto Supplier GMBH 498994588 I NC NC NC Ship To Party Any Logistics Mngt, Inc 964475835 I NC NC NC

    General Motors Corp c/o/

    Ultimate Consignee Party Any Logistics provider 087203456 I NC NC Carriage Mode Code 11 I NC Carriage Mode Of Transport

    Name Vessel I NC

    Carriage Carrier Name Code ABCL I NC Carriage Carrier Name Text ABC Line I NC NC Conveyance Name ABC Europa I Conveyance Flag US I Conveyance Reference Number 42 I NC NC Handling Quantity 22 PCS I NC NC Gross Weight 8628 kg I NC NC Total Customs Value 193248 EUR I Bill Of Lading ABCL706026315 I A S N Ref 19296 I NC NC Booking Ref 706026315 I Export Ref 732697 I Transport Ref 2178883 I Ultimate Consignee Ref VLU-1175007 I Container Stuffing Location Kaiserslautern Door 498994573 I NC NC Place of Delivery Spring Hill, TN, Door I NC Transport Equipment Type I

    Container Number ABCL-3011360 I Container Type/Size 21 ft. I Seal Number 690545 I Line Quantity 22 BX I NC NC NC Part Number 12678915 I NC NC NC Lot Number 19298 I NC HTS # 8708.80.6590 I NC Description Cylinder Heads I NC NC Goods Height 91 cm I NC Goods Length 225 cm I NC Goods Volume 20 MTQ I Goods Width 146 cm I NC Item Gross Weight 8628 KG I Item Net Weight 7920 KG I NC NC Quantity Ordered 352 PCS I Quantity Per Package 16 PCS I Quantity Despatched 352 PCS I NC NC

    Quantity To Be Delivered 352 PCS I C Country of Origin DE I C NC NC Value 193248 EUR I NC Unit Price 549 EUR I NC Transport ChargesMethod of

    Payment CC I NC NC Terms of Payment INCO

    Termscode FCA I NC NC Order Reference Number 1765398 I NC NC Requested Ship Date 20070707120000 10 I Actual Ship Date 20070707120000 11 I Requested Delivery Date 20070803120000 2 I Expected Delivery Date 20070811120000 191 I NC NC Total Invoice Value 193248 EUR I NC

Guidance on Performing Exercise 1:

To perform Exercise 1, the technology provider should obtain from the NIST MOSS Repository,

    ( the DELJIT message exercise-data/exercise1-9735.txt. In the terminology of the

    MOSS Concept of Operations, (this document can be found in the repository) this DELJIT is the “message setting up the

    test.” This data includes 112 pieces of information and 9 milestone/visibility events. The data in the message setting up the test represents many, but not all aspects of an inbound ocean shipment, similarly it represents many, but not all data

    normally found in the various message sets. The subsequent MOSS Pilot will include all required, conditional and

    optional data for each message set.

There are three tools on the MOSS Worksite that were designed to help in the implementation of the recommendation:

    1) The MOSS Message Views: At is a link to views of the 3

    messages of Exercise 1. In these views you can expand and compress a hierarchical tree of message structure

    detail, starting with segments and segment groups appearing at the top level, and proceeding downward to

    segment group instances, segments and MOSS properties.

    2) The MOSS Data Matrix: At you can obtain the MOSS data matrix (data-

    matrix.xls, or .ods (OpenDocument format)). The Data Matrix, lists all MOSS Properties and maps them to the

    messages. Currently only the messages for Exercise 1 are mapped.

    3) The MOSS Conformance Testing Tools: At you can upload

    DELJIT, DESADV and INVOIC messages to determine whether they map correctly to MOSS Properties.

    Additionally, for the INVOIC, you can see how the data uploaded maps to a .pdf eDocument. At you can run “Input Tests” that assess the ability of tools

    to interpret MOSS data directed into the tool.

Report this document

For any questions or suggestions please email