Belgian Federal Government VenSoc Taxonomy Architecture Guide

Transcription

Belgian Federal Government
VenSoc Taxonomy
Architecture Guide
Version: 1.5
© 2008 FPS FIN – CONFIDENTIAL
VENSOC TAXONOMY ARCHITECTURE GUIDE
Table of Contents
1. Document controls..................................................................................................................... 4
DOCUMENT INFORMATION ............................................................................................................................. 4
DOCUMENT VERSIONING ............................................................................................................................... 4
2. Introduction ................................................................................................................................ 5
CONTENT OVERVIEW ..................................................................................................................................... 6
3. Domain model ............................................................................................................................ 7
INTRODUCTION ............................................................................................................................................... 7
REQUIREMENTS OF THE TAXONOMY............................................................................................................. 7
INVOLVED PARTIES AND PROCESSES ........................................................................................................... 9
RELEVANT PROCESSES ................................................................................................................................. 9
REFERENCE AUTHORITIES .......................................................................................................................... 10
DATA SCOPE OF THE TAXONOMY ................................................................................................................ 11
VERSIONING CONSIDERATIONS ................................................................................................................... 12
4. Logical model ........................................................................................................................... 13
INTRODUCTION ............................................................................................................................................. 13
TAXONOMY STRUCTURE .............................................................................................................................. 13
TAXONOMY REFERENCES............................................................................................................................ 13
SCHEMA MODULARITY ................................................................................................................................. 14
LINKBASE MODULARITY ............................................................................................................................... 15
OTHER ASPECTS .......................................................................................................................................... 16
EXTENSIBILITY ............................................................................................................................................. 16
5. Physical model ......................................................................................................................... 17
PHYSICAL COMPONENTS ............................................................................................................................. 17
FOLDER NAMING CONVENTION.................................................................................................................... 20
EXTENDEDLINKROLES ................................................................................................................................ 20
6. Annexes .................................................................................................................................... 21
LEXICON ....................................................................................................................................................... 21
OVERVIEW OF DIMENSIONS ......................................................................................................................... 22
OVERVIEW OF DATA TYPES USED BY THE VENSOC TAXONOMY ............................................................... 24
COPERFIN PROCESSES ............................................................................................................................... 25
2 / 26
PROCESSUS 1 ‘COLLECTER ET GERER DONNEES PERSONNELLES’ ......................................................... 25
PROCESSUS 2 ‘COLLECTER ET GERER DONNEES FISCALES’.................................................................... 26
PROCESSUS 5 ‘CALCULER LES DETTES, CREANCES, RISQUES FINANCIERS OU DROIT DE
REMBOURSEMENT........................................................................................................................................ 26
3 / 26
1. Document controls
Document information
Document Information
Project
FPS FIN_XBRL VenSoc
File name
be-tax-ArchitectureGuide-v1.05_ENG_STIRON
Document versioning
Date
Version
Description
20090126
1.5
Draft (This document is not a final version and can be modified)
4 / 26
2. Introduction
The VenSoc Taxonomy Architecture guide describes the architecture of the VenSoc tax return taxonomy
(hereafter referred to as VenSoc taxonomy). Version 1.0 is the version submitted for validation at the start
of the taxonomy design to guide the development of the first version of the VenSoc taxonomy. A public
exposure draft version (version 2.0) of this document will be published at the end of the design phase to
assist in the refinement of the VenSoc taxonomy in cooperation with external stakeholders.
This document is part of a full set of documents that document the VenSoc taxonomy. The full set of
documentation consists of:
Title
Filename
Content
VenSoc Taxonomy Architecture Guide
be-tax-inc-ArchitectureGuide-vxx.doc
The purpose of this
document is to detail the
architecture of the
VenSoc taxonomy.
VenSoc Taxonomy Style Guide
be-tax-inc-StyleGuide-vxx.doc
The purpose of this
document is to define the
styles guidelines to use
for defining the concepts
in the VenSoc taxonomy.
VenSoc Taxonomy Patterns Guide
be-tax-inc-PatternsGuide-vxx.doc
The purpose of this
document is to describe
the basic patterns used in
the VenSoc taxonomy,
including examples and
sample taxonomies.
VenSoc Taxonomy Preparer Guide
be-tax-inc-PreparerGuide-vxx.doc
This document provides
the necessary guidelines
for preparers of tax filings
for creating instance
documents. (This
document is not in scope
of the initial design
phase)
VenSoc Taxonomy Presentation
be-tax-inc-Taxonomy-vxx.doc
This document presents
the full VenSoc taxonomy
The file name refers to the document version number (v.x-x).
5 / 26
Content overview
Chapter 3 – Domain model provides a general overview of domain and covers the following subjects:
• The main requirements identified for the taxonomy
• The involved parties and processes
• A description of the data domain
• The organization of concepts
• Versioning comments
Chapter 4 – Logical model: describes the logical architecture of the taxonomy components.
Chapter 5 – Physical model: describes the organisation of the taxonomy in physical files and folders.
The annexes contain:
Lexicon
Overview of dimensions used in the VenSoc taxonomy
Overview of data types used in the VenSoc taxonomy
1.
2.
3.
6 / 26
3. Domain model
Introduction
The domain model describes:
1. the requirements of the taxonomy,
2. the stakeholders and parties involved,
3. the relevant processes at FPS Fin and the submitters,
4. reference authorities to the taxonomy,
5. data scope of the taxonomy,
6. versioning aspects of the taxonomy
Requirements of the taxonomy
The next table provides an overview of the requirements that have been defined to guide the design of the
taxonomy.
Requirement
Description
REQ-01: the taxonomy must
be 100% XBRL compliant.
The taxonomy must conform to the XBRL 2.1 specification, including the
Dimensions, version 1.0 specification.
REQ-02: the taxonomy should
use business terminology and
avoid technical jargon where
possible.
Terminology that can be understood by a business user should be used
and technical jargon should be avoided.
REQ-03: the data structure of
the taxonomy reflects the full
content of the tax return
forms in a robust and
consistent way.
Tax return forms provide valuable insight in the logical structure of the
concepts. The goal of the taxonomy is deliver a clear, transparent and
consistent data structure to be used by software vendors and preparers
to prepare the filings in the most efficient way. This does not necessarily
involve the exact reproduction of the current tax return forms. The
taxonomy will deliver a clear view however of the concepts used in the
respective forms by grouping these concepts in the presentation linkbase
provide support for the front
application
To assist in the validation of the submission, a clear definition of the
concepts and data types must be included in the taxonomy as well as
business rules that logic consistency of an instance document.
REQ-05: prepare for risk
control functions
FPS FIN wishes to enhance the risk control processes, allowing more
targeted control of the tax returns. This will imply more analytical
processing of the tax return data: relations between tax return concepts,
aggregations, trends, patterns & data mining, etc. The VenSoc taxonomy
should enable the consistency between the main tax return form and the
appendices as well as the extended use of the data (from the appendices
in particular) for analytical purposes.
REQ-06: the taxonomy is
aligned with other
Where possible and relevant, the taxonomy should be aligned with other
Belgian taxonomies, e.g. issued by NBB.
7 / 26
Requirement
Description
taxonomies used in the
Belgian jurisdiction
REQ-07: the taxonomy must
enable software vendors to
hide XBRL from end users1.
(Take an ‘XBRL Inside’
approach)
User friendliness is highly important for the successful market adoption of
the taxonomy. The taxonomy should take user friendliness for preparers
and submitters into account.
avoid redundancy of
concepts.
Requesting information only once is a key enabler to reduce the
administrative burden for submitters. Redundancy should be avoided
through the use of unique tags for equal concepts or referring to other
existing taxonomies.
REQ-09: contribute to
improved collaboration in
detection of fiscal and social
fraude
Improving the fraud detection via improved collaboration between
government agencies is a key objective of the policy makers, as described
in the “Plan d’action pour mieux lutter contre la fraude” > Bernard
Clerfayt. (02/07/2008). This is one of the pillars for the XBRL business
case. Collaboration between agencies against fraud depends on the
coherence of the information shared, the parties involved and the
alignment of processes. The VenSoc taxonomy should enable this by the
application of XBRL as open standard for the exchange of information.
REQ10: usefulness and userfriendly
End users must be able to use the taxonomy in an accessible way. On the
one hand this relates to FPS Finance to extend the taxonomy to be used
by the internal back office systems, data structures and validation
processes. On the other hand this relates to the mapping of the taxonomy
to common practice accounting software and accounting practices.
REQ11: performance
The structural design of the taxonomy impacts the performance of the
data processing of the tax filings received from the submitters. A
modular design enables the taxonomy to only load those parts of the
taxonomy that are relevant for the validation and processing.
REQ12: Version control
Although a versioning specification has not yet been published by XBRL
International, a solid standard for versioning control of the taxonomy is
key to manage the changes in respective taxonomies by software vendors
and preparers as well as manage the consistency with taxonomies that
1
The definition of ‘end user’ will be part of the preparer guide.
8 / 26
Requirement
Description
are referenced by the VenSoc taxonomy.
REQ13: Reusability
Reusability is at the heart of the XBRL standard, as XBRL enables the reuse
of concepts inside a taxonomy as well as concepts from other
taxonomies. The taxonomy should therefore reuse concepts as much as
possible.
REQ14: Extensibility
Extensibility enables the introduction of new concepts to a taxonomy or
link additional taxonomies. The design of the taxonomy should reflect
the tax domain in a way that the taxonomy can easily be extended to
include other parts of the tax domain. The structure and naming
conventions used for the taxonomy must enable the extension to other
domains.
Involved parties and processes
The parties involved in the design and refinement of the VenSoc taxonomy are:
• FPS Finance; FPS FIN owns the taxonomy.
• XBRL Belgium; The ”Platform XBRL Belgium” coordinates the development of XBRL within the
Belgian jurisdiction.
• National Bank of Belgium; NBB plays a key role within the jurisdiction. NBB is the owner of the [be-frpfs] taxonomy.
• Software vendors; software vendors provide software to support the tax return process.
• Intermediaries (cijferberoepen)
Relevant processes
A description of the processes that are related to the VenSoc taxonomy is provided by the Coperfin process
book (version 2002). The taxonomy relates to the functional processes of “Taxes & Recovery” in particular.
The Coperfin process book describes the to be process architecture, as defined in 2002. Please refer to the
annex of this document for a description of the Coperfin processes.
Other processes (not described in the Coperfin process book) that could benefit from the use of the VenSoc
taxonomy are:
• Process performance reporting: monitor the performance of the tax return process (process
ratio’s,...).
• Distribution of the tax return process result.
o Internal reporting
o Exchange with the NIS (National statistics office) for (macro)economic analysis.
o Exchange with other tax authorities
o Etc…
Support of these processes is not in scope of the taxonomy.
From the perspective of the preparer and submitter of the tax filings, the following processes are relevant:
1. Process – Prepare the tax return
This process includes:
• the mapping of the taxonomy to the administrative software of the submitter
• the basic up-front validations, based on the data scope of the instance document
• some input support: multi-lingual value lists,…
• the rendering of the (draft) tax return instance
9 / 26
The taxonomy supports this process in the data structure of the taxonomy that takes into account the data
structures as used by administrative software packages as well as the validation of the data entry by defining
strict data types.
2. Process – Submit the tax return
This process involves the transmission of the XBRL instance document to FPS FIN.
A preparer guide to assist software vendors and preparers in submitting the tax return, will be delivered
during the refinement phase.
3. Process – Receive feedback of the tax return processing result
This process involves the transmission of feedback messages from government to submitter.
A preparer guide to assist software vendors and preparers in submitting the tax return, will be delivered
during the refinement phase.
Reference authorities
The main authority reference for the tax filings is the Income Tax Code (WIB92 or CIR92). This code
distinguishes the following income tax categories:
Reference
Scope
French
reference
Dutch
reference
Corporate Income Tax
Belgian companies, +- 400.000.
ISoc
VenB
Individual Income Tax
physical persons
IPP
PB
Income Tax on Legal Entities
Belgian legal entities other than
“companies”; Mostly non-profit
organizations (VZW), +-93.000
IPM
RPB
Income Tax on non-residents
non-residents, includes physical and nonphysical persons; +-13.000 non-physical
entities
INR/Soc &
BNI/Ven &
INR/P.P.
BNI/Nat .
Pers.
The scope of the VenSoc taxonomy is limited to Corporate Income Tax.
Hereunder an overview of the reference texts, containing the body of knowledge for the said domain.
The taxonomy is no authority in its own right; it articulates the concepts, definitions and relationships that
are described in the below reference texts, and in a readable format for software applications.
French Reference
Dutch Reference
Description
CIR92 – Code des impôts sur
les revenus 92
WIB92 – Wetboek van de
inkomstenbelastingen 1992
Legal basis for income taxes, thoroughly
reviewed in 1992. Main reference
authority for [be-tax-inc].
AR CIR92 – Arrêté royal
d'exécution du Code des
impôts sur les revenus 92
KBWIB92 – Koninklijk besluit tot
uitvoering van WIB92
Implementing order of the tax code for
income taxes, thoroughly reviewed in
1992. Main reference authority for [betax-inc].
10 / 26
NBB pfs – core taxonomy of
the National Bank of Belgium
(NBB)
NBB pfs – core taxonomy of the
National Bank of Belgium (NBB)
A number of primary concepts from the
NBB core taxonomy can be reused
within [be-tax]. [be-tax] will copy the
NBB references for these concepts.
Data scope of the taxonomy
The following concepts are in scope for the VenSoc taxonomy:
• Primary concepts required for the tax return.
• Dimensional members required for the tax return.
• Concepts required for the presentation and structuring of the primary concepts and dimensional
members.
The following concepts are not in scope:
• Concepts required for the exact reproduction of the current tax return forms. e.g. preparer
instructions available on the forms.
• Specific concepts required for the control and processing of the tax return
The concepts to be defined in the taxonomy reflect the basic structure of today’s tax return forms.
Hereunder a visual representation of the concept organization.
Accounts
- Legal reserve
- Available reserves
- Accumulated profits
- Equity
- Investment grants
275.1 – Tax return
I – Reserves
A Taxable reserved profit
B Exempted reserved profit
II – Disallowed expenses
III – Dividends paid
Annexes
Annexes “Exempted capital gains”
276P Exemption capital gains sea vessels
275B Exemption capital gains river vessels
276N Exemption capital gains corporate vehicles
204.3 Exempted write downs debt claims and
provisions risks and expenses
275K Exemption capital gains specific securities
276K Exemption capital gains tangible and intangible
fixed assets
IV – Breakdown profit
1. Taxable reserved profit
2. Disallowed expenses
3. Dividends paid
4. Fiscal result
5. Deductions
6. Shipping profit tonnage
7. Basic taxable amount
V – Separate assessments
VI – Diamond traders and tax credit
VII – Participation exemption income
movable assets
VIII – Carry-over allowance
corporate equity
IX – Tax losses compensation
X – Tax rate
Annexes “Deductions”
275C Allowance corporate equity
275P Deduction patents
275U Investment deduction
276T Additional personnel
276W1 Additional personnel scientific research
276W2 Additional personnel development
technological potential
276W3 Additional personnel head Export department
276W4 Additional personnel head TQM department
275R Investment reserve
Tax credit
275W Tax credit research and development
Depreciations
328K Degressive depreciation
328L Revocation degressive depreciation
XI – Prepayments
XII – Clearable advance levies
XIII – Tax shelter
XIV – Documents, statements ...
XV – Financial account number
11 / 26
Versioning considerations
As to the versioning of the taxonomy, the following aspects have to be taken into consideration:
Tax assessment year
• The VenSoc taxonomy supports the tax return of corporate income taxes for any tax assessment year.
• A tax return version for a given tax assessment year needs to be maintained and supported for as long as
5 calendar years.
• Changes to the tax return are not limited or fixed to any date. This means that changes in legislation with
regard to any one tax assessment year can alter after year end.
• As companies have to file tax filings before June 30th, the taxonomy and accompanying filing
infrastructure should be available on March 31th. This enables companies to prepare their tax filings and
allows for minimal 1 month to do the actual filing.
• Currently around 5% of the VenSoc tax return forms change every year. Also new appendices are added
regularly, which in practice take the longest to be published.
Alignment with NBB
• NBB publishes a preliminary version of the NBB taxonomy for any year in the month of October
preceding the calendar year.
• NBB publishes a final version of the NBB taxonomy on January 31rst that includes updates in the value
lists (e.g. country lists) and the latest legislative changes.
• NBB publishes the accompanying software that enables companies to file their annual statements no
later than April 1rst.
• NBB publishes a yearly taxonomy version, and only supports the latest version (regardless of the
accounting period a preparer needs to submit).
• The accounting periods of NBB and fiscal periods of FPS FIN are mostly aligned; although there may be
exceptions.
Alignment with back office systems
• FPS FIN is preparing the replacement of the Vensoc application, and is considering to use an XML/XBRL
based database. Alignment of versioning is needed between the respective versions of the VenSoc
taxonomy and the application data model.
• Alignment with software vendors, preparers and submitters.
• Software vendors, preparers and submitters must have enough time available to embed the VenSoc
taxonomy in their systems and processes.
Alignment with developments of XBRL standard on versioning
• XBRL International is currently working on a versioning specification to account for changes in
taxonomies. This versioning specification is expected to be published before end of 2008.
Taking into account these considerations, the first version of the VenSoc taxonomy will address versioning by
applying a basic form of versioning that is embedded in the structure of filenames used. Please refer to
chapter 5 for the description of this versioning approach.
12 / 26
4. Logical model
Introduction
This chapter provides an overview of the logical components of the VenSoc taxonomy and how these are
related. Please note: the logical model differs from the way the taxonomy is organized in physical files and
folders. These are described in the next chapter.
• E.g.: the dimensions schema “be-tax-d” in the logical model, will be physically split in a separate
schema file (“d-“) per individual dimension.
• E.g.: the logical hypercube schema “be-tax-hc” will be physically split in separate files.
The physical files and folder structure are described in the physical model (Chapter 5).
Taxonomy structure
The taxonomy will use the following general description of the domain:
• be
the taxonomy within the Belgian jurisdiction.
• tax
the taxonomy belongs to the tax domain.
o inc
the taxonomy belongs to the income tax subdomain.
o vat
the taxonomy belongs to the value added tax subdomain (BTW/TVA).
Within the be-tax-inc domain, the following sub domains apply:
• rcorp
Residential CORPorate Income Tax
• rind
Residential INDividual Income Tax
• rle
Residential Income Tax on Legal Entities
• nrind
Income Tax on Non-Resident INDividuals
• nrcorp
Income Tax on Non-Resident CORPorations
This naming convention is key to the physical model of the taxonomy as described in chapter 5.
The scope of the VenSoc taxonomy is limited to Residential CORPorate Income Tax (RCORP). This results in
the following name of the taxonomy: be-tax-inc-rcorp.
Taxonomy references
The following external taxonomies are referenced by the VenSoc taxonomy:
• XBRL Dimension taxonomy, version 1.0
• NBB taxonomy
o The VenSoc taxonomy will not refer to the NBB ”Core” taxonomy, given the limited
reusability of these concepts; although a limited number of primary concepts from the NBB
core taxonomy will be reused within [be-tax]. [be-tax] will fully copy the NBB concepts.
o The NBB ”Data type” schema will be reused by the VenSoc taxonomy. If extension to this
schema are needed, NBB agreed to add these to the NBB data type schema to allow for one
data type schema for both taxonomies.
o The NBB ”Value list” taxonomy will be reused by the VenSoc taxonomy, and extended with
be-tax value lists.
13 / 26
Schema modularity
VenSoc tax return taxonomy (be-tax-inc-rcorp)
This schema is the entry point for the VenSoc tax return.
• It does not own any concepts, but imports concepts from “be-tax-inc” and “be-tax-hc”.
• It contains a definition linkbase: connect the primary concepts imported from the core taxonomy
(be-tax-inc) to the hypercubes imported from (be-tax-hc).
• It contains a presentation linkbase, structuring the data domain according to the current tax return
forms.
Core taxonomy (be-tax-inc)
Contains all primary and abstract concepts for the income tax domain.
Dimension taxonomy (be-tax-d-..)
The dimension taxonomy contains all dimensions used. For the VenSoc taxonomy two types of dimensions
are distinguished:
• Explicit Dimensions: commonly used breakdowns that are applied in several schedules and for several
concepts. E.g. Asset type, Investment category. Explicit dimensions have a fixed number of dimension
members.
• Typed Dimensions: these are used for non-limitative lists, where it cannot be predicted how many rows
the submitter needs to declare. E.g. capital gains.
Hypercube taxonomy (be-tax-hc-...)
Contains the hypercube concepts and imports the required dimension schema’s.
14 / 26
GCD taxonomy (gcd)
Contains company identification information. Currently owned by NBB.
Data type taxonomy
The VenSoc taxonomy will adopt the data type schema of NBB. If additional data types are needed, these
will be discussed and added to the NBB schema. Please refer to the appendices for an overview of the data
types used by NBB and the VenSoc taxonomy.
Linkbase modularity
Reference linkbases
References are provided for the concepts in the core taxonomy (be-tax-inc).
Concepts in dimensional taxonomies do not have references in the current taxonomy version; dimensions
can be reused in several tax return taxonomies in the future, with potentially different references.
Reference characteristics:
• Each reference contains the following reference parts: Publisher, Number
• Only the “Standard” reference role is used.
• Multiple references can be related to one concept (all with Standard reference role).
• References are language neutral.
Label linkbases
Labels are available in 3 languages: Dutch (NL), French (FR) and German (DE).
The ‘Standard Label’ role is required for all concepts.
Other label roles like ‘Verbose Label’ 2, ‘Terse Label’3, “Period End Label” and “Period Start Label”4 are used
when necessary to provide a relevant description of the concept in the presentation linkbase.
The “documentation” label role can be used to document the application codes that exist in the current tax
return forms, when possible and relevant.
Presentation linkbases
As the users of the VenSoc taxonomy are familiar with the current paper based or electronic forms, the
presentation linkbase in be-tax-inc-rcorp reflects reflects the current forms structure. An extended link is
created for each individual form.
Since “be-tax-inc-rcorp”; [be-tax-inc-nrcorp]; [be-tax-inc-rle] will currently be the only entry point for the betax domain, no presentation linkbase is added to “be-tax-inc”. This may need to be added when additional
entry points will be created.
Definition linkbases
Definition linkbases are only used for the dimensional taxonomies:
• [be-tax-hc-…]: dimension and hypercube definition
2
complete description of the concept
3
a very short description
4
Period Start Label and Period End Label are used for instant type concepts that require a different
representation at the beginning and at the end of the period.
15 / 26
•
•
[be-tax-inc-rcorp]; [be-tax-inc-nrcorp]; [be-tax-inc-rle]: connect the primary concepts to the
hypercubes.
Given the limited reusability, currently no definition linkbase is related to the [be-tax-d-…] schemas.
Calculation linkbases
Calculation linkbases have not been retained for this version of the taxonomy, due to its limited use.
Formula linkbases
As the final version of the XBRL Formula specification has not yet been published, formulas are not in scope
for the version 1.0 of the VenSoc taxonomy [be-tax-inc-rcorp]; [be-tax-inc-nrcorp] and [be-tax-inc-rle].
Depending the status of the specification this will be reviewed.
Other aspects
The taxonomy will provide the possibility to include attachments for non-structured annexes, these will be
stored in concepts using a data type designed for binary objects5. This capability is required to enable
submitters to file signed documents as part of the VenSoc tax returns. As this capability has also been
implemented by NBB, the be-tax will follow the NBB approach.
Extensibility
The VenSoc taxonomy does not require or allow extensions by preparers or submitters. Typed dimensions
are used for lists with an unknown number of records (non-limitative lists) and the submitter will have to
provide values for those typed dimensions in the instance document.
5
Data type is provided by NBB datatype taxonomy: pfd-dt: nonEmptyBase64BinaryItemType.
16 / 26
5. Physical model
Physical components
Considering the FRTA file naming conventions and specific needs of the VenSoc taxonomy, the following
adjusted file naming structure is defined for the VenSoc taxonomy:
•
Core taxonomy
NamespacePrefix
NamespaceIdentifier
be-tax-inc
http://www.minfin.fgov.be/be/tax/inc/
Files
Filename
Schema
be-tax-inc-<<date of publication>>.xsd
Example: be-tax-inc-2008-04-01.xsd
Label link base
be-tax-inc-<<date of publication>> -label.xml
Example: be-tax-inc-2008-07-01-label.xml
Presentation link base
Not applicable in this version of the taxonomy.
Reference link base
be-tax-inc-<<date of publication>>-reference.xml
Example: be-tax-inc-2008-04-01-reference.xml
Definition link base
•
Dimensional taxonomy schema’s
NamespacePrefix
NamespaceIdentifier
d-<<name of dimension>>
http://www.minfin.fgov.be/be/tax/d/<<name of dimension>>
Files
File Name
Schema
be-tax-d-<<name of dimension>>-<<date of publication>>.xsd
Example: be-tax-d-eiv-2008-04-01.xsd
Comment: typed dimensions are grouped in one singe schema file:
be-tax-d-ty-<<date of publication>>.xsd
Label link base
be-tax-d-<<name of dimension>>-<<date of publication>>-label.xml
Example:
be-tax-d-eiv-2008-04-01-label.xml
17 / 26
•
Hypercube taxonomy schema’s
NamespacePrefix
NamespaceIdentifier
hc-<<name of hypercube>>
http://www.minfin.fgov.be/be/tax/hc/<<name of hypercube>>
Files
File Name
Schema
be-tax-hc-<<name of hypercube>>-<<date of publication>>.xsd
Example: be-tax-hc-eiv-2008-04-01.xsd
Label link base
Be-tax-d-<<name of hypercube>>-<<date of publication>>-label.xml
Example: be-tax-hc-eiv-2008-04-01-label.xml
be-tax-hc-<<name of hypercube>>-<<date of publication >>-definition.xml
be-tax-dim-eiv-2008-04-01-definition.xml
•
Corporate tax return taxonomy
NamespacePrefix
NamespaceIdentifier
inc-rcorp
http://www.minfin.fgov.be/be/tax/inc/rcorp
Files
File Name
Schema
be-tax-inc-<<abbreviation of income tax type>>-<<assessment year>>-<<date of
publication>>.xsd
Example: be-tax-inc-rcorp-2008-2007-11-01.xsd
Label link base
publication>>-label.xml
Example: be-tax-inc-rcorp-2008-2007-11-01-label.xml
publication>>-presentation.xml
Example: be-tax-inc-rcorp-2008-2007-11-01-presentation.xml
publication>>-definition.xml
Example: Be-tax-inc-rcorp-2008-2007-11-01-definition.xml
18 / 26
•
Non-Resident Corporate tax return taxonomy
NamespacePrefix
NamespaceIdentifier
inc-nrcorp
http://www.minfin.fgov.be/be/tax/inc/nrcorp
Files
File Name
Schema
publication>>.xsd
Example: be-tax-inc-nrcorp-2008-2007-11-01.xsd
Label link base
Example: be-tax-inc-nrcorp-2008-2007-11-01-label.xml
Example: be-tax-inc-nrcorp-2008-2007-11-01-presentation.xml
Example: Be-tax-inc-nrcorp-2008-2007-11-01-definition.xml
•
Legal Entities tax return taxonomy
NamespacePrefix
NamespaceIdentifier
inc-rle
http://www.minfin.fgov.be/be/tax/inc/rle
Files
File Name
Schema
publication>>.xsd
Example: be-tax-inc-rle-2008-2007-11-01.xsd
Label link base
Example: be-tax-inc-rle-2008-2007-11-01-label.xml
Example: be-tax-inc-rle-2008-2007-11-01-presentation.xml
Be-tax-inc-rle-2008-2007-11-01-definition.xml
19 / 26
Folder naming convention
All taxonomy files will be stored in one single folder.
Folder name: be-tax-<<version date>>
ExtendedLinkRoles
In the tax return taxonomy, an extended link is created for each tax return form. It hosts the presentation
and definition linkbases for that form.
Example of naming convention:
• RoleName: rcorp-Form275.1
• Name: rcorp-Form275.1
• Definition: rcorp-Form275.1
An ExtendedLinkRole is created for each hypercube schema. It hosts the hypercube’s definition linkbase.
Example:
• RoleName: hc-ricg
• Name: hc-ricg
• Definition: hc-ricg
In the current taxonomy version, no ExtendedLinkRoles are created for dimension schema’s: these do not
have a presentation or definition linkbase.
20 / 26
6. Annexes
Lexicon
Term
Definition
Belastingplichtige
Entity submitting the tax return
VenB
“Vennootschapsbelasting Belgische Ondernemingen”: corporate tax
for Belgian companies.
Aanslagjaar
Assessment year
VenSoc taxonomy
The full set of taxonomies to support the VenSoc tax tax return.
[be-tax-inc-rcorp]
Taxonomy specific for tax on corporations
[be-tax-inc-nrcorp]
Taxonomy specific for tax on non-resident corporations
[be-tax-inc-rle]
Taxonomy specific for tax on legal entities
[be-tax-inc]
Taxonomy containing the primary concepts for the income tax
domain.
Concepts
Elements of a taxonomy, could be dimensional or not dimensional
Primary concepts
Non-dimensional XBRL concepts
21 / 26
Overview of dimensions
Hereunder an overview of the dimensions that are being used in the current forms used for VenSoc
taxonomy: (This list will be refined during the creation of the taxonomy)
Dim.
Type
Name of dimension
Explicit
BreakdownTotalDimension
This dimension contains an explicit
member for each typed dimension
(supra)
Explicit
AssetTypeDimension
Used for the tax return of capital
gains and reinvestments.
Explicit
CalendarYearDimension
Used for the “Additional
Personnel” form
Explicit
DepreciationMethodDimension
Used for the “Depreciation” forms
Explicit
InvestmentCategoryDimension
Used for the “Investment
deduction” and “Tax credit
research and development” forms.
Explicit
IncentiveCategoryDimension
Used for the “Investment
deduction” and “Tax credit
research development” forms.
Dimension members
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
TotalDomain
BreakdownMember
ReserveOtherTypedTotalMember
FixedAssetDegressiveDepreciationTypedTotalMember
ReinvestmentTypedTotalMember
FixedAssetTangibleIntangibleTypedTotalMember
CapitalGainTypedTotalMember
TaxableTypedTotalMember
ProvisionRiskExpenseTypedTotalMember
WriteDownDebtClaimTypedTotalMember
EmployeeTypedTotalMember
AssetTypeDomain
CorporateVehicleMember
SpecificSecurityMember
RiverVesselMember
TangibleIntangibleFixedAssetsMember
FixedAssetMember
SeaVesselMember
CalendarYearDomain
CalendarYearAssessmentYear-1Member
CalendarYearAssessmentYear-2Member
•
•
•
DepreciationMethodDomain
DegressiveDepreciationMember
RevocationDegressiveDepreciationMember
•
•
InvestmentCategoriesDomain
PromoteReutilisationRefillableBeveragePackagesReusable
IndustrialProductsMember
SecurityDevicesMember
EnergySavingsMember
PatentsMember
ResearchDevelopmentMember
SmokeExtractionAirTreatmentSystemsHorecaOutletsMem
ber
SeaVesselsNonBelgianOriginMember
IncentiveCategoryDomain
InvestmentDeductionNoTaxCreditResearchDevelopment
Member
InvestmentDeductionTaxCreditResearchDevelopmentMe
mber
TaxCreditResearchDevelopmentMember
•
•
•
•
•
•
•
•
•
•
22 / 26
Dim.
Type
Explicit
Name of dimension
EmploymentFunctionDimension
Used for the tax return forms
related to hiring specific personnel.
Explicit
EmploymentPeriodDimension
Used for the tax return forms
related to hiring specific personnel.
Explicit
TaxPeriodDimension
Used for the “Investment reserve”
form
Dimension members
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
EmploymentFunctionDomain
DepartmentHeadTQMMember
DepartmentHeadExportMember
HighlyQualifiedResearcherMember
EmployedIncreaseTechnologicalPotentialMember
ResearcherMember
EmploymentPeriodDomain
PersonnelHiredTaxPeriodFullTimeMember
PersonnelHiredTaxPeriodFullTimeReplacementMember
PersonnelHiredPreviousTaxPeriodFullTimeMember
PersonnelHiredPreviousTaxPeriodPartTimeMember
PersonnelHiredPreviousTaxPeriodEmploymentEndedMem
ber
PersonnelFullTimeTransferTaxPeriodMember
TaxPeriodDomain
TaxPeriodAssessmentYear-1Member
Typed
AllowanceCorporateEquityTypedDi
mension
(Non-limitative list)
Typed
CapitalGainTypedDimension
Typed
ReinvestmenTypedDimension
Typed
ReserveOtherTypedDimension
Typed
FixedAssetDegressiveDepreciationT
ypedDimension
Typed
ProvisionRiskExpenseTypedDimens
ion
Typed
WriteDownDebtClaimTypedDimens (Non-limitative list)
ion
Typed
EmployeeTypedDimension
Typed
InvestmentTypedDimension
23 / 26
Overview of data types used by the VenSoc taxonomy
Hereunder an overview of the data types is presented that are being used in VenSoc taxonomy:
Data Type
Defined by
Used in
VenSoc
Taxono
my
Explanation
Example
Monetary14D2ItemType
NBB
yes
Monetary value
14 positions +
2 decimals
Standard format
for most
monetary
values
nonNegativeDecimal6D1ItemType
NBB
yes
Number of
employees in
FTE
nonNegativeDecimal6D2ItemType
NBB
yes
nonNegativeInteger11ItemType
NBB
yes
Numeric, non
negative value
6 positions +
1 decimal
Numeric, non
negative value
6 positions +
2 decimals
Non negative integer
value
11 positions
VenSoc, will
be added to
NBB data
types
yes
value
1 position, value
ranging from 1 to 6
Number of
hours,
reference
numbers
NBB
yes
nonNegativeMonetary14D2ItemType
NBB
yes
nonPositiveMonetary14D2ItemType
NBB
yes
value
6 positions
Non negative
monetary value
14 positions +
2 decimals
Non positive
monetary value
14 positions +
2 decimals
nonNegativeSharesIntegeterItemType
NBB
yes
Number of
employees in
FTE
Number of
hours,
reference
numbers
Zero or more
Zero of less
Non negative
24 / 26
number of shares
sharesIntegerItemType
NBB
yes
yes
Integer number of
shares
Decimal value
1 position +
4 decimals
percentageItemType
NBB
0,xxxx,
maximum value
equals 1
nonEmptyBase64BinaryItemType
NBB
Yes
Binary large objects
pdf document
Coperfin processes
Processus 1 ‘Collecter et gérer données personnelles’
Raison d’être
Le processus ‘collecter et gérer données personnelles’ sert à identifier tous les contribuables (potentiels)
et à rassembler leurs données ‘personnelles’, correctes et actuelles, et à les structurer dans un dossier
unique. A cet effet, on tient compte des directives générales relatives au dossier unique telles qu’elles
sont définies aux niveaux N-1 et N-2. Le processus ‘collecter et gérer données personnelles’ vise
également à réunir toutes les données disponibles au sein et en dehors du SPF Finances qui sont relatives
à ces contribuables (personnes physiques, morales, associations de fait,…) et à les gérer. Ainsi, ce
processus permet également aux autres processus de mieux suivre les droits et obligations du
contribuable.
Alors que le processus ‘collecter et gérer données fiscales’ et ‘collecter et gérer données préavis d’arriv.
et déclarations’ sont axés sur les données relatives à la situation fiscale et non fiscale d’un contribuable,
le processus ‘collecter et gérer données personnelles’ se concentre sur les données relatives au
contribuable en personne. Ce sont ces données qui aideront spécifiquement à déterminer la meilleure
méthode d’interaction dans toutes ses formes, eu égard aux caractéristiques du contribuable.
Le processus englobe la création initiale du dossier unique en termes de contenu. C'est la raison pour
laquelle on tient compte de la collecte de données essentielles pour les prestations de services, la
vérification et le recouvrement lorsque l’on met sur pied ce processus.
Comme l’utilisation de ces données s’étend au-delà du SPF, on contrôle également dans le cadre de ce
processus, la qualité des données. Lors d’inconsistances, un signal est envoyé au propriétaire des
données.
Les principaux objectifs de ce processus visent à :
- Identifier tous les contribuables potentiels (et les autres catégories de citoyens /entités pertinentes)
- Organiser le rassemblement de ces données en fonction du principe de ‘fourniture unique de
données’
- Réunir ces données personnelles dans un dossier unique dont les principes sont respectés dans tout
le SPF Finances
- Obtenir ou entrer toutes les données nécessaires par la voie électronique
- Veiller à un rassemblement de données aussi exhaustif et correct que possible afin qu’il n’y est pas de
distorsion dans les résultats des analyses réalisées dans le cadre des processus ‘compréhension des
clients’ et ‘gestion des risques’ sur la base de ces données.
- Etablir les relations correctes entre les différents contribuables/entités afin d’obtenir une vue
globale et exacte (p.ex. famille, relations entre les PME, fonctions au sein de PME /GE)
25 / 26
-
Renforcer l’accessibilité de l’administration en désignant un account manager/poste de travail
(responsable en premier ligne de la gestion d’un certain dossier)
Processus 2 ‘Collecter et gérer données fiscales’6
Raison d’être
Le processus ‘collecter et gérer données fiscales’ sert à :
- obtenir toutes les informations relatives à la situation fiscale d’un contribuable identifié
(informations rassemblées par l’administration elle-même, informations récoltées sur base des
déclarations, informations récoltées après réaction du contribuable)
- structurer après validation des exigences de forme, les informations dans un dossier unique.
- détecter des anomalies objectives et les résoudre. Il s’agit d’anomalies que l’on n’a pas détectées
lors d’une vérification de la situation fiscale mais qui visent à corriger de manière objective les
éléments fiscaux. (p.ex. % de déduction des frais de restaurant)
- traiter les litiges/contentieux susceptibles d’en découler.
Processus 5 ‘calculer les dettes, créances, risques financiers ou droit de
remboursement7
Raison d’être
Le processus ‘calculer les dettes, créances, risques financiers ou droit de remboursement’ sert à calculer
le montant dû ou à rembourser pour tous les types d’impôts (séparément) et d’indiquer comme montant
dû par ou pour le contribuable. Pour certaines impôts le montant est incorporé dans le bilan de synthèse
qui établit un aperçu de l’ensemble des obligations financières entre les administrations et les
contribuables et en effectue le suivi.
Les principaux objectifs de ce processus visent à :
- Tenir à jour un relevé complet des droits et obligations fiscales du contribuable par le biais d’un
historique complet et correct des interactions financières proactives avec ce contribuable.
- Calculer correctement les impôts (inclus les impôts régionalisés), les droits, droits de magasin,
amendes et rétributions et attribuer ceux-ci à la personne qui a l’obligation de s’en acquitter
- Calculer correctement les risques financiers (par ex. : le calcul de la garantie à déposer dans le cas
d’importation temporaire D&A)
6
Remarque : dans le cadre de ce processus ne seront pas uniquement traités les impôts directs et la TVA mais également les taxes de circulation avec
signe distinctif fiscal, les taxes de circulation sans signe distinctif fiscal, appareils automatiques de divertissement, eurovignettes, jeux et paris,
précomptes immobiliers.
7
Remarque : dans le cadre de ce processus ne seront pas uniquement traités les impôts directs et la TVA mais également les taxes de circulation avec
signe distinctif fiscal, les taxes de circulation sans signe distinctif fiscal, appareils automatiques de divertissement, eurovignettes, jeux et paris,
précomptes immobiliers.
26 / 26

Belgian Federal Government VenSoc Taxonomy Architecture Guide

Transcription

Documents pareils

1255565750 mrs. fafa isabel nyirenda

Pilgrimage and Family Day

Vocabulaire 1. avec soin with care 2. argent silver 3. la commode

Revue de presse ANGLAIS Semaine du 03 au 09 octobre 2011

lease help Vic`s friends by connecting them to their right house!

tableau numbers 99 - collège Saint Eutrope

set-list - Les Old Boys

Programming a new Remote

Jacksonville State University College of Arts and Sciences Updated

Surface : 49.17m² / Price : 265 000