XBRLmapper: Difference between revisions

From XBRLWiki
Jump to navigationJump to search
Line 24: Line 24:


===Generating XBRL (Mapper)===
===Generating XBRL (Mapper)===
Generating XBRL is one of the operations for which the mapper was conceived. In this documentation Mapper is the process of obtaining data from data repositories in order to create an XBRL report.
The XBRL Mapper product designed by Reporting Standard S.L. is adapted to work in the most complex scenarios. The XBRL Mapper is robuts, powerful and flexible.
* Robust because it is based on a native XBRL API that supports 100% Conformance level with XBRL Validation
* Powerful because it is based on an architecture that allows the users to plug-in drivers prepared to read different data sources and prepare combinations of data sources attending "mapping events".
* Flexible because it allows users to easily migrate to new taxonomies by just changing the instance document template but maintaining the same "mapping event" names and driver configurations. Or to adapt the system to obtain data from different data sources while using the same target taxonomy.
The configuration of the mapping engine requires then two steps:
# Preparing an instance document template and the definition of the "mapping events"
# Preparing the configuration file for the driver(s) attending "mapping events"


====The instance document template====
====The instance document template====
The instance document template is the configuration file where the "mapping events" are defined. The creation of an instance document template is a simple process


====Drivers====
====Drivers====

Revision as of 18:43, 28 June 2009

XBRLmapper WIKI

Product page

[XBRL Mapper product page]

Descripcion

XBRLmapper is a sofisticated tool that transfers data from information systems to XBRL reports and from XBRL reports to other systems. It supports then two different purposes:

  1. Automatic generation of XBRL reports from different data sources
  2. Automatic extraction of data from XBRL reports and data loading into different repositories

Both products share a similar architecture. Both are based on a common definition of data events connected with the XBRL side and specific drivers that attend the data events. Both sides (definition of events, and driver) can be configured using XML files. This architecture has multiple advantages:

  1. Isolates the complexity of the XBRL Technology in one part (the data events). If the taxonomy changes the user may need to change just the connection between the events and the taxonomy or instance templates
  2. Isolates the complexity of the internal data repositories each one of the repositories may be accessed by an intantiation of a specific driver
  3. Each driver has his own configuration file that is specific for the data repository it is specialized
  4. The generation of an XBRL report may involve several drivers looking at data in different repositores simultaneously
  5. The same event could be potentially attended by more than one driver
  6. Multiple drivers of the same repository type can be used concurrently

The XBRL mapper is a software component that can be launched from a GUI or can be integrated in a workflow. The integration requires development of code (in Java or .NET)

Generating XBRL (Mapper)

Generating XBRL is one of the operations for which the mapper was conceived. In this documentation Mapper is the process of obtaining data from data repositories in order to create an XBRL report.

The XBRL Mapper product designed by Reporting Standard S.L. is adapted to work in the most complex scenarios. The XBRL Mapper is robuts, powerful and flexible.

  • Robust because it is based on a native XBRL API that supports 100% Conformance level with XBRL Validation
  • Powerful because it is based on an architecture that allows the users to plug-in drivers prepared to read different data sources and prepare combinations of data sources attending "mapping events".
  • Flexible because it allows users to easily migrate to new taxonomies by just changing the instance document template but maintaining the same "mapping event" names and driver configurations. Or to adapt the system to obtain data from different data sources while using the same target taxonomy.

The configuration of the mapping engine requires then two steps:

  1. Preparing an instance document template and the definition of the "mapping events"
  2. Preparing the configuration file for the driver(s) attending "mapping events"

The instance document template

The instance document template is the configuration file where the "mapping events" are defined. The creation of an instance document template is a simple process

Drivers

Moving XBRL data (Loader)

The definition of the loading events

Drivers

Navigate

Main Page