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". 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.   Core System Concepts The system is based on a set of core concepts that together represent the physical and administrative handling of Product within terminal operations. Visit – Represents a Means of Transport (MOT) and its time of arrival. A single MOT may execute multiple Visits over time. Visits form the temporal and operational entry point for incoming or outgoing Product flows. Product – Represents the physical substance (molecules) being handled, such as bulk liquids. Product is the base physical entity on which all operational and administrative processes are applied. Storage Unit – Represents a physically segregated storage entity for Product. Storage Units ensure physical separation of Product and define how it is stored. Examples include: A Tank, which is a single Storage Unit; A Vessel, which may contain multiple segregated Storage Units; A Train, where wagons function as individual Storage Units; A Truck, where separate compartments can each represent distinct Storage Units containing different Products. Location – Defines where Activities are executed. Locations are relevant for operational control and for compliance with applicable licenses and regulatory requirements. Activity – Represents all operational actions performed on Product within the system. Activities include all forms of handling, transformation, movement, storage, or processing of Product across Visits, Storage Units, and Locations. Together, these concepts form the foundational structure for representing physical flows and their administrative and compliance-related processing within the system. Activities For each Activity, whether a Movement or a Service, ATLAS provides information on all Products involved. In the case of Services, where no physical transfer of goods takes place between locations, the data relates to Parcel information within a Storage Unit (for example, a Tank or a Vessel). In the case of a Movement, at least two Storage Units are involved, and ATLAS provides Parcel data for all Products participating in the transfer between these Storage Units. As further described under “Business Process”, the following list of Activities is used to support the record-keeping requirements from a customs compliance perspective: Movement; 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: Movements . Which concerns physical movement of goods; and/or 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: validate if the concerned Product falls within the scope of our licenses; check if certain prohibitions / restrictions apply;  what documents can be expected; and 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 . Movements 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: 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; 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. 

Parcel administration
The parcel administration model distinguishes between three separate business concepts: Product , Parcel , and Stock Keeping Unit (SKU) . Although a Parcel may in some situations correspond to a single SKU, these concepts are fundamentally different and can not be treated as interchangeable within the system. The three layers are defined as follows: Product – The physical commodity handled at the terminal, such as gas oil, gasoline, or naphtha. Parcel – The administrative representation of a physical product. A Parcel records characteristics such as commodity code, customs status, origin, cargo documents and, where applicable, consignor or consignee information. Stock Keeping Unit (SKU) – An administrative unit used for inventory management and record-keeping purposes. SKUs support stock administration but do not define the legal or logistical identity of a Parcel. 
 Parcel creation for incoming products For incoming products, the User registers the received physical product by creating one or more Parcels. Each Parcel serves as an administrative reflection of the product and captures attributes such as the commodity code, customs status, and origin. These attributes alone do not determine the number of Parcels that must be created. Even where multiple quantities of product share identical administrative characteristics, the User may decide to register them as separate Parcels. Consequently, the creation and granularity of Parcels for incoming receipts are driven by the User's administrative requirements rather than solely by the product characteristics. 
 Parcel creation for outgoing products The same principle applies to the dispatch of goods. When product is loaded for shipment, the User creates one or more Parcels to represent the administrative distribution of the physical product. For example, 15,000 MT of gasoline with a T1 (non-Union) customs status may be loaded, with 5,000 MT destined for one terminal and 10,000 MT destined for another. Although both quantities have the same commodity code, customs status, and origin, separate Parcels are created because they are intended for different consignees or destinations and are accompanied by different transport or customs documentation. The User determines the required Parcel structure based on the operational and documentary requirements of the shipment. The Parcel  is defined when Products are registered by the User as these are carried by the Means of Transport including administrative characteristics such as Commodity code, customs status, origin, cargo documents, consignee, etc. Parcel Administration During Product Movements For product handling, the creation and movement of Parcels is driven by the physical product being processed and its customs status. In these scenarios, the IT system determines the Parcels based on the administrative composition of the stock being moved. For example, a Vessel or a tank containing 7,000 MT of gasoil may consist of 3,000 MT with T1 customs status and 4,000 MT with T2 customs status. When more than 4,000 MT is moved, the operation results in the movement of two separate Parcels, reflecting the two different customs statuses. Where a Parcel contains multiple underlying SKUs, such as SKUs with different origins, the associated SKUs follow the Parcel movement according to the First In, First Out (FIFO) allocation methodology. As a result, the Parcel defines the administrative movement of the product, while the SKUs are allocated within that Parcel in FIFO order to maintain accurate inventory records and traceability. The administration of Parcels for liquid bulk operations requires a dynamic approach because the physical quantity moved during an operation is not known until the operation has been completed. At the same time, customs legislation requires that goods are declared and presented before the operation takes place, as subsequent blending or commingling may make it impossible to distinguish the originally declared goods. 
 Initial Parcel determination Prior to the start of a movement, the IT system determines the Product and the corresponding Parcel or Parcels based on the planned quantity. The determination is performed using the inventory position as it exists immediately before the operation commences. At this point, the system queries the record keeping to identify all relevant Parcels and their administrative characteristics, including customs status. Based on this assessment, the required customs declarations can be prepared and lodged before the physical movement starts. The quantity used during this initial assessment is an estimated or planned quantity. The actual transferred quantity cannot yet be established. Determination of the actual quantity In liquid bulk operations, the actual moved quantity is established only after completion of the physical operation. The quantity may be determined through: Tank measurements before and after the operation; Flow meter readings; or Weighbridge measurements. Only after these measurements have been completed can the definitive quantity of Product and the corresponding Parcel allocation be determined. Retrospective Parcel validation Once the actual moved quantity is known, the IT system performs a retrospective validation of the Parcel administration. This validation reassesses which Parcels should have been moved based on the inventory situation that existed immediately before the operation started, rather than the inventory situation at the time the reassessment is executed. This temporal consistency is essential because customs declarations are based on the goods that were presented immediately prior to the operation. Consequently, the reassessment must use the same point-in-time inventory snapshot as the initial determination. In practice, the Product already present in the receiving tank is treated as a fixed condition that existed before the movement and therefore remains unchanged for purposes of the reassessment. Once the moved quantity has been measured, the final quantity is established and the circumstances of the Activity are reassessed retrospectively based on the situation as it existed at the start of execution. Parcel identity and corrections Each Parcel must have a unique reference that identifies the represented Product and its associated customs status. This unique reference should remain unchanged between the initial assessment before the operation and the retrospective validation after completion. In most cases, the retrospective validation will confirm the initial Parcel determination, with only the moved quantity requiring adjustment. In exceptional circumstances, however, the final measured quantity may lead to a different Parcel composition than originally anticipated. For example, an operation initially expected to involve a single Parcel may ultimately require two Parcels because the final quantity spans different customs status boundaries, or vice versa. As a result, customs declarations may in some cases not be lodged prior to the start of the operation, or may in hindsight have been created when they were not required. In such cases, the IT system must correct the Parcel administration and any associated customs declarations while preserving the original assessment timestamp representing the moment immediately before the operation commenced. This ensures both an accurate inventory administration and a legally consistent customs audit trail. Customs compliance risk is controlled at Product entry (license validation), while operational accuracy is ensured retrospectively through measured quantities and Parcel reconciliation. In the near future it is expected that declarations for certain Products must be declared real-time via the Normal procedure instead of by means of Entry Into the Declarants Record (EIDR). In that case correction will be more cumbersome!  Customs declaration validation During the preparation of an Activity, the system determines the customs obligations associated with the identified Parcel(s). This includes identifying the required customs procedure based on the Product characteristics, including commodity code and customs status. As part of this process, the system validates whether the Parcel(s) involved in the Activity have already been declared under the required customs procedure. If a Parcel has already been covered by an existing declaration for the applicable procedure, no new declaration is created for that Parcel within the scope of the Activity. This validation ensures that customs declarations are only created where necessary and prevents duplication of declarations for Parcels that have already been correctly declared under the relevant customs regime.