The Fundamentals

The Fundamentals describe the basic concepts that should be covered at a granular level to accommodate the building of features to result in a good TMS. 

Means of Transport and the concept of a Visit

'Goods don't fall from the sky'.

The operational business of a Terminal that deals with energy products, starts with receiving Products.  These Products are carried by a Means of Transport (MoT). The following MoT's are common in the industry.


Any MoT has their own particulars in terms of what to register. For example, a Vessel will have an International Maritime Organization (IMO) number, which is a unique identification number and is referred too in the business by name. A truck on the other hand comes with a license plate number and won't have a name. A Train has wagons and each wagon has an ID. So each type of MoT has it's own set of details that need to be registered.

Furthermore, it is important to note that these MoT's are in the business of transport, meaning they can visit the terminal today and be back tomorrow for another operation. Therefore, when registering a Visit, registering the MoT by identification is not sufficient, it should also be registered under the Estimated Time of Arrival (ETA).

The Means of Transport visiting the terminal is registered under an identification and estimated time of arrival. The registration of a Visit.


Looking at the inbound process, the registration of a Visit requires a setup by Visit type. In terms of setup the aim is to do this in a generic manner, so that the principle of setting up a Visit type is characterized by:

  1. The identification of the MoT. This is the name and/or registration numbers. Think of IMO numbers in case of Vessels, license number for Trucks, Wagon numbers for trains, etc.;
  2. The ETA; and
  3. Other specific data elements driven the type of MoT, where it should always be flexible to add a data element.




Locations

The governance of customs processes is done via authorizations/licenses. In these licenses, an important element is the identification of locations that are considered approved for the application of the license. To allow the application of business rules, but also the general requirement of keeping record of the location of products, the proper setup of Locations is essential. Below the some common examples emphasize the principle:

  1. The entire Terminal with the address. Although not always relevant from he start, a License could cover for example multiple Terminals, meaning that the setup should be in such a way that the Terminal is linked to a license number, but also has its own identification reference. For example, in the Netherlands there are two Terminals. One in Rotterdam and one in Amsterdam. Both Terminals fall within the scope of the same license with license number X. Each Terminal has its own 'Tax warehouse reference'. The Rotterdam Terminal has Tax warehouse reference Y, belonging to License X and the Amsterdam Terminals has 'Tax warehouse reference Z', while belonging to License X. This setup is also relevant to the registration of Parties, which is described in the Chapter Parties;
  2. Jetties at the Terminal. Operationally speaking a Visit will typically berth at a Jetty, hence this information is likely to be available already. A Jetty should be considered a Location where it is possible to apply settings to a Jetty such as 'label' them as belonging to a certain license yes or no;
  3. Tanks. Some Member States license tanks instead of the full Terminal for (certain) customs procedure. To keep flexibility and allow for implementation of Measures of Internal Control, Tanks should be considered as Location just like Jetties allowing for allocation to licenses. This would allow the implementation of business rules where not only an Activity is validated if it is allowed under a certain license, but also is the license covers the Location where the Activity takes place. For example, if an Excise warehouse license does not include a Jetty and a User is trying to register an Activity related to Excise controlled goods at the Jetty, the system has the parameters and setup to prompt the User that said Activity is not allowed at the jetty location;
  4. Remote locations. Remote locations, such as Buoys (also referred to as Dolphins) or remote jetties not belonging to the Terminal infrastructure wise can be part of a License. The concept of Locations should also cover these type of Locations in terms of settings, where, for example, a Buoy has a registration number and/or address. For example, in case Product is moved under the governance of a license from a Terminal Jetty 1 to a Buoy 12, the record keeping should show the Movement from Jetty 1 to Buoy 12. When the Vessel leaves from Buoy 12 after performing an operation a declaration is likely to require the identification of the Buoy 12 as Place of Dispatch with the listing of address details. Hence, in terms of setup it should be possible to register a Location with an address.

Wherever a Location is used in the business process, Location details should be available from the Locations setup. 


Parties

In the dealing with Products, we deal with various Parties in the Supply chain. The Parties involves vary from Customers to Surveyors, but also Consignors and Consignees, or Customers of our Customers to which assets are sub-leased. Hence, a generic concept is the registration of Parties of which certain data related to those Parties should be available in the operational process. 

For example. When Product is loaded for a destination being another Terminal, a User should be 'bothered' only with specifying the destination/Consignee. In all likelihood, a customs declaration or electronic message is required in which the Consignee must be listed with potentially address details, a 'Tax warehouse reference' and a License reference. This data should be readily available from the parties setup, instead of a User having to specify every single time. As explained under Locations, a Terminal (Rotterdam and Amsterdam Location example) can be one of multiple locations listed under a License. This means that on the registration of Parties it should be carefully considered that certain data elements can be listed per party. In this case the physical location (Third Party Terminal name) should be registered as a Party including data elements such as:

  1. Address details;
  2. Economic Operators Registration and Identification (Eori) number (if available);
  3. Excise warehouse license number (if available);
  4. Tax warehouse reference number under Excise warehouse (if available);
  5. ....

Another example is a Customer. When we import Product for our Customers, typically the VAT on import is for the account of the Customer. In many cases there is a facility subject to a license that allows the customer to defer the VAT to their periodic VAT return, where they don't have to pre-finance the VAT and then recover, but they can simply include it in their VAT return as a payable and receivable at the same time. If we do the import declaration, we don't want to 'bother'the user by having to include this information. Rather the registration of the Customer under Parties should allow the registration of a 'VAT deferment license' number. Hence, wherever a business process involves Party information, the details around the Party should come from the Party setup rather then having to key in data at every instance.
 
 

Wherever a business process involves Party information, the details around the Party should come from the Party setup rather then having to 'bother' a user to key in data at every instance

Products and Parcels

By far, the most important part of a sufficient setup of a record keeping is the so-called Parcel administration.

Customs is all about Products. Please let that sink in.

Yes, Products are transported with a means of Transportation or are stored and blended in tanks. But without Product, no need for MoT's to transport Product or Tanks to store and blend. So the starting point should always be the Product.

No Product, no business!


A Product is defined as a physical substance or article. Something you can physically identify, point at or pick up. The Product is the thing that Operations deal with to Move or to apply a Service to, such as homogenizing.

A Product is defined as a physical substance or article


In the case of piece goods, you can easily keep them apart. For example, when your receive a car component, such as a steering wheel, you can have a 'top shelf' where you store steering wheels brought in from outside the EU (referred to as having a non-Union customs status (commonly referred to as Bonded or T1) and a 'bottom shelf' where you store steering wheels coming from the free circulation of the EU (referred to as having a Union customs status) (commonly referred to as T2). The same thing applies to the origin of the Products. One steering wheel coming from the US, the other coming from Germany. You could add labels to the steering wheels. A Product is registered by Trade name and Commodity code.

With bulk products this is not possible. That means it should be recorded in the record keeping and the data is tracked by accounting segregation.

A Parcel is the registration of a Product with certain administrative characteristics. For example, a Parcel has a:

  1. Customs Status (non-Union (T1 Bonded) or Union (T2);
  2. Origin;
  3. value;
  4. Etc... 

Let's say we receive gasoil originating from the US, which is discharged into a Tank containing gasoil originating from the EU. After discharge, the Tank contains Gas oil (Product). The Tank contains two Parcels, namely an x quantity of Gas oil originating from the US and an x quantity of Gas oil originating from the EU. Physically segregating these Parcels is practically undoable, therefore the registration of a Parcel allows for the application of accounting segregation and tracking of the Products as received. For compliance purposes it is critical to provide for an audit trail, which requires a sufficient Parcel administration.

A Parcel is the registration of a Product with certain administrative characteristics


A parcel is identified by a unique reference where at least a part of that reference is static, meaning that when administrative changes are done to an existing Parcel, the Parcel can always be identified. When a parcel is registered, new activities can take place in relation to that Parcel or part of that Parcel. To preserve an audit trail, it is important to maintain a relation between Parcels, by a so-called Parent-Child relation. This is typically done by means of three Parcel elements in terms of reference:
 
  1. The Ultimate Parent. This is the Parcel reference created the first time a Product is registered by means of a Parcel. This means a first time registration of a Parcel results in a Parcel without having an (ultimate) parent registration;
  2. The Parent. This is the reference to the Parcel where the current Parcel (Child) directly comes from. This means a first time registration of a Parcel results in a Parcel without having a parent registration;
  3. The Child. This is the Parcel reference, where dependent on if there is a Parent reference, it is considered the Child reference.
In case of the registration of a Blended Product, the Parcel will have multiple Parent references showing the relation to the Components.

The words Parcel and Lots are sometimes used interchangeably, but could refer to the same principle. Or sometimes a Lot is referred to as a part of a Parcel. Any form of Stock Keeping Unit and name can be used, as long as it serves the principles.

Cargo documents

Any cargo comes with various documents. These documents are typically archived in an archiving system. However, some data from the documents accompanying the Products is relevant to register with the Parcel. There are various possibilities. Some examples are:

  1. A Transit document, whereby it is relevant that the registration of the Parcel is linked to this document as it requires an Unloading remarks message in which the quantity received is reported, based on the Measurement(s) of the (Child) Parcels in the Tank or receiving Means of Transport (MoT). Also the declaration for the Product requires mentioning of this Transit Document by means of an indication of the Type of Document and the reference number (MRN) of the document;
  2. An e-AD, with a similar principle as the Transit document with the requirement top send a Report of receipt;
  3. A Preferential Origin document such as an Origin declaration or an EUR 1, whereby reference needs to be made to the document type and reference number in the required declarations;
  4. A Bill of Lading with relevant details such as a Density and a quantity;
  5. Etc...

Storage Unit

Any (bulk) Product is physically contained somewhere. This can be a compartment on a Vessel, a Truck or in a Train Wagon. Or it could be in a Tank or a Pipeline. To identify the physical location where a Product can be taken from we refer to the concept of a Storage Unit. For example, if a Vessel arrives carrying Gasoline and Diesel, there will be at least two Storage units. So the Storage Unit is used to identify the physical segregation of Product for registration purposes. 

The Storage Unit is used to identify the physical segregation of Product for registration purposes. 

In the aforementioned example, it could be that the Gasoline is physically spread over 10 compartments. For the operation there is no relevance to register all these 10 components so the User can suffice with one Storage unit that will allow the registration of a Movement from that Storage unit to another. Should there be a need to register 10 Storage units, the option should be there. Some examples:

  1. A Visit can have one or more Storage Units. 
  2. A Tank or Pipeline equals one Storage unit by default.
  3. A train holds a Storage unit per wagon.

Activities - Movements or Services

So now that we have covered the registration of the Means of Transport (MoT), Locations where these MoT's can be located, the Products and related information, we are getting to the registration of the things we will do with the Product. The Activities.

An Activity means any action / operation involving Product(s)

In the business of storage and handling of Energy Products the most prominent Activity is Moving the Product. Therefore, one of the Activity types is a Movement. A Movement is the physical relocation of Product, meaning the product is moved from one Storage Unit to another Storage Unit.

A Movement means the physical movement of Product from one Storage Unit to another


Apart from moving Product, other Activities are relevant. Any Activity that is not a Movement is considered a Services. These two concept also relate back to the contractual agreements and basis for invoicing, where typically throughput, where the registration of Movement play a role, and Service are the basis for invoicing. By using these concepts, the basis is there to govern the 'order to cash' process. Services can come in various types. A few examples:

  1. Release for free circulation (import);
  2. Booking of a quantity as received without a physical Movement;
  3. Registration of a Blend;
  4. Heating of product;
  5. Homogenization;
  6. Etc.

A Service is any Activity that is not a Movement