Example of Process - River Bill of Lading
Shows visually the steps taken to create an electronic equivalent of the River Bill of Lading
The inland water community provided some examples of river bill of lading documents used as part of a pilot digital corridor between the Black Sea and the Baltic Sea.
Example River Bill Used as an Example
The River Bill of Lading is the Transport document issued by the carrier to the shipper of goods carried by river which evidences receipt of the goods for carriage and binds the carrier to surrender the goods to the consignee at the port of destination.
From the document we take the list of attributes using the terminology provided, note that if you are working on multiple examples there will be a mix of terminology, we would need to align these, examples could be (exporter, shipper, consignor) we would when reviewing the attributes against MMT RDM start to use the correct term in the above example this would be the consignor and you can use the CCL as a good reference point to do this, as its important that when working across borders everyone understnds the same terms.
In addition I have grouped these up to be logically in the right groupings.
- Consignment Note No
- Place of Issue
- Date of Issue
- Shipper (and Address)
- Consignee (and Address)
- Notify (and Address)
- Ship Owner
- Port of Loading
- Port of Discharge
- Marks and Numbers
- Description Of Goods
- No of Pieces
- Gross Weight
- Freight and Charges
- Payment Instructions
- Weight as Per Draft
Working through the above list of attributes helps when they are grouped as we did before, MMT is a hierarchical data model so now for the groupings above we can think about where we might find that type of information in the model and which other elements would also be in that class from the group.
If we look at an example of how:
The Party class contains the party name, and address details, we know that the Consignor, Consignee and Notify are Parties to the River Bill of Lading, so we would look for their business names in the MMT model and find that they are linked to the Party Class and we will easily see the attributes needed from MMT to fulfil this mapping as below.
So we would link our data attributes to the attributes from MMT, knowing that we are building upon a long history of contributions from industry so the model is rich with attributes and knowledge that is in use for electronic messages already.
If you work to the methodology above you will find that generally most of your data attributes are covered withing the MMT RDM due to its underlying influence in transport documents and contracts globally.
You will find on occasion items that require more consideration or subject matter experts (SME) to answer, so for example with the River Bill of Lading it was not immediately obvious where the
Weight as Per Draftwere on the first pass, so these would go onto a list of questions to discuss with the SME's and understand usage and application to then further identify the right location in the model.
The process would then iterate until the complete dataset is modelled.
If there are attributes that do not fit then it would be useful to discuss these with experts within the UN/CEFACT community and in some cases you would need to make a library submission to have them included into MMT RDM, this is a simple process of requesting a submission to the library.
Example data model for River Bill of Lading based on UN/CEFACT MMT.
The above shows the UML diagram, we used a data modelling tool, which will allow us to output in various formats (xml, json), as we loaded the UN/CEFACT MMT RDM into the tool we were able to quickly within a few hours build a data model which could be used as a basis for considering inland waterway transport as an electronic river bill of lading.
By workign in this way we avoid the inevitable pitfalls of 'rolling our own' data model, and we use familiar semantic definitions understood by industry that can be trusted globally.