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: Commodity code; Customs status; Origin (preferential and non-preferential); and Reference numbers / cargo document data, among which customs documents. With ATLAS in combination with CMS, customs processes are automated as much as possible.

Abbreviations
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". 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.

Compliance management
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: Export declarations (B1 and B4). These are done via the normal procedure; and 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: 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.; 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. 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.

Technical specifications
To include

Main communication Source system to CMS - Transaction JSON
The Transaction JSON is the standardized interface used by the source system to communicate business and operational data to the customs management system. It contains all relevant information relating to a logistics activity, such as the movement of goods, transport details, involved parties, storage locations, and the products or parcels that are part of the transaction. The information contained in the Transaction JSON serves as the primary input for the creation of customs declarations and other compliance-related processes. Each message must accurately represent the underlying business transaction and include all data required to determine the correct customs treatment of the goods. The quality, completeness, and timeliness of the data provided are critical. Incorrect, incomplete, or delayed information may result in inaccurate customs declarations, non-compliance with customs legislation, delays in the supply chain, financial penalties, or increased audit risks. It is therefore the responsibility of the source system and the data provider to ensure that: all mandatory data elements are populated correctly; the information reflects the actual business transaction and physical movement of the goods; product and parcel details, including commodity classifications, origin, quantities, and supporting documents, are accurate and up to date; changes affecting the transaction are communicated promptly to the customs management system. By providing reliable and timely Transaction JSON messages, organizations can support compliant customs processes, minimize operational risks, and ensure efficient processing of import, export, transit, and storage activities. ​ JSON Field Business Name Description Mandatory Customer Data Source Example Value sourceApplication Source System System from which the data originates. Yes Internal integration ATLAS terminal Terminal Terminal or operational location where the goods are handled. Yes Terminal Operator / WMS ETT reference Movement Reference Unique reference for the movement or customs transaction. Yes ERP / WMS PR_ACTI_AC10007466 displayReference Display Reference Human-readable reference shown to users. Yes ERP AC 007 466 taxCountry Customs Country Country where the customs process takes place. Yes ERP NL cmsReference CMS Reference Internal customs management reference. Yes Internal system 530E2446-… overrideCheckAlert Override Indicator Indicates whether validation warnings have been overridden. Yes Internal system Y presentationDateTime Presentation Date & Time Date and time when goods are presented to Customs. Yes Terminal / WMS 2026-05-30T20:59:17Z Activity JSON Field Business Name Description Mandatory Customer Data Source Example Value activities.reference Activity Reference Unique identifier of the activity. Yes ERP PR_ACTI_AC10007466 activities.displayReference Activity Display Reference User-friendly activity number. Yes ERP AC 007 466 activities.activityType Activity Type Type of activity. Movement or Service. Yes ERP MOVEMENT activities.nominationReference Nomination Reference Unique identifier of the activity  nomination. Conditional Scheduling system NM 004 824 activities.relatedReference Related Reference Reference to a related movement. No ERP — Storage Unit / Transport JSON Field Business Name Description Mandatory Customer Data Source Example Value medium.type Movement Direction Indicates source or destination storage. Yes WMS FROM_STORAGE_UNIT storageUnit.storageUnitReference Storage Unit Reference Identifier of the storage location. Yes WMS VS10003221:1 visit.visitReference Visit Reference Identifier of terminal visit of the means of transport. Conditional Terminal system VS 003 221 visit.transportMeansReference Transport Means Name Name of vessel or vehicle. Yes Shipping documents MARAN WIND visit.transportMeansTypeCode Transport Means Type Mode of transport code. Yes Shipping documents VES visit.transportMeansNationalityCode Transport Means Nationality Registration or flag country. Conditional Shipping documents BS tank.tankName Tank Name Receiving or storage tank identifier. Conditional Terminal / WMS T08 Goods Item (Parcel) JSON Field Business Name Description Mandatory Customer Data Source Example Value parcels.reference Goods Item Reference Unique goods item identifier. Yes ERP 2605/SKU20:59… parcels.parentReference Parent Reference Parent goods item reference. No ERP 2605/SKU08:07… parcels.firstTimeArrival First Arrival in EU Indicates first arrival into the EU customs territory. Conditional Customs process Y parcels.inwardProcessingFlag Inward Processing Indicates Inward Processing procedure. Conditional Customs department N parcels.commercialPolicyMeasureFlag Commercial Policy Measure Indicates trade policy measures apply. Conditional Customs department N parcels.exceptionDocument Exception Document Supporting exemption document reference. Conditional Compliance — Customer Information JSON Field Business Name Description Mandatory Customer Data Source Example Value parties.customer.reference Customer Code Internal customer identifier. No ERP COMP parties.customer.name Customer Name Name of importer/exporter. Yes Master data Company A parties.customer.eori EORI Number EORI registration number. Yes Master data NLXXX parties.customer.vatNumber VAT Number VAT registration number. Conditional Master data NLXXX parties.customer.language Preferred Language Customer language. No Master data NL parties.customer.address.streetName Street Customer street name. Yes Master data Weena parties.customer.address.houseNumber House Number Customer house number. Yes Master data 690 parties.customer.address.postalCode Postal Code Customer postal code. Yes Master data 3012CN parties.customer.address.cityName City Customer city. Yes Master data Rotterdam parties.customer.address.countryCode Country Customer country. Yes Master data NL parties.customer.cbsCode Statistical Code Statistical reporting code. No Master data 49933 parties.customer.locationName Location Name Named business location. No Master data — Goods Location JSON Field Business Name Description Mandatory Customer Data Source Example Value location.address.streetName Goods Location Street Street where goods are located. Yes WMS Moezelweg location.address.houseNumber Goods Location House Number House number. Yes WMS 151 location.address.postalCode Goods Location Postal Code Postal code. Yes WMS 3198 LS location.address.cityName Goods Location City City of storage. Yes WMS Europoort Rotterdam location.address.countryCode Goods Location Country Country where goods are stored. Yes WMS NL location.cbsCode Goods Location Statistical Code Statistical location code. No WMS 325 location.locationName Goods Location Name Name of warehouse or facility. No WMS — Country Information JSON Field Business Name Description Mandatory Customer Data Source Example Value destinationCountryCode Country of Destination Final destination country. Yes Commercial documents NL dispatchCountryCode Country of Dispatch Country from which goods are dispatched. Yes Commercial documents GB origin.type=NON-PREFERENTIAL.countryCode Non-Preferential Origin Customs country of origin. Yes Supplier declaration GB origin.type=PREFERENTIAL.countryCode Preferential Origin Preferential origin under trade agreement. Conditional Origin certificate — Commodity Information JSON Field Business Name Description Mandatory Customer Data Source Example Value commodity.code Commodity Code HS/CN/TARIC classification. Yes Product master 2709009000 commodity.description Commodity Description Commercial description of goods. Yes Product master Kraken Crude Oil commodity.reference Product Reference Internal product identifier. No Product master — customsStatus Customs Status Customs status of the goods. Yes Customs/WMS BONDED Supporting Documents JSON Field Business Name Description Mandatory Customer Data Source Example Value cargoDocuments.type Document Type Type of supporting document. Conditional Shipping documents B_L cargoDocuments.reference Document Reference Reference number of the document. Conditional Shipping documents 003 221 cargoDocuments.quantities.kgv Document Gross Weight Gross weight on document. Conditional Bill of Lading 33,000,000 cargoDocuments.quantities.l15 Document Volume @15°C Standard volume on document. Conditional Bill of Lading 33,863,520 cargoDocuments.quantities.mtv Manifest Quantity Quantity from manifest. Conditional Cargo manifest 33,000,000 Quantity Information JSON Field Business Name Description Mandatory Customer Data Source Example Value quantities.type Quantity Type Actual or estimated quantity. Yes Measurement system ACTUAL quantities.kgv Gross Weight (kg) Gross weight including packaging. Yes Weighbridge / WMS 5,501,823 quantities.kga Net Weight (kg) Net weight excluding packaging. Yes Weighbridge / WMS 5,495,622 quantities.gmv Gross Mass Volume Gross mass volume, where applicable. Conditional Measurement system — quantities.gma Actual Gross Mass Measured gross mass. Conditional Measurement system — quantities.l15 Volume @15°C Volume corrected to 15°C. Conditional Metering system 5,636,892 quantities.l20 Volume @20°C Volume corrected to 20°C. Conditional Metering system 5,655,158 quantities.ml5 Alcohol Volume @5°C Alcohol volume at 5°C. Conditional Laboratory — quantities.alcPerc Alcohol Percentage Alcohol strength by volume. Conditional Laboratory — Product Characteristics JSON Field Business Name Description Mandatory Customer Data Source Example Value density.value Density Measured product density. Conditional Laboratory 0.845 density.uom Density Reference Reference basis for density measurement. Conditional Laboratory D15 unNumber UN Number Dangerous goods UN classification number. Conditional Safety Data Sheet (SDS) 1203 Example JSON structure {   "sourceApplication": "ATLAS",   "terminal": "ETT",   "reference": "MVM000012345",   "displayReference": "MVM 012 345",   "taxCountry": "NL",   "cmsReference": "12345678-ABCD-1234-EFGH-987654321000",   "overrideCheckAlert": "N",   "presentationDateTime": "2026-01-15T10:30:00Z",   "activities": [     {       "reference": "MVM000012345",       "displayReference": "MVM 012 345",       "activityType": "MOVEMENT",       "nominationReference": "NOM00056789",       "relatedReference": null,       "medium": [         {           "type": "FROM_STORAGE_UNIT",           "storageUnit": {             "storageUnitReference": "STORAGE_A01",             "visit": {               "visitReference": "VISIT001234",               "transportMeansReference": "MV EXAMPLE STAR",               "transportMeansTypeCode": "VES",               "transportMeansNationalityCode": "NL",               "changedTransportArrangement": null             }           },           "parcels": [             {               "reference": "PARCEL000001",               "parentReference": null,               "firstTimeArrival": "Y",               "inwardProcessingFlag": "N",               "commercialPolicyMeasureFlag": "N",               "exceptionDocument": null,               "parties": {                 "customer": {                   "reference": "CUST001",                   "name": "Example Trading B.V.",                   "eori": "NL123456789000",                   "vatNumber": "NL123456789B01",                   "language": "EN",                   "address": {                     "cityName": "Rotterdam",                     "countryCode": "NL",                     "streetName": "Example Street",                     "postalCode": "3011AA",                     "houseNumber": "100"                   },                   "cbsCode": "12345",                   "locationName": "Head Office"                 }               },               "location": {                 "language": "EN",                 "address": {                   "cityName": "Rotterdam",                   "countryCode": "NL",                   "streetName": "Harbour Road",                   "postalCode": "3199AA",                   "houseNumber": "1"                 },                 "cbsCode": "325",                 "locationName": "Tank Farm A"               },               "destinationCountryCode": "NL",               "dispatchCountryCode": "US",               "origin": [                 {                   "type": "NON-PREFERENTIAL",                   "countryCode": "US"                 },                 {                   "type": "PREFERENTIAL",                   "countryCode": null                 }               ],               "commodity": {                 "code": "2709009000",                 "description": "Crude Petroleum Oil",                 "reference": "MAT-0001"               },               "customsStatus": "BONDED",               "cargoDocuments": [                 {                   "type": "B_L",                   "reference": "BL123456789",                   "quantities": [                     {                       "kgv": 1000000,                       "l15": 1185000                     }                   ]                 },                 {                   "type": "MANIFEST_INFO",                   "reference": "MANIFEST001",                   "quantities": [                     {                       "mtv": 1185000                     }                   ]                 }               ],               "unNumber": "1267",               "quantities": [                 {                   "kgv": 1000000,                   "kga": 995000,                   "gmv": null,                   "gma": null,                   "l15": 1185000,                   "l20": 1192000,                   "ml5": null,                   "alcPerc": null,                   "type": "ACTUAL"                 }               ],               "density": {                 "value": 0.840,                 "uom": "D15"               }             }           ]         },         {           "type": "TO_STORAGE_UNIT",           "storageUnit": {             "storageUnitReference": "TANK_101",             "tank": {               "tankName": "Tank 101"             }           },           "parcels": [             {               "reference": "PARCEL000002",               "parentReference": "PARCEL000001",               "firstTimeArrival": "N",               "inwardProcessingFlag": "N",               "commercialPolicyMeasureFlag": "N",               "exceptionDocument": null,               "parties": {                 "customer": {                   "reference": "CUST001",                   "name": "Example Trading B.V.",                   "eori": "NL123456789000",                   "vatNumber": "NL123456789B01",                   "language": "EN",                   "address": {                     "cityName": "Rotterdam",                     "countryCode": "NL",                     "streetName": "Example Street",                     "postalCode": "3011AA",                     "houseNumber": "100"                   },                   "cbsCode": "12345",                   "locationName": "Head Office"                 }               },               "location": {                 "language": "EN",                 "address": {                   "cityName": "Rotterdam",                   "countryCode": "NL",                   "streetName": "Harbour Road",                   "postalCode": "3199AA",                   "houseNumber": "1"                 },                 "cbsCode": "325",                 "locationName": "Tank Farm A"               },               "destinationCountryCode": "NL",               "dispatchCountryCode": "US",               "origin": [                 {                   "type": "NON-PREFERENTIAL",                   "countryCode": "US"                 },                 {                   "type": "PREFERENTIAL",                   "countryCode": null                 }               ],               "commodity": {                 "code": "2710194300",                 "description": "Gas Oil",                 "reference": "MAT-0002"               },               "customsStatus": "BONDED",               "cargoDocuments": [],               "unNumber": "1202",               "quantities": [                 {                   "kgv": 500000,                   "kga": 497500,                   "gmv": null,                   "gma": null,                   "l15": 595000,                   "l20": 598000,                   "ml5": null,                   "alcPerc": null,                   "type": "ACTUAL"                 }               ],               "density": {                 "value": 0.835,                 "uom": "D15"               }             }           ]         }       ]     }   ] }

Business rules to determine customs declarations required for all Products involved in the Activity
1. Overall Structure of the Rules All business rules follow a consistent pattern: Rule Logic Each rule is evaluated using: 
 IF → starting condition 
 AND / OR → additional conditions 
 Conditions are based on:
 
 Customs status (e.g. BONDED, EXCISE_CONTROLLED, DOMESTIC) 
 Destination (EU, EFTA, non-EU, special territories) 
 Activity type (MOVEMENT, TAKE_IN, DEPARTURE, etc.) 
 Procedure (EXPORT, RE-EXPORT, STORAGE, INWARD_PROCESSING, etc.) 
 Flags (e.g. first arrival, monthly approval) 
 
 
 Rule Outcome Each rule determines: 
 Required customs procedure 
 Required documents 
 Required system message / record 
 Final warehouse or closing process 
 2. Export Rules (Functional Description) Export rules are primarily driven by: 
 Customs status of goods 
 Destination 
 Transport specifics 
 Excise applicability 
 2.1 Excise-Controlled Goods (AAD) Scenario Goods are under excise suspension and must remain controlled during movement. Functional Logic 
 IF goods are excise controlled 
 AND movement is export 
 THEN apply excise + customs requirements depending on destination 
 Outcomes by Destination A. Export to Non‑EU 
 Documents: 
 
 e-AD (excise) 
 Export declaration (EX A - B1) 
 
 
 Logic: 
 
 e-AD is discharged by export declaration 
 Export declaration is discharged by confirmation of exit 
 
 
 Purpose: 
 
 Maintain excise suspension until exit 
 
 
 B. Export to EFTA+ 
 If no transit possible (sea-only routes) :
 
 Same as non-EU export 
 
 
 If transit required (crossing EU) :
 
 Add Transit document (T2) 
 Export → Transit sequence 
 
 
 C. Export to Special Territories (Customs / VAT Exceptions) Different combinations lead to B4 declarations : Territory Type Outcome Customs territory only Export (B4) + T2LF Customs + Excise Export (B4) + T2LF Customs + Excise + VAT No export declaration D. Movement within EU 
 Standard case: 
 
 e-AD required 
 
 
 Exception (VAG): 
 
 Monthly declaration replaces e-AD 
 
 
 E. Pipeline Transport (Excise Goods) 
 If monthly approval:
 
 VAGD (monthly declaration) 
 No e-AD 
 
 
 2.2 Domestic (Free Circulation) Goods Scenario Goods are not subject to excise. Functional Logic 
 IF goods are DOMESTIC 
 AND movement is export 
 Outcomes A. Export to Non‑EU 
 Document: Export declaration (B1) 
 No e-AD required 
 Proof of exit discharges liability 
 B. Export to EFTA+ 
 Same as export to non-EU 
 Transit applies if crossing EU:
 
 Add T2 transit document 
 
 
 C. Export to Special Territories 
 Use B4 declaration 
 Add T2LF or T2L to prove Union status 
 D. Movement within EU 
 No customs declaration 
 Goods remain in free circulation 
 E. Pipeline Transport 
 No customs requirements 
 2.3 Bonded Goods (T1 – Non-Union) Scenario Goods are not in free circulation and require customs supervision. Functional Logic 
 IF goods are BONDED 
 AND procedure is RE-EXPORT or movement 
 Outcomes A. Re-export to Non‑EU 
 Document: Re-export declaration (B1) 
 Confirmation of exit required 
 B. Re-export to EFTA+ 
 Without transit → same as above 
 With EU crossing:
 
 Add Transit document (T1) 
 
 
 C. Movement within EU 
 Transit procedure (T1) mandatory 
 D. Internal Movement (VAG Exception) 
 No transit declaration 
 Use VAG document 
 E. Pipeline Transport 
 Considered automatically under transit 
 No T1 document required 
 3. Import Rules (Functional Description) Import rules are driven by: 
 Customs procedure 
 Customs status 
 First arrival vs subsequent movements 
 Operational activity (storage, blending, processing) 
 3.1 First Arrival of Bonded Goods A. Storage (No processing) 
 Condition: 
 
 First arrival = YES 
 No blending 
 
 
 Outcome: 
 
 Entry into Customs Warehouse 
 Notification of Presentation 
 
 
 B. Usual Forms of Handling (UFH) 
 Condition: 
 
 Blending allowed under warehouse rules 
 
 
 Outcome: 
 
 Remains under Customs Warehouse 
 Classified as UFH 
 
 
 C. Inward Processing 
 Condition: 
 
 Blending requiring processing license 
 
 
 Outcome: 
 
 Customs Warehouse → Inward Processing 
 Requires additional declaration 
 
 
 3.2 Subsequent Movements (After First Arrival) A. Inward Processing 
 Applies when:
 
 Goods are blended with other qualities 
 
 
 Outcome:
 
 Declared under Inward Processing 
 
 
 B. Usual Forms of Handling 
 Applies when:
 
 Blending fits UFH criteria 
 
 
 Outcome:
 
 Remains within Customs Warehouse 
 
 
 3.3 Administrative Stock Transfers Purpose Avoid physical segregation using accounting reallocation. Logic 
 IF activity = Administrative Stock Transfer 
 AND target status includes BONDED 
 Outcome 
 Reallocation of customs status:
 
 From Bonded → Excise or Domestic (or vice versa) 
 
 
 No physical movement required 
 3.4 Release for Free Circulation (General Concept) 
 Converts T1 (non-Union) → T2 (Union goods) 
 May:
 
 Trigger customs debt 
 Transfer goods into:
 
 Free warehouse 
 Excise warehouse 
 
 
 
 
 3.5 Excise Warehouse Handling 
 For excise-controlled goods:
 
 Entry into excise warehouse 
 Possible:
 
 Storage 
 Manufacturing 
 Blending 
 
 
 
 
 3.6 Internal Activities A. Shifting 
 Internal movement within same warehouse 
 No customs impact 
 B. Rebranding 
 Creates new product identity 
 Typically remains under same procedure 
 C. Commodity Code Correction 
 Administrative correction 
 May impact:
 
 Customs classification 
 Warehouse allocation 
 
 
 4. Key Concepts Across All Rules Customs Status Types 
 BONDED (T1): Non-Union goods 
 EXCISE_CONTROLLED: Goods under excise suspension 
 DOMESTIC (FRE): Union goods in free circulation 
 Core Procedures 
 Export / Re-export 
 Transit (T1 / T2) 
 Customs Warehouse 
 Excise Warehouse 
 Inward Processing 
 Usual Forms of Handling 
 Exception Mechanisms 
 VAG / VAGD: Monthly declarations replacing standard documents 
 Pipeline transport: Simplified treatment 
 Administrative stock transfer: Accounting-based status change 
 Document Types 
 e-AD: Excise movement 
 EX A (B1/B4): Export declaration 
 T1 / T2: Transit 
 T2L / T2LF: Proof of Union status 
 VAG / VAGD: Monthly declaration 
 5. Simplified Rule Classification Category Key Driver Outcome Export Destination + status Export / Transit / e-AD Import Procedure + activity Warehouse / Processing Exception Approval flags Simplified procedure Internal Activity type No declaration or reassignment 6. Key Takeaway The entire rule engine can be summarized as: 
 Determine the customs status + movement type + destination → select the correct procedure → generate the required documents → ensure proper discharge (exit, transit, or warehouse accounting).

Business rules overview CMS
Code Title Result (Customs) procedure result (Closing record) Conditions IMP_BR01 Bonded goods – First arrival, storage in Customs Warehouse NOP:IE507 CUSTOMS_WAREHOUSE • Customs procedure operation = STORAGE • Status = BONDED • First arrival flag = Y • Activity type = MOVEMENT / TAKE_IN IMP_BR02 Bonded goods – First arrival with UFH NOP:IE507 + CW:UFH USUAL_FORMS_OF_HANDLING • Customs procedure operation = USUAL_FORMS_OF_HANDLING • Status = BONDED • First arrival flag = Y • Activity type = MOVEMENT IMP_BR03 Bonded goods – First arrival with Inward Processing NOP:IE507 + IP:IE015 INWARD_PROCESSING • Customs procedure operation = INWARD_PROCESSING • Status = BONDED • First arrival flag = Y • Activity type = MOVEMENT IMP_BR04 Administrative stock transfer – Excise controlled goods to Bonded ADMIN (No message) N/A • Activity type = ADMINISTRATIVE_STOCK_TRANSFER • Status = EXCISE_CONTROLLED • Transferred customs status contains BONDED IMP_BR05 Administrative stock transfer – Domestic goods to Bonded ADMIN (No message) N/A • Activity type = ADMINISTRATIVE_STOCK_TRANSFER • Status = DOMESTIC • Transferred customs status contains BONDED IMP_BR06 Bonded → Inward Processing (to storage unit) IP:IE015 INWARD_PROCESSING • Customs procedure operation = INWARD_PROCESSING • Status = BONDED • First arrival flag = N • Previous closing record ≠ INWARD_PROCESSING • Activity type = MOVEMENT • Medium type = TO_STORAGE_UNIT IMP_BR06A Bonded → Inward Processing (from storage) IP:IE015 INWARD_PROCESSING • Customs procedure operation = INWARD_PROCESSING • Status = BONDED • First arrival flag = N • Previous closing record ≠ INWARD_PROCESSING • Activity type = MOVEMENT • Medium type = FROM_STORAGE_UNIT IMP_BR07 Bonded goods – UFH (subsequent movement) CW:UFH USUAL_FORMS_OF_HANDLING • Customs procedure operation = USUAL_FORMS_OF_HANDLING • Status = BONDED • First arrival flag = N • Previous closing record ≠ USUAL_FORMS_OF_HANDLING • Activity type = MOVEMENT • Medium type = TO_STORAGE_UNIT IMP_BR07A Rebrand after UFH CW (update) CUSTOMS_WAREHOUSE • Customs procedure operation = USUAL_FORMS_OF_HANDLING • Activity type = REBRAND

Transaction Request
transaction_request_schema.md   transaction_request_json_schema (1).md   transaction_response_json_schema.md   The request expected by CMS to create a transaction Schema Version:   https://json-schema.org/draft/2020-12/schema Properties sourceApplication   (required) Type:   string   Description:   The unique identifier of the source application   Allowed values:   ATLAS ,   CTA terminal   (required) Type:   string   Description:   The unique identifier for a terminal reference   (required) Type:   string   Description:   The unique local reference for the request to do a declaration for a specific terminal displayReference Type:   string   Description:   The display value for the unique local reference for the request to do a declaration for a specific terminal taxCountry Type:   string   Description:   The countrycode for the country where we have to pay national tax for in this case. CMS provides the possible values in an LOV API cmsReference Type:   string   Description:   The unique cms reference so you can relate to a previous transaction overrideCheckAlert Type:   string   Description:   Ability to override (ignore) the check alert warning when applicable, so declarations are created.   Allowed values:   Y ,   N userId Type:   string   Description:   User that called the transaction rest service. presentationDateTime Type:   string   Description:   Timestamp transaction CMS. Standardized to UTC time format   Format:   date-time   Pattern:   ^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z$ normalProcedure Type:   string   Description:   Indicates if the (Customs) Normal Procedure must be applied for declarations derived from this transaction. Default N.   Allowed values:   Y ,   N customsProduct Type:   object   Description:   Combines information about the parcels customsValue Type:   object   Description:   The customs value of the combined parcels invoice **Type:** `object`
**Description:** Filled if the customs value is based on an invoice
 reference **Type:** `string`
 **Description:** the number / name of the invoice
 amount **Type:** `number`
 **Description:** the amount of money invoiced
 currency **Type:** `string`
 **Description:** the currency in which the amount is expressed, for now always use USD
 **Allowed values:** `USD`, `EUR`, Null
 incotermCode **Type:** `string`
 **Description:** Applicable Incoterm, such as CIF or FOB. Default CIF
 **Allowed values:** `CIF`, `FOB`
 elementsToInclude **Type:** `object`
 **Description:** Parts of the invoice which are important to determine customs value
 ####### freightCostsAmount   Type:   number   Description:   In case seperately indicated, the cost of freight ####### insuranceCostsAmount   Type:   number   Description:   In case seperately indicated, the cost of insurance marketValue **Type:** `object`
**Description:** Filled if the customs value is not based on an invoice
 amount **Type:** `number`
 **Description:** Value of the goods according to current market situation
 currency **Type:** `string`
 **Description:** the currency in which the amount is expressed, for now always use USD
 **Allowed values:** `USD`, `EUR`, Null
 commodity Type:   object   Description:   Information about the (end)product used for rebrand code **Type:** `string`
**Description:** The 10-digit taric code of the product
 description **Type:** `string`
**Description:** Commercial name of the product coming from the Source system
 reference **Type:** `string`
**Description:** Unique external reference of the product
 activities Type:   array of object   Description:   An array with the activity for which the transaction is sent and any activities which might run in parallel Array Items reference Type:   string   Description:   The unique local reference to the activity displayReference Type:   string   Description:   The display value for the unique local reference to the activity activityType Type:   string   Description:   The type of the activity   Allowed values:   MOVEMENT ,   SERVICE serviceType Type:   string   Description:   The type of service. Filled when the activityType is SERVICE   Allowed values:   IMPORT ,   REBRAND ,   RENAME ,   DEPARTURE ,   ADMINISTRATIVE_STOCK_TRANSFER ,   TAKE_IN ,   SHIFTING ,   COMMODITY_CODE_CORRECTION relatedReference Type:   string   Description:   Filled if it concerns a parallel activity. It holds the unique reference of the activity for which the transaction is sent executedByExternalCustomsBroker Type:   string   Description:   Shows if customs import is done by External broker. By default N. medium Type:   array of object   Description:   An array of parcels for the activities Array Items type **Type:** `string`
**Description:** Holds information about the side of the activity. If it concerns a service it will be inStorageUnit
**Allowed values:** `FROM_STORAGE_UNIT`, `TO_STORAGE_UNIT`, `IN_STORAGE_UNIT`
 storageUnit **Type:** `object`
**Description:** Information about the storage unit
 storageUnitReference **Type:** `string`
 **Description:** the reference of the storage unit
 visit **Type:** `object`
 **Description:** used if the storage unit is for a visit
 ####### visitReference   Type:   string   Description:   the local reference of the visit ####### transportMeansReference   Type:   string   Description:   How the visit is identified. In case of vessel/barge is the name, in case of truck its the license plate number ####### transportMeansTypeCode   Type:   string   Description:   The manner in which the transport means is identified, for example via license plate or via barge name.   Allowed values:   RA ,   RO ,   VES ,   BAR ,   PI ,   TANK , Null ####### transportMeansNationalityCode   Type:   string   Description:   The nationality of the means of transport ####### changedTransportArrangement   Type:   string   Description:   ? tank **Type:** `object`
 **Description:** used if the storage unit is for a tank
 ####### tankName   Type:   string   Description:   the name of the tank parcels **Type:** `array of object`
 **Description:** An array of parcels and their properties
 ####### Array Items ####### reference   Type:   string   Description:   The unique reference of the parcel ####### parentReference   Type:   string   Description:   The unique reference of the parcel from which the current parcel has been made ####### firstTimeArrival   Type:   string   Description:   Did this parcel arrive for the first time, or was it already under our license   Allowed values:   Y ,   N ####### inwardProcessingFlag   Type:   string   Description:   Has this parcel ever been subject to Inward Processing   Allowed values:   Y ,   N ####### commercialPolicyMeasureFlag   Type:   string   Description:   Is this parcel subjected to Commercial Policy Measures (CPM)   Allowed values:   Y ,   N ####### exceptionDocument   Type:   string   Description:   Are there any exception document to take into account   Allowed values:   VAG ####### parties   Type:   object ######## customer   Type:   object   Description:   Information about the Customer ######### reference   Type:   string   Description:   Unique identifier for CMS ######### name   Type:   string   Description:   The name/description ######### language   Type:   string   Description:   The language ######### eori   Type:   string   Description:   The unique registration number with EU customs ######### vatNumber   Type:   string   Description:   The identifier used for tax purposes ######### cbsCode   Type:   string   Description:   The code for this party for CBS (Centraal Bureau voor de Statistiek) ######### address   Type:   object   Description:   Address information ########## cityName   Type:   string   Description:   City name ########## countryCode   Type:   string   Description:   Country code in CMS ########## streetName   Type:   string   Description:   Street name ########## postalCode   Type:   string   Description:   Postal code ########## houseNumber   Type:   string   Description:   House number ######## consignee   Type:   object   Description:   Information about the Consignee, the receiver of a shipment ######### reference   Type:   string   Description:   Unique identifier for CMS ######### name   Type:   string   Description:   The name/description ######### eori   Type:   string   Description:   The unique registration number with EU customs ######### language   Type:   string   Description:   The language ######### exciseNumber   Type:   string   Description:   Valid SEED registration number of the authorised warehousekeeper or registered consignee ######### registeredConsigneeFlag   Type:   string   Description:   This indicates if the consignee is a registered consignee or not   Allowed values:   Y ,   N ######### cbsCode   Type:   string   Description:   The code for this party for CBS (Centraal Bureau voor de Statistiek) ######### monthlyStatementApproval   Type:   string   Description:   Indicates if the consignee makes use of monthly statement approval   Allowed values:   Y ,   N ######### address   Type:   object   Description:   Address information ########## cityName   Type:   string   Description:   City name ########## countryCode   Type:   string   Description:   Country code in CMS ########## streetName   Type:   string   Description:   Street name ########## postalCode   Type:   string   Description:   Postal code ########## houseNumber   Type:   string   Description:   House number ######## consignor   Type:   object   Description:   Information about the Consignor, the sender of a shipment. Not required. If empty, it will be derived from terminal address data ######### reference   Type:   string   Description:   Unique identifier for CMS ######### name   Type:   string   Description:   The name/description ######### eori   Type:   string   Description:   The unique registration number with EU customs ######### language   Type:   string   Description:   The language ######### exciseNumber   Type:   string   Description:   Valid SEED registration number of the authorised warehousekeeper or registered consignor ######### cbsCode   Type:   string   Description:   The code for this party for CBS (Centraal Bureau voor de Statistiek) ######### address   Type:   object   Description:   Address information ########## cityName   Type:   string   Description:   City name ########## countryCode   Type:   string   Description:   Country code in CMS ########## streetName   Type:   string   Description:   Street name ########## postalCode   Type:   string   Description:   Postal code ########## houseNumber   Type:   string   Description:   House number ######## placeOfDispatchTrader   Type:   object   Description:   Information about the party dispatching goods. Not required. If empty, it will be derived from terminal address data. ######### reference   Type:   string   Description:   Unique identifier for CMS ######### name   Type:   string   Description:   The name/description ######### eori   Type:   string   Description:   The unique registration number with EU customs ######### language   Type:   string   Description:   The language ######### referenceOfTaxWarehouse   Type:   string   Description:   Valid SEED registration number of the tax warehouse. ######### locationName   Type:   string   Description:   Name of the physical location at the terminal. Used for SHIFTING service. ######### cbsCode   Type:   string   Description:   The code for this party for CBS (Centraal Bureau voor de Statistiek) ######### address   Type:   object   Description:   Address information ########## cityName   Type:   string   Description:   City name ########## countryCode   Type:   string   Description:   Country code in CMS ########## streetName   Type:   string   Description:   Street name ########## postalCode   Type:   string   Description:   Postal code ########## houseNumber   Type:   string   Description:   House number ######## deliveryPlaceTrader   Type:   object   Description:   Information about the delivery place trader ######### reference   Type:   string   Description:   Unique identifier for CMS ######### name   Type:   string   Description:   The name/description ######### eori   Type:   string   Description:   The unique registration number with EU customs ######### language   Type:   string   Description:   The language ######### referenceOfTaxWarehouse   Type:   string   Description:   Valid SEED registration number of the tax warehouse. ######### locationName   Type:   string   Description:   Name of the physical location at the terminal. Used for SHIFTING service. ######### cbsCode   Type:   string   Description:   The code for this party for CBS (Centraal Bureau voor de Statistiek) ######### address   Type:   object   Description:   Address information ########## cityName   Type:   string   Description:   City name ########## countryCode   Type:   string   Description:   Country code in CMS ########## streetName   Type:   string   Description:   Street name ########## postalCode   Type:   string   Description:   Postal code ########## houseNumber   Type:   string   Description:   House number ######## exporter   Type:   object   Description:   Information about the exporter. Not required. If empty, it will be derived from the Seller-, or from the Customer address data. ######### reference   Type:   string   Description:   Unique identifier for CMS ######### name   Type:   string   Description:   The name/description ######### eori   Type:   string   Description:   The unique registration number with EU customs ######### language   Type:   string   Description:   The language ######### cbsCode   Type:   string   Description:   The code for this party for CBS (Centraal Bureau voor de Statistiek) ######### address   Type:   object   Description:   Address information ########## cityName   Type:   string   Description:   City name ########## countryCode   Type:   string   Description:   Country code in CMS ########## streetName   Type:   string   Description:   Street name ########## postalCode   Type:   string   Description:   Postal code ########## houseNumber   Type:   string   Description:   House number ######## seller   Type:   object   Description:   Information about the seller ######### reference   Type:   string   Description:   Unique identifier for CMS ######### name   Type:   string   Description:   The name/description ######### eori   Type:   string   Description:   The unique registration number with EU customs ######### language   Type:   string   Description:   The language ######### cbsCode   Type:   string   Description:   The code for this party for CBS (Centraal Bureau voor de Statistiek) ######### address   Type:   object   Description:   Address information ########## cityName   Type:   string   Description:   City name ########## countryCode   Type:   string   Description:   Country code in CMS ########## streetName   Type:   string   Description:   Street name ########## postalCode   Type:   string   Description:   Postal code ########## houseNumber   Type:   string   Description:   House number ####### location   Type:   object   Description:   Information about the location of the goods ######## language   Type:   string   Description:   Language used at the location of the goods ######## address   Type:   object   Description:   Address information about location of the goods ######### cityName   Type:   string   Description:   City name ######### countryCode   Type:   string   Description:   Country code in CMS ######### streetName   Type:   string   Description:   Street name ######### postalCode   Type:   string   Description:   Postal code ######### houseNumber   Type:   string   Description:   House number ####### destinationCountryCode   Type:   string   Description:   CMS code for the country where the goods are destined for ####### dispatchCountryCode   Type:   string   Description:   CMS code for the country from where the goods were dispatched ####### exitOffice   Type:   object   Description:   the exitOffice will overwrite the default exit Office of a terminal ######## reference   Type:   string   Description:   Unique identifier for CMS ######## name   Type:   string   Description:   The name/description ######## id   Type:   string   Description:   The unique ID of the exit office according the code list of customs offices: CL294 ####### origin   Type:   array of object   Description:   Information about the origin ######## Array Items ######## type   Type:   string   Description:   Indicates if the type of origin   Allowed values:   PREFERENTIAL ,   NON-PREFERENTIAL ######## countryCode   Type:   string   Description:   The code of the origin. CMS provides an LOV via API with possible values ####### commodity   Type:   object   Description:   Information about the product ######## code   Type:   string   Description:   The 10-digit taric code of the product ######## description   Type:   string   Description:   Commercial name of the product coming from the Source system ######## reference   Type:   string   Description:   Unique external reference of the product ####### customsValue   Type:   object   Description:   The customs value of the parcel ######## marketValue   Type:   object   Description:   Filled if the customs value is not based on an invoice ######### amount   Type:   number   Description:   Value of the goods according to current market situation ######### currency   Type:   string   Description:   the currency in which the amount is expressed, for now always use USD   Allowed values:   USD ,   EUR , Null ####### customsStatus   Type:   string   Description:   The standardized customs status of the goods   Allowed values:   BONDED ,   EXCISE ,   DOMESTIC ####### cargoDocuments   Type:   array of object   Description:   Cargo documents to needed for the customs declarations ######## Array Items ######## type   Type:   string   Description:   The type of the document   Allowed values:   MANIFEST_INFO ,   B_L ,   AGRIM ,   AT_R ,   EUR_1 ,   EUR_MED ,   INVOICE ,   ORIG_DECL ,   INF3 ,   STAT_ON_ORIG ,   T2L_F ,   T2L ,   E_AD ,   T1 ,   T2 ,   EVIDENCE ######## reference   Type:   string   Description:   The name/number/identication of the document ####### unNumber   Type:   string   Description:   United Nations Dangerous Goods Identifier (UNDG) ####### quantities   Type:   array of object   Description:   The quantities related to the parcel ######## Array Items ######## type   Type:   string   Description:   The type of quantity   Allowed values:   PLANNED ,   ACTUAL ######## kgv   Type:   number   Description:   quantity in kilograms in vacuum ######## kga   Type:   number   Description:   quantity in kilograms in air ######## gma   Type:   number   Description:   quantity in kilograms in air, with decimals ######## gmv   Type:   number   Description:   quantity in kilograms in vacuum, with decimals ######## l15   Type:   number   Description:   quantity in liters at 15 degrees celcius ######## l20   Type:   number   Description:   quantity in liters at 20 degrees celcius ######## ml5   Type:   number   Description:   quantity in liters at 15 degrees celcius, with decimals ######## alcPerc   Type:   number   Description:   the alcohol percentage. Percentage of ethanol ####### density   Type:   object   Description:   Information about the density of a parcel ######## value   Type:   number   Description:   Value of the density 5,2 ######## uom   Type:   string   Description:   The Unit of Measure D15 (15 vac), D1A (15 air)   Allowed values:   D15 ,   D1A Example JSON {
 "sourceApplication": "ATLAS",
 "terminal": "example_string",
 "reference": "example_string",
 "displayReference": "example_string",
 "taxCountry": "example_string",
 "cmsReference": "example_string",
 "overrideCheckAlert": "Y",
 "userId": "example_string",
 "presentationDateTime": "2023-12-01T10:00:00Z",
 "normalProcedure": "Y",
 "customsProduct": {
 "customsValue": {
 "invoice": {
 "reference": "example_string",
 "amount": 42,
 "currency": "USD",
 "incotermCode": "CIF",
 "elementsToInclude": {
 "freightCostsAmount": 42,
 "insuranceCostsAmount": 42
 }
 },
 "marketValue": {
 "amount": 42,
 "currency": "USD"
 }
 },
 "commodity": {
 "code": "example_string",
 "description": "example_string",
 "reference": "example_string"
 }
 },
 "activities": [
 {
 "reference": "example_string",
 "displayReference": "example_string",
 "activityType": "MOVEMENT",
 "serviceType": "IMPORT",
 "relatedReference": "example_string",
 "medium": [
 {
 "type": "FROM_STORAGE_UNIT",
 "storageUnit": {
 "storageUnitReference": "example_string",
 "visit": {
 "visitReference": "example_string",
 "transportMeansReference": "example_string",
 "transportMeansTypeCode": "RA",
 "transportMeansNationalityCode": "example_string",
 "changedTransportArrangement": "example_string"
 },
 "tank": {
 "tankName": "example_string"
 },
 "parcels": [
 {
 "reference": "example_string",
 "parentReference": "example_string",
 "inwardProcessingFlag": "Y",
 "commercialPolicyMeasureFlag": "Y",
 "exceptionDocument": "VAG",
 "parties": {
 "customer": {
 "reference": "example_string",
 "name": "example_string",
 "language": "example_string",
 "eori": "example_string",
 "vatNumber": "example_string",
 "cbsCode": "example_string",
 "address": {
 "cityName": "example_string",
 "countryCode": "example_string",
 "streetName": "example_string",
 "postalCode": "example_string",
 "houseNumber": "example_string"
 }
 },
 "consignee": {
 "reference": "example_string",
 "name": "example_string",
 "eori": "example_string",
 "language": "example_string",
 "exciseNumber": "example_string",
 "registeredConsigneeFlag": "N",
 "cbsCode": "example_string",
 "monthlyStatementApproval": "Y",
 "address": {
 "cityName": "example_string",
 "countryCode": "example_string",
 "streetName": "example_string",
 "postalCode": "example_string",
 "houseNumber": "example_string"
 }
 },
 "consignor": {
 "reference": "example_string",
 "name": "example_string",
 "eori": "example_string",
 "language": "example_string",
 "exciseNumber": "example_string",
 "cbsCode": "example_string",
 "address": {
 "cityName": "example_string",
 "countryCode": "example_string",
 "streetName": "example_string",
 "postalCode": "example_string",
 "houseNumber": "example_string"
 }
 },
 "placeOfDispatchTrader": {
 "reference": "example_string",
 "name": "example_string",
 "eori": "example_string",
 "language": "example_string",
 "referenceOfTaxWarehouse": "example_string",
 "locationName": "example_string",
 "cbsCode": "example_string",
 "address": {
 "cityName": "example_string",
 "countryCode": "example_string",
 "streetName": "example_string",
 "postalCode": "example_string",
 "houseNumber": "example_string"
 }
 },
 "deliveryPlaceTrader": {
 "reference": "example_string",
 "name": "example_string",
 "eori": "example_string",
 "language": "example_string",
 "referenceOfTaxWarehouse": "example_string",
 "locationName": "example_string",
 "cbsCode": "example_string",
 "address": {
 "cityName": "example_string",
 "countryCode": "example_string",
 "streetName": "example_string",
 "postalCode": "example_string",
 "houseNumber": "example_string"
 }
 },
 "exporter": {
 "reference": "example_string",
 "name": "example_string",
 "eori": "example_string",
 "language": "example_string",
 "cbsCode": "example_string",
 "address": {
 "cityName": "example_string",
 "countryCode": "example_string",
 "streetName": "example_string",
 "postalCode": "example_string",
 "houseNumber": "example_string"
 }
 },
 "seller": {
 "reference": "example_string",
 "name": "example_string",
 "eori": "example_string",
 "language": "example_string",
 "cbsCode": "example_string",
 "address": {
 "cityName": "example_string",
 "countryCode": "example_string",
 "streetName": "example_string",
 "postalCode": "example_string",
 "houseNumber": "example_string"
 }
 }
 },
 "location": {
 "language": "example_string",
 "address": {
 "cityName": "example_string",
 "countryCode": "example_string",
 "streetName": "example_string",
 "postalCode": "example_string",
 "houseNumber": "example_string"
 }
 },
 "destinationCountryCode": "example_string",
 "dispatchCountryCode": "example_string",
 "exitOffice": {
 "reference": "example_string",
 "name": "example_string",
 "id": "example_string"
 },
 "origin": [
 {
 "type": "PREFERENTIAL",
 "countryCode": "example_string"
 }
 ],
 "commodity": {
 "code": "example_string",
 "description": "example_string",
 "reference": "example_string"
 },
 "customsValue": {
 "marketValue": {
 "amount": 42,
 "currency": "USD"
 }
 },
 "customsStatus": "BONDED",
 "cargoDocuments": [
 {
 "type": "MANIFEST_INFO",
 "reference": "example_string"
 }
 ],
 "unNumber": "example_string",
 "quantities": [
 {
 "type": "PLANNED",
 "kgv": 42,
 "kga": 42,
 "gma": 42.345,
 "gmv": 42.345,
 "l15": 42,
 "l20": 42,
 "ml5": 0.5,
 "alcPerc": 42
 }
 ],
 "density": {
 "value": 42,
 "uom": "D15"
 }
 }
 ]
 }
 }
 ]
 }
 ]
}