INTEGRATED CUSTOMS DUTY AND TAX SYSTEM

 

MODEL AND IMPLEMENTATION IN THE SOLUTIONS OF SKG S.A.
September 2011

 

ASSUMPTIONS

Based on its long-standing experience in building and servicing customs duty systems, SKG S.A. has developed a conceptual model of the customs duty system used in various customs clearance processes particularly for international exchange of goods. This model is founded on the following assumption – the customs duty system is not a monolithic kernel. It consists of interfaced subsystems and each of them:

  • operates and may be developed independently,
  • communicates with the other subsystems via well-defined interfaces based on SOAP protocol,
  • may operate on various hardware and software platforms,
  • may be delivered by different suppliers and made in different technologies,
  • can provide the requirements for all global regional trading as well as customs purposes,
  • can provide a quick and economic functional use for local and regional purposes.

 

MODEL

The figure presents logical view of the customs duty system model. It includes the most essential subsystems that may be built separately using various technologies as they communicate among one another using Service Oriented Architecture (SOA). It is also possible to use existing components to integrate with other subsystems.

 

INTEGRATED CUSTOMS DUTY AND TAX SYSTEM

 

 

OPERATING SUBSYSTEMS – HANDLING CUSTOMS CLEARANCES

The most distinct parts of the customs duty system are related to handling three basic customs procedures i.e. Import, Export and Transit.

These subsystems operate upon similar patterns of handling customs declarations submitted by entities i.e. declaration acceptance, decision on inspection, possible management of inspection proceedings and release for customs procedure. From the perspective of technology, all these sub¬systems can be created as one system. In practice however, they are developed by different suppliers at different times and due to many other factors made separately in many European countries. Such situation takes place in Poland. Celina system, that originally handled the entire customs procedure, has been successively divided into three indepen¬dent subsystems (NCTS, ECS, ICS) on the account of EU requirements.

 

Taking into consideration the fact that handling inspection proceedings (detailed determination of tasks, assignment of officers in charge and results registration) is common to import, export and transit making Inspection Subsystem a separate part is reasonable. Inspection Subsystem is designed to suit all the Operating Subsystems. As for technology, when handling import, export and transit procedures several services and sets of data are found identical i.e. risk analysis, validation, charge calculation, securities balancing, declaration linking and balancing, handling quotas, shared reference data, user authentication and authorisation processes, e-signature service, storing documents in repository and making them available. These functionalities are designed as separate Servi¬ce Subsystems.

 

Tasks, customs authorities are responsible for, including customs inspection and supervision, though necessary, generally impede business activities. However, technological progress and computerisation of the customs services makes it possible to limit these difficulties by fully electronic management of communication between authorities and entities – starting from declaration submission up to the receipt of confirmation that customs proceedings have been completed. In this model, the customs declara¬tion is sent by one of three electronic means:

  • Entity Application used directly – via non-vi- sual SOAP-based interface available through Enterprise Service Bus (ESB),
  • E-mail,
  • Web browser via Customs Duty Portal.

 

The declaration is checked by Service Validation Subsystem (Validator), stored in Document Repository and directed to the applicable target Import/Export/Transit Subsystem. When declaration handling, at crucial moments of the process, e.g. when the identification number is assigned, decision on inspection is made, release for procedures or completion, the return information is sent back to the entity and at the same time stored in Document Repository. This operation allows business entities to receive information on ongoing customs procedu¬res almost immediately.

 

Customs declaration handling does not cover only country’s territory or customs authorities’ operation scope. The information obtained when declara¬tion handling is often required by foreign customs or fiscal authorities. For example, the information on completion of export services is essential for the reasons of VAT reimbursement. Therefore mutual transfer of information covering the status of decla¬ration handling between customs and fiscal offices in different countries is essential. In the presented model, it is achieved by exchanging messages between customs authorities and other offices by means of ESB, using standard (e-mail, webservice, WWW) or specialised (e.g. CCN/CSI to exchange messages among customs offices in dif-ferent EU countries) communication methods. These documents are also stored in Document Repository.

 

One of the most significant problems of the customs authorities is to balance the number of performed customs inspections in relation to the total number of clearances and obtain the maximum efficiency in detecting abuses and offences, in a competent manner. Analyses carried out upon real historical data concerning clearances are found very helpful in solution of this problem. In order to perform such analyses the data from operating and other subsystems are replicated into Analytical Database on an ongoing basis. Searching for trends, irregularities and anomalies using applicable analytical tools makes no adverse impact on the efficiency of the other systems. The results of these analyses are then taken into account when formulating the rules of operation for Risk Analysis and Post-Control Subsystems to ensure feedback and growth in control efficiency. The additional benefit of using the Analytical Databa¬se is the ability to create reports of any type e.g. for statistical reasons or to combine data from different subsystems.

 

BACK-OFFICE SUBSYSTEMS

In case of Back-office Subsystems, as opposed to the Operating Subsystems, duration of handling individual matters is not critical. As for architecture, they are able to interoperate with other subsystems in the same way as operating subsystems do, including managing communication between entities and other authorities through ESB and storage of sent and received documents in Repository. The essential data gathered in these subsystems can also be replicated into Analytical Database.

 

Finance Management Subsystem
Is supplied with information on required charges from the Operating Subsystems through ESB and makes settlements. Depending on the rules regarding settlement of charges applied in a given country, electronic communication with banks, ensured by ESB, may be necessary.

 

Securities Handling Subsystem
Processes documents related to the issuance of warranties/securities and feeds these data into the Securities Balancing Subsystem (refer to: Service Subsystems). Permits Handling Subsystem supports permit issuance process the results of which are transferred as permits to Reference Data Subsystem (refer to: Service Subsystems). Entities and offices exchange messages, standing for claims and decisions, using ESB and Repository.

 

Permits Handling Subsystem
Supports permit issuance process the results of which are transferred as permits to Reference Data Subsystem (refer to: Service Subsystems). Entities and offices exchange messages, standing for claims and decisions, using ESB and Repository.

 

Administration Penalty Procedures Subsystem
Supports administration proceedings handling. It is a typical system to manage document circulation that cooperates with Operating Systems and Finance Management Subsystem by message exchange thro¬ugh ESB and Repository.

 

Post-Control Subsystem
Handles business entity audit process. The results of analyses performed by Analytical Database and entities data stored in EORI Register constitute its source of data.

 

SERVICE SUBSYSTEMS

Customs Tariff is designed for storing the infor¬mation on goods nomenclature as well as rates and algorithms necessary to calculate charges. For solutions applied in EU member states goods nomenc¬lature and customs rates are taken from TARIC sys¬tem through ESB. In addition, rates of taxes typical of a given country, e.g. VAT and excise, are updated. Apart from data collection function, Customs Tariff provides services covering calculation of charges and analyses of declarations with regard to bans, antidumping measures etc, used by Operating Sub¬systems and published via Customs Duty Portal to make available for entities.

 

Reference Data Subsystem
Acts as a source da¬tabase for other subsystems. It stores reference data distributed to other subsystems by means of ESB. In this case, reference data means both simple code- value lists (e.g. the list of country codes) and data with more complex structure (e.g. permits, customs office detailed data, working hours of offices, rates of exchange etc). The management of these data in one place eliminates any inconsistencies related to the reference data in other subsystems and also exempts them from the duty to manage these data. Other subsystems or CS/RD application, as in case of the European Union, is a source of some part of reference data. However, even in such cases, data are also gathered in Reference Data Subsystem and distributed to other subsystems, in order to ensure efficient data coherence management.

 

EORI Register
Identification and address data are also meant as reference data. EORI Register acts as a separate subsystem as these data are managed in a distinctive way. Entities’ data are synchronised with data available in a central EU register and made available when declaration handling. EORI Register stores information concerning AEO status as well.

 

Validator
Is a complex service that validates mes¬sages exchanged using ESB. Validation is a multi- stage process that starts from checking the struc¬ture, comparing data with codified values stored in Reference Data Subsystem up to validation against rules, designed to be configured. Validator generates two kinds of messages: “warnings” and “errors”. Generated “warning” does not resuit in rejection of the message it concerns but provides customs authorities and entities with information that facilitates completion of customs proceedings according to regulations in force.

 

Risk Analysis Subsystem
Is called up when handling the customs declaration. It provides Ope¬rating Subsystems with information concerning risk level and customs officers with instructions concer¬ning controls, returned as directives. Directives are a result of declaration scanning made on the basis of algorithms, referred to as the profiles, created with a specialised editor. Profiles are the effect of analyti¬cal works performed using Analytical Database.

 

Authentication and Authorisation Subsystem and E-Signature Service Subsystem
Is to protect the functions of the Customs Duty System against unauthorised access and make communication with other systems more secure. They additionally handle e-signature and encode documents exchanged between the customs duty system and the outside world.

 

Security Balancing Subsystem
Its bidirectional cooperation with operating subsystems is distinctive, i.e. when charging the security/warranty balance and releasing the balance after the customs procedure has been completed. In addition, it is possible for business entities to preview their security balances. ESB is used for this cooperation.

 

Quota Management Subsystem
Cooperates with operating subsystems (import handling) and, in case of EU member states, with the EU Quota Manage¬ment System. Communication takes place via ESB.

 

Document Repository
Repository for any essential electronic documents and messages exchanged between customs duty system and the outside world (entities, customs offices in other countries, other authorities, banks, etc) and between particular subsystems. This subsystem acquires particular significance when use of paper documents is abandoned – then electronically signed documents stored in Repository are the only reliable source of data derived from the received/sent documents (no paper documents). Repository stores not only customs declarations but also documents attached, if available in electronic form. Apart from the content of documents, the repository also allows storing the additional related information in the form of metadata, easy to search for. The metadata describe relationship among the documents stored in Repository, such as the fact that a specific document is an enclosure or a return document. The metadata also contain information about the message receiver and sender, reference numbers etc. Generally, Repository stores documents of any type, but the most typical formats are XML and PDF.

 

ANALYTICAL DATABASE

In Analytical Database, any significant informa¬tion derived from other subsystems is gathered and used for analyses and reporting. Apart from data, analytical tools constitute a very important component of this subsystem.

 

ENTERPRISE SERVICE BUS – ESB

Allows subsystems to integrate and communicate with one another and the outside world. It is particularly essential for providing communication among subsystems, made in various technologies by different manufacturers that due to technical restrictions are not able to interoperate with other subsystems directly. ESB makes interfaces between providers and consumers of services flexible. Moreover, thanks to address information directs messages to applicable recipients and, if necessary, converts messages and communication protocols to mediate between provider and consumer interfaces. ESB allows construction of complex services to facilitate subsystems integration. Document Repository, that cooperates with ESB when exchanging messages between cor- respondents, constitutes its essential element.

 

CUSTOMS DUTY PORTAL

The task of Customs Duty Portal is to ensure, over the Web, transfer of documents to Customs Subsystems. Moreover, using Customs Duty Portal, it is possible to follow document state in customs procedures, by having access to Repository. Cu¬stoms Duty Portal makes content-related (regulations, acts etc) and technical (reference data, techni¬cal specifications of interfaces) information available to entities. Customs Duty Portal communicates with Customs Subsystems using the same interface, availabie through ESB, as entities’ applications.