# Terminal Management System
In this Chapter we focus on the role that our TMS - ATLAS plays in the process of governance. ATLAS is where data is received from in the CMS and where a User is informed on the outcome of the Customs processes.
# Fundamentals
#### Overview
Below is an overview of the physical flows relevant to the Terminal. The philosophy applied is the What You See IS What You Get principle. The record keeping and inventory is built on the concepts as explained under "Business process - Governance".
.png)
Part of ATLAS is the CMS. The purpose of CMS is to evaluate and validate the input data it receives from ATLAS and manage the compliance process. It is aimed at providing feedback to the Users on the basis of analysis performed and to lodge customs declarations timely and correct.
#### Products
The information regarding the Products is setup as follows, to accommodate, among other things, the customs processes:
1. Product - i.e., the physical Product without considering administrative aspects. For example, gas oil, or gasoline;
2. Parcel - i.e., the administrative reflection of a Product taking into account the Customs status, origin, consignee and, if applicable, Product characteristics such as alcohol percentage. For example, gas oil of the customs status non-Union (T1 - Bonded), or gasoline of the Union (T2 - Excise controlled) customs status. When the latter is loaded on board and part is destined for Terminal 1 and part is destined for Terminal 2, the Product will comprise of two Parcels. Parcel data is the data visible and relevant to the user;
3. Stock Keeping Unit (SKU) - The SKUs reflect the Parcels and their lifecycle in the record keeping. Whenever a SKU is moved, fully or partially, a Child SKU is created always keeping a relation with the Parent, and ultimately the Parcel, it originates from. This provides for a full audit trail of any Product entering the Terminal up until the point where the Product has left the Terminal. Each SKU has its own characteristics, meaning for each SKU the Customs status and/or origin may change, the Customs value may change, etc.
#### Activities
With any Activity, being a Movement or a Service, ATLAS provides the information of all Products involved in the Activity. For Services, which means there is no physical Movement of goods from A to B, the data provided relates to Parcel information in a Storage Unit (e.g. a Tank or on board of a vessel). When it concerns a Movement, two Storage Units are involved and ATLAS provides Parcel data regarding all Product involved in the Movement.
As further described under 'Business Process', below a list of Activities relevant to accommodate record keeping requirements from a Customs compliance point of view:
1. Movement;
2. Services:
- Take in quantity;
- Rebrand;
- Import;
- Administrative Stock Transfer;
- Shifting service;
- Commodity code correction;
- Departure.
# Business process
#### General
The Activities executed require formalities towards Customs based on our type of operation, i.e., Movements of Product, and based on Services we provide, such as blending or importation (i.e., release for free circulation). These Activities are governed through our TMS, ATLAS, whereby executing such Activities include a mandatory or automated step to ensure compliance.
In ATLAS, these **Activities** are initiated through:
1. **Movements**. Which concerns physical movement of goods; and/or
2. **Services**. Basically any activity that is not a Movement.
An **Activity** is either a **Movement** or a **Service**. Whenever it does not concern a physical Movement of goods, it concerns a Service.
#### Product registration
As soon as a Product is registered by means of a **Parcel**, compliance checks are performed to:
1. validate if the concerned Product falls within the scope of our licenses;
2. check if certain prohibitions / restrictions apply;
3. what documents can be expected; and
4. if the Product may be eligible for a Preferential rate.
The goods are accompanied by various documents, such as one or more bill of lading(s), customs transport documents such as a Transit document and/or e-AD, and other documents, such as origin documents. All documents are stored in our **Document Management System** with reference to the respective Activity. When **data from documents or incoming messages is needed** in our business process, this data is registered by means of **Cargo Documents**. This data is stored with the Parcel.
The **Cargo Document** functionality enables the **capture and recording of data** from physical documents or incoming electronic messages required to support business processes from a compliance perspective, with **the source document serving as the basis for all entered information**.
When a Movement is planned, the Activity is **Released to Ops**, triggering validation checks to confirm that all prerequisites for execution, including customs formalities, are in place. Upon this Release to Ops, all customs-relevant Movement data—comprising Parcel data related to the product in the source of the Movement and Parcel data related to the Product in the destination of the Movement —is transmitted to CMS, where the data is validated and subjected to checks. At this stage, **the Movement is not yet executed**. The checks performed are based on the information available at the time of release to OPS and may differ from the situation at the moment of actual execution. This functionality is therefore purely informative and is intended to highlight any relevant consequences requiring attention prior to execution.
**Checks at Release to OPS** are based on current data and **are informational only**, as actual execution may differ, and any resulting consequences requiring attention are highlighted at this stage.
Check at Release to OPS yet to be developed for ETA go-live
When receiving and handling goods at the terminal, the physical flow of goods is done by the start of pumping. Before doing so a mandatory step in the process is the so-called **Pre-Check**. The Pre-check is the final check done to validate all is in place to allow for the start of an operation, including customs formalities. As soon as this Pre-check is initiated, all data relevant to the Movement from a Customs perspective is send through to CMS via a so-called Transaction. CMS will validate the data, process it and produce all relevant customs declarations and/or records. In response to the Pre-check, CMS will inform the User in ATLAS that the Pre-check is approved and that, from a customs compliance point of view, the operation can commence.
From the Approved status, or any other status, the User can access the CMS page showing the relevant steps. In case of an Error, the User can identify where the error comes from and contact the customs colleagues to resolve any issue.
#### Services
Unlike Movements, Services are effectively administrative handlings. Because there is no physical pumping, the starting point is not a Pre-check, but the saving of the Service. As soon as a User saves the Service, a message is send to CMS in a similar fashion as the pre-check. In case of error, the Service will not save.
The following Services available in ATLAS relate to Customs compliance:
**Take in quantity**
When we want to take in a quantity while still on the MoT but at our facility (e.g., Vessel berthed at one of our licensed locations, truck or train available on our fenced facility), as soon as this Service is saved, the Parcel information is sent to CMS and the customs compliance handling is done. CMS will inform the User in ATLAS whether it is Approved yes or no. This way of processing applies to all Services.
**Rebrand**
This is the registration of a new Product, resulting from a blend process.
**Import**
This is the Release for Free Circulation.
**Administrative Stock Transfer**
The application of accounting segregation of our stock on the basis of origin and customs status.
**Shifting Service**
The moving of a MoT from one location within our Terminal locations to another. All locations are included in our customs licenses, such as jetties by virtue of our address and cadastral information and remote Buoys and/or jetties.
**Commodity code correction**
In practice there are situations that the sampling of Product result in a different Commodity code that should be used going forward. This is very exceptional, but it does happen. Examples are:
1. It concerns Products classified mainly on the basis of their aromatic content. Different approved methods apply, whereby the results can be different. We have seen some instances where the different methods lead to slightly different results, but with a difference that does matter for the classification;
2. Lines are never completely empty. Sometimes this can lead to slight changes in sulphur content for example, where again these minimal changes are decisive for classification purposes.
Hence, this Service allows for the correction and identification at all times.
**Departure**
When a MoT is loaded and all operations are completed, the MoT is ready to depart. The Departure Service includes the **Declare goods to Customs** whereby the relevant Parcel details are communicated to CMS and CMS informs the User in ATLAS on approval. When approved, relevant documents such as an Export declaration, Transit document and/or e-AD can be printed, including the emergency procedure versions.
The Departure Service includes the **Declare goods to Customs **whereby the relevant Parcel details are communicated to CMS and CMS informs the User in ATLAS on approval.
When approved, relevant documents such as an Export declaration, Transit document and/or e-AD can be printed, including the emergency procedure versions.
