# Update Annex AO/IC ATLAS-CMS
Document outlining the process governed through ATLAS and our Compliance Management System (CMS).
# Introduction
This document describes the Functional setup of our Terminal Management System (TMS) called ATLAS and its working in conjunction with our Compliance Managements System (CMS). With CMS, we implement processes and measures of internal controls to ensure compliance with the relevant legal requirements and updated systems on the side of the relevant authorities.
CMS is a an autonomous module/system built using the same standards as ATLAS (i.e. Oracle APEX). In the intermediate period, where Tomcat is still in production, CMS will be linked to Tomcat as source system. As Tomcat is phased out gradually, CMS is now also linked to ATLAS as the source system.
CMS will only be used by Terminals that offer Compliance services, such as Customs and Global Trade (CGT) services to their clients. Examples are lodging customs declarations, issuing customs documents such as customs transport documents or origin documents.
All Terminals globally have to deal with compliance requirements, but where the Terminal does not perform actual services in this matter, it merely keeps record of data relevant to the goods we handle. This is covered by the source system and is not in scope of CMS. Think of data around the goods we handle, such as:
1.
Commodity code;
2.
Customs status;
3.
Origin (preferential and non-preferential); and
4.
Reference numbers / cargo document data, among which customs documents.
With ATLAS in combination with CMS, customs processes are automated as much as possible.
| AO/IC
| Document describing the Administrative Organization and Measures of Internal Control, to which this document is an annex.
|
| CGT | Customs and Global Trade.
|
| CS | Customer Services team.
|
| CMS | Compliance Management System. |
| CPM | Commercial Policy Measures |
| DMS | Customs Management System of the Dutch Customs authorities used for lodging customs declarations and messages.
|
| EIDR | Entry Into the Declarants Records |
| NoP | Notification of Presentation message to present goods to Customs.
|
| MAB | Notice Expiration of Payment Term.
|
| OPS | Operations team.
|
| SKU | Stock Keeping Unit |
| TMS | Terminal Management System. |
| TSD | Temporary Storage Declaration (i.e. practically the customs declaration done by the agent on behalf of our customers, prior to the goods arriving at our terminal).
|
# 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.
Outlining the principles and the working of the CMS.
# Customs Procedure Operation
Each Parcel may require a different customs treatment, depending on the type of Operation performed. For that purpose, the first assessment done by CMS is determining the **Customs procedure** applicable to the **Operation**. This is done on the following basis:
Basically, when two Products mix, a distinction is made between Blends that involve Bonded goods and Blends that don't.
**Blends not involving Bonded Product**
In this case, the determination of whether the Operation concerns a Blend depends on whether or not the 8-digit Commodity Code of the products involved is the same. If yes, then the Operation relates to manufacturing. The type of manufacturing is dependent on the Customs status / Type of goods, where, when it involves Excise controlled Product, it is considered Manufacturing under Excise warehouse. When it involves only Domestic (i.e. not Excise controlled) Product then it is considered manufacturing under Free warehouse.
Upon registration of the Blend, the Customs status / Type of goods of the end Product determine the qualification of Manufactured under Excise warehouse for Excise controlled or Manufactured under Free warehouse for Domestic.
**Blends including Bonded product**
When a Blend does involve Bonded product, a check is done on the Commodity code on a 9-digit level. The reason for looking at the first 9 digits is that this relates to physical characteristics of Products that say something about the quality. For example, 2710 1948 10 versus 2710 1948 90 is different on the basis of sulphur content. 2710 1942 21 versus 2710 1942 29 is, respectively, "Consigned from Canada" and "other". Both paraffinic gas oils. Hence, the 10th digit relates to statistical information and not the physical characteristics.
When the Commodity codes are not the same on a 9-digit level, the **Customs Procedure Operation** is Inward processing, or, in specific cases a Usual Form of Handling. A Usual Form of Handling requires both the base Product and the Additive to be marked in the product database of CMS as Usual form of Handling.
When the 9-digit Commodity codes are the same, it could still be that the products involved are considered Products of a different quality. This is identified by Quality groups assigned to Products in the Product database in CMS. These quality groups are indicated by the Customer, the owner of the product, having extensive knowledge on quality. In case there are Quality groups assigned to the Parcels involved, then in case they are different, the result is a Blend and the customs procedure Inward Processing applies. In case no Quality Groups are available, the distinction is made on the basis of the (commercial / operational) Product name.
In case the Commodity code on 9-digit level is the same AND the Quality Groups (or Product names) of the Parcels are the same, then, in principle, the result is the Customs procedure Storage for the Operation. An exception to this rule is when it concerns both Bonded and non-Bonded / Union (i.e., Excise controlled or Domestic) Products AND the Bonded Products are subject to preliminary or definitive Anti-Dumping or Countervailing duties. In that case the Products, by law, may not be considered the same Commercial quality and hence it results in a Blend. As a result, the customs procedure Inward processing applies.
In any case, where the result of the assessment is a Customs Blend, where it involves both Bonded and non-Bonded, the User is informed that the operation will result in all Union goods becoming Bonded and the User must actively confirm its intentions.
# Business rules
Before starting an operation, the Products involved are declared when required. The determination on what Customs declaration(s) or records are required is based on implemented business rules. For each Transaction coming from ATLAS, the analysis and execution is made available to the user via a screen as included below **(Transaction details)**. Here the User can see what happened from a Customs point of view and find information relating to the Results.
#### Business rules
In the example above, the Product received is of the Bonded Customs status, discharged into a Tank containing the same Product. Therefore, the result is Storage. The applicable business rule in this case reads as follows:
- The first condition relates to the assessment of the Customs procedure for the operation. In this example, all Parcels are of the same Commodity code AND have the same Quality group "High aromatic oils" not Bonded Product subject to CPM. Hence, the result for the Customs Procedure Operation is Storage;
- The Product declared is of the T1 - Bonded Customs status;
- It is the first time the product on board of the Vessel arrives at the Terminal. This is recognized by the System on the basis of the Parcel not having a Parent reference. In case a parcel has a Parent reference, that means the Parcel comes from another Parcel we have registered before and hence, it is not the first time arrival;
- The Activity type is a Movement.
For the Product on board of the Vessel, all of the above conditions required are met and hence the goods are declared for Customs warehouse via EIDR. As required in relation to the EIDR, a NoP is send.
For the Product in tank, the criteria of "First time arrival" is not met and hence, the business rule does not apply. In the above example, the Parcels have already undergone this process at an earlier stage and are currently under Customs warehouse already for the Bonded Parcels and Free warehouse for the non Bonded Parcels.
# Customs declarations or records
The outcome of the business rules define what customs declarations are lodged or what records are recorded. In terms of declarations for the application of customs procedures, the main rule is that declarations are done by means of EIDR. Exceptions to this main rule are:
1. Export declarations (B1 and B4). These are done via the normal procedure; and
2. In case preferred or required by law the Import declaration (H1).
**Simplified Declarations (I1)**
Any declaration for the application of customs procedures, excluding Export, is done simplified, regardless of the way the declaration is done (i.e. via EIDR or normal procedure). Inherent to the nature of our business is that at the moment of declaring the goods, only planned quantities are known.
**Supplementary Declarations (H.)**
Any simplified declaration goes into our supplementary declaration process after entry into the record. Once the quantities are measured and final, ATLAS sends through the ACTUAL figures, and the supplementary declaration is created. The supplementary declarations for Inward processing and Release for Free Circulation are automatically sent in within 10 days after the entry. Below an example of the Processed Supplementary Declaration page:
All Declarations are available content wise from the Transaction Details page, the Declaration overview Page and the Supplementary declaration page. This includes an overview of the messaging and options for a User to utilize with regards to the specific Declaration. Below an example of the part of the Transaction Details Page where the Declarations are listed.
The Declarations can be selected to go to the Declaration details page.
**Content declarations**
The content of the declarations is determined on the basis of:
1. Input from the User on the basis of information received from the Customer via the Nomination. Such as the Product and its Commodity Code, the Customs status, the origin, the customs value, etc.;
2. The application of business rules. For example, in case of a Release for Free Circulation the procedure codes are determined on the basis of certain parameters. Below we have included an example where the Current Procedure Code is dictated by the fact that it concerns Excise controlled goods and the Previous Customs Code is based on the fact that it concerns goods coming from IP.
3. Defaults for Measure Types. Below some examples of default values for Measure Types, used in the event such Measure Type is applicable for the product declared.
# Reporting
This Chapter provides an overview of the primary reporting in CMS.
# Monitoring licenses
For the Customs warehouse and Inward processing license, the quantities and amounts licenses are monitored automatically. Each time a declaration is done under the respective procedure, the quantities and amounts are set off against the licensed quantity.
**Customs warehouse monitoring**
**Inward Processing monitoring**
# Bill of Discharge
For Inward Processing the discharge of the procedure is always by means of a Customs warehouse declaration. Each Inward Processing declaration is monitored via the Bill of discharge screen where the Product declared for Inward Processing is matched with the same Parcel(s) being, subsequently, declared for Customs warehouse. As it can very well be that T2 Products are used in an Inward Processing blend, not requiring an Inward Processing license, the full quantity of the specific Customs warehouse declaration may exceed the quantity of an Inward processing declaration. It could also be that multiple Inward processing declarations are discharged by the same Customs warehouse declaration. Below an example of the Bill of discharge screen.
# Detailed Stock Management
For internal audit purposes we have developed the so-called Detailed Stock Management (DSM) report. The DSM report shows all relevant data related to the Products we handle and the Declarations we have lodged. The data set is a combination of data coming from CMS, which relates to all Transactions communicated by ATLAS to CMS, and data coming from ATLAS. This concerns data that is not part of the data set communicated via the Transactions from ATLAS, such as stock density corrections, opening and closing balance, etc.
**Business rules and mutations**
Apart from the physical Movements, the data set also includes the accounting for the goods under the various customs procedures / regimes. For this purpose, each business rule includes Mutations. Below we have included an example of a discharge that leads to the placing of the goods under the Customs warehouse procedure, directly followed by the placing under the Inward Processing procedure. This means a physical Movement leads to a + in the Customs warehouse, which is directly depleted (-) and followed by a + under Inward Processing.
When such blend would be completed and registered by means of a Rebrand Service (i.e. registration of the blend), it would result in the placing of the End product under the Customs warehouse procedure again, coming from the Inward Processing procedure. Mutation wise this means the depletion (-) of the components and a + for the newly registered product as processed good under Inward Processing, which subsequently is depleted (-) under Inward Processing and placed under the Customs warehouse procedure (+).
These mutations can be summarized in the following overview.
The DSM report forms the 'single version of the truth, where all other reporting is always based on the data showing in the DSM. In the event that any report requested should include data not included in the DSM, then it will be added to the DSM first and from there added to any subsequent report.
# Audit file
The Audit File Voorraad is a report required by the Dutch Customs authorities, in which all relevant information in relation to the inventory and customs declarations is listed in a specific format as specified in the MIG. Effectively, **the Audit File is a translation of the data coming from our DSM report** into a specific format.
With the available test environments, proper testing of the Audit File was not possible. Furthermore, we started with CMS (V1) connected to our legacy TMS Tomcat. As the building of Audit File is quite substantial and given the dependency on the source system, we have a agreed with Customs to not invest in developing Audit File under Tomcat - CMS V1 as Tomcat is shortly being discontinued. Under Tomcat-V1 we still have the GPA available safeguarding the record keeping requirements.
ATLAS has only gone live since the 1st of December 2025. It is since then that we could properly test the data becoming available in the Audit File report. Although the Audit File report has been available from a technical point of view, we are currently finalizing the population of the various tables with the correct data. Below we have include the current status and the parts that we are working on.
## Completed
- Full Technical report - To be validated by the Customs authorities;
- All data related to discharges and loads;
- **Transaction Associated Documents.** All documents for the declaration systems DMS, NCTS, and EMCS are included in the audit file.
From the Audit File report page the Audit file can be generated for a specific month.
Once created, the report becomes available in draft.
Under the three dots the report can be finalized, after which the period will also be blocked. under Downloads the file can be downloaded to share with the Customs authorities.
##
## To be completed
**Balance data (inv\_period\_balance)**
- Records with location type **INLAND\_WATER**. This concerns vessels that have been loaded or discharged at our site. In these cases there is no opening or closing stock (*beginning\_quantity* and *ending\_quantity*). The question is whether we should include received and dispatched quantities. From the terminal’s perspective, this is a kind of storage location. We will report Product as stock in cases where, in case of incoming, we have declared goods on board without a movement. The same principle applies to loads as long as there is no completed Departure. We assume in other cases, where we have not taken any responsibility for the products (yet) no reporting is required?
- For trains, blending takes place on the wagon. The wagon receives base product and additive, after which the end product is dispatched. The additional rows (mutations) that are required to track the transfer between procedures (USF – usual form of handling) still require implementation in Audit File.
- Inventory should reconcile per row (*ending\_quantity = beginning\_quantity + received\_quantity – dispatched\_quantity*). This currently not yet the case. For *cust\_transfers* (production (ETW), inward processing, and usual form of handling), t
he additional rows (mutations) that are required to track the transfer between procedures needs implementation in the audit file. The data required for this is already available in our *detailed\_stock\_movements\_cu* table. This concerns movements between procedures.
- Movements between tanks (tank-to-tank transfers) are not fully completed yet. Also here the mutations need implemetation into the Audit File.
**Transactions (inv\_transaction and inv\_transaction\_char)**
- Tank-to-tank movements have not yet been included in the audit file. The required setup in the business rule mutation configuration has not yet been added to Audit File.
- Due to the missing setup of the mutations, the chain that allows goods to be traced from CPW to IPR, IPR production, and back to CPW is not yet fully implemented.
This also applies to USF (usual form of handling).
- In the case of a density correction, we set the value **CT** in the characteristic *NL\_CUST\_TRANSFER*. However, this does not correspond to the description (“correction due to temperature difference”). The code CT seemed the most appropriate to us.
**Products (inv\_product and inv\_product\_char)**
- New goods that are created through blending require implementation of the mutations (see comment under Transactions regarding IPR and USF).
**Transaction Associated Documents**
- The other documents mentioned in code list 6 (*codelist trans.submsyst*) and code list 6 (*codelist document code*) are still being reviewed by us to determine whether they are applicable to our situation.
**Points of attention**
- The specifications mention a number of columns and characteristics required to track goods with regard to movements (between procedures). We are testing whether this works correctly in all cases. The plan is to create an automated check for this in the future.
- During the Deloitte GTA session on Thursday, 20 November, Customs indicated in their presentation what types of validations/checks they perform on the submitted data. Building similar checks is on our roadmap.